Nadzór nad zasobami

W przypadku uruchamiania wielu usług w tym samym węźle lub klastrze istnieje możliwość, ż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 nadzoru nad zasobami

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 dalej podzielić między pakiety kodu. Usługa Service Fabric obsługuje zarządzanie procesorem 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 klaster Resource Manager (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ż doprowadzi to do niezdefiniowanego zachowania.

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 w przypadku 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 dla zasobów procesora 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 klaster Resource Manager (CRM) dla servicefabric:/_CpuCores metryk i servicefabric:/_MemoryInMB . Innymi słowy, crm uważa, że użycie zasobów usługi jest równe 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.

• Gdy jest używana specyfikacja 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 ze specyfikacją 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ług, 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 CPU. Ponieważ oba pakiety usług mają specyfikację RequestsOnly, ich wartości limitu są ustawiane na ich wartości żądania.

1. Najpierw pakiet usługi oparty 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ług 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. Program CRM nie umieszcza więcej kontenerów ani procesów usług z żądaniami procesora CPU w tym węźle. W węźle proces i kontener są uruchomione z jednym rdzeniem i nie będą ze sobą zmagać się z procesorem 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ług oparty 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ług oparty 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, które są umieszczane w węźle, jest równa pojemności procesora CPU węzła. Program CRM nie umieszcza więcej kontenerów ani procesów usług z żądaniami procesora CPU w tym węźle. Jednak w węźle suma limitów (dwa rdzenie dla kontenera + jeden rdzeń dla 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 zwiększać maksymalnie dwa rdzenie procesora CPU, co powoduje, ż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 Resource Manager 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ć problemy z hałaśliwym sąsiadem:

• Mieszanie zarządzanych i nienależących 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ć je 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 tej sytuacji proces poza usługą Service Fabric będzie 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.

• Gdy żą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 zużyć 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 wykrywa 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 w buforze 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, jak poinstruować usługę Service Fabric, aby korzystała z 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 zalecane jest automatyczne wykrywanie pojemności węzłów dla procesora CPU i pamięci (automatyczne wykrywanie jest domyślnie włączone). Jeśli jednak potrzebujesz pełnej ręcznej konfiguracji pojemności węzłów, możesz skonfigurować je dla każdego typu 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 ilości 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 ustawić 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żytkowników będzie obliczana 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żytkowników będzie obliczana na 4 rdzenie (bufor pojemności wynoszący 20% nie jest ignorowany)

Określanie ładu zasobów

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

Przykład 1. Specyfikacja żądań

<?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 pakietu 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 kod CodeA1 będzie ograniczony do dwóch trzecich rdzeni, a kod CodeA2 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 równie między nimi.

Chociaż procesor CpuShares określony dla pakietów kodu reprezentuje względną część ogólnego limitu procesora CPU pakietu usługi, wartości pamięci dla pakietów kodu są określane w wartościach bezwzględnych. W tym przykładzie MemoryInMB atrybut służy do określania żądań pamięci o rozmiarze 1024 MB dla kodu CodeA1 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 dla elementu ServicePackageA żądanie i limit pamięci 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 pakietu 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 1024 MB dla CodeA1 i CodeA2, a ponieważ żądania (MemoryInMB atrybut) nie są określone, są uważane za 0. W związku z tym żądanie pamięci i limit dla elementu ServicePackageA są obliczane odpowiednio jako 0 i 2048. Ponieważ żądania procesora CPU i pamięci dla elementu ServicePackageA są 0, nie ma obciążenia, które należy wziąć pod uwagę podczas umieszczania, dla servicefabric:/_CpuCores 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 można użyć jednego pliku parametrów 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 za pomocą 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ć wersji usługi Service Fabric do wersji wcześniejszej niż 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 uruchomić 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 "uciekane" usługi 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ące się w złej kondycji
• Brak odpowiedzi interfejsów API zarządzania klastrami usługi Service Fabric

Aby zapobiec wystąpieniu takich 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 nieumyślnie) w celu zagwarantowania, że usługi użytkownika nigdy nie będą używać więcej niż określona ilość zasobów. Można to osiągnąć, ustawiając wartość 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 klaster Resource Manager nie wie o tych zasobach i nie będzie wykonywać żadnych kontroli pojemności ani równoważenia obciążenia dla nich.

• MemorySwapInMB: całkowita 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) ł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 procesorami CpuPercent, CpuCores lub CpuCoresLimit.
• MaximumIOps: maksymalna liczba operacji we/wy (odczyt i zapis) w zakresie liczby 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ę operacji 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 (i nie wymykać się) 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 na temat 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ą mapowe na nie — odczytaj aplikację w usłudze Service Fabric.