فهم أداء مشاركة ملف Azure وتحسينه
يمكن أن تفي Azure Files بمتطلبات الأداء لمعظم التطبيقات وحالات الاستخدام. تشرح هذه المقالة العوامل المختلفة التي يمكن أن تؤثر على أداء مشاركة الملفات وكيفية تحسين أداء مشاركات ملفات Azure لحمل العمل الخاص بك.
ينطبق على
| نوع مشاركة الملف | SMB | NFS |
|---|---|---|
| مشاركات الملفات القياسية (GPv2)، حسابات التخزين المكررة محليًا (LRS) وحسابات التخزين المكررة في المنطقة (ZRS) |  |
 |
| مشاركات الملفات القياسية (GPv2)، حساب تخزين مكرر جغرافي (GRS) أو حساب تخزين مكرر للمنطقة الجغرافية (GZRS) | |
|
| مشاركات الملفات المدفوعة (FileStorage)، حسابات التخزين المكررة محليًا (LRS) وحسابات التخزين المكررة في المنطقة (ZRS) | |
|
المسرد
قبل قراءة هذه المقالة، من المفيد فهم بعض المصطلحات الرئيسية المتعلقة بأداء التخزين:
عمليات الإدخال والإخراج في الثانية (IOPS)
يقيس IOPS أو عمليات الإدخال/الإخراج في الثانية عدد عمليات نظام الملفات في الثانية. مصطلح "IO" قابل للتبادل مع مصطلحي "operation" و"transaction" في وثائق Azure Files.
حجم الإدخال/إخراج
حجم الإدخال/الإخراج، الذي يشار إليه أحيانا باسم حجم الكتلة، هو حجم الطلب الذي يستخدمه التطبيق لتنفيذ عملية إدخال/إخراج واحدة (I/O) على التخزين. اعتمادا على التطبيق، يمكن أن يتراوح حجم الإدخال/الإخراج من أحجام صغيرة جدا مثل 4 KiB إلى أحجام أكبر بكثير. يلعب حجم الإدخال/إخراج دورا رئيسيا في معدل النقل القابل للتحقيق.
الإنتاجية
يقيس معدل النقل عدد البتات المقروءة أو المكتوبة إلى التخزين في الثانية، ويتم قياسها بالميبايت في الثانية (MiB/s). لحساب معدل النقل، اضرب IOPS في حجم الإدخال/إخراج. على سبيل المثال، 10,000 IOPS * 1 MiB I/O size = 10 GiB/s، بينما 10,000 IOPS * 4 KiB I/O size = 38 MiB/s.
الكمون
زمن الانتقال هو مرادف للتأخير وعادة ما يتم قياسه بالمللي ثانية (مللي ثانية). هناك نوعان من زمن الانتقال: زمن الانتقال من طرف إلى طرف وزمن انتقال الخدمة. لمزيد من المعلومات، راجع زمن الانتقال.
عمق قائمة الانتظار
عمق قائمة الانتظار هو عدد طلبات الإدخال/الإخراج المعلقة التي يمكن لمورد التخزين معالجتها في أي وقت. لمزيد من المعلومات، راجع عمق قائمة الانتظار.
اختيار مستوى أداء استنادا إلى أنماط الاستخدام
توفر Azure Files مجموعة من مستويات التخزين التي تساعد على تقليل التكاليف من خلال السماح لك بتخزين البيانات بالمستوى المناسب من الأداء والسعر. على أعلى مستوى، تقدم Azure Files مستويين من الأداء: قياسي ومميز. تتم استضافة مشاركات الملفات القياسية على نظام تخزين مدعوم بمحركات أقراص ثابتة (HDD)، بينما يتم دعم مشاركات الملفات المتميزة بواسطة محركات الأقراص ذات الحالة الصلبة (SSD) للحصول على أداء أفضل. تحتوي مشاركات الملفات القياسية على العديد من مستويات التخزين (المعاملات المحسنة والساخنة والباردة) التي يمكنك التنقل بينها بسلاسة لزيادة تخزين البيانات الثابتة وأسعار المعاملات. ومع ذلك، لا يمكنك التنقل بين المستويات القياسية والمتميزة دون ترحيل بياناتك فعليا بين حسابات تخزين مختلفة.
عند الاختيار بين مشاركات الملفات القياسية والمميزة، من المهم فهم متطلبات نمط الاستخدام المتوقع الذي تخطط لتشغيله على Azure Files. إذا كنت تحتاج إلى كميات كبيرة من IOPS أو سرعات نقل البيانات السريعة للغاية أو زمن انتقال منخفض جدا، فيجب عليك اختيار مشاركات ملفات Azure المتميزة.
يلخص الجدول التالي أهداف الأداء المتوقعة بين القياسي والمميز. للحصول على التفاصيل، راجع أهداف قابلية التوسع والأداء لملفات Azure.
| متطلبات نمط الاستخدام | قياسي | بريميوم |
|---|---|---|
| زمن انتقال الكتابة (مللي ثانية من رقم واحد) | نعم | نعم |
| زمن انتقال القراءة (بالمللي ثانية من رقم واحد) | لا | نعم |
تقدم مشاركات الملفات المتميزة نموذج توفير يضمن ملف تعريف الأداء التالي استنادا إلى حجم المشاركة. لمزيد من المعلومات، راجع النموذج المقدم. تتراكم أرصدة الاندفاع في مستودع الاندفاع كلما كانت نسبة استخدام الشبكة لمشاركة الملف أقل من IOPS الأساسي. يتم استخدام الأرصدة المكتسبة لاحقا لتمكين الاندفاع عندما تتجاوز العمليات IOPS الأساسي.
| السعة (جيبي بايت) | الخط الأساسي IOPS | اندفاع IOPS | أرصدة الاندفاع | معدل النقل (الدخول + الخروج) |
|---|---|---|---|---|
| 100 | 3,100 | ما يصل إلى 10,000 | 24,840,000 | 110 ميبي بايت/ثانية |
| 500 | 3,500 | ما يصل إلى 10,000 | 23,400,000 | 150 ميغا بايت / ثانية |
| 1,024 | 4,024 | ما يصل إلى 10,000 | 21,513,600 | 203 ميبي بايت/ثانية |
| 5,120 | 8,120 | ما يصل إلى 15,360 | 26,064,000 | 613 ميبي بايت/ثانية |
| 10,240 | 13,240 | ما يصل إلى 30,720 | 62,928,000 | 1,125 ميبي بايت/ثانية |
| 33,792 | 36,792 | ما يصل إلى 100,000 | 227,548,800 | 3480 ميجابايت/ ثانية |
| 51200 | 54,200 | ما يصل إلى 100,000 | 164,880,000 | 5,220 ميبي بايت/ثانية |
| 102,400 | 100,000 | ما يصل إلى 100,000 | 0 | 10,340 ميبي بايت/ثانية |
قائمة التحقق من الأداء
سواء كنت تقوم بتقييم متطلبات الأداء لحمل عمل جديد أو موجود، سيساعدك فهم أنماط الاستخدام على تحقيق أداء يمكن التنبؤ به. راجع مسؤول التخزين أو مطور التطبيق لتحديد أنماط الاستخدام التالية.
حساسية زمن الانتقال: هل يقوم المستخدمون بفتح الملفات أو التفاعل مع أسطح المكتب الظاهرية التي تعمل على Azure Files؟ هذه أمثلة على أحمال العمل الحساسة لزمن انتقال القراءة والتي تتمتع أيضا برؤية عالية للمستخدمين النهائيين. هذه الأنواع من أحمال العمل أكثر ملاءمة لمشاركات ملفات Azure المتميزة، والتي يمكن أن توفر زمن انتقال أحادي المللي ثانية لكل من عمليات القراءة والكتابة (< 2 مللي ثانية لحجم الإدخال/الإخراج الصغير).
متطلبات IOPS ومعدل النقل: تدعم مشاركات الملفات المتميزة حدود IOPS ومعدل النقل أكبر من مشاركات الملفات القياسية. راجع أهداف مقياس مشاركة الملفات لمزيد من المعلومات.
مدة وتكرار حمل العمل: ستكون أحمال العمل القصيرة (بالدقائق) وغير المتكررة (بالساعة) أقل عرضة لتحقيق حدود الأداء العليا لمشاركات الملفات القياسية مقارنة بأحمال العمل طويلة الأمد والمتكررة. في مشاركات الملفات المتميزة، تكون مدة حمل العمل مفيدة عند تحديد ملف تعريف الأداء الصحيح لاستخدامه استنادا إلى حجم التوفير. اعتمادا على المدة التي يحتاجها حمل العمل للاندفاع والمدة التي يقضيها تحت IOPS الأساسي، يمكنك تحديد ما إذا كنت تقوم بتجميع أرصدة اندفاع كافية لتلبية حمل العمل الخاص بك باستمرار في أوقات الذروة. سيؤدي العثور على الرصيد الصحيح إلى تقليل التكاليف مقارنة بالإفراط في توفير مشاركة الملف. من الأخطاء الشائعة إجراء اختبارات الأداء لبضع دقائق فقط، وهو أمر مضلل في كثير من الأحيان. للحصول على رؤية واقعية للأداء، تأكد من الاختبار بمعدل تردد ومدة عالين بما فيه الكفاية.
توازي حمل العمل: بالنسبة لأحمال العمل التي تنفذ العمليات بالتوازي، مثل من خلال مؤشرات ترابط متعددة أو عمليات أو مثيلات تطبيق على نفس العميل، توفر مشاركات الملفات المتميزة ميزة واضحة على مشاركات الملفات القياسية: SMB Multichannel. راجع تحسين أداء مشاركة ملف SMB Azure لمزيد من المعلومات.
توزيع عملية واجهة برمجة التطبيقات: هل بيانات تعريف حمل العمل ثقيلة مع عمليات فتح/إغلاق الملف؟ هذا شائع لأحمال العمل التي تنفذ عمليات القراءة مقابل عدد كبير من الملفات. راجع بيانات التعريف أو حمل العمل الثقيل لمساحة الاسم.
زمن الانتقال
عند التفكير في زمن الانتقال، من المهم أولا فهم كيفية تحديد زمن الانتقال باستخدام Azure Files. القياسات الأكثر شيوعا هي زمن الانتقال المرتبط وزمن الانتقال من طرف إلى طرف ومقاييس زمن انتقال الخدمة. يمكن أن يساعد استخدام مقاييس المعاملات هذه في تحديد زمن الانتقال من جانب العميل و/أو مشكلات الشبكات من خلال تحديد مقدار الوقت الذي تقضيه حركة مرور التطبيق الخاص بك أثناء النقل من وإلى العميل.
زمن الانتقال من طرف إلى طرف (SuccessE2ELatency) هو إجمالي الوقت الذي تستغرقه المعاملة لإجراء رحلة ذهابا وإيابا كاملة من العميل وعبر الشبكة وخدمة Azure Files والعودة إلى العميل.
زمن انتقال الخدمة (SuccessServerLatency) هو الوقت الذي تستغرقه المعاملة للرحلة ذهابا وإيابا فقط داخل خدمة ملفات Azure. لا يتضمن هذا أي زمن انتقال للعميل أو الشبكة.
الفرق بين قيم SuccessE2ELatency وS successServerLatency هو زمن الانتقال المحتمل بسبب الشبكة و/أو العميل.
من الشائع الخلط بين زمن انتقال العميل وزمن انتقال الخدمة (في هذه الحالة، أداء ملفات Azure). على سبيل المثال، إذا كان زمن انتقال الخدمة يبلغ عن زمن انتقال منخفض وكان من طرف إلى طرف يبلغ عن زمن انتقال مرتفع جدا للطلبات، فهذا يشير إلى أن كل الوقت يتم إنفاقه أثناء النقل من العميل وإطاره، وليس في خدمة ملفات Azure.
علاوة على ذلك، كما يوضح الرسم التخطيطي، كلما كنت بعيدا عن الخدمة، كلما كانت تجربة زمن الانتقال أبطأ، وكلما كان تحقيق حدود مقياس الأداء مع أي خدمة سحابية أكثر صعوبة. هذا صحيح بشكل خاص عند الوصول إلى Azure Files من أماكن العمل. في حين أن خيارات مثل ExpressRoute مثالية محليا، فإنها لا تزال لا تتطابق مع أداء تطبيق (حساب + تخزين) يعمل حصريا في نفس منطقة Azure.
تلميح
يعد استخدام جهاز ظاهري في Azure لاختبار الأداء بين الموقع المحلي وAzure طريقة فعالة وعملية لخطوط الأساس لقدرات الشبكات للاتصال ب Azure. في كثير من الأحيان يمكن إبطاء حمل العمل بواسطة دائرة ExpressRoute أو بوابة VPN ذات حجم أقل أو توجيهها بشكل غير صحيح.
عمق قائمة الانتظار
عمق قائمة الانتظار هو عدد طلبات الإدخال/الإخراج المعلقة التي يمكن لمورد التخزين خدمتها. نظرا لأن الأقراص المستخدمة من قبل أنظمة التخزين قد تطورت من مدورات HDD (IDE، SATA، SAS) إلى أجهزة الحالة الصلبة (SSD، NVMe)، فقد تطورت أيضا لدعم عمق قائمة الانتظار الأعلى. حمل العمل الذي يتكون من عميل واحد يتفاعل بشكل تسلسلي مع ملف واحد داخل مجموعة بيانات كبيرة هو مثال على عمق قائمة الانتظار المنخفضة. في المقابل، يمكن أن يحقق حمل العمل الذي يدعم التوازي مع مؤشرات ترابط متعددة وملفات متعددة عمقا عاليا في قائمة الانتظار بسهولة. نظرا لأن Azure Files هي خدمة ملفات موزعة تمتد عبر الآلاف من عقد نظام مجموعة Azure وتم تصميمها لتشغيل أحمال العمل على نطاق واسع، نوصي بإنشاء واختبار أحمال العمل مع عمق قائمة انتظار عال.
يمكن تحقيق عمق قائمة الانتظار العالي بعدة طرق مختلفة بالاشتراك مع العملاء والملفات ومؤشرات الترابط. لتحديد عمق قائمة الانتظار لحمل العمل الخاص بك، اضرب عدد العملاء في عدد الملفات في عدد مؤشرات الترابط (العملاء * الملفات * مؤشرات الترابط = عمق قائمة الانتظار).
يوضح الجدول أدناه المجموعات المختلفة التي يمكنك استخدامها لتحقيق عمق أعلى لقائمة الانتظار. على الرغم من أنه يمكنك تجاوز عمق قائمة الانتظار الأمثل وهو 64، فإننا لا نوصي بذلك. لن ترى المزيد من مكاسب الأداء إذا قمت بذلك، وتخاطر بزيادة زمن الانتقال بسبب تشبع TCP.
| العملاء | الملفات | المواضيع | عمق قائمة الانتظار |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
تلميح
لتحقيق حدود الأداء العليا، تأكد من أن حمل العمل أو اختبار القياس الخاص بك متعدد الترابط مع ملفات متعددة.
تطبيقات أحادية مقابل تطبيقات متعددة مؤشرات الترابط
Azure Files هي الأنسب للتطبيقات متعددة مؤشرات الترابط. أسهل طريقة لفهم تأثير الأداء الذي تحدثه مؤشرات الترابط المتعددة على حمل العمل هي المرور عبر السيناريو بواسطة الإدخال/الإخراج. في المثال التالي، لدينا حمل عمل يحتاج إلى نسخ 10000 ملف صغير في أسرع وقت ممكن من أو إلى مشاركة ملف Azure.
يقسم هذا الجدول الوقت اللازم (بالمللي ثانية) لإنشاء ملف 16 KiB واحد على مشاركة ملف Azure، استنادا إلى تطبيق مؤشر ترابط واحد يكتب بأحجام كتلة 4 KiB.
| عملية الإدخال/إخراج | إنشاء | كتابة 4 كيبيبايت | كتابة 4 كيبيبايت | كتابة 4 كيبيبايت | كتابة 4 كيبيبايت | إغلاق | الإجمالي |
|---|---|---|---|---|---|---|---|
| مؤشر ترابط 1 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
في هذا المثال، قد يستغرق الأمر حوالي 14 مللي ثانية لإنشاء ملف 16 KiB واحد من العمليات الست. إذا أراد تطبيق مترابط واحد نقل 10,000 ملف إلى مشاركة ملف Azure، فإن ذلك يترجم إلى 140,000 مللي ثانية (14 مللي ثانية * 10,000) أو 140 ثانية لأنه يتم نقل كل ملف بشكل تسلسلي واحد في كل مرة. ضع في اعتبارك أن وقت خدمة كل طلب يتم تحديده بشكل أساسي من خلال مدى قرب الحساب والتخزين من بعضهما البعض، كما تمت مناقشته في القسم السابق.
باستخدام ثمانية مؤشرات ترابط بدلا من مؤشر ترابط واحد، يمكن تقليل حمل العمل أعلاه من 140000 مللي ثانية (140 ثانية) إلى 17500 مللي ثانية (17.5 ثانية). كما يظهر الجدول أدناه، عندما تقوم بنقل ثمانية ملفات بالتوازي بدلا من ملف واحد في كل مرة، يمكنك نقل نفس كمية البيانات في وقت أقل بنسبة 87.5٪ .
| عملية الإدخال/إخراج | إنشاء | كتابة 4 كيبيبايت | كتابة 4 كيبيبايت | كتابة 4 كيبيبايت | كتابة 4 كيبيبايت | إغلاق | الإجمالي |
|---|---|---|---|---|---|---|---|
| مؤشر ترابط 1 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر ترابط 2 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر الترابط 3 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر ترابط 4 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر ترابط 5 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر ترابط 6 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر ترابط 7 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |
| مؤشر ترابط 8 | 3 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 2 مللي ثانية | 3 مللي ثانية | 14 مللي ثانية |