كيفية توسيع نطاق مراكز البيانات. تقرير ياندكس

لقد قمنا بتطوير تصميم شبكة مركز البيانات الذي يسمح بنشر مجموعات حوسبة أكبر من 100 ألف خادم مع عرض نطاق ترددي مجزأ يصل إلى أكثر من بيتابايت واحد في الثانية.

من تقرير ديمتري أفاناسييف، ستتعرف على المبادئ الأساسية للتصميم الجديد، وتوسيع نطاق الطبولوجيا، والمشكلات التي تنشأ مع ذلك، وخيارات حلها، وميزات التوجيه وتوسيع نطاق وظائف مستوى إعادة التوجيه لأجهزة الشبكة الحديثة في "المتصلة بكثافة" طبولوجيا مع عدد كبير من مسارات ECMP . بالإضافة إلى ذلك، تحدثت ديما بإيجاز عن تنظيم الاتصال الخارجي، والطبقة المادية، ونظام الكابلات وطرق زيادة السعة.

- مساء الخير جميعا! اسمي ديمتري أفاناسييف، أنا مهندس شبكات في Yandex وأقوم بشكل أساسي بتصميم شبكات مراكز البيانات.



ستكون قصتي حول الشبكة المحدثة لمراكز بيانات Yandex. إنه تطور كبير للتصميم الذي لدينا، ولكن في الوقت نفسه هناك بعض العناصر الجديدة. يعد هذا عرضًا تقديميًا عامًا لأنه كان هناك الكثير من المعلومات التي يجب تجميعها في فترة زمنية قصيرة. سنبدأ باختيار طوبولوجيا منطقية. بعد ذلك، ستكون هناك نظرة عامة على مستوى التحكم ومشاكل قابلية التوسع في مستوى البيانات، واختيار ما سيحدث على المستوى المادي، وسننظر في بعض ميزات الأجهزة. دعونا نتطرق قليلاً إلى ما يحدث في مركز البيانات المزود بتقنية MPLS، والذي تحدثنا عنه منذ فترة.

إذن، ما هو ياندكس من حيث الأحمال والخدمات؟ Yandex هو برنامج Hyperscaler نموذجي. إذا نظرنا إلى المستخدمين، فإننا نقوم في المقام الأول بمعالجة طلبات المستخدمين. أيضًا خدمات البث المختلفة ونقل البيانات، لأن لدينا أيضًا خدمات تخزين. إذا كان أقرب إلى الواجهة الخلفية، فستظهر أحمال وخدمات البنية التحتية هناك، مثل تخزين الكائنات الموزعة، وتكرار البيانات، وبالطبع قوائم الانتظار المستمرة. أحد الأنواع الرئيسية لأحمال العمل هو MapReduce والأنظمة المماثلة ومعالجة التدفق والتعلم الآلي وما إلى ذلك.

كيف هي البنية التحتية التي فوقها كل هذا يحدث؟ مرة أخرى، نحن فرط التدرج نموذجي جدًا، على الرغم من أننا ربما نكون أقرب قليلاً إلى الجانب الأقل فرطًا من الطيف. ولكن لدينا كل الصفات. نحن نستخدم الأجهزة السلعية والقياس الأفقي حيثما أمكن ذلك. لدينا تجميع كامل للموارد: نحن لا نعمل مع أجهزة فردية، أو رفوف فردية، ولكن ندمجها في مجموعة كبيرة من الموارد القابلة للتبديل مع بعض الخدمات الإضافية التي تتعامل مع التخطيط والتخصيص، ونعمل مع هذه المجموعة بأكملها.

إذن لدينا المستوى التالي - نظام التشغيل على مستوى مجموعة الحوسبة. من المهم جدًا أن نتحكم بشكل كامل في مجموعة التكنولوجيا التي نستخدمها. نحن نتحكم في نقاط النهاية (المضيفين) والشبكة ومكدس البرامج.

لدينا العديد من مراكز البيانات الكبيرة في روسيا والخارج. إنهم متحدون بواسطة العمود الفقري الذي يستخدم تقنية MPLS. البنية التحتية الداخلية لدينا مبنية بالكامل تقريبًا على IPv6، ولكن نظرًا لأننا بحاجة إلى خدمة حركة المرور الخارجية التي لا تزال تأتي بشكل أساسي عبر IPv4، فيجب علينا بطريقة ما تسليم الطلبات القادمة عبر IPv4 إلى خوادم الواجهة الأمامية، والانتقال أكثر قليلاً إلى IPv4 الخارجي - الإنترنت - من أجل على سبيل المثال، للفهرسة.

استخدمت التكرارات القليلة الأخيرة لتصميمات شبكة مركز البيانات طبولوجيا Clos متعددة الطبقات وهي L3 فقط. لقد غادرنا L2 منذ فترة وتنفسنا الصعداء. وأخيرًا، تشتمل بنيتنا التحتية على مئات الآلاف من مثيلات الحوسبة (الخادم). كان الحد الأقصى لحجم المجموعة منذ بعض الوقت حوالي 10 آلاف خادم. ويرجع ذلك إلى حد كبير إلى كيفية عمل أنظمة التشغيل والمجدولات وتخصيص الموارد وما إلى ذلك على مستوى المجموعة. ومنذ حدوث التقدم على جانب برامج البنية التحتية، أصبح الحجم المستهدف الآن حوالي 100 ألف خادم في مجموعة حوسبة واحدة، و لدينا مهمة - أن نكون قادرين على بناء مصانع الشبكات التي تسمح بتجميع الموارد بكفاءة في مثل هذه المجموعة.

ماذا نريد من شبكة مركز البيانات؟ بادئ ذي بدء، هناك الكثير من النطاق الترددي الرخيص والموزع بشكل موحد إلى حد ما. لأن الشبكة هي العمود الفقري الذي يمكننا من خلاله تجميع الموارد. ويبلغ الحجم المستهدف الجديد حوالي 100 ألف خادم في مجموعة واحدة.

نحن أيضًا، بالطبع، نريد طائرة تحكم مستقرة وقابلة للتطوير، لأنه في مثل هذه البنية التحتية الكبيرة تنشأ الكثير من المشاكل حتى من مجرد أحداث عشوائية، ولا نريد أن تسبب لنا طائرة التحكم الصداع أيضًا. وفي الوقت نفسه، نريد التقليل من الحالة فيه. كلما كانت الحالة أصغر، كان كل شيء يعمل بشكل أفضل وأكثر استقرارًا، وأصبح تشخيصه أسهل.

وبطبيعة الحال، نحن بحاجة إلى الأتمتة، لأنه من المستحيل إدارة مثل هذه البنية التحتية يدويا، وقد ظل ذلك مستحيلا لبعض الوقت. نحن بحاجة إلى دعم تشغيلي قدر الإمكان ودعم CI/CD إلى الحد الذي يمكن تقديمه.

مع هذه الأحجام من مراكز البيانات والمجموعات، أصبحت مهمة دعم النشر والتوسع المتزايدين دون انقطاع الخدمة حادة للغاية. إذا كان حجم مجموعات من ألف جهاز، وربما ما يقرب من عشرة آلاف جهاز، فلا يزال من الممكن طرحها كعملية واحدة - أي أننا نخطط لتوسيع البنية التحتية، وإضافة عدة آلاف من الآلات كعملية واحدة، ومن ثم فإن مجموعة بحجم مائة ألف آلة لا تنشأ على الفور بهذه الطريقة، بل يتم بناؤها على مدى فترة من الزمن. ومن المرغوب فيه أن يكون ما تم ضخه بالفعل، والبنية التحتية التي تم نشرها، متاحًا طوال هذا الوقت.

وأحد المتطلبات التي كانت لدينا وتركناها: دعم تعدد الإيجارات، أي المحاكاة الافتراضية أو تجزئة الشبكة. الآن لا نحتاج إلى القيام بذلك على مستوى نسيج الشبكة، لأن التقسيم انتقل إلى المضيفين، وهذا جعل التوسع سهلاً للغاية بالنسبة لنا. بفضل IPv6 ومساحة العنوان الكبيرة، لم نكن بحاجة إلى استخدام عناوين مكررة في البنية التحتية الداخلية؛ حيث كانت كل العناوين فريدة بالفعل. وبفضل حقيقة أننا قمنا بتصفية وتجزئة الشبكة للمضيفين، فإننا لا نحتاج إلى إنشاء أي كيانات شبكة افتراضية في شبكات مركز البيانات.

الشيء المهم للغاية هو ما لا نحتاجه. إذا كان من الممكن إزالة بعض الوظائف من الشبكة، فهذا يجعل الحياة أسهل بكثير، وكقاعدة عامة، يوسع نطاق اختيار المعدات والبرامج المتاحة، مما يجعل التشخيص بسيطًا للغاية.

إذًا، ما الذي لا نحتاج إليه، وما الذي تمكنا من التخلي عنه، ليس دائمًا بفرح وقت حدوثه، ولكن بارتياح كبير عندما تكتمل العملية؟

بادئ ذي بدء، التخلي عن L2. نحن لسنا بحاجة إلى L2، لا حقيقي ولا مقلد. غير مستخدم إلى حد كبير بسبب حقيقة أننا نتحكم في مكدس التطبيق. تطبيقاتنا قابلة للتطوير أفقيًا، وتعمل مع معالجة L3، ولا يشعرون بالقلق الشديد من خروج بعض المثيلات الفردية، بل يقومون ببساطة بطرح مثيل جديد، ولا يلزم طرحه على العنوان القديم، نظرًا لوجود مستوى منفصل لاكتشاف الخدمة ومراقبة الأجهزة الموجودة في المجموعة. نحن لا نفوض هذه المهمة إلى الشبكة. مهمة الشبكة هي توصيل الحزم من النقطة أ إلى النقطة ب.

ليس لدينا أيضًا مواقف تتحرك فيها العناوين داخل الشبكة، وهذا يحتاج إلى المراقبة. في العديد من التصميمات، يكون هذا مطلوبًا عادةً لدعم إمكانية تنقل الأجهزة الافتراضية. نحن لا نستخدم إمكانية تنقل الأجهزة الافتراضية في البنية التحتية الداخلية لشركة Yandex الكبيرة، وعلاوة على ذلك، نعتقد أنه حتى لو تم ذلك، فلا ينبغي أن يحدث مع دعم الشبكة. إذا كان هناك حاجة إلى القيام بذلك بالفعل، فيجب القيام به على مستوى المضيف، ودفع العناوين التي يمكن ترحيلها إلى التراكبات، حتى لا تلمس أو تجري الكثير من التغييرات الديناميكية على نظام التوجيه الخاص بالطبقة الأساسية نفسها (شبكة النقل) .

تقنية أخرى لا نستخدمها هي البث المتعدد. إذا كنت تريد، أستطيع أن أقول لك بالتفصيل لماذا. وهذا يجعل الحياة أسهل بكثير، لأنه إذا تعامل شخص ما معها ونظر إلى الشكل الدقيق لمستوى التحكم في البث المتعدد، في جميع التركيبات باستثناء أبسطها، فسيكون هذا بمثابة صداع كبير. والأكثر من ذلك، أنه من الصعب العثور على تطبيق مفتوح المصدر يعمل بشكل جيد، على سبيل المثال.

وأخيرًا، نقوم بتصميم شبكاتنا بحيث لا تتغير كثيرًا. يمكننا الاعتماد على حقيقة أن تدفق الأحداث الخارجية في نظام التوجيه صغير.

ما هي المشاكل التي تنشأ وما هي القيود التي يجب مراعاتها عند تطوير شبكة مركز البيانات؟ التكلفة بالطبع. قابلية التوسع، المستوى الذي نريد أن ننمو إليه. ضرورة التوسع دون توقف الخدمة. عرض النطاق الترددي، والتوافر. رؤية ما يحدث على الشبكة لأنظمة المراقبة والفرق التشغيلية. دعم الأتمتة - مرة أخرى، قدر الإمكان، حيث يمكن حل المهام المختلفة على مستويات مختلفة، بما في ذلك إدخال طبقات إضافية. حسنًا، لا [ربما] تعتمد على البائعين. على الرغم من أنه في فترات تاريخية مختلفة، اعتمادًا على القسم الذي تنظر إليه، كان تحقيق هذا الاستقلال أسهل أو أكثر صعوبة. إذا أخذنا مقطعًا عرضيًا من شرائح أجهزة الشبكة، فحتى وقت قريب كان الحديث عن الاستقلال عن البائعين أمرًا مشروطًا للغاية، إذا أردنا أيضًا شرائح ذات إنتاجية عالية.

ما هي الطوبولوجيا المنطقية التي سنستخدمها لبناء شبكتنا؟ سيكون هذا إغلاقًا متعدد المستويات. في الواقع، لا توجد بدائل حقيقية في الوقت الراهن. وتعد طوبولوجيا Clos جيدة جدًا، حتى عند مقارنتها بمختلف الطبولوجيا المتقدمة التي تعد أكثر في مجال الاهتمام الأكاديمي الآن، إذا كان لدينا محولات جذرية كبيرة.

كيف يتم بناء شبكة Clos متعددة المستويات بشكل تقريبي وما هي العناصر المختلفة التي تسمى فيها؟ بادئ ذي بدء، ارتفعت الريح، لتوجيه نفسك إلى أين الشمال، أين الجنوب، أين الشرق، أين الغرب. عادةً ما يتم إنشاء الشبكات من هذا النوع بواسطة أولئك الذين لديهم حركة مرور كبيرة جدًا بين الغرب والشرق. أما بالنسبة للعناصر المتبقية، في الأعلى يوجد مفتاح افتراضي تم تجميعه من مفاتيح أصغر. هذه هي الفكرة الرئيسية للبناء العودي لشبكات Clos. نحن نأخذ عناصر لها نوع ما من الجذر ونربطها بحيث يمكن اعتبار ما نحصل عليه بمثابة مفتاح ذو جذر أكبر. إذا كنت بحاجة إلى المزيد، يمكن تكرار الإجراء.

في الحالات، على سبيل المثال، مع إغلاق المستويين، عندما يكون من الممكن تحديد المكونات الرأسية بوضوح في الرسم التخطيطي الخاص بي، يُطلق عليها عادةً اسم المستويات. إذا أردنا بناء Clos بثلاثة مستويات من مفاتيح العمود الفقري (جميعها ليست مفاتيح حدودية أو مفاتيح ToR وتستخدم فقط للعبور)، فستبدو المستويات أكثر تعقيدًا؛ تبدو المستويات ذات المستويين هكذا تمامًا. نحن نطلق على مجموعة من ToR أو المفاتيح الورقية ومفاتيح العمود الفقري من المستوى الأول المرتبطة بها اسم Pod. مفاتيح العمود الفقري لمستوى العمود الفقري 1 في الجزء العلوي من الجراب هي الجزء العلوي من الجراب، أعلى الجراب. المفاتيح الموجودة في الجزء العلوي من المصنع بأكمله هي الطبقة العليا من المصنع، أعلى القماش.

بالطبع، السؤال الذي يطرح نفسه: لقد تم بناء شبكات Clos لبعض الوقت؛ والفكرة نفسها عمومًا تأتي من زمن الاتصالات الهاتفية الكلاسيكية، شبكات TDM. ربما ظهر شيء أفضل، ربما يمكن القيام بشيء أفضل؟ نعم و لا. نظرياً نعم، وعملياً في المستقبل القريب بالتأكيد لا. نظرًا لوجود عدد من الطبولوجيا المثيرة للاهتمام، يتم استخدام بعضها في الإنتاج، على سبيل المثال، يتم استخدام Dragonfly في تطبيقات HPC؛ هناك أيضًا طبولوجيا مثيرة للاهتمام مثل Xpander وFatClique وJellyfish. إذا نظرت إلى التقارير في مؤتمرات مثل SIGCOMM أو NSDI مؤخرًا، فيمكنك العثور على عدد كبير جدًا من الأعمال حول طبولوجيا بديلة لها خصائص أفضل (واحدة أو أخرى) من Clos.

لكن كل هذه الطبولوجيا لها خاصية واحدة مثيرة للاهتمام. فهو يمنع تنفيذها في شبكات مراكز البيانات، التي نحاول بناءها على أجهزة سلعية والتي تكلف أموالاً معقولة جدًا. في كل هذه الطبولوجيا البديلة، لا يمكن للأسف الوصول إلى معظم النطاق الترددي عبر أقصر المسارات. لذلك نفقد على الفور فرصة استخدام طائرة التحكم التقليدية.

ومن الناحية النظرية فإن حل المشكلة معروف. هذه، على سبيل المثال، تعديلات على حالة الارتباط باستخدام المسار الأقصر k، ولكن مرة أخرى، لا توجد مثل هذه البروتوكولات التي يمكن تنفيذها في الإنتاج ومتاحة على نطاق واسع على المعدات.

علاوة على ذلك، نظرًا لأن معظم السعة لا يمكن الوصول إليها عبر أقصر المسارات، فنحن بحاجة إلى تعديل أكثر من مجرد مستوى التحكم لتحديد كل تلك المسارات (وبالمناسبة، هذه حالة أكبر بكثير في مستوى التحكم). ما زلنا بحاجة إلى تعديل مستوى التوجيه، وكقاعدة عامة، هناك حاجة إلى ميزتين إضافيتين على الأقل. هذه هي القدرة على اتخاذ جميع القرارات المتعلقة بإعادة توجيه الحزم لمرة واحدة، على سبيل المثال، على المضيف. في الواقع، هذا هو توجيه المصدر، أحيانًا في الأدبيات المتعلقة بشبكات التوصيل البيني يُطلق عليه قرارات إعادة التوجيه الشاملة. والتوجيه التكيفي هو وظيفة نحتاجها لعناصر الشبكة، والتي تتلخص، على سبيل المثال، في حقيقة أننا نختار الخطوة التالية بناءً على معلومات حول أقل حمل في قائمة الانتظار. على سبيل المثال، هناك خيارات أخرى ممكنة.

وبالتالي فإن الاتجاه مثير للاهتمام، ولكن للأسف لا يمكننا تطبيقه الآن.

حسنًا، لقد استقرنا على طوبولوجيا كلوس المنطقية. كيف سنقوم بتحجيمها؟ دعونا نرى كيف يعمل وما يمكن القيام به.

يوجد في شبكة Clos معلمتان رئيسيتان يمكننا تغييرهما بطريقة ما والحصول على نتائج معينة: جذر العناصر وعدد المستويات في الشبكة. لدي رسم تخطيطي لكيفية تأثير كلاهما على الحجم. من الناحية المثالية، نحن نجمع بين الاثنين.

يمكن ملاحظة أن العرض النهائي لشبكة كلوس هو حاصل ضرب جميع مستويات مفاتيح العمود الفقري للجذر الجنوبي، وعدد الروابط الموجودة لدينا، وكيفية تفرعها. هذه هي الطريقة التي نقيس بها حجم الشبكة.

فيما يتعلق بالسعة، خاصة في محولات ToR، هناك خياران للقياس. إما أن نتمكن، مع الحفاظ على الهيكل العام، من استخدام روابط أسرع، أو يمكننا إضافة المزيد من المستويات.

إذا نظرت إلى النسخة الموسعة من شبكة Clos (في الزاوية اليمنى السفلية) ورجعت إلى هذه الصورة مع شبكة Clos أدناه...

... إذن هذه هي نفس الطوبولوجيا تمامًا، ولكن في هذه الشريحة يتم طيها بشكل أكثر إحكاما ويتم تركيب مستويات المصنع فوق بعضها البعض. نفس الشيء.

كيف يبدو قياس شبكة Clos بالأرقام؟ أقدم هنا بيانات حول الحد الأقصى للعرض الذي يمكن الحصول عليه للشبكة، والحد الأقصى لعدد الرفوف، أو مفاتيح ToR، أو مفاتيح الأوراق، إذا لم تكن موجودة في رفوف، فيمكننا الحصول عليها اعتمادًا على أساس المفاتيح التي نستخدمها لمستويات العمود الفقري، و كم عدد المستويات التي نستخدمها.

إليك عدد الرفوف التي يمكننا الحصول عليها، وعدد الخوادم، والمقدار التقريبي الذي يمكن أن يستهلكه كل هذا بناءً على 20 كيلووات لكل رف. لقد ذكرت سابقًا أننا نهدف إلى الوصول إلى حجم مجموعة يبلغ حوالي 100 ألف خادم.

يمكن ملاحظة أنه في هذا التصميم بأكمله هناك خياران ونصف مثيران للاهتمام. هناك خيار بطبقتين من الأشواك ومفاتيح ذات 64 منفذًا، وهو أقل قليلاً. ثم هناك خيارات مناسبة تمامًا للمفاتيح ذات 128 منفذًا (مع جذر 128) ذات مستويين، أو مفاتيح ذات جذر 32 بثلاثة مستويات. وفي جميع الحالات، حيث يوجد المزيد من الجذور والمزيد من الطبقات، يمكنك إنشاء شبكة كبيرة جدًا، ولكن إذا نظرت إلى الاستهلاك المتوقع، فعادةً ما يكون هناك جيجاوات. من الممكن مد كابل، لكن من غير المرجح أن نحصل على هذا القدر من الكهرباء في موقع واحد. إذا نظرت إلى الإحصائيات والبيانات العامة حول مراكز البيانات، يمكنك العثور على عدد قليل جدًا من مراكز البيانات التي تقدر طاقتها بأكثر من 150 ميجاوات. عادةً ما تكون المراكز الأكبر حجمًا هي مراكز البيانات، وهي عبارة عن عدة مراكز بيانات كبيرة تقع بالقرب من بعضها البعض.

هناك معلمة أخرى مهمة. إذا نظرت إلى العمود الأيسر، فسيتم إدراج النطاق الترددي القابل للاستخدام هناك. من السهل أن نرى أنه في شبكة Clos يتم استخدام جزء كبير من المنافذ لتوصيل المحولات ببعضها البعض. النطاق الترددي القابل للاستخدام، وهو شريط مفيد، هو شيء يمكن تقديمه للخارج نحو الخوادم. بطبيعة الحال، أنا أتحدث عن المنافذ الشرطية وعلى وجه التحديد عن النطاق. كقاعدة عامة، تكون الروابط داخل الشبكة أسرع من الروابط نحو الخوادم، ولكن لكل وحدة من عرض النطاق الترددي، بقدر ما يمكننا إرسالها إلى معدات الخادم لدينا، لا يزال هناك بعض النطاق الترددي داخل الشبكة نفسها. وكلما زاد عدد المستويات التي نصنعها، زادت التكلفة المحددة لتوفير هذا الشريط للخارج.

علاوة على ذلك، حتى هذا النطاق الإضافي ليس هو نفسه تمامًا. في حين أن الامتدادات قصيرة، يمكننا استخدام شيء مثل DAC (النحاس المتصل مباشرة، أي كابلات Twinax)، أو البصريات متعددة الأوضاع، والتي تكلف أموالًا معقولة أكثر أو أقل. بمجرد أن ننتقل إلى فترات أطول - كقاعدة عامة، هذه بصريات أحادية الوضع، وتزداد تكلفة هذا النطاق الترددي الإضافي بشكل ملحوظ.

ومرة أخرى، بالعودة إلى الشريحة السابقة، إذا قمنا بإنشاء شبكة Clos بدون اشتراك زائد، فمن السهل إلقاء نظرة على الرسم البياني، ومعرفة كيفية بناء الشبكة - بإضافة كل مستوى من مفاتيح العمود الفقري، نكرر الشريط بأكمله الذي كان في قاع. المستوى الإضافي - بالإضافة إلى نفس النطاق، ونفس عدد المنافذ الموجودة على المحولات كما كانت في المستوى السابق، ونفس عدد أجهزة الإرسال والاستقبال. ولذلك، فمن المستحسن للغاية تقليل عدد مستويات مفاتيح العمود الفقري.

بناءً على هذه الصورة، من الواضح أننا نريد حقًا البناء على شيء مثل المفاتيح ذات نصف قطر 128.

هنا، من حيث المبدأ، كل شيء هو نفس ما قلته للتو، وهذه شريحة للنظر فيها لاحقًا.

ما هي الخيارات المتاحة التي يمكننا اختيارها مثل هذه المفاتيح؟ إنها أخبار سارة للغاية بالنسبة لنا أنه يمكن الآن بناء مثل هذه الشبكات أخيرًا على مفاتيح أحادية الشريحة. وهذا رائع جدًا، فلديهم الكثير من الميزات الرائعة. على سبيل المثال، ليس لديهم أي بنية داخلية تقريبًا. وهذا يعني أنها تنكسر بسهولة أكبر. إنهم ينكسرون بشتى الطرق، لكن لحسن الحظ ينكسرون تمامًا. يوجد في الأجهزة المعيارية عدد كبير من الأخطاء (غير سارة للغاية)، عندما يبدو أنها تعمل من وجهة نظر الجيران ومستوى التحكم، ولكن، على سبيل المثال، فقد جزء من القماش ولا يعمل بكامل طاقتها. وحركة المرور إليها متوازنة بناءً على حقيقة أنها تعمل بكامل طاقتها، ويمكن أن نتعرض لأحمال زائدة.

أو، على سبيل المثال، تنشأ مشاكل مع لوحة الكترونية معززة، لأنه يوجد داخل الجهاز المعياري أيضا SerDes عالي السرعة - وهو معقد حقا في الداخل. إما أن تكون الإشارات بين عناصر إعادة التوجيه متزامنة أو غير متزامنة. بشكل عام، أي جهاز معياري منتج يتكون من عدد كبير من العناصر، كقاعدة عامة، يحتوي على نفس شبكة Clos داخل نفسه، ولكن من الصعب للغاية تشخيصه. في كثير من الأحيان يكون من الصعب حتى على البائع نفسه تشخيص المرض.

ولديها عدد كبير من سيناريوهات الفشل التي يتدهور فيها الجهاز، لكنه لا يخرج عن الهيكل بالكامل. نظرًا لأن شبكتنا كبيرة، يتم استخدام التوازن بين العناصر المتطابقة بشكل نشط، والشبكة منتظمة جدًا، أي أن المسار الذي يكون كل شيء فيه على ما يرام لا يختلف عن المسار الآخر، ومن المربح لنا أن نفقد بعضًا من بعضنا ببساطة الأجهزة من الطوبولوجيا من أن ينتهي بها الأمر في موقف يبدو أن بعضها يعمل، ولكن البعض الآخر لا يعمل.

الميزة الرائعة التالية للأجهزة ذات الشريحة الواحدة هي أنها تتطور بشكل أفضل وأسرع. كما أنها تميل إلى أن تكون لديها قدرة أفضل. إذا أخذنا الهياكل المجمعة الكبيرة الموجودة لدينا على شكل دائرة، فإن السعة لكل وحدة حامل للمنافذ بنفس السرعة تكون تقريبًا ضعف قدرة الأجهزة المعيارية. تعد الأجهزة المبنية على شريحة واحدة أرخص بشكل ملحوظ من الأجهزة المعيارية وتستهلك طاقة أقل.

ولكن، بالطبع، كل هذا لسبب ما، هناك أيضا عيوب. أولاً، يكون الجذر دائمًا أصغر من الأجهزة المعيارية. إذا تمكنا من الحصول على جهاز مبني على شريحة واحدة بها 128 منفذًا، فيمكننا الآن الحصول على جهاز معياري به عدة مئات من المنافذ دون أي مشاكل.

هذا حجم أصغر بشكل ملحوظ من جداول إعادة التوجيه، وعادةً ما يتعلق بكل ما يتعلق بقابلية التوسع في مستوى البيانات. المخازن المؤقتة الضحلة. وكقاعدة عامة، وظائف محدودة إلى حد ما. ولكن اتضح أنه إذا كنت تعرف هذه القيود وتحرص على تجاوزها في الوقت المناسب أو ببساطة أخذها في الاعتبار، فهذا ليس مخيفًا جدًا. حقيقة أن الجذر أصغر لم تعد مشكلة على الأجهزة ذات الجذر 128 التي ظهرت مؤخرًا؛ يمكننا البناء في طبقتين من الأشواك. ولكن لا يزال من المستحيل بناء أي شيء أقل من اثنين يثير اهتمامنا. بمستوى واحد يتم الحصول على مجموعات صغيرة جدًا. حتى تصاميمنا ومتطلباتنا السابقة لا تزال تتجاوزها.

في الواقع، إذا أصبح الحل فجأة على حافة الهاوية، فلا تزال هناك طريقة للتوسع. نظرًا لأن المستوى الأخير (أو الأول) الذي يتم فيه توصيل الخوادم هو محولات ToR أو مفاتيح الأوراق، فليس من الضروري توصيل حامل واحد بها. لذلك، إذا كان الحل أقل بمقدار النصف تقريبًا، فيمكنك التفكير ببساطة في استخدام مفتاح ذو جذر كبير في المستوى الأدنى وتوصيل، على سبيل المثال، رفوفين أو ثلاثة رفوف في مفتاح واحد. يعد هذا أيضًا خيارًا، وله تكاليفه، ولكنه يعمل بشكل جيد ويمكن أن يكون حلاً جيدًا عندما تحتاج إلى الوصول إلى ضعف الحجم تقريبًا.

لتلخيص ذلك، نحن نبني على طوبولوجيا ذات مستويين من الأشواك، مع ثماني طبقات من المصنع.

ماذا سيحدث للفيزياء؟ حسابات بسيطة جدا. إذا كان لدينا مستويين من العمود الفقري، فلدينا ثلاثة مستويات فقط من المحولات، ونتوقع أنه سيكون هناك ثلاثة قطاعات كبلية في الشبكة: من الخوادم إلى المحولات الورقية، إلى العمود الفقري 1، إلى العمود الفقري 2. الخيارات التي يمكننا القيام بها الاستخدام هو - Twinax، Multimode، Single Mode. وهنا نحتاج إلى النظر في الشريط المتاح، وكم سيكلف، وما هي الأبعاد المادية، وما هي الامتدادات التي يمكننا تغطيتها، وكيف سنقوم بالترقية.

من حيث التكلفة، كل شيء يمكن أن يصطف. تعد Twinaxes أرخص بكثير من البصريات النشطة، وأرخص من أجهزة الإرسال والاستقبال متعددة الأوضاع، إذا كنت تأخذها لكل رحلة من النهاية، فهي أرخص إلى حد ما من منفذ تبديل 100 جيجابت. ويرجى ملاحظة أنها أقل تكلفة من البصريات أحادية الوضع، لأنه في الرحلات الجوية التي تتطلب الوضع الفردي، في مراكز البيانات لعدد من الأسباب، من المنطقي استخدام CWDM، في حين أن الوضع الفردي الموازي (PSM) ليس مناسبًا جدًا للعمل مع، يتم الحصول على عبوات كبيرة جدًا من الألياف، وإذا ركزنا على هذه التقنيات، نحصل على التسلسل الهرمي للسعر التالي تقريبًا.

ملاحظة أخرى: لسوء الحظ، ليس من الممكن استخدام منافذ متعددة الأوضاع مفككة من 100 إلى 4x25. نظرًا لميزات تصميم أجهزة الإرسال والاستقبال SFP28، فهي ليست أرخص بكثير من 28 جيجابت QSFP100. وهذا التفكيك للوضع المتعدد لا يعمل بشكل جيد.

هناك قيد آخر يتمثل في أنه نظرًا لحجم مجموعات الحوسبة وعدد الخوادم، فقد تبين أن مراكز البيانات لدينا كبيرة الحجم فعليًا. هذا يعني أنه يجب القيام برحلة واحدة على الأقل باستخدام جهاز واحد. مرة أخرى، نظرًا للحجم الفعلي للبودات، لن يكون من الممكن تشغيل امتدادين من Twinax (الكابلات النحاسية).

ونتيجة لذلك، إذا قمنا بتحسين السعر وأخذنا في الاعتبار هندسة هذا التصميم، فسنحصل على نطاق واحد من twinax، ونطاق واحد من الأوضاع المتعددة، ونطاق واحد من الوضع الفردي باستخدام CWDM. ويأخذ هذا في الاعتبار مسارات الترقية المحتملة.

هذا ما يبدو عليه الأمر مؤخرًا، إلى أين نتجه وما هو ممكن. من الواضح، على الأقل، كيفية التحرك نحو 50 جيجابت SerDes لكل من الوضع المتعدد والوضع الفردي. علاوة على ذلك، إذا نظرت إلى ما هو موجود في أجهزة الإرسال والاستقبال أحادية الوضع الآن وفي المستقبل لـ 400G، فغالبًا حتى عندما يصل 50G SerDes من الجانب الكهربائي، يمكن أن تذهب 100 جيجابت في الثانية لكل حارة بالفعل إلى البصريات. لذلك، من الممكن تمامًا أنه بدلاً من الانتقال إلى 50، سيكون هناك انتقال إلى 100 Gigabit SerDes و100 Gbps لكل حارة، لأنه وفقًا لوعود العديد من البائعين، من المتوقع توفرها قريبًا جدًا. يبدو أن الفترة التي كانت فيها 50G SerDes هي الأسرع، لن تكون طويلة جدًا، لأن النسخ الأولى من 100G SerDes سيتم طرحها في العام المقبل تقريبًا. وبعد مرور بعض الوقت، من المحتمل أن تستحق أموالاً معقولة.

فارق بسيط آخر حول اختيار الفيزياء. من حيث المبدأ، يمكننا بالفعل استخدام 400 أو 200 منفذ جيجابت باستخدام 50G SerDes. ولكن اتضح أن هذا ليس له معنى كبير، لأننا، كما قلت سابقًا، نريد جذرًا كبيرًا إلى حد ما على المفاتيح، في حدود المعقول بالطبع. نريد 128. وإذا كانت لدينا سعة شريحة محدودة وقمنا بزيادة سرعة الارتباط، فإن الجذر يتناقص بشكل طبيعي، ولا توجد معجزات.

ويمكننا زيادة السعة الإجمالية باستخدام الطائرات، ولا توجد تكاليف خاصة، ويمكننا جمع عدد الطائرات. وإذا فقدنا الجذر، فسيتعين علينا تقديم مستوى إضافي، لذلك في الوضع الحالي، مع الحد الأقصى الحالي للسعة المتاحة لكل شريحة، اتضح أنه من الأكثر كفاءة استخدام منافذ 100 جيجابت، لأنها تسمح لك للحصول على جذر أكبر.

والسؤال التالي هو كيف يتم تنظيم الفيزياء، ولكن من وجهة نظر البنية التحتية للكابلات. اتضح أنه تم تنظيمه بطريقة مضحكة إلى حد ما. الكابلات بين المفاتيح الورقية والأشواك من المستوى الأول - لا توجد روابط كثيرة هناك، كل شيء مبني ببساطة نسبيًا. لكن إذا أخذنا مستوى واحدًا، فإن ما يحدث في الداخل هو أننا بحاجة إلى ربط جميع أشواك المستوى الأول بجميع أشواك المستوى الثاني.

بالإضافة إلى ذلك، كقاعدة عامة، هناك بعض الرغبات حول الشكل الذي يجب أن يبدو عليه داخل مركز البيانات. على سبيل المثال، أردنا حقًا دمج الكابلات في حزمة وسحبها بحيث تدخل لوحة التصحيح عالية الكثافة بالكامل في لوحة توصيل واحدة، بحيث لا تكون هناك حديقة حيوان من حيث الأطوال. تمكنا من حل هذه المشكلة. إذا نظرت في البداية إلى الهيكل المنطقي، يمكنك أن ترى أن المستويات مستقلة، ويمكن بناء كل مستوى بمفرده. ولكن عندما نضيف مثل هذه الحزمة ونريد سحب لوحة التصحيح بأكملها إلى لوحة التصحيح، يتعين علينا مزج مستويات مختلفة داخل حزمة واحدة وإدخال بنية وسيطة في شكل اتصالات متقاطعة بصرية لإعادة تجميعها من كيفية تجميعها على شريحة واحدة، في كيفية جمعها على شريحة أخرى. بفضل هذا، نحصل على ميزة لطيفة: كل التبديل المعقد لا يتجاوز الرفوف. عندما تحتاج إلى تشابك شيء ما بقوة شديدة، "فتح الطائرات"، كما يطلق عليه أحيانًا في شبكات Clos، فكل ذلك يتركز داخل رف واحد. ليس لدينا تفكيك كبير، وصولا إلى الروابط الفردية، والتبديل بين الرفوف.

هكذا يبدو الأمر من وجهة نظر التنظيم المنطقي للبنية التحتية للكابل. في الصورة على اليسار، الكتل متعددة الألوان تصور كتل مفاتيح العمود الفقري من المستوى الأول، كل منها ثماني قطع وأربع حزم من الكابلات القادمة منها، والتي تذهب وتتقاطع مع الحزم القادمة من كتل مفاتيح العمود الفقري-2 .

المربعات الصغيرة تشير إلى التقاطعات. في الجزء العلوي الأيسر يوجد تفصيل لكل تقاطع من هذا القبيل، وهو في الواقع وحدة توصيل متقاطع بمنفذ 512 × 512 تقوم بإعادة تعبئة الكابلات بحيث تأتي بالكامل في حامل واحد، حيث يوجد مستوى عمود فقري واحد فقط. وعلى اليمين، يعد مسح هذه الصورة أكثر تفصيلاً قليلاً فيما يتعلق بالعديد من الكبسولات على مستوى العمود الفقري 2، وكيفية تعبئتها في اتصال متقاطع، وكيف يصل الأمر إلى مستوى العمود الفقري 1.

هذا هو ما يبدو عليه الأمر. حامل العمود الفقري 2 الذي لم يتم تجميعه بالكامل (على اليسار) وحامل التوصيل المتقاطع. لسوء الحظ، ليس هناك الكثير لرؤيته هناك. يتم نشر هذه البنية بأكملها الآن في أحد مراكز البيانات الكبيرة لدينا والتي يتم توسيعها. هذا عمل قيد التنفيذ، وسيبدو أجمل، وسيتم ملؤه بشكل أفضل.

سؤال مهم: لقد اخترنا الطوبولوجيا المنطقية وقمنا ببناء الفيزياء. ماذا سيحدث لطائرة التحكم؟ من المعروف جيدًا من خلال تجربة التشغيل، أن هناك عددًا من التقارير التي تربط بروتوكولات الحالة بأنها جيدة، ومن دواعي سروري العمل معهم، ولكن لسوء الحظ، فهي لا تتوسع بشكل جيد في طوبولوجيا متصلة بكثافة. وهناك عامل رئيسي واحد يمنع ذلك - وهذه هي الطريقة التي يعمل بها الفيضان في بروتوكولات حالة الارتباط. إذا أخذت خوارزمية الغمر ونظرت إلى كيفية هيكلة شبكتنا، يمكنك أن ترى أنه سيكون هناك انتشار كبير جدًا في كل خطوة، وسوف يؤدي ذلك ببساطة إلى إغراق مستوى التحكم بالتحديثات. على وجه التحديد، تختلط هذه الهياكل بشكل سيئ للغاية مع خوارزمية الغمر التقليدية في بروتوكولات حالة الارتباط.

والخيار هو استخدام BGP. كيفية تحضيره بشكل صحيح موصوفة في RFC 7938 حول استخدام BGP في مراكز البيانات الكبيرة. الأفكار الأساسية بسيطة: الحد الأدنى لعدد البادئات لكل مضيف والحد الأدنى بشكل عام لعدد البادئات على الشبكة، واستخدام التجميع إن أمكن، وقمع تتبع المسار. نريد توزيعًا دقيقًا للغاية ومراقبًا للغاية للتحديثات، وهو ما يسمى Valley Free. نريد نشر التحديثات بمجرد مرورها عبر الشبكة. إذا نشأت من الأسفل، فإنها ترتفع، ولا تتكشف أكثر من مرة. لا ينبغي أن يكون هناك متعرج. متعرجة سيئة للغاية.

للقيام بذلك، نستخدم تصميمًا بسيطًا بما يكفي لاستخدام آليات BGP الأساسية. وهذا يعني أننا نستخدم eBGP الذي يعمل على الارتباط المحلي، ويتم تعيين الأنظمة المستقلة على النحو التالي: نظام مستقل على ToR، ونظام مستقل على الكتلة الكاملة لمفاتيح العمود الفقري 1 من Pod واحد، ونظام مستقل عام على الجزء العلوي بأكمله من القماش. ليس من الصعب أن ننظر ونرى أنه حتى السلوك الطبيعي لـ BGP يمنحنا توزيع التحديثات التي نريدها.

وبطبيعة الحال، يجب تصميم العنونة وتجميع العناوين بحيث تكون متوافقة مع طريقة بناء التوجيه، بحيث تضمن استقرار مستوى التحكم. ترتبط عنونة L3 في النقل بالطوبولوجيا، لأنه بدونها يكون من المستحيل تحقيق التجميع؛ وبدون ذلك، سوف تتسلل العناوين الفردية إلى نظام التوجيه. وهناك شيء آخر هو أن التجميع، لسوء الحظ، لا يمتزج جيدًا مع المسارات المتعددة، لأنه عندما يكون لدينا مسارات متعددة ولدينا تجميع، كل شيء على ما يرام، وعندما تكون الشبكة بأكملها سليمة، لا توجد أعطال فيها. لسوء الحظ، بمجرد ظهور حالات الفشل في الشبكة وفقدان تناسق الهيكل، يمكننا أن نصل إلى النقطة التي تم الإعلان عن الوحدة منها، والتي لا يمكننا المضي قدمًا إلى حيث نحتاج إلى الذهاب إليها. لذلك، من الأفضل التجميع حيث لا يوجد المزيد من المسارات المتعددة، في حالتنا هذه هي مفاتيح ToR.

في الواقع، من الممكن التجميع، ولكن بعناية. إذا تمكنا من القيام بالتصنيف المتحكم فيه عند حدوث فشل في الشبكة. لكن هذه مهمة صعبة للغاية، حتى أننا تساءلنا عما إذا كان من الممكن القيام بذلك، وما إذا كان من الممكن إضافة أتمتة إضافية، وأجهزة حالة محدودة يمكنها ركلة BGP بشكل صحيح للحصول على السلوك المطلوب. لسوء الحظ، معالجة الحالات الزاوية غير واضحة ومعقدة للغاية، ولا يتم حل هذه المهمة بشكل جيد عن طريق إرفاق مرفقات خارجية بـ BGP.

لقد تم إنجاز عمل مثير للاهتمام للغاية في هذا الصدد في إطار بروتوكول RIFT، والذي سيتم مناقشته في التقرير التالي.

شيء آخر مهم هو كيفية قياس مستويات البيانات في الهياكل الكثيفة، حيث لدينا عدد كبير من المسارات البديلة. في هذه الحالة، يتم استخدام العديد من بنيات البيانات الإضافية: مجموعات ECMP، والتي بدورها تصف مجموعات Next Hop.

في شبكة تعمل بشكل طبيعي، دون فشل، عندما نصعد إلى طوبولوجيا Clos، يكفي استخدام مجموعة واحدة فقط، لأن كل ما هو غير محلي موصوف افتراضيًا، يمكننا الصعود. عندما ننتقل من الأعلى إلى الأسفل إلى الجنوب، فإن جميع المسارات ليست ECMP، بل هي مسارات مسار واحد. كل شيء على ما يرام. المشكلة هي أن خصوصية طوبولوجيا Clos الكلاسيكية هي أننا إذا نظرنا إلى الجزء العلوي من القماش، في أي عنصر، هناك مسار واحد فقط لأي عنصر أدناه. في حالة حدوث فشل على طول هذا المسار، يصبح هذا العنصر المعين الموجود في الجزء العلوي من المصنع غير صالح على وجه التحديد لتلك البادئات التي تقع خلف المسار المقطوع. ولكن بالنسبة للبقية فهو صالح، وعلينا تحليل مجموعات ECMP وإدخال حالة جديدة.

كيف تبدو قابلية التوسع في مستوى البيانات على الأجهزة الحديثة؟ إذا قمنا بـ LPM (أطول تطابق للبادئة)، فسيكون كل شيء جيدًا جدًا، أكثر من 100 ألف بادئة. إذا كنا نتحدث عن مجموعات Next Hop، فكل شيء أسوأ، 2-4 آلاف. إذا كنا نتحدث عن جدول يحتوي على وصف للقفزات التالية (أو التقاربات)، فهذا يتراوح من 16 كيلو إلى 64 كيلو بايت. وهذا يمكن أن يصبح مشكلة. وهنا نأتي إلى استطراد مثير للاهتمام: ماذا حدث لـ MPLS في مراكز البيانات؟ من حيث المبدأ، أردنا أن نفعل ذلك.

حدث شيئين. لقد أجرينا تجزئة دقيقة على الأجهزة المضيفة، ولم نعد بحاجة إلى القيام بذلك على الشبكة. لم يكن الأمر جيدًا جدًا مع الدعم المقدم من بائعين مختلفين، بل وأكثر من ذلك مع التطبيقات المفتوحة على المربعات البيضاء مع MPLS. وMPLS، على الأقل تطبيقاتها التقليدية، لسوء الحظ، يتم دمجها بشكل سيء للغاية مع ECMP. وهذا هو السبب.

هذا هو الشكل الذي تبدو عليه بنية إعادة توجيه ECMP لـ IP. يمكن لعدد كبير من البادئات استخدام نفس المجموعة ونفس كتلة Next Hops (أو التقاربات، قد يتم تسميتها بشكل مختلف في وثائق مختلفة لأجهزة مختلفة). النقطة المهمة هي أن هذا يوصف بأنه المنفذ الصادر وما يجب إعادة كتابة عنوان MAC إليه للوصول إلى الخطوة التالية الصحيحة. بالنسبة لـ IP، يبدو كل شيء بسيطًا، يمكنك استخدام عدد كبير جدًا من البادئات لنفس المجموعة، ونفس كتلة Next Hops.

تتضمن بنية MPLS الكلاسيكية أنه، اعتمادًا على الواجهة الصادرة، يمكن إعادة كتابة الملصق إلى قيم مختلفة. لذلك، نحتاج إلى الاحتفاظ بمجموعة وكتلة Next Hops لكل تسمية إدخال. وهذا، للأسف، لا يتسع.

من السهل أن نرى أننا في تصميمنا كنا بحاجة إلى حوالي 4000 محول ToR، وكان الحد الأقصى للعرض 64 مسارًا ECMP، إذا ابتعدنا عن العمود الفقري 1 نحو العمود الفقري 2. بالكاد نصل إلى جدول واحد من مجموعات ECMP، إذا اختفت بادئة واحدة فقط مع ToR، ولا ندخل إلى جدول Next Hops على الإطلاق.

ليس الأمر كله ميؤوسًا منه، لأن البنى مثل Segment Routing تتضمن تسميات عالمية. رسميًا، سيكون من الممكن طي كل كتل القفزات التالية هذه مرة أخرى. للقيام بذلك، تحتاج إلى عملية نوع بدل: خذ تسمية وأعد كتابتها إلى نفس التسمية دون قيمة محددة. ولكن لسوء الحظ، هذا ليس موجودا جدا في التطبيقات المتاحة.

وأخيرًا، نحتاج إلى جلب حركة المرور الخارجية إلى مركز البيانات. كيف افعلها؟ في السابق، تم إدخال حركة المرور إلى شبكة Clos من الأعلى. أي أنه كانت هناك أجهزة توجيه حافة متصلة بجميع الأجهزة في الجزء العلوي من القماش. يعمل هذا الحل بشكل جيد على الأحجام الصغيرة والمتوسطة. لسوء الحظ، من أجل إرسال حركة المرور بشكل متماثل إلى الشبكة بأكملها بهذه الطريقة، نحتاج إلى الوصول في وقت واحد إلى جميع عناصر الجزء العلوي من النسيج، وعندما يكون هناك أكثر من مائة منهم، يتبين أننا نحتاج أيضًا إلى عدد كبير من العناصر الجذر على أجهزة التوجيه الحافة. بشكل عام، هذا يكلف أموالاً، لأن أجهزة التوجيه الطرفية أكثر وظيفية، وستكون المنافذ الموجودة عليها أكثر تكلفة، والتصميم ليس جميلًا جدًا.

خيار آخر هو بدء مثل هذه الحركة من الأسفل. من السهل التحقق من أن طوبولوجيا Clos مبنية بطريقة بحيث يتم توزيع حركة المرور القادمة من الأسفل، أي من جانب ToR، بالتساوي بين المستويات في جميع أنحاء الجزء العلوي من النسيج بأكمله في تكرارين، مما يؤدي إلى تحميل الشبكة بأكملها. لذلك، نقدم نوعًا خاصًا من البودات، وهو Edge Pod، الذي يوفر إمكانية الاتصال الخارجي.

هناك خيار آخر. وهذا ما يفعله الفيسبوك، على سبيل المثال. يسمونه مجمع النسيج أو HGRID. يتم تقديم مستوى إضافي للعمود الفقري لربط مراكز بيانات متعددة. هذا التصميم ممكن إذا لم يكن لدينا وظائف إضافية أو تغييرات تغليف في الواجهات. إذا كانت نقاط اتصال إضافية، فمن الصعب. عادة، هناك المزيد من الوظائف ونوع من الغشاء الذي يفصل بين أجزاء مختلفة من مركز البيانات. ليس من المنطقي جعل مثل هذا الغشاء كبيرًا، ولكن إذا كانت هناك حاجة إليه حقًا لسبب ما، فمن المنطقي التفكير في إمكانية إزالته، وجعله واسعًا قدر الإمكان ونقله إلى المضيفين. يتم ذلك، على سبيل المثال، من قبل العديد من مشغلي السحابة. لديهم تراكبات، يبدأون من المضيفين.

ما هي فرص التطوير التي نراها؟ أولاً، تحسين الدعم لخط أنابيب CI/CD. نريد أن نطير بالطريقة التي نختبرها ونختبر الطريقة التي نطير بها. هذا لا يعمل بشكل جيد للغاية، لأن البنية التحتية كبيرة ومن المستحيل تكرارها للاختبارات. أنت بحاجة إلى فهم كيفية إدخال عناصر الاختبار في البنية التحتية للإنتاج دون إسقاطها.

إن الأدوات الأفضل والمراقبة الأفضل لا تكون أبدًا غير ضرورية على الإطلاق. المسألة برمتها هي توازن الجهد والعودة. إذا كان بإمكانك إضافته بجهد معقول، فهذا جيد جدًا.

أنظمة التشغيل المفتوحة لأجهزة الشبكة. بروتوكولات أفضل وأنظمة توجيه أفضل، مثل RIFT. هناك حاجة أيضًا إلى البحث في استخدام مخططات أفضل للتحكم في الازدحام وربما تقديم دعم RDMA، على الأقل في بعض النقاط، داخل المجموعة.

وبالنظر إلى المستقبل، نحتاج إلى طبولوجيا متقدمة وربما شبكات تستخدم حملًا أقل. من بين الأشياء الجديدة، ظهرت مؤخرًا منشورات حول تقنية النسيج الخاصة بـ HPC Cray Slingshot، والتي تعتمد على سلعة Ethernet، ولكن مع خيار استخدام رؤوس أقصر بكثير. ونتيجة لذلك، يتم تقليل النفقات العامة.

يجب أن يبقى كل شيء بسيطًا قدر الإمكان، ولكن ليس أبسط. التعقيد هو عدو قابلية التوسع. البساطة والهياكل العادية هي أصدقائنا. إذا كان بإمكانك التوسع في مكان ما، فافعل ذلك. وبشكل عام، من الرائع أن تشارك في تقنيات الشبكات الآن. هناك الكثير من الأشياء المثيرة للاهتمام تحدث. شكرًا لك.

المصدر: www.habr.com