Мы размещаем Exchange Server в виртуальной среде, если хотим гибко масштабироваться и более эффективно использовать ресурсы. Но если виртуализировать без оглядки на лучшие практики, можно срезаться на обидных мелочах.
Я решил собрать в одном месте опыт работы с Exchange Server в виртуальной среде и показать, как обращаться с реальными и виртуальными процессорами и памятью, а также дисками и сетью. Я не дам конкретных пошаговых рецептов, что невозможно с учетом всего многообразия инфраструктур. Но покажу несколько правил, которые выведены опытным путем и не противоречат рекомендациям вендоров.
Это статья по итогам моего выступления на Raiffeisen DGTL Communications Online Meetup 21 января.
Оговорки и ограничения
Любое решение в виртуальной среде зависит от конкретных параметров физической инфраструктуры. Как бы мы ни хотели “виртуализовываться” дальше, мы неразрывно связаны с особенностями конкретных физических серверов.
Поэтому в начале оговорюсь про ограничения для Exchange Server 2019. На один сервер берем 256 Гб памяти и CPU не более двух сокетов. Эти требования растут из требований к физическим серверам. Напомню, что установка Exchange Server на железо (Bare-Metal) — предпочитаемая архитектура Exchange Server с точки зрения Microsoft. Если у нас четырехсокетная физическая система, то виртуальная машина не должна выходить за пределы двух сокетов по vCPU. Эти параметры установлены опытным путем большими исследовательскими командами вендоров, так что примем за аксиому.
Сначала была NUMA: правила для vCPU
В первом разделе сформулируем правила работы с ресурсами процессора. Для этого нам нужно сначала обратиться к физической топологии неравномерного доступа к памяти, или NUMA.
Топология NUMA дает процессору доступ и к своей локальной памяти, и к памяти других процессоров. Изначально в распоряжении каждого процессора есть:
собственный банк памяти, который находится в непосредственной близости к CPU;
несколько уровней кэша.
Все эти ресурсы памяти вместе с процессором и называют NUMA Node. Для простоты сделаем допущение, что количество физических сокетов в нашей системе равно количеству NUMA-нод. На практике это не так, так как существует Sub-NUMA Clustering. Но в рамках данной статьи мы не будем заострять на этом внимание.
Доступ к памяти других процессоров в рамках NUMA мы обозначаем как Memory Access. Когда при сайзинге виртуальной машины мы выходим за пределы ресурсов одной NUMA-ноды, ВМ размазывается по двум нодам, их память тоже размазывается.
Подводные камни на примере сайзинга ВМ в рамках NUMA Node. Допустим, у нас есть двухпроцессорный сервер, где стоят два процессора с 20 физическими ядрами и 256 Гб памяти, по 128 Гб на каждый процессор. У нас есть виртуальная машина с 20 процессорами и 128 Гб памяти. Любой планировщик любого гипервизора по умолчанию будет стараться разместить ее в рамках одной NUMA-ноды.
Если мы докинем ресурсы процессора до 24, то машина переедет на две физические NUMA-ноды. В этой ситуации мы можем накидывать виртуальной машине до 30 виртуальных процессоров. Но если мы назначим ей нечетное количество процессоров при расположении на двух нодах, планировщик сойдет с ума, пытаясь разделить нечетное число на 2. В результате мы просядем по производительности.
Именно поэтому лучшие практики рекомендуют при сайзинге машины обращаться к таблице распределения по ядрам и NUMA-нодам. Вот пример для такой конфигурации: 4 сокета, 4 физических NUMA-ноды, 24 ядра на сокет, 96 логических потоков.
Все становится еще интереснее, когда появляется vNUMA в ESXi. Подробнее про ее причуды мы уже писали тут.
vNUMA позволяет эмулировать физическую топологию NUMA для ВМ и принудительно располагать ВМ на NUMA-нодах. Начиная с VMware версии 6.0, vNUMA старается предоставить машине топологию в соответствии с физическими NUMA-нодами. Но все равно нужно следить, чтобы физические и виртуальные сущности совпадали. Использование vNUMA поддерживается при развертывании Exchange Server 2016/2019, но с соблюдением ограничения в 2 сокета на одну ВМ.
Нюансы многопоточности и переподписки для разных гипервизоров. Если у процессора есть SMT (Simultaneous Multithreading), то разные планировщики обращаются с ней по-разному. Планировщик VMware сначала смотрит, как расположить ВМ по физическим ядрам, и только потом смотрит на гипертрединг и распределяет все по потокам. Hyper-V же сначала старается разложить ВМ по гипертрединговым ядрам, поэтому теоретически может разместить 2 виртуальные машины в одну NUMA-ноду за счет разных потоков.
Для разных случаев пригодятся разные варианты. Так что для VMware обратим внимание на настройку приоритетов гипертрединга, а затем рассмотрим нюансы переподписки на одном хосте.
Когда важнее гипертрединг. Допустим, у нас есть восьмиядерный процессор и виртуалка VMware с восемью ядрами. В такой конфигурации она будет жить на одной NUMA-ноде. Когда мы сайзим ВМ до 16 ядер, планировщик VMware по умолчанию размещает ее на 2 нодах. Но мы можем оставить ВМ в рамках одной ноды, например, чтобы сохранить быстрый доступ к кэшу одного процессора. В этом случае включаем настройку vcpu.numa.preferHT, которая отдает приоритет потокам SMT.
При этом важно учесть, что гипертрединг не удваивает вычислительную мощность, так как SMT-потоки используют ресурсы своего физического ядра. Чтобы это увидеть, представим физическое ядро с двумя потоками. Когда мы размещаем двухпроцессорную виртуальную машину на обоих SMT-потоках этого ядра, то процессор считает все с той же мощностью, просто в 2 потока.
Это становится критичным, если мы размещаем на хостах несколько виртуальных машин. Так возникает переподписка, когда суммарное число ядер всех виртуальных машин на хосте превышает количество физических ядер.
В Hyper-V у нас есть 2 вида планировщика: Classic и Core. Нас интересует работа планировщика Core: он никогда не разместит 2 ВМ с нечетным количеством vCPU на двух соседних потоках (такая защита от Meltdown and Spectre), что увеличивает переподписку в угоду безопасности. Поэтому, в случае виртуализации Exchange Server на Hyper-V следует определиться с типом шедулера. Если требования ИБ позволяют, стоит сменить Core на Classic.
Когда может помешать переподписка. При переподписке на время одного физического ядра всегда претендуют несколько виртуальных машин. Даже если мы размазали всю нагрузку по SMT-потокам, то вычислительная мощность остается прежней и делится на всех. Если для сервиса критично время доступа к процессору, рекомендуют выделить отдельный физический кластер и таким образом контролировать переподписку.
Exchange Server часто относят к критичным приложениям, поэтому его тоже рекомендуется выделять в отдельный кластер. В этом случае мы изолируем рабочие нагрузки от других виртуальных машин и не заморачиваемся с настройкой приоритетов для гипертрединга. Если же время не так критично, то допустимым уровнем переподписки считается два к одному: два ядра виртуальной машины к одному физическому ядру на процессоре.
Итак, обобщим все рекомендации по vCPU.
При сайзинге ВМ всегда отталкиваемся от топологии NUMA конкретного физического сервера.
Количество vCPU делаем кратным числу физических ядер процессора.
Если мы выходим за пределы NUMA Node по ядрам, не допускаем нечетного количества ядер виртуального процессора.
Количество виртуальных процессоров должно быть достаточным, но не избыточным. Лучше докинуть vCPU потом, чем бороться с переподпиской.
Хорошим тоном является изоляция Exchange server в отдельный кластер ESXi или Hyper-V.
Если это невозможно, используем пул ресурсов, настраиваем приоритеты процессора для этих ВМ.
В Hyper-V принять решение о типе шедулеров на хостах.
Правила для оперативной памяти
Здесь мы тоже зависим от топологии NUMA, потому что память и процессор неразрывно связаны. Но в случае с оперативной памятью переподписка не допускается: выделенная память должна быть статична, это входит во все рекомендации VMware и Microsoft. В Hyper-V этот вопрос решен за нас: динамическая память отключена по умолчанию. А вот с VMware все не так однозначно, остановимся на этом подробнее.
Резервирование памяти для ВМ VMware. По умолчанию память VMware ESXi будет динамической. Это значит, что гипервизор в любой момент может забрать у виртуальной машины неиспользуемую память за счет балунинга. Так повышается риск вывода памяти в SWAP: когда гипервизор заберет себе освободившуюся память, слепок памяти ВМ отправится на жесткий диск, производительность упадет. Раньше мы подробно описывали это здесь.
При этом у VMware есть опция горячего добавления памяти (Memory Hot-Add), но эта настройка отключает механизм vNUMA и все равно потребует перезагрузки. Так что не советую ею пользоваться: мы все равно получим простой и рискуем снизить производительность.
Для резервирования памяти под виртуальную машину используем Reservation Pools в режиме All Memory Locked. При этом на других хостах кластера должно быть достаточное количество оперативной памяти, чтобы при перебалансировке DRS или при перезапуске ВМ по HA виртуальная машина могла переехать/перезапуститься на новом хосте. Если же мы строим выделенный кластер под Exchange, то вопрос переподписки уже не стоит так остро.
Сайзинг памяти. При сайзинге виртуальной машины имеет смысл заранее определить предельное значение оперативной памяти.
Чтобы рассчитать ожидаемый размер загрузки, смотрим такие параметры:
количество почтовых ящиков,
размеры и количество писем,
количество активных баз данных и их реплик,
частота резервного копирования и требования к ресурсам для системы резервного копирования,
количество пользовательских устройств для доступа к почте.
Этот список параметров не достаточен и сильно зависит от конфигурации Microsoft Exchange.
Как отправную точку для расчетов можно использовать Exchange Calculator, если учитывать несколько его особенностей:
исходит из максимальных лимитов на ВМ,
не учитывает топологию NUMA на физических серверах,
закладывает 10% накладных расходов на гипервизор (в реальности эти накладные расходы не превышают пять процентов),
не учитывает переподписку по CPU, количество ВМ и конфигурацию гипервизоров.
Теперь обобщим рекомендации для оперативной памяти:
Рассчитываем память, исходя из топологии NUMA.
Используем 100% резервирование памяти под ВМ.
Не допускаем переподписку.
Не используем горячее добавление памяти.
Используем выделенный кластер для 100% резервирования памяти под сервер.
Оставляем минимум 20% свободной памяти на хостах для возможности маневра при балансировке ВМ.
Если нужно увеличить ресурсы, думаем над горизонтальным расширением DAG.
Общие правила для дисков и сети
Правила хорошего тона для дисков и сети применимы не только для Exchange, но касаются виртуализации Windows-сервера вообще. Так что объединил их в один раздел.
Рекомендации для дисковой подсистемы.
В VMware ESXi поддерживаются такие диски:
VMDK на VMFS6, NFS, vSAN Datastore,
RDM — Raw Device Mapping.
Здесь же поддерживаются разные виртуальные SCSI-контроллеры:
LSI Logic SAS. До vSphere 7.0 этот контроллер ставился по умолчанию для виртуальных машин Windows. Как результат, часто можно увидеть развертывания Exchange с его использованием.
Достоинства:
прекрасно распознается Windows без инъекции драйверов;
приемлемая производительность по сравнению с AHCI SATA.
Недостатки:
производительность ниже PVSCSI за счет дополнительной прослойки при передаче SCSI-команд;
выше нагрузка на CPU по сравнению с PVSCSI;
как следствие, более высокая задержка.
AHCI SATA Controller. Контроллер SATA можно использовать отдельно или в дополнение к контроллерам LSI или PVSCSI для предоставления большого числа дисков для ВМ. На этом его достоинства заканчиваются.
Недостатки:
выше загрузка CPU на I/O по сравнению с LSI и PVSCSI;
ниже общая производительность по сравнению с LSI и PVSCSI;
выше латенси по сравнению с LSI и PVSCS.
Паравиртуальный SCSI-контроллер (PVSCSI). Контроллер PVSCSI является самым производительным контроллером по сравнению с вышеперечисленными и хорошо подходит для высокопроизводительных сред хранения.
Достоинства:
производительность за счет более прозрачной передачи SCSI-команд;
меньше задержка и больше IOPS по сравнению с другими контроллерами;
снижение нагрузки на CPU в гостевой ОС (и на ESXi).
Недостатки (если их можно так назвать):
гостевая кластеризация не поддерживается (нельзя отдать Shared VMDK), но это не относится ни к Exchange Server, ни к SQL Server в сценарии Always-On;
PVSCSI требует инъекции драйверов в Windows или ВМ, для которой мы хотим заменить LSI на PVSCSI.
для добавления требует выключения ВМ.
NVMe Controller. Впервые появился в vSphere 6.5. Начиная с vSphere 7.0, является контроллером по умолчанию для ВМ с ОС Windows, вместо морально устаревшего LSI. Этот тип виртуального контроллера оптимизирован для работы на All-Flash массивах (SSD/NVMe). Лишен всех недостатков PVSCSI и сохраняет все преимущества. Следовательно, может рассматриваться как контроллер для баз данных Exchange. На начало 2021 года поддерживает только 15 дисков на контроллер. Этот факт стоит учитывать при планировании хранилищ баз данных Exchange Server.
Для Hyper-V рекомендации по дисковой подсистеме такие:
VHDX может размещаться на NTFS, ReFS, CSV, SMB3, S2D (т.е. любое поддерживаемое хранилище).
В сценарии Storage Spaces Direct нужно следить, чтобы виртуальная машина располагалась на хосте-координаторе того тома, где она расположена по хранилищу.
Общие рекомендации к сети.
Используем синтетические адаптеры: VMXNET3 или Synthetic Network Adapter.
Включаем и настраиваем RSS со стороны гостевой операционной системы, чтобы параллельно принимать и передавать данные на ВМ по ядрам vCPU. Для VMXNET3 дополнительно включаем Recv Segment Coalescing для IPv4 и IPv6.
Если есть возможность, используем сетевые адаптеры SR-IOV. Этот способ подойдет, если у нас жесткие требования к пропускной способности сети и нужен гарантированный канал с очень большой скоростью. Но этот пункт скорее для ВМ, которые требовательны к пропускной способности адаптеров.
Делаем несколько сетевых адаптеров в Exchange-сервере, чтобы использовать механизм SMB Multi-Channel. Так мы сможем не только принимать, но и отдавать несколько потоков через протокол SMB.
И в заключение несколько полезных ссылок по теме:
Microsoft Exchange Server on VMware vSphere.
Performance Best Practices for VMware.
Exchange 2010. Block mode replication.
Exchange Server Virtualization.
