Kapacitetsplanering för Service Fabric-program

I det här dokumentet lär du dig hur du beräknar hur mycket 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 växer i popularitet. 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 har 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 kapacitetsplanering främst fokusera på storlek. 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 tillhandahåller Service Fabric-körningen smart växling som endast behåller frekventa data i minnet och flyttar kalla data till disk. Program kan därför använda mer minne än vad som är fysiskt tillgängligt på den virtuella datorn. Att ha 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.

Fastställa 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 Partitionering av Service Fabric. Varje partition måste passa in i en enskild virtuell dator, men flera (små) partitioner kan placeras på en enda virtuell dator. Att ha fler små partitioner ger dig därför 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 transacted-åtgärder mellan 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ördelar 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 om 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 den 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 ligger runt RAM-minnet på 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å växlingen som tillhandahålls av Service Fabric-körningen. Det innebär att prestandan kanske inte är optimal om hela data anses vara frekventa (sedan dess är data in-/utsidessidor). Men för många tjänster där endast en bråkdel av data är frekventa är det 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, utöver 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 ner). 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 artikeln partitionering om metodtips. Den föregående ekvationen är dock partitions- och replikaberoende eftersom Service Fabric ser till att replikerna sprids ut mellan noderna på ett optimerat sätt.

Använda ett kalkylblad för kostnadsberäkning

Nu ska vi lägga 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 månadskostnad. Baserat på storleken på den virtuella datorn anger kalkylbladet det minsta antal partitioner som du måste använda för att dela upp dina data så att de passar fysiskt 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 denna information, visar kalkylbladet att du fysiskt kan hämta alla data med önskade partitioner och repliker i ett 26-nodskluster. Det här klustret skulle dock vara tätt packat, så du kanske vill ha 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

Kolla in Partitionering av Service Fabric-tjänster för att lära dig mer om partitionering av tjänsten.