Пошук уроків, статей та іншого контенту
Розглянете автоматичне й ручне перемикання на резервні компоненти та критерії вибору активної репліки.
Failover — це перемикання обробки запитів із поточного активного компонента на резервний після збою або погіршення його роботи.
Компонентами можуть бути:
сервери застосунку;
екземпляри бази даних;
балансувальники навантаження;
мережеві шлюзи;
цілі дата-центри;
репліки сервісу в різних зонах доступності.
У типовій схемі є:
active — компонент, який зараз обробляє трафік;
standby — резервний компонент;
health checker — механізм перевірки стану;
failover controller — компонент, що приймає рішення про перемикання;
routing layer — DNS, балансувальник або service discovery, який направляє трафік.
Клієнти
|
Маршрутизація
|
Active replica --------> Standby replica
|
health checks
|
Failover controllerМета failover — зменшити час простою та зберегти узгодженість даних.
Під час автоматичного failover система самостійно:
перевіряє доступність активного компонента;
визначає, що збій є достатньо тривалим і серйозним;
обирає резервну репліку;
за потреби зупиняє стару активну репліку;
призначає резервну репліку активною;
перемикає маршрутизацію трафіку;
перевіряє працездатність нової активної репліки.
Автоматизація особливо корисна, коли важливий низький RTO — час відмовостійкого відновлення.
1. Active не відповідає на health check.
2. Перевірка повторюється кілька разів.
3. Контролер підтверджує збій.
4. Репліка B має актуальні дані та здоровий стан.
5. Репліка B стає active.
6. Балансувальник направляє запити на B.Одноразова невдала перевірка не повинна автоматично запускати failover. Причиною може бути короткочасна затримка мережі або перевантаження.
Для зменшення кількості помилкових failover використовують:
кілька послідовних невдалих перевірок;
затримку перед перемиканням;
перевірки з кількох незалежних вузлів;
різні типи health check;
обмеження частоти повторних перемикань.
Наприклад, умова може мати такий вигляд:
failover дозволено, якщо:
- активний компонент не відповідає 3 перевірки поспіль;
- перевірки виконувалися протягом щонайменше 15 секунд;
- резервна репліка доступна;
- резервна репліка має прийнятну затримку реплікації.Під час ручного failover рішення приймає оператор або відповідальна команда.
Типовий порядок дій:
підтвердити, що активний компонент справді несправний;
перевірити стан резервної репліки;
визначити допустиму втрату даних;
заборонити старому активному компоненту приймати записи;
підвищити резервну репліку до активної;
змінити маршрутизацію;
перевірити основні операції системи;
зафіксувати результат і причину перемикання.
Ручне перемикання повільніше, але дає оператору більше контролю. Воно може бути безпечнішим у ситуаціях, коли автоматична система не може надійно відрізнити збій компонента від проблеми мережі.
Ручний режим часто застосовують для:
планових робіт;
перемикання між дата-центрами;
складних аварій;
випадків, коли є ризик пошкодження або неузгодженості даних;
повернення з резервного середовища до основного.
Наявність резервної репліки ще не означає, що її можна одразу зробити активною. Перед перемиканням оцінюють кілька критеріїв.
Репліка повинна:
відповідати на мережеві запити;
проходити liveness- і readiness-перевірки;
мати доступ до необхідних залежностей;
приймати та обробляти тестові операції.
Перевірка процесу недостатня. Процес може працювати, але база даних, диск або мережа можуть бути недоступними.
Для реплік бази даних важливий replication lag — затримка реплікації.
Чим більша затримка, тим більше даних може бути відсутньо на резервній репліці. Якщо активний компонент вийшов з ладу, ці дані можуть бути втрачені.
Наприклад:
Репліка A: остання позиція журналу — 10500
Репліка B: остання позиція журналу — 10495
Різниця: 5 операційЯкщо політика дозволяє втратити не більше двох операцій, репліка B не підходить для автоматичного failover.
Реплікам можуть призначати різні пріоритети:
локальна репліка має вищий пріоритет;
репліка в іншій зоні використовується після локальної;
репліка в іншому дата-центрі є останнім варіантом;
тимчасово нездорова репліка виключається з вибору.
Пріоритет не повинен бути єдиним критерієм. Репліка з найвищим пріоритетом, але застарілими даними, може бути гіршим вибором.
Якщо кілька реплік однаково актуальні, можна вибрати ту, що має меншу мережеву затримку до клієнтів або основних залежностей.
Це впливає на:
час відповіді;
пропускну здатність;
навантаження на мережу;
стабільність після перемикання.
Нова активна репліка повинна мати достатньо:
CPU;
пам’яті;
дискового простору;
мережевої пропускної здатності;
з’єднань для клієнтів.
Резервний компонент, який працює в режимі мінімальних ресурсів, може бути придатним лише для аварійного обслуговування частини трафіку.
Нижче наведено спрощений приклад контролера на JavaScript. Він:
відкидає нездорові репліки;
відкидає репліки з надмірною затримкою реплікації;
обирає репліку з найвищим пріоритетом;
за однакового пріоритету обирає актуальнішу репліку;
за однакової актуальності обирає репліку з меншою мережевою затримкою.
const replicas = [
{
name: "db-a",
healthy: false,
priority: 100,
replicationLag: 0,
networkLatency: 10,
},
{
name: "db-b",
healthy: true,
priority: 90,
replicationLag: 1,
networkLatency: 20,
},
{
name: "db-c",
healthy: true,
priority: 80,
replicationLag: 0,
networkLatency: 45,
},
];
const MAX_REPLICATION_LAG = 5;
function chooseReplica(replicaList) {
const candidates = replicaList
.filter((replica) => replica.healthy)
.filter((replica) => replica.replicationLag <= MAX_REPLICATION_LAG);
if (candidates.length === 0) {
throw new Error("Немає придатної репліки для failover");
}
candidates.sort((a, b) => {
if (b.priority !== a.priority) {
return b.priority - a.priority;
}
if (a.replicationLag !== b.replicationLag) {
return a.replicationLag - b.replicationLag;
}
return a.networkLatency - b.networkLatency;
});
return candidates[0];
}
try {
const selected = chooseReplica(replicas);
console.log(`Новою активною реплікою стане: ${selected.name}`);
console.log(`Затримка реплікації: ${selected.replicationLag}`);
console.log(`Мережева затримка: ${selected.networkLatency} мс`);
} catch (error) {
console.error(`Failover скасовано: ${error.message}`);
}У реальній системі між вибором репліки та перенаправленням трафіку мають бути додаткові кроки: блокування старого лідера, зміна ролі в системі зберігання даних та перевірка, що нова активна репліка справді може приймати записи.
Split-brain виникає, коли дві репліки одночасно вважають себе активними.
Наприклад:
активний сервер втрачає зв’язок із контролером;
контролер вирішує, що сервер несправний;
контролер призначає резервну репліку активною;
старий сервер продовжує працювати й приймати записи.
У результаті записи можуть надходити до двох активних компонентів. Це призводить до:
конфліктів даних;
втрачених записів;
різних станів реплік;
складного відновлення.
Fencing — це механізм, який не дозволяє старому активному компоненту продовжувати роботу після передачі ролі.
Варіанти fencing:
вимкнення або перезавантаження старого вузла;
блокування його мережевого доступу;
відкликання його оренди або токена;
блокування запису на спільне сховище;
використання зовнішнього керованого пристрою живлення.
Надійний failover має гарантувати не лише запуск нової активної репліки, а й припинення роботи старої в активній ролі.
Якщо рішення про failover приймає один контролер, його власний збій або мережева ізоляція можуть спричинити неправильне перемикання.
Для критичних систем використовують кілька контролерів і кворум. Рішення вважається підтвердженим, коли його підтримує більшість учасників.
Наприклад, у групі з трьох контролерів кворум становить два. Один контролер, який втратив зв’язок з іншими, не повинен самостійно призначати нову активну репліку.
Це допомагає зменшити ризик:
двох одночасних лідерів;
перемикання через локальну мережеву проблему;
суперечливих команд від різних контролерів.
Переваги:
малий час реакції;
не потребує оператора в момент збою;
добре підходить для повторюваних і передбачуваних сценаріїв;
забезпечує стабільний порядок дій.
Ризики:
хибне перемикання;
помилковий вибір репліки;
виникнення split-brain;
каскадні перемикання під час нестабільної мережі.
Переваги:
оператор може оцінити контекст;
легше врахувати стан даних;
підходить для складних аварій;
зменшує ризик автоматичного рішення в неоднозначній ситуації.
Недоліки:
більший час простою;
залежність від доступності та досвіду команди;
ризик помилки під час стресу;
необхідність чіткої документації процедур.
На практиці часто використовують змішану модель:
автоматичне перемикання між репліками в одній зоні;
ручне підтвердження перемикання між дата-центрами;
автоматичне відновлення сервісу після перевірки оператором.
Failback — це повернення активної ролі до основного компонента після його відновлення.
Не слід автоматично повертати роль одразу після появи старого компонента в мережі. Спочатку потрібно:
перевірити його стан;
синхронізувати дані;
переконатися, що він не має застарілої або конфліктної копії;
виконати планове перемикання;
перевірити трафік після повернення.
Іноді нову активну репліку залишають активною надовго, а відновлений компонент використовують як резервний. Це дозволяє уникнути повторного ризику під час негайного failback.
Щоб зрозуміти, чи було перемикання успішним, потрібно фіксувати:
час виявлення збою;
час прийняття рішення;
обрану репліку;
значення replication lag;
причину перемикання;
час зміни маршрутизації;
кількість помилок до та після failover;
час відновлення старого компонента.
Корисно розділяти події:
FAILURE_DETECTED
FAILOVER_STARTED
REPLICA_SELECTED
FENCING_COMPLETED
ROUTING_UPDATED
FAILOVER_COMPLETEDБез таких даних складно перевірити, чи відповідає система цільовим показникам RTO та RPO.
Короткочасна мережева затримка може бути помилково сприйнята як повний збій.
Як уникнути: використовувати кілька перевірок, часові пороги та незалежні джерела спостереження.
Репліка може бути доступною, але мати значну затримку даних або недостатні ресурси.
Як уникнути: враховувати актуальність даних, пріоритет, ресурси та затримку.
Стара активна репліка може продовжити приймати записи після перемикання.
Як уникнути: перед активацією резервної репліки гарантовано заблокувати стару.
Відновлений компонент може містити застарілі дані або знову швидко вийти з ладу.
Як уникнути: виконувати синхронізацію, перевірки та планове повернення ролі.
Механізм, який не тестували, може не спрацювати під час реального інциденту.
Як уникнути: регулярно проводити контрольовані тести failover і перевіряти фактичний час відновлення.
Failover перемикає систему з активного компонента на резервний.
Автоматичний режим зменшує час реакції, але потребує захисту від хибних рішень.
Ручний режим дає більше контролю та підходить для неоднозначних або масштабних аварій.
Активну репліку обирають за доступністю, актуальністю даних, пріоритетом, затримкою та ресурсами.
Одна невдала health check не повинна автоматично запускати перемикання.
Fencing необхідний для захисту від split-brain.
Failover слід перевіряти за допомогою спостережуваності та регулярних тестів.
Повернення основного компонента, failback, потрібно виконувати окремо й контрольовано.