Hur man beräknar resurser på en terminalserver: En praktisk storleksmetod

En terminalserverberäknare är sällan en bokstavlig beräknare. I de flesta SMB- och MSP-miljöer är det en planeringsmetod som används för att uppskatta hur mycket CPU, RAM, lagring och utrymme en terminalserver kommer att behöva innan användarna börjar klaga. Den verkliga frågan bakom nyckelordet är praktisk: hur beräknar man resurser på en terminalserver tillräckligt bra för att kunna distribuera med förtroende, undvika överskridande av budgeten och minska risken för prestandaflaskhalsar ?

Vad ska en terminalserverkalkylator egentligen beräkna?

En användbar terminalserverkalkylator bör uppskatta mer än "användare per server." Som administratör bör den hjälpa dig att planera för CPU, RAM, lagringsprestanda, profil lagring och kapacitetsmarginal under realistisk samtidig användning. Microsofts vägledning för Remote Desktop-sessionvärdar ramar in storlek baserat på arbetsbelastningstyp och föreslagna användare per vCPU, inte runt en generell standardanslutningsgräns.

Varför är användarantalet ensamt inte tillräckligt för att beräkna resurser på en terminalserver?

Sessionsanvändning

Tänk på att två miljöer med samma antal användare kan ge mycket olika resultat. Vi antar att du redan vet hur många användare som kommer att få tillgång till din infrastruktur, så att ha betraktade licensiering och CALs , det praktiska arbetet kan börja.

Föreställ dig hur femton användare som öppnar en affärsapplikation kan belasta en värd måttligt. Under tiden kan femton användare som kör en fullständig fjärrskrivbord med webbläsare, Office-applikationer, PDF-verktyg, utskrift och bakgrundssynkronisering skapa ett mycket tyngre avtryck. Dimensioneringsmodeller återspeglar den skillnaden genom att separera lätta, medel och tunga flersessioner arbetsbelastningar.

Skillnaden är viktig eftersom "30 användare" inte är en kapacitetsfigur i sig. Det är endast meningsfullt när du definierar vad dessa användare gör och använder under högsäsong.

Serveranvändning

Kom också ihåg en viktig åtskillnad som spelar en enorm roll: för laboratorier eller ett litet kontor kan du planera en enda server, eftersom den kommer att hantera färre samtidiga användarsessioner, medan du för produktion sannolikt kommer att planera en farm. Faktum är att separata roller behövs för att förbättra prestanda, förenkla felsökning och låsa säkerheten, så en vanlig uppdelning skulle vara:

• 1 server för Broker, Web och Licensiering
• 1 eller flera servrar för Session Host
• 1 RD Gateway på sin egen server för extern åtkomst.

För att gå ett steg längre kommer du också att upptäcka att den typen av server, minne osv. kommer att spela in och du kanske vill inkludera SSD i större installationer till exempel. Ändå är detta bara en nämning för att göra dig medveten om möjligheterna.

Vilka fyra ingångar formar resursplanering?

Nästa, mer pålitligt än att hoppa rakt på hårdvarunummer, här är fyra ingångar att samla in innan du börjar räkna. Detta arbete uppströms undviker överlappning med licensieringsfrågor om vem som kan ansluta och under vilka Microsoft-regler. Den centrala frågan här är hur mycket resurser en sessionsvärd behöver för att förbli responsiv. Vår tidigare artikel täckte licensiering och serverkapacitet så vi kan utveckla här praktikaliteterna för att räkna allt metodiskt för att planera rätt.

Därför behöver du summera:

Samtidiga aktiva användare

Vi behöver fortfarande inkludera detta viktiga nummer eftersom antalet sessioner som körs parallellt definitivt kommer att påverka serverns prestanda. Observera att det samtidiga antalet kan vara oberoende av det totala antalet.

Arbetsbelastningsklass per användargrupp

Att bedöma hur mycket en användare eller en uppsättning användare kommer att använda resurser är den första verklighetskontrollen. Vissa grupper eller individer kommer oundvikligen att använda mer av de uppgifter de utför. Därför behöver de tunga användarna identifieras.

Applikation och sessionstyp

Det är också mycket hjälpsamt att identifiera specifika applikationer, eftersom vissa användare kommer att monopolera stora mängder resurser beroende på vilka de kör.

Topp, tillväxt och fail-over marginal

Runda av denna inmatningslista genom att ta hänsyn till maximal användning, lämna utrymme för förväntad kortsiktig tillväxt och bygga in en buffermarginal för felövergång.

Hur beräknar du resurser på terminalservrar?

Här är en praktisk beräkningsmetod som vi hoppas kommer att vara användbar inom SMB-administration såväl som i andra sammanhang. Den syftar till att åtminstone förenkla planering och strukturera uppstarten. Sedan bör den senare kunna förfinas så att du kan räkna med den under pilotperioden och framåt.

Steg 1: Räkna samtidiga användare, inte totala användare

Börja med antalet användare som är aktiva samtidigt. Detta är det antal som driver serverbelastningen. Ett företag med 50 namngivna användare kan ha endast 18 till 25 anslutna samtidigt under rusningstid. När man dimensionerar en sessionsvärd är antalet samtidiga sessioner mycket mer användbart än det totala antalet användare.

Innan testning av hållbar kapacitet i verkliga situationer under belastning, behöver planeringen utmana uppskattningarna.

Steg 2: Klassificera arbetsbelastningar som lätta, medel eller tunga

Nästa, sortera gruppanvändare efter arbetsbelastning. Microsofts aktuell session-värd vägledning föreslår följande grundlinjedensitetsintervall för flersessionmiljöer och HP och andra källor instämmer:

• upp till 6 lätta användare per vCPU,
• 4 medelanvändare per vCPU och
• 2 tunga användare per vCPU,

med respektive ett 8 vCPU, 16 GB RAM, 32 GB lagring minimum VM-exempel över dessa arbetsbelastningsband. Rekommendationer inkluderar också att hålla fleranvändarsession VM-storlekar ungefär mellan 4 och 24 vCPUs för bättre kapacitetsavkastning.

En enkel arbetsbelastningskarta för SMB-planering skulle således vägleda sorteringen:

• Ljus: en affärsapp, begränsad webbläsaranvändning, korta sessioner
• Medium: Kontorsappar, webbläsartabbar, PDF-verktyg, måttlig multitasking
• Tung: ERP, större Excel-filer, konstant webbläsaranvändning, utskrift, flera appar öppna hela dagen

Detta är grundläggande planeringsband, inte garantier. Syftet är att välja en utgångspunkt baserad på arbetsbelastningens beteende.

Steg 3: Uppskatta CPU-kapacitet

När användare har grupperats, uppskatta CPU med en användare-per-vCPU-ansats. Till exempel, om 24 samtidiga användare mestadels är medelanvändare, föreslår Microsofts baslinje på cirka 4 användare per vCPU att börja runt 6 vCPUs, och sedan avrunda till en praktisk värdstorlek med utrymme för toppar. Om du vill ge bättre kapacitet för toppar under kortvariga CPU-behovstoppar, planera lägre användare-per-kärnförhållanden än du annars skulle göra.

Som kan ha blivit uppenbart, bör CPU-storleken inte stanna vid det matematiska minimum. Den bör ta hänsyn till inloggningstoppar, antivirusaktivitet, rapporteringsjobb och korta perioder av samtidiga applikationslanseringar.

Steg 4: Beräkna RAM-krav

RAM bör täcka behoven hos operativsystemet, kärntjänster, sessionsöverhead och applikationsminnesanvändning per användare. Som beskrivits ovan kopplade den nuvarande Microsoft-multi-session baslinjen sina lätta, medel och tunga arbetsbelastningsexempel med ett minimum av 16 GB RAM för en 8 vCPU utgångspunkt. Även om detta bara är en baslinje, ger det ändå en konkret utgångspunkt för uppskattning.

En praktisk metod i ett litet eller medelstort företag är att:

1. reservera minne för operativsystemet och plattformstjänsterna,
2. uppskatta minne per session per användarklass,
3. multiplicera med samtidiga sessioner,
4. då lägg till en säkerhetsmarginal.

PeteNetLive ger en avsiktligt bred tumregel av 2 till 8 GB per användare för RAM-planering av RD Session Host. Detta är användbart som en försiktighetsåtgärd mot att underskatta tunga sessioner, även om det exakta antalet måste förfinas i testning.

Steg 5: Kontrollera lagring och profilöverhead

Lagring underskattas ofta i planeringen av terminalservrar. Långsam, överbelastad lagring kan påverka inloggningar, profilinläsning, temporära filer, applikationslanseringar och utskriftsbuffring även när CPU och RAM fortfarande ser acceptabla ut.

• profil lagring
• OS-lagring
• loggar: för säkerhet och andra sådana ändamål

Denna sista kategori är väl värd att uppskatta eftersom den snabbt kan växa beroende på storleken på din infrastruktur och den typ av övervakning och skydd du behöver.

PeteNetLives roll-för-roll presentation fungerar som en användbar påminnelse om att sessionsvärden vanligtvis är där resurstrycket först uppstår, medan andra RDS-roller ofta har relativt mindre fotavtryck. Tänk på detta när du letar efter markörer för ditt företags användningskapacitet, eftersom det kan stödja storleksbedömningen av planer.

Steg 6: Lägg till utrymme för toppar, tillväxt och failover

Ingen terminalserverberäknare bör sluta med det "just tillräckligt" antalet. Lägg till marginal för:

• morgonsign-in-toppar
• patchning och AV-skanningar
• månatliga rapporteringstoppar
• förväntad användartillväxt
• värdmisslyckande i en fler-serverdesign

Avslutningsvis, några bra driftsråd för alla miljöer som går bortom en enda värd är att ta hänsyn till ytterligare värdar i händelse av server- eller hypervisorförlust.

Enkel metod för terminalserverberäkning för SMB:er och MSP:er

Denna kalkylatorlogik är avsiktligt enkel. Den är avsedd att ge en försvarbar första uppskattning, inte en slutlig referenspunkt, och för att du ska kunna anpassa den därefter.

En snabb planeringsformel

Använd denna sekvens:

1. Antal samtida användare .
2. Sortera dem i ljus, medium och tung grupper.
3. Kostnadsförslag CPU använder ett grundläggande användare-per-vCPU-förhållande.
4. Kostnadsförslag RAM från OS-överhead plus per-session efterfrågan.
5. Kontrollera lagring för profil, temporär och lanseringsprestanda.
6. Lägg till 20 till 30 procent utrymme , granska sedan behoven av failover.

Detta speglar essensen av hur storlek definieras i allmänhet: arbetsbelastning först, förhållanden andra, förfining efter observation. Och nu, varför inte få en förhandstitt på vilken form det kan ta , få en exakt uppskattning och kartlägga din potentiella infrastruktur? Ett viktigt verktyg när du planerar din budget.

Exempel 1: 15 ljusa kontorsanvändare

Anta att 15 samtidiga användare får åtkomst till en publicerad affärsapp plus lätt webbläsaranvändning.

Genom att använda rekommenderade ljusa baslinjer är den råa CPU-uppskattningen cirka 3 vCPU:er. I praktiken är det för snävt för burstkapacitet, så en planerare skulle välja en mer praktisk värdprofil istället för att bygga till kanten. Du kommer att se att råden förespråkar ett bredare intervall för storlek på 4 till 24 vCPU:er med 8 vCPU och 16 GB RAM som en standard basprofil för flersessioners arbetsbelastningar.

För RAM, reservera kapacitet för operativsystemet och tjänster, lägg sedan till sessionsminne för varje användare. Om miljön är stabil och appanvändningen är begränsad kan detta passa bekvämt på en blygsam värd, men det bör fortfarande valideras under pilotanvändning.

Exempel 2: 30 blandade kontors- och ERP-användare

Anta:

• 18 medelanvändare
• 12 tunga användare

En planeringsgenväg skulle behandla den medelstora gruppen som ungefär 4 användare per vCPU och den tunga gruppen som ungefär 2 användare per vCPU. Det innebär cirka 4,5 vCPUs för den medelstora gruppen och 6 vCPUs för den tunga gruppen, innan overhead och marginal. I praktiken pekar det redan bort från en enda lätt stor värd och mot antingen en större värd med marginal eller en uppdelning över flera sessionsvärdar.

Detta är där rådet "planera för serverresurser" blir meningsfullt. Med en ERP precis som i alla företagskontexter är målet inte bara att passa in användare någonstans. Målet är inte bara att passa in användare någonstans. Målet är att hålla svarstiderna acceptabla under de mest hektiska delarna av dagen.

Exempel 3: När man ska dela användare över flera värdar

När beräkningen ger en tät värd med begränsad kapacitet för plötsliga belastningar kan det bättre svaret vara arkitektoniskt snarare än vertikal skalning. Sessionsvärdar kan ställas in för att göra det tunga lyftet, medan roller som RD Connection Broker, Gateway och Licensing kan ges olika resursprofiler. Att dela användarbelastningen över flera värdar kommer sannolikt att förbättra motståndskraft, underhållsflexibilitet och planering för övergångar.

För MSP:er är detta ofta den avgörande punkten där en terminalserverkalkylator blir en diskussion om gårdsstorlek istället för en diskussion om en enda server.

Vilka vanliga storleksmisstag bryter vanligtvis terminalserverprestanda?

Storleksfel orsakas vanligtvis inte bara av matematik. De kommer från felaktiga antaganden.

Förvirra licensiering med prestandakapacitet

Licensiering berättar hur åtkomst tilldelas och konfigureras. Det säger inte hur många samtidiga användare en server kommer att stödja med acceptabel prestanda.

Ignorera webbläsartunga och utskriftstunga sessioner

Många miljöer underskattar fortfarande hur mycket belastning modern webbläsaranvändning, PDF-hantering och utskrift kan lägga på en sessionsvärd. Dessa aktiviteter kan flytta en användargrupp från lätt till medel, eller från medel till tung, även när affärsapplikationen i sig är blygsam.

Storlek endast för genomsnittlig belastning

Genomsnittlig belastning är sällan det ögonblick då användare klagar. Klagomål uppstår under inloggningsstormar, samtidiga filöppningar, rapporteringskörningar eller morgontoppar. Microsoft noterar att bättre kapacitet för toppar är viktigt vid lägre användar-per-kärna-förhållanden eftersom det stödjer att lämna utrymme istället för att sikta på maximal densitet.

Att glömma resten av RDS-stacken

Sessionsvärden är den främsta resurskonsumenten, men det är inte den enda rollen i miljön. PeteNetLives rollfördelning är en användbar påminnelse om att ta hänsyn till Connection Broker, Gateway, Web Access och licensiering separat när distributionen växer bortom en liten installation med en värd.

Varför bör övervakning validera dina storleksuppskattningar?

En terminalserverkalkylator ger dig en planeringsgrund. Den ger dig inte bevis. För bevis behöver du övervaka användningen.

Från grundlinje till bevis: övervakning som en nödvändighet

I vår tidigare artikel förklarar vi varför hållbar användarkapacitet är en praktisk övervakningsfråga. Här har målet varit att visa hur man uppskattar den första versionen av den kapaciteten innan lansering. Övervakning kommer att ge dig många av de räkningar vi har nämnt. Vi rekommenderar att du testar i en laboratoriemiljö för att utvärdera dina planerade behov.

Var gör TSplus Server Monitoring skillnad?

TSplus Server Monitoring passar efter att storleksuppskattningen har implementerats. Det hjälper till att verifiera om CPU-mättnad, minnestryck, lagringsflaskhalsar eller användningstoppar matchar de antaganden som användes i planeringen. Det är särskilt användbart för IT-administratörer i små och medelstora företag och tjänsteleverantörer som behöver bevis innan de ändrar storlek på en värd, omfördelar användare eller lägger till en annan server.

Utöver att veta hur man projekterar resurser, hur kan du annars veta om beräkningen var korrekt än genom övervakningssystem? Server Monitoring ger dig realtidsövervakning och aviseringar för att hålla dig informerad när som helst markörer når dina angivna trösklar. .

TSplus programvara för säker och hållbar leverans av appar och skrivbord

TSplus Remote Access fungerar som leveranslager i den bredare berättelsen medan Advanced Security är skräddarsydd för att skydda applikationsservrar. Dessutom erbjuder TSplus Remote Support ett kit med nödvändigheter för felsökning och underhåll av dessa servrar och mer från vilken plats som helst. När miljön är korrekt dimensionerad kommer TSplus Remote Access att publicera skrivbord och applikationer enklare än Citrix och utan att överskrida din budget. Testa funktioner som webbåtkomst och centraliserad leverans för att få en känsla för hur du kan gå bortom ad hoc RDP-åtkomst.

Slutsats

En terminalserverkalkylator bör inte lova ett magiskt svar. Nu är det dags att beräkna terminalserverresurser i steg: börja med samtidiga användare, klassificera arbetsbelastningens intensitet, uppskatta CPU och RAM utifrån realistiskt sessionsbeteende, kontrollera lagring och lägg sedan till marginal för toppar, tillväxt och failover.

Som systemadministratör, SMB IT-administratörer eller MSP, kommer detta att ge dig en praktisk första uppskattning. Därifrån är den verkliga disciplinen validering. Planera noggrant, distribuera konservativt och använd sedan övervakningsdata för att bekräfta om värden, eller värd gård kan upprätthålla den användarupplevelse du avser.