شبکه Scale-Across چیست؟ اتصال چند دیتاسنتر برای هوش مصنوعی

پاسخ کوتاه: شبکه Scale-Across معماری اتصال چند دیتاسنتر است تا بخشی از شتاب‌دهنده‌ها و کلاسترهای هوش مصنوعی در سایت‌های جداگانه، یک کار هماهنگ را اجرا کنند. این معماری فقط یک لینک پرظرفیت بین دو ساختمان نیست؛ تأخیر، ازدحام، افت بسته، همگام‌سازی عملیات جمعی، بازیابی خطا و مصرف توان باید از ابتدا برای بارهای AI طراحی شوند. برای بیشتر شرکت‌ها Scale-Across هنوز جایگزین شبکه دیتاسنتر معمولی نیست و فقط زمانی توجیه دارد که محدودیت برق، ظرفیت یا توسعه یک سایت مانع رشد کلاستر شده باشد.

شبکه Scale-Across چیست و چه مسئله‌ای را حل می‌کند؟

در آموزش یا استنتاج توزیع‌شده هوش مصنوعی، تعداد زیادی GPU باید مرتب داده و نتیجه محاسبات را با یکدیگر مبادله کنند. اگر همه شتاب‌دهنده‌ها در یک رک یا یک سالن قرار داشته باشند، می‌توان شبکه را با فاصله کوتاه و تأخیر کنترل‌شده طراحی کرد. اما توان برق، خنک‌کاری، زمین و ظرفیت توسعه یک دیتاسنتر محدود است. Scale-Across تلاش می‌کند ظرفیت محاسباتی چند محل را به شکلی به هم متصل کند که بتوانند در یک کار هماهنگ شرکت کنند.

این مفهوم با Data Center Interconnect یا DCI سنتی هم‌پوشانی دارد، اما نیازهای آن سخت‌گیرانه‌تر است. DCI معمولاً برای جابه‌جایی داده، تکرار ذخیره‌سازی، دسترسی کاربران یا تداوم کسب‌وکار طراحی می‌شود. در Scale-Across، جریان‌های طولانی و پرحجمِ میان شتاب‌دهنده‌ها ممکن است به شکل هم‌زمان منتظر یکدیگر بمانند؛ بنابراین نوسان تأخیر یا ازدحام یک مسیر می‌تواند استفاده مفید از GPUهای گران‌قیمت را کاهش دهد.

تفاوت Scale-up، Scale-out و Scale-Across چیست؟

این سه لایه رقیب یکدیگر نیستند. یک معماری بزرگ می‌تواند درون هر رک Scale-up، درون هر سایت Scale-out و میان سایت‌ها Scale-Across داشته باشد. اشتباه رایج این است که صرفاً با خرید یک لینک WAN سریع، همان رفتار شبکه محلی را انتظار داشته باشیم. قوانین فیزیکی فاصله حذف نمی‌شوند و نرم‌افزار آموزش، توپولوژی Fabric و الگوی ارتباطی مدل باید با فاصله میان سایت‌ها سازگار باشند.

چرا آموزش AI در چند دیتاسنتر دشوار است؟

تأخیر و نوسان تأخیر مستقیماً روی زمان پایان کار اثر می‌گذارند

در عملیات جمعی مانند All-Reduce، یک گروه از GPUها باید نتایج میانی را مبادله و همگام کنند. اگر یک مسیر کند شود، سایر اعضای گروه ممکن است منتظر بمانند. به همین دلیل فقط بیشینه پهنای باند مهم نیست؛ پایداری تأخیر، توزیع متوازن جریان‌ها و رفتار شبکه هنگام خرابی نیز باید اندازه‌گیری شود. شاخص‌هایی مانند زمان تکمیل عملیات جمعی یا CCT برای چنین محیطی از عدد خام ظرفیت پورت مفیدتر هستند.

لینک دوربرد به بافر و اپتیک مناسب نیاز دارد

هرچه فاصله بیشتر شود، حاصل‌ضرب پهنای باند در تأخیر بزرگ‌تر می‌شود و حجم بیشتری از داده می‌تواند هم‌زمان در مسیر باشد. روتر یا سوئیچی که برای یک Fabric محلی بهینه شده لزوماً برای مسیر بین‌شهری انتخاب مناسبی نیست. Cisco در معماری Scale-Across خود بر سیلیکون قابل‌برنامه‌ریزی، سامانه‌های Deep Buffer و اپتیک coherent تأکید می‌کند. این ادعا به معنای مناسب بودن یک مدل برای همه پروژه‌ها نیست؛ ظرفیت بافر، نوع ماژول، فاصله واقعی، افزونگی مسیر و سازگاری نرم‌افزار باید برای طرح مشخص بررسی شوند.

بازیابی خطا باید با رفتار کار AI هماهنگ باشد

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

معماری Scale-Across چه اجزایی دارد؟

• Fabric محلی AI: شبکه Scale-out هر سایت که GPUها، سرورها و ذخیره‌سازی را متصل می‌کند.
• درگاه میان‌سایتی: روترها یا سامانه‌های مرزی با ظرفیت، بافر و جدول مسیریابی متناسب با حجم ترافیک.
• لایه اپتیکی: ترنسیور، DWDM یا سامانه انتقال coherent متناسب با فاصله و بودجه توان نوری.
• کنترل ازدحام و توازن بار: سازوکاری برای جلوگیری از تمرکز جریان‌های هم‌زمان روی یک مسیر.
• تله‌متری انتهابه‌انتها: مشاهده تأخیر، افت بسته، استفاده مسیر و اثر رخدادها بر زمان اجرای کار.
• امنیت: رمزنگاری مسیر، جداسازی ترافیک، کنترل هویت مدیریتی و ثبت تغییرات پیکربندی.

انتخاب تجهیزات باید از نیاز محاسباتی شروع شود، نه از مدل پورت. برای بررسی گزینه‌های فعلی شبکه سازمانی و دیتاسنتر می‌توانید مشخصات و محدودیت‌های سوئیچ‌های سیسکو را مقایسه کنید. این دسته شامل تجهیزات تجاری موجود در نت‌یک است، اما هر سوئیچ سیسکو برای Scale-Across مناسب نیست و تطبیق مدل دقیق با معماری پروژه ضروری است.

پیش از اجرای Scale-Across چه معیارهایی را اندازه بگیریم؟

1. الگوی ارتباطی مدل: نسبت محاسبه به ارتباط، اندازه پیام و تعداد عملیات جمعی در هر مرحله.
2. فاصله و RTT: تأخیر رفت‌وبرگشت واقعی در ساعات مختلف، نه فقط عدد قراردادی سرویس‌دهنده.
3. Goodput: نرخ داده مفید پایدار پس از کسر سربار، تکرار و ازدحام.
4. زمان بازیابی: رفتار Fabric و کار AI هنگام قطع لینک یا تغییر مسیر.
5. توان و خنک‌کاری: هزینه انرژی سامانه‌های شبکه و اپتیک در هر دو سایت.
6. ظرفیت رشد: تعداد GPU، سرعت پورت و تعداد مسیرهای موردنیاز در افق ۱۲ تا ۳۶ ماه.
7. هزینه کل: اجاره فیبر، اپتیک، پشتیبانی، نیروی متخصص و هزینه GPUهای بیکار در زمان اختلال.

همچنین باید ظرفیت محاسباتی دو سمت هم‌تراز باشد. اگر نسل شتاب‌دهنده‌ها، سرعت حافظه یا ذخیره‌سازی تفاوت زیادی داشته باشد، شبکه به‌تنهایی گلوگاه را رفع نمی‌کند. برای برآورد بخش محاسباتی، دسته سرورهای شبکه و دیتاسنتر نقطه شروع تجاری مناسبی است؛ با این حال انتخاب سرور AI به GPU، شاسی، منبع تغذیه، خنک‌کاری و نرم‌افزار مورد استفاده وابسته است و باید جداگانه مهندسی شود.

چه زمانی Scale-Across انتخاب مناسبی نیست؟

اگر بار کاری را می‌توان در یک کلاستر کوچک‌تر اجرا کرد، یا سرویس صرفاً استنتاج سبک و مستقل در هر شعبه است، تقسیم یک کار هماهنگ بین چند سایت ممکن است پیچیدگی و هزینه غیرضروری ایجاد کند. در بسیاری از سازمان‌ها استفاده از چند کلاستر مستقل، زمان‌بندی کارها بین سایت‌ها یا انتقال داده پیش از شروع پردازش ساده‌تر و قابل‌اعتمادتر است.

همچنین معماری Scale-Across نباید با بازیابی بحران اشتباه گرفته شود. یک سایت پشتیبان می‌تواند داده و سرویس را پس از حادثه تحویل بگیرد، بدون اینکه دو سایت در یک کار آموزشی هم‌زمان مشارکت کنند. هدف، نرم‌افزار و شاخص موفقیت این دو سناریو متفاوت است.

نقش Cisco Silicon One در Scale-Across چیست؟

سیسکو خانواده P از معماری Silicon One را برای مسیریابی میان دیتاسنترها و شبکه‌های Scale-Across معرفی کرده است. در اعلام رسمی OCP 2026، این شرکت از استقرار سامانه‌های 51.2 ترابیت‌برثانیه مبتنی بر P200 در محیط تولید و ترکیب آن‌ها با اپتیک coherent خبر داد. این اعداد ظرفیت سامانه هستند، نه تضمین کارایی یک پروژه. نتیجه واقعی به توپولوژی، تعداد مسیرها، فاصله، الگوی ترافیک، تنظیمات و نرم‌افزار بستگی دارد.

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

چک‌لیست تصمیم‌گیری برای مدیر شبکه

• ابتدا مشخص کنید هدف، تقسیم یک کار AI بین سایت‌هاست یا فقط انتقال داده و تداوم سرویس.
• Baseline زمان اجرا، استفاده GPU، RTT، افت بسته و CCT را در یک سایت ثبت کنید.
• یک آزمایش محدود با همان چارچوب نرم‌افزاری و مدل واقعی بسازید.
• خرابی هر مسیر و بازگشت آن را در شرایط بار تست کنید.
• اثر رمزنگاری، تله‌متری و سیاست‌های امنیتی را در محاسبه ظرفیت لحاظ کنید.
• پیش از خرید، مدل دقیق اپتیک، فیبر، بافر، سیستم‌عامل و قرارداد پشتیبانی را تطبیق دهید.

جمع‌بندی

شبکه Scale-Across پاسخ به یک محدودیت واقعی است: همه ظرفیت برق و خنک‌کاری لازم برای کلاسترهای بزرگ AI را نمی‌توان همیشه در یک محل جمع کرد. اما اتصال چند دیتاسنتر تنها با افزایش سرعت لینک حل نمی‌شود. فاصله، تأخیر، بافر، اپتیک، کنترل ازدحام، بازیابی و رفتار نرم‌افزار باید یک سامانه واحد دیده شوند. برای سازمانی که هنوز نیازش با Scale-out داخل یک دیتاسنتر برطرف می‌شود، ساده نگه‌داشتن معماری معمولاً تصمیم اقتصادی‌تر و کم‌ریسک‌تری است.

پرسش‌های متداول

آیا Scale-Across همان DCI است؟

خیر. از زیرساخت‌های DCI استفاده می‌کند، اما برای هماهنگی کارهای AI به کنترل سخت‌گیرانه‌تر تأخیر، ازدحام و بازیابی نیاز دارد.

آیا هر لینک 400G یا 800G برای Scale-Across کافی است؟

خیر. سرعت پورت فقط یکی از معیارهاست. فاصله، RTT، بافر، اپتیک، مسیرهای افزونه، افت بسته و سازگاری نرم‌افزار نیز تعیین‌کننده‌اند.

Scale-Across برای شرکت‌های متوسط کاربرد دارد؟

معمولاً نه برای یک کار آموزشی واحد. بسیاری از شرکت‌ها با کلاستر مستقل در هر سایت، زمان‌بندی کار یا سرویس ابری نتیجه ساده‌تر و اقتصادی‌تری می‌گیرند.

منبع

ناشر: The Register
عنوان اصلی: When one datacenter is no longer enough
مطالعه مقاله اصلی در The Register

منابع فنی تکمیلی: اعلام رسمی Cisco در OCP 2026 و راهنمای معماری Scale-Across سیسکو.