مشاركة عبر

أفضل الممارسات لخيارات تثبيت Linux NFS لـAzure NetApp Files

  • مقالة

تساعدك هذه المقالة على فهم خيارات التحميل وأفضل الممارسات لاستخدامها مع Azure NetApp Files.

Nconnect

nconnect يتيح لك استخدام خيار التحميل تحديد عدد الاتصالات (تدفقات الشبكة) التي يجب إنشاؤها بين عميل NFS ونقطة نهاية NFS حتى حد 16. تقليديا، يستخدم عميل NFS اتصالا واحدا بينه وبين نقطة النهاية. من خلال زيادة عدد تدفقات الشبكة، تزداد الحدود العليا من الإدخال/الإخراج ومعدل النقل بشكل كبير. وقد وجد nconnect=8 أن الاختبار هو الأكثر أداء.

عند إعداد بيئة SAS GRID متعددة العقد للإنتاج، قد تلاحظ انخفاضا متكررا بنسبة 30٪ في وقت التشغيل من 8 ساعات إلى 5.5 ساعات:

خيار التحميل أوقات تشغيل المهمة
لا nconnect ثمان ساعات
nconnect=8 5.5 ساعات

استخدمت مجموعتا الاختبارات نفس الجهاز الظاهري E32-8_v4 و RHEL8.3، مع تعيين القراءة المسبقة إلى 15 ميبي بايت.

عند استخدام nconnect، ضع القواعد التالية في الاعتبار:

  • nconnect مدعوم من قبل Azure NetApp Files على جميع توزيعات Linux الرئيسية ولكن فقط على الإصدارات الأحدث:

    إصدار Linux NFSv3 (الحد الأدنى للإصدار) NFSv4.1 (الحد الأدنى للإصدار)
    Redhat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 أو SLES15SP1 SLES15SP2
    Ubuntu Ubuntu18.04

    إشعار

    SLES15SP2 هو الحد الأدنى لإصدار SUSE الذي nconnect تدعمه Azure NetApp Files ل NFSv4.1. جميع الإصدارات الأخرى كما هو محدد هي الإصدارات الأولى التي قدمت الميزة nconnect .

  • سترث nconnect كافة عمليات التحميل من نقطة نهاية واحدة إعداد التصدير الأول الذي تم تحميله، كما هو موضح في السيناريوهات التالية:

    السيناريو 1: nconnect يستخدمه التحميل الأول. لذلك، جميع عمليات التحميل مقابل نفس نقطة النهاية استخدام nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    السيناريو 2: nconnect لا يستخدمه التحميل الأول. لذلك، لا توجد عمليات تحميل مقابل نفس استخدام nconnect نقطة النهاية على الرغم من nconnect أنه قد يتم تحديدها في ذلك الوقت.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    السيناريو 3: nconnect لا يتم نشر الإعدادات عبر نقاط نهاية تخزين منفصلة. nconnect يستخدم من قبل جبل القادمة من 10.10.10.10 ولكن ليس من قبل جبل القادمة من 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect يمكن استخدامها لزيادة تزامن التخزين من أي عميل معين.

للحصول على التفاصيل، راجع أفضل ممارسات تزامن Linux ل Azure NetApp Files.

Nconnect الاعتبارات

لا ينصح باستخدام nconnect خيارات التحميل معا sec=krb5* . تمت ملاحظة انخفاض الأداء عند استخدام الخيارين معا.

توفر واجهة برمجة التطبيقات القياسية للأمان العامة (GSS-API) طريقة للتطبيقات لحماية البيانات المرسلة إلى تطبيقات النظير. قد يتم إرسال هذه البيانات من عميل على جهاز إلى خادم على جهاز آخر. 

عند nconnect استخدام في Linux، تتم مشاركة سياق أمان GSS بين جميع nconnect الاتصالات بخادم معين. TCP هو نقل موثوق به يدعم تسليم الحزمة خارج الطلب للتعامل مع الحزم خارج الطلب في دفق GSS، باستخدام نافذة منزلقة من أرقام التسلسل. عندما يتم تلقي الحزم غير الموجودة في نافذة التسلسل، يتم تجاهل سياق الأمان، ويتم التفاوض على سياق أمان جديد. لم تعد جميع الرسائل المرسلة مع في السياق المهمل الآن صالحة، وبالتالي تتطلب إرسال الرسائل مرة أخرى. يؤدي العدد الأكبر من الحزم في nconnect الإعداد إلى تكرار حزم البيانات خارج النافذة، مما يؤدي إلى السلوك الموضح. لا يمكن ذكر أي نسب مئوية معينة للتدهور مع هذا السلوك.

Rsize وWsize

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

تعين rsize العلامات و wsize الحد الأقصى لحجم النقل لعملية NFS. إذا تم rsize تحديد أو wsize لم يتم تحديده عند التحميل، يتفاوض العميل والخادم على أكبر حجم يدعمه الاثنين. حاليا، تدعم كل من ملفات Azure NetApp وتوزيعات Linux الحديثة أحجام القراءة والكتابة بحجم 1,048,576 بايت (1 ميبي بايت). ومع ذلك، للحصول على أفضل معدل نقل إجمالي وزمن انتقال، توصي Azure NetApp Files بتعيين كل rsize من ولا wsize يزيد عن 262144 بايت (256 K). قد تلاحظ أن كلا من زيادة زمن الانتقال وانخفاض معدل النقل عند استخدام rsizewsize أكبر من 256 KiB.

على سبيل المثال، نشر نظام توسيع SAP HANA مع عقدة الاستعداد على أجهزة Azure الظاهرية باستخدام Azure NetApp Files على SUSE Linux Enterprise Server يظهر 256-KiB rsize والحد wsize الأقصى كما يلي:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

على سبيل المثال، توصي SAS Viya بأحجام قراءة وكتابة 256 كيبيبايت، وSAS GRID تحد r/wsize من إلى 64 كيبيبايت مع زيادة أداء القراءة مع زيادة القراءة المسبقة لتركيبات NFS. راجع أفضل ممارسات قراءة NFS لملفات Azure NetApp للحصول على التفاصيل.

تنطبق الاعتبارات التالية على استخدام rsize و wsize:

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

كأفضل ممارسة مع Azure NetApp Files، للحصول على أفضل معدل نقل إجمالي وزمن انتقال، قم بتعيين rsizewsize ولا يزيد عن 262144 بايت.

تناسق إغلاق الفتح وموقتات سمة ذاكرة التخزين المؤقت

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

إذا كان لدى العميل ملكية كاملة للبيانات، أي أنه لا تتم مشاركته بين عقد أو أنظمة متعددة، فهناك تناسق مضمون. في هذه الحالة، يمكنك تقليل getattr عمليات الوصول إلى التخزين وتسريع التطبيق عن طريق إيقاف تشغيل التناسق القريب من الفتح (cto) (nocto كخيار تحميل) وعن طريق تشغيل المهلات لإدارة ذاكرة التخزين المؤقت للسمة (actimeo=600 حيث يغير خيار التحميل المؤقت إلى 10m مقابل الإعدادات الافتراضية acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). في بعض الاختبارات، nocto يقلل ما يقرب من 65-70٪ من getattr مكالمات الوصول، ويقلل ضبط actimeo هذه المكالمات 20-25٪ أخرى.

كيفية عمل مؤقتات ذاكرة التخزين المؤقت للسمات

تتحكم السمات acregminacregmaxacdirminو acdirmax في اتساق ذاكرة التخزين المؤقت. تتحكم السمتان السابقتان في مدة الثقة في سمات الملفات. تتحكم السمتان الأخيرتان في مدة الثقة في سمات ملف الدليل نفسه (حجم الدليل، ملكية الدليل، أذونات الدليل). min تحدد السمتان و max الحد الأدنى والحد الأقصى للمدة التي تعتبر سمات الدليل وسمات الملف ومحتوى ذاكرة التخزين المؤقت للملف جديرة بالثقة، على التوالي. بين min و max، يتم استخدام خوارزمية لتحديد مقدار الوقت الذي يتم فيه الوثوق بإدخال مخزن مؤقتا.

على سبيل المثال، ضع في اعتبارك القيمة الافتراضية acregminacregmax والقيم، 3 و30 ثانية، على التوالي. على سبيل المثال، يتم تقييم السمات بشكل متكرر للملفات في دليل. بعد 3 ثوان، يتم الاستعلام عن خدمة NFS للحصول على حداثة. إذا اعتبرت السمات صالحة، يضاعف العميل الوقت الموثوق به إلى 6 ثوان، 12 ثانية، 24 ثانية، ثم يتم تعيين الحد الأقصى إلى 30، 30 ثانية. من تلك النقطة فصاعدا، حتى يتم اعتبار السمات المخزنة مؤقتا قديمة (عند هذه النقطة تبدأ الدورة من جديد)، يتم تعريف الجدارة بالثقة على أنها 30 ثانية كونها القيمة المحددة بواسطة acregmax.

هناك حالات أخرى يمكن أن تستفيد من مجموعة مماثلة من خيارات التحميل، حتى عندما لا يكون هناك ملكية كاملة من قبل العملاء، على سبيل المثال، إذا كان العملاء يستخدمون البيانات للقراءة فقط وتتم إدارة تحديث البيانات من خلال مسار آخر. بالنسبة للتطبيقات التي تستخدم شبكات العملاء مثل EDA واستضافة الويب وعرض الأفلام ولديها مجموعات بيانات ثابتة نسبيا (أدوات أو مكتبات EDA ومحتوى الويب وبيانات المادة)، فإن السلوك النموذجي هو تخزين مجموعة البيانات مؤقتا إلى حد كبير على العملاء. هناك عدد قليل من القراءات ولا توجد كتابات. سيكون هناك العديد من getattrاستدعاءات /access التي تعود إلى التخزين. يتم تحديث مجموعات البيانات هذه عادة من خلال عميل آخر يقوم بتحميل أنظمة الملفات ودفع تحديثات المحتوى بشكل دوري.

في هذه الحالات، هناك تأخير معروف في التقاط المحتوى الجديد ولا يزال التطبيق يعمل مع البيانات التي يحتمل أن تكون قديمة. في هذه الحالات، noctoactimeo ويمكن استخدامه للتحكم في الفترة التي يمكن فيها إدارة تاريخ نفاد البيانات. على سبيل المثال، في أدوات ومكتبات EDA، actimeo=600 تعمل بشكل جيد لأن هذه البيانات عادة ما يتم تحديثها بشكل غير متكرر. بالنسبة لاستضافة الويب الصغيرة حيث يحتاج العملاء إلى رؤية تحديثات البيانات الخاصة بهم في الوقت المناسب أثناء تحرير مواقعهم، actimeo=10 قد يكون مقبولا. بالنسبة لمواقع الويب واسعة النطاق حيث يتم دفع المحتوى إلى أنظمة ملفات متعددة، actimeo=60 قد يكون مقبولا.

يؤدي استخدام خيارات التحميل هذه إلى تقليل حمل العمل إلى التخزين بشكل كبير في هذه الحالات. (على سبيل المثال، أدت تجربة EDA الأخيرة إلى تقليل عمليات الإدخال/الإخراج في الثانية إلى حجم الأداة من >150 كيلو بايت إلى ~6 كيلوبايت) يمكن تشغيل التطبيقات بشكل أسرع بكثير لأنها يمكن أن تثق في البيانات في الذاكرة. (وقت الوصول إلى الذاكرة هو nanoseconds مقابل مئات ميكرو ثانية ل getattr/access على شبكة سريعة.)

تناسق قريب من الفتح

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

  • عند تتبع ارتباطات دليل (lsعلى ls -l سبيل المثال) يتم إصدار مجموعة معينة من RPCs (استدعاءات الإجراء البعيد).
    يشارك خادم NFS طريقة عرضه لنظام الملفات. طالما cto يتم استخدام من قبل جميع عملاء NFS الذين يصلون إلى تصدير NFS معين، سيرى جميع العملاء نفس قائمة الملفات والدلائل الموجودة فيها. يتم التحكم في حداثة سمات الملفات في الدليل بواسطة مؤقتات ذاكرة التخزين المؤقت للسمة. بمعنى آخر، طالما cto يتم استخدامه، تظهر الملفات للعملاء البعيدين بمجرد إنشاء الملف ووصول الملف إلى التخزين.
  • عند فتح ملف، يتم ضمان محتوى الملف حديثا من منظور خادم NFS.
    إذا كان هناك حالة تعارض حيث لم ينته المحتوى من المسح من الجهاز 1 عند فتح ملف على الجهاز 2، فسيتلقى الجهاز 2 فقط البيانات الموجودة على الخادم في وقت الفتح. في هذه الحالة، لن يقوم الجهاز 2 باسترداد المزيد من البيانات من الملف حتى acreg يتم الوصول إلى المؤقت، ويتحقق الجهاز 2 من اتساق ذاكرة التخزين المؤقت الخاصة به من الخادم مرة أخرى. يمكن ملاحظة هذا السيناريو باستخدام ذيل -f من الجهاز 2 عند استمرار كتابة الملف من الجهاز 1.

لا يوجد تناسق قريب من الفتح

عند عدم استخدام أي تناسق قريب من الفتح (nocto)، سيثق العميل في حداثة طريقة العرض الحالية للملف والدليل حتى يتم خرق مؤقتات سمة ذاكرة التخزين المؤقت.

  • عند تتبع ارتباطات دليل (lsعلى ls -l سبيل المثال) يتم إصدار مجموعة معينة من RPCs (استدعاءات الإجراء البعيد).
    سيصدر العميل فقط استدعاء إلى الخادم للحصول على قائمة حالية بالملفات عند acdir خرق قيمة مؤقت ذاكرة التخزين المؤقت. في هذه الحالة، لن تظهر الملفات والدلائل التي تم إنشاؤها مؤخرا وستظل الملفات والدلائل التي تمت إزالتها مؤخرا تظهر.

  • عند فتح ملف، طالما أن الملف لا يزال في ذاكرة التخزين المؤقت، يتم إرجاع المحتوى المخزن مؤقتا (إن وجد) دون التحقق من التناسق مع خادم NFS.

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