Service Fabric att tänka på vid kapacitetsplanering för kluster

Planering av klusterkapacitet är viktigt för varje Service Fabric produktionsmiljö. Viktiga saker att tänka på är:

• Ursprungligt antal och egenskaper för klusternodtyper

• Hållbarhetsnivå för varje nodtyp, som avgör Service Fabric VM-behörigheter i Azure-infrastrukturen

• Klustrets tillförlitlighetsnivå, som avgör stabiliteten för Service Fabric systemtjänster och övergripande klusterfunktion

I den här artikeln går vi igenom viktiga beslutspunkter för vart och ett av dessa områden.

Ursprungligt antal och egenskaper för klusternodtyper

En nodtyp definierar storlek, antal och egenskaper för en uppsättning noder (virtuella datorer) i klustret. Varje nodtyp som definieras i ett Service Fabric mappar till en VM-skalningsuppsättning.

Eftersom varje nodtyp är en distinkt skalningsuppsättning kan den skalas upp eller ned oberoende av varandra, ha olika uppsättningar portar öppna och ha olika kapacitetsmått. Mer information om relationen mellan nodtyper och VM-skalningsuppsättningar finns i Service Fabric av klusternodtyper.

Varje kluster kräver en primär nodtyp, som kör kritiska systemtjänster Service Fabric tillhandahåller plattformsfunktioner. Även om det är möjligt att även använda primära nodtyper för att köra dina program rekommenderar vi att du dedikerar dem enbart till systemtjänster som körs.

Icke-primära nodtyper kan användas för att definiera programroller (till exempel frontend- och servertjänster) och för att fysiskt isolera tjänster i ett kluster. Service Fabric kan ha noll eller flera icke-primära nodtyper.

Den primära nodtypen konfigureras med hjälp av isPrimary -attributet under nodtypsdefinitionen i Azure Resource Manager distributionsmallen. En fullständig lista över egenskaper för nodtyper finns i Objektet NodeTypeDescription. Till exempel kan du öppna valfri AzureDeploy.json-fil i Service Fabric-klusterexempel och Söka efter objektet på nodeTypes sidan.

Planeringsöverväganden för nodtyper

Antalet inledande nodtyper beror på syftet med ditt kluster och de program och tjänster som körs på det. Överväg följande frågor:

• Har ditt program flera tjänster och behöver någon av dem vara offentliga eller Internet-riktade?

  Vanliga program innehåller en gatewaytjänst på klientsidan som tar emot indata från en klient och en eller flera backend-tjänster som kommunicerar med klienttjänster, med separata nätverk mellan klient- och backend-tjänsterna. Dessa fall kräver vanligtvis tre nodtyper: en primär nodtyp och två icke-primära nodtyper (en var för front- och backend-tjänsten).

• Har de tjänster som utgör ditt program olika infrastrukturbehov, till exempel större RAM-minne eller högre CPU-cykler?

  Frontend-tjänsten kan ofta köras på mindre virtuella datorer (VM-storlekar som D2) som har portar öppna till Internet. Beräkningsintensiva backend-tjänster kan behöva köras på större virtuella datorer (med VM-storlekar som D4, D6, D15) som inte är Internet-riktade. Genom att definiera olika nodtyper för dessa tjänster kan du effektivisera och skydda användningen av underliggande Service Fabric virtuella datorer och göra det möjligt för dem att skala dem oberoende av varandra. Mer information om hur du beräknar mängden resurser som du behöver finns i Kapacitetsplanering för Service Fabric program

• Behöver någon av dina programtjänster skala ut över 100 noder?

  En enda nodtyp kan inte skalas på ett tillförlitligt sätt över 100 noder per VM-skalningsuppsättning för Service Fabric program. Om du kör fler än 100 noder krävs ytterligare VM-skalningsuppsättningar (och därmed ytterligare nodtyper).

• Kommer ditt kluster att omfatta Tillgänglighetszoner?

  Service Fabric stöder kluster som sträcker sig över Tillgänglighetszoner genom att distribuera nodtyper som är fästa till specifika zoner, vilket säkerställer hög tillgänglighet för dina program. Tillgänglighetszoner ytterligare planering för nodtyper och minimikrav. Mer information finns i Rekommenderad topologi för att sträcka sig över en primär nodtyp över Tillgänglighetszoner.

Tänk på att du alltid kan lägga till, ändra eller ta bort (icke-primära) nodtyper när klustret har distribuerats när du fastställer antalet och egenskaperna för nodtyper för det första skapandet av klustret. Primära nodtyper kan också skalas upp eller ned i kluster som körs, men för att göra det måste du skapa en ny nodtyp, flytta arbetsbelastningen över och sedan ta bort den ursprungliga primära nodtypen.

En ytterligare faktor för egenskaperna för nodtypen är hållbarhetsnivån, som avgör behörigheter för en nodtyps virtuella datorer i Azure-infrastrukturen. Använd storleken på de virtuella datorer som du väljer för klustret och instansantalet som du tilldelar för enskilda nodtyper för att avgöra lämplig hållbarhetsnivå för var och en av dina nodtyper enligt beskrivningen nedan.

Klustrets hållbarhetsegenskaper

Hållbarhetsnivån anger de behörigheter som dina virtuella Service Fabric har med den underliggande Azure-infrastrukturen. Med den här Service Fabric du pausa eventuella infrastrukturbegärande på VM-nivå (till exempel omstart, avbildning eller migrering) som påverkar kvorumkraven för Service Fabric-systemtjänster och tillståndsful-tjänster.

Tabellen nedan visar Service Fabric för hållbarhetsnivåer, deras krav och priser.

Brons

Nodtyper som körs med bronsbeständighet får inga privilegier. Det innebär att infrastrukturjobb som påverkar dina tillståndsintensiva arbetsbelastningar inte stoppas eller fördröjs. Använd bronsbeständighet för nodtyper som bara kör tillståndslösa arbetsbelastningar. För produktionsarbetsbelastningar rekommenderas att du kör Silver eller högre.

Silver och Guld

Använd silver- eller guldbeständighet för alla nodtyper som är värdar för tillståndsful-tjänster som du förväntar dig att skala in ofta, och där du vill att distributionsåtgärder ska fördröjas och kapaciteten minskas för att förenkla processen. Utskalningsscenarier bör inte påverka ditt val av hållbarhetsnivå.

Fördelar

• Minskar antalet nödvändiga steg för inskalningsåtgärder (nodinaktivering och Remove-ServiceFabricNodeState anropas automatiskt).
• Minskar risken för dataförlust på grund av storleksändringsåtgärder på plats för virtuella datorer och Azure-infrastrukturåtgärder.

Nackdelar

• Distributioner till VM-skalningsuppsättningar och andra relaterade Azure-resurser kan ta för lång tid, fördröjas eller blockeras helt av problem i klustret eller på infrastrukturnivå.
• Ökar antalet livscykelhändelser för repliker (till exempel primära växlingar) på grund av automatiserade nodinaktiveringar under Azure-infrastrukturåtgärder.
• Tar bort noder från tjänsten under tidsperioder då det sker uppdateringar av Azure-plattformsprogram eller maskinvaruunderhåll. Du kan se noder med statusen Inaktiverad/Inaktiverad under dessa aktiviteter. Detta minskar kapaciteten för klustret tillfälligt, men bör inte påverka tillgängligheten för klustret eller programmen.

Metodtips för nodtyper för silver- och guldbeständighet

Följ dessa rekommendationer för att hantera nodtyper med silver- eller guldbeständighet:

• Håll klustret och programmen felfria hela tiden och se till att programmen svarar på alla livscykelhändelser för tjänstrepliker (t.ex. att repliken i versionen har fastnat) i rätt tid.
• Anta säkrare sätt att göra en storleksändring av den virtuella datorn (skala upp/ned). Att ändra VM-storleken på en VM-skalningsuppsättning kräver noggrann planering och försiktighet. Mer information finns i Skala upp Service Fabric en nodtyp
• Ha ett minsta antal noder för en VM-skalningsuppsättning som har hållbarhetsnivån Guld eller Silver aktiverad. Klustret kommer att ange feltillstånd om du skalar in under det här tröskelvärdet och du måste rensa tillstånd manuellt ( Remove-ServiceFabricNodeState ) för de borttagna noderna.
• Varje VM-skalningsuppsättning med hållbarhetsnivå Silver eller Guld måste mappa till en egen nodtyp i Service Fabric klustret. Genom att mappa flera VM-skalningsuppsättningar till en enda nodtyp förhindras samordning mellan Service Fabric och Azure-infrastrukturen från att fungera korrekt.
• Ta inte bort slumpmässiga VM-instanser, använd alltid vm-skalningsuppsättningsskalning i funktionen. Borttagningen av slumpmässiga VM-instanser kan skapa obalans i VM-instansen som sprids över uppgraderingsdomäner och feldomäner. Den här obalansen kan påverka systemets förmåga att belastningsutjämna korrekt mellan tjänstinstanserna/tjänstreplikerna.
• Om du använder autoskalning anger du regler som gör att åtgärder för att skala in (ta bort VM-instanser) endast utförs en nod i taget. Det är inte säkert att skala in fler än en instans i taget.
• Om du tar bort eller tar bort virtuella datorer på den primära nodtypen ska du aldrig minska antalet allokerade virtuella datorer under tillförlitlighetsnivån. Dessa åtgärder kommer att blockeras på obestämd tid i en skalningsuppsättning med hållbarhetsnivån Silver eller Guld.

Ändra hållbarhetsnivåer

Inom vissa begränsningar kan hållbarhetsnivån för nodtyper justeras:

• Nodtyper med hållbarhetsnivåer silver eller guld kan inte nedgraderas till Brons.
• Det kan ta några timmar att uppgradera från brons till silver eller guld.
• När du ändrar hållbarhetsnivå måste du uppdatera den i både Service Fabric-tilläggskonfigurationen i din vm-skalningsuppsättningsresurs och i definitionen för nodtypen i Service Fabric klusterresursen. Dessa värden måste matcha.

Ett annat övervägande när kapacitetsplanering är tillförlitlighetsnivån för klustret, som avgör stabiliteten för systemtjänster och det övergripande klustret, enligt beskrivningen i nästa avsnitt.

Klustrets tillförlitlighetsegenskaper

Klustrets tillförlitlighetsnivå avgör antalet systemtjänstrepliker som körs på klustrets primära nodtyp. Ju fler repliker, desto mer tillförlitliga är systemtjänsterna (och därmed klustret som helhet).

Tillförlitlighetsnivån kan ha följande värden:

• – Systemtjänster körs med antalet målrepliker på nio
• Guld – Systemtjänster körs med antalet målrepliker på sju
• Silver – Systemtjänster körs med antalet målrepliker på fem
• Brons – Systemtjänster körs med antalet målrepliker på tre

Här är rekommendationen om att välja tillförlitlighetsnivå. Antalet start start startnoder är också inställt på det minsta antalet noder för en tillförlitlighetsnivå.

När du ökar eller minskar storleken på klustret (summan av VM-instanser i alla nodtyper) bör du överväga att uppdatera klustrets tillförlitlighet från en nivå till en annan. Detta utlöser de klusteruppgraderingar som krävs för att ändra antalet replikuppsättning för systemtjänster. Vänta tills uppgraderingen har slutförts innan du gör några andra ändringar i klustret, till exempel lägga till noder. Du kan övervaka uppgraderingsförloppet på Service Fabric Explorer eller genom att köra Get-ServiceFabricClusterUpgrade

Kapacitetsplanering för tillförlitlighet

Klustrets kapacitetsbehov bestäms av dina specifika krav på arbetsbelastning och tillförlitlighet. Det här avsnittet innehåller allmänna riktlinjer som hjälper dig att komma igång med kapacitetsplanering.

Storlek på virtuell dator

För produktionsarbetsbelastningar är den rekommenderade VM-storleken (SKU) Standard D2_V2 (eller motsvarande) med minst 50 GB lokal SSD, 2 kärnor och 4 GiB minne. Minst 50 GB lokal SSD rekommenderas, men vissa arbetsbelastningar (till exempel de som Windows containrar) kräver större diskar. Tänk på följande begränsningar när du väljer andra VM-storlekar för produktionsarbetsbelastningar:

• Vm-storlekar med partiella kärnor som Standard A0 stöds inte.
• A-serien VM-storlekar stöds inte av prestandaskäl.
• Lågprioriterade virtuella datorer stöds inte.

Primär nodtyp

Produktionsarbetsbelastningar i Azure kräver minst fem primära noder (VM-instanser) och tillförlitlighetsnivån Silver. Vi rekommenderar att du dedikerar klusternodtypen till systemtjänster och använder placeringsbegränsningar för att distribuera programmet till sekundära nodtyper.

Testarbetsbelastningar i Azure kan köra minst en eller tre primära noder. Om du vill konfigurera ett kluster med en nod måste du se till att inställningen är helt utelämnad i Resource Manager mallen (det räcker inte att ange ett tomt reliabilityLevel reliabilityLevel strängvärde för). Om du konfiguration av klustret med en nod med Azure Portal, utförs den här konfigurationen automatiskt.

Icke-primära nodtyper

Det minsta antalet noder för en icke-primär nodtyp beror på nodtypens specifika hållbarhetsnivå. Du bör planera antalet noder (och hållbarhetsnivå) baserat på antalet repliker av program eller tjänster som du vill köra för nodtypen och beroende på om arbetsbelastningen är tillståndslös eller tillståndslös. Tänk på att du kan öka eller minska antalet virtuella datorer i en nodtyp när som helst efter att du har distribuerat klustret.

Tillståndsfulla arbetsbelastningar

För tillståndsfulproduction workloads using Service Fabric reliable collections or reliable Actors ,a minimum and target replica count of five is recommended. Med detta i stabilt tillstånd får du en replik (från en replikuppsättning) i varje feldomän och uppgraderingsdomän. Använd i allmänhet tillförlitlighetsnivån som du anger för systemtjänster som en vägledning för antalet repliker som du använder för dina tillståndsful-tjänster.

Tillståndslösa arbetsbelastningar

För tillståndslösa produktionsarbetsbelastningar är den minsta storlek som inte är primär nodtyp tre för att bibehålla kvorum, men en nodtypstorlek på fem rekommenderas.

Nästa steg

Innan du konfigurerar klustret granskar du uppgraderingsprinciperna för klustret för att undvika att behöva återskapa klustret senare på grund av i Not Allowed övrigt oföränderliga systemkonfigurationsinställningar.

Mer information om klusterplanering finns i:

• Beräkningsplanering och skalning
• Kapacitetsplanering för Service Fabric program
• Planering för haveriberedskap