استكشاف أخطاء تكوين NAS ومشكلات هدف تخزين NFS وإصلاحها

مقالة
06/01/2023

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

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

تلميح

قبل استخدام هذا الدليل، اقرأ المتطلبات الأساسية لأهداف تخزين NFS.

إذا لم يتم تضمين حل مشكلتك هنا، فالرجاء فتح تذكرة دعم حتى تتمكن خدمة Microsoft والدعم من العمل معك للتحقيق في المشكلة وحلها.

توفير مؤشرات ترابط اتصال كافية

تقوم أنظمة HPC Cache الكبيرة بإجراء طلبات اتصال متعددة بهدف تخزين. على سبيل المثال، إذا كان هدف التخزين الخاص بك يستخدم الوحدة النمطية Ubuntu Linux nfs-kernel-server ، يمكن أن يكون العدد الافتراضي لمؤشرات ترابط البرنامج الخفي NFS منخفضا حتى ثمانية. قم بزيادة عدد مؤشرات الترابط إلى 128 أو 256، وهي أرقام أكثر منطقية لدعم ذاكرة التخزين المؤقت للحوسبة عالية الأداء متوسطة أو كبيرة.

يمكنك التحقق من عدد مؤشرات الترابط في Ubuntu أو تعيينها باستخدام قيمة RPCNFSDCOUNT في /etc/init.d/nfs-kernel-server.

التحقق من إعدادات المنفذ

يحتاج Azure HPC Cache إلى الوصول للقراءة/الكتابة إلى العديد من منافذ UDP/TCP على نظام تخزين NAS الخلفي. تأكد من إمكانية الوصول إلى هذه المنافذ على نظام NAS وأيضا السماح بنسبة استخدام الشبكة إلى هذه المنافذ من خلال أي جدران حماية بين نظام التخزين والشبكة الفرعية لذاكرة التخزين المؤقت. قد تحتاج إلى العمل مع جدار الحماية ومسؤولي الشبكة لمركز البيانات للتحقق من هذا التكوين.

تختلف المنافذ لأنظمة التخزين من موردين مختلفين، لذا تحقق من متطلبات النظام عند إعداد هدف تخزين.

بشكل عام، تحتاج ذاكرة التخزين المؤقت إلى الوصول إلى هذه المنافذ:

بروتوكول	المنفذ	الخدمة
TCP/UDP	111	rpcbind
TCP/UDP	2049	NFS
TCP/UDP	4045	nlockmgr
TCP/UDP	4046	مثبتة
TCP/UDP	4047	الحالة

لمعرفة المنافذ المحددة المطلوبة لنظامك، استخدم الأمر التالي rpcinfo . يسرد هذا الأمر أدناه المنافذ وينسق النتائج ذات الصلة في جدول. (استخدم عنوان IP لنظامك بدلا من <> مصطلح storage_IP.)

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

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

تأكد من أن جميع المنافذ التي تم إرجاعها بواسطة rpcinfo الاستعلام تسمح بنسبة استخدام الشبكة غير المقيدة من الشبكة الفرعية ل Azure HPC Cache.

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

تحقق من إعدادات squash الجذر

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

يمنع squash الجذر الطلبات المرسلة من قبل جذر المستخدم الفائق المحلي على العميل من إرسالها إلى نظام تخزين خلفي كجذر. يعيد تعيين الطلبات من الجذر إلى معرف مستخدم غير مميز (UID) مثل "لا أحد".

تلميح

كانت الإصدارات السابقة من Azure HPC Cache تتطلب أنظمة تخزين NAS للسماح بالوصول الجذر من HPC Cache. الآن، لا تحتاج إلى السماح بالوصول الجذر على تصدير هدف التخزين إلا إذا كنت تريد أن يكون لعملاء HPC Cache حق الوصول الجذر إلى التصدير.

يمكن تكوين الجذر squash في نظام HPC Cache في هذه الأماكن:

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

لا يقوم نهج وصول العميل الافتراضي بسحق الجذر.
في تصدير التخزين - يمكنك تكوين نظام التخزين الخاص بك لإعادة تعيين الطلبات الواردة من الجذر إلى معرف مستخدم غير مميز (UID).

إذا كان نظام التخزين الخاص بك يصدر جذر squashes، يجب تحديث قاعدة وصول عميل HPC Cache لهدف التخزين هذا إلى جذر squash أيضا. إذا لم يكن الأمر كما هو، فقد تواجه مشكلات في الوصول عند محاولة القراءة أو الكتابة إلى نظام التخزين الخلفي من خلال HPC Cache.

يوضح هذا الجدول سلوك سيناريوهات squash الجذر المختلفة عند إرسال طلب عميل ك UID 0 (الجذر). لا ينصح بالسيناريو المميز ب * لأنه يمكن أن يسبب مشاكل في الوصول.

الإعدادات	UID المرسل من HPC Cache	معرف UID فعال على التخزين الخلفي
لا يوجد جذر squash	0 (جذر)	0 (جذر)
سحق الجذر في HPC Cache فقط	65534 (لا أحد)	65534 (لا أحد)
*الجذر squash في تخزين NAS فقط	0 (جذر)	65534 (لا أحد)
الجذر squash في HPC Cache و NAS	65534 (لا أحد)	65534 (لا أحد)

(UID 65534 هو مثال؛ عند تشغيل squash الجذر في نهج وصول العميل يمكنك تخصيص UID.)

التحقق من الوصول إلى مسارات الدليل

بالنسبة لأنظمة NAS التي تقوم بتصدير الدلائل الهرمية، تحقق من أن Azure HPC Cache لديه حق الوصول المناسب إلى كل مستوى تصدير في المسار إلى الملفات التي تستخدمها.

على سبيل المثال، قد يعرض النظام ثلاث عمليات تصدير مثل هذه:

/ifs
/ifs/accounting
/ifs/accounting/payroll

التصدير /ifs/accounting/payroll هو تابع ل /ifs/accounting، وهو /ifs/accounting في حد ذاته تابع ل /ifs.

إذا أضفت payroll التصدير كهدف تخزين HPC Cache، فإن ذاكرة التخزين المؤقت تقوم بالفعل بتحميل /ifs/ دليل كشف المرتبات والوصول إليه من هناك. لذلك يحتاج Azure HPC Cache إلى وصول كاف إلى /ifs من أجل الوصول إلى /ifs/accounting/payroll التصدير.

يرتبط هذا المطلب بالطريقة التي تقوم بها ذاكرة التخزين المؤقت بفهرسة الملفات وتجنب تضارب الملفات، باستخدام مقابض الملفات التي يوفرها نظام التخزين.

يمكن لنظام NAS مع عمليات تصدير هرمية إعطاء مقابض ملفات مختلفة لنفس الملف إذا تم استرداد الملف من عمليات تصدير مختلفة. على سبيل المثال، يمكن للعميل تحميل /ifs/accounting الملف payroll/2011.txtوالوصول إليه . يقوم عميل آخر بتحميل /ifs/accounting/payroll الملف 2011.txtوالوصول إليه . اعتمادا على كيفية تعيين نظام التخزين لمقابض الملفات، قد يتلقى هذان العميلان نفس الملف مع مقابض ملفات مختلفة (واحد ل <mount2>/payroll/2011.txt وواحد ل <mount3>/2011.txt).

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

لتجنب تضارب الملفات المحتمل هذا مع الملفات في عمليات تصدير متعددة، يقوم Azure HPC Cache تلقائيا بتحميل التصدير المتوفر الضحل في المسار (/ifs في المثال) ويستخدم مقبض الملف المحدد من هذا التصدير. إذا كانت عمليات التصدير المتعددة تستخدم نفس المسار الأساسي، فإن Azure HPC Cache يحتاج إلى الوصول إلى هذا المسار.

ضبط قيود حجم حزمة VPN

إذا كان لديك VPN بين ذاكرة التخزين المؤقت وجهاز NAS الخاص بك، فقد تحظر VPN حزم Ethernet كاملة الحجم بحجم 1500 بايت. قد تواجه هذه المشكلة إذا لم تكتمل عمليات التبادل الكبيرة بين NAS ومثيل Azure HPC Cache، ولكن تعمل التحديثات الأصغر كما هو متوقع.

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

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

قم بتشغيل أمر اتصال عبر VPN إلى NAS باستخدام هذه الخيارات. (استخدم عنوان IP لنظام التخزين بدلا من <> قيمة storage_IP.)
```
ping -M do -s 1472 -c 1 <storage_IP>
```
هذه هي الخيارات في الأمر:
- -M do - عدم التجزئة
- -c 1 - إرسال حزمة واحدة فقط
- -s 1472 - تعيين حجم الحمولة إلى 1472 بايت. هذه هي حمولة الحجم الأقصى لحزمة بيانات 1500 بايت بعد محاسبة حمل Ethernet.
يبدو أن الاستجابة الناجحة هي:
```
PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms
```
إذا فشل اختبار الاتصال ب 1472 بايت، فمن المحتمل أن تكون هناك مشكلة في حجم الحزمة.

لإصلاح المشكلة، قد تحتاج إلى تكوين تضييق MSS على VPN لجعل النظام البعيد يكشف بشكل صحيح عن الحد الأقصى لحجم الإطار. اقرأ وثائق معلمات بوابة VPN IPsec/IKE لمعرفة المزيد.

في بعض الحالات، يمكن أن يساعد تغيير إعداد MTU ل Azure HPC Cache إلى 1400. ومع ذلك، إذا قمت بتقييد MTU على ذاكرة التخزين المؤقت، يجب عليك أيضا تقييد إعدادات MTU للعملاء وأنظمة التخزين الخلفية التي تتفاعل مع ذاكرة التخزين المؤقت. اقرأ تكوين إعدادات Azure HPC Cache إضافية للحصول على التفاصيل.

التحقق من نمط أمان ACL

تستخدم بعض أنظمة NAS نمط أمان مختلط يجمع بين قوائم التحكم في الوصول (ACLs) وأمان POSIX أو UNIX التقليدي.

إذا أبلغ النظام عن نمط الأمان الخاص به ك UNIX أو POSIX دون تضمين اختصار "ACL"، فلن تؤثر هذه المشكلة عليك.

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

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

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

Share via