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 zarządzanie procesorem CPU i pamięcią na poziomie pakietu usługi z dwoma wbudowanymi metrykami:

• CPU (nazwa metryki servicefabric:/_CpuCores): logiczny rdzeń 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 odnosi się do fizycznej pamięci dostępnej 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ż prowadzi 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 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 metryk servicefabric:/_CpuCores 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 alokacji.

• 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 oraz RequestsAndLimits dla procesora 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 zarządzania zasobami, przyjrzyjmy się przykładowemu scenariuszowi przydziału przy użyciu specyfikacji RequestsOnly dla procesora (mechanizm zarządzania pamięcią jest podobny). 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 do umieszczenia 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 już na tym węźle więcej kontenerów ani procesów usług z żądaniami procesora CPU. Na węźle uruchomione są proces i kontener, z jednym rdzeniem każdy, i nie będą ze sobą rywalizować o procesor.

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 całkowita wartość żądań procesora CPU pakietów usług umieszczonych w węźle jest równa pojemności CPU węzła. System CRM nie będzie umieszczał więcej kontenerów ani procesów serwisowych z żądaniami CPU na tym węźle. Jednak na węźle suma limitów (dwa rdzenie na kontener + jeden rdzeń na proces) 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 rozmieszczenia. 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. W takich sytuacjach proces i kontener z naszego przykładu mogą napotkać problem z hałaśliwym sąsiadem.

• Mieszanie zarządzanych i niezarządzanych usług i kontenerów: jeśli użytkownik tworzy usługę bez określonego zarządzania zasobami, środowisko uruchomieniowe postrzega ją jako niezużywającą żadnych zasobów i może umieścić ją na węźle w naszym przykładzie. W takim przypadku ten nowy proces skutecznie wykorzystuje część zasobów CPU kosztem usług, które są już uruchomione na węźle. Istnieją dwa rozwiązania tego problemu. Albo nie mieszaj usług zarządzanych i innych niż zarządzane w tym samym klastrze lub używaj ograniczeń umieszczania , aby te dwa typy usług nie trafiały do tego samego zestawu węzłów.

• Po uruchomieniu innego procesu w węźle poza Service Fabric (na przykład usługą systemu operacyjnego): W tym przypadku proces poza Service Fabric również konkuruje o zasoby 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ż jej żądania jest umieszczona na węźle, może zużywać zasoby (jeśli są dostępne) do tych limitów. W takich przypadkach inne usługi na węźle mogą nie być w stanie wykorzystywać zasobów do wartości ich żądań.

Konfiguracja klastra na potrzeby umożliwienia zarządzania zasobami

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, jak poinstruować Service Fabric, aby używał 50% dostępnego 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 i pamięci jest zalecaną konfiguracją (automatyczne wykrywanie jest włączone domyślnie). 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 automatycznejdetecji 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% łącznej 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 nadpisać pojemność zasobu węzła dla metryki rdzeni procesora CPU i ustawić 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 zarządzania zasobami

Żądania i limity zarządzania zasobami 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 udziałów CPU 512:256 służy do obliczania limitów 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 CpuShares nie są określone dla wszystkich pakietów kodu, usługa Service Fabric dzieli limit CPU równomiernie między nimi.

Podczas gdy udziały CPU (CpuShares) określone dla pakietów kodu reprezentują ich względny udział w ogólnym limicie procesora dla pakietu usługi, wartości limitów pamięci dla pakietów kodu są określane w kategoriach bezwzględnych. W tym przykładzie atrybut MemoryInMB jest używany do określania żądań pamięci na 1024 MB zarówno dla CodeA1, jak i KodA2. 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 atrybutów CpuCoresLimit i MemoryInMBLimit, które są dostępne tylko w wersjach SF 7.2 i nowszych. 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 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 ServicePackageA wynoszą 0, nie ma obciążenia, które CRM powinien wziąć pod uwagę przy umieszczaniu servicefabric:/_CpuCores i servicefabric:/_MemoryInMB metryk. 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. ServicePackageA ma zapotrzebowanie na 1 rdzeń CPU i 3072 (1024 + 2048) MB pamięci, odpowiednio. 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 być użyty do lokalnego testowania aplikacji, gdzie będzie otrzymywać 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 zarządzania zasobami przy użyciu parametrów aplikacji jest dostępne od wersji 6.1 Service Fabric.

Gdy parametry aplikacji są używane do określania zarządzania zasobami, usługi Service Fabric nie można obniżyć do wersji wcześniejszej niż 6.1.

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

Podczas stosowania zarządzania zasobami do usług Service Fabric gwarantuje się, że te objęte zarządzaniem zasobami usługi nie mogą przekroczyć swojego limitu przydziału zasobów, jednak wielu użytkowników nadal musi uruchamiać niektóre usługi Service Fabric w trybie niezwiązanym z zarządzaniem zasobami. W przypadku korzystania z niezarządzanych usług Service Fabric można napotkać sytuacje, w których niekontrolowane usługi zużywają wszystkie dostępne zasoby na węzłach Service Fabric, co może prowadzić do poważnych problemów, takich jak:

• Wyczerpanie zasobów przez inne usługi działające na węzłach (w tym usługi systemowe Service Fabric)
• Węzły przechodzą w nieprawidłowy stan
• 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 konfiguracji EnforceUserServiceMetricCapacities w sekcji PlacementAndLoadBalancing elementu ClusterManifest na wartość true. To ustawienie jest domyślnie wyłączone.

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

Dodatkowe uwagi:

• Wymuszanie limitu zasobów dotyczy jedynie metryk zasobów servicefabric:/_CpuCores i servicefabric:/_MemoryInMB.
• Wymuszanie limitów 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 autodetekcji lub za pośrednictwem użytkowników ręcznie określających pojemności węzłów (zgodnie z opisem w sekcji Konfiguracja klastra na potrzeby zarządzania zasobami). Jeśli pojemności węzłów nie są skonfigurowane, możliwości wymuszania limitu zasobów nie mogą być używane, ponieważ usługa Service Fabric nie może wiedzieć, ile zasobów można zarezerwować dla usług użytkowników. Usługa Service Fabric zgłosi ostrzeżenie dotyczące stanu zdrowia, jeśli "EnforceUserServiceMetricCapacities" jest ustawiona na true, ale zasoby węzłów nie są skonfigurowane.

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 i pamięci, menedżer zasobów klastra nie jest świadomy tych zasobów i nie wykonuje dla nich żadnych kontroli wydajności ani równoważenia obciążenia.

• MemorySwapInMB: łączna ilość pamięci wymiany, która może być używana w MB. Musi być dodatnią liczbą całkowitą.
• MemoryReservationInMB: miękki limit (w MB) dla zarządzania pamięcią, który jest wymuszany tylko wtedy, gdy wykryty jest niedobór pamięci na 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 CpuPercent, 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 bajtów na sekundę, które mogą być używane (dla odczytu i zapisu). Musi być dodatnią liczbą całkowitą.
• BlockIOWeight: Waga operacji we/wy blokowanych 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 Docker na Windows zgłasza błąd, jeśli to ustawienie jest włączone.
• 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 Docker będzie to po prostu ignorować (a nie zgłaszać błąd) przy określeniu.

Te zasoby można łączyć z 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 menedżerze zasobów 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ą mapowane na nie—przeczytaj Modelowanie aplikacji w Service Fabric.