مشاركة عبر

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

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

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

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

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

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

  • الذاكرة (اسم servicefabric:/_MemoryInMBالقياس): يتم التعبير عن الذاكرة بالميغابايت، ويتم تعيينها إلى الذاكرة الفعلية المتوفرة على الجهاز.

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

ملاحظة

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

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

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

ملاحظة

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

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

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

ملاحظة

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

  • الطلبات: تمثل قيم طلب وحدة المعالجة المركزية والذاكرة الأحمال المستخدمة من قبل Cluster Resource Manager (CRM) للمقاييس servicefabric:/_CpuCores و servicefabric:/_MemoryInMB . بمعنى آخر، تعتبر إدارة علاقات العملاء استهلاك الموارد لخدمة ما مساويا لقيم طلبها وتستخدم هذه القيم عند اتخاذ قرارات الموضع.

  • حدود: تمثل قيم حد وحدة المعالجة المركزية والذاكرة حدود الموارد الفعلية المطبقة عند تنشيط عملية أو حاوية على عقدة.

يسمح Service Fabric بالطلباتOnly و LimitsOnly ومواصفات RequestsAndLimits لوحدة المعالجة المركزية والذاكرة.

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

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

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

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

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

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

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

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

ملاحظة

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

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

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

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

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

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

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

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

فيما يلي مثال على كيفية إرشاد Service Fabric لاستخدام 50% من وحدة المعالجة المركزية المتاحة و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>

بالنسبة لمعظم العملاء والسيناريوهات، يكون الكشف التلقائي عن قدرات العقدة لوحدة المعالجة المركزية والذاكرة هو التكوين الموصى به (يتم تشغيل الكشف التلقائي بشكل افتراضي). ومع ذلك، إذا كنت بحاجة إلى إعداد يدوي كامل لسعات العقدة، يمكنك تكوينها لكل نوع عقدة باستخدام آلية وصف العقد في نظام المجموعة. فيما يلي مثال على كيفية إعداد نوع العقدة بأربعة ذاكرات أساسية وذاكرة 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>

هام

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

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

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

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

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

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

مثال 1: مواصفات الطلبات فقط

<?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 لتحديد طلب 1 ذاكرة أساسية لوحدة المعالجة المركزية ل ServicePackageA. نظرا لعدم تحديد حد وحدة المعالجة المركزية (CpuCoresLimit سمة)، يستخدم Service Fabric أيضا قيمة الطلب المحددة البالغة 1 نواة كحد وحدة المعالجة المركزية لحزمة الخدمة.

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

بينما تمثل CpuShares المحددة لحزم التعليمات البرمجية نسبة نسبية لها من الحد الإجمالي لوحدة المعالجة المركزية لحزمة الخدمة، يتم تحديد قيم الذاكرة لحزم التعليمات البرمجية بالمصطلحات المطلقة. في هذا المثال، يتم استخدام السمة 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>

يستخدم CpuCoresLimitMemoryInMBLimit هذا المثال والسمات، والتي تتوفر فقط في إصدارات SF 7.2 والإصدارات الأحدث. يتم استخدام السمة CpuCoresLimit لتحديد حد وحدة المعالجة المركزية من ذاكرة أساسية واحدة ل ServicePackageA. نظرا لعدم تحديد طلب وحدة المعالجة المركزية (CpuCores سمة)، فإنه يعتبر 0. MemoryInMBLimit تستخدم السمة لتحديد حدود الذاكرة 1024 ميغابايت ل CodeA1 وCodeA2 وبما أن الطلبات (MemoryInMB السمة) غير محددة، فإنها تعتبر 0. وبالتالي يتم حساب طلب الذاكرة وحدود ServicePackageA ك 0 و2048 على التوالي. نظرا لأن كل من طلبات وحدة المعالجة المركزية والذاكرة ل 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>

بناء على المثالين الأولين، يوضح هذا المثال تحديد كل من الطلبات والحدود لوحدة المعالجة المركزية والذاكرة. يحتوي ServicePackageA على وحدة المعالجة المركزية وطلبات الذاكرة من 1 ذاكرة أساسية و3072 (1024 + 2048) ميغابايت على التوالي. يمكن وضعه فقط على عقدة تحتوي على نواة واحدة على الأقل (و3072 ميغابايت) من السعة المتبقية بعد طرح مجموع جميع طلبات وحدة المعالجة المركزية (والذاكرة) لجميع حزم الخدمة التي يتم وضعها على العقدة من إجمالي سعة وحدة المعالجة المركزية (والذاكرة) للعقدة. على العقدة، سيقتصر 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>

هام

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

عند استخدام معلمات التطبيق لتحديد إدارة الموارد، لا يمكن تخفيض 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، إما عبر آلية الكشف التلقائي، أو عبر المستخدمين الذين يحددون قدرات العقدة يدويا (كما هو موضح في إعداد نظام المجموعة لتمكين قسم إدارة الموارد ). إذا لم يتم تكوين قدرات العقدة، فلا يمكن استخدام إمكانية فرض حد الموارد نظرا لأن Service Fabric لا يمكنه معرفة مقدار الموارد التي يجب حجزها لخدمات المستخدم. سيصدر Service Fabric تحذيرا صحيا إذا كان "EnforceUserServiceMetricCapacities" صحيحا ولكن لم يتم تكوين قدرات العقدة.

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

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

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

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

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

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