‏الگوی ۲+۲+۱ برای دیتابیس‌های همیشه‌آنلاین روی کوبرنتیز

روی یه کلاستر کوبرنتیز تنها، اگه کل یه منطقه بخوره زمین، کنترل‌پلین خراب بشه یا شبکه قطع بشه، دیتابیستون بدون هیچ راه بازیابی خودکاری از کار می‌افته. نویسنده‌ها تو این پست، با استفاده از اپراتور پرکونا برای MongoDB (یه Operator اپن‌سورس تحت لایسنس Apache 2.0)، نشون می‌دن چطور می‌شه نودهای MongoDB رو بین چند کلاستر کوبرنتیز پخش کرد تا هم Disaster Recovery داشته باشین، هم بدون قطع سرویس ترافیک رو بین محیط‌ها جابه‌جا کنین یا یه کلاستر رو برای آپدیت خالی کنین.

معماری بر پایه دو نقش: Main Site که کاملاً زیر دست اپراتوره، نود Primary رو نگه می‌داره و کار صدور گواهی‌های TLS، اعتبارنامه‌ی کاربرها و تنظیم replica set هم با همینه؛ Replica Site هم تو حالت unmanaged اجرا می‌شه، به‌جای ساختن replica set جدید، گواهی‌ها و اعتبارنامه‌های Main Site رو کپی می‌کنه و بهش ملحق می‌شه. همه‌ی نودها، فارغ از این‌که تو کدوم کلاستر باشن، عضو یه replica set واحدن که رأی‌گیری و انتخاب رهبر بین کلاستری رو ممکن می‌کنه.

ارتباط بین کلاسترها از طریق Kubernetes Multi-Cluster Services API (MCS API) برقرار می‌شه؛ با فعال کردن multiCluster.enabled، اپراتور منابع ServiceExport و ServiceImport رو می‌سازه تا نودهای کلاسترهای مختلف از طریق یه zone مشترک DNS همدیگه رو پیدا کنن. توجه کنین که MCS API تو نصب استاندارد کوبرنتیز نیست و به ابزاری مثل Submariner، Cilium ClusterMesh یا سرویس MCS بومی GKE نیاز داره:

multiCluster:
  enabled: true  # فعال‌سازی سرویس چندکلاستری
  DNSSuffix: svc.clusterset.local

نکته کلیدی بعدی الگوی معروف به ۲+۲+۱ـه. یه replica set برای انتخاب Primary باید اکثریت مطلق رأی‌ها رو داشته باشه؛ اگه چهار نود رأی‌دهنده رو مساوی بین دو سایت پخش کنین، با قطع شبکه‌ی بین اون دو، هیچ‌کدوم به اکثریت نمی‌رسن و کل سیستم متوقف می‌شه، حتی اگه همه‌ی سرورها سالم باشن. راه‌حل، اضافه کردن یه نود پنجم تو یه سایت سومه؛ این‌طوری از مجموع پنج رأی، یه طرف همیشه به سه رأی (اکثریت) می‌رسه:

externalNodes:
  - host: third-site-rs0-4.psmdb.svc.clusterset.local
    votes: 1
    priority: 1

بعد از یه قطعی منطقه‌ای، سیستم وارد حالت «تنزل‌یافته» می‌شه: یه نود تو سایت دوم Primary جدید می‌شه، ولی دیتابیس دقیقاً با حداقل تعداد نود لازم برای اکثریت کار می‌کنه و دیگه هیچ حاشیه امنیتی نداره؛ از دست رفتن حتی یه نود دیگه سیستم رو به حالت read-only قفل می‌کنه. به گفته‌ی نویسنده‌ها، تو تنظیمات پیش‌فرض انتخاب Primary جدید معمولاً بیشتر از ۱۲ ثانیه طول نمی‌کشه، هرچند تو محیط‌های چندمنطقه‌ای بهتره اپلیکیشن از retryable writes استفاده کنه تا اون بازه‌ی کوتاه بی‌Primary رو بدون خطا رد کنه.

نکات کلیدی:

• روی یه کلاستر تنها، قطعی منطقه یا شبکه می‌تونه کل دیتابیس رو از کار بندازه
• اپراتور پرکونا برای MongoDB با نقش‌های Main Site و Replica Site این مشکل رو حل می‌کنه
• ارتباط بین کلاسترها از طریق Kubernetes MCS API و یه DNS مشترک برقرار می‌شه
• الگوی ۲+۲+۱ با اضافه کردن یه رأی پنجم تو سایت سوم، از قفل شدن رأی‌گیری جلوگیری می‌کنه
• بعد از فیل‌اُور، سیستم کار می‌کنه ولی حاشیه امنیتی‌ش صفر می‌شه