Виртуализация Exchange 2013 — правильный подход

Люди пытались виртуализировать MS Exchnage с самого первого появления гипервизоров. Сначала Microsoft препятствовала этим попыткам, не оказывая техподдержки при появлении проблем: проблема должна быть воспроизведена на «настоящем» сервере перед тем, как обращаться за техподдержкой.

Ситуация изменилась с выходом Exchange 2007. Запросы клиентов, растущая стабильность технологии виртуализации и появление собственного гипервизора Microsoft создали новый императив для поддержки виртуализации Exchange. С тех пор Microsoft постоянно улучшает возможности Exchange по использованию различных технологий виртуализации и Exchange стал приложением, которое в основном работает на Microsoft Hyper-V, Vmware Sphere и других гиревизорах, одобренных Microsoft.

У виртуализации есть свои особенные технические требования, которые системные администраторы должны учитывать при планировании её использования с приложениями. Некоторые приложения, такие как Exchange, имеют относительно строгие инструкции по поводу того, какие технологии виртуализации можно использовать, а какие — нет. Иногда это из-за того, что технология не протестирована с Exchange; иногда из-за того, что аспекты работы технологии конфликтуют с аспектами работы Exchange. Данная статья описывает самые важные проблемы, о которых системы администраторы должны знать перед развёртыванием Exchange 2013 на платформе виртуалтизации.

Учитывая высокую частоту выхода обновлений для Exchange 2013, продолжающееся развитие гипервизоров, новые возможности Windows, прочие улучшения в оборудовании и программном обеспечении, рекомендации, данные в этой статье могут стать со временем неактуальными. Данная статья актуальна на апрель 2014 года и затрагивает Exchange 2013 SP1, Windows 2013 и Windows 2012 R2, а также технологии виртуализации, доступные на этот момент.

Защитники виртуализации обычно продвигают свои доводы, основываясь на том, что виртуализация эффективнее использует имеющееся оборудование. Идея состоит в том, что один или более больших виртуальных хостов способны обеспечить необходимые ресурсы для поддержки требуемого числа серверов Exchange. Настройка виртуального хоста позволяет точно выделить конкретное количество ресурсов каждому серверу Exchange в зависимости от того является этот сервер выделенным почтовым сервером, мультиролевым сервером, сервером клиентского доступа или транспортным сервером. Озвучиваются следующие преимущества:

• Виртуальные серверы более эффективно используют имеющееся оборудование и, тем самым, снижают общую стоимость решения. Это возможно, т. к. правильно настроенный и обслуживаемый виртуальный хост способен поддерживать несколько виртуальных серверов Exchange и полное решение будет лучше использовать доступные ресурсы оборудования, чем Exchnage, развёрнутый на нескольких «настоящих» компьютерах. Это, в частности, верно для развёртываний, где Exchange обслуживает пару сотен почтовых ящиков и загрузка отнимает только часть общих ресурсов, доступных на физическом сервере. Другой пример виртуализации, добавляющей полезность, - это разворачивание нескольких виртуальных серверов Exchange (в идеале на нескольких хостах) вместо одного большого физического сервера для обслуживания тысяч почтовых ящиков. В данном случае виртуальные сервера Exchnage могут быть организованы в Группу доступности баз данных (DAG), чтобы получить преимущество от нативных функций высокой доступности, тогда как один большой физический сервер не защищён Группой доступности баз данных (DAG) и поэтому представляет собой потенциальную точку отказа.
  
  Эффективное использование ресурсов должно быть проверено в контексте проектов, созданных для данных условий. Есть вероятность выделить слишком много ресурсов для работы с определённой нагрузкой и, следовательно, виртуальные серверы не будут достаточно эффективны; также возможно выделить слишком мало ресурсов в стремлении максимизировать утилизацию ресурсов.

• Виртуальные серверы гибче и проще развёртывать. Правильно обслуживаемые виртуальные окружения настроены так, чтобы позволить новым серверам Exchnage развернуться очень быстро, на самом деле намного быстрее, чем покупка нового серверного оборудования и последующая установка Windows, Exchange и другого программного обеспечения, необходимого для производственного окружения. Эта способность позволяет решению быть намного гибче физического эквивалента — фактор, который может быть важным при миграции с одной версии Exchange на другую, или если требуется дополнительная ёмкость в таких ситуациях, как слияние корпораций.

• Виртуальные серверы проще восстановить. Если виртуальный сервер упадёт, то легче создать новый виртуальный сервер, а затем восстановить его при помощи опции Exchange Setup / RecoverServer, чем решить мириады проблем с оборудованием, которые могут возникнуть с физическим сервером.

• Виртуальные серверы Exchange позволяют небольшим организациям внедрять такие технологии, как Группы доступности баз данных (DAGs), без вложения средств в большое количество физических серверов. Это верно, т. к. возможно использовать много виртуальных серверов Exchange, организованных в Группу доступности баз данных на одной физическом сервере. Однако, как объяснено выше, концепция нежелания иметь все яйца в одной корзине имеет место также и здесь, т. к. отказ одного физического сервера, в данном случае, приведёт к неработоспособности всей Группы доступности баз данных (DAG).

Ни одно их этих преимуществ не может быть достигнуто без тщательных процессов планирования и подготовки виртуального окружения, которое будет поддерживать Exchange. Плохо настроенное и обслуживаемое виртуальное окружение будет иметь больше проблем, чем его физический аналог. Поэтому важно сделать акцент на том, что потребуется много усилий для поддерживания виртуализированного Exchange. В мире ИТ за всё хорошее надо платить.

Некоторые опытные администраторы Exchange всегда будут предпочитать работать с Exchange на физических серверах на том основании, что данные серверы предоставляют более предсказуемый уровень производительности. Эта позиция принята для серверов почтовых ящиков, но она может быть распространена также на серверы клиентского доступа (CAS) и транспортные серверы. Аргументы против виртуализации Exchange обычно включают:

• Серверы легче настраивать и поддерживать. Нельзя отрицать, что поставить Exchange на физический сервер проще, хотя бы потому, что не требуется подготавливать виртуальные машины для поддержки Exchange. Также верно, что легче поддерживать Exchange, работающий на физических компьютерах, т.к. слой гипервизора не принимается во внимание при отладке проблем, возникающих во время развёртывания или текущей работы.

• Удаление виртуализации устраняет сложность. Exchange — это достаточно сложное серверное приложение, которое зависит от Windows и ряда других компонентов (таких как PowerShell). Поддержка развёртывания Exchange настолько простая, насколько это возможно, имеет много положительных моментов в плане поддерживаемости и стоимости. Добавление слоя гипервизора увеличивает сложность всего решения и делает более трудным развёртывание и управление серверами. Факт, что Microsoft не применяет виртуализированные серверы в сервисе Exchange Online с Office 365, используется для поддержки данного утверждения.

• Виртуализация — это дорого. Стоимость лицензий гипервизоров — это явные дополнительные затраты, которые вы несёте сверх стоимости лицензий Windows и Exchange Server. Удаление гипервизора уменьшает стоимость, а также устраняет время, необходимое администраторам для настройки виртуальных хостов для поддержки Exchange. Следующие затраты относятся к ресурсам, необходимым для работы дополнительного слоя гипервизора, и работе, выполняемой для поддержания работоспособности виртуальных серверов. Этот слой обычно отнимает 10% процессорной мощности хостового компьютера. Калькулятор для расчёта требований для роли сервера помогает узнать влияние виртуализации, включая этот оверхэд в расчёт необходимого для управления конкретной нагрузкой числа серверов Exchange 2013.

Все эти проблемы могут быть преодолены различными способами. Опыт и знания платформ виртуализации облегчают работы по настройке и поддержке. Тоже самое верно и в плане сложности. Люди, не работавшие с виртуальными серверами, приложат намного больше усилий для разворачивания Exchange на этой платформе, чем те, кто знаком с виртуализацией.

Затраты часто являются одной из сложнейших проблем для решения, т.к. прямые и легкоизмеряемые затраты на лицензии программного обеспечения могут быть нивелированы эффективной загрузкой оборудования, простотой развёртывания сервера и его управления, оба из которых сложно измерить в терминах прямых сбережений. Также верно то, что Exchange 2013 потребляет больше ресурсов CPU и памяти, чем предыдущие версии, и то, что горизонтальное масштабирование предпочтительней вертикального. Когда оба эти фактора объединяются с необходимостью повышения надёжности посредством разделения компонентов таким образом, чтобы ни один отказ не мог навредить большому количеству серверов; результатом часто является распределения ряда виртуальных серверов Exchange по нескольким физическим хостам, что, в свою очередь, увеличивает общие затраты на оборудование и программное обеспечение.

Верно и то,что любое решение по виртуализации какого-либо приложения должно быть хорошо профинансировано и основано на реальных данных. Решение использовать виртуализацию без какой-либо причины редко является хорошей идеей. Решение виртуализировать Exchange только потому, что ваша компания имеет достаточно знаний по технологии виртуализации и приняла стратегическое решение виртуализировать приложения при наличии возможности, — это совсем другой подход. Убедитесь, что вы понимаете возможные риски и то преимущество, которое вы желаете получить, перед началом проекта по виртуализации.

Команда разработчиков Microsoft Exchange поддерживает виртуализированный Exchange, потому что они считают, что запуск Exchange на виртуальной платформе имеет много смысла для конкретного подмножества их базы с более чем 300 миллионами почтовых ящиков. Об этом говорилось на многих конференциях.

Техподдержка виртуализированного Exchange не означает, что Microsoft «впаривает» виртуализацию каждому клиенту. Вместо этого они говорят, что любое решение по использованию виртуализации в конечном итоге должно принести определённую прибыль клиенту. Другими словами, если Вы решаете развернуть Exchange на виртуальной платформе, убедитесь, что вы получите что-то измеряемое от этого рещения.

21 апреля 2014 года Microsoft опубливала в блоге статью, описывающую Предпочтительную Архитектуру для Exchange 2013. В ней утверждалось, что архитектура избегает виртуализацию. Вот цитата из статьи:

«В предпочтительной архитектуре все серверы являются физическими мультиролевыми серверами. Физическое оборудование предпочитается виртуализированному по двум причинам:

1. Серверы масштабируются таким образом, чтобы использование ресурсов не превышало 80% в случае наихудшего сценария отказа оборудования.

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

Сторонники виртуализации могут быть разочарованы таким утверждением, т. к. оно показывает поверхностное ознакомление с виртуальными серверами. Однако, данное утверждение должно рассматриваться в свете логичного подхода к контексту.

• Microsoft сильно подвержен собственному опыту установки Exchange 2013 в огромных масштабах в Office 365. Это развёртывание не использует виртуализацию из-за несомненной сложности, которую внесёт дополнительный слой в управление более чем 100 000 серверами.

• Поддержка проще и дешевле для Microsoft, когда клиенты следуют самым простым принципам при развёртывании любого приложения. Поддержка сложнее, когда применяются гипервизоры, т. к. это требует дополнительного опыта и знаний по этой части для персонала техподдержки.

Любая предпочтительная архитектура от вендора может быть выражена только как набор руководящих принципов на предмет того, что должно приниматься в расчёт при планировании мельчайших деталей для развёртывания этого вендорского продукта в конкретных условиях. Эти условия включают требования бизнеса, существующее рабочее и технологическое окружение, а также навыки и знания архитекторов и ИТ-персонала. Другими словами, необходимо применять эти принципы в конкретном контексте и корректировать при необходимости для конкретной ситуации.

Например, в статье «Предпочтительная Архитектура» утверждается: «Для получения архитектуры с высокой доступностью и устойчивостью сайта необходимо иметь два или более хорошо соединённых дата-центра». Это утверждение верно, но также не имеет никакого смысла для компаний, которые не имеют ресурсов для содержания двух дата-центров (факт, признанный Microsoft), и не работает там (по разным причинам), где компания решила сконцентрировать ИТ в одном дата-центре. В этих случаях надо игнорировать устойчивость сайта и вместо этого разработать план по использованию ИТ-активов компании для достижения высокой доступности, что возможно для Exchange 2013 с некоторыми известными ограничениями.

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

Общие советы по развёртыванию Exchange 2013 применимы к физическим и виртуальным серверам и включают:

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

• Настройте серверы в Группах доступности баз данных (DAGs) для достижения высокой доступности. Каждая Группа доступности баз данных (DAG) является Отказоустойчивым кластером, но Exchange имеет дело со всей конфигурацией и управлением базового кластера.

• Все члены Группы доступности баз данных (DAG) должны работать под одной и той же версией ОС Windows. Все члены Группы доступности баз данных (DAG) должны работать с одной и той же версией Exchange за исключением момента, когда кумулятивное обновление устанавливается на всех членах Группы доступности баз данных (DAG). Не забудьте перевести все члены Группы доступности баз данных (DAG) в режим обслуживания перед установкой кумулятивного обновления.

• Убедитесь, что каждая база данных имеет по крайней мере 3 копии в пределах Группы доступности баз данных (DAG). Такой уровень избыточности гарантирует, что потеря одного-двух серверов не лишит пользователей сервиса. По этой причине горизонтальное масштабирование посредством распределения почтовых ящиков на нескольких серверах (это позволит  поддерживать множественные копии баз данных) предпочтительней вертикального масштабирования с большими серверами для поддержки тысяч пользователей. Помните, база данных не должна резервно копироваться на этот же самый сервер. Высокая доступность Exchange зависит от способности поддерживать реплицированные базы данных, распределённые по нескольким серверам.

• Убедитесь, что серверы Exchange настроены на соответствующий предполагаемой нагрузке уровень производительности CPU, системы хранения данных и оперативной памяти. Используйте  Калькулятор для расчёта требований для роли сервера для создания первоначальных настроек и затем откорректируйте согласно специфике вашего окружения.

• Следуйте лучшей практике для управления и мониторинга Exchange 2013. Помните, что Управляемая Доступность должна быть включена на на всех серверах Exchange 2013 для обеспечения элементарного автоматического управления. Однако, Управляемая Доступность не осуществляет мониторинга Windows или гипервизора.

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

• Серверы Exchange обычно поддерживают стороннее программное обеспечение, которое интегрируется c Exchange для обеспечения дополнительной функциональности конечным пользователям. Необходимо проверять работоспособность этих продуктов с выбранным гипервизором.

Лучшие практические советы меняются со временем по мере увеличения опыта работы с программным обеспечением и улучшений, вносимых в оборудование и программное обеспечение. Microsoft обновляет Exchange 2013 каждый квартал и этот цикл обновлений необходимо учитывать в планах по развёртыванию.

Знакомства с гипервизором и Windows недостаточно для знаний по развёртыванию Exchange 2013. Необходимо понимать все тонкости перед тем, как начать и быть способным управлять полученный инфраструктурой.

Группа разработчиков Exchange постепенно улучшает поддержку гипервизоров и виртуализированных серверов в течение последних лет. Это поддержка получается через всестороннее тестирование разных версий Exchange на разных гипервизорах в течение многих лет. Такое тестироввание делается для того, чтобы убедиться, что различные комбинации работают, что целостность данных не меняется в различных условиях, и что возможно поддерживать решения в течение клиентского развёртывания. Опыт, полученный во время этих проверок, выливается в чёткий набор рекомендаций, которые необходимо принимать всерьёз во время планирования развёртывания виртуальных серверов Exchange.

Не удивительно, что Exchange поддерживает все версии Hyper-V. Сторонние гипервизоры, такие как vShpere, поддерживаются, если они утверждены Программой проверки виртуализации серверов (SVVP) Microsoft. Простой совет: используйте последнюю версию гипервизора для виртуализации Exchange. Все серверные роли Exchange 2013/2010 поддерживают виртуализацию, хотя рекомендуется использовать многоролевые серверы для достижения наилучшего соотношения доступности и использования ресурсов.

Важно отметить, что все версии Exchange поддерживают только блочные устройства хранения данных. Решения, основанные на протоколе Сетевой Файловой Системы (NFS), часто используются в виртуализированных окружениях, но не поддерживаются Exchange, в основном из-за проблем с производительностью и надёжностью, которые случались в прошлом. Неполадки с производительностью устранены, но надёжность (целостность данных) продолжает вызывать беспокойство. Microsoft не тестирует решения, основанные на протоколе Сетевой Файловой Системы (NFS), с Exchange и поэтому не может гарантировать, что любое из этих решений сможет обеспечить необходимые качества системы хранения данных, требуемые Exchange.

Вокруг данной темы разгорелось много технических споров и некоторые NFS-вендоры предложили поддержку своим клиентам, если они решили использовать Сетевую Файловую Систему (NFS), с Exchange. Сторонники использования Сетевой Файловой Системы (NFS) утверждают, что эта система хранения данных работает с Exchange, и может быть установлена с Exchange подходящим, надёжным и защищённым способом, и также указывают на работающие инсталляции для подтверждения своих доводов. Однако, проблема состоит в том, что хотя и возможно создать работающее решение, основанное на конкретной версии гипервизора со специфическими драйверами, подключённое к обозначенному набору NFS-хранилищ, в общем нельзя гарантировать, что любое NFS-решение будет работать таким же образом.

Позиция Microsoft остаётся неизменной: они не будут поддерживать NFS c Exchange вне зависимости от того развёрнуто ли NFS-хранилище на физических серверах Exchange или виртуальных. Другие альтернативные системы хранения данных с общим доступом, такие как iSCSI, SMB 3.0 или Fibre Channel, способны обеспечить надёжное хранение данных для Exchange. Поэтому рекомендация Microsoft абсолютна чёткая: любая система хранения данных, подключаемая к Exchange, должна быть блочной.

Разностные или дельта диски также не поддерживаются Exchange. Одно из отличий между Exchange 2010 и 2013 заключается в том, что Exchange 2013 поддерживает SMB 3.0 для файлов на виртуальных жёстких дисках (VHD). Microsoft рекомендует использовать утилиту JetStress для проверки, способна ли система хранения данных, предоставленная виртуальному Exchange, справиться с предполагаемой нагрузкой, генерируемой почтовыми ящиками и другой активностью.

Каждая версия Exchange имеет свои спецификации для систем хранения данных, т. к. Microsoft продолжает снижать требования к физическим операциям ввода/вывода в пользу использования большего кэширования данных в памяти. В то же самое время новые функции требуют больше ресурсов. Вмести эти факты делают обязательным выделение достаточного количества ресурсов для успешной виртуализации Exchange, а также проверку этих ресурсов тестированием.

В общем, любая система хранения данных, предоставленная Exchange, должна быть оптимизирована на низкую задержку операций ввода/вывода и её способность быть используемой функциями высокой доступности Exchange. Учитывая, что Exchange 2013 способен использовать различные виды систем хранения данных: от корпоративного уровня до JBOD-дисков - предоставление правильной блочной системы хранения данных не должно быть проблемой.

Exchange поддерживает кластер на базе узлов — метод возвращения машин в строй после поломки оборудования, произошедшем на одном из узлов кластера. Такие перебои заканчиваются перемещением виртуальных машин, работающих на одном из компьютеров, на другой узел кластера. Однако, кластер на базе узлов не обеспечивает настоящую высокую доступность для Exchnage, т. к. узел не имеет понятия о том, что различные функции Exchange объединяются для обеспечения высокой доступности его базам данных и системе транспорта. С другой стороны, если вы запускаете отдельные серверы Exchange, которые не являются частью Группы обеспечения доступности баз данных (DAG), то кластер на базе узлов — это эффективный метод быстрого восстановления этих серверов до рабочего состояния.

Хотя он справляется с неполадками оборудования, кластер на базе узлов не разрешает ситуаций, которые вызываются Exchange, такие как служба исправления обособленной страницы, используемая для разрешения повреждённых страниц в копиях баз данных или автоматическом переключателе баз данных на другого члена Группы обеспечения доступности баз данных (DAG), если Управляемая Доступность определила, что протокол упал на каком-то сервере. По мере понимая его ограничений хорошей идей является использование кластера на базе узлов совместно с высокой доступностью Exchange для получения максимальной защиты от потенциальных выходов из строя.

Exchange 2013 поддерживает технологию миграции с некоторыми ограничениями. Например, можно использовать Динамическую Миграцию Hyper-V или функционал vMotion от Vmware для перемещения виртуальных серверов Exchange между компьютерами-хостами, но нельзя использовать службу Быстрой Миграции Hyper-V. Основное условие — виртуальная машина с запущенным Exchangе должна оставаться включённой во время миграции.

Выполнение восстановления-на-определенный-момент-времени с сохранением-на-диск и перемещение не поддерживаются. Причина проста: чтобы обеспечить максимально возможную производительность, Exchange оперирует большим количеством данных в памяти. Если сервер Exchange является членом Группы обеспечения доступности баз данных (DAG), эта память включает снимок текущего состояния базового Отказоустойчивого Кластера Windows.

Сохранение-на-диск и перемещение могут вернуть сервер Exchange в такое рабочее состояние, при котором данные в памяти вызовут повреждение перемещённого сервера Exchange или другого сервера в организации. Например, когда возвращаете члена Группы обеспечения доступности баз данных (DAG) в рабочее состояние, этот сервер может понять, что является полнофункциональным членом базового Отказоустойчивого Кластера Windows, и начать функционировать соответствующим образом. Во время процесса миграции другой член Группы обеспечения доступности баз данных (DAG) может обнаружить, что сервер ушёл в оффлайн, и по этой причине перенастроит членство в кластере, удалив отключённый сервер. В результате этого происходит конфликт синхронизации, при котором один из серверов имеет конкретный снимок кластера, неразделяемый остальными членами кластера. Восстановление Группы обеспечения доступности баз данных (DAG) и кластера до состояние полного функционирования потребует ручного вмешательства администратора.

Оставив виртуальные машины (и следовательно Exchange) включёнными во время миграции, это позволит избежать проблемы, т. к. отсутствует потребность для других серверов Exchnage начинать действия (такие как активация копий баз данный на других серверах в пределах Группы обеспечения доступности баз данных (DAG) или инициация повтора сообщений во-время-передачи из Сети системы безопасности), потому что остальные серверы Exchange зарегистрировали факт выхода сервера из строя.

Наибольшей проблемой, с которой можно столкнуться при миграции, наверняка будет то, что узлы члена Группы обеспечения доступности баз данных (DAG) продолжают обмениваться информацией во время перемещения. Неспособность достичь этого заставляет пульс кластера остановиться и перемещаемый узел будет удалён из Отказоустойчивого Кластера Windows, что укрепит Группу обеспечения доступности баз данных (DAG). Когда происходит миграция, копия восстановления-на-определенный-момент-времени памяти виртуальной машины переносится из источника на целевой компьютер-хост. В то же самое время  изменённые страницы отслеживаются и эти страницы также копируются на целевой компьютер по мере продолжения процесса миграции. В конце концов, страницы перестают изменяться и настаёт «период частичного отключения», в течение которого виртуальная машина недоступна, т. к. она перемещается из хоста-источника на целевой компьютер-хост.

Если период частичного отключения короче остановки пульса кластера (обычно это 5 секунд), сервер Exchange может продолжить работать с момента начала частичного отключения, и операции будут продолжаться в нормальном ритме. Если частичное отключение длится дольше остановки сервера, то Отказоустойчивый Кластер Windows посчитает, что узёл ушёл в оффлайн и удалит этот узел из кластера. С свою очередь, это заставит процесс Активного Диспетчера, работающего в Группе обеспечения доступности баз данных (DAG), инициировать отказоустойчивость сервера для только что удалённого узла и активировать его базы данных на остальных членах Группы обеспечения доступности баз данных (DAG). Фактически миграция не провалилась, потому что службы не поддерживались и стандартные операции не продолжались, когда виртуальная машина переехала на новый компьютер-хост. В конце концов только что перемещённый сервер вернётся в строй и переприсоединится к кластеру, но снова потребуется ручное вмешательство администратора, чтобы реактивировать копии баз данных на сервере для перебалансировки нагрузки по Группе обеспечения доступности баз данных (DAG).

Эту проблему можно уменьшить в два этапа. Во-первых, убедиться, что имеется достаточная пропускная способность сети для передачи виртуальных машин без получения риска, что период частичного отключения превысит остановку пульса кластера. Точное значение величины пропускной способности сети зависит от размера виртуальной машины, нагрузки на неё в данный момент и версии используемого гипервизора. Таким образом, необходимо выполнить тестирование для точного фиксирования того, как быстро виртуальные машины могут быть перенесены. Второй этап — это настройка времени остановки пульса кластера, чтобы отразить время периода частичного отключения. Настраивать время остановки пульса кластера обычно не рекомендуется, но это может быть эффективным решением проблемы. Если всё-таки решите отрегулировать время остановки, самым высоким рекомендуемым разработчиками Exchange значением является 10 секунд.

Exchange 2013 спроектирован так, чтобы быть высокодоступным приложением, которое может продолжать обеспечивать высокой уровень сервиса клиентам, даже когда случаются общие сценарии отключения, затрагивающие базы данных, такие как поломки жёстких дисков или серверов. Вместе с остальными многочисленными функциями, включая Управляемую Доступность, Группу обеспечения доступности баз данных (DAG) и реплицированные базы данных, являются фундаментальными блоками, используемыми Exchange для обеспечения высокой доступности.

Важно отметить, что многие функции гипервизора, которые считаются функциями высокой доступности, на самом деле предусмотрены, чтобы использоваться для аварийного восстановления (DR). Это правда, что эти функции могут способствовать достижению сервиса высокой доступности, но это не является целью. Функции аварийного восстановления (DR), такие как Hyper-V replica, нацелены на поддержание серверов в рабочем состоянии, скорее отслеживая сбои оборудования, чем позволяя им функционировать на уровне приложений, когда транзакционный контекст и предохранение необходимы для достижения защищённого, высокодоступного сервиса.

Развёрнутый на физических или виртуальных серверах, Exchange зависит от своих собственных функций высокой доступности для подтверждения того, что сервис предоставлен конечным пользователям. Такой подход позволяет Exchange функционировать в одной и той же предсказуемой манере как на физических, так и на виртуальных серверах. Функции аварийного восстановления (DR), включённые гипервизором, такие как Hyper-V replica, не поддерживаются Exchange. Эти функции лучше всего использовать с помощью приложений, которые, в отличие от Exchange, не имеют функционала высокой доступности, встроенного в ядро продукта. При виртуализации Exchange необходимо продолжать использовать встроенные функции высокой доступности и развёртывать многоролевые серверы Exchange, объединённые в Группу обеспечения доступности баз данных (DAG), для достижения желамого результата.

Когда запускаете Exchange 2013 на виртуальных машинах, необходимо настроить статическое распределение памяти для этих машин. Exchange не поддерживает динамическое распределение памяти, «воздушный шар» (ballooning — способ координации с компонентами динамического распределения памяти в гостевой операционной системе), чрезмерное выделение памяти, или управление памяти для любого сервера в производственной среде. При развёртывании Exchange следует избегать любые сторонние продукты управления памятью на виртуальных платформах. Причина проста: серверы Exchange кэшируют большой объём данных в памяти для улучшения производительности. Если память удаляется из виртуального сервера Exchange произвольным образом, это может иметь непредсказуемые последствия для различных компонентов Exchnage, вплоть до значительного падения производительности, когда клиенты буду испытывать явные долгие задержки ответов на запросы от общего сервера, например, при создании нового сообщения. В большинстве случаев производительность падает по причине того, что Exchange вынужден прибегать к использованию ресурсоёмких операций ввода/вывода для извлечения информации из систем хранения данных, а не оперировать страницами в памяти.

Другой фактор, который необходимо принять в расчёт: Exchange 2013 имеет систему управления рабочей нагрузкой, предназначение которой - гарантировать, что ни одному компоненту Exchange не будет позволено чрезмерно нагружать сервер, потребляя слишком много ресурсов, и что более важная работа будет выполнена раньше и до выполнения менее важных. Система управления рабочей нагрузкой наблюдает за запущенными процессами на сервере Exchnage, гарантируя, что доступные ресурсы будут потребляться эффективно. Очевидно, что управление рабочей нагрузкой работает хорошо, когда сервер стабилен и ресурсы не появляются и не исчезают без предупреждения. Если ресурсы удаляются внезапно, то действия, выполняемые системой управления рабочей нагрузкой вряд ли будут достаточно правильными и общая производительность системы пострадает, потому что компоненты протоколов (например, как те, что управляют интерактивными запросами клиентов) не получают необходимого им количества ресурсов.

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

Снапшоты гипервизора не поддерживаются как способ восстановления сервера Exchange на определённый момент времени. Это вполне приемлемый метод для тестирования серверов Exchange, но его нельзя применять в производственной среде по той же самой причине, что и виртуальные серверы Exchange должны быть включены во время миграции.

Рассмотрим ситуацию, которая может произойти, если воспользоваться снапшотом гипервизора для многоролевого сервера Exchange 2013, который состоит в Группе обеспечения доступности баз данных (DAG), для последующей возможности восстановления этого снапшота. В момент снятия снапшота Exchange, скорее всего, оперирует большим количеством данных в памяти, включая те, что ещё не были переданы базам данных, и те, что копируются на другие члены Группы обеспечения доступности баз данных (DAG) в блочном режиме. Также может использоваться классическое копирование файлов для передачи транзакционных логов на другие члены Группы обеспечения доступности баз данных (DAG). Всё это происходит под контролем Службы репликации Microsoft Exchange, которая в курсе того, какие данные необходимо скопировать на различные целевые серверы, и каково текущее состояние репликации.

При восстановлении снапшота происходит возращение сервера Exchnage обратно в Группу обеспечения доступности баз данных (DAG) таким же, каким он был в момент снятия снапшота. Это может быть  несколько часов или даже дней назад по сравнению с текущим моментом. У гипервизора нет информации о том, какие данные обрабатывал Exchange во всей Группе обеспечения доступности баз данных (DAG) в момент снятия снапшота. Также, гипервизор не имеет понятия о том, какие шаги надо предпринять для возвращения сервера обратно в Группу обеспечения доступности баз данных (DAG) предсказуемым и известным способом. И, когда этот сервер Exchange просыпается, Служба репликации Exchange ни имеет ни малейшей идеи о том, что происходило в промежуток времени между снятием снапшота и текущим состоянием репликации на остальных членах Группы обеспечения доступности баз данных (DAG). Exchange не имеет функционала для восстановления члена Группы обеспечения доступности баз данных (DAG) методом продвижения его к текущему времени контролируемо и бесконфликтно.

В результате этого восстановленный снапшот, вероятно, отправит Группу обеспечения доступности баз данных (DAG) в состояние, в котором репликация находится в несогласованном состоянии для одной или более баз данных. Возможно даже, что какая-то база данных повредится, особенно, если служба исправления обособленной страницы попыталась восстановить повреждённую базу данных, когда сервер был недоступен (оффлайн). Вполне возможно, что сервер продолжит работать нормально после восстановления снапшота, но невозможно гарантировать, что нормальная работа сервиса продолжится после восстановления, и Microsoft не окажет технической поддержки при возникновении такой проблемы.

Снапшоты имеют ценность в тестовых лабораториях, т. к. они позволяют вернуть сервер в хорошо известное состояние, например, перед применением нового кумулятивного обновления на сервер. Учитывая рабочие нагрузки, которым подвергаются лабораторные системы, вы получите меньший риск столкнуться с проблемами, указанными ранее,чем при активной работе с серверами в производственной среде. Однако, если вы решили использовать снапшоты в тестовой лаборатории, то, скорее всего, появится необходимость сделать снапшоты для всех членов Группы обеспечения доступности баз данных (DAG), чтобы можно было при необходимости откатиться до точки согласования. Но восстанавливая очень старый снапшот для тестирования Группы обеспечения доступности баз данных (DAG), вряд ли всё пройдёт успешно, т. к. Exchange не предназначен для управления путешествиями во времени.

Исключение часто подтверждает правило. В данном случае, создание снапшота или теневой копии Hyper-V, которое ранее применялось для создания резервных копий, является исключением там, где применимо использование этих технологий на сервере Exchange 2013 в производственной среде. Снапшот или копия используется как промежуточный этап в процессе создания правильной резервной копии Exchange, которая может быть использована для восстановления данных в будущем. Настройка гипервизора на снятие снапшота работающего сервера является только частью общего процесса, необходимого для сохранения целостности Exchange, и должна выполняться интерфейсами API Cлужбы теневого копирования томов Windows, предназначенных, во-первых, для снижения активности сервера, информирования Exchangе о том, что резервная копия выполнена, а затем для подтверждения факта готовности резервной копии, чтобы Exchange мог укоротить поток логов транзакций.

Не рекомендуется превышать лимит процессоров при их распределении на виртуальные сервера Exсhange. Exchange — это приложение, которое будет использовать все доступные выделенные ему ресурсы и, особенно, это касается Exchange 2013. При назначении процессоров виртуальным машинам (vCPU) Exchange ожидает возможности использовать эти процессоры и, если компьютер-хост не может сделать эти процессоры доступными по причине того, что эти процессоры физически не существуют или они заняты другими приложениями, производительность Exchange существенно снизится. Последствия превышения процессорного лимита (процессорный голод) будет заметен в таких вещах, как рост очередей сообщений, замедление индексации содержимого (ведёт к неточному поиску) и увеличение задержки в Удалённом вызове процедур (RPC), что приведёт к снижению отзывчивости на клиентские запросы.

Лучшей практикой является назначать такое количество процессоров, которое точно будет гарантировано виртуальным серверам Exchange (соотношение 1:1 между виртуальными и физическими процессорами). Другими словами, не превышайте процессорный лимит.

Microsoft не рекомендует включать hyperthreading на физических серверах Exchnage 2013. Это связано с тем, что они не хотят, чтобы логические процессоры, включённые гипертрейдингом были видны серверу, т. к. это меняет то, как фреймворк .Net рассчитывает распределение памяти. Exchange интенсивно использует фреймворк .Net и поэтому важно, чтобы он основывался на точных расчётах памяти.

Рекомендация для виртуальных серверов слегка отличается. В этом случае приемлемо включать hyperthreading пока сайзинг серверов основан на имеющихся ядрах физического процессора, а не виртуальных процессорах. Например, сервер, оснащённый четырьмя физическими CPU, каждый из которых поддерживает 4 процессора, имеет доступные 16 физических процессоров. Назначьте эти физические процессоры виртуальным серверам вместо логических процессоров, включённых гипертрейдингом. Другими словами, если имеется 4 виртуальных сервера, назначьте каждому серверу 4 процессора.

В общих словах, лучше всего выполнять сайзинг под требования для Exchange, как будто он будет развёрнут на физических компьютерах, а затем проводить какие-либо корректировки, необходимые для размещения виртуальной платформы, включая резервирование необходимых ресурсов, чтобы они, будучи выделенными для Exchange, не могли быть заняты другими приложениями.

NUMA — это неравномерный доступ к памяти, схема реализации компьютерной памяти, используемая в мультипроцессорных системах для увеличения скорости процессора без негативного воздействия на процессорную шину. Слово «неравномерный» в названии означает тот факт, что одна память расположена ближе к процессору, чем другая. Таким образом, однородный доступ к памяти отсутствует. Гипервизоры используют NUMA для более эффективного использования памяти гостевыми машинами. Например, Hyper-V имеет функцию «Виртуальный NUMA», которая группирует виртуальные процессоры и память, назначенные гостевым машинам, в виртуальные NUMA узлы, и гостевая машина «видит» топологию, основанную на физической топологии системы-хозяйки. При создании виртуальной машины Hyper-V создаёт конфигурацию, основанную на физической топологии, принимая в расчёт количество логических процессоров и памяти на один NUMA-узел.

В отличие от SQL, Exchange не имеет понятия о NUMA и не получает никаких преимуществ масшатабирования от работы на серверах с включённым NUMA. Однако, Exchange получит преимущество от оптимизации операционной системы для NUMA. Это согласуется с рекомендацией назначать статические ресурсы CPU и памяти виртуальным системам, на которых работает Exchange так, чтобы Exchange затем мог управлять выделенными ресурсами для его различных компонентов.

Однажды развёрнутое, виртуализированное окружение Exchange должно обеспечиваться поддержкой. Вот несколько рекомендаций, которые помогут поддерживать виртуальные сервера Exchnage 2013 в хорошем состоянии.

В общем, лучше горизонтально масштабировать Exchange, создавая много виртуальных серверов, чем делать вертикальное масштабирование и сосредотачивать всё на небольшом количестве больших серверов. Такой подход позволяет получить максимум преимуществ от высокой доступности Exchange, распределяя почтовые ящики по базам данных, управляемым Группой обеспечения доступности баз данных (DAG), где каждая база данных имеет по крайней мере 3 копии. В такой же манере, следует распределить виртуальные серверы Exchange по множеству физических компьтеров-хостов так, чтобы поломка одного хоста ударила как можно по меньшему числу серверов Exchange. Даже если оборудование сможет справиться с нагрузкой, не имеет смысла иметь 10-12 виртуальных серверов Exchange на одном большом (мощном) хосте, т. к. его поломка может привести к полной невозможности оказания сервиса всем клиентам.

В идеале, должна быть возможность для серверов Exchange, которые продолжают работать после поломки какого-либо хоста, восстановить полное оказание сервиса путём активации копий баз данных на оставшихся серверах. Достижение этой цели требует тщательного планирования размещения почтовых ящиков и баз данных, и внимания к деталям для других зависимостей, таких как следящие сервера, контоллеры доменов Active Directory, балансировщики нагрузки, и т. д. Это также требует постоянного мониторинга для того, чтобы убедиться, что не происходит незапланированная активация баз данных из-за автоматизированных переходов на другой ресурс, вызванных Управляемой Доступностью, обслуживанием сервера или другими рабочими моментами.

Хотя Exchange и создан приложением высокой доступности и включает в себя множество функций для понимания этой цели, его успешное функционирование требует, чтобы все части решения работали правильно, начиная с основного оборудования. Гипервизоры — это не магия и они не делают автоматически виртуализированные приложения высокодоступными. То же самое верно для функций высокой доступности, встроенных в Exchange 2013. Комбинация этих функций высокой доступности может дополнять друг друга, но ни одна из них не будет эффективной, пока высокая доступность не будет заложена в развёртывание. Это означает следующее:

• Функции высокой доступности Exchange 2013 должны использоваться в качестве основной защиты данных Exchange

• Функции высокой доступности гипервизора, такие как миграция, должны использоваться для заполнения возможных пробелов в основной защите

• Должно уделяться внимание другим элементам решения, таким как Active Directory, балансировщики нагрузки и следящие серверы.

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

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

Microsoft выпускает новые кумулятивные обновления для Exchange 2013 ежеквартально и последнее доступное обновление должно быть установлено перед обращением в техподдержку Microsoft. Поэтому необходимо быть готовым устанавливать кумулятивные обновления на регулярной основе. В то же самое время необходимо подготовиться в регулярному обновлению Windows, гипервизора, драйверов оборудования, других приложений и сторонних продуктов, используемых совместно с Exchange 2013.

Обновлять Exchange 2013 нетрудно и применение последнего кумулятивного обновления полностью обновит сервер новейшими функциями и исправит выявленные ошибки. Однако, история применения обновлений Exchange 2013 омрачена маленькими, но раздражающими, ошибками, которые причинили множество проблем пользователям. По этой причине жизненно важно тестировать новое кумулятивное обновление в среде, которая достаточно точно повторяет производственную среду, перед его внедрением в производство.

Возможно создание резервных копий на хосте, который представляет собой резервную копию всего сервера, включая Exchange. Для того, чтобы сделать резервную копию, которая может быть успешно использована для восстановления работающего сервера Exchangе, необходимо, чтобы утилита создания резервной копии знала об Exchange и взаимодействовала с продуктом для захвата конфигурации сервера вместе с базами данных в момент создания резервной копии. Самое важное заключается в том, что утилита создания резервной копии использует Службу теневого копирования томов Windows (VSS) для правильного взаимодействия с Банком Сообщений и, что усечение журнала транзакций произойдёт верно. Отметьте, что процесс усечения журнала различен для отдельностоящих почтовых серверов Exchange 2013 и для объединённых в Группу обеспечения доступности баз данных (DAG). Поэтому критично, чтобы утилита создания резервной копии использовала точные вызовы интерфейсов API Службы теневого копирования томов Windows (VSS) для подготовки Exchange к созданию резервной копии, и затем информировала Exchange об успешном создании резервной копии. Также важно, чтобы резервные копии баз данных находились в чистом состоянии для того, чтобы их можно было сразу использовать, если их надо восстановить.

Единственный верный способ узнать, прошло ли создание резервной копии успешно, проверить их в качестве источника для восстановления данных. По этой причине важно проверять, что резервные копии, снятые с виртуальных серверов Exchange 2013, можно быстро и надёжно восстановить. Удостоверьтесь, что такое тестирование происходит постоянно, чтобы обслуживающий персонал был знаком с шагами, необходимыми для восстановления сервера из резервной копии и проверки того, что восстановленные базы данных содержат то, что нужно, и нет необходимости переводить их в чистое состояние перед их использованием. С особой тщательностью восстанавливайте базы данных, принадлежащие Группе обеспечения доступности баз данных (DAG).

Решение о виртуализации Exchange 2013 не должно приниматься обособленно. Это комплекс решений, который требует взвешивания многих факторов и оценки в разрезе ИТ-среды, в которой будет развёрнут Exchange, удовлетворения нужд бизнеса и долговременной технической стратегии компании. Microsoft создала Exchange 2013 отличным кандидатом для виртуализации при условии, что предостережения, разъяснённые в этой статье, приняты во внимание. Вопрос, следовательно, состоит в том, какой Exchange 2013, виртуальный или физический, больше подходит для удовлетворения нужд вашей компании. И ответ на этот вопрос можете дать только вы.