Hoe middelen op een Terminal Server te berekenen: een praktische maatstaf voor sizing

Een terminalservercalculator is zelden een letterlijke calculator. In de meeste SMB- en MSP-omgevingen is het een planningsmethode die wordt gebruikt om te schatten hoeveel CPU, RAM, opslag en speling een terminalserver nodig heeft voordat gebruikers beginnen te klagen. De echte vraag achter het trefwoord is praktisch: hoe bereken je de middelen op een terminalserver goed genoeg om met vertrouwen uit te rollen, overspending te vermijden en het risico op prestatieknelpunten verminderen ?

Wat zou een terminalservercalculator eigenlijk moeten berekenen?

Een nuttige terminalservercalculator zou meer moeten schatten dan "gebruikers per server." Als beheerder zou het je moeten helpen bij het plannen van CPU, RAM, opslagprestaties, profielopslag en capaciteitsmarge onder realistische gelijktijdige gebruiksomstandigheden. De richtlijnen van Microsoft voor Remote Desktop-sessiehosts kaderen de sizing rond het type werklast en voorgestelde gebruikers per vCPU, niet rond een generieke limiet voor verbindingen die voor iedereen geschikt is.

Waarom is het aantal gebruikers alleen niet genoeg om de middelen op een terminalserver te berekenen?

Sessiegebruik

Houd er rekening mee dat twee omgevingen met hetzelfde aantal gebruikers zeer verschillende resultaten kunnen opleveren. We gaan ervan uit dat u al weet hoeveel gebruikers toegang zullen hebben tot uw infrastructuur, dus het hebben van overwogen licenties en CALs , het praktische werk kan beginnen.

Stel je voor hoe vijftien gebruikers die één zakelijke applicatie openen een bescheiden belasting op een host kunnen plaatsen. Ondertussen kunnen vijftien gebruikers die een volledige remote desktop met browsers, Office-toepassingen, PDF-tools, afdrukken en achtergrond-synchronisatie draaien een veel zwaardere belasting creëren. Sizingmodellen weerspiegelen dat verschil door lichte, gemiddelde en zware multi-sessie werkbelastingen te scheiden.

De onderscheiding is belangrijk omdat "30 gebruikers" op zichzelf geen capaciteitsgetal is. Het is pas betekenisvol zodra je het definieert. wat die gebruikers doen en gebruiken tijdens piekperiodes.

Servergebruik

Vergeet ook een belangrijke onderscheiding niet die enorm van belang is: voor laboratoria of een klein kantoor kun je misschien een enkele server plannen, aangezien deze minder gelijktijdige gebruikerssessies zal draaien, terwijl je voor productie waarschijnlijk een farm zult plannen. Inderdaad, aparte rollen zijn nodig om de prestaties te verbeteren, het oplossen van problemen te vereenvoudigen en de beveiliging te vergrendelen, dus een gebruikelijke splitsing zou zijn:

• 1 server voor Broker, Web en Licensing
• 1 of meer servers voor Session Host
• 1 RD Gateway op zijn eigen server voor externe toegang.

Om een stap verder te gaan, zult u ook dat type server, geheugen, enz. tegenkomen en u wilt misschien SSD opnemen in grotere opstellingen bijvoorbeeld. Toch is dit slechts een vermelding om u bewust te maken van de mogelijkheden.

Welke vier invoeren vormen de resourceplanning?

Volgende, betrouwbaarder dan direct hardwarecijfers te bekijken, zijn hier vier invoerpunten om te verzamelen voordat je begint met tellen. Dit upstream werk voorkomt overlap met licentievraagstukken over wie mag verbinden en onder welke Microsoft-regels. De centrale zorg hier is hoeveel middelen een sessiehost nodig heeft om responsief te blijven. Ons vorige artikel behandelde licenties en servercapaciteit zodat we hier de praktische aspecten van het methodisch tellen van alles kunnen ontwikkelen om goed te plannen.

Daarom moet je optellen:

Gelijktijdige actieve gebruikers

We moeten dit essentiële nummer nog steeds opnemen, aangezien het aantal sessies dat parallel wordt uitgevoerd zeker invloed zal hebben op de serverprestaties. Let op dat de gelijktijdige telling onafhankelijk kan zijn van de totale telling.

Werkbelastingklasse per gebruikersgroep

Het beoordelen van hoeveel één gebruiker of een groep gebruikers gebruik zal maken van middelen is de eerste realiteitscontrole. Bepaalde groepen of individuen zullen onvermijdelijk meer verbruiken naarmate ze de taken uitvoeren. Daarom moeten de zware gebruikers worden geïdentificeerd.

Toepassing en sessietype

Het is ook zeer nuttig om specifieke applicaties te pinpointen, aangezien bepaalde gebruikers grote hoeveelheden middelen zullen monopolizeren, afhankelijk van welke zij draaien.

Piek-, groeien- en fail-overmarge

Rond deze invoerlijst af door rekening te houden met het maximale gebruik, ruimte te laten voor verwachte kortetermijngroei en een fail-over buffer marge in te bouwen.

Hoe bereken je middelen op terminalservers?

Hier is een praktische rekenmethode waarvan we hopen dat deze nuttig zal zijn in het beheer van MKB's en andere contexten. Het is bedoeld om ten minste de planning te vereenvoudigen en de opbouw te structureren. Daarna zou het zich moeten lenen voor verfijning, zodat je erop kunt rekenen tijdens de pilotperiode en daarna.

Stap 1: Tel gelijktijdige gebruikers, niet totale gebruikers

Begin met het aantal gebruikers dat tegelijkertijd actief is. Dit is het aantal dat de serverbelasting aandrijft. Een bedrijf met 50 benoemde gebruikers heeft mogelijk slechts 18 tot 25 gelijktijdig verbonden tijdens piekuren. Bij het dimensioneren van een sessiehost is het aantal gelijktijdige sessies veel nuttiger dan het totale aantal gebruikers.

Voordat de duurzame capaciteit in de echte wereld onder belasting wordt getest, moet de planning de schattingen uitdagen.

Stap 2: Classificeer workloads als licht, gemiddeld of zwaar

Vervolgens de groepsgebruikers sorteren op werklast. Microsofts huidige sessie-host begeleiding suggereert de volgende basisdichtheidsbereiken voor multi-sessie omgevingen en HP en andere bronnen zijn het daarmee eens:

• tot 6 lichte gebruikers per vCPU,
• 4 gemiddelde gebruikers per vCPU en
• 2 zware gebruikers per vCPU,

met respectievelijk een 8 vCPU, 16 GB RAM, 32 GB opslag minimum VM voorbeeld binnen die werklastbanden. Aanbevelingen omvatten ook het handhaven van multi-sessie VM-groottes tussen de 4 en 24 vCPU's voor betere capaciteitsrendementen.

Een eenvoudige werklastkaart voor SMB-planning zou dus het sorteren begeleiden:

• Licht: één zakelijke app, beperkt browsergebruik, korte sessies
• Medium: Office-apps, browsertabs, PDF-tools, gematigd multitasking
• Zwaar: ERP, grotere Excel-bestanden, constant browsergebruik, afdrukken, meerdere apps de hele dag open

Dit zijn basisplanningsbanden, geen garanties. Het doel is om een startpunt te kiezen dat is gebaseerd op het gedrag van de werklast.

Stap 3: Schat de CPU-capaciteit

Zodra gebruikers zijn gegroepeerd, schat de CPU met een gebruikers-per-vCPU benadering. Als bijvoorbeeld 24 gelijktijdige gebruikers voornamelijk gemiddelde gebruikers zijn, suggereert de basislijn van Microsoft van ongeveer 4 gebruikers per vCPU te beginnen met ongeveer 6 vCPU's, en vervolgens naar een praktische hostgrootte met burstruimte te ronden. Als u een betere burstcapaciteit wilt bieden tijdens kortdurende pieken in de CPU-vraag, plan dan lagere gebruikers-per-core verhoudingen dan u anders zou doen.

Zoals misschien duidelijk is geworden, zou CPU-sizing niet moeten stoppen bij het wiskundige minimum. Het moet rekening houden met inlogpieken, antivirusactiviteit, rapportagejobs en korte periodes van gelijktijdige applicatielanceringen.

Stap 4: Schat de RAM-vereisten

RAM moet voldoen aan de behoeften van het besturingssysteem, kernservices, sessie-overhead en het geheugenverbruik van applicaties per gebruiker. Zoals hierboven beschreven, koppelde de huidige Microsoft multi-sessie basislijn zijn lichte, gemiddelde en zware werklastvoorbeelden aan een minimum van 16 GB RAM voor een startpunt van 8 vCPU. Hoewel dit slechts een basislijn is, biedt het desondanks een tastbaar startpunt voor schatting.

Een praktische methode in een klein of middelgroot bedrijf is om:

1. reserveer geheugen voor het besturingssysteem en platformdiensten,
2. schatting per-sessie geheugen per gebruikersklasse,
3. vermenigvuldig met gelijktijdige sessies,
4. dan een veiligheidsmarge toevoegen.

PeteNetLive geeft een opzettelijk brede vuistregel van 2 tot 8 GB per gebruiker voor RD Session Host RAM-planning. Dit is nuttig als waarschuwing tegen het onderschatten van zware sessies, ook al moet het exacte aantal in tests worden verfijnd.

Stap 5: Controleer opslag en profiel overhead

Opslag wordt vaak onderschat bij de planning van terminalservers. Langzame, verstopte opslag kan inloggen, profiel laden, tijdelijke bestanden, applicatielanceringen en printspooling schaden, zelfs wanneer CPU en RAM er nog acceptabel uitzien.

• profielopslag
• OS-opslag
• logs: voor beveiliging en andere dergelijke doeleinden

Deze laatste categorie is het waard om te schatten, aangezien deze snel kan toenemen afhankelijk van de grootte van uw infrastructuur en het type monitoring en bescherming dat u nodig heeft.

De rol-voor-rol presentatie van PeteNetLive dient als een nuttige herinnering dat de sessiehost meestal de plek is waar de druk op de middelen als eerste verschijnt, terwijl andere RDS-rollen vaak relatief kleinere voetafdrukken hebben. Houd dit in gedachten wanneer je op zoek bent naar indicatoren van de gebruiksdrukcapaciteit van jouw bedrijf, aangezien dit kan helpen bij het inschatten van plannen.

Stap 6: Voeg ruimte toe voor pieken, groei en failover

Geen enkele terminalservercalculator zou moeten eindigen met het "net genoeg" aantal. Voeg speling toe voor:

• ochtend pieken bij inloggen
• patching en AV-scans
• maandelijkse rapportage pieken
• verwachte gebruikersgroei
• hostfout in een multi-serverontwerp

Tot slot, een goed operationeel advies voor elke omgeving die verder gaat dan een enkele host, is om extra hosts in overweging te nemen voor het geval van verlies van een server of hypervisor.

Eenvoudige Terminal Server Calculator Methode voor MKB's en MSP's

Deze rekenmachine-logica is opzettelijk eenvoudig. Het is bedoeld om een verdedigbare eerste schatting te produceren, niet een definitieve benchmark, en voor jou om het dienovereenkomstig aan te passen.

Een snelle planningsformule

Gebruik deze volgorde:

1. Aantal concurrente gebruikers .
2. Sorteer ze in licht, medium en zwaar groepen.
3. Schatting CPU gebruik makend van een basislijn gebruikers-per-vCPU ratio.
4. Schatting RAM van OS-overhead plus per-sessie vraag.
5. Controleer opslag voor profiel-, tijdelijke en lanceringprestaties.
6. Toevoegen 20 tot 30 procent speling , evalueer vervolgens de failoverbehoeften.

Dit weerspiegelt de essentie van hoe sizing in het algemeen wordt gepresenteerd: eerst de werklast, dan de verhoudingen, verfijning na observatie. En nu, waarom niet een sneak preview krijgen van welke vorm het zou kunnen aannemen , verkrijg een nauwkeurige schatting en breng uw potentiële infrastructuur in kaart? Een belangrijk hulpmiddel bij het plannen van uw budget.

Voorbeeld 1: 15 lichte kantoorgebruikers

Neem aan dat 15 gelijktijdige gebruikers toegang hebben tot een gepubliceerde zakelijke app plus licht browsergebruik.

Bij gebruik van aanbevolen lichte basislijnen is de ruwe CPU-schatting ongeveer 3 vCPU's. In de praktijk is dat te krap voor burstcapaciteit, dus zou een planner overstappen naar een praktischer hostprofiel in plaats van tot het uiterste te bouwen. U zult merken dat het advies een breder bereik van 4 tot 24 vCPU's aanbeveelt, met 8 vCPU's en 16 GB RAM als een standaard basisprofiel voor multi-sessie workloads.

Voor RAM, reserveer capaciteit voor het besturingssysteem en de services, en voeg vervolgens sessiememory voor elke gebruiker toe. Als de omgeving stabiel is en het gebruik van de applicatie beperkt is, kan dit comfortabel passen op een bescheiden host, maar het moet nog steeds gevalideerd worden tijdens het proefgebruik.

Voorbeeld 2: 30 gemengde kantoor- en ERP-gebruikers

Neem aan:

• 18 middelgrote gebruikers
• 12 zware gebruikers

Een planningssn shortcut zou de mediumgroep behandelen met ongeveer 4 gebruikers per vCPU en de zware groep met ongeveer 2 gebruikers per vCPU. Dat impliceert ongeveer 4,5 vCPU's voor de mediumgroep en 6 vCPU's voor de zware groep, vóór overhead en speling. In de praktijk wijst dat al weg van een enkele lichtgeconfigureerde host en naar ofwel een grotere host met marge of een splitsing over meerdere sessiehosts.

Dit is waar het advies "plan voor serverbronnen" betekenisvol wordt. Met een ERP net als in elke zakelijke context is het doel niet alleen om gebruikers ergens te laten passen. Het doel is niet alleen om gebruikers ergens te plaatsen. Het doel is om de responstijden acceptabel te houden tijdens de drukste momenten van de dag.

Voorbeeld 3: Wanneer gebruikers over meerdere hosts te splitsen

Zodra de berekening een dichte host met beperkte piekcapaciteit oplevert, kan het betere antwoord architectonisch zijn in plaats van verticale schaalvergroting. Sessiehosts kunnen worden ingesteld om het zware werk te doen, terwijl rollen zoals RD Connection Broker, Gateway en Licensing verschillende resourceprofielen kunnen krijgen. Het splitsen van de gebruikersbelasting over meerdere hosts zal waarschijnlijk de veerkracht, onderhoudsflexibiliteit en failoverplanning verbeteren.

Voor MSP's is dit vaak het kantelpunt waar een terminalservercalculator een discussie over het dimensioneren van een farm wordt in plaats van een discussie over een enkele server.

Welke veelvoorkomende maatfouten breken doorgaans de prestaties van de terminalserver?

Sizingfouten worden meestal niet alleen door wiskunde veroorzaakt. Ze komen voort uit onjuiste aannames.

Licenties verwarren met prestatiecapaciteit

Licensing vertelt je hoe toegang wordt toegewezen en geconfigureerd. Het vertelt je niet hoeveel gelijktijdige gebruikers een server met acceptabele prestaties zal ondersteunen.

Negeren van browserzware en printzware sessies

Veel omgevingen onderschatten nog steeds hoeveel belasting het gebruik van moderne browsers, PDF-verwerking en afdrukken kan toevoegen aan een sessiehost. Deze activiteiten kunnen een gebruikersgroep van licht naar gemiddeld verschuiven, of van gemiddeld naar zwaar, zelfs wanneer de bedrijfsapplicatie zelf bescheiden is.

Sizing alleen voor gemiddelde belasting

Gemiddelde belasting is zelden het moment waarop gebruikers klagen. Klachten komen voor tijdens inlogstormen, gelijktijdige bestandsopeningen, rapportage-uitvoeringen of ochtendpieken. Microsoft merkt op dat een betere piekcapaciteit belangrijk is bij lagere gebruikers-per-core verhoudingen omdat het ruimte laat in plaats van te mikken op maximale dichtheid.

Vergeten de rest van de RDS-stack

De sessiehost is de belangrijkste hulpbronverbruiker, maar het is niet de enige rol in de omgeving. De rolverdeling van PeteNetLive is een nuttige herinnering om rekening te houden met Connection Broker, Gateway, Web Access en Licenties afzonderlijk wanneer de implementatie groter wordt dan een kleine opstelling met één host.

Waarom zou monitoring uw maatinschattingen moeten valideren?

Een terminalservercalculator geeft je een planningsbasis. Het geeft je geen bewijs. Voor bewijs moet je het gebruik monitoren.

Van basislijn tot bewijs: monitoring als essentieel

In ons eerdere artikel leggen we uit waarom duurzame gebruikerscapaciteit een praktische monitoringsvraag is. Hier is het doel om te laten zien hoe je de eerste versie van die capaciteit kunt schatten voordat deze wordt uitgerold. Monitoring zal voor jou veel van de tellingen verkrijgen die we hebben genoemd. We raden je aan om in een labcontext te testen om je verwachte behoeften te evalueren.

Waar maakt TSplus Server Monitoring het verschil?

TSplus Server Monitoring past na de implementatie van de schatting van de grootte. Het helpt te verifiëren of CPU-saturatie, geheugendruk, opslagknelpunten of gebruikspieken overeenkomen met de aannames die zijn gebruikt bij de planning. Dit is vooral nuttig voor IT-beheerders van MKB's en MSP's die bewijs nodig hebben voordat ze een host opnieuw dimensioneren, gebruikers herverdelen of een andere server toevoegen.

Naast het weten hoe je middelen moet projecteren, hoe kun je anders weten of de berekening juist was dan door middel van monitoringsystemen? Server Monitoring biedt je real-time monitoring en de meldingen om je op de hoogte te houden wanneer markers je ingestelde drempels bereiken. .

TSplus-software voor veilige en duurzame levering van apps en desktops

TSplus Remote Access behoort als de leveringslaag in het bredere verhaal, terwijl Advanced Security op maat is gemaakt om applicatieservers te beschermen. Daarnaast biedt TSplus Remote Support een kit met essentiële tools voor het oplossen van problemen en het onderhouden van deze servers en meer vanaf elke locatie. Zodra de omgeving correct is afgestemd, zal TSplus Remote Access desktops en applicaties eenvoudiger publiceren dan Citrix en zonder uw budget te overschrijden. Het testen van functies zoals webtoegang en gecentraliseerde levering zal u een idee geven van hoe u verder kunt gaan dan ad-hoc RDP-toegang.

Conclusie

Een terminalservercalculator zou geen magisch antwoord moeten beloven. Nu is het tijd om de terminalserverbronnen in fasen te berekenen: begin met gelijktijdige gebruikers, classificeer de werklastintensiteit, schat CPU en RAM op basis van realistisch sessiegedrag, controleer de opslag en voeg vervolgens een marge toe voor pieken, groei en failover.

Als systeembeheerder, SMB IT-beheerders of MSP, geeft dit je een praktische eerste schatting. Van daaruit is de echte discipline validatie. Plan zorgvuldig, implementeer conservatief en gebruik vervolgens monitorgegevens om te bevestigen of de host, of host farm kan de gebruikerservaring die u voor ogen heeft, ondersteunen.