مشاركة عبر


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

يمكن أن تفي Azure Files بمتطلبات الأداء لمعظم التطبيقات وحالات الاستخدام. تشرح هذه المقالة العوامل المختلفة التي يمكن أن تؤثر على أداء مشاركة الملفات وكيفية تحسين أداء مشاركات ملفات Azure لحمل العمل الخاص بك.

ينطبق على

نموذج الإدارة نموذج الفوترة مستوى الوسائط التكرار SMB NFS
Microsoft.Storage الإصدار 2 المتوفر SSD (متميز) محلي (LRS) لا ‏‏نعم‬
Microsoft.Storage الإصدار 2 المتوفر SSD (متميز) المنطقة (ZRS) لا ‏‏نعم‬
Microsoft.Storage الإصدار 2 المتوفر HDD (قياسي) محلي (LRS) ‏‏نعم‬ لا
Microsoft.Storage الإصدار 2 المتوفر HDD (قياسي) المنطقة (ZRS) ‏‏نعم‬ لا
Microsoft.Storage الإصدار 2 المتوفر HDD (قياسي) الموقع الجغرافي (GRS) ‏‏نعم‬ لا
Microsoft.Storage الإصدار 2 المتوفر HDD (قياسي) المنطقة الجغرافية (GZRS) ‏‏نعم‬ لا
Microsoft.Storage الإصدار 1 المتوفر SSD (متميز) محلي (LRS) ‏‏نعم‬ ‏‏نعم‬
Microsoft.Storage الإصدار 1 المتوفر SSD (متميز) المنطقة (ZRS) ‏‏نعم‬ ‏‏نعم‬
Microsoft.Storage الدفع الفوري HDD (قياسي) محلي (LRS) ‏‏نعم‬ لا
Microsoft.Storage الدفع الفوري HDD (قياسي) المنطقة (ZRS) ‏‏نعم‬ لا
Microsoft.Storage الدفع الفوري HDD (قياسي) الموقع الجغرافي (GRS) ‏‏نعم‬ لا
Microsoft.Storage الدفع الفوري HDD (قياسي) المنطقة الجغرافية (GZRS) ‏‏نعم‬ لا

المسرد

قبل قراءة هذه المقالة، من المفيد فهم بعض المصطلحات الرئيسية المتعلقة بأداء التخزين:

  • عمليات الإدخال والإخراج في الثانية (IOPS)

    يقيس IOPS أو عمليات الإدخال/الإخراج في الثانية عدد عمليات نظام الملفات في الثانية. مصطلح "IO" قابل للتبديل مع مصطلحي "operation" و"transaction" في وثائق Azure Files.

  • حجم الإدخال/إخراج

    حجم الإدخال/الإخراج، الذي يشار إليه أحيانا باسم حجم الكتلة، هو حجم الطلب الذي يستخدمه التطبيق لتنفيذ عملية إدخال/إخراج واحدة (I/O) على التخزين. اعتمادا على التطبيق، يمكن أن يتراوح حجم الإدخال/الإخراج من أحجام صغيرة مثل 4 KiB إلى أحجام أكبر. يلعب حجم الإدخال/إخراج دورا رئيسيا في معدل النقل القابل للتحقيق.

  • الإنتاجية

    يقيس معدل النقل عدد البتات المقروءة أو المكتوبة إلى التخزين في الثانية، ويتم قياسها بالميبايت في الثانية (MiB/s). لحساب معدل النقل، اضرب IOPS في حجم الإدخال/إخراج. على سبيل المثال، 10,000 IOPS _ 1 MiB حجم الإدخال/الإخراج = 10 جيجابايت/ثانية، بينما 10,000 IOPS _ 4 كيلوبايت حجم الإدخال/الإخراج = 38 ميجابايت/ثانية.

  • كمون

    زمن الانتقال هو مرادف للتأخير ويتم قياسه بالمللي ثانية (مللي ثانية). هناك نوعان من زمن الانتقال: زمن الانتقال من طرف إلى طرف وزمن انتقال الخدمة. لمزيد من المعلومات، راجع زمن الانتقال.

  • عمق قائمة الانتظار

    عمق قائمة الانتظار هو عدد طلبات الإدخال/الإخراج المعلقة التي يمكن لمورد التخزين معالجتها في أي وقت. لمزيد من المعلومات، راجع عمق قائمة الانتظار.

اختيار طبقة وسائط استنادا إلى أنماط الاستخدام

توفر Azure Files مستويين من وسائط التخزين تسمح لك بموازنة الأداء والسعر: SSD وHDD. يمكنك اختيار طبقة الوسائط لمشاركة الملف على مستوى حساب التخزين، وبمجرد إنشاء حساب تخزين في طبقة وسائط معينة، لا يمكنك الانتقال إلى طبقة الوسائط الأخرى دون الترحيل يدويا إلى مشاركة ملف جديدة.

عند الاختيار بين مشاركات ملفات SSD وHDD، من المهم فهم متطلبات نمط الاستخدام المتوقع الذي تخطط لتشغيله على Azure Files. إذا كنت تحتاج إلى كميات كبيرة من IOPS أو سرعات نقل البيانات السريعة أو زمن انتقال منخفض، فيجب عليك اختيار مشاركات ملفات SSD.

يلخص الجدول التالي أهداف الأداء المتوقعة بين مشاركات ملفات SSD وHDD. للحصول على التفاصيل، راجع أهداف قابلية التوسع والأداء لملفات Azure.

متطلبات نمط الاستخدام فرقه HDD
زمن انتقال الكتابة (مللي ثانية من رقم واحد) ‏‏نعم‬ ‏‏نعم‬
زمن انتقال القراءة (بالمللي ثانية من رقم واحد) ‏‏نعم‬ لا

تقدم مشاركات ملفات SSD نموذج توفير يضمن ملف تعريف الأداء التالي استنادا إلى حجم المشاركة. لمزيد من المعلومات، راجع نموذج v1 المقدم.

قائمة التحقق من الأداء

سواء كنت تقيم متطلبات الأداء لحمل عمل جديد أو موجود، يساعدك فهم أنماط الاستخدام على تحقيق أداء يمكن التنبؤ به.

  • حساسية زمن الانتقال: تعد أحمال العمل الحساسة لزمن انتقال القراءة والرؤية العالية للمستخدمين النهائيين أكثر ملاءمة لمشاركات ملفات SSD، والتي يمكن أن توفر زمن انتقال أحادي المللي ثانية لكل من عمليات القراءة والكتابة (< 2 مللي ثانية لحجم الإدخال/الإخراج الصغير).

  • متطلبات IOPS ومعدل النقل: تدعم مشاركات ملفات SSD حدود IOPS ومعدل النقل أكبر من مشاركات ملفات HDD. راجع أهداف مقياس مشاركة الملفات لمزيد من المعلومات.

  • مدة حمل العمل وتكراره: من غير المرجح أن تحقق أحمال العمل القصيرة (بالدقائق) والقليلة (بالساعة) حدود الأداء العليا لمشاركات ملفات HDD مقارنة بأحمال العمل طويلة الأمد والمتكررة. في مشاركات ملفات SSD، تكون مدة حمل العمل مفيدة عند تحديد ملف تعريف الأداء الصحيح لاستخدامه استنادا إلى التخزين المقدم وIOOPS ومعدل النقل. من الأخطاء الشائعة إجراء اختبارات الأداء لبضع دقائق فقط، وهو أمر مضلل في كثير من الأحيان. للحصول على رؤية واقعية للأداء، تأكد من الاختبار بمعدل تردد ومدة عالين بما فيه الكفاية.

  • توازي حمل العمل: بالنسبة لأحمال العمل التي تنفذ عمليات بالتوازي، مثل من خلال مؤشرات ترابط متعددة أو عمليات أو مثيلات تطبيق على نفس العميل، توفر مشاركات ملفات SSD ميزة واضحة على مشاركات ملفات HDD: SMB Multichannel. راجع تحسين أداء مشاركة ملف SMB Azure لمزيد من المعلومات.

  • توزيع عملية واجهة برمجة التطبيقات: تعد أحمال عمل بيانات التعريف الثقيلة، مثل أحمال العمل التي تنفذ عمليات القراءة مقابل عدد كبير من الملفات، مناسبة بشكل أفضل لمشاركات ملفات SSD. راجع بيانات التعريف أو حمل العمل الثقيل لمساحة الاسم.

زمن الانتقال

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

  • زمن الانتقال من طرف إلى طرف (SuccessE2ELatency) هو إجمالي الوقت الذي تستغرقه المعاملة لإجراء رحلة ذهابا وإيابا كاملة من العميل وعبر الشبكة وخدمة Azure Files والعودة إلى العميل.

  • زمن انتقال الخدمة (SuccessServerLatency) هو الوقت الذي تستغرقه المعاملة للرحلة ذهابا وإيابا فقط داخل ملفات Azure. لا يتضمن هذا أي زمن انتقال للعميل أو الشبكة.

    رسم تخطيطي يقارن زمن انتقال العميل وزمن انتقال الخدمة لملفات Azure.

الفرق بين قيم SuccessE2ELatency وS successServerLatency هو زمن الانتقال المحتمل بسبب الشبكة و/أو العميل.

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

علاوة على ذلك، كما يوضح الرسم التخطيطي، كلما كنت بعيدا عن الخدمة، كلما تباطأت تجربة زمن الانتقال، زادت صعوبة تحقيق حدود مقياس الأداء مع أي خدمة سحابية. هذا صحيح بشكل خاص عند الوصول إلى Azure Files من أماكن العمل. في حين أن خيارات مثل ExpressRoute مثالية محليا، فإنها لا تزال لا تتطابق مع أداء تطبيق (حساب + تخزين) يعمل حصريا في نفس منطقة Azure.

تلميح

يعد استخدام جهاز ظاهري في Azure لاختبار الأداء بين الموقع المحلي وAzure طريقة فعالة وعملية لخطوط الأساس لقدرات الشبكات للاتصال ب Azure. يمكن أن تؤدي دوائر ExpressRoute أو بوابات VPN ذات الحجم الأدنى أو التوجيه غير الصحيح إلى إبطاء أحمال العمل التي تعمل على ملفات Azure بشكل كبير.

عمق قائمة الانتظار

عمق قائمة الانتظار هو عدد طلبات الإدخال/الإخراج المعلقة التي يمكن لمورد التخزين خدمتها. نظرا لأن الأقراص المستخدمة من قبل أنظمة التخزين قد تطورت من مدورات 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 مللي ثانية

(راجع أيضًا )