کلیدواژهٔ اصلی این مقاله: etcdctl snapshot.
اجتناب از اعضای خوشه «زامبی» هنگام ارتقاء به etcd v3.6 🧭
هشدار کلیدی: قبل از ارتقاء مستقیم به etcd v3.6، حتماً ابتدا خوشه را به etcd نسخه 3.5.26 یا بالاتر ببرید. این قدم تضمین میکند که خوشه بهصورت خودکار تعمیر شود و از بروز اعضای زامبی جلوگیری شود 🙂
مسئله چیست؟ اخیراً در برخی خوشههای قدیمی هنگام رفتن از 3.5 به 3.6 ناسازگاری بین دادههای عضویت گزارش شده است. نتیجهٔ این ناسازگاری ظهور دوبارهٔ گرههایی است که قبلاً از خوشه حذف شده بودند — این «اعضای زامبی» پس از پیوستن مجدد به اجماع، میتوانند خوشه را تا زمانی که حذف نشوند غیرقابلاستفاده کنند.
چرا این اتفاق میافتد؟ تا نسخههای 3.5 و قدیمیتر، v2store منبع حقیقت برای دادههای عضویت بود، هرچند v3store هم وجود داشت. در مسیر حذف v2store، در نسخه 3.6 تصمیم گرفته شده که v3store منبع حقیقت شود. در بعضی خوشههای قدیمی دیده شده که v2store و v3store ناسازگار هستند؛ این ناهماهنگی ممکن است بعد از ارتقاء آشکار شود و اعضای قدیمی که حذف شده بودند دوباره بهصورت «زامبی» ظاهر شوند.
راهکار ایمن چیست؟ یک مکانیزم در etcd نسخه 3.5.26 اضافه شده که v3store را از v2store بهطور خودکار همگام میکند. به همین دلیل مسیر ایمن پیشنهادی این است: اول خوشه را به 3.5.26 یا بالاتر ارتقا دهید، صبر کنید و تأیید کنید همه اعضا بعد از بهروزرسانی سالم هستند، و سپس به 3.6 بروید. اگر بستهٔ 3.5.26 از طرف توزیع یا فروشندهتان در دسترس نیست، تا حضور آن نسخه ارتقاء به 3.6 را به تعویق بیاندازید 🚦
توضیحات فنی (خلاصه و کاربردی): این مشکل عمدتاً در خوشههایی رخ میدهد که در محیط تولید با etcd نسخه 3.5.25 یا قدیمیتر کار میکنند و معمولاً پس از افزودن/حذف اعضا یا بازیابی خوشه از شکست ظاهر میشود. هرچه خوشه قدیمیتر و پرتغییرتر باشد، احتمال بروز این مشکل بیشتر است؛ اما حتی خوشههای نهچندانقدیمی هم ممکن است آسیبپذیر باشند.
سه محرک شناساییشده که اغلب با این مشکل مرتبط هستند:
1) باگ در etcdctl snapshot restore در نسخههای قدیمیتر (مثلاً v3.4): این ابزار قرار بود اعضای موجود را قبل از اضافه کردن اعضای جدید حذف کند، اما بهخاطر باگ اعضای قدیمی حذف نشدند و زامبی ایجاد شد. به توضیحات etcdctl مراجعه کنید. 🔍
2) استفاده از –force-new-cluster در نسخههای 3.5 و قبل: در موارد نادر ایجاد اجباری یک خوشهٔ تکعضوی جدید بهدرستی اعضای قدیمی را پاک نکرد و زامبیها باقی ماندند. این مشکل در نسخه 3.5.22 رفع شد. برای جزئیات بیشتر به مستندات پروتکل Raft مراجعه کنید.
3) فعال بودن –unsafe-no-sync: اگر این گزینه روشن باشد، ممکن است تغییر عضویت به v3store ادامه یابد اما قبل از نوشتن آن در WAL از کار بیفتد که باعث ناهماهنگی بین v2store و v3store میشود؛ این حالت بهویژه در خوشههای تکعضوی خطرناک است. بهطور کلی –unsafe-no-sync توصیه نمیشود زیرا میتواند ضمانتهای پروتکل اجماع را نقض کند ⚠️
نکتهٔ مهم: ممکن است عوامل دیگری هم محرک شوند؛ بنابراین صرف اینکه شما هیچیک از سه مورد بالا را انجام ندادهاید، بهمعنای ایمن بودن قطعی نیست. پس همیشه پیش از ارتقاء به 3.6 مسیر ایمن را دنبال کنید.
پس از ارتقاء به etcd v3.6، v3store بهعنوان منبع حقیقت عضویت درنظر گرفته میشود و پس از آن احتمال بروز تناقضهای بیشتر کاهش مییابد. اگر کاربر پیشرفتهای هستید و میخواهید سازگاری v2store و v3store را بررسی کنید، میتوانید مراحل فنی توصیهشده در مستندات مربوط را دنبال کنید؛ اما این بررسی برای انجام ارتقاء ضروری نیست و توصیه نمیشود که بهخاطر نتایج چنین بررسیای از ارتقاء به 3.5.26 صرفنظر کنید.
خلاصهٔ عملی برای تیمهای DevOps / SRE: اول و مهمتر از همه، نسخهٔ میانی 3.5.26 را وارد چرخهٔ ارتقاء کنید، وضعیت عضویت را مانیتور کنید و پس از اطمینان از ثبات خوشه، به 3.6 بروید. این فرایند بهطور محسوسی از بروز اعضای زامبی جلوگیری میکند و خوشه را قابلاطمینان نگه میدارد 👍
تشکر ویژه از کریستین باومن بهخاطر گزارش و پیگیری این مشکل که باعث شد تیمها زودتر متوجه شوند و راهحل مناسبی پیادهسازی شود 🙏
