В продолжение темы об оптимизации хоста с VMware ESXi, рассмотрим как поступать со Swap'ом в инфраструктуре живущей на СХД NetApp FAS. Хотя эта статья должна быть полезна и не только владельцам систем NetApp FAS.
Одна из важнейших возможностей виртуализации заключается в возможности более эффективно утилизировать серверное оборудование, что подразумевает Overcommit ресурсов. Если мы говорим об ОЗУ, это означает, что мы можем настроить каждой виртуальной машине больше памяти, чем есть на сервере на самом деле. А дальше мы полагаемся на ESXi, чтобы тот разрулил борьбу за ресурсы — забрал (такой процесс часто называют reclamation) не нужную память одной виртуальной машины и отдал той, которая в ней действительно нуждается. В тот момент когда не хватает памяти, начинается процесс свапинга памяти.
Начнём с того, что есть два типа свапинга которые могут происходить на ESXi хосте. Их очень часто путают, по-этому давайте условно будем называть их Тип 1 и Тип 2.
Расположение данных VMware ESXi по-умолчанию
Тип 1. VMX swapping (vSwap)
Это самый простой тип свапинга для описания. Память выделяется не только для виртуальных машин, а также и для различных компонент хоста, к примеру для монитора виртуальных машин (VMM) и виртуальных устройств. Такая память может быть свапирована для того, чтобы выделить более нуждающимся виртуальным машинам больше физической памяти. По словам VMware эта возможность может высвободить от 50MB до 10MB памяти, для каждой виртуальной машины без существенного ухудшения производительности.
Этот тип свапианга включён по-умолчанию, VMX Swap храняться в папке с виртуальной машиной в виде файла с расширением vswp (расположение может быть изменено через параметр sched.swap.vmxSwapDir). VMX swapping может быть выключен при помощи установки параметра виртуальной машины sched.swap.vmxSwapEnabled = FALSE.
Тип 2. Guest OS Swapping
Виртуальная машина «видит» столько якобы «физической» памяти, сколько ОЗУ задано в ёё настройках. С точки зрения гоствеой ОС, вся такая выделенная память для неё физическая. На самом деле гипервизор скрывает за слоем виртуализации для гостевой ОС, какая же память используется на самом деле: физическая или vSwap. Когда память «внутри» гостевой ОС заканчивается, она сама начинает свапить. И вот здесь нужно не запутаться — этот процесс не имеет ничего общего со свапингом на уровне хоста (VMX). К примеру для виртуальной машины с настроенными 4GB памяти, гипервизор может выдилить эту память на хосте, как в физической памяти, так и в свапе хоста (VMX) – для виртуальной машины это не важно, все 4GB будут использованы как физическая память просто потому, что гостевая ОС не имеет понятия, что её память виртуализирована.
Когда гостевая ОС хочет использовать больше чем 4GB памяти, она будет использовать собственный свапинг, Windows использует pagefile.sys, в Linux это выделенный Swap раздел. Таким образом свап сохраняется внутри виртуального диска — внутри одного из VMDK файлов виртуальной машины. Т.е. Pagefile.sys/Swap раздел это часть виртуального диска виртуальной машины.
И вот что происходит, когда используется драйвер балунинга: когда он «раздувается», он забивает всю свободную (с точки зрения гостевой ОС) память, при этом драйвер балунинга удостоверяется что он получает на самом деле физическую, не свапированную память хоста, а когда у такой виртуальной машины нет свободной памяти, это затсавляет гостевую ОС начать свапить данные. И это хорошо, так как гостевая ОС лучше знает что свапить на диск, а что нет.
ESXi Host swapping
Когда мы понимаем, что ESXi хост очень много свапит, это говорит о том, что у нас очень большое перерасходывание ресурсов, все reclamation и техники по экономии памяти (ballooning, page sharing и сжатие memory) не спасают — хосту по-просту не хватает ОЗУ. Считается, что хост находится в состоянии «Hard state» (1%-2% памяти свободно) или «Low state» (1% и меньше). Такое положение дел существенно ухудшает производительность, его нужно избегать. Другая проблема, когда Swapping на уровне хоста не имеет контроля над тем, что туда попадает – в отличае от свапинга гостевой ОС (Тип 2), гипервизор не знает, какие данные более важные для гостевой ОС, по-этому важно устанавливать VMware Tools, чтобы работал драйвер балунинга.
vSwap (Тип 1) по-умолчанию сохраняется в .vswp файл в папке с виртуальной машиной. NetApp рекомендует сохранять vSwap (Тип 1) на выделенный датастор.
/vmfs/volumes/4b953b81-76b37f94-efef-0010185f132e/vp # ls -lah |grep swp
--rw------ 1 root root 2.0G Jan 11 18:02 vp-c6783a5c.vswp
Такой файл существует только для запущенных виртуальных машин – при запуске гипервизор создаёт этот файл и удаляет при выключении виртуальной машины. Обратите внимение на размер этого файла — он равен разнице между сконфигурированной памятью для виртуальной машины и резервом физической памяти за этой машиной. Таким образом обеспечивается наличие заданного пространства памяти, когда виртуальная машина стартует (не зависимо от того, какая память используется — настоящая физическая или vSwap). Резерв заботится о том, чтобы виртуальная машина получила нужное простанство всегда в физической памяти хоста. а разница между резервом и настроенной памятью виртуальной машины сохраняется в vswp файл.
Ниже пример запуска виртуальной машины с 4GB памяти и резервом 2GB. Помните, что vSwap удаляется после выключения? А если в этот момент датастор хранящий эту виртуальную машину заполнится и останется свободного 1.8GB пространства, что произойдёт?
Что можно с этим сделать? Конечно же можно высвободить пространство на датасторе или расположить vSwap (Тип 1) на другом датасторе. По-умолчанию он храниться в папке с виртуальной пашиной. Если это «standalone» хост: Configuration > Software > Virtual Machine Swapfile Location. Расположение vSwap файлов также можно изменить на уровне настроек каждой виртуальной машины. Откройте настройки виртуальной машины и выберите вкладку Options:
Если этот хост часть кластера, загляните в настройки кластера Store the swapfile in the datastore specified by the host
Далее выбирите датастор где будет храниться vSwap (Тип 1).
Зачем располагать свап на отдельный датастор?
Рекомендуемая схема расположения Swap'а для NetApp FAS
Во-первых стоит отметить что общее правило VMware гласит по возможности располагать vSwap (Тип 1) в папке с виртуальной машиной, так как вынесение на отдельный датастор может замедлить vMotion. Но в частном случае VMware + NetApp FAS вступает другая рекомендация. NetApp рекомендует хранить vSwap (Тип 1) на отдельном выделенном, одном для всех виртуальных машин датасторе, так как в этом случае разница при миграции vMotion практически нивилирована. VMware рекомендует, чтобы пространсто под vSwap (Тип 1) было больше или равно разнице сконфигурированной и зарезервированной для виртуальной машины памяти. Иначе виртуальные машины могут не стартовать. Пример: у нас есть 5-ть виртуальных машин с размером памяти 4GB и резервацией для каждой 3GB.
Минимальный размер датастора для vSwap Тип 1:
5VM * (4 GB — 3GB )= 5GB
Если на хосте нет свободных физических 5VM * 3GB = 15 GB памяти, машины могут не стартовать, выводя ошибку:
The host does not have sufficient memory resources to satisfy the reservation
И в то же время будет создан Event log
Во-вторых это перфоменс – расположив свап на более медленном датасторе, если вы уверены, что свапинга почти никогда не будет. Или если виртуальные машины будут запрашивать больше памяти, чем есть на хосте, и свапинг будет постоянным – на более быстром датасторе.
В-третьих это снепшоты и дедубликация на уровне хранилища. Так как у нетапа снепшоты не влияют на производительность, они являются нормой жизни, выполняются постоянно и являются частью парадигмы резервного копирования NetApp для систем FAS. Свап это абсолютно бесполезная информация при резервном копировании и восстановлении. Если он интенсивно используется, а снепшоты часто снимаются, в снепшотах будет «захвачена» и храниться, все время жизни снепшота, эта бесполезная информация. А так как свап постоянно меняется, а спепшот захватывает только новые изменённые данные, в каждом таком снепшоте будет храниться эти новые изменённые данные из свапа, беспощадно поедая полезное пространство под бесполезные данные на хранилище. Дедублицировать свап нет никакого резона, ведь данные в свапе не нужны при восстановлении и никогда не будут считаны. В этом смысле удобно выносить свапы на отдельный датастор. NetApp рекомендует распологать свап на отдельный датастор с выключенными снепшотами и дедубликацией, так мы можем ещё сильнее уменьшить оверхед в снепшотах и на репликации.
NetApp не рекомендует использовать локальные диски (стр 76-78, DEC11) на хосте, для хранения vSwap (Тип 1) потому, что такая конфигурация имеет негативное влияние на скорость выполнения операции vMotion.
Стоит ли выносить Тип 2 Swap?
Размещение временных данных, таких как Swap и Pagefile.sys на выделенный датастор (создав выделенный виртуальный диск для этой цели) позволяет не дедублицировать и не бекапировать эти данные также как и vSwap (Тип 1). Очень важно не забыть указать этот диск как Independent, чтобы агент VSC не заставлял FAS снимать снепшоты с раздела хранящего Swap файлы (Тип 2).
У NetApp нет рекомендаций относительно Swap Тип 2, вынесение этих данных является опциональным дизайном, у которого есть свои плюсы и минусы:
В дополнение к вынесенному vSwap Тип 1, вынесение Swap Тип 2 ещё сильнее уменьшит оверхед на снепшотах, и как следствие увеличит пропускную способность для репликации. В ACB для DR решений наличие Swap'а (оба типа) не нисет никакой смысловой нагрузки, ведь он не используется при старте системы. Если мы перестанем хранить Swap (Тип 2) в снепшотах и резервных копиях, при локальном восстановлении это не должно вызывать каких-либо проблем, так как восстанавливаемый .vmx config файл будет содержать ссылку на VMDK файл хранящий раздел со Swap'ом, ведь тот будет находиться на том же месте. Но это добавит дополнительные шаги при восстановлении на удалённой площадке, в таких конфигурациях как SRM, SnapProtect и друхих DR решений.
Так при восстановлении виртуальной машины без VMDK файла хранящего свап гостевой ОС, нужно дополнить шагами создания виртуального диска, файловой системы на нём и его подключения к виртуальной машине (или подключения существующего VMDK с созданной файловой системой). Подробнее TR-3671.
Сообщения по ошибкам в тексте прошу направлять в ЛС.
Замечания и дополнения напротив прошу в комментарии
Автор: bbk
