الخلاصة

  • وضعت RFC 7147 قيمة iSCSIProtocolLevel ضمن سمات كل جلسة، فحافظت على نطاق التفاوض الحقيقي بين المبادر والهدف.
  • تثبت القيمة 2 حالة بروتوكولية لتلك الجلسة؛ ولا تثبت اكتمال مهمة SCSI محددة أو قبول التطبيق لنتيجتها.

الجهاز ليس محادثة واحدة

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

هذه هي الفكرة الهندسية التي جعلتها RFC 7147 قابلة للرصد. صدر النص في أبريل 2014، وأحلّ RFC 4544 وحدّث قاعدة معلومات الإدارة الخاصة بـ iSCSI بما يوافق RFC 7143 وRFC 7144. وأضاف إلى جدول الجلسات سمتين للقراءة فقط: iscsiSsnProtocolLevel وiscsiSsnTaskReporting. الأولى تسجل مستوى بروتوكول iSCSI المتفاوض عليه لهذه الجلسة. والثانية تسجل دلالات الإبلاغ عن اكتمال المهام التي جرى التفاوض عليها مع هدف SCSI.

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

التفاوض شرط، لا إثبات تنفيذ

تشترط RFC 7144 التفاوض على القيمة «2» لمفتاح iSCSIProtocolLevel لاستخدام الميزات التي تصفها. لكنها تنص أيضاً على أن هذا التفاوض ضروري وغير كافٍ لاستخدام قدرات SCSI المقابلة. فقد يرفض التنفيذ وظيفة محددة لإدارة المهام. ويبقى على المبادر تفسير استجابة SCSI؛ ولا يمكن لقراءة SNMP أن تحل محلها.

لهذا لا تعني عبارة «المستوى 2» أن كل وظيفة متاحة أو أن أمراً بعينه نجح. إنها تعني أن طرفي تلك الجلسة اتفقا على مستوى بروتوكولي معين. أما دعم الوظيفة في التنفيذ، وإرسال الطلب، واستجابة الهدف، ومعالجة المضيف للنتيجة، فلكل منها دليل مستقل.

وتظهر الحدود نفسها في السمة الثانية. يمثل TaskReporting مجموعة من دلالات الإبلاغ المتفاوض عليها، ومنها السلوك الأساسي في RFC 3720 وResponseFence وFastAbort. يوضح هذا الحقل كيف يُبلَّغ عن اكتمال المهام؛ ولا يشهد بأن مهمة بعينها نُفذت أو أن البيانات أصبحت دائمة أو أن التطبيق اعتمد النتيجة.

شجرة الإدارة تفصل طبقات مختلفة

تبدأ بنية MIB بمثيل iSCSI، ثم تنظم تحته العقد والمنافذ والجلسات والاتصالات. ويُفهرس كل كائن غير قياسي أولاً برقم المثيل. قد يمثل المثيل قسماً مادياً أو افتراضياً من جهاز تخزين. وتوضح RFC 7147 أن المثيل لا يحل محل سياق SNMP؛ بل يسهّل إسناد القسم إلى سياق واحد أو أكثر من دون تكرار الإسناد لكل سجل منفذ أو جلسة.

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

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

ما الذي يمكن أن تقوله القيمة؟

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

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

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

المصادر