Q В ВМ повинні бути встановлені і працювати VMware tools. Вони надають драйвери для більш ефективних моделей віртуальних контролерів, драйвер для перерозподілу пам'яті vmmemctl і ін.
Q Вкрай бажано, щоб VMware tools були актуальної версії. Викорис зуйте VMware Update Manager для контролю версій і оновлення.
Q Є деякі нюанси при експлуатації ESX (i) на серверах з архітектурою NUMA. Ця архітектура передбачає, що контролер пам'яті інтегрований в процесор, і для процесора є «своя» і «не своя» пам'ять, з відмінним часом доступу. Це сервери на процесорах AMD Op-
teron і на деяких моделях Intel Xeon. Прикладом такого нюансу може бути небажаність створення ВМ з кількістю vCPU більше, ніж ядер в одному процесорі, - в такому разі ESX (i) фізично не зможе зробити так, щоб всі процесори цієї ВМ працювали на одному NUMA-вузлі і вся її пам'ять для всіх її процесорів була доступна як «локальна». Таким чином, якщо у вас сервери на NUMA-архітектурі, ознайомтеся з відповідним розділом «vSphere Resource Management Guide».
Q Для гостьових операційних систем рекомендується включити использова-
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 при 70% -ної завантаженні процесора, а range = 5, то alarm спрацює при завантаженні вище 75% (= 70 + 5) і повернеться в нормальний стан при завантаженні нижче 65% (= 70 - 5).
Trigger Frequency - протягом цієї кількості хвилин після спрацювання alarm не спрацює ще раз.
Що б не відстежував той чи інший аларм, ключовим наслідком цього є можливість реакції на подію. При створенні АЛАРМ ми вказуємо умови зміни статусу об'єкта, за яким спостерігаємо. На останній закладці ми вказуємо заходів, яких треба вжити при зміні статусу.
Серед дій ми зустрінемо (в залежності від типу АЛАРМ і за ким він спостерігає):
Q сповіщення по електронній пошті. Дія доступна для об'єктів усіх типів. Лист буде відправляти vCenter, тому в меню Home. vCenter Server Settings. Mail потрібно вказати налаштування поштового сервера;
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
Зверніть увагу на контекстне меню на активному 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 ...).
Тепер, у разі погіршення в роботі компонентів сервера, vCenter переведе його в Maintenance-режим, що викличе міграцію віртуальних машин з цього сервера на інші і стане на заваді запуску ВМ на даному сервері.
Міграція виключеною (або suspend) віртуальної машини
Мал. 6.55. Існуючі за замовчуванням alarms
Якщо віртуальна машина вимкнена або знаходиться в стані паузи (suspend), то її можна мігрувати як між серверами, так і між сховищами, між серверами і сховищами одночасно.
Запуск міграції здійснюється перетягуванням ВМ на потрібний сервер або сховище, або пунктом Migrate контекстного меню ВМ. Умов ні на ВМ, ні на сервери не накладається.
Якщо необхідно мігрувати ВМ без участі vCenter, то пункт Migrate або перетягування вам недоступно. Тоді можна зробити так:
1. Виключити ВМ або перевести в стан паузи (suspend).
2. Видалити ВМ з ієрархії об'єктів ESX (i) - пункт Remove from Inventory
3. Перенести файли ВМ на інше сховище, якщо необхідно. Для цього можна скористатися вбудованим файловим менеджером або будь-яким іншим.
4. Зареєструвати ВМ на потрібному сервері. Для цього через вбудований файловий менеджер знайти її файли і вибрати Add to inventory в контекстному меню її файлу налаштувань (* .vmx).
Якщо є необхідність перенести ВМ з сервера на сервер або на інше сховище з мінімальним простоєм, але vMotion / Storage vMotion недоступний, то можна зробити так:
1. Для працюючої ВМ створити знімок стану (snapshot).
2. Скопіювати всі її файли, крім файлів останнього знімка стану, на нове сховище.
3. Перевести ВМ в стан паузи (suspend).
4. Перенести на інше сховище залишилися файли ВМ (це файли останнього знімка і файл з пам'яттю ВМ в стані паузи).
Storage vMotion - жива міграція файлів ВМ між сховищами
6. Включити ВМ на новому місці, видалити знімок стану, видалити вихідну ВМ.
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 - тут можна вказати тип диска для ВМ на новому сховищі.
Умов на тип сховища немає - можливе перенесення ВМ між системами зберігання будь-яких типів, включаючи локальні диски і DAS. Але ще раз звертаю вашу увагу на те, що процес Storage vMotion залишає ВМ на тому ж самому сервері.
Для віртуальних машин умов два:
Q не повинно бути знімків стану (snapshot);
Q диски ВМ не повинні бути в режимі independent.
Для сервера умова, в общем-то, одне - щоб була ліцензія на Storage vMotion.
Зверніть вніманіе.Іногда SVMotion не може завершитися. Це може бути при міграції ВМ з декількома дисками, в такому випадку фінальна стадія їх перенесення може не укластися у відведений для цього час. В такому випадку вам може допомогти збільшення цього тайм-ауту зі значення в 100 секунд за замовчуванням. Робиться це зазначенням необхідного значення рядком fsr.maxSwitchoverSeconds в файлі конфігурації ВМ.
Схожі пости: