ІТ-інфраструктура для вашого підприємства
Для додатків без вбудованих засобів високої доступності рішенням може стати віртуалізація, що забезпечує високу доступність на рівні віртуальної машини. Цей підхід дозволяє автоматично перезапустити віртуальну машину на іншому вузлі віртуалізації в разі незапланованого перемикання ресурсів. Також можливе перенесення віртуальних машин між вузлами без простоїв в планових ситуаціях, наприклад при технічному обслуговуванні. Ці рішення забезпечують перемикання ресурсів на рівні вузла (якщо один з вузлів відмовляє).
Однак в разі природних катаклізмів (наприклад, нещодавнє повне відключення центру обробки даних) або аварій, викликаних діяльністю людини (таких як розрив резервних каналів зв'язку з Інтернетом при проведенні дорожніх робіт), центр обробки даних може виявитися відрізаним від решти світу. Компанії повинні скласти плани робіт навіть на випадок втрати основного центру обробки даних.
Якщо у компанії є запасний майданчик для центру обробки даних, то багато раніше згадані технології рівня додатків можуть охоплювати кілька місць. Багато рішень, такі як використання декількох контролерів домену, і додатки, розраховані на відмовостійкий кластер, функціонують з урахуванням географічної інформації. Однак у традиційній відмовостійкої кластеризації Windows, яка застосовується до віддалених майданчиків, є недолік. У багатьох додатках, що використовують кластеризацию, і у всіх віртуальних кластерах загальне сховище повинне бути доступно всім вузлам кластера. В цілому цей підхід пов'язаний з більш високими витратами, так як потрібні мережі зберігання даних (SAN) в обох місцях, хороший зв'язок між майданчиками і реплікація сховищ для синхронізації вмісту в обох SAN.
Більшість рішень реплікації SAN-SAN синхронні: операція запису в основний SAN підтверджується для процесу запису, тільки якщо запис виконується в репліці SAN. Таким чином забезпечується безперервна синхронізація сховищ обох SAN. Синхронна реплікація дає найнадійніший захист, але обходиться недешево.
Знайомство з Hyper-V Replica
У деяких SAN також передбачена асинхронна реплікація даних з основного вузла в репліку, але не в реальному часі. Дії записи виконуються на основному вузлі, підтверджуються для процесу запису, а потім реплицируются, коли можливо. Існує затримка між записом на основному вузлі і на репліці. Залежно від затримки на сервері репліки може не виявитися певної кількості даних, які будуть втрачені в разі відмови основного вузла. Можливий пропуск часто називають цільової точкою відновлення recovery point objective (RPO). По суті, він визначає максимальний розмір втрати даних, прийнятний при аварії. Наприклад, значення RPO, рівне 5 хвилинах, означає, що будуть втрачені дані не більше ніж за 5 хвилин.
Асинхронна реплікація на рівні SAN для багатьох компаній небажана, так як для основного майданчика і репліки потрібно один і той же постачальник. Але Hyper-V Replica використовує асинхронну реплікацію дуже ефективно. На верхньому рівні Hyper-V Replica функціонує наступним чином.
- Коли віртуальна машина підготовлена для реплікації, створюється нова віртуальна машина на вузлі репліки Hyper-V. Віртуальна машина-репліка має таку ж конфігурацію, як основна віртуальна машина; вона відключена.
- Сховище основний віртуальної машини реплицируется в віртуальну машину-репліку на сервері репліки Hyper-V. На основному вузлі Hyper-V формується журнал для збереження записів на реплікованих віртуальних жорстких дисках (VHD). Файл журналу зберігається в тому ж місці, що і вихідний VHD.
- Після завершення початкової реплікації сховища файл журналу закривається. Формується новий файл журналу для відстеження поточних змін; закритий файл журналу відсилається на вузол репліки Hyper-V і об'єднується з віртуальними жорсткими дисками для репліки віртуальної машини. Репліка віртуальної машини залишається відключеною.
- Через кожні п'ять хвилин файл журналу закривається, створюється новий, а закритий файл об'єднується з реплікою.
Завдяки асинхронної реплікації в Hyper-V Replica реплікація стає можливою у багатьох компаніях і сценаріях аварійного відновлення:
- реплікація між центрами обробки даних для додатків рівня 1 в компаніях без реплікації на рівні SAN (малі і середні компанії);
- реплікація між центрами обробки даних для додатків рівня 2 в компаніях з реплікацією на рівні SAN, але не бажають використовувати її для додатків, відмінних від рівня 1;
- реплікація філія-головний офіс для захисту додатків, розміщених у філії;
- реплікація між постачальниками послуг хостингу;
- реплікація на постачальника послуг хостингу для аварійного відновлення у невеликих компаніях, які не мають другого центру обробки даних.
Існує і безліч інших можливих сценаріїв. Головне, що завдяки Hyper-V Replica реплікація віртуальних машин доступна будь-якої компанії.
Використання Hyper-V Replica
Налаштувати Hyper-V Replica нескладно. Найпростіший спосіб зрозуміти принципи роботи Hyper-V Replica - пройти по етапах настройки і включити реплікацію для віртуальної машини.
Перший крок - налаштувати сервер Hyper-V Replica для прийому запитів на розміщення репліки. У диспетчері Hyper-V виберіть Hyper-V Settings (параметри Hyper-V) зі списку дій сервера. У Hyper-V Settings виберіть список Replication Configuration (параметри реплікації), як показано на екрані 1. Встановіть прапорець Enable this computer as a Replica server ( «Використовувати цей комп'ютер як сервер репліки»). Потім потрібно виконати кілька налаштувань.
Екран 1. Налаштування цільового сервера Hyper-V на прийом реплік
В першу чергу - задіяти Kerberos (використовує протокол HTTP) або перевірку автентичності на основі сертифікатів (протокол HTTP Secure - HTTPS). Kerberos налаштувати простіше, але при цьому потрібно, щоб як основний сервер Hyper-V, так і репліка використовували перевірку достовірності Kerberos і тому входили в один ліс Active Directory (AD) або довірені домени. При використанні Kerberos дані, реплицируемой між основним сервером і реплікою, що не шифруються, а передаються як зазвичай через HTTP-порт 80. Але якщо потрібно шифрування, то можна використовувати реалізацію IPsec для Windows.
Другий варіант - застосувати перевірку справжності на основі сертифікатів. У цьому випадку основний сервер і репліка можуть бути членами різних лісів AD або організацій, але при цьому необхідно вказати сертифікат. Додаткова перевага HTTPS - шифрування всіх даних, що пересилаються. Якщо включити як Kerberos, так і перевірку автентичності на основі сертифікатів, то при створенні нового відносини реплікації адміністратор, що налаштовує реплікацію, може вибрати будь-який метод.
Єдиний параметр - вказати сервери, з яких репліка буде приймати запити на реплікацію, а також місце зберігання цих реплік. Один варіант - дозволити реплікацію з будь-якого сервера, який пройшов перевірку автентичності. У цьому випадку виберіть одне місце для зберігання всіх реплік. Інший варіант - вказати сервери, які можуть виконувати реплікацію на сервер-репліку; кожного серверу можна призначити окреме сховище.
Призначаючи сервери, можна використовувати один (!) Універсальний символ в імені сервера. Таким чином можна охопити групу серверів; наприклад, * .na.savilltech.net для всіх серверів з повним ім'ям FQDN, що завершується на na.savilltech.net. За допомогою тега Trust Group можна переміщати віртуальні машини між вузлами Hyper-V з однаковою групою довіри і продовжувати реплікацію. За допомогою Shared Nothing Live Migration можна переміщати віртуальні машини між некластерізованний вузлами Hyper-V без простоїв. При використанні цього нововведення в способах перенесення необхідно, щоб групи серверів мали однаковий тег Trust Group, щоб забезпечити бездоганну реплікацію після переміщення віртуальних машин між серверами в групі довіри.
Останній крок - призначити необхідні виключення брандмауера для використовуваного порту: 80 для HTTP і 443 для HTTPS. Виключення брандмауера вбудовані в Windows Server, але не включені, навіть після завершення налаштування реплікації. Необхідно запустити брандмауер Windows за допомогою адміністративного кошти Advanced Security, вибрати Inbound Rules ( «Правила для вхідних підключень») і включити прослуховувач Hyper-V Replica HTTP Listener (TCP-In) і / або прослуховувач Hyper-V Replica HTTPS Listener (TCP-In ), в залежності від методу перевірки автентичності.
Коли сервер репліки готовий до реплікації, важливо також включити основний сервер Hyper-V як репліку. Це дозволить виконати зворотну реплікацію, якщо віртуальна машина активована на сервері репліки і повинна почати реплікацію на колишній основний сервер (який в цьому випадку вважається реплікою).
Вказувати мережу для передачі трафіку реплікації не потрібно. Передбачається, що технологія використовується для передачі даних між центрами обробки даних. Між ними є тільки один правильний шлях до секретного, тому Hyper-V Replica автоматично вибирає потрібну мережу для трафіку реплікації. Підозрюю, що декому хотілося б більшої свободи у виборі мережі для Hyper-V Replica; якщо для вас це важливо, відправте свій відгук в компанію Microsoft.
Реплікація віртуальної машини
Наступний крок після того, як вузли та кластери Hyper-V налаштовані на роботу з компонентом Hyper-V Replica, - підготувати віртуальні машини до реплікації. Використовуйте Hyper-V Manager або Windows PowerShell (особливо при автоматизованій груповій налаштування). Вкажіть віртуальну машину, для якої потрібно включити реплікацію, а потім виберіть дію Enable Replication ( «Включити реплікацію»). В результаті запуститься майстер настройки реплікації, що складається з декількох кроків.
Вказавши цільової сервер Hyper-V, виберіть тип перевірки автентичності. Він визначається типом реплікації, що виконується сервером. Також вкажіть, чи потрібно стискати дані, що передаються по мережі; при стисненні скорочується час передачі по мережі, але зростає навантаження на процесор як на основному сервері Hyper-V, так і на репліці. Якщо у віртуальної машини кілька віртуальних жорстких дисків, то можна вибрати жорсткі диски для реплікації. Таким чином можна домогтися, щоб реплицироваться тільки потрібні жорсткі диски (тобто містять більше одного файлу підкачки). Реплікуються тільки віртуальні жорсткі диски; за допомогою Hyper-V Replica можна реплицировать фізичні диски, до яких віртуальна машина звертається безпосередньо (ще одна з причин, за якими слід уникати безпосереднього звернення до фізичних дисків).
Наступний крок - настройка журналу відновлення. За замовчуванням існує єдина точка відновлення репліки: найостанніше стан реплікації. Однак можна підготувати розширений журнал відновлення з додатковими погодинними точками відновлення, як показано на екрані 2.
Екран 2. Налаштування журналу відновлення для репліки віртуальної машини
Якщо віртуальна машина містить додатки з модулями записи VSS, рекомендується використовувати цей режим для створення точки відновлення узгодженого стану додатків. Прийняте за замовчуванням значення забезпечує баланс між цілісністю і додатковими зусиллями для створення точки відновлення на вихідної віртуальній машині.
Після завершення налаштування точки відновлення необхідно вибрати метод початкової реплікації сховища:
- передати вміст VHD через мережу;
- передати вміст VHD з використанням зовнішнього носія; вказати місцезнаходження для експорту вмісту.
- використовувати існуючу віртуальну машину на сервері репліки в якості початкової копії. Цей варіант можна задіяти, якщо ви вже відновили віртуальну машину на цільовому сервері Hyper-V або раніше включили реплікацію і отримали репліку, а тепер хочете знову активувати її. Щоб забезпечити узгодження, буде виконано дуже корисне побітовое порівняння між основною копією і реплікою.
Можна налаштувати негайний або відкладений запуск початкової реплікації в зазначений час; наприклад, в неробочі години, коли потреба в мережевих ресурсах знижується. Залежно від вибору адміністратора, віртуальна машина створюється на сервері репліки Hyper-V в відключеному стані, і початкова реплікація стартує. Через кожні п'ять хвилин файл журналу Hyper-V Replica (.hrl) закривається, пересилається в репліку і об'єднується з VHD репліки. Протягом усього цього часу репліка віртуальної машини відключена. Тільки вміст диска, але не стан пам'яті, процесора або пристроїв, копіюється в репліку віртуальної машини. Якщо репліка активується, вона буде включена і завантажена в стані, відповідному аварії, як ніби вона запущена без попереднього чистого закриття. Це одна з причин, за якими для цілісності диска корисно періодично формувати точки відновлення і використовувати моментальний знімок VSS.
Створена репліка віртуальної машини існує окремо від основної віртуальної машини. Будь-які зміни в налаштуваннях основний віртуальної машини не відображаються в репліці віртуальної машини. Це дозволяє вносити зміни в будь-яку віртуальну машину, а реплікація вмісту VHD продовжиться.
Використання Hyper-V Replica
Пам'ятайте, що Hyper-V Replica - рішення для відновлення після аварії. Компонент не призначений для застосування замість відмов кластерів або інших технологій високої доступності. Зазвичай у разі аварії доводиться виконувати безліч дій і процесів, щоб активувати сайт відновлення. Hyper-V Replica - не автоматизовані рішення. Воно не виявляє відсутність віртуальної машини на основному вузлі і запускає віртуальну машину на сервері репліки, так як неправильне визначення збою сайту може створити проблеми. Компонент необхідно ініціювати вручну, однак немає ніяких причин, що заважають автоматизувати його за допомогою PowerShell в рамках інших процесів. Можливо, надалі компонент буде автоматизовано через будь-яке рішення управління від Microsoft, наприклад System Center Virtual Machine Manager, щоб забезпечити перемикання декількох віртуальних машин в рамках більшого процесу відновлення сайтів.
Існує три типи відпрацювання відмови Hyper-V Replica - один для тестування і два для практичних цілей.
* Тестова відпрацювання відмови. Запускається на репліці віртуальної машини. Потім репліка віртуальної машини може бути запущена на вузлі репліки Hyper-V. Для цього потрібно підготувати тимчасову віртуальну машину на основі обраної точки відновлення, а потім в процесі тестування переконатися, що реплікація працює, як заплановано. У хоті тестування відпрацювання відмови основна віртуальна машина продовжує посилати поновлення журналу репліці віртуальної машини. Ці оновлення об'єднуються з віртуальними жорсткими дисками репліки, що дозволяє продовжувати реплікацію. Після закінчення тестування тимчасова віртуальна машина видаляється.
* Планова відпрацювання відмови. Запускається на основний віртуальній машині і є кращим типом відпрацювання відмови. При цьому основна віртуальна машина відключається, і реплікуються будь-які зміни, щоб не було втрат даних, а також автоматично перемикається на репліку віртуальної машини. Хід реплікації змінюється на протилежний, щоб зміни пересилалися в зворотному напрямку, а потім запускається репліка віртуальної машини. Ця віртуальна машина стає основною, а колишня основна віртуальна машина стає реплікою.
У відпрацювання відмови з використанням сайту відновлення в іншому місцезнаходження є недолік: конфігурація TCP / IP віртуальної машини навряд чи придатна для роботи в іншому місці розташування, яке майже напевно знаходиться в іншій підмережі. Hyper-V Replica має додаткової конфігурацією TCP / IP у віртуальній машині при включеній реплікації. Ця конфігурація (на конфігурацією мережного адаптера віртуальної машини) дозволяє вказати альтернативні параметри IPv4 або IPv6 для репліки віртуальної машини. Мережева конфігурація вводиться в віртуальну машину в процесі відпрацювання відмови, як показано на екрані 4.
Екран 4. Завдання альтернативної конфігурації IPv4 для віртуальної машини
Реплікація для відновлення
Поділіться матеріалом з колегами і друзями