مراقبة فقدان حزم الشبكة وزمن الوصول على Roblox Cloud

يقوم فريق هندسة الشبكات في Roblox بصيانة شبكة كبيرة وسريعة النمو تضم مراكز بيانات ومواقع نقاط تواجد (POP) موزعة في جميع أنحاء العالم. يعتمد تقديم تجربة مستخدم رائعة على منصة Roblox على أداء وموثوقية هذه الشبكة. من الضروري أن يتمكن مشغلو الشبكات من استكشاف الأخطاء وإصلاحها واكتشاف المشكلات في الشبكة، وأن يكون لديهم رؤية واضحة لأداء الشبكة. تتم مراقبة الشبكة عمومًا من خلال جمع إحصائيات الأجهزة ومقاييس الأخطاء وسجلات النظام بشكل دوري، وتخزينها في سلسلة زمنية أو قاعدة بيانات سجلات. يتم جمع البيانات إما بنموذج الدفع أو السحب باستخدام بروتوكولات قياسية مثل SNMP أو Netconf أو Rest APIs أو Streaming Telemetry.

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

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

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

تصميم نظام مراقبة شبكي موثوق وقابل للتوسع

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

ما الذي نستخدمه لاختبار الشبكة؟

يجب أن تحاكي اختبارات الفحص حركة المرور الحية التي تمر عبر شبكة الإنتاج. معظم حركة المرور على شبكتنا هي إما TCP أو UDP أو HTTP، ويمكن استخدام كل منها في الاختبارات. تتمثل إحدى مشكلات اختبار TCP في أنه ليس خفيفًا بما يكفي للتوسع إلى عدد الاتصالات اللازمة لمراقبة شبكة كبيرة. هناك مشكلة أخرى في TCP وهي أن التحكم المدمج في التدفق وعمليات الإرسال القائمة على النافذة المنزلقة تؤدي إلى معدل إرسال متغير للمسبار، وهو أمر غير مثالي لتحديد أو اكتشاف حالات فقدان الحزم المؤقتة. عادةً ما يكون ICMP، الذي يستخدمه كل من ping و traceroute، محدودًا من حيث المعدل على الخوادم أو عقد الشبكة. وهذا يحد من المعدل الإجمالي لمسبارات ICMP التي يمكن استخدامها. تقع طلبات HTTP في أعلى طبقة التطبيق وتعتمد على بعض العوامل خارج الشبكة مثل أداء الخادم أو التطبيق. يضيف HTTP عاملاً متغيرًا إضافيًا إلى النتائج يصعب فصله. الهدف من هذا النظام هو مراقبة أداء البنية التحتية للشبكة الأساسية التي تعمل بشكل أساسي في طبقات OSI 4 وما دونها. اخترنا اختبارات UDP لهذه الأسباب بالإضافة إلى كونها بروتوكول طبقة النقل الأساسي على شبكتنا.

من أين نجري الاختبارات؟

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

كيف نقيس فقدان الشبكة وزمن الوصول؟

قد يبدو هذا حسابًا بسيطًا على دفق واحد من الاختبارات، ومع ذلك، هناك بعض التحديات التي تنشأ على نطاق واسع والتي لا تكون واضحة على الفور. للتوسع إلى شبكة كبيرة كهذه، يحتاج الوكيل إلى حساب أعداد حزم الإرسال (Tx) والاستقبال (Rx) بسرعة ودقة مع طوابع زمنية عبر العديد من الدفقات في وقت واحد. من المهم ألا تتضمن مقاييس فقدان الشبكة الحزم المفقودة في المضيف الذي يشغل الوكيل عندما تكون وحدة المعالجة المركزية (CPU) مشغولة أو عندما تفيض مخازن الشبكة المؤقتة. يجب حساب زمن انتقال الشبكة بناءً على الوقت الإجمالي الذي قضته الاختبارات على السلك أو العقد الشبكية الوسيطة، مع استبعاد الوقت الذي قضته في الانتظار في مخازن الإدخال/الإخراج (I/O) وعملية الوكيل في انتظار جدولة نظام التشغيل.

نظام Ping Mesh من Roblox

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

• اخترنا لغة Go لتنفيذ جميع مكونات نظامنا، مما ساعدنا على تحقيق مستوى عالٍ من الأداء مع استخدام الحد الأدنى من موارد النظام.
• تتميز وكالاتنا بدرجة عالية من الاستقرار ويمكن تشغيلها على مجموعة واسعة من مضيفات الإنتاج، بما في ذلك تلك التي تقدم خدمات حيوية على منصة Roblox مثل خوادم حركة المرور والتخزين المؤقت والتطبيقات.
• تم تحسين الوكيل لتجميع عمليات إدخال/إخراج الحزم باستخدام وظائف غلاف Go عبر استدعاءات نظام Linux sendmmsg() و recvmmsg()، مما يمكّنه من إرسال معدل عالٍ من الاختبارات بتكلفة تشغيل منخفضة. يقوم كل وكيل في نشرنا بإرسال الاختبارات في وقت واحد إلى ما يصل إلى 100 مضيف آخر، بمعدل 100 حزمة في الثانية (PPS). يرسل الوكيل دفعات من الحزم كل ثانية إلى كل وجهة.
• تحمل الاختبارات قيم حقول مختلفة لنوع الخدمة (TOS) في رأس IP إلى كل وجهة ويتم حسابها بشكل منفصل لفقدان الحزم والكمون عبر الشبكة. تتضمن كل دفعة حزم مزيجًا من قيم TOS متعددة لكل وجهة أخرى. يساعد هذا في مراقبة أداء الشبكة لفئات مختلفة من جودة الخدمة (QoS).
• يمكن للوكيل اكتشاف انقطاعات في الشبكة تصل إلى 1 من كل 6000 حزمة في الدقيقة على كل مسار مسبار. يمكن اكتشاف فقدان الحزم داخل قلب الشبكة أو حافتها لمدة تقل عن ثانية واحدة، مثل تلك التي تحدث أثناء تقلب BGP.
• تحاكي مخططات انخفاض حزم الاختبار معدلات أخطاء واجهة جهاز الشبكة عندما تكون الأخطاء مسؤولة عن الانخفاضات. تمكنا من اكتشاف أخطاء "الثقب الأسود" في حركة المرور على الشبكة والتي يصعب اكتشافها.
• تستخدم الوكلاء طوابع زمنية لقراءة نواة NIC لتحقيق دقة عالية في قياسات زمن انتقال الشبكة. يمكن قياس زمن انتقال ذهاب وإياب ثابت داخل الموقع يتراوح بين 50 و100 ميكروثانية مع استبعاد زمن انتقال جدولة نظام تشغيل المضيف وانحراف ساعة الشبكة.
• استخدام منخفض لوحدة المعالجة المركزية (CPU) وبصمة ذاكرة صغيرة. يستخدم الوكيل أقل من 25% من نواة واحدة عند معدلات الإرسال والاستقبال القصوى (5 كيلو بايت في الثانية لكل منهما). يستخدم معظم الوكلاء المنشورين حوالي 5% فقط من النواة. لا يلزم سوى 10 ميغابايت من ذاكرة الكومة لإدارة مخازن حزم الإرسال والاستقبال والعدادات الخاصة بالوكيل. عندما تنمو الشبكة، يمكننا التوسع عموديًا أو أفقيًا عن طريق تعديل الحدود أو إضافة وكلاء إضافيين.
• نادرًا ما يتأثر الوكيل عندما يكون نظام المضيف تحت ضغط. لقد حصلنا على نتائج دقيقة حتى عندما اقترب حمل وحدة المعالجة المركزية (CPU) للمضيف من 99٪ في عدة مناسبات.
• يتم جمع بيانات القياس عن بُعد من كل وكيل لمراقبة حالته. يمكن للوكلاء تحديد المواقف التي تنطوي على مشاكل، مثل إعادة تشغيل النظام المضيف، أو إعادة تشغيل عملية الوكيل، أو فقدان الحزم بسبب فيضان مخازن مآخذ التوصيل.

يتم نشر الوكلاء باستخدام Chef على مجموعة واسعة من مجموعات الخوادم للحفاظ على عدد كبير من العقد المشاركة في فحص الشبكة. يتم تشغيل ملف الوكيل الثنائي وإدارته باستخدام systemd على نظام Linux بحيث يتم إعادة تشغيله تلقائيًا بعد إعادة تشغيل المضيف أو ترقية الوكيل. يقوم مجدول الشبكة بالكشف عن التدفقات وتعديلها ديناميكيًا حسب الحاجة عندما يتعطل أي من الوكلاء أو يظهر وكلاء جدد. يقوم تطبيق المجدول لدينا باستقصاء مخزون الأجهزة ونظام اكتشاف الخدمات بشكل دوري لاكتشاف الوكلاء الجدد وحالة صحة الخادم قبل تخصيص أهداف للاختبار داخل المجموعة (Intra-Pod) وداخل الموقع (Intra-Site) وبين المواقع (Inter-Site). يتم استخدام ناقل رسائل لإبلاغ قائمة المضيفات المستهدفة لكل وكيل يقوم بإرسال اختبارات الفحص. يتم توزيع التدفقات الفردية التي تنشأ أو تنتهي عند رف معين على جميع الوكلاء المتاحين داخل ذلك الرف. يساعدنا هذا في ممارسة عدد كبير من مسارات التكلفة المتساوية داخل بنية شبكتنا، كما هو موضح في الأشكال أدناه.

بدأنا بـ 150 وكيلاً في أول عملية نشر لنا، والآن نجحنا في التوسع بمقدار 10 أضعاف. تغطي الشبكة شبكتنا الأساسية التي تربط 25 موقعًا منتشرة في جميع أنحاء العالم. في أحد مواقع مراكز البيانات الرئيسية لدينا، لدينا شبكة داخلية تغطي أكثر من 200 رفًا مع حوالي 33000 دفقًا يبلغ معدل الاستقصاء الإجمالي لها 1.65 مليون استقصاء في الثانية. يتلقى كل رف 5-10 آلاف استقصاء في الثانية من الرفوف الأخرى. يقوم تطبيق المجدول بحساب وتوزيع أكثر من 35000 هدف بالتساوي على جميع وكلائنا في المواقع المختلفة.

جمع البيانات وتصورها

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

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

ملخص والخطوات التالية

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

يمكن لنظامنا أيضًا تقديم رؤى حول الموثوقية الإجمالية لشبكة Roblox Cloud. في أحد مواقع مراكز البيانات الرئيسية لدينا، لدينا أكثر من 100 مليون مسبار في الدقيقة تراقب حالة الشبكة ونادرًا ما نصل إلى عدد فقدان حزم يزيد عن 50 في الدقيقة. يشير هذا إلى موثوقية تبلغ حوالي 6 أرقام 9 (99.9999٪) من شبكة مركز البيانات لدينا. في كثير من الأحيان، لا يُلاحظ أي فقدان لحزم البيانات بين 100 مليون حزمة. وعندما تُفقد كمية كبيرة من الحزم، يوفر هذا النظام رؤى حول مكان حدوث فقدان الحزم ومدته. ويقوم محرك الإصلاح التلقائي بإصلاح الشبكة ذاتيًا ويمنع حركة مرور المستخدمين من التعرض لمزيد من حالات الفقدان عن طريق إعادة توجيهها عبر مسار مختلف في الشبكة. وقد أنشأ فريق الشبكات في Roblox شبكة سحابية موثوقة للغاية.

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