الخلاصة

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

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

صدر RFC 2039 في نوفمبر 1996 بوصفه وثيقة Informational لا معيار إنترنت. جاء بطلب من مدير مجال إدارة الشبكات عقب جلسة HTTP-MIB BOF في الاجتماع الخامس والثلاثين لـIETF في لوس أنجلوس. كان سؤاله عن مدى ملاءمة MIBs القائمة لإدارة خوادم World Wide Web.

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

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

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

لماذا لا يكفي جرد العمليات

راجع RFC 2039 كلاً من MIB-II وHost Resources MIB وNetwork Services Monitoring MIB وأعمال Application MIB. كانت هناك معلومات مفيدة عن النظام والواجهات والمعالجات والتخزين والبرمجيات المثبتة والجارية وتطبيقات الشبكة وارتباطاتها. لبّت هذه الأدوات جانباً كبيراً من المتطلبات التشغيلية وجزءاً من منظور الخدمة.

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

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

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

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

جاء RFC 2594 في 1999 كـProposed Standard ليعرّف كائنات إدارة لخدمات WWW حول نقل الوثائق والطلبات والاستجابات ورموز الحالة والمضيفين الافتراضيين والإحصاءات. أعلن أنه منظور موجّه إلى الخدمة لا إلى العملية، ومخصص لاكتشاف المشكلات وتشخيصها على المدى القصير لا للمحاسبة. لم يحدّث RFC 2039 أو يلغِه رسمياً، لكنه جسّد الحاجة إلى لغة للخدمة تختلف عن لغة العمليات.

المصادر