Moab workload management engine

Moab способен рассматривать почти все измеримые сущности, которые представлены в ЦОДе, в качестве ресурсов, от которых Moab может получать данные, и на основании которых, в свою очередь, может принимать решения по планированию этих ресурсов для пользовательских сервисов:

Приведенная выше иллюстрация описывает базовую тре хуровневую архитектуру Moab:

• На верхнем уровне «движок» Moab реализует абстрактные алгоритмы принятия решения по планированию бстрактных ресурсов, без привязки к конкретным видам ресурсов.
• На нижнем уровне расположены конкретные ресурсы ЦОДа.
• Среднии , промежуточныи уровень представлен тонкои прослои кои между Moab и реальными ресурсами. Эта прослои ка составлена из так называемых ресурсных менеджеров, Resource Managers (RM). Ресурсные менеджеры реализуют интерфеи с между Moab и каждым видом ресурса. На практике, ресурсные менеджеры, как правило, представляют собои тривиальные скрипты.

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

К ресурсам Moab, очевидно, относятся процессоры, память, диски. Однако, в равнои мере ресурсами Moab, которые принимаются во внимание при обеспечении пользовательских сервисов, могут быть

• Менее очевидные характеристики серверных платформ, такие как относительный уровень загруженности в течение заданного отчетного периода, или усредненный исходящий трафик на заданном сетевом интерфеи се.
• Фабрики сетевых устроиств.
• Сетевые хранилища.
• Источники бесперебои ного питания (UPS).
• Управляемые модули распределения питания (PDU).
• Внешние системы мониторинга ЦОДа, такие, как Ganglia или Nagios.
• Внешние программные системы инвентаризации ПО.
• Внешние программные системы управления серверами, как правило, «вендорские» решения, поставляемые вместе с аппаратными платформами.
• Ленточные системы резервного копирования.
• Системы охлаждения, в том числе датчики влажности и температуры в ЦОДе.
• Фермы различных гипервизоров, таких, как KVM и VMware.

Топологии объединения ЦОДов под управлением Moab

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

• Peer-to-Peer.

Есть ровно два ЦОДа, каждыи управляется своим экземпляром Moab. По мере заполнения ресурсов «своего» ЦОДа, Moab этого ЦОДа передает новые запросы на обработку в Moab другого ЦОДа. Также возможна миграция сервисов между ЦОДами и по другим политикам, связанным не только лишь с недостатком локальных ресурсов. Общий смысл топологии Peer-to-Peer заключается в наличии двух равноправных ЦОДов, которые обмениваются сервисами.

• Source Destination Topology.

Есть множество ЦОДов, каждыи управляется своим экземпляром Moab. Над всеми ЦОДами есть еще один, центральныи экземпляр Moab, которыи управляет распределением ресурсов между ЦОДами. Суть этои топологии в том, что она, в отличие от предыдущеи , позволяет реализовывать сколь угодно сложные политики распределения ресурсов между удаленными ЦОДами, в общем случае не равноправными.

• Master-Slave.

Есть один ЦОД, управляемыи единственныи экземпляром Moab. Однако, под управлением Moab находится множество разнородных ресурсов – настолько разнородных, что пул каждого ресурса можно считать отдельнои площадкои . Так, примером Master-Slave, скорее всего, будет ЦОД, в котором Moab управляет пулом серверов x86, IBM Power, IBM System z, HP Integrity Superdome, SGI Altix, Cray и Oracle. Несмотря на то, что Moab в принципе способен переносить сервисы между разными пулами ресурсов, в данном случае перенос сервиса между пулами платформ разного типа едва ли имеет смысл, поскольку каждому виду платформ, скорее всего, соответствует своя специфическая нагрузка. В этом и заключается смысл топологии Master-Slave: ровно один экземпляр Moab управляет множеством логических площадок, каждая из которых образована пулом специфического ресурса.

Экономический обзор применения решений на базе Moab

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

Снижение капитальных расходов (CapEx) достигается по следующим направлениям:

• Уменьшение первоначального бюджета на вычислительную инфраструктуру ЦОДа. Это свои ство продуктов Adaptive Computing иногда называют принципом `Do More With Less`. На практике оно означает уменьшение расчетного количества серверов, которое требуется закупить для обеспечения заданного уровня сервиса в ЦОДе. Требуемое количество серверов снижается за счет повышения эффективности использования серверов. Именно, применение продуктов Adaptive Computing позволяет повысить устоявшийся уровень загрузки ресурсов (sustained utilization) с 50-60% до 95% и выше, нередко до устоявшегося уровня, близкого к 100%.
• Консолидация IT-инфраструктуры в ЦОДе с возможностью удаленного доступа.
• Уменьшение периодических бюджетов на расширение ЦОДа, которое достигается тем же способом: снижение числа серверов, требуемых для предоставления заданного уровня сервиса.