Hvordan beregne ressurser på en terminalserver: En praktisk dimensjoneringsmetode

En terminalserverkalkulator er sjelden en bokstavelig kalkulator. I de fleste SMB- og MSP-miljøer er det en planleggingsmetode som brukes for å estimere hvor mye CPU, RAM, lagring og rom en terminalserver vil trenge før brukerne begynner å klage. Det virkelige spørsmålet bak nøkkelordet er praktisk: hvordan beregner du ressurser på en terminalserver godt nok til å implementere med selvtillit, unngå overspending og redusere risikoen for ytelsesflaskehalser ?

Hva skal en terminalserverkalkulator egentlig beregne?

En nyttig terminalserverkalkulator bør estimere mer enn "brukere per server." Som administrator bør den hjelpe deg med å planlegge for CPU, RAM, lagringsytelse, profil lagring og kapasitetmargin under realistisk samtidig bruk. Microsofts veiledning for Remote Desktop-øktverter rammer inn størrelsen rundt arbeidsbelastningstype og foreslåtte brukere per vCPU, ikke rundt en generell standardforbindelsesgrense.

Hvorfor er ikke bare antall brukere nok til å beregne ressurser på en terminalserver?

Sesjonsbruk

Husk at to miljøer med samme antall brukere kan gi svært forskjellige resultater. Vi antar at du allerede vet hvor mange brukere som vil få tilgang til infrastrukturen din, så det å ha vurderte lisenser og CALs , kan det praktiske arbeidet begynne.

Tenk deg hvordan femten brukere som åpner én forretningsapplikasjon kan legge en beskjeden belastning på en vert. I mellomtiden kan femten brukere som kjører en full fjernskrivebord med nettlesere, Office-applikasjoner, PDF-verktøy, utskrift og bakgrunnssynkronisering skape et mye tyngre fotavtrykk. Størrelsesmodeller reflekterer den forskjellen ved å skille mellom lette, middels og tunge flersesjons arbeidsbelastninger.

Skille er viktig fordi "30 brukere" ikke er et kapasitetsmål i seg selv. Det er kun meningsfullt når du definerer hva disse brukerne gjør og bruker i høysesonger.

Serverbruk

Husk også en viktig distinksjon som betyr enormt mye: for laboratorier eller et lite kontor kan du planlegge en enkelt server, ettersom den vil kjøre færre samtidige brukersesjoner, mens du for produksjon sannsynligvis vil planlegge en farm. Faktisk er separate roller nødvendige for å forbedre ytelsen, forenkle feilsøking og låse sikkerheten, så en vanlig oppdeling ville være:

• 1 server for Broker, Web og Lisensiering
• 1 eller flere servere for Session Host
• 1 RD Gateway på sin egen server for ekstern tilgang.

For å gå et skritt videre, vil du også oppdage at type server, minne osv. vil spille inn, og du kan ønske å inkluder SSD i større oppsett for eksempel. Likevel, dette er bare en omtale for å gjøre deg oppmerksom på mulighetene.

Hvilke fire innganger former ressursplanlegging?

Neste, mer pålitelig enn å hoppe rett til maskinvare tall, her er fire innspill å samle før du begynner å telle. Dette upstream arbeidet unngår overlapp med lisensieringsspørsmål om hvem som kan koble til og under hvilke Microsoft-regler. Den sentrale bekymringen her er hvor mye ressurser en sesjonsvert trenger for å forbli responsiv. Vår forrige artikkel dekket lisensiering og serverkapasitet så vi kan utvikle her praktikalitetene ved å telle alt metodisk for å planlegge riktig.

Derfor må du summere opp:

Samtidige aktive brukere

Vi må fortsatt inkludere dette essensielle tallet siden antallet økter som kjøres parallelt definitivt vil påvirke serverytelsen. Merk at det samtidige antallet kan være uavhengig av det totale antallet.

Arbeidsbelastningsklasse per brukergruppe

Å vurdere hvor mye én bruker eller en gruppe brukere vil bruke ressurser er den første virkelighetssjekken. Bestemte grupper eller enkeltpersoner vil uunngåelig bruke mer av oppgavene de utfører. Derfor må de tunge brukerne identifiseres.

Applikasjon og sesjonstype

Det er også veldig nyttig å identifisere spesifikke applikasjoner, siden visse brukere vil monopolere store mengder ressurser avhengig av hvilke de kjører.

Topp, vekst og failover-margin

Rund av denne inndatlisten ved å ta hensyn til maksimal bruk, og la rom for forventet kortsiktig vekst og bygge inn en fail-over buffermargin.

Hvordan beregner du ressurser på terminalservere?

Her er en praktisk beregningsmetode vi håper vil være nyttig i SMB-administrasjon så vel som i andre sammenhenger. Den har som mål å i det minste forenkle planlegging og strukturere oppkjøringen. Deretter bør den senere kunne brukes til å finjustere, slik at du kan stole på den i pilotperioden og videre.

Trinn 1: Tell samtidige brukere, ikke totale brukere

Start med antallet brukere som er aktive samtidig. Dette er tallet som driver serverbelastningen. En bedrift med 50 navngitte brukere kan ha bare 18 til 25 tilkoblet samtidig i rushtiden. Når man dimensjonerer en sesjonsvert, er antallet samtidige sesjoner langt mer nyttig enn det totale antallet brukere.

Før testing av bærekraftig kapasitet i virkelige situasjoner under belastning, må planleggingen utfordre estimatene.

Trinn 2: Klassifiser arbeidsmengder som lette, middels eller tunge

Neste, sorter gruppebrukere etter arbeidsbelastning. Microsofts nåværende sesjonsvert veiledning foreslår følgende grunnlinjedensitetsområder for flersesjonsmiljøer, og HP og andre kilder er enige:

• opptil 6 lette brukere per vCPU,
• 4 middels brukere per vCPU og
• 2 tunge brukere per vCPU,

med henholdsvis et 8 vCPU, 16 GB RAM, 32 GB lagring minimum VM-eksempel på tvers av disse arbeidsbelastningsbåndene. Anbefalingene inkluderer også å holde størrelsene på multi-session VM-er omtrent mellom 4 og 24 vCPUs for bedre kapasitetsavkastning.

En enkel arbeidsbelastningskart for SMB-planlegging ville dermed veilede sorteringen:

• Lys: én forretningsapp, begrenset nettleserbruk, korte økter
• Medium: Kontorapper, nettleserfaner, PDF-verktøy, moderat multitasking
• Tung: ERP, større Excel-filer, konstant bruk av nettleser, utskrift, flere apper åpne hele dagen

Dette er grunnleggende planleggingsbånd, ikke garantier. Formålet er å velge et startpunkt basert på arbeidsbelastningsatferd.

Trinn 3: Estimer CPU-kapasitet

Når brukere er gruppert, estimer CPU med en tilnærming med brukere per vCPU. For eksempel, hvis 24 samtidige brukere for det meste er middels brukere, antyder Microsofts basislinje på omtrent 4 brukere per vCPU å starte rundt 6 vCPUs, og deretter runde opp til en praktisk vertsstørrelse med plass til spurt. Hvis du ønsker å gi bedre spurtkapasitet under kortvarige spiker i CPU-behov, planlegg lavere bruker-per-kjerne-forhold enn du ellers ville gjort.

Som det kanskje har blitt åpenbart, bør CPU-størrelse ikke stoppe ved det matematiske minimum. Den bør ta hensyn til påloggingsutbrudd, antivirusaktivitet, rapporteringsoppgaver og korte perioder med samtidige applikasjonslanseringer.

Trinn 4: Estimer RAM-krav

RAM bør dekke behovene til operativsystemet, kjernefunksjoner, sesjonsoverhead og applikasjonsminnebruk per bruker. Som beskrevet ovenfor, parret den nåværende Microsoft multi-sesjons baseline sine lette, middels og tunge arbeidsbelastningseksempler med et minimum på 16 GB RAM for et 8 vCPU utgangspunkt. Selv om dette bare er en baseline, gir det likevel et håndgripelig utgangspunkt for estimering.

En praktisk metode i en liten eller mellomstor bedrift er å:

1. reservere minne for OS og plattformtjenester,
2. estimat per økt minne etter brukerklasse,
3. multipliser med samtidige økter,
4. da legge til en sikkerhetsmargin.

PeteNetLive gir en bevisst bred tommelfingerregel av 2 til 8 GB per bruker for RAM-planlegging av RD Session Host. Dette er nyttig som en advarsel mot å undervurdere tunge økter, selv om det nøyaktige tallet må finjusteres i testing.

Trinn 5: Sjekk lagring og profiloverhead

Lagring undervurderes ofte i planleggingen av terminalservere. Langsom, tilstoppet lagring kan skade pålogginger, profilinnlasting, midlertidige filer, applikasjonslanseringer og utskriftskø selv når CPU og RAM fortsatt ser akseptable ut.

• profil lagring
• OS-lagring
• logger: for sikkerhet og andre slike formål

Denne siste kategorien er vel verdt å estimere, da den raskt kan vokse avhengig av størrelsen på infrastrukturen din og typen overvåking og beskyttelse du trenger.

PeteNetLive sin rolle-for-rolle presentasjon fungerer som en nyttig påminnelse om at sesjonsverten vanligvis er der ressurspresset først oppstår, mens andre RDS-roller ofte har relativt mindre fotavtrykk. Ha dette i bakhodet når du ser etter markører for selskapets bruks kapasitet, da det kan komme til støtte for vurdering av planer.

Trinn 6: Legg til rom for topper, vekst og failover

Ingen terminalserverkalkulator bør ende med "akkurat nok" antall. Legg til sikkerhetsmargin for:

• morgeninnloggingsspikes
• oppdatering og AV-skanninger
• månedlige rapporteringstopper
• forventet brukervekst
• vertfeil i et fler-serverdesign

Avslutningsvis, noen gode driftsråd for ethvert miljø som går utover en enkelt vert, er å ta med ekstra verter i tilfelle tap av server eller hypervisor.

Enkel terminalserver kalkulatormetode for SMB-er og MSP-er

Denne kalkulatorlogikken er bevisst enkel. Den er ment å gi et forsvarlig første estimat, ikke en endelig referanse, og for deg å tilpasse den deretter.

En rask planleggingsformel

Bruk denne sekvensen:

1. Antall samtidige brukere .
2. Sorter dem inn i lys, middels og tung grupper.
3. Estimere CPU ved å bruke et grunnlinje-forhold mellom brukere per vCPU.
4. Estimere RAM fra OS-overhead pluss per-økt etterspørsel.
5. Sjekk lagring for profil, midlertidig og oppstart ytelse.
6. Legg til 20 til 30 prosent spillerom , deretter gjennomgå behovene for failover.

Dette speiler essensen av hvordan størrelsesvurdering rammes inn generelt: arbeidsmengde først, forhold deretter, finjustering etter observasjon. Og nå, hvorfor ikke få en sniktitt på hvilken form det kan ta , få et presist estimat og kartlegge din potensielle infrastruktur? Et nøkkelverktøy når du planlegger budsjettet ditt.

Eksempel 1: 15 lys kontorbrukere

Anta at 15 samtidige brukere får tilgang til en publisert forretningsapp pluss lett nettleserbruk.

Ved å bruke anbefalte lette basislinjer, er det rå CPU-estimatet omtrent 3 vCPUs. I praksis er det for stramt for burstkapasitet, så en planlegger ville gå opp til en mer praktisk vertprofil i stedet for å bygge til kanten. Du vil finne at råd favoriserer et bredere størrelsesområde på 4 til 24 vCPU med 8 vCPU, 16 GB RAM som en standard basislinjeprofil for flersesjonsarbeidsmengder.

For RAM, reserver kapasitet for OS og tjenester, og legg deretter til sesjonsminne for hver bruker. Hvis miljøet er stabilt og applikasjonsbruken er smal, kan dette passe komfortabelt på en beskjeden vert, men det bør fortsatt valideres under pilotbruk.

Eksempel 2: 30 blandede kontor- og ERP-brukere

Anta:

• 18 mellomstore brukere
• 12 tunge brukere

En planleggingsgenvei ville behandle den middels gruppen med omtrent 4 brukere per vCPU og den tunge gruppen med omtrent 2 brukere per vCPU. Det innebærer omtrent 4,5 vCPUs for den middels gruppen og 6 vCPUs for den tunge gruppen, før overhead og sikkerhetsmargin. I praksis peker det allerede bort fra en enkelt lett dimensjonert vert og mot enten en større vert med margin eller en deling over flere sesjonsverter.

Dette er hvor rådet "planlegg for serverressurser" blir meningsfullt. Med en ERP akkurat som i enhver bedriftskontekst, er målet ikke bare å plassere brukere et sted. Målet er ikke bare å plassere brukere et sted. Målet er å holde responstider akseptable i de travleste delene av dagen.

Eksempel 3: Når man skal dele brukere over flere verter

Når beregningen gir en tett vert med begrenset burstkapasitet, kan det bedre svaret være arkitektonisk snarere enn vertikal skalering. Økt vertskap kan settes til å gjøre det tunge arbeidet, mens roller som RD Connection Broker, Gateway og Lisensiering kan få forskjellige ressursprofiler. Å dele brukerbelastningen over flere verter vil sannsynligvis forbedre motstandskraft, vedlikeholdsfleksibilitet og failoverplanlegging.

For MSP-er er dette ofte vendepunktet der en terminalserverkalkulator blir en diskusjon om gårdsstørrelse i stedet for en diskusjon om en enkelt server.

Hvilke vanlige størrelsesfeil bryter vanligvis ytelsen til Terminal Server?

Størrelsesfeil skyldes vanligvis ikke bare matematikk. De kommer fra feil antakelser.

Forvirrende lisensiering med ytelsesevne

Lisensiering forteller deg hvordan tilgang tildeles og konfigureres. Det forteller deg ikke hvor mange samtidige brukere en server vil støtte med akseptabel ytelse.

Ignorerer nettleser- og utskriftstunge økter

Mange miljøer undervurderer fortsatt hvor mye belastning moderne nettleserbruk, PDF-håndtering og utskrift kan tilføre en sesjonsvert. Disse aktivitetene kan flytte en brukergruppe fra lett til middels, eller fra middels til tung, selv når forretningsapplikasjonen i seg selv er beskjeden.

Størrelse kun for gjennomsnittlig belastning

Gjennomsnittlig belastning er sjelden det øyeblikket brukerne klager. Klager skjer under påloggingsstormer, samtidige filåpninger, rapportkjøringer eller morgenpeak. Microsoft bemerker at bedre burstkapasitet er viktig ved lavere bruker-per-kjerne-forhold fordi det støtter å gi rom i stedet for å sikte mot maksimal tetthet.

Glemme resten av RDS-stakken

Sesjonsverten er den viktigste ressursforbrukeren, men det er ikke den eneste rollen i miljøet. PeteNetLives rollefordeling er en nyttig påminnelse om å ta hensyn til Connection Broker, Gateway, Web Access og lisensiering separat når distribusjonen vokser utover en liten enkeltvert-oppsett.

Hvorfor bør overvåking validere dine størrelsesestimater?

En terminalserverkalkulator gir deg en planleggingsbaseline. Den gir deg ikke bevis. For bevis må du overvåke bruken.

Fra grunnlinje til bevis: overvåking som en nødvendighet

I vår tidligere artikkel forklarer vi hvorfor bærekraftig brukerkapasitet er et praktisk overvåkingsspørsmål. Her har målet vært å vise hvordan man kan estimere den første versjonen av den kapasiteten før utrulling. Overvåkingen vil skaffe deg mange av de tellingene vi har nevnt. Vi anbefaler at du tester i en laboratoriekontekst for å evaluere dine planlagte behov.

Hvor gjør TSplus Server Monitoring en forskjell?

TSplus Server Monitoring passer etter at størrelsesestimatet er implementert. Det hjelper med å verifisere om CPU-mettning, minnepress, lagringsflaskehalser eller bruksøkninger samsvarer med antagelsene som ble brukt i planleggingen. Dette er spesielt nyttig for SMB IT-administratorer og MSP-er som trenger bevis før de endrer størrelsen på en vert, omfordeler brukere eller legger til en annen server.

Utover å vite hvordan man skal projisere ressurser, hvordan kan du ellers vite om beregningen var riktig enn gjennom overvåkingssystemer? Server Monitoring gir deg sanntidsovervåking og varsler for å holde deg informert når markører når dine satte terskler. .

TSplus programvare for sikker og vedvarende levering av apper og skrivebord

TSplus Remote Access fungerer som leveringslaget i den bredere historien, mens Advanced Security er skreddersydd for å beskytte applikasjonsservere. I tillegg gir TSplus Remote Support et sett med nødvendigheter for feilsøking og vedlikehold av disse serverne og mer fra hvilken som helst plassering. Når miljøet er riktig dimensjonert, vil TSplus Remote Access publisere skrivebord og applikasjoner enklere enn Citrix og uten å overskride budsjettet ditt. Testing av funksjoner som webtilgang og sentralisert levering vil gi deg en smakebit på hvordan du kan gå utover ad hoc RDP-tilgang.

Konklusjon

En terminalserverkalkulator bør ikke love et magisk svar. Nå er det på tide å beregne terminalserverressurser i trinn: start med samtidige brukere, klassifiser arbeidsbelastningens intensitet, estimer CPU og RAM ut fra realistisk sesjonsatferd, sjekk lagring og legg deretter til margin for topper, vekst og failover.

Som systemadministrator, SMB IT-administratorer eller MSP, vil dette gi deg et praktisk første estimat. Derfra er den virkelige disiplinen validering. Planlegg nøye, distribuer konservativt og bruk deretter overvåkingsdata for å bekrefte om verten, eller vertsgård kan opprettholde brukeropplevelsen du har til hensikt.