Як я перестав хвилюватися і полюбив реплікацію Hyper-V

Можливо, це дивно, але в перші дні на роботі після новорічних канікул, коли всі впало за свята вже успішно повернуто до життя, у багатьох виникає бажання якось впорядкувати інформацію в своїй голові, щоб привести її до систематизованого вигляду. Хорошим каталізатором цього процесу є усвідомлення факту, що начебто і маєш багажем знань, але бабусі з вулиці або шестирічному дитині в простих словах цей багаж ну ніяк не вийде пояснити. Бо, як говорить народна мудрість, не зміг пояснити дитині — значить, сам не знаєш. Та й взагалі, дефрагментація інформації ще нікому не шкодила.
Але у нас не курс прикладної психології, тому сьогодні я просто викладу в систематизованому вигляді набору пікселів максимальна кількість корисної інформації про функції реплікації віртуальних машин в середовищі гіпервізора Hyper-V на прикладі поточної версії Windows Server 2012 R2.

Отже, на що я хочу витратити приблизно годину вашого часу:
  • Треба зрозуміти, навіщо взагалі потрібна реплікації в умовах сучасного світу
  • Скласти чек лист з очевидних і не дуже пунктів, що передують налаштування серверів
  • Як правильно і швидко налаштувати реплікацію вбудованими засобами. Досить докладно, але без води
  • Кілька порад по оптимізації процесу реплікації.
  • Ні слова про продукти Veeam або інших вендорів.

Акт перший. Оглядовий.

Значення терміна «реплікація віртуальних машин» нічим не відрізняється від загальноприйнятого в IT значення слова «реплікація»: на сторонньому хості створюється і підтримується копія ВМ з основного хоста.

Давайте відразу домовимося: реплікація — це не бекап! Як снапшоти не бекап, рейди не бекап, і взагалі нічого не бекап крім бекапу, бо якби дідусь був бабусею

Але краще все ж на всякий випадок поясню, чому «не бекап»: у разі виходу з ладу основної машини завжди можна без затримки включити репліку, але якщо вихід з ладу був спровокований не сьогочасної помилкою, а комплексом накопичених проблем на рівні ОС або додатків, то всі вони будуть успішно відображені на репліці, і нічого доброго у вас не вийде. Незліченно кількість випадків, коли після включення реплікованої ВМ вона працює кілька хвилин і вмирає слідом за своїм батьком з тими ж симптомами.
Таким чином, реплікація — це прекрасний інструмент для розширення вашого плану катастрофостійкості, що дозволяє повернути всі ваші сервіси в бойовий стан з мінімальною затримкою в часі, але не можна на нього перекладати всю відповідальність, оскільки ніщо не зовсім і скрізь є мінуси.
Реплікацію віртуальної машини Hyper-V як процес можливо здійснити трьома шляхами:
  • Вбудованими засобами гіпервізора.
  • За допомогою стороннього софту. Тут цікавий факт укладено в ігноруванні цієї функції деякими вендорами без видимих причин.
  • За допомогою засобів SAN. Безсумнівно, метод найбільш цікавий, швидкий та інша..., але вкрай дорогою.


Як було обумовлено в самому початку, ми будемо розглядати тільки перший пункт — а саме реплікацію Hyper-V машин вбудованими засобами Windows Server 2012 R2. Дозволю собі зауважити, що саме R2 т. к. між першим і другим релізом лежить функціональна прірву, і використовувати не R2 версію гіпервізора в продакшн середовищі практично моветон.

Отже, що ж нам пропонує Microsoft з коробки:
  • Реплікація з допомогою асинхронного копіювання змінених даних з батьківської машини на репліковану. Асинхронне — значить, дані не передаються негайно після зміни оригінальних даних, а через деякі проміжки часу, що дозволяє не «перенапружувати» машину-джерело і канал передачі. У даний момент мінімальний період реплікації дорівнює 30 секундам.
  • Для реплікації Hyper-V машин не треба мати спеціальних поділюваних сховищ або дотримуватися одноманітності обладнання для зберігання на джерела і приймачі
  • Все, що може бути виртуализовано, можна повторити.
  • Реплікація відбувається за звичайним IP мереж і, у разі необхідності, трафік може бути зашифрований.
  • Hyper-V реплікація можлива як між окремими хостами, так і між кластерами. І навіть змішаний варіант можливий без обмежень.
  • Хости, між якими відбувається реплікація, можуть перебувати де завгодно, в будь-яких мережах і належати до різних доменів.


Чек-лист, поки не стало пізно

  • Пункт перший і очевидний, але часто упускається: переконайтеся, що сервер, на який піде реплікація, має Hyper-V-сумісний залізо. Інженерам властиво запускати все, що завгодно, на що завгодно, але повірте, що це не той випадок. Абсолютно не той. Апаратна підтримка віртуалізації строго повинна бути в обов'язковому порядку.
  • Другий очевидний пункт: розрахуйте, скільки вам знадобиться місця на приймаючому сховище, і перевірте швидкість його роботи. Знімаючи з далекої полиці хранилку епохи динозаврів, ви ризикуєте побачити загальну швидкість передачі даних на рівні тієї ж епохи, незважаючи на всі ваші мережні гигабиты.
  • Наслідок попереднього пункту: на підставі періоду реплікації усередненої віртуальної машини прикиньте, скільки буде важити кожна точка реплікації і скільки таких точок ви можете собі дозволити. Максимальна кількість, доступне на даний момент — це 24 точки відкату.
  • Якщо планується тиражувати машини, які є частиною Hyper-V кластера, то треба встановити і налаштувати роль Replica Broker в кластері. Якщо на приймаючій стороні є кластер — треба повторити.
  • Перевірте налаштування фаєрволом і роутинг на всьому маршруті між хостами. Якщо за мережу відповідаєте не ви, то знайдіть вашого сетевика і мучте його розпеченим залізом, поки він не вибудує найкоротший і найшвидших маршрут між хостами. З фаерволами все простіше: нам потрібен 80 порт для Kerberos over HTTP 443 для certificate-based over HTTPS. Само собою, порти можна поміняти в процесі налаштування.
  • Якщо ви плануєте шифрувати трафік між хостами, то вам знадобляться сертифікати, і потрібно заздалегідь розкласти їх по всім зацікавленим серверів. І не відкидайте ідею перевірити сертифікати на термін придатності, а центри сертифікації внести в довірені, якщо використовуєте самоподписные.
  • Проінспектуйте всі ваші віртуальні машини на предмет використовуваних VHD. Маєте всі шанси виявити диски, які абсолютно не треба повторити, що заощадить вам час і гроші.
  • Складіть список додатків, для яких важлива консистентним даних. Перевірте здоров'я VSS системи як на хостах, так і всередині гостьових ОС. Якщо ваші програми не використовують VSS (наприклад, не самі старі версії Oracle), їм доведеться приділити окрему увагу.
  • Продумайте час для першого проходу реплікації. При першому прогоні через мережу буде передана вся машина, — і, природно, хочеться це зробити поза межами робочого часу. Якщо приймає хост знаходиться за межами локальної мережі, ви ризикуєте не встигнути закінчити передачу за ніч або вихідні та вранці отримати сильно завантажений канал зв'язку і дуже завантажений хост. Як уникнути такої ситуації, буде написано трохи нижче.
  • Врахуйте, що реплікація в Hyper-V можлива не тільки між двома хостами, але і з використанням проміжних серверів. Отака багатоходова реплікація.
  • Проаналізуйте ваш поточний план резервного копіювання на предмет сумісності з планом реплікації. Думаю, нікому не сподобається ситуація, коли під час бекапу запуститься ще і реплікації. Ваш хост цілком може не пробачити вам таке навантаження. Так само варто відповісти на запитання, що буде, якщо ви відновите машину з бекапа: чи потрібна вам репліка у вигляді машини до аварії, чи треба швидше привести її до консистентному увазі.


Вважаю, що так само справедливо буде згадати інструмент від Microsoft, що дозволяє з певною часткою похибки підрахувати необхідні для реплікації окремо взятої віртуальної машини ресурси. Називається він Capacity Planner for Hyper-V Replica Звичайно, ви не отримаєте точну кількість IOPS, навантаження на мережу і процесор, але як оціночний інструмент він досить непоганий і дозволить проаналізувати вашу інфраструктуру заздалегідь.

При запуску вас попросять вказати основний сервер, сервер для реплікації, машини, які належить обробляти і час проведення вимірювань. Рекомендую змінити встановлені за замовчуванням 30 хвилин в бік збільшення до години. І, звичайно, оптимальний час для запуску — це самий розпал робочого дня. Зібраними даними можна дуже здорово лякати начальство і просити грошей на нові игруш… залозки.

Акт другий. Настроювальний.

І ось настав відповідальний момент! Сертифікати є, мережа налаштована, скрізь працює Hyper-V роль, не забуті інструменти управління, і ми можемо приступати.
Першим ділом треба дозволити нашому хосту виступати в якості сервера реплікації і приймати машини на борт. Робиться це через вікно стандартних налаштувань Hyper-V:
image

Всі налаштування прозорі, але я хочу трохи загострити увагу на нижній секції Authorization and storage. Це не критично, але дуже рекомендую дозволяти реплікацію тільки з певними хостами або групами хостів. Не часто, але бувають випадки, коли помилково або від незнання запускається помилкова реплікація — і добре, якщо це запасний хост, а може статися забивання сховища бойового з усіма подальшими розвагами. Дозволяти все підряд — доля лабораторій для тестувальників і розробників. Ну або просто сміливих людей =)

Кличемо брокера

Оскільки на самому початку ми домовилися, що інфраструктура у нас як у дорослих (тобто налаштований і успішно працює кластер), то нам необхідно включити роль брокера реплік Hyper-V. Якщо ж кластера у вас немає, то можете сміливо пропускати цей параграф.

Процедура активації проста і включає в себе 5 кнопок Next і одну Finish. Пояснювати тут нема чого, тому просто йдемо в майстер управління кластером, вибираємо Configure Role і проходимо майстра, не забувши дати NETBIOS відповідне ім'я і вказати IP.

Невеликий хинт для тих, хто спочатку читає документацію, а потім робить, хоча справжні інженери так не роблять, — все описане в попередньому параграфі, можна зробити безпосередньо з брокера лише з тією різницею, що налаштування будуть застосовані відразу на весь кластер і не доведеться вручну дозволяти реплікацію на кожному сервері. Як бачите, виглядає все так само:


І невелике пояснення про роль брокера в процесі реплікації — при реплікації машин, що не беруть участь в High Availability кластері, брокер ніяк не задіюється. Але коли мова заходить про кластеризовані машини, він повністю забирає на себе управління всіма процесами, пов'язаними з реплікацією і кластеризацией, не даючи кластеру прийняти невірне рішення про доступність машин. Тому золоте правило — з цього моменту дії ви повинні робити тільки через консоль Failover Cluster Manager, інакше ви ризикуєте залишитися без кластера. Навіть якщо на бойовий хост впаде метеорит, найгірше, що ви можете зробити в цій ситуації — це включити репличную машину через Hyper-V Manager.

Перший пішов

Тепер нарешті-то ми дійсно готові повторити нашу саму першу машину. Як і все в Windows, робити це ми будемо через праву кнопку миші:


Далі відкривається досить стандартний майстер налаштувань, де на перших кроках нас запитують ім'я сервера (куди буде реплицирована машина) і просять уточнити параметри підключення. Вірніше, якщо хости знаходяться в одному домені, то все буде заповнено без нашої участі, а от якщо сервер не знайомі, та ще треба зашифрувати трафік, то доведеться всі параметри вказати вручну. Єдина галочка, заслуговує уваги на цьому кроці — «стискати дані передаються». Тут ми звертаємося до стадії планування і дивимося, що нам важливіше: стискати інформацію та швидше закінчити передачу даних (що неминуче викличе додаткове навантаження на хости), або нам не важливий обсяг і тривалість передачі, т. к. в пріоритеті продуктивність хоста. Два нудних скріншота:




На наступному кроці необхідно вибрати диски, які будуть брати участь у реплікації. В кінці статті, коли піде мова про загальну оптимізацію, я наведу кілька порад, а поки що варто запам'ятати одну деталь — диск, не зазначений для реплікації, буде повністю відображатися на приймаючій стороні, тобто він виключається з конфігурації віртуальної машини. Якщо без цього диска машина не може функціонувати, але на ньому зберігається щось неважливе (зразок тимчасових файлів), то просто створіть заново цей диск на реплікованої машині.


Потім знову звертаємося до етапу планування і виставляємо вибраний період реплікації. Якщо через непорозуміння ви все ще використовуєте Server 2012, то вас навіть не спитають, а просто виставлять значення в 5 хвилин. З часом Microsoft прийшли до висновку, що така поведінка не зовсім правильне, і в Server 2012 R2 додали можливість вибору з 30 секунд, 5 і 15 хвилин. Не фонтан, звичайно, але краще, ніж нічого.

Та будьте дуже обережні, вибираючи 30-ти секундний інтервал — вам знадобиться дійсно дуже сильний хост, з дуже швидкою мережею і дуже швидким сховищем.


Наступний відповідальний крок — вказуємо, скільки точок відновлення ми будемо зберігати. Тут же вказуємо, з якою періодичністю будуть створюватися VSS снапшоти. В принципі, можна чудово обходитися і без них, але тоді ніхто не зможе вам гарантувати консистентним даних з усіма випливають наслідками, особливо якщо мова йде про програми, для яких вона критична.
Приклад на скріншоті можна інтерпретувати на російську таким чином, нам необхідно створювати точки відновлення щогодини, зберігати її 24 години (це максимальне значення) і раз в 4 години створювати VSS снапшот. Погоджуся з тим, що не сама прозора і зручна для розуміння конструкція, але, що є, з тим і працюємо.


Слідом йде дуже корисний пункт для тих, у кого ну дуже великі машини або просто немає можливості передавати великі обсяги даних по мережі. Як ми пам'ятаємо, при першому запуску з хоста на хост повинен бути переданий весь обсяг реплікованої машини, і нам на вибір пропонується аж три варіанти, як ми можемо це зробити:
  • Безпосередньо по мережі з зазначенням часу старту процесу. Варіант за замовчуванням, додаткових коментарів не потребує.
  • найцікавіший, на мій погляд, варіант. Якщо його вибрати, в перший момент часу на передавальному хості буде створено і збережено в окрему папку машина-клон. Папка буде наименована за шаблоном <VMname_GUID>. Ця ж машина буде реплицирована у вигляді пустушки на приймаючій стороні. Далі папку з фейкової машиною можна і потрібно скопіювати на зовнішній носій і перенести ближче до другого хосту. На другому хості у машини-пустушки з'явиться новий пункт в меню: Import Initial Replica, тобто машина перебуватиме в очікуванні справжніх даних. Нас попросять вказати шлях до папки з даними, вони будуть скопійовані на місце постійної служби, запустяться внутрішні процеси узгодження, і на цьому прохід першої репліки можна вважати завершеним. Безсумнівно, чим довше диск з даними буде подорожувати між хостами, тим більшою буде різниця між машинами, тому не варто затягувати цю подорож.
  • І третій варіант: коли на приймаючій стороні вже є копія віртуальної машини. Ви просто вказуєте цю машину, і далі вона буде використана як опорна. Як таке може бути? Наприклад, вона була відновлена з бекапа. Чи залишилася від попередньої реплікації. Не важливо, головне, що ця машина може бути використана як опорна, і по мережі будуть передані тільки неспівпадаючі дані.


Потім нам запропонують окинути поглядом все введені налаштування і підтвердити своє бажання кнопкою Finish. Нам скажуть, що все пройшло добре, і запропонують змінити мережеві настройки для реплік, т. к. за замовчуванням вони не підключені ні до однієї мережі (згоден, що це дуже несподіване місце для такої пропозиції), але мені здається, що краще питання мережі пояснити на практичних прикладах, які будуть далі, а поки перейдемо до розширеної реплікації Hyper-V машин.

Розширюємо широту наших глибин

Як і багато інші цікаві функції, розширена реплікація віртуальних машин з'явилася тільки в Windows Server 2012 R2. Розширена реплікація дозволяє налаштовувати реплікацію не тільки за принципом «точка-точка», але й вибудовувати цілі ланцюжки, коли після проходу реплікації з головного сервера (назвемо це основний реплікою), запускається процес реплікації репліки (масло масляне, але краще не скажеш) на третій хост.

І, якщо багатьом не зовсім ясно, навіщо взагалі потрібна реплікація, то наявність можливості створення ланцюжка реплікації, ймовірно, здатна остаточно заплутати навіть найстійкіших. Однак пропоную на ваш суд ось такий, не вигаданий приклад. Припустимо, що у вас досить велика компанія з декількома серверними в одному будинку, і ви налаштовуєте реплицирование кожні 30 секунд, щоб у разі прориву каналізації і затоплення серверів мати можливість швидко включити копії ваших віртуальних машин з мінімальними втратами даних. Це відмінна схема, але, на жаль, вона ніяк не захищає від повного знеструмлення будівлі або трактора, перегрызающего оптичні канали, які підходять до будівлі. На такий випадок дуже хочеться мати копії машин десь на стороні, оновлювані, нехай і не кожні 30 секунд, але хоча б раз в 15 хвилин, щоб не дозволити вам впасти в бруд обличчям.

Тут варто визначити правила для проведення розширеної реплікації віртуальних машин:
  • Частота розширеної реплікації не може бути менше основний тобто якщо основна відбувається раз на 5 хвилин, розширена не може відбуватися кожні 30 секунд
  • Частота створення VSS снепшотов не може бути змінена
  • не Можна поміняти список дисків беруть участь в реплікації
  • Однак можна змінити методи аутентифікації і спосіб проходу першої репліки


Майстер налаштування розширеної реплікації викликається традиційно правим кліком по реплікованої машині і вибором пункту Extend Replication. Подальша настройка відбувається точнісінько як у випадку із звичайною, тому розглядати її окремо сенсу немає.


І ось ми всі успішно налаштували, запустили і перевірили, тому пропоную перейти до розгляду поведінки у разі аварії зробивши невелику зупинку біля мереж.

Трохи про мережах

Достеменно не відомо, зайва це параноя чи ні, але прийнято всі репліки підключити до ізольованої мережі, яка ніяк не перетинається з виробничою. А часто у адміністратора і зовсім немає вибору, т. к. в дата центрі на приймаючій стороні використовуються інші підмережі, і репліки повинні бути абсолютно інші мережеві настройки.

І, як ми можемо бачити на скріншоті нижче, Hyper-V надає нам можливість вказати точні налаштування кожного мережевого адаптера на випадок аварійного включення. Яке, до речі називається failover, і ми поговоримо про нього прямо зараз.


Страшне слово Фейловер

Почну з пояснення терміна Failover, т. к. адекватного перекладу на мову Пушкіна і Толстого ще не придумали. Фейловером називається процесправильного (читай керованого) включення, оперування і виключення реплікованої машини. Приклад неправильної поведінки: з панелі управління хостом або кластером машина включається по кнопці Start. В цьому випадку ми отримуємо гарантований крах реплікації, з подальшою налаштуванням заново, і весь набір веселих проблем, властивих наявності двох однакових машин в одній інфраструктурі.

Отже, фейловер буває трьох видів:
  • Запланований
  • Тестовий
  • Аварійний (або просто фейловер, без приписок)


Плановий фелойвер

Використання запланованого фейловера, передбачає, що заздалегідь відомо про можливих проблеми з основним хостом. Наприклад, проводитимуться роботи з мережами харчування, на вас рухається ураган, необхідно вимкнути хост для обслуговування або робочі вранці вирішили длубатися в землі в небезпечній близькості від підвідних кабельних трас.

В даному варіанті присутній невеликий простий сервісів, рівний часу вимикання основної машини і завантаженні репліки, але те, що перемикання здійснюється планово, дає можливість підібрати найбільш зручний для всіх час.

Важливий момент — реплікація може бути продовжена у зворотному режимі, тобто всі зміни, зроблені на стороні репліки, при її виключенні будуть передані на основну машину. Це дозволяє повністю виключити втрату даних.
Отже, як відбувається запланований фейловер:
  1. Вимикаємо основну віртуальну машину. Зробити це можна тільки вручну, щоб уникнути помилкового відключення. Поки машина не буде повністю виключена, майстер фейловера буде показувати відповідну помилку.
  2. Там же, на основному хості, клікаєм по вимкненій машині і вибираємо Planned Failover
  3. За замовчуванням пункт Reverse the replication direction after failover, що забезпечує зворотний реплікацію, не відзначений, і, якщо вам не хочеться втрачати дані, накопичені за час роботи машини в режимі фейловера, варто відзначити цей пункт. Важливе зауваження — на основному хості повинно бути встановлено дозвіл про прийняття реплік, про що говорилося на самому початку, інакше дані просто не будуть прийняті.


Запускаємо процес фейловера і перевіряємо мережеву доступність піднятою машини для користувачів. Тут найбільш часті помилки — це невірно вказаний VLAN і відсутність відповідної DNS записи. Ні те, ні інше майстер фейловера не перевіряє, залишаючи це на розсуд адміністратора.

Найцікавіше в цій ситуації — це те, як відбувається зворотне перемикання: нам треба повторити фейловер, але на цей раз з боку другого хоста, тобто треба вимкнути на ньому репліку і зробити її плановий фейловер. Рішення більш ніж дивне, але що є — то є.

Тестовий фейловер

Саме той випадок, коли назва відповідає функціоналу. Репліки, як і бекапи, хочеться перевіряти, щоб спати трохи більш спокійно. А кращий спосіб перевірити репліку — це включити її. На перший погляд може здатися, що це інша назва запланованого фейловера, проте це не так.

При виконанні тестового фейловера на стороні репліки створюється тимчасова машина, на якій можна виконувати різноманітні тести. Наприклад, перевірити телнетом набір портів, і у випадку позитивної відповіді бути впевненим, що сервіси на цих портах запущені успішно. Один нюанс — за замовчуванням віртуальна машина в тестовому фейловере запускається не підключеної до мережі. Тому першим кроком вказуємо загальні мережеві налаштування на випадок фейловера, пере-відкриваємо майстер і бачимо новий пункт меню:


Або більш цікавий варіант: подивитися, як поведе себе критичне для бізнес процесів додаток після установки нового патча, не забувши вивести машину в спеціально підготовлену ізольовану мережу.

Само собою, тестовий фейловер треба запускати на стороні репліки. Процес повністю повторює плановий фейловер, з тією лише різницею, що після виконання всіх необхідних процедур його необхідно зупинити. Інакше машина так і буде працювати, поки рано чи пізно не розростеться на весь диск.

Аварійний фейловер

Тут є тільки одне золоте правило — ніколи не запускати цей фейловер, крім тих випадків, коли це дійсно необхідно, тобто якщо немає аварійної ситуації — користуйтеся виключно тестовим і плановим варіантами. Якщо необхідно просто подивитися, як це працює, написати документацію для інженерів і т. п., то виконайте всі кроки виключно в тестовій середовищі.

При виконанні фейловера єдина опція, яка буде вам доступна — це вибір необхідної точки відновлення. Далі машина буде запущена незважаючи ні на що. Якщо при виконанні планового фейловера майстер не дасть вам вистрілити в ногу і включити дві однакові машини (тобто він буде чекати моменту повного вимикання основної машини), то в цьому випадку ви отримаєте всього лише дуже чітке, але ненав'язливе попередження.


В якості останнього бар'єру перед точкою неповернення вам необхідно буде підтвердити завершення фейловера з допомогою Complete-VMFailover командлета PowerShell. Всі додаткові точки відновлення будуть видалені, а процес фейловера логічно завершений.

Best Practice

Перш ніж перейти до загальних порад, я хочу торкнутися теми приватної оптимізації для конкретної інфраструктури. Єдиним джерелом інформації, на основі якої можна буде робити далекосяжні висновки, само собою, служить всеохоплюючий моніторинг. Можна сперечатися, кращим чи ні є Operation Manager з пакету System Center. Але, оскільки на початку ми домовилися не розглядати сторонній софт, та ще за чималі гроші, цей інструмент ми пропустимо.

Отже, перше засіб з коробки, яка зустрічає нас при кожному завантаженні Windows Server, носить непоказне назва Best Practice Analyzer (воно знаходиться в самому низу Server Manager консолі).

Запускаючи час від часу BPA, можна отримати дійсно цінні поради щодо налаштувань хоста, які робляться на основі накопичених подій і моніторингу продуктивності різних підсистем вашого конкретного хоста та інформації накопиченої самої Microsoft.

З невідомих мені причин події для Hyper-V Replica не винесені в окрему підгрупу і, хоча і мають свої унікальні номери, але йдуть під грифом Hyper-V. Правила, що відносяться до реплік, йдуть під номерами від 37 до 54 включно.

Наступним по порядку йде безпосередньо консоль Hyper-V Manager. Варто додати в стандартне вікно зі списком машин додаткову колонку Replication Health. Як неважко здогадатися, в цій колонці відображається поточний стан реплікації.


І через меню Replication можна викликати досить докладну довідку про стан машини:




А тепер перейдемо до загальних порад:
  • Не бійтеся провести за плануванням і тестами зайвий день
  • За можливості виносьте файл підкачки віртуальної машини на окремий VHDX і виключайте його реплікації. Немає абсолютно ніякого резону для його передачі.
  • Якщо ви вирішили провести апгрейд серверів до 2012 R2, то спочатку потрібно виконати апгрейд репліки, а потім основного сервера — і ніколи навпаки. Реплікація не підтримує зворотну сумісність.
  • Якщо ви змінили розмір диска у машини джерела (стало можливим Server 2012 R2), необхідно змінити диск у репліки. Автоматично це не відбувається.
  • Використовуйте Network Throttling, якщо немає можливості використовувати виділену мережу для реплікації, т. к. процес реплікації здатний повністю захопити всю смугу пропускання каналу зв'язку. У таких випадках QoS наше все. На мій погляд, простіше всього налаштувати обмеження для процесу vmms.exe або для зазначених портів


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.