نحوه مقیاس بندی مراکز داده گزارش یاندکس

ما یک طراحی شبکه مرکز داده ایجاد کرده‌ایم که امکان استقرار خوشه‌های محاسباتی بزرگ‌تر از 100 هزار سرور با پهنای باند دوبخشی بیش از یک پتابایت در ثانیه را فراهم می‌کند.

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

- عصر همگی بخیر! نام من دیمیتری آفاناسیف است، من یک معمار شبکه در Yandex هستم و در درجه اول شبکه های مرکز داده را طراحی می کنم.



داستان من در مورد شبکه به روز شده مراکز داده Yandex خواهد بود. این بسیار تکامل یافته از طراحی ما است، اما در عین حال برخی از عناصر جدید وجود دارد. این یک ارائه اجمالی است زیرا اطلاعات زیادی وجود داشت که باید در زمان کمی بسته بندی شوند. ما با انتخاب یک توپولوژی منطقی شروع می کنیم. سپس مروری بر صفحه کنترل و مشکلات مربوط به مقیاس پذیری صفحه داده، انتخاب آنچه در سطح فیزیکی اتفاق خواهد افتاد وجود خواهد داشت و برخی از ویژگی های دستگاه ها را بررسی خواهیم کرد. بیایید کمی به آنچه در یک مرکز داده با MPLS اتفاق می افتد، که مدتی پیش در مورد آن صحبت کردیم، بپردازیم.

بنابراین، Yandex از نظر بارها و خدمات چیست؟ Yandex یک hyperscaler معمولی است. اگر به کاربران نگاه کنیم، در درجه اول درخواست های کاربر را پردازش می کنیم. همچنین سرویس های پخش و انتقال داده های مختلف، زیرا ما خدمات ذخیره سازی نیز داریم. اگر به باطن نزدیک‌تر باشد، بارگذاری‌های زیرساخت و سرویس‌ها مانند ذخیره‌سازی اشیاء توزیع‌شده، تکثیر داده‌ها و البته صف‌های دائمی در آنجا ظاهر می‌شوند. یکی از انواع اصلی بارهای کاری MapReduce و سیستم های مشابه، پردازش جریان، یادگیری ماشین و غیره است.

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

بنابراین ما سطح بعدی را داریم - سیستم عامل در سطح خوشه محاسباتی. بسیار مهم است که پشته فناوری را که استفاده می کنیم کاملاً کنترل کنیم. ما نقاط پایانی (میزبان)، شبکه و پشته نرم افزار را کنترل می کنیم.

ما چندین مرکز داده بزرگ در روسیه و خارج از کشور داریم. آنها توسط یک ستون فقرات که از فناوری MPLS استفاده می کند متحد شده اند. زیرساخت داخلی ما تقریباً به طور کامل بر روی IPv6 ساخته شده است، اما از آنجایی که ما باید به ترافیک خارجی سرویس دهیم که هنوز عمدتاً از طریق IPv4 می‌آید، باید به نحوی درخواست‌هایی را که از طریق IPv4 ارسال می‌شوند به سرورهای frontend ارائه دهیم و کمی بیشتر به اینترنت IPv4 خارجی برویم. به عنوان مثال، برای نمایه سازی

چند تکرار اخیر طراحی های شبکه مرکز داده از توپولوژی های چند لایه Clos استفاده کرده اند و فقط L3 هستند. چندی پیش L2 را ترک کردیم و نفس راحتی کشیدیم. در نهایت، زیرساخت ما شامل صدها هزار نمونه محاسباتی (سرور) است. حداکثر اندازه کلاستر چند وقت پیش حدود 10 هزار سرور بود. این عمدتاً به این دلیل است که همان سیستم‌عامل‌های سطح خوشه، زمان‌بندی‌ها، تخصیص منابع و غیره می‌توانند کار کنند. از آنجایی که پیشرفت در سمت نرم‌افزار زیرساخت اتفاق افتاده است، اندازه هدف اکنون حدود 100 هزار سرور در یک خوشه محاسباتی است. ما وظیفه داریم - بتوانیم کارخانه های شبکه ای بسازیم که امکان تجمیع منابع کارآمد را در چنین خوشه ای فراهم کند.

ما از یک شبکه مرکز داده چه می خواهیم؟ اول از همه، پهنای باند ارزان و نسبتاً یکنواخت زیادی وجود دارد. زیرا شبکه ستون فقراتی است که از طریق آن می توانیم منابع را جمع آوری کنیم. اندازه هدف جدید حدود 100 هزار سرور در یک کلاستر است.

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

البته ما به اتوماسیون نیاز داریم، زیرا مدیریت چنین زیرساختی به صورت دستی غیرممکن است و مدتی است که غیرممکن بوده است. ما به پشتیبانی عملیاتی تا حد امکان و پشتیبانی CI/CD تا حد امکان نیاز داریم.

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

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

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

بنابراین، چه چیزی است که ما به آن نیاز نداریم، چه چیزی را توانسته‌ایم رها کنیم، نه همیشه با خوشحالی در زمان وقوع آن، بلکه با آسودگی زیاد وقتی این فرآیند تکمیل شد؟

اول از همه، رها کردن L2. ما به L2 نیاز نداریم، نه واقعی و نه شبیه سازی شده. تا حد زیادی به دلیل این واقعیت که ما پشته برنامه را کنترل می کنیم استفاده نشده است. برنامه های ما به صورت افقی مقیاس پذیر هستند، آنها با آدرس دهی L3 کار می کنند، آنها خیلی نگران نیستند که برخی از نمونه های فردی از بین رفته باشد، آنها به سادگی یک نمونه جدید را ارائه می کنند، نیازی نیست که در آدرس قدیمی منتشر شود، زیرا یک مورد وجود دارد. سطح جداگانه ای از خدمات کشف و نظارت بر ماشین های واقع در خوشه. ما این وظیفه را به شبکه محول نمی کنیم. وظیفه شبکه تحویل بسته ها از نقطه A به نقطه B است.

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

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

در نهایت شبکه هایمان را طوری طراحی می کنیم که زیاد تغییر نکنند. ما می توانیم روی این واقعیت حساب کنیم که جریان رویدادهای خارجی در سیستم مسیریابی کم است.

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

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

یک شبکه Clos چند سطحی تقریباً چگونه ساختار یافته است و عناصر مختلف در آن چه نامیده می شوند؟ اول از همه، باد بلند شد، تا خودت را جهت دهی کجا شمال، کجا جنوب، کجا شرق، کجا غرب. شبکه هایی از این نوع معمولا توسط کسانی ساخته می شوند که ترافیک بسیار زیادی از غرب به شرق دارند. همانطور که برای عناصر باقی مانده، در بالا یک سوئیچ مجازی است که از سوییچ های کوچکتر مونتاژ شده است. این ایده اصلی ساخت بازگشتی شبکه های Clos است. عناصر را با نوعی ریشه می گیریم و آنها را به هم وصل می کنیم تا آنچه به دست می آوریم به عنوان یک سوئیچ با یک ریشه بزرگتر در نظر گرفته شود. اگر حتی بیشتر نیاز دارید، روش می تواند تکرار شود.

در مواردی که مثلاً با Clos دو سطحی می‌توان به وضوح اجزایی را که در نمودار من عمودی هستند شناسایی کرد، معمولاً به آنها هواپیما گفته می‌شود. اگر بخواهیم یک Clos با سه سطح سوئیچ ستون فقرات بسازیم (که همه آنها سوئیچ های مرزی یا ToR نیستند و فقط برای حمل و نقل استفاده می شوند)، هواپیماها پیچیده تر به نظر می رسند؛ هواپیماهای دو سطحی دقیقاً شبیه این هستند. ما بلوکی از سوئیچ‌های ToR یا برگ و سوئیچ‌های سطح اول ستون فقرات مرتبط با آنها را Pod می‌نامیم. سوئیچ های ستون فقرات سطح ستون فقرات 1 در بالای غلاف، بالای پاد، بالای پاد هستند. کلیدهایی که در بالای کل کارخانه قرار دارند لایه بالایی کارخانه یعنی Top of Fabric هستند.

البته این سوال پیش می‌آید: شبکه‌های Clos مدتی است که ساخته شده‌اند؛ ایده خود عموماً از زمان تلفن کلاسیک، شبکه‌های TDM می‌آید. شاید چیز بهتری ظاهر شده باشد، شاید بتوان کاری را بهتر انجام داد؟ بله و خیر. از نظر تئوری بله، در عمل در آینده نزدیک قطعا خیر. از آنجا که تعدادی توپولوژی جالب وجود دارد، برخی از آنها حتی در تولید استفاده می شوند، به عنوان مثال، Dragonfly در برنامه های کاربردی HPC استفاده می شود. توپولوژی های جالبی مانند Xpander، FatClique، Jellyfish نیز وجود دارد. اگر اخیراً به گزارش‌های کنفرانس‌هایی مانند SIGCOMM یا NSDI نگاه کنید، می‌توانید تعداد نسبتاً زیادی کار در مورد توپولوژی‌های جایگزین پیدا کنید که ویژگی‌های بهتری (یکی یا دیگری) نسبت به Clos دارند.

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

از نظر تئوری، راه حل مشکل مشخص است. به عنوان مثال، اینها اصلاحات وضعیت پیوند با استفاده از k-کوتاه ترین مسیر هستند، اما، دوباره، چنین پروتکل هایی وجود ندارد که در تولید پیاده سازی شود و به طور گسترده در تجهیزات موجود باشد.

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

بنابراین، جهت جالب است، اما، افسوس، ما نمی توانیم آن را در حال حاضر اعمال کنیم.

خوب، ما روی توپولوژی منطقی Clos قرار گرفتیم. چگونه آن را مقیاس کنیم؟ بیایید ببینیم چگونه کار می کند و چه کاری می توان انجام داد.

در یک شبکه Clos دو پارامتر اصلی وجود دارد که می توانیم به نحوی آنها را تغییر دهیم و نتایج مشخصی به دست آوریم: ریشه عناصر و تعداد سطوح در شبکه. من یک نمودار شماتیک از نحوه تأثیر هر دو بر اندازه دارم. در حالت ایده آل، ما هر دو را ترکیب می کنیم.

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

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

اگر به نسخه توسعه یافته شبکه Clos (در گوشه پایین سمت راست) نگاه کنید و با شبکه Clos زیر به این تصویر بازگردید...

... پس این دقیقا همان توپولوژی است، اما در این اسلاید فشرده تر فرو می ریزد و هواپیماهای کارخانه روی هم قرار می گیرند. این همان است.

مقیاس بندی یک شبکه Clos از نظر اعداد چگونه است؟ در اینجا من داده‌هایی را در مورد حداکثر عرض یک شبکه، حداکثر تعداد رک، سوئیچ‌های ToR یا سوئیچ برگ ارائه می‌دهم، اگر در رک‌ها نباشند، بسته به اینکه چه ریشه سوئیچ‌هایی را برای سطوح ستون فقرات استفاده می‌کنیم، می‌توانیم دریافت کنیم. از چند سطح استفاده می کنیم

در اینجا آمده است که ما چند رک می توانیم داشته باشیم، چند سرور و تقریباً چه مقدار می تواند بر اساس 20 کیلو وات در هر رک مصرف کند. کمی قبل از آن اشاره کردم که ما قصد داریم اندازه کلاستر حدود 100 هزار سرور داشته باشیم.

مشاهده می شود که در کل این طراحی دو گزینه و نیم مورد توجه است. گزینه ای با دو لایه خار و سوئیچ 64 پورت وجود دارد که کمی کوتاه است. سپس گزینه های کاملاً مناسبی برای سوئیچ های ستون فقرات 128 پورت (با ریشه 128) با دو سطح یا سوئیچ های با رادیکس 32 با سه سطح وجود دارد. و در همه موارد، جایی که رادیکس ها و لایه های بیشتری وجود دارد، می توانید یک شبکه بسیار بزرگ ایجاد کنید، اما اگر به مصرف مورد انتظار نگاه کنید، معمولا گیگاوات وجود دارد. امکان کابل کشی وجود دارد، اما بعید است که در یک سایت چنین مقدار برق دریافت کنیم. اگر به آمار و داده های عمومی در مراکز داده نگاه کنید، می توانید مراکز داده بسیار کمی را با ظرفیت تخمینی بیش از 150 مگاوات بیابید. مراکز بزرگتر معمولاً پردیس های مرکز داده هستند، چندین مرکز داده بزرگ که کاملاً نزدیک به یکدیگر قرار دارند.

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

علاوه بر این، حتی این باند اضافی دقیقاً یکسان نیست. در حالی که دهانه‌ها کوتاه هستند، می‌توانیم از چیزی مانند DAC (اتصال مستقیم مسی، یعنی کابل‌های twinax) یا اپتیک‌های چند حالته استفاده کنیم که حتی هزینه‌های کم و بیش معقولی را نیز دارند. به محض اینکه به بازه های طولانی تر می رویم - به عنوان یک قاعده، این اپتیک های تک حالته هستند و هزینه این پهنای باند اضافی به طور قابل توجهی افزایش می یابد.

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

بر اساس این تصویر، واضح است که ما واقعاً می خواهیم روی چیزی مانند سوئیچ هایی با ریشه 128 بسازیم.

در اینجا، در اصل، همه چیز همان چیزی است که من گفتم؛ این یک اسلاید برای بررسی بعد است.

چه گزینه هایی وجود دارد که می توانیم به عنوان این سوئیچ ها انتخاب کنیم؟ این برای ما بسیار خوشایند است که اکنون چنین شبکه هایی می توانند در نهایت روی سوئیچ های تک تراشه ساخته شوند. و این بسیار جالب است، آنها دارای بسیاری از ویژگی های خوب است. به عنوان مثال، آنها تقریباً هیچ ساختار داخلی ندارند. این بدان معنی است که آنها راحت تر می شکنند. آنها به هر طریقی می شکنند، اما خوشبختانه کاملاً می شکنند. در دستگاه های مدولار تعداد زیادی ایراد وجود دارد (بسیار ناخوشایند)، زمانی که از نظر همسایگان و صفحه کنترل به نظر می رسد که کار می کند، اما مثلاً بخشی از پارچه گم شده است و کار نمی کند. با ظرفیت کامل و ترافیک به آن بر اساس این واقعیت که کاملاً کاربردی است متعادل است و ما می توانیم بیش از حد بارگیری کنیم.

یا، به عنوان مثال، مشکلاتی در backplane ایجاد می شود، زیرا در داخل دستگاه مدولار نیز SerDes با سرعت بالا وجود دارد - در داخل واقعا پیچیده است. یا علائم بین عناصر فوروارد همگام هستند یا همگام نیستند. به طور کلی، هر دستگاه مدولار تولیدی متشکل از تعداد زیادی عنصر، به عنوان یک قاعده، حاوی همان شبکه Clos در داخل خود است، اما تشخیص آن بسیار دشوار است. اغلب حتی برای خود فروشنده نیز تشخیص آن دشوار است.

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

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

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

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

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

به طور خلاصه، ما در حال ساخت یک توپولوژی با دو سطح خار، با هشت لایه کارخانه هستیم.

چه اتفاقی برای فیزیک خواهد افتاد؟ محاسبات بسیار ساده اگر دو سطح اسپین داشته باشیم، پس فقط سه سطح سوئیچ داریم و انتظار داریم که سه بخش کابل در شبکه وجود داشته باشد: از سرورها تا سوئیچ های برگ، به ستون 1 تا ستون 2. گزینه هایی که می توانیم استفاده از آنها عبارتند از: twinax، multimode، single mode. و در اینجا باید در نظر بگیریم که چه نواری در دسترس است، چقدر هزینه دارد، ابعاد فیزیکی آن چقدر است، چه دهانه هایی را می توانیم پوشش دهیم، و چگونه ارتقاء خواهیم داد.

از نظر هزینه، همه چیز را می توان ردیف کرد. Twinax ها به طور قابل توجهی ارزان تر از اپتیک های فعال، ارزان تر از فرستنده های چند حالته هستند، اگر آن را در هر پرواز از انتها استفاده کنید، تا حدودی ارزان تر از یک پورت سوئیچ 100 گیگابیتی است. و لطفاً توجه داشته باشید که هزینه آن کمتر از اپتیک تک حالته است، زیرا در پروازهایی که به حالت تک حالت نیاز است، در مراکز داده به دلایلی منطقی است که از CWDM استفاده کنید، در حالی که حالت تک موازی (PSM) برای کار خیلی راحت نیست. با بسته های بسیار بزرگ الیاف به دست می آید و اگر روی این فناوری ها تمرکز کنیم تقریباً سلسله مراتب قیمت زیر را بدست می آوریم.

یک نکته دیگر: متأسفانه، استفاده از پورت های چند حالته 100 تا 4x25 جدا شده چندان امکان پذیر نیست. با توجه به ویژگی های طراحی فرستنده گیرنده SFP28، آن را بسیار ارزان تر از 28 گیگابیت QSFP100 نیست. و این جداسازی برای چند حالت خیلی خوب کار نمی کند.

محدودیت دیگر این است که به دلیل اندازه خوشه های محاسباتی و تعداد سرورها، مراکز داده ما از نظر فیزیکی بزرگ هستند. این بدان معناست که حداقل یک پرواز باید با سینگل مود انجام شود. باز هم به دلیل اندازه فیزیکی Pods، امکان اجرای دو دهانه twinax (کابل های مسی) وجود نخواهد داشت.

در نتیجه، اگر برای قیمت بهینه سازی کنیم و هندسه این طرح را در نظر بگیریم، یک دهانه twinax، یک دهانه چند حالته و یک دهانه تک حالت با استفاده از CWDM بدست می آوریم. این امر مسیرهای احتمالی ارتقا را در نظر می گیرد.

این چیزی است که اخیراً به نظر می رسد، به کجا می رویم و چه چیزی ممکن است. حداقل نحوه حرکت به سمت SerDes 50 گیگابیتی برای چند حالته و تک حالته روشن است. علاوه بر این، اگر به آنچه در فرستنده‌های تک حالته در حال حاضر و در آینده برای 400G وجود دارد نگاه کنید، اغلب حتی زمانی که 50G SerDes از سمت الکتریکی می‌آیند، 100 گیگابیت بر ثانیه در هر خط می‌تواند به اپتیک برسد. بنابراین، کاملاً ممکن است که به جای انتقال به 50، انتقال به 100 گیگابیت SerDes و 100 گیگابیت بر ثانیه در هر خط انجام شود، زیرا طبق قول بسیاری از فروشندگان، به زودی در دسترس بودن آنها پیش بینی می شود. به نظر می‌رسد دوره‌ای که 50G SerDes سریع‌ترین بودند، خیلی طولانی نخواهد بود، زیرا اولین نسخه‌های 100G SerDes تقریباً سال آینده عرضه می‌شوند. و پس از مدتی پس از آن احتمالاً ارزش پول معقولی را خواهند داشت.

یک نکته ظریف دیگر در مورد انتخاب فیزیک. در اصل، ما می توانیم از پورت های 400 یا 200 گیگابیتی با استفاده از 50G SerDes استفاده کنیم. اما معلوم می‌شود که این چندان منطقی نیست، زیرا، همانطور که قبلاً گفتم، ما یک ریشه نسبتاً بزرگ روی سوئیچ‌ها می‌خواهیم، ​​البته در حد منطق. ما 128 می خواهیم. و اگر ظرفیت تراشه محدودی داشته باشیم و سرعت لینک را افزایش دهیم، به طور طبیعی رادیکس کاهش می یابد، هیچ معجزه ای وجود ندارد.

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

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

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

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

مربع های کوچک تقاطع ها را نشان می دهند. در بالا سمت چپ، تفکیک هر یک از این تقاطع ها وجود دارد، این در واقع یک ماژول اتصال متقاطع پورت 512 در 512 است که کابل ها را دوباره بسته بندی می کند تا کاملاً در یک قفسه قرار گیرند، جایی که تنها یک هواپیمای spine-2 وجود دارد. و در سمت راست، اسکن این تصویر در رابطه با چندین Pods در سطح spine-1، و نحوه بسته بندی آن در یک اتصال متقاطع، نحوه رسیدن آن به سطح spine-2 کمی دقیق تر است.

این چیزی است که به نظر می رسد. پایه spine-2 هنوز به طور کامل مونتاژ نشده (در سمت چپ) و پایه اتصال متقاطع. متأسفانه، چیز زیادی برای دیدن وجود ندارد. کل این ساختار در حال حاضر در یکی از مراکز داده بزرگ ما که در حال گسترش است مستقر شده است. این یک کار در حال پیشرفت است، زیباتر به نظر می رسد، بهتر پر می شود.

یک سوال مهم: ما توپولوژی منطقی را انتخاب کردیم و فیزیک را ساختیم. چه اتفاقی برای هواپیمای کنترل خواهد افتاد؟ از تجربه عملیاتی کاملاً شناخته شده است، تعدادی گزارش وجود دارد که پروتکل های وضعیت پیوند خوب هستند، کار با آنها لذت بخش است، اما، متأسفانه، آنها به خوبی در یک توپولوژی متصل متراکم مقیاس نمی شوند. و یک عامل اصلی وجود دارد که از این امر جلوگیری می کند - این نحوه عملکرد سیل در پروتکل های وضعیت پیوند است. اگر فقط الگوریتم flooding را در نظر بگیرید و به ساختار شبکه ما نگاه کنید، می بینید که در هر مرحله یک fanout بسیار بزرگ وجود خواهد داشت و به سادگی صفحه کنترل را با به روز رسانی ها پر می کند. به طور خاص، چنین توپولوژی‌هایی با الگوریتم flooding سنتی در پروتکل‌های وضعیت پیوند بسیار ضعیف ترکیب می‌شوند.

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

برای انجام این کار، ما از طرحی استفاده می کنیم که به اندازه کافی ساده باشد تا از مکانیسم های زیرین BGP استفاده کند. یعنی، ما از eBGP در حال اجرا بر روی لینک محلی استفاده می‌کنیم، و سیستم‌های خودمختار به صورت زیر اختصاص داده می‌شوند: یک سیستم خودمختار در ToR، یک سیستم خودمختار در کل بلوک سوئیچ‌های spine-1 یک Pod، و یک سیستم خودمختار عمومی در کل Top از پارچه سخت نیست که ببینیم و ببینیم که حتی رفتار عادی BGP توزیع به‌روزرسانی‌هایی را که می‌خواهیم به ما می‌دهد.

به طور طبیعی، آدرس دهی و تجمع آدرس باید به گونه ای طراحی شود که با روش ساخت مسیریابی سازگار باشد، به طوری که ثبات صفحه کنترل را تضمین کند. آدرس دهی L3 در حمل و نقل به توپولوژی گره خورده است، زیرا بدون آن امکان جمع آوری وجود ندارد؛ بدون این، آدرس های فردی به سیستم مسیریابی نفوذ می کنند. و یه چیز دیگه اینکه تجمیع متاسفانه خیلی با چند مسیر قاطی نمیشه چون وقتی چند مسیری داریم و تجمیع داریم همه چیز درست میشه وقتی کل شبکه سالم باشه هیچ خرابی درش نیست. متأسفانه به محض اینکه خرابی ها در شبکه ظاهر می شود و تقارن توپولوژی از بین می رود، می توانیم به نقطه ای برسیم که واحد از آنجا اعلام شده است که از آنجا نمی توانیم به جایی که باید برویم ادامه دهیم. بنابراین، بهتر است در جایی که مسیر چندگانه دیگری وجود ندارد جمع آوری شود، در مورد ما اینها سوئیچ های ToR هستند.

در واقع، امکان تجمیع وجود دارد، اما با دقت. اگر بتوانیم در هنگام بروز خرابی شبکه، تفکیک کنترل شده را انجام دهیم. اما این یک کار بسیار دشوار است، ما حتی به این فکر کردیم که آیا انجام این کار امکان پذیر است، آیا می توان اتوماسیون اضافی و ماشین های حالت محدودی را اضافه کرد که به درستی BGP را برای به دست آوردن رفتار مورد نظر ضربه بزنند. متأسفانه پردازش موارد گوشه ای بسیار غیر مشهود و پیچیده است و این کار با الصاق پیوست های خارجی به BGP به خوبی حل نمی شود.

کارهای بسیار جالبی در این زمینه در چارچوب پروتکل RIFT انجام شده است که در گزارش بعدی به آن پرداخته خواهد شد.

نکته مهم دیگر این است که چگونه صفحات داده در توپولوژی های متراکم مقیاس می شوند، جایی که ما تعداد زیادی مسیر جایگزین داریم. در این مورد، چندین ساختار داده اضافی استفاده می شود: گروه های ECMP، که به نوبه خود گروه های Next Hop را توصیف می کنند.

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

مقیاس پذیری صفحه داده در دستگاه های مدرن چگونه است؟ اگر LPM (طولانی ترین تطابق پیشوند) را انجام دهیم، همه چیز بسیار خوب است، بیش از 100 هزار پیشوند. اگر در مورد گروه های Next Hop صحبت می کنیم، پس همه چیز بدتر است، 2-4 هزار. اگر ما در مورد جدولی صحبت می کنیم که حاوی توضیحات Next Hops (یا مجاورت ها) است، این مقدار از 16k تا 64k است. و این می تواند به یک مشکل تبدیل شود. و در اینجا به یک انحراف جالب می رسیم: چه اتفاقی برای MPLS در مراکز داده افتاد؟ در اصل ما می خواستیم این کار را انجام دهیم.

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

ساختار ارسال ECMP برای IP به این شکل است. تعداد زیادی از پیشوندها می توانند از همان گروه و همان بلوک Next Hops استفاده کنند (یا مجاورت ها، این ممکن است در اسناد مختلف برای دستگاه های مختلف به طور متفاوتی نامیده شود). نکته این است که این به عنوان پورت خروجی توصیف می‌شود و اینکه آدرس MAC را به چه چیزی بازنویسی کنیم تا به Next Hop صحیح برسیم. برای IP همه چیز ساده به نظر می رسد، می توانید از تعداد بسیار زیادی پیشوند برای همان گروه، همان بلوک Next Hops استفاده کنید.

معماری کلاسیک MPLS به این معنی است که بسته به رابط خروجی، برچسب را می توان به مقادیر مختلف بازنویسی کرد. بنابراین، ما باید یک گروه و یک بلوک Next Hops برای هر برچسب ورودی نگه داریم. و این، افسوس، مقیاس نیست.

به راحتی می توان فهمید که در طراحی ما به حدود 4000 سوئیچ ToR نیاز داشتیم، حداکثر عرض 64 مسیر ECMP بود، اگر از spine-1 به سمت spine-2 حرکت کنیم. اگر فقط یک پیشوند با ToR حذف شود، به سختی وارد یک جدول از گروه‌های ECMP می‌شویم، و اصلاً وارد جدول Next Hops نمی‌شویم.

همه چیز ناامید کننده نیست، زیرا معماری هایی مانند Segment Routing شامل برچسب های جهانی است. به طور رسمی، ممکن است دوباره همه این بلوک های Next Hops جمع شوند. برای انجام این کار، به یک عملیات نوع کارت وحشی نیاز دارید: یک برچسب بردارید و آن را بدون مقدار مشخص در همان مورد بازنویسی کنید. اما متاسفانه در پیاده سازی های موجود این امر چندان وجود ندارد.

و در نهایت، باید ترافیک خارجی را به مرکز داده بیاوریم. چگونه انجامش بدهیم؟ قبلاً ترافیک از بالا به شبکه Clos وارد می شد. یعنی روترهای لبه ای وجود داشتند که به تمام دستگاه های بالای پارچه متصل می شدند. این محلول روی سایزهای کوچک تا متوسط ​​به خوبی کار می کند. متأسفانه، برای ارسال ترافیک به صورت متقارن به کل شبکه از این طریق، باید به طور همزمان به تمام عناصر Top of Fabric برسیم، و زمانی که بیش از صد مورد از آنها وجود دارد، معلوم می شود که ما نیز به یک عنصر بزرگ نیاز داریم. رادیکس روی روترهای لبه به طور کلی، این کار هزینه دارد، زیرا روترهای لبه عملکرد بیشتری دارند، پورت های روی آنها گران تر خواهند بود و طراحی آن چندان زیبا نیست.

گزینه دیگر این است که چنین ترافیکی را از پایین شروع کنید. به راحتی می توان تأیید کرد که توپولوژی Clos به گونه ای ساخته شده است که ترافیک وارد شده از پایین، یعنی از سمت ToR، به طور مساوی در بین سطوح در سراسر Top of Fabric در دو تکرار توزیع می شود و کل شبکه را بارگیری می کند. بنابراین نوع خاصی از پاد یعنی Edge Pod را معرفی می کنیم که اتصال خارجی را فراهم می کند.

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

چه فرصت های توسعه ای را می بینیم؟ اول از همه، بهبود پشتیبانی از خط لوله CI/CD. ما می‌خواهیم همانطور که آزمایش می‌کنیم پرواز کنیم و روشی که پرواز می‌کنیم را آزمایش کنیم. این خیلی خوب کار نمی کند، زیرا زیرساخت بزرگ است و نمی توان آن را برای آزمایش تکرار کرد. شما باید بدانید که چگونه می توان عناصر آزمایشی را بدون حذف آن به زیرساخت تولید وارد کرد.

ابزار دقیق و نظارت بهتر تقریباً هیچ وقت اضافی نیستند. کل سوال تعادل تلاش و بازگشت است. اگر بتوانید با تلاش معقول آن را اضافه کنید، بسیار خوب است.

باز کردن سیستم عامل برای دستگاه های شبکه پروتکل های بهتر و سیستم های مسیریابی بهتر، مانند RIFT. همچنین تحقیقاتی در مورد استفاده از طرح‌های کنترل تراکم بهتر و شاید معرفی، حداقل در برخی نقاط، پشتیبانی RDMA در داخل خوشه مورد نیاز است.

با نگاهی بیشتر به آینده، ما به توپولوژی های پیشرفته و احتمالاً شبکه هایی نیاز داریم که از سربار کمتری استفاده کنند. از میان چیزهای تازه، اخیراً انتشاراتی در مورد فناوری پارچه برای HPC Cray Slingshot منتشر شده است که مبتنی بر اترنت کالا است، اما با امکان استفاده از هدرهای بسیار کوتاه تر. در نتیجه سربار کاهش می یابد.

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

منبع: www.habr.com