Кластер DRS. DPM

Живая миграция  ВМ – это полезная  штука. Она позволяет мигрировать ВМ между серверами для:

Q  балансировки нагрузки  между ними;

Q  освобождения сервера, когда нужно его перезагрузить. Это пригодится при установке обновлений,  аппаратном  обслуживании.

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

Зачем нужен DRS:

Q  для балансировки нагрузки  (по процессору и памяти) между серверами;

Q  для автоматического vMotion виртуальных машин с сервера в режиме обслуживания (maintenance mode). Этим режимом администратор или VMware Update Manager помечает сервер, который надо освободить от виртуальных машин перед операциями обслуживания.

Для решения этих задач DRS умеет осуществлять всего две вещи:

Q  запускать  vMotion для виртуальных машин и выбирать, откуда, куда и какую ВМ лучше мигрировать;

Q  при включении  ВМ выбирать  сервер, на котором  она включится (это называется Initial  Placement).

Для создания DRS-кластера необходимо создать объект «Cluster» в иерархии  vCenter.  В контекстном меню Datacenter выберите Add new Cluster, укажите имя создаваемого кластера и поставьте флажок DRS (не имеет значения, стоит ли флажок HA). Нажмите ОК.

Итак, кластер как объект vCenter вы создали. Осталось  два шага:

1.    Настроить DRS-кластер.

2.    Добавить в него серверы ESX(i).

Впрочем, включить DRS можно и для уже существующего  кластера.

Если для кластера  активирован DRS, то вам доступны  группы настроек,  показанные на рис. 6.60.

По порядку.

VMware DRS. Здесь мы можем указать базовую настройку  – уровень автоматизации. Напомню, что DRS делает всего две вещи – инициирует vMotion и выбирает, где включить ВМ. Эти настройки указывают, что из этого следует делать автоматически, а что лишь предлагать для одобрения администратору. Вариантов три:

Рис. 6.60. Настройки кластера DRS

Q  Manual (ручной) – и выбор, где включить,  и vMotion будет лишь предлагаться;

Q  Partially automated (полуавтомат) – выбор, где включить  ВМ, DRS будет делать сам, а вот vMotion – лишь предлагать;

Q  Fully automated (полностью  автоматический) – и выбор, где включить, и vMotion DRS будет делать сам.

Обратите внимание на бегунок Migration Threshold – его положение указыва ет агрессивность работы кластера DRS. Чем его положение ближе к Conservative, тем только  более важные  рекомендации будет выдавать  и исполнять DRS.  Чем бегунок ближе к Aggressive, тем менее важные рекомендации будут выдаваться.

Обратите внимание. Если DRS работает в ручном (Manual) режиме,  то непривилегированные пользователи (у которых есть право включать ВМ, например с ролью Virtual Machine User) не смогут увидеть окно выбора сервера при включении этой ВМ (рис. 6.66), и ВМ не включится.

DRS создает рекомендацию для миграции по следующим причинам:

Q  для балансировки нагрузки на процессоры сервера, или reservation по процессору;

Q  для балансировки нагрузки  на память сервера, или reservation по памяти;

Q  для удовлетворения настройки reservation для пулов ресурсов;

Q  для  удовлетворения правил  affinity  или  anti-affinity (речь  идет об  одноименной  настройке  кластера  DRS,  а не о настройке  CPU affinity  в свойствах ВМ);

Q  для  миграции   ВМ  с  сервера,  переходящего  в  режим  maintenance  или

standby;

Q  для  удовлетворения рекомендаций Distributed  Power  Management,  если этот компонент  используется.

DRS  отслеживает счетчики  Host  CPU:  Active  (включая run  и ready) и Host  Memory:  Active. DRS  выдает  рекомендации за пятиминутные интервалы,  изменить это нельзя. Ссылка Run DRS на закладке DRS для кластера принудительно заставляет обсчитать рекомендации.

Приоритет рекомендаций миграции  измеряется цифрами от 1 до 5, где 5 указывает на наименьший приоритет. Приоритет зависит от нагрузки на серверы: чем больше загружен один сервер и чем меньше другой – тем выше приоритет  миграции ВМ с первого на второй. Обратите  внимание на рис. 6.61.

Рис. 6.61. Текущая информация о статусе DRS-кластера

Самое главное здесь – это:

Q  Migration Threshold – настройка,  указывающая на уровень  приоритета,  рекомендации с которым  выполняются автоматически. От этой настройки зависит  значение  «Target  host load standard deviation». Таким  образом, данная  настройка указывает на то, насколько  кластер  может быть несбалансированным;

Q  Target host load standard deviation – стандартное  отклонение  нагрузки,  при достижении которого требуется балансировка;

Q  Current host load standard deviation – стандартное  отклонение текущей нагрузки  на серверы.

В расчете стандартного  отклонения используется расчет нагрузки  на каждый сервер по следующей формуле:

sum(нагрузка от ВМ   на одном сервере)  / (ресурсы сервера)

Приоритет миграции высчитывается по формуле:

6   ceil(Current host  load  standard deviation / 0.1  ?   sqrt(Количество   серверов в  кластере))

где ceil(x) – наименьшее целое, не меньшее x.

Впрочем, формула может меняться  в следующих версиях vSphere.

Также  высокий  приоритет  имеют миграции,  вызванные  правилами affinity и anti-affinity, о которых  позже. Наконец,  если сервер поместить  в режим Maintenance, то DRS  сгенерирует  рекомендацию мигрировать с него все ВМ, и у этих рекомендаций приоритет  будет максимальный.

Таким  образом, если бегунок стоит в самом консервативном положении, выполняются только  рекомендации от правил  affinity  и anti-affinity и  миграция  с серверов в режиме обслуживания. Если в самом агрессивном режиме – даже небольшая  разница  в нагрузке  на серверы будет выравниваться. Рекомендуемыми настройками являются средняя  или более консервативные.

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

Начиная с версии 4.1, DRS учитывает не только нагрузку на процессоры и память серверов, но и число виртуальных машин. Теперь не будет ситуаций, когда на одном из двух серверов кластера 20 маленьких виртуальных машин, а на втором – 2 большие. Получалось слишком много яиц в первой корзине.

Начиная с версии 4.1, в кластере DRS может быть до 32 серверов и до 3000 виртуальных машин. На каждом сервере может быть до 320 виртуальных машин. Эти цифры не зависят от типа кластера (HA/DRS/оба) и не зависят от числа серверов в кластере (как это было в предыдущих  версиях).

DRS Groups Manager – этот пункт  настроек  появился только  в версии 4.1. Его суть в том, что для DRS-кластера мы можем обозначить  группы серверов  и виртуальных машин, а затем создать правила соотношения между ними. Правила  вида «группа виртуальных машин "test"  не должна работать на серверах группы "new_servers"» или «группа виртуальных машин "CPU Intensive" должна работать на серверах группы "Servers_with_new_CPU"» (рис. 6.62).

Эта возможность может быть интересна нам из следующих соображений:

Q  чтобы однотипные виртуальные машины работали на одних и тех же серверах. В таком случае механизм  transparent page sharing будет более эффек тивно дедуплицировать оперативную  память этих виртуальных машин;

Рис. 6.62. Группы серверов и виртуальных машин для кластера DRS

Q  чтобы виртуальные машины  с более высокими  требованиями к произво дительности работали  на более производительных серверах кластера  (где более новые процессоры или больший объем памяти);

Q  если приложение в виртуальных машинах лицензируется таким образом,

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

Q  если у части серверов есть единая точка отказа (например, в кластере сервера из двух шасси блейд-серверов), то можно дублирующие друг друга ВМ  (такие  как серверы  DNS  или  контроллеры домена)  явно  привязать к серверам только одного шасси. Соответственно, часть серверов DNS старается  работать  на серверах  одного шасси, а часть – на серверах  другого шасси;

Q  чтобы HA  использовал для  включения после  сбоя некоторых,  например

тестовых, виртуальных машин только некоторые серверы ESX(i).

Rules – здесь  мы можем  создавать  так называемые  правила  affinity  и  antiaffinity,  а также  указывать  правила  принадлежности групп виртуальных машин группам серверов.

При создании правила anti-affinity мы указываем  несколько  виртуальных машин, которые  DRS  должен  разносить  по разным  серверам.  Обратите внимание: каждая ВМ одной группы anti-affinity должна располагаться на отдельном сервере. Например, такое правило  имеет смысл для основного  и резервного  серверов DNS или контроллеров домена. Таким образом,  в одном правиле не сможет участвовать виртуальных машин больше, чем в кластере серверов.

В правиле affinity мы указываем  произвольное количество  ВМ, которые DRS должен  держать на одном сервере. Например, это бывает оправдано  для сервера приложений и сервера БД, с которым  тот работает. Если такая пара будет работать на одном сервере, трафик между ними не будет нагружать физическую сеть и не будет ограничен ее пропускной способностью. Если какие-то  правила  взаимоисключающие,  то у имени, созданного  последним, нельзя  поставить  флажок  (то есть правило  нельзя активировать). С каким другим правилом  оно конфликтует, можно посмотреть по кнопке Details (рис. 6.63).

Рис. 6.63. Подробности правила для DRS

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

В версии 4.1 появилась возможность разделить  виртуальные машины и сер-

веры по группам и указать правила их связи друг с другом. Доступны следующие варианты (рис. 6.64):

Q  Must run on hosts in group – указанная группа виртуальных машин обязана

работать на указанной группе серверов. Если подходящего сервера не будет доступно – виртуальная машина не будет включена или мигрирована;

Q  Should run on hosts in group – указанная группа  виртуальных  машин

должна  стараться работать на указанной группе серверов. Если подходящих серверов не будет – виртуальная машина будет работать на каком-то из прочих;

Q  Must Not run on hosts in group – указанная группа виртуальных машин

обязана работать не на указанной группе серверов;

Q  Should Not run on hosts in group – указанная группа виртуальных машин

должна стараться работать не на указанной группе серверов.

Рис. 6.64. Варианты привязки групп виртуальных машин к группам серверов ESX(i)

Хотя это разделение  делается в настройках  DRS, «жесткие» правила оказыва ют влияние  также на HA и DPM.

Для этого механизма следует упомянуть  о следующих правилах  работы:

Q  для правил нет возможности указывать приоритет. Если одна виртуальная машина подпадает сразу под пару правил, она будет работать только на серверах, удовлетворяющих обоим правилам;

Q  если происходит конфликт правил для одной виртуальной машины, прио-

ритет имеет правило, созданное позднее;

Q  если  в кластере  присутствуют  группы  с жесткими  связями вида  «Must  run..» или «Must  Not run..», то даже администратор не сможет  запустить  или  мигрировать виртуальную машину  на  сервер,  не удовлетворяющий правилу.  Более  того, DRS,  DPM и HA не будут осуществлять операции, противоречащие этим правилам. То есть при конфликте с таким правилом:

•    DRS  не будет мигрировать виртуальные машины  с сервера, переводимого в режим обслуживания;

•    DRS  не будет включать  или  мигрировать для балансировки нагрузки  виртуальную машину на неподходящий сервер;

•    HA не включит виртуальную машину, если подходящих по правилу серверов не будет доступно;

•    DPM не выключит  серверы, которые не сможет освободить из-за влияния правила;

Q  с правилами типа  «Should..»,  мягкими,  таких  ограничений нет – именно потому они являются рекомендуемыми в общем случае;

Q  правила  типа «Should..», мягкие, DRS может не брать в расчет при дисба-

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

Обратите внимание. Доступна возможность создать alarm, который будет отслеживать событие конфликта с правилом.  Для этого создайте alarm для виртуальной машины или их группы типа Event based и на вкладке Trigger выберите VM is violating VM-Host Affinity Rule.

Virtual Machine Options – это следующий пункт настроек DRS. Здесь можно включить  или выключить  возможность индивидуальной настройки уровня автоматизации для каждой ВМ. Часто имеет смысл для тяжелых ВМ выставить эту настройку в ручной или полуавтоматический режим, чтобы минимизировать влия ние на такие ВМ со стороны DRS. Балансировка нагрузки  будет осуществляться за счет менее критичных виртуальных машин.

Обратите внимание. В случае DRS-кластера рекомендуется для ВМ с vCenter настроить DRS в ручной режим и всегда держать эту ВМ на одном выбранном сервере (например, первом). Иначе если ВМ с vCenter не работает, то искать ее придется на всех серверах по очереди перебором.

Power Management и Host Options – здесь настраивается DPM. О нем и о его настройках  позднее.

VMware EVC или Enhanced vMotion Compatibility – так как DRS использует  vMotion для выполнения своих функций,  то для виртуальных машин и серверов в DRS-кластере должны  выполняться условия  для vMotion. Одно из них – одинаковость  процессоров  по поддерживаемым инструкциям. Самый  эффективный способ это сделать – включить функцию  EVC.

Суть ее – в том, что все серверы в DRS-кластере со включенным  EVC «приводятся  к единому знаменателю» по функциям процессора,  путем отключения тех функций,  которых нет хотя бы на одном сервере кластера.

EVC способна обеспечить совместимость не любых процессоров, и даже не любых поколений процессоров  даже одного вендора. Информацию по группам  совместимости EVC (рис. 6.65) можно найти в базе знаний VMware (статьи 1003212 и 1005764).

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

1.    Создать кластер DRS (на нем также может быть включена и функция HA, это не имеет значения  в данном контексте).

2.    Включить EVC.

Рис. 6.65. Настройка EVC для кластера DRS

3.    Добавить в кластер серверы.

4.    После этого начать создавать и включать виртуальные машины.

Если DRS-кластер уже существует, то порядок  включения EVC будет следующим:

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

2.    Включить ЕVC.

3.    Включить ВМ, выключенные  на шаге 1.

Swapfile location – где ВМ по умолчанию  будут хранить свой vmkernel swap файл. Обратите  внимание,  что файл подкачки  может быть расположен не на общем хранилище. Например, если мы указали хранить файлы подкачки на локальных дисках серверов, виртуальные машины все равно смогут мигрировать с помощью vMotion.

Обращаю  ваше внимание,  что употребляемый здесь термин  «кластер» означает тип объектов в иерархии vCenter.  По сути, этот «кластер»  – не что иное, как контейнер  для  серверов,  группа  серверов.  На  этой группе  мы  можем  включить  функции DRS  и/или HA. Однако  настройки EVC  и Swapfile location  мы можем задавать и для кластера, где ни DRS, ни HA не включены. Следовательно, мы можем задавать эти настройки,  даже когда лицензий на HA и DRS у нас нет.

Иллюстрация работы DRS – обратите внимание на рис. 6.66.

Рис. 6.66. DRS предлагает сервер, на котором лучше включить ВМ

Это окно выбора сервера для включения ВМ. Такое окно вы увидите в Manualрежиме DRS-кластера при включении  ВМ. Обратите  внимание, что при клике на имена ВМ и серверов вы попадете в их свойства, а не выберете миграцию  на тот или иной сервер. Смотреть здесь надо на значения в столбце Priority – чем больше число, тем лучше (по мнению DRS)  запустить ВМ на сервере из этой строки.

Выделив кластер, на закладке  Summary вы увидите базовую информацию по нему. Обратите  внимание на DRS Recommendations (рис. 6.67).

Перейдя по этой ссылке, вы попадете на закладку DRS. По кнопке Recommendations на ней вы увидите примерно такую картинку,  как показано на рис. 6.68.

Вот так выглядят рекомендации к миграции от DRS. В этом примере нам предлагают  мигрировать ВМ  File_Server_Win2008 на сервер  esx1.vm4.ru.  Если  вы хотите  выполнить эту рекомендацию,  нажмите  кнопку  Apply Recommendation. Если DRS  предлагает  миграцию  сразу нескольких  ВМ, а вы не хотите мигриро вать сразу все – поставьте флажок  Override DRS recommendations и флажками в столбце Apply выбирайте  рекомендации, которые будут выполнены  по нажатии  Apply Recommendation.

По кнопке History на закладке DRS для кластера доступна история успешных

миграций.  Данные  на этой странице  сохраняются в течение четырех часов и доступны и при открытии  новой сессии клиента vSphere.

Рис. 6.67. Summary для кластера DRS

Рис. 6.68. Рекомендация vMotion от DRS

По кнопке Faults на закладке  DRS для кластера  доступна  история неуспешных миграций.  Показывается, кто и куда не может (для  режима Manual) или не смог (для Automatic) мигрировать и по какой причине.

Обычно  рекомендации DRS  следуют из сильно  различающейся нагрузки на серверы, которую можно увидеть на закладке Hosts для кластера (рис. 6.69).

Рис. 6.69. Нагрузка на серверы в DRS-кластере

Вернемся  к рис. 6.54. На закладке  Summary для кластера  DRS  доступна информация о его настройках и о ресурсах кластера. В моем примере сообщается, что совокупные ресурсы кластера равняются 6 ГГц для процессора и 4,62 Гб для памяти. Обратите  внимание  – это не означает, что я могу выделить одной ВМ 4,62 Гб физической памяти, потому что эта память разнесена по нескольким серверам. То есть правильно читать  эту информацию следующим образом: все ВМ в данном кластере в совокупности могут задействовать 6 ГГц и 4,62 Гб физической памяти. То есть для распределения ресурсов присутствует некоторая дискретность.  Впрочем, обычно ресурсы сервера значительно превосходят  ресурсы для самой требовательной ВМ, и это предупреждение неактуально.

VMware Distributed Power Management

DPM – это дополнительная функция кластера  DRS. Заключается она в том, что DRS анализирует нагрузку  на серверы и, если для работы всех виртуальных машин  достаточно  лишь  части серверов,  может перенести  все ВМ на эту часть. А оставшиеся  серверы перевести в standby-режим. Разумеется, в тот момент, когда в их производительности возникнет нужда, DPM включит их обратно. Анализ  DPM основан на тех данных, что собирает и анализирует DRS. DRS  выполняет свою работу  с пятиминутным  интервалом, таким  образом,  DRS  пересчитывает свою аналитику раз в пять минут. При анализе DPM руководствуется данными за 40-минутный интервал.

По умолчанию  DPM считает нормальной нагрузку  на сервер 63±18%. Когда нагрузка  на серверы превышает  81%, начинается  включение  серверов. Когда нагрузка падает ниже 45%, DPM начинает консолидировать ВМ и выключать серверы. Эти настройки можно изменять  в Advanced  Settings для DRS-кластера, о чем ниже.

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

Для  включения серверов  DPM может  использовать два  механизма:  BMC/ IPMI или  Wake-On-LAN (WOL).  Для  задействования  BMC/IPMI  необходимо для каждого сервера указать необходимые параметры  доступа к BMC (Baseboard Management Controller). Под BMC понимаются контроллеры, работающие по протоколу IPMI, например HP iLO, Fujitsu iRMC, IBM RSA, Dell DRAC (рис. 6.70).

Рис. 6.70. Настройка параметров доступа к IPMI/iLo для ESX(i) 4

Само собой, должны быть сделаны необходимые настройки – на BMC должен быть создан пользователь, имеющий право включать сервер, IP-адрес BMC/IPMI должен быть доступен с сервера vCenter. Подробности по настройке  этих компонентов следует искать в документации к серверу.

Суть  BMC/IPMI  контроллера – в том, что эти  контроллеры  являются, по сути, компьютерами в миниатюре,  со своим  сетевым портом.  Эти  контроллеры имеют доступ к управлению оборудованием «большого»  сервера. Работают  они независимо  от работоспособности сервера. Таким образом, если сервер выключен, то BMC/IPMI остается доступен по сети, и по сети можно инициировать, в частности, функцию включения сервера. Этим и пользуется DPM.

Если  для  сервера  не указаны  настройки BMC/IPMI,  то vCenter  будет  пытаться включать их с помощью механизма Wake-On-Lan. Обратите  внимание, что пакеты  WOL  будут посылаться  на те физические сетевые контроллеры сервера, к которым  подключен  vMotion интерфейс VMkernel.  Посылаться они будут не

сервером  vCenter,  а одним из включенных  серверов  ESX(i) по команде  vCenter.

Таким образом, необходимо выполнение следующих условий:

Q  на каждом  сервере  должны  быть  интерфейсы VMkernel  с  разрешенным vMotion через них;

Q  эти интерфейсы должны быть в одной подсети, без маршрутизаторов между ними;

Q  тот физический сетевой  контроллер, через  который  будет  работать  этот vMotion интерфейс,  должен  поддерживать WOL.  Проверить это  можно,

пройдя  Configuration ? Network Adapters для сервера. В столбце Wake

On LAN Supported должно стоять Yes.

Обратите  внимание,  что многие сетевые контроллеры одерживают  WOL не во всех режимах работы. Часто только 100 или 10 Мбит/с. Таким образом, может потребоваться настройка  портов физического коммутатора,  к которому подключены эти сетевые контроллеры серверов. Эти порты должны  быть настроены  на автосогласование (auto  negotiate) скорости, чтобы, когда сервер выключен,  сетевые карты могли работать на требуемой для WOL скорости.

Еще до включения функционала DPM следует протестировать работоспособность этих механизмов. В контекстном меню работающего сервера есть пункт Enter Standby Mode, а в меню выключенного сервера – Power on. Если включение сервера  через IPMI/iLO не заработало,  то удалите  настройки из пункта  Power Management для этого сервера. Когда IPMI/iLO для сервера не настроено, DPM будет использовать WOL.

Для настройки DPM зайдите в свойства кластера DRS, вас интересует пункт

Power Management. Там три варианта настройки:

Q  Off – DPM выключен;

Q  Manual – DPM включен, но будет лишь показывать  рекомендации по выключению  серверов. Эти рекомендации будут доступны  на закладке DRS для кластера;

Q  Automatic – включение и выключение серверов, а также связанные с этим миграции ВМ будут происходить автоматически. Бегунок указывает на то, рекомендации с каким  приоритетом будут  выполняться  автоматически. Приоритет обозначается  цифрами от 1 (максимальный) до 5 (минимальный).

Обратите  внимание, что уровень автоматизации можно указывать индивидуально для каждого сервера. Делается  это на пункте Host Options. Если какие-то  серверы невозможно включить  через IPMI/iLO/WOL,  будет хорошей идеей для них функцию  DPM отключить.

Рекомендации DRS и DPM не зависят  друг от друга. Уровни автоматизации DRS и DPM не связаны друг с другом.

Для  автоматизации мониторинга действий  как DRS,  так и DPM можно использовать  механизм  vCenter alarms.  Для  кластера  или  выше  него в  иерархии  vCenter надо создать alarm, который мониторит  события (events). Например, для DPM можно мониторить следующие события:

Q  DrsEnteringStandbyModeEvent – инициация выключения сервера;

Q  DrsEnteredStandbyModeEvent – успешное выключение сервера; Q  DrsExitingStandbyModeEvent – инициация включения сервера; Q  DrsExitedStandbyModeEvent – успешное включение сервера;

Q  DrsExitStandbyModeFailedEvent – неуспешное включение сервера.

С мониторингом может быть связан еще один нюанс – у вас может использо ваться какое-либо  из средств мониторинга,  такое как BMC Performance Manager, HP   System   Insight  Manager,   CA  Virtual  Performance  Management,  Microsoft  System  Center Operations Manager, IBM  Tivoli. Эта система  может среагировать  на выключение сервера, инициированное DPM. Могут потребоваться коррективы правил мониторинга,  чтобы на такие штатные выключения серверов эти системы не реагировали.

Достаточно  естественной  является идея включать  серверы по утрам, немного ДО того, как их начнут  нагружать  приходящие на работу сотрудники.  Начиная с версии  4.1, эта возможность реализуется штатными средствами.  Для  этого че-

рез планировщик vCenter (Home ? Scheduled Tasks ? New) создайте задание

Change Cluster Power Settings.

Обратите внимание. vCenter привязывает шаблоны ВМ к какому-то серверу, даже когда они расположены на общем хранилище. Если DPM выключит тот сервер,  за которым числится шаблон, то шаблоном невозможно  будет воспользоваться. Поэтому в идеале тот сервер, за которым числятся шаблоны, не должен выключаться DPM. Если же шаблон оказался недоступен, то его надо удалить из иерархии vCenter (пункт Remove from Inventory контекстного меню шаблона) и затем добавить обратно через встроенный файловый менеджер (пункт Browse Datastore контекстного меню хранилища, где расположен шаблон).

Удаление DRS

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

Advanced Settings

Обратите  внимание на рис. 6.71.

Здесь вы видите область расширенных  настроек кластера DRS и DPM.

В данном примере значение 75 настройки DemandCapacityRatioTarget говорит о том, что DPM должен  обращать  внимание  на серверы не по формуле  63±18%, а по формуле 75±18%.

За списком расширенных  настроек обратитесь по ссылке http://www.vmware.

com/resources/techresources/1080.

Рис. 6.71. DRS Advanced Settings

Источник: Михеев М. О.  Администрирование VMware vSphere 4.1. – М.: ДМК Пресс, 2011. – 448 с.: ил.

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий