إدارة استهلاك الموارد وتحميلها في Service Fabric باستخدام المقاييس

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

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

المقاييس الافتراضية

لنفترض أنك تريد البدء في كتابة خدمتك وتوزيعها. في هذه المرحلة، لا تعرف الموارد الفعلية أو المنطقية التي تستهلكها. هذا جيد! يستخدم Service Fabric Cluster Resource Manager بعض المقاييس الافتراضية عند عدم تحديد مقاييس أخرى. وهذه هي:

• PrimaryCount - عدد النسخ المتماثلة الأساسية في العقدة
• ReplicaCount - عدد إجمالي النسخ المتماثلة ذات الحالة الخاصة في العقدة
• Count - عدد جميع عناصر الخدمة (عديمة الحالة وذات الحالة الخاصة) في العقدة

متري	تحميل مثيل عديم الحالة	تحميل نسخة متماثلة ثانوية ذات حالة خاصة	تحميل نسخة متماثلة أساسية ذات حالة خاصة	الوزن
PrimaryCount	0	0	1	درجة عالية
ReplicaCount	0	1	1	متوسط
العدد	1	1	1	منخفض

بالنسبة لأحمال العمل الأساسية، توفر المقاييس الافتراضية توزيعًا لائقًا للعمل في نظام المجموعة. في المثال التالي، دعنا نرى ما يحدث عندما ننشئ خدمتين ونعتمد على المقاييس الافتراضية للموازنة. الخدمة الأولى هي خدمة ذات حالة خاصة بها ثلاثة أقسام وحجم مجموعة النسخ المتماثلة الهدف ثلاثة. الخدمة الثانية هي خدمة عديمة الحالة بها قسم واحد وعدد المثيلات ثلاثة.

إليكم الخدمات:

بعض الأشياء التي يجب ملاحظتها:

• يتم توزيع النسخ المتماثلة الأساسية للخدمة ذات الحالة الخاصة عبر عدة عقد
• توجد النسخ المتماثلة لنفس القسم في عقد مختلفة
• يتم توزيع العدد الإجمالي للنسخ المتماثلة الأساسية والثانوية في نظام المجموعة
• يتم تخصيص العدد الإجمالي لعناصر الخدمة بالتساوي على كل عقدة

جيد!

تعمل المقاييس الافتراضية بشكل رائع كبداية. ومع ذلك، فإن المقاييس الافتراضية لن تفيدك سوى إلى حد معين. على سبيل المثال: ما هو احتمال أن يؤدي نظام التقسيم الذي اخترته إلى استخدام متساوٍ تمامًا من قبل جميع الأقسام؟ ما هو احتمال أن يكون الحمل لخدمة معينة ثابتًا بمرور الوقت، أو حتى هو نفسه عبر أقسام متعددة في الوقت الحالي؟

يمكنك التشغيل باستخدام المقاييس الافتراضية فقط. ومع ذلك، فإن القيام بذلك يعني عادةً أن استخدام نظام المجموعة لديك أقل وأكثر تفاوتًا مما تريد. وذلك لأن المقاييس الافتراضية ليست تكييفية وتفترض أن كل شيء متكافئ. على سبيل المثال، تساهم النسخة المتماثلة الأساسية المشغولة وغير المشغول على حد سواء بالرقم "1" في مقياس PrimaryCount. في أسوأ الحالات، يمكن أن يؤدي استخدام المقاييس الافتراضية فقط أيضًا إلى عقد مجدولة بشكل زائد مما يؤدي إلى مشاكل في الأداء. إذا كنت مهتمًا بتحقيق أقصى استفادة من نظام المجموعة لديك وتجنب مشاكل الأداء، فأنت بحاجة إلى استخدام مقاييس مخصصة وتقارير الحمل الديناميكي.

مقاييس مخصصة

يتم تكوين المقاييس على أساس مثيل لكل خدمة مسماة عند إنشاء الخدمة.

يحتوي أي مقياس على بعض الخصائص التي تصفه: الاسم والأهمية والحمل الافتراضي.

• اسم المقياس: اسم المقياس. اسم المقياس هو معرف فريد للمقياس داخل نظام المجموعة من منظور Resource Manager.

ملاحظة

يجب ألا يكون اسم المقياس المخصص أياً من أسماء مقاييس النظام مثل servicefabric:/_CpuCores أو servicefabric:/_MemoryInMB لأنه يمكن أن يؤدي إلى سلوك غير معرف. بدءاً من الإصدار 9.1 من Service Fabric، للخدمات الموجودة التي تحمل أسماء المقاييس المخصصة هذه، يتم إصدار تحذير صحي للإشارة إلى أن اسم المقياس غير صحيح.

• الأهمية: تحدد أهمية المقياس مدى أهمية هذا المقياس مقارنة بالمقاييس الأخرى لهذه الخدمة.
• الحمل الافتراضي: يتم تمثيل الحمل الافتراضي بشكل مختلف اعتمادًا على ما إذا كانت الخدمة عديمة الحالة أو ذات حالة خاصة.
  • بالنسبة للخدمات عديمة الحالة، يحتوي كل مقياس على خاصية واحدة تسمى DefaultLoad
  • بالنسبة للخدمات ذات الحالة الخاصة، يمكنك تعريف:
    • PrimaryDefaultLoad: المقدار الافتراضي لهذا المقياس الذي تستهلكه هذه الخدمة عندما تكون نسخة متماثلة أساسية
    • SecondaryDefaultLoad: المقدار الافتراضي لهذا المقياس الذي تستهلكه هذه الخدمة عندما تكون ثانوية

ملاحظة

إذا قمت بتعريف مقاييس مخصصة وأردت أيضًا استخدام المقاييس الافتراضية، فستحتاج إلى إضافة المقاييس الافتراضية بشكل صريح مرة أخرى وتحديد مستويات الأهمية والقيم لها. ويرجع ذلك إلى أنه يجب تحديد العلاقة بين المقاييس الافتراضية والمقاييس المخصصة. على سبيل المثال، ربما تكون مهتمًا بـ ConnectionCount أو WorkQueueDepth أكثر من توزيع النسخ المتماثلة الأساسية. بشكل افتراضي، تكون أهمية مقياس PrimaryCount «عالية»، لذا فأنت تريد تقليلها إلى «متوسطة» عند إضافة مقاييسك الأخرى لضمان أن تكون لها الأسبقية.

تعريف مقاييس الخدمة - مثال

لنفترض أنك تريد التكوين التالي:

• تبلغ خدمتك عن مقياس يسمى "ConnectionCount"
• تريد أيضًا استخدام المقاييس الافتراضية
• لقد أجريت بعض القياسات وتعلم أن النسخة المتماثلة الأساسية لتلك الخدمة عادةً ما تستهلك 20 وحدة من "ConnectionCount"
• تستخدم النسخ المتماثلة الثانوية 5 وحدات من "ConnectionCount"
• أنت تعلم أن "ConnectionCount" هو المقياس الأكثر أهمية من حيث إدارة أداء هذه الخدمة تحديدًا
• ما زلت تريد موازنة النسخ المتماثلة الأساسية. تعد موازنة النسخ المتماثلة الأساسية فكرة جيدة بشكل عام بغض النظر عن أي شيء. يساعد ذلك على منع فقدان بعض العقد أو مجال الخطأ من التأثير على غالبية النسخ المتماثلة الأساسية معه.
• خلاف ذلك، فإن المقاييس الافتراضية جيدة

إليك التعليمة البرمجية التي ستكتبها لإنشاء خدمة باستخدام تكوين المقياس هذا:

التعليمة البرمجية:

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
StatefulServiceLoadMetricDescription connectionMetric = new StatefulServiceLoadMetricDescription();
connectionMetric.Name = "ConnectionCount";
connectionMetric.PrimaryDefaultLoad = 20;
connectionMetric.SecondaryDefaultLoad = 5;
connectionMetric.Weight = ServiceLoadMetricWeight.High;

StatefulServiceLoadMetricDescription primaryCountMetric = new StatefulServiceLoadMetricDescription();
primaryCountMetric.Name = "PrimaryCount";
primaryCountMetric.PrimaryDefaultLoad = 1;
primaryCountMetric.SecondaryDefaultLoad = 0;
primaryCountMetric.Weight = ServiceLoadMetricWeight.Medium;

StatefulServiceLoadMetricDescription replicaCountMetric = new StatefulServiceLoadMetricDescription();
replicaCountMetric.Name = "ReplicaCount";
replicaCountMetric.PrimaryDefaultLoad = 1;
replicaCountMetric.SecondaryDefaultLoad = 1;
replicaCountMetric.Weight = ServiceLoadMetricWeight.Low;

StatefulServiceLoadMetricDescription totalCountMetric = new StatefulServiceLoadMetricDescription();
totalCountMetric.Name = "Count";
totalCountMetric.PrimaryDefaultLoad = 1;
totalCountMetric.SecondaryDefaultLoad = 1;
totalCountMetric.Weight = ServiceLoadMetricWeight.Low;

serviceDescription.Metrics.Add(connectionMetric);
serviceDescription.Metrics.Add(primaryCountMetric);
serviceDescription.Metrics.Add(replicaCountMetric);
serviceDescription.Metrics.Add(totalCountMetric);

await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ConnectionCount,High,20,5”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

ملاحظة

توضح الأمثلة المذكورة أعلاه وبقية هذا المستند إدارة المقاييس على أساس كل خدمة مسماة. من الممكن أيضًا تعريف مقاييس الخدمات على مستوى نوع الخدمة. يتم تحقيق ذلك عن طريق تحديدها في بيانات الخدمة. غير مستحسن تعريف المقاييس على مستوى النوع لعدة أسباب. السبب الأول هو أن أسماء المقاييس غالبًا ما تكون خاصة بالبيئة. ما لم يكن هناك عقد ثابت معمول به، لا يمكنك التأكد من أن المقياس "Cores" في بيئة ما ليس "MiliCores" أو "CoReS" في بيئة أخرى. إذا تم تعريف المقاييس في البيان، فستحتاج إلى إنشاء بيانات جديدة لكل بيئة. يؤدي هذا عادةً إلى انتشار بيانات مختلفة مع اختلافات طفيفة فقط، مما قد يؤدي إلى صعوبات في الإدارة.

عادةً ما يتم تعيين أحمال المقاييس على أساس مثيل لكل خدمة مسماة. على سبيل المثال، لنفترض أنك قمت بإنشاء مثيل واحد للخدمة لـ CustomerA الذي يخطط لاستخدامه بشكل خفيف فقط. لنفترض أيضًا أنك قمت بإنشاء مثيل آخر لـ CustomerB الذي لديه حمل عمل أكبر. في هذه الحالة، ربما ترغب في إدخال تعديلات نهائية على الأحمال الافتراضية لتلك الخدمات. إذا كانت لديك مقاييس وأحمال معرّفة عبر البيانات وتريد دعم هذا السيناريو، فإنه يتطلب أنواعًا مختلفة من التطبيقات والخدمات لكل عميل. تتجاوز القيم المعرفة في وقت إنشاء الخدمة تلك المعرفة في البيان، لذا يمكنك استخدام ذلك لتعيين الإعدادات الافتراضية المحددة. ومع ذلك، يؤدي القيام بذلك إلى عدم تطابق القيم المعلن عنها في البيانات مع تلك التي يتم تشغيل الخدمة بها بالفعل. قد يؤدي هذا إلى حدوث إرباك.

كتذكير: إذا كنت تريد فقط استخدام المقاييس الافتراضية، فلن تحتاج إلى لمس مجموعة المقاييس على الإطلاق أو القيام بأي شيء خاص عند إنشاء الخدمة. يتم استخدام المقاييس الافتراضية تلقائيًا عندما لا يتم تعريف أي مقاييس أخرى.

الآن، دعنا نتعرف على كل من هذه الإعدادات بمزيد من التفصيل ونتحدث عن السلوك الذي يؤثر عليه.

التحميل

الهدف الأساسي من تعريف المقاييس هو تمثيل بعض الحمل. الحمل هو مقدار ما يتم استهلاكه من مقياس محدد بواسطة مثيل خدمة أو نسخة متماثلة على عقدة محددة. يمكن تكوين الحمل في أي وقت تقريبًا. على سبيل المثال:

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

يمكن استخدام كل هذه الاستراتيجيات في الخدمة نفسها طوال مدة بقائها.

الحمل الافتراضي

الحمل الافتراضي هو مقدار المقياس الذي يستهلكه كل عنصر خدمة (مثيل عديم الحالة أو نسخة متماثلة ذات حالة خاصة) من هذه الخدمة. يستخدم Cluster Resource Manager هذا الرقم لحمل عنصر الخدمة حتى يتلقى معلومات أخرى، مثل تقرير الحمل الديناميكي. بالنسبة للخدمات الأكثر بساطة، يكون الحمل الافتراضي تعريفًا ثابتًا. لا يتم تحديث الحمل الافتراضي مطلقًا ويتم استخدامه طوال مدة بقاء الخدمة. تعمل الأحمال الافتراضية بشكل رائع مع سيناريوهات تخطيط السعة البسيطة حيث يتم تخصيص كميات معينة من الموارد لأحمال عمل مختلفة ولا تتغير.

ملاحظة

لمزيد من المعلومات حول إدارة السعة وتحديد السعات للعقد في نظام المجموعة، يرجى الاطلاع على هذه المقالة.

يسمح Cluster Resource Manager للخدمات ذات الحالة الخاصة بتحديد حمل افتراضي مختلف لنسخها المتماثلة الأساسية والثانوية. يمكن للخدمات عديمة الحالة تحديد قيمة واحدة فقط تنطبق على جميع المثيلات. بالنسبة للخدمات ذات الحالة الخاصة، عادةً ما يختلف الحمل الافتراضي للنسخ المتماثلة الأساسية والثانوية نظرًا لأن النسخ المتماثلة تقوم بأنواع مختلفة من العمل في كل دور. على سبيل المثال، عادةً ما تخدم النسخ المتماثلة الأساسية كلاً من القراءة والكتابة، وتتعامل مع معظم العبء الحسابي، في حين أن النسخ المتماثلة الثانوية لا تفعل ذلك. عادةً ما يكون الحمل الافتراضي للنسخة المتماثلة الأساسية أعلى من الحمل الافتراضي للنسخ المتماثلة الثانوية. يجب أن تعتمد الأرقام الحقيقية على قياساتك الخاصة.

الحمل الديناميكي

لنفترض أنك تقوم بتشغيل خدمتك منذ فترة. مع بعض المراقبة، لاحظت ما يلي:

1. تستهلك بعض أقسام أو مثيلات خدمة معينة موارد أكثر من غيرها
2. تحتوي بعض الخدمات على حمل يختلف بمرور الوقت.

هناك الكثير من الأشياء التي يمكن أن تسبب هذه الأنواع من تقلبات الأحمال. على سبيل المثال، ترتبط الخدمات أو الأقسام المختلفة بعملاء مختلفين بمتطلبات مختلفة. يمكن أن يتغير الحمل أيضًا لأن مقدار العمل الذي تقوم به الخدمة يختلف على مدار اليوم. بغض النظر عن السبب، لا يوجد عادةً رقم واحد يمكنك استخدامه كإعداد افتراضي. هذا صحيح بشكل خاص إذا كنت ترغب في الحصول على أقصى استفادة من نظام المجموعة. أي قيمة تختارها للحمل الافتراضي تكون خاطئة لبعض الوقت. تؤدي الأحمال الافتراضية غير الصحيحة إلى زيادة أو نقصان في تخصيص الموارد في Cluster Resource Manager. نتيجة لذلك، يكون لديك عقد مستخدمة بشكل مفرط أو غير مستغلة بشكل كافٍ على الرغم من اعتقاد Cluster Resource Manager بأن نظام المجموعة متوازن. لا تزال الأحمال الافتراضية جيدة لأنها توفر بعض المعلومات عن الموضع الأولي، ولكنها لا توفر كل المعلومات عن أحمال العمل الحقيقية. لالتقاط متطلبات الموارد المتغيرة بدقة، يسمح Cluster Resource Manager لكل عنصر خدمة بتحديث الحمل الخاص به أثناء وقت التشغيل. وهذا ما يسمى تقارير الحمل الديناميكي.

تسمح تقارير الحمل الديناميكي للنسخ المتماثلة أو المثيلات بضبط تخصيصها/حمل المقاييس المبلغ عنه طوال مدة بقائها. عادةً ما تبلغ النسخة المتماثلة للخدمة أو مثيلها الذي كان ضعيفًا ولا يقوم بأي عمل أنه كان يستخدم قدرًا قليلاً من مقياس معين. ستبلغ النسخة المتماثلة أو المثيل المشغول أنه يستخدم المزيد.

الإبلاغ عن الحمل لكل نسخة متماثلة أو مثيل يسمح لـ Cluster Resource Manager بإعادة تنظيم عناصر الخدمة الفردية في نظام المجموعة. تساعد إعادة تنظيم الخدمات في ضمان حصولها على الموارد التي تحتاجها. تحصل الخدمات المشغولة بشكل فعال على "استعادة" الموارد من النسخ المتماثلة أو المثيلات الأخرى الضعيفة حاليًا أو التي تقوم بعمل أقل.

داخل Reliable Services، تبدو التعليمة البرمجية للإبلاغ عن الحمل ديناميكيًا كما يلي:

التعليمة البرمجية:

this.Partition.ReportLoad(new List<LoadMetric> { new LoadMetric("CurrentConnectionCount", 1234), new LoadMetric("metric1", 42) });

يمكن للخدمة الإبلاغ عن أي من المقاييس المحددة لها في وقت الإنشاء. إذا أبلغت خدمة عن حمل مقياس لم يتم تكوينه لاستخدامه، فستتجاهل Service Fabric هذا التقرير. إذا تم الإبلاغ عن مقاييس أخرى صالحة في الوقت نفسه، فسيتم قبول هذه التقارير. يمكن للتعليمة البرمجية للخدمة قياس جميع المقاييس التي تعرف كيفية القيام بها والإبلاغ عنها، ويمكن للمشغلين تحديد تكوين المقياس لاستخدامه دون الحاجة إلى تغيير التعليمة البرمجية للخدمة.

الإبلاغ عن حمل قسم

يوضح القسم السابق كيفية قيام النسخ المتماثلة للخدمة أو مثيلات الخدمة نفسها بالإبلاغ عن الحمل. هناك خيار إضافي للإبلاغ ديناميكيًا عن حمل النسخ المتماثلة أو المثيلات الخاصة بالقسم من خلال واجهة برمجة تطبيقات Service Fabric. عند الإبلاغ عن حمل قسم، يمكنك الإبلاغ عن أقسام متعددة في وقت واحد.

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

باستخدام واجهة برمجة التطبيقات هذه، توجد طرق متعددة لتحديث الحمل في نظام المجموعة:

• يمكن لقسم خدمة ذات حالة خاصة تحديث حمل النسخة المتماثلة الأساسية الخاصة به.
• يمكن لكل من الخدمات عديمة الحالة وذات الحالة الخاصة تحديث حمل جميع نسخها المتماثلة الثانوية أو مثيلاتها.
• يمكن لكل من الخدمات عديمة الحالة وذات الحالة الخاصة تحديث حمل نسخة متماثلة أو مثيل معين على عقدة.

من الممكن أيضًا الجمع بين أي من هذه التحديثات لكل قسم في الوقت نفسه. يجب تحديد مجموعة من تحديثات الحمل لقسم معين من خلال العنصر PartitionMetricLoadDescription، والذي يمكن أن يحتوي على قائمة مقابلة بتحديثات الحمل كما هو موضح في المثال أدناه. يتم تمثيل تحديثات الحمل من خلال العنصر MetricLoadDescription، والذي يمكن أن يحتوي على قيمة الحمل الحالية أو المتوقعة لمقياس، محدد باسم مقياس.

ملاحظة

قيم حمل المقاييس المتوقعة تعد حاليًا ميزة معاينة. فهي تسمح بالإبلاغ عن قيم الحمل المتوقعة واستخدامها في جانب Service Fabric، ولكن هذه الميزة غير ممكَّنة حاليًا.

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

• PartitionNotFound - معرف القسم المحدد غير موجود.
• ReconfigurationPending - القسم قيد إعادة التكوين حاليًا.
• InvalidForStatelessServices - تم إجراء محاولة لتغيير حمل نسخة متماثلة أساسية لقسم ينتمي إلى خدمة عديمة الحالة.
• ReplicaDoesNotExist - النسخة المتماثلة الثانوية أو المثيل غير موجود على عقدة محددة.
• InvalidOperation - يمكن أن يحدث في حالتين: لم يتم تمكين تحديث الحمل لقسم ينتمي إلى تطبيق النظام أو تحديث الحمل المتوقع.

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

التعليمة البرمجية:

Guid partitionId = Guid.Parse("53df3d7f-5471-403b-b736-bde6ad584f42");
string metricName0 = "CustomMetricName0";
List<MetricLoadDescription> newPrimaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 100)
};

string nodeName0 = "NodeName0";
List<MetricLoadDescription> newSpecificSecondaryReplicaLoads = new List<MetricLoadDescription>()
{
    new MetricLoadDescription(metricName0, 200)
};

OperationResult<UpdatePartitionLoadResultList> updatePartitionLoadResults =
    await this.FabricClient.UpdatePartitionLoadAsync(
        new UpdatePartitionLoadQueryDescription
        {
            PartitionMetricLoadDescriptionList = new List<PartitionMetricLoadDescription>()
            {
                new PartitionMetricLoadDescription(
                    partitionId,
                    newPrimaryReplicaLoads,
                    new List<MetricLoadDescription>(),
                    new List<ReplicaMetricLoadDescription>()
                    {
                        new ReplicaMetricLoadDescription(nodeName0, newSpecificSecondaryReplicaLoads)
                    })
            }
        },
        this.Timeout,
        cancellationToken);

باستخدام هذا المثال، ستقوم بإجراء تحديث لآخر حمل تم الإبلاغ عنه لقسم 53df3d7f-5471-403b-b736-bde6ad584f42. سيتم تحديث حمل النسخة المتماثلة الأساسية لمقياس CustomMetricName0 بالقيمة 100. في الوقت نفسه، سيتم تحديث حمل المقياس نفسه لنسخة متماثلة ثانوية محددة موجودة في العقدة NodeName0 بالقيمة 200.

تحديث تكوين مقياس الخدمة

يمكن تحديث قائمة المقاييس المرتبطة بالخدمة وخصائص تلك المقاييس ديناميكيًا أثناء نشر الخدمة. هذا يسمح بالتجريب والمرونة. فيما يلي بعض الأمثلة على متى يكون هذا مفيدًا:

• تعطيل مقياس باستخدام تقرير الأخطاء لخدمة معينة
• إعادة تكوين مستويات أهمية المقاييس استنادًا إلى السلوك المطلوب
• تمكين مقياس جديد فقط بعد توزيع التعليمات البرمجية بالفعل والتحقق من صحتها عبر آليات أخرى
• تغيير الحمل الافتراضي لخدمة استنادًا إلى السلوك المُلاحظ والاستهلاك

واجهات برمجة التطبيقات الرئيسية لتغيير تكوين المقاييس هي FabricClient.ServiceManagementClient.UpdateServiceAsync في C# وUpdate-ServiceFabricService في PowerShell. مهما كانت المعلومات التي تحددها باستخدام واجهات برمجة التطبيقات هذه، فإنها تحل محل معلومات المقاييس الحالية للخدمة على الفور.

خلط قيم الحمل الافتراضي وتقارير الحمل الديناميكي

يمكن استخدام الحمل الافتراضي والأحمال الديناميكية للخدمة نفسها. عندما تستخدم خدمة كلاً من الحمل الافتراضي وتقارير الحمل الديناميكي، يعمل الحمل الافتراضي كتقدير حتى تظهر التقارير الديناميكية. يعتبر الحمل الافتراضي جيدًا لأنه يمنح Cluster Resource Manager شيئًا للعمل معه. يسمح الحمل الافتراضي لـ Cluster Resource Manager بوضع عناصر الخدمة في مواقع جيدة عند إنشائها. إذا لم يتم توفير معلومات الحمل الافتراضي، فسيكون موضع الخدمات عشوائيًا بشكل فعال. عندما تصل تقارير الحمل لاحقًا، غالبًا ما يكون الموضع العشوائي الأولي خاطئًا ويتعين على Cluster Resource Manager نقل الخدمات.

لنأخذ مثالنا السابق ونرى ما يحدث عندما نضيف بعض المقاييس المخصصة وتقارير الحمل الديناميكي. في هذا المثال، نستخدم "MemoryInMb" كمثال للمقياس.

ملاحظة

الذاكرة هي أحد مقاييس النظام التي يمكن لـ Service Fabric إدارة الموارد من خلالها، وعادةً ما يكون الإبلاغ عنها بنفسك أمرًا صعبًا. نحن لا نتوقع منك في الواقع الإبلاغ عن استهلاك الذاكرة. تستخدم الذاكرة هنا كوسيلة مساعدة للتعرف على قدرات Cluster Resource Manager.

لنفترض أننا أنشأنا الخدمة ذات الحالة الخاصة في البداية باستخدام الأمر التالي:

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("MemoryInMb,High,21,11”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

كتذكير، فإن بناء الجملة هذا هو ("MetricName, MetricWeight, PrimaryDefaultLoad, SecondaryDefaultLoad").

لنرى كيف يمكن أن يبدو تخطيط نظام المجموعة المحتمل:

فيما يلي بعض الأشياء التي تجدر الإشارة إليها:

• يمكن أن يكون لكل نسخة متماثلة ثانوية داخل القسم حمل خاص بها
• بشكل عام، تبدو المقاييس متوازنة. بالنسبة للذاكرة، فإن النسبة بين الحد الأقصى والحد الأدنى للحمل هي 1.75 (العقدة ذات الحمل الأكبر هي N3، والأقل هي N2، و28/16 = 1.75).

هناك بعض الأشياء التي ما زلنا بحاجة إلى شرحها:

• ما الذي حدد ما إذا كانت النسبة 1.75 معقولة أم لا؟ كيف يمكن لـ Cluster Resource Manager معرفة ما إذا كان ذلك جيدًا بما فيه الكفاية أو إذا كان هناك المزيد من العمل الذي يتعين القيام به؟
• متى تحدث الموازنة؟
• ماذا يعني أن الذاكرة كانت ذات أهمية "عالية"؟

مستويات أهمية المقاييس

من المهم تعقب المقاييس نفسها عبر الخدمات المختلفة. طريقة العرض العمومية هذه هي ما يسمح لـ Cluster Resource Manager بتعقب الاستهلاك في نظام المجموعة، وموازنة الاستهلاك عبر العقد، والتأكد من أن العقد لا تتجاوز السعة. ومع ذلك، قد يكون للخدمات وجهات نظر مختلفة حول أهمية المقياس نفسه. أيضًا، في نظام مجموعة به العديد من المقاييس والكثير من الخدمات، قد لا توجد حلول متوازنة تمامًا لجميع المقاييس. كيف ينبغي أن يتعامل Cluster Resource Manager مع هذه الحالات؟

تسمح مستويات أهمية المقاييس لـ Cluster Resource Manager بتحديد كيفية موازنة نظام المجموعة عندما لا تكون هناك إجابة مثالية. تسمح مستويات أهمية المقاييس أيضًا لـ Cluster Resource Manager بموازنة خدمات معينة بشكل مختلف. يمكن أن يكون للمقاييس أربعة مستويات مختلفة من الأهمية: صفر ومنخفضة ومتوسطة وعالية. لا يسهم المقياس ذو مستوى الأهمية «صفر» بأي شيء عند النظر فيما إذا كانت الأمور متوازنة أم لا. ومع ذلك، لا يزال حمله يساهم في إدارة السعة. لا تزال المقاييس ذات مستوى الأهمية «صفر» مفيدة وكثيرًا ما تستخدم كجزء من سلوك الخدمة ومراقبة الأداء. توفر هذه المقالة مزيدًا من المعلومات حول استخدام المقاييس لمراقبة خدماتك وتشخيصها.

التأثير الحقيقي لمستويات أهمية المقاييس المختلفة في نظام المجموعة هو أن Cluster Resource Manager ينشئ حلولاً مختلفة. تخبر مستويات أهمية المقاييس Cluster Resource Manager بأن بعض المقاييس أكثر أهمية من غيرها. عندما لا يكون هناك حل مثالي، يمكن أن يفضل Cluster Resource Manager الحلول التي تعمل على موازنة المقاييس ذات الأهمية الأعلى بشكل أفضل. إذا اعتقدت خدمة ما أن مقياسًا معينًا غير مهم، فقد تجد أن استخدامها لهذا المقياس غير متوازن. يتيح ذلك لخدمة أخرى الحصول على توزيع متساوٍ لبعض المقاييس المهمة بالنسبة لها.

دعنا نلقي نظرة على مثال لبعض تقارير الحمل وكيف تؤدي مستويات أهمية المقاييس المختلفة إلى تخصيصات مختلفة في نظام المجموعة. في هذا المثال، نرى أن تبديل مستوى الأهمية النسبي للمقاييس يؤدي إلى قيام Cluster Resource Manager بإنشاء ترتيبات مختلفة للخدمات.

في هذا المثال، هناك أربع خدمات مختلفة، تُبلغ جميعها عن قيم مختلفة لمقياسين مختلفين، هما MetricA وMetricB. في إحدى الحالات، تعرف جميع الخدمات MetricA بأنه الأكثر أهمية (الأهمية = عالية) وMetricB بأنه غير مهم (الأهمية = منخفضة). ونتيجة لذلك، نرى أن Cluster Resource Manager يضع الخدمات بحيث يكون MetricA متوازنًا بشكل أفضل من MetricB. تعني عبارة "متوازن بشكل أفضل" أن MetricA لديه انحراف معياري أقل من MetricB. في الحالة الثانية، نعكس مستويات أهمية المقاييس. ونتيجة لذلك، يقوم Cluster Resource Manager بتبديل الخدمتين A وB للتوصل إلى تخصيص يكون فيه MetricB متوازنًا بشكل أفضل من MetricA.

ملاحظة

تحدد مستويات أهمية المقاييس كيفية قيام Cluster Resource Manager بالموازنة، ولكن ليس متى يجب أن تحدث الموازنة. لمزيد من المعلومات حول الموازنة، راجع هذه المقالة

مستويات أهمية المقاييس العمومية

لنفترض أن ServiceA تعرف MetricA بأنه ذو أهمية «عالية»، وتقوم ServiceB بتعيين أهمية MetricA إلى «منخفضة» أو «صفر». ما هو مستوى الأهمية الفعلي الذي ينتهي به الأمر إلى الاعتياد عليه؟

هناك مستويات أهمية متعددة يتم تعقبها لكل مقياس. مستوى الأهمية الأول هو مستوى الأهمية المحدد للمقياس عند إنشاء الخدمة. مستوى الأهمية الآخر هو مستوى الأهمية العمومي الذي يتم حسابه تلقائيًا. يستخدم Cluster Resource Manager كلا مستويي الأهمية هذين عند تقييم الحلول. من المهم أخذ كلا مستويي الأهمية في الاعتبار. يتيح ذلك لـ Cluster Resource Manager موازنة كل خدمة وفقًا لأولوياتها الخاصة، وكذلك ضمان تخصيص نظام المجموعة ككل بشكل صحيح.

ماذا سيحدث إذا لم يهتم Cluster Resource Manager بالتوازن العمومي والمحلي؟ حسنًا، من السهل إنشاء حلول متوازنة بشكل عمومي، ولكنها تؤدي إلى ضعف توازن الموارد للخدمات الفردية. في المثال التالي، دعنا نلقي نظرة على خدمة تم تكوينها باستخدام المقاييس الافتراضية فقط، ونرى ما يحدث عند مراعاة التوازن العمومي فقط:

في المثال العلوي المستند إلى التوازن العمومي فقط، فإن نظام المجموعة ككل متوازن بالفعل. تحتوي جميع العقد على نفس عدد النسخ المتماثلة الأساسية ونفس العدد الإجمالي للنسخ المتماثلة. ومع ذلك، إذا نظرت إلى التأثير الفعلي لهذا التخصيص، فإنه ليس جيدًا: يؤثر ففقدان أي عقدة على حمل عمل معين بشكل غير متناسب، لأنه يزيل جميع النسخ المتماثلة الأساسية الخاصة به. على سبيل المثال، إذا فشلت العقدة الأولى فسيتم فقدان جميع النسخ المتماثلة الأساسية الثلاث للأقسام الثلاثة المختلفة لخدمة Circle (الدائرة). على العكس من ذلك، فإن خدمتي Triangle (المثلث) وHexagon (السداسي) تفقد أقسامهما نسخة متماثلة. لا يتسبب هذا في حدوث أي تعطل، بخلاف الاضطرار إلى استرداد النسخة المتماثلة المتوقفة عن التشغيل.

في المثال السفلي، قام Cluster Resource Manager بتوزيع النسخ المتماثلة استنادًا إلى كل من التوازن العمومي والتوازن لكل خدمة. عند حساب درجة الحل، فإنه يعطي معظم الأهمية للحل العمومي، وجزءًا (قابلاً للتكوين) للخدمات الفردية. يتم حساب التوازن العمومي للمقياس استنادًا إلى متوسط مستويات أهمية المقاييس من كل خدمة. تتم موازنة كل خدمة وفقًا لمستويات أهمية المقاييس المحددة الخاصة بها. وهذا يضمن أن تكون الخدمات متوازنة فيما بينها وفقًا لاحتياجاتها الخاصة. نتيجة لذلك، إذا فشلت العقدة الأولى نفسها، فسيتم توزيع الفشل عبر جميع أقسام كل الخدمات. التأثير على كل منها هو نفسه.

الخطوات التالية

• لمزيد من المعلومات حول تكوين الخدمات، تعرف على تكوين الخدمات(service-fabric-cluster-resource-manager-configure-services.md)
• يعد تعريف مقاييس إلغاء التجزئة إحدى الطرق لدمج الحمل على العقد بدلًا من توزيعه. لمعرفة كيفية تكوين إلغاء التجزئة، راجع هذه المقالة
• لمعرفة كيفية قيام Cluster Resource Manager بإدارة الحمل وموازنته في نظام المجموعة، راجع المقالة حول موازنة الحمل
• ابدأ من البداية واحصل على مقدمة حول Service Fabric Cluster Resource Manager
• تكلفة الحركة هي إحدى طرق الإشارة إلى Cluster Resource Manager بأن نقل بعض الخدمات أكثر تكلفة من غيرها. لمعرفة المزيد حول تكلفة الحركة، راجع هذه المقالة