Dela via

Skala Azure Service Fabric-kluster

  • Artikel

Ett Service Fabric-kluster är en nätverksansluten uppsättning virtuella eller fysiska datorer där dina mikrotjänster distribueras och hanteras. En dator eller virtuell dator som ingår i ett kluster kallas för en nod. Kluster kan innehålla potentiellt tusentals noder. När du har skapat ett Service Fabric-kluster kan du skala klustret vågrätt (ändra antalet noder) eller lodrätt (ändra nodernas resurser). Du kan skala klustret när som helst, även när arbetsbelastningar körs i klustret. När klustret skalas skalas även dina program automatiskt.

Varför skalar du klustret? Programkrav ändras över tid. Du kan behöva öka klusterresurserna för att möta ökad programarbetsbelastning eller nätverkstrafik eller minska klusterresurserna när efterfrågan sjunker.

Skala in och ut eller horisontell skalning

Ändrar antalet noder i klustret. När de nya noderna ansluter till klustret flyttar kluster Resource Manager tjänster till dem, vilket minskar belastningen på de befintliga noderna. Du kan också minska antalet noder om klustrets resurser inte används effektivt. När noderna lämnar klustret flyttas tjänsterna från dessa noder och belastningen ökar på de återstående noderna. Om du minskar antalet noder i ett kluster som körs i Azure kan du spara pengar eftersom du betalar för antalet virtuella datorer som du använder och inte för arbetsbelastningen på dessa virtuella datorer.

  • Fördelar: Oändlig skala, i teorin. Om ditt program är utformat för skalbarhet kan du aktivera obegränsad tillväxt genom att lägga till fler noder. Verktygen i molnmiljöer gör det enkelt att lägga till eller ta bort noder, så det är enkelt att justera kapaciteten och du betalar bara för de resurser du använder.
  • Nackdelar: Program måste utformas för skalbarhet. Programdatabaser och beständighet kan också kräva ytterligare arkitekturarbete för skalning. Tillförlitliga samlingar i tillståndskänsliga Service Fabric-tjänster gör det dock mycket enklare att skala dina programdata.

Vm-skalningsuppsättningar är en Azure-beräkningsresurs som du kan använda för att distribuera och hantera en samling virtuella datorer som en uppsättning. Varje nodtyp som definieras i ett Azure-kluster konfigureras som en separat skalningsuppsättning. Varje nodtyp kan sedan skalas in eller ut oberoende av varandra, ha olika portuppsättningar öppna och ha olika kapacitetsmått.

Tänk på följande riktlinjer när du skalar ett Azure-kluster:

  • primära nodtyper som kör produktionsarbetsbelastningar bör alltid ha fem eller fler noder.
  • icke-primära nodtyper som kör tillståndskänsliga produktionsarbetsbelastningar bör alltid ha fem eller flera noder.
  • icke-primära nodtyper som kör tillståndslösa produktionsarbetsbelastningar bör alltid ha två eller flera noder.
  • Alla nodtyper av hållbarhetsnivå guld eller silver bör alltid ha fem eller fler noder.
  • Ta inte bort slumpmässiga VM-instanser/noder från en nodtyp, använd alltid vm-skalningsuppsättningens skalningsskala i funktionen. Borttagningen av slumpmässiga VM-instanser kan påverka systemens förmåga att belastningsutjämningen ska vara korrekt.
  • Om du använder regler för automatisk skalning anger du reglerna så att inskalning (ta bort VM-instanser) görs en nod i taget. Det är inte säkert att skala ned mer än en instans i taget.

Eftersom Service Fabric-nodtyperna i klustret består av VM-skalningsuppsättningar på serverdelen kan du konfigurera regler för automatisk skalning eller manuellt skala varje nodtyp/VM-skalningsuppsättning.

Programmeringsskalning

I många scenarier är skalning av ett kluster manuellt eller med autoskalningsregler bra lösningar. För mer avancerade scenarier kanske de dock inte passar. Potentiella nackdelar med dessa metoder är:

  • Manuell skalning kräver att du loggar in och uttryckligen begär skalningsåtgärder. Om skalningsåtgärder krävs ofta eller vid oförutsägbara tidpunkter kanske den här metoden inte är en bra lösning.
  • När regler för automatisk skalning tar bort en instans från en VM-skalningsuppsättning tar de inte automatiskt bort kunskapen om noden från det associerade Service Fabric-klustret om inte nodtypen har hållbarhetsnivån Silver eller Guld. Eftersom regler för automatisk skalning fungerar på skalningsuppsättningsnivå (i stället för på Service Fabric-nivå) kan regler för automatisk skalning ta bort Service Fabric-noder utan att stänga av dem på ett smidigt sätt. Den här oförskämda nodborttagningen lämnar "ghost" Service Fabric-nodtillståndet efter inskalningsåtgärder. En enskild person (eller en tjänst) skulle regelbundet behöva rensa bort nodtillståndet i Service Fabric-klustret.
  • En nodtyp med hållbarhetsnivån Guld eller Silver rensar automatiskt borttagna noder, så ingen ytterligare rensning behövs.
  • Även om det finns många mått som stöds av regler för automatisk skalning är det fortfarande en begränsad uppsättning. Om ditt scenario kräver skalning baserat på ett mått som inte omfattas av den uppsättningen är regler för automatisk skalning kanske inte ett bra alternativ.

Hur du ska hantera Service Fabric-skalning beror på ditt scenario. Om skalning är ovanligt räcker det förmodligen att lägga till eller ta bort noder manuellt. För mer komplexa scenarier erbjuder regler för automatisk skalning och SDK:er möjligheten att skala programmatiskt kraftfulla alternativ.

Azure-API:er finns som gör att program kan arbeta programmatiskt med VM-skalningsuppsättningar och Service Fabric-kluster. Om befintliga alternativ för automatisk skalning inte fungerar för ditt scenario gör dessa API:er det möjligt att implementera anpassad skalningslogik.

En metod för att implementera den här "hemgjorda" funktionen för automatisk skalning är att lägga till en ny tillståndslös tjänst i Service Fabric-programmet för att hantera skalningsåtgärder. Genom att skapa en egen skalningstjänst får du högsta möjliga kontroll och anpassningsförmåga över programmets skalningsbeteende. Detta kan vara användbart för scenarier som kräver exakt kontroll över när eller hur ett program skalar in eller ut. Den här kontrollen innebär dock en kompromiss mellan kodkomplexitet. Med den här metoden behöver du äga skalningskod, vilket inte är trivialt. I tjänstens RunAsync -metod kan en uppsättning utlösare avgöra om skalning krävs (inklusive kontroll av parametrar som maximal klusterstorlek och skalning av nedkylning).

API:et som används för interaktioner med VM-skalningsuppsättningar (både för att kontrollera det aktuella antalet virtuella datorinstanser och för att ändra det) är biblioteket fluent Azure Management Compute. Fluent-beräkningsbiblioteket tillhandahåller ett lätthanterad API för att interagera med VM-skalningsuppsättningar. Om du vill interagera med själva Service Fabric-klustret använder du System.Fabric.FabricClient.

Skalningskoden behöver dock inte köras som en tjänst i klustret för att skalas. Både IAzure och FabricClient kan fjärransluta till sina associerade Azure-resurser, så skalningstjänsten kan enkelt vara ett konsolprogram eller en Windows-tjänst som körs utanför Service Fabric-programmet.

Baserat på dessa begränsningar kanske du vill implementera mer anpassade automatiska skalningsmodeller.

Skala upp och ned eller lodrät skalning

Ändrar resurserna (CPU, minne eller lagring) för noder i klustret.

  • Fördelar: Programvaru- och programarkitekturen förblir densamma.
  • Nackdelar: Begränsad skala, eftersom det finns en gräns för hur mycket du kan öka resurserna på enskilda noder. Stilleståndstid, eftersom du måste ta fysiska eller virtuella datorer offline för att lägga till eller ta bort resurser.

Vm-skalningsuppsättningar är en Azure-beräkningsresurs som du kan använda för att distribuera och hantera en samling virtuella datorer som en uppsättning. Varje nodtyp som definieras i ett Azure-kluster konfigureras som en separat skalningsuppsättning. Varje nodtyp kan sedan hanteras separat. Att skala upp eller ned en nodtyp innebär att en ny nodtyp läggs till (med uppdaterad VM-SKU) och att den gamla nodtypen tas bort.

Tänk på följande riktlinjer när du skalar ett Azure-kluster:

Processen för att skala upp eller ned en nodtyp skiljer sig åt beroende på om det är en icke-primär eller primär nodtyp.

Skala icke-primära nodtyper

Skapa en ny nodtyp med de resurser du behöver. Uppdatera placeringsbegränsningarna för tjänster som körs så att de inkluderar den nya nodtypen. Gradvis (en i taget) minskar du antalet instanser av den gamla nodtypen till noll så att klustrets tillförlitlighet inte påverkas. Tjänsterna migreras gradvis till den nya nodtypen när den gamla nodtypen inaktiveras.

Skala den primära nodtypen

Distribuera en ny primär nodtyp med uppdaterad VM-SKU och inaktivera sedan den ursprungliga primära nodtypen en i taget så att systemtjänsterna migreras till den nya skalningsuppsättningen. Kontrollera att klustret och de nya noderna är felfria och ta sedan bort den ursprungliga skalningsuppsättningen och nodtillståndet för de borttagna noderna.

Om det inte är möjligt kan du skapa ett nytt kluster och återställa programtillståndet (om tillämpligt) från ditt gamla kluster. Du behöver inte återställa något systemtjänsttillstånd. De återskapas när du distribuerar dina program till det nya klustret. Om du bara körde tillståndslösa program i klustret är allt du gör att distribuera dina program till det nya klustret, du har inget att återställa.

Nästa steg