درون Rebalancer؛ چالش اشباع حافظه در مراکز داده متا

تصور کنید مدیر یک مرکز داده هستید و سامانه به شما می‌گوید تمام وظایف به‌طور بهینه توزیع شده‌اند، اما در واقعیت، سرورهای شما در آستانه فروپاشی حافظه هستند. این همان شکاف خطرناکی است که در پیاده‌سازی Rebalancer شرکت متا (Meta) دیده می‌شود. بهینه‌سازی نحوه توزیع وظایف در یک مرکز داده می‌تواند میلیون‌ها دلار از اتلاف منابع پردازشی را نجات دهد، اما Rebalancer ثابت می‌کند که تفاوت بین یک پرچم «حل‌شده» و یک طرح واقعاً بهینه، اغلب یک شکاف خطرناک است.

طبق مستندات فنی منتشر شده در ۱۳ اکتبر ۲۰۲۶، تکیه صرف بر پرچم‌های وضعیت (Solver Flags) در این ابزار می‌تواند فریبنده باشد؛ به‌طوری که سیستم وضعیت را «حل‌شده» (Solved) گزارش می‌کند، اما در عمل ظرفیت حافظه سرورها بیش از حد مجاز پر شده است.

مدیریت خوشه‌های عظیم نیازمند چیزی فراتر از توازن بار ساده است؛ این کار در واقع حل مسائل بهینه‌سازی مقید در لحظه است. همان‌طور که در تحلیل‌های قبلی ما درباره زیرساخت‌های سخت‌افزاری متا اشاره کردیم، این شرکت علاوه بر سخت‌افزارهای مصرف‌کننده مانند عینک‌های Ray-Ban برای حل اصطکاک‌های اجتماعی، روی حذف اصطکاک‌های نامرئی در بهره‌وری سرورها نیز متمرکز است. Rebalancer این چالش‌های جای‌گذاری را به مدل‌های قابل‌فهمی تبدیل می‌کند که از طریق جست‌وجوی محلی یا حل‌کننده دقیق HiGHS قابل حل هستند.

معماری هسته

این ابزار برای دستیابی به حداکثر سرعت از یک هسته C++ استفاده می‌کند و برای دسترسی آسان‌تر، رابط‌های پایتون دارد. ساختار آن بر پایه سلسله‌مراتبی از اشیاء، کانتینرها، ابعاد، محدوده‌ها و پارتیشن‌ها است:

• اشیاء (Objects): وظایف یا بارهای کاری که باید جای‌گذاری شوند.
• کانتینرها (Containers): میزبان‌ها یا سرورهایی که وظایف را می‌پذیرند.
• ابعاد (Dimensions): منابع مورد اندازه‌گیری، مانند CPU یا حافظه.
• محدوده‌ها (Scopes): گروه‌بندی‌های منطقی (مثل رک‌ها) برای اعمال محدودیت‌های سطح بالا.
• پارتیشن‌ها (Partitions): گروه‌بندی اشیاء بر اساس معیارهایی مثل شغل والد.

رویارویی حل‌کننده‌ها: جست‌وجوی محلی در برابر HiGHS

سامانه دو مسیر برای یافتن جواب ارائه می‌دهد. جست‌وجوی محلی (Local Search) برای سرعت طراحی شده، در حالی که HiGHS دقت ریاضیاتی ارائه می‌دهد. در این سیستم، رابط‌ها انوم‌ها (Enums) را به عنوان اعداد صحیح Thrift در نظر می‌گیرند؛ به این معنی که نام‌های متنی مانند "HARD" یا "HIGHS" رد می‌شوند و باید از اعداد یک جدول خاص استفاده کرد.

برای مثال، در جدول PACKAGE عدد ۰ به XPRESS، عدد ۱ به GUROBI و عدد ۲ به HIGHS اشاره دارد. به همین ترتیب، در جدول POLICY عدد ۱ به DEFAULT، عدد ۲ به HARD و عدد ۳ به SOFT نگاشت شده است. سایر جداول حیاتی شامل FORMULA (LINEAR: 1, SQUARES: 2, MAX: 3, IDEAL: 4) و LIMIT (ABSOLUTE: 1, RELATIVE: 2) هستند.

در یک تست روی مرکز داده کوچک با ۸ میزبان در ۴ رک، جست‌وجوی محلی توانست ۱۳ وظیفه را جابه‌جا کند تا تمام تخلفات CPU و حافظه را در میانگین ۲.۵ میلی‌ثانیه برطرف کند. در مقابل، HiGHS زمان بیشتری برد اما نتیجه‌ای از نظر ریاضی بهینه را تضمین کرد.

با این حال، یک تله بحرانی در این پیاده‌سازی وجود دارد: پرچم «حل‌شده». بر اساس بررسی‌ها، در ۲۴ مورد حل مسئله، سیستم برای ۱۴ مورد وضعیت True (حل‌شده) را گزارش کرد، در حالی که حافظه همچنان بیش از ظرفیت بود. این یعنی توسعه‌دهندگان نباید به حکم داخلی حل‌کننده اعتماد کنند و باید تخصیص‌های بازگشتی را به‌صورت دستی بازشماری کنند. در یک تست با چهار وظیفه ۱۰ گیگابایتی روی دو میزبان ۲۰ گیگابایتی (README model)، وقتی زمان حل (solveTime) روی صفر تنظیم شد، حل‌کننده هیچ جابه‌جایی نکرد و ۱۰ گیگابایت ظرفیت را تخطی کرد، اما باز هم گزارش داد که solved=True است.

اعمال محدودیت‌های پیچیده

Rebalancer اجازه می‌دهد قوانینی تعریف کنید که نیازهای واقعی مرکز داده را منعکس کند. یکی از این قوانین، محدودیت «یک وظیفه برای هر شغل در هر رک» است تا خرابی یک رک باعث از کار افتادن کل یک سرویس نشود. در مدل مرکز داده، این مورد با استفاده از groupCountSpec و مقدار کران ۱.۰ پیاده شد.

مکانیزم‌های محدودیت:

• محدودیت‌های مطلق (Absolute Limits): مرزهای سختی هستند که حل‌کننده هرگز نباید از آن‌ها عبور کند. در تست‌ها، این محدودیت به‌طور موفقیت‌آمیزی از تکرار رک‌ها جلوگیری کرد.
• محدودیت‌های نسبی (Relative Limits): بیشتر شبیه به دستورالعمل هستند تا قانون. تست‌ها نشان داد محدودیت نسبی در قانون رک‌ها عملاً هیچ اثری نداشت و ۵ مورد تکرار رک باقی ماند.
• محدودیت‌های تخلیه (ToFree Constraints): به اپراتورها اجازه می‌دهد یک میزبان شلوغ را با اجبار به جابه‌جایی تمام وظایف، «تخلیه» کنند. در تست تخلیه host1، جست‌وجوی محلی در ۱۳ حرکت میزبان را خالی کرد. اما وقتی بودجه جابه‌جایی (stopAfterMoves) اعمال شد، حل‌کننده زودتر متوقف شد؛ مثلاً در ۶ حرکت، بازشماری نشان داد ۴ تخلف CPU، ۱۶ گیگابایت حافظه اضافی و ۶ تکرار رک باقی مانده است، اما پرچم solved همچنان True بود.
• آیتم‌های محدوده انحصاری (ExclusiveScopeItems): از میزبانی هم‌زمان وظایف در کانتینرهای خاص جلوگیری می‌کند. در تستی با سه میزبان انحصاری دو به دو (host1, host2, host3)، جست‌وجوی محلی شکست خورد چون هیچ تک‌حرکتی مقدار brokenVal را کم نمی‌کرد، اما HiGHS در ۵.۹ میلی‌ثانیه مشکل را حل کرد.

قدرت تاپل‌های هدف

یکی از ظریف‌ترین ویژگی‌های Rebalancer استفاده از تاپل‌های هدف است. یک تاپل با رتبه پایین‌تر همیشه اولویت دارد، فارغ از اینکه وزن‌های داخلی آن چقدر باشد. این یک سلسله‌مراتب سخت از اولویت‌ها ایجاد می‌کند.

به‌عنوان مثال، اگر هدف «اصلاح خطا» (repairing a broken constraint) در تاپل دیرتری نسبت به هدف «کاهش جابه‌جایی» قرار بگیرد، حل‌کننده ممکن است ترجیح دهد یک میزبان را بیش از ظرفیت رها کند تا فقط از جابه‌جایی وظایف جلوگیری کند. جابه‌جا کردن ترتیب این تاپل‌ها، سیستم را مجبور می‌کند پایداری و ظرفیت را بر هزینه جابه‌جایی اولویت دهد.

مثال‌های منطق تاپل:

• موازنه وزن‌ها: در یک تاپل واحد، وزن‌ها اثرگذارند. وزن ۱ برای نزدیکی (affinity) در برابر وزن ۱۰۰۰ برای جابه‌جایی شکست می‌خورد و وظیفه در جای خود می‌ماند. جابه‌جایی این وزن‌ها باعث حرکت وظیفه می‌شود.
• تقدم تاپل: هدفی در تاپل ۰ بر هر وزنی در تاپل ۱ پیروز می‌شود.
• مقادیر اصلاحی: سیستم مقدار «اصلاح» (fix-it) را ۱۰,۰۰۰ به‌اضافه ۱۰۰ برابر مقدار brokenVal محاسبه می‌کند. مقدار brokenVal خود برابر است با مجموع مقدار اضافی تقسیم بر میانگین ظرفیت میزبان‌ها در ۱۵ نمونه.

محک در برابر OR-Library

برای اعتبارسنجی، این ابزار با ۶۰ نمونه از تخصیص تعمیم‌یافته (generalized-assignment) از OR-Library تست شد که با چک‌سام (sha256: 54513b5b96f6) تایید شده بودند. این نمونه‌ها شامل تعداد متغیری از عوامل و شغل‌ها بودند و مصرف منابع توسط یک بُعد شیء پویا تعریف شده بود.

HiGHS در تمام ۶۰ مورد با نتایج بهینه منتشرشده مطابقت داشت و کندترین حل آن ۱.۳۱ ثانیه بود. جست‌وجوی محلی در حالی که بسیار سریع‌تر بود، در دقت مشکل داشت. حتی با بهترین نتیجه از سه دانه تصادفی (با استفاده از حرکت‌های تک، جابه‌جایی، حلقه سه‌گانه و Kernighan-Lin)، تنها در ۴ مورد از ۶۰ مورد به جواب بهینه رسید و به‌طور میانگین ۱.۰۷٪ در سود (۷.۷ واحد سود) عقب ماند. در ۹ اجرا، میانگین کمبود بین ۷.۶ تا ۸.۱ بود.

مقیاس‌پذیری در خوشه‌های عظیم

در تست‌های سنتتیک روی تراشه Apple M4 با سیستم‌عامل macOS، Rebalancer یک خوشه با ۱,۰۰۰ شیء و ۱۰۰ کانتینر را در میانگین ۱.۳ ثانیه مدیریت کرد. سیستم تمام ۱۳ کانتینر دارای بار اضافی را در سه فرآیند مجزا پاکسازی کرد و هر بار هش تخصیص یکسانی را بازگرداند. برای خوشه‌ای با ابعاد ۱,۰۰۰ در ۱,۰۰۰، زمان حل به ۳.۵۵ ثانیه رسید.

وقتی مقیاس به ۱۰,۰۰۰ شیء روی ۱۰۰ کانتینر رسید، سیستم به سقف زمانی ۲۵ ثانیه برخورد کرد و دلیل پایان را HIT_TIME_LIMIT گزارش کرد. این نشان می‌دهد در مقیاس‌های بسیار بزرگ، دلیل پایان (endReason) معیار اصلی برای قضاوت درباره یک طرح ناقص است. دلایل پایان شامل موارد زیر است:

• OPTIMAL: بهترین راه حل ممکن یافت شد.
• HIT_TIME_LIMIT: حل به دلیل اتمام بودجه زمانی متوقف شد.
• HIT_MOVE_LIMIT: حل‌کننده به حداکثر جابه‌جایی‌های مجاز رسید.
• HIT_STOP_CONSTRAINT: یک محدودیت توقف خاص فعال شد.
• HIT_PLATEAU_TIME: برای مدتی مشخص هیچ بهبودی یافت نشد.
• NO_SOLUTION_FOUND: هیچ تخصیص معتبری یافت نشد.
• HIT_STAGE_MOVE_LIMIT: محدودیت جابه‌جایی یک مرحله خاص به پایان رسید.
• HIT_EXCEPTION: خطای داخلی در حین حل رخ داد.
• UNABLE_TO_FIND_MORE_MOVES: هیچ حرکت معتبر دیگری در دسترس نبود.
• HIT_MIN_CYCLE_OBJECTIVE_IMPROVEMENT: میزان بهبود به زیر آستانه حداقل رسید.
• UNABLE_TO_FIND_IMPROVING_MOVES: هیچ حرکتی که هدف را بهبود بخشد یافت نشد.

بسته‌بندی جعبه‌ای و کران L1

Rebalancer همچنین روی نمونه‌های بسته‌بندی جعبه‌ای (u120_00 و t60_00) در برابر کران پایین L1 تست شد که برابر با بهترین تعداد جعبه‌های شناخته شده (۴۸ و ۲۰) است.

• MinimizeContainers: جست‌وجوی محلی با شروع از FFD (first-fit decreasing) نتوانست هیچ جعبه‌ای را در هر دو نمونه حذف کند.
• Fixed-L1 Packing: وقتی مجبور شد دقیقاً از L1 جعبه استفاده کند، جست‌وجوی محلی توانست u120_00 را در ۰.۰۲ ثانیه ببندد و به کران بهینه برسد. اما برای t60_00 هیچ بسته‌بندی ۲۰ جعبه‌ای نیافت و HiGHS نیز پس از ۱۰ ثانیه متوقف شد. این توقف محدودیت زمانی است، نه اثبات ریاضی برای غیرممکن بودن.

تله‌های پیاده‌سازی عملی

توسعه‌دهندگان باید مراقب شکست‌های «ساکت» باشند. اشتباه در نوشتن کلیدهای تنظیمات (مثلاً stopAfterMove به‌جای stopAfterMoves) بدون هشدار نادیده گرفته می‌شود و حل‌کننده به‌سادگی تا انتها اجرا می‌شود. تابع کمکی spec() می‌تواند این موارد را قبل از حل شناسایی کند، اما ارسال مستقیم دیکشنری این بررسی را دور می‌زند.

همچنین برخی فرمول‌های توازن مثل IDEAL (که مجموع مجذورات بهره‌وری است) باعث بروز خطا در HiGHS می‌شوند، در حالی که جست‌وجوی محلی آن‌ها را به‌راحتی مدیریت می‌کند. سایر فرمول‌های موجود شامل LINEAR، SQUARES و MAX هستند.

برای استقرار در محیط عملیاتی، درس‌ها روشن است: انوم‌ها را به‌صورت عدد پاس دهید، هر کلید تنظیمات را تایید کنید و همیشه تخصیص نهایی را بازشماری کنید تا مطمئن شوید محدودیت‌ها واقعاً رعایت شده‌اند. آنچه باقی مانده این است که ببینیم Rebalancer در برابر ردپاهای واقعی خوشه‌های عمومی چگونه عمل می‌کند و آیا متا مجموعه‌ای از type-stubs را برای جلوگیری از شکست‌های ساکت کلیدها منتشر خواهد کرد یا خیر.

گام بعدی شما

• اگر از حل‌کننده‌های بهینه‌سازی در زیرساخت استفاده می‌کنید، هرگز به پرچم solved=True اعتماد نکنید و یک لایه بازبینی (Recount) برای تایید ظرفیت‌ها اضافه کنید.
• برای مسائل با محدودیت‌های سخت و متقاطع، از HiGHS استفاده کنید و جست‌وجوی محلی را تنها برای اصلاحات سریع و تقریبی به کار ببرید.
• ترتیب تاپل‌های هدف را بازبینی کنید تا مطمئن شوید اهداف حیاتی (مثل ظرفیت) فدای اهداف ثانویه (مثل کاهش جابه‌جایی) نمی‌شوند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.