Udostępnij za pośrednictwem

Zasady umieszczania dla usług Service Fabric

  • Artykuł

Polityki umieszczania to dodatkowe reguły, które mogą służyć do zarządzania umieszczaniem usługi w niektórych specyficznych, 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
  • Twoje środowisko obejmuje wiele obszarów pod względem geopolitycznej lub prawnej kontroli, lub jakiegoś innego przypadku, gdzie masz granice polityki, które musisz 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 instancji partycji na 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);

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

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 której ma być umieszczona domena podstawowa. Podstawowy serwer trafia do tej domeny, gdy wszystko działa prawidłowo. Jeśli domena lub podstawowa replika przestanie działać lub zostanie zamknięta, replika podstawowa zostanie przeniesiona 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);

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 awarii i aktualizacji, gdy klaster jest sprawny. 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 fd:/1 i fd:/2 przestały działać. 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 zdrowotny, 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 napotkałeś ten stan lub coś podobnego. Zwykle tylko jedna lub dwie repliki są tymczasowo pakowane razem. Tak długo, jak w danej domenie jest mniej niż kworum replik, jesteś bezpieczny. 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ą niedostępne, a menedżer zasobów klastra musi utworzyć zastępcze, zazwyczaj istnieją inne węzły dostępne w optymalnych strefach awarii.

Niektóre obciążenia wolą zawsze mieć docelową liczbę replik, nawet jeśli są one pakowane w mniej domen. Te obciążenia robocze opierają się na łącznych równoczesnych trwałych awariach domen i zwykle mogą odzyskać 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, z więcej niż trzema domenami błędów i z wieloma prawidłowymi węzłami 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 politykę w usłudze. Po ustawieniu tej zasady, menedżer zasobów klastra zapewnia, że nie ma dwóch replik z tej samej partycji uruchomionych w tej samej domenie błędów lub domenie uaktualnienia.

Kod:

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

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 próbować wymuszać uruchamiania danego obciążenia w jednej szafie lub preferować jakiś segment klastra lokalnego nad innym. Różne konfiguracje sprzętu powinny być rozproszone pomiędzy domeny awarii i zarządzane za pośrednictwem standardowych reguł rozmieszczenia 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. Ta zasada umieszczania usuwa to ograniczenie, i umożliwia określenie wartości InstanceCount większej niż liczba węzłów.

Jeśli kiedykolwiek widziałeś komunikat dotyczący stanu zdrowia, 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 wystąpił ten problem lub coś podobnego.

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

PowerShell:

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

Uwaga

Obecnie polityka jest obsługiwana tylko dla usług bezstanowych z trybem aktywacji pakietu usługi ExclusiveProcess.

Ostrzeżenie

Zasada nie jest obsługiwana w przypadku użycia z punktami końcowymi statycznych portów. Użycie obu w połączeniu może prowadzić do niezdrowego klastra, ponieważ wiele wystąpień na tym samym węźle próbuje związać się z tym samym portem i nie mogą się uruchomić.

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