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

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

Applies to

Management model	Billing model	Media tier	Redundancy	SMB	NFS
Microsoft.Storage	Provisioned v2	SSD (premium)	Local (LRS)
Microsoft.Storage	Provisioned v2	SSD (premium)	Zone (ZRS)
Microsoft.Storage	Provisioned v2	HDD (standard)	Local (LRS)
Microsoft.Storage	Provisioned v2	HDD (standard)	Zone (ZRS)
Microsoft.Storage	Provisioned v2	HDD (standard)	Geo (GRS)
Microsoft.Storage	Provisioned v2	HDD (standard)	GeoZone (GZRS)
Microsoft.Storage	Provisioned v1	SSD (premium)	Local (LRS)
Microsoft.Storage	Provisioned v1	SSD (premium)	Zone (ZRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	Local (LRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	Zone (ZRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	Geo (GRS)
Microsoft.Storage	Pay-as-you-go	HDD (standard)	GeoZone (GZRS)

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

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. In a text editor, create the /etc/udev/rules.d/99-nfs.rules file by entering and saving the following text:

   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. In a console, apply the udev rule by running the udevadm command as a superuser and reloading the rules files and other databases. تحتاج فقط إلى تشغيل هذا الأمر مرة واحدة، لجعل udev على علم بالملف الجديد.

   sudo udevadm control --reload
   

NFS nconnect

NFS nconnect هو خيار تحميل من جانب العميل لمشاركات ملفات NFS التي تسمح لك باستخدام اتصالات TCP متعددة بين العميل ومشاركة ملف NFS.

Benefits

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

Metric (operation)	I/O size	Performance improvement
IOPS (write)	64 كيبيبايت، 024 1 كيبيبايت	3x
IOPS (read)	كافة أحجام الإدخال/إخراج	2-4x
Throughput (write)	64 كيبيبايت، 024 1 كيبيبايت	3x
Throughput (read)	كافة أحجام الإدخال/إخراج	2-4x

Prerequisites

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

Performance impact

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

Recommendations

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

جبر nconnect=4

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

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

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

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

عمق قائمة الانتظار هو عدد طلبات الإدخال/الإخراج المعلقة التي يمكن لمورد التخزين خدمتها. لا نوصي بتجاوز عمق قائمة الانتظار الأمثل وهو 64 لأنك لن ترى المزيد من مكاسب الأداء. For more information, see Queue depth.

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

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

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

• 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: لكل تكوين تحميل عبر نقطة النهاية العامة (غير مدعوم)

• 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

Note

حتى إذا تم حل حساب التخزين إلى عنوان IP مختلف، فلا يمكننا ضمان استمرار هذا العنوان لأن نقاط النهاية العامة ليست عناوين ثابتة.

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

• 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

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

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

• Single client: Azure VM (DSv4-Series) with single NIC
• OS: Linux (Ubuntu 20.40)
• NFS storage: SSD file share (provisioned 30 TiB, set nconnect=4)

Size	vCPU	Memory	التخزين المؤقت (SSD)	الحد الأقصى لأقراص البيانات	Max NICs	النطاق الترددي المتوقع للشبكة
Standard_D16_v4	16	64 GiB	التخزين عن بعد فقط	32	8	12,500 Mbps

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

استخدمنا 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٪

حجم الإدخال/إخراج 64 كيبيبايت - قراءة عشوائية - عمق قائمة الانتظار 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

حجم الإدخال/إخراج 1024 كيبيبايت - 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٪ من عمليات الكتابة

حجم الإدخال/إخراج 4 كيبيبايت - 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

حجم الإدخال/إخراج 8 كيبيبايت - 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٪ يكتب

حجم الإدخال/إخراج 64 كيبيبايت - 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

حجم الإدخال/إخراج 1024 كيبيبايت - 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 مفيدا لحمل العمل الخاص بك. يوصى باستخدام السيناريوهات المميزة باللون الأخضر، بينما لا يتم تمييز السيناريوهات باللون الأحمر. السيناريوهات المميزة باللون الأصفر محايدة.

See also

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