Trident: يجب أن يكون للسائقين ontap وضع صوت أكثر ذكاءً

لكي نكون واضحين ، فإن معظم هذه تنطبق على جميع برامج تشغيل ONTAP. جدولة Trident هي بالتأكيد بيئة مستهدفة غنية.

سأقوم بإجراء 1+ لهذا الطلب نيابة عن العديد من التفاعلات التي أجريتها وإضافة بعض العناصر الإضافية. غالبًا ما يُطلب مني العديد من الإمكانات حول منطق اختيار تجمع التخزين:

1. القدرة على استبعاد تجمعات التخزين باستخدام تعريف فئة التخزين. على سبيل المثال ، "أريد كل الفلاش (الوسائط = ssd) ، باستثناء سياسة AFF aggr1 و SF QoS" البرونزية. " الآلية الوحيدة حاليًا لتحقيق ذلك هي القيام بالعكس ، حيث يتم تحديد كل تجمع تخزين باستثناء المجموعة (المجموعات) التي سيتم استبعادها في فئة التخزين.

2. آلية لإيقاف توفير طلبات PVC الجديدة مقابل مجموعة تخزين عندما يصل جهاز التخزين الأساسي (مثل تجميع ONTAP) إلى مستوى عشوائي من "كامل". يمكن / ينبغي أن يعتمد ذلك على السعة الفعلية / الحقيقية المتبقية بالإضافة إلى نسبة / نسبة الاشتراك الزائدة.

3. السماح بتحديد سعة تعسفية لواجهة خلفية معينة. على سبيل المثال ، مع ONTAP ، بغض النظر عن الحجم الفعلي للتجميع ، يُسمح لـ Trident فقط باستهلاك X GiB من تلك السعة. ينطبق نفس المبدأ على SolidFire ، على الرغم من أن النموذج يمكن أن يمتد ليس فقط إلى GiB ، ولكن أيضًا IOPS (الحد الأدنى من QoS ، على وجه التحديد).

4. الاستفادة من AppDM كخلفية.

5. الاستفادة من مدير مستوى الخدمة كخلفية.

6. دمج سعة أداء ONTAP كمقياس لاختيار مجمع التخزين.

حسنًا ، إذا تحدثنا عن منطق الموضع ، فسأضيف بعض العناصر الأخرى التي يجب مراعاتها (بناءً على متطلبات العميل الفعلية):

• عدد وحدات التخزين على العقدة (بما أن لدى Ontap حدود منطقية لا تريد تجاوزها)
• العقدة التي تحمل LIF لـ SVM (لتجنب الوصول غير المباشر إلى البيانات للحصول على أفضل أداء)
• IOPS المقدم (عبر مفهوم QoS التكيفي) على العقدة / التجميع

يتم دمجها مع النقاط التي سبق ذكرها من قبل الآخرين ويتم ترجيحها وفرزها وفقًا لمتطلبات العميل المحددة.

في النهاية ، سنحتاج إما إلى محرك قاعدة قابل للتخصيص في ترايدنت ، أو آلية مرنة لإرفاق أدوات أخرى. إذا قررنا المضي قدمًا في الإصدار الأحدث ، فسأصوت لصالح WFA بالإضافة إلى AppDM و NSLM المذكورتين بالفعل ، نظرًا لأنها (اليوم) هي الأداة الوحيدة التي تتسم بالمرونة الكافية لإنشاء حل مخصص يأخذ كل ما سبق العناصر في الاعتبار.

1+ لهذا لأنني أواجه مشكلات عند استخدام Trident + cloud manager معًا ، لأنه لا يزال لا يختار المجموعة الصحيحة التي يتم إنشاؤها تلقائيًا من أجلي.

+1 نفس الطلب: لدينا مجموعة مكونة من 12 عقدة للنقطة: العقدة التي تحمل LIF لـ SVM (لتجنب الوصول غير المباشر إلى البيانات للحصول على أفضل أداء)
و
الاستفادة من توفير الحجم الكامل كما هو مذكور من قبل.

حسنًا ، إذا تحدثنا عن منطق الموضع ، فسأضيف بعض العناصر الأخرى التي يجب مراعاتها (بناءً على متطلبات العميل الفعلية):

• عدد وحدات التخزين على العقدة (بما أن لدى Ontap حدود منطقية لا تريد تجاوزها)
• العقدة التي تحمل LIF لـ SVM (لتجنب الوصول غير المباشر إلى البيانات للحصول على أفضل أداء)
• IOPS المقدم (عبر مفهوم QoS التكيفي) على العقدة / التجميع

يتم دمجها مع النقاط التي سبق ذكرها من قبل الآخرين ويتم ترجيحها وفرزها وفقًا لمتطلبات العميل المحددة.

في النهاية ، سنحتاج إما إلى محرك قاعدة قابل للتخصيص في ترايدنت ، أو آلية مرنة لإرفاق أدوات أخرى. إذا قررنا المضي قدمًا في الإصدار الأحدث ، فسأصوت لصالح WFA بالإضافة إلى AppDM و NSLM المذكورتين بالفعل ، نظرًا لأنها (اليوم) هي الأداة الوحيدة التي تتسم بالمرونة الكافية لإنشاء حل مخصص يأخذ كل ما سبق العناصر في الاعتبار.

أيضا +1

فكرة اخرى. تنظر المعلمة limitAggregateUsage في الاستخدام العام للتجميع ، وليس فقط السعة المُدارة بواسطة Trident.

إذا تمت مشاركة الإجمالي بين أحمال عمل مختلفة ، وهو ما يحدث غالبًا ، يجب أن تكون هذه المعلمة أكثر دقة قليلاً.

مثال:

• تم ضبط الحد على 20٪
• aggr ممتلئ بالفعل بنسبة 50٪ من أحمال العمل الأخرى
  في هذه الحالة ، لن يكون Trident قادرًا على إنشاء مجلد.
  إذا كانت المعلمة تبحث في المساحة التي يشغلها ترايدنت فقط ، لكان الخلق قد نجح.