Service Discovery на etcd: кластер з TLS і моніторингом

Чому etcd service discovery деградує під навантаженням

Кластер etcd тримає карту сервісів: хто де слухає і який вузол ще живий. Поки все рівно, etcd service discovery віддає актуальні адреси майже миттєво, і застосунки ходять одне до одного напряму, без проміжної ланки.

Під навантаженням ламається не сам сервіс, а реєстр: чим більше клієнтів і ключів, тим довше запис, і кластер починає відставати від потоку оновлень.

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

Застарілі записи реєстру небезпечніші за явну відмову. Ключ із простроченою орендою продовжує віддаватися споживачам, трафік іде на зупинений екземпляр, і замість навантаження балансувальник накопичує помилки зв'язку.

Виявлення буксує: час від публікації адреси до першого успішного запиту зростає із секунд до десятків секунд, а частина з'єднань не встановлюється взагалі.

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

Стійкість кластера: кворум, вибори лідера, час реакції

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

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

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

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

Для виявлення сервісів змінюється головне: клієнти замість періодичного опитування тримають довготривалу підписку на зміни.

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

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

Такий кластер ми збираємо на etcd з TLS між вузлами й клієнтами та оповіщеннями на втрату кворуму й зміну лідера. В експлуатації це видно як клас відмов, що перестав бути аварією: падіння вузла або цілої зони не створює вікна недоступності сервісів.

Режими service discovery: клієнтський, серверний, гібридний

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

Вибір диктує не мода, а допустима зона відмови, вартість експлуатації та сумісність із поточним контуром — сертифікатами, збором метрик, порядком викочування.

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

Балансування між сервісами при цьому залишається керованим — правила вибору інстансу описуються декларативно й не розмазуються по коду застосунків.

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

Розгортання кластера: аудит, TLS, перевірка відмов

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

1. Інвентаризація сервісів. Збираємо список того, що буде реєструватися й знаходитися через кластер: ключі, час життя записів, хто пише й хто читає, які сервіси залежать від карти адрес напряму. Без цього списку не можна ні порахувати навантаження, ні налаштувати квоти.
2. Схема розміщення вузлів. Визначаємо кількість вузлів кворуму, розкладаємо їх по різних зонах відмови, перевіряємо затримки між майданчиками. Кворум тримаємо непарним, щоб втрата однієї зони не зупиняла запис.
3. Підготовка вузлів і сховища. Окремі диски під журнал і дані, синхронізація часу, ліміти ресурсів і передбачувана поведінка при переповненні диска — найчастіша причина деградації кластера.
4. Шифрування трафіку. Налаштовуємо сертифікати для зв'язку між вузлами й для клієнтів, вмикаємо взаємну автентифікацію й описуємо порядок ротації. Окремо перевіряємо, що старий сертифікат не залишається робочим після відкликання.
5. Моніторинг і оповіщення. Виводимо метрики кворуму, затримки запису й стану лідера, ставимо оповіщення на втрату кворуму й зростання часу відгуку, щоб збій помічав черговий, а не користувач.
6. Перевірка сценаріїв відмови. Планово гасимо вузол, виводимо цілу зону, рвемо зв'язок між майданчиками, перезапускаємо кластер — і фіксуємо, за який час він повертається в робочий стан.
7. Передача й регламент. Віддаємо документацію, доступи, інструкції з оновлення та виведення вузлів на обслуговування, розбираємо типові інциденти з черговою зміною.

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

Конфігурації, схеми й регламенти: що залишається у вашому контурі

Після здачі весь контур залишається у вас — не «чорна скринька підрядника», а комплект артефактів, за якими ваша команда розгорне стенд з нуля, пройде аудит або прийме чергування без дзвінка нам.

Кожне нестандартне значення в конфігурації має письмове обґрунтування: чому параметр такий, що зламається за його зміни й як відкотитися до попереднього стану.

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

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

Кейс: реєстр на 40 сервісів без ручних правок

Спочатку адреси сорока сервісів жили в статичних конфігураціях і частково в нотатках чергової зміни.

Після перенесення екземпляра на інший вузол сторона, що викликає, продовжувала ходити на попередню адресу: сервіс відповідав помилкою 15–40 хвилин, доки інженер не знаходив застарілий запис і не перевипускав конфігурацію.

Частка ручних змін у маршрутизації становила всі 100%, а на чергову зміну за місяць надходило 12–14 викликів лише через неправильні адреси.

Що змінили

Підняли відмовостійкий реєстр на etcd — три вузли з кворумом, взаємна перевірка справжності за TLS, права на запис розмежовані за шляхами.

Кожен сервіс отримав невеликий агент: під час старту він публікує свою адресу з орендою на короткий термін і продовжує її, під час зупинки — знімає запис сам.

Якщо екземпляр падає й не продовжує оренду, ключ спливає, і сторона, що викликає, протягом секунд перестає бачити застарілу адресу.

Метрики до і після

Клас відмов «клієнт знає адресу, якої вже немає» пішов повністю — під час відкату релізу адреса попередньої версії залишається опублікованою, тому повернення на неї не потребує правок.

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

Що робити, якщо реєстр сервісів уже розгорнуто на іншій системі?

Міграцію на etcd service discovery не роблять одним перемиканням: спочатку два контури працюють паралельно. Нові інстанси реєструються і в старому реєстрі, і в новому, а споживачі читають звичне джерело.

Співіснування двох контурів не ламає продуктивні сервіси — розходження видачі видно до того, як від нього хтось постраждав.

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

Доступ до etcd закриваємо взаємною перевіркою сертифікатів і роздільними ролями на читання й запис, щоб споживач не міг правити чужі ключі.

Критерій готовності групи сервісів — збіг видачі двох контурів і однакова реакція на зупинку екземпляра; тільки після цього перемикаємо читачів партіями.

Перехідний період тримаємо, доки всі споживачі не змінять джерело, — зазвичай це кілька хвиль за групами сервісів.

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

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

Типова помилка — вимикати старий реєстр за календарем, а не за фактом: поки хоч один споживач читає його, контур зобов'язаний відповідати.

Часті технічні питання: відмовостійкість і експлуатація

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

Як влаштовано відновлення після збою?

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

Чи є запас щодо масштабування?

Зростає не кількість вузлів, а обсяг ключів: реєстр зберігає адреси сервісів, а не їхній трафік. Десятки тисяч записів обслуговує той самий склад із п'яти вузлів.

При високому навантаженні на читання додаємо спостерігачів — вони не беруть участі у виборі лідера й не впливають на кворум.

Які вимоги до оточення й доступів?

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

Обговоримо ваше завдання: схема реєстру й план впровадження

Щоб оцінка була предметною, а не «на око», нам потрібні вихідні дані: перелік сервісів та їхні залежності, вимоги до доступності й часу відновлення, поточна схема мережі, місце під кластер etcd і люди на вашому боці, відповідальні за доступи й мережеві правила.

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

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

Обговорити завдання можна в листуванні або на короткому розборі: що вже є, що не працює, які терміни. Повернемося з оцінкою та планом, де видно обсяг і порядок кроків.