Переконфігурація під час виконання

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

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

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

Випадки використання переконфігурації

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

Заміна або оновлення кількох машин

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

Безпечно видаляти лідера, однак буде короткий період простою під час процесу виборів. Якщо кластер містить понад 50 МБ даних v2, рекомендується перенести теку даних члена.

Зміна розміру кластера

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

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

Заміна зламаної машини

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

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

Перезапуск кластера після збою більшості

Якщо більшість кластера втрачено або всі вузли змінили IP-адреси, необхідно вжити ручних заходів для безпечного відновлення. Основні кроки в процесі відновлення включають створення нового кластера з використанням старих даних, примусове призначення одного члена лідером і, нарешті, використання конфігурації під час виконання для додавання нових членів до цього нового кластера по одному.

Відновлення кластера після збою меншості

Якщо певного члена втрачено, це еквівалентно заміні зламаної машини. Кроки описані в розділі Заміна зламаної машини.

Операції переконфігурації кластера

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

Перед внесенням будь-яких змін проста більшість (кворум) членів etcd повинна бути доступна. Це по суті та сама вимога для будь-якого виду запису в etcd.

Усі зміни в кластері повинні виконуватися послідовно:

• Щоб оновити peerURLs одного члена, виконайте операцію оновлення
• Щоб замінити справного члена, видаліть старого члена, а потім додайте нового члена
• Щоб збільшити кількість членів з 3 до 5, виконайте дві операції додавання
• Щоб зменшити кількість членів з 5 до 3, виконайте дві операції видалення

Усі ці приклади використовують інструмент командного рядка etcdctl, який постачається з etcd. Щоб змінити склад без etcdctl, використовуйте v2 HTTP members API або v3 gRPC members API.

Оновлення члена

Оновлення advertise client URLs

Щоб оновити advertise client URLs члена, просто перезапустіть цього члена з оновленим прапорцем client urls (--advertise-client-urls) або змінною середовища (ETCD_ADVERTISE_CLIENT_URLS). Перезапущений член самостійно опублікує оновлені URL-адреси. Неправильно оновлена URL-адреса клієнта не вплине на справність кластера etcd.

Оновлення advertise peer URLs

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

Щоб оновити advertise peer URLs, спочатку знайдіть ID цільового члена. Щоб перелічити всіх членів за допомогою etcdctl:

$ etcdctl member list
6e3bd23ae5f1eae0: name=node2 peerURLs=http://localhost:23802 clientURLs=http://127.0.0.1:23792
924e2e83e93f2560: name=node3 peerURLs=http://localhost:23803 clientURLs=http://127.0.0.1:23793
a8266ecf031671f3: name=node1 peerURLs=http://localhost:23801 clientURLs=http://127.0.0.1:23791

Цей приклад оновить ID члена a8266ecf031671f3 і змінить його значення peerURLs на http://10.0.1.10:2380:

$ etcdctl member update a8266ecf031671f3 --peer-urls=http://10.0.1.10:2380
Updated member with ID a8266ecf031671f3 in cluster

Видалення члена

Припустимо, що ID члена для видалення — a8266ecf031671f3. Використовуйте команду remove для виконання видалення:

$ etcdctl member remove a8266ecf031671f3
Removed member a8266ecf031671f3 from cluster

Цільовий член зупиниться в цей момент і виведе видалення в журнал:

etcd: this member has been permanently removed from the cluster. Exiting.

Безпечно видаляти лідера, однак кластер буде неактивним, поки не буде обрано нового лідера. Цей період зазвичай триває період тайм-ауту виборів плюс процес голосування.

Додавання нового члена

Додавання члена — це двоетапний процес:

• Додайте нового члена до кластера за допомогою HTTP members API, gRPC members API або команди etcdctl member add.
• Запустіть нового члена з новою конфігурацією кластера, включаючи список оновлених членів (наявні члени + новий член).

etcdctl додає нового члена до кластера, вказуючи імʼя члена та оголошені peer URLs:

$ etcdctl member add infra3 --peer-urls=http://10.0.1.13:2380
added member 9bf1b35fc7761a23 to cluster

ETCD_NAME="infra3"
ETCD_INITIAL_CLUSTER="infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra3=http://10.0.1.13:2380"
ETCD_INITIAL_CLUSTER_STATE=existing

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

$ export ETCD_NAME="infra3"
$ export ETCD_INITIAL_CLUSTER="infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra3=http://10.0.1.13:2380"
$ export ETCD_INITIAL_CLUSTER_STATE=existing
$ etcd --listen-client-urls http://10.0.1.13:2379 --advertise-client-urls http://10.0.1.13:2379 --listen-peer-urls http://10.0.1.13:2380 --initial-advertise-peer-urls http://10.0.1.13:2380 --data-dir %data_dir%

Новий член буде працювати як частина кластера і негайно почне наздоганяти решту кластера.

Якщо додається кілька членів, найкраща практика — налаштовувати одного члена за раз і перевіряти, чи він правильно запускається, перш ніж додавати більше нових членів. Якщо додається новий член до кластера з 1 вузлом, кластер не зможе продовжувати роботу, поки новий член не запуститься, оскільки для досягнення консенсусу потрібні два члени. Ця поведінка відбувається лише між часом, коли etcdctl member add повідомляє кластер про нового члена, і новий член успішно встановлює зʼєднання з наявним.

Додавання нового члена як учня

Починаючи з версії v3.4, etcd підтримує додавання нового члена як учня / члена без права голосу. Мотивацію та дизайн можна знайти в документі дизайну. Щоб зробити процес додавання нового члена безпечнішим і зменшити час простою кластера під час додавання нового члена, рекомендується додавати нового члена до кластера як учня, поки він не наздожене лідера. Це можна описати як триетапний процес:

• Додайте нового члена як учня за допомогою gRPC members API або команди etcdctl member add --learner.

• Запустіть нового члена з новою конфігурацією кластера, включаючи список оновлених членів (поточні члени + новий член). Цей крок точно такий же, як і раніше.

• Підвищіть новододаного учня до члена з правом голосу за допомогою gRPC members API або команди etcdctl member promote. Сервер etcd перевіряє запит на підвищення, щоб забезпечити його безпеку. Лише після того, як його журнал raft наздожене лідера, учень може бути підвищений до члена з правом голосу. Якщо журнал raft учня не наздогнав журнал лідера, запит на підвищення члена не вдасться (див. випадки помилок при підвищенні члена для отримання додаткової інформації). У цьому випадку користувач повинен почекати та спробувати пізніше.

У версії v3.4 сервер etcd обмежує кількість учнів, які може мати кластер, до одного. Основна причина — обмежити додаткове навантаження на лідера через поширення даних від лідера до учня.

Використовуйте etcdctl member add з прапорцем --learner, щоб додати нового члена до кластера як учня.

$ etcdctl member add infra3 --peer-urls=http://10.0.1.13:2380 --learner
Member 9bf1b35fc7761a23 added to cluster a7ef944b95711739

ETCD_NAME="infra3"
ETCD_INITIAL_CLUSTER="infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra3=http://10.0.1.13:2380"
ETCD_INITIAL_CLUSTER_STATE=existing

Після запуску нового процесу etcd для новододаного учня використовуйте etcdctl member promote, щоб підвищити учня до члена з правом голосу.

$ etcdctl member promote 9bf1b35fc7761a23
Member 9e29bbaa45d74461 promoted in cluster a7ef944b95711739

Випадки помилок при додаванні членів

У наступному випадку новий хост не включений до списку перерахованих вузлів. Якщо це новий кластер, вузол повинен бути доданий до списку початкових членів кластера.

$ etcd --name infra3 \
  --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380 \
  --initial-cluster-state existing
etcdserver: assign ids error: the member count is unequal
exit 1

У цьому випадку вкажіть іншу адресу (10.0.1.14:2380) від тієї, яка використовувалася для приєднання до кластера (10.0.1.13:2380):

$ etcd --name infra4 \
  --initial-cluster infra0=http://10.0.1.10:2380,infra1=http://10.0.1.11:2380,infra2=http://10.0.1.12:2380,infra4=http://10.0.1.14:2380 \
  --initial-cluster-state existing
etcdserver: assign ids error: unmatched member while checking PeerURLs
exit 1

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

$ etcd
etcd: this member has been permanently removed from the cluster. Exiting.
exit 1

Випадки помилок при додаванні учня

Не можна додати учня до кластера, якщо кластер вже має 1 учня (v3.4).

$ etcdctl member add infra4 --peer-urls=http://10.0.1.14:2380 --learner
Error: etcdserver: too many learner members in cluster

Випадки помилок при підвищенні учня

Учня можна підвищити до члена з правом голосу лише тоді, коли він синхронізований з лідером.

$ etcdctl member promote 9bf1b35fc7761a23
Error: etcdserver: can only promote a learner member which is in sync with leader

Підвищення члена, який не є учнем, не вдасться.

$ etcdctl member promote 9bf1b35fc7761a23
Error: etcdserver: can only promote a learner member

Підвищення члена, який не існує в кластері, не вдасться.

$ etcdctl member promote 12345abcde
Error: etcdserver: member not found

Режим суворої перевірки переконфігурації (-strict-reconfig-check)

Як описано вище, найкраща практика додавання нових членів — налаштовувати одного члена за раз і перевіряти, чи він правильно запускається, перш ніж додавати більше нових членів. Цей покроковий підхід дуже важливий, оскільки якщо новододані члени не налаштовані правильно (наприклад, peer URLs неправильні), кластер може втратити кворум. Втрата кворуму відбувається, оскільки новододані члени враховуються в кворумі, навіть якщо цей член недоступний для інших наявних членів. Також втрата кворуму може статися, якщо виникає проблема з підключенням або є операційні проблеми.

Щоб уникнути цієї проблеми, etcd надає опцію -strict-reconfig-check. Якщо ця опція передається до etcd, etcd відхиляє запити на переконфігурацію, якщо кількість запущених членів буде менше кворуму переконфігурованого кластера.

Вона стандартно увімкнена.