Комментарии 13
Спасибо за статью!
Спасибо! Полезная информация, в закладки.
НЛО прилетело и опубликовало эту надпись здесь
Диски могут быть тонкими и дедуплицироваться, ядра можно делить между несколькими ВМ, а память если используется, то практически монопольно
Если у вас резервируется память, то откуда взялся VSWP из статьи?
У платформы vСloud Director есть особенность: она резервирует на диске место под оперативную память ВМ в момент её запуска.
Мы не говорим про конкретного облачного провайдера, в каких-то случаях резервирование память на 100% оправдано и своп не создаётся. Но часто операторы пытаются экономить, но это не значит, что ВМ будет свопится туда. Просто не все клиенты оптимально используют память, и очень много выделено для Вм, но фактически не используется никогда.
Также речь не только про своп, а и про дамп памяти ВМ, при её приостановке, например.
Также речь не только про своп, а и про дамп памяти ВМ, при её приостановке, например.
Оказывается платформа тут ни при чем, просто некоторые провайдеры так экономят на лицензиях, чтобы побольше заработать.
Начнём с того, что статья «немножко устарела». С такими вещами, как vCD (да и вообще продукты VMware) зачастую нет смысла читать статьи такого возраста. Блин, даже дисковые и cpu шедулеры меняются.
А вот по существу: создание .vswp это поведение vSphere, а не vCD. Логично, что при отсутствии резервирования памяти, размер этого файла будет равен размеру памяти VM. Ключевой момент в том, что это своп уровня гипервизора, а не уровня гостя, т.е. vswp read/write происходит в том случае, когда у гипервизора не достаточно RAM для предоставления VM (если со стороны VM есть «demand»). Т.е. .vswp не будет и не должен работать, если имеет место мисконфигурация VM и её дали памяти сильно меньше, чем нужно гостю. Если сделать полное резервирование памяти, то файл .vswp на датасторе всё равно будет создан, но он будет минимального размера.
Теперь о vCD: при создании машин от команды vCD (а не напрямую в vSphere) резервирование памяти для VM не предусмотрено. Есть резервирование на уровне Resource Pool, который фактически является vCD Organization VDC. Пример: вы купили 1 TB памяти с 20% резервированием с моделью Allocation Pool. Это значит, вы можете создать машины с суммарной сконфигурированной RAM 1 TB. Создаёте машину с 64 GB RAM, и на ресурс пул приземляется Reservation 20% от 64, т.е. 12800 (а не сразу 200 GB, что есть 20% от 1TB). А вот на уровень VM резервирование не прилетает. Это нормальное поведение vCD (правда, я давно не интересовался моделью reservation и совсем не интересовался flex).
И более того, даже если вы заразерервируете память на уровне VM, vCD на это плевать и он зачтёт размер памяти в requested storage. Емнип, у vCD в схеме базы даже нет полей с данными резервирования compute ресурсов на уровне именно VM. Т.е. при синке inventory он этих данных от vCenter'а не получает, да ему и не зачем (типа логика «облачности» тогда страдает, ну вот эта вот философия, ага). Пример: создали вы VM 40GB диск, 40 GB RAM. Вам админ vSphere зарезервировал всю память на этой VM (за красивые глаза), включаете. Но Requested Storage на Storage Policy всё равно будет 80 GB. Это точно справедливо для vCD 9.1 и 9.5 (уверен, что для 9.7 и 10 в этом плане ничего не поменялось).
А вот по существу: создание .vswp это поведение vSphere, а не vCD. Логично, что при отсутствии резервирования памяти, размер этого файла будет равен размеру памяти VM. Ключевой момент в том, что это своп уровня гипервизора, а не уровня гостя, т.е. vswp read/write происходит в том случае, когда у гипервизора не достаточно RAM для предоставления VM (если со стороны VM есть «demand»). Т.е. .vswp не будет и не должен работать, если имеет место мисконфигурация VM и её дали памяти сильно меньше, чем нужно гостю. Если сделать полное резервирование памяти, то файл .vswp на датасторе всё равно будет создан, но он будет минимального размера.
Теперь о vCD: при создании машин от команды vCD (а не напрямую в vSphere) резервирование памяти для VM не предусмотрено. Есть резервирование на уровне Resource Pool, который фактически является vCD Organization VDC. Пример: вы купили 1 TB памяти с 20% резервированием с моделью Allocation Pool. Это значит, вы можете создать машины с суммарной сконфигурированной RAM 1 TB. Создаёте машину с 64 GB RAM, и на ресурс пул приземляется Reservation 20% от 64, т.е. 12800 (а не сразу 200 GB, что есть 20% от 1TB). А вот на уровень VM резервирование не прилетает. Это нормальное поведение vCD (правда, я давно не интересовался моделью reservation и совсем не интересовался flex).
И более того, даже если вы заразерервируете память на уровне VM, vCD на это плевать и он зачтёт размер памяти в requested storage. Емнип, у vCD в схеме базы даже нет полей с данными резервирования compute ресурсов на уровне именно VM. Т.е. при синке inventory он этих данных от vCenter'а не получает, да ему и не зачем (типа логика «облачности» тогда страдает, ну вот эта вот философия, ага). Пример: создали вы VM 40GB диск, 40 GB RAM. Вам админ vSphere зарезервировал всю память на этой VM (за красивые глаза), включаете. Но Requested Storage на Storage Policy всё равно будет 80 GB. Это точно справедливо для vCD 9.1 и 9.5 (уверен, что для 9.7 и 10 в этом плане ничего не поменялось).
Разве своп как раз на самых быстрых дисках не должен быть в общем случае, если планово допускается активное свопование? Или дешевле памяти добрать?
Если у вас ВМ свопится, то это плохой провайдер. Тут лучше что-то другое придумать. Но если свопится, то быстро.
Кажется мы о разных свопах. Я о свопе в самой виртуалке.
Я тут выше немножко расписал. Но вот два примера:
1. Вы дали машине 8GB RAM, запустили, внутри гостя (например, венда) создается swap-файл, т.е. внутри VMDK, прям на файловой системе (скажем, NTFS). И вот приложение в вашем госте начинает требовать больше, чем вы дали машине. У гипервизора свободной памяти в достатке, но VM страдает просто из-за мисконфигурации. А вот начинается активная запись в swap и чтение из него (тот, который внутри гостя на NTFS лежит). Машине плохо, но гипервизор в этом не виноват;
2. Вы дали машине 8GB RAM, запустили. Demand у неё 6GB, и ей этих 8 хватает. Внезапно у гипервизора перестаёт хватать памяти для неё (из-за noisy neighbour'а, например) и он может выделить только 2, а вот нужные 6 не может. И вот если не спасают всякие танцы TPS (который если современный, с солью, и его не конфигурировали, то сильно он не сдедуплицирует), не помог balooning, то в последнюю очередь начинает работать swap на уровне гипервизора и он пишет туда данные вытесненных страниц памяти. Это когда уже у ESXi не хватает памяти для VM. Этот файл .vswp создается на датасторе vSphere в каталоге VM, а не внутри гостя (не в вашей венде). Это крайний случай механизмов экономии памяти, он работает последним и если он запустился, то это плохо. Более того, даже приходится делать ручной unswap (или ребут хехе), но это уже другая история. В общем, этот .vswp файл по размеру соответствует размеру памяти VM (сконфигурированной памяти), что логично. Но при достаточном количестве ресурсов он не активен, т.е. запись в этот файл не ведется, как нет и чтения из него.
Так вот, если у гипервизоров массово не хватает памяти для VM, и .vswp файлы активно пишутся и читаются, то вас вряд ли спасёт даже современный all-flash массив.
Ну вот это вот на пальцах так, кратко.
1. Вы дали машине 8GB RAM, запустили, внутри гостя (например, венда) создается swap-файл, т.е. внутри VMDK, прям на файловой системе (скажем, NTFS). И вот приложение в вашем госте начинает требовать больше, чем вы дали машине. У гипервизора свободной памяти в достатке, но VM страдает просто из-за мисконфигурации. А вот начинается активная запись в swap и чтение из него (тот, который внутри гостя на NTFS лежит). Машине плохо, но гипервизор в этом не виноват;
2. Вы дали машине 8GB RAM, запустили. Demand у неё 6GB, и ей этих 8 хватает. Внезапно у гипервизора перестаёт хватать памяти для неё (из-за noisy neighbour'а, например) и он может выделить только 2, а вот нужные 6 не может. И вот если не спасают всякие танцы TPS (который если современный, с солью, и его не конфигурировали, то сильно он не сдедуплицирует), не помог balooning, то в последнюю очередь начинает работать swap на уровне гипервизора и он пишет туда данные вытесненных страниц памяти. Это когда уже у ESXi не хватает памяти для VM. Этот файл .vswp создается на датасторе vSphere в каталоге VM, а не внутри гостя (не в вашей венде). Это крайний случай механизмов экономии памяти, он работает последним и если он запустился, то это плохо. Более того, даже приходится делать ручной unswap (или ребут хехе), но это уже другая история. В общем, этот .vswp файл по размеру соответствует размеру памяти VM (сконфигурированной памяти), что логично. Но при достаточном количестве ресурсов он не активен, т.е. запись в этот файл не ведется, как нет и чтения из него.
Так вот, если у гипервизоров массово не хватает памяти для VM, и .vswp файлы активно пишутся и читаются, то вас вряд ли спасёт даже современный all-flash массив.
Ну вот это вот на пальцах так, кратко.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
На чём стоит экономить в облаке