Kuinka laskea resursseja terminaalipalvelimella: käytännön kokoamismenetelmä

Terminaalipalvelinlaskin ei yleensä ole kirjaimellinen laskin. Useimmissa PK-yritys- ja MSP-ympäristöissä se on suunnittelumenetelmä, jota käytetään arvioimaan, kuinka paljon CPU:ta, RAM-muistia, tallennustilaa ja varaa terminaalipalvelin tarvitsee ennen kuin käyttäjät alkavat valittaa. Todellinen kysymys avainsanan takana on käytännönläheinen: kuinka lasket resurssit terminaalipalvelimella riittävän hyvin, jotta voit ottaa käyttöön luottavaisin mielin, välttää ylilyönnit ja vähentää suorituskykypullonkaulojen riskiä ?

Mitä terminaalipalvelinlaskurin tulisi oikeastaan laskea?

Hyödyllisen terminaalipalvelimen laskurin tulisi arvioida enemmän kuin "käyttäjiä palvelinta kohti." Järjestelmänvalvojana sen tulisi auttaa sinua suunnittelemaan CPU, RAM, tallennus suorituskyky, profiilitallennus ja kapasiteettivaraus realististen samanaikaisten käyttötilanteiden mukaan. Microsoftin ohjeet etätyöpöytäistuntojen isännille kehystävät koon työkuormatyypin ja ehdotettujen käyttäjien per vCPU ympärille, eivätkä yleisen yhden koon rajoituksen ympärille.

Miksi pelkkä käyttäjämäärä ei riitä laskemaan resursseja terminaalipalvelimella?

Istunnon käyttö

Muista, että kaksi ympäristöä, joissa on sama määrä käyttäjiä, voivat tuottaa hyvin erilaisia tuloksia. Oletamme, että tiedät jo, kuinka monta käyttäjää pääsee infrastruktuuriisi, joten on hyvä olla otettu huomioon lisensointi ja CALit käytännön työ voi alkaa.

Kuvittele, kuinka viisitoista käyttäjää, jotka avaavat yhden liiketoimintasovelluksen, voivat aiheuttaa kohtuullisen kuormituksen isännälle. Samaan aikaan viisitoista käyttäjää, jotka käyttävät täyttä etätyöpöytää selaimilla, Office-sovelluksilla, PDF-työkaluilla, tulostuksella ja taustasynkronoinnilla, voivat luoda paljon raskaamman jalanjäljen. Kokoamismallit heijastavat tätä eroa erottamalla kevyet, keskikokoiset ja raskaat monikäyttöiset kuormitukset.

Ero on tärkeä, koska "30 käyttäjää" ei itsessään ole kapasiteettiluku. Se on merkityksellinen vasta kun määrittelet. mitä käyttäjät tekevät ja käyttävät huippuaikoina.

Palvelimen käyttö

Muista myös tärkeä ero, joka on erittäin merkittävä: laboratorioita tai pientä toimistoa varten saatat suunnitella yhden palvelimen, koska se käsittelee vähemmän samanaikaisia käyttäjäistuntoja, kun taas tuotantoa varten suunnittelet todennäköisesti farmia. Todellakin, erilliset roolit ovat tarpeen suorituskyvyn parantamiseksi, vianetsinnän yksinkertaistamiseksi ja turvallisuuden lukitsemiseksi, joten yleinen jako olisi:

• 1 palvelin Brokerille, Webille ja Lisensoinnille
• 1 tai useampi palvelin Istuntopalvelimelle
• 1 RD Gateway omalla palvelimellaan ulkoista pääsyä varten.

Mennäksesi askeleen pidemmälle, huomaat myös, että palvelintyypit, muisti jne. tulevat mukaan ja saatat haluta sisällytä SSD suuremmissa kokoonpanoissa esimerkiksi. Silti tämä on vain maininta, jotta olet tietoinen mahdollisuuksista.

Mitkä neljä syötettä muovaavat resurssisuunnittelua?

Seuraavaksi, luotettavampaa kuin suoraan laitteistotietojen hyppääminen, tässä on neljä syötettä, jotka on kerättävä ennen laskemisen aloittamista. Tämä ylävirran työ välttää päällekkäisyyksiä lisensointikysymysten kanssa siitä, kuka voi yhdistää ja minkä Microsoftin sääntöjen mukaan. Keskeinen huolenaihe tässä on, kuinka paljon resursseja istuntopalvelimen tarvitsee pysyäkseen reagoivana. Aiemmassa artikkelissamme käsiteltiin lisensointi ja palvelinkapasiteetti joten voimme kehittää täällä käytännön asioita kaiken laskemisesta järjestelmällisesti suunnitellaksemme oikein.

Siksi sinun on laskettava yhteen:

Samanaikaiset aktiiviset käyttäjät

Meidän on edelleen sisällytettävä tämä olennainen luku, koska samanaikaisesti käynnissä olevien istuntojen määrä vaikuttaa varmasti palvelimen suorituskykyyn. Huomaa, että samanaikainen määrä voi olla riippumaton kokonaismäärästä.

Käyttökuormaluokka käyttäjäryhmää kohti

Arvioiminen siitä, kuinka paljon yksi käyttäjä tai käyttäjäryhmä käyttää resursseja, on ensimmäinen todellisuuden tarkistus. Tietyt ryhmät tai yksilöt kuluttavat väistämättä enemmän niitä tehtäviä, joita he suorittavat. Siksi raskaat käyttäjät on tunnistettava.

Sovellus- ja istuntotyyppi

On myös erittäin hyödyllistä paikantaa tietyt sovellukset, sillä tietyt käyttäjät monopolisoivat suuria määriä resursseja sen mukaan, mitä he käyttävät.

Huippu, kasvu ja vikasietoisuusmarginaali

Kokoa tämä syötteiden lista huomioimalla maksimaalinen käyttö, jättäen tilaa odotetulle lyhytaikaiselle kasvulle ja rakentaen varajärjestelmän puskurimarginaalin.

Miten lasket resurssit terminaalipalvelimilla?

Tässä on käytännöllinen laskentamenetelmä, jonka toivomme olevan hyödyllinen pk-yritysten hallinnassa sekä muissa yhteyksissä. Sen tavoitteena on ainakin yksinkertaistaa suunnittelua ja rakenteellista valmistautumista. Sen pitäisi myöhemmin soveltua myös tarkentamiseen, jotta voit luottaa siihen pilottivaiheen aikana ja sen jälkeen.

Vaihe 1: Laske samanaikaiset käyttäjät, ei kokonaiskäyttäjiä

Aloita samanaikaisesti aktiivisten käyttäjien määrästä. Tämä on luku, joka vaikuttaa palvelimen kuormitukseen. Yrityksellä, jossa on 50 nimettyä käyttäjää, saattaa olla vain 18–25 samanaikaisesti yhteydessä hupeakäyttöaikoina. Istuntopalvelimen mitoittamisessa samanaikaisten istuntojen määrä on paljon hyödyllisempi kuin kokonaiskäyttäjämäärä.

Ennen kestävän todellisen kapasiteetin testaamista kuormituksen alla, suunnittelun on haastettava arviot.

Vaihe 2: Luokittele kuormitukset kevyiksi, keskikokoisiksi tai raskaimmiksi

Seuraavaksi lajittele ryhmän käyttäjät työkuorman mukaan. Microsoftin nykyinen istunto-isäntä ohjeistus ehdottaa seuraavia perus tiheysalueita monikäyttöympäristöille, ja HP sekä muut lähteet ovat samaa mieltä:

• enintään 6 kevyttä käyttäjää per vCPU,
• 4 keskikokoista käyttäjää per vCPU ja
• 2 raskasta käyttäjää per vCPU,

mukana vastaavasti 8 vCPU:lla, 16 GB RAM:lla, 32 GB tallennustilalla vähimmäis VM-esimerkki näiden kuormitustasojen yli. Suositukset sisältävät myös monikäyttöisten VM-kokojen pitämisen suunnilleen 4 ja 24 vCPU:n välillä paremman kapasiteettituoton saavuttamiseksi.

Yksinkertainen työkuormakartta PK-yritysten suunnittelua varten ohjaisi siten lajittelua:

• Valo: yksi liiketoimintasovellus, rajoitettu selainkäyttö, lyhyet istunnot
• Keskikokoinen: Toimisto-ohjelmat, selainvälilehdet, PDF-työkalut, kohtuullinen moniajo
• Raskas: ERP, suuremmat Excel-tiedostot, jatkuva selaimen käyttö, tulostaminen, useita sovelluksia auki koko päivän

Nämä ovat perussuunnittelubändejä, eivät takeita. Tarkoitus on valita lähtöpiste, joka perustuu työkuormakäyttäytymiseen.

Vaihe 3: Arvioi CPU-kapasiteetti

Kun käyttäjät on ryhmitelty, arvioi CPU käyttäjien per vCPU -lähestymistavalla. Esimerkiksi, jos 24 samanaikaista käyttäjää ovat pääasiassa keskikokoisia käyttäjiä, Microsoftin peruslinja noin 4 käyttäjää per vCPU ehdottaa aloittamista noin 6 vCPU:lla, ja sitten pyöristetään käytännön isäntäkokoon, jossa on ylimääräistä kapasiteettia. Jos haluat tarjota paremman ylimääräisen kapasiteetin lyhytaikaisissa CPU-kysynnän huipuissa, suunnittele alhaisemmat käyttäjä-per-ydin -suhteet kuin muuten saattaisit.

Kuten on saattanut käydä ilmi, CPU-kokoamisen ei tulisi pysähtyä matemaattiseen minimimäärään. Sen tulisi ottaa huomioon kirjautumispiikit, virustorjunta-aktiviteetti, raportointitehtävät ja lyhyet jaksot samanaikaisista sovellusten käynnistyksistä.

Vaihe 4: Arvioi RAM-vaatimukset

RAM:n tulisi kattaa käyttöjärjestelmän, ydinpalveluiden, istuntokuormituksen ja sovellusten muistin käytön tarpeet käyttäjää kohti. Kuten edellä on kuvattu, nykyinen Microsoftin monikäyttöistuntojen peruslinja yhdistää kevyet, keskikokoiset ja raskaat kuormitusesimerkit vähintään 16 Gt RAM:iin 8 vCPU:n lähtöpisteenä. Vaikka tämä on vain peruslinja, se tarjoaa silti konkreettisen lähtöpisteen arviointia varten.

Käytännöllinen menetelmä pienessä tai keskikokoisessa yrityksessä on:

1. varaa muistia käyttöjärjestelmälle ja alustapalveluille,
2. arvioi istuntokohtainen muisti käyttäjäluokan mukaan,
3. kerroin samanaikaisten istuntojen määrästä,
4. sitten lisää turvallisuusmarginaali.

PeteNetLive antaa yhden tarkoituksellisesti laaja nyrkkisääntö 2–8 Gt käyttäjää kohti RD Session Hostin RAM-suunnittelua varten. Tämä on hyödyllistä varoituksena raskaita istuntoja aliarvioitaessa, vaikka tarkka luku onkin tarkennettava testauksessa.

Vaihe 5: Tarkista tallennustila ja profiilin ylikuormitus

Tallennusta aliarvioidaan usein terminaalipalvelimen suunnittelussa. Hidas, tukkeutunut tallennus voi vaikuttaa kirjautumisiin, profiilien lataamiseen, väliaikaisiin tiedostoihin, sovellusten käynnistämiseen ja tulostusjonoon, vaikka CPU ja RAM näyttäisivät edelleen hyväksyttäviltä.

• profiilitallennus
• OS-tallennus
• lokit: turvallisuus- ja muiden tällaisten tarkoitusten vuoksi

Tämä viimeinen kategoria on ehdottomasti arvioinnin arvoinen, sillä se voi nopeasti paisua infrastruktuurisi koon ja tarvitsemasi valvonnan ja suojauksen tyypin mukaan.

PeteNetLive:n rooli roolilta esitys toimii hyödyllisenä muistutuksena siitä, että istunnon isäntä on yleensä se paikka, jossa resurssipaine ilmenee ensimmäisenä, kun taas muut RDS-roolit ovat usein suhteellisen pienempiä. Pidä tämä mielessä etsiessäsi merkkejä yrityksesi käyttökapasiteetin nostamisesta, sillä se voi tukea suunnitelmien arvioimista.

Vaihe 6: Lisää liikkumavaraa huippuja, kasvua ja vikasietoisuutta varten

Ei terminaalipalvelinlaskurin tulisi päättyä "juuri tarpeeksi" -lukuun. Lisää varaa:

• aamupäivän kirjautumishuiput
• korjaaminen ja AV-skannaukset
• kuukausittaiset raportointihuiput
• odotettu käyttäjäkasvu
• isäntävika monipalvelinrakenteessa

Lopuksi, hyvä käytännön neuvo kaikille ympäristöille, jotka siirtyvät yhden isäntäpalvelimen yli, on ottaa huomioon lisäisännät palvelimen tai hypervisorin menetyksen varalta.

Yksinkertainen Terminal Server -laskentamenetelmä pk-yrityksille ja MSP:ille

Tämä laskurin logiikka on tarkoituksella yksinkertainen. Sen on tarkoitus tuottaa puolustettavissa oleva ensimmäinen arvio, ei lopullinen vertailuarvo, ja sinun on mukautettava se sen mukaisesti.

Nopea suunnittelukaava

Käytä tätä järjestystä:

1. Laskuri samanaikaiset käyttäjät .
2. Lajittele ne sisään kevyt, keskikokoinen ja raskas ryhmät.
3. Arvio CPU käyttäen peruslinjaa käyttäjien ja vCPU-suhteelle.
4. Arvio RAM käyttöjärjestelmän ylikuormituksesta plus istuntokohtaisesta kysynnästä.
5. Tarkista varastointi profiili, lämpötila ja käynnistys suorituskyky.
6. Lisää 20–30 prosentin liikkumavara , sitten tarkista vikasietoisuuden tarpeet.

Tämä heijastaa sitä, miten koon määrittely yleensä kehystetään: työkuorma ensin, suhteet toisena, hienosäätö havainnon jälkeen. Ja nyt, miksi et saisi ennakkokatsauksen minkä muodon se voisi ottaa Hanki tarkka arvio ja kartoita mahdollinen infrastruktuurisi? Avainväline budjettisi suunnittelussa.

Esimerkki 1: 15 kevyttä toimistokäyttäjää

Oletetaan, että 15 samanaikaista käyttäjää käyttää julkaistua liiketoimintasovellusta sekä kevyttä selaamista.

Suositeltuja kevyitä peruslinjoja käyttäen raaka CPU-arvio on noin 3 vCPU:ta. Käytännössä tämä on liian tiukka purkautumiskapasiteetille, joten suunnittelija siirtyisi käytännöllisempään isäntäprofiiliin sen sijaan, että rakentaisi äärirajoille. Löydät neuvoja, jotka suosivat laajempaa 4–24 vCPU-kokoaluetta, jossa 8 vCPU ja 16 GB RAM ovat standardiperusprofiili monikäyttökuormille.

Varaa RAM:lle kapasiteetti käyttöjärjestelmälle ja palveluille, lisää sitten istuntomuisti jokaiselle käyttäjälle. Jos ympäristö on vakaa ja sovelluksen käyttö on rajallista, tämä voisi mahtua mukavasti vaatimattomaan isäntään, mutta se tulisi silti validoida pilottikäytön aikana.

Esimerkki 2: 30 sekoitettua toimisto- ja ERP-käyttäjää

Oleta:

• 18 keskikokoista käyttäjää
• 12 raskasta käyttäjää

Suunnittelun oikopolku käsittelisi keskikokoista ryhmää noin 4 käyttäjällä per vCPU ja raskasta ryhmää noin 2 käyttäjällä per vCPU. Tämä tarkoittaa noin 4,5 vCPU:ta keskikokoiselle ryhmälle ja 6 vCPU:ta raskaalle ryhmälle, ennen ylikuormitusta ja varaa. Käytännössä tämä viittaa jo pois yhdestä kevyesti mitoitetusta isäntäpalvelimesta ja kohti joko suurempaa isäntäpalvelinta, jossa on varaa, tai jakautumista useiden istuntoisäntäpalvelimien kesken.

Tässä on kohta, jossa neuvo "suunnittele palvelinresurssit" saa merkityksensä. Kanssa ERP kuten missä tahansa yrityskontekstissa, tavoite ei ole vain sijoittaa käyttäjiä johonkin. Tavoite ei ole vain sijoittaa käyttäjiä johonkin. Tavoite on pitää vasteajat hyväksyttävinä päivän kiireisimpinä aikoina.

Esimerkki 3: Milloin jakaa käyttäjät useille isännille

Kun laskenta tuottaa tiheän isännän, jolla on rajoitettu purkukapasiteetti, parempi vastaus voi olla arkkitehtoninen sen sijaan, että käytetään pystysuoraa skaalausta. Istuntovieraat voidaan asettaa tekemään raskasta työtä, kun taas rooleille, kuten RD-yhteysvälittäjä, Gateway ja lisensointi, voidaan antaa erilaisia resurssiprofiileja. Käyttäjäkuorman jakaminen useiden isäntien kesken parantaa todennäköisesti resilienssiä, ylläpidon joustavuutta ja vikasietoisuussuunnittelua.

MSP:ille tämä on usein se käännekohta, jossa terminaalipalvelinlaskuri muuttuu farmikoon keskusteluksi sen sijaan, että se olisi yksittäisen palvelimen keskustelu.

Mitkä yleiset koon virheet tyypillisesti heikentävät terminaalipalvelimen suorituskykyä?

Kokoamisvirheet eivät yleensä johdu pelkästään matematiikasta. Ne johtuvat vääristä oletuksista.

Hämmentävä lisensointi suorituskyvyn kapasiteetin kanssa

Lisensointi kertoo, miten pääsy on määritetty ja konfiguroitu. Se ei kerro, kuinka monta samanaikaista käyttäjää palvelin tukee hyväksyttävällä suorituskyvyllä.

Selaimen raskaita ja tulostamiseen painottuneita istuntoja ei oteta huomioon

Monet ympäristöt aliarvioivat edelleen, kuinka paljon kuormitusta nykyaikaisen selaimen käyttö, PDF-tiedostojen käsittely ja tulostaminen voivat lisätä istuntopalvelimelle. Nämä toiminnot voivat siirtää käyttäjäryhmän kevyestä keskitasoon tai keskitasosta raskaaseen, vaikka liiketoimintasovellus itsessään olisi vaatimaton.

Kokoaminen vain keskimääräiselle kuormalle

Keskimääräinen kuormitus ei juuri koskaan ole hetki, jolloin käyttäjät valittavat. Valituksia esiintyy kirjautumistormien, samanaikaisten tiedostojen avauksien, raportointisuoritusten tai aamuhuippujen aikana. Microsoft huomauttaa, että parempi purkukapasiteetti on tärkeää alhaisemmilla käyttäjäytimen suhdeluvuilla, koska se tukee tilan jättämistä maksimaalisen tiheyden sijaan.

Unohtamalla loput RDS-pinosta

Istuntoisäntä on pääasiallinen resurssien kuluttaja, mutta se ei ole ainoa rooli ympäristössä. PeteNetLive:n roolijako on hyödyllinen muistutus ottaa huomioon Yhteysvälittäjä, Portti, Verkkopääsy ja Lisensointi erikseen, kun käyttöönotto kasvaa yli pienen yhden isännän asetelman.

Miksi valvonnan tulisi vahvistaa kokoarvioitasi?

Terminaalipalvelinlaskin antaa sinulle suunnitteluperustan. Se ei anna sinulle todisteita. Todisteita varten sinun on seurattava käyttöä.

Peruslinjasta todisteeseen: valvonta olennaisena osana

Aiemmassa artikkelissamme selitämme, miksi kestävä käyttäjäkapasiteetti on käytännöllinen seurantakysymys. Tässä tavoitteena on ollut näyttää, kuinka arvioida tuon kapasiteetin ensimmäinen versio ennen käyttöönottoa. Seuranta tuo sinulle monia mainitsemistamme laskelmista. Suosittelemme, että testaat laboratoriokontekstissa arvioidaksesi suunniteltuja tarpeitasi.

Missä TSplus Server Monitoring tekee eron?

TSplus Server Monitoring sopii sijoituksen arvioinnin jälkeen. Se auttaa varmistamaan, vastaavatko CPU-saturaatio, muistin paine, tallennuspullonkaulat tai käyttöpiikit suunnittelussa käytettyjä oletuksia. Tämä on erityisen hyödyllistä PK-yritysten IT-johdolle ja MSP:ille, jotka tarvitsevat todisteita ennen isännän koon muuttamista, käyttäjien uudelleenjakamista tai toisen palvelimen lisäämistä.

Ymmärtämisen lisäksi siitä, miten resursseja projisoidaan, miten muuten voit tietää, oliko laskelma oikea kuin valvomalla järjestelmiä? Server Monitoring tarjoaa sinulle reaaliaikaisen valvonnan ja hälytykset, jotta pysyt ajan tasalla aina, kun merkit saavuttavat asettamasi kynnykset. .

TSplus-ohjelmisto sovellusten ja työpöytien turvalliseen ja jatkuvaan toimitukseen

TSplus Remote Access kuuluu toimituskerrokseen laajemmassa tarinassa, kun taas Advanced Security on räätälöity suojaamaan sovelluspalvelimia. Lisäksi TSplus Remote Support tarjoaa paketin olennaisista työkaluista näiden palvelimien vianetsintään ja ylläpitoon mistä tahansa sijainnista. Kun ympäristö on oikein mitoitettu, TSplus Remote Access julkaisee työpöytiä ja sovelluksia yksinkertaisemmin kuin Citrix ja ilman budjetin ylittämistä. Ominaisuuksien, kuten verkkopääsyn ja keskitetyn toimituksen, testaaminen antaa sinulle käsityksen siitä, kuinka voit siirtyä ad hoc RDP-pääsyn yli.

Päätelmä

Terminaalipalvelimen laskurin ei tulisi luvata taikavastausta. Nyt on aika laskea terminaalipalvelimen resursseja vaiheittain: aloita samanaikaisista käyttäjistä, luokittele kuormituksen intensiivisyys, arvioi CPU ja RAM realistisesta istuntokäyttäytymisestä, tarkista tallennustila ja lisää sitten marginaali huippuja, kasvua ja vikasietoisuutta varten.

Järjestelmänvalvojana, SMB IT -valvojana tai MSP:nä tämä antaa sinulle käytännön ensimmäisen arvion. Siitä eteenpäin todellinen kurinalaisuus on validointi. Suunnittele huolellisesti, ota käyttöön varovaisesti ja käytä sitten seurantatietoja vahvistaaksesi, onko isäntä tai isäntätila voi ylläpitää käyttäjäkokemusta, jonka aiot.