فهم أنواع تأمين الملفات وتأمينها في Azure NetApp Files

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

أنواع الأقفال

هناك عدة أنواع من أقفال NFS، والتي تتضمن:

التأمينات المشتركة: يمكن استخدام التأمينات المشتركة بواسطة عمليات متعددة في نفس الوقت ولا يمكن إصدارها إلا إذا لم تكن هناك تأمينات حصرية على ملف. هذه التأمينات مخصصة لعمل للقراءة فقط ولكن يمكن استخدامها للكتابات (مثل مع قاعدة بيانات).

التأمين الحصري: تعمل الأقفال الحصرية بنفس عمليات التأمين الحصرية في CIFS/SMB: يمكن لعملية واحدة فقط استخدام الملف عند وجود تأمين حصري. إذا قامت أي عمليات أخرى بتأمين الملف، فلا يمكن إصدار تأمين حصري ما لم يتم نسخ هذه العملية.

التفويضات: يتم استخدام التفويضات فقط مع NFSv4.x ويتم تعيينها عند تمكين خيارات خادم NFS ويدعم العميل تفويضات NFSv4.x. توفر الوفود طريقة لتخزين العمليات مؤقتا على جانب العميل عن طريق إنشاء تأمين "ناعم" للملف الذي يستخدمه العميل. يؤدي هذا إلى تحسين أداء أحمال عمل معينة عن طريق تقليل عدد الاستدعاءات بين العميل والخادم وهي مشابهة لأقفال SMB الانتهازية. لا تدعم ملفات Azure NetApp حاليا تفويضات NFSv4.x.

تأمينات نطاق البايت: بدلا من تأمين ملف بأكمله، يتم تأمين نطاق البايت فقط لجزء من الملف.

يعتمد سلوك التأمين على نوع التأمين وإصدار نظام تشغيل العميل وإصدار NFS المستخدم. تأكد من اختبار التأمين في بيئتك لقياس السلوك المتوقع.

تأمين NFSv3

يستخدم NFSv3 بروتوكولات إضافية مثل Network Lock Manager (NLM) وNetwork Status Monitor (NSM) لتنسيق تأمين الملفات بين عميل NFS والخادم. يتم تعريف هذه البروتوكولات المساعدة في RFC-1813، والتي تلتزم بها Azure NetApp Files.

يساعد NLM في إنشاء تأمينات وتحريرها، بينما تقوم NSM بإعلام نظراء عمليات إعادة تشغيل الخادم. مع تأمين NFSv3، عند إعادة تشغيل العميل، يجب على الخادم تحرير التأمينات. عند إعادة تشغيل الخادم، يذكر العميل الخادم بالأقفال التي يحتفظ بها

إشعار

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

تأمين NFSv4.x

يستخدم NFSv4.x نموذج تأمين قائم على التأجير مدمج ضمن بروتوكول NFS. وهذا يعني أنه لا توجد خدمات إضافية للحفاظ عليها أو القلق بشأنها؛ يتم تغليف جميع التأمين في اتصال NFSv4.x.

تدعم Azure NetApp Files آلية تأمين الملفات NFSv4.x، مع الحفاظ على حالة جميع أقفال الملفات ضمن نموذج قائم على التأجير. وفقا ل RFC 8881، ستقوم Azure NetApp Files "بتحديد فترة تأجير واحدة لجميع الحالات التي يحتفظ بها عميل NFS. إذا لم يجدد العميل عقد التأجير الخاص به خلال الفترة المحددة، فقد يتم تحرير جميع الحالة المقترنة بعقد إيجار العميل من قبل الخادم."

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

المصطلح التعريف
الإيجار الفترة الزمنية التي تمنح فيها Azure NetApp Files تأمينا لعميل بشكل لا رجعة فيه.
فترة السماح الفترة الزمنية التي يحاول فيها العملاء استعادة حالة التأمين الخاصة بهم أثناء استرداد الخادم في حالة انقطاع الخادم.

كيف تعالج Azure NetApp Files عمليات تأمين NFSv4.x

يتم إصدار التأمينات بواسطة Azure NetApp Files بناء على طلب العميل على أساس التأجير. يتحقق خادم Azure NetApp Files من التأجير على كل عميل كل 30 ثانية للتغييرات. في حالة إعادة تشغيل العميل، يمكن للعميل استعادة جميع التأمينات الصالحة من الخادم بعد إعادة تشغيله. إذا تم إعادة تشغيل خادم Azure NetApp Files، فلن يصدر عند إعادة التشغيل أي تأمينات جديدة للعملاء لفترة سماح مدتها 45 ثانية. بعد ذلك الوقت، يمكن إصدار الأقفال للعملاء الطالبين. إذا تعذر إعادة تأسيس التأمين خلال فترة السماح المحددة، تنتهي صلاحية التأمين من تلقاء نفسه. يختلف هذا السلوك عن تأمين NFSv3، حيث لن تكون هناك أقفال قديمة تحتاج إلى كسر يدويا.

إنشاء الأقفال يدويا على عميل

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

ومع ذلك، هناك أدوات مساعدة لإنشاء الأقفال يدويا. على سبيل المثال، يمكن ل flock تأمين الملفات.

لإنشاء تأمين على ملف، قم أولا بتشغيل exec لتعيين معرف رقمي.

# exec 4<>v4user_file

استخدم flock لإنشاء تأمين مشترك أو حصري على الملف.

# flock

Usage:
 flock [options] <file|directory> <command> [command args]
 flock [options] <file|directory> -c <command>
 flock [options] <file descriptor number>

Options:
 -s  --shared             get a shared lock
 -x  --exclusive          get an exclusive lock (default)
 -u  --unlock             remove a lock
 -n  --nonblock           fail rather than wait
 -w  --timeout <secs>     wait for a limited amount of time
 -E  --conflict-exit-code <number>  exit code after conflict or timeout
 -o  --close              close file descriptor before running command
 -c  --command <command>  run a single command string through the shell

 -h, --help     display this help and exit
 -V, --version  output version information and exit

# flock -n 4

لإلغاء تأمين الملف.

# flock -u -n 4

يسمح لك تأمين الملفات يدويا باختبار فتح الملفات وتحرير التفاعلات واختبار وظيفة تعطل التأمين في Azure NetApp Files.

الخطوات التالية