Q В ВМ должны быть установлены и работать VMware tools. Они предоставляют драйверы для более эффективных моделей виртуальных контроллеров, драйвер для перераспределения памяти vmmemctl и др.

Q Крайне желательно, чтобы VMware tools были актуальной версии. Исполь зуйте VMware Update Manager для контроля версий и обновления.

Q Для Linux ВМ и некоторых приложений в Windows ВМ проблемой может быть частота Timer-Interrupt; см. статью в базе знаний VMware – http:// kb.vmware.com/kb/1006427 для Linux ВМ. Также на сайте VMware существуют документы с рекомендациями для работы в ВМ конкретных приложений, например для ВМ с Java см. статью «Java in Virtual Machines on VMware ESX: Best Practices». Вас интересует следующий раздел сайта – http://www.vmware.com/resources/techresources/.

Q Есть некоторые нюансы при эксплуатации ESX(i) на серверах с архитектурой NUMA. Эта архитектура предполагает, что контроллер памяти интегрирован в процессор, и для процессора есть «своя» и «не своя» память, с отличающимся временем доступа. Это серверы на процессорах AMD Op-

Механизм Alarm

teron и на некоторых моделях Intel Xeon. Примером такого нюанса может быть нежелательность создания ВМ с количеством vCPU больше, чем ядер в одном процессоре, – в таком случае ESX(i) физически не сможет сделать так, чтобы все процессоры этой ВМ работали на одном NUMA-узле и вся ее память для всех ее процессоров была доступна как «локальная». Таким образом, если у вас серверы на NUMA-архитектуре, ознакомьтесь с соответствующим разделом «vSphere Resource Management Guide».

Q Для гостевых операционных систем рекомендуется включить использова-

ние так называемых «Large Page», страниц памяти большого размера. Это снижает накладные расходы на виртуализацию их работы с памятью. См. http://www.vmware.com/resources/techresources/1039.

6.4.  Механизм Alarm

ESX(i) предоставляет большое количество информации о состоянии инфраструктуры. Это и разнообразные счетчики производительности, и данные по состоянию серверов, наличие сигналов пульса (heartbeat) от VMware tools внутри ВМ, журнал событий (events) и др. Однако часто бывает полезной не только сама по себе возможность посмотреть данные, но и получить автоматически оповещение или иную реакцию.

Для этого в vCenter предусмотрен механизм Alarms – обратите внимание на одноименную закладку для дата-центров, серверов, кластеров, виртуальных машин, пулов ресурсов и папок (рис. 6.52).

Рис. 6.52. Сработавший alarm для сервера

Каждый alarm – это суть триггер, отслеживающий событие или состояние счетчика нагрузки. Alarm могут мониторить счетчики для объектов разных типов – ВМ, серверов, сетей, хранилищ. Притом отслеживаться может как показатель нагрузки (например, процент загрузки процессора или свободное место на диске), так и состояние (включена ли ВМ, доступен ли сервер по сети).

Кроме того, alarm может отслеживать событие (event) с указанными параметрами.

Для создания Alarm перейдите на желаемый уровень иерархии. Например, если я хочу создать alarm для мониторинга виртуальных машин, то выберу Data center в случае, когда хочу отслеживать сразу все ВМ в нем. Если же я хочу отслеживать только группу ВМ, то перейду на соответствующий пул ресурсов, vApp или каталог для виртуальных машин.

Затем следует перейти на закладку Alarms ? кнопка Definitions. Там мы уви-

дим все актуальные для этого уровня иерархии alarm. В столбце Defined In ука-

зано, с какого объекта они наследуются. Выбрав пункт New Alarm в контекстном меню пустого места этой закладки, мы запустим мастер создания нового alarm.

На первой закладке вводим имя alarm и что он должен мониторить (рис. 6.53).

Рис. 6.53. Создание alarm

Вариантов типов объектов, как вы видите, много. Также здесь мы указываем, что мы хотим мониторить, – состояние какого-либо счетчика или состояние объекта, или событие, произошедшее с объектом.

На закладке Triggers мы указываем условия срабатывания alarm. Их может быть несколько, alarm может срабатывать как при выполнении любого, так и сразу всех условий. Кроме того, мы можем указать пороговые значения, при которых alarm меняет статус объекта на Warning (предупреждение) или Error (ошибка).

На закладке Reporting мы указываем параметры срабатывания alarm.

Range – диапазон, при выходе из которого alarm меняет статус. То есть «наступление порогового значения» плюс «диапазон» = сработавший alarm. Например,

Механизм Alarm

если вы указали срабатывание alarm при 70%-ной загрузке процессора, а range = 5, то alarm сработает при загрузке выше 75% (= 70 + 5) и вернется в нормальное состояние при загрузке ниже 65% (= 70 – 5).

Trigger Frequency – в течение этого количества минут после срабатывания alarm не сработает еще раз.

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

Среди действий мы встретим (в зависимости от типа аларма и за кем он наблюдает):

Q оповещение по электронной почте. Действие доступно для объектов всех типов. Письмо будет отправлять vCenter, поэтому в меню Home ? vCenter Server Settings ? Mail нужно указать настройки почтового сервера;

Q оповещение по SNMP. Действие доступно для объектов всех типов. Trap сообщения будет рассылать сервер vCenter, поэтому в меню Home ? vCenter Server Settings ? SNMP нужно указать адреса получателей и строки

community;

Q запуск произвольной команды. Действие доступно для объектов всех типов. В столбце Configuration указываются путь и параметры запускаемой программы. Например:

c:\windows\system32\cmd.exe /c c:\tools\cmd.bat

Также в качестве параметров можно передавать некоторые поля alarm. Например:

c:\tools\sendsms.exe AlarmName targetName

Список доступных полей см. в документе «vSphere Basic System Administration».

Указанная команда будет выполнена на сервере vCenter отдельным от службы vCenter потоком;

Q для виртуальных машин – включение, выключение, пауза, миграция, пере-

загрузка;

Q для серверов – ввод в режим обслуживания, вывод из режима обслуживания, отключение от vCenter, перезагрузка, выключение.

Аларм, созданный на одноименной вкладке на каком-то уровне иерархии vCenter, мониторит объекты этой ветки иерархии. Например, аларм мониторинга ВМ, созданный на уровне Datacenter, мониторит все ВМ. А созданный на уровне каталога для ВМ – все ВМ этого каталога.

Обратите внимание: в контекстном меню большинства объектов иерархии vCenter есть пункт Alarm ? Disable Alarms Actions (рис. 6.54).

Этот пункт нужен для отключения реакции (но не факта срабатывания) alarm для данного объекта. Опять же, востребовано обычно во время каких-либо плановых процедур с инфраструктурой, которые могут вызвать нежелательные сраба-

Рис. 6.54. Выключение реакции alarm

тывания alarm. Срабатывание автоматических реакций alarm отключается, пока их не включите обратно, из того же самого меню.

Существующие по умолчанию alarms созданы для самого верхнего уровня иерархии. Найти их, чтобы посмотреть свойства, поменять свойства или удалить,

можно, выбрав vCenter в иерархии ? закладка Alarms ? кнопка Definitions

(рис. 6.55).

Обратите внимание на контекстное меню на активном alarm. Пункт acknowledge (рис. 6.40) блокирует автоматическое действие alarm, не сбрасывая его статус. Это полезно, когда alarm реагирует на какое-либо плановое событие, о котором вы знаете и реагировать на которое не нужно.

Также в нижней части экрана есть кнопка Alarms, выбор которой покажет все активные на данный момент alarm (рис. 6.56).

Приведу пример применения этого механизма. Допустим, перед нами поставили задачу – эвакуировать виртуальные машины с сервера, на котором произошел отказ компонента. Из тех соображений, что отказ компонента, не приведший к отказу сервера, все равно снижает его надежность. Например, если отказал один

из двух блоков питания. Для этого в клиенте vSphere пройдите Home ? Inventory

? Hosts and Clusters и в левом дереве выберите объект высокого уровня иерар-

хии, например корень, Datacenter или кластер, – чтобы все наши серверы были

ниже по иерархии.

Вас интересует закладка Alarms ? кнопка Definitions. Контекстное меню пусто-

го места ? New Alarm. Мониторить будем серверы (выпадающее меню Monitor),

для серверов мониторить будем состояние (Monitor for specific events…).

На закладке Triggers добавьте условие «Hardware Health Changed». А на закладке Actions добавьте реакцию – «Enter maintenance mode». Также при необходимости добавьте оповещение по SNMP или e-mail.

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

Миграция выключенной (или suspend) виртуальной машины

Рис. 6.55. Существующие по умолчанию alarms

Больше информации о возможностях механизма alarm вы можете подчерпнуть по ссылке http://communities.vmware.com/docs/DOC-12145.

6.5.  Миграция выключенной

(или suspend) виртуальной машины

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

Запуск миграции осуществляется перетаскиванием ВМ на нужный сервер или хранилище, или пунктом Migrate контекстного меню ВМ. Условий ни на ВМ, ни на серверы не налагается.

Если необходимо мигрировать ВМ без участия vCenter, то пункт Migrate или перетаскивание вам недоступно. Тогда можно сделать так:

1.    Выключить ВМ или перевести в состояние паузы (suspend).

Рис. 6.56. Просмотр сработавших alarms

2.    Удалить ВМ из иерархии объектов ESX(i) – пункт Remove from Inventory

контекстного меню.

3.    Перенести файлы ВМ на другое хранилище, если необходимо. Для этого можно воспользоваться встроенным файловым менеджером или любым другим.

4.    Зарегистрировать ВМ на нужном сервере. Для этого через встроенный файловый менеджер найти ее файлы и выбрать Add to inventory в контекстном меню ее файла настроек (*.vmx).

Если есть необходимость перенести ВМ с сервера на сервер или на другое хранилище с минимальным простоем, но vMotion/Storage vMotion недоступен, то можно сделать так:

1.    Для работающей ВМ создать снимок состояния (snapshot).

2.    Скопировать все ее файлы, кроме файлов последнего снимка состояния, на новое хранилище.

3.    Перевести ВМ в состояние паузы (suspend).

4.    Перенести на другое хранилище оставшиеся файлы ВМ (это файлы последнего снимка и файл с памятью ВМ в состоянии паузы).

Storage vMotion – живая миграция файлов ВМ между хранилищами

5.    Через встроенный файловый менеджер найти скопированные файлы на другом сервере и выбрать Add to inventory в контекстном меню ее файла настроек (*.vmx). Если копирование на другое хранилище этого же сервера, то тогда исходную ВМ нужно удалить пунктом Remove from inventory, а скопированную добавить на этом же сервере.

6.    Включить ВМ на новом месте, удалить снимок состояния, удалить исходную ВМ.

6.6.  Storage vMotion –

живая миграция файлов ВМ между хранилищами

Storage vMotion, иногда SvMotion – это перенос файлов ВМ с хранилища на хранилище без ее выключения. Поддерживаются хранилища любых типов, включая локальные диски. Поддерживается перенос как всей ВМ, так и только одного или нескольких ее файлов vmdk.

Кроме переноса файлов ВМ с хранилища на хранилище, Storage vMotion пригодится для:

Q конвертации диска ВМ между форматами thin и thick;

Q уменьшения размера thin-дисков. Если внутри тонкого диска сначала какое-то место было занято данными, а затем освободилось – thin-диск не уменьшится. Чтобы его уменьшить, можно сначала обнулить незанятые блоки (например, утилитой Sysinternals SDelete), а затем выполнить Storage vMotion этой ВМ на другое хранилище. Тонкий диск на новом хранилище опять будет содержать только существующие данные;

Q копирования vRDM в файл vmdk. Обратный процесс таким образом не-

возможен.

Суть процесса в следующем:

1.    Когда администратор инициирует Storage vMotion, для ВМ активируется функция change block tracking. С ее помощью ESX(i) в отдельном файле отслеживает, какие блоки файла vmdk были изменены.

2.    Основной объем информации (файлы vmdk) копируется. Притом копируются не сами файлы, а содержимое исходных файлов (исключая нулевые блоки) копируется в новые пустые файлы.

3.    Когда основной vmdk скопирован, начинает копироваться накопившийся массив измененных блоков, притом change block tracking теперь применя ется для него. Итерация повторяется до тех пор, пока время переноса данных измененных блоков не станет достаточно мало. Когда это происходит, обращения этой ВМ к диску временно блокируются, и последние измененные блоки копируются на другое хранилище.

4.    Гипервизор отправляет запросы ВМ уже к новым файлам. Старые файлы удаляются.

Для запуска этого процесса выберите Migrate в контекстном меню ВМ и

Change Datastore на первом шаге мастера.

Или перейдите Home ? Datastore ? хранилище с ВМ ? закладка Virtual

Machines и перетащите нужную ВМ на другое хранилище.

В мастере будут шаги:

1.    Select Datastore – здесь вы выберете, на какое хранилище переносить ВМ. А если нажать кнопку Advanced, то можно указать миграцию только отдельных дисков этой ВМ;

2.    Disk Format – здесь можно указать тип диска для ВМ на новом хранилище.

Thick, Thin или тот же, что и сейчас. Если у ВМ есть RDM-диски, то при выборе здесь Same format as source они останутся неизмененными, скопируется лишь vmdk-ссылка на RDM. При выборе thin или thick содержимое RDM LUN скопируется в файл vmdk на указанном хранилище. Это верно только для virtual RDM, для physical RDM такой способ копирования в файл vmdk невозможен.

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

Для виртуальных машин условий два:

Q не должно быть снимков состояния (snapshot);

Q диски ВМ не должны быть в режиме independent.

Для сервера условие, в общем-то, одно – чтобы была лицензия на Storage vMotion.

Обратите внимание. Иногда SVMotion не может завершиться. Это может быть при миграции ВМ с несколькими дисками, в таком случае финальная стадия их переноса может не уложиться в отведенное для этого время. В таком случае вам может помочь увеличение этого тайм-аута со значения в 100 секунд по умолчанию. Делается это указанием необходимого значения строкой fsr.maxSwitchoverSeconds в конфигурационном файле ВМ.

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