إدارة الموارد

مقالة
03/25/2023

عند تشغيل خدمات متعددة على نفس العقدة أو نظام المجموعة، من الممكن أن تستخدم خدمة واحدة مزيداً من الموارد، ما يؤدي إلى استهلاك الخدمات الأخرى في هذه العملية. هذه المشكلة يُشار إليها باسم "الجار الصاخب". يمكّن Azure Service Fabric المطور من التحكم في هذا السلوك عن طريق تحديد الطلبات والحدود لكل خدمة للحد من استخدام الموارد.

قبل متابعة هذه المقالة، من المستحسن التعرف على نموذج تطبيق Service Fabric ونموذج استضافة Service Fabric.

مقاييس إدارة الموارد

يتوفر الدعم لإدارة الموارد في Service Fabric وفقاً لـ حزمة الخدمة. يمكن تقسيم الموارد المُعيّنة إلى حزمة الخدمة بشكل أكبر على حزم التعليمات البرمجية. يدعم Service Fabric إدارة الذاكرة و CPU لكل حزمة خدمة، مع مقياسين مدمجين:

CPU (اسم المقياسservicefabric:/_CpuCores): تتوفر ذاكرة أساسية منطقية على الجهاز المضيف. يتم ترجيح جميع الذاكرات الأساسية عبر جميع العُقد بنفس الطريقة.
Memory (اسم المقياسservicefabric:/_MemoryInMB): يتم التعبير عن الذاكرة بالميغابايت، ويتم تعيينها إلى الذاكرة الفعلية المتوفرة على الجهاز.

بالنسبة إلى هذين المقياسين، يتتبع Cluster Resource Manager (CRM) إجمالي سعة نظام المجموعة، والحمل على كل عقدة في نظام المجموعة وكذلك الموارد المتبقية في نظام المجموعة. هذان المقياسان يكافئان أي مستخدم آخر أو مقياس مخصص.

ملاحظة

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

يمكن استخدام جميع الميزات الموجودة معهما:

يمكن موازنة نظام المجموعة وفقاً لهذين المقياسين (السلوك الافتراضي).
يمكن إلغاء تجزئة نظام المجموعة وفقاً لهذين المقياسين.
عند وصف نظام مجموعة، يمكن تعيين السعة المُخزَنة مؤقتاً لهذين المقياسين.

ملاحظة

لا يتوفر الدعم لإنشاء تقارير الحمل الديناميكي لهذه المقاييس؛ وذلك لأن أحمال هذين المقياسين تُعرّف في وقت الإنشاء.

آلية إدارة الموارد

بدءاً من الإصدار 7.2، يدعم وقت تشغيل Service Fabric مواصفات الطلبات والحدود لـ CPU وموارد الذاكرة.

ملاحظة

تدعم إصدارات وقت تشغيل Service Fabric الأقدم من 7.2 فقط نموذجاً واحداً حيث تعمل قيمة واحدة باعتبارهاطلباً ووحداً في نفس الوقت لمورد معيّن (CPU أو ذاكرة). يُوصف هذا كمواصفة RequestsOnly في هذا المستند.

Requests: تمثل قيم الذاكرة وCPU الأحمال المستخدمة بواسطة Cluster Resource Manager (CRM) للمقياسين servicefabric:/_CpuCores وservicefabric:/_MemoryInMB. بمعنى آخر، يعتبر CRM استخدام مورد خدمة ما مكافئاً لقيم طلبها ويستخدم هذه القيم عند اتخاذ قرارات تحديد الموضع.
Limits: تمثل قيم الذاكرة وCPU حدود الموارد الفعلية المطبقة عند تنشيط عملية أو حاوية على عقدة.

يسمح Service Fabric بـالمواصفات RequestsOnly وLimitsOnly وكل من RequestsAndLimits للذاكرة وCPU.

عند استخدام المواصفة RequestsOnly، يستخدم service fabric أيضاً قيم الطلب كحدود.
عند استخدام المواصفة LimitsOnly، يعتبر service fabric أن قيم الطلب 0.
عند استخدام المواصفة RequestsAndLimits، يجب أن تكون قيم الحدود أكبر من قيم الطلب أو مساوية لها.

لفهم آلية إدارة الموارد بشكل أفضل، دعونا نلقِ نظرة على مثال سيناريو الموضع حيث المواصفة RequestsOnly لمورد CPU (آلية إدارة الذاكرة مكافئة). افترض أن هناك عُقدة بذاكرتي CPU أساسيتين وحزمتي خدمة سيتم وضعهما على هذه العُقدة. حزمة الخدمة الأولى، التي سيتم وضعها، تتكون من حزمة تعليمة برمجية لحاوية واحدة وتحدد فقط طلباً واحداً لذاكرة CPU أساسية واحدة. حزمة الخدمة الثانية، التي سيتم وضعها، تتكون من عملية واحدة فقط تعتمد على حزمة تعليمة برمجية تحدد أيضاً طلباً لذاكرة CPU أساسية واحدة. وبما أن كلاً من حزمتي الخدمة يتضمن المواصفة RequestsOnly، فإن قيم حدودهما تُعيّن على قيم الطلب المرتبط بهما.

توضع حزمة الخدمة المستندة إلى حاوية، والتي تطلب ذاكرة CPU أساسية واحدة على العُقدة. ينشط وقت التشغيل الحاوية و يُعين حد CPU على ذاكرة أساسية واحدة. لن تتمكن الحاوية من استخدام أكثر من ذاكرة أساسية واحدة.
بعد ذلك، تُوضع حزمة الخدمة المستندة إلى العملية، والتي تطلب ذاكرة CPU أساسية واحدة على العُقدة. ينشط وقت التشغيل عملية الخدمة ويعيّن حد CPU على ذاكرة أساسية أساسي واحدة.

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

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

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

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

ملاحظة

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

توجد حالات قليلة قد تحدث فيها منافسة على الاتصال بـ CPU. في هذه الحالات، قد تواجه العملية والحاوية المذكورة في المثال مشكلة الجار الصاخب:

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

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

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

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

فيما يلي مثال على كيفية إرشاد Service Fabric لاستخدام 50٪ من CPU المتاحة و70٪ من الذاكرة المتوفرة:

<Section Name="PlacementAndLoadBalancing">
    <!-- 0.0 means 0%, and 1.0 means 100%-->
    <Parameter Name="CpuPercentageNodeCapacity" Value="0.5" />
    <Parameter Name="MemoryPercentageNodeCapacity" Value="0.7" />
</Section>

بالنسبة إلى معظم العملاء والسيناريوهات، الكشف التلقائي عن سعات العُقد لـ CPU والذاكرة هو التكوين الموصى به (يتم تشغيل الكشف التلقائي افتراضياً). مع ذلك، إذا كنت بحاجة إلى إعداد سعات العُقد يدوياً بالكامل، يمكنك تكوينها لكل نوع عقدة باستخدام آلية وصف العُقد في نظام المجموعة. فيما يلي مثال على كيفية إعداد نوع العقدة بأربعة ذاكرات أساسية وذاكرة بحجم 2 غيغابايت:

    <NodeType Name="MyNodeType">
      <Capacities>
        <Capacity Name="servicefabric:/_CpuCores" Value="4"/>
        <Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
      </Capacities>
    </NodeType>

عند تمكين الكشف التلقائي عن الموارد المتاحة، وتحديد سعات العُقد يدوياً في بيان نظام المجموعة، يتحقق Service Fabric من أن العقدة لديها موارد كافية لدعم السعة التي حددها المستخدم:

إذا كانت سعات العُقد المعرفة في البيان أقل من الموارد المتوفرة على العُقدة أو مساوية لها، فإن Service Fabric يستخدم السعات المحددة في البيان.
إذا كانت سعات العُقد المعرّفة في البيان أكبر من الموارد المتاحة، يستخدم Service Fabric الموارد المتوفرة كسعات للعُقد.

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

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>

للوصول إلى الأداء الأمثل، يجب أيضاً تشغيل الإعداد التالي في بيان نظام المجموعة:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="PreventTransientOvercommit" Value="true" />
    <Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade" Value="true" />
</Section>

هام

بدءاً من الإصدار 7.0 من Service Fabric، تم تحديث القاعدة المتعلقة بكيفية حساب السعة لموارد العُقدة في الحالات التي يوفر فيها المستخدم يدوياً قيم السعة لموارد العُقدة. دعونا نفكر في السيناريو التالي:

هناك إجمالي 10 ذاكرات CPU أساسية على العقدة
تم تكوين SF لاستخدام 80٪ من إجمالي الموارد لخدمات المستخدم (الإعداد الافتراضي)، ما يترك مخزن مؤقت يُقدَّر بحوالي 20٪ للخدمات الأخرى التي تعمل على العقدة (بما في ذلك خدمات نظام Service Fabric)
يقرر المستخدم تجاوز سعة مورد العقدة يدوياً لمقياس الذاكرات الأساسية لـ CPU، ويعيّنها على 5 ذاكرات أساسية

لقد قمنا بتغيير القاعدة المتعلقة بكيفية حساب السعة المتاحة لخدمات مستخدم Service Fabric بالطريقة التالية:

بدءاً من الإصدار Service Fabric 7.0، سيتم حساب السعة المتاحة لخدمات المستخدم على 5 ذاكرات أساسية (لن يتم تجاهل المخزن المؤقت للسعة التي تُقدر بـ 20٪)
بدءاً من الإصدار Service Fabric 7.0، سيتم حساب السعة المتاحة لخدمات المستخدم على 4 ذاكرات أساسية (لن يتم تجاهل المخزن المؤقت للسعة التي تُقدر بـ 20٪)

تحديد إدارة الموارد

يتم تحديد طلبات إدارة الموارد وحدودها في بيان التطبيق (مقطع ServiceManifestImport). دعونا ننظر في بعض الأمثلة:

مثال 1: مواصفات RequestsOnly

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="1"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="1024" />
    </Policies>
  </ServiceManifestImport>

في هذا المثال، تُستخدم السمة CpuCores لتحديد طلب ذاكرة CPU أساسية واحدة لـ ServicePackageA. بما أن الحد الأقصى لـ CPU غير معرّف (سمة CpuCoresLimit)، فسيستخدم Service Fabric أيضاً قيمة الطلب المحدد لذاكرة واحدة أساسية كحد أقصى لـ CPU لحزمة الخدمة.

تُوضع ServicePackageA فقط في عقدة حيث تكون سعة الذاكرة المتبقية بعد طرح مجموع طلبات CPU لجميع حزم الخدمات الموضوعة على تلك العقدة أكبر من أو تساوي ذاكرة أساسية واحدة. في العقدة، ستقتصر حزمة الخدمة على ذاكرة أساسية واحدة. تحتوي حزمة الخدمة على حزمتي تعليمات برمجية (CodeA1 وCodeA2) وكل منهما يحدد السمة CpuShares. تُستخدم نسبة CpuShares 512:256 لحساب حدود CPU لحزمة التعليمة البرمجية الواحدة. لذا، سيقتصر CodeA1 على ثلثي الذاكرة الأساسية الواحدة، وسيقتصر CodeA2 على ثلث الذاكرة الأساسية الواحدة. إذا لم يتم تحديد CpuShares لكل حزم التعليمات البرمجية، يقسّم Service Fabric حد CPU بالتساوي عليها.

بينما يمثل CpuShares المحدد لحزم التعليمات البرمجية النسبة ذات الصلة بحد CPU الكلي لحزمة الخدمة، يتم تحديد قيم الذاكرة لحزم التعليمات البرمجية بقيم مطلقة. في هذا المثال، تُستخدم السمة MemoryInMB لتحديد طلبات الذاكرة التي تُقدر بـ 1024 ميغابايت لكل من CodeA1 وCodeA2. بما أن حد الذاكرة (سمة MemoryInMBLimit) لم يحدد، فسيستخدم Service Fabric أيضاً قيم الطلبات المعرّفة كحدود لحزم التعليمات البرمجية. يُحسب طلب الذاكرة (والحد) لحزمة الخدمة باعتباره مجموع قيم طلبات الذاكرة (والحد) من حزم التعليمات البرمجية المكونة لها. إذن، بالنسبة إلى ServicePackageA، يُحسب طلب الذاكرة والحد الأقصى على أنه 2048 ميغابايت.

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

مثال 2: مواصفات LimitsOnly

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCoresLimit="1"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMBLimit="1024" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMBLimit="1024" />
    </Policies>
  </ServiceManifestImport>

يستخدم هذا المثال سمتي CpuCoresLimit وMemoryInMBLimit، واللتين تتوفران فقط في إصدارات SF 7.2 والإصدارات الأحدث. تُستخدم سمة CpuCoresLimit لتعيين الحد الأقصى لـ CPU على ذاكرة أساسية واحدة ServicePackageA. بما أن طلب CPU (سمة CpuCores) لم يُحدد، فسيتم التعامل باعتباره 0. MemoryInMBLimit تُستخدم سمة لتعريف حدود الذاكرة على 1024 ميغابايت لـ CodeA1 وCodeA2 وبما أن الطلبات (سمة MemoryInMB) غير محددة، فإنها تعتبر 0. ومن ثم، يُحسب طلب الذاكرة والحد الأقصى لـ ServicePackageA على أنهما 0 و2048 على التوالي. بما أن كلاً من طلبات الذاكرة وCPU لـ ServicePackageA هي 0، فإنها لا تشكّل أي حمل على CRM يلزم وضعه، لمقاييس servicefabric:/_CpuCores وservicefabric:/_MemoryInMB. لذا، من منظور إدارة الموارد، يمكن وضع ServicePackageA على أي عقدة بغض النظر عن السعة المتبقية. على غرار المثال 1، سيقتصر CodeA1 في العقدة على ثلثي الذاكرة الأساسية و1024 ميغابايت من الذاكرة، وسيقتصر CodeA2 على ثلث الذاكرة الأساسية و1024 ميغابايت من الذاكرة.

مثال 3: مواصفات RequestsAndLimits

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="1" CpuCoresLimit="2"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" MemoryInMBLimit="3072" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="2048" MemoryInMBLimit="4096" />
    </Policies>
  </ServiceManifestImport>

بناءً على المثالين الأولين، يوضح هذا المثال كيفية تحديد كل من طلبات وحدود الذاكرة وCPU. يحتوي ServicePackageA على طلبات ذاكرة وCPU لذاكرة واحدة أساسية و3072 (1024 + 2048) ميغابايت على التوالي. يمكن وضعها فقط على عُقدة تحتوي على ذاكرة أساسية واحدة على الأقل (و3072 ميغابايت) متبقية من السعة بعد طرح إجمالي طلبات CPU (والذاكرة) لجميع حزم الخدمة الموضوعة على العُقدة من إجمالي سعة CPU (والذاكرة) للعُقدة. في العقدة، سيُحدد لـ CodeA1 ثلثي ذاكرتين أساسيتين و3072 ميغابايت من الذاكرة بينما سيُحدد لـ CodeA2 ثلث ذاكرتين أساسيتين و4096 ميغابايت من الذاكرة.

استخدام معلّمات التطبيق

عند تحديد إعدادات إدارة الموارد، من الممكن استخدام معلّمات التطبيق لإدارة تكوينات تطبيقات متعددة. يوضح المثال التالي كيفية استخدام معلّمات التطبيق:

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>

  <Parameters>
    <Parameter Name="CpuCores" DefaultValue="4" />
    <Parameter Name="CpuSharesA" DefaultValue="512" />
    <Parameter Name="CpuSharesB" DefaultValue="512" />
    <Parameter Name="MemoryA" DefaultValue="2048" />
    <Parameter Name="MemoryB" DefaultValue="2048" />
  </Parameters>

  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="[CpuSharesA]" MemoryInMB="[MemoryA]" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="[CpuSharesB]" MemoryInMB="[MemoryB]" />
    </Policies>
  </ServiceManifestImport>

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

<!-- ApplicationParameters\Local.xml -->

<Application Name="fabric:/TestApplication1" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="CpuCores" DefaultValue="2" />
    <Parameter Name="CpuSharesA" DefaultValue="512" />
    <Parameter Name="CpuSharesB" DefaultValue="512" />
    <Parameter Name="MemoryA" DefaultValue="1024" />
    <Parameter Name="MemoryB" DefaultValue="1024" />
  </Parameters>
</Application>

هام

ستتوفر إمكانية تحديد إدارة الموارد باستخدام معلّمات التطبيق بدءاً من الإصدار 6.1 لـ Service Fabric.

عند استخدام معلّمات التطبيق لتحديد إدارة الموارد، لا يمكن إرجاع Service Fabric إلى إصدار أقدم من الإصدار 6.1.

فرض حدود الموارد لخدمات المستخدمين

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

استهلاك الموارد من الخدمات الأخرى التي يتم تشغيلها على العُقد (بما في ذلك خدمات نظام Service Fabric)
العُقد التي تنتهي بحالة غير سليمة
واجهات برمجة التطبيقات لإدارة نظام مجموعة Service Fabric لا تستجيب

لمنع حدوث مثل هذه الحالات، يسمح لك Service Fabric بـ فرض حدود الموارد لجميع خدمات مستخدم Service Fabric الذي يعمل على العُقدة (المُدارة وغير المُدارة) لضمان عدم استخدام خدمات المستخدم أكثر من الكمية المحددة من الموارد. يتحقق ذلك بتعيين قيمة تكوين EnforceUserServiceMetricCapacities في المقطع PlacementAndLoadBalancing لـ ClusterManifest على true. يتم إيقاف تشغيل هذا الإعداد بشكل افتراضي.

<SectionName="PlacementAndLoadBalancing">
    <ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>

ملاحظات إضافية:

ينطبق فرض حد الموارد فقط على مقاييس موارد servicefabric:/_CpuCores وservicefabric:/_MemoryInMB
لا يعمل فرض الحد على الموارد إلا إذا كانت سعات العُقد لمقاييس الموارد متوفرة لـ Service Fabric، إما عبر آلية الكشف التلقائي، أو عبر المستخدمين الذين يحددون سعات العُقد يدوياً (كما هو موضح في المقطع إعداد Cluster لتمكين إدارة الموارد). إذا لم يتم تكوين سعات العُقد، فلا يمكن استخدام إمكانية فرض حد على المورد نظرا لأن Service Fabric لا يمكن أن يعرف حجم الموارد التي يجب حجزها لخدمات المستخدم. سيُصدر Service Fabric تحذير سلامة إذا كان "EnforceUserServiceMetricCapacities" معيناً على true ولم يتم تكوين سعات العُقدة.

الموارد الأخرى للحاويات

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

MemorySwapInMB:إجمالي حجم الذاكرة الظاهرية التي يمكن استخدامها، بالميغابايت. يجب أن تكون عدداً صحيحاً موجباً.
MemoryReservationInMBالحد المبدئي (بالميغابايت) لإدارة الذاكرة، والذي يتم فرضه فقط عند اكتشاف المنافسة على الاتصال بالذاكرة على العُقدة. يجب أن تكون عدداً صحيحاً موجباً.
CpuPercent: النسبة المئوية القابلة للاستخدام من وحدات CPU المتاحة (Windows فقط). يجب أن تكون عدداً صحيحاً موجباً. لا يمكن استخدامها مع CpuShares أو CpuCores أو CpuCoresLimit.
CpuShares: الوزن النسبي لـ CPU. يجب أن تكون عدداً صحيحاً موجباً. لا يمكن استخدامها مع CpuPercent أو CpuCores أو CpuCoresLimit.
MaximumIOps:الحد الأقصى لمعدل الإدخال/الإخراج (للقراءة والكتابة) من حيث عدد مرات الإدخال والإخراج في الثانية التي يمكن استخدامها. يجب أن تكون عدداً صحيحاً موجباً.
MaximumIOBandwidth: الحد الأقصى للإدخال والإخراج (بالبايت لكل ثانية) الذي يمكن استخدامه (للقراءة والكتابة). يجب أن تكون عدداً صحيحاً موجباً.
BlockIOWeightوزن الإدخال/الإخراج للكتلة، مرتبط بحزم التعليمات البرمجية الأخرى. يجب أن يكون عددًا صحيحًا موجبًا بين 10 و1000.
DiskQuotaInMB: الحصة النسبية لأقراص الحاويات. يجب أن تكون عدداً صحيحاً موجباً.
KernelMemoryInMB: حدود ذاكرة Kernel بالبايت. يجب أن تكون عدداً صحيحاً موجباً. لاحظ أن هذا خاص بنظام Linux، وسيفشل Docker على نظام Windows مع رسالة خطأ إذا عينت ذلك.
ShmSizeInMB: حجم /dev/shm بالبايت. إذا حُذف، فسيستخدم النظام 64 ميغابايت. يجب أن تكون عدداً صحيحاً موجباً. لاحظ أن هذا خاص بنظام Linux، ولكن، Docker سوف يتجاهل فقط ذلك (لكنه لن يفشل بخطأ) إذا تم تحديده.

يمكن دمج هذه الموارد مع CPU والذاكرة. فيما يلي مثال على كيفية تحديد موارد إضافية للحاويات:

    <ServiceManifestImport>
        <ServiceManifestRef ServiceManifestName="FrontendServicePackage" ServiceManifestVersion="1.0"/>
        <Policies>
            <ResourceGovernancePolicy CodePackageRef="FrontendService.Code" CpuPercent="5"
            MemorySwapInMB="4084" MemoryReservationInMB="1024" MaximumIOPS="20" />
        </Policies>
    </ServiceManifestImport>

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

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

مشاركة عبر

إدارة الموارد

مقاييس إدارة الموارد

آلية إدارة الموارد

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

تحديد إدارة الموارد

استخدام معلّمات التطبيق

فرض حدود الموارد لخدمات المستخدمين

الموارد الأخرى للحاويات

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

الملاحظات

الملاحظات

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