Як «бути готовим» або DR на Nutanix: асинхронна реплікація



Тема побудови відмовостійких ЦОД з використанням гиперконвергентных систем Nutanix досить велика, тому, щоб, з одного боку, «не скакати по верхівках», а з іншого — не заглиблюватися в занудность, розіб'ємо її на дві частини. У першій розглянемо теорію і «класичні» методи реплікації, у другій — нашу нову фішку, так звану Metro Availability, можливість побудови синхронно-реплицируемого метрокластера (metropolitan-area, масштабу великого міста і навіть більше) на відстані розносу датацентрів до 400 кілометрів.

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


Nutanix, як компанія молода і виникла «на вістрі потреб» відразу орієнтувалася на необхідність в сучасному датацентрі мати і резервний ЦОД, і правильну, багатофункціональну реплікацію. Саме тому, навіть у наймолодшій ліцензії, яка йде з кожною системою Nutanix, і включена в ціну (у нас вона називається Starter), вже є повнофункціональними реплікацію. Цим Nutanix відрізняється від багатьох традиційних систем, в яких реплікація, найчастіше, йде як опція і коштує додаткових, часто дуже істотних грошей.
Не так у нас. Будь Nutanix вже вміє двонаправлену асинхронну реплікацію. Двунаправленность, до речі, яка дозволяє використовувати обидва датацентри в режимі «активний-активний» (а не «активний-резера», як зазвичай) також зустрічається далеко не у всіх вендорів.

У світі методів реплікацій прийнято розрізняти два основних принципи їх роботи, так звані «синхронну» і «асинхронну» реплікації.
Синхронна реплікація — це просто. Кожна операція запису на диски не вважається закінченою, поки та ж операція запису не буде передана і завершена на дисках віддаленої системи. Блок даних прийшов, блок записався на диски локального пристрою зберігання, додаток але поки відповіді «готово, записано!» не отримало. Тим часом блок даних передався на віддалену систему, і на ній розпочато процес запису цього блоку. І тільки після того, як блок записаний на віддаленій системі, вона рапортує про успіх, і от тоді про завершення запису система повідомляє додатком, блок якого записувався, локальна, перша система.



Переваги синхронної реплікації очевидні. Дані записуються на локальну і віддалену системи максимально безпечним чином, копія в резервному Цоді завжди повністю ідентична копії у вашому локальному Цоді. Проте є і мінус, він хоч і один, але — величезний.
У випадку, якщо у вас дві системи пов'язані синхронної реплікацією, то швидкість локальної для вашого додатки, системи буде дорівнює швидкості каналу передачі даних між локальною і віддаленою системою. Тому що поки віддалена система не отримає блок даних для запису і не запише його, ваша локальна система буде стояти і чекати. І якщо від додатка до дисків локальної системи у вас 16G FC, а від локальної системи до віддаленої — 1GB Ethernet по каналу провайдера через кілька роутерів, то запис на локальні диски у вас не перевищить швидкість цього ось каналу Gigabit Ethernet.

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

Тим не менш, на практиці, асинхронна реплікація широко застосовується. Що ж робити з «неточністю копії»? Ну, по-перше, ви можете подумати, і оцінити, що продуктивність запису системи і низькі значення latency при запису для вас важливіше, ніж можлива втрата 15 хвилин змін у даних (а часто так і буває). Або ж використовувати як доповнення до загальної асинхронної реплікації для всіх додатків, якісь засоби захисту даних на рівні конкретних додатків, а не сховища даних взагалі (приклад — різні засоби, які є у продуктів Microsoft, Availability Groups в MS Exchange, або аналогічні засоби у MS SQL Server).

В принципі тут Nutanix не винайшов нічого нового. На системах Nutanix є як синхронна, з допомогою якої реалізована так звана Metro Availability, так і асинхронна реплікація з одного кластера Nutanix, в одному ДЦ, на інший, зазвичай в іншому ДЦ. Асинхронна реплікація виконана з допомогою передачі «снэпшотов» дискового сховища, а синхронна — трохи складніше і полюбопытнее.

Кілька слів про деяку термінологічну закавыке.
Використовуване сьогодні усіма підряд слово «кластер» може ввести в певне утруднення, якщо не оману. Справа в тому, що в IT-індустрії сьогодні слово «кластер» використовується для позначення не просто дуже різних по природі речей, але ще й, в основному, застосовується до структури, що забезпечує високу доступність (high availability). І настільки часто слово «кластер» застосовується для позначення саме і тільки «HA-cluster», що у багатьох складається враження, що «кластер»=«відмовостійкий кластер», і тільки.
Не завжди це так.

По-перше, що є «кластер»?
Кластер — це об'єднання окремих елементів в деяку загальну сутність верхнього порядку, існуючу і керовану як самостійна одиниця. Як бачите, в такому визначенні немає нічого про відмовостійкість. Вона може бути, може не бути, і кластер це не завжди «HA-кластер».
Мені часто доводиться відповідати на питання: «А чи можна нам розкидати ноди кластера Nutanix по різним сайтам, от у нас і буде надійність?»
Відповідь тут такий: у теорії — так, можна (звичайно не варто забувати, що вам потрібно по сайтах протягнути також і по парі 10G каналів для внутрикластерной комунікації, але навіть це вже сьогодні можна зробити), але на практиці це не рекомендується, і взагалі «ви цього самі не захочете». Чому?

Давайте уявимо, для аналогії, що кластер Nutanix це група дисків в дисковому масиві, підключеному по FC. Ось у нас є сайт A, і на ньому JBOD-полку і в ній десяток дисків на FC, і сайт Б, з такою ж полицею і десятком дисків, всі включені в загальну FC-мережу. І ми вирішуємо зробити з усіх цих двадцяти дисків RAID-групу в RAID-5 або 6. В принципі, в теорії — можемо, чого немає. Кожен диск JBOD ми бачимо як окреме FC-пристрій, об'єднуй. Але далі питання, що станеться з RAID-му, якщо у нас проїде екскаватор щось трапиться з мережею між сайтами?
Нічого хорошого. Втрати половини, або навіть хоча б третини учасників разом, швидше за все не витримає ні RAID, ні, в схожій ситуації, кластер Nutanix.

Саме тому, говорячи з користувачами про кластери і про Nutanix, доводиться мінімізувати плутанину, уточнюючи, що тут ми говоримо: «кластер Nutanix», а тут під «кластер» розуміється «HA-кластер VMware», а тут — Real Application Cluster (RAC) бази даних Oracle. І це будуть всі різні кластери, часто розташовані ієрархічно один над одним, і це абсолютно нормально.

Таким чином, розкидати ноди одного кластера Nutanix сайтів для забезпечення відмовостійкості ми не можемо. Але можемо на одному сайті розташувати ноди одного «кластера Nutanix», на іншому сайті — іншого («кластера Nutanix»), а далі об'єднати їх в репліковані відносини в потрібному нам напрямку, наприклад, з основного ДЦ в резервний, з головного офісу в філії (і навпаки), а то і зовсім в обох напрямках.

Причому, якщо це буде «синхронний» метрокластер, то поверх такої синхронно реплікованої пари кластерів, які, нагадаю, можуть розташовуватися на відстані, в ідеальному випадку, до 400 кілометрів (або, говорячи технічною мовою, нам треба, щоб між сайтами roundtrip IP-пакета не перевищував 5ms), а потім поверх цієї метро-пари ми можемо створити кластер VMware, усередині якого віртуальні машини будуть перезавантажиться і мігрувати як на загальному, єдиному дисковому сховищі, згідно політикам DRS, які ми напишемо. Але про це я детальніше розповім в наступній серії.

Для асинхронної реплікації даних з одного сайту на інший Nutanix використовує внутрішній механізм «снэпшотов Vmcaliber». При їх використанні по каналу передачі даних між двома сайтами передається тільки різницева частина, своєрідний diff вмісту дискового тому-контейнера. З вихідної системи береться diff від попередньої передачі, потім відправляється на віддалений сайт-одержувач реплікації, і там «накочується». На сьогодні інтервал передачі асинхронної реплікації у Nutanix — 15 хвилин. Тобто, в найгіршому випадку, ви можете втратити лише 15 хвилин даних, при цьому, на відміну від синхронної реплікації, процес не знижує продуктивність і збільшує latency при роботі з даними.



Таким чином, кожні 15 хвилин на DR-сайт їде diff дисків основної системи, і там автоматично розгортається і накочується, підтримуючи її актуальність. При втраті системи в «головному» ДЦ, у найгіршому випадку, ви втратите зміни даних за 15 хвилин.
Але що робити, якщо п'ятнадцятихвилинний лад — занадто багато, і потрібна синхронна реплікація?
Для цього можна скористатися нашою технологією Metro Availability, про яку наступний пост.

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

0 коментарів

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