Hogyan számítsuk ki az erőforrásokat egy terminál szerveren: Egy gyakorlati méretezési módszer

A terminál szerver kalkulátor ritkán egy szó szerinti kalkulátor. A legtöbb KKV és MSP környezetben ez egy tervezési módszer, amelyet arra használnak, hogy megbecsüljék, mennyi CPU-ra, RAM-ra, tárolóra és tartalékra lesz szüksége egy terminál szervernek, mielőtt a felhasználók elkezdenének panaszkodni. A kulcsszó mögötti valódi kérdés gyakorlati: hogyan lehet elegendő pontossággal kiszámítani az erőforrásokat egy terminál szerveren ahhoz, hogy magabiztosan telepíthessük, elkerüljük a túlköltekezést és csökkentse a teljesítmény szűk keresztmetszeteinek kockázatát ?

Mit kellene valójában kiszámolnia egy terminál szerver kalkulátornak?

Egy hasznos terminálszerver-kalkulátornak többet kellene becsülnie, mint a „felhasználók száma szerveren”. Adminisztrátorként segítenie kellene a CPU, RAM, tárolási teljesítmény, profil tárolás és kapacitás-margó tervezésében reális egyidejű használat mellett. A Microsoft útmutatása a Remote Desktop munkamenet-hosztok számára a munkaterhelés típusa és a javasolt felhasználók vCPU-nként köré építi a méretezést, nem pedig egy általános, mindenki számára megfelelő kapcsolatkorlát köré.

Miért nem elegendő csupán a felhasználói szám a források kiszámításához egy terminál szerveren?

Session használat

Tartsd észben, hogy két olyan környezet, amelyben ugyanannyi felhasználó van, nagyon különböző eredményeket hozhat. Feltételezzük, hogy már tudod, hány felhasználó fogja elérni az infrastruktúrádat, így van. figyelembe vett licencelést és CAL-okat a gyakorlati munka elkezdődhet.

Képzelje el, hogy tizenöt felhasználó egy üzleti alkalmazást nyit meg, ami mérsékelt terhelést jelent egy gazdagépen. Eközben tizenöt felhasználó, aki teljes távoli asztalt futtat böngészőkkel, Office alkalmazásokkal, PDF eszközökkel, nyomtatással és háttérszinkronizálással, sokkal nagyobb terhelést okozhat. A méretezési modellek ezt a különbséget tükrözik azáltal, hogy elkülönítik a könnyű, közepes és nehéz több munkamenetes terheléseket.

A megkülönböztetés fontos, mert a "30 felhasználó" önmagában nem kapacitási adat. Csak akkor van értelme, ha meghatározod. mit csinálnak és használnak azok a felhasználók csúcsidőszakokban.

Szerverhasználat

Egy fontos megkülönböztetést is érdemes megjegyezni, amely rendkívül lényeges: laborok vagy kis irodák esetén egyetlen szervert tervezhetsz, mivel kevesebb egyidejű felhasználói munkamenetet fog futtatni, míg a termeléshez valószínűleg egy farmot tervezel. Valóban, különböző szerepkörökre van szükség a teljesítmény javítása, a hibaelhárítás egyszerűsítése és a biztonság megszilárdítása érdekében, így egy gyakori felosztás a következő lenne:

• 1 szerver a Broker, Web és Licencelés számára
• 1 vagy több szerver a Session Host számára
• 1 RD Gateway saját szerveren külső hozzáféréshez.

Egy lépéssel továbbhaladva azt is észre fogja venni, hogy a szerver típusa, a memória stb. szerepet játszik, és lehet, hogy szeretné. SSD-t nagyobb beállításokban is belefoglalni például. Mégis, ez csak egy említés, hogy tudomásodra hozza a lehetőségeket.

Mely négy bemenet formálja az erőforrás-tervezést?

Következő lépésként, megbízhatóbb, mint közvetlenül a hardver számok ugrása, itt van négy bemenet, amelyet össze kell gyűjteni, mielőtt elkezdenénk a számolást. Ez a felfelé irányuló munka elkerüli a licencelési kérdésekkel való átfedést, hogy ki csatlakozhat és milyen Microsoft szabályok szerint. A középpontban az áll, hogy mennyi erőforrásra van szüksége egy munkamenet gazdának ahhoz, hogy reagálóképes maradjon. Korábbi cikkünk foglalkozott licencelés és szerverkapacitás így itt kidolgozhatjuk a mindent módszeresen számolásának gyakorlati részleteit a helyes tervezéshez.

Ezért össze kell adnia:

Párhuzamos aktív felhasználók

Még mindig szükségünk van erre az alapvető számra, mivel a párhuzamosan futó ülések száma hatással lesz a szerver teljesítményére. Vegye figyelembe, hogy a párhuzamos szám független lehet a teljes számtól.

Felhasználói csoportonkénti terhelési osztály

A felhasználók vagy felhasználói csoportok erőforrás-felhasználásának felmérése az első valóságellenőrzés. Bizonyos csoportok vagy egyének elkerülhetetlenül többet fognak felhasználni a végzett feladatokból. Ezért szükséges az intenzív felhasználók azonosítása.

Alkalmazás és munkamenet típusa

Nagyon hasznos a konkrét alkalmazások pontos meghatározása is, mivel bizonyos felhasználók nagy mennyiségű erőforrást monopolizálnak attól függően, hogy melyeket futtatják.

Csúcs, növekedés és hibaátviteli tartalék

A bemeneti lista kerekítése a maximális felhasználás figyelembevételével, helyet hagyva a várható rövid távú növekedésnek és egy tartalék puffer marzs beépítésével.

Hogyan számolja ki az erőforrásokat a terminál szervereken?

Itt van egy gyakorlati számítási módszer, amely reméljük, hasznos lesz a KKV-k adminisztrációjában, valamint más kontextusokban is. Célja, hogy legalább egyszerűsítse a tervezést és a struktúra előkészítését. Ezt később finomítani is lehet, így a próbaidőszak alatt és azon túl is számíthat rá.

1. lépés: Számolja a párhuzamos felhasználókat, ne a teljes felhasználókat

Kezdje a számával, amely a rendszerben egyszerre aktív felhasználókat jelenti. Ez a szám határozza meg a szerver terhelését. Egy 50 névvel rendelkező felhasználóval rendelkező vállalkozás csúcsidőben csak 18-25 felhasználót csatlakoztathat egyidejűleg. Amikor egy munkamenet hoszt méretezéséről van szó, az egyidejű munkamenetek száma sokkal hasznosabb, mint a teljes létszám.

A fenntartható valós kapacitás terhelés alatti tesztelése előtt a tervezésnek meg kell kérdőjeleznie a becsléseket.

2. lépés: A munkaterhelések osztályozása könnyű, közepes vagy nehéz kategóriába

Következő lépésként csoportosítsa a felhasználókat a munkaterhelés alapján. Microsoft’s aktuális session-host útmutató javasolja a következő alap sűrűségi tartományokat a több munkamenetes környezetekhez, és a HP és más források egyetértenek:

• legfeljebb 6 könnyű felhasználó vCPU-nként,
• 4 közepes felhasználó vCPU-nként és
• 2 nehéz felhasználó vCPU-nként,

8 vCPU-val, 16 GB RAM-mal, 32 GB tárolással rendelkező minimum VM példa az említett munkaterhelési sávokon. A javaslatok között szerepel, hogy a több munkamenetes VM méreteket körülbelül 4 és 24 vCPU között tartsuk a jobb kapacitás-visszatérítés érdekében.

Egy egyszerű munkaterhelési térkép a KKV-k tervezéséhez így irányítaná a rendezést:

• Fény: egy üzleti alkalmazás, korlátozott böngészőhasználat, rövid ülések
• Közepes: Irodai alkalmazások, böngészőlapok, PDF-eszközök, mérsékelt multitasking
• Nehéz: ERP, nagyobb Excel fájlok, folyamatos böngészőhasználat, nyomtatás, több alkalmazás nyitva egész nap

Ezek alapvető tervezési sávok, nem garanciák. A cél az, hogy egy kiindulópontot válasszunk, amely a munkaterhelés viselkedésén alapul.

3. lépés: CPU kapacitás becslése

Miután a felhasználókat csoportosították, a CPU-t a felhasználók vCPU-ra vonatkozó megközelítéssel kell megbecsülni. Például, ha 24 egyidejű felhasználó többsége közepes felhasználó, a Microsoft alapértéke, amely körülbelül 4 felhasználó vCPU-nként, azt javasolja, hogy körülbelül 6 vCPU-val kezdjünk, majd kerekítsük fel egy praktikus hosztméretre, amely lehetővé teszi a burst kapacitást. Ha jobb burst kapacitást szeretne biztosítani a rövid távú CPU igénycsúcsok során, tervezzen alacsonyabb felhasználó-per-mag arányokat, mint amit egyébként tenné.

Ahogy talán nyilvánvalóvá vált, a CPU méretezésének nem szabad megállnia a matematikai minimumnál. Figyelembe kell vennie a bejelentkezési csúcsokat, az antivírus tevékenységet, a jelentési feladatokat és a rövid ideig tartó egyidejű alkalmazásindításokat.

4. lépés: A RAM követelmények becslése

A RAM-nak fedeznie kell az operációs rendszer, a magszolgáltatások, a munkamenet többlet és az alkalmazás memóriahasználat igényeit felhasználónként. Ahogy fentebb leírtuk, a jelenlegi Microsoft több munkamenetes alapértéke a könnyű, közepes és nehéz terhelési példáit 16 GB RAM minimumra párosította egy 8 vCPU kiindulási ponttal. Bár ez csak egy alapérték, mégis kézzelfogható kiindulási pontot nyújt a becsléshez.

Egy praktikus módszer egy kis- vagy középvállalkozásban az, hogy:

1. fenntartott memória az operációs rendszer és a platform szolgáltatások számára,
2. felhasználói osztályonkénti memória becslése munkamenetenként
3. többszörözés egyidejű munkamenetekkel,
4. majd adj hozzá egy biztonsági tartalékot.

PeteNetLive egy szándékosan széles irányelv 2 és 8 GB közötti felhasználónként az RD Session Host RAM tervezéséhez. Ez hasznos figyelmeztetés a nehéz munkamenetek alábecsülésével szemben, még akkor is, ha a pontos számot tesztelés során finomítani kell.

5. lépés: Ellenőrizze a tárolást és a profil többletet

A tárolást gyakran alábecsülik a terminál szerver tervezésében. A lassú, eldugult tárolás károsíthatja a bejelentkezéseket, a profilok betöltését, a temp fájlokat, az alkalmazások indítását és a nyomtatási sorokat, még akkor is, ha a CPU és a RAM még mindig elfogadhatónak tűnik.

• profil tárolás
• OS tárolás
• naplók: biztonsági és egyéb ilyen célokra

Ez az utolsó kategória jól megérdemli az értékelést, mivel gyorsan megnövekedhet az infrastruktúrája méretétől és a szükséges megfigyelés és védelem típusától függően.

PeteNetLive szerep-alapú bemutatója hasznos emlékeztetőként szolgál arra, hogy a session host általában az a hely, ahol a forráspresszió először megjelenik, míg más RDS szerepek gyakran viszonylag kisebb lábnyommal rendelkeznek. Ezt tartsd szem előtt, amikor a céged használati kapacitásának jelzőit keresed, mivel ez segíthet a tervek méretezésében.

6. lépés: Hagyjon helyet a csúcsok, növekedés és hibaátállás számára

A terminálkiszolgáló számológépnek nem szabad a „csak annyi” számra végződnie. Hagyjon tartalékot a következőhöz:

• reggeli bejelentkezési csúcsok
• javítás és AV vizsgálatok
• havi jelentési csúcsok
• várt felhasználói növekedés
• tárhelyhiba egy több szerveres tervezésben

Zárásként néhány jó működési tanács bármilyen környezet számára, amely egyetlen gazdagépről tovább lép, hogy vegye figyelembe a további gazdagépeket a szerver vagy a hipervizor elvesztése esetére.

Egyszerű Terminál Szolgáltató Számológép Módszer KKV-k és Szolgáltató Cégek Számára

Ez a kalkulátor logika szándékosan egyszerű. Célja, hogy egy védhető első becslést készítsen, ne pedig egy végső mércét, és hogy Ön ennek megfelelően alkalmazza.

Gyors tervezési formula

Használja ezt a sorrendet:

1. Szám párhuzamos felhasználók .
2. Rendezze őket csoportokba világos, közepes és nehéz csoportok.
3. Becsülés CPU a vCPU arányához viszonyított alapfelhasználói arány használatával.
4. Becsülés RAM az operációs rendszer többletén kívül, plusz sessionenkénti igény.
5. Ellenőrizze tárolás profil, ideiglenes és indítási teljesítmény.
6. Hozzáadás 20-30 százalékos mozgástér , majd felülvizsgálja a hibatűrési igényeket.

Ez tükrözi annak lényegét, ahogyan a méretezést általában keretezik: először a munkaterhelés, másodszor az arányok, a megfigyelés után pedig a finomítás. És most, miért ne néznénk meg egy előzetest a következőből? milyen formát ölthet , szerezzen pontos becslést és térképezze fel potenciális infrastruktúráját? Kulcsfontosságú eszköz a költségvetés tervezésekor.

Példa 1: 15 könnyű irodai felhasználó

Tegyük fel, hogy 15 egyidejű felhasználó hozzáfér egy közzétett üzleti alkalmazáshoz, plusz könnyű böngészőhasználat.

Ajánlott könnyű alapok használatával a nyers CPU becslés körülbelül 3 vCPU. A gyakorlatban ez túl szoros a burst kapacitás számára, így egy tervező inkább egy praktikusabb gazdagép profilt választana, mintsem a határra építene. Az ajánlások egy szélesebb 4-24 vCPU méretezési tartományt javasolnak, 8 vCPU és 16 GB RAM mint standard alapprofil a több munkamenetes terhelésekhez.

A RAM számára, tartalékoljon kapacitást az operációs rendszer és a szolgáltatások számára, majd adjon hozzá session memóriát minden felhasználóhoz. Ha a környezet stabil és az alkalmazás használata szűk, ez kényelmesen elférhet egy szerény hoszton, de ezt mégis érdemes validálni a pilot használat során.

Példa 2: 30 vegyes irodai és ERP felhasználó

Feltételezd:

• 18 közepes felhasználó
• 12 nehéz felhasználó

A tervezési gyorsítótár a közepes csoportot körülbelül 4 felhasználóval vCPU-nként, a nehéz csoportot pedig körülbelül 2 felhasználóval vCPU-nként kezeli. Ez körülbelül 4,5 vCPU-t jelent a közepes csoport számára és 6 vCPU-t a nehéz csoport számára, a többlet és a tartalék előtt. A gyakorlatban ez már eltérít a egyetlen, enyhén méretezett gazdagéptől, és inkább egy nagyobb gazdagép felé mutat, amelynek van tartaléka, vagy több munkamenet-gazdagép közötti megosztásra.

Itt válik értelmessé a „tervezze meg a szerver erőforrásokat” tanács. Együtt ERP ahogyan bármely vállalati környezetben, a cél nem csupán az, hogy a felhasználókat valahová elhelyezzük. A cél nem csupán az, hogy a felhasználókat valahová elhelyezzük. A cél az, hogy a legforgalmasabb időszakokban is elfogadható válaszidőket tartsunk.

Példa 3: Mikor osszuk szét a felhasználókat több hoszton

Miután a számítás egy sűrű gazdagépet hoz létre korlátozott robbanási kapacitással, a jobb válasz építészeti lehet, nem pedig függőleges skálázás. A munkamenet-gazdagépeket be lehet állítani a nehéz feladatok elvégzésére, míg az olyan szerepek, mint az RD Connection Broker, Gateway és Licensing különböző erőforrás-profilokat kaphatnak. A felhasználói terhelés több gazdagép között történő megosztása valószínűleg javítja a rugalmasságot, a karbantartási rugalmasságot és a hibatűrés tervezését.

MSP-k számára ez gyakran az a döntő pillanat, amikor a terminál szerver kalkulátor farmméretezési beszélgetéssé válik, ahelyett, hogy egyetlen szerverről beszélgetnénk.

Melyek a leggyakoribb méretezési hibák, amelyek általában megszakítják a terminálkiszolgáló teljesítményét?

A méretezési hibákat általában nem csupán a matematikai számítások okozzák. Ezek helytelen feltételezésekből erednek.

A licenc zavaros összekeverése a teljesítménykapacitással

A licencelés megmondja, hogyan van a hozzáférés hozzárendelve és konfigurálva. Nem mondja meg, hány egyidejű felhasználót támogat egy szerver elfogadható teljesítménnyel.

Figyelmen kívül hagyva a böngésző- és nyomtatásigényes munkameneteket

Sok környezet még mindig alábecsüli, hogy a modern böngészőhasználat, a PDF-kezelés és a nyomtatás mennyi terhelést adhat egy munkamenet gazdagéphez. Ezek a tevékenységek egy felhasználói csoportot könnyűről közepesre, vagy közepesről nehézre is áthelyezhetnek, még akkor is, ha az üzleti alkalmazás maga szerény.

Csak az átlagos terhelés méretezése

Az átlagos terhelés ritkán az a pillanat, amikor a felhasználók panaszkodnak. A panaszok bejelentkezési viharok, egyidejű fájlmegnyitások, jelentésfuttatások vagy reggeli csúcsidők alatt fordulnak elő. A Microsoft megjegyzi, hogy a jobb robbanási kapacitás fontosabb alacsonyabb felhasználó-per-mag arányoknál, mert támogatja a hely fenntartását a maximális sűrűség helyett.

Az RDS stack többi részének elfelejtése

A munkamenet gazda a fő erőforrás-felhasználó, de nem ez az egyetlen szerep a környezetben. A PeteNetLive szerepmegosztása hasznos emlékeztető, hogy a kapcsolatközvetítőt, a kaput, a webes hozzáférést és a licencelést külön kell figyelembe venni, amikor a telepítés túlnő egy kis, egy gazdás beállításon.

Miért kellene a monitorozásnak érvényesítenie a méretezési becsléseidet?

A terminálszerver-kalkulátor egy tervezési alapot ad. Nem ad bizonyítékot. A bizonyítékhoz figyelemmel kell kísérnie a használatot.

A kiindulóponttól a bizonyítékig: a monitoring mint alapvető elem

Korábbi cikkünkben elmagyarázzuk, miért a fenntartható felhasználói kapacitás egy gyakorlati monitoring kérdés. Itt az a cél, hogy bemutassuk, hogyan lehet megbecsülni ennek a kapacitásnak az első verzióját a bevezetés előtt. A monitoring számos olyan számot fog biztosítani, amelyet említettünk. Javasoljuk, hogy laboratóriumi környezetben tesztelje az elképzelt igényeit.

Hol hoz különbséget a TSplus Server Monitoring?

TSplus Szerver Figyelés illik miután a méretezési becslést telepítették. Segít ellenőrizni, hogy a CPU telítettsége, a memória nyomás, a tárolási szűk keresztmetszetek vagy a használati csúcsok megfelelnek-e a tervezés során használt feltételezéseknek. Ez különösen hasznos a kis- és középvállalati IT-adminisztrátorok és a szolgáltatásnyújtók számára, akiknek bizonyítékra van szükségük egy gazda újraméretezése, a felhasználók újraelosztása vagy egy újabb szerver hozzáadása előtt.

A források tervezésének ismerete mellett hogyan tudhatná még, hogy a számítás helyes volt, mint a monitorozó rendszerek révén? A Server Monitoring valós idejű monitorozást és értesítéseket biztosít, hogy tájékoztatva legyen, amikor a jelzők elérik a beállított küszöbértékeket. .

TSplus szoftver az alkalmazások és asztalok biztonságos, folyamatos szállításához

A TSplus Remote Access a szélesebb történet szállítási rétegéhez tartozik, míg az Advanced Security kifejezetten az alkalmazás szerverek védelmére készült. Ezenkívül a TSplus Remote Support egy alapvető eszközkészletet biztosít a problémák elhárításához és ezeknek a szervereknek a karbantartásához, valamint még sok máshoz, bármely helyszínről. Miután a környezet megfelelően van méretezve, a TSplus Remote Access egyszerűbben fogja közzétenni az asztalokat és alkalmazásokat, mint a Citrix, és anélkül, hogy túllépné a költségvetését. Az olyan funkciók tesztelése, mint a webes hozzáférés és a központosított szállítás, ízelítőt ad arról, hogyan léphet túl az ad hoc RDP hozzáférésen.

Következtetés

A terminál szerver kalkulátornak nem szabad varázslatos választ ígérnie. Most itt az idő, hogy lépésről lépésre kiszámoljuk a terminál szerver erőforrásait: kezdjük a párhuzamos felhasználókkal, osztályozzuk a terhelés intenzitását, becsüljük meg a CPU-t és a RAM-ot a reális munkamenet viselkedés alapján, ellenőrizzük a tárolást, majd adjunk hozzá egy tartalékot a csúcsok, a növekedés és a hibaátállás miatt.

Rendszeradminisztrátorként, SMB IT adminisztrátoroként vagy MSP-ként ez egy gyakorlati első becslést ad. Ezt követően a valódi feladat a validálás. Gondosan tervezzen, óvatosan telepítsen, majd használja a megfigyelési adatokat annak megerősítésére, hogy a gazda, vagy gazda farm fenntarthatja a felhasználói élményt, amelyet szándékozik.