Ako vypočítať zdroje na terminálovom serveri: Praktická metóda dimenzovania

Terminálový serverový kalkulátor zriedka predstavuje doslovný kalkulátor. Vo väčšine prostredí SMB a MSP ide o plánovaciu metódu, ktorá sa používa na odhad, koľko CPU, RAM, úložiska a rezervy bude terminálový server potrebovať predtým, ako začnú používatelia sťažovať. Skutočná otázka za kľúčovým slovom je praktická: ako dostatočne presne vypočítať zdroje na terminálovom serveri, aby sa dalo nasadiť s dôverou, vyhnúť sa nadmerným výdavkom a znižte riziko výkonnostných úzkych miest ?

Čo by mal vlastne kalkulátor terminálového servera počítať?

Užitočný kalkulátor terminálového servera by mal odhadnúť viac ako „používateľov na server“. Ako administrátor by vám mal pomôcť naplánovať CPU, RAM, výkon úložiska, úložisko profilov a kapacitnú rezervu pri realistickom súbežnom používaní. Pokyny spoločnosti Microsoft pre hostiteľov relácií Remote Desktop rámcujú veľkosť okolo typu pracovnej záťaže a navrhovaného počtu používateľov na vCPU, nie okolo všeobecného limitu pripojenia.

Prečo samotný počet používateľov nestačí na výpočet zdrojov na terminálovom serveri?

Využitie relácie

Majte na pamäti, že dve prostredia s rovnakým počtom používateľov môžu priniesť veľmi odlišné výsledky. Predpokladáme, že už viete, koľko používateľov bude pristupovať k vašej infraštruktúre, takže mať zohľadnené licencie a CALs praktická práca sa môže začať.

Predstavte si, ako pätnásť používateľov otvára jeden podnikový softvér, čo môže vytvoriť skromnú záťaž na hostiteľovi. Medzitým pätnásť používateľov, ktorí spúšťajú plnú vzdialenú pracovnú plochu s prehliadačmi, aplikáciami Office, nástrojmi na PDF, tlačou a synchronizáciou na pozadí, môže vytvoriť oveľa ťažšiu stopu. Modely veľkosti odrážajú tento rozdiel oddelením ľahkých, stredných a ťažkých viacnásobných relácií.

Rozlíšenie je dôležité, pretože „30 používateľov“ nie je kapacitná hodnota sama o sebe. Má zmysel až po definovaní. čo títo používatelia robia a používajú počas špičkových období.

Využitie servera

Pamätajte tiež na dôležité rozlíšenie, ktoré má obrovský význam: pre laboratóriá alebo malú kanceláriu môžete plánovať jeden server, pretože bude mať menej súbežných používateľských relácií, zatiaľ čo pre produkciu pravdepodobne naplánujete farmu. Naozaj, sú potrebné samostatné úlohy na zlepšenie výkonu, zjednodušenie odstraňovania problémov a zabezpečenie bezpečnosti, takže bežné rozdelenie by bolo:

• 1 server pre makléra, web a licencovanie
• 1 alebo viac serverov pre hostiteľa relácií
• 1 RD Gateway na vlastnom serveri pre externý prístup.

Aby ste sa posunuli o krok ďalej, zistíte, že typ servera, pamäť atď. sa tiež zapoja a možno budete chcieť zahrnúť SSD do väčších nastavení napríklad. Napriek tomu, toto je len zmienka, aby vás informovala o možnostiach.

Aké štyri vstupy formujú plánovanie zdrojov?

Ďalej, spoľahlivejšie ako skákanie priamo na hardvérové čísla, tu sú štyri vstupy, ktoré je potrebné zhromaždiť pred začatím počítania. Táto predchádzajúca práca zabraňuje prekrytiu s otázkami licencovania o tom, kto sa môže pripojiť a podľa akých pravidiel Microsoftu. Hlavnou obavou je, koľko zdrojov potrebuje hostiteľ relácie, aby zostal reagujúci. Náš predchádzajúci článok pokrýval licencovanie a kapacita servera aby sme mohli vyvinúť praktické aspekty systematického počítania všetkého na správne plánovanie.

Preto musíte sčítať:

Súčasní aktívni používatelia

Stále musíme zahrnúť toto základné číslo, pretože počet relácií, ktoré sa vykonávajú paralelne, určite ovplyvní výkon servera. Všimnite si, že počet súbežných relácií môže byť nezávislý od celkového počtu.

Klasifikácia pracovného zaťaženia podľa skupiny používateľov

Hodnotenie, koľko jeden používateľ alebo skupina používateľov využije zdroje, je prvou realitou. Určité skupiny alebo jednotlivci nevyhnutne spotrebujú viac z úloh, ktoré vykonávajú. Preto je potrebné identifikovať ťažkých používateľov.

Typ aplikácie a relácie

Je tiež veľmi užitočné určiť konkrétne aplikácie, pretože niektorí používatelia budú monopolizovať veľké množstvá zdrojov v závislosti od toho, ktoré z nich spúšťajú.

Špička, rast a rezerva pre zlyhanie

Zhrňte tento zoznam vstupov zohľadnením maximálneho využitia, pričom nechajte priestor pre očakávaný krátkodobý rast a vytvorte rezervu pre zlyhanie.

Ako vypočítate zdroje na terminálových serveroch?

Tu je praktická metóda výpočtu, o ktorej dúfame, že sa bude hodiť pri správe SMB, ako aj v iných kontextoch. Jej cieľom je aspoň zjednodušiť plánovanie a štruktúrovať prípravy. Potom by sa mala neskôr prispôsobiť, aby ste na ňu mohli počítať počas pilotného obdobia a ďalej.

Krok 1: Počítajte súčasných používateľov, nie celkových používateľov

Začnite s počtom používateľov, ktorí sú aktívni súčasne. Toto je číslo, ktoré ovplyvňuje zaťaženie servera. Podnik s 50 menovanými používateľmi môže mať počas špičkových hodín pripojených iba 18 až 25 súčasne. Pri určovaní veľkosti hostiteľa relácie je počet súčasných relácií oveľa užitočnejší ako celkový počet.

Pred testovaním udržateľnej reálnej kapacity pod zaťažením je potrebné plánovanie spochybniť odhady.

Krok 2: Klasifikujte pracovné zaťaženia ako ľahké, stredné alebo ťažké

Ďalej usporiadajte skupinových používateľov podľa pracovného zaťaženia. Microsoftovho aktuálne usmernenie pre hostiteľa relácie navrhuje nasledujúce základné hustotné rozsahy pre viacnásobné relácie a HP a iné zdroje súhlasí:

• až 6 ľahkých používateľov na vCPU,
• 4 strední používatelia na vCPU a
• 2 ťažkí používatelia na vCPU,

s príslušným príkladom VM s minimálne 8 vCPU, 16 GB RAM a 32 GB úložiskom naprieč týmito pracovnými zaťaženiami. Odporúčania tiež zahŕňajú udržiavanie veľkostí multi-session VM zhruba medzi 4 a 24 vCPU pre lepšie výnosy kapacity.

Jednoduchá mapa pracovného zaťaženia pre plánovanie SMB by teda usmernila triedenie:

• Svetlo: jedna obchodná aplikácia, obmedzené používanie prehliadača, krátke relácie
• Stredná: Aplikácie Office, karty prehliadača, nástroje PDF, mierne multitasking
• Ťažký: ERP, väčšie súbory Excel, neustále používanie prehliadača, tlač, otvorené viaceré aplikácie celý deň

Toto sú základné plánovacie pásma, nie záruky. Cieľom je vybrať východiskový bod založený na správaní pracovnej záťaže.

Krok 3: Odhadnite kapacitu CPU

Akonáhle sú používatelia zoskupení, odhadnite CPU pomocou prístupu používateľov na vCPU. Napríklad, ak je 24 súbežných používateľov väčšinou stredne náročných, základná línia Microsoftu okolo 4 používateľov na vCPU naznačuje začať okolo 6 vCPU, potom zaokrúhliť na praktickú veľkosť hostiteľa s rezervou na náraz. Ak chcete poskytnúť lepšiu kapacitu pre nárazy počas krátkodobých špičiek dopytu po CPU, naplánujte nižšie pomery používateľov na jadro, ako by ste inak mohli.

Ako sa môže zdať zrejmé, veľkosť CPU by nemala zastaviť na matematickom minime. Mala by zohľadniť nárazové prihlásenia, činnosť antivírusového programu, reportovacie úlohy a krátke obdobia súčasného spúšťania aplikácií.

Krok 4: Odhadnite požiadavky na RAM

RAM by mala pokryť potreby operačného systému, základných služieb, režijných nákladov na reláciu a využitia pamäte aplikácií na používateľa. Ako je uvedené vyššie, aktuálny základný model Microsoftu pre viac relácií spároval svoje príklady ľahkej, strednej a ťažkej záťaže s minimálne 16 GB RAM pre východiskový bod 8 vCPU. Hoci ide len o základný model, predsa len poskytuje hmatateľný východiskový bod pre odhad.

Praktická metóda v malej alebo strednej firme je:

1. rezervovať pamäť pre operačný systém a platformové služby,
2. odhad pamäte na reláciu podľa triedy používateľa,
3. násobte súbežnými reláciami,
4. potom pridajte bezpečnostnú rezervu.

PeteNetLive poskytuje a úmyselne široké pravidlo palca od 2 do 8 GB na používateľa pre plánovanie RAM na RD Session Host. Toto je užitočné ako varovanie pred podceňovaním náročných relácií, aj keď presný počet musí byť upresnený v testovaní.

Krok 5: Skontrolujte úložisko a režijné náklady profilu

Úložisko je často podceňované pri plánovaní terminálového servera. Pomalé preplnené úložisko môže ovplyvniť prihlásenia, načítanie profilov, dočasné súbory, spúšťanie aplikácií a spooling tlače, aj keď CPU a RAM stále vyzerajú prijateľne.

• úložisko profilu
• úložisko OS
• záznamy: na bezpečnostné a iné podobné účely

Táto posledná kategória stojí za odhad, pretože sa môže rýchlo zväčšiť v závislosti od veľkosti vašej infraštruktúry a typu monitorovania a ochrany, ktorú potrebujete.

Prezentácia PeteNetLive podľa rolí slúži ako užitočné pripomenutie, že hostiteľ relácie je zvyčajne miestom, kde sa tlak na zdroje objavuje ako prvý, zatiaľ čo ostatné RDS role často majú relatívne menšie nároky. Majte to na pamäti, keď hľadáte ukazovatele kapacity využívania vašej spoločnosti, pretože to môže podporiť plánovanie rozšírenia.

Krok 6: Pridajte rezervu pre špičky, rast a zálohovanie

Žiadny terminálový server by nemal končiť na čísle „len dosť“. Pridajte rezervu pre:

• ráno prihlásenie špičky
• opravy a skenovanie AV
• mesačné správy vrcholov
• očakávaný rast používateľov
• zlyhanie hostiteľa v dizajne s viacerými servermi

Na záver, niekoľko dobrých prevádzkových rád pre akékoľvek prostredie, ktoré prechádza za rámec jedného hostiteľa, je zohľadniť ďalších hostiteľov v prípade straty servera alebo hypervízora.

Jednoduchá metóda kalkulátora terminálového servera pre SMB a MSP

Táto logika kalkulačky je zámerne jednoduchá. Je určená na vytvorenie obhájiteľného prvého odhadu, nie konečného benchmarku, a pre vás, aby ste ju prispôsobili podľa potreby.

Rýchla plánovacia formula

Použite túto sekvenciu:

1. Počet súčasní používatelia .
2. Zaradiť ich do ľahký, stredný a ťažký skupiny.
3. Odhad CPU použitím základného pomeru používateľov na vCPU.
4. Odhad RAM z OS nadbytočnosti plus požiadavka na reláciu.
5. Skontrolovať úložisko pre profil, výkon dočasného a spúšťania.
6. Pridať 20 až 30 percentná rezerva , potom skontrolujte potreby pre prevzatie.

Toto odráža podstatu toho, ako je veľkosť rámcovaná vo všeobecnosti: najprv pracovná záťaž, potom pomery, zdokonalenie po pozorovaní. A teraz, prečo si nedopriať malý náhľad na akú formu by to mohlo mať získať presný odhad a naplánovať svoju potenciálnu infraštruktúru? Kľúčový nástroj pri plánovaní vášho rozpočtu.

Príklad 1: 15 svetelných kancelárskych používateľov

Predpokladajte, že 15 súčasných používateľov pristupuje k zverejnenej obchodnej aplikácii plus ľahké používanie prehliadača.

Použitím odporúčaných svetelných základov je odhad surového CPU približne 3 vCPU. V praxi je to príliš tesné pre burst kapacitu, takže plánovač by prešiel na praktickejší profil hostiteľa, než aby sa budoval na hrane. Nájdete odporúčania, ktoré uprednostňujú širší rozsah veľkosti 4 až 24 vCPU s 8 vCPU a 16 GB RAM ako štandardný základný profil pre viacnásobné pracovné zaťaženia.

Pre RAM si rezervujte kapacitu pre operačný systém a služby, potom pridajte pamäť relácie pre každého používateľa. Ak je prostredie stabilné a používanie aplikácií je úzke, toto by sa mohlo pohodlne zmestiť na skromnom hostiteľovi, ale malo by sa to stále overiť počas pilotného používania.

Príklad 2: 30 zmiešaných používateľov kancelárie a ERP

Predpokladajte:

• 18 stredne veľkých používateľov
• 12 ťažkých používateľov

Plánovací skratka by zaobchádzala so strednou skupinou s približne 4 používateľmi na vCPU a s ťažkou skupinou s približne 2 používateľmi na vCPU. To naznačuje asi 4,5 vCPU pre strednú skupinu a 6 vCPU pre ťažkú skupinu, pred preťažením a rezervou. V praxi to už ukazuje od jedného ľahko dimenzovaného hostiteľa a smerom k buď väčšiemu hostiteľovi s rezervou, alebo k rozdeleniu medzi viaceré hostiteľské relácie.

Toto je miesto, kde sa rada „plánovať serverové zdroje“ stáva významnou. S pomocou ERP rovnako ako v akomkoľvek podnikovom kontexte, cieľom nie je len umiestniť používateľov niekde. Cieľom nie je len umiestniť používateľov niekam. Cieľom je udržať časy reakcií prijateľné počas najrušnejších častí dňa.

Príklad 3: Kedy rozdeliť používateľov medzi viaceré hostiteľské systémy

Akonáhle výpočet vytvorí hustého hostiteľa s obmedzenou kapacitou pre nárazové zaťaženie, lepšia odpoveď môže byť architektonická skôr než vertikálne škálovanie. Hostitelia relácií môžu byť nastavení na vykonávanie ťažkej práce, zatiaľ čo úlohy ako RD Connection Broker, Gateway a Licensing môžu mať rôzne profily zdrojov. Rozdelenie zaťaženia používateľov medzi viacerých hostiteľov pravdepodobne zlepší odolnosť, flexibilitu údržby a plánovanie prechodu.

Pre MSPs je to často rozhodujúci moment, kedy sa kalkulačka terminálového servera stáva diskusiou o veľkosti farmy namiesto diskusie o jednom serveri.

Aké bežné chyby pri veľkosti typicky narušujú výkon terminálového servera?

Chyby v dimenzovaní zvyčajne nie sú spôsobené len matematikou. Pochádzajú z nesprávnych predpokladov.

Zamieňanie licencovania s výkonnostnou kapacitou

Licencovanie vám hovorí, ako je prístup priradený a nakonfigurovaný. Nehovorí vám, koľko súčasných používateľov server podporí s prijateľným výkonom.

Ignorovanie relácií s vysokou záťažou pre prehliadač a tlač.

Mnohé prostredia stále podceňujú, akú záťaž môže moderné používanie prehliadača, spracovanie PDF a tlač pridať na hostiteľa relácie. Tieto aktivity môžu posunúť skupinu používateľov z ľahkej na strednú, alebo zo strednej na ťažkú, aj keď samotná aplikácia pre podnikanie je skromná.

Veľkosť iba pre priemerné zaťaženie

Priemerné zaťaženie je zriedka moment, kedy sa používatelia sťažujú. Sťažnosti sa vyskytujú počas logonových búrok, súčasného otvárania súborov, spúšťania reportov alebo ranných špičiek. Microsoft poznamenáva, že lepšia kapacita nárazov je dôležitá pri nižších pomeroch používateľov na jadro, pretože podporuje ponechanie priestoru namiesto zamerania sa na maximálnu hustotu.

Zabudnutie na zvyšok RDS stacku

Hlavný hostiteľ relácie je hlavným spotrebiteľom zdrojov, ale nie je to jediná úloha v prostredí. Rozdelenie úloh PeteNetLive je užitočná pripomienka, aby sa pri rozširovaní nasadenia nad rámec malej jednorazovej konfigurácie zohľadnili Connection Broker, Gateway, Web Access a licencovanie samostatne.

Prečo by malo monitorovanie overiť vaše odhady veľkosti?

Kalkulačka terminálového servera vám poskytuje plánovaciu základňu. Nedáva vám dôkaz. Na dôkaz potrebujete monitorovať používanie.

Od základnej línie po dôkaz: monitorovanie ako nevyhnutnosť

V našom predchádzajúcom článku vysvetľujeme, prečo je udržateľná kapacita používateľov praktickou otázkou monitorovania. Cieľom bolo ukázať, ako odhadnúť prvú verziu tejto kapacity pred nasadením. Monitorovanie vám poskytne mnoho z počtov, ktoré sme spomenuli. Odporúčame vám testovať v laboratórnom prostredí, aby ste vyhodnotili svoje zamýšľané potreby.

Kde robí TSplus Server Monitoring rozdiel?

TSplus Server Monitoring sedí po nasadení odhadu veľkosti. Pomáha overiť, či saturácia CPU, tlak na pamäť, úzke miesta v úložisku alebo špičky v používaní zodpovedajú predpokladom použitým pri plánovaní. To je obzvlášť užitočné pre IT administrátorov SMB a MSP, ktorí potrebujú dôkazy pred zmenou veľkosti hostiteľa, redistribúciou používateľov alebo pridaním ďalšieho servera.

Okrem vedomosti, ako projektovať zdroje, ako inak môžete vedieť, či bola kalkulácia správna, než prostredníctvom monitorovacích systémov? Server Monitoring vám poskytuje monitorovanie v reálnom čase a upozornenia, aby ste boli informovaní, kedykoľvek ukazovatele dosiahnu vaše nastavené prahové hodnoty. .

TSplus softvér pre bezpečné a trvalé dodávanie aplikácií a desktopov

TSplus Remote Access patrí ako dodávková vrstva v širšom príbehu, zatiaľ čo Advanced Security je navrhnutý na ochranu aplikačných serverov. Okrem toho TSplus Remote Support poskytuje súpravu základných nástrojov na riešenie problémov a údržbu týchto serverov a ďalších z akéhokoľvek miesta. Akonáhle je prostredie správne nastavené, TSplus Remote Access zverejní pracovné plochy a aplikácie jednoduchšie ako Citrix a bez prekročenia vášho rozpočtu. Testovanie funkcií, ako je webový prístup a centralizovaná dodávka, vám poskytne predstavu o tom, ako môžete prejsť za ad hoc prístup RDP.

Záver

Terminálový server by nemal sľubovať magickú odpoveď. Teraz je čas vypočítať zdroje terminálového servera po etapách: začnite s concurrentnými používateľmi, klasifikujte intenzitu zaťaženia, odhadnite CPU a RAM na základe realistického správania relácií, skontrolujte úložisko a potom pridajte rezervu na špičky, rast a zálohovanie.

Ako systémový administrátor, administrátori IT SMB alebo MSP, vám to poskytne praktický prvý odhad. Odtiaľ je skutočná disciplína validácia. Plánujte starostlivo, nasadzujte konzervatívne a potom používajte monitorovacie údaje na potvrdenie, či je hostiteľ, alebo hostiteľská farmácia , môže udržať používateľský zážitok, ktorý zamýšľate.