تحتوي مراكز البيانات الحديثة على مئات الأجهزة النشطة التي تغطيها أنواع مختلفة من المراقبة. ولكن حتى المهندس المثالي مع المراقبة المثالية في متناول اليد سيكون قادرًا على الاستجابة بشكل صحيح لفشل الشبكة في بضع دقائق فقط. في تقرير في مؤتمر Next Hop 2020 ، قدمت منهجية تصميم شبكة مركز البيانات التي تتميز بميزة فريدة - يعالج مركز البيانات نفسه في أجزاء من الثانية. بتعبير أدق ، يعمل المهندس على حل المشكلة بهدوء ، في حين أن الخدمات ببساطة لا تلاحظ ذلك.
بالنسبة للعديد من مهندسي الشبكات ، تبدأ شبكة مركز البيانات ، بالطبع ، مع ToR ، بمفتاح في الرف. تحتوي ToR عادةً على نوعين من الروابط. يذهب الصغار إلى الخوادم ، بينما يذهب الآخرون - عدد مرات أكثر منهم - نحو العمود الفقري من المستوى الأول ، أي إلى روابطه الصاعدة. عادةً ما تُعتبر الروابط الصاعدة متساوية ، وتتم موازنة حركة المرور بين الارتباطات الصاعدة استنادًا إلى التجزئة المكونة من 5 مجموعات ، والتي تتضمن proto و src_ip و dst_ip و src_port و dst_port. لا يوجد اي مفاجئات هنا.
بعد ذلك ، كيف تبدو بنية الطائرات؟ العمود الفقري من المستوى الأول غير متصل ببعضه البعض ، لكنهم متصلون عن طريق superspins. سيكون الحرف X مسؤولاً عن superspins ، فهو يشبه الاتصال المتبادل تقريبًا.
ومن الواضح ، من ناحية أخرى ، أن توري مرتبطة بجميع الأشواك من المستوى الأول. ما هو المهم في هذه الصورة؟ إذا كان لدينا تفاعل داخل الحامل ، فإن التفاعل ، بالطبع ، يمر عبر ToR. إذا استمر التفاعل داخل الوحدة النمطية ، فإن التفاعل يمر عبر أشواك المستوى الأول. إذا كان التفاعل متعدد الوحدات - كما هو الحال هنا ، ToR 1 و ToR 2 - فسوف يمر التفاعل عبر أشواك المستويين الأول والثاني.
من الناحية النظرية ، فإن مثل هذه الهندسة قابلة للتطوير بسهولة. إذا كانت لدينا سعة منفذ ، واحتياطي مساحة في مركز البيانات وألياف مُعدة مسبقًا ، فيمكن دائمًا زيادة عدد الطائرات ، وبالتالي زيادة السعة الإجمالية للنظام. على الورق ، من السهل جدًا القيام بذلك. سيكون الأمر كذلك في الحياة الواقعية. لكن قصة اليوم لا تتعلق بذلك.
أريد استخلاص الاستنتاجات الصحيحة. لدينا العديد من المسارات داخل مركز البيانات. هم مستقلون بشكل مشروط. طريقة واحدة داخل مركز البيانات ممكنة فقط داخل ToR. داخل الوحدة ، لدينا نفس عدد المسارات مثل عدد المستويات. عدد المسارات بين الوحدات يساوي حاصل ضرب عدد المستويات وعدد الدورات الفائقة في كل مستوى. لتوضيح الأمر ، لتشعر بالمقياس ، سأقدم الأرقام الصالحة لأحد مراكز بيانات Yandex.
هناك ثماني طائرات ، كل طائرة بها 32 دورانًا فائقًا. نتيجة لذلك ، اتضح أن هناك ثمانية مسارات داخل الوحدة النمطية ، ومع التفاعل بين الوحدات يوجد بالفعل 256 مسارًا.
بمعنى ، إذا كنا نطور كتابًا للطبخ ، نحاول أن نتعلم كيفية بناء مراكز بيانات تتسامح مع الأخطاء وتعالج نفسها ، فإن البنية المستوية هي الاختيار الصحيح. يسمح لك بحل مشكلة التحجيم ، وهو سهل نظريًا. هناك العديد من المسارات المستقلة. يبقى السؤال: كيف تنجو مثل هذه العمارة من الفشل؟ هناك حوادث مختلفة. وسنناقش هذا الآن.
دع أحد دبابيسنا الفائقة يمرض. هنا عدت إلى هندسة طائرتين. سنلتزم بها كمثال لأنه سيكون من الأسهل رؤية ما يحدث هنا بأجزاء متحركة أقل. دع X11 يمرض. كيف سيؤثر ذلك على الخدمات التي تعيش داخل مراكز البيانات؟ يعتمد الكثير على كيفية ظهور الفشل في الواقع.
إذا كان الفشل جيدًا ، يتم اكتشافه على مستوى أتمتة نفس BFD ، فالأتمتة تضع مفاصل المشكلة وتعزل المشكلة بسعادة ، ثم كل شيء على ما يرام. لدينا العديد من المسارات ، ويتم إعادة توجيه حركة المرور على الفور إلى طرق بديلة ، ولن تلاحظ الخدمات أي شيء. هذا سيناريو جيد
السيناريو السيئ هو إذا كانت لدينا خسائر مستمرة ، ولا تلاحظ الأتمتة المشكلة. لفهم كيفية تأثير ذلك على التطبيق ، سيتعين علينا قضاء بعض الوقت في مناقشة كيفية عمل بروتوكول TCP.
آمل ألا أصدم أي شخص بهذه المعلومات: TCP هو بروتوكول مصافحة. وهذا يعني ، في أبسط الحالات ، أن المرسل يرسل حزمتين ، ويتلقى ack تراكميًا عليهما: "لقد تلقيت حزمتين."
بعد ذلك ، سيرسل حزمتين أخريين ، وسيتكرر الموقف. أعتذر مقدما عن بعض التبسيط. هذا السيناريو صحيح إذا كانت النافذة (عدد الحزم في الرحلة) هي اثنين. بالطبع ، هذا ليس بالضرورة هو الحال بشكل عام. لكن سياق إعادة توجيه الحزمة لا يتأثر بحجم النافذة.
ماذا يحدث إذا فقدنا الحزمة 3؟ في هذه الحالة ، سيتلقى المستلم الحزم 1 و 2 و 4. وسيبلغ المرسل صراحةً باستخدام خيار SACK: "أتعلم ، ثلاثة أتوا ، لكن الوسط فقد". يقول "أك 2 ، كيس 4".
يكرر المرسل في هذه اللحظة الحزمة المفقودة تمامًا دون أي مشاكل.
ولكن في حالة فقد الحزمة الأخيرة في النافذة ، سيبدو الوضع مختلفًا تمامًا.
يتلقى المستلم الحزم الثلاث الأولى ويبدأ أولاً في الانتظار. بفضل بعض التحسينات في مكدس TCP في Linux kernel ، سينتظر الحزمة المزدوجة ، ما لم يكن هناك إشارة صريحة في العلامات إلى أن هذه هي الحزمة الأخيرة أو شيء من هذا القبيل. سينتظر حتى تنتهي مهلة ACK المؤجلة ثم يرسل إقرارًا بالحزم الثلاثة الأولى. ولكن الآن المرسل سينتظر. لا يعرف ما إذا كانت الحزمة الرابعة قد ضاعت أم أنها على وشك الوصول. ولكي لا تفرط الشبكة في التحميل ، ستحاول انتظار الإشارة الصريحة إلى فقدان الحزمة ، أو انتهاء مهلة RTO.
ما هي مهلة RTO؟ هذا هو الحد الأقصى من RTT المحسوب بواسطة مكدس TCP وبعض الثوابت. ما هو هذا الثابت ، سنناقش الآن.
ولكن من المهم أنه إذا لم يحالفنا الحظ مرة أخرى وفقدت الحزمة الرابعة مرة أخرى ، فإن RTO يتضاعف. أي أن كل محاولة فاشلة هي مضاعفة المهلة.
لنرى الآن ما تساوي هذه القاعدة. بشكل افتراضي ، الحد الأدنى من RTO هو 200 مللي ثانية. هذا هو الحد الأدنى من RTO لحزم البيانات. لحزم SYN مختلفة ، 1 ثانية. كما ترى ، حتى المحاولة الأولى لإعادة إرسال الحزم ستستغرق 100 مرة أكثر من RTT داخل مركز البيانات.
الآن عد إلى السيناريو الخاص بنا. ما الذي يحدث بالخدمة؟ تبدأ الخدمة في فقدان الحزم. دع الخدمة تكون محظوظة في البداية وتفقد شيئًا ما في منتصف النافذة ، ثم تتلقى SACK ، وتعيد إرسال الحزم المفقودة.
ولكن إذا تكرر الحظ السيئ ، فعندئذ يكون لدينا RTO. ما هو المهم هنا؟ نعم ، لدينا الكثير من المسارات في الشبكة. لكن حركة مرور TCP لاتصال TCP معين ستستمر في المرور عبر نفس المكدس المعطل. لا يؤدي فقدان الحزمة ، بشرط ألا يخرج هذا السحر X11 من تلقاء نفسه ، إلى تدفق حركة المرور إلى مناطق لا تمثل مشكلة. نحن نحاول تسليم حزمة من خلال نفس المكدس المكسور. يؤدي هذا إلى فشل متتالي: مركز البيانات عبارة عن مجموعة من التطبيقات المتفاعلة ، وتبدأ بعض اتصالات TCP لجميع هذه التطبيقات في التدهور - لأن الدوران الفائق يؤثر على جميع التطبيقات الموجودة داخل مركز البيانات. كما في المثل: إذا لم ترتدي جوادًا ، فإن الحصان يعرج ؛ الحصان يعرج - لم يتم تسليم التقرير ؛ لم يتم تسليم الرسالة - لقد خسروا الحرب. هنا فقط ينتقل العد لثوانٍ من لحظة حدوث المشكلة إلى مرحلة التدهور التي تبدأ الخدمات في الشعور بها. هذا يعني أن المستخدمين قد لا يتلقون شيئًا في مكان ما.
هناك نوعان من الحلول الكلاسيكية التي تكمل بعضها البعض. الأول هو الخدمات التي تحاول وضع القش وحل المشكلة مثل هذا: "دعونا نعدل شيئًا ما في مكدس TCP. ودعنا نحدد مهلات على مستوى التطبيق أو جلسات TCP طويلة الأمد مع فحوصات صحية داخلية. تكمن المشكلة في أن مثل هذه الحلول: أ) لا تتسع على الإطلاق ؛ ب) اختبار سيئ للغاية. أي ، حتى إذا قامت الخدمة عن طريق الخطأ بتكوين مكدس TCP بحيث يصبح أفضل ، أولاً ، من غير المحتمل أن يكون هذا قابلاً للتطبيق على جميع التطبيقات وجميع مراكز البيانات ، وثانيًا ، على الأرجح ، لن تفهم ما تم تنفيذه بشكل صحيح وماذا لا. أي أنها تعمل ، لكنها تعمل بشكل سيئ ولا تتسع. وإذا كانت هناك مشكلة في الشبكة ، فمن يقع اللوم؟ بالطبع NOC. ماذا تفعل NOC؟
تعتقد العديد من الخدمات أن العمل في NOC يسير على هذا النحو. لكن لأكون صادقًا ، ليس فقط.
تشارك NOC في المخطط الكلاسيكي في تطوير العديد من عمليات المراقبة. هذه هي كل من مراقبة الصندوق الأسود ومراقبة الصندوق الأبيض. حول مثال مراقبة الصندوق الأسود للعمود الفقري الكسندر كليمينكو على القفزة الماضية الماضية. بالمناسبة ، هذه المراقبة تعمل. ولكن حتى المراقبة المثالية ستتأخر في الوقت. عادة ما تكون عدة دقائق. بعد أن يعمل ، يحتاج المهندسون المناوبون إلى وقت للتحقق من تشغيله مرة أخرى ، وتوطين المشكلة ، ثم إطفاء منطقة المشكلة. أي ، في أفضل الأحوال ، تستغرق معالجة المشكلة 5 دقائق ، على الأقل 20 دقيقة ، إذا لم يكن من الواضح على الفور مكان حدوث الخسائر. من الواضح أن كل هذا الوقت - 5 أو 20 دقيقة - ستستمر خدماتنا في الإضرار ، وهو على الأرجح ليس جيدًا.
ماذا تريد ان تحصل؟ لدينا العديد من المسارات. وتظهر المشاكل على وجه التحديد لأن تدفقات بروتوكول التحكم في الإرسال (TCP) غير المحظوظة تستمر في استخدام نفس المسار. نحتاج إلى شيء يسمح لنا باستخدام مسارات متعددة ضمن اتصال TCP واحد. يبدو أن لدينا حل. هناك TCP ، وهو ما يسمى - متعدد المسارات TCP ، أي TCP للعديد من المسارات. صحيح ، لقد تم تطويره لمهمة مختلفة تمامًا - للهواتف الذكية التي تحتوي على العديد من أجهزة الشبكة. لتعظيم النقل أو جعل الوضع الأساسي / النسخ الاحتياطي ، تم تطوير آلية تنشئ بشفافية عدة سلاسل (جلسات) للتطبيق وتسمح لك بالتبديل بينها في حالة الفشل. أو ، كما قلت ، تعظيم النطاق الترددي.
لكن هناك فارق بسيط هنا. لفهم ما هو عليه ، علينا أن ننظر في كيفية إعداد التدفقات.
يتم تعيين المواضيع بالتتابع. يتم تثبيت الدفق الأول أولاً. يتم بعد ذلك تعيين التدفقات اللاحقة باستخدام ملف تعريف الارتباط المتفق عليه بالفعل داخل هذا الموضوع. وهنا تكمن المشكلة.
المشكلة هي أنه إذا لم يتم تثبيت الخيط الأول ، فلن تظهر الخيوط الثانية والثالثة أبدًا. أي أن TCP متعدد المسارات لا يحل خسارة حزمة SYN في الدفق الأول. وفي حالة فقدان SYN ، يصبح TCP متعدد المسارات TCP عاديًا. لذلك ، في بيئة مركز البيانات ، لن يساعدنا ذلك في حل مشكلة الخسائر في المصنع ومعرفة كيفية استخدام مسارات متعددة في حالة الفشل.
ما الذي يمكن أن يساعدنا؟ لقد خمّن البعض منكم بالفعل من الاسم أن حقل عنوان تدفق IPv6 سيكون حقلاً مهمًا في قصتنا الإضافية. في الواقع ، هذا حقل يظهر في الإصدار 6 ، وليس في الإصدار 4 ، ويستغرق 20 بتًا ، وكان هناك جدل حول استخدامه لفترة طويلة. هذا مثير للاهتمام للغاية - كانت هناك خلافات ، وتم إصلاح شيء ما في إطار RFC ، وفي الوقت نفسه ، ظهر تطبيق في Linux kernel لم يتم توثيقه في أي مكان.
أقترح أن تنضم إلي في تحقيق صغير. دعنا نلقي نظرة على ما كان يحدث في Linux kernel خلال السنوات القليلة الماضية.
عام 2014. يضيف مهندس من شركة كبيرة وذات سمعة طيبة إلى وظائف Linux kernel اعتمادًا على قيمة ملصق التدفق على تجزئة المقبس. ما الذي يحاولون إصلاحه هنا؟ هذا يتعلق بـ RFC 6438 الذي ناقش المشكلة التالية. داخل مركز البيانات ، غالبًا ما يتم تغليف IPv4 في حزم IPv6 ، لأن المصنع نفسه هو IPv6 ، ولكن يجب تقديم IPv4 بطريقة ما. لفترة طويلة كانت هناك مشاكل مع المحولات التي لا يمكن أن تنظر تحت رأسي IP للوصول إلى TCP أو UDP والعثور على src_ports ، dst_ports هناك. اتضح أن التجزئة ، إذا نظرت إلى أول رأسي IP ، تبين أنها ثابتة تقريبًا. لتجنب ذلك ، حتى تعمل موازنة حركة المرور المغلفة هذه بشكل صحيح ، تم اقتراح إضافة تجزئة من الحزمة المغلفة المكونة من 5 مجموعات إلى قيمة حقل تسمية التدفق. تم إجراء نفس الشيء تقريبًا لمخططات التغليف الأخرى ، لـ UDP ، لـ GRE ، وفي الأخير تم استخدام حقل مفتاح GRE. بطريقة أو بأخرى ، الأهداف هنا واضحة. وعلى الأقل في ذلك الوقت كانت مفيدة.
في عام 2015 ، يأتي التصحيح الجديد من نفس المهندس المحترم. إنه ممتع للغاية. تقول ما يلي - سنقوم بترتيب التجزئة عشوائيًا في حالة حدوث حدث توجيه سلبي. ما هو حدث التوجيه السلبي؟ هذا هو RTO الذي ناقشناه سابقًا ، أي أن فقدان ذيل النافذة هو حدث سلبي حقًا. صحيح أنه من الصعب نسبيًا تخمين ما هو عليه.
عام 2016 ، شركة أخرى محترمة ، كبيرة أيضًا. إنه يوزع العكازات الأخيرة ويجعلها تتغير الآن في كل مرة يتم فيها إعادة إرسال SYN وبعد كل مهلة RTO. وفي هذه الرسالة ، وللمرة الأولى والأخيرة ، يبدو الهدف النهائي - التأكد من أن حركة المرور في حالة فقدان القنوات أو زيادة حملها لديها إمكانية إعادة توجيه بسيطة ، باستخدام مسارات متعددة. بالطبع ، بعد ذلك كان هناك الكثير من المنشورات ، يمكنك العثور عليها بسهولة.
على الرغم من الجواب ، لا يمكنك ذلك ، لأنه لم يكن هناك منشور واحد حول هذا الموضوع. لكننا نعلم!
وإذا كنت لا تفهم تمامًا ما تم فعله ، فسوف أخبرك الآن.
ما الذي تم إنجازه ، ما هي الوظائف التي تمت إضافتها إلى Linux kernel؟ يتغير txhash إلى قيمة عشوائية بعد كل حدث RTO. هذه هي نفس نتيجة التوجيه السلبية. تعتمد التجزئة على هذا txhash وتعتمد تسمية التدفق على تجزئة skb. توجد بعض العمليات الحسابية على الوظائف هنا ، ولا يمكن وضع جميع التفاصيل في شريحة واحدة. إذا كان أي شخص فضوليًا ، فيمكنك مراجعة رمز kernel والتحقق منه.
ما هو المهم هنا؟ تتغير قيمة حقل تسمية التدفق إلى رقم عشوائي بعد كل RTO. كيف يؤثر هذا على دفق TCP غير المحظوظ لدينا؟
في حالة SACK ، لم يتغير شيء لأننا نحاول إعادة إرسال حزمة مفقودة معروفة. حتى الان جيدة جدا.
ولكن في حالة RTO ، بشرط أن نكون قد أضفنا تسمية تدفق إلى وظيفة التجزئة في ToR ، يمكن أن تتخذ حركة المرور مسارًا مختلفًا. وكلما زاد عدد الطائرات ، زادت احتمالية العثور على مسار لا يتأثر بحادث تصادم على جهاز معين.
تبقى مشكلة واحدة - RTO. تم العثور على طريق آخر ، بالطبع ، ولكن يتم قضاء الكثير من الوقت فيه. 200 مللي ثانية كثير. والثاني هو الوحشية بشكل عام. في وقت سابق ، تحدثت عن المهلات التي تهيئ الخدمات. لذا ، فإن الثانية هي المهلة التي عادةً ما تُنشئ خدمة على مستوى التطبيق ، وفي هذا ستكون الخدمة مناسبة نسبيًا. علاوة على ذلك ، أكرر ، فإن RTT الحقيقي داخل مركز بيانات حديث يبلغ حوالي 1 مللي ثانية.
ما الذي يمكن عمله بخصوص مهلات RTO؟ يمكن تكوين المهلة المسؤولة عن RTO في حالة فقدان حزم البيانات بسهولة نسبيًا من مساحة المستخدم: هناك أداة مساعدة IP ، وتحتوي إحدى معلماتها على نفس rto_min. بالنظر إلى أنه ، بالطبع ، تحتاج إلى تحويل RTO ليس عالميًا ، ولكن بالنسبة لبادئات معينة ، تبدو هذه الآلية تعمل تمامًا.
صحيح ، مع SYN_RTO كل شيء أسوأ إلى حد ما. هو مسمر بشكل طبيعي. القيمة ثابتة في القلب - ثانية واحدة ، وهذا كل شيء. لا يمكنك الوصول إليه من مساحة المستخدم. هناك طريقة واحدة فقط.
يأتي eBPF للإنقاذ. بكل بساطة ، هذه برامج صغيرة من نوع C. يمكن إدخالها في خطافات في أماكن مختلفة في تنفيذ مكدس النواة ومكدس TCP ، والتي من خلالها يمكنك تغيير عدد كبير جدًا من الإعدادات. بشكل عام ، eBPF هو اتجاه طويل الأجل. بدلاً من نشر العشرات من معلمات sysctl الجديدة وتوسيع أداة IP المساعدة ، تكون الحركة في اتجاه eBPF وتوسيع وظائفها. باستخدام eBPF ، يمكنك تغيير عناصر تحكم الازدحام ديناميكيًا والعديد من إعدادات TCP الأخرى.
ولكن من المهم بالنسبة لنا أنه بمساعدة ذلك يمكنك تحريف قيم SYN_RTO. وهناك مثال منشور للجمهور: . ماذا يحدث هنا؟ المثال يعمل ، لكنه في حد ذاته قاسي للغاية. من المفترض هنا أننا داخل مركز البيانات نقارن أول 44 بتة ، إذا كانت متطابقة ، فإننا نجد أنفسنا داخل العاصمة. وفي هذه الحالة ، نقوم بتغيير قيمة مهلة SYN_RTO إلى 4 مللي ثانية. يمكن القيام بنفس المهمة بشكل أكثر رشاقة. لكن هذا المثال البسيط يوضح ما هو أ) ممكن ؛ ب) سهل نسبيًا.
ماذا نعرف بالفعل؟ أن البنية المستوية تسمح بالتوسع ، فقد تبين أنها مفيدة للغاية بالنسبة لنا عندما نقوم بتشغيل تسمية التدفق على ToR والحصول على فرصة للتدفق حول مناطق المشاكل. أفضل طريقة لخفض قيم RTO و SYN-RTO هي استخدام برامج eBPF. يبقى السؤال: هل من الآمن استخدام ملصق التدفق لتحقيق التوازن؟ وهناك فارق بسيط هنا.
افترض أن لديك خدمة على الشبكة تعيش في أي بث. لسوء الحظ ، ليس لدي وقت للخوض في التفاصيل حول أي بث ، لكنها خدمة موزعة حيث تتوفر خوادم فعلية مختلفة على نفس عنوان IP. وهنا مشكلة محتملة: يمكن أن يحدث حدث RTO ليس فقط عندما تمر حركة المرور عبر المصنع. يمكن أن يحدث أيضًا على مستوى المخزن المؤقت ToR: عند حدوث حدث غير مباشر ، يمكن أن يحدث حتى على المضيف عندما ينسكب المضيف شيئًا ما. عندما يقع حدث RTO ويغير تسمية التدفق. في هذه الحالة ، قد تنتقل حركة المرور إلى مثيل anycast آخر. لنفترض أنه أي بث ذي حالة ، يحتوي على حالة اتصال - يمكن أن يكون موازن L3 أو خدمة أخرى. ثم تنشأ مشكلة ، لأنه بعد RTO ، يصل اتصال TCP إلى الخادم ، الذي لا يعرف شيئًا عن اتصال TCP هذا. وإذا لم يكن لدينا مشاركة حالة بين خوادم anycast ، فسيتم إسقاط حركة المرور هذه وسينقطع اتصال TCP.
ما الذي يمكن القيام به هنا؟ ضمن البيئة التي يتم التحكم فيها ، حيث تقوم بتمكين موازنة تسمية التدفق ، تحتاج إلى إصلاح قيمة ملصق التدفق عند الوصول إلى خوادم أي بث. أسهل طريقة هي القيام بذلك من خلال نفس برنامج eBPF. ولكن هنا نقطة مهمة للغاية - ماذا تفعل إذا كنت لا تشغل شبكة مركز بيانات ، ولكنك مشغل اتصالات؟ هذه هي مشكلتك أيضًا: بدءًا من إصدارات معينة من Juniper و Arista ، فإنها تتضمن تسمية التدفق في وظيفة التجزئة افتراضيًا - لأكون صادقًا ، بدون سبب أفهمه. يمكن أن يتسبب ذلك في إسقاط اتصالات TCP من المستخدمين الذين يمرون عبر شبكتك. لذلك ، أوصي بشدة بالتحقق من إعدادات جهاز التوجيه الخاص بك في هذا الموقع.
بطريقة أو بأخرى ، يبدو لي أننا مستعدون للانتقال إلى التجارب.
عندما قمنا بتشغيل ملصق التدفق على ToR ، أعدنا eBPF الخاص بالوكيل ، والذي يعيش الآن على المضيفين ، قررنا ألا ننتظر الفشل الكبير التالي ، ولكن لإجراء انفجارات محكومة. أخذنا ToR ، الذي يحتوي على أربعة وصلات صاعدة ، وقمنا بإفلات واحد منهم. قالوا إنهم رسموا قاعدة - الآن أنت تفقد كل الحزم. كما ترى على اليسار ، لدينا مراقبة لكل حزمة ، والتي انخفضت إلى 75٪ ، أي أن 25٪ من الحزم قد فقدت. على اليمين توجد رسوم بيانية للخدمات التي تعيش خلف هذه الشروط. في الواقع ، هذه رسوم بيانية لحركة المرور للمفاصل مع الخوادم داخل الرف. كما ترون ، غرقوا حتى أقل. لماذا انخفضوا - ليس بنسبة 25 ٪ ، ولكن في بعض الحالات بنسبة 3-4 مرات؟ إذا كان اتصال TCP غير محظوظ ، فسيستمر في محاولة الوصول من خلال الواجهة المعطلة. يتفاقم هذا بسبب السلوك المعتاد للخدمة داخل DC - بالنسبة لطلب مستخدم واحد ، يتم إنشاء طلبات N للخدمات الداخلية ، وستذهب الاستجابة إلى المستخدم ، إما عند استجابة جميع مصادر البيانات ، أو عند حدوث مهلة في مستوى التطبيق ، والذي لا يزال بحاجة إلى التهيئة. أي أن كل شيء سيء للغاية.
الآن نفس التجربة ، ولكن مع تمكين تسمية التدفق. كما ترون ، على اليسار ، انخفضت مراقبة الدُفعات بنسبة 25٪. هذا صحيح تمامًا ، لأنه لا يعرف أي شيء عن عمليات إعادة الإرسال ، فهو يرسل الحزم ويحسب ببساطة نسبة عدد الحزم المسلمة والمفقودة.
وعلى اليمين جدول الخدمات. لن تجد تأثير مشكلة مشتركة هنا. تدفقت حركة المرور في تلك الأجزاء بالمللي ثانية نفسها من منطقة المشكلة إلى الوصلات الصاعدة الثلاثة المتبقية التي لم تتأثر بالمشكلة. لدينا شبكة تشفي نفسها.
هذه هي الشريحة الأخيرة ، حان وقت التقييم. الآن ، أتمنى أن تعرف كيفية بناء شبكة مركز بيانات ذاتية الشفاء. لن تحتاج إلى مراجعة أرشيف Linux kernel والبحث عن تصحيحات خاصة هناك ، فأنت تعلم أن تسمية Flow تحل المشكلة في هذه الحالة ، ولكن عليك التعامل مع هذه الآلية بعناية. وأؤكد مرة أخرى أنه إذا كنت مشغل شبكة ، فلا يجب عليك استخدام تسمية التدفق كوظيفة تجزئة ، وإلا فسوف تقطع جلسات المستخدمين.
بالنسبة لمهندسي الشبكات ، يجب إجراء تحول مفاهيمي: لا تبدأ الشبكة بـ ToR ، وليس بجهاز شبكة ، ولكن مع مضيف. ومن الأمثلة الصارخة إلى حد ما كيف نستخدم eBPF لتغيير RTO ولإصلاح تسمية التدفق تجاه خدمات anycast.
ميكانيكي تسمية التدفق مناسب بالتأكيد للاستخدامات الأخرى داخل الجزء الإداري الخاضع للرقابة. يمكن أن يكون هذا هو حركة المرور بين مراكز البيانات ، أو يمكنك استخدام هذه الآليات بطريقة خاصة للتحكم في حركة المرور الصادرة. لكنني آمل أن أتحدث عن هذا في المرة القادمة. شكرا جزيلا لكم على اهتمامكم.
المصدر: www.habr.com