Реплікуйте групу, а не диск: консистентність у реплікації масивів

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

Копія кожного диска не є копією застосунку

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

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

Коли кожен том реплікується незалежно, кожна копія рухається своїм темпом, тож віддалені диски майже ніколи не перебувають в одній миті часу. Відповідь на це: група консистентності, тобто набір томів, які масив реплікує як одне ціле, зберігаючи порядок запису між усіма ними. На HPE 3PAR це Remote Copy group. Інші масиви мають власну назву для тієї самої ідеї. Хай як вона називається, правило одне. Усе, що потрібно застосунку для запуску, входить до однієї групи.

Як обирати, що входить до групи

Починайте від застосунку, а не від списку томів:

• Перелічіть кожен том, на який пише застосунок, включно з тими, про які легко забути: том з архівом binary log або write-ahead log, окремий тимчасовий tablespace, диск з конфігурацією.
• Помістіть їх усі в одну групу.
• Тримайте непов’язані застосунки в окремих групах, щоб один можна було перемкнути на резерв, протестувати або призупинити, не чіпаючи інший.

Потім вирішіть, наскільки щільно копія йде за оригіналом.

Наскільки близькою має бути копія?

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

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

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

Тримайте реплікацію поза продуктивним шляхом

Трафік реплікації конкурує з I/O хостів, якщо йому дозволити. Дайте йому виділені порти масиву, тримайте ці порти окремо від портів, якими користуються хости, і тримайте кожен канал реплікації до одного партнера. Стежте за відставанням реплікації, а не лише за станом каналу. Канал, який працює, поки копія з кожною годиною відстає дедалі більше, саме той режим відмови, що перетворює план аварійного відновлення на сюрприз.

Тестуйте репліку, не ламаючи її

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

• Зробіть point-in-time snapshot вторинних томів групи на віддаленому масиві. Знімайте всю групу одразу, щоб тестова копія була такою ж консистентною, як репліка.
• Надайте snapshots ізольованому тестовому хосту на віддаленому майданчику. Тримайте цей хост поза продуктивною мережею, щоб копія не могла відповідати на реальний трафік, надсилати реальну пошту чи запускати заплановані завдання проти реальних систем.
• Запустіть застосунок точно так, як робили б під час аварії, за своїм написаним runbook і більше нічим.
• Перевірте на рівні застосунку: база даних відкривається і проходить власну перевірку консистентності, кількість рядків і найновіші записи там, де каже точка відновлення, і вхід у застосунок працює.
• Заміряйте час від рішення про перемикання до першої успішної транзакції. Це число є вашим реальним часом відновлення, хай що каже план.
• Видаліть snapshots і запишіть результат, включно з усім, що вас здивувало.

Проводьте тест після будь-якої зміни групи і за регулярним графіком, навіть коли нічого не змінилося, бо застосунки тихо додають томи.

Реплікація не є резервним копіюванням

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

Як це робимо ми

Між нашими дата-центрами в Афінах і Амстердамі томи клієнтів можуть реплікуватися з масиву на масив на HPE 3PAR, а пов’язані томи розміщуються в одній Remote Copy group, щоб залишатися консистентними один з одним. Режим реплікації погоджується для кожного сервісу, реплікація йде через виділені порти, один партнер на пару портів, через наше власне приватне з’єднання між майданчиками, а репліки даних, розміщених у ЄС, залишаються всередині нашої інфраструктури в ЄС. Усередині кожного майданчика масиви об’єднані у federation, тож томи також переміщуються між масивами онлайн. Резервні копії стоять поруч, окремо і лише в режимі pull.

Якщо ви не впевнені, що ваша віддалена копія запуститься в день, коли вона знадобиться, це варто з’ясувати у спокійний день. Ми радо допоможемо спроєктувати групи і тест.

cta: Поговоріть з інженером

Related

• /what-we-do/storage-compute/storage-replication-federation/
• /what-we-do/storage-compute/disaster-recovery/
• /what-we-do/storage-compute/enterprise-san-storage/