Dela via

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

  • Artikel

Planering av klusterkapacitet är viktigt för varje Service Fabric-produktionsmiljö. Viktiga överväganden är:

  • Initialt antal och egenskaper för klusternodtyper

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

  • Tillförlitlighetsnivån för klustret, som avgör stabiliteten för Service Fabric-systemtjänster och övergripande klusterfunktion

Den här artikeln beskriver de viktiga beslutspunkterna för vart och ett av dessa områden.

Initialt antal och egenskaper för klusternodtyper

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

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

Varje kluster kräver en primär nodtyp, som kör kritiska systemtjänster som tillhandahåller Service Fabric-plattformsfunktioner. Även om det är möjligt att även använda primära nodtyper för att köra dina program rekommenderar vi att de endast används för att köra systemtjänster.

nodtyper som inte är primära kan användas för att definiera programroller (till exempel klient- och serverdelstjänster ) och för att fysiskt isolera tjänster i ett kluster. Service Fabric-kluster kan ha noll eller fler nodtyper som inte ärprimariska.

Den primära nodtypen konfigureras med hjälp av isPrimary attributet under nodtypdefinitionen i Azure Resource Manager-distributionsmallen. Se NodeTypeDescription-objektet för den fullständiga listan över egenskaper för nodtyp. Du kan till exempel öppna valfri AzureDeploy.json fil i Service Fabric-klusterexempel och Söka efter nodeTypes objektet på sidan.

Planeringsöverväganden för nodtyp

Antalet initiala nodtyper beror på syftet med klustret 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 offentlig eller internetuppkopplad?

    Typiska program innehåller en klientdelsgatewaytjänst som tar emot indata från en klient och en eller flera serverdelstjänster som kommunicerar med klientdelstjänsterna, med separata nätverk mellan klient- och serverdelstjänsterna. Dessa fall kräver vanligtvis tre nodtyper: en primär nodtyp och två nodtyper som inte ärprimariska (en var för klient- och serverdelstjänsten).

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

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

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

    En enskild nodtyp kan inte skalas på ett tillförlitligt sätt utö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ärför ytterligare nodtyper).

  • Kommer klustret att sträcka sig över Tillgänglighetszoner?

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

När du fastställer antalet och egenskaperna för nodtyper för det första skapandet av klustret bör du tänka på att du alltid kan lägga till, ändra eller ta bort (icke-privilegierade) nodtyper när klustret har distribuerats. 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 över arbetsbelastningen och sedan ta bort den ursprungliga primära nodtypen.

Ytterligare ett övervägande för egenskaperna för nodtypen är hållbarhetsnivån, som avgör vilka privilegier en nodtyps virtuella datorer har i Azure-infrastrukturen. Använd storleken på de virtuella datorer som du väljer för klustret och antalet instanser som du tilldelar för enskilda nodtyper för att fastställa lämplig hållbarhetsnivå för var och en av dina nodtyper enligt beskrivningen nedan.

Hållbarhetsegenskaper för klustret

Hållbarhetsnivån anger de privilegier som dina virtuella Service Fabric-datorer har med den underliggande Azure-infrastrukturen. Med det här privilegiet kan Service Fabric pausa alla infrastrukturbegäranden på VM-nivå (till exempel omstart, omimering eller migrering) som påverkar kvorumkraven för Service Fabric-systemtjänster och dina tillståndskänsliga tjänster.

Viktigt!

Hållbarhetsnivån anges per nodtyp. Om ingen har angetts används bronsnivån . Produktionsarbetsbelastningar kräver hållbarhetsnivån Silver eller Guld för att undvika dataförlust från infrastrukturbegäranden på VM-nivå.

I tabellen nedan visas service fabric-hållbarhetsnivåer, deras krav och priser.

Hållbarhetsnivå Minsta antal virtuella datorer som krävs VM-storlekar som stöds Uppdateringar som du gör i vm-skalningsuppsättningen Uppdateringar och underhåll som initieras av Azure
Guld 5 Fullnodsstorlekar som är dedikerade till en enskild kund – tillgängliga VM-storlekar Kan fördröjas tills det har godkänts av Service Fabric-klustret Kan pausas i 2 timmar per uppgraderingsdomän för att ge ytterligare tid för repliker att återställas från tidigare fel
Silver 5 VM med en eller flera kärnor och minst 50 GB lokal SSD Kan fördröjas tills det har godkänts av Service Fabric-klustret Det går inte att fördröja under en längre tid
Brons 1 Virtuella datorer med minst 50 GB lokal SSD Fördröjs inte av Service Fabric-klustret Det går inte att fördröja under en längre tid

Kommentar

Det ovan nämnda minsta antalet virtuella datorer är ett nödvändigt krav för varje hållbarhetsnivå. Vi har valideringar på plats som förhindrar skapande eller ändring av befintliga vm-skalningsuppsättningar som inte uppfyller dessa krav.

Varning

Med bronshållbarhet är automatisk os-avbildningsuppgradering inte tillgänglig. Patch Orchestration Application (endast avsett för icke-Azure-värdbaserade kluster) rekommenderas inte för Silver eller högre hållbarhetsnivåer, men det är det enda alternativet för att automatisera Windows-uppdateringar med avseende på Service Fabric-uppgraderingsdomäner.

Viktigt!

Oavsett hållbarhetsnivå förstörs klustret genom att köra en frigöringsåtgärd på en VM-skalningsuppsättning.

Brons

Nodtyper som körs med bronshållbarhet får inga privilegier. Det innebär att infrastrukturjobb som påverkar dina tillståndskänsliga arbetsbelastningar inte stoppas eller fördröjs. Använd bronshållbarhet för nodtyper som bara kör tillståndslösa arbetsbelastningar. För produktionsarbetsbelastningar rekommenderar vi att du kör Silver eller senare.

Silver och guld

Använd silver- eller guldhållbarhet för alla nodtyper som är värdar för tillståndskänsliga tjänster som du förväntar dig att skala in ofta, och där du vill att distributionsåtgärderna ska fördröjas och att kapaciteten minskas till förmån 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 (nodaktivering och Remove-ServiceFabricNodeState anropas automatiskt).
  • Minskar risken för dataförlust på grund av storleksändringsåtgärder för virtuella datorer på plats och Azure-infrastrukturåtgärder.

Nackdelar

  • Distributioner till vm-skalningsuppsättningar och andra relaterade Azure-resurser kan överskrida tidsgränsen, fördröjas eller blockeras helt av problem i klustret eller på infrastrukturnivå.
  • Ökar antalet repliklivscykelhändelser (till exempel primära växlingar) på grund av automatiserade nodaktiveringar under Azure-infrastrukturåtgärder.
  • Tar noder ur drift under perioder medan programuppdateringar för Azure-plattformen eller maskinvaruunderhåll pågår. Du kan se noder med statusEnaktivering/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 guldhållbarhet

Följ dessa rekommendationer för att hantera nodtyper med silver- eller guldhållbarhet:

  • Håll klustret och programmen felfria hela tiden och se till att programmen svarar på alla livscykelhändelser för tjänstrepliker (till exempel replik i bygget) i tid.
  • Använd säkrare sätt att ändra storlek på virtuella datorer (skala upp/ned). Att ändra vm-storleken för en VM-skalningsuppsättning kräver noggrann planering och försiktighet. Mer information finns i Skala upp en Service Fabric-nodtyp
  • Behåll minst fem noder för alla vm-skalningsuppsättningar som har hållbarhetsnivån Guld eller Silver aktiverat. Klustret anger feltillstånd om du skalar in under det här tröskelvärdet och du måste rensa tillståndet (Remove-ServiceFabricNodeState) för de borttagna noderna manuellt.
  • Varje vm-skalningsuppsättning med hållbarhetsnivån Silver eller Guld måste mappas till sin egen nodtyp i Service Fabric-klustret. Genom att mappa flera vm-skalningsuppsättningar till en enskild nodtyp förhindrar du att samordningen mellan Service Fabric-klustret och Azure-infrastrukturen fungerar korrekt.
  • Ta inte bort slumpmässiga VM-instanser, använd alltid skalningsuppsättningsskala för virtuella datorer i funktionen. Borttagningen av slumpmässiga VM-instanser kan skapa obalanser i den virtuella datorinstansen fördelad på uppgraderingsdomäner och feldomäner. Den här obalansen kan påverka systemens möjlighet att korrekt belastningsutjämning mellan tjänstinstanser/tjänstrepliker.
  • Om du använder Autoskalning anger du regler som skalar in (borttagning av VM-instanser) åtgärder görs endast en nod i taget. Skalning i mer än en instans i taget är inte säkert.
  • Om du tar bort eller frigör virtuella datorer på den primära nodtypen kan du aldrig minska antalet allokerade virtuella datorer under vad tillförlitlighetsnivån kräver. 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 nodtyp justeras:

  • Nodtyper med hållbarhetsnivåer silver eller guld kan inte nedgraderas till Brons.
  • Nedgradering av nodtyper med hållbarhetsnivån Guld till Silver stöds inte.
  • Det kan ta några timmar att uppgradera från Brons till Silver eller Guld.
  • När du ändrar hållbarhetsnivån måste du uppdatera den i både Service Fabric-tilläggskonfigurationen i resursen för vm-skalningsuppsättningen och i nodtypdefinitionen i din Service Fabric-klusterresurs. Dessa värden måste matcha.

En annan faktor när kapacitetsplanering är tillförlitlighetsnivån för klustret, som avgör stabiliteten för systemtjänster och ditt övergripande kluster, enligt beskrivningen i nästa avsnitt.

Tillförlitlighetsegenskaper för klustret

Klustertillförlitlighetsnivån 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).

Viktigt!

Tillförlitlighetsnivån anges på klusternivå och avgör det minsta antalet noder av den primära nodtypen. Produktionsarbetsbelastningar kräver en tillförlitlighetsnivå för Silver (större eller lika med fem noder) eller högre.

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

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

Här är rekommendationen om att välja tillförlitlighetsnivå. Antalet startnoder anges också till det minsta antalet noder för en tillförlitlighetsnivå.

Antal noder Tillförlitlighetsnivå
1 Ange inte parametern reliabilityLevel : systemet beräknar den.
3 Brons
5 eller 6 Silver
7 eller 8 Guld
9 och uppåt Platina

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

Kapacitetsplanering för tillförlitlighet

Klustrets kapacitetsbehov bestäms av dina specifika arbetsbelastnings- och tillförlitlighetskrav. Det här avsnittet innehåller allmän vägledning som hjälper dig att komma igång med kapacitetsplanering.

Storleksändring för virtuell dator

För produktionsarbetsbelastningar rekommenderar vi en VM-storlek (SKU) med följande:

  • Minst 2 kärnor.
  • Minst 50 GB lokal SSD. Vissa arbetsbelastningar, till exempel de som kör Windows-containrar, kräver dock större diskar.

Som standard är lokal SSD konfigurerad till 64 GB. Storleken kan konfigureras i inställningen MaxDiskQuotaInMB i avsnittet Diagnostik i klusterinställningar.

Anvisningar om hur du justerar klusterinställningarna för ett kluster som finns i Azure finns i Uppgradera konfigurationen av ett kluster i Azure

Anvisningar om hur du justerar klusterinställningarna för ett fristående kluster som finns i Windows finns i Uppgradera konfigurationen av ett fristående kluster

Tänk på följande begränsningar när du väljer andra VM-storlekar för produktionsarbetsbelastningar:

  • Vm-storlekar med partiella/enkla kärnor som Standard A0 stöds inte.
  • Vm-storlekar i en serie stöds inte av prestandaskäl.
  • Virtuella datorer med låg prioritet stöds inte.
  • B-serien burstable SKU:er 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 tillägnar klustrets primära nodtyp 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 kontrollerar du att reliabilityLevel inställningen utelämnas i Resource Manager-mallen (det räcker inte att ange ett tomt strängvärde för reliabilityLevel ). Om du konfigurerar ett nodkluster med Azure Portal görs den här konfigurationen automatiskt.

Varning

Ennodskluster körs med en speciell konfiguration utan tillförlitlighet och där utskalning inte stöds.

nodtyper som inte ärprimary

Det minsta antalet noder för en nodtyp som inte ärprimary 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åndskänslig 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åndskänsliga arbetsbelastningar

För tillståndskänsliga produktionsarbetsbelastningar som använder tillförlitliga Service Fabric-samlingar eller tillförlitliga aktörer rekommenderas ett minsta och målreplikantal på fem. Med detta i stabilt tillstånd får du en replik (från en replikuppsättning) i varje feldomän och uppgraderingsdomän. I allmänhet använder du den tillförlitlighetsnivå som du har angett för systemtjänster som en guide för antalet repliker som du använder för dina tillståndskänsliga tjänster.

Tillståndslösa arbetsbelastningar

För tillståndslösa produktionsarbetsbelastningar är den minsta icke-primariska nodtypstorleken som stöds tre för att upprätthålla kvorum, men en nodtypstorlek på fem rekommenderas.

Nästa steg

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

Mer information om klusterplanering finns i: