Hvordan man beregner ressourcer på en terminalserver: En praktisk dimensioneringsmetode

En terminalserverberegner er sjældent en bogstavelig beregner. I de fleste SMB- og MSP-miljøer er det en planlægningsmetode, der bruges til at estimere, hvor meget CPU, RAM, lagerplads og overhead en terminalserver vil have brug for, før brugerne begynder at klage. Det virkelige spørgsmål bag nøgleordet er praktisk: hvordan beregner man ressourcer på en terminalserver godt nok til at implementere med tillid, undgå overspending og reducere risikoen for præstationsflaskehalse ?

Hvad skal en terminalserverberegner egentlig beregne?

En nyttig terminalserverberegner bør estimere mere end "brugere pr. server." Som administrator bør den hjælpe dig med at planlægge for CPU, RAM, lagerydelse, profilopbevaring og kapacitetsmargin under realistisk samtidigt brug. Microsofts vejledning til Remote Desktop-sessionværter rammer størrelsesbestemmelse omkring arbejdsbyttype og foreslåede brugere pr. vCPU, ikke omkring en generisk standardforbindelsesgrænse.

Hvorfor er brugerantallet alene ikke nok til at beregne ressourcer på en terminalserver?

Session brug

Husk, at to miljøer med det samme antal brugere kan producere meget forskellige resultater. Vi antager, at du allerede ved, hvor mange brugere der vil få adgang til din infrastruktur, så det at have overvejede licensering og CALs den praktiske arbejde kan begynde.

Forestil dig, hvordan femten brugere, der åbner en forretningsapplikation, kan lægge en beskeden belastning på en vært. I mellemtiden kan femten brugere, der kører en fuld fjernskrivebord med browsere, Office-applikationer, PDF-værktøjer, udskrivning og baggrundssynkronisering, skabe et meget tungere fodaftryk. Dimensioneringsmodeller afspejler den forskel ved at adskille lette, mellemstore og tunge multi-session arbejdsbelastninger.

Forskellen er vigtig, fordi "30 brugere" ikke er et kapacitetsmål i sig selv. Det er kun meningsfuldt, når du definerer hvad de brugere gør og bruger i spidsbelastningsperioder.

Serverbrug

Husk også en vigtig skelnen, som betyder enormt meget: for laboratorier eller et lille kontor kan du planlægge en enkelt server, da den vil køre færre samtidige brugersessioner, mens du til produktion sandsynligvis vil planlægge en farm. Faktisk er separate roller nødvendige for at forbedre ydeevnen, forenkle fejlfinding og låse sikkerheden, så en almindelig opdeling ville være:

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

For at gå et skridt videre, vil du også finde, at den type server, hukommelse osv. vil komme i spil, og du måske ønsker at inkluder SSD i større opsætninger for eksempel. Alligevel er dette kun en omtale for at gøre dig opmærksom på mulighederne.

Hvilke fire input former ressourceplanlægning?

Næste, mere pålideligt end at springe direkte til hardware-numre, her er fire input, der skal indsamles, før man begynder at tælle. Dette forarbejde undgår overlap med licensspørgsmål om, hvem der må oprette forbindelse, og under hvilke Microsoft-regler. Den centrale bekymring her er, hvor mange ressourcer en sessionsvært har brug for for at forblive responsiv. Vores tidligere artikel dækkede licensering og serverkapacitet så vi kan udvikle her praktikaliteterne ved at tælle alt metodisk for at planlægge rigtigt.

Derfor skal du lægge sammen:

Samtidige aktive brugere

Vi skal stadig inkludere dette essentielle nummer, da antallet af sessioner, der kører parallelt, bestemt vil påvirke serverens ydeevne. Bemærk, at det samtidige antal kan være uafhængigt af det samlede antal.

Arbejdsbyrdeklasse pr. brugergruppe

At vurdere, hvor meget en bruger eller en gruppe af brugere vil trække på ressourcer, er den første realitetskontrol. Visse grupper eller enkeltpersoner vil uundgåeligt bruge mere af de opgaver, de udfører. Derfor er det nødvendigt at identificere de tunge brugere.

Applikation og sessionstype

Det er også meget nyttigt at identificere specifikke applikationer, da visse brugere vil monopolisere store mængder af ressourcer afhængigt af, hvilke de kører.

Top, vækst og fail-over margin

Rund denne inputliste op ved at tage højde for maksimal brug, så der er plads til forventet kortsigtet vækst og indbygge en fail-over buffermargin.

Hvordan beregner man ressourcer på terminalservere?

Her er en praktisk beregningsmetode, som vi håber vil være nyttig i SMB-administration såvel som i andre sammenhænge. Den sigter mod i det mindste at forenkle planlægning og strukturere opstarten. Derefter bør den senere kunne finpudses, så du kan regne med den i pilotperioden og fremad.

Trin 1: Tæl samtidige brugere, ikke totale brugere

Start med antallet af brugere, der er aktive på samme tid. Dette er det antal, der driver serverbelastningen. En virksomhed med 50 navngivne brugere har muligvis kun 18 til 25 tilsluttede samtidig i spidsbelastningsperioder. Når man dimensionerer en sessionsvært, er antallet af samtidige sessioner langt mere nyttigt end det samlede antal brugere.

Før test af bæredygtig kapacitet i den virkelige verden under belastning, skal planlægning udfordre estimaterne.

Trin 2: Klassificer arbejdsbelastninger som lette, mellemstore eller tunge

Næste, sorter gruppebrugere efter arbejdsbyrde. Microsofts aktuel session-vært vejledning foreslår følgende baseline tæthedsområder for multi-session miljøer, og HP og andre kilder er enige:

• op til 6 lette brugere pr. vCPU,
• 4 mellemstore brugere pr. vCPU og
• 2 tunge brugere pr. vCPU,

med henholdsvis et 8 vCPU, 16 GB RAM, 32 GB lager minimum VM eksempel på tværs af disse arbejdsbyrdebånd. Anbefalinger inkluderer også at holde multi-session VM størrelser nogenlunde mellem 4 og 24 vCPUs for bedre kapacitetsafkast.

Et simpelt arbejdsbyrdekort til SMB-planlægning ville således vejlede sorteringen:

• Lys: én forretningsapp, begrænset browserbrug, korte sessioner
• Medium: Office-apps, browsertabs, PDF-værktøjer, moderat multitasking
• Tung: ERP, større Excel-filer, konstant brug af browser, udskrivning, flere apps åbne hele dagen

Disse er baseline planlægningsbånd, ikke garantier. Formålet er at vælge et udgangspunkt baseret på arbejdsbyrdeadfærd.

Trin 3: Estimér CPU-kapacitet

Når brugerne er grupperet, estimer CPU med en tilgang til brugere pr. vCPU. For eksempel, hvis 24 samtidige brugere hovedsageligt er mellembrugere, antyder Microsofts baseline på omkring 4 brugere pr. vCPU at starte omkring 6 vCPUs, og derefter runde op til en praktisk værtstørrelse med burst-headroom. Hvis du ønsker at give bedre burstkapacitet under kortvarige CPU-efterspørgselsstigninger, planlæg lavere bruger-pr. kerne-forhold, end du ellers ville.

Som det måske er blevet åbenlyst, bør CPU-størrelse ikke stoppe ved det matematiske minimum. Den bør tage højde for login-burst, antivirusaktivitet, rapporteringsopgaver og korte perioder med samtidige applikationslanceringer.

Trin 4: Estimér RAM-krav

RAM bør dække behovene for operativsystemet, kerneydelser, sessionsoverhead og applikationshukommelsesforbrug pr. bruger. Som beskrevet ovenfor parrede den nuværende Microsoft multi-session baseline sine lette, mellemstore og tunge arbejdsbyrder med et minimum på 16 GB RAM som udgangspunkt for 8 vCPU. Selvom dette kun er en baseline, giver det alligevel et håndgribeligt udgangspunkt for estimering.

En praktisk metode i en lille eller mellemstor virksomhed er at:

1. reserver hukommelse til OS og platformtjenester,
2. estimat pr. session hukommelse efter brugerklasse,
3. multiplicere med samtidige sessioner,
4. så tilføj en sikkerhedsmargen.

PeteNetLive giver en bevidst bred tommelfingerregel af 2 til 8 GB pr. bruger til RD Session Host RAM planlægning. Dette er nyttigt som en advarsel mod at undervurdere tunge sessioner, selvom det nøjagtige antal skal præciseres i test.

Trin 5: Tjek lager- og profiloverhead

Lagring undervurderes ofte i planlægningen af terminalservere. Langsom, tilstoppet lagring kan skade logins, indlæsning af profiler, temp-filer, applikationsstart og printspooling, selv når CPU og RAM stadig ser acceptable ud.

• profilopbevaring
• OS-lagring
• logs: til sikkerhed og andre sådanne formål

Denne sidste kategori er bestemt værd at estimere, da den hurtigt kan vokse afhængigt af størrelsen på din infrastruktur og den type overvågning og beskyttelse, du har brug for.

PeteNetLive's rolle-for-rolle præsentation fungerer som en nyttig påmindelse om, at session værten normalt er det sted, hvor ressourcepresset først opstår, mens andre RDS-roller ofte har relativt mindre fodaftryk. Hav dette i tankerne, når du leder efter markører for din virksomheds kapacitet til at håndtere belastning, da det kan støtte op om vurderingen af planer.

Trin 6: Tilføj plads til spidser, vækst og failover

Ingen terminalserverberegner bør ende med det "lige nok" antal. Tilføj plads til:

• morgen tilmeldingsspidser
• opdatering og AV-scanninger
• månedlige rapporteringstoppe
• forventet bruger vækst
• hostfejl i et multi-server design

Afslutningsvis er et godt operationelt råd for ethvert miljø, der bevæger sig ud over en enkelt vært, at tage højde for yderligere værter i tilfælde af tab af server eller hypervisor.

Simpel Terminal Server Beregner Metode for SMB'er og MSP'er

Denne kalkulatorlogik er bevidst enkel. Den er beregnet til at producere et forsvarligt første estimat, ikke en endelig benchmark, og til at du kan tilpasse den derefter.

En hurtig planlægningsformel

Brug denne sekvens:

1. Antal samtidige brugere .
2. Sorter dem i lys, medium og tung grupper.
3. Estimere CPU ved at bruge et grundlæggende brugere-pr-vCPU-forhold.
4. Estimere RAM fra OS-overhead plus pr-session efterspørgsel.
5. Tjek opbevaring for profil, temp og lancering ydeevne.
6. Tilføj 20 til 30 procent hovedrum , så gennemgå behovene for failover.

Dette afspejler essensen af, hvordan størrelsesbestemmelse generelt rammes ind: arbejdsbyrde først, forhold dernæst, forfining efter observation. Og nu, hvorfor ikke få et smugkig på hvilken form det kunne tage , få et præcist estimat og kortlægge din potentielle infrastruktur? Et nøgleværktøj når du planlægger dit budget.

Eksempel 1: 15 lette kontorbrugere

Antag 15 samtidige brugere får adgang til en offentliggjort forretningsapp plus let browserbrug.

Ved at bruge anbefalede lette baseline er det rå CPU-estimat omkring 3 vCPUs. I praksis er det for stramt til burstkapacitet, så en planlægger ville vælge en mere praktisk værtprofil i stedet for at bygge til kanten. Du vil finde, at rådgivningen favoriserer et bredere størrelsesinterval på 4 til 24 vCPU'er med 8 vCPU'er og 16 GB RAM som en standard baseline-profil for multi-session arbejdsbelastninger.

For RAM, reserver kapacitet til OS og tjenester, og tilføj derefter sessionshukommelse for hver bruger. Hvis miljøet er stabilt, og app-brugen er begrænset, kan dette passe komfortabelt på en beskeden vært, men det bør stadig valideres under pilotbrug.

Eksempel 2: 30 blandede kontor- og ERP-brugere

Antag:

• 18 mellemstore brugere
• 12 tunge brugere

En planlægningsgenvej ville behandle den mellemstore gruppe med cirka 4 brugere pr. vCPU og den tunge gruppe med cirka 2 brugere pr. vCPU. Det indebærer omkring 4,5 vCPUs for den mellemstore gruppe og 6 vCPUs for den tunge gruppe, før overhead og sikkerhedsmargin. I praksis peger det allerede væk fra en enkelt let størrelse vært og mod enten en større vært med margin eller en opdeling på tværs af flere sessionsværter.

Dette er, hvor rådet "planlæg for serverressourcer" bliver meningsfuldt. Med en ERP lige som i enhver virksomhedssammenhæng er målet ikke kun at placere brugerne et sted. Målet er ikke kun at placere brugerne et sted. Målet er at holde svartiderne acceptable i de travleste dele af dagen.

Eksempel 3: Hvornår man skal opdele brugere på tværs af flere værter

Når beregningen producerer en tæt vært med begrænset burstkapacitet, kan det bedre svar være arkitektonisk snarere end vertikal skalering. Sessionværter kan indstilles til at udføre det tunge løft, mens roller som RD Connection Broker, Gateway og Licensering kan tildeles forskellige ressourceprofiler. At fordele brugerbelastningen på tværs af flere værter vil sandsynligvis forbedre modstandsdygtighed, vedligeholdelsesfleksibilitet og failoverplanlægning.

For MSP'er er dette ofte det afgørende punkt, hvor en terminalserverberegner bliver en diskussion om farmstørrelse i stedet for en diskussion om en enkelt server.

Hvilke almindelige størrelsesfejl bryder typisk terminalserverens ydeevne?

Størrelsesfejl skyldes normalt ikke kun matematik. De stammer fra forkerte antagelser.

Forveksling af licensering med ydeevnekapacitet

Licensering fortæller dig, hvordan adgang tildeles og konfigureres. Det fortæller dig ikke, hvor mange samtidige brugere en server vil understøtte med acceptabel ydeevne.

Ignorerer browser-tunge og print-tunge sessioner

Mange miljøer undervurderer stadig, hvor meget belastning moderne browserbrug, PDF-håndtering og udskrivning kan tilføje til en session vært. Disse aktiviteter kan flytte en brugergruppe fra let til medium, eller fra medium til tung, selv når forretningsapplikationen i sig selv er beskeden.

Kun dimensionering for gennemsnitlig belastning

Gennemsnitlig belastning er sjældent det øjeblik, brugerne klager. Klager opstår under logonstorme, samtidige filåbninger, rapporteringskørsler eller morgen-toppe. Microsoft bemærker, at bedre burstkapacitet er vigtig ved lavere bruger-til-kerne-forhold, fordi det understøtter at efterlade plads i stedet for at sigte mod maksimal tæthed.

Glemme resten af RDS-stakken

Session værten er den primære ressourceforbruger, men det er ikke den eneste rolle i miljøet. PeteNetLive's rolleopdeling er en nyttig påmindelse om at tage højde for Connection Broker, Gateway, Web Access og Licenser separat, når implementeringen vokser ud over en lille enkelt-vært opsætning.

Hvorfor skal overvågning validere dine størrelsesestimater?

En terminalserverberegner giver dig en planlægningsbaseline. Den giver dig ikke bevis. For bevis skal du overvåge brugen.

Fra baseline til bevis: overvågning som en nødvendighed

I vores tidligere artikel forklarer vi, hvorfor bæredygtig brugerkapacitet er et praktisk overvågningsspørgsmål. Her har målet været at vise, hvordan man estimerer den første version af den kapacitet, før den implementeres. Overvågning vil skaffe dig mange af de tællinger, vi har nævnt. Vi anbefaler, at du tester i en laboratoriekontekst for at evaluere dine forventede behov.

Hvor gør TSplus Server Monitoring en forskel?

TSplus Server Monitoring passer efter størrelsesvurderingen er implementeret. Det hjælper med at verificere, om CPU-mætning, hukommelsespres, lagringsflaskehalse eller brugstoppe matcher de antagelser, der blev brugt i planlægningen. Det er især nyttigt for SMB IT-administratorer og MSP'er, der har brug for beviser, før de ændrer størrelsen på en vært, omfordeler brugere eller tilføjer en anden server.

Udover at vide, hvordan man projicerer ressourcer, hvordan kan du ellers vide, om beregningen var korrekt, end gennem overvågningssystemer? Server Monitoring giver dig realtidsovervågning og advarsler for at holde dig informeret, når markører når dine indstillede grænser. .

TSplus software til sikker og vedvarende levering af apps og desktops

TSplus Remote Access fungerer som leveringslag i den bredere historie, mens Advanced Security er skræddersyet til at beskytte applikationsservere. Derudover giver TSplus Remote Support et sæt af essentielle værktøjer til fejlfinding og vedligeholdelse af disse servere og mere fra enhver placering. Når miljøet er korrekt dimensioneret, vil TSplus Remote Access publicere skriveborde og applikationer mere enkelt end Citrix og uden at overskride dit budget. Testfunktioner som webadgang og centraliseret levering vil give dig en forsmag på, hvordan du kan bevæge dig ud over ad hoc RDP-adgang.

Konklusion

En terminalserverberegner bør ikke love et magisk svar. Nu er det tid til at beregne terminalserverressourcer i faser: start med samtidige brugere, klassificer arbejdsbyrdeintensitet, estimér CPU og RAM ud fra realistisk sessionsadfærd, tjek lager og tilføj derefter margin for spidser, vækst og failover.

Som systemadministrator, SMB IT-administratorer eller MSP, vil dette give dig et praktisk første estimat. Derfra er den reelle disciplin validering. Planlæg omhyggeligt, implementer konservativt og brug derefter overvågningsdata til at bekræfte, om værten, eller værtgård kan opretholde den brugeroplevelse, du har til hensigt.