Vsphere drs что такое
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Советы и хитрости VMware DRS
Планировщик распределенных ресурсов VMware (VMware DRS) — это система, которая позволяет автоматически сбалансировать виртуальные машины (ВМ) в кластерной среде VMware vSphere. В этой статье мы рассмотрим некоторые советы и рекомендации по планированию, настройке и использованию vSphere DRS.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Сбалансированный кластер обозначает то, что ваши хосты в кластере будут одинаково (или почти) распределены. Если ваш кластер не сбалансирован, ваши ВМ будут автоматически перенесены с помощью vMotion на хосты с минимальным использованием ресурсов. Например, если в вашей среде есть DRS, вы не будете видеть, что один хост используется на 99%, а другой на 50%. DRS заботится о балансировке ВМ с помощью vMotion.
В этой статье мы дадим вам несколько советов, которые позволят получить максимальную отдачу от VMware DRS и сделать эту технологию оправдывающей вложения.
VMware DRS не является частью vSphere Standard и входит только в версии Enterprise Plus или Platinum. Всегда возникает вопрос, стоит ли переходить на версию vSphere с DRS. Если бы у меня была возможность выбора, я бы предпочел лицензионный вариант VMware DRS.
Чтобы дать вам представление о том, что нужно, давайте начнем с основ. Для VMware vSphere Distributed Resources Scheduler (DRS) требуется следующее:
Советы и хитрости VMware DRS
Используйте однородное оборудование.
Скорость DRS и снижение использования ресурсов.
Обновитесь до последней версии vSphere. Последняя vSphere, 6.7, гораздо более эффективна, когда речь идет о скорости DRS и использовании ресурсов. Несмотря на то, что сама скорость vMotion не может быть выше, поскольку она зависит от базовой архитектуры сети и хранилища, VMware оптимизирует скорость принятия решений до того, как произойдет vMotion. Фактически, они достигли в 2-3 раза более быстрого принятия решений в vSphere 6.7. Одним из улучшений стало упрощенное начальное размещение, которое теперь не делает снимок всей среды, а просто использует непрерывный мониторинг, позволяя сохранять 1-2 секунды перед принятием каждого решения. Это особенно ценно в средах с высокой степенью затрат, где вы сможете увидеть снижение потребления ресурсов из-за улучшений DRS и уменьшенной задержки при создании VMotions для балансировки нагрузки. Также вы увидите быстрое начальное размещение ВМ.
Используйте полностью автоматический режим.
Уровень автоматизации DRS может быть установлен на ручной, частично автоматический или полностью автоматический. Какая разница? Давайте объясним:
По умолчанию, когда вы включаете DRS в кластере, уровень автоматизации, выбранный на уровне кластера, будет применён ко всем ВМ, которые находятся в этом кластере. Однако вы можете создать отдельные правила для виртуальных машин, которые необходимо разделить (или хранить вместе).
Порог миграции
Эта опция позволяет вам установить порог, который при ударе заставляет DRS срабатывать и перемещать виртуальные машины, чтобы достичь идеально сбалансированного состояния. Поскольку производительность каждой ВМ варьируется, процессор и использование памяти хоста также различаются.
Вы можете переместить ползунок порога, чтобы использовать одну из пяти настроек, от консервативных до активных. Пять параметров миграции генерируют рекомендации на основе назначенного им уровня приоритета.При перемещении ползунка вправо каждый параметр позволяет включить один из более низких уровней приоритета. Консервативный параметр генерирует только рекомендации с приоритетом один (обязательные рекомендации), следующий уровень справа генерирует рекомендации с приоритетом два и выше и т. д. до уровня активный, который генерирует рекомендации с приоритетом пять и выше (то есть все рекомендации).
Вы должны определить, насколько активно или консервативно вы хотите запустить DRS. Я обычно держу его на середине, потому что, если вы слишком активны, скорее всего, будете слишком часто перемещать свои виртуальные машины. И помните, что при каждом перемещении вы создаете нагрузку на базовую инфраструктуру, такую как хранилище или загрузка ЦП. Это связано с тем, что операции копирования во время vMotion могут насыщать сетевые ссылки, и, если у вас нет 10 Гб (или более), операции vMotion будут бесконечными.
Если вы оставите настройку слишком низкой (слишком консервативной), ваши виртуальные машины не будут достаточно двигаться, и дисбаланс вашего кластера будет расти или будет происходить чаще, без исправления.
Выключите виртуальные машины, которые вы не используете
Оставьте включенными только те ВМ, которые вам действительно нужны. Виртуальные машины с включенным питанием потребляют ресурсы памяти и некоторые ресурсы ЦП даже в режиме ожидания. Даже неиспользуемые виртуальные машины с их малым пользованием ресурсов могут повлиять на решения DRS. Вы можете получить небольшое увеличение производительности, выключив или приостановив ВМ, которые не используются.
Правила соответствия DRS.
Правила соответствия DRS могут хранить две или более ВМ на одном хосте ESXi («соответствие VM / VM»), или с другой стороны, они могут быть уверены, что они всегда находятся на разных хостах («несоответствие VM / VM»). Правила соответствия DRS также можно использовать, чтобы убедиться, что группа виртуальных машин работает только на определенных хостах ESXi («соответствие VM / Хост») или никогда не запускается на определенных хостах («несоответствие VM / Хост»)
Зачастую лучше оставить настройки соответствия без изменений. Однако в неко
Помимо настроек по умолчанию, типами настроек соответствия являются:
Финальные заметки
При понимании ваших рабочих процессов и требований, вы сможете настроить vSphere DRS, чтобы получить максимальную производительность и максимальную выгоду от вашей виртуальной инфраструктуры.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интесиве от тренера с 30 летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Distributed Resource Scheduler
Оптимизируйте управление рабочими нагрузками vSphere за счет группировки узлов VMware ESXi в кластеры ресурсов для разделения потребностей в вычислительных ресурсах разных бизнес-подразделений.
Обзор
Поддержка VMware DRS для управления рабочими нагрузками.
Разделите потребности в вычислительных ресурсах разных бизнес-подразделений за счет группировки узлов VMware ESXi в кластеры. Кластеры VMware vSphere предоставляют следующие возможности:
Возможности
Балансировка ресурсов
Распределите вычислительные ресурсы по кластерам, чтобы обеспечить оптимальную производительность узлов и виртуальных машин. VMware vSphere Distributed Resource Scheduler (DRS) — это функция, входящая в состав решения vSphere Enterprise Plus. Функция DRS предоставляет следующие возможности:
Снижение объема энергопотребления
Динамически оптимизируйте энергопотребление в кластере vSphere с помощью функции VMware vSphere Distributed Power Management (DPM), которая также входит в состав редакций vSphere Enterprise Plus и vSphere with Operation Management Enterprise Plus. В периоды сниженной нагрузки DPM переводит узлы в режим ожидания, а когда потребность в ресурсах возрастает, DPM снова включает достаточное количество узлов, чтобы обеспечить доступность сервисов. Динамическое управление энергопотреблением с помощью DPM предоставляет следующие преимущества:
5 причин использовать VMware DRS в режиме Fully Automated
5 причин использовать VMware DRS в режиме Fully Automated
Совсем недавно в Сан-Франциско прошла ежегодная конференция 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 и пока не вызвал нареканий. Мы обязательно будем следить за развитием событий и держать вас в курсе.
Технологии хранения данных VMware vSphere 6. Часть 1 – Old School
VASA – vSphere API for Storage Awareness / Набор API для отслеживания хранилищ
VASA это набор API, предоставляемый VMware и предназначенный для разработки провайдеров хранилищ (storage providers) для инфраструктуры vSphere. Storage provider-ы это программные компоненты, предоставляемые vSphere или разрабатываемые 3-ей стороной, предназначенные для интеграции (отслеживания) хранилищ (программных и аппаратных СХД) и фильтров ввода-вывода (VAIO) с инфраструктурой vSphere.
Storage provider (VASA-провайдер) нужен для того, чтобы виртуальная инфраструктура:
VASA-провайдеры сторонних разработчиков используются как сервисы отслеживания информации о данном хранилище для vSphere. Такие провайдеры требуют отдельной регистрации и установки соответствующих плагинов.
Встроенные storage provider-ы являются компонентами vSphere и не требуют регистрации. Так, например, провайдер для Virtual SAN автоматически регистрируется при её развертывании.
vSphere посредством storage provider собирает информацию о хранилищах (характеристики, статус, возможности) и сервисах данных (фильтрах VAIO) во всей инфраструктуре, данная информация становится доступной для мониторинга и принятия решений через vSphere Web Client.
Информацию, собираемую VASA-провайдерами, можно разделить на 3 категории:
К одному storage provider-у могут одновременно обращаться несколько серверов vCenter. Один vCenter может одновременно взаимодействовать с множеством storage provider-ов (несколько массивов и фильтров ввода-вывода).
VAAI — vSphere API for Array Integration / Набор API для интеграции массива
API данного типа можно разделить на 2 категории:
Storage Hardware Acceleration (VAAI для Hardware Acceleration)
Данный функционал обеспечивает интеграцию хостов ESXi и совместимых СХД, позволяет перенести выполнение отдельных операций по сопровождению ВМ и хранилища с гипервизора (хоста ESXi) на массив (СХД), благодаря чему увеличивается скорость выполнения данных операций, при этом снижается нагрузка на процессор и память хоста, а также на сеть хранения данных.
Storage Hardware Acceleration поддерживается для блочных (FC, iSCSI) и файловых (NAS) СХД. Для работы технологии необходимо, чтобы блочное устройство поддерживало стандарт T10 SCSI либо имело VAAI-плагин. Если блочный массив поддерживает стандарт T10 SCSI, то VAAI-плагин для поддержки Hardware Acceleration не нужен, все заработает напрямую. Файловые хранилища требуют наличия отдельного VAAI-плагина. Разработка VAAI-плагинов ложится на плечи производителя СХД.
В целом VAAI для Hardware Acceleration позволяют оптимизировать и переложить на массив следующие процессы:
Пояснение
VMFS является кластерной ФС (файловая система) и поддерживает параллельную работу нескольких хостов ESXi (гипервизоров) с одним LUN-ом (который под неё отформатирован). На LUN-е с VMFS может размешаться множество файлов ВМ, а также метаданные. В обычном режиме, пока не вносятся изменения в метаданные, все работает параллельно, множество хостов обращается в VMFS, никто никому не мешает, нет никаких блокировок.
Если Hardware Acceleration (VAAI) не поддерживаются блочным устройством, то для внесения изменений в метаданные на VMFS каким-либо хостом приходится использовать команду SCSI reservation, LUN при этом передается в монопольное использование данному хосту, для остальных хостов на момент внесения изменений в метаданные этот LUN становится недоступен, что может вызвать ощутимую потерю производительности.
Метаданные содержат информацию о самом разделе VMFS и о файлах ВМ. Изменения метаданных происходят в случае: включения/выключения ВМ, создания фалов ВМ (создание ВМ, клонирование, миграция, добавление диска, создание снапшота), удаление файлов (удаление ВМ или дисков ВМ), смена владельца файла ВМ, увеличение раздела VMFS, изменение размера файлов ВМ (если у ВМ «тонкие» диски или используются снапшоты – это происходит постоянно).
Hardware Acceleration для VMFS не отработает и нагрузка ляжет на хост если:
Multipathing Storage APIs — Pluggable Storage Architecture (PSA) / Набор API для мультипафинга
Для управления мультипафингом гипервизор ESXi использует отдельный набор Storage APIs называемый Pluggable Storage Architecture (PSA). PSA – открытый модульный каркас (framework), координирующий одновременную работу множества плагинов мультипафинга (multipathing plug-ins – MPPs). PSA позволяет производителям разрабатывать (интегрировать) собственные технологии мультипафинга (балансировки нагрузки и восстановления после сбоя) для подключения своих СХД к vSphere.
PSA выполняет следующие задачи:
NMP в свою очередь также является расширяемым модулем, управляющим двумя наборами плагинов: Storage Array Type Plug-Ins (SATPs), and Path Selection Plug-Ins (PSPs). SATPs и PSPs могут быть встроенными плагинами VMware или разработками сторонних производителей. При необходимости разработчик СХД может создать собственный MPP для использования в дополнение или вместо NMP.
SATP отвечает за восстановление пути посте сбоя (failover): мониторинг состояния физических путей, информирование об изменении их состояния, переключение со сбойного пути на рабочий. NMP предоставляет SATPs для всех возможных моделей массивов, поддерживаемых vSphere, и осуществляет выбор подходящего SATP.
PSP отвечает за выбор физического пути передачи данных. NMP предлагает 3 встроенных варианта PSP: Most Recently Used, Fixed, Round Robin. Основываясь на выбранном для массива SATP, модуль NMP делает выбор варианта PSP по умолчанию. При этом vSphere Web Client дает возможность выбрать вариант PSP вручную.
Принцип работы вариантов PSP: