Разъяснение вопросов виртуализации в Exchange 2010 с пакетом обновления 1 (SP1)

Оригинал статьи опубликован во вторник, 11 октября 2011 г.

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

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

Учитывая сказанное, далее приводится краткий обзор изменений и того, что они практически значат.

Если развернута система Exchange 2010 с пакетом обновления 1 (или более поздние версии):

• В виртуальной машине поддерживаются все роли сервера Exchange 2010, включая единую систему обмена сообщениями.
• Виртуальные машины единой системы обмена сообщениями имеют следующие особые требования:
  • Для виртуальной машины требуется четыре виртуальных процессора. Объем памяти должен определяться с помощью стандартных рекомендаций.
  • Для каждой виртуальной машины с ролью единой системы обмена сообщениями всегда должны быть доступны четыре физических процессорных ядра. Это требование означает, что переназначение процессоров использовать нельзя. Это требование затрагивает способность виртуальной машины с ролью единой системы обмена сообщениями использовать ресурсы физического процессора.
• Серверные виртуальные машины Exchange (включая виртуальные машины почтовых ящиков Exchange, являющиеся частью группы обеспечения доступности баз данных) могут сочетаться с технологией аппаратной отказоустойчивой кластеризации и миграции, если виртуальные машины настроены так, что они не сохраняют состояние на диске и не восстанавливают его при перемещении или переходе в автономный режим. Все действия по обработке отказа должны приводить к холодной загрузке, когда виртуальная машина активируется на целевом узле. Вся запланированная миграция должна приводить либо к завершению работы и холодной загрузке, либо к сетевой миграции, использующей технологию, подобную динамической миграции Hyper-V. Миграция виртуальных машин с помощью низкоуровневой оболочки поддерживается поставщиком низкоуровневой оболочки. Поэтому необходимо убедиться, что поставщик низкоуровневой оболочки проверил и поддерживает миграцию виртуальных машин Exchange. Майкрософт поддерживает миграцию таких виртуальных машин посредством динамической миграции Hyper-V.

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

• Холодная загрузка. Это включение системы из состояния отключенного питания и чистый запуск ОС. В этом случае не сохраняется какое-либо состояние ОС.
• Сохраненное состояние. Когда питание виртуальной машины отключается, низкоуровневые оболочки обычно имеют возможность сохранять состояние виртуальной машины на момент отключения, чтобы при включении машины вернуться к этому состоянию и не производить процесс "холодной загрузки". "Сохраненное состояние" может быть результатом операции "Сохранить" (Save) в Hyper-V.
• Запланированная миграция. Если администратор инициирует перемещение виртуальной машины с одного узла низкоуровневой оболочки на другой, мы называем это запланированной миграцией. Это может быть однократная миграция, или администратор может настроить некоторую автоматизацию для перемещения виртуальной машины по расписанию или в ответ на определенное событие, возникающее в системе и не являющееся сбоем оборудования или ПО. Ключевой момент здесь в том, что виртуальная машина Exchange работает в нормальном режиме и по какой-то причине перемещается. Это может быть выполнено с использованием технологий динамической миграции, vMotion или других. Если в виртуальной машине Exchange или на узле низкоуровневой оболочки, где расположена машина, возникают различные сбои, перемещение не будет называться "запланированным".

Виртуализация серверов единой системы обмена сообщениями

Одно из изменений состоит в добавлении поддержки роли единой системы обмена сообщениями в Hyper-V и другие поддерживаемые низкоуровневые оболочки. Как я уже говорил в начале статьи, мы хотели гарантировать, что изменения, вносимые нами в заявление об обеспечении поддержки, не отразятся на функциональности продукта и будут способствовать предоставлению пользователям наилучшего обслуживания. Поэтому мы требуем, чтобы для поддержки единой системы обмена сообщениями развертывался Exchange Server 2010 с пакетом обновления 1 (SP1). Причина этого достаточно проста. Роль единой системы обмена сообщениями зависит от промежуточного компонента, предоставляемого рабочей группой Microsoft Lync. Наши партнеры в Lync проделали определенную работу до выпуска пакета обновления 1 (SP1) для Exchange 2010, чтобы обеспечить поддержку высококачественной обработки звука в режиме реального времени в виртуальном развертывании, а в пакете обновления 1 для Exchange 2010 эти изменения были интегрированы в роль единой системы обмена сообщениями. После этого мы провели дополнительное тестирование для проверки того, что работа пользователей будет максимально комфортной, и затем изменили заявление об обеспечении поддержки.

Как вы, скорее всего, уже заметили, имеются определенные требования относительно конфигурации ЦП для виртуальных машин (и компьютеров, на которых размещены низкоуровневые оболочки), на которых предполагается работа единой системы обмена сообщениями. Это является дополнительной предосторожностью, направленной на предотвращение плохого качества работы для конечных пользователей (которое может проявиться в неудовлетворительном качестве звука).

Аппаратная отказоустойчивая кластеризация и миграция

Один из крупнейших очагов непонимания по поводу измененного заявления об обеспечении поддержки возник вокруг объединения технологий аппаратной отказоустойчивой кластеризации и миграции с группой обеспечения доступности баз данных (DAG) в Exchange 2010. Но ларчик-то на самом деле просто открывается.

• Сначала скажем о том, поддерживаем ли мы сторонние технологии виртуализации (например, vMotion компании VMware). Корпорация Майкрософт не может сделать заявление об обеспечении "поддержки" относительно интеграции сторонних продуктов низкоуровневой оболочки и использования этих технологий с Exchange 2010, так как эти технологии не являются частью программы проверки виртуализации Windows Server (SVVP), охватывающей другие аспекты нашей поддержки сторонних низкоуровневых оболочек. Здесь мы делаем общее заявление об обеспечении поддержки, но вам необходимо дополнительно убедиться, что поставщик низкоуровневой оболочки поддерживает объединение своей технологии миграции (кластеризации) с Exchange 2010. Проще говоря, если поставщик низкоуровневой оболочки и его технология миграции поддерживают Exchange 2010, то мы поддерживаем Exchange 2010 с технологией миграции поставщика.

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

• Третье, когда в заявлении об обеспечении поддержки речь заходит о технологиях миграции , мы говорим о любой технологии, позволяющей выполнять запланированное перемещение виртуальной машины с одного компьютера ВМ на другой. Кроме того, это может быть автоматизированное перемещение, происходящее в процессе балансировки нагрузки ресурсов (но не относящееся к сбою в системе). Миграция полностью поддерживается при условии, что виртуальные машины никогда не запускаются из сохраненного состояния, имеющегося на диске. Это значит, что в Exchange 2010 поддерживаются технологии перемещения виртуальных машин посредством переноса состояния и памяти виртуальной машины по сети, исключающие простой для конечного пользователя. Обратите внимание, что поставщик сторонних низкоуровневых оболочек должен обеспечить поддержку технологии миграции, а Майкрософт, со своей стороны, предоставит поддержку Exchange при использовании в данной конфигурации. В случае использования технологии Microsoft Hyper-V это может означать, что динамическая миграция поддерживается, но быстрая миграция не поддерживается.

В случае Hyper-V важно иметь в виду, что при выборе операции "Переместить" (Move) на виртуальной машине поведение по умолчанию заключается в выполнении быстрой миграции. Чтобы обеспечить совместимое состояние с другими членами группы обеспечения доступности баз данных Exchange 2010 с пакетом обновления 1 (SP1), важно настроить это поведение, как показано на снимке параметров виртуальной машины ниже (приведенные здесь параметры показывают порядок развертывания Hyper-V):

Рис. 1. Правильное поведение виртуальной машины Hyper-V для членов группы обеспечения доступности баз данных

Рассмотрим эти параметры. В Hyper-V динамическая миграция членов группы обеспечения доступности баз данных поддерживается, но быстрая миграция не поддерживается. Если представить картинками, то следующий вариант поддерживается:

Рис. 2. Динамическая миграция члена группы обеспечения доступности баз данных Hyper-V поддерживается (перейти к снимку большего размера)

А следующий вариант не поддерживается:

Рис. 3. Быстрая миграция членов группы обеспечения доступности баз данных не поддерживается

Мы надеемся, что данная статья поможет прояснить заявление об обеспечении поддержки и рекомендации по изменениям в пакете обновления 1 (SP1). Мы ждем любые ваши отзывы!

Джефф Милиф (Jeff Mealiffe)

Это локализованная запись блога. Исходная статья находится по ссылке Demystifying Exchange 2010 SP1 Virtualization