Udostępnij za pośrednictwem

Zasady umieszczania dla usług service fabric

  • Artykuł

Zasady umieszczania to dodatkowe reguły, które mogą służyć do zarządzania umieszczaniem usługi w określonych, mniej typowych scenariuszach. Oto kilka przykładów tych scenariuszy:

  • Klaster usługi Service Fabric obejmuje odległości geograficzne, takie jak wiele lokalnych centrów danych lub w różnych regionach świadczenia usługi Azure
  • Środowisko obejmuje wiele obszarów geopolitycznej lub prawnej kontroli lub w innym przypadku, w którym istnieją granice zasad, które należy wymusić
  • Istnieją zagadnienia dotyczące wydajności lub opóźnienia komunikacji ze względu na duże odległości lub użycie wolniejszych lub mniej niezawodnych łączy sieciowych
  • Należy zachować pewne obciążenia ułożone jako najlepsze rozwiązanie, zarówno z innymi obciążeniami, jak i w pobliżu klientów
  • Potrzebujesz wielu bezstanowych wystąpień partycji w jednym węźle

Większość tych wymagań jest zgodna z fizycznym układem klastra reprezentowanym jako domeny błędów klastra.

Zaawansowane zasady umieszczania, które pomagają rozwiązać te scenariusze, to:

  1. Nieprawidłowe domeny
  2. Wymagane domeny
  3. Preferowane domeny
  4. Niedozwolone pakowanie replik
  5. Zezwalaj na wiele wystąpień bezstanowych w węźle

Większość poniższych kontrolek można skonfigurować za pomocą właściwości węzła i ograniczeń umieszczania, ale niektóre z nich są bardziej skomplikowane. Aby ułatwić sobie sprawę, menedżer zasobów klastra usługi Service Fabric udostępnia te dodatkowe zasady umieszczania. Zasady umieszczania są konfigurowane dla poszczególnych nazwanych wystąpień usługi. Można je również aktualizować dynamicznie.

Określanie nieprawidłowych domen

Zasady umieszczania InvalidDomain umożliwiają określenie, że określona domena błędów jest nieprawidłowa dla określonej usługi. Ta zasada gwarantuje, że określona usługa nigdy nie działa w określonym obszarze, na przykład ze względów geopolitycznych lub firmowych. Wiele nieprawidłowych domen można określić za pomocą oddzielnych zasad.

Nieprawidłowy przykład domeny

Kod:

ServicePlacementInvalidDomainPolicyDescription invalidDomain = new ServicePlacementInvalidDomainPolicyDescription();
invalidDomain.DomainName = "fd:/DCEast"; //regulations prohibit this workload here
serviceDescription.PlacementPolicies.Add(invalidDomain);

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("InvalidDomain,fd:/DCEast”)

Określanie wymaganych domen

Wymagane zasady umieszczania domeny wymagają, aby usługa znajduje się tylko w określonej domenie. Wiele wymaganych domen można określić za pomocą oddzielnych zasad.

Przykład wymaganej domeny

Kod:

ServicePlacementRequiredDomainPolicyDescription requiredDomain = new ServicePlacementRequiredDomainPolicyDescription();
requiredDomain.DomainName = "fd:/DC01/RK03/BL2";
serviceDescription.PlacementPolicies.Add(requiredDomain);

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("RequiredDomain,fd:/DC01/RK03/BL2")

Określanie preferowanej domeny dla replik podstawowych usługi stanowej

Preferowana domena podstawowa określa domenę błędów, w ramach których ma być umieszczana domena podstawowa. Podstawowa kończy się w tej domenie, gdy wszystko jest w dobrej kondycji. Jeśli domena lub replika podstawowa nie powiedzie się lub zostanie zamknięta, podstawowy zostanie przeniesiony do innego miejsca, najlepiej w tej samej domenie. Jeśli ta nowa lokalizacja nie znajduje się w preferowanej domenie, menedżer zasobów klastra jak najszybciej przeniesie go z powrotem do preferowanej domeny. Oczywiście to ustawienie ma sens tylko w przypadku usług stanowych. Te zasady są najbardziej przydatne w klastrach obejmujących regiony platformy Azure lub wiele centrów danych, ale mają usługi, które preferują umieszczanie w określonej lokalizacji. Utrzymywanie prawyborów blisko użytkowników lub innych usług pomaga zapewnić mniejsze opóźnienie, zwłaszcza w przypadku odczytów, które są domyślnie obsługiwane przez prawybory.

Preferowane domeny podstawowe i tryb failover

ServicePlacementPreferPrimaryDomainPolicyDescription primaryDomain = new ServicePlacementPreferPrimaryDomainPolicyDescription();
primaryDomain.DomainName = "fd:/EastUS/";
serviceDescription.PlacementPolicies.Add(primaryDomain);

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("PreferredPrimaryDomain,fd:/EastUS")

Wymaganie dystrybucji replik i uniemożliwienie pakowania

Repliki są zwykle rozproszone w domenach błędów i uaktualniania, gdy klaster jest w dobrej kondycji. Istnieją jednak przypadki, w których więcej niż jedna replika dla danej partycji może zostać tymczasowo zapakowana w jedną domenę. Załóżmy na przykład, że klaster ma dziewięć węzłów w trzech domenach błędów, fd:/0, fd:/1 i fd:/2. Załóżmy również, że usługa ma trzy repliki. Załóżmy, że węzły używane dla tych replik w pliku fd:/1 i fd:/2 spadły. Zwykle menedżer zasobów klastra preferuje inne węzły w tych samych domenach błędów. W takim przypadku załóżmy, że z powodu problemów z pojemnością żaden z innych węzłów w tych domenach nie był prawidłowy. Jeśli menedżer zasobów klastra tworzy zamienniki dla tych replik, konieczne byłoby wybranie węzłów w pliku fd:/0. Jednak spowoduje to utworzenie sytuacji, w której ograniczenie domeny błędów zostanie naruszone. Pakowanie replik zwiększa prawdopodobieństwo, że cały zestaw replik może spaść lub zostać utracony.

Uwaga

Aby uzyskać więcej informacji na temat ograniczeń i priorytetów ograniczeń, zapoznaj się z tym tematem.

Jeśli kiedykolwiek widziałeś komunikat o kondycji, taki jak "The Load Balancer has detected a Constraint Violation for this Replica:fabric:/<some service name> Secondary Partition <some partition ID> is violating the Constraint: FaultDomain", oznacza to, że ten stan został trafiony lub coś takiego. Zwykle tylko jedna lub dwie repliki są tymczasowo pakowane razem. Tak długo, jak w danej domenie jest mniej niż kworum replik, można bezpiecznie. Pakowanie jest rzadkie, ale może się zdarzyć, a zwykle te sytuacje są przejściowe, ponieważ węzły wracają. Jeśli węzły pozostają w dół, a menedżer zasobów klastra musi utworzyć zamiany, zazwyczaj istnieją inne węzły dostępne w idealnych domenach błędów.

Niektóre obciążenia wolą zawsze mieć docelową liczbę replik, nawet jeśli są one pakowane w mniej domen. Te obciążenia są obstawiwane względem łącznych równoczesnych awarii domeny trwałej i zwykle mogą odzyskiwać stan lokalny. Inne obciążenia wolałyby podjąć przestój wcześniej niż ryzyko poprawności lub utraty danych. Większość obciążeń produkcyjnych działa z więcej niż trzema replikami, więcej niż trzy domeny błędów i wiele prawidłowych węzłów na domenę błędów. W związku z tym domyślne zachowanie zezwala na domyślne pakowanie domen. Domyślne zachowanie umożliwia normalne równoważenie i tryb failover do obsługi tych skrajnych przypadków, nawet jeśli oznacza to tymczasowe pakowanie domeny.

Jeśli chcesz wyłączyć takie pakowanie dla danego obciążenia, możesz określić RequireDomainDistribution zasady w usłudze. Po ustawieniu tych zasad menedżer zasobów klastra zapewnia, że nie ma dwóch replik z tej samej partycji uruchomionej w tej samej domenie błędów lub uaktualnieniu.

Kod:

ServicePlacementRequireDomainDistributionPolicyDescription distributeDomain = new ServicePlacementRequireDomainDistributionPolicyDescription();
serviceDescription.PlacementPolicies.Add(distributeDomain);

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton -PlacementPolicy @("RequiredDomainDistribution")

Teraz można użyć tych konfiguracji dla usług w klastrze, który nie został geograficznie rozpięty? Można, ale nie ma też wielkiego powodu. Należy unikać wymaganych, nieprawidłowych i preferowanych konfiguracji domeny, chyba że scenariusze ich wymagają. Nie ma sensu, aby spróbować wymusić uruchomienie danego obciążenia w jednym stojaku lub preferować jakiś segment klastra lokalnego w innym. Różne konfiguracje sprzętu powinny być rozłożone między domeny błędów i obsługiwane za pośrednictwem normalnych ograniczeń umieszczania i właściwości węzła.

Umieszczanie wielu bezstanowych wystąpień partycji w jednym węźle

Zasady umieszczania AllowMultipleStatelessInstancesOnNode umożliwiają umieszczanie wielu bezstanowych wystąpień partycji w jednym węźle. Domyślnie na węźle nie można umieścić wielu wystąpień pojedynczej partycji. Nawet w przypadku usługi -1 nie można skalować liczby wystąpień poza liczbą węzłów w klastrze dla danej nazwanej usługi. Te zasady umieszczania usuwa to ograniczenie i umożliwiają określenie wartości InstanceCount większej niż liczba węzłów.

Jeśli kiedykolwiek widziałeś komunikat o kondycji, taki jak "The Load Balancer has detected a Constraint Violation for this Replica:fabric:/<some service name> Secondary Partition <some partition ID> is violating the Constraint: ReplicaExclusion", oznacza to, że ten stan został trafiony lub coś takiego.

Aby wyrazić zgodę na zastosowanie tych zasad umieszczania w usłudze, włącz następujące konfiguracje:

<Section Name="Common">
  <Parameter Name="AllowCreateUpdateMultiInstancePerNodeServices" Value="True" />
  <Parameter Name="HostReuseModeForExclusiveStateless" Value="1" />
</Section>

Określając zasady w usłudze AllowMultipleStatelessInstancesOnNode , parametr InstanceCount można ustawić poza liczbę węzłów w klastrze.

Kod:

ServicePlacementAllowMultipleStatelessInstancesOnNodePolicyDescription allowMultipleInstances = new ServicePlacementAllowMultipleStatelessInstancesOnNodePolicyDescription();
serviceDescription.PlacementPolicies.Add(allowMultipleInstances);

Program PowerShell:

New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless –PartitionSchemeSingleton –PlacementPolicy @(“AllowMultipleStatelessInstancesOnNode”) -InstanceCount 10 -ServicePackageActivationMode ExclusiveProcess

Uwaga

Obecnie zasady są obsługiwane tylko w przypadku usług bezstanowych z trybem aktywacji pakietu usługi ExclusiveProcess.

Ostrzeżenie

Zasady nie są obsługiwane w przypadku użycia z punktami końcowymi portów statycznych. Użycie obu w połączeniu może prowadzić do złej kondycji klastra, ponieważ wiele wystąpień w tym samym węźle próbuje powiązać z tym samym portem i nie może pojawić się.

Uwaga

Użycie wysokiej wartości parametru MinInstanceCount z tymi zasadami umieszczania może prowadzić do zablokowanych uaktualnień aplikacji. Jeśli na przykład masz klaster z pięcioma węzłami i ustawisz wartość InstanceCount=10, będziesz mieć dwa wystąpienia w każdym węźle. Jeśli ustawisz wartość MinInstanceCount=9, próba uaktualnienia aplikacji może zostać zablokowana; w przypadku parametru MinInstanceCount=8 można tego uniknąć.

Następne kroki