مشاركة عبر

أفضل ممارسات تزامن Linux لملفات Azure NetApp - فتحات الجلسة وإدخالات جدول الفتحات

  • مقالة

تساعدك هذه المقالة على فهم أفضل ممارسات التزامن لفتحات الجلسة وإدخالات جدول الفتحات لبروتوكول Azure NetApp Files NFS.

NFSv3

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

بشكل افتراضي، تحدد نواة Linux الحديثة حجم sunrpc.tcp_max_slot_table_entries إدخال الجدول لكل فتحة اتصال sunrpc على أنه يدعم 65536 عملية معلقة، كما هو موضح في الجدول التالي.

خادم NFSv3 لملفات Azure NetApp
الحد الأقصى لسياقات التنفيذ لكل اتصال		 عميل Linux
الحد الأقصى sunrpc الافتراضي لإدخالات جدول الفتحة لكل اتصال
128 65,536

تحدد إدخالات جدول الفتحة هذه حدود التزامن. قيم هذا الارتفاع غير ضرورية. على سبيل المثال، باستخدام نظرية قائمة الانتظار المعروفة باسم Littles Law، ستجد أن معدل الإدخال/الإخراج يتم تحديده بواسطة التزامن (أي الإدخال/الإخراج المعلق) وزمن الانتقال. على هذا النحو، تثبت الخوارزمية أن 65536 فتحة هي أوامر ذات حجم أعلى مما هو مطلوب لدفع أحمال العمل حتى شديدة الطلب.

Littles Law: (concurrency = operation rate × latency in seconds)

يعد مستوى التزامن منخفضا حتى 155 كافيا لتحقيق 155000 عملية Oracle DB NFS في الثانية باستخدام Oracle Direct NFS، وهي تقنية مشابهة من حيث المفهوم لخيار nconnect التحميل:

  • بالنظر إلى زمن انتقال يبلغ 0.5 مللي ثانية، يلزم وجود تزامن قدره 55 لتحقيق 110,000 IOPS.
  • بالنظر إلى زمن انتقال يبلغ 1 مللي ثانية، يلزم وجود تزامن قدره 155 لتحقيق 155000 IOPS.

Oracle DNFS latency curve

راجع أداء قاعدة بيانات Oracle على وحدات التخزين الفردية لملفات Azure NetApp للحصول على التفاصيل.

sunrpc.tcp_max_slot_table_entries الضبط هو معلمة ضبط على مستوى الاتصال. كأفضل ممارسة، قم بتعيين هذه القيمة إلى 128 أو أقل لكل اتصال، وليس تجاوز 10000 فتحة عرض البيئة.

أمثلة على عدد الفتحات استنادا إلى توصية التزامن

توضح الأمثلة في هذا القسم عدد الفتحات استنادا إلى توصية التزامن.

مثال 1 - عميل NFS واحد، 65536 sunrpc.tcp_max_slot_table_entries، ولا nconnect للتزامن الأقصى البالغ 128 استنادا إلى الحد الأقصى من جانب الخادم وهو 128

يستند المثال 1 إلى حمل عمل عميل واحد بالقيمة الافتراضية sunrpc.tcp_max_slot_table_entry 65536 واتصال شبكة واحد، أي لا nconnect. في هذه الحالة، يمكن تحقيق تزامن 128.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • من الناحية النظرية، لا يمكن للعميل إصدار أكثر من 65536 طلبا في الرحلة إلى الخادم لكل اتصال.
      • لن يقبل الخادم أكثر من 128 طلب في الرحلة من هذا الاتصال الفردي.

مثال 2 - عميل NFS واحد، 128 sunrpc.tcp_max_slot_table_entries، ولا nconnect لتزامن أقصى يبلغ 128

يستند المثال 2 إلى حمل عمل عميل واحد بقيمة sunrpc.tcp_max_slot_table_entry 128، ولكن بدون nconnect خيار التحميل. باستخدام هذا الإعداد، يمكن تحقيق تزامن 128 من اتصال شبكة واحدة.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • لن يصدر العميل أكثر من 128 طلبا في الرحلة إلى الخادم لكل اتصال.
      • لن يقبل الخادم أكثر من 128 طلب في الرحلة من هذا الاتصال الفردي.

مثال 3 - عميل NFS واحد، 100 sunrpc.tcp_max_slot_table_entries، ولحد nconnect=8 أقصى للتزامن يبلغ 800

يستند المثال 3 إلى حمل عمل عميل واحد، ولكن بقيمة أقل sunrpc.tcp_max_slot_table_entry من 100. هذه المرة، nconnect=8 استخدم خيار التحميل نشر حمل العمل عبر اتصال 8. مع هذا الإعداد، يمكن تحقيق تزامن 800 عبر 8 اتصالات. هذا المبلغ هو التزامن اللازم لتحقيق 400,000 IOPS.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)
    • الاتصال ion 1
      • لن يصدر العميل أكثر من 100 طلب في الرحلة إلى الخادم من هذا الاتصال.
      • من المتوقع أن يقبل الخادم ما لا يزيد عن 128 طلبا في الرحلة من العميل لهذا الاتصال.
    • الاتصال 2
      • لن يصدر العميل أكثر من 100 طلب في الرحلة إلى الخادم من هذا الاتصال.
      • من المتوقع أن يقبل الخادم ما لا يزيد عن 128 طلبا في الرحلة من العميل لهذا الاتصال.
    • …
    • …
    • الاتصال ion 8
      • لن يصدر العميل أكثر من 100 طلب في الرحلة إلى الخادم من هذا الاتصال.
      • من المتوقع أن يقبل الخادم ما لا يزيد عن 128 طلبا في الرحلة من العميل لهذا الاتصال.

مثال 4 - 250 عميل NFS، 8 sunrpc.tcp_max_slot_table_entries، ولا nconnect للحد الأقصى للتزامن 2000

يستخدم المثال 4 القيمة المخفضة لكل عميل sunrpc.tcp_max_slot_table_entry من 8 لبيئة EDA 250 حساب آلي. في هذا السيناريو، يتم الوصول إلى تزامن عام 2000 على مستوى البيئة، وهي قيمة أكثر من كافية لدفع 4000 ميجابايت/ثانية من حمل عمل EDA الخلفي.

  • NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • لن يصدر العميل أكثر من 8 طلبات في الرحلة إلى الخادم لكل اتصال.
      • لن يقبل الخادم أكثر من 128 طلب في الرحلة من هذا الاتصال الفردي.
  • NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12
    • Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)
      • لن يصدر العميل أكثر من 8 طلبات في الرحلة إلى الخادم لكل اتصال.
      • لن يقبل الخادم أكثر من 128 طلب في الرحلة من هذا الاتصال الفردي.
  • …
  • …
  • NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13
    • Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)
      • لن يصدر العميل أكثر من 8 طلبات في الرحلة إلى الخادم لكل اتصال.
      • لن يقبل الخادم أكثر من 128 طلب في الرحلة من هذا الاتصال الفردي.

عند استخدام NFSv3، يجب عليك بشكل جماعي الاحتفاظ بعدد فتحات نقطة نهاية التخزين إلى 10000 أو أقل. من الأفضل تعيين قيمة لكل اتصال إلى sunrpc.tcp_max_slot_table_entries أقل من 128 عندما يتم توسيع نطاق التطبيق عبر العديد من اتصالات الشبكة (nconnect وHPC بشكل عام، وEDA على وجه الخصوص).

كيفية حساب الأفضل sunrpc.tcp_max_slot_table_entries

باستخدام Littles Law، يمكنك حساب إجمالي عدد إدخالات جدول الفتحة المطلوب. بشكل عام، ضع في اعتبارك العوامل التالية:

  • غالبا ما تكون أحمال العمل واسعة النطاق ذات طبيعة متسلسلة كبيرة بشكل مهيمن.
  • غالبا ما تكون أحمال عمل قاعدة البيانات، خاصة OLTP، عشوائية في طبيعتها.

يوضح الجدول التالي عينة من دراسة التزامن مع زمن الانتقال العشوائي المتوفر:

حجم الإدخال/الإخراج زمن الانتقال الإدخال/إخراج أو معدل النقل التزامن
8 كيبيبايت 0.5 مللي ثانية 110,000 IOPS | 859 ميبي بايت/ثانية 55
8 كيبيبايت 2 مللي ثانية 400,000 IOPS | 3,125 ميبي بايت/ثانية 800
256 كيبيبايت 2 مللي ثانية 16,000 IOPS | 4000 ميجابايت/ثانية 32
256 كيبيبايت 4 مللي ثانية 32,000 IOPS | 8000 ميجابايت/ ثانية 128

كيفية حساب إعدادات التزامن حسب عدد الاتصالات

على سبيل المثال، إذا كان حمل العمل عبارة عن مزرعة EDA و1250 عميلا، فدفع حمل العمل إلى نفس نقطة نهاية التخزين (نقطة نهاية التخزين هي عنوان IP للتخزين)، يمكنك حساب معدل الإدخال/الإخراج المطلوب وتقسيم التزامن عبر المزرعة.

افترض أن حمل العمل هو 4000 ميجابايت/ ثانية باستخدام متوسط حجم العملية 256-KiB ومتوسط زمن انتقال 10 مللي ثانية. لحساب التزامن، استخدم الصيغة التالية:

(concurrency = operation rate × latency in seconds)

يترجم الحساب إلى تزامن 160:

(160 = 16,000 × 0.010)

نظرا للحاجة إلى 1250 عميلا، يمكنك تعيين sunrpc.tcp_max_slot_table_entries بأمان إلى 2 لكل عميل للوصول إلى 4000 ميجابايت/ثانية. ومع ذلك، قد تقرر البناء في غرفة رأس إضافية عن طريق تعيين الرقم لكل عميل إلى 4 أو حتى 8، مع الحفاظ على أقل بكثير من سقف الفتحة الموصى به البالغ 10000.

كيفية التعيين sunrpc.tcp_max_slot_table_entries على العميل

  1. أضف sunrpc.tcp_max_slot_table_entries=<n> إلى /etc/sysctl.conf ملف التكوين.
    أثناء الضبط، إذا تم العثور على قيمة أقل من 128 مثالية، فاستبدل 128 بالرقم المناسب.
  2. شغّل الأمر التالي:
    $ sysctl -p
  3. قم بتحميل (أو إعادة تحميل) جميع أنظمة ملفات NFS، حيث ينطبق القابل للضبط فقط على التحميلات التي تم إجراؤها بعد تعيين الضبط.

NFSv4.1

في NFSv4.1، تحدد الجلسات العلاقة بين العميل والخادم. سواء كانت أنظمة ملفات NFS المثبتة تقع فوق اتصال واحد أو العديد منها (كما هو الحال مع nconnect)، يتم تطبيق قواعد الجلسة. في إعداد جلسة العمل، يتفاوض العميل والخادم على الحد الأقصى لطلبات الجلسة، ويستقران على أقل من القيمتين المدعومتين. تدعم Azure NetApp Files 180 طلبا معلقة، وعملاء Linux الافتراضيين إلى 64. يوضح الجدول التالي حدود الجلسة:

خادم NFSv4.1 لملفات Azure NetApp
الحد الأقصى للأوامر لكل جلسة عمل		 عميل Linux
الحد الأقصى الافتراضي للأوامر لكل جلسة عمل		 تم التفاوض على أوامر الحد الأقصى لجلسة العمل
180 64 64

على الرغم من أن عملاء Linux افتراضيا إلى 64 طلبا كحد أقصى لكل جلسة عمل، فإن قيمة قابلة max_session_slots للضبط. يلزم إعادة التشغيل حتى تسري التغييرات. systool -v -m nfs استخدم الأمر لمعرفة الحد الأقصى الحالي المستخدم من قبل العميل. لكي يعمل الأمر، يجب أن يكون تحميل NFSv4.1 واحد على الأقل في مكانه:

$ systool -v -m nfs
{
Module = "nfs"
...
  Parameters:
...
    max_session_slots   = "64"
...
}

لضبط max_session_slots، قم بإنشاء ملف تكوين ضمن /etc/modprobe.d على هذا النحو. تأكد من عدم وجود "علامات اقتباس" للسطر في الملف. وإلا، لن يسري مفعول الخيار.

$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf $ sudo reboot

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

أمثلة على الحد الأقصى المتوقع للتزامن

توضح الأمثلة في هذا القسم الحد الأقصى المتوقع للتزامن.

مثال 1 – 64 max_session_slots ولا nconnect

يستند المثال 1 إلى الإعداد الافتراضي 64 max_session_slots ولا nconnect. مع هذا الإعداد، يمكن تحقيق تزامن 64، كل ذلك من اتصال شبكة واحدة.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • لن يصدر العميل أكثر من 64 طلبا في الرحلة إلى الخادم للجلسة.
      • لن يقبل الخادم أكثر من 64 طلبا في الرحلة من العميل للجلسة. (64 هي القيمة المتفاوض عليها.)

مثال 2 – 64 max_session_slots و nconnect=2

يعتمد المثال 2 على 64 كحد أقصى session_slots ولكن مع خيار التحميل المضاف ل nconnect=2. يمكن تحقيق تزامن 64 ولكن مقسما عبر اتصالين. على الرغم من أن الاتصالات المتعددة لا تجلب المزيد من التزامن في هذا السيناريو، فإن انخفاض عمق قائمة الانتظار لكل اتصال له تأثير إيجابي على زمن الانتقال.

max_session_slots مع ما زال في 64 ولكن nconnect=2، لاحظ أن الحد الأقصى لعدد الطلبات يتم تقسيمها عبر الاتصالات.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • الاتصال ion 1
      • لن يصدر العميل أكثر من 32 طلبا أثناء الطيران إلى الخادم من هذا الاتصال.
      • من المتوقع أن يقبل الخادم ما لا يزيد عن 32 طلبا في الرحلة من العميل لهذا الاتصال.
    • الاتصال 2
      • لن يصدر العميل أكثر من 32 طلبا أثناء الطيران إلى الخادم من هذا الاتصال.
      • من المتوقع أن يقبل الخادم ما لا يزيد عن 32 طلبا في الرحلة من العميل لهذا الاتصال.

مثال 3 – 180 max_session_slots ولا nconnect

المثال 3 يسقط nconnect خيار التحميل ويعين max_session_slots القيمة إلى 180، مطابقا الحد الأقصى لتزامن جلسة NFSv4.1 للخادم. في هذا السيناريو، مع اتصال واحد فقط ونظرا لعملية Azure NetApp Files 128 القصوى المعلقة لكل اتصال NFS، تقتصر الجلسة على 128 عملية في الرحلة.

على الرغم من max_session_slots تعيين إلى 180، يقتصر اتصال الشبكة الواحدة على 128 طلب كحد أقصى على هذا النحو:

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • لن يصدر العميل أكثر من 180 طلبا أثناء الرحلة إلى الخادم للجلسة.
      • لن يقبل الخادم أكثر من 180 طلبا في الرحلة من العميل للجلسة.
      • لن يقبل الخادم أكثر من 128 طلبا في إصدار التقييم للاتصال الفردي.

مثال 4 – 180 max_session_slots و nconnect=2

يضيف nconnect=2 المثال 4 خيار التحميل ويعيد استخدام القيمة 180 max_session_slots . نظرا لأن حمل العمل الكلي مقسم عبر اتصالين، يمكن تحقيق 180 عملية معلقة.

مع وجود اتصالين قيد التشغيل، تدعم الجلسة المخصص الكامل ل 180 طلبا معلقة.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • الاتصال ion 1
      • من المتوقع أن يحتفظ العميل بأكثر من 90 طلبا في الرحلة إلى الخادم من الاتصال الأول.
      • من المتوقع أن يحتفظ الخادم بأكثر من 90 طلبا في الرحلة من العميل لهذا الاتصال داخل الجلسة.
    • الاتصال 2
      • من المتوقع أن يحتفظ العميل بأكثر من 90 طلبا في الرحلة إلى الخادم من الاتصال الأول.
      • من المتوقع أن يحتفظ الخادم بأكثر من 90 طلبا في الرحلة من العميل لهذا الاتصال داخل الجلسة.

إشعار

للحصول على الحد الأقصى للتزامن، قم بتعيين max_session_slots يساوي 180، وهو الحد الأقصى للتزامن على مستوى الجلسة الذي تدعمه Azure NetApp Files حاليا.

كيفية التحقق من الحد الأقصى للطلبات المعلقة للجلسة

لمشاهدة الأحجام session_slot التي يدعمها العميل والخادم، قم بالتقاط أمر التحميل في تتبع الحزمة. ابحث عن CREATE_SESSION المكالمة والرد CREATE_SESSION كما هو موضح في المثال التالي. تم إنشاء المكالمة من العميل، ونشأ الرد من الخادم.

استخدم الأمر التالي tcpdump لالتقاط أمر التحميل:

$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049

باستخدام Wireshark، تكون حزم الاهتمام كما يلي:

Screenshot that shows packets of interest.

ضمن هاتين الحزمتين، انظر إلى max_reqs الحقل داخل القسم الأوسط من ملف التتبع.

  • نظام ملفات الشبكة
    • عمليات
      • Opcode
        • csa_fore_channel_attrs
        • max reqs

تظهر الحزمة 12 (طلبات العميل القصوى) أن العميل لديه max_session_slots قيمة 64. في القسم التالي، لاحظ أن الخادم يدعم تزامن 180 لجلسة العمل. تنتهي الجلسة بالتفاوض على أقل من القيمتين المقدمتين.

Screenshot that shows max session slots for Packet 12.

يوضح المثال التالي الحزمة 14 (الطلبات القصوى للخادم):

Screenshot that shows max session slots for Packet 14.

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