الخلاصة

  • كان تعطل وصلتين صاعدتين في ترتيب محدد ضمن Firehose 1.0 قادراً على منع مجموعتين من الأجهزة من التواصل بينهما، مع بقاء اتصالهما بأجهزة أخرى. لم ينقل ذلك التصميم حركة تشغيل فعلية.
  • أتاحت الكتل المستقلة لاحقاً حصر بعض أعمال الصيانة في نطاق أصغر، لكن فصل المعدات لم يلغ المخاطر المشتركة في التحكم والبرمجيات والإعدادات.
  • يربط الدور الموثق لـ Urs Hölzle ومشاركته في تأليف دراسة جماعية بينه وبين هذا العمل الهندسي، من دون نسبة كل قرار تقني إليه منفرداً.

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

تصف ورقة SIGCOMM الأصلية الصادرة عام 2015 حالة كهذه في Firehose 1.0. إذا تعطلت وصلتان صاعدتان على جانبين متقابلين في مبدلين أعلى الرفوف خلال نافذة الإصلاح نفسها، أمكن للأجهزة التابعة لهما الوصول إلى أجهزة أخرى، دون الوصول بعضها إلى بعض. يذكر المؤلفون أن التطبيقات واجهت صعوبة في التعامل مع هذا الاتصال غير المتعدي.

ولا يصح تحويل الوصف إلى خبر عن انقطاع حالي لدى Google. فبحسب الورقة، لم يحمل Firehose 1.0 حركة تشغيل فعلية قط. إنه درس من محاولة تصميم وتنفيذ مبكرة، وجزء من تفسير التغييرات التي جاءت بعدها.

مسؤولية موثقة وعمل جماعي

يظهر Urs Hölzle بين عدد كبير من مؤلفي الدراسة. وتعرّفه صفحته في Google Research بأنه Google Fellow في Google Cloud، وتوضح أنه شغل منصب النائب الأول للرئيس المسؤول عن البنية التحتية التقنية حتى عام 2023. شملت مهمته آنذاك الإشراف على تصميم الخوادم والشبكات ومراكز البيانات وتركيبها وتشغيلها لخدمات Google.

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

يوثق إعلان Google في مايو 2013 ومقال Hölzle عن الشبكة في مارس 2020 ذلك الدور في تاريخين محددين. ويميز المقال الثاني بين شبكة Google والوصلة الأخيرة التي يوفرها مزودو الوصول إلى الإنترنت. لذلك لا ينبغي توسيع نطاق المسؤولية ليشمل كل ما يعتمد عليه اتصال المستخدم.

توزيع المخاطر يوسع الحاجة إلى الاتصال

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

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

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

كم يختفي من الشبكة عند صيانة جزء منها؟

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

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

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

إذن لا يكفي عدّ المعدات التي تخرج من الخدمة. يجب اختيار مجموعة الصيانة بناءً على الاتصال الذي يبقى وكيفية توزيع الحركة عليه.

ما الذي يبقى مشتركاً رغم الفصل؟

تصف الدراسة Firepath في أجيال Firehose وWatchtower وSaturn. يوزع النظام رؤية مشتركة للبنية وحالة الوصلات، بينما يحسب كل مبدل جداول التمرير محلياً. المركزية هنا تخص تنسيق الحالة، لا اتخاذ قرار لكل حزمة في مركز واحد. تدعم هذا الترتيب وظائف تحكم احتياطية وشبكة منفصلة. وتذكر الورقة صراحة أن تفاصيل التحكم في Jupiter خارج نطاقها.

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

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

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

النتيجة التي يمكن نسبتها إلى هذا المسار

سجل مؤتمر 2015 ونسخة CACM المنشورة عام 2016 يعودان إلى العمل نفسه، ولا يمثلان تحققين مستقلين. تشرح مراجعة المشغّل تعلمه التاريخي، لكنها لا تثبت بنية مراكز البيانات الحالية أو توافرها اليوم.

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

المصادر