Уникнення зомбі-учасників кластера при оновленні до etcd v3.6

Автор: Benjamin Wang VMware by Broadcom, Josh Berkus Red Hat | Перекладач(і): Андрій Головін |

Ця стаття була нещодавно опублікована в офіційному блозі etcd. Основний висновок? Завжди оновлюйтеся до etcd v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та дозволяж уникати появі зомбі-учасників.

Підсумок проблеми

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

У etcd v3.5 та раніше v2store був джерелом істини для даних про членство, навіть якщо v3store також був присутній. Як частина нашого плану припинення підтримки v2store, у v3.6 v3store стає джерелом істини для інформації про членство в кластері. Зі звіту про баг ми дізналися, що в деяких старих кластерах v2store та v3store могли стати несумісними. Ця несумісність проявляється після оновлення як поява старих, видалених "зомбі" учасників кластера, які знову зʼявляються в кластері.

Виправлення та шлях оновлення

Ми додали механізм у etcd v3.5.26 для автоматичної синхронізації v3store з v2store, гарантуючи, що уражені кластери будуть відновлені перед оновленням до 3.6.x.

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

  1. Оновіть ваш кластер до v3.5.26 або пізнішої версії.
  2. Зачекайте та підтвердіть, що всі учасники є справними після оновлення.
  3. Оновіться до v3.6.

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

Додаткові технічні деталі

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

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

Супроводжувачі etcd, працюючи зі авторами повідомлення про проблему, виявили три можливі причини виникнення проблеми на основі симптомів та аналізу коду та логів etcd:

  1. Баг у etcdctl snapshot restore (v3.4 та старих версіях): Під час відновлення знімка за допомогою etcdctl snapshot restore, etcdctl мав видалити наявих учасників перед додаванням нових. У v3.4 через баг старі учасники не були видалені, що призвело до появи зомбі-учасників. Зверніться до коментаря щодо etcdctl.
  2. --force-new-cluster у v3.5 та попередніх версіях: У рідкісних випадках примусове створення нового кластера з одним учасником не повністю видаляло старих учасників, залишаючи зомбі. Проблема була вирішена у v3.5.22. Будь ласка, зверніться до цього PR у проєкті Raft для детальної технічної інформації.
  3. Увімкнено --unsafe-no-sync: Якщо --unsafe-no-sync увімкнено, у рідкісних випадках etcd може зберегти зміну членства у v3store, але аварійно завершити роботу перед записом у WAL, спричиняючи несумісність між v2store та v3store. Це проблема для кластерів з одним учасником. Для кластерів з багатьма учасниками примусове створення нового кластера з одним учасником з даних аварійного вузла може призвести до появи зомбі-учасників.

Важливо, що можуть бути інші причини для несумісності даних членства v2store та v3store, які ми ще не виявили. Це означає, що ви не можете припустити, що ви в безпеці лише тому, що не виконували жодної з трьох дій вище. Після оновлення користувачів до etcd v3.6 v3store стає джерелом даних про членство, і подальша несумісність неможлива.

Досвідчені користувачі, які хочуть перевірити сумісність між v2store та v3store, можуть слідувати крокам, описаним у цьому коментарі. Ця перевірка не потрібна для виправлення проблеми, і SIG etcd не рекомендує обходити оновлення v3.5.26 незалежно від результатів перевірки.

Основний висновок

Завжди оновлюйтеся до v3.5.26 або новішої версії перед переходом до v3.6. Це гарантує автоматичне відновлення кластера та уникає появі зомбі-учасників.

Подяки

Ми хотіли б подякувати Christian Baumann за повідомлення про цю давню проблему оновлення. Його звіт та подальша робота допомогли привернути нашу увагу до проблеми, щоб ми могли дослідити та вирішити її.