Совсем недавно в Сан-Франциско прошла ежегодная конференция VMworld 2019, на которой, в числе прочего, была анонсирована версия планировщика ресурсов VMware Distributed Resource Scheduler (DRS) 2.0. Поскольку вторая версия инструмента содержит несколько фундаментальных нововведений, мы решили выпустить подробную обзорную статью о VMware DRS и рассказать о принципах его работы, которые могут быть неизвестны многим читателям.
Но для начала повторим основную теорию.
Как работает VMware DRS
VMware DRS (Distributed Resource Scheduler)
используется для балансировки рабочей нагрузки в виртуальной среде. Задача этого механизма — определить оптимальный хост для миграции функционирующей виртуальной машины или запуска новой. Основная цель DRS — выровнять нагрузку на хостах, находящихся внутри DRS-кластера, так, чтобы виртуальные машины и их приложения всегда получали вычислительные ресурсы и работали с максимальной эффективностью. Все виртуальные машины обеспечиваются ресурсами вскоре после включения, а ресурсы в рамках кластера утилизируются равномерно. При использовании режима fully automated процесс балансировки происходит автоматически и может регулироваться несколькими правилами, задаваемыми администратором. К работе с правилами мы еще вернемся чуть ниже. Время от времени рабочие нагрузки виртуальных машин могут меняться, что может вызвать в кластере «перекос» и, соответственно, ухудшить производительность. DRS решает эти проблемы: раз в 5 минут определяет сбалансированность кластера и в случае дисбаланса производит необходимые миграции или дает рекомендации относительно необходимых перемещений в зависимости от выбранного уровня автоматизации. Далее мы подробнее рассмотрим, как именно DRS определяет, чего не хватает виртуальным машинам для «полного счастья».
Размещение виртуальных машин
Как только в кластере DRS запускается новая виртуальная машина, DRS с помощью специального алгоритма определяет наиболее подходящий для нее ESXi-хост. Это решение принимается на основании ожидаемых изменений в распределении ресурсов на хосте. Вновь запущенная машина должна на старте получить все требуемые ресурсы. К примеру, чтобы определить необходимое количество RAM для машины, применяется следующая формула:
Требуемое значение RAM для ВМ = Function (Active memory used, Swapped, Shared) + 25% (RAM, потребляемая в простое)
Хорошо сбалансированным считается кластер, в котором ресурсы хоста используются более-менее равномерно. Для принятия решений о распределении нагрузки DRS использует метрику сбалансированности кластера. Показатель баланса рассчитывается из стандартного отклонения данных об использовании ресурсов из хостов в кластере. Раз в 5 минут запускается процесс оценки дисбаланса. Если необходимо изменить расположение виртуальных машин, DRS использует vMotion для их миграции с одного ESXi-хоста на другой.
Уровни автоматизации DRS
Во время первоначального размещения и балансировки нагрузки DRS генерирует рекомендации по размещению и миграции машин. Этот процесс можно полностью автоматизировать, выбрав режим Fully automated, или превратить в ручной труд администратора. Всего же DRS имеет три уровня автоматизации:
Уровни агрессивности DRS (миграционный порог)
Изменение агрессивности DRS позволяет установить уровень допустимого дисбаланса в кластере. Всего доступно 5 уровней агрессии. Минимальный (консервативный) допускает больший дисбаланс, максимальный (агрессивный) инициирует больше миграций, но позволяет добиться наиболее равномерного распределения нагрузки. Средний (3) уровень агрессивности, установленный по умолчанию, в большинстве случаев является оптимальным. На минимальном уровне (1) DRS будет применять только те рекомендации, которые необходимы для соблюдения жестких ограничений — правил привязки или развязки (affinity/antiaffinity rules), а также сможет эвакуировать виртуальные машины с хоста, входящего в режимы обслуживания или ожидания.
Индивидуальные настройки и правила
Несмотря на всю внешнюю простоту работы утилиты и малое количество настроек, имеющиеся опции позволяют гибко регулировать распределение виртуальных машин по хостам или группам. В идеале расположение каждой машины в кластере контролируется DRS (режим Fully automated). Тем не менее иногда вам может понадобиться запускать некоторые ВМ только на определенных хостах или держать группу ВМ всегда вместе. Чаще всего это требуется для соблюдений правил лицензирования, когда виртуальные машины должны работать исключительно на определенных физических серверах, или в тех случаях, когда следует жестко определить совместное или раздельное нахождение виртуальных машин на хостах. Что же касается возможных ошибок — у DRS не так много настроек, это простой инструмент, работа которого регулируется режимами, уровнем агрессивности и набором правил. При этом глобальных настроек нет, ошибки могут возникать именно в резервации ресурсов для машин. Ошибочная резервация ресурсов может привести к проблемам при миграции: например, если выделить для машины оперативной памяти больше, чем в принципе бывает свободно на хосте, DRS не сможет мигрировать эту машину и сбалансировать нагрузку.
5 причин установить режим Fully Automated
Можно выделить только один сценарий, при котором необходимо использовать частично автоматизированный (Partially automated) или ручной (Manual) режим работы DRS вместо полной автоматизации. Это рационально, если в кластере существует некий «проблемный» хост и вы не хотите, чтобы виртуальные машины могли переезжать на него. В этом случае DRS будет отслеживать состояние виртуальных машин и хостов и выдавать рекомендации по миграции, которые можно выполнять вручную. Во всех остальных случаях оптимальным будет режим Fully Automated. Давайте рассмотрим 5 ключевых преимуществ его использования.
Миграция на основе множества факторов и актуальных данных
Ни один, даже самый опытный администратор, физически не сможет отслеживать работу тысяч виртуальных машин и хостов, постоянно просчитывать актуальную и потенциальную нагрузку и производить миграцию с той же скоростью, что и DRS. DRS имеет постоянный доступ к информации о загруженности хостов внутри кластера, о ресурсах, потребляемых виртуальными машинами, и их резервациях. Так что сравнивать производительность DRS с производительностью человека вряд ли имеет смысл. Это всё равно, что соревноваться с микропроцессором в скорости счета.
Гибкая настройка правил
Если в рамках виртуальной инфраструктуры требуется соблюдение определенных правил относительно совместного или, наоборот, несовместного нахождения виртуальных машин, нет необходимости использовать ручной или полуавтоматизированный режим работы VMware DRS. Гибкие опции позволяют соблюсти необходимые требования и в полностью автоматическом режиме.
Повышение утилизации ресурсов
Балансировщик следит за ровной нагрузкой на всех хостах, снижая простои и повышая утилизацию имеющихся ресурсов. Грамотное взаимодействие с VMware DRS позволит вам эффективно использовать имеющиеся мощности и задумываться о масштабировании только тогда, когда появится реальная необходимость.
Защита от ошибок клиентов
Если вы продаете инфраструктуру как решение, а ваши клиенты самостоятельно распределяют нагрузки, размеры виртуальных машин и другие параметры, вы оказываетесь в ситуации, когда уже невозможно отследить взаимодействие клиента с виртуальной инфраструктурой и его возможные ошибки. Например, клиент может создать машину и выделить для нее чрезмерное количество оперативной памяти. DRS отслеживает подобные моменты и балансирует нагрузку.
Делегирование задач миграции
Использование DRS в автоматическом режиме снимает с администратора задачи по миграции машин в целях балансировки нагрузки. Благодаря этому специалист может посвятить свое время более важным задачам.
Когда можно справиться и без DRS
Ручная балансировка возможна, но исключительно в рамках небольшой и ненагруженной инфраструктуры. Если ВМ при максимальной нагрузке загружают хост на 50%, смысла в DRS нет. Машины чувствуют себя комфортно, в миграции для балансировки просто нет необходимости. Также DRS не обязателен, если вы можете перевести ВМ на другой хост вручную — например, при технических работах на этом хосте. Если вы четко знаете, сколько машины будут потреблять и до какого объема они могут вырасти, DRS не пригодится.
Что появится в DRS 2.0
Теперь, когда стали более-менее понятны задачи, поставленные перед DRS, и способы их решения, пришло время рассмотреть новую версию DRS, анонсированную на VMworld 2019. В первую очередь стоит сказать об изменении самой парадигмы: ранее DRS концентрировался на балансировке ресурсов в рамках кластера. В DRS 2.0 основным элементом дата-центра станет виртуальная машина, которая может мигрировать как между кластерами, так и между разными физическими дата-центрами. Также в новой версии введена новая модель cost-benefit model (затраты — преимущества). Она расширяет понятие «счастья ВМ» и является сложной метрикой, сформированной из нескольких основных показателей виртуальных машин. Среди них: Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Новая метрика VM Happiness фактически является основным KPI, к которому будет стремиться DRS при миграции машин. Еще одно значительное изменение коснулось времени срабатывания: DRS 2.0 активируется 1 раз в минуту вместо 1 раза в 5 минут. Это нововведение вытекает из предыдущего пункта: если ранее для создания рекомендаций DRS требовалось создавать снапшоты кластера, то теперь есть показатель VM Happiness. Помимо этого, пользователи получат возможность устанавливать интервал опроса «счастья ВМ». В DRS 2.0 также появилась возможность производить сетевую балансировку нагрузки при перемещении машин. Теперь это полноценная метрика, которая позволит DRS принимать решения при балансировке.
Другие изменения коснулись механизма установки пороговых значений при миграции. Пока не известно, когда DRS 2.0 станет доступен для всех, однако известно, что он уже почти год работает в облаке VMware Cloud on AWS и пока не вызвал нареканий. Мы обязательно будем следить за развитием событий и держать вас в курсе.
