حلقه تطبیق: کنترلرهای کوبرنیتیز چگونه وضعیت مطلوب را در یک سیستم توزیع‌شده حفظ می‌کنند

برای اینکه هر سیستم توزیع‌شده‌ای بتواند بازیابی خود را خودکار کند، یک شرط الزام‌آور باید برقرار باشد: سیستم به یک منبع حقیقت مطلق و دست‌نخورده و دیدی بدون مانع به سخت‌افزار واقعی نیاز دارد. اگر یک صفحه کنترل نتواند واقعیت را مشاهده کند یا آن را تغییر دهد، هماهنگ‌سازی غیرممکن است. در کوبرنیتیز، این شرط توسط سرور ای‌پی‌آی و پایگاه داده ای‌تی‌سی‌دی که وضعیت مطلوب اعلانی را در خود نگه می‌دارند، برآورده می‌شود. تا زمانی که این وضعیت در دسترس باشد، کلاستر می‌تواند خود را از تقریباً هر خرابی بازسازی کند.

صنعت نرم‌افزارهای سازمانی، کوبرنیتیز را با هیاهوی فراوان به عنوان یک هماهنگ‌کننده «خودترمیم‌شونده» و تقریباً هوشمند که قادر به تصمیم‌گیری خودکار است، بازاریابی می‌کند. فروشندگان مرتباً اصطلاحاتی مانند «عملیات مبتنی بر هوش مصنوعی» را به محصولات زیرساختی خود می‌چسبانند. اما واقعیتی که در کدهای این سیستم پیاده‌سازی شده، بسیار مکانیکی‌تر و قطعی‌تر است. این یک هوش مصنوعی نیست؛ بلکه مجموعه‌ای از حلقه‌های بی‌نهایت است که در پس‌زمینه اجرا می‌شوند.

در قلب این سیستم، حلقه تطبیق قرار دارد. بر اساس مستندات رسمی کوبرنیتیز که در سپتامبر ۲۰۲۴ به‌روزرسانی شده است: «یک کنترلر حداقل یک نوع منبع کوبرنیتیز را ردیابی می‌کند. این اشیاء دارای یک فیلد اسپک هستند که وضعیت مطلوب را نشان می‌دهد.» تنها مسئولیت کنترلر این است که وضعیت فعلی کلاستر را با آن وضعیت مطلوب مطابقت دهد.[5]

این حلقه یک فرآیند سه‌مرحله‌ای دقیق و پایان‌ناپذیر را اجرا می‌کند: مشاهده، مقایسه و اقدام. این سیستم یک اسکریپت از پیش‌تعریف‌شده یا یک جریان کاری مرحله‌به‌مرحله را اجرا نمی‌کند. در عوض، تفاوت بین دو فیلد تودرتو را محاسبه می‌کند. فیلد اسپک آنچه را که کاربر می‌خواهد اعلام می‌کند—مانند اجرای دقیقاً سه نسخه از یک وب‌سرور. فیلد استاتوس آنچه را که در واقعیت روی سخت‌افزار وجود دارد، گزارش می‌دهد.[2]

زیرساخت‌های سنتی به شدت به دستورات امری متکی بودند. مهندسان اسکریپت‌هایی می‌نوشتند که دنباله‌ای از مراحل را اجرا می‌کرد: تامین یک ماشین مجازی، نصب وابستگی‌ها، اجرای برنامه. اگر مرحله دوم به دلیل قطعی شبکه با شکست مواجه می‌شد، اسکریپت از کار می‌افتاد و سیستم را در یک وضعیت نامعلوم و خراب رها می‌کرد که برای رفع آن به دخالت انسان نیاز بود.

از آنجا که حلقه تطبیق ماهیتی اعلانی دارد، برایش مهم نیست که سیستم چگونه به وضعیت فعلی خود رسیده است. اگر یک سرور فیزیکی برق خود را از دست بدهد و سه پاد برنامه از دسترس خارج شوند، کنترلر نیازی به یک اسکریپت خاص مدیریت خطا برای قطعی برق ندارد. او به سادگی بیدار می‌شود، می‌بیند که تعداد پادهای واقعی صفر است در حالی که تعداد مطلوب سه است، و دستوراتی را به سرور ای‌پی‌آی صادر می‌کند تا سه پاد جدید ایجاد کند.[3]

یک نیاز حیاتی برای این معماری، ویژگی هم‌توانی است. تابع تطبیق کنترلر باید بتواند صدها بار بدون ایجاد عوارض جانبی ناخواسته اجرا شود. راهنمای فنی سال ۲۰۲۱ شرکت ردهت خاطرنشان می‌کند: «هنگام توسعه اپراتورها، حلقه تطبیق کنترلر باید هم‌توان باشد.» اگر وضعیت مطلوب از قبل برآورده شده باشد، حلقه تفاوت را ارزیابی می‌کند، واریانس را صفر می‌یابد و هیچ اقدامی انجام نمی‌دهد.[1]

در صفحه کنترل کوبرنیتیز، مؤلفه‌ای به نام مدیر کنترلر این حلقه‌ها را به طور پیوسته اجرا می‌کند. کنترلرهای داخلی، منابع بومی را مدیریت می‌کنند. به عنوان مثال، کنترلر رپلیکا‌ست اطمینان حاصل می‌کند که تعداد صحیحی از پادها در حال اجرا هستند، در حالی که کنترلر جاب وظایف محدود را اجرا می‌کند. ردهت توضیح می‌دهد: «مدیر کنترلر یک حلقه کنترلی را اجرا می‌کند که به هر کنترلر اجازه می‌دهد با فراخوانی متد تطبیق خود اجرا شود.»[1]

این معماری به گونه‌ای طراحی شده که قابل توسعه باشد. صنعت به شدت روی «اپراتورها» مانور تبلیغاتی داده است—کنترلرهای سفارشی که حلقه تطبیق را روی سیستم‌های خارجی یا پیچیده مانند پایگاه‌های داده، صف‌های پیام و لایه‌های کش اعمال می‌کنند. با تعریف یک منبع سفارشی، تیم‌های مهندسی می‌توانند مفاهیم خاص یک دامنه را به کوبرنیتیز آموزش دهند.[2]

در حالی که فروشندگان این اپراتورها را به عنوان «مدیران پایگاه داده خودکار» می‌فروشند، قابلیتی که در عمل ارائه می‌شود اساساً فقط یک منبع سفارشی است که با یک حلقه تطبیق استاندارد جفت شده است. این قابلیت، فراخوانی‌های ای‌پی‌آی خاص یک دامنه را کدگذاری می‌کند—مانند نحوه تهیه نسخه پشتیبان ایمن از یک پایگاه داده پستگرس‌کیوال—اما مکانیزم زیربنایی همان مقایسه ساده بین فیلدهای اسپک و استاتوس باقی می‌ماند.[6]

با مقیاس‌پذیری کلاسترها به هزاران نود، اجرای یک حلقه تطبیق واحد به یک گلوگاه عملکردی تبدیل می‌شود. کنترلرها می‌توانند برای تطبیق همزمان پیکربندی شوند و چندین رویداد را به طور همزمان پردازش کنند. با این حال، این امر شرایط رقابتی را به وجود می‌آورد. بر اساس مستندات گیت‌هاب در مورد تطبیق همزمان، مکانیزم‌های قفل‌گذاری دقیق یا کنترل همزمانی خوش‌بینانه مورد نیاز است تا اطمینان حاصل شود که دو حلقه در یک میلی‌ثانیه دقیقاً یک شیء را تغییر نمی‌دهند.[4]

حلقه تطبیق یک راه‌حل ظریف برای مدیریت سیستم‌های توزیع‌شده است، اما یک محدودیت سخت دارد. این الگو فرض می‌کند که صفحه کنترل در دسترس‌پذیری بالایی قرار دارد و می‌توان به سرور ای‌پی‌آی متصل شد. اگر پایگاه داده ای‌تی‌سی‌دی از کار بیفتد یا خراب شود، حلقه، حافظه خود را از وضعیت مطلوب از دست می‌دهد. در آن نقطه، سیستم به طور کامل از ترمیم باز می‌ایستد و واقعیت مکانیکی پنهان در پس بازاریابی‌های خودکارسازی را آشکار می‌کند.[6]