Это значительное изменение по сравнению с тем, что было всего несколько лет назад, когда серверы развертывались на физическом оборудовании, если не было особых оснований для виртуализации.
Как обстоит дело с Microsoft Exchange Server? Нужно ли виртуализировать какую-то часть или всю среду Exchange и воспользоваться выгодами консолидации, оптимизации и гибкости, которые предоставляет виртуальная инфраструктура? В действительности многие среды Exchange, особенно Exchange 2010, могут быть развернуты на виртуальных серверах, если для виртуальных гостевых систем выделены достаточные ресурсы и виртуальные хост-системы правильно масштабируются. Неграмотное развертывание Exchange в виртуальной среде может привести к замедлению работы и другим проблемам производительности и уменьшить доверие руководства к виртуализации в целом, поэтому очень важно заранее рассмотреть критерии для построения виртуальной среды Exchange.
Поддержка виртуализации компанией Microsoft
История поддержки продуктов Microsoft, работающих в виртуальных системах, долгая и сложная. До недавних пор Microsoft предлагала ограниченную поддержку своих флагманских серверных продуктов, таких как Microsoft SQL Server, SharePoint и Exchange, и оставляла открытым вопрос о том, что проблему может потребоваться воспроизвести на физическом оборудовании, если специалисты по поддержке не смогут определить природу проблемы в виртуальной среде. Кроме того, в то время был выпущен Exchange Server 2007, а тогдашний собственный продукт виртуализации Microsoft, Virtual Server 2005 R2, не был продуктом, построенным на базе гипервизора, и не мог виртуализировать 64?разрядные гостевые системы. Таким образом, поддержка виртуализации 64?разрядных продуктов, таких как Exchange 2007, отсутствовала.
Два события изменили ситуацию. Первым был выпуск корпорацией Microsoft продукта Hyper-V, гипервизора с 64?разрядной поддержкой; вторым — разработка программы оценки виртуализации серверов Server Virtualization Validation Program (SVVP), которая обозначила установку Microsoft на официальную поддержку работы ее продуктов на сторонних платформах виртуализации, таких как VMware ESX Server и Citrix XenServer. Эта программа, описанная в статье «Support policy for Microsoft software running in non-Microsoft hardware virtualization software» (support.microsoft.com/kb/897615), позволила осуществлять поддержку решений Microsoft на сторонних продуктах виртуализации, которые были проверены в Microsoft и удовлетворяли определенному критерию, а именно — способности гостевых сессий получать прямой доступ к аппаратным ресурсам через гипервизор виртуализации. Эти два события открыли для серверов Microsoft путь к работе в виртуальных гостевых системах и принесли спокойствие организациям, которым требовались решения с официальной поддержкой.
Поддержка виртуализации Exchange
Exchange в течение многих лет не поддавался виртуализации. Одним из оснований для этого было то, что серверы почтовых ящиков Exchange всегда имели высокие требования к производительности и операциям ввода/вывода, которые иногда могли быть не по силам виртуальной среде. И хотя Exchange можно было запускать в виртуальной среде, он мог потреблять столь значительную часть ресурсов хост-системы, что все выгоды консолидации с помощью виртуализации могли сойти на нет. Если к тому же вспомнить позицию Microsoft в отношении поддержки, то легко понять, почему Exchange стал одним из приложений, которые сильно отставали от других по количеству систем, виртуализированных в реальной производственной среде.
Exchange Server 2003 виртуализировался очень редко, за исключением небольшого числа серверов с ролью Outlook Web Access (OWA) или серверов?плацдармов (bridgehead server). И даже в этих случаях Microsoft не поддерживала многие варианты. Exchange 2007 стал первой версией, получившей широкую поддержку виртуализации, чаще для серверов клиентского доступа и центральных транспортных серверов и реже для серверов почтовых ящиков. Exchange 2010, однако, уже позиционируется как очень подходящая для виртуализации версия, так как Microsoft добилась успехов как в развитии технологий виртуализации, так и в снижении требований к операциям ввода/вывода для роли сервера почтовых ящиков. Объем дисковых операций ввода/вывода в Exchange 2010 значительно меньше, чем в Exchange 2007, где, в свою очередь, их меньше, чем в эквивалентном сервере Exchange 2003. В результате многие организации начинают всерьез задумываться о виртуализации своих новых систем Exchange 2010.
В виртуализации ролей сервера Exchange 2010 существуют некоторые ограничения. Например, Microsoft не поддерживает виртуализацию роли сервера объединенных коммуникаций Unified Messaging. Однако остальные роли — сервер клиентского доступа, транспортный центральный транспорт, пограничный транспортный сервер и сервер почтовых ящиков — поддерживаются, при условии что программное обеспечение виртуализации участвует в упомянутой выше программе SVVP.
Microsoft также не поддерживает использование варианта высокой доступности почтовых ящиков в Exchange 2010, групп доступности DAG, на высокодоступных виртуальных узлах. Это ограничение распространяется на такие технологии, как V-Motion от VMware, XenMotion компании Citrix, Hyper-V Live Migration, а также на все остальные решения, которые автоматически переводят гостевые сессии с вышедшего из строя узла на другой хост-сервер. В общем случае более предпочтительным вариантом может быть использование реплик групп доступности DAG, а серверы почтовых ящиков Exchange можно развернуть на виртуальных системах без обеспечения высокой доступности.
Требования к узлу виртуализации (виртуальной хост-системе)
Ключом для построения устойчивой и высокопроизводительной виртуализированной среды Exchange является использование соответствующей архитектуры на узлах виртуализации. Стандартные настройки системы и медленные диски могут работать в тестовой среде, но Exchange имеет специфические требования к хост-системе для достижения высокой производительности. Необходимо обеспечить следующие минимальные требования при проектировании инфраструктуры узлов виртуализации.
- Выделите достаточно памяти для операционной системы хоста. Если вы используете Hyper-V, необходимо зарезервировать не менее 1 Гбайт оперативной памяти для использования хост-системы с Hyper-V. Если задействованы сторонние продукты виртуализации, обратитесь к производителю за информацией о необходимом объеме памяти.
- Выделите сетевой адаптер для управления. Каждая хост-система должна иметь выделенный сетевой адаптер для управления, отдельный от сетевых адаптеров, предназначенных для работы виртуальных гостевых систем.
- Выделите сетевой адаптер для отработки отказа (failover). Если вы используете программное обеспечение для создания отказоустойчивых хост-систем для виртуализации, такое как Hyper-V Live Migration, используйте отдельный сетевой адаптер для отработки отказа. Однако помните об ограничениях поддержки при использовании отказоустойчивых хост-систем с группами DAG Exchange.
- Используйте несколько логических номеров устройств LUN или дисковых массивов. Рекомендуется выделять отдельный логический номер LUN или дисковый массив для хост-системы, еще один — для виртуальных дисков гостевых операционных систем, и как минимум еще один — для хранилища базы данных сервера почтовых ящиков Exchange.
- Используйте виртуальные диски фиксированного размера или диски с прямым (pass-through) доступом. Для построения поддерживаемого решения Microsoft требует, чтобы все виртуальные жесткие диски Virtual Hard Disks (VHD), используемые серверами Exchange, были дисками фиксированного размера или дисками с прямым доступом (pass-through), подключенными непосредственно к тому на хост-хранилище. Диски с прямым доступом предоставляют максимальную производительность, которая рекомендуется для серверов почтовых ящиков. Диски фиксированного размера быстрее, чем динамически расширяемые диски, которые теряют в производительности при изменении размера.
- Используйте отношение 2:1 между виртуальными процессорами и физическими ядрами. Поддерживаемый виртуальный узел Exchange не должен быть перегружен гостевыми сессиями. Microsoft поддерживает решения при соотношении 2:1 между количеством виртуальных процессоров и количеством физических ядер. Иными словами, если ваша хост-машина имеет два четырехъядерных процессора (всего 8 ядер), то максимальное количество виртуальных процессоров, выделенных виртуальным системам, в любой момент времени не более 16. Если, например, каждой гостевой сессии выделяется 4 виртуальных процессора, то максимальное количество работающих гостевых систем на хост-машине — не более четырех.
Кроме этих технических спецификаций для узла виртуализации при создании виртуальной среды вам потребуется учитывать некоторые дополнительные ограничения. Microsoft поддерживает серверы Exchange на виртуальных хост-системах, на которых функционирует только программное обеспечение виртуализации, за исключением антивирусов и программ резервного копирования. Перегрузка хост-системы другими программами или серверными ролями может существенно снизить производительность гостевой системы. Кроме того, с точки зрения лицензирования Windows Server запуск на сервере Windows иных ролей, кроме роли виртуализации, требует одной дополнительной лицензии. Если же на хост-системе работает только роль виртуализации, то данная система не учитывается при определении числа лицензий Windows, используемых по программе лицензирования виртуализации корпорации Microsoft.
Не объединяйте на одной гостевой системе роли сервера почтовых ящиков, центрального транспортного сервера и сервера клиентского доступа. Сервер Exchange со всеми тремя ролями, установленными одновременно, требует больше виртуальных процессоров, чем может быть выделено для одного виртуального гостя, и, хотя это допустимо для тестирования, такая конфигурация со всеми ролями на одной гостевой системе не поддерживается в производственной среде. Используйте не менее двух виртуальных гостевых систем: одна для сервера почтовых ящиков, другая — для центрального транспорта и сервера клиентского доступа. И наконец, Microsoft не поддерживает возврат состояния сервера Exchange к снимку (snapshot), сделанному системой виртуализации, а также использование разностных или дельта-дисков.
В целом наилучшим вариантом всегда является выделение для виртуальных узлов стольких процессорных ядер и такого объема памяти, сколько позволяет бюджет. Хост-системы с несколькими многоядерными процессорами и большим объемом памяти (64 Гбайт, 128 Гбайт и более) становятся обычным явлением из-за способности программного обеспечения виртуализации использовать преимущества дополнительных ресурсов, а также из-за потребности отказоустойчивых решений в наличии дополнительных ресурсов на каждом узле для отказоустойчивых сессий. В действительности всегда имеется оптимальная точка при определении размера узлов виртуализации, которая балансирует между стоимостью различных компонентов и необходимостью иметь меньшее количество хост-систем. В общем, издержки на виртуализацию, необходимые для работы виртуальных серверов, составляют всего 5%, так что ресурсы, расходуемые при виртуализации, «стоят» преимуществ от ее использования.
Замечания о лицензировании
Настоятельно рекомендуется использовать программное обеспечение виртуализации самых последних версий. Последняя версия Hyper-V входит в состав Windows Server 2008 R2. Данная версия Hyper-V имеет гораздо более высокую производительность по сравнению с первоначальной версией и предоставляет новые возможности, такие как перевод ядра в состояние простоя Core Parking, динамический перенос виртуальных машин Live Migration, усовершенствованные операции ввода/вывода для виртуальных дисков фиксированного размера, разгрузка TCP (TCP Offload) и кадры крупных размеров (Jumbo Frames), а также поддержка процессоров с трансляцией адресов второго уровня Second-Level Address Translation (SLAT). Если вы виртуализируете Exchange на Hyper-V, обязательно рассмотрите вариант развертывания хост-системы в режиме сервера Server Core для минимизации поверхности уязвимости и используемой памяти.
Если вы управляете несколькими хост-машинами виртуализации, рекомендуется использовать соответствующее программное обеспечение для централизованного управления. Так, Microsoft предлагает для управления виртуализацией менеджер System Center Virtual Machine Manager (VMM) 2008 R2. VMM 2008 позволяет осуществлять преобразование физического сервера в виртуальный (physical-to-virtual, P2V), имеет библиотеки шаблонов серверов, а также предоставляет управление из единой консоли хост-машинами и гостевыми системами как в среде Hyper-V, так и в VMware.
Microsoft предоставляет выгодные по стоимости варианты лицензирования Windows Server, которые позволяют организациям достичь большой экономии на лицензиях Windows Server при использовании виртуализации. Существует три типа лицензирования сервера виртуализации (хост-системы).
- Редакция Windows Server Standard, которая позволяет развернуть операционную систему либо на одной физической системе (physical OS environment, POSE), либо на одной виртуальной (virtual OS environment, VOSE) для каждой лицензии на стандартную редакцию системы. Заметим, что узел виртуализации, который выделен только для решения задач виртуализации, сам по себе не расходует лицензию, даже если на нем работает полная версия Windows Server (как и в случае с Hyper-V).
- Редакция Windows Server Enterprise, которая позволяет использовать на одном узле виртуализации до четырех виртуальных систем (VOSE) одновременно. Заметим, что количество лицензий считается только для активных гостевых систем, то есть если гостевая система находится в выключенном состоянии, при подсчете используемых лицензий она не учитывается.
- Редакция Windows Server Datacenter, которая лицензируется «на процессор» для хост-системы (два четырехъядерных процессора потребуют двух лицензий), дает право на запуск неограниченного числа виртуальных серверов на хост-системе.
Эти правила лицензирования действуют не только для Microsoft Hyper-V, но и для всех систем виртуализации, участвующих в программе SVVP. Для организаций, вкладывающих значительные средства в виртуальную инфраструктуру, наиболее эффективной в отношении стоимости может оказаться покупка соответствующего количества лицензий на редакцию Datacenter, чтобы лицензировать все используемые виртуальные серверы.
Виртуализация центральных транспортных серверов и пограничных транспортных серверов
Наилучшие кандидаты для виртуализации из ролей сервера Exchange — это центральные транспортные серверы и пограничные транспортные серверы. Эти серверы обеспечивают поток сообщений между почтовыми ящиками, управление политиками и работу служб антиспама. Их легко виртуализировать, и во многих организациях это первые роли Exchange, которые подвергаются виртуализации.
В таблице 1 показаны основные ориентиры для ролей центральных транспортных серверов и пограничных транспортных серверов. Основное правило при виртуализации серверов — развертывать один центральный транспорт на каждые пять серверов почтовых ящиков и выделять 1 Гбайт памяти на каждый виртуальный процессор. Эти же ориентиры применимы и к пограничным транспортным серверам. Для типичного виртуального центрального транспортного сервера или пограничного транспортного сервера выделяются четыре виртуальных процессора и 4 Гбайт памяти в сочетании с тремя виртуальными жесткими дисками — один для операционной системы, один для транспортной базы данных и один для журналов транзакций транспортной базы данных. Максимальной производительности можно достичь, помещая транспортную базу данных и журналы транзакций транспортной базы данных на отдельные VHD, расположенные на разных жестких дисках родительской хост-системы. Если центральный транспорт или пограничный транспортный сервер с такими характеристиками должны обслуживать трафик большего объема, можно просто добавить еще серверы с такими же параметрами. Размер диска хост-системы должен быть не менее 12 Гбайт плюс общий объем памяти, выделенный гостевым системам, но лучше всего выделять больший объем, примерно 50 Гбайт, для обеспечения роста объема, занимаемого операционной системой хоста. Эти рекомендации подходят для любой виртуализированной роли сервера Exchange.
Виртуализация сервера клиентского доступа
Следующий кандидат на виртуализацию — роль сервера клиентского доступа, который обрабатывает запросы от клиентов по протоколам HTTP, HTTPS, IMAP, POP и MAPI. Эта роль стала более важной в Exchange 2010, так как все клиентские подключения передаются через уровень серверов клиентского доступа, делая их критически важными для доступа к серверам почтовых ящиков и увеличивая требования к ресурсам.
Таблица 2 содержит ориентиры для ресурсов серверов клиентского доступа. Заметим, что требования к памяти в два раза выше, чем для центральных транспортных серверов и пограничных транспортных серверов, и количество серверов клиентского доступа в расчете на один сервер почтовых ящиков также значительно больше. Тщательно планируйте количество серверов клиентского доступа, виртуальных или физических, для Exchange 2010. Типичная система для роли сервера клиентского доступа состоит из виртуального гостя с четырьмя виртуальными процессорами и 8 Гбайт оперативной памяти. Для гостевой операционной системы выделен виртуальный жесткий диск фиксированного размера объемом 50 Гбайт.
Объединение ролей центрального транспортного сервера и сервера клиентского доступа
Обычно в организациях объединяют роли центрального транспорта и сервера клиентского доступа для создания комбинированного сервера или набора серверов. Позднее для этих серверов можно настроить балансировку нагрузки с помощью программных или аппаратных средств для обеспечения высокой доступности службы клиентского доступа.
И хотя объединение двух ролей приводит к дополнительной нагрузке на серверную сессию, многие из ориентиров для процессоров или памяти, применимые для сервера клиентского доступа, применимы также и к комбинированному серверу, как показано в таблице 3. Различие имеется в отношении количества объединенных центральных транспортных серверов и серверов клиентского доступа к количеству серверов почтовых ящиков, которое увеличилось до 1:1.
Типичная виртуальная система с ролями центрального транспортного сервера и сервера клиентского доступа является виртуальным гостем с четырьмя виртуальными процессорами и 8 Гбайт памяти. Она имеет виртуальный жесткий диск фиксированного размера объемом 50 Гбайт для операционной системы и еще два виртуальных диска фиксированного размера для транспортной базы данных и ее журналов транзакций соответственно.
Виртуализация сервера почтовых ящиков
Сервер почтовых ящиков — наиболее чувствительная для виртуализации роль. Это сервер, который требует львиной доли ресурсов процессора и памяти. Физический сервер почтовых ящиков имеет те же самые ограничения на процессор, что и другие серверы (максимум 12 ядер), и те же самые виртуальные пределы (максимум 4 виртуальных процессора), однако выделение памяти становится более сложным. Уравнение, которое обычно используется при определении размера сервера почтовых ящиков, начинается с минимума в 4 Гбайт памяти и далее добавляется от 3 до 24 Мбайт памяти на каждый почтовый ящик, в зависимости от того, как много сообщений каждый почтовый ящик отправляет и получает ежедневно. Используя информацию из таблицы 4, можно приблизительно определить, какой объем памяти необходимо выделять серверу и как много почтовых ящиков могут обслуживаться каждым виртуальным процессором. Средний поток сообщений в большинстве организаций отражен в таблице 4 в строке с указанием «типичный/типичное». При определении спецификаций для вашей организации должна использоваться точная статистика по почтовому трафику.
В качестве примера, если в организации в среднем пересылается 150 сообщений по 75 Кбайт в день на каждый почтовый ящик и существует всего порядка 2000 почтовых ящиков, вы можете развернуть один сервер почтовых ящиков на всю организацию. Можно выделить один виртуальный процессор на 720 почтовых ящиков и с четырьмя виртуальными процессорами обслуживать до 2880 почтовых ящиков на одном сервере. Используя уравнение для памяти, вам потребуется выделить 22 Гбайт памяти на сервер исходя из 4 Гбайт плюс еще 18 Гбайт (9 Мбайт × 2000 почтовых ящиков). Разумеется, вы можете развернуть больше серверов для обеспечения отказоустойчивости с помощью групп доступности DAG или просто обеспечить более высокий уровень обслуживания, но тут важно понимать, что такое ограничения Microsoft и что они установлены не для проектирования системы, которая содержит больше почтовых ящиков, чем указано в таблице.
В большинстве организаций в среднем ежедневно отправляется не более 100 или 150 сообщений по 75 Кбайт на каждый почтовый ящик; однако в некоторых организациях могут быть более высокие требования к обмену сообщений. Эти организации должны принять во внимание более высокие требования к объему памяти для роли сервера почтовых ящиков и меньшее количество почтовых ящиков на один виртуальный процессор. Например, в организации с очень большим количеством почты можно рассмотреть обработку 1000 почтовых ящиков одной виртуальной гостевой системой и выделение 26 Гбайт памяти для нее.
Надо всегда помнить, что это всего лишь ориентиры. Реальная производительность может определяться типом дисков, аппаратной архитектурой и другими факторами. Некоторые организации при вычислении аппаратных требований для большей уверенности просто добавляют еще памяти или сокращают количество почтовых ящиков.
Пример виртуализированной архитектуры Exchange 2010
Существует много способов развертывания Exchange 2010 в виртуальной среде. Но одни подходы более общие, чем другие, и они отражают потребности многих организаций. Например, требование высокой доступности становится обязательным для критически важных систем обмена сообщениями в Exchange. Все три новых варианта высокой доступности в Exchange 2010 доступны для виртуальной среды, и их развертывание упрощается благодаря гибкости, предоставляемой виртуализацией.
На рисунке 1 показана малая виртуализированная среда Exchange 2010, в которой все компоненты работают на одной виртуальной хост-системе. Этот тип развертывания не предусматривает всех встроенных средств высокой доступности или восстановления после сбоев, но это самая простая для развертывания среда и она обладает преимуществами масштабирования и виртуализации. Таблица 5 содержит примерные спецификации сервера для системы такого размера. Эти спецификации подразумевают 500 почтовых ящиков на сервере и в среднем 150 отправляемых и получаемых сообщений на каждый почтовый ящик ежедневно.
На рисунке 2 изображен типичный сценарий виртуализации для Exchange 2010, который обеспечивает высокий уровень доступности, устойчивости к сбоям и масштабируемости для среды с 2000 почтовых ящиков. Среда Exchange в целом, включая контроллеры домена (DC) для доменных служб Active Directory (AD DS), развернута на трех виртуальных хост-системах: две — в основном центре обработки данных и одна — в дополнительном центре. Экземпляры групп доступности DAG всех почтовых баз данных реплицируются на все три сервера, предоставляя две резервные копии каждой базы данных, которые могут автоматически использоваться в случае сбоя сервера почтовых ящиков, управляющего активной базой данных. Объединенные центральные транспортные серверы и пограничные транспортные серверы развернуты в каждом из центров и настроены с балансировкой нагрузки в основном центре.
Все эти варианты высокой доступности и восстановления после сбоев не требуют общего хранилища SAN или решений высокой доступности хост-систем. В таблице 6 приведены ориентиры для архитектуры хост-системы и виртуальных гостевых систем, используемые в решении, показанном на рисунке 2.
Технологии виртуализации позволяют достигать высокого уровня масштабируемости и не ограничены малыми и средними организациями. Например, архитектура, изображенная на рисунке 3, позволяет поддерживать десятки тысяч почтовых ящиков, устойчивость к отказам и высокую доступность при высокой производительности, ожидаемой от Exchange. В этой модели несколько реплик DAG баз данных почтовых ящиков Exchange распределены по нескольким виртуальным гостевым системам и одному физическому серверу почтовых ящиков для целей резервного копирования. Серверная роль, которая не может быть виртуализирована, роль системы объединенных коммуникаций Unified Messaging, размещена на физических серверах, как и выделенные центральные транспортные серверы и серверы клиентского доступа. Наконец, инфраструктура управления для Exchange включает серверы System Center Mobile Device Manager (MDM) и VMM, интегрированные в данную схему.
Эти три примера иллюстрируют некоторые из возможных вариантов, доступные для виртуальной среды Exchange. Конечно, каждая среда уникальна, и специфика обусловлена потребностями бизнеса и технологий. Однако вы можете задействовать эти три архитектуры в качестве отправной точки для создания высокопроизводительной виртуализированной среды Exchange 2010.
Виртуализация серверов может предоставить значительные преимущества и помочь архитекторам систем Exchange создавать высокодоступные и отказоустойчивые среды с меньшими затратами, чем это достигается исключительно на физическом оборудовании. Кроме того, виртуальные среды эффективны за счет консолидации, оптимизации и снижения расходов, что делает их идеальными для многих организаций. При правильном подходе к архитектуре виртуализации вы можете развертывать отказоустойчивые и высокопроизводительные среды Exchange, что позволит извлечь максимальную выгоду из виртуализации в вашей организации.
Майкл Ноэль (michael@cco.com) — партнер Convergent Computing, обладатель сертификата Microsoft SharePoint MVP и автор книг о SharePoint, ISA Server и Exchange Server
Рекомендации по выделению ресурсов для роли сервера клиентского доступа
Рекомендации по максимальному количеству почтовых ящиков и памяти для роли сервера почтовых ящиков
Малая виртуальная среда Exchange 2010 на одной виртуальной хост-системе
Спецификации для развертывания малой виртуальной среды Exchange
Виртуальная среда Exchange 2010 среднего размера с высоким уровнем доступности
Спецификации для развертывания виртуальной среды Exchange среднего размера