استخدام تخزين النقطة المثبتة على NFS مع ذاكرة التخزين المؤقت لـ Azure HPC
يمكنك استخدام حاويات blob المثبتة على NFS مع ذاكرة التخزين المؤقت ل Azure HPC. اقرأ المزيد حول دعم بروتوكول NFS 3.0 في وحدة تخزين Azure Blob على موقع وثائق تخزين Blob.
يستخدم Azure HPC Cache تخزين blob ممكن NFS في نوع هدف التخزين ADLS-NFS الخاص به. تتشابه أهداف التخزين هذه مع أهداف تخزين NFS العادية، ولكن لديها أيضا بعض التداخل مع أهداف Azure Blob العادية.
توضح هذه المقالة الاستراتيجيات والقيود التي يجب فهمها عند استخدام أهداف تخزين ADLS-NFS.
يجب عليك أيضا قراءة وثائق نقطة NFS ، خاصة هذه الأقسام التي تصف السيناريوهات المتوافقة وغير المتوافقة ، وتقديم نصائح لاستكشاف الأخطاء وإصلاحها:
- نظرة عامة على الميزات
- اعتبارات الأداء
- المشكلات والقيود المعروفة
- دليل الإجراءات الإرشادية واستكشاف الأخطاء وإصلاحها
فهم متطلبات الاتساق
تتطلب ذاكرة التخزين المؤقت HPC اتساقا قويا لأهداف تخزين ADLS-NFS. بشكل افتراضي، لا يقوم تخزين blob الذي يدعم NFS بتحديث بيانات تعريف الملف بشكل صارم، مما يمنع HPC Cache من مقارنة إصدارات الملفات بدقة.
كمحاولة للتغلب على هذا الاختلاف، يقوم Azure HPC Cache تلقائيا بتعطيل التخزين المؤقت لسمة NFS على أي حاوية blob ممكنة ل NFS تستخدم كهدف تخزين.
يستمر هذا الإعداد طوال عمر الحاوية، حتى إذا قمت بإزالته من ذاكرة التخزين المؤقت.
تحميل البيانات مسبقا باستخدام بروتوكول NFS
في حاوية blob ممكنة بواسطة NFS، لا يمكن تحرير الملف إلا بنفس البروتوكول المستخدم عند إنشائه. أي أنه إذا كنت تستخدم واجهة برمجة تطبيقات Azure REST لملء حاوية، فلا يمكنك استخدام NFS لتحديث هذه الملفات. نظرا لأن Azure HPC Cache يستخدم NFS فقط، فلا يمكنه تحرير أي ملفات تم إنشاؤها باستخدام واجهة برمجة تطبيقات Azure REST. (مزيد من المعلومات حول المشكلات المعروفة في واجهات برمجة تطبيقات تخزين blob)
إنها ليست مشكلة بالنسبة لذاكرة التخزين المؤقت إذا كانت الحاوية فارغة ، أو إذا تم إنشاء الملفات باستخدام NFS.
إذا تم إنشاء الملفات الموجودة في الحاوية باستخدام واجهة برمجة تطبيقات Azure Blob REST بدلا من 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.
تستخدم نماذج الاستخدام هذه التخزين المؤقت للقراءة فقط:
- قراءة الكتابات الكثيفة والنادرة
- يكتب العملاء إلى هدف NFS ، متجاوزين ذاكرة التخزين المؤقت
- قراءة كثيفة، والتحقق من دعم الخادم كل 3 ساعات
يمكنك استخدام نماذج الاستخدام هذه مع الملفات التي تم إنشاؤها بواسطة واجهة برمجة تطبيقات REST أو بواسطة NFS. ستظل أي عمليات كتابة NFS مرسلة من عميل إلى حاوية الواجهة الخلفية تفشل، ولكنها ستفشل على الفور وتعيد رسالة خطأ إلى العميل.
لا يزال بإمكان سير عمل التخزين المؤقت للقراءة تضمين تغييرات في الملف، طالما لم يتم تخزينها مؤقتا. على سبيل المثال، قد يتمكن العملاء من الوصول إلى الملفات من الحاوية ولكنهم يكتبون تغييراتهم مرة أخرى كملف جديد، أو يمكنهم حفظ الملفات المعدلة في موقع مختلف.
التعرف على قيود إدارة قفل الشبكة (NLM)
لا تدعم حاويات blob التي تدعم NFS Network Lock Manager (NLM) ، وهو بروتوكول NFS شائع الاستخدام لحماية الملفات من التعارضات.
إذا كان سير عمل NFS مكتوبا في الأصل لأنظمة تخزين الأجهزة، فقد تتضمن تطبيقات العميل طلبات NLM. للتغلب على هذا القيد عند نقل العملية إلى وحدة تخزين blob التي تدعم NFS، تأكد من قيام عملائك بتعطيل NLM عند تحميل ذاكرة التخزين المؤقت.
لتعطيل NLM، استخدم الخيار -o nolock الموجود في أمر عملائك mount . يمنع هذا الخيار العملاء من طلب أقفال NLM وتلقي الأخطاء استجابة لذلك. nolock يتم تنفيذ الخيار بشكل مختلف في أنظمة التشغيل المختلفة ؛ تحقق من وثائق نظام التشغيل العميل (man 5 nfs) للحصول على التفاصيل.
تبسيط عمليات الكتابة إلى الحاويات التي تدعم NFS باستخدام ذاكرة التخزين المؤقت HPC
يمكن أن تساعد ذاكرة التخزين المؤقت ل Azure HPC في تحسين الأداء في عبء العمل الذي يتضمن كتابة التغييرات على هدف تخزين ADLS-NFS.
ملاحظة
يجب عليك استخدام NFS لملء حاوية تخزين ADLS-NFS إذا كنت تريد تعديل ملفاتها من خلال ذاكرة التخزين المؤقت ل Azure HPC.
أحد القيود الموضحة في مقالة اعتبارات أداء blob التي تدعم NFS هو أن تخزين ADLS-NFS ليس فعالا جدا في الكتابة فوق الملفات الموجودة. إذا كنت تستخدم ذاكرة التخزين المؤقت ل Azure HPC مع وحدة تخزين blob المثبتة على NFS، فإن ذاكرة التخزين المؤقت تعالج عمليات إعادة الكتابة المتقطعة بينما يقوم العملاء بتعديل ملف نشط. يتم إخفاء زمن انتقال كتابة ملف إلى حاوية النهاية الخلفية عن العملاء.
ضع في اعتبارك القيود الموضحة أعلاه في بيانات التحميل المسبق باستخدام بروتوكول NFS.