Чому etcd кластер втрачає кворум і обвалює сервіси
etcd кластер зберігає конфігурацію як журнал реплікованих записів: запис вважається застосованим лише після підтвердження більшістю вузлів. Із п’яти вузлів кворум потребує трьох — втрата третього переводить кластер у режим лише читання, а згодом і в повну відмову.
Окрема пастка — розсинхрон налаштувань: вузол із повільним диском відстає від лідера, накопичує чергу змін і випадає з голосування, після чого ті, що залишилися, починають по колу обирати нового лідера.
Ззовні це виглядає як відмова сховища конфігурацій без жодної помилки в логах застосунку. Частина сервісів читає ключі з кешу й продовжує жити на застарілих значеннях, частина звертається напряму та отримує таймаут.
Розсинхрон налаштувань розтікається групами сервісів: одні вже бачать нову адресу залежності, інші тримають стару, і трафік іде в нікуди.
Далі спрацьовує каскадна недоступність. На сховищі зав’язані виявлення сервісів, ротація секретів і запуск нових екземплярів застосунків: поки воно мовчить, не піднімаються репліки, не оновлюються маршрути, а перевірки живості починають відстрілювати здорові екземпляри. Втрата кворуму б’є по всьому контуру одразу, хоча причина локальна.
І майже завжди це не раптова відмова диска, а накопичений борг: усі вузли в одній зоні відмови, немає контролю затримки застосування записів, бекапи жодного разу не перевіряли відновленням. Розбираємо, як це закривається — від топології та лімітів до регламенту заміни вузла.
Що дає відмовостійкий etcd кластер: ефект за метриками
Відмовостійкий etcd кластер збирають із непарної кількості вузлів — зазвичай трьох або п’яти. Такий склад переживає втрату одного-двох вузлів: ті, що залишилися, зберігають кворум і продовжують віддавати конфігурацію, тому деградація вузла не перетворюється на зупинку сервісів. Нижче — п’ять результатів, які видно в метриках після переїзду на такий контур.
Час відновлення після відмови вузла
Збійний вузол замінюється додаванням нового до складу та синхронізацією знімка стану — без ручного розбору конфігурації на хості. Час відновлення скорочується з годин ручного підняття до десятків хвилин, причому запис і читання конфігурації доступні весь цей час.
Усунений клас відмов: розбіжність конфігурацій між сервісами
Єдина конфігурація в одному сховищі прибирає розрізнені файли на хостах, через які середовища розходилися й падали на незбігу параметрів.
Історія ревізій показує, хто й коли змінив значення, а відкат до попередньої ревізії повертає сервіс у робочий стан за секунди замість пошуку відмінностей вручну.
Решта ефектів — відсутність єдиної точки відмови під час читання налаштувань, однакова конфігурація в усіх середовищах і передбачувана швидкість застосування змін: правка розкочується на всі сервіси одним проходом, без обходу хостів.
Режими розгортання сховища конфігурацій: порівняння
Режим розгортання визначає дві речі: як вузли знаходять одне одного та скільки відмов кластер переживає без втрати конфігурацій. Різниця між статичним складом вузлів і динамічним виявленням проявляється саме в момент збою — тоді й стає видно, чи правильно вибрано схему.
Один центр обробки даних
Тут доречний статичний склад вузлів: адреси прописані в конфігурації кожного учасника, кластер збирається передбачувано, налагодження зводиться до перевірки зв’язності між вузлами. Непарна кількість вузлів дає запас на відмову одного з них без зупинки запису.
Обмеження схеми в іншому: додати вузол без правки конфігурацій і перезапуску не можна, а відмова всього центру обробки даних зупиняє запис конфігурацій повністю.
Кілька зон доступності
Тут потрібніше динамічне виявлення: вузли знаходять одне одного через зовнішній реєстр або службу імен, склад кластера змінюється без ручної правки. Ціна — залежність від мережі між зонами та від самого джерела виявлення.
Чим вища затримка між зонами, тим довше підтверджується запис, тому зони розміщують із передбачуваною зв’язністю.
| Режим | Коли підходить | Обмеження схеми |
|---|---|---|
| Статичний склад, один ЦОД | Невеликий контур зі стабільною кількістю вузлів | Новий вузол — правка конфігурацій і перезапуск; відмова центру зупиняє запис |
| Статичний склад за зонами | Є керована мережа між зонами | Затримка між зонами збільшує час підтвердження запису |
| Динамічне виявлення | Склад вузлів змінюється часто | Потрібне зовнішнє джерело виявлення; його недоступність заважає зборці |
Перед вибором перевіряємо затримку між зонами та те, як часто змінюється кількість вузлів, — від цього залежить схема й порядок заміни учасників.
Етапи впровадження: від аудиту до передачі в експлуатацію
Порядок робіт вибудуваний так, щоб кожен крок спирався на дані попереднього: спочатку фіксуємо фактичний стан, потім проєктуємо й лише після цього змінюємо бойовий контур. Нижче — типовий маршрут для etcd-кластера, який зберігає конфігурації та стан застосунків.
Аудит поточного стану
Дивимося, що вже працює та які конфігурації не можна втрачати, і окремо — на поточні точки відмови: єдиний вузол, реплікація без кворуму, бекап, який жодного разу не перевіряли.
- Аудит конфігурацій. Карта сервісів, які читають і пишуть стан, обсяг ключів, частота змін, права доступу. На виході — вузькі місця та список конфігурацій, які переживуть міграцію без правок.
- Проєктування схеми. Кількість вузлів і кворум, розкладка за зонами доступності, регламент бекапу, схема сертифікатів і розмежування доступу між застосунками.
- Налаштування вузлів. Розгортання за спроєктованою схемою, перенесення конфігурацій із звіркою ключів, моніторинг, алерти на втрату кворуму та автоматичний перезапуск.
Перевірка відмовостійкості під навантаженням
- Перевірка відмовостійкості. Гасимо по одному вузлу, імітуємо втрату лідера та розрив зв’язку між зонами: кластер зобов’язаний зберегти кворум і продовжувати обслуговувати читання й запис.
- Навантажувальні прогони. Профіль, близький до бойового: піки запису, багато одночасних клієнтів, довгі сесії. Вимірюємо затримку відповіді та час вибору нового лідера.
- Передача в експлуатацію. Регламенти відновлення, дашборди, розмежування прав, навчання з командою замовника та супровід у перші дні після перемикання.
Комплект передачі: конфігурації, схеми, політики доступу
Комплект збираємо не «для галочки», а щоб чергова зміна могла підняти, розширити й відновити кластер без нас. Нижче — що саме передається замовнику на руки разом із працюючим контуром.
Політики доступу та IAM-ролі
- Ролі та прив’язки з розділенням прав: читання конфігурацій, запис, адміністрування кластера — під окремі сервісні облікові записи.
- Порядок видачі та ротації сертифікатів із процедурою відкликання скомпрометованого ключа.
- Матриця «хто і що може»: відповідність застосунків, облікових записів і дозволених операцій; запис у бойовий контур із тестових застосунків заборонено правилами.
- Налаштування аудиту: які звернення до сховища логуються та як довго зберігається журнал.
Регламенти обслуговування та відновлення
- Конфігураційні файли всіх вузлів із коментарями — який параметр кластера виставлено й чому саме так.
- Схеми розгортання: топологія, кворум, порядок додавання та заміни учасника, прив’язка до майданчиків.
- Регламент обслуговування: регламентні перевірки стану, оновлення на актуальну гілку, виведення вузла без втрати кворуму.
- Інструкція з відновлення: зняття резервних копій, перевірка їх придатності, сценарій підняття з нуля та точка, до якої можливий відкат.
- Документація для експлуатації: відповідальні, вікна робіт, час реакції чергового та журнал змін.
Комплект передаємо в закритому репозиторії та на захищеному носії, із супровідним описом — що лежить у кожній папці та коли цей артефакт потрібно оновлювати.
Кейс: відновлення сховища без втрати конфігурацій
Після збою диска один із вузлів etcd вийшов з ладу, кворум розпався, і застосунки перестали читати конфігурації.
Частина сервісів залишилася працювати на застарілих значеннях, а відновлення розтягнулося на чотири години: стан збирали з добового бекапу та правок, зроблених прямо на живих вузлах, звіряючи ключі вручну. Розбираємо, що змінили в роботі зі сховищем.
Що було до: ручні правки та розбіжність налаштувань
Правки йшли напряму в живе сховище через клієнт, минаючи репозиторій і рев’ю. За кілька місяців розбіжності накопичилися: сім сервісів читали застарілі ключі, і помітили це лише за інцидентом.
Бекап знімався раз на добу й жодного разу не перевірявся відновленням, а втрачений вузол піднімали вручну, зіставляючи значення за логами — у середньому чотири години простою запису конфігурацій.
Що стало після: керована схема та перемикання вузлів
Тепер стан etcd-кластера описано декларативно й живе в репозиторії поруч із маніфестами Kubernetes: зміни проходять рев’ю та застосовуються автоматично.
Кворум тримається на непарній кількості вузлів і переживає втрату одного — виведення вузла на обслуговування займає секунди, застосунки не помічають перемикання.
Снапшот знімається кожні п’ятнадцять хвилин і раз на тиждень перевіряється повним відновленням на тестовому контурі.
Підсумок: розбіжність ключів між вузлами — нуль, відновлення вузла — дванадцять хвилин замість чотирьох годин, перемикання — менше десяти секунд замість сорока хвилин простою.
Що робити, якщо сховище вже розгорнуто в одному центрі?
Робоча схема з кворумом в одному центрі розширюється без перезбирання кластера. Додавання вузла — це приєднання нового учасника до чинного кворуму: лідер зберігає роль, запис конфігурацій іде безперервно. Новий вузол спочатку отримує снапшот і наздоганяє журнал змін, і лише потім стає голосуючим.
Порядок такий: вузли вводяться по одному, між кроками перевіряємо відставання за журналом і відгук на читання. Так зміна топології проходить поступово — з трьох учасників на п’ять у тому ж центрі, а потім частину з них переносять на інший майданчик. Дані залишаються ті самі, змінюється лише розкладка кворуму за центрами.
Міграція сховища в інший центр іде тим самим принципом: піднімаємо учасник на новому місці, даємо йому наздогнати інших, і лише потім виводимо вузол на старому.
На кожному кроці більшість голосів залишається живою, тому вікна недоступності не виникає — сервіси продовжують читати й писати конфігурації.
Перед перемиканням фіксуємо план: точки повернення, свіжі снапшоти, допустиме відставання та порядок виведення вузлів.
Окремо дивимося затримку між майданчиками — узгодження змін до неї чутливе, і повільний канал здатен перетворити здоровий кластер на такий, що постійно переобирає лідера.
Після переїзду знімаємо контрольні метрики: час узгодження запису, стабільність лідера, обсяг журналу. Якщо значення виходять за межі, підготовлений відкат на попередню розкладку виконується так само без простою.
Технічні сумніви замовників: відмови вузлів і оновлення
Відмова вузла в кластері конфігурацій рідко виглядає як миттєва аварія: застосунки продовжують читати стан, поки зберігається кворум, а проблема спливає пізніше — під час планової заміни обладнання або під час спроби підняти середовище з копії.
Нижче — три питання, які найчастіше задають до старту робіт: поведінка під час випадіння вузла, порядок зміни складу та придатність резервних копій.
Що станеться, якщо один вузол випаде?
Кворум — це більшість учасників: у складі з трьох вузлів втрачається один, два голоси залишаються, і запис конфігурацій продовжується. Лідер переобирається, клієнтські застосунки бачать коротку затримку відгуку, а не відмову.
Склад із двох вузлів кворуму не дає взагалі — випадіння будь-якого зупиняє запис, тому парні схеми ми переводимо на непарні, а не «зміцнюємо» додаванням другого вузла.
Як змінювати склад без простою?
Вузли вводяться й виводяться по одному, за суворою послідовністю: спочатку вмикаємо нового учасника, чекаємо, поки він наздожене стан і підтвердить готовність приймати навантаження, і лише потім виводимо старий. Передачу ролі лідера плануємо у вікно обслуговування.
Адреси та ролі учасників описані в конфігурації як дані — ми не правимо живі вузли руками, інакше склад розходиться з описом.
Як переконатися, що резервна копія робоча?
Знімок стану безкорисний, поки його не відновлено: копія перевіряється розгортанням на ізольованому стенді, звіркою повноти ключів і контрольних значень із робочим кластером. Окремо фіксуємо час відновлення — саме він визначає, за скільки середовище підніметься після аварії.
Перевірку копій ставимо в регулярний регламент, а самі копії зберігаємо за межами майданчика, де працює кластер.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб оцінка спиралася на факти, а не на середні значення по галузі, нам потрібні вихідні дані по вашому контуру. Опишіть задачу у вільній формі — уточнимо те, чого бракує, і повернемося з оцінкою, планом робіт і порядком кроків.
Що запитуємо для розрахунку:
- поточну схему розміщення вузлів etcd: скільки машин, як рознесені за зонами доступності, чи окремі диски під журнал;
- чим зараз керуються конфігурації застосунків і як вони доставляються на вузли;
- профіль навантаження: кількість ключів, частка операцій запису проти читання, пікові періоди;
- вимоги до доступності — яке вікно недоступності одного вузла допустиме, хто ініціює обслуговування;
- як влаштовано резервне копіювання та коли востаннє перевіряли відновлення з копії;
- обмеження за доступами, сертифікатами, сегментацією мережі та регламентом змін;
- хто з боку замовника приймає роботи й за якими критеріями.
Далі порядок кроків такий: розбір поточної схеми та вузьких місць, план робіт з етапами й точками контролю, узгодження вікна змін, впровадження з перевіркою на відмову вузла, передача конфігурацій, схеми та регламенту обслуговування. Опишіть задачу — повернемося з планом і строками.
