Overwegingen voor capaciteitsplanning
Basiscapaciteitsplanning begint met enkele eenvoudige berekeningen, maar er zijn factoren die het proces kunnen bemoeilijken. Naast eenvoudige huidige en voorspelde gebruiksnummers moet u ook rekening houden met de volgende overwegingen:
- Servicelimieten en quotums
- Kostenbeperkingen
- Inefficiëntie van code en configuratie
- Afhankelijkheden
In deze les bekijkt u hoe deze overwegingen van invloed kunnen zijn op uw capaciteitsplanning en hoe u deze allemaal kunt aanpakken.
Servicelimieten en quota
Er is een tendens om cloud-computing te zien als een onbeperkte resource. In vergelijking met traditionele server-/datacentermodellen lijkt de capaciteit van de cloud oneindig te zijn. De cloud biedt een geheel nieuw schaalniveau. Net als alles heeft het echter wel enkele beperkingen. Capaciteitsplanning houdt in dat u begrijpt wanneer u deze servicelimieten bereikt.
Wanneer u uw systeem en de architectuur bekijkt, moet u inzicht hebben in de limieten voor de cloudservices die u gebruikt. Standaard kunt u bijvoorbeeld maximaal 200 VM's per VM-beschikbaarheidsset in Azure hebben. Deze limiet lijkt misschien meer dan voldoende VM's als u net begint. Wanneer u deze limiet bereikt, kunt u echter geen vm's meer inrichten, wat mogelijk tot een storing kan leiden.
Op dezelfde manier kunt u standaard 250 opslagaccounts per abonnement per regio hebben. Deze limieten zijn beide voorbeelden van zachte limieten die kunnen worden verhoogd. Maar sommige services hebben maximale limieten, die u kunt vinden via de volgende koppeling.
azure-abonnements- en servicelimieten, quota en beperkingen
Deze limieten en quota zijn iets om rekening mee te houden en te controleren. Laten we eens kijken naar manieren om dat te doen.
Azure Portal
U kunt de servicequota zien en waar u zich bevindt ten opzichte van deze limieten in de sectie Gebruik en quota onder Abonnementen -> Instellingen in het navigatiedeelvenster. U kunt filteren op servicecategorie, zoals netwerk/berekening en Azure-regio. U ziet waar u zich ten opzichte van de limieten bevindt.
Middels een code
U kunt het Usage - List-eindpunt voor elke Azure-service gebruiken om de huidige resourcegebruiksgegevens en de limieten voor rekenresources onder het abonnement op te halen, zoals wordt weergegeven in dit afgekapte voorbeeld.
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2023-03-01
{
"currentValue": 124,
"/subscriptions/{subscriptionId}/providers/Microsoft.Network/locations/westeurope/usages/VirtualNetworks",
"limit": 1000,
"name": {
"localizedValue": "Virtual Networks",
"value": "VirtualNetworks"
},
"unit": "Count"
}
U kunt zien dat het huidige aantal gebruikte virtuele Azure-netwerken (VNets) 124 is tegen een limiet van 1000. Voor het verhogen van een limiet is een ondersteuningsaanvraag vereist, dus zorg ervoor dat u van tevoren weet wanneer u de drempelwaarde nadert.
Kostenbeperkingen
Schalen gaat niet alleen over het inzetten van meer middelen op het probleem. Het is belangrijk voor uw organisatie om inzicht te krijgen in de kosten van uw cloudomgeving en dat het toevoegen van meer resources over het algemeen gelijk is aan meer kosten. Houd rekening met deze kosten en werk samen met uw financiële teams om ervoor te zorgen dat u akkoord gaat met de huidige en verwachte clouduitgaven.
U moet kosten voorspellen voor zowel bij het ontwerpen van de systemen als bij het uitvoeren van regelmatige beoordelingen van uw reeds actieve systemen. Azure biedt hulpprogramma's waarmee u het volgende kunt doen:
- Plan de kosten van een omgeving met behulp van de Azure-calculator.
- Bekijk de huidige en verwachte maandelijkse uitgaven in Azure Portal.
- Budgetten instellen in Microsoft Cost Management. Met dit hulpprogramma kunt u uw kosten op verschillende niveaus analyseren, waaronder beheergroep, resourcegroep en abonnement.
Inefficiëntie van code en configuratie
Soms kan het omsturen van meer resources een probleem oplossen, maar dat kost geld. Soms is schalen niet de oplossing of niet de volledige oplossing. In sommige gevallen kan het zijn dat wat lijkt te moeten worden geschaald, eigenlijk een probleem is dat wordt veroorzaakt door slechte codering of configuratie.
U kunt mogelijk geld en tijd besparen door eerst de bugs te vinden, voordat u resources uitschaalt. Enkele voorbeelden van deze aanpak zijn:
- Als u een slecht ontworpen database met dynamische partities hebt, zoals het gebruik van slechts één partitie in een enorme NoSQL-database, is het traag, ongeacht hoeveel u schaalt.
- Als u inefficiënte databasequery's hebt, zorgt u ervoor dat ze beter presteren voordat u meer resources in de database genereert. Soms kan het toevoegen van de juiste index aan een database op basis van algemene query's uw kosten 100x verlagen.
- Als uw time-outs onjuist zijn ingesteld, kunnen uw databaseverbindingen overbelast raken vanwege nieuwe pogingen van inconsistente time-outs tussen server en database. In dat geval moet u de instellingen herstellen voordat u de database schaalt.
- Als de code van de ontwikkelaar inefficiënt is, kunt u efficiëntere code schrijven om het probleem op te lossen? Misschien heeft de code geen geheugen vrij wanneer dat mogelijk is, zodat u grotere geheugen-VM's hebt gebruikt wanneer dat niet nodig is. Oplossingen zoals die kunnen aanzienlijke kostenbesparingen bieden.
Afhankelijkheden
De wijzigingen die nodig zijn om een aantal problemen op te lossen die in deze module worden beschreven, hebben vaak afhankelijkheden van de ontwikkelaars van uw toepassing. Voor sommige van de oplossingen en aanbevolen procedures die hier worden aanbevolen, is samenwerking tussen u en die ontwikkelaars vereist om dit mogelijk te maken.
Mogelijk kunt u niet al deze aanbevelingen volledig zelf implementeren. Als u echter inzicht hebt in het cloudsysteem en de mogelijkheden en kenmerken ervan, kunt u een stuurprogramma worden voor verandering in het verbeteren van uw systemen en hun schaalbaarheid en betrouwbaarheid.