Att tänka på vid kapacitetsplanering för Service Fabric-kluster
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
Klustrets tillförlitlighetsnivå, som avgör stabiliteten för Service Fabric-systemtjänster och övergripande klusterfunktion
Den här artikeln vägleder dig genom de viktiga beslutspunkterna för vart och ett av dessa områden.
Initialt 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-kluster 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 portuppsättningar öppna och ha olika kapacitetsmått. Mer information om relationen mellan nodtyper och VM-skalningsuppsättningar finns i Nodtyper för Service Fabric-kluster.
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 dedikerar dem enbart till systemtjänster som körs.
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 icke-primära nodtyper.
Den primära nodtypen konfigureras med hjälp av isPrimary attributet under nodtypsdefinitionen i Azure Resource Manager-distributionsmallen. Se NodeTypeDescription-objektet för den fullständiga listan över nodtypsegenskaper. Du kan till exempel öppna en AzureDeploy.json-fil i Service Fabric-klusterexempel och söka efter objektet genom att sökanodeTypes på sidan.
Planeringsöverväganden för nodtyper
Antalet inledande 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?
Vanliga 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å icke-primära nodtyper (en var för front- 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 göra en effektivare och säkrare användning 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 över 100 noder?
En enskild nodtyp kan inte skalas över 100 noder per VM-skalningsuppsättning för Service Fabric-program på ett tillförlitligt sätt. Att köra fler än 100 noder kräver ytterligare VM-skalningsuppsättningar (och därmed ytterligare nodtyper).
Sträcker sig klustret ö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-primära) 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 det antal 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 härnäst.
Klustrets hållbarhetsegenskaper
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, avbildning 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 inget har angetts används bronsnivån . Produktionsarbetsbelastningar kräver hållbarhetsnivån Silver eller Guld för att undvika dataförlust från begäranden på VM-nivå i infrastrukturen.
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 du gör till 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 tillåta 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 |
Anteckning
Ovanstående minsta antal 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 uppgradering av operativsystemavbildningar inte tillgängligt. Även om Patch Orchestration-programmet (endast avsett för kluster som inte är Azure-värdbaserade) inte rekommenderas för Silver eller högre hållbarhetsnivåer, är det ditt enda alternativ 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 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 ändringsåtgärder för VM-storlek 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 automatiska nodaktiveringar under Azure-infrastrukturåtgärder.
- Tar bort noder från tjänsten under tidsperioder då programuppdateringar för Azure-plattformen eller aktiviteter för maskinvaruunderhåll pågår. 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 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 kompilering har fastnat) 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 VM-instansen som är spridda över uppgraderingsdomäner och feldomäner. Den här obalansen kan negativt påverka systemens förmåga att belastningsutjämning mellan tjänstinstanser/tjänstrepliker.
- Om du använder autoskalning anger du regler som skalar in (borttagning av VM-instanser) utförs endast en nod i taget. Skalning i fler ä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 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 för 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 både i Service Fabric-tilläggskonfigurationen i resursen för vm-skalningsuppsättningen och i nodtypsdefinitionen i din Service Fabric-klusterresurs. 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 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å på 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 målreplikuppsättningsantalet nio
- Guld – Systemtjänster körs med målreplikuppsättningsantalet sju
- Silver – Systemtjänster körs med antal målrepliker på fem
- Brons – Systemtjänster körs med målreplikuppsättningsantalet 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 | Platinum |
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 behövs för att ändra antalet replikeringsuppsättningar 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 förloppet för uppgraderingen på 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 ä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 kör Windows-containrar) kräver större diskar.
Som standard konfigureras lokal SSD 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
När du väljer andra VM-storlekar för produktionsarbetsbelastningar bör du tänka på följande begränsningar:
- Partiella/enskilda kärnstorlekar för virtuella datorer som Standard A0 stöds inte.
- A-serie VM-storlekar stöds inte av prestandaskäl.
- Virtuella datorer med låg prioritet stöds inte.
- B-seriens burstbara SKU:er stöds inte.
Primär nodtyp
Produktionsarbetsbelastningar i Azure kräver minst fem primära noder (VM-instanser) och tillförlitlighetsnivån för Silver. Vi rekommenderar att du dedikerar 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 måste du se till att reliabilityLevel inställningen utelämnas i Resource Manager-mallen (det räcker inte att ange ett tomt strängvärde förreliabilityLevel). Om du konfigurerar ett nodkluster med Azure Portal görs den här konfigurationen automatiskt.
Varning
Kluster med en nod körs med en särskild konfiguration utan tillförlitlighet och där utskalning inte stöds.
nodtyper som inte ärprimariska
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 när du har distribuerat klustret.
Tillståndskänsliga arbetsbelastningar
För tillståndskänsliga produktionsarbetsbelastningar med hjälp av tillförlitliga Service Fabric-samlingar eller tillförlitliga aktörer rekommenderas ett minsta antal repliker och målrepliker på fem. Med detta hamnar du i stabilt tillstånd med 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 nodtypen 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: