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ług 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 między regionami świadczenia usługi Azure
  • Środowisko obejmuje wiele obszarów geopolitycznej lub kontroli prawnej lub w innym przypadku, w którym istnieją granice zasad, które należy wymusić
  • Istnieją zagadnienia dotyczące wydajności komunikacji lub opóźnienia ze względu na duże odległości lub użycie wolniejszych lub mniej niezawodnych łączy sieciowych
  • Należy zachować pewne obciążenia w połączeniu z innymi obciążeniami lub 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ę, klaster usługi Service Fabric Resource Manager udostępnia te dodatkowe zasady umieszczania. Zasady umieszczania są konfigurowane na podstawie nazwanego wystąpienia 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. Te zasady zapewniają, ż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.

Przykład nieprawidłowej 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 do umieszczania w elemencie Podstawowym. Element Podstawowy 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 przeniesie się do innego miejsca, najlepiej w tej samej domenie. Jeśli ta nowa lokalizacja nie znajduje się w preferowanej domenie, klaster Resource Manager zostanie przeniesiony z powrotem do preferowanej domeny tak szybko, jak to możliwe. Oczywiście to ustawienie ma sens tylko dla usług stanowych. Te zasady są najbardziej przydatne w klastrach obejmujących wiele regionów platformy Azure lub wielu centrów danych, ale mają usługi, które preferują umieszczanie w określonej lokalizacji. Utrzymanie 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 repliki i uniemożliwienie pakowania

Repliki są zwykle dystrybuowane 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 zapakowanych 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, które były używane dla tych replik w fd:/1 i fd:/2, spadły. Zwykle klaster Resource Manager preferuje inne węzły w tych samych domenach błędów. W tym przypadku załóżmy, że z powodu problemów z pojemnością żadna z innych węzłów w tych domenach nie była prawidłowa. Jeśli klaster Resource Manager kompiluje zamiany dla tych replik, konieczne byłoby wybranie węzłów w pliku fd:/0. Jednak w ten sposób powstaje sytuacja, w której ograniczenie domeny błędów zostało naruszone. Repliki pakowania zwiększają 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", to ten warunek lub coś takiego. Zwykle tylko jedna lub dwie repliki są spakowane razem tymczasowo. Tak długo, jak w danej domenie jest mniej niż kworum replik, możesz 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 pozostaną w dół, a Resource Manager klastra musi utworzyć zamiany, zwykle 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 zapakowane w mniej domen. Te obciążenia są obstawianie łącznej liczby równoczesnych awarii domeny trwałej i zwykle może odzyskać stan lokalny. Inne obciążenia wolałyby podjąć przestoje wcześniej niż poprawność lub utratę 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. Z tego powodu domyślne zachowanie zezwala na domyślne pakowanie domeny. Domyślne zachowanie umożliwia normalne równoważenie i tryb failover do obsługi tych ekstremalnych 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 klaster Resource Manager gwarantuje, że żadne dwie repliki z tej samej partycji działają 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")

Czy teraz można użyć tych konfiguracji dla usług w klastrze, który nie został geograficznie rozproszonych? 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ętowe powinny być rozłożone między domenami 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 wystąpień bezstanowych 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", to ten warunek 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 ze statycznymi punktami końcowymi portów. 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 minInstanceCount z 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; Za pomocą polecenia MinInstanceCount=8 można tego uniknąć.

Następne kroki