Как да изчислим ресурсите на терминален сървър: Практически метод за определяне на размерите

Калкулаторът за терминален сървър рядко е буквален калкулатор. В повечето среди на малки и средни предприятия (SMB) и управлявани услуги (MSP) това е метод за планиране, използван за оценка на необходимото количество CPU, RAM, хранилище и резерв на терминален сървър, преди потребителите да започнат да се оплакват. Истинският въпрос зад ключовата дума е практичен: как да изчислите ресурсите на терминален сървър достатъчно добре, за да разположите с увереност, да избегнете прекомерни разходи и намалете риска от проблеми с производителността ?

Какво трябва всъщност да изчислява един терминален сървър?

Полезен калкулатор за терминален сървър трябва да оценява повече от "потребители на сървър". Като администратор, той трябва да ви помогне да планирате производителността на CPU, RAM, съхранение, профилно съхранение и капацитет под реалистично паралелно използване. Насоките на Microsoft за хостове на сесии за Remote Desktop определят размерите в зависимост от типа на натоварването и предложените потребители на vCPU, а не около общ лимит за свързване.

Защо само броят на потребителите не е достатъчен, за да се изчислят ресурсите на терминален сървър?

Използване на сесия

Имайте предвид, че две среди с едно и също количество потребители могат да произведат много различни резултати. Предполагаме, че вече знаете колко потребители ще имат достъп до вашата инфраструктура, така че имайки разглеждани лицензи и CALs практическата работа може да започне.

Представете си как петнадесет потребители, отварящи едно бизнес приложение, могат да поставят скромно натоварване на хост. Междувременно, петнадесет потребители, работещи с пълен отдалечен десктоп с браузъри, офис приложения, PDF инструменти, печат и синхронизация на заден план, могат да създадат много по-тежък отпечатък. Моделите за размери отразяват тази разлика, като разделят леките, средните и тежките многосесийни натоварвания.

Разграничението е важно, защото "30 потребители" не е цифра за капацитет сама по себе си. То има значение само след като дефинирате какво правят и използват тези потребители по време на пиковите периоди.

Използване на сървър

Също така запомнете важната разлика, която има огромно значение: за лаборатории или малки офиси, може да планирате един сървър, тъй като той ще поддържа по-малко едновременни потребителски сесии, докато за продукция вероятно ще планирате ферма. Всъщност, отделни роли са необходими за подобряване на производителността, опростяване на отстраняването на проблеми и затваряне на сигурността, така че общото разделение би било:

• 1 сървър за брокер, уеб и лицензиране
• 1 или повече сървъри за хост на сесии
• 1 RD Gateway на собствен сървър за външен достъп.

Да отидете една стъпка напред, ще откриете, че типът на сървъра, паметта и т.н. ще играят роля и може да искате да включете SSD в по-големи настройки например. Въпреки това, това е само споменаване, за да ви информира за възможностите.

Кои четири входа оформят планирането на ресурсите?

Следващото, по-надеждно от директното скок на хардуерни числа, ето четири входа, които да съберете преди да започнете да броите. Тази предварителна работа избягва припокриване с въпроси за лицензиране относно това кой може да се свърже и при какви правила на Microsoft. Централната загриженост тук е колко ресурс е необходим на хост сесия, за да остане отзивчив. Нашата предишна статия обхвана лицензиране и капацитет на сървъра така че можем да разработим тук практическите аспекти на методичното броене на всичко, за да планираме правилно.

Следователно, трябва да сумирате:

Съвместно активни потребители

Все още трябва да включим този основен номер, тъй като броят на сесиите, които се изпълняват паралелно, определено ще повлияе на производителността на сървъра. Обърнете внимание, че броят на паралелните сесии може да бъде независим от общия брой.

Клас на натоварване на потребителска група

Оценяването на това колко много един потребител или група потребители ще използват ресурси е първият реален тест. Определени групи или индивиди неизбежно ще изразходват повече от задачите, които изпълняват. Затова е необходимо да се идентифицират тежките потребители.

Тип на приложението и сесията

Също така е много полезно да се определят конкретни приложения, тъй като определени потребители ще монополизират големи количества ресурси в зависимост от това кои от тях използват.

Пиков, растеж и резервен марж

Окръгнете този списък с входове, като отчетете максималната употреба, оставяйки място за очакван растеж на по-кратки срокове и изграждайки буферна граница за резервиране.

Как да изчислите ресурсите на терминалните сървъри?

Тук е практичен метод за изчисление, който се надяваме да бъде полезен в администрацията на малки и средни предприятия, както и в други контексти. Целта му е поне да опрости планирането и структурата на подготовката. След това той трябва да се поддаде на усъвършенстване, за да можете да разчитате на него през пилотния период и след това.

Стъпка 1: Брой на едновременни потребители, а не на общите потребители

Започнете с броя на потребителите, които са активни едновременно. Това е числото, което определя натоварването на сървъра. Бизнес с 50 именувани потребители може да има само 18 до 25 свързани едновременно по време на пиковите часове. Когато определяте размерите на хоста на сесията, броят на едновременните сесии е много по-полезен от общия брой.

Преди да се тества устойчивата реална производителност под натоварване, планирането трябва да оспори оценките.

Стъпка 2: Класифицирайте натоварванията като леки, средни или тежки

След това сортирайте груповите потребители по натоварване. Microsoft’s настояща насока за хост на сесия предлага следните основни плътностни диапазони за много-сесийни среди и HP и други източници се съгласяват:

• до 6 леки потребители на vCPU,
• 4 средни потребители на vCPU и
• 2 тежки потребители на vCPU,

съответно с пример за VM с минимум 8 vCPU, 16 GB RAM и 32 GB хранилище в тези работни натоварвания. Препоръките също включват поддържане на размерите на много-сесийните VM приблизително между 4 и 24 vCPU за по-добри капацитетни възвръщаемости.

Проста карта на натоварването за планиране на МСП би насочила сортирането:

• Светлина: едно бизнес приложение, ограничено използване на браузър, кратки сесии
• Среден: Офис приложения, браузър табове, PDF инструменти, умерено многозадачно управление
• Тежък: ERP, по-големи Excel файлове, постоянно използване на браузър, печатане, множество приложения отворени през целия ден

Това са основни планиращи диапазони, а не гаранции. Целта е да се избере отправна точка, основана на поведението на работното натоварване.

Стъпка 3: Оценка на капацитета на CPU

След като потребителите бъдат групирани, оценете CPU с подхода потребители на vCPU. Например, ако 24 едновременни потребители са предимно средни потребители, основната линия на Microsoft от около 4 потребители на vCPU предполага започване около 6 vCPU, след което закръглете до практичен размер на хоста с резерв за натоварване. Ако желаете да осигурите по-добра капацитет за натоварване по време на краткосрочни пикове на търсенето на CPU, планирайте по-ниски съотношения потребители на ядро, отколкото бихте направили в противен случай.

Както може да е станало очевидно, определянето на размера на CPU не трябва да спира на математическия минимум. То трябва да отчита пикове на вход, активност на антивируса, задачи за отчитане и кратки периоди на едновременни стартирания на приложения.

Стъпка 4: Оценете изискванията за RAM

RAM трябва да покрива нуждите на операционната система, основните услуги, разходите за сесия и използването на паметта на приложението на потребител. Както е описано по-горе, текущата основна линия на Microsoft за многосесийност свързва примери за лека, средна и тежка натовареност с минимум 16 GB RAM за отправна точка с 8 vCPU. Въпреки че това е само основна линия, тя все пак предоставя осезаема отправна точка за оценка.

Практически метод в малък или среден бизнес е:

1. резервирайте памет за операционната система и платформените услуги,
2. оценка на паметта на сесия на потребителски клас,
3. умножете по едновременни сесии,
4. след това добавете марж за безопасност.

PeteNetLive предоставя едно уместно широко правило от 2 до 8 GB на потребител за планиране на RAM за RD Session Host. Това е полезно като предупреждение срещу недооценяване на тежките сесии, дори ако точният брой трябва да бъде уточнен в тестовете.

Стъпка 5: Проверете натоварването на хранилището и профила

Съхранението често се подценява при планирането на терминални сървъри. Бавното запушено съхранение може да навреди на влизанията, зареждането на профили, временните файлове, стартирането на приложения и спулирането на печат дори когато CPU и RAM все още изглеждат приемливи.

• профилно хранилище
• OS хранилище
• дневници: за сигурност и други подобни цели

Тази последна категория определено заслужава оценка, тъй като може бързо да нарасне в зависимост от размера на вашата инфраструктура и типа мониторинг и защита, от които се нуждаете.

Представянето на PeteNetLive по роли служи като полезно напомняне, че хостът на сесията обикновено е мястото, където натискът върху ресурсите се появява първо, докато другите роли на RDS често имат относително по-малки отпечатъци. Имайте това предвид, когато търсите маркери за капацитета на използване на вашата компания, тъй като това може да помогне при оценката на плановете.

Стъпка 6: Добавете резерв за пикове, растеж и прехвърляне.

Нито един терминален сървър не трябва да завършва с "точно достатъчно" число. Добавете резерв за:

• сутрешни пикове на влизане
• пачване и AV сканирания
• месечни отчетни върхове
• очакван растеж на потребителите
• неуспех на хоста в многосървърен дизайн

В заключение, някои добри оперативни съвети за всяка среда, която преминава отвъд един единствен хост, е да се вземат предвид допълнителни хостове в случай на загуба на сървър или хипервизор.

Метод за прост калкулатор на терминален сървър за МСП и ИТ услуги

Тази логика на калкулатора е умишлено проста. Тя е предназначена да произведе защитима първа оценка, а не окончателен еталон, и за вас да я адаптирате съответно.

Бърза формула за планиране

Използвайте тази последователност:

1. Брой паралелни потребители .
2. Сортирайте ги в светъл, среден и тежък групи.
3. Оценка ЦПУ използвайки основно съотношение потребители на vCPU.
4. Оценка RAM от OS разходи плюс на сесия.
5. Проверете съхранение за профил, временно и стартиране на производителност.
6. Добавяне 20 до 30 процента резервен капацитет , след това прегледайте нуждите от резервиране.

Това отразява същността на начина, по който размерите се определят по принцип: натоварване на първо място, съотношения на второ, усъвършенстване след наблюдение. А сега, защо да не получите предварителен преглед на каква форма може да приеме , получете точна оценка и очертайте потенциалната си инфраструктура? Ключов инструмент при планирането на бюджета си.

Пример 1: 15 светлинни офис потребители

Предполага се, че 15 едновременни потребители имат достъп до публикувано бизнес приложение, плюс леко използване на браузър.

Използвайки препоръчителни светлинни базови линии, суровата оценка на CPU е около 3 vCPU. На практика, това е твърде стегнато за капацитет на избухване, така че планировчикът би преминал към по-практичен профил на хост, вместо да изгражда до ръба. Ще намерите съвети, които предпочитат по-широк диапазон на размерите от 4 до 24 vCPU с 8 vCPU и 16 GB RAM като стандартен базов профил за многосесийни работни натоварвания.

За RAM, резервирайте капацитет за операционната система и услугите, след което добавете памет за сесия за всеки потребител. Ако средата е стабилна и използването на приложенията е ограничено, това може да се побере удобно на скромен хост, но все пак трябва да бъде валидирано по време на пилотното използване.

Пример 2: 30 смесени офисни и ERP потребители

Предположим:

• 18 средни потребители
• 12 тежки потребители

Планиращият съкратен вариант би трTreat medium group at roughly 4 users per vCPU and the heavy group at roughly 2 users per vCPU. Това предполага около 4.5 vCPUs за средната група и 6 vCPUs за тежката група, преди разходите и резервите. На практика, това вече сочи към не един единствен хост с малък размер, а към по-голям хост с марж или разпределение между множество хостове за сесии.

Тук съветът „планирайте ресурсите на сървъра“ става смислен. С [един] ERP както в контекста на всяко предприятие, целта не е просто да се настанят потребителите някъде. Целта не е просто да се настанят потребителите някъде. Целта е да се поддържат времето за отговор в приемливи граници по време на най-заетите части от деня.

Пример 3: Кога да разделите потребителите на множество хостове

След като изчислението произведе плътен хост с ограничена капацитет за внезапни натоварвания, по-добрият отговор може да бъде архитектурен, а не вертикално мащабиране. Хостовете на сесиите могат да бъдат настроени да извършват тежката работа, докато роли като RD Connection Broker, Gateway и Licensing получават различни профили на ресурси. Разпределянето на потребителското натоварване между множество хостове вероятно ще подобри устойчивостта, гъвкавостта на поддръжката и планирането на прехвърляне при отказ.

За MSP, това често е решаващият момент, в който калкулаторът на терминален сървър става дискусия за размерите на фермата вместо дискусия за един сървър.

Кои често срещани грешки при оразмеряване обикновено нарушават производителността на терминалния сървър?

Грешките в размерите обикновено не се причиняват само от математиката. Те произтичат от неправилни предположения.

Объркване на лицензиране с производителност

Лицензирането ви казва как се задава и конфигурира достъпът. То не ви казва колко едновременни потребители ще поддържа един сървър с приемливо представяне.

Игнориране на сесии с голямо натоварване на браузъра и печат.

Много среди все още подценяват колко натоварване може да добави използването на съвременни браузъри, обработката на PDF файлове и печатът към хост на сесия. Тези дейности могат да преместят група потребители от леко към средно натоварване или от средно към тежко, дори когато самото приложение за бизнес е скромно.

Размери само за средно натоварване

Средното натоварване рядко е моментът, в който потребителите се оплакват. Оплакванията се случват по време на логон бури, едновременни отваряния на файлове, изпълнения на отчети или сутрешни пикове. Microsoft отбелязва, че по-добрата капацитет за избухване е важна при по-ниски съотношения потребители на ядро, тъй като това позволява оставяне на пространство вместо насочване към максимална плътност.

Забравяйки останалата част от RDS стека

Сесионният хост е основният потребител на ресурси, но не е единствената роля в средата. Разпределението на ролите в PeteNetLive е полезно напомняне да се вземат предвид Connection Broker, Gateway, Web Access и Лицензиране поотделно, когато внедряването нарасне извън малка настройка с един хост.

Защо мониторингът трябва да валидира вашите оценки за размери?

Калкулаторът на терминален сървър ви дава основа за планиране. Той не ви дава доказателство. За доказателство трябва да наблюдавате използването.

От основата до доказателството: мониторингът като съществено условие

В нашата предишна статия обясняваме защо устойчивата потребителска капацитет е практичен въпрос за мониторинг. Тук целта е да покажем как да оцените първата версия на този капацитет преди внедряване. Мониторингът ще ви предостави много от броя, които споменахме. Препоръчваме ви да тествате в лабораторен контекст, за да оцените предвидените си нужди.

Къде прави разликата TSplus Server Monitoring?

TSplus Сървърно наблюдение попада след като оценката на размера бъде внедрена. Тя помага да се провери дали наситеността на CPU, натискът върху паметта, задръстванията в съхранението или пиковете в използването съответстват на предположенията, използвани в планирането. Това е особено полезно за ИТ администратори на малки и средни предприятия и доставчици на управлявани услуги, които се нуждаят от доказателства преди да променят размера на хост, да преразпределят потребители или да добавят сървър.

Освен да знаете как да проектирате ресурси, как иначе можете да разберете дали изчислението е било правилно, освен чрез системи за наблюдение? Server Monitoring ви предоставя мониторинг в реално време и известия, за да ви информира, когато маркерите достигнат зададените от вас прагове. .

TSplus софтуер за сигурно и устойчиво предоставяне на приложения и работни станции

TSplus Remote Access принадлежи към слоя за доставка в по-широката история, докато Advanced Security е специално проектиран да защитава сървъри на приложения. В допълнение, TSplus Remote Support предоставя комплект от основни инструменти за отстраняване на проблеми и поддържане на тези сървъри и още от всяко място. След като средата е правилно настроена, TSplus Remote Access ще публикува работни станции и приложения по-лесно от Citrix и без да надвишава бюджета ви. Тестовите функции като уеб достъп и централизирана доставка ще ви дадат представа как можете да преминете отвъд ad hoc RDP достъпа.

Заключение

Калкулаторът за терминален сървър не трябва да обещава магически отговор. Сега е време да се изчислят ресурсите на терминалния сървър на етапи: започнете с concurrent users, класифицирайте интензивността на натоварването, оценете CPU и RAM на базата на реалистично поведение на сесиите, проверете хранилището и след това добавете марж за пикове, растеж и резервиране.

Като системен администратор, ИТ администратори на малки и средни предприятия или управлявани услуги, това ще ви даде практическа първа оценка. Оттам нататък истинската дисциплина е валидиране. Планирайте внимателно, внедрявайте консервативно и след това използвайте данни за мониторинг, за да потвърдите дали хостът или хост ферма може да поддържа потребителското изживяване, което възнамерявате.