Dela via

Skala Azure Service Fabric-kluster

  • Artikel

Ett Service Fabric-kluster är en nätverksansluten uppsättning virtuella eller fysiska datorer som dina mikrotjänster distribueras till och hanteras från. 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 klusterresurser när efterfrågan minskar.

Skala in och ut eller horisontell skalning

Ändrar antalet noder i klustret. När de nya noderna ansluter till klustret flyttar Klusterresurshanteraren tjänster till dem, vilket minskar belastningen på befintliga noder. Du kan också minska antalet noder om klustrets resurser inte används effektivt. När noder 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 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 arkitektoniskt arbete för att skala. 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 uppsättningar portar öppna och kan 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 fler 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å för 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 skalningsuppsättningsskalan för virtuella datorer i funktionen. Borttagningen av slumpmässiga VM-instanser kan påverka systemens möjlighet att belastningsutjämningen ska vara korrekt.
  • Om du använder regler för automatisk skalning anger du reglerna så att skalning i (borttagning av 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 skala varje nodtyp/VM-skalningsuppsättning manuellt.

Programmatisk skalning

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

  • Manuellt 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 en hållbarhetsnivå för 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 dem på ett korrekt 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 krä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 närma dig 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 kan regler och SDK:er för automatisk skalning exponera möjligheten att skala programmatiskt och erbjuda kraftfulla alternativ.

Det finns Azure-API:er 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. Att skapa en egen skalningstjänst ger högsta grad av kontroll och anpassningsbarhet ö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 medför dock en kompromiss med kodkomplexitet. Med den här metoden behöver du äga skalningskoden, 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 nedkylning av skalning).

API:et som används för vm-skalningsuppsättningsinteraktioner (både för att kontrollera det aktuella antalet virtuella datorinstanser och för att ändra det) är biblioteket fluent Azure Management Compute. Biblioteket fluent compute är 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 ansluta till sina associerade Azure-resurser via fjärranslutning, 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 koppla från fysiska eller virtuella datorer för att kunna 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 (med uppdaterad VM SKU) läggs till 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 en nodtyp uppåt eller nedåt skiljer sig 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 att köra tjänster 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 de ursprungliga primära nodtypsinstanserna 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