وصف نظام مجموعة تصميم الخدمة باستخدام ميزة إدارة موارد أنظمة المجموعات

مقالة
03/25/2023

توفر ميزة إدارة موارد أنظمة المجموعات في تصميم خدمة Azure عدة آليات لوصف نظام مجموعة:

مجالات الخطأ
مجالات الترقية
خصائص العقدة
قدرات العقدة

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

مجالات الخطأ

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

توجد الأجهزة المتصلة بنفس مفتاح Ethernet في مجال الخطأ نفسه. وكذلك الأجهزة التي تشترك في مصدر واحد للطاقة أو في مكان واحد.

وذلك لأنه من الطبيعي أن تتداخل أخطاء الأجهزة، فإن مجالات الخطأ هرمية بطبيعتها. يتم تمثيلها كعناوين URI في تصميم الخدمة.

من المهم إعداد نطاقات الأخطاء بشكل صحيح لأن "تصميم الخدمة" يستخدم هذه المعلومات لوضع الخدمات بأمان. لا يريد "تصميم الخدمة" وضع خدمات بطريقة يمكن بسببها أن يؤدي فقدان مجال خطأ (بسبب فشل بعض المكونات) إلى تعطيل الخدمة.

في بيئة Azure، يستخدم "تصميم الخدمة" معلومات مجال الخطأ التي توفرها البيئة لتكوين العقد في نظام المجموعة بشكل صحيح نيابة عنك. بالنسبة للمثيلات المستقلة "لتصميم الخدمة"، يتم تعريف مجالات الخطأ في وقت إعداد نظام المجموعة.

تحذير

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

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

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

في الرسم البياني التالي، نقوم بتلوين جميع الكيانات التي تساهم في مجالات الخطأ ونسرد جميع مجالات الخطأ المختلفة التي تنجم عن ذلك. في هذا المثال، لدينا مراكز بيانات ("DC") ورفوف ("R") وشفرات ("B"). إذا كانت كل شفرة تحتوي على أكثر من جهاز ظاهري واحد، فقد تكون هناك طبقة أخرى في التدرج الهرمي لمجال الخطأ.

Nodes organized via fault domains

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

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

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

إنها تريد استخدام الآلات في هذا المجال "الثقيل" عن طريق وضع الخدمات عليها.
إنها تريد وضع خدمات في مجالات أخرى حتى لا يتسبب فقدان المجال في حدوث مشاكل.

كيف تبدو المجالات غير المتوازنة؟ يوضح الرسم التخطيطي التالي تخطيطين مختلفين لنظام المجموعة. في المثال الأول، يتم توزيع العقد بالتساوي عبر مجالات الخطأ. في المثال الثاني، يحتوي مجال خطأ واحد على العديد من العقد أكثر من مجالات الخطأ الأخرى.

Two different cluster layouts

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

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

مجالات الترقية

مجالات الترقية هي ميزة أخرى تساعد إدارة موارد أنظمة المجموعات لتصميم الخدمة على فهم تخطيط نظام المجموعة. تحدد مجالات الترقية مجموعات العقد التي تتم ترقيتها في نفس الوقت. تساعد مجالات الترقية إدارة موارد أنظمة المجموعات على فهم عمليات الإدارة مثل الترقيات وتنسيقها.

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

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

Placement With fault and upgrade domains

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

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

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

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

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

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

مجالات الخطأ والترقية التي تم تعيينها 1:1
مجال ترقية واحد لكل عقدة (مثيل نظام التشغيل الفعلي أو الافتراضي)
نموذج "مخطط" أو "مصفوفة" حيث تشكل مجالات الخطأ والترقية مصفوفة أثناء تشغيل الأجهزة للأقطار

Layouts of fault and upgrade domains

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

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

إشعار

لا تدعم أنظمة مجموعات "تصميم الخدمة" المستضافة في Azure تغيير الاستراتيجية الافتراضية. أنظمة المجموعات المستقلة هي فقط من توفر هذا التخصيص.

قيود مجال الخطأ والترقية والسلوك الناتج عنها

النهج الافتراضي

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

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

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

	FD0	FD1	FD2	FD3	FD4
UD0	N1
UD1	N6	N2
UD2			N3
UD3				N4
UD4					N5

الآن لنفترض أننا أنشأنا خدمة بقيمة خمسة لـحجم مجموعة النسخ المتماثلة المستهدف (أو، لخدمة عديمة الجنسية، عدد المثيلات). سيتم توجيه النسخ المتماثلة إلى N1-N5. في الواقع، لا يتم استخدام N6 أبدًا بغض النظر عن عدد الخدمات مثل هذه التي تقوم بإنشائها. لكن لماذا؟ دعونا نلقي نظرة على الفرق بين التخطيط الحالي وما سيحدث إذا تم اختيار N6.

إليك التخطيط الموجود لدينا والعدد الإجمالي للنسخ المتماثلة لكل مجال خطأ وترقية:

	FD0	FD1	FD2	FD3	FD4	إجمالي مجالات الترقية
UD0	R1					1
UD1		R2				1
UD2			R3			1
UD3				R4		1
UD4					R5	1
إجمالي مجالات الخطأ	1	1	1	1	1	-

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

الآن، دعونا نلقي نظرة على ما سيحدث إذا استخدمنا N6 بدلا من N2. كيف سيتم توزيع النسخ المتماثلة بعد ذلك؟

	FD0	FD1	FD2	FD3	FD4	إجمالي مجالات الترقية
UD0	R1					1
UD1	R5					1
UD2			R2			1
UD3				R3		1
UD4					R4	1
إجمالي مجالات الخطأ	2	0	1	1	1	-

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

وبالمثل، إذا اخترنا N2 و N6 (بدلًا من N1 و N2)، فسنحصل على:

	FD0	FD1	FD2	FD3	FD4	إجمالي مجالات الترقية
UD0						0
UD1	R5	R1				2
UD2			R2			1
UD3				R3		1
UD4					R4	1
إجمالي مجالات الخطأ	1	1	1	1	1	-

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

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

ومن ناحية أخرى، يمكن أن يكون هذا النهج صارمًا للغاية ولا يسمح لنظام المجموعة باستخدام جميع الموارد. لا يمكن استخدام عقد معينة في بعض تكوينات أنظمة المجموعات. ونتيجة لذلك، قد لا يقوم Service Fabric بتثبيت خدماتك، مما يؤدي إلى ظهور رسائل تحذير. في المثال السابق، لا يمكن استخدام بعض عقد أنظمة المجموعات (N6 في المثال). حتى إذا أضفت عقدا إلى نظام المجموعة هذا (N7-N10)، سيتم وضع النسخ المتماثلة/المثيلات فقط في N1–N5 بسبب القيود المفروضة على مجالات الخطأ والترقية.

	FD0	FD1	FD2	FD3	FD4
UD0	N1				N10
UD1	N6	N2
UD2		N7	N3
UD3			N8	N4
UD4				N9	N5

نهج بديل

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

إشعار

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

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

لنرجع إلى المثال السابق. مع إصدار القيد الذي به «خزينة حصص»، ستكون جميع التخطيطات الثلاثة صالحة. حتى إذا فشل FD0 في التخطيط الثاني أو فشل UD1 في التخطيط الثالث، فسيظل القسم يتمتع بالحصة. (غالبية النسخ المتماثلة ستظل موجودة.) باستخدام هذا الإصدار من القيد، يمكن دائما استخدام N6.

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

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

النهج التكيفي

نظرا لأن كلا النهجين لهما نقاط قوة وضعف، فقد قدمنا نهجًا تكيفيًا يجمع بين هاتين الاستراتيجيتين.

إشعار

هذا هو السلوك الافتراضي بدءا من الإصدار 6.2 من Service Fabric.

يستخدم النهج التكيفي منطق "الحد الأقصى للفرق" افتراضيًا ويُغير إلى منطق "خزينة الحصص" فقط عند الضرورة. تكتشف إدارة موارد أنظمة المجموعات تلقائيًا الاستراتيجية الضرورية من خلال النظر في كيفية تكوين نظام المجموعة والخدمات.

يجب أن تستخدم إدارة موارد أنظمة المجموعة منطق "قائم على الحصص" لخدمة تستوفي هذين الشرطين:

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

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

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

	FD0	FD1	FD2	FD3	FD4
UD0	N1
UD1	N6	N2
UD2		N7	N3
UD3			N8	N4
UD4					N5

نظرًا لاستيفاء جميع الشروط الضرورية، ستستخدم إدارة موارد أنظمة المجموعات منطق "خزينة الحصص" في توزيع الخدمة. وهذا يتيح استخدام N6-N8. قد يبدو أحد توزيعات الخدمة المحتملة في هذه الحالة كما يلي:

	FD0	FD1	FD2	FD3	FD4	إجمالي مجالات الترقية
UD0	R1					1
UD1	R2					1
UD2		R3	R4			2
UD3						0
UD4					R5	1
إجمالي مجالات الخطأ	2	1	1	0	1	-

إذا تم تقليل قيمة حجم مجموعة النسخ المتماثلة المستهدفةلخدمتك إلى أربعة (على سبيل المثال)، فستلاحظ إدارة موارد أنظمة المجموعات هذا التغيير. سيتم استئناف الخدمة باستخدام منطق "الحد الأقصى للفرق" لأن حجم مجموعة النسخ المتماثلة المستهدفة غير قابل للتقسيم حسب عدد مجالات الخطأ ومجالات الترقية بعد الآن. ونتيجة لذلك، ستحدث بعض حركات النسخ المتماثلة لتوزيع النسخ المتماثلة الأربعة المتبقية على العقد N1-N5. وبهذه الطريقة، لا يتم انتهاك منطق إصدار "الحد الأقصى للفرق" من مجال الخطأ ومجال الترقية.

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

	FD0	FD1	FD2	FD3	FD4	إجمالي مجالات الترقية
UD0	‏‫غير متوفر‬	غير متاح	غير متاح	غير متاح	غير متاح	‏‫غير متوفر‬
UD1	R2					1
UD2		R3	R4			2
UD3				R1		1
UD4					R5	1
إجمالي مجالات الخطأ	1	1	1	1	1	-

تكوين مجالات الخطأ والترقية

في عمليات نشر Service Fabric المستضافة من Azure، يتم تعريف مجالات الخطأ ومجالات الترقية تلقائيًا. يحصل Service Fabric على معلومات البيئة من Azure ويستخدمها.

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

  <Infrastructure>
    <!-- IsScaleMin indicates that this cluster runs on one box/one single server -->
    <WindowsServer IsScaleMin="true">
      <NodeList>
        <Node NodeName="Node01" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType01" FaultDomain="fd:/DC01/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node02" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType02" FaultDomain="fd:/DC01/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node03" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType03" FaultDomain="fd:/DC01/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node04" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType04" FaultDomain="fd:/DC02/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node05" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType05" FaultDomain="fd:/DC02/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node06" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType06" FaultDomain="fd:/DC02/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
        <Node NodeName="Node07" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType07" FaultDomain="fd:/DC03/Rack01" UpgradeDomain="UpgradeDomain1" IsSeedNode="true" />
        <Node NodeName="Node08" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType08" FaultDomain="fd:/DC03/Rack02" UpgradeDomain="UpgradeDomain2" IsSeedNode="true" />
        <Node NodeName="Node09" IPAddressOrFQDN="localhost" NodeTypeRef="NodeType09" FaultDomain="fd:/DC03/Rack03" UpgradeDomain="UpgradeDomain3" IsSeedNode="true" />
      </NodeList>
    </WindowsServer>
  </Infrastructure>

يستخدم هذا المثال ClusterConfig.json لعمليات التوزيع المستقلة:

"nodes": [
  {
    "nodeName": "vm1",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm2",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm3",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc1/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm4",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm5",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm6",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc2/r0",
    "upgradeDomain": "UD3"
  },
  {
    "nodeName": "vm7",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD1"
  },
  {
    "nodeName": "vm8",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD2"
  },
  {
    "nodeName": "vm9",
    "iPAddress": "localhost",
    "nodeTypeRef": "NodeType0",
    "faultDomain": "fd:/dc3/r0",
    "upgradeDomain": "UD3"
  }
],

إشعار

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

خصائص العقدة وقيود الموضع

في بعض الأحيان (بل في أغلب الأحيان)، سيكون عليك التأكد من أن أحمال عمل معينة تعمل فقط على أنواع معينة من العقد في نظام المجموعة. على سبيل المثال، قد تتطلب بعض أحمال العمل وحدات معالجة رسومات أو محركات أقراص SSD، وقد لا يتطلب البعض الآخر ذلك.

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

يتوقع Service Fabric أنه في بعض الحالات، قد يتطلب الأمر تشغيل أحمال عمل معينة على تكوينات أجهزة معينة. على سبيل المثال:

تم "رفع وتحويل" تطبيق مستوى n موجود إلى بيئة Service Fabric.
يجب تشغيل حمل العمل على أجهزة معينة لأسباب تتعلق بالأداء أو السعة أو عزل الأمان.
وينبغي عزل حمل العمل عن أحمال العمل الأخرى لأسباب تتعلق بالنُهج أو استهلاك الموارد.

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

Different workloads for a cluster layout

خصائص العقدة المدمجة

يحدد Service Fabric بعض خصائص العقدة الافتراضية التي يمكن استخدامها تلقائيًا حتى لا تضطر إلى تعريفها. الخصائص الافتراضية المحددة في كل عقدة هي نوع العقدة واسم العقدة.

على سبيل المثال، يمكنك كتابة قيد موضع كـ "(NodeType == NodeType03)". نوع العقدة هي خاصية شائعة الاستخدام. إنها مفيد لأنه تتوافق 1: 1 مع نوع من الأجهزة. يتوافق كل نوع من أنواع الأجهزة مع نوع من أحمال العمل في تطبيق مستوى n تقليدي.

Placement constraints and node properties

قيود الموضع وبناء جملة خاصية العقدة

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

الفحوصات الشرطية لإنشاء عبارات معينة:

البيان‬	بناء الجملة
"يساوي"	"=="
"لا يساوي"	"!="
‏"‏أكبر من"	">"
"أكبر من أو يساوي"	">="
"أقل من"	"<"
"أصغر من أو يساوي"	"<="

البيانات المنطقية للتجميع والعمليات المنطقية:

البيان‬ بناء الجملة

"و" "&&"

"أو" "||"

"لا" "!"

"مجموعة كعبارة واحدة" "()"

البيان‬	بناء الجملة
"و"	"&&"
"أو"	"\|\|"
"لا"	"!"
"مجموعة كعبارة واحدة"	"()"

فيما يلي بعض الأمثلة على عبارات القيد الأساسية:

"Value >= 5"
"NodeColor != green"
"((OneProperty < 100) || ((AnotherProperty == false) && (OneProperty >= 100)))"

يمكن وضع الخدمة فقط في العقد التي يتم فيها تقييم عبارة قيود الموضع الإجمالية إلى "صحيح". لا تتطابق العقد التي لا تحتوي على خاصية محددة مع أي قيد موضع يحتوي على الخاصية.

لنفترض أنه تم تعريف خصائص العقدة التالية لنوع عقدة في ClusterManifest.xml:

    <NodeType Name="NodeType01">
      <PlacementProperties>
        <Property Name="HasSSD" Value="true"/>
        <Property Name="NodeColor" Value="green"/>
        <Property Name="SomeProperty" Value="5"/>
      </PlacementProperties>
    </NodeType>

يوضح المثال التالي خصائص العقدة المعرفة عبر ClusterConfig.json لعمليات النشر المستقلة أو Template.json لأنظمة المجموعات المستضافة بواسطة Azure.

إشعار

في قالب Azure Resource Manager، عادة ما يتم تحديد مَعلمات العقدة. سيبدو مثل "[parameters('vmNodeType1Name')]" بدلًا من NodeType01.

"nodeTypes": [
    {
        "name": "NodeType01",
        "placementProperties": {
            "HasSSD": "true",
            "NodeColor": "green",
            "SomeProperty": "5"
        },
    }
],

يمكنك إنشاء قيود موضع الخدمة لخدمة على النحو التالي:

FabricClient fabricClient = new FabricClient();
StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
serviceDescription.PlacementConstraints = "(HasSSD == true && SomeProperty >= 4)";
// Add other required ServiceDescription fields
//...
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceType -Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementConstraint "HasSSD == true && SomeProperty >= 4"

إذا كانت جميع عقد NodeType01 صالحة، يمكنك أيضًا تحديد نوع العقدة هذا باستخدام القيد "(NodeType == NodeType01)".

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

StatefulServiceUpdateDescription updateDescription = new StatefulServiceUpdateDescription();
updateDescription.PlacementConstraints = "NodeType == NodeType01";
await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);

Update-ServiceFabricService -Stateful -ServiceName $serviceName -PlacementConstraints "NodeType == NodeType01"

يتم تحديد قيود المواضع لكل مثيل خدمة مُسمى. تحل التحديثات دائمًا محل (استبدال) ما تم تحديده مسبقًا.

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

وصف وإدارة موارد نظام المجموعة

واحدة من أهم وظائف أي منسق هي المساعدة في إدارة استهلاك الموارد في نظام المجموعة. يمكن أن تعني إدارة موارد نظام المجموعة بعض الأمور.

أولًا، هناك ضمان عدم تحميل الأجهزة بشكل زائد. وهذا يعني التأكد من أن الأجهزة لا تُشغل خدمات أكثر مما يمكنها التعامل معه.

ثانيًا، هناك موازنة وتحسين، وهما أمران حاسمان لتشغيل الخدمات بكفاءة. لا يمكن أن تسمح عروض الخدمات الفعالة من حيث التكلفة أو التي تتأثر بالأداء لبعض العقد بأن تكون فعالة بينما تكون العقد الأخرى غير فعالة. تؤدي العقد الفعالة إلى تزاحم الموارد وضعف الأداء. تمثل العقد غير الفعالية موارد مهدرة وتكاليف متزايدة.

يقدم Service Fabric الموارد كمقاييس. المقاييس هي أي مورد منطقي أو مادي تريد وصفه لـ Service Fabric. أمثلة على المقاييس هي "WorkQueueDepth" أو "MemoryInMb". للحصول على معلومات حول الموارد المادية التي يمكن إدارتها من قبل Service Fabric على العقد، راجع إدارة الموارد. للحصول على معلومات حول المقاييس الافتراضية التي تستخدمها إدارة موارد أنظمة المجموعات وكيفية تكوين المقاييس المخصصة، راجع هذه المقالة.

تختلف المقاييس عن قيود المواضع وخصائص العقدة. خصائص العقدة هي واصفات ثابتة للعقد نفسها. تصف المقاييس الموارد التي تمتلكها العقد والتي تستهلكها الخدمات عند تشغيلها على عقدة. قد تكون خاصية العقدة HasSSD وقد يتم تعيينها إلى صحيحة أو خاطئة. يُعد مقدار المساحة المتاحة على محرك أقراص SSD هذا ومقدار ما تستهلكه الخدمات مقياسًا مثل "DriveSpaceInMb".

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

السعة

إذا قمت بإيقاف تشغيل كافة عمليات موازنة الموارد، فستظل إدارة موارد أنظمة المجموعات لـ Service Fabric تضمن عدم تجاوز أي عقدة لسعتها. يمكن إدارة تجاوزات السعة ما لم يكن نظام المجموعة ممتلئ للغاية أو كان حمل العمل أكبر من أي عقدة. السعة هي قيد آخر تستخدمه إدارة موارد أنظمة المجموعات لفهم مقدار ما تملكه العقدة من مورد ما. كما يتم تعقب السعة المتبقية لنظام المجموعة ككل.

يتم التعبير عن كل من القدرة والاستهلاك على مستوى الخدمة من حيث المقاييس. على سبيل المثال، قد يكون المقياس "اتصالات العميل" وقد يكون للعقدة سعة لـ "اتصالات العميل" تبلغ 32,768. يمكن أن يكون للعقد الأخرى حدود أخرى. يمكن أن تشير الخدمة التي تعمل على هذه العقدة إنها تستهلك حاليا 32,256 من المقياس "اتصالات العميل".

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

Cluster nodes and capacity

StatefulServiceDescription serviceDescription = new StatefulServiceDescription();
ServiceLoadMetricDescription metric = new ServiceLoadMetricDescription();
metric.Name = "ClientConnections";
metric.PrimaryDefaultLoad = 1024;
metric.SecondaryDefaultLoad = 0;
metric.Weight = ServiceLoadMetricWeight.High;
serviceDescription.Metrics.Add(metric);
await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ClientConnections,High,1024,0)

يمكنك رؤية السعات المحددة في بيان نظام المجموعة. في ما يلي مثال على ClusterManifest.xml:

    <NodeType Name="NodeType03">
      <Capacities>
        <Capacity Name="ClientConnections" Value="65536"/>
      </Capacities>
    </NodeType>

يوضح المثال التالي خصائص العقدة المعرفة عبر ClusterConfig.json لعمليات النشر المستقلة أو Template.json لأنظمة المجموعات المستضافة بواسطة Azure:

"nodeTypes": [
    {
        "name": "NodeType03",
        "capacities": {
            "ClientConnections": "65536",
        }
    }
],

غالبًا ما يتغير حمل الخدمة بشكل ديناميكي. لنفترض أن تحميل نسخة طبق الأصل من "ClientConnections" تغير من 1,024 إلى 2,048. كانت العقدة التي كانت تعمل عليها آنذاك تبلغ سعتها 512 فقط متبقية لهذا المقياس. الآن أصبح موضع النسخة المتماثلة أو المثيل غير صالح، لأنه لا توجد مساحة كافية على هذه العقدة. يجب على إدارة موارد أنظمة المجموعات إعادة العقدة إلى ما دون السعة. يقلل من الحمل على العقدة التي تزيد سعتها عن طريق نقل واحد أو أكثر من النسخ المتماثلة أو المثيلات من تلك العقدة إلى عقد أخرى.

تحاول إدارة موارد أنظمة المجموعات تقليل تكلفة نقل النسخ المتماثلة. يمكنك معرفة المزيد عن تكلفة الحركة وعن إعادة توازن الاستراتيجيات والقواعد.

سعة نظام المجموعة

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

تساعد عناصر التحكم في إدارة موارد أنظمة المجموعات على منع حدوث مشكلات. أول شيء يمكنك القيام به هو منع إنشاء أحمال عمل جديدة من شأنها أن تتسبب في امتلاء نظام المجموعة.

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

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

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

سعة التخزين المؤقت للعقدة وسعة الحجز الزائد

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

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

وضع نسخة متماثلة جديدة أو استبدال النسخ المتماثلة الفاشلة
الموضع أثناء الترقيات
إصلاح خروقات القيود البسيطة والشديدة
إلغاء التجزئة

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

على سبيل المثال، إذا كانت العقدة تحتوي على سعة محددة لمقياساستخدام وحدة المعالجة المركزية بقيمة 100 وتم تعيين النسبة المئوية للمخزن المؤقت للعقدة لهذا المقياس إلى 20٪، فستكون السعات الإجمالية وغير المُخزنة مؤقتًا 100 و80 على التوالي، ولن تضع إدارة موارد أنظمة المجموعات إلا 80 وحدة تحميل على العقدة خلال الظروف العادية وليس أكثر.

Total capacity equals node capacity (Node buffer + Unbuffered)

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

من ناحية أخرى، إذا تم استخدام نسبة الحجز الزائد للعقدة وتعيينها إلى 20٪، فستكون السعات الإجمالية وغير المخزنة مؤقتًا 120 و 100، على التوالي.

Total capacity equals overbooking capacity plus node capacity (Overbooking + Unbuffered)

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

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

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

لا يمكن تحديد كل المخزن المؤقت للعقدة وسعة الحجز الزائد للمقياس في الوقت نفسه.

في ما يلي مثال على كيفية تحديد سعة المخزن المؤقت للعقدة أو الحجز الزائد في ClusterManifest.xml:

<Section Name="NodeBufferPercentage">
    <Parameter Name="SomeMetric" Value="0.15" />
</Section>
<Section Name="NodeOverbookingPercentage">
    <Parameter Name="SomeOtherMetric" Value="0.2" />
    <Parameter Name=”MetricWithInfiniteOverbooking” Value=”-1.0” />
</Section>

فيما يلي مثال على كيفية تحديد سعة المخزن المؤقت للعقدة أو الحجز الزائد عبر ClusterConfig.jsonلعمليات النشر المستقلة أو Template.jsonلأنظمة المجموعات المستضافة بواسطة Azure:

"fabricSettings": [
  {
    "name": "NodeBufferPercentage",
    "parameters": [
      {
          "name": "SomeMetric",
          "value": "0.15"
      }
    ]
  },
  {
    "name": "NodeOverbookingPercentage",
    "parameters": [
      {
          "name": "SomeOtherMetric",
          "value": "0.20"
      },
      {
          "name": "MetricWithInfiniteOverbooking",
          "value": "-1.0"
      }
    ]
  }
]

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

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

مشاركة عبر

وصف نظام مجموعة تصميم الخدمة باستخدام ميزة إدارة موارد أنظمة المجموعات

مجالات الخطأ

مجالات الترقية

قيود مجال الخطأ والترقية والسلوك الناتج عنها

النهج الافتراضي

نهج بديل

النهج التكيفي

تكوين مجالات الخطأ والترقية

خصائص العقدة وقيود الموضع

خصائص العقدة المدمجة

قيود الموضع وبناء جملة خاصية العقدة

وصف وإدارة موارد نظام المجموعة

السعة

سعة نظام المجموعة

سعة التخزين المؤقت للعقدة وسعة الحجز الزائد

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

الملاحظات

الملاحظات

الموارد الإضافية