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

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

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

Совет № 1. Не считайте себя умнее DRS

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

Я убедил коллегу перевести уровень автоматизации с позиции manual в позицию fully automated, а также настроить порог миграции на применение рекомендаций приоритета 1, приоритета 2 и приоритета 3, как показано на экране 1. Эта настройка, к которой можно обратиться через узел VMware DRS экрана свойств кластера, переводит продукт в режим, занимающий промежуточное положение между режимами conservative и aggressive.

 

Экран 1. Порог миграции DRS в режиме fully automated

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

Три уровня автоматизации DRS определяют степень контроля перемещения виртуальных машин, предоставляемую службам DRS. Режим manual не предусматривает выполнения каких-либо действий; планировщик ограничивается предложением рекомендаций. Режим partially automated вступает в действие лишь тогда, когда виртуальные машины предварительно запущены. В этих двух случаях система дает рекомендации и ждет действий со стороны администратора. И только режим fully automated обеспечивает автоматическое перемещение виртуальных машин в соответствии с расчетами службы мониторинга. Представители VMware, как и большинство экспертов, полагают, что режим DRS fully automated — наилучший выбор практически для любого кластера.

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

Совет № 2. Изучите применяемые в DRS формулы восстановления баланса

Следовать совету № 1 — не значит слепо, без каких-либо проверок, доверяться планировщику DRS. Перейдя в режим fully automated, вы сможете применять реализованную в DRS математическую модель уровня кластера для определения баланса кластера. Разобраться в этой модели несложно, а когда вы освоите ее, то сможете определить оптимальную настройку порога миграции. В зависимости от ваших потребностей эта настройка может оказаться чуть ближе к консервативному сегменту спектра или к более агрессивному сегменту.

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

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

Теперь вообразите, что произойдет, когда коэффициент использования процессора и памяти на одном хосте станет заметно выше, чем на других. Равновесие будет нарушено, и «стол начнет заваливаться на бок». Чтобы снять проблему и восстановить равновесие, планировщик DRS должен будет перевести одну или несколько виртуальных машин на новый хост.

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

 

В данной формуле значение VM Entitlements включает в себя все квоты, зарезервированные для процессора либо памяти, или ограничения, налагаемые на виртуальные машины. Учитываются также спрос на ресурсы процессора и размер рабочего набора памяти; оба показателя являются динамическими. Чтобы получить значение Host Capacity, можно вычислить общую сумму приходящихся на данный хост ресурсов процессора и памяти и вычесть из полученного результата накладные расходы на VMkernel, накладные расходы на консоль службы Service Console, а также 6% дополнительного резервирования. Если на данном кластере активированы средства HA и Admission Control, вы можете также вычесть из общей суммы объем дополнительного резервирования, необходимого для обеспечения показателя высокой доступности.

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

Упомянутые значения вычисляются планировщиком DRS. На экране 2 представлен снимок, отображающий вкладку Summary демонстрационного кластера. В данном кластере целевое среднеквадратическое отклонение для хоста определяется как равное или меньшее 0,2. Это значение определяет наибольшую степень дисбаланса, допускаемую кластером. При более высоких значениях система будет принимать меры для восстановления равновесия. На экране 2 мы также видим, что в данный момент среднеквадратическое отклонение для данного кластера составляет всего 0,074, что меньше показателя 0,2. Отсюда следует, что баланс кластера не нарушен. Необходимости в перемещении виртуальных машин нет.

 

Экран 2. Целевое и текущее среднеквадратическое отклонение нагрузки хоста

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

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

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

Уровень приоритета любого потенциального действия рассчитывается по следующей формуле:

 

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

В этой ситуации большое значение приобретает то, каким образом мы определяем параметр порога миграции (экран 1). В рассмотренном примере для порога миграции была выбрана настройка middle, которая предписывает планировщику DRS автоматически применять рекомендации для любого из приоритетов 1, 2 или 3, игнорируя при этом все остальные рекомендации. Предлагаемые перемещения, оказывающие менее значительный эффект на восстановление баланса кластера, — в данном случае перемещения с приоритетами 4 или 5 — игнорируются.

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

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

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

Совет № 3. Используйте ограничения с осторожностью

vSphere обеспечивает широкие (или даже слишком широкие) возможности для ограничения расходования ресурсов. Администратор может применять правила, в соответствии с которыми тот или иной набор виртуальных машин должен размещаться на одном и том же хосте, или правила, предписывающие располагать их на разных хостах. Если вы работаете с версией vSphere 4.1, можете применять правила Virtual Machines to Hosts; эти правила определяют группы виртуальных машин, которые должны, не должны, по возможности должны или по возможности не должны выполняться на группах хостов.

Правила Virtual Machines to Hosts дают возможность применять бизнес-логику к используемым планировщиком DRS формулам восстановления баланса. Сразу же вспоминается несколько типичных ситуаций — например, если в центре обработки данных используется два виртуализованных контроллера домена Active Directory (AD), выполнение обоих серверов на одном и том же хосте ESX, по-видимому, нецелесообразно. Ведь в случае потери хоста ESX прекратится функционирование доменных служб. Применив правило Separate Virtual Machines, что можно сделать из узла Rule в окне свойств кластера (экран 3), вы обеспечите разделение виртуальных машин — пусть даже после этого нагрузки в кластере разбалансируются. Подобным же образом (хотя и для достижения других целей) вы можете применить правило Keep Virtual Machines Together; это правило стоит использовать в ситуациях, когда виртуальные машины той или иной группы взаимодействуют друг с другом в процессе обмена данными или по соображениям безопасности либо в рамках выполнения установленных законом требований.

 

Экран 3. Применение правил для виртуальных машин

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

 

Экран 4. Выделение ресурсов процессора для виртуальных машин

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

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

Чтобы понять логику этого утверждения, нужно представить себе, каким образом ограничения на ресурсы влияют на функционирование DRS. Вы помните, что главная задача DRS — балансировка нагрузки кластера. Расчет балансировки нагрузки начинается с анализа квот на ресурсы каждой виртуальной машины, куда входят все статически заданные зарезервированные ресурсы или предельные значения. Определение этих зарезервированных ресурсов и предельных значений там, где без них можно обойтись, излишне усложняет применяемые планировщиком DRS формулы восстановления баланса (из совета № 2). Зарезервированные ресурсы и предельные значения позволяют сокращать общее число возможных перемещений, исключая те из них, которые нарушили бы ограничения по ресурсам. Кроме того, зарезервированные ресурсы и предельные значения могут снижать эффективность возможных оставшихся перемещений, поскольку соответствующему кластеру придется восстанавливать свой баланс на основе ограничений по ресурсам, которые не являются действительными с оперативной точки зрения.

Совет № 4. Хостов в кластере не должно быть ни слишком много, ни слишком мало

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

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

Проблема возникает, если столов у вас слишком мало либо слишком много (или, возвращаясь к нашему случаю, слишком много либо слишком мало серверов ESX). За двумя достаточно большими столами могут разместиться все участники торжества. А что если вдруг окажется, что все члены одного внушительного семейства не смогут расположиться в непосредственной близости от своих родственников? Вам придется поломать голову над тем, как расставить стулья надлежащим образом при наличии всего лишь двух столов со множеством гостей.

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

Но если мы пойдем по пути добавления все новых и новых хостов, это может завести нас слишком далеко. Когда хостов становится слишком много, возникает проблема совсем другого свойства. Кластер DRS на платформе vSphere 4.1 может взаимодействовать с 32 хостами и с 3000 виртуальных машин. И чем больше хостов, а также виртуальных машин входит в состав кластера, тем больше моделей должен построить DRS с целью определения модели, наиболее эффективно воздействующей на кластер. «Прогоны» DRS осуществляются с интервалом в 5 минут, так что соответствующие расчеты должны выполняться быстро — до начала следующего «прогона». Поэтому более эффективным решением представляется распределение хостов и виртуальных машин по нескольким кластерам.

В своей книге «VMware vSphere 4.1 HA and DRS Technical Deepdive» (издательство CreateSpace, 2010 г.) авторы Дункан Эппинг и Френк Деннеман утверждают, что оптимальное число хостов в расчете на кластер в настоящее время составляет от 16 до 24. По их словам, такое число обеспечивает достаточное количество вариантов для балансировки нагрузки виртуальных машин по различным хостам внутри кластера, не создавая излишнего числа DRS-потоков на платформе vCenter.

Совет № 5. Крупные виртуальные машины ограничивают свободу движений

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

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

Все не так просто, как кажется

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

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

Грег Шилдс (virtualgreg@concentratedtech.com) — соучредитель и технический руководитель в компании Concentrated Technology, специализирующейся на ИТ-аналитике и стратегическом консалтинге