VMware Fault Tolerance, FT

Завданням VMware HA кластера є мінімізація часу простою всіх або більшості ВМ через відмову сервера (а вважаючи компонент VM Monitoring – і через відмову на рівні гостьовий ОС) А VMware Fault Tolerance дозволяє окремі ВМ позбавити від простоїв через відмову сервера (мається на увазі апаратний збій або проблема з самим ESX (i)) Передбачається, що таким чином захищати ми будемо найбільш критичні для нас ВМ

Зверніть увагу: FT не захистить ВМ від збою системи зберігання або від програмного збою програми та гостьовий ОС Зате від збою сервера ця функція захищає прозоро від гостьової ОС і додатків

Суть FT – у тому, що для захищається ВМ створюється її копія на іншому сервері І виконувані вихідної ВМ процесорні інструкції безперервно реплицируются на копію Якщо падає сервер, на якому працює вихідна ВМ, то достатньо випустити в мережу копію, щоб робота продовжилася без перерви

Ще один варіант – відмовостійкість на вимогу Наприклад, є ВМ

з формуючим звітність сервером Зазвичай ця ВМ захищена тільки HA Але в звітний період, коли переривання формування звіту загрожує втратою часу, для цієї ВМ легко включити FT і отримати велику доступність, ніж дає HA

Для роботи VMware FT повинні бути виконані деякі умови

Умови для інфраструктури:

Q повинен існувати кластер HA FT є його подфункцией Притому якщо HA включається для кластера і захищає все ВМ в ньому, то FT включається індивідуально для окремих ВМ у ньому

Висока доступність віртуальних машин

Q для всіх серверів, що використовуються для FT, повинна бути включена перевірка сертифікатів серверів (вона включена за замовчуванням)

Q на кожному сервері повинен бути інтерфейс VMkernel, налаштований для VMotion, і інтерфейс VMkernel, налаштований для FT Logging (і те, і інше – прапорці у властивостях інтерфейсу VMkernel) VMware рекомендує, щоб це були два різних інтерфейсу, що працюють через різні физиче ські мережеві контролери

Q між серверами повинна бути сумісність по процесорах

Q починаючи з версії 41 сервери не зобовязані мати однакову версію ESX (i) і однаковий набір оновлень У нових версіях vSphere перевіряється тільки сумісність версій компонента, що відповідає за Fault Tolerance Таким чином, цілком можлива ситуація, коли FT працює між хостами різних версій ESX (i), і навіть версії FT-компонента можуть відрізняти ся – але вони повинні бути сумісні

Q захищаються FT ВМ повинні використовувати дискові ресурси, доступні

з усіх серверів

Умови для серверів:

Q процесори серверів повинні бути зі списку сумісності VMware Fault Tolerance Подробиці – у статті бази знань номер 1008027 Бажано, щоб тактова частота процесорів серверів відрізнялася не більше ніж на 300 МГц

Q в BIOS серверів повинна бути включена апаратна підтримка ВІРТУАЛ-

зації

Умови для віртуальних машин На жаль, FT накладає досить багато обмежень на віртуальну машину під своїм захистом:

Q у віртуальної машини не повинно бути знімків стану (snapshot) на

момент включення FT, і їх не можна створювати для ВМ під захистом FT Це може бути важливо для резервного копіювання цієї ВМ – багато рішень резервного копіювання використовують знімки стану у своїй роботі (На жаль, це обмеження присутній і у версії 41)

Q VMware протестувала FT задля будь-яких ОС і не будь-яких комбінацій ОС

і процесорів Подробиці – у статті бази знань номер 1008027

Q не можна здійснити Storage VMotion для ВМ під захистом FT (на жаль, це обмеження присутній і у версії 41)

Q DRS отримав повну інтеграцію з FT починаючи з версії 41 Тепер Primary і Secondary віртуальні машини можуть бути перенесені між серверами для балансування навантаження, у тому числі автоматично

Q у ВМ повинен бути тільки один vCPU Це дуже сильно обмежує при-

сування даної функції для критичних і вимогливих до процесора завдань, адже один vCPU – це одне ядро

Q до ВМ не повинні бути підключені диски у форматі physical RDM

Q CD-ROM і FDD цієї ВМ можуть посилатися тільки на файли-образи з загальних сховищ Якщо подмонтіровать образ з приватного сховища і про-

ізошел збій сервера з Primary ВМ, то переїзд відбудеться, але нова Primary до цього образу доступу вже не отримає

Q не підтримується ВМ з паравіртуалізованним SCSI-контроллером, так

що в конфігурації ВМ не повинно бути PVSCSI

Q не повинна використовуватися паравіртуалізації для гостьових ОС

Q не повинно бути USBі аудіопристроїв

Q NPIV не повинен використовуватися для цієї ВМ

Q VMDirectPath I / O не повинен використовуватися для цієї ВМ

Q для захищеної FT ВМ неможливо гаряче додавання пристроїв

Q не дозволені Extended Page Tables / Rapid Virtualization Indexing (EPT / RVI)

Q файли ВМ повинні бути розташовані на загальному сховищі Тип храни-

ліща не важливий

Q диском ВМ може бути virtual RDM або файл vmdk типу eagerzeroedthick

Для створення такого vmdk відзначте прапорець Cluster Options при його створенні (рис 712)

Рис 712 Створення файлу vmdk з попередніми обнуленням

Висока доступність віртуальних машин

Втім, диски ВМ можна перетворити і після створення Для цього допоможе будь-яка дія з наступного списку:

Q запуск Storage VMotion і вибір Thick як типу дисків, попередньо

додавши у файл vmx рядок Set cbtmotionforceEagerZeroedThick = true

Q або пунктInflate в контекстному меню файлу vmdk, якщо знайти його через вбудований файловий менеджер

Q або команда vmkfstools – diskformat eagerzeroedthick

Q нарешті, найпростіше – при включенні FT сам майстер запропонує вам змінити тип дисків на необхідний Але зверніть увагу: ESX (i) перетворює thin-диск в диск потрібного для FT формату, лише якщо ви включили FT для виключеною ВМ

Отже, для включення Fault Tolerance вам необхідно зробити наступні дії:

1 Увімкнути перевірку сертифікатів серверів

2 Налаштувати мережу на кожному сервері

3 Створити кластер HA, додати в нього сервери і перевірити відповідність налаштувань

Для включення перевірки сертифікатів серверів зайдіть в меню Administration vCenter Settings SSL Settings ⇒ відзначте Check host certificates

Під налаштуванням мережі мається на увазі наступне: вам потрібні два інтерфейсу VMkernel, один з яких буде використовуватися під VMotion, а другий – під трафік Fault Tolerance Щоб конфігурація була підтримуваної, вони повинні мати за власним і виділеному гігабітному мережевого контроллера, хоча б по одному

Таким чином, вам необхідно створити два порти VMkernel, виділити кожному з фізичного мережевого контроллера і розставити прапорці (рис 713 і 714)

Мною наведено лише приклад конфігурації мережі Зрозуміло, немає потреби поміщати VMotion і FT інтерфейси VMkernel на один віртуальний комутатор

Рис 713 Налаштування портів VMkernel для FT

Рис 714 Приклад мережі для FT

Звичайно, ці порти можуть бути створені і на розподіленому віртуальному комутаторі

Наступний крок – сервери повинні бути в кластері HA Якщо це ще не так – зробіть це зараз

Зверніть увагу, що на закладціSummary для кожного сервера у вас має бути зазначено, що VMotion і Fault Tolerance для нього включені (рис 715)

Для перевірки відповідності налаштувань перейдіть на закладкуProfile Compliance для кластера і натисніть посиланняCheck  Compliance Now Вам покажуть статус серверів щодо кластера (рис 716)

Рис 715 Summary для сервера

Висока доступність віртуальних машин

Рис 716 Вбудована перевірка кластера на відповідність вимогам FT

Також у VMware є спеціальна утиліта під назвою VMware SiteSurvey (Http://wwwvmwarecom/support/sitesurvey) Вона здатна завчасно показати, чи годиться наша інфраструктура для включення FT Дається розклад як по кожному серверу, так і по кожній ВМ

Нарешті, ми готові почати користуватися благами FT Для цього виберіть у контекстному меню ВМ пункт Fault Tolerance Turn On (Рис 717)

Рис 717 Включення FT

Якщо в налаштуваннях сервера, конфігурації сервера або конфігурації ВМ є щось, що заважає FT, вам покажуть відповідне повідомлення про неможливість активувати Fault Tolerance для даної ВМ

Якщо все пройшло нормально, то ви побачите зміна іконки цієї ВМ, а на закладціVirtual Machines для кластера побачите і Secondary віртуальну машину (рис 718)

Рис 718 Primary і Secondary ВМ в інтерфейсі vSphere клієнта

Коли FT для ВМ включений, на її закладціSummary показується інформа ція про статус його роботи (рис 719)

Рис 719 Інформація про статус FT для ВМ

Що ми тут бачимо:

Q  Fault Tolerance Status – Показує поточний статус захисту ВМ Варіан ти – Protected і Not Protected В останньому випадку нам покажуть причину:

•&nbsp&nbsp&nbsp Starting – FT в процесі запуску Secondary ВМ

•&nbsp&nbsp&nbsp Need Secondary VM – Primary працює без Secondary Зазвичай таке буває, коли FT вибирає, де включити Secondary Або в кластері немає сервера, сумісного з сервером, де працює Primary В останньому випадку, коли проблема вирішена, вимкніть (disable) і включіть FT заново

•&nbsp&nbsp&nbsp Disabled – Адміністратор відключив FT

•&nbsp&nbsp&nbsp VM not Running – Primary ВМ вимкнена

Q  Secondary location – На якому сервері запущена Secondary ВМ

Висока доступність віртуальних машин

Q  Total Secondary CPU – Скільки мегагерц споживає Secondary ВМ

Q  Total Secondary Memory – Скільки мегабайт памяті споживає Secondary ВМ

Q  vLockstep Interval – На скільки секунд Secondary ВМ відстає від Primary

У більшості випадків цей час не перевищує половини секунди, зазвичай менше 1 мс – але величина цієї затримки залежить від мережі У даному прикладі Secondary ВМ відстає на 8 тисячні секунди

Q  Log Bandwidth – Смуга пропускання, зараз задіяна під трафік

FT цієї ВМ

Для захищеної FT ВМ доступні наступні операції (рис 720):

Q  Turn Off Fault Tolerance – Вимикає FT для ВМ

Q  Disable Fault Tolerance – Відключає FT для ВМ, але зберігає всі налаштування, історію і Secondary ВМ Використовується в разі тимчасового відключення FT для цієї ВМ

Q  Migrate Secondary – Мігрувати Secondary ВМ на інший сервер

Q  Test Failover – Secondary ВМ стає Primary і створює собі нову Secondary Колишня Primary пропадає

Q  Test Restart Secondary – Перестворює Secondary ВМ

Рис 720 Дії з ВМ, захищеної FT

Коли ви включаєте FT для ВМ, vCenter ініціює її VMotion (тобто копіювання вмісту її оперативної памяті) на інший сервер Однак VMotion використовується не для міграції, а для створення такої ж ВМ на іншому сервері, тобто вихідна ВМ не видаляється

Якщо FT включений, в той час як ВМ вимкнена, при включенні віртуальна машина відразу починає працювати на двох серверах

Вибір сервера для включення Secondary здійснює DRS (якщо він включений) І Primary, і Secondary ВМ можна мігрувати за допомогою VMotion, але DRS для цих ВМ вимкнений (тобто видавати рекомендації по їх міграції DRS не буде)

Ми отримуємо дві ідентичні ВМ, два ідентичних процесу на різних серверах Вихідна ВМ називається Primary, її копія – Secondary Події та дані з Primary ВМ безперервно реплицируются на Secondary, по мережі Ця реплікація називається virtual lockstep, або vLockstep Таким чином, стан Secondary ВМ завжди таке ж, як у Primary, з відставанням на незначний час Файли vmx і деякі інші у Secondary свої власні, але створюються вони в тому ж каталозі, де розташовані файли Primary

І Primary, і Secondary ВМ працюють з одними і тими ж дисками Вірніше, Secondary не працює – ESX пригнічує звернення Secondary ВМ до дисків і до мережі для запобігання конфліктів Але коли вона стане Primary – вона почне працювати з ними Важливо розуміти, що це не позначається на цілісності даних, так як єдину копію оновлює Primary ВМ Всі дії, включаючи роботу з цими даними, виконуються і на Secondary ВМ теж Тобто при переході з відмови Secondary ВМ отримає диск саме в тому стані, в якому очікує

Primary і Secondary ВМ обмінюються повідомленнями пульсу (heartbeat) Якщо повідомлення пропали – Secondary негайно підміняє Primary Відразу після цього ініціюється створення черговий Secondary ВМ, і через короткий час після збою дана ВМ знову відмовостійкості за допомогою VMware FT Вибір сервера для нової Secondary здійснює HA

Якщо збій стався в мережі між серверами, то Secondary ВМ перестала отримувати heartbeat-повідомлення Вона спробує стати Primary і отримати доступ до файлів ВМ Однак через збережених блокувань файлів у неї не вийде це зробити, і вона буде знищена Primary ВМ ж створить для себе нову Secondary, так як від старої вона перестала отримувати heartbeat-повідомлення

Якщо Primary ВМ вимикається, то Secondary вимикається Якщо Primary переводиться в стан паузи (suspend), то Secondary вимикається

Primary і Secondary ВМ не можуть працювати на одному сервері, за цим стежить Fault Tolerance Однак вони можуть значитися на одному сервері в вимкненому стані – це нормально

Якщо відмовили одночасно кілька серверів, і в числі них сервери і з Primary, і з Secondary, то ВМ впаде Однак HA перезапустить Primary, після цього FT зробить для неї Secondary

Якщо всередині ВМ трапиться програмний збій, наприклад BSOD, то він отрепліціруется в Secondary ВМ FT не захищає від такого роду проблем Однак у складі HA є компонент VM Monitoring, який здатний перезапустити завислі ВМ

Secondary ВМ витрачає ресурси того сервера, на якому працює Тобто після включення FT для якоїсь ВМ вона починає використовувати в два рази більше ресурсів Це – плата за відмовостійкість HA враховує споживані Secondary ВМ ресурси в своїх розрахунках резервування ресурсів Зверніть увагу,

Висока доступність віртуальних машин

що ресурсів для Secondary ВМ повинно бути в достатку Якщо їх буде не вистачати на роботу з тією ж швидкістю, що і Primary, то робота Primary ВМ сповільниться Доброю аналогією є дві шестерінки на одного ланцюга – якщо друга крутиться повільніше, то і перша буде змушена сповільнитися

Якщо частота процесорів серверів, на яких працюють Primary і Secondary ВМ, відрізняється (не рекомендується різниця більш ніж на 300 МГц), то FT може періодично перезапускати Secondary ВМ через накопичився відставання Якщо перезапуск відбувається регулярно, має сенс спробувати відключити технології пониження енергоспоживання в BIOS серверів, так як ці технології можуть знижувати тактові частоти Деякі джерела рекомендують відключати HyperThreading при траблшутінге FT

FT-трафік між Primaryі Secondary-вузлами містить в собі процесорні інструкції, що виконуються Primary, і необхідні для цього дані Цей трафік може бути значний, особливо коли на сервері працюють кілька FT-захищених ВМ Використовуйте Jumbo frames, задумайтеся про використання 10 Гбіт Ethernet

Всі дані, що надходять на вхід Primary ВМ, пересилаються на Secondary по FT-мережі Це дані, що приходять по мережі, і прочитане з дисків Якщо даних багато, то навантаження на FT-мережа велика У випадку інтенсивного читання з дисків і браку пропускної спроможності FT-мережі добре б відключити цю пересилку – дозволивши Secondary ВМ читати дані безпосередньо з дисків ВМ Це не рекомендується VMware, але можливо Налаштовується це таким чином: у файл vmx виключеною ВМ додається рядок

replaylogReadData =  checksum

Для скасування цієї настройки вимкніть ВМ і видаліть цей рядок Докладніше дивіться у базі знань VMware, стаття 1011965

Намагайтеся розносити захищені FT віртуальні машини по серверам кластера рівномірно, для рівномірного завантаження мережі FT

Якщо під трафік FT виділені кілька фізичних мережевих контролерів, то з налаштуванням за замовчуванням віртуальні комутатори не зможуть збалансувати за ним навантаження Трафік FT (тобто реплікація стану всіх захищаються FT віртуальних машин з одного сервера) йде від одного інтерфейсу VMkernel, від одного MAC-адреси Щоб віртуальні комутатори змогли балансувати трафік FT по різних каналах в зовнішню мережу, необхідно включити метод балансування навантаження за IP-хешу (Route based on IP hash) Цей метод балансування використовує пару IP-джерела – IP-одержувача для розподілу трафіку FT-пари між різними серверами мають різні пари IP-джерело – IP одержувач, і трафік до різних серверів зможе виходити назовні через різні фізичні контролери Нагадаю, що для включення балансування навантаження за IP-хешу необхідно налаштувати etherchannel (8023ad Link aggregation) на портах фізичного комутатора

Зверніть увагу, що включення і відключення FT займають секунди Таким чином, якщо з ВМ необхідно виконати операцію, для FT-захищеної

ВМ неможливу, то можна відключити FT, виконати операцію, включити FT Прикладом такої операції є гаряче додавання будь-якого пристрою, наприклад диска ВМ

vCenter володіє декількома alarm, які відстежують події FT (рис 721)

Рис 721 Alarm для моніторингу подій FT

На закладціPerformance для Primary ВМ доступна інформація за сукупною навантаженні ВМ та її копії (рис 722)

Рис 722 Закладка Performance для FT-захищеної ВМ

Управління оновленнями віртуальної інфраструктури

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*