تكامل إدارة موارد نظام المجموعة مع إدارة مجموعة Service Fabric

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

التكامل الصحي

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

مثال آخر على التحذيرات الصحية Resource Manager هو انتهاكات قيود التنسيب. على سبيل المثال، إذا قمت بتعريف قيد موضع (مثل“NodeColor == Blue”) واكتشف Resource Manager انتهاكًا لهذا القيد، فإنه يصدر تحذيرًا صحيًا. ينطبق هذا على القيود المخصصة والقيود الافتراضية (مثل مجال الخطأ وقيود مجال الترقية).

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

PS C:\Users\User > Get-ServiceFabricPartitionHealth -PartitionId '00000000-0000-0000-0000-000000000001'


PartitionId           : 00000000-0000-0000-0000-000000000001
AggregatedHealthState : Warning
UnhealthyEvaluations  :
                        Unhealthy event: SourceId='System.PLB', Property='ReplicaConstraintViolation_UpgradeDomain', HealthState='Warning', ConsiderWarningAsError=false.

ReplicaHealthStates   :
                        ReplicaId             : 130766528804733380
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577821
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528854889931
                        AggregatedHealthState : Ok

                        ReplicaId             : 130766528804577822
                        AggregatedHealthState : Ok

                        ReplicaId             : 130837073190680024
                        AggregatedHealthState : Ok

HealthEvents          :
                        SourceId              : System.PLB
                        Property              : ReplicaConstraintViolation_UpgradeDomain
                        HealthState           : Warning
                        SequenceNumber        : 130837100116930204
                        SentAt                : 8/10/2015 7:53:31 PM
                        ReceivedAt            : 8/10/2015 7:53:33 PM
                        TTL                   : 00:01:05
                        Description           : The Load Balancer has detected a Constraint Violation for this Replica: fabric:/System/FailoverManagerService Secondary Partition 00000000-0000-0000-0000-000000000001 is
                        violating the Constraint: UpgradeDomain Details: UpgradeDomain ID -- 4, Replica on NodeName -- Node.8 Currently Upgrading -- false Distribution Policy -- Packing
                        RemoveWhenExpired     : True
                        IsExpired             : False
                        Transitions           : Ok->Warning = 8/10/2015 7:13:02 PM, LastError = 1/1/0001 12:00:00 AM

إليك ما تخبرنا به هذه الرسالة الصحية:

1. جميع النسخ المتماثلة نفسها صحية: كل منها لديه AggregatedHealthState : Ok
2. يتم حاليًا انتهاك قيد توزيع مجال الترقية. هذا يعني أن مجال ترقية معين يحتوي على نسخ متماثلة من هذا القسم أكثر مما ينبغي.
3. ما هي العقدة التي تحتوي على النسخة المتماثلة التي تسبب الانتهاك. في هذه الحالة، تكون العقدة التي تحمل اسم Node.8
4. ما إذا كانت الترقية تحدث حاليًا لهذا القسم ("الترقية حاليا - خطأ")
5. سياسة التوزيع لهذه الخدمة: "سياسة التوزيع - التعبئة". ويتحكم RequireDomainDistribution في ذلك نهج الإيداع. تشير التعبئة إلى أنه في هذه الحالة لم يكن DomainDistribution مطلوبًا، لذلك نحن نعلم أنه لم يتم تحديد سياسة المواضع لهذه الخدمة.
6. وقت حدوث التقرير - 8/10/2015 7:13:02 م

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

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

1. جعلت بعض الحالات العابرة من المستحيل وضع مثيل الخدمة هذا أو النسخة المتماثلة بشكل صحيح
2. متطلبات التنسيب الخاصة بالخدمة غير مرضية.

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

أنواع القيود

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

• ReplicaExclusionStatic وReplicaExclusionDynamic: تشير هذه القيود إلى أنه تم رفض حل لأنه يجب وضع كائنين خدمة من نفس القسم على نفس العقدة. هذا غير مسموح به لأن فشل هذه العقدة سيؤثر بشكل مفرط على هذا القسم. ReplicaExclusionStatic وReplicaExclusionDynamic هما نفس القاعدة تقريبًا ولا يهم الاختلافات حقًا. إذا كنت ترى تسلسل إزالة قيد يحتوي إما على القيد ReplicaExclusionStatic أو ReplicaExclusionDynamic، Resource Manager نظام المجموعة يعتقد أنه لا توجد عقد كافية. ويتطلب ذلك حلولًا مستديمة لاستخدام هذه المواضع غير الصالحة، وهي غير مسموح بها. عادة ما تخبرنا القيود الأخرى في التسلسل لماذا يتم التخلص من العقد في المقام الأول.
• PlacementConstraint: إذا ظهرت لك هذه الرسالة، فهذا يعني أننا حذفنا بعض العقد لأنها لم تتطابق مع قيود مواضع الخدمة. نحن نتتبع قيود المواضع التي تم تكوينها حاليًا كجزء من هذه الرسالة. هذا أمر طبيعي إذا كان لديك قيد موضع محدد. ومع ذلك، إذا كان قيد الموضع يتسبب بشكل غير صحيح في إزالة عدد كبير جدًا من العقد، فهذه هي الطريقة التي ستلاحظها.
• NodeCapacity: يعني هذا القيد أن Resource Manager الكتلة لا يمكنه وضع النسخ المتماثلة على العقد المشار إليها لأن ذلك سيضعها فوق السعة.
• التقارب: يشير هذا القيد إلى أنه لم نتمكن من وضع النسخة المتماثلة على العقد المتأثرة لأنها ستسبب انتهاكًا لقيد التقارب. مزيد من المعلومات حول التقارب في هذه المقالة
• FaultDomain وUpgradeDomain: يزيل هذا القيد العقد إذا كان وضع النسخة المتماثلة على العقد المشار إليها سيؤدي إلى التعبئة في خطأ معين أو مجال ترقية. يتم عرض العديد من الأمثلة التي تناقش هذا القيد في الموضوع حول قيود المجال الخاطئة والترقية والسلوك الناتج
• PreferredLocation: يجب ألا ترى عادة هذا القيد يزيل العقد من الحل لأنه يعمل كتحسين افتراضيًا. يوجد قيد الموقع المفضل أيضًا في أثناء الترقيات. في أثناء الترقية، يتم استخدامه لنقل الخدمات مرة أخرى إلى ما كانت عليه عند بدء الترقية.

عقد قائمة الحظر

رسالة حماية أخرى Resource Manager نظام المجموعة هي عندما يتم حظر العقد. يمكنك التفكير في قائمة الحظر كقيد مؤقت يتم تطبيقه تلقائيًا نيابة عنك. يتم حظر العقد عندما تواجه حالات فشل متكررة عند تشغيل مثيلات من نوع الخدمة هذا. يتم حظر العقد على أساس كل نوع خدمة. قد يتم حظر عقدة لنوع خدمة واحد ولكن ليس آخر.

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

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

أولويات القيود

تحذير

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

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

يمكن تكوين القيود بمستويات أولوية مختلفة. وهي فيما يلي:

• “hard” (0)
• “soft” (1)
• “optimization” (2)
• “off” (-1).

يتم تكوين معظم القيود كقيود ثابتة بشكل افتراضي.

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

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

في المواقف المتقدمة، يمكنك تغيير أولويات القيد. على سبيل المثال، لنفترض أنك تريد التأكد من أن التقارب سيتم انتهاكه دائمًا عند الضرورة لحل مشكلات سعة العقدة. لتحقيق ذلك، يمكنك تعيين أولوية قيد التقارب إلى “soft” (1) وترك قيد السعة مضبوطًا على “hard” (0).

يتم تحديد قيم الأولوية الافتراضية للقيود المختلفة في التكوين التالي:

ClusterManifest.xml

        <Section Name="PlacementAndLoadBalancing">
            <Parameter Name="PlacementConstraintPriority" Value="0" />
            <Parameter Name="CapacityConstraintPriority" Value="0" />
            <Parameter Name="AffinityConstraintPriority" Value="0" />
            <Parameter Name="FaultDomainConstraintPriority" Value="0" />
            <Parameter Name="UpgradeDomainConstraintPriority" Value="1" />
            <Parameter Name="PreferredLocationConstraintPriority" Value="2" />
        </Section>

عبر ClusterConfig.json لعمليات التوزيع المستقلة أو Template.json للمجموعات المستضافة في Azure:

"fabricSettings": [
  {
    "name": "PlacementAndLoadBalancing",
    "parameters": [
      {
          "name": "PlacementConstraintPriority",
          "value": "0"
      },
      {
          "name": "CapacityConstraintPriority",
          "value": "0"
      },
      {
          "name": "AffinityConstraintPriority",
          "value": "0"
      },
      {
          "name": "FaultDomainConstraintPriority",
          "value": "0"
      },
      {
          "name": "UpgradeDomainConstraintPriority",
          "value": "1"
      },
      {
          "name": "PreferredLocationConstraintPriority",
          "value": "2"
      }
    ]
  }
]

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

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

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

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

قيد الموقع المفضل

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

الترقيات

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

• ضمان عدم المساس بقواعد المجموعة
• حاول مساعدة الترقية بسلاسة

استمر في تطبيق القواعد

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

البدائل الذكية

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

تقليل الزحام

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

سعة التخزين المؤقت والترقية

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

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

• ابدأ من البداية واحصل على مقدمة حول Service Fabric Cluster Resource Manager