Режими відмов

Види відмов та стійкість etcd до них

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

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

Незначний збій у послідовниках

Коли виходить з ладу менше половини послідовників, кластер etcd все ще може приймати запити та просуватися без будь-яких серйозних збоїв. Наприклад, вихід з ладу двох послідовників не вплине на роботу кластера etcd з пʼяти членів. Однак клієнти втратять зʼєднання з членами, що зазнали збою. Бібліотеки клієнтів повинні приховувати ці переривання від користувачів для запитів на читання, автоматично перепідключаючись до інших членів. Оператори повинні очікувати збільшення навантаження на інші члени через перепідключення.

Збій у роботі лідера

Коли лідер зазнає невдачі, кластер etcd автоматично обирає нового лідера. Вибори не відбуваються миттєво, як тільки лідер виходить з ладу. Для обрання нового лідера потрібен певний тайм-аут, оскільки модель виявлення збоїв базується на тайм-аутах.

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

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

Новий лідер автоматично продовжує тайм-аути для всіх оренд. Цей механізм гарантує, що оренда не закінчиться до закінчення наданого TTL, навіть якщо вона була надана старим лідером.

Збій у роботі більшості

Коли більшість членів кластера виходять з ладу, кластер etcd виходить з ладу і не може приймати більше записів.

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

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

Розділ мережі

Мережевий розділ схожий на відмову незначних послідовників або відмову лідера. Мережевий поділ розділяє кластер etcd на дві частини; одна з більшістю членів і інша з меншістю членів. Сторона з більшістю стає доступним кластером, а сторона з меншістю стає недоступною. У etcd немає “роздвоєння мозку”, оскільки члени кластера явно додаються/видаляються, і кожна така зміна затверджується поточною більшістю членів.

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

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

Збій під час початкового завантажування

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

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