CXL memory pooling از اسلایدهای roadmap به انتخاب واقعی در طراحی دیتاسنتر تبدیل می‌شود

برای مدت طولانی، Compute Express Link شبیه یکی از آن فناوری‌های دیتاسنتر بود که همه قبول داشتند روزی مهم می‌شود. این فناوری در keynoteها، دیاگرام‌های معماری و roadmapهای مربوط به زیرساخت‌های ترکیب‌پذیر دیده می‌شد، اما بیشتر اپراتورها هنوز سرورها را به روش قدیمی می‌خریدند: سوکت‌های ثابت CPU، حافظه محلی ثابت، و فرضیات ارتقاء ثابت. این وضعیت در حال تغییر است. حالا که workloadهای AI هزینه حافظه‌های بلااستفاده (stranded memory) و محدودیت‌های طراحی صلب سرور را آشکار کرده‌اند، CXL برای توسعه حافظه و pooling از تئوری به بحث خرید تبدیل شده است.

دلیلش ساده است. زیرساخت مدرن نامتوازن شده است. بعضی workloadها به پردازش نیاز دارند، بعضی به حافظه، و خیلی‌ها در ساعات مختلف روز به هر دو. اما سرورهای معمولی خریداران را مجبور می‌کنند CPU و DRAM را در گام‌های نسبتاً درشت تأمین کنند. این باعث اتلاف می‌شود. تیم‌ها اغلب برای ظرفیت حافظه محلی هزینه می‌کنند که روی یک node کم‌استفاده است، درحالی‌که workload مجاور محدودیت دارد. CXL جذاب است چون رابطه روان‌تری بین پردازنده‌ها و حافظه وعده می‌دهد، مخصوصاً در محیط‌هایی که AI inference، analytics و مجازی‌سازی منحنی‌های تقاضای غیرقابل پیش‌بینی ایجاد می‌کنند.

تغییری که CXL در مقایسه با حافظه سنتی سرور ایجاد می‌کند

در سطح بالا، CXL ایده‌های interconnect پرسرعت را گسترش می‌دهد تا CPUها، شتاب‌دهنده‌ها و دستگاه‌های حافظه بتوانند داده‌ها را منسجم‌تر از مدل‌های قدیمی اتصال به اشتراک بگذارند. برای خریداران زیرساخت، نکته عملی، ظرافت پروتکل نیست؛ بلکه انعطاف‌پذیری است. به‌جای اینکه حافظه سرور را به‌طور دائمی به هویت یک node متصل بدانند، اپراتورها می‌توانند به حافظه به‌عنوان منبعی فکر کنند که می‌تواند به‌صورت انعطاف‌پذیر گسترش یابد، لایه‌بندی شود، یا در برخی موارد pooling شود.

این بدان معنا نیست که ناگهان هر rack به یک fabric حافظه کامل تبدیل می‌شود. تأخیر (latency) همچنان مهم است، نرم‌افزار باید توپولوژی را درک کند، و DDR محلی برای بسیاری از workloadهای داغ پاسخ درست است. اما CXL گزینه‌ها را تغییر می‌دهد. یک تیم پلتفرم می‌تواند بپرسد آیا یک workload واقعاً به تمام DRAM با بالاترین عملکرد محلی نیاز دارد، یا بخشی از ظرفیت می‌تواند پشت یک لایه CXL-attached با tradeoff عملکرد قابل قبول قرار گیرد. این سؤال چند سال پیش در برنامه‌ریزی سرورهای اصلی عملی نبود.

AI هزینه حافظه‌های بلااستفاده را غیرقابل توجیه می‌کند

زیرساخت AI دلیل بزرگی است که CXL حالا مطرح می‌شود، نه فردا. کلاسترهای آموزشی تیتر یک هستند، اما فشار عملیاتی بیشتر روی inference، workloadهای vector و Pipelineهای آماده‌سازی داده است که به مجموعه‌های کاری بزرگ و سریع نیاز دارند بدون اینکه همیشه از CPU، GPU و حافظه به نسبت متوازن استفاده کنند. در این محیط‌ها، حافظه بلااستفاده از نظر مالی دردناک می‌شود. اپراتورها نگران شتاب‌دهنده‌های کم‌استفاده هستند. حالا دارند متوجه DRAM کم‌استفاده و هزینه ارتقاء آن در کنار سایر مؤلفه‌ها می‌شوند.

CXL راهی برای نرم‌تر کردن این صلبیت ارائه می‌دهد. کارت‌های توسعه حافظه می‌توانند بدون نیاز به طراحی مجدد کل پلتفرم، ظرفیت اضافه کنند. معماری‌های سوئیچینگ و pooling امکان تخصیص پویاتر حافظه در بین سیستم‌ها را فراهم می‌کنند. حتی جایی که pooling کامل مستقر نشود، وجود یک مسیر توسعه مبتنی بر استاندارد، مکالمه خرید را تغییر می‌دهد. خریداران می‌توانند برای رشد حافظه به‌صورت تدریجی برنامه‌ریزی کنند، نه اینکه در زمان خرید سرور شرط‌های همه‌یا‌هیچ بگذارند.

چرا این یک داستان هزینه و عملیات هم هست

راحت است CXL را به‌عنوان یک فناوری عملکردی توصیف کنیم، اما بخش زیادی از جذابیت آن اقتصادی است. تیم‌های دیتاسنتر تحت فشار بودجه‌های AI، محدودیت برق و نوسان خرید هستند. اگر شرکتی بتواند برخی چرخه‌های تعویض سرور را به تأخیر بیندازد، میانگین استفاده از حافظه را بهبود بخشد، یا overprovisioning برای سناریوهای اوج را کاهش دهد، این مهم است. زیرساخت ترکیب‌پذیر (composable infrastructure) انتزاعی به نظر می‌رسد تا وقتی که خودش را به‌صورت سرمایه‌گذاری کمتر به ازای هر workload یا مسیر تمیزتری برای جذب جهش تقاضا نشان دهد.

همچنین یک زاویه عملیاتی وجود دارد. طراحی ثابت سرور تیم‌ها را مجبور می‌کند هر مشکل رشد را با یک نوع node جدید، یک مسیر تأیید دیگر، و یک استثنا در چرخه عمر حل کنند. CXL این پیچیدگی را از بین نمی‌برد، اما می‌تواند تعداد دفعاتی را کاهش دهد که تیم‌های زیرساخت مجبور می‌شوند بین خرید بیش از حد امروز یا ریسک کمبود فردا انتخاب کنند. این در محیط‌هایی که استانداردسازی ناوگان تقریباً به اندازه عملکرد خام معیار مهم است، اهمیت دارد.

مشکل اینجاست که توپولوژی همچنان همه‌چیز را تعیین می‌کند

هیچکدام اینها به این معنی نیست که CXL یک ناهار رایگان است. سوال سخت این است که در سلسله‌مراتب کجا قرار می‌گیرد. حافظه محلی همچنان برای داغ‌ترین مجموعه‌های کاری بهترین است. حافظه CXL-attached می‌تواند بسیار مفید باشد، اما فقط وقتی workload، نرم‌افزار و تحمل تأخیر هماهنگ باشند. بعضی تیم‌ها میزان شفافیت pooling را بیش از حد تخمین می‌زنند. دیگران کشف می‌کنند که orchestration، observability یا تنظیمات برنامه آن‌ها برای درمان حافظه به‌عنوان یک منبع اشتراکی پویا آماده نیست.

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

فروشندگان حالا باید بیشتر از رعایت استانداردها اثبات کنند

تمایز در حال ظهور فقط این نیست که چه کسی CXL را روی برگه مشخصات پشتیبانی می‌کند. این است که چه کسی آن را قابل استقرار می‌کند. خریداران به توپولوژی‌های تأییدشده، ابزارهای مدیریت، کنترل‌های امنیتی، تله‌متری، و راهنمایی واقع‌گرایانه درباره رفتار عملکرد تحت رقابت نیاز دارند. باید بدانند وقتی حافظه اشتراکی به مشکل همسایه پرسر و صدا (noisy neighbor) تبدیل می‌شود یا لایه‌های توسعه با چارچوب‌های مجازی‌سازی و شتاب‌دهی تعامل می‌کنند، چه اتفاقی می‌افتد. استانداردها فرصت ایجاد می‌کنند، اما اجرای محصول تعیین می‌کند که آیا اپراتور به استقرار اعتماد خواهد کرد.

اینجاست که دور بعدی رقابت رخ می‌دهد. سازندگان سرور، فروشندگان سوئیچ، شرکت‌های سیلیکون، و ارائه‌دهندگان نرم‌افزار پلتفرم همه می‌خواهند بخشی از داستان زیرساخت ترکیب‌پذیر را مال خود کنند. فروندگانی که برنده می‌شوند، آنهایی نیستند که بلندترین صدا را درباره آینده fabricهای حافظه دارند. آنهایی برنده‌اند که CXL را به‌اندازه کافی برای تیم‌های زیرساخت قابل درک می‌کنند تا بتوانند مدل‌سازی، تست و پشتیبانی کنند بدون نیاز به کارهای خاص.

تیم‌های زیرساخت باید چه چیزی را دنبال کنند

سوال کوتاه‌مدت این نیست که آیا هر سازمانی باید یک fabric حافظه pooled بسازد. این است که آیا CXL به ناوگان‌های خاص اجازه می‌دهد اندازه‌گیری آسان‌تر و تکامل ارزان‌تری داشته باشند. تیم‌ها باید کلاسترهای AI inference، محیط‌های analytics، و workloadهای مجازی‌سازی را که فشار حافظه بالاست اما بین nodeها کاملاً هماهنگ نیست، بررسی کنند. باید هزینه DRAM محلی بیش‌ازحد را با پیچیدگی عملیاتی توسعه یا pooling مقایسه کنند. همچنین باید به آمادگی نرم‌افزار توجه کنند، زیرا انعطاف‌پذیری حافظه فقط زمانی مفید است که زمان‌بندها و برنامه‌ها بتوانند از آن استفاده کنند.

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