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

Підсумок: SIG-etcd виправила ще одну потенційну проблему, що блокує оновлення з v3.5 до v3.6. Якщо ви оновлюєтеся, обовʼязково спочатку оновіться до v3.5.26 або новішої версії.

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

Нещодавно спільнота 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 за повідомлення про цю давню проблему оновлення. Його звіт та подальша робота допомогли привернути нашу увагу до цієї проблеми, щоб ми могли розслідувати та вирішити її.

• ←Попередня
• Наступна→