Capaciteitsplanning voor Service Fabric-toepassingen

In dit document leert u hoe u een schatting kunt maken van de hoeveelheid resources (CPU's, RAM, schijfopslag) die u nodig hebt om uw Azure Service Fabric-toepassingen uit te voeren. Het is gebruikelijk dat uw resourcevereisten in de loop van de tijd veranderen. Normaal gesproken hebt u weinig resources nodig tijdens het ontwikkelen/testen van uw service en hebt u vervolgens meer resources nodig naarmate u in productie gaat en uw toepassing steeds populairder wordt. Wanneer u uw toepassing ontwerpt, moet u nadenken over de vereisten voor de lange termijn en keuzes maken waarmee uw service kan worden geschaald om te voldoen aan de hoge vraag van klanten.

Wanneer u een Service Fabric-cluster maakt, bepaalt u welke soorten virtuele machines (VM's) het cluster vormen. Elke VM wordt geleverd met een beperkte hoeveelheid resources in de vorm van CPU's (kernen en snelheid), netwerkbandbreedte, RAM en schijfopslag. Naarmate uw service in de loop van de tijd groeit, kunt u upgraden naar VM's die meer resources bieden en/of meer VM's toevoegen aan uw cluster. Als u dit laatste wilt doen, moet u uw service in eerste instantie ontwerpen, zodat deze kan profiteren van nieuwe VM's die dynamisch aan het cluster worden toegevoegd.

Sommige services beheren weinig tot geen gegevens op de VM's zelf. Daarom moet de capaciteitsplanning voor deze services voornamelijk gericht zijn op prestaties, wat betekent dat de juiste CPU's (kernen en snelheid) van de VM's moeten worden geselecteerd. Daarnaast moet u rekening houden met de netwerkbandbreedte, inclusief hoe vaak netwerkoverdrachten plaatsvinden en hoeveel gegevens worden overgedragen. Als uw service goed moet presteren naarmate het servicegebruik toeneemt, kunt u meer VM's toevoegen aan het cluster en de netwerkaanvragen verdelen over alle VM's.

Voor services die grote hoeveelheden gegevens op de VM's beheren, moet de capaciteitsplanning zich voornamelijk richten op de grootte. U moet dus zorgvuldig rekening houden met de capaciteit van het RAM-geheugen en de schijfopslag van de VM. Het beheersysteem voor virtueel geheugen in Windows zorgt ervoor dat schijfruimte eruitziet als RAM-naar-toepassingscode. Bovendien biedt de Service Fabric-runtime slim paging om alleen dynamische gegevens in het geheugen te bewaren en de koude gegevens naar de schijf te verplaatsen. Toepassingen kunnen dus meer geheugen gebruiken dan fysiek beschikbaar is op de VM. Als u meer RAM-geheugen hebt, worden de prestaties alleen maar verbeterd, omdat de VM meer schijfopslag in het RAM-geheugen kan behouden. De vm die u selecteert, moet een schijf hebben die groot genoeg is om de gewenste gegevens op de virtuele machine op te slaan. Op dezelfde manier moet de VM voldoende RAM-geheugen hebben om u de gewenste prestaties te bieden. Als de gegevens van uw service in de loop van de tijd toenemen, kunt u meer VM's toevoegen aan het cluster en de gegevens partitioneren over alle VM's.

Bepalen hoeveel knooppunten u nodig hebt

Door uw service te partitioneren, kunt u de gegevens van uw service uitschalen. Zie Partitioning Service Fabric voor meer informatie over partitionering. Elke partitie moet binnen één virtuele machine passen, maar er kunnen meerdere (kleine) partities op één VM worden geplaatst. Als u dus meer kleine partities hebt, hebt u meer flexibiliteit dan een paar grotere partities. Het nadeel is dat het hebben van veel partities de Service Fabric-overhead verhoogt en dat u geen transacties tussen partities kunt uitvoeren. Er is ook meer potentieel netwerkverkeer als uw servicecode vaak toegang nodig heeft tot stukjes gegevens die zich in verschillende partities bevinden. Wanneer u uw service ontwerpt, moet u deze voor- en nadelen zorgvuldig overwegen om tot een effectieve partitioneringsstrategie te komen.

Stel dat uw toepassing één stateful service heeft met een winkelgrootte die naar verwachting in een jaar zal toenemen tot DB_Size GB. U bent bereid om meer toepassingen (en partities) toe te voegen naarmate u na dat jaar groei ervaart. De replicatiefactor (RF), die het aantal replica's voor uw service bepaalt, is van invloed op het totale DB_Size. Het totale DB_Size voor alle replica's is de replicatiefactor vermenigvuldigd met DB_Size. Node_Size vertegenwoordigt de schijfruimte/HET RAM-geheugen per knooppunt dat u wilt gebruiken voor uw service. Voor de beste prestaties moet de DB_Size in het geheugen in het cluster passen en moet er een Node_Size worden gekozen die zich rond het RAM-geheugen van de virtuele machine bevindt. Door een Node_Size toe te wijzen die groter is dan de RAM-capaciteit, vertrouwt u op de paging die wordt geleverd door de Service Fabric-runtime. Uw prestaties zijn dus mogelijk niet optimaal als uw volledige gegevens als dynamisch worden beschouwd (sindsdien worden de gegevens in-/uitpagina's weergegeven). Voor veel services waarbij slechts een fractie van de gegevens dynamisch is, is het echter rendabeler.

Het aantal knooppunten dat is vereist voor maximale prestaties, kan als volgt worden berekend:

Number of Nodes = (DB_Size * RF)/Node_Size

Rekening houden met groei

Mogelijk wilt u het aantal knooppunten berekenen op basis van de DB_Size die u verwacht dat uw service zal groeien, naast de DB_Size waarmee u bent begonnen. Vergroot vervolgens het aantal knooppunten naarmate uw service groeit, zodat u het aantal knooppunten niet te veel inricht. Maar het aantal partities moet zijn gebaseerd op het aantal knooppunten dat nodig is wanneer u uw service uitvoert met maximale groei.

Het is goed om op elk gewenst moment een aantal extra machines beschikbaar te hebben, zodat u onverwachte pieken of storingen kunt afhandelen (bijvoorbeeld als er een paar VM's uitvallen). Hoewel de extra capaciteit moet worden bepaald met behulp van de verwachte pieken, is het uitgangspunt om een paar extra VM's te reserveren (5-10 procent extra).

In het voorgaande wordt uitgegaan van één stateful service. Als u meer dan één stateful service hebt, moet u de DB_Size die zijn gekoppeld aan de andere services toevoegen aan de vergelijking. U kunt ook het aantal knooppunten afzonderlijk berekenen voor elke stateful service. Uw service heeft mogelijk replica's of partities die niet zijn verdeeld. Houd er rekening mee dat partities mogelijk ook meer gegevens bevatten dan andere. Zie het artikel partitionering over best practices voor meer informatie over partitionering. De voorgaande vergelijking is echter partitie- en replicaagnostisch, omdat Service Fabric ervoor zorgt dat de replica's op een geoptimaliseerde manier over de knooppunten worden verdeeld.

Een spreadsheet gebruiken voor kostenberekening

Nu gaan we enkele reële getallen in de formule plaatsen. Een voorbeeld van een spreadsheet laat zien hoe u de capaciteit kunt plannen voor een toepassing die drie typen gegevensobjecten bevat. Voor elk object geven we een schatting van de grootte en het aantal objecten dat we verwachten te hebben. We selecteren ook het gewenste aantal replica's van elk objecttype. Het werkblad berekent de totale hoeveelheid geheugen die in het cluster moet worden opgeslagen.

Vervolgens voeren we een VM-grootte en maandelijkse kosten in. Op basis van de VM-grootte geeft de spreadsheet het minimale aantal partities aan dat u moet gebruiken om uw gegevens te splitsen zodat deze fysiek op de knooppunten passen. Mogelijk wilt u een groter aantal partities om tegemoet te komen aan de specifieke reken- en netwerkverkeerbehoeften van uw toepassing. Het spreadsheet toont het aantal partities dat de gebruikersprofielobjecten beheert, is toegenomen van één naar zes.

Op basis van al deze informatie ziet u nu dat u alle gegevens fysiek kunt ophalen met de gewenste partities en replica's op een cluster met 26 knooppunten. Dit cluster is echter dicht ingepakt, dus mogelijk wilt u enkele extra knooppunten om knooppuntfouten en upgrades op te vangen. Het werkblad laat ook zien dat het hebben van meer dan 57 knooppunten geen extra waarde biedt omdat u dan lege knooppunten zou hebben. Nogmaals, u kunt toch boven de 57 knooppunten gaan om knooppuntfouten en upgrades op te vangen. U kunt het spreadsheet aanpassen aan de specifieke behoeften van uw toepassing.

Volgende stappen

Bekijk Service Fabric-services partitioneren voor meer informatie over het partitioneren van uw service.