Концептуальное руководство по vSphere Distributed Resources Scheduler (часть 1)

Введение

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

Хотя в этой статье не будет обсуждаться облако, важно отметить, что новые функции как в vSphere, так и в Hyper-V позволяют организациям беспрепятственно переносить текущие рабочие нагрузки как между гипервизорами, так и с локального оборудования на облачные службы, например как облачные сервисы Windows Azure от Microsoft и гибридные облачные сервисы VMware vSphere.

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

DRS, доступный в редакциях vSphere Enterprise и Enterprise Plus, предоставляет ряд услуг для администраторов:

• Начальное размещение виртуальной машины. Когда администратор создает новую виртуальную машину, DRS сканирует кластер, чтобы определить наиболее подходящее расположение для новых виртуальных машин.
• Бесшовное обслуживание. Позволяет администратору эвакуировать все виртуальные машины с хоста, чтобы можно было выполнить техническое обслуживание.
• Постоянное управление ресурсами. В зависимости от уровня чувствительности, включенного администратором, по мере появления новых возможностей производительности DRS может использовать эти возможности, автоматически перемещая рабочие нагрузки.
• Балансировки нагрузки. Гарантирует, что все хост-серверы максимально сбалансированы. При этом учитывается потребность в накладных расходах ресурсов, которые будут использоваться в случае сбоя.
• Соблюдение ограничений. Администраторы могут создавать ограничения, называемые правилами сходства и анти-соответствия, которые ограничивают возможности DRS.

Требования ЗВС

Как вы понимаете, такая услуга, как DRS, имеет ряд требований:

• Прежде всего, должно быть какое-то общее хранилище, такое как SAN или NAS, используемое хостами, участвующими в кластере DRS.
• Убедитесь, что все тома VMFS доступны для всех хостов в кластере и что в томах VMFS достаточно места для хранения необходимых виртуальных машин.

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

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

Самый простой способ обеспечить постоянную совместимость процессоров в кластере — включить Enhanced vMotion Compatibility (EVC) для этого кластера. EVC использует подход «наименьшего общего знаменателя» к совместимости. EVC идентифицирует семейство процессоров, которое поддерживается всеми процессорами в кластере, а для более новых процессоров или процессоров с дополнительными функциями EVC маскирует эти функции от использования, чтобы можно было переносить рабочие нагрузки между всеми процессорами. При использовании этого метода все процессоры в кластере совместимы для целей DRS.

Объяснение аффинити и анти-аффинити

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

Правила сходства — ВМ/ВМ

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

Эти виды потребностей удовлетворяются путем создания правил подобия.

Правила сходства — Хост/ВМ

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

Правила анти-аффинити — ВМ/ВМ

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

Уровни автоматизации vSphere DRS

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

Руководство

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

Частично автоматизировано

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

Полностью автоматизирован

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

Резюме

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