یکی از دوستانم پیوندهایی به مقاله جدیدی که توسط مهندسان AWS منتشر شده و یک پست مرتبط لینکدین برای من ارسال کرد که ادعا می کند:
ما پارچه‌های نازک، الاستیک و انبوهی داریم که با 69 درصد روتر کمتر، 27 درصد صرفه‌جویی در هزینه، 40 درصد مصرف انرژی کمتر و انتشار CO2 کمتر، 33 درصد توان عملیاتی بهتری را ارائه می‌دهند.
سوال واضحی که باید بعد از خواندن پست وبلاگ تهویه بیش از حد در مورد طراحی مجدد شبکه رادیکال بپرسد این است: آیا این پایان شبکه های برگ و ستون فقرات است؟ البته نه. بیایید وارد جزئیات شویم.
به روز رسانی: در کمتر از یک روز پس از انتشار پست وبلاگ، جاکومو برناردی (یکی از نویسندگان) به سراغش رفت و اطلاعات مهمی را که از قلم انداخته بودم ارائه کرد. من آنها را به پست وبلاگ اضافه کرده ام (در جعبه های خاکستری)، چند مورد را بازنویسی کرده ام و قصد دارم یک پیگیری دقیق تر انجام دهم.
دقیقا چه کردند؟ آنها روشی را که Plexxi برای ساخت پارچه های مرکز داده تلاش کرد، دوباره اختراع کردند. به جای سوئیچ های ستون فقرات، Plexxi سعی کرد سوئیچ های برگ را مستقیماً وصل کند، ابتدا با CWDM (آنها رویای پهنای باند پویا از برگ به برگ را در سر می پرورانند)، سپس با یک جعبه میانی از قبل متصل (آنچه مهندسان AWS آن را ShuffleBox می نامند).
در حالی که ایده یکسان است، کابل های AWS RNG به طور متفاوتی سوئیچ می شوند. همانطور که نویسندگان در یادداشتی که برای من فرستادند توضیح دادند، شبکه Plexxi یک بود اتحاد حلقه ها; AWS RNG است گسترش دهنده بهینه.
بدیهی است که از این طریق پهنای باند زیادی را از دست خواهید داد، زیرا همیشه برخی از سوئیچ های برگ وجود دارند که با وجود اتصال مستقیم، ترافیک را مبادله نمی کنند. Plexxi این مشکل را با هزینه های چند مسیره نابرابر حل کرد (ترافیک همچنین از مسیرهای طولانی تری استفاده می کند، نه فقط اتصالات مستقیم). پست وبلاگ AWS این را مسیریابی از طریق تصادفی می نامد.
همانطور که هر کسی که تلاش کرده است LFA را درک کند، می‌داند، چند مسیری با هزینه نابرابر تا آنجا پیش می‌رود. اگر می‌خواهید استفاده از اتصال را بیشتر افزایش دهید، به مهندسی ترافیک “مناسب” نیاز دارید که به مدارهای مجازی (و بنابراین یک لایه اضافی از کپسوله کردن) نیاز دارد. صرف نظر از اینکه از فریم های MAC استفاده می کنید یا خیرMPLS، SRv6 یا کبوتر برای این لایه اضافی مهم نیست.
چگونه یک ShuffleBox از قبل متصل می‌تواند تصادفی باشد؟ بله، این اولین ماشه بزرگ در سرعت سنج من بود. ابتدا فکر کردم از سوئیچ‌های فیبر نوری استفاده می‌کنند (که به دلیل حجم تولید پایین‌تر می‌توانند به اندازه سوئیچ‌های ستون فقرات سنتی گران باشند) اما پس از خواندن مقاله این تصور را پیدا کردم که آنها لینک‌های سوئیچ را به خطوط جداگانه تقسیم می‌کنند (به عنوان مثال چهار خط 100 GE در یک پورت آپلینک 400 GE وجود دارد) و آن را از قبل با سیم‌کشی shundomeoxlexlex ساخته‌اند. مانند یک ژنراتور تصادفی اعداد XKCD. شایان ذکر است که Plexxi دقیقاً همین کار را برای خلاص شدن از شر هزینه های CWDM انجام داد، و تقسیم باند یک روش قدیمی است که بیش از یک دهه پیش برای آن استفاده کردیم. آنها زندگی ما را بدبخت می کنند پارچه های بزرگتر را با برگ و پشتی بسازید (برخی جزئیات).
در حالی که هیچ چیز تصادفی در مورد ShuffleBox وجود ندارد، آنها می توانند تصادفی بودن کلی را با پیوندهای سوئیچ تصادفی شده به ShuffleBox و بین ShuffleBox افزایش دهند.
آنها ادعا می‌کنند که از روش‌های بهینه‌سازی برای یافتن بهترین شبکه جزئی بین N سوئیچ‌های دارای لینک بالا D استفاده کرده‌اند. نتیجه احتمالاً بهینه است (تحت برخی محدودیت ها) و ممکن است برای یک ناظر معمولی تصادفی به نظر برسد، اما هیچ چیز تصادفی در مورد آن وجود ندارد. سند arXiv به درستی آن را یک نمودار شبه تصادفی می نامد. این تفاوت ظریف به دلایل واضح از بین رفته استدر پست های وبلاگ و مواد تبلیغاتی مشابه.
آیا آنها می توانند خروجی بهتری نسبت به پارچه های ورقه ای و پشتی داشته باشند؟ در مقایسه سیب به سیب، البته نه. من این را سال ها پیش توضیح دادم، اما مطمئناً هیچ کس مطالب قدیمی را نمی خواند، بنابراین بیایید یک آزمایش فکری ساده دیگر انجام دهیم:
- شما یک پارچه برگ و ستون با اشتراک بیش از حد N:1 سوئیچ‌های برگ می‌سازید – کل پهنای باند پورت‌های لبه N برابر پهنای باند کل پیوندهای بالا است. N معمولاً روی سه تنظیم می شود.
- ستون فقرات (یا بافت سوپر سنبله) پارچه شما هیچ رونویسی ندارد. تنها منابعی که بیش از حد بارگذاری شده اند سوئیچ های برگ رو به بالا هستند.
- بنابراین، ترافیک از هر نقطه پایانی به هر نقطه پایانی دیگری در پارچه ستون فقرات برگ باید دقیقاً از دو لینک بالا برای یک سوئیچ leaf-plus-fabric بدون رونویسی عبور کند.
- ترافیک در یک راه حل Plexxi یا AWS ممکن است برای تغییر یک برگ (زمانی که از برگه های دیگر به عنوان گره های رله استفاده می کنند) نیاز به عبور از بیش از دو لینک بالا داشته باشد.
در محیطی با جریان‌های بسیار کوچک (برای متعادل‌سازی بار)، به این ترتیب، دریافت توان عملیاتی بهتر در یک شبکه جزئی نسبت به بافت برگ و ستون فقرات بدون بازنویسی هسته غیرممکن است، و تا زمانی که لینک‌های سوئیچ برگ، گلوگاه‌ها هستند، مشخصات ترافیکی آن مهم نیست. جزئیات به عنوان تمرینی برای خواننده کنجکاو باقی مانده است.
اما آنها ادعا می کنند که عملکرد بهتری در مقاله arXiv داشته اند! بله، سعی کردم این را بفهمم اما موفق نشدم. به نظر می رسد که آنها از شبیه سازی برای تولید نمودارهای توان استفاده کرده اند، اما کد منبع در دسترس نیستبنابراین برای کسی که با این موضوع آشنا نیست سخت است که بداند دقیقا چه کاری انجام داده است. علاوه بر این، آنها راه حل خود را با درختان ضخیم بدون مشخص کردن پارامترهای درختان ضخیم که استفاده می کنند. بیایید فرض کنیم منظور آنها “پارچه چند لایه با برگ و ستون فقرات روی آن نوشته نشده است”.
من می توانم چند توضیح نسبتا ساده برای نتایج آنها در نظر بگیرم:
- لایه ستون فقرات (یا بافت زمین) در بافت آنها بیش از حد شلوغ است.
- تعادل بار در بافت برگ و ستون فقرات آنها نامطلوب است (برخی از پیوندهای بالادستی بیش از حد بارگذاری می‌شوند در حالی که برخی دیگر غیرفعال هستند). راه های زیادی برای حل این چالش قبل از تغییر به سمپاشی دسته ای وجود دارد. Cisco ACI قرار است از یکی از این موارد استفاده کند و من چند پست وبلاگ در مورد این موضوع نوشته ام در صورتی که شما به جزئیات علاقه مند باشید.
- آنها از تعادل بار استفاده می کنند از طریق مسیرهای مجازی در راه حل آنها، منجر به تعداد بیشتری از مسیرهای جایگزین و در نتیجه عملکرد متعادل کننده بار بهتر می شود.
- آنها از یک الگوریتم مسیریابی استفاده می کنند که بار لینک را در نظر می گیرد و در نتیجه لینک های متراکم تری ایجاد می کند.
- آنها از پراکندگی بسته ها (ارسال بسته ها از یک جلسه در چندین مسیر) در راه حل خود استفاده می کنند، اما نه در ستون فقرات برگ و ستون فقرات.
من یک نکته مهم را در مقاله از دست دادم: آنها به پیوندهای بالا به سوئیچ های برگ نیاز دارند تا به همان نسبت اشتراک بیش از حد یک پارچه برگ و ستون فقرات مشابه دست یابند. از بخش 2 سند:اما توسعه‌دهنده‌ای که عملکردی معادل یک درخت چاق است، ممکن است به پیوندهای ToRs بیشتری نیاز داشته باشد (پورت‌هایی که رو به تخته هستند) زیرا مقداری از ظرفیت لینک بالا توسط ترافیک ارسال شده به ToRهای دیگر مصرف می‌شود.“
این نیاز به سوئیچ های برگ بیشتری دارد، اما یک پارچه به اندازه کافی بزرگ هنوز از عناصر فعال کمتری (سوئیچ) استفاده می کند و در نتیجه مصرف انرژی کمتری دارد. روشن کاهش هزینه از سوی دیگر، آنها صرفه جویی را از سوییچ های پارچه کمتر محاسبه می کنند، اما هزینه کل پارچه، از جمله ShuffleBox را ذکر نمی کنند.
همچنین (و چند مسیری با هزینه نابرابر)، آنها از پروتکل حمل و نقل چند مسیره (SRD) یکسانی در هر دو مورد استفاده می‌کنند، اما از ترفندهای اضافی مانند پاشش بسته‌ها استفاده نمی‌کنند.
من می خواهم باور کنم که راه حلی جادویی وجود دارد که بهتر از یک پارچه برگ و خار که به طور بهینه اجرا شده است، کار می کند، اما فکر نمی کنم قوانین فیزیک با این دیدگاه موافق باشند. با این حال، طبق قانون اول کلارک، ممکن است چیزی واضح را از دست بدهم. در این صورت لطفا نظر بدهید
آیا مهم است این یک رویکرد جالب است و احتمالاً برای اکثر موارد به اندازه کافی خوب است. از این گذشته، من همیشه به مردم گفته‌ام که به جای اتلاف وقت روی یک لایه ستون فقرات، چهار سوئیچ لنگه را به یک شبکه مشبک متصل کنند. من معتقد نیستم که پهنای باند بیشتری به شما می دهد، اما کاملاً موافقم که از انرژی کمتری استفاده می کند (ShuffleBoxها احتمالاً غیرفعال هستند).
آیا باید منتظر راه حل های مشابه در مراکز داده با اندازه سازمانی باشیم؟ احتمالا نه. ممکن است دلیلی وجود داشته باشد که Plexxi به جایی نمی رسد. همچنین، در حالی که شرکت های Fortune 50 به کمتر از دوجین سوئیچ برای ساخت دو مرکز داده (بر اساس یک داستان واقعی) نیاز دارند، بهینه سازی طراحی پارچه ممکن است بهترین سرمایه گذاری در زمان همه نباشد.
از سوی دیگر، اگر پارچه هایی با ده ها هزار سوئیچ می سازید، قطعا باید نگاه دقیق تری داشته باشید. اگر دارید، خوشحال می شوم نظرات شما را بشنوم.
