Kapacitetsplanering för Service Fabric-program

I det här dokumentet får du lära dig hur du beräknar mängden resurser (processorer, RAM-minne, disklagring) som du behöver för att köra Dina Azure Service Fabric-program. Det är vanligt att dina resurskrav ändras över tid. Du behöver vanligtvis få resurser när du utvecklar/testar din tjänst och behöver sedan fler resurser när du går in i produktion och ditt program blir allt populärare. När du utformar ditt program bör du tänka igenom de långsiktiga kraven och göra val som gör att tjänsten kan skalas för att möta kundernas höga efterfrågan.

När du skapar ett Service Fabric-kluster bestämmer du vilka typer av virtuella datorer som utgör klustret. Varje virtuell dator levereras med en begränsad mängd resurser i form av processorer (kärnor och hastighet), nätverksbandbredd, RAM-minne och disklagring. När tjänsten växer med tiden kan du uppgradera till virtuella datorer som erbjuder större resurser och/eller lägga till fler virtuella datorer i klustret. Om du vill göra det senare måste du först skapa tjänsten så att den kan dra nytta av nya virtuella datorer som läggs till dynamiskt i klustret.

Vissa tjänster hanterar lite eller inga data på de virtuella datorerna själva. Därför bör kapacitetsplaneringen för dessa tjänster främst fokusera på prestanda, vilket innebär att välja lämpliga processorer (kärnor och hastighet) för de virtuella datorerna. Dessutom bör du överväga nätverksbandbredd, inklusive hur ofta nätverksöverföringar sker och hur mycket data som överförs. Om tjänsten behöver fungera bra när tjänstanvändningen ökar kan du lägga till fler virtuella datorer i klustret och belastningsutjämning av nätverksbegäranden över alla virtuella datorer.

För tjänster som hanterar stora mängder data på de virtuella datorerna bör kapacitetsplaneringen främst fokusera på storleken. Därför bör du noga överväga kapaciteten för den virtuella datorns RAM-minne och disklagring. Det virtuella minneshanteringssystemet i Windows gör att diskutrymmet ser ut som RAM-minne för programkod. Dessutom ger Service Fabric-körningen smart växling som endast behåller frekventa data i minnet och flyttar kalldata till disk. Program kan därför använda mer minne än vad som är fysiskt tillgängligt på den virtuella datorn. Om du har mer RAM ökar bara prestandan eftersom den virtuella datorn kan behålla mer disklagring i RAM-minnet. Den virtuella dator som du väljer bör ha en disk som är tillräckligt stor för att lagra de data som du vill använda på den virtuella datorn. På samma sätt bör den virtuella datorn ha tillräckligt med RAM-minne för att ge dig den prestanda du önskar. Om tjänstens data växer med tiden kan du lägga till fler virtuella datorer i klustret och partitionera data över alla virtuella datorer.

Ta reda på hur många noder du behöver

Genom att partitionera tjänsten kan du skala ut tjänstens data. Mer information om partitionering finns i Partitionera Service Fabric. Varje partition måste rymmas i en enda virtuell dator, men flera (små) partitioner kan placeras på en enda virtuell dator. Om du har fler små partitioner får du större flexibilitet än att ha några större partitioner. Kompromissen är att om du har många partitioner ökar Service Fabric-omkostnaderna och du kan inte utföra transaktionsåtgärder över partitioner. Det finns också mer potentiell nätverkstrafik om din tjänstkod ofta behöver komma åt delar av data som finns i olika partitioner. När du utformar din tjänst bör du noga överväga dessa för- och nackdelar för att komma fram till en effektiv partitioneringsstrategi.

Anta att ditt program har en enda tillståndskänslig tjänst som har en butiksstorlek som du förväntar dig att växa till DB_Size GB på ett år. Du är villig att lägga till fler program (och partitioner) när du upplever tillväxt efter det året. Replikeringsfaktorn (RF) som avgör antalet repliker för din tjänst påverkar det totala DB_Size. Den totala DB_Size för alla repliker är replikeringsfaktorn multiplicerad med DB_Size. Node_Size representerar diskutrymmet/RAM-minnet per nod som du vill använda för tjänsten. För bästa prestanda bör DB_Size passa in i minnet i klustret och en Node_Size som finns runt RAM-minnet för den virtuella datorn bör väljas. Genom att allokera en Node_Size som är större än RAM-kapaciteten förlitar du dig på sidindelningen som tillhandahålls av Service Fabric-körningen. Därför kanske dina prestanda inte är optimala om hela dina data anses vara frekventa (eftersom data sedan bläddras in/ut). För många tjänster där endast en bråkdel av data är frekvent är det dock mer kostnadseffektivt.

Antalet noder som krävs för maximal prestanda kan beräknas på följande sätt:

Number of Nodes = (DB_Size * RF)/Node_Size

Ta hänsyn till tillväxt

Du kanske vill beräkna antalet noder baserat på de DB_Size som du förväntar dig att tjänsten ska växa till, förutom de DB_Size som du började med. Öka sedan antalet noder när tjänsten växer så att du inte överetablerar antalet noder. Men antalet partitioner bör baseras på antalet noder som behövs när du kör tjänsten med maximal tillväxt.

Det är bra att ha några extra datorer tillgängliga när som helst så att du kan hantera oväntade toppar eller fel (till exempel om några virtuella datorer går ned). Den extra kapaciteten bör bestämmas med hjälp av dina förväntade toppar, men en startpunkt är att reservera några extra virtuella datorer (5–10 procent extra).

Föregående förutsätter en enda tillståndskänslig tjänst. Om du har mer än en tillståndskänslig tjänst måste du lägga till DB_Size som är associerade med de andra tjänsterna i ekvationen. Du kan också beräkna antalet noder separat för varje tillståndskänslig tjänst. Tjänsten kan ha repliker eller partitioner som inte är balanserade. Tänk på att partitioner också kan ha mer data än andra. Mer information om partitionering finns i partitioneringsartikeln om metodtips. Den föregående ekvationen är dock partitions- och replikagnostisk, eftersom Service Fabric säkerställer att replikerna sprids ut mellan noderna på ett optimerat sätt.

Använda ett kalkylblad för kostnadsberäkning

Nu ska vi placera några riktiga tal i formeln. Ett exempel på ett kalkylblad visar hur du planerar kapaciteten för ett program som innehåller tre typer av dataobjekt. För varje objekt beräknar vi dess storlek och hur många objekt vi förväntar oss att ha. Vi väljer också hur många repliker vi vill ha av varje objekttyp. Kalkylbladet beräknar den totala mängden minne som ska lagras i klustret.

Sedan anger vi en VM-storlek och en månatlig kostnad. Baserat på storleken på den virtuella datorn visar kalkylbladet det minsta antal partitioner som du måste använda för att dela upp dina data så att de passar på noderna. Du kanske vill ha ett större antal partitioner för att tillgodose programmets specifika beräknings- och nätverkstrafikbehov. Kalkylbladet visar att antalet partitioner som hanterar användarprofilobjekten har ökat från ett till sex.

Nu, baserat på all den här informationen, visar kalkylbladet att du fysiskt kan hämta alla data med önskade partitioner och repliker i ett kluster med 26 noder. Det här klustret skulle dock vara tätt packat, så du kanske vill ha några ytterligare noder för att hantera nodfel och uppgraderingar. Kalkylbladet visar också att fler än 57 noder inte ger något ytterligare värde eftersom du skulle ha tomma noder. Återigen kanske du vill gå över 57 noder ändå för att hantera nodfel och uppgraderingar. Du kan justera kalkylbladet så att det matchar programmets specifika behov.

Nästa steg

Mer information om hur du partitionerar tjänsten finns i Partitionering av Service Fabric-tjänster .