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

  • مقالة

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

ينطبق على

نوع مشاركة الملف SMB NFS
مشاركات الملفات القياسية (GPv2)، حسابات التخزين المكررة محليًا (LRS) وحسابات التخزين المكررة في المنطقة (ZRS) No, this article doesn't apply to standard SMB Azure file shares LRS/ZRS. NFS shares are only available in premium Azure file shares.
مشاركات الملفات القياسية (GPv2)، حساب تخزين مكرر جغرافي (GRS) أو حساب تخزين مكرر للمنطقة الجغرافية (GZRS) No, this article doesn't apply to standard SMB Azure file shares GRS/GZRS. NFS is only available in premium Azure file shares.
مشاركات الملفات المدفوعة (FileStorage)، حسابات التخزين المكررة محليًا (LRS) وحسابات التخزين المكررة في المنطقة (ZRS) No, this article doesn't apply to premium SMB Azure file shares. Yes, this article applies to premium NFS Azure file shares.

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

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، مع الحفاظ على مرونة النظام الأساسي كخدمة (PaaS).

فوائد nconnect

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

قياس (عملية) حجم الإدخال/إخراج تحسين الأداء
IOPS (كتابة) 64K، 1024K 3x
IOPS (قراءة) كافة أحجام الإدخال/إخراج 2-4x
معدل النقل (الكتابة) 64K، 1024K 3x
معدل النقل (قراءة) كافة أحجام الإدخال/إخراج 2-4x

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

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

تأثير أداء nconnect

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

Screenshot showing average improvement in IOPS when using nconnect with NFS Azure file shares.

Screenshot showing average improvement in throughput when using nconnect with NFS Azure file shares.

التوصيات لnconnect

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

تعيين nconnect=4

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

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

اعتمادا على متطلبات حمل العمل الخاص بك، من المهم تغيير حجم أجهزة العميل بشكل صحيح لتجنب تقييدها من خلال النطاق الترددي المتوقع للشبكة. لا تحتاج إلى بطاقات NIC متعددة من أجل تحقيق معدل النقل المتوقع للشبكة. في حين أنه من الشائع استخدام الأجهزة الظاهرية للأغراض العامة مع ملفات 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

إشعار

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

السيناريو 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 Virtual Machine (DSv4-Series) مع NIC واحد
  • نظام التشغيل: Linux (Ubuntu 20.40)
  • تخزين NFS: مشاركة ملفات Azure المتميزة (تم توفير 30 تيرابايت، تعيين nconnect=4)
حجم وحدة المعالجة المركزية الظاهرية الذاكرة التخزين المؤقت (SSD) الحد الأقصى لأقراص البيانات الحد الأقصى لبطاقات NIC النطاق الترددي المتوقع للشبكة
Standard_D16_v4 16 64 جيبي بايت التخزين عن بعد فقط 32 8 12500 ميغابت في الثانية

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

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

Screenshot showing various read and write I O scenarios with corresponding latency to indicate when nconnect is advisable.

(راجع أيضًا )

  • للحصول على إرشادات التحميل، راجع تحميل مشاركة ملف NFS إلى Linux.
  • للحصول على قائمة شاملة بخيارات التحميل، راجع صفحة Linux NFS man.
  • للحصول على معلومات حول زمن الانتقال وIOOPS ومعدل النقل ومفاهيم الأداء الأخرى، راجع فهم أداء ملفات Azure.