مشاركة عبر

سياسات التنسيب لخدمات نسيج الخدمة

  • مقالة

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

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

تتوافق معظم هذه المتطلبات مع التخطيط الفعلي للمجموعة، والتي يتم تمثيلها كمجالات خطأ للمجموعة.

سياسات المواضع المتقدمة التي تساعد في معالجة هذه السيناريوهات هي:

  1. نطاقات غير صالحة
  2. النطاقات المطلوبة
  3. النطاقات المفضلة
  4. عدم السماح بالتعبئة المقلدة
  5. السماح بمثيلات متعددة عديمة الجنسية على العقدة

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

تحديد نطاقات غير صالحة

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

مثال على مجال غير صالح

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

ServicePlacementInvalidDomainPolicyDescription invalidDomain = new ServicePlacementInvalidDomainPolicyDescription();
invalidDomain.DomainName = "fd:/DCEast"; //regulations prohibit this workload here
serviceDescription.PlacementPolicies.Add(invalidDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("InvalidDomain,fd:/DCEast”)

تحديد النطاقات المطلوبة

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

مثال على المجال المطلوب

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

ServicePlacementRequiredDomainPolicyDescription requiredDomain = new ServicePlacementRequiredDomainPolicyDescription();
requiredDomain.DomainName = "fd:/DC01/RK03/BL2";
serviceDescription.PlacementPolicies.Add(requiredDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("RequiredDomain,fd:/DC01/RK03/BL2")

تحديد مجال مفضل للنسخ المتماثلة الأساسية لخدمة ذات حالة

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

المجالات الأساسية المفضلة وتجاوز الفشل

ServicePlacementPreferPrimaryDomainPolicyDescription primaryDomain = new ServicePlacementPreferPrimaryDomainPolicyDescription();
primaryDomain.DomainName = "fd:/EastUS/";
serviceDescription.PlacementPolicies.Add(primaryDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("PreferredPrimaryDomain,fd:/EastUS")

طلب توزيع نسخة طبق الأصل وعدم السماح بالتعبئة

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

ملاحظة

لمزيد من المعلومات حول القيود وأولويات القيود بشكل عام، راجع هذا الموضوع.

إذا سبق لك أن رأيت رسالة صحية مثل "The Load Balancer has detected a Constraint Violation for this Replica:fabric:/<some service name> Secondary Partition <some partition ID> is violating the Constraint: FaultDomain"، فقد أصبت بهذه الحالة أو شيء من هذا القبيل. عادة ما يتم تعبئة نسخة واحدة أو اثنتين فقط معا مؤقتًا. طالما أن هناك أقل من حصة النسخ المتماثلة في مجال معين، فأنت آمن. التعبئة نادرة، ولكن يمكن أن تحدث، وعادة ما تكون هذه المواقف عابرة منذ عودة العقد. إذا بقيت العقد منخفضة واحتاج Resource Manager الكتلة إلى إنشاء بدائل، فعادة ما تكون هناك عقد أخرى متوفرة في مجالات الخطأ المثالية.

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

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

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

ServicePlacementRequireDomainDistributionPolicyDescription distributeDomain = new ServicePlacementRequireDomainDistributionPolicyDescription();
serviceDescription.PlacementPolicies.Add(distributeDomain);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("RequiredDomainDistribution")

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

وضع مثيلات متعددة عديمة الجنسية لقسم على عقدة واحدة

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

إذا سبق لك أن رأيت رسالة صحية مثل "The Load Balancer has detected a Constraint Violation for this Replica:fabric:/<some service name> Secondary Partition <some partition ID> is violating the Constraint: ReplicaExclusion"، فقد أصبت بهذه الحالة أو شيء من هذا القبيل.

للاشتراك في تطبيق سياسة المواضع هذه على خدمتك، قم بتمكين التكوينات التالية:

<Section Name="Common">
  <Parameter Name="AllowCreateUpdateMultiInstancePerNodeServices" Value="True" />
  <Parameter Name="HostReuseModeForExclusiveStateless" Value="1" />
</Section>

من خلال تحديد النهج AllowMultipleStatelessInstancesOnNode على الخدمة، يمكن تعيين InstanceCount خارج عدد العقد في المجموعة.

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

ServicePlacementAllowMultipleStatelessInstancesOnNodePolicyDescription allowMultipleInstances = new ServicePlacementAllowMultipleStatelessInstancesOnNodePolicyDescription();
serviceDescription.PlacementPolicies.Add(allowMultipleInstances);

PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless –PartitionSchemeSingleton –PlacementPolicy @(“AllowMultipleStatelessInstancesOnNode”) -InstanceCount 10 -ServicePackageActivationMode ExclusiveProcess

ملاحظة

حاليًا يتم دعم السياسة فقط للخدمات عديمة الجنسية مع وضع تنشيط حزمة خدمة ExclusiveProcess.

تحذير

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

ملاحظة

يمكن أن يؤدي استخدام قيمة عالية من MinInstanceCount مع سياسة المواضع هذه إلى تعليق ترقيات التطبيق. على سبيل المثال، إذا كان لديك مجموعة من خمس عقد وقمت بتعيين InstanceCount=10، فسيكون لديك مثيلان على كل عقدة. إذا قمت بتعيين MinInstanceCount=9، فقد تتعثر محاولة ترقية التطبيق؛ مع MinInstanceCount=8، يمكن تجنب ذلك.

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