Jak vypočítat zdroje na terminálovém serveru: Praktická metoda dimenzování

Kalkulátor terminálového serveru je zřídka doslovný kalkulátor. Ve většině prostředí SMB a MSP je to plánovací metoda používaná k odhadu, kolik CPU, RAM, úložiště a rezervy terminálový server bude potřebovat, než začnou uživatelé stěžovat. Skutečná otázka za klíčovým slovem je praktická: jak správně vypočítat zdroje na terminálovém serveru, abyste mohli nasadit s důvěrou, vyhnout se nadměrným výdajům a snížit riziko výkonnostních úzkých míst ?

Co by měl terminálový server kalkulátor vlastně počítat?

Užitečný kalkulátor terminálového serveru by měl odhadnout více než „uživatelé na server“. Jako administrátor by vám měl pomoci naplánovat CPU, RAM, výkon úložiště, úložiště profilů a kapacitní rezervu při realistickém souběžném používání. Pokyny společnosti Microsoft pro hostitele relací Remote Desktop rámcují velikost podle typu pracovní zátěže a doporučeného počtu uživatelů na vCPU, nikoli podle obecného limitu připojení pro všechny.

Proč samotný počet uživatelů nestačí k výpočtu zdrojů na terminálovém serveru?

Využití relace

Mějte na paměti, že dvě prostředí se stejným počtem uživatelů mohou přinášet velmi odlišné výsledky. Předpokládáme, že již víte, kolik uživatelů bude přistupovat k vaší infrastruktuře, takže mít zvažované licencování a CALs , praktická práce může začít.

Představte si, jak patnáct uživatelů otevírajících jednu aplikaci pro podnikání může vyvinout mírné zatížení na hostiteli. Mezitím patnáct uživatelů, kteří provozují plnou vzdálenou plochu s prohlížeči, aplikacemi Office, nástroji pro PDF, tiskem a synchronizací na pozadí, může vytvořit mnohem těžší zátěž. Modely velikosti odrážejí tento rozdíl tím, že oddělují lehké, střední a těžké více relace pracovní zátěže.

Rozlišení je důležité, protože „30 uživatelů“ není samo o sobě údaj o kapacitě. Má smysl pouze tehdy, když to definujete. co ti uživatelé dělají a používají během špičkových období.

Využití serveru

Také si pamatujte důležité rozlišení, které má obrovský význam: pro laboratoře nebo malou kancelář můžete plánovat jeden server, protože bude mít méně současných uživatelských relací, zatímco pro produkci pravděpodobně naplánujete farmu. Opravu, oddělené role jsou potřebné pro zlepšení výkonu, zjednodušení odstraňování problémů a zajištění bezpečnosti, takže běžné rozdělení by bylo:

• 1 server pro Brokera, Web a Licencování
• 1 nebo více serverů pro hostitele relací
• 1 RD Gateway na vlastním serveru pro externí přístup.

Abychom šli o krok dál, zjistíte, že typ serveru, paměť atd. budou hrát roli a možná budete chtít zahrnout SSD do větších konfigurací například. Přesto je to pouze zmínka, aby vás informovala o možnostech.

Které čtyři vstupy formují plánování zdrojů?

Další, spolehlivější než skákání přímo na čísla hardwaru, zde jsou čtyři vstupy, které je třeba shromáždit před zahájením počítání. Tato upstreamová práce se vyhýbá překrývání s otázkami licencí o tom, kdo se může připojit a podle jakých pravidel Microsoftu. Hlavní obavou zde je, kolik zdrojů potřebuje hostitel relace, aby zůstal reagující. Náš předchozí článek pokrýval licencování a kapacita serveru abychom zde mohli vyvinout praktické aspekty systematického počítání všeho pro správné plánování.

Proto je třeba sečíst:

Současní aktivní uživatelé

Stále musíme zahrnout toto zásadní číslo, protože počet relací běžících paralelně určitě ovlivní výkon serveru. Všimněte si, že počet současných relací může být nezávislý na celkovém počtu.

Třída zátěže na uživatelskou skupinu

Hodnocení, kolik jeden uživatel nebo skupina uživatelů využije zdrojů, je první kontrola reality. Určité skupiny nebo jednotlivci nevyhnutelně spotřebují více na úkoly, které vykonávají. Proto je důležité identifikovat těžké uživatele.

Typ aplikace a relace

Je také velmi užitečné určit konkrétní aplikace, protože někteří uživatelé budou monopolizovat velké množství zdrojů podle toho, které aplikace spouštějí.

Vrchol, růst a rezerva pro selhání

Zaokrouhlete tento seznam vstupů tím, že zohledníte maximální využití, ponecháte prostor pro očekávaný krátkodobý růst a vytvoříte rezervu pro selhání.

Jak vypočítáte zdroje na terminálových serverech?

Zde je praktická metoda výpočtu, kterou doufáme, že bude užitečná v administraci SMB i v dalších kontextech. Cílem je alespoň zjednodušit plánování a strukturovat přípravy. Poté by se měla později hodit k vylepšení, abyste na ni mohli spoléhat během pilotního období a dále.

Krok 1: Počítejte současné uživatele, nikoli celkové uživatele

Začněte s počtem uživatelů, kteří jsou aktivní současně. To je číslo, které ovlivňuje zatížení serveru. Firma s 50 pojmenovanými uživateli může mít během špičkových hodin připojeno pouze 18 až 25 uživatelů současně. Při dimenzování hostitele relace je počet současných relací mnohem užitečnější než celkový počet uživatelů.

Před testováním udržitelné kapacity v reálném světě pod zátěží je třeba plánování zpochybnit odhady.

Krok 2: Klasifikujte pracovní zátěže jako lehké, střední nebo těžké

Další, seřaďte skupinové uživatele podle pracovní zátěže. Microsoftova aktuální pokyny pro hostitele relace navrhuje následující základní hustotní rozsahy pro více relací a HP a další zdroje souhlasí:

• až 6 lehkých uživatelů na vCPU,
• 4 střední uživatelé na vCPU a
• 2 těžcí uživatelé na vCPU,

s odpovídajícím příkladem VM s minimálně 8 vCPU, 16 GB RAM a 32 GB úložiště napříč těmito pracovními zátěžemi. Doporučení také zahrnují udržování velikostí multi-session VM přibližně mezi 4 a 24 vCPU pro lepší návratnost kapacity.

Jednoduchá mapa pracovního zatížení pro plánování SMB by tedy vedla k třídění:

• Světlý: jedna obchodní aplikace, omezené používání prohlížeče, krátké relace
• Střední: Aplikace Office, záložky prohlížeče, nástroje PDF, mírné multitasking
• Těžký: ERP, větší soubory Excel, neustálé používání prohlížeče, tisk, otevřené více aplikací po celý den

Toto jsou základní plánovací pásma, nikoli záruky. Účelem je vybrat výchozí bod založený na chování pracovního zatížení.

Krok 3: Odhadněte kapacitu CPU

Jakmile jsou uživatelé seskupeni, odhadněte CPU pomocí přístupu uživatelů na vCPU. Například, pokud je 24 současných uživatelů převážně středních, základní hodnota Microsoftu přibližně 4 uživatelé na vCPU naznačuje začít kolem 6 vCPU, a poté zaokrouhlit na praktickou velikost hostitele s rezervou pro nárazové zatížení. Pokud chcete poskytnout lepší kapacitu pro nárazové zatížení během krátkodobých špiček poptávky po CPU, naplánujte nižší poměry uživatelů na jádro, než byste jinak mohli.

Jak může být zřejmé, velikost CPU by neměla končit na matematickém minimu. Měla by zohlednit nárazové přihlašování, činnost antiviru, reportovací úkoly a krátké období současného spouštění aplikací.

Krok 4: Odhadnout požadavky na RAM

RAM by měla pokrýt potřeby operačního systému, základních služeb, režie relace a využití paměti aplikací na uživatele. Jak bylo uvedeno výše, aktuální základní linie Microsoftu pro více relací spojila příklady lehkého, středního a těžkého zatížení s minimálně 16 GB RAM pro výchozí bod 8 vCPU. Ačkoli se jedná pouze o základní linii, přesto poskytuje hmatatelný výchozí bod pro odhad.

Praktickou metodou v malé nebo střední firmě je:

1. rezervovat paměť pro operační systém a platformní služby,
2. odhad paměti na sezení podle uživatelské třídy,
3. násobit současnými relacemi,
4. poté přidejte bezpečnostní rezervu.

PeteNetLive poskytuje a úmyslně široké pravidlo palce od 2 do 8 GB na uživatele pro plánování RAM RD Session Host. To je užitečné jako varování proti podceňování náročných relací, i když přesný počet musí být upřesněn při testování.

Krok 5: Zkontrolujte úložný prostor a režii profilu

Úložiště je často podceňováno při plánování terminálového serveru. Pomalé ucpané úložiště může poškodit přihlašování, načítání profilů, dočasné soubory, spouštění aplikací a spooling tisku, i když CPU a RAM stále vypadají přijatelně.

• úložiště profilu
• Úložiště OS
• logy: pro bezpečnost a jiné podobné účely

Tato poslední kategorie stojí za odhad, protože se může rychle zvětšit v závislosti na velikosti vaší infrastruktury a typu monitorování a ochrany, kterou potřebujete.

Prezentace PeteNetLive podle rolí slouží jako užitečná připomínka, že hostitel relace je obvykle místem, kde se tlak na zdroje objevuje jako první, zatímco ostatní role RDS často mají relativně menší nároky. Mějte to na paměti, když hledáte ukazatele kapacity využití vaší společnosti, protože to může podpořit plánování velikosti.

Krok 6: Přidejte rezervu pro špičky, růst a přepnutí.

Žádný kalkulátor terminálového serveru by neměl končit na čísle „jen dost“. Přidejte rezervu pro:

• ráno přihlašovací špičky
• záplaty a skenování AV
• měsíční vrcholy reportování
• očekávaný růst uživatelů
• selhání hostitele v návrhu s více servery

Na závěr, několik dobrých provozních rad pro jakékoli prostředí, které se posouvá za jediný hostitel, je zohlednit další hostitele pro případ ztráty serveru nebo hypervizoru.

Jednoduchá metoda kalkulátoru terminálového serveru pro SMB a MSP

Tato logika kalkulačky je záměrně jednoduchá. Je určena k tomu, aby poskytla obhajitelný první odhad, nikoli konečný standard, a abyste ji mohli podle toho přizpůsobit.

Rychlá plánovací formule

Použijte tuto sekvenci:

1. Počet současní uživatelé .
2. Seřaďte je do světlo, střední a těžký skupiny.
3. Odhad CPU použití základního poměru uživatelů na vCPU.
4. Odhad RAM z OS přetížení plus poptávka na sezení.
5. Zkontrolovat úložiště pro výkon profilu, dočasného a spuštění.
6. Přidat 20 až 30 procent rezervy , poté zkontrolujte potřeby pro přepnutí.

Toto odráží podstatu toho, jak je velikost obecně definována: nejprve pracovní zátěž, poté poměry, zdokonalení po pozorování. A teď, proč si neudělat malou ochutnávku jaký tvar by to mohlo mít , získat přesný odhad a naplánovat svou potenciální infrastrukturu? Klíčový nástroj při plánování vašeho rozpočtu.

Příklad 1: 15 uživatelů v kanceláři s nízkou zátěží

Předpokládejte, že 15 současných uživatelů přistupuje k publikované obchodní aplikaci a zároveň používá lehký prohlížeč.

Použitím doporučených lehkých základních hodnot je hrubý odhad CPU přibližně 3 vCPU. V praxi je to příliš těsné pro burst kapacitu, takže plánovač by přešel na praktičtější profil hostitele, než aby stavěl na hranici. Najdete doporučení, která preferují širší rozsah velikosti 4 až 24 vCPU s 8 vCPU a 16 GB RAM jako standardní základní profil pro více relací.

Pro RAM rezervujte kapacitu pro operační systém a služby, poté přidejte paměť relace pro každého uživatele. Pokud je prostředí stabilní a používání aplikací je úzké, může to pohodlně vyhovovat na skromném hostiteli, ale mělo by to být stále ověřeno během pilotního použití.

Příklad 2: 30 smíšených uživatelů kanceláře a ERP

Předpokládejme:

• 18 středně velkých uživatelů
• 12 těžkých uživatelů

Plánovací zkratka by považovala střední skupinu za přibližně 4 uživatele na vCPU a těžkou skupinu za přibližně 2 uživatele na vCPU. To naznačuje přibližně 4,5 vCPU pro střední skupinu a 6 vCPU pro těžkou skupinu, před přídavnými náklady a rezervou. V praxi to již ukazuje na odklon od jednoho lehce dimenzovaného hostitele a směrem k buď většímu hostiteli s rezervou, nebo k rozdělení napříč více hostiteli relací.

Toto je místo, kde rada „plánovat serverové zdroje“ nabývá smyslu. S pomocí ERP stejně jako v jakémkoli podnikatelském kontextu, cílem není jen umístit uživatele někam. Cílem není jen umístit uživatele někam. Cílem je udržet časy odezvy přijatelné během nejrušnějších částí dne.

Příklad 3: Kdy rozdělit uživatele mezi více hostiteli

Jakmile výpočet vytvoří hustý hostitel s omezenou kapacitou pro nárazové zatížení, může být lepší odpovědí architektura než vertikální škálování. Hostitelé relací mohou být nastaveni na provádění těžké práce, zatímco role jako RD Connection Broker, Gateway a Licensing mohou mít různé profily zdrojů. Rozdělení uživatelského zatížení mezi více hostiteli pravděpodobně zlepší odolnost, flexibilitu údržby a plánování přepnutí.

Pro MSP je to často rozhodující moment, kdy se kalkulátor terminálového serveru stává diskusí o velikosti farmy místo diskuse o jednom serveru.

Jaké běžné chyby při velikosti obvykle narušují výkon terminálového serveru?

Chyby v dimenzování obvykle nejsou způsobeny pouze matematikou. Pocházejí z nesprávných předpokladů.

Zaměňování licencí s výkonnostní kapacitou

Licencování vám říká, jak je přístup přiřazen a nakonfigurován. Neříká vám, kolik současných uživatelů server podpoří s přijatelným výkonem.

Ignorování relací s vysokou zátěží pro prohlížeč a tisk

Mnoho prostředí stále podceňuje, kolik zátěže může moderní používání prohlížeče, zpracování PDF a tisk přidat na hostitele relace. Tyto činnosti mohou posunout uživatelskou skupinu z lehké na střední, nebo ze střední na těžkou, i když je samotná aplikace pro podnikání skromná.

Velikost pouze pro průměrné zatížení

Průměrné zatížení je zřídka okamžik, kdy si uživatelé stěžují. Stížnosti se objevují během logonových bouří, současného otevírání souborů, běhů reportů nebo ranních špiček. Microsoft uvádí, že lepší kapacita pro výbuchy je důležitá při nižších poměrech uživatelů na jádro, protože podporuje ponechání prostoru místo cílení na maximální hustotu.

Zapomínání na zbytek RDS stacku

Host relace je hlavním spotřebitelem zdrojů, ale není to jediná role v prostředí. Rozdělení rolí PeteNetLive je užitečná připomínka, abychom při rozšiřování nasazení nad rámec malé jednorázové konfigurace zohlednili Connection Broker, Gateway, Web Access a Licensing zvlášť.

Proč by mělo monitorování ověřit vaše odhady velikosti?

Kalkulačka terminálového serveru vám poskytuje základ pro plánování. Nedává vám však důkaz. Pro důkaz musíte sledovat využití.

Od základny k důkazu: monitorování jako nezbytnost

V našem předchozím článku vysvětlujeme, proč je udržitelná uživatelská kapacita praktickou otázkou monitorování. Cílem bylo ukázat, jak odhadnout první verzi této kapacity před nasazením. Monitorování vám poskytne mnoho z počtů, které jsme zmínili. Doporučujeme, abyste testovali v laboratorním kontextu, abyste vyhodnotili své zamýšlené potřeby.

Kde dělá TSplus Server Monitoring rozdíl?

TSplus Server Monitoring padne po nasazení odhadu velikosti. Pomáhá ověřit, zda saturace CPU, tlak na paměť, úzká místa ve skladování nebo špičky v používání odpovídají předpokladům použitým při plánování. To je obzvlášť užitečné pro IT administrátory SMB a MSP, kteří potřebují důkazy před změnou velikosti hostitele, redistribucí uživatelů nebo přidáním dalšího serveru.

Kromě znalosti, jak projektovat zdroje, jak jinak můžete vědět, zda byla kalkulace správná, než prostřednictvím monitorovacích systémů? Server Monitoring vám poskytuje monitorování v reálném čase a upozornění, abyste byli informováni, kdykoli ukazatele dosáhnou vašich nastavených prahových hodnot. .

TSplus software pro bezpečné a trvalé doručování aplikací a desktopů

TSplus Remote Access patří jako dodací vrstva do širšího příběhu, zatímco Advanced Security je navrženo na míru k ochraně aplikačních serverů. Kromě toho TSplus Remote Support poskytuje sadu základních nástrojů pro odstraňování problémů a údržbu těchto serverů a dalších z jakéhokoli místa. Jakmile je prostředí správně dimenzováno, TSplus Remote Access bude publikovat pracovní plochy a aplikace jednodušeji než Citrix a bez překročení vašeho rozpočtu. Testování funkcí, jako je webový přístup a centralizované dodání, vám dá ochutnat, jak můžete překročit ad hoc RDP přístup.

Závěr

Kalkulátor terminálového serveru by neměl slibovat kouzelnou odpověď. Nyní je čas vypočítat zdroje terminálového serveru ve fázích: začněte s concurrentními uživateli, klasifikujte intenzitu zátěže, odhadněte CPU a RAM na základě realistického chování relací, zkontrolujte úložiště a poté přidejte rezervu pro špičky, růst a přepnutí.

Jako systémový administrátor, IT administrátoři SMB nebo MSP, vám to poskytne praktický první odhad. Odtud je skutečnou disciplínou validace. Plánujte pečlivě, nasazujte konzervativně a poté použijte monitorovací data k potvrzení, zda hostitel, nebo hostitelská farmářská , může udržet uživatelskou zkušenost, kterou zamýšlíte.