Kaynak idaresi

Aynı düğümde veya kümede birden çok hizmet çalıştırdığınızda, bir hizmet daha fazla kaynak tüketerek işlemdeki diğer hizmetleri aç bırakabilir. Bu soruna "gürültülü komşu" sorunu denir. Azure Service Fabric, kaynak kullanımını sınırlamak için hizmet başına istekler ve sınırlar belirterek geliştiricinin bu davranışı denetlemesini sağlar.

Bu makaleye devam etmeden önce Service Fabric uygulama modeli ve Service Fabric barındırma modeli hakkında bilgi edinmenizi öneririz.

Kaynak idaresi ölçümleri

Hizmet paketine uygun olarak Service Fabric'te kaynak idaresi desteklenir. Hizmet paketine atanan kaynaklar kod paketleri arasında daha fazla bölünebilir. Service Fabric, iki yerleşik ölçümle hizmet paketi başına CPU ve bellek idaresini destekler:

• CPU (ölçüm adı servicefabric:/_CpuCores): Konak makinede kullanılabilen mantıksal çekirdek. Tüm düğümlerdeki tüm çekirdekler aynı ağırlıklıdır.

• Bellek (ölçüm adı servicefabric:/_MemoryInMB): Bellek megabayt cinsinden ifade edilir ve makinede bulunan fiziksel belleğe eşler.

Bu iki ölçüm için Küme Resource Manager (CRM), toplam küme kapasitesini, kümedeki her düğümdeki yükü ve kümedeki kalan kaynakları izler. Bu iki ölçüm, diğer tüm kullanıcılara veya özel ölçümlere eşdeğerdir.

Tüm mevcut özellikler bunlarla kullanılabilir:

• Küme, bu iki ölçüme (varsayılan davranış) göre dengelenebilir.
• Küme bu iki ölçüme göre birleştirilebilir .
• Bir kümeyi açıklarken, bu iki ölçüm için arabelleğe alınan kapasite ayarlanabilir.

Kaynak idare mekanizması

Sürüm 7.2'den başlayarak Service Fabric çalışma zamanı, CPU ve bellek kaynakları için isteklerin ve sınırların belirtimini destekler.

• İstekler: CPU ve bellek isteği değerleri, Ve servicefabric:/_MemoryInMB ölçümleri için servicefabric:/_CpuCores Küme Resource Manager (CRM) tarafından kullanılan yükleri temsil eder. Başka bir deyişle CRM, bir hizmetin kaynak tüketimini istek değerlerine eşit olarak değerlendirir ve yerleştirme kararları alırken bu değerleri kullanır.

• Sınırlar: CPU ve Bellek sınırı değerleri, düğümde bir işlem veya kapsayıcı etkinleştirildiğinde uygulanan gerçek kaynak sınırlarını temsil eder.

Service Fabric, Cpu ve bellek için RequestsOnly, LimitsOnly ve requestsAndLimits belirtimlerine izin verir.

• RequestsOnly belirtimi kullanıldığında, service fabric istek değerlerini de sınır olarak kullanır.
• LimitsOnly belirtimi kullanıldığında, service fabric istek değerlerini 0 olarak değerlendirir.
• RequestsAndLimits belirtimi kullanıldığında, sınır değerleri istek değerlerine eşit veya ondan büyük olmalıdır.

Kaynak idare mekanizmasını daha iyi anlamak için CPU kaynağı için RequestsOnly belirtimi (bellek idaresi mekanizması eşdeğerdir) içeren örnek bir yerleştirme senaryosuna göz atalım. İki CPU çekirdeğine ve üzerine yerleştirilecek iki hizmet paketine sahip bir düğümü düşünün. Yerleştirilecek ilk hizmet paketi yalnızca bir kapsayıcı kodu paketinden oluşur ve yalnızca bir CPU çekirdeği isteğini belirtir. Yerleştirilecek ikinci hizmet paketi, yalnızca bir işlem tabanlı kod paketinden oluşur ve ayrıca yalnızca bir CPU çekirdeği isteğini belirtir. Her iki hizmet paketinin requestsOnly belirtimi olduğundan, sınır değerleri istek değerlerine ayarlanır.

1. İlk olarak bir CPU çekirdeği isteyen kapsayıcı tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı kapsayıcıyı etkinleştirir ve CPU sınırını tek bir çekirdek olarak ayarlar. Kapsayıcı birden fazla çekirdek kullanamaz.

2. Ardından, bir CPU çekirdeği isteyen işlem tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı hizmet işlemini etkinleştirir ve CPU sınırını tek bir çekirdek olarak ayarlar.

Bu noktada isteklerin toplamı düğümün kapasitesine eşittir. CRM, bu düğüme CPU istekleriyle başka kapsayıcı veya hizmet işlemi yerleştirmez. Düğümde, bir işlem ve kapsayıcı her biri bir çekirdekle çalışır ve CPU için birbirleriyle tartışmaz.

Şimdi örneğimizi requestsAndLimits belirtimi ile yeniden gözden geçirelim. Bu kez kapsayıcı tabanlı hizmet paketi bir CPU çekirdeği isteği ve iki CPU çekirdeği sınırı belirtir. İşlem tabanlı hizmet paketi hem istek hem de bir CPU çekirdeği sınırı belirtir.

1. İlk olarak kapsayıcı tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı kapsayıcıyı etkinleştirir ve CPU sınırını iki çekirdeğe ayarlar. Kapsayıcı ikiden fazla çekirdek kullanamaz.
2. Ardından işlem tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı hizmet işlemini etkinleştirir ve CPU sınırını tek bir çekirdek olarak ayarlar.

Bu noktada, düğüme yerleştirilen hizmet paketlerinin CPU isteklerinin toplamı düğümün CPU kapasitesine eşittir. CRM, bu düğüme CPU istekleriyle başka kapsayıcı veya hizmet işlemi yerleştirmez. Ancak düğümde sınırların toplamı (kapsayıcı için iki çekirdek + işlem için bir çekirdek) iki çekirdeğin kapasitesini aşıyor. Kapsayıcı ve işlem aynı anda patlarsa, CPU kaynağı için çekişme olasılığı vardır. Bu tür çekişmeler platform için temel işletim sistemi tarafından yönetilir. Bu örnekte kapsayıcı iki cpu çekirdeğine kadar artarak işlemin bir CPU çekirdeği isteğinin garanti edilmemesiyle sonuçlanabilir.

CPU için çekişme olabileceği birkaç durum vardır. Bu gibi durumlarda örneğimizdeki işlem ve kapsayıcı gürültülü komşu sorunuyla karşılaşabilir:

• İdare edilen ve yönetilmeyen hizmetlerle kapsayıcıları karıştırma: Kullanıcı herhangi bir kaynak idaresi belirtilmeden bir hizmet oluşturursa, çalışma zamanı bunu kaynak tüketen olarak görür ve örneğimizdeki düğüme yerleştirebilir. Bu durumda, bu yeni işlem düğümde zaten çalışmakta olan hizmetlerin pahasına bazı CPU'ları etkili bir şekilde tüketir. Bu sorunun iki çözümü vardır. Yönetilen ve yönetilmeyen hizmetleri aynı kümede karıştırmayın veya yerleştirme kısıtlamalarını kullanarak bu iki hizmet türünün aynı düğüm kümesine varmaması için kullanın.

• Düğümde Service Fabric dışında başka bir işlem başlatıldığında (örneğin, bir işletim sistemi hizmeti): Bu durumda, Service Fabric dışındaki işlem de mevcut hizmetlerle CPU'yu belirler. Bu sorunun çözümü, sonraki bölümde gösterildiği gibi işletim sistemi ek yükünü hesaba katmak için düğüm kapasitelerini doğru şekilde ayarlamaktır.

• İstekler sınırlara eşit olmadığında: Daha önce RequestsAndLimits örneğinde açıklandığı gibi, istekler düğümdeki kaynakların rezervasyonunu sağlamaz. İsteklerden daha büyük sınırları olan bir hizmet bir düğüme yerleştirildiğinde, bu sınırlara kadar kaynakları (varsa) tüketebilir. Böyle durumlarda düğümdeki diğer hizmetler, istek değerlerine kadar olan kaynakları kullanamayabilir.

Kaynak idaresini etkinleştirmek için küme kurulumu

Bir düğüm başlatıldığında ve kümeye katıldığında Service Fabric kullanılabilir bellek miktarını ve kullanılabilir çekirdek sayısını algılar ve ardından bu iki kaynak için düğüm kapasitelerini ayarlar.

service Fabric, işletim sistemi ve düğümde çalışıyor olabilecek diğer işlemler için arabellek alanı bırakmak için düğümdeki kullanılabilir kaynakların yalnızca %80'ini kullanır. Bu yüzde yapılandırılabilir ve küme bildiriminde değiştirilebilir.

Service Fabric'e kullanılabilir CPU'nun %50'sini ve kullanılabilir belleğin %70'ini kullanma talimatı vermenin bir örneği aşağıda verilmiştir:

<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>

Çoğu müşteri ve senaryo için cpu ve bellek için düğüm kapasitelerinin otomatik olarak algılanması önerilen yapılandırmadır (otomatik algılama varsayılan olarak açıktır). Ancak, düğüm kapasitelerinin tam el ile ayarlanması gerekiyorsa, kümedeki düğümleri açıklama mekanizmasını kullanarak düğüm türü başına bunları yapılandırabilirsiniz. Dört çekirdek ve 2 GB bellek ile düğüm türünün nasıl ayarlanacağına ilişkin bir örnek aşağıda verilmiştir:

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

Kullanılabilir kaynakların otomatik olarak algılanması etkinleştirildiğinde ve düğüm kapasiteleri küme bildiriminde el ile tanımlandığında, Service Fabric düğümün kullanıcının tanımladığı kapasiteyi desteklemek için yeterli kaynağa sahip olduğunu denetler:

• Bildirimde tanımlanan düğüm kapasiteleri düğümdeki kullanılabilir kaynaklara eşit veya daha küçükse Service Fabric bildirimde belirtilen kapasiteleri kullanır.

• Bildirimde tanımlanan düğüm kapasiteleri kullanılabilir kaynaklardan büyükse, Service Fabric kullanılabilir kaynakları düğüm kapasiteleri olarak kullanır.

Gerekli değilse kullanılabilir kaynakların otomatik olarak algılanması kapatılabilir. Kapatmak için aşağıdaki ayarı değiştirin:

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

En iyi performans için küme bildiriminde aşağıdaki ayarın da açık olması gerekir:

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

Kaynak idaresi belirtme

Kaynak idare istekleri ve sınırları uygulama bildiriminde (ServiceManifestImport bölümü) belirtilir. Bazı örneklere bakalım:

Örnek 1: RequestsOnly belirtimi

<?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>

Bu örnekte özniteliği ServicePackageA CpuCoresiçin 1 CPU çekirdeği isteği belirtmek için kullanılır. CPU sınırı (CpuCoresLimit öznitelik) belirtilmediğinden Service Fabric, hizmet paketi için CPU sınırı olarak 1 çekirdeğin belirtilen istek değerini de kullanır.

ServicePackageA yalnızca bu düğüme yerleştirilen tüm hizmet paketlerinin CPU isteklerinin toplamını çıkardıktan sonra kalan CPU kapasitesinin 1 çekirdekten büyük veya buna eşit olduğu bir düğüme yerleştirilir. Düğümde hizmet paketi tek bir çekirdekle sınırlandırılır. Hizmet paketi iki kod paketi (CodeA1 ve CodeA2) içerir ve her ikisi de özniteliğini CpuShares belirtir. CpuShares 512:256 oranı, tek tek kod paketlerinin CPU sınırlarını hesaplamak için kullanılır. Bu nedenle CodeA1, bir çekirdeğin üçte ikisi ile, CodeA2 ise çekirdeğin üçte biriyle sınırlandırılır. Tüm kod paketleri için CpuShares belirtilmezse, Service Fabric CPU sınırını aralarında eşit olarak böler.

Kod paketleri için belirtilen CpuShare'ler hizmet paketinin genel CPU sınırının göreli oranını temsil ederken, kod paketleri için bellek değerleri mutlak terimlerle belirtilir. Bu örnekte özniteliği, MemoryInMB hem CodeA1 hem de CodeA2 için 1024 MB bellek isteklerini belirtmek için kullanılır. Bellek sınırı (MemoryInMBLimit öznitelik) belirtilmediğinden, Service Fabric kod paketleri için sınırlar olarak belirtilen istek değerlerini de kullanır. Hizmet paketi için bellek isteği (ve sınırı), bağlı kod paketlerinin bellek isteği (ve sınırı) değerlerinin toplamı olarak hesaplanır. Bu nedenle ServicePackageA için bellek isteği ve sınırı 2048 MB olarak hesaplanır.

ServicePackageA yalnızca bu düğüme yerleştirilen tüm hizmet paketlerinin bellek isteklerinin toplamını çıkardıktan sonra kalan bellek kapasitesinin 2048 MB'tan büyük veya buna eşit olduğu bir düğüme yerleştirilir. Düğümde her iki kod paketi de 1024 MB bellekle sınırlandırılır. Kod paketleri (kapsayıcılar veya işlemler) bu sınırdan daha fazla bellek ayıramaz ve bunu yapmaya çalışmak bellek dışı özel durumlarla sonuçlanır.

Örnek 2: LimitsOnly belirtimi

<?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>

Bu örnek, yalnızca 7.2 ve sonraki SF sürümlerinde kullanılabilen ve MemoryInMBLimit özniteliklerini kullanırCpuCoresLimit. CpuCoresLimit özniteliği, ServicePackageA için 1 çekirdek cpu sınırı belirtmek için kullanılır. CPU isteği (CpuCores öznitelik) belirtilmediğinden 0 olarak kabul edilir. MemoryInMBLimit özniteliği CodeA1 ve CodeA2 için 1024 MB bellek sınırlarını belirtmek için kullanılır ve istekler (MemoryInMB öznitelik) belirtilmediğinden 0 olarak kabul edilir. Bu nedenle ServicePackageA için bellek isteği ve sınırı sırasıyla 0 ve 2048 olarak hesaplanır. ServicePackageA için hem CPU hem de bellek istekleri 0 olduğundan, CRM'nin ve servicefabric:/_MemoryInMB ölçümleri için yerleştirmeyi göz önünde bulundurması servicefabric:/_CpuCores gereken bir yük sunmaz. Bu nedenle, kaynak idaresi perspektifinden bakıldığında ServicePackageA kalan kapasiteden bağımsız olarak herhangi bir düğüme yerleştirilebilir. Örnek 1'e benzer şekilde, düğümdeki CodeA1 bir çekirdeğin üçte ikisi ve 1024 MB bellekle, CodeA2 ise çekirdeğin üçte biriyle ve 1024 MB bellekle sınırlandırılır.

Örnek 3: RequestsAndLimits belirtimi

<?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>

İlk iki örneği temel alan bu örnek, CPU ve bellek için hem istekleri hem de sınırları belirtmeyi gösterir. ServicePackageA sırasıyla 1 çekirdek ve 3072 (1024 + 2048) MB CPU ve bellek isteklerine sahiptir. Düğümün toplam CPU (ve bellek) kapasitesinden düğüme yerleştirilen tüm hizmet paketlerinin tüm CPU (ve bellek) isteklerinin toplamı çıkarıldıktan sonra en az 1 çekirdek (ve 3072 MB) kapasiteye sahip bir düğüme yerleştirilebilir. Düğümde CodeA1, 2 çekirdeğin üçte ikisi ve 3072 MB bellekle, CodeA2 ise 2 çekirdeğin üçte biriyle ve 4096 MB bellekle sınırlandırılır.

Uygulama parametrelerini kullanma

Kaynak idaresi ayarlarını belirtirken, birden çok uygulama yapılandırmasını yönetmek için uygulama parametrelerini kullanmak mümkündür. Aşağıdaki örnekte uygulama parametrelerinin kullanımı gösterilmektedir:

<?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>

Bu örnekte, her Hizmet Paketinin 4 çekirdek ve 2 GB bellek elde ettiği üretim ortamı için varsayılan parametre değerleri ayarlanır. Uygulama parametre dosyalarıyla varsayılan değerleri değiştirmek mümkündür. Bu örnekte, uygulamayı yerel olarak test için bir parametre dosyası kullanılabilir ve burada üretimden daha az kaynak alabilir:

<!-- 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>

Kullanıcı hizmetleri için kaynak sınırlarını zorunlu tutma

Service Fabric hizmetlerinize kaynak idaresi uygulanması, kaynak tarafından yönetilen hizmetlerin kaynak kotasını aşamayacağını garanti ederken, birçok kullanıcının service Fabric hizmetlerinin bazılarını hala devre dışı modda çalıştırması gerekir. Ungoverned Service Fabric hizmetlerini kullanırken, "runaway" kullanılmayan hizmetlerin Service Fabric düğümlerinde kullanılabilir tüm kaynakları kullandığı ve bu da aşağıdaki gibi ciddi sorunlara yol açabilecek durumlarla karşılaşılabilir:

• Düğümlerde çalışan diğer hizmetlerin kaynak açlığı (Service Fabric sistem hizmetleri dahil)
• İyi durumda olmayan bir durumda biten düğümler
• Yanıt vermeyen Service Fabric küme yönetimi API'leri

Bu durumların oluşmasını önlemek için Service Fabric, kullanıcı hizmetlerinin hiçbir zaman belirtilen kaynak miktarından fazlasını kullanmayacağını garanti etmek için düğümde çalışan tüm Service Fabric kullanıcı hizmetlerinin (hem idare hem de devre dışı) kaynak sınırlarını zorunlu kılmanıza olanak tanır. Bu, ClusterManifest'in PlacementAndLoadBalancing bölümündeki EnforceUserServiceMetricCapacities yapılandırmasının değeri true olarak ayarlanarak elde edilir. Bu ayar varsayılan olarak kapalıdır.

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

Ek açıklamalar:

• Kaynak sınırı zorlaması yalnızca ve servicefabric:/_MemoryInMB kaynak ölçümleri için servicefabric:/_CpuCores geçerlidir
• Kaynak sınırı zorlaması yalnızca otomatik algılama mekanizması aracılığıyla veya düğüm kapasitelerini el ile belirten kullanıcılar aracılığıyla (kaynak idaresini etkinleştirmeye yönelik Küme kurulumu bölümünde açıklandığı gibi) kaynak ölçümleri için düğüm kapasiteleri Service Fabric tarafından kullanılabiliyorsa çalışır. Düğüm kapasiteleri yapılandırılmamışsa, Service Fabric kullanıcı hizmetleri için ne kadar kaynak ayıracaklarını bilmediğinden kaynak sınırı zorlama özelliği kullanılamaz. "EnforceUserServiceMetricCapacities" doğruysa ancak düğüm kapasiteleri yapılandırılmadıysa Service Fabric bir sistem durumu uyarısı verecek.

Kapsayıcılar için diğer kaynaklar

CPU ve belleğin yanı sıra kapsayıcılar için başka kaynak sınırları da belirtebilirsiniz. Bu sınırlar kod paketi düzeyinde belirtilir ve kapsayıcı başlatıldığında uygulanır. CPU ve bellek kullanımından farklı olarak, Küme Kaynak Yöneticisi bu kaynakların farkında değildir ve bunlar için kapasite denetimi veya yük dengelemesi yapmaz.

• MemorySwapInMB: Mb cinsinden kullanılabilecek toplam takas belleği miktarıdır. Pozitif bir tamsayı olmalıdır.
• MemoryReservationInMB: Yalnızca düğümde bellek çekişmesi algılandığında uygulanan bellek idaresi için geçici sınır (MB cinsinden). Pozitif bir tamsayı olmalıdır.
• CpuPercent: Kullanılabilir CPU'ların kullanılabilir yüzdesi (yalnızca Windows). Pozitif bir tamsayı olmalıdır. CpuShares, CpuCores veya CpuCoresLimit ile kullanılamaz.
• CpuShares: Göreli CPU ağırlığı. Pozitif bir tamsayı olmalıdır. CpuPercent, CpuCores veya CpuCoresLimit ile kullanılamaz.
• MaximumIOps: Kullanılabilecek IOps açısından en yüksek GÇ oranı (okuma ve yazma). Pozitif bir tamsayı olmalıdır.
• MaximumIOBandwidth: Kullanılabilecek maksimum GÇ (saniye başına bayt sayısı) (okuma ve yazma). Pozitif bir tamsayı olmalıdır.
• BlockIOWeight: Diğer kod paketlerine göre GÇ ağırlığını engelleyin. 10 ile 1000 arasında pozitif bir tamsayı olmalıdır.
• DiskQuotaInMB: Kapsayıcılar için disk kotası. Pozitif bir tamsayı olmalıdır.
• KernelMemoryInMB: Bayt cinsinden çekirdek bellek sınırları. Pozitif bir tamsayı olmalıdır. Bunun Linux'a özgü olduğunu ve Windows'ta Docker'ın ayarlı olması durumunda hata oluştuğuna dikkat edin.
• ShmSizeInMB: Bayt cinsinden /dev/shm boyutu. Atlanırsa, sistem 64 MB kullanır. Pozitif bir tamsayı olmalıdır. Bunun Linux'a özgü olduğuna dikkat edin, ancak Docker belirtilirse yalnızca yoksayar (hata vermez).

Bu kaynaklar CPU ve bellekle birleştirilebilir. Kapsayıcılar için ek kaynakların nasıl belirtileceğini gösteren bir örnek aşağıda verilmiştir:

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

Sonraki adımlar

• Küme Kaynak Yöneticisi hakkında daha fazla bilgi edinmek için Service Fabric küme kaynak yöneticisine giriş bölümünü okuyun.
• Uygulama modeli, hizmet paketleri ve kod paketleri hakkında daha fazla bilgi edinmek ve çoğaltmaların bunlarla nasıl eşlenip eşlenmeyeceğinizi öğrenmek için Bkz . Service Fabric'te uygulama modelleme.