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

Введение

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

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

Простое устранение неполадок

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

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

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

Снижение затрат на поддержку

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

Во-первых, дополнительные расходы на лицензирование могут быть не такими высокими, как вы ожидаете. Например, если вы развернете Hyper-V поверх Windows Server Data Center Edition, вы можете иметь неограниченное количество виртуальных машин, работающих на этом сервере, при условии, что каждая виртуальная машина работает под управлением той же операционной системы, что и хост.. Таким образом, вы можете сэкономить довольно много денег, поскольку вам не требуется лицензировать операционную систему каждой виртуальной машины.

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

Лучшая безопасность

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

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

Детальный контроль ресурсов

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

Контроль ресурсов сводится к предсказуемости рабочей нагрузки. Для линейки бизнес-приложений линейная рабочая нагрузка встречается редко. Вместо этого в течение дня наблюдаются всплески производительности. В этом случае требования к оборудованию могут быть определены как диапазон, а не как абсолютное значение. Например, приложение idol может потреблять 2 ГБ памяти, тогда как то же самое приложение может потреблять 3 ГБ памяти в периоды интенсивного использования.

Теперь давайте вернемся к моему предыдущему примеру, в котором конкретное приложение состояло из шести отдельных компонентов. Если предположить, что все шесть компонентов можно развернуть по отдельности, то для каждого компонента будет свой диапазон производительности. Каждый компонент будет иметь низкое значение и высокое значение для таких вещей, как потребление памяти, использование ЦП и дисковый ввод-вывод.

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

Масштабируемость

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

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

Вывод

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