استخدام تخزين النقطة المثبتة على NFS مع ذاكرة التخزين المؤقت لـ Azure HPC

مقالة
06/01/2023

يمكنك استخدام حاويات blob المثبتة على NFS مع Azure HPC Cache. اقرأ المزيد حول دعم بروتوكول NFS 3.0 في تخزين Azure Blob على موقع وثائق تخزين Blob.

يستخدم Azure HPC Cache تخزين الكائن الثنائي كبير الحجم الممكن ل NFS في نوع هدف تخزين ADLS-NFS الخاص به. تشبه أهداف التخزين هذه أهداف تخزين NFS العادية، ولكن لها أيضا بعض التداخل مع أهداف Azure Blob العادية.

تشرح هذه المقالة الاستراتيجيات والقيود التي يجب أن تفهمها عند استخدام أهداف تخزين ADLS-NFS.

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

فهم متطلبات التناسق

تتطلب HPC Cache تناسقا قويا لأهداف تخزين ADLS-NFS. بشكل افتراضي، لا يقوم تخزين الكائن الثنائي كبير الحجم الذي يدعم NFS بتحديث بيانات تعريف الملف بدقة، مما يمنع HPC Cache من مقارنة إصدارات الملفات بدقة.

للتغلب على هذا الاختلاف، يقوم Azure HPC Cache تلقائيا بتعطيل التخزين المؤقت لسمة NFS على أي حاوية كائن ثنائي كبير الحجم ممكنة ل NFS تستخدم كهدف تخزين.

يستمر هذا الإعداد طوال مدة بقاء الحاوية، حتى إذا قمت بإزالتها من ذاكرة التخزين المؤقت.

تحميل البيانات مسبقا باستخدام بروتوكول NFS

في حاوية كائن ثنائي كبير الحجم ممكنة ل NFS، لا يمكن تحرير الملف إلا بواسطة نفس البروتوكول المستخدم عند إنشائه. أي، إذا كنت تستخدم Azure REST API لتعبئة حاوية، فلا يمكنك استخدام NFS لتحديث هذه الملفات. نظرا لأن Azure HPC Cache يستخدم NFS فقط، فإنه لا يمكنه تحرير أي ملفات تم إنشاؤها باستخدام Azure REST API. (تعرف على المزيد حول المشكلات المعروفة مع واجهات برمجة تطبيقات تخزين الكائنات الثنائية كبيرة الحجم)

إنها ليست مشكلة لذاكرة التخزين المؤقت إذا كانت الحاوية فارغة، أو إذا تم إنشاء الملفات باستخدام NFS.

إذا تم إنشاء الملفات في الحاوية الخاصة بك باستخدام Azure Blob REST API بدلا من NFS، يتم تقييد Azure HPC Cache إلى هذه الإجراءات على الملفات الأصلية:

سرد الملف في دليل.
اقرأ الملف (واحتفظ به في ذاكرة التخزين المؤقت للقراءات اللاحقة).
احذف الملف .
إفراغ الملف (اقتطاعه إلى 0).
احفظ نسخة من الملف. يتم وضع علامة على النسخة كملف تم إنشاؤه بواسطة NFS، ويمكن تحريرها باستخدام NFS.

لا يمكن ل Azure HPC Cache تحرير محتويات ملف تم إنشاؤه باستخدام REST. وهذا يعني أن ذاكرة التخزين المؤقت لا يمكنها حفظ ملف تم تغييره من عميل مرة أخرى إلى هدف التخزين.

من المهم فهم هذا القيد، لأنه يمكن أن يسبب مشاكل في تكامل البيانات إذا كنت تستخدم نماذج استخدام التخزين المؤقت للقراءة/الكتابة على الملفات التي لم يتم إنشاؤها باستخدام NFS.

تلميح

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

كتابة سيناريوهات التخزين المؤقت

تتضمن نماذج استخدام ذاكرة التخزين المؤقت هذه التخزين المؤقت للكتابة:

أكبر من 15٪ من الكتابات
أكبر من 15٪ من عمليات الكتابة، والتحقق من الخادم الاحتياطي للتغييرات كل 30 ثانية
أكبر من 15٪ من عمليات الكتابة، والتحقق من خادم النسخ الاحتياطي للتغييرات كل 60 ثانية
أكبر من 15٪ من عمليات الكتابة، قم بالكتابة مرة أخرى إلى الخادم كل 30 ثانية

يجب استخدام نماذج استخدام التخزين المؤقت للكتابة فقط على الملفات التي تم إنشاؤها باستخدام NFS.

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

فيما يلي كيفية وضع محاولة التخزين المؤقت للكتابات إلى الملفات التي تم إنشاؤها بواسطة REST البيانات في خطر:

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

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

قراءة سيناريوهات التخزين المؤقت

قراءة سيناريوهات التخزين المؤقت مناسبة للملفات التي تم إنشاؤها باستخدام NFS أو Azure Blob REST API.

تستخدم نماذج الاستخدام هذه التخزين المؤقت للقراءة فقط:

قراءة الكتابات الثقيلة غير المتكررة
يكتب العملاء إلى هدف NFS، متجاوزين ذاكرة التخزين المؤقت
قراءة ثقيلة، والتحقق من خادم النسخ الاحتياطي كل 3 ساعات

يمكنك استخدام نماذج الاستخدام هذه مع الملفات التي تم إنشاؤها بواسطة REST API أو بواسطة NFS. ستظل أي عمليات كتابة NFS يتم إرسالها من عميل إلى الحاوية الخلفية تفشل، ولكنها ستفشل على الفور وتعيد رسالة خطأ إلى العميل.

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

التعرف على قيود Network Lock Manager (NLM)

لا تدعم حاويات blob التي تدعم NFS Network Lock Manager (NLM)، وهو بروتوكول NFS شائع الاستخدام لحماية الملفات من التعارضات.

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

لتعطيل NLM، استخدم الخيار -o nolock في أمر العملاء mount . يمنع هذا الخيار العملاء من طلب تأمين NLM وتلقي الأخطاء في الاستجابة. nolock يتم تنفيذ الخيار بشكل مختلف في أنظمة تشغيل مختلفة؛ تحقق من وثائق نظام تشغيل العميل (رجل 5 nfs) للحصول على التفاصيل.

تبسيط عمليات الكتابة إلى الحاويات التي تدعم NFS باستخدام HPC Cache

يمكن أن تساعد Azure HPC Cache في تحسين الأداء في حمل العمل الذي يتضمن كتابة تغييرات على هدف تخزين ADLS-NFS.

إشعار

يجب استخدام NFS لملء حاوية تخزين ADLS-NFS إذا كنت تريد تعديل ملفاتها من خلال Azure HPC Cache.

أحد القيود الموضحة في مقالة اعتبارات أداء الكائن الثنائي كبير الحجم الذي يدعم NFS هو أن تخزين ADLS-NFS ليس فعالا جدا في الكتابة فوق الملفات الموجودة. إذا كنت تستخدم Azure HPC Cache مع تخزين كائن ثنائي كبير الحجم مثبت على NFS، فإن ذاكرة التخزين المؤقت تعالج عمليات إعادة الكتابة المتقطعة أثناء قيام العملاء بتعديل ملف نشط. يتم إخفاء زمن انتقال كتابة ملف إلى الحاوية الخلفية من العملاء.

ضع في اعتبارك القيود الموضحة أعلاه في بيانات التحميل المسبق باستخدام بروتوكول NFS.

مشاركة عبر