لقد طورنا تصميمًا لشبكة من مراكز البيانات ، والتي تتيح لك نشر مجموعات حوسبة أكبر من 100 ألف خادم مع عرض نطاق ترددي مزدوج يصل إلى أكثر من بيتابت في الثانية.
من تقرير ديمتري أفاناسييف ، سوف تتعرف على المبادئ الأساسية للتصميم الجديد ، وتوسيع نطاق الطوبولوجيا التي تنشأ مع هذه المشكلات ، والحلول لهم ، حول ميزات التوجيه وتوسيع نطاق وظائف طائرة إعادة التوجيه لأجهزة الشبكة الحديثة في طوبولوجيا "كثيفة الارتباط" مع عدد كبير من طرق ECMP . بالإضافة إلى ذلك ، تحدثت ديما لفترة وجيزة عن تنظيم الاتصال الخارجي ، والمستوى المادي ، ونظام الكابل وطرق زيادة السعة.
- مساء الخير جميعا! اسمي ديمتري أفاناسييف ، أنا مهندس شبكة من ياندكس وأنا أتعامل بشكل رئيسي مع تصميم شبكات مراكز البيانات.
ستكون قصتي حول شبكة مركز بيانات ياندكس المحدثة. هذا إلى حد كبير تطور في التصميم الذي قمنا به ، ولكن في نفس الوقت هناك بعض العناصر الجديدة. هذا عرض تقديمي للمراجعة ، لأنه كان من الضروري احتواء الكثير من المعلومات في وقت قصير. نبدأ باختيار طوبولوجيا منطقية. بعد ذلك ، سيكون هناك نظرة عامة على مستوى التحكم ومشاكل قابلية التوسع في مستوى البيانات ، واختيار ما سيحدث على المستوى المادي ، دعونا نلقي نظرة على بعض ميزات الأجهزة. سنتطرق أيضًا إلى ما يحدث في مركز البيانات مع MPLS ، والذي تحدثنا عنه منذ بعض الوقت.
لذلك ، ما هو ياندكس من حيث أعباء العمل والخدمات؟ ياندكس هو فرط نموذجي. إذا نظرت في اتجاه المستخدمين ، فنحن نعالج طلبات المستخدم بشكل أساسي. أيضا ، العديد من خدمات التدفق وإخراج البيانات ، لأن لدينا أيضا خدمات التخزين. إذا كان أقرب إلى الواجهة الخلفية ، فستظهر أحمال وخدمات البنية التحتية هناك ، مثل مخازن الكائنات الموزعة ، وتكرار البيانات ، وبالطبع قوائم الانتظار الدائمة. أحد أنواع التحميل الرئيسية هو MapReduce وما شابه ذلك ، ومعالجة البث المباشر ، والتعلم الآلي ، وما إلى ذلك.
كيف هي البنية التحتية التي يحدث كل هذا؟ مرة أخرى ، نحن hyperskaler نموذجي للغاية ، على الرغم من أننا ربما نكون أقرب قليلاً من جانب الطيف حيث توجد hyperskalers أصغر. لكن لدينا كل الصفات. نحن نستخدم الأجهزة السلعية والتحجيم الأفقي كلما أمكن ذلك. لدينا نمو كامل في تجميع الموارد: نحن لا نعمل مع أجهزة منفصلة ، رفوف منفصلة ، ولكن نجمعها في مجموعة كبيرة من الموارد القابلة للتبديل مع بعض الخدمات الإضافية التي تشارك في التخطيط والتخصيص ، ونحن نعمل مع كل هذا التجمع.
لذلك لدينا المستوى التالي - مجموعة الحوسبة على مستوى نظام التشغيل. من المهم جدًا أن نتحكم بشكل كامل في كومة التقنية التي نستخدمها. نحن نتحكم في نقاط النهاية (المضيفين) وشبكة البرمجيات والمكدس.
لدينا العديد من مراكز البيانات الكبيرة في روسيا والخارج. يتم توحيدها بواسطة العمود الفقري باستخدام تقنية MPLS. تعتمد البنية الأساسية الداخلية الخاصة بنا بشكل كامل على IPv6 ، ولكن بما أننا بحاجة إلى التعامل مع حركة المرور الخارجية ، والتي لا تزال يتم توصيلها بشكل رئيسي عبر IPv4 ، فيجب علينا توصيل الطلبات القادمة عبر IPv4 إلى الخوادم الأمامية ، ولا نزال ننتقل قليلاً إلى IPv4- الخارجية الإنترنت - على سبيل المثال ، للفهرسة.
تستخدم التكرارات القليلة الأخيرة من تصميم شبكة مركز البيانات طبولوجيا Clos متعددة المستويات ، ويتم استخدام L3 فقط فيها. غادرنا L2 منذ بعض الوقت والتنفس الصعداء. أخيرًا ، تتضمن البنية الأساسية لدينا مئات الآلاف من مثيلات الحوسبة (الخادم). الحد الأقصى لحجم الكتلة منذ بعض الوقت كان حوالي 10 ألف خوادم. ويعزى ذلك إلى حد كبير إلى كيفية عمل أنظمة التشغيل على مستوى نظام المجموعة - المجدول ، وتخصيص الموارد ، وما إلى ذلك. نظرًا لوجود تقدم على جانب برنامج البنية التحتية ، أصبح الهدف الآن حوالي 100 ألف خادم في مجموعة حوسبة واحدة ، و كان لدينا مهمة - أن نكون قادرين على بناء مصانع شبكات تتيح تجميع الموارد بكفاءة في مثل هذه المجموعة.
ماذا نريد من شبكة مركز البيانات؟ بادئ ذي بدء - الكثير من النطاق الترددي رخيصة وموزعة إلى حد ما. لأن الشبكة هي تلك الركيزة التي يمكننا من خلالها القيام بتجميع الموارد. حجم الهدف الجديد هو حوالي 100 ألف خوادم في كتلة واحدة.
أيضًا ، بالطبع ، نريد وجود طائرة تحكم ثابتة وقابلة للتطوير ، لأن الكثير من الصداع في هذه البنية التحتية الكبيرة تنشأ حتى من الأحداث العشوائية فقط ، ولا نريد أن تحضرنا طائرة التحكم إلى الصداع. في الوقت نفسه ، نريد تقليل الحالة فيه. كلما كانت الحالة أصغر ، كلما كان كل شيء أفضل وأكثر استقرارًا ، أصبح من السهل التشخيص.
بالطبع ، نحن بحاجة إلى الأتمتة ، لأنه من المستحيل إدارة هذه البنية التحتية يدويًا ، وكان ذلك مستحيلًا منذ بعض الوقت. كلما أمكن ، نحتاج إلى دعم تشغيلي ودعم CI / CD إلى أقصى حد ممكن.
مع مثل هذه الأحجام من مراكز البيانات والمجموعات ، أصبحت مهمة دعم النشر التزايدي والتوسع دون انقطاع الخدمة حادة للغاية. إذا كان حجم المجموعات من ألف سيارة على الأرجح في المجموعات يصل إلى عشرة آلاف ماكينة ، فلا يزال من الممكن طرحها كعملية واحدة - أي أننا نخطط لتوسيع البنية التحتية ، وتتم إضافة عدة آلاف من الآلات كعملية واحدة ، ثم لا تجمع مجموعة بحجم مائة ألف سيارة تماما مثل ذلك ، تم بناؤه لبعض الوقت. ومن المرغوب فيه أن يتوفر كل هذا الوقت الذي تم ضخه بالفعل ، والبنية التحتية التي تم نشرها.
وأحد المتطلبات التي كان لدينا وتركنا: هذا هو دعم multitenancy ، أي الافتراضية أو تجزئة الشبكة. الآن نحن لسنا بحاجة إلى القيام بذلك على مستوى مصنع الشبكة ، لأن التقسيم ذهب إلى المضيفين ، مما جعل عملية التحجيم سهلة للغاية بالنسبة لنا. بفضل IPv6 ومساحة العنوان الكبيرة ، لم نكن بحاجة إلى استخدام عناوين مكررة في البنية التحتية الداخلية ، فكل العناوين كانت فريدة بالفعل. ونظرًا لأننا أخذنا التصفية وتقسيم الشبكة إلى المضيفين ، لا نحتاج إلى إنشاء أي كيانات للشبكات الافتراضية في شبكات مراكز البيانات.
الشيء المهم هو أننا لسنا بحاجة. إذا كانت بعض الوظائف يمكن إزالتها من الشبكة ، فإن ذلك يبسط الحياة إلى حد كبير ، وكقاعدة عامة ، يوسع اختيار الأجهزة والبرامج المتاحة ، ويبسط التشخيص إلى حد كبير.
إذن ، ما الذي لا نحتاج إليه ، ما الذي تمكنا من رفضه ، ليس دائمًا بالفرح في الوقت الذي حدث فيه هذا ، ولكن بارتياح كبير ، عندما اكتملت العملية؟
بادئ ذي بدء ، رفض L2. نحن لسنا بحاجة L2 سواء حقيقية أو مقلدة. لا تستخدم إلى حد كبير بسبب حقيقة أننا نتحكم في مكدس التطبيق. يتم قياس تطبيقاتنا بشكل أفقي ، فهي تعمل باستخدام عناوين L3 ، ولا تقلق حقًا من وجود بعض الحالات المعينة ، فهي فقط تطرح نسخة جديدة ، ولا تحتاج إلى طرحها على العنوان القديم ، لأن هناك مستوى منفصلًا لاكتشاف الخدمة ومراقبة الأجهزة الموجودة في المجموعة . نحن لا نحول هذه المهمة إلى الشبكة. مهمة الشبكة هي توصيل الحزم من النقطة أ إلى النقطة ب.
أيضًا ، ليست لدينا مواقف تنتقل فيها العناوين داخل الشبكة ، ويجب مراقبة ذلك. في العديد من التصميمات ، عادة ما تكون هناك حاجة لدعم تنقل VM. نحن لا نستخدم قابلية تنقل الأجهزة الافتراضية في البنية التحتية الداخلية لشركة Yandex الكبيرة بالضبط ، وبالإضافة إلى ذلك ، نعتقد أنه حتى إذا تم ذلك ، فلن يحدث هذا مع دعم الشبكة. إذا كنت بحاجة فعلاً للقيام بذلك ، فعليك القيام بذلك على مستوى المضيف ، وقيادة العناوين التي يمكن أن تنتقل إلى التراكبات حتى لا تلمس أو تجري الكثير من التغييرات الديناميكية على نظام التوجيه نفسه (شبكة النقل).
تقنية أخرى لا نستخدمها هي البث المتعدد. استطيع ان اقول لكم بالتفصيل لماذا. هذا يجعل الحياة أسهل بكثير ، لأنه إذا تعامل شخص معه وشاهد كيف تبدو طائرة التحكم في البث المتعدد تمامًا - في جميع المنشآت باستثناء أبسطها ، فهذا يعد صداعًا كبيرًا. والأكثر من ذلك ، من الصعب العثور على تطبيق مفتوح المصدر يعمل بشكل جيد ، على سبيل المثال.
أخيرًا ، نقوم بتصميم شبكاتنا بحيث لا تحتوي على الكثير من التغييرات. يمكننا الاعتماد على حقيقة أن تدفق الأحداث الخارجية في نظام التوجيه صغير.
ما هي المشاكل التي تنشأ والقيود التي يجب مراعاتها عند تطوير شبكة مركز البيانات؟ تكلفة بالطبع. قابلية التوسع ، إلى أي مستوى نريد أن ننمو. الحاجة إلى التوسع دون إيقاف الخدمة. توافر عرض النطاق الترددي. رؤية ما يحدث على الشبكة ، لأنظمة المراقبة ، للفرق التشغيلية. دعم الأتمتة هو ، مرة أخرى ، قدر الإمكان ، حيث يمكن حل المهام المختلفة على مستويات مختلفة ، بما في ذلك إدخال طبقات إضافية. حسنًا - [كلما كان ذلك ممكنًا] - الاعتماد على البائعين. رغم أنه في فترات تاريخية مختلفة ، بناءً على القسم الذي يجب النظر إليه ، كان هذا الاستقلال أسهل أو أصعب تحقيقًا. إذا أخذنا شريحة من شرائح أجهزة الشبكة ، فحتى وقت قريب ، تحدثنا عن الاستقلال عن البائعين ، وإذا أردنا أيضًا شرائح ذات إنتاجية عالية ، فقد تكون تعسفية للغاية.
ما هي الطوبولوجيا المنطقية التي سنستخدمها لبناء شبكتنا؟ سيكون هذا كلوس متعدد المستويات. في الواقع ، لا يوجد حاليا أي بدائل حقيقية. طوبولوجيا Clos جيدة بما فيه الكفاية ، حتى لو قارناها بالعديد من الطبولوجيا المتقدمة التي أصبحت الآن أكثر في مجال الاهتمام الأكاديمي ، إذا كان لدينا مفاتيح ذات نطاق كبير.
كيف يتم تنظيم شبكة Clos ذات الطبقات تقريبًا وما هي العناصر المختلفة التي يتم استدعاءها؟ بادئ ذي بدء ، ارتفعت الرياح ، لمعرفة أين الشمال ، حيث الجنوب ، حيث الشرق ، حيث الغرب. وعادة ما يتم بناء شبكات من هذا النوع من قبل أولئك الذين لديهم حركة مرور كبيرة جدا من الغرب إلى الشرق. بالنسبة لبقية العناصر ، يظهر مفتاح افتراضي تم تجميعه من مفاتيح أصغر في الجزء العلوي. هذه هي الفكرة الأساسية لبناء شبكات كلوس بشكل متكرر. نحن نأخذ عناصر بنوع معين من الجذر ونقوم بتوصيلها بحيث يمكن اعتبار ما حدث بمثابة مفتاح ذو نطاق أكبر. إذا كنت بحاجة إلى المزيد ، فيمكن تكرار الإجراء.
في الحالات ، على سبيل المثال ، مع Clos ذو مستويين ، عندما يكون من الممكن التمييز بوضوح بين المكونات ذات العمودي في المخطط الخاص بي ، فإنها تسمى عادة الطائرات. إذا قمنا ببناء Clos - مع ثلاثة مستويات من مفاتيح العمود الفقري (جميعها ليست حدودية وليست مفاتيح ToR والتي تستخدم فقط للمرور العابر) ، فإن الطائرات ستبدو أكثر تعقيدًا ، ويبدو مستواها على هذا النحو. كتلة من مفاتيح ToR أو ورقة ومفاتيح العمود الفقري المستوى الأول المرتبطة ندعو قرنة. مفاتيح مستوى العمود الفقري 1 في الجزء العلوي من قرنة هي الجزء العلوي من قرنة ، الجزء العلوي من قرنة. المفاتيح الموجودة في أعلى المصنع بالكامل هي الطبقة العليا للمصنع ، أعلى القماش.
بطبيعة الحال ، فإن السؤال الذي يطرح نفسه: تم بناء شبكات Clos لبعض الوقت ، والفكرة نفسها تأتي عادة من أيام الاتصالات الهاتفية الكلاسيكية ، شبكات TDM. ربما يبدو شيء أفضل ، وربما يمكنك أن تفعل شيئا أفضل بطريقة أو بأخرى؟ نعم ولا. من الناحية النظرية ، نعم ، في الممارسة العملية ، في المستقبل القريب ، بالتأكيد لا. نظرًا لوجود عدد من طبولوجيا مثيرة للاهتمام ، يتم استخدام بعضها في الإنتاج ، على سبيل المثال ، يتم استخدام Dragonfly في تطبيقات HPC ؛ هناك أيضًا طبولوجيا مثيرة للاهتمام مثل Xpander و FatClique و Jellyfish. إذا نظرت إلى تقارير في مؤتمرات مثل SIGCOMM أو NSDI في الآونة الأخيرة ، يمكنك العثور على عدد كبير إلى حد ما من الأوراق حول طبولوجيا بديلة لها خصائص أفضل (واحدة أو أخرى) من Clos.
ولكن كل هذه الطبولوجيا لها خاصية واحدة مثيرة للاهتمام. ويمنع تنفيذها في شبكات مراكز البيانات ، التي نحاول الاستفادة منها على الأجهزة السلعية والتي تكلف مالًا معقولًا. في جميع هذه الطوبولوجيا البديلة ، معظم الفرقة ، للأسف ، لا يمكن الوصول إليها عبر أقصر الطرق. لذلك ، نفقد على الفور القدرة على استخدام طائرة التحكم التقليدية.
من الناحية النظرية ، فإن حل المشكلة معروف. هذه ، على سبيل المثال ، هي تعديلات لحالة الارتباط باستخدام أقصر الطرق k ، ولكن مرة أخرى ، لا توجد بروتوكولات يمكن تنفيذها في الإنتاج ومتاحة بشكل كبير على المعدات.
علاوة على ذلك ، نظرًا لأن معظم السعة لا يمكن الوصول إليها عبر أقصر الطرق ، نحتاج إلى تعديل ليس فقط مستوى التحكم بحيث يختار كل هذه المسارات (وبالمناسبة ، هذه حالة أكبر بكثير في مستوى التحكم). ما زلنا بحاجة إلى تعديل مستوى إعادة التوجيه ، وكقاعدة عامة ، لا بد من وجود ميزتين إضافيتين على الأقل. هذه فرصة لاتخاذ جميع القرارات المتعلقة بإعادة توجيه الحزم لمرة واحدة ، على سبيل المثال ، على مضيف. هذا هو في الواقع توجيه المصدر ، في بعض الأحيان في الأدبيات على شبكات الاتصال البيني يطلق عليه قرارات إعادة توجيه الكل في وقت واحد. يعد التوجيه التكيفي وظيفة نحتاجها بالفعل في عناصر الشبكة ، والتي تتلخص ، على سبيل المثال ، في حقيقة أننا نختار القفزة التالية بناءً على معلومات حول أقل حمل في قائمة الانتظار. كمثال ، الخيارات الأخرى ممكنة.
وبالتالي ، فإن الاتجاه مثير للاهتمام ، ولكن ، للأسف ، لا يمكننا تطبيقه الآن.
حسنا ، استقر على الطوبولوجيا المنطقية لكلوس. كيف سنقوم بتوسيع نطاقه؟ دعونا نرى كيف يعمل وما يمكن القيام به.
يوجد في شبكة Clos معلمتان أساسيتان يمكننا أن نغيرهما بطريقة ما ونحصل على نتائج معينة: عناصر الجذر وعدد المستويات في الشبكة. أصف بشكل تخطيطي كيف يؤثر الآخر والآخر على الحجم. من الناحية المثالية ، نجمع بين الاثنين.
يمكن أن نرى أن العرض الكلي لشبكة Clos هو نتاج جميع مستويات مفاتيح العمود الفقري للنصوص الجنوبية ، وعدد الروابط التي لدينا ، وكيف تتفرع. هذه هي الطريقة التي نقيس بها حجم الشبكة.
بالنسبة للسعة ، خاصةً في مفاتيح ToR ، يوجد خياران للتحجيم. إما أنه يمكننا ، مع الحفاظ على الهيكل العام ، استخدام روابط أسرع ، أو يمكننا إضافة المزيد من الطائرات.
إذا نظرت إلى الإصدار المفصل من شبكة Clos (في الركن الأيمن السفلي) والعودة إلى هذه الصورة مع شبكة Clos أدناه ...
... ثم هذا هو نفس الهيكل تمامًا ، ولكن في هذه الشريحة يتم طيها بشكل أكثر إحكاما ويتم تركيب طائرات المصنع على بعضها البعض. انها واحدة ونفس الشيء.
كيف يبدو توسيع نطاق شبكة Clos بالأرقام؟ لدي هنا بيانات عن أقصى عرض يمكن أن تحصل عليه الشبكة ، أو الحد الأقصى لعدد الرفوف ، أو مفاتيح ToR ، أو مفاتيح الأوراق ، إذا لم تكن موجودة في الرفوف ، فيمكننا الحصول على اعتماد على مجموعة رموز التبديل التي نستخدمها في الفقرات المستويات وعدد المستويات التي نستخدمها.
إنه يوضح عدد الرفوف التي يمكن أن نحصل عليها ، وعدد الخوادم وكم يمكن أن يستهلك كل هذا بمعدل 20 كيلو واط لكل رف. قبل قليل ، ذكرت أننا نهدف إلى حجم كتلة من حوالي 100 ألف خوادم.
يمكن أن نرى أن في هذا البناء كله خياران ونصف مهمان. هناك خيار مع طبقتين من العمود الفقري ومفاتيح 64 منفذ ، والتي هي قصيرة بعض الشيء. بعد ذلك ، تتوفر خيارات ملائمة تمامًا لمفاتيح العمود الفقري ذات 128 منفذًا (مع 128 radix) بمستويين ، أو مفاتيح ذات 32 radix مع ثلاثة مستويات. وفي جميع الحالات التي يوجد فيها عدد أكبر من المستويات والمزيد من المستويات ، يمكنك إنشاء شبكة كبيرة جدًا ، ولكن إذا نظرت إلى الاستهلاك المتوقع ، كقاعدة عامة ، فهناك غيغاوات. يمكنك وضع الكابل ، لكن من غير المحتمل أن نحصل على الكثير من الكهرباء في موقع واحد. إذا نظرت إلى الإحصاءات ، فإن البيانات العامة حول مراكز البيانات - يمكن العثور على عدد قليل جدًا من مراكز البيانات بسعة تقدر بأكثر من 150 ميجاوات. والأكثر من ذلك - كقاعدة عامة ، حرم مراكز البيانات ، والعديد من مراكز البيانات الضخمة الموجودة بالقرب من بعضها البعض.
هناك معلمة أخرى مهمة. إذا نظرت إلى العمود الأيسر ، فسيتم الإشارة إلى النطاق الترددي القابل للاستخدام هناك. من السهل ملاحظة أنه في شبكة Clos ، يتم إنفاق جزء كبير من المنافذ على توصيل المحولات ببعضها البعض. عرض النطاق الترددي القابل للاستخدام هو ما يمكنك تقديمه تجاه الخوادم. بطبيعة الحال ، أنا أتحدث عن المنافذ الشرطية وعن الشريط. كقاعدة عامة ، تكون الروابط داخل الشبكة أسرع من الارتباطات بالخوادم ، ولكن لكل وحدة من النطاقات ، بقدر ما يمكننا تقديمها إلى أجهزة الخادم الخاصة بنا ، لا يزال هناك بعض النطاقات داخل الشبكة نفسها. وكلما زادت مستوياتنا ، زادت تكاليف الوحدة لتوفير هذا الشريط للخارج.
علاوة على ذلك ، حتى هذه الفرقة الإضافية ليست هي نفسها بالضبط. على الرغم من أن فترات الامتداد قصيرة ، إلا أنه يمكننا استخدام شيء مثل DAC (النحاس المتصل مباشرة ، أي كابلات twinax) ، أو البصريات متعددة الوسائط ، والتي تكلف أكثر أو أقل من المال المعقول. بمجرد أن نتحول إلى امتدادات أصيلة - كقاعدة عامة ، هذه بصريات أحادية الوضع ، وتكلفة هذه الفرقة الإضافية تزداد بشكل ملحوظ.
ومرة أخرى ، بالعودة إلى الشريحة السابقة ، إذا قمنا بإنشاء شبكة Clos دون إعادة الاشتراك ، فمن السهل أن ننظر إلى الرسم التخطيطي ، وانظر كيف تم بناء الشبكة - بإضافة كل مستوى من مفاتيح العمود الفقري ، نكرر الشريط بأكمله الذي كان أدناه. مستوى زائد - بالإضافة إلى نفس النطاق ، نفس عدد المنافذ على المفاتيح كما في المستوى السابق ، نفس عدد أجهزة الإرسال والاستقبال. لذلك ، فإن عدد مستويات مفاتيح العمود الفقري أمر مرغوب فيه للغاية لتقليله.
استنادًا إلى هذه الصورة ، من الواضح أننا نرغب حقًا في البناء على شيء مثل المحولات ذات 128 نطاقًا أساسيًا.
هنا ، من حيث المبدأ ، كل شيء هو نفسه كما قلت للتو ، من المرجح أن يتم النظر في هذه الشريحة لاحقًا.
, ? , - . , . , . , . , , , , . ( ), control plane , , , , . , , .
, , , SerDes- — - . forwarding . , , , , , Clos-, . .
, , . , , , , , , , , , .
— , . , , . , , , - , . , , , , .
, , , . -, , . , , 128 , .
, , , data plane. . , , . , , , . , , , , 128 , . . . .
, - , . ( ), , — ToR- leaf-, . - , , , , - . , , , - .
, , .
? . , , , : leaf-, 1, 2. , — twinax, multimode, single mode. , , , , , .
. , , multimode , , , 100- . , , , single mode , , single mode, - CWDM, single mode (PSM) , , , .
: , 100 425 . SFP28 , QSFP28 100 . multimode .
- , - , - - . , . , - Pods twinax- ( ).
, , , CWDM. .
, , . , , 50- SerDes . , , 400G, 50G SerDes- , 100 Gbps per lane. , 50 100- SerDes 100 Gbps per lane, . , 50G SerDes , , , 100G SerDes . - , , .
. , 400- 200- 50G SerDes. , , , , , , . 128. , , , , .
, , . , , , , , 100- , .
— , . , . leaf- — , . , , — .
, , , -. , , - -, . . , , , . - -, -, , , , . : . - , « », Clos-, . , , .
. - , , , , -2-.
. , - 512 512 , , , -2. Pods -1, -, -2.
هنا هو كيف يبدو. -2 () -. , . -, . , , .
: , . control plane-? , - , link state , , , , . , — , link state . , , , , fanout, control plane . link state .
— BGP. , RFC 7938 BGP -. : , , , path hunting. , , , valley free. , , , . , , . . .
, , BGP. eBGP, link local, : ToR, -1- Pod, Top of Fabric. , BGP , .
, , , , control plane. L3 , , . — , , , multi-path, multi-path , , , . , , , , , . , multi-path, ToR-.
, , — . , , , , BGP, . , corner cases , BGP .
RIFT, .
— , data plane , . : ECMP , Next Hop.
, , Clos- , , , , , . , ECMP, single path-. . , Clos- , Top of fabric, , . , , . , ECMP state.
data plane ? LPM (longest prefix match), , 100 . Next Hop , , 2-4 . , Next Hops ( adjacencies), - 16 64. . : MPLS -? , .
. , . white boxes MPLS. MPLS, , , , ECMP. وهنا السبب.
ECMP- IP. Next Hops ( adjacencies, -). , -, Next Hop. IP , , Next Hops.
MPLS , . Next Hops . , , .
, 4000 ToR-, — 64 ECMP, -1 -2. , , ECMP-, ToR , Next Hops.
, Segment Routing . Next Hops. wild card: . , .
, - . ? Clos- . , Top of fabric. . , , Top of fabric, , , . , , , , .
— . , Clos- , , , ToR, Top of fabric , . Pod, Edge Pod, .
. , , Facebook. Fabric Aggregator HGRID. -, -. , . , touch points, . , , -. , - , , . , , . overlays, .
? — CI/CD-. , , , . , , . , , .
, . . — .
. , RIFT. congestion control , , , , RDMA .
, , , , overhead. — HPC Cray Slingshot, commodity Ethernet, . overhead .
, , . — . — . - scale out — . , . . شكرا لك