Overvejelser i forbindelse med kapacitetsplanlægning

5 minutter

Grundlæggende kapacitetsplanlægning starter med nogle enkle beregninger, men der er faktorer, der kan komplicere processen. Ud over simple aktuelle og forudsagte brugsnumre skal du også tage højde for følgende overvejelser:

Tjenestegrænser og -kvoter
Omkostningsbegrænsninger
Ineffektivitet i forbindelse med kode og konfiguration
Afhængigheder

I dette undermodul ser du på, hvordan disse overvejelser kan påvirke din kapacitetsplanlægning, og hvordan du håndterer hver af dem.

Tjenestegrænser og -kvoter

Der er en tendens til at se cloudcomputing som en ubegrænset ressource. I forhold til traditionelle server-/datacentermodeller ser cloudkapaciteten ud til at være uendelig. Clouden tilbyder et helt nyt skaleringsniveau. Men som alt andet har det nogle grænser. Kapacitetsplanlægning omfatter forståelse af, hvornår du vil nå disse tjenestegrænser.

Når du ser på dit system og dets arkitektur, skal du forstå grænserne for de cloudtjenester, du bruger. For eksempel kan du som standard have maksimalt 1000 VM'er pr. VM-tilgængelighed sat i Azure. Denne grænse kan virke som mere end nok VM'er, hvis du lige er ved at komme i gang. Men når du når denne grænse, kan du ikke klargøre flere VM'er, hvilket kan resultere i en afbrydelse.

Bemærkning

For nye udrulninger bør du overveje at bruge Tilgængelighedszoner eller Flexible Virtual Machine Scale Sets i stedet for tilgængelighedssæt. Tilgængelighedszoner giver højere robusthed ved at distribuere VM'er over fysisk adskilte datacentre inden for en region.

Ligeledes kan du som standard have 250 lagerkonti pr. abonnement pr. region (denne grænse kan øges via en supportanmodning). Disse grænser er begge eksempler på bløde grænser, der kan øges. Men nogle tjenester har maksimumgrænser, som du kan finde på følgende link.

Azure abonnements- og servicegrænser, kvoter og begrænsninger

Disse grænser og kvoter er noget, man skal være opmærksom på og overvåge. Lad os se på måder at gøre det på.

Azure portal

Du kan se tjenestekvoterne, og hvor du befinder dig i forhold til disse grænser i afsnittet Forbrug + kvoter under Abonnementer –> Indstillinger i navigationsruden. Du kan filtrere på servicekategorier som netværk / compute og Azure-region. Det viser dig, hvor du er imod grænserne.

Skærmbillede af Service Limits-information fundet i Azure-portalen, der viser en tabel over forskellige ressourcer og deres kvoter.

Via kode

Du kan bruge Usage - List-endpointet for enhver Azure service til at få den aktuelle ressourceforbrugsinformation og grænserne for beregningsressourcer under abonnementet, som vist i dette afkortede eksempel. Tjek referencen Azure REST API for den nyeste stabile API-version.

GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/{location}/usages?api-version=2024-07-01
{ 
    "currentValue": 12,
    "id": "/subscriptions/{subscriptionId}/providers/Microsoft.Compute/locations/westeurope/usages/virtualMachines",
    "limit": 25000, 
    "name": { 
        "localizedValue": "Virtual Machines",
        "value": "virtualMachines" 
    }, 
    "unit": "Count" 
}

Du kan se, at det nuværende antal virtuelle maskiner, der bruges, er 12 mod en grænse på 25.000. Nogle grænser kan hæves via en supportanmodning, så sørg for at vide på forhånd, hvornår du kan nærme dig en grænse.

Omkostningsbegrænsninger

Skalering handler ikke kun om at kaste flere ressourcer på problemet. Det er vigtigt for din organisation at forstå omkostningerne ved dit cloudmiljø, og at tilføjelse af flere ressourcer generelt er lig med flere omkostninger. Vær opmærksom på disse omkostninger, og arbejd sammen med dine økonomiteams for at sikre, at du er enig i aktuelle og forventede cloududgifter.

Du bør forudsige omkostningerne, både når du først designer systemerne, og når du udfører regelmæssige gennemgange af dine systemer, der allerede kører. Azure tilbyder værktøjer, der kan hjælpe dig:

Planlæg omkostningerne ved et miljø ved hjælp af Azure beregneren.
Gennemgå nuværende og forventede månedlige udgifter i Azure-portalen.
Opsæt budgetter i Microsoft Cost Management. Med dette værktøj kan du undersøge dine omkostninger på forskellige områder, herunder administrationsgruppe, ressourcegruppe og abonnement.

Ineffektivitet i forbindelse med kode og konfiguration

Nogle gange kan det løse et problem at dirigere flere ressourcer, men det koster penge. Nogle gange er skalering ikke løsningen eller ikke den komplette løsning. I nogle tilfælde kan det være, at det, der ser ud til at være et behov for at skalere, faktisk er et problem, der skyldes dårlig kodning eller konfiguration.

Du kan potentielt spare penge og tid ved at finde fejlene først, før du skalerer ressourcer ud. Nogle eksempler på denne fremgangsmåde omfatter:

Hvis du har en dårligt designet database med varme partitioner, som for eksempel kun bruger én partition på en kæmpe NoSQL-database, er den langsom, uanset hvor meget du skalerer.
Hvis du har ineffektive databaseforespørgsler, kan du gøre dem mere effektive, før du kaster flere ressourcer på databasen. Nogle gange kan hvis du blot føjer det rigtige indeks til en database, der er baseret på almindelige forespørgsler, slippe dine omkostninger 100x.
Hvis timeout er angivet forkert, kan databaseforbindelserne blive mættet pga. nye forsøg fra inkonsekvente timeout mellem server og database. I så fald skal du rette indstillingerne, før du skalerer databasen.
Hvis udviklerens kode er ineffektiv, kan du så skrive mere effektiv kode for at løse problemet? Måske frigør koden ikke hukommelse, når den kan, så du har brugt vm'er med større hukommelse, når det ikke er nødvendigt. Den slags rettelser kan give betydelige omkostningsbesparelser.

Afhængigheder

De ændringer, der er nødvendige for at løse nogle af de problemer, der er beskrevet i dette modul, har ofte afhængigheder af udviklerne af dit program. Nogle af de løsninger og bedste praksisser, der anbefales her, kræver samarbejde mellem dig og disse udviklere for at få det til at ske.

Du kan muligvis ikke implementere alle disse anbefalinger helt af dig selv. Men hvis du forstår cloudsystemet og dets funktioner og egenskaber, kan du blive en faktor til at forbedre dine systemer og deres skalerbarhed og pålidelighed.

Feedback

Var denne side nyttig?

Overvejelser i forbindelse med kapacitetsplanlægning

Tjek din viden

Feedback