Nadzór nad zasobami

W przypadku uruchamiania wielu usług w tym samym węźle lub klastrze możliwe jest, że jedna usługa może zużywać więcej zasobów, głodując inne usługi w procesie. Ten problem jest określany jako problem "hałaśliwy sąsiad". Usługa Azure Service Fabric umożliwia deweloperowi kontrolowanie tego zachowania przez określenie żądań i limitów na usługę w celu ograniczenia użycia zasobów.

Przed kontynuowaniem pracy z tym artykułem zalecamy zapoznanie się z modelem aplikacji usługi Service Fabric i modelem hostingu usługi Service Fabric.

Metryki ładu zasobów

Nadzór nad zasobami jest obsługiwany w usłudze Service Fabric zgodnie z pakietem usług. Zasoby przypisane do pakietu usługi można dodatkowo podzielić między pakiety kodu. Usługa Service Fabric obsługuje ład procesora CPU i pamięci na pakiet usługi z dwoma wbudowanymi metrykami:

• Procesor CPU (nazwa servicefabric:/_CpuCoresmetryki): rdzeń logiczny dostępny na maszynie hosta. Wszystkie rdzenie we wszystkich węzłach są ważone tak samo.

• Pamięć (nazwa servicefabric:/_MemoryInMBmetryki): pamięć jest wyrażona w megabajtach i mapuje ją na pamięć fizyczną dostępną na maszynie.

W przypadku tych dwóch metryk menedżer zasobów klastra (CRM) śledzi łączną pojemność klastra, obciążenie każdego węzła w klastrze i pozostałe zasoby w klastrze. Te dwie metryki są równoważne każdej innej metryce użytkownika lub niestandardowej.

Uwaga

Niestandardowe nazwy metryk nie powinny być jedną z tych dwóch nazw metryk, ponieważ spowoduje to niezdefiniowane zachowanie.

Wszystkie istniejące funkcje mogą być używane z nimi:

• Klaster można zrównoważyć zgodnie z tymi dwoma metrykami (zachowanie domyślne).
• Klaster można defragmentować zgodnie z tymi dwoma metrykami.
• Podczas opisywania klastra można ustawić buforowaną pojemność dla tych dwóch metryk.

Uwaga

Dynamiczne raportowanie obciążenia nie jest obsługiwane dla tych metryk; obciążenia dla tych metryk są definiowane w czasie tworzenia.

Mechanizm nadzoru nad zasobami

Począwszy od wersji 7.2, środowisko uruchomieniowe usługi Service Fabric obsługuje specyfikację żądań i limitów zasobów procesora CPU i pamięci.

Uwaga

Wersje środowiska uruchomieniowego usługi Service Fabric starsze niż 7.2 obsługują tylko model, w którym pojedyncza wartość służy zarówno jako żądanie, jak i limit dla określonego zasobu (procesora CPU lub pamięci). Jest to opisane jako specyfikacja RequestsOnly w tym dokumencie.

• Żądania: wartości żądań procesora CPU i pamięci reprezentują obciążenia używane przez menedżera zasobów klastra (CRM) dla servicefabric:/_CpuCores metryk i servicefabric:/_MemoryInMB . Innymi słowy, crm uważa, że użycie zasobów usługi jest równe jej wartościom żądania i używa tych wartości podczas podejmowania decyzji dotyczących umieszczania.

• Limity: wartości limitu procesora CPU i pamięci reprezentują rzeczywiste limity zasobów stosowane w przypadku aktywowania procesu lub kontenera w węźle.

Usługa Service Fabric umożliwia korzystanie ze specyfikacji RequestsOnly, LimitsOnly i RequestsAndLimits dla procesora CPU i pamięci.

• W przypadku użycia specyfikacji RequestsOnly usługa Service Fabric używa również wartości żądania jako limitów.
• Gdy jest używana specyfikacja LimitsOnly, usługa Service Fabric uznaje wartości żądania za 0.
• Gdy jest używana specyfikacja RequestsAndLimits, wartości limitu muszą być większe lub równe wartościom żądania.

Aby lepiej zrozumieć mechanizm nadzoru nad zasobami, przyjrzyjmy się przykładowemu scenariuszowi umieszczania przy użyciu specyfikacji RequestsOnly dla zasobu procesora CPU (mechanizm nadzoru nad pamięcią jest równoważny). Rozważ węzeł z dwoma rdzeniami procesora CPU i dwoma pakietami usług, które zostaną na nim umieszczone. Pierwszy pakiet usługi do umieszczenia składa się tylko z jednego pakietu kodu kontenera i określa tylko żądanie jednego rdzenia procesora CPU. Drugi pakiet usługi, który ma zostać umieszczony, składa się tylko z jednego pakietu kodu opartego na procesie, a także określa żądanie jednego rdzenia procesora. Ponieważ oba pakiety usług mają specyfikację RequestsOnly, ich wartości limitu są ustawiane na ich wartości żądania.

1. Najpierw pakiet usługi opartej na kontenerze żądający jednego rdzenia procesora CPU jest umieszczany w węźle. Środowisko uruchomieniowe aktywuje kontener i ustawia limit procesora CPU na jeden rdzeń. Kontener nie będzie mógł używać więcej niż jednego rdzenia.

2. Następnie pakiet usługi oparty na procesie żądający jednego rdzenia procesora CPU jest umieszczany w węźle. Środowisko uruchomieniowe aktywuje proces usługi i ustawia limit procesora CPU na jeden rdzeń.

W tym momencie suma żądań jest równa pojemności węzła. System CRM nie umieszcza więcej kontenerów ani procesów usług przy użyciu żądań procesora CPU w tym węźle. W węźle proces i kontener są uruchomione z jednym rdzeniem, a każdy z nich nie będzie rywalizować ze sobą dla procesora CPU.

Wróćmy teraz do naszego przykładu ze specyfikacją RequestsAndLimits . Tym razem pakiet usługi opartej na kontenerze określa żądanie jednego rdzenia procesora CPU i limit dwóch rdzeni procesora CPU. Pakiet usługi opartej na procesie określa zarówno żądanie, jak i limit jednego rdzenia procesora CPU.

1. Najpierw pakiet usługi opartej na kontenerze jest umieszczany w węźle. Środowisko uruchomieniowe aktywuje kontener i ustawia limit procesora CPU na dwa rdzenie. Kontener nie będzie mógł używać więcej niż dwóch rdzeni.
2. Następnie pakiet usługi opartej na procesie jest umieszczany w węźle. Środowisko uruchomieniowe aktywuje proces usługi i ustawia limit procesora CPU na jeden rdzeń.

W tym momencie suma żądań procesora CPU pakietów usług umieszczonych w węźle jest równa pojemności procesora CPU węzła. System CRM nie umieszcza więcej kontenerów ani procesów usług przy użyciu żądań procesora CPU w tym węźle. Jednak w węźle suma limitów (dwa rdzenie dla kontenera + jeden rdzeń procesu) przekracza pojemność dwóch rdzeni. Jeśli kontener i proces pękną w tym samym czasie, istnieje możliwość rywalizacji o zasób procesora CPU. Takie rywalizacje będą zarządzane przez bazowy system operacyjny dla platformy. W tym przykładzie kontener może spowodować pęknięcie do dwóch rdzeni procesora CPU, co spowoduje, że żądanie jednego rdzenia procesora CPU nie jest gwarantowane.

Uwaga

Jak pokazano w poprzednim przykładzie, wartości żądań procesora CPU i pamięci nie prowadzą do rezerwacji zasobów w węźle. Te wartości reprezentują zużycie zasobów, które menedżer zasobów klastra uwzględnia podczas podejmowania decyzji dotyczących umieszczania. Wartości limitu reprezentują rzeczywiste limity zasobów stosowane w przypadku aktywowania procesu lub kontenera w węźle.

Istnieje kilka sytuacji, w których może wystąpić rywalizacja o procesor CPU. W takich sytuacjach proces i kontener z naszego przykładu mogą wystąpić problem z hałaśliwym sąsiadem:

• Mieszanie zarządzanych i nierządnych usług i kontenerów: jeśli użytkownik tworzy usługę bez określonego ładu zasobów, środowisko uruchomieniowe postrzega je jako zużywające żadne zasoby i może umieścić ją w węźle w naszym przykładzie. W takim przypadku ten nowy proces efektywnie zużywa część procesora CPU kosztem usług, które są już uruchomione w węźle. Istnieją dwa rozwiązania tego problemu. Nie mieszaj usług zarządzanych i nienależących do tego samego klastra lub używaj ograniczeń umieszczania, aby te dwa typy usług nie były używane w tym samym zestawie węzłów.

• Po uruchomieniu innego procesu w węźle poza usługą Service Fabric (na przykład usługą systemu operacyjnego): W takiej sytuacji proces poza usługą Service Fabric również walczy o procesor CPU z istniejącymi usługami. Rozwiązaniem tego problemu jest prawidłowe skonfigurowanie pojemności węzłów w celu uwzględnienia obciążenia systemu operacyjnego, jak pokazano w następnej sekcji.

• Jeśli żądania nie są równe limitom: zgodnie z opisem w przykładzie RequestsAndLimits żądania nie prowadzą do rezerwacji zasobów w węźle. Gdy usługa z limitami większymi niż żądania jest umieszczana w węźle, może zużywać zasoby (jeśli są dostępne) do limitów. W takich przypadkach inne usługi w węźle mogą nie być w stanie wykorzystywać zasobów do ich wartości żądania.

Konfiguracja klastra na potrzeby włączania ładu zasobów

Po uruchomieniu węzła i dołączeniu do klastra usługa Service Fabric wykryje dostępną ilość pamięci i dostępną liczbę rdzeni, a następnie ustawia pojemności węzłów dla tych dwóch zasobów.

Aby pozostawić miejsce buforu dla systemu operacyjnego i innych procesów, które mogą być uruchomione w węźle, usługa Service Fabric używa tylko 80% dostępnych zasobów w węźle. Ta wartość procentowa jest konfigurowalna i może zostać zmieniona w manifeście klastra.

Oto przykład sposobu poinstruowania usługi Service Fabric o użyciu 50% dostępnego procesora CPU i 70% dostępnej pamięci:

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

W przypadku większości klientów i scenariuszy automatyczne wykrywanie pojemności węzłów dla procesora CPU i pamięci jest zalecaną konfiguracją (automatyczne wykrywanie jest domyślnie włączone). Jeśli jednak potrzebujesz pełnej ręcznej konfiguracji pojemności węzłów, możesz je skonfigurować na typ węzła przy użyciu mechanizmu opisywania węzłów w klastrze. Oto przykład konfigurowania typu węzła z czterema rdzeniami i 2 GB pamięci:

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

Po włączeniu automatycznego wykrywania dostępnych zasobów, a pojemności węzłów są definiowane ręcznie w manifeście klastra, usługa Service Fabric sprawdza, czy węzeł ma wystarczającą ilość zasobów do obsługi pojemności zdefiniowanej przez użytkownika:

• Jeśli pojemności węzłów zdefiniowane w manifeście są mniejsze lub równe dostępnym zasobom w węźle, usługa Service Fabric używa pojemności określonych w manifeście.

• Jeśli pojemności węzłów zdefiniowane w manifeście są większe niż dostępne zasoby, usługa Service Fabric używa dostępnych zasobów jako pojemności węzłów.

Automatyczne wykrywanie dostępnych zasobów można wyłączyć, jeśli nie jest to wymagane. Aby wyłączyć tę funkcję, zmień następujące ustawienie:

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

Aby uzyskać optymalną wydajność, należy również włączyć następujące ustawienie w manifeście klastra:

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

Ważne

Począwszy od usługi Service Fabric w wersji 7.0, zaktualizowaliśmy regułę sposobu obliczania pojemności zasobów węzła w przypadkach, w których użytkownik ręcznie udostępnia wartości pojemności zasobów węzła. Rozważmy następujący scenariusz:

• W węźle znajduje się łącznie 10 rdzeni procesora CPU
• Usługa SF jest skonfigurowana do używania 80% całkowitej liczby zasobów dla usług użytkownika (ustawienie domyślne), co pozostawia bufor wynoszący 20% dla innych usług uruchomionych w węźle (łącznie z usługami systemowymi usługi Service Fabric)
• Użytkownik decyduje się ręcznie zastąpić pojemność zasobu węzła dla metryki rdzeni procesora CPU i ustawia ją na 5 rdzeni

Zmieniliśmy regułę dotyczącą sposobu obliczania dostępnej pojemności dla usług użytkownika usługi Service Fabric w następujący sposób:

• Przed usługą Service Fabric 7.0 dostępna pojemność dla usług użytkownika zostanie obliczona na 5 rdzeni (bufor pojemności wynoszący 20% jest ignorowany)
• Począwszy od usługi Service Fabric 7.0, dostępna pojemność dla usług użytkownika będzie obliczana na 4 rdzenie (bufor pojemności wynoszący 20% nie jest ignorowany)

Określanie ładu zasobów

Żądania i limity ładu zasobów są określone w manifeście aplikacji (sekcja ServiceManifestImport). Przyjrzyjmy się kilku przykładom:

Przykład 1: Specyfikacja 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>

W tym przykładzie CpuCores atrybut służy do określania żądania 1 rdzenia procesora CPU dla elementu ServicePackageA. Ponieważ limit procesora CPU (CpuCoresLimit atrybut) nie jest określony, usługa Service Fabric używa również określonej wartości żądania 1 rdzeni jako limitu procesora CPU dla pakietu usługi.

Pakiet ServicePackageA zostanie umieszczony tylko w węźle, w którym pozostała pojemność procesora CPU po odjęciu sumy żądań procesora CPU wszystkich pakietów usług umieszczonych w tym węźle jest większa lub równa 1 rdzeniu. W węźle pakiet usługi będzie ograniczony do jednego rdzenia. Pakiet usługi zawiera dwa pakiety kodu (CodeA1 i CodeA2), a oba określają CpuShares atrybut. Proporcja procesorów CpuShares 512:256 służy do obliczania limitów procesora CPU dla poszczególnych pakietów kodu. W związku z tym kodA1 będzie ograniczony do dwóch trzecich rdzeni, a kodA2 będzie ograniczony do jednej trzeciej rdzenia. Jeśli procesor CpuShares nie jest określony dla wszystkich pakietów kodu, usługa Service Fabric dzieli limit procesora CPU w równym stopniu między nimi.

Podczas gdy procesor CpuShares określony dla pakietów kodu reprezentuje ich względny odsetek ogólnego limitu procesora CPU pakietu usługi, wartości pamięci dla pakietów kodu są określane w kategoriach bezwzględnych. W tym przykładzie MemoryInMB atrybut jest używany do określania żądań pamięci 1024 MB dla koduA1 i CodeA2. Ponieważ limit pamięci (MemoryInMBLimit atrybut) nie jest określony, usługa Service Fabric używa również określonych wartości żądania jako limitów pakietów kodu. Żądanie pamięci (i limit) dla pakietu usługi jest obliczane jako suma wartości żądania pamięci (i limitu) pakietów kodu składowego. W związku z tym w przypadku usługi ServicePackageA żądanie pamięci i limit są obliczane jako 2048 MB.

Pakiet ServicePackageA zostanie umieszczony tylko w węźle, w którym pozostała pojemność pamięci po odjęciu sumy żądań pamięci wszystkich pakietów usług umieszczonych w tym węźle jest większa lub równa 2048 MB. W węźle oba pakiety kodu będą ograniczone do 1024 MB pamięci. Pakiety kodu (kontenery lub procesy) nie będą mogły przydzielić więcej pamięci niż ten limit, a próba wykonania tej czynności spowoduje wyjątki braku pamięci.

Przykład 2. Specyfikacja 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>

W tym przykładzie użyto CpuCoresLimit atrybutów i MemoryInMBLimit , które są dostępne tylko w wersji SF w wersji 7.2 lub nowszej. Atrybut CpuCoresLimit służy do określania limitu procesora CPU 1 rdzeni dla elementu ServicePackageA. Ponieważ żądanie procesora CPU (CpuCores atrybut) nie jest określone, jest uważane za 0. MemoryInMBLimit Atrybut służy do określania limitów pamięci wynoszących 1024 MB dla kodów CodeA1 i CodeA2, a ponieważ żądania (MemoryInMB atrybut) nie są określone, są uważane za 0. Żądanie pamięci i limit dla elementu ServicePackageA są zatem obliczane odpowiednio jako 0 i 2048. Ponieważ zarówno żądania procesora CPU, jak i pamięci dla usługi ServicePackageA są 0, nie ma obciążenia dla programu CRM, które należy wziąć pod uwagę pod kątem servicefabric:/_CpuCores umieszczania, dla metryk i servicefabric:/_MemoryInMB . W związku z tym z perspektywy ładu zasobów pakiet ServicePackageA można umieścić w dowolnym węźle niezależnie od pozostałej pojemności. Podobnie jak w przykładzie 1, w węźle kodA1 będzie ograniczony do dwóch trzecich rdzeni i 1024 MB pamięci, a kodA2 będzie ograniczony do jednej trzeciej rdzenia i 1024 MB pamięci.

Przykład 3. Specyfikacja 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>

Bazując na dwóch pierwszych przykładach, w tym przykładzie pokazano określanie zarówno żądań, jak i limitów procesora CPU i pamięci. Pakiet ServicePackageA ma odpowiednio 1 rdzeń i 3072 (1024 + 2048) MB. Można go umieścić tylko w węźle, który ma co najmniej 1 rdzeń (i 3072 MB) pojemności pozostawionej po odjęciu sumy wszystkich żądań procesora CPU (i pamięci) wszystkich pakietów usług umieszczonych w węźle z całkowitej pojemności procesora CPU (i pamięci) węzła. W węźle kodA1 będzie ograniczony do dwóch trzecich 2 rdzeni i 3072 MB pamięci, podczas gdy kodA2 będzie ograniczony do jednej trzeciej 2 rdzeni i 4096 MB pamięci.

Używanie parametrów aplikacji

Podczas określania ustawień ładu zasobów można użyć parametrów aplikacji do zarządzania wieloma konfiguracjami aplikacji. W poniższym przykładzie pokazano użycie parametrów aplikacji:

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

W tym przykładzie domyślne wartości parametrów są ustawiane dla środowiska produkcyjnego, w którym każdy pakiet usługi będzie pobierać 4 rdzenie i 2 GB pamięci. Istnieje możliwość zmiany wartości domyślnych za pomocą plików parametrów aplikacji. W tym przykładzie jeden plik parametrów może służyć do lokalnego testowania aplikacji, gdzie będzie uzyskać mniej zasobów niż w środowisku produkcyjnym:

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

Ważne

Określanie ładu zasobów przy użyciu parametrów aplikacji jest dostępne od wersji 6.1 usługi Service Fabric.

Gdy parametry aplikacji są używane do określania ładu zasobów, nie można obniżyć poziomu usługi Service Fabric do wersji wcześniejszej niż wersja 6.1.

Wymuszanie limitów zasobów dla usług użytkowników

Podczas stosowania ładu zasobów do usług Service Fabric gwarantuje, że te usługi zarządzane przez zasoby nie mogą przekroczyć limitu przydziału zasobów, wielu użytkowników nadal musi uruchamiać niektóre usługi Service Fabric w trybie ungoverned. W przypadku korzystania z ungoverned usług Service Fabric można napotkać sytuacje, w których "runaway" ungoverned usług zużywają wszystkie dostępne zasoby w węzłach usługi Service Fabric, co może prowadzić do poważnych problemów, takich jak:

• Zasób głodu innych usług uruchomionych w węzłach (w tym usług systemowych usługi Service Fabric)
• Węzły kończą się w stanie złej kondycji
• Brak odpowiedzi interfejsów API zarządzania klastrem usługi Service Fabric

Aby zapobiec wystąpieniu tych sytuacji, usługa Service Fabric umożliwia wymuszenie limitów zasobów dla wszystkich usług użytkownika usługi Service Fabric uruchomionych w węźle (zarządzanych i ungoverned), aby zagwarantować, że usługi użytkowników nigdy nie będą używać więcej niż określona ilość zasobów. Jest to osiągane przez ustawienie wartości dla konfiguracji EnforceUserServiceMetricCapacities w sekcji PlacementAndLoadBalancing elementu ClusterManifest na true. To ustawienie jest domyślnie wyłączone.

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

Dodatkowe uwagi:

• Wymuszanie limitu zasobów dotyczy servicefabric:/_CpuCores tylko metryk zasobów i servicefabric:/_MemoryInMB
• Wymuszanie limitu zasobów działa tylko wtedy, gdy pojemności węzłów dla metryk zasobów są dostępne dla usługi Service Fabric za pośrednictwem mechanizmu automatycznego wykrywania lub za pośrednictwem użytkowników ręcznie określających pojemności węzłów (zgodnie z wyjaśnieniem w sekcji Konfiguracja klastra na potrzeby włączania ładu zasobów). Jeśli pojemności węzłów nie są skonfigurowane, nie można użyć funkcji wymuszania limitu zasobów, ponieważ usługa Service Fabric nie może wiedzieć, ile zasobów należy zarezerwować dla usług użytkowników. Usługa Service Fabric wyświetli ostrzeżenie o kondycji, jeśli wartość "EnforceUserServiceMetricCapacities" ma wartość true, ale nie skonfigurowano pojemności węzłów.

Inne zasoby dla kontenerów

Oprócz procesora CPU i pamięci można określić inne limity zasobów dla kontenerów. Te limity są określane na poziomie pakietu kodu i są stosowane po uruchomieniu kontenera. W przeciwieństwie do procesora CPU i pamięci menedżer zasobów klastra nie zna tych zasobów i nie wykonuje żadnych kontroli wydajności ani równoważenia obciążenia dla nich.

• MemorySwapInMB: łączna ilość pamięci wymiany, która może być używana w MB. Musi być dodatnią liczbą całkowitą.
• MemoryReservationInMB: limit nietrwały (w MB) dla ładu pamięci, który jest wymuszany tylko wtedy, gdy rywalizacja o pamięć jest wykrywana w węźle. Musi być dodatnią liczbą całkowitą.
• CpuPercent: procent użycia dostępnych procesorów CPU (tylko system Windows). Musi być dodatnią liczbą całkowitą. Nie można używać z procesorami CpuShares, CpuCores lub CpuCoresLimit.
• CpuShares: względna waga procesora CPU. Musi być dodatnią liczbą całkowitą. Nie można używać z procesorem CpuPercent, procesorami CPUCores lub CpuCoresLimit.
• MaximumIOps: maksymalna liczba operacji we/wy (odczyt i zapis) w zakresie operacji we/wy na sekundę, które mogą być używane. Musi być dodatnią liczbą całkowitą.
• MaximumIOBandwidth: maksymalna liczba operacji we/wy (bajtów na sekundę), których można użyć (odczyt i zapis). Musi być dodatnią liczbą całkowitą.
• BlockIOWeight: Blokuj wagę we/wy względem innych pakietów kodu. Musi być dodatnią liczbą całkowitą z zakresu od 10 do 1000.
• DiskQuotaInMB: limit przydziału dysku dla kontenerów. Musi być dodatnią liczbą całkowitą.
• KernelMemoryInMB: limity pamięci jądra w bajtach. Musi być dodatnią liczbą całkowitą. Należy pamiętać, że jest to specyficzne dla systemu Linux, a platforma Docker w systemie Windows wymyka się, jeśli jest ustawiona.
• ShmSizeInMB: rozmiar /dev/shm w bajtach. W przypadku pominięcia system używa 64 MB. Musi być dodatnią liczbą całkowitą. Należy pamiętać, że jest to specyficzne dla systemu Linux, jednak platforma Docker będzie ignorować tylko (a nie błąd) w przypadku określenia.

Te zasoby można łączyć z procesorem CPU i pamięcią. Oto przykład sposobu określania dodatkowych zasobów dla kontenerów:

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

Następne kroki

• Aby dowiedzieć się więcej o usłudze Resource Manager klastra, przeczytaj Wprowadzenie do menedżera zasobów klastra usługi Service Fabric.
• Aby dowiedzieć się więcej o modelu aplikacji, pakietach usług i pakietach kodu — oraz o tym, jak repliki są mapowania na nie — odczytaj aplikację modelową w usłudze Service Fabric.