What is vSphere Replication? | Disaster Recovery in VM | VMware

Прошел уже почти год с момента как я опубликовал последнюю запись на тему документа по Best Practices в VMware 7.0. Изначально я не планировал разбирать его дальше раздела, посвященного виртуальным машинам, однако результаты посещаемости сайта говорят о том, что данный цикл интересен читателю и было бы неплохо его закончить.

В течение следующих частей мы посмотрим на рекомендации VMware по управлению виртуальной инфраструктурой. Сегодня на очереди vCenter Server, vMotion, DRS, DPM.

Еще раз напоминаю, что это вольное изложение и часть информации из документа будет опущена, а что-то может быть сформулировано не совсем корректно. Не забудьте ознакомиться с оригинальным документом.

Для тех, кто здесь впервые, рекомендую предварительно ознакомиться с другими частями:

Часть 1 – Hardware for Use with VMware vSphere;

Часть 2 – ESXi General Considerations и CPU;

Часть 3 – ESXi General Considerations и оперативная память;

Часть 4 – ESXi Storage Considerations;

Часть 5 – ESXi Networ Considerations;

Часть 6 – Guest Operating Systems.

General Resource Management

Гипервизор ESXi предоставляет пользователю несколько механизмов для конфигурации и распределения ресурсов между виртуальными машинами. При этом ручное распределение вычислительных ресурсов может оказать значительное влияние на производительность виртуальных машин. Отсюда следует ряд рекомендаций:

1. Следует использовать Reservation, Shares и Limits только в случае необходимости;
2. Если ожидаются частые изменения в инфраструктуре, которые могут влиять на общее количество доступных ресурсов, стоит использовать Shares, а не Reservation для честного распределения ресурсов между виртуальными машинами;
3. При использовании Reservation, рекомендуется указывать минимально необходимое количество CPU или RAM, а не резервировать все ресурсы для виртуальной машины. После того, как резерв будет удовлетворен, оставшиеся ресурсы будут распределены на основании показателя Shares. Не стоит выставлять большие значения Reservations, это может помещать запуску других виртуальных машин, которым не остается свободных ресурсов в пуле;
4. При использовании резервов, всегда необходимо оставлять свободные ресурсы для работы гипервизора и прочих служб, например, DRS и миграции;
5. Чтобы полностью изолировать пул ресурсов, необходимо использовать тип Fixed, а также включить для него Reservation и Limit;
6. Если сервис состоит из нескольких виртуальных машин (multi-tier service), стоит группировать данные виртуальные машины в рамках одного пула ресурсов для управления потребностями на уровне сервиса целиком.

VMware vCenter

1. vCenter Server должен получать достаточное количество вычислительных и дисковых ресурсов для функционирования;
2. Количество потребляемых ресурсов и производительность напрямую зависит от размера инфраструктуры (количество хостов, виртуальных машин и т.п.), а также от количества подключенных клиентов. Превышение допустимых максимумов однозначно скажется на производительности в худшую сторону, и к тому же не поддерживается;
3. Для получения минимальных задержек при работе vCenter с базой данных, следует минимизировать количество сетевых узлов между ними;
4. Сетевые задержки между vCenter Server и хостами ESXi могут влиять на производительность операций, в которые вовлечены данные хосты.

VMware vCenter Database Considerations

Работа vCenter напрямую зависит от работоспособности и производительности базы данных, в которой он хранит конфигурационную информацию о всем окружении, статистику, задачи, события и т.д.

VMware vCenter Database Network and Storage Considerations

1. Если vCenter Appliance использует thin или lazy-zeroed диски, процесс загрузки может быть дольше, чем в случае использования дисков в формате eager-zeroed;
2. В крупных инсталляциях могут генерироваться большие объемы данных и хорошей практикой будет наблюдение за утилизацией дискового пространства. Как настроить оповещения сказано в соответствующей KB.

VMware vCenter Database Configuration and Maintenance

1. Следует использовать statistic level в соответствии с текущими требованиями. Данное значение может варьироваться от 1 до 4, но 1 достаточно в большинстве случаев. Более высокие значения могут замедлить работу vCenter, а также увеличится потребление дискового пространства. В случае, если необходим более высокий уровень статистики, например, при отладке, по окончанию данного процесса его следует снизить;
2. При запуске vCenter формирует пул из 50 потоков для подключения к БД. Размер данного пула меняется динамически в зависимости от работы vCenter и не требует модификации. Однако, при необходимости, размер данного пула может быть изменен до 128 потоков, при этом следует учитывать, что это увеличит потребление ОЗУ и может снизить скорость загрузки VC;
3. При необходимости подключения к БД VCSA следует воспользоваться материалом из данной KB;
4. В случае, если наблюдается медленное выполнение запросов, производительность может быть увеличена с помощью выполнения процедуры Vacuum and Analyze на базе данных VCDB.

PostgreSQL (vPostgres) Database Recommendations

В качестве базы данных vCenter использует PostgreSQL (vPosgress). Несмотря на то, что на этапе инсталляции, оптимизация работы базы данных выполняется автоматически, есть некоторые моменты на которые стоит обратить внимание:

1. vCenter Server Appliance создает несколько виртуальных дисков в момент инсталляции. Для улучшения производительности в больших окружениях следует убедиться, что виртуальные диски с партициями /storage/db, /storage/dblog и /storage/seat располагаются на разных физических дисках;
2. На виртуальном диске /storage/dblog хранятся транзакционные логи базы данных. vCenter особенно чувствителен к производительности данной партиции, в связи с чем виртуальный диск с данным разделом рекомендуется располагать на высокопроизводительном хранилище с наименьшим временем отклика;
3. Несмотря на то, что у PostgreSQL имеется свой собственный кэш, данные так же кэшируются на уровне операционной системы. Таким образом, производительность может быть улучшена за счет увеличения кэша ОС. Сделать это можно увеличив объем ОЗУ, выделенный виртуальной машине с vCenter Server, после чего, часть выделенной оперативной памяти будет задействована под кэш;
4. При достижении размера партиции /storage/dblog примерно до 90%, происходит сброс транзакционных логов. Чем быстрее заполняется этот раздел – тем чаще происходит операция сброса, увеличивая при этом количество дисковых операций. Увеличение размеров данной партиции снижает частоту сброса логов и уменьшает общий ввод-вывод. Это может помочь в больших инфраструктурах, однако, здесь есть и минусы – в случае необходимости восстановления после сбоя, данная процедура может занять большее время;
5. Для мониторинга дискового пространства можно использовать параметры vpxd.vdb.space.errorPercent и vpxd.vdb.space.warningPercent в расширенных настройках vCenter Server;
6. Так же для мониторинга можно использовать плагин pgtop для vCenter Server Appliance.

VMware vMotion and Storage vMotion

VMware vMotion Recommendations

1. Виртуальные машины, создаваемые в vSphere 7.0, имеют версию vHardware 17 (а в более свежих апдейтах – 18). Поскольку виртуальные машины с vHardware версии 17 могут запускаться только на хостах ESXi 7.0 и выше, vMotion для данных VM будет функционировать только в рамках хостов, поддерживающих данную версию;
2. Начиная с версии 6.5 vSphere поддерживает шифрование при выполнении операций миграции vMotion. Шифрование выполняется как на источнике, так и на приемнике, поэтому в случае миграции виртуальной машины на хост, версия которого ниже, чем 6.5, шифрования траффика при операциях vMotion производиться не будет;
3. Производительность vMotion со включенным шифрованием будет значительно выше, в случае если хост поддерживает инструкции AES_NI (Intel’s Advanced Encryption Standard New Instruction Set). Без поддержки данных инструкций, производительность vMotion может быть неприемлемой;
4. Зашифрованные виртуальные машины всегда используют Encrypted vMotion при миграции. Для нешифрованных виртуальных машин, шифрование может быть отключено (Disabled), обязательно (Required) и «по возможности» (Opportunistic);
5. Производительность vMotion напрямую зависит от скорости сети, поэтому рекомендуется иметь сетевое подключение 10GB/s и выше для сети, которая задействована под миграцию;
6. Все vmknic для vMotion следует располагать на одном и том же виртуальном свитче, при этом каждая из подгрупп, к которым они подключены, должна использовать разные физические интерфейсы в качестве активного аплинка;
7. В случае использования сети 40GB/s, рекомендуется сконфигурировать минимум 3 vMotion vmknics. Использование нескольких vmknic позволяет создавать множество потоков vMotion, утилизируя при этом большее количество процессорных ядер и увеличивая общую производительность;
8. При выполнении операций vMotion, ESXi старается зарезервировать процессорные ресурсы на источнике и приемнике, с целью максимальной утилизации пропускной способности сети. Количество резервируемого CPU зависит от количества vMotion NICs и их скорости, и составляет 10% производительности процессорного ядра за каждый 1Gb/s сетевого интерфейса, или же 100% процессорного ядра за каждый 10GB/s сетевой интерфейс, c минимальным резервом в 30%. Из этого вытекает то, что всегда следует держать незарезервированные процессорные ресурсы, чтобы процессы vMotion могли полностью утилизировать доступный сетевой канал и выполнять миграции быстрее;
9. Производительность vMotion может быть снижена, если swap уровня хоста размещен на локальных дисках (SSD или HDD).

VMware Storage vMotion Recommendations

1. Производительность Storage vMotion напрямую зависит от инфраструктуры хранения данных, от скорости подключения ESXi к хранилищам, от скорости работы хранилища-источника и хранилища-приемника. В момент операции миграции происходит чтение данных виртуальной машины из источника и запись в приемник, при этом виртуальная машина продолжает функционировать;
2. Storage vMotion будет иметь максимальную производительность в моменты низкой активности в сети хранения и если перемещаемые виртуальные машины при этом не создают большого дискового ввода-вывода;
3. Одна операция миграции позволяет перемещать до 4-х дисков виртуальной машины одновременно, но при этом на один Datastore будет копироваться не более одного диска одновременно.  Например, перемещение 4-х дисков VMDK с хранилища A в хранилище B будет выполняться последовательно диск за диском, в то время, как перемещение четырех дисков VMDK с хранилищ A, B, C, D в хранилища E, F, G, H будут идти параллельно;
4. Как вариант, можно использовать anti-affinity правила для дисков виртуальных машин, тем самым выполнять операции svMotion на разные Datastore параллельно;
5. При выполнении операции Storage vMotion на более быстрое хранилище, эффект будет заметен только по окончанию процедуры миграции. В то же время эффект от перемещения на более медленное хранилище будет проявляться постепенно с операцией копирования;
6. Storage vMotion работает значительно лучше на массивах, поддерживающих VAAI.

VMware Cross-Host Storage vMotion Recommendations

Cross-host Storage vMotion позволяет перемещать виртуальные машины одновременно между хостами и хранилищами.

1. Cross-host Storage vMotion оптимизирован для работы с блоками размером 1MB, который уже достаточно давно является размером блока, выбираемым по умолчанию для VMFS. Однако, при создании хранилищ VM на VMFS3 размер блока мог быть выбран другой и при апгрейде хранилища до VMFS5 он не изменялся. В таком случае, самым верным вариантом будет пересоздать хранилище;
2. При использовании 40GB/s интерфейсов, применяются те же правила, что и для обычного vMotion, и рекомендуется использовать 3 vMotion vmknics;
3. Аналогичным образом одновременно копируется 4 диска и применяются те же правила, что и при Storage vMotion;
4. В большинстве своем, Cross-host Storage vMotion для миграции виртуальных дисков использует сеть vMotion. Однако, если оба хоста, между которыми выполняется миграция, подключены к одному и тому же массиву, поддерживающему VAAI, и хост-источник имеет доступы к Datastore, на который будет мигрирована виртуальная машина, в таком случае будет задействован VAAI функционал массива. Если же VAAI не поддерживается, будет задействована сеть хранения данных для копирования дисков, а не сеть vMotion;

При миграции выключенных виртуальных машин, Cross-host Storage vMotion будет использовать технологию Network File Copy (NFC). Однако, как и в случае со включенными виртуальными машинами, NFC будет задействовать VAAI, если это возможно, или же сеть хранения данных (нужно помнить, что это будет возможно только в случае, если хост-источник имеет доступ к хранилищу, куда перемещается машина).

Примечание: до vSphere 6.0 NFC использовал только management сеть. Начиная с vSphere 6.0, NFC траффик все так же использует сеть управления по умолчанию, однако, теперь для нужд NFC можно выделить отдельный интерфейс (vmknic Storage Replication).

VMware Distributed Resource Scheduler (DRS)

DRS in General

1. Следует следить за рекомендациями DRS, особенно в случае использования ручных ограничений и правил. В некоторых случаях невыполнение текущих рекомендаций может помешать генерации новых;
2. В случае использования affinity rules, следует наблюдать за DRS Faults и ошибками в работе DRS, которые могут возникать из-за препятствия существующих правил балансировке. Устранение текущих ошибок может значительно помочь с балансировкой существующей нагрузки;
3. Начиная с vSphere 7.0 привычная метрика cluster-level balance была заменена на новую – Cluster DRS Score, которая является индикатором состояния кластера и виртуальных машин в данном кластере.

DRS Cluster Configuration Setting

1. При формировании DRS кластера, следует использовать гомогенные хосты со схожими параметрами CPU и объемами оперативной памяти. Это позволяет более точно предсказывать производительность и стабильность кластера;
2. В случае использования гетерогенных хостов в кластере, DRS в большинстве случаев предпочитает размещать виртуальные машины на хостах с большим объемом оперативной памяти и более высокими процессорными частотами;
3. vMotion не поддерживается между хостами с несовместимыми процессорами и это может помешать функционированию DRS. Для того чтобы быть уверенным в совместимости CPU, следует использовать одно и тоже семейство процессоров с одинаковым набором инструкций. В случае, если это невозможно, следует задействовать Enhanced vMotion Compatibility или же EVC;
4. Препятствовать выполнению операций vMotion может так же низкая пропускная способность сети (<1Gb/s), несовместимость версий vHardware виртуальной машины и хостов в кластере, неверная конфигурация сетей на ESXi и т.п.;
5. Следует убедиться, что все хосты в кластере DRS имеют доступ к одинаковому набору хранилищ. В противном случае выбор DRS для осуществления миграций может быть ограничен;
6. Начиная с vSphere 7.0 DRS учитывает всю выделенную оперативную память (granted), когда рассчитывает потребности виртуальной машины в ОЗУ. Таким образом, необоснованно большие машины могут создать дополнительные препятствия при балансировке, из чего следует очередная рекомендация в выделении виртуальной машине ровно того количества ресурсов, которое ей требуется;
7. Все виртуальные машины во время простоя потребляют не только оперативную память, но и небольшое количество процессорных ресурсов. Такие виртуальные машины могут влиять на решения, которые принимает DRS. Небольшой выигрыш в производительности можно получить за счет отключения неиспользуемых машин;
8. Для обеспечения максимальной гибкости DRS, следует размещать виртуальные машины на общих хранилищах, доступных всем хостам в кластере, а также следует убедиться, что данные VM не используют ресурсы хоста, которые будут препятствовать миграции;
9. DRS Lens и DRS Dump Insight – две неофициальные утилиты, которые позволяют более детально взглянуть на работу DRS в кластере, особенно в моменты траблшутинга.

DRS affinity rules позволяют обеспечивать нахождение группы виртуальных машин в рамках одного хоста (VM/VM affinity), в то время как anti-affinity rules, препятствуют этому (VM/VM anti-affinity). Правила DRS так же позволяют явно указать хосты, на которых будут запускаться виртуальные машины (VM/Host affinity), или наоборот не будут (VM/Host anti-affinity).

В большинстве случаев, отказ от использования affinity rules позволит получить наилучший эффект от работы DRS, однако в некоторых случаях, данные правила могут улучшить производительность и обеспечить высокую доступность для сервисов.

Доступны следующие правила:

1. Keep Virtual Machines Together – позволяет достичь повышения производительности за счет уменьшения задержек при взаимодействии между виртуальными машинами в группе;
2. Separate Virtual Machines – Использование данного правила для группы VM, предоставляющих один и тот же сервис, позволит повысить доступность сервиса, за счет исключения ситуации, при которой все виртуальные машины, обеспечивающие один и тот же сервис оказались на одном хосте, с которым возникли неполадки;
3. Virtual Machines to Hosts – Включает в себя правила Must run on, Should run on, Must not run on и Should not run on, которые могут применяться, например, в случае с лицензированием, поскольку ограничивают круг хостов, на которых могут запускаться VM.

DRS Cluster Sizing and Resource Settings

1. Превышение допустимых максимумов по количеству хостов, виртуальных машин, пулов ресурсов не поддерживается. Несмотря на то, что система с превышенными максимумами может оставаться работоспособной, это может повлиять на производительность vCenter Server и DRS;
2. С осторожностью следует подходить к установке reservations, shares и limits. Слишком большой резерв может оставить мало незарезервированных ресурсов в кластере, что повлияет на DRS. В то же время слишком низкие лимиты могут препятствовать виртуальной машине в использовании свободных ресурсов, что скажется на ее производительности;
3. DRS учитывает NetIOC (NIOC) при расчетах рекомендаций;
4. Как уже упоминалось выше, для операций vMotion следует оставлять свободные ресурсы CPU на хостах.

DRS Performance Tuning

Начиная с vSphere 7.0 реакция механизма DRS зависит от типа нагрузок и настраивается соответственно нагрузкам в кластере. Всего таких уровней 5:

Level 1 – Только необходимая миграция, например, при вводе хоста в режим Maintenance. На текущем уровне DRS не предлагает миграцию с целью улучшения производительности;

Level 2 – Используется для стабильных рабочих нагрузок. DRS рекомендует миграцию виртуальных машин, только в моменты нехватки ресурсов;

Level 3 – Уровень по умолчанию. Подходит для большинства стабильных нагрузок;

Level 4 – Для систем, которым свойственны всплески при потреблении ресурсов и требуется реакция DRS;

Level 5 – Данный уровень следует использовать для динамичных нагрузок, потребление ресурсов которых постоянно изменяется.

В vSphere имеется ряд функций, которые могут упростить управление кластером:

1. VM Distribution – DRS старается равномерно распределять виртуальные машины в кластере, тем самым косвенно повышая доступность систем;
2. Начиная с vSphere 7.0 в дополнении к процессорным ресурсам и оперативной памяти, DRS учитывает так же и пропускную способность сети, когда формирует рекомендации по перемещению VM.

Обще вышеуказанных опции доступны в разделе Additional Options настроек DRS.

Как уже упоминалось ранее, с vSphere 7.0 DRS оперирует метрикой Cluster DRS Score, которая отображает общее состояние виртуальных машин в кластере. Чем выше это значение – тем лучше. Значения выше 80% – очень хорошо, значения ниже 20% – очень плохо.

Для получения высоких показателей DRS Score, возможно, следует ослабить действующие в кластере правила, изменить уровень реагирования DRS, либо снизить потребление ресурсов в кластере.

Есть несколько причин, по которым DRS Score может быть занижен:

1. Миграции препятствуют affinity и anti-affinity правила;
2. Миграции препятствуют несовместимые хосты в кластере;
3. Затраты ресурсов на миграцию могут быть выше, чем ожидаемые преимущества после ее выполнения;
4. На всех хостах в кластере повышенная загрузка сетевых интерфейсов;
5. В кластере нет свободных ресурсов, чтобы удовлетворить потребности виртуальных машин.

VMware Distributed Power Management (DPM)

VMware Distributed Power Management позволяет экономить электроэнергию, в моменты, когда хосты в кластере не утилизированы и не находятся под нагрузкой. Данный функционал позволяет консолидировать виртуальные машины на группе хостов, после чего переводит высвободившиеся гипервизоры в Standby режим. DPM поддерживает достаточную вычислительную емкость в кластере, чтобы удовлетворить нужды всех виртуальных машин. В моменты, когда потребность в ресурсах увеличивается, DPM включает дополнительные хосты и переносит на них виртуальные машины, приводя кластер к сбалансированному состоянию.

Начиная с vSphere 7.0, DPM учитывает всю выделенную оперативную память для виртуальных машин и поскольку эти значения достаточно стабильны, в большинстве случаев работа DPM зависит от процессорной утилизации.

DPM использует DRS, а значит большинство практик, применяемых к DRS, применяются и к DPM.

DPM Configuration and Modes of Operation

1. DPM дополняет Host Power Management (о котором говорилось в предыдущих статьях) и позволяет экономить электроэнергию, переводя гипервизоры в Standby режим. Power Management в свою очередь позволяет экономить, когда хост остается включенным. Сочетание двух данных возможностей позволяет получить значительные показатели экономии электроэнергии;
2. Хосты в кластере с DPM получают настройки автоматически, на основании тех, что заданы на уровне кластера. Однако, для каждого хоста можно выставить индивидуальные значения. В случае, если DPM выставлен в ручном (manual) режиме, vCenter будет запрашивать подтверждение пользователя по переводу, либо выводу хоста из Standby режима.
3. Наилучшие результаты при использовании DPM можно получить, используя его в автоматическом режиме. В случае, если в кластере имеются хосты, на которых выставлен автоматический и ручной режим, DPM будет переводить в режим Standby предпочтительно первую группу хостов;
4. DPM может быть отключен для определенных хостов, даже если он включен на уровне кластера. Это может потребоваться, например, для хостов на которых работают критически важные виртуальные машины. В этом же случае можно использовать VM/Host affinity rules.

Tuning the DPM Algorithm

1. DPM принимает решения на основании исторических данных о том, как много ресурсов необходимо иметь доступными в кластере и при этом держит некоторый запас на случай, если нагрузка возрастет. Так же DPM будет включать дополнительные хосты в случае возросшей нагрузки, либо, если она будет требоваться под запуск новых виртуальных машин;
2. Параметр DPM Threshold позволяет настраивать «агрессивность» работы DPM;
3. В кластерах, которым свойственен непредсказуемый рост нагрузки, можно использовать параметры MinPoweredOnCpuCapacity, MinPoweredOnMemCapacity, которые отвечают за минимальное количество ресурсов, которые должны быть доступны (по умолчанию это 1MB и 1MHz);

Scheduling DPM and Running DPM Proactively

1. В vSphere 7.0 появился новый параметр DPMPowerOffInterval, который отвечает за минимальное время, через которое DPM производит расчеты и определяет, нужно ли переводить хосты в Standby режим. Минимально – 30 минут, максимально – 12 часов;
2. DPM может быть активирован и деактивирован по расписанию, используя планировщик vCenter (Scheduled Tasks). При деактивации DPM, все хосты, которые находились в Standby режиме, будут включены.  Это может быть полезно в случаях, когда периоды повышения нагрузки известны заранее и инфраструктура должна быть к этому готова. Интересное примечание: в случае, если vCenter, либо служба vpxd будут перезапущены, все Standby хосты будут включены;
3. В случае использования Predictive DRS, DPM может использовать полученную статистику и заранее выводить хосты из режима Standby. Например, если известно, что нагрузка возрастает в 9 утра, DPM предварительно подготовит хосты в 8:00.

Using DPM With VMware High Availability (HA)

1. DPM учитывает настройки High Availability и не нарушает их при отключении хостов. В кластере с активированным HA, DPM всегда оставит нужное число хостов включенными для того, чтобы их количество соответствовало требованиям высокой доступности;
2. Если в кластере включен функционал VMware HA и хотя бы одна виртуальная машина, DPM будет держать включенными минимум два гипервизора. Это утверждение остается верным, даже если в настройках кластера деактивирован admission control.