Рекомендации по распределенным приложениям в виртуальных средах (часть 1)

Недавно я слышал, как кто-то из Microsoft говорил о некоторых причинах того, как была спроектирована архитектура Exchange Server 2013. Как вы, возможно, знаете, Exchange Server 2007 и Exchange Server 2010 поддерживали по пять различных ролей сервера. Однако, когда Microsoft создала Exchange Server 2013, они отказались от большинства этих ролей и вернулись к использованию архитектуры, которая больше похожа на ту, что есть в Exchange Server 2003. Фактически, Exchange Server 2013 использует только две разные роли сервера — роль сервера почтовых ящиков. и роль сервера клиентского доступа.

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

Хотя это конкретное обсуждение было увлекательным само по себе, оно заставило меня задуматься о более широкой теме запуска распределенных приложений на виртуальных машинах. Лучше ли распределять приложения таким образом, чтобы роли приложений размещались на отдельных виртуальных машинах, или чтобы роли были безопасно объединены в отдельные виртуальные машины, или это вообще имеет значение?

На первый взгляд это кажется спорным вопросом. Возьмем, к примеру, Exchange Server 2010. Предположим, что вы разделили различные роли сервера, и у вас есть виртуальная машина, действующая как сервер клиентского доступа, другая виртуальная машина, действующая как транспортный сервер-концентратор, и еще одна виртуальная машина, действующая как сервер почтовых ящиков. Если предположить, что все эти виртуальные машины работают на одном и том же хосте, с аппаратной точки зрения нет никакого преимущества в разделении ролей сервера. Во всяком случае, Exchange Server потребляет немного больше аппаратных ресурсов, работая в распределенном режиме, чем если бы все роли были объединены в одну виртуальную машину. Причина этого в том, что каждая виртуальная машина имеет свою собственную операционную систему, и существует определенная степень потребления ресурсов, связанная с операционной системой.

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

Стоимость лицензирования

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

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

Обычно лицензирование работает на виртуальном оборудовании так же, как и на физическом. Если вы планируете развернуть четыре экземпляра Exchange Server, вам потребуются лицензии Exchange Server. Вам также понадобятся четыре лицензии Windows Server. Если вы устанавливаете виртуальные машины поверх сервера Hyper-V с лицензией на выпуск для центра обработки данных, то требования к лицензии на операционную систему отменяются. Однако в любом случае вам необходимо приобрести необходимое количество лицензий Exchange Server. С другой стороны, если бы вы просто объединили все роли Exchange Server на одной виртуальной машине, вам потребовалась бы только одна лицензия на операционную систему и одна лицензия на Exchange Server. Требования к клиентской лицензии остаются одинаковыми в любой ситуации.

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

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

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

Вывод

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