مقياس Azure Storage Mover وأهداف الأداء
يعد أداء خدمة ترحيل التخزين جانبا رئيسيا لأي ترحيل. في هذه المقالة، نشارك نتائج اختبار الأداء، على الرغم من أن Azure Storage Mover هي خدمة جديدة، فقد تختلف تجربتك.
أهداف المقياس
يتم اختبار Azure Storage Mover مع 100 مليون عنصر مساحة اسم (ملفات ومجلدات)، تم ترحيلها من مصدر مدعوم إلى هدف مدعوم في Azure.
كيف نختبر
Azure Storage Mover هي خدمة سحابية مختلطة. تحتوي الخدمات المختلطة على مكون خدمة سحابية ومكون بنية أساسية يقوم مسؤول الخدمة بتشغيله في بيئة الشركة الخاصة بهم. بالنسبة إلى Storage Mover، هذا المكون المختلط هو عامل ترحيل. العوامل هي أجهزة ظاهرية، يتم تشغيلها على مضيف بالقرب من التخزين المصدر.
العامل فقط هو جزء ذي صلة من الخدمة لاختبار الأداء. لحذف مخاوف الخصوصية والأداء، تنتقل البيانات مباشرة من عامل Storage Mover إلى التخزين الهدف في Azure. يتم إرسال رسائل التحكم وبيانات تتبع الاستخدام فقط إلى الخدمة السحابية.
أسس الأداء
يتم إنشاء نتائج الاختبار هذه في ظل ظروف مثالية. وهي مخصصة كأساس للمكونات التي يمكن أن تؤثر عليها خدمة Storage Mover والعامل مباشرة. لا يتم النظر في الاختلافات في الأجهزة المصدر والأقراص واتصالات الشبكة في هذا الاختبار. يختلف أداء العالم الحقيقي.
تم تنفيذ الترحيل من تحميل SMB إلى اختبارات مشاركة ملف Azure كما يلي:
يصف الجدول التالي خصائص بيئات الاختبار التي أنتجت نتائج اختبار الأداء من تحميل SMB إلى مشاركة ملف Azure.
| اختبار لا. | عدد من الملفات | إجمالي وزن الملفات | حجم الملف | بنية المجلد |
|---|---|---|---|---|
| 1 | 12 مليون | 12 غيغابايت | 1 كيلوبايت كل | 12 مجلدا، يحتوي كل منها على 100 مجلد فرعي يحتوي على 10000 ملف |
| 2 | 30 | 20 غيغابايت | مجلد 1 | |
| 3 | 1 مليون | 100 غيغابايت | 100 كيلوبايت لكل منها | 1000 مجلد، كل منها يحتوي على 1000 ملف |
| 4 | 1 | 4 تيرابايت | ||
| 5 | 117 مليون نسمة | 117 غيغابايت | 1 كيلوبايت كل | 117 مجلدا، يحتوي كل منها على 100 مجلد فرعي يحتوي على 10000 ملف |
| 6 | 1 | 1 تيرابايت | ||
| 7 | 3.3 مليون نسمة | 45 غيغابايت | 13 كيلوبايت لكل منها | 200,000 مجلد، يحتوي كل منها على 16\17 ملفا |
| 8 | 50 مليون نسمة | 1 تيرابايت | 20 كيلوبايت لكل منها | 2,940,000 مجلد، يحتوي كل مجلد على 17 ملفا |
| 9 | 100 مليون | 2 تيرابايت | 20 كيلوبايت لكل منها | 5,880,000 مجلد، يحتوي كل منها على 17 ملفا |
يتم اختبار تكوينات موارد الوكيل المختلفة على نقاط نهاية SMB:
Minspec: 4 وحدات معالجة مركزية / ذاكرة وصول عشوائي 8 غيغابايت 4 ذاكرات أساسية افتراضية لوحدة المعالجة المركزية بمعدل 2.7 غيغاهرتز لكل منها و8 غيغابايت من الذاكرة (RAM) هي الحد الأدنى من المواصفات لعامل Azure Storage Mover.
اختبار لا. وقت التنفيذ وقت الفحص 6 16 دقيقة، 42 ثانية 1.2 ثانية 7 55 دقيقة، 4 ثوان دقيقة واحدة، 17 ثانية 8 9 Bootspec: 8 وحدات معالجة مركزية / ذاكرة وصول عشوائي 16 غيغابايت 8 ذاكرات أساسية افتراضية لوحدة المعالجة المركزية بسرعة 2.7 غيغاهرتز لكل منها و16 غيغابايت من الذاكرة (RAM) هي الحد الأدنى من المواصفات لعامل Azure Storage Mover.
النتائج: حساب التخزين القياسي
اختبار لا. وقت التنفيذ وقت الفحص 1 15 ساعة، 59 دقيقة 2 ساعة، 36 دقيقة، 34 ثانية 2 دقيقة واحدة، 54 ثانية 3.34 ثانية 3 ساعة واحدة، 19 دقيقة، 27 ثانية 57.62 ثانية 4 ساعة واحدة، 5 دقائق، 57 ثانية 2.89 ثانية النتائج: حساب تخزين قياسي مع تمكين ملفات كبيرة
اختبار لا. وقت التنفيذ وقت الفحص 1 3 ساعات، 51 دقيقة، 31 ثانية 41 دقيقة و45 ثانية 5 25 ساعة، 47 دقيقة 23 ساعة، 35 دقيقة 6 11 دقيقة، 11 ثانية 0.7 ثانية 7 55 دقيقة، 10 ثوان دقيقة واحدة، 3 ثوان 8 9 النتائج: حساب تخزين متميز
اختبار لا. وقت التنفيذ وقت الفحص 1 2 ساعة، 35 دقيقة، 14 ثانية 24 دقيقة، 46 ثانية 5 23 ساعة، 34 دقيقة 21 ساعة، 34 دقيقة
راجع موارد العامل الموصى بها لنطاق الترحيل في مقالة نشر العامل.
لماذا يختلف أداء الترحيل
بشكل أساسي، تؤثر جودة الشبكة والقدرة على معالجة الملفات والمجلدات وبيانات التعريف الخاصة بها على سرعة الترحيل.
عبر المجالين الأساسيين للشبكة والحوسبة، يكون للعديد من الجوانب تأثير:
- سيناريو الترحيل
النسخ إلى هدف فارغ أسرع مقارنة بالهدف الذي يحتوي على محتوى. يرجع هذا السلوك إلى تقييم محرك الترحيل ليس فقط للمصدر، ولكن أيضا الهدف لاتخاذ قرارات النسخ. - عدد عناصر مساحة الاسم
يستغرق ترحيل 1 غيغابايت من الملفات الصغيرة وقتا أطول من ترحيل 1 غيغابايت من الملفات الأكبر. - شكل مساحة الاسم
التسلسل الهرمي للمجلدات الواسعة يفسح المجال للمعالجة المتوازية أكثر من بنية دليل ضيقة أو عميقة. تقوم نسبة الملف إلى المجلد أيضا بتشغيل لفة. - خسارة مساحة الاسم
عدد الملفات والمجلدات وبيانات التعريف التي تم تغييرها بين نسختين يتم تشغيلها من نفس المصدر إلى نفس الهدف. - الشبكه
- النطاق الترددي وزمن الانتقال بين المصدر وعامل الترحيل
- النطاق الترددي وزمن الانتقال بين عامل الترحيل والهدف في Azure
- موارد عامل الترحيل
يمكن أن يكون لكمية الذاكرة (RAM) وعدد الذاكرات الأساسية للحساب وحتى مقدار سعة القرص المحلي المتوفرة على عامل الترحيل تأثير عميق على سرعة الترحيل. يساعد المزيد من موارد الحوسبة على تحسين استخدام النطاق الترددي المتاح، خاصة عندما تحتاج كميات كبيرة من الملفات الأصغر إلى المعالجة في الترحيل.
على سبيل المثال، يتطلب الترحيل التقليدي استراتيجية لتقليل وقت تعطل حمل العمل الذي يعتمد على التخزين الذي سيتم ترحيله. يدعم Azure Storage Mover مثل هذه الاستراتيجية. يسمى الترحيل المتقارب، n-pass.
في هذه الاستراتيجية، يمكنك النسخ من المصدر إلى الهدف عدة مرات. أثناء تكرارات النسخ هذه، يظل المصدر متوفرا للقراءة والكتابة إلى حمل العمل. قبل تكرار النسخ النهائي، خذ المصدر دون اتصال. من المتوقع أن تنتهي النسخة النهائية بشكل أسرع من القول بأن النسخة الأولى التي قمت بها تستغرق ما دامت النسخة السابقة لها مباشرة. بعد النسخة النهائية، يتم تجاوز فشل حمل العمل لاستخدام التخزين الهدف الجديد في Azure ومتاح للاستخدام مرة أخرى.
أثناء النسخة الأولى من المصدر إلى الهدف، من المحتمل أن يكون الهدف فارغا ويجب أن ينتقل جميع محتوى المصدر إلى الهدف. ونتيجة لذلك، من المرجح أن تكون النسخة الأولى مقيدة أكثر بموارد الشبكة المتوفرة.
في نهاية الترحيل، عند نسخ المصدر إلى الهدف عدة مرات بالفعل، تم تغيير عدد قليل فقط من الملفات والمجلدات وبيانات التعريف منذ النسخة الأخيرة. في تكرار النسخ الأخير هذا، تتطلب مقارنة كل ملف في المصدر والهدف لمعرفة ما إذا كان يجب تحديثه، المزيد من موارد الحوسبة وموارد شبكة أقل. غالبا ما تكون عمليات تشغيل النسخ في هذه المرحلة المتأخرة من الترحيل أكثر تقييدا للحساب. يصبح توفير الموارد المناسب لعامل Storage Mover مهما بشكل متزايد.
الخطوات التالية
يمكن أن تساعد المقالات التالية في نشر Azure Storage Mover بنجاح.