Консолидация серверов

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

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

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

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

Варианты консолидации

Варианты консолидации могут быть определены в контексте трех основных подходов.

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

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

Интеграция данных и приложений. Подобная операция предполагает консолидацию данных из самых разнообразных источников на одном сервере и в одной системе хранения, а также установку однородных приложений на одном консолидированном сервере (таком, как Web-сервер). Потенциальная экономия очевидна, как и в предыдущих случаях, а риски снижения производительности, связанные с повышенными нагрузками на аппаратные и программные компоненты, высоки. На рассматриваемом уровне консолидации эффективность усилий по интеграции приложений и данных может в значительной степени зависеть от ресурсов, связанных с тем или иным приложением — таких, как средства блокировки и пулы сетевых соединений. Блокировка дает клиенту возможность монопольного доступа к приложению или «ресурсу» данных. Создание пулов сетевых соединений представляет один из методов совместного использования ресурсов серверов [1].

Общие шаги, позволяющие описать методологию консолидации, таковы.

• Определить бизнес-цели (снижение издержек, гарантированный уровень обслуживания, согласованное управление и т.п.).
• Зафиксировать базовый уровень производительности сети в ее нынешнем виде, указав при этом параметры, характеризующие текущую конфигурацию.
• Определить возможности консолидации.
• Оценить эффективность «кандидатов на объединение» с точки зрения потребностей бизнеса.
• Составить план необходимых изменений в инфраструктуре и в программных средствах; реализовать эти изменения.

При реализации проектов консолидации полезно использовать методологию пошаговых уточнений.

Пошаговые уточнения

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

Успех моделирования производительности в решающей степени зависит от двух факторов.

• Необходимо сосредоточить усилия на ключевых вопросах производительности и на важнейших бизнес-целях (эффективность).
• Уровень детализации должен быть минимальным; следует указывать лишь те детали, которые необходимы для ответа на поставленные вопросы (действенность).

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

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

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

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

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

Рис. 1. Уровень детализации, необходимый для создания модели производительности

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

Применение пошаговых уточнений при анализе перспектив консолидации

Вне зависимости от избранного уровня детализации выполнение анализа предполагает сбор информации.

• Приложения. Выявляют представительные приложения, транзакции и потоки работ.
• Среда выполнения. Анализ в этой области предполагает определение серверов, на которых будет выполняться рассматриваемое приложение. Кроме того, следует определиться с сетевой топологией.
• Рабочая нагрузка. Этот показатель описывает объем запросов к представительному приложению и закономерности в его использовании.
• Уровень использования ресурсов. Эта характеристика включает использование ресурсов представительными транзакциями, процессами, серверами и сетевыми сегментами, которые активно участвуют в обработке запросов к приложениям.

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

Централизация

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

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

Физическое объединение

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

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

Интеграция данных и приложений

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

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

Пример

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

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

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

В сфере масштабируемости программ и физической консолидации имели значение ответы на следующие вопросы.

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

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

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

Проект по моделированию производительности реализовывался в виде серии шагов в соответствии с определенной методологией.

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

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

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

После создания, калибровки и проверки правильности модели производительности она используется для получения ответов на поставленные выше вопросы, касающиеся производительности системы.

Рис. 2. Существующая топология среды

На рис. 2 показана топология ИТ-инфраструктуры в модели производительности; при ее построении использовался популярный инструментарий создания симуляционных моделей. В модели представлены все серверы, пользователи, сетевые компоненты и приложения.

Рис. 3. Базовый уровень существующей среды

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

Перемещение серверов и приложений

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

Рис. 4. Перемещение приложения

Приложение и связанные с ним серверы перемещалось как единая группа, в ходе одной операции. В рамках модели производительности перемещение приложения (рис. 4) осуществляется без затруднений. Задав сетевые соединения с локальной сетью главного офиса, можно активизировать модель и приступить к оценке результатов. Результаты свидетельствуют об увеличении времени отклика для одного перемещенного приложения. Нагрузка на серверы, полоса пропускания сети и время отклика всех других приложений остаются в норме. Обычная реакция ИТ-менеджера в этом случае состояла бы в увеличении полосы пропускания сети, что обошлось бы дорого и в данном случае не обеспечило бы снижения времени отклика. Дело в том, что профиль приложения выявил излишние обращения к базам данных за обновлениями. Когда мы скорректировали модель и вновь запустили ее, оказалось, что подстройка приложения обеспечивает сокращение времени отклика без дополнительных вложений в сеть. Следовательно, перемещать данное приложение можно без опасений: эта операция не повлечет за собой отрицательных последствий.

Консолидация серверов

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

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

Рис. 5. Результаты исполнения модели после консолидации серверов

Исследование конфигурации данного сервера показало, что установка дополнительного процессора может повысить его производительность. После его «установки» мы вновь запустили модель. На рис. 5 представлены результаты этого прогона модели. Теперь сервер не перегружен, а значит, реорганизация не привела к созданию в инфраструктуре новых слабых звеньев.

***

В числе выгод от применения моделирования перед осуществлением консолидации отметим:

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

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

Литература

Эйми Спеллман (services@hyperformix.com) — руководитель направления проблем производительности компании HyPerformix. Карен Эриксон — руководитель направления проблем консолидации серверов компании HyPerformix. Джим Рейнолдс — консультант компании HyPerformix.

Amy Spellmann, Karen Erickson, Jim Reynolds, Server Consolidation Using Performance Modeling. IT Professional, September-October 2003. IEEE Computer Society, 2003. All rights reserved. Translated with permission.