تحسين الأداء لمشاركات ملفات NFS Azure

توضح هذه المقالة كيف يمكنك تحسين أداء مشاركات ملفات Azure لنظام ملفات الشبكة (NFS).

ينطبق على

نوع مشاركة الملف	SMB	NFS
مشاركات الملفات القياسية (GPv2)، حسابات التخزين المكررة محليًا (LRS) وحسابات التخزين المكررة في المنطقة (ZRS)
مشاركات الملفات القياسية (GPv2)، حساب تخزين مكرر جغرافي (GRS) أو حساب تخزين مكرر للمنطقة الجغرافية (GZRS)
مشاركات الملفات المدفوعة (FileStorage)، حسابات التخزين المكررة محليًا (LRS) وحسابات التخزين المكررة في المنطقة (ZRS)

زيادة حجم القراءة المسبقة لتحسين معدل نقل القراءة

read_ahead_kb تمثل معلمة kernel في Linux كمية البيانات التي يجب "قراءتها مسبقا" أو إحضارها مسبقا أثناء عملية قراءة متتالية. تعيين إصدارات Linux kernel قبل 5.4 قيمة القراءة المسبقة إلى ما يعادل 15 مرة نظام rsizeالملفات المحملة ، والذي يمثل خيار التحميل من جانب العميل لحجم المخزن المؤقت للقراءة. يؤدي هذا إلى تعيين قيمة القراءة المسبقة عالية بما يكفي لتحسين معدل نقل القراءة التسلسلي للعميل في معظم الحالات.

ومع ذلك، بدءا من Linux kernel الإصدار 5.4، يستخدم عميل Linux NFS قيمة افتراضية read_ahead_kb تبلغ 128 KiB. قد تقلل هذه القيمة الصغيرة من مقدار معدل نقل القراءة للملفات الكبيرة. قد يواجه العملاء الذين يطورون من إصدارات Linux بقيمة القراءة المسبقة الأكبر إلى الإصدارات الافتراضية 128 KiB انخفاضا في أداء القراءة التسلسلي.

بالنسبة إلى Linux kernels 5.4 أو أحدث، نوصي باستمرار بتعيين read_ahead_kb إلى 15 ميبي بايت لتحسين الأداء.

لتغيير هذه القيمة، قم بتعيين حجم القراءة المسبقة عن طريق إضافة قاعدة في udev، مدير جهاز Linux kernel. اتبع الخطوات التالية:

1. في محرر النصوص، قم بإنشاء ملف /etc/udev/rules.d/99-nfs.rules عن طريق إدخال النص التالي وحفظه:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

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

   sudo udevadm control --reload
   

Nconnect

Nconnect هو خيار تحميل Linux من جانب العميل الذي يزيد من الأداء على نطاق واسع من خلال السماح لك باستخدام المزيد من اتصالات بروتوكول التحكم في الإرسال (TCP) بين العميل وخدمة Azure Premium Files ل NFSv4.1.

فوائد nconnect

باستخدام nconnect، يمكنك زيادة الأداء على نطاق واسع باستخدام عدد أقل من أجهزة العميل لتقليل التكلفة الإجمالية للملكية (TCO). Nconnect يزيد من الأداء باستخدام قنوات TCP متعددة على واحد أو أكثر من بطاقات NIC، باستخدام عملاء مفردين أو عدة عملاء. بدون nconnect، ستحتاج إلى ما يقرب من 20 جهاز عميل من أجل تحقيق حدود مقياس النطاق الترددي (10 غيغابايت/ ثانية) التي يقدمها أكبر حجم توفير لمشاركة ملفات Azure المتميزة. باستخدام nconnect، يمكنك تحقيق هذه الحدود باستخدام 6-7 عملاء فقط، ما يقلل من تكاليف الحوسبة بنسبة 70٪ تقريبا مع توفير تحسينات كبيرة في عمليات الإدخال/الإخراج في الثانية (IOPS) ومعدل النقل على نطاق واسع. راجع الجدول التالي.

المتطلبات الأساسية

• تدعم nconnectأحدث توزيعات Linux بشكل كامل . بالنسبة لتوزيعات Linux الأقدم، تأكد من أن إصدار Linux kernel هو 5.3 أو أعلى.
• يتم دعم التكوين لكل تحميل فقط عند استخدام مشاركة ملف واحد لكل حساب تخزين عبر نقطة نهاية خاصة.

تأثير أداء nconnect

حققنا نتائج الأداء التالية عند استخدام nconnect خيار التحميل مع مشاركات ملفات NFS Azure على عملاء Linux على نطاق واسع. لمزيد من المعلومات حول كيفية تحقيقنا لهذه النتائج، راجع تكوين اختبار الأداء.

توصيات ل nconnect

اتبع هذه التوصيات للحصول على أفضل النتائج من nconnect.

جبر nconnect=4

بينما تدعم Azure Files الإعداد nconnect إلى الإعداد الأقصى وهو 16، نوصي بتكوين خيارات التحميل مع الإعداد الأمثل ل nconnect=4. حاليا، لا توجد مكاسب تتجاوز أربع قنوات لتنفيذ ملفات Azure ل nconnect. في الواقع، تجاوز أربع قنوات لمشاركة ملف Azure واحد من عميل واحد قد يؤثر سلبا على الأداء بسبب تشبع شبكة TCP.

تحجيم الأجهزة الظاهرية بعناية

اعتمادا على متطلبات حمل العمل الخاص بك، من المهم تغيير حجم الأجهزة الظاهرية للعميل (VMs) بشكل صحيح لتجنب تقييدها من خلال النطاق الترددي المتوقع للشبكة. لا تحتاج إلى وحدات تحكم واجهة شبكة متعددة (NICs) من أجل تحقيق معدل نقل الشبكة المتوقع. في حين أنه من الشائع استخدام الأجهزة الظاهرية للأغراض العامة مع ملفات Azure، تتوفر أنواع مختلفة من الأجهزة الظاهرية اعتمادا على احتياجات حمل العمل وتوافر المنطقة. لمزيد من المعلومات، راجع محدد جهاز Azure الظاهري.

إبقاء عمق قائمة الانتظار أقل من أو يساوي 64

عمق قائمة الانتظار هو عدد طلبات الإدخال/الإخراج المعلقة التي يمكن لمورد التخزين خدمتها. لا نوصي بتجاوز عمق قائمة الانتظار الأمثل وهو 64 لأنك لن ترى المزيد من مكاسب الأداء. لمزيد من المعلومات، راجع عمق قائمة الانتظار.

Nconnect تكوين لكل تحميل

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

السيناريو 1: nconnect التكوين لكل تحميل عبر نقطة نهاية خاصة مع حسابات تخزين متعددة (مدعومة)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

السيناريو 2: nconnect التكوين لكل تحميل عبر نقطة النهاية العامة (غير مدعوم)

• StorageAccount.file.core.windows.net = 52.239.238.8
• StorageAccount2.file.core.windows.net = 52.239.238.7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

السيناريو 3: nconnect التكوين لكل تحميل عبر نقطة نهاية خاصة مع مشاركات متعددة على حساب تخزين واحد (غير مدعوم)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

تكوين اختبار الأداء

استخدمنا الموارد التالية وأدوات القياس لتحقيق النتائج الموضحة في هذه المقالة وقياسها.

• عميل واحد: Azure VM (DSv4-Series) مع NIC واحد
• نظام التشغيل: Linux (Ubuntu 20.40)
• تخزين NFS: مشاركة ملفات Azure المتميزة (تم توفير 30 تيرابايت، تعيين nconnect=4)

أدوات واختبارات قياس الأداء

استخدمنا Flexible I/O Tester (FIO)، وهي أداة إدخال/إخراج مجانية مفتوحة المصدر للقرص تستخدم للتحقق من الأداء والإجهاد/الأجهزة. لتثبيت FIO، اتبع قسم الحزم الثنائية في ملف FIO README لتثبيت النظام الأساسي الذي تختاره.

بينما تركز هذه الاختبارات على أنماط الوصول العشوائية إلى الإدخال/إخراج، تحصل على نتائج مماثلة عند استخدام الإدخال/إخراج التسلسل.

عمليات الإدخال والإخراج في الثانية (IOPS) العالية: قراءات بنسبة 100٪

حجم الإدخال/إخراج 4k - قراءة عشوائية - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

حجم الإدخال/إخراج 8k - قراءة عشوائية - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

معدل النقل العالي: قراءات بنسبة 100٪

حجم الإدخال/إخراج 64k - قراءة عشوائية - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

حجم الإدخال/إخراج 1024k - قراءة عشوائية بنسبة 100٪ - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

عمليات الإدخال والإخراج في الثانية (IOPS) العالية: 100٪ من عمليات الكتابة

حجم الإدخال/إخراج 4k - الكتابة العشوائية 100٪ - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

حجم الإدخال/إخراج 8k - الكتابة العشوائية 100٪ - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

معدل النقل العالي: 100٪ يكتب

حجم الإدخال/إخراج 64k - الكتابة العشوائية 100٪ - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

حجم الإدخال/إخراج 1024k - كتابة عشوائية بنسبة 100٪ - عمق قائمة الانتظار 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

اعتبارات الأداء ل nconnect

عند استخدام nconnect خيار التحميل، يجب تقييم أحمال العمل التي لها الخصائص التالية عن كثب:

• أحمال عمل الكتابة الحساسة لزمن الانتقال التي تكون مترابطة واحدة و/أو تستخدم عمق قائمة انتظار منخفض (أقل من 16)
• أحمال عمل القراءة الحساسة لزمن الانتقال التي تكون مترابطة واحدة و/أو تستخدم عمق قائمة انتظار منخفضا مع أحجام إدخال/إخراج أصغر

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

(راجع أيضًا )

• تحميل مشاركة ملف NFS إلى Linux
• قائمة خيارات التحميل
• فهم أداء ملفات Azure