터미널 서버에서 리소스를 계산하는 방법: 실용적인 크기 조정 방법

터미널 서버 계산기는 실제 계산기가 아닌 경우가 많습니다. 대부분의 SMB 및 MSP 환경에서 이는 사용자가 불만을 제기하기 전에 터미널 서버가 얼마나 많은 CPU, RAM, 저장소 및 여유 공간이 필요한지를 추정하는 데 사용되는 계획 방법입니다. 이 키워드 뒤에 있는 실제 질문은 실용적입니다: 터미널 서버에서 자원을 얼마나 잘 계산하여 자신 있게 배포하고 과도한 지출을 피할 수 있을까요? 성능 병목 현상의 위험을 줄이다 ?

터미널 서버 계산기가 실제로 무엇을 계산해야 합니까?

유용한 터미널 서버 계산기는 "서버당 사용자" 이상의 추정을 해야 합니다. 관리자로서 CPU, RAM, 저장 성능, 프로필 저장 및 현실적인 동시 사용량에 따른 용량 여유를 계획하는 데 도움이 되어야 합니다. Microsoft의 원격 데스크톱 세션 호스트에 대한 가이드는 작업 유형과 vCPU당 권장 사용자 수에 따라 크기를 조정하는 것을 기준으로 하며, 일반적인 일률적인 연결 제한을 기준으로 하지 않습니다.

사용자 수만으로는 터미널 서버의 리소스를 계산하기에 충분하지 않은 이유는 무엇인가요?

세션 사용량

두 환경이 동일한 사용자 수를 가지고 있더라도 매우 다른 결과를 생성할 수 있다는 점을 염두에 두십시오. 귀하의 인프라에 접근할 사용자 수를 이미 알고 있다고 가정하므로, 이를 고려하십시오. 라이센스 및 CALs를 고려했습니다. 실질적인 작업을 시작할 수 있습니다.

상상해 보세요, 열다섯 명의 사용자가 하나의 비즈니스 애플리케이션을 열면 호스트에 적당한 부하를 줄 수 있습니다. 한편, 열다섯 명의 사용자가 브라우저, Office 애플리케이션, PDF 도구, 인쇄 및 백그라운드 동기화를 포함한 전체 원격 데스크톱을 실행하면 훨씬 더 무거운 발자국을 남길 수 있습니다. 크기 조정 모델은 가벼운, 중간 및 무거운 다중 세션 작업 부하를 구분하여 그 차이를 반영합니다.

구분이 중요합니다. 왜냐하면 "30 사용자"는 그 자체로 용량 수치가 아니기 때문입니다. 정의할 때만 의미가 있습니다. 사용자들이 하는 일과 사용하는 것 피크 시간 동안.

서버 사용량

또한 매우 중요한 구분을 기억하세요: 실험실이나 소규모 사무실의 경우, 동시 사용자 세션이 적게 실행될 것이므로 단일 서버를 계획할 수 있지만, 생산 환경의 경우에는 농장을 계획할 가능성이 높습니다. 실제로 성능을 개선하고 문제 해결을 단순화하며 보안을 강화하기 위해 별도의 역할이 필요하므로 일반적인 분할은 다음과 같습니다:

• 브로커, 웹 및 라이센스를 위한 1 서버
• 세션 호스트용 1개 이상의 서버
• 1 RD 게이트웨이를 외부 액세스를 위한 자체 서버에 설치합니다.

한 걸음 더 나아가면, 서버 유형, 메모리 등도 고려해야 하며, 원할 수 있습니다. 대규모 설정에 SSD 포함 예를 들어. 그래도, 이것은 당신에게 가능성을 알리기 위한 언급일 뿐입니다.

자원 계획을 형성하는 네 가지 입력은 무엇입니까?

다음으로, 하드웨어 숫자를 바로 뛰어넘는 것보다 더 신뢰할 수 있는 네 가지 입력을 수집하기 전에 시작해야 합니다. 이 상류 작업은 누가 연결할 수 있는지와 어떤 Microsoft 규칙에 따라 연결할 수 있는지에 대한 라이센스 질문과의 중복을 피합니다. 여기서 가장 중요한 문제는 세션 호스트가 응답성을 유지하기 위해 얼마나 많은 리소스가 필요한가입니다. 이전 기사에서는 다루었습니다. 라이센스 및 서버 용량 그래서 우리는 모든 것을 체계적으로 세는 방법의 실용성을 여기에서 개발하여 올바르게 계획할 수 있습니다.

따라서, 당신은 합산해야 합니다:

동시 활성 사용자

이 필수 숫자를 포함해야 합니다. 병렬로 실행되는 세션 수는 서버 성능에 확실히 영향을 미치기 때문입니다. 동시 수는 총 수와 독립적일 수 있습니다.

사용자 그룹별 작업 부하 클래스

사용자 또는 사용자 집합이 자원을 얼마나 사용할지를 평가하는 것은 첫 번째 현실 점검입니다. 특정 그룹이나 개인은 수행하는 작업에 따라 불가피하게 더 많은 자원을 소모하게 됩니다. 그래서 많은 사용자를 식별할 필요가 있습니다.

애플리케이션 및 세션 유형

특정 애플리케이션을 정확히 파악하는 것도 매우 유용합니다. 특정 사용자가 실행하는 애플리케이션에 따라 많은 자원을 독점할 수 있기 때문입니다.

피크, 성장 및 장애 조치 마진

이 입력 목록을 최대 사용량을 고려하여 정리하고, 예상되는 단기 성장에 대한 여유를 남기며, 장애 조치 버퍼 마진을 구축합니다.

터미널 서버에서 리소스를 어떻게 계산합니까?

여기 SMB 관리 및 기타 맥락에서 유용하게 사용되기를 바라는 실용적인 계산 방법이 있습니다. 이 방법은 최소한 계획을 단순화하고 구조를 정리하는 것을 목표로 합니다. 그런 다음, 이후에는 이를 다듬어 파일럿 기간 및 그 이후에도 신뢰할 수 있도록 해야 합니다.

1단계: 총 사용자가 아닌 동시 사용자를 계산합니다.

동시에 활동 중인 사용자 수로 시작하십시오. 이것이 서버 부하를 유발하는 수치입니다. 50명의 명명된 사용자가 있는 비즈니스는 피크 시간 동안 동시에 18명에서 25명만 연결될 수 있습니다. 세션 호스트의 크기를 조정할 때, 동시에 연결된 세션 수는 총 사용자 수보다 훨씬 더 유용합니다.

부하 하에서 지속 가능한 실제 용량을 테스트하기 전에 계획은 추정치를 도전해야 합니다.

2단계: 작업 부하를 경량, 중간 또는 중량으로 분류합니다.

다음으로 그룹 사용자를 작업량별로 정렬합니다. Microsoft의 현재 세션 호스트 안내 다중 세션 환경을 위한 다음 기준 밀도 범위를 제안하며 HP 및 기타 출처도 이에 동의합니다:

• vCPU당 최대 6명의 경량 사용자
• vCPU당 4명의 중간 사용자 및
• vCPU당 2명의 중간 사용자,

각 작업 부하 대역에 대해 각각 8 vCPU, 16 GB RAM, 32 GB 저장소를 갖춘 최소 VM 예제를 포함합니다. 권장 사항에는 더 나은 용량 수익을 위해 다중 세션 VM 크기를 대략 4에서 24 vCPU 사이로 유지하는 것도 포함됩니다.

중소기업 계획을 위한 간단한 작업 부하 맵은 정렬을 안내할 것입니다:

• 빛: 하나의 비즈니스 앱, 제한된 브라우저 사용, 짧은 세션
• 중간: 오피스 앱, 브라우저 탭, PDF 도구, 적당한 멀티태스킹
• 무거운: ERP, 더 큰 Excel 파일, 지속적인 브라우저 사용, 인쇄, 하루 종일 여러 앱 열기

이것들은 보장 사항이 아닌 기본 계획 범위입니다. 목적은 작업 부하 행동에 기반한 시작점을 선택하는 것입니다.

3단계: CPU 용량 추정

사용자가 그룹화되면 사용자당 vCPU 접근 방식을 사용하여 CPU를 추정합니다. 예를 들어, 24명의 동시 사용자가 대부분 중간 사용자일 경우, Microsoft의 기준인 약 4명의 사용자가 vCPU당 시작하는 것을 기준으로 6개의 vCPU로 시작한 다음, 버스트 여유 공간이 있는 실용적인 호스트 크기로 반올림합니다. 단기 CPU 수요 급증 동안 더 나은 버스트 용량을 제공하려면, 그렇지 않으면 예상할 수 있는 것보다 낮은 코어당 사용자 비율을 계획하십시오.

CPU 크기 조정은 수학적 최소값에서 그치지 않아야 한다는 것이 분명해졌을 것입니다. 로그인 급증, 바이러스 백신 활동, 보고 작업 및 짧은 기간의 동시 애플리케이션 실행을 고려해야 합니다.

4단계: RAM 요구 사항 추정

RAM은 운영 체제, 핵심 서비스, 세션 오버헤드 및 사용자당 애플리케이션 메모리 사용의 요구를 충족해야 합니다. 위에서 설명한 바와 같이, 현재 Microsoft의 다중 세션 기준은 8 vCPU 시작점을 위해 최소 16 GB RAM과 함께 가벼운, 중간 및 무거운 작업 부하 예제를 쌍으로 제공합니다. 비록 이것이 단지 기준일 뿐이지만, 여전히 추정의 실질적인 시작점을 제공합니다.

중소기업에서 실용적인 방법은 다음과 같습니다:

1. 운영 체제 및 플랫폼 서비스에 대한 메모리 예약,
2. 사용자 클래스별 세션당 메모리 추정
3. 동시 세션 수에 따라 곱하기
4. 그런 다음 안전 여유를 추가하십시오.

PeteNetLive는 제공한다 고의적으로 넓은 경험 법칙 사용자당 2GB에서 8GB의 RD 세션 호스트 RAM 계획을 위한 것입니다. 이는 테스트에서 정확한 숫자를 조정해야 하더라도, 무거운 세션을 과소평가하는 것에 대한 주의로 유용합니다.

5단계: 저장소 및 프로필 오버헤드 확인

저장소는 종종 터미널 서버 계획에서 과소평가됩니다. 느린 막힌 저장소는 CPU와 RAM이 여전히 괜찮아 보일 때에도 로그온, 프로필 로딩, 임시 파일, 애플리케이션 실행 및 인쇄 스풀링에 악영향을 미칠 수 있습니다.

• 프로필 저장소
• 운영 체제 저장소
• 로그: 보안 및 기타 목적을 위한

이 마지막 범주는 귀하의 인프라 크기와 요구하는 모니터링 및 보호 유형에 따라 빠르게 부풀어 오를 수 있으므로 추정할 가치가 충분히 있습니다.

PeteNetLive의 역할별 프레젠테이션은 세션 호스트가 일반적으로 리소스 압력이 처음 나타나는 곳이라는 유용한 상기 역할을 하며, 다른 RDS 역할은 상대적으로 작은 발자국을 가지는 경우가 많습니다. 회사의 사용량 증가 용량을 평가할 때 이 점을 염두에 두십시오. 이는 계획을 수립하는 데 도움이 될 수 있습니다.

단계 6: 피크, 성장 및 장애 조치를 위한 여유 공간 추가

터미널 서버 계산기는 "충분한" 숫자로 끝나서는 안 됩니다. 여유를 추가하십시오:

• 아침 로그인 급증
• 패치 및 AV 스캔
• 월간 보고서 피크
• 예상 사용자 성장
• 다중 서버 설계에서 호스트 실패

마지막으로, 단일 호스트를 넘어서는 모든 환경에 대한 좋은 운영 조언은 서버나 하이퍼바이저 손실에 대비하여 추가 호스트를 고려하는 것입니다.

중소기업 및 관리 서비스 제공업체를 위한 간단한 터미널 서버 계산기 방법

이 계산기 로직은 의도적으로 간단합니다. 방어 가능한 첫 번째 추정치를 생성하기 위한 것이며, 최종 기준이 아니라 필요에 따라 조정할 수 있도록 설계되었습니다.

빠른 계획 공식

이 시퀀스를 사용하세요:

1. 수량 동시 사용자 .
2. 정렬하세요 가벼운, 중간 및 무거운 그룹.
3. 견적 CPU vCPU당 사용자 비율을 기준으로 사용합니다.
4. 견적 램 운영 체제 오버헤드와 세션당 수요에서 추가.
5. 확인 저장소 프로필, 임시 및 실행 성능을 위해.
6. 추가 20에서 30퍼센트 여유 그런 다음 장애 조치 요구 사항을 검토하십시오.

이는 일반적으로 크기 조정이 어떻게 구성되는지를 반영합니다: 작업량이 먼저, 비율이 두 번째, 관찰 후에 세밀화가 이루어집니다. 그리고 이제, 미리보기를 해보는 것은 어떨까요? 어떤 형태를 취할 수 있는지 정확한 견적을 얻고 잠재적인 인프라를 계획하는 데 도움이 되는 주요 도구입니다.

예시 1: 15명의 경량 사무실 사용자

15명의 동시 사용자가 게시된 비즈니스 앱에 접근하고 가벼운 브라우저 사용을 추가한다고 가정합니다.

권장되는 가벼운 기준을 사용하면 원시 CPU 추정치는 약 3 vCPU입니다. 실제로 이는 버스트 용량에 비해 너무 빡빡하므로, 계획자는 가장자리를 구축하기보다는 보다 실용적인 호스트 프로필로 전환할 것입니다. 조언은 4에서 24 vCPU의 더 넓은 크기 범위를 선호하며, 8 vCPU, 16 GB RAM을 다중 세션 작업 부하에 대한 표준 기준 프로필로 제안합니다.

RAM의 경우, OS와 서비스에 대한 용량을 예약한 다음 각 사용자에 대한 세션 메모리를 추가합니다. 환경이 안정적이고 애플리케이션 사용이 제한적이라면, 이는 적당한 호스트에 편안하게 맞을 수 있지만, 파일럿 사용 중에 여전히 검증되어야 합니다.

예시 2: 30명의 혼합 사무실 및 ERP 사용자

가정하다:

• 18명의 중간 사용자
• 12명의 중증 사용자

계획 단축키는 중간 그룹을 대략 vCPU당 4명의 사용자로, 무거운 그룹을 대략 vCPU당 2명의 사용자로 처리합니다. 이는 중간 그룹에 대해 약 4.5 vCPU와 무거운 그룹에 대해 6 vCPU를 의미하며, 오버헤드와 여유 공간을 고려하기 전입니다. 실제로 이는 이미 단일 경량 호스트에서 벗어나 여유가 있는 더 큰 호스트 또는 여러 세션 호스트에 걸쳐 분할하는 방향으로 나아갑니다.

서버 리소스를 계획하라는 조언이 의미를 갖는 곳입니다. 함께 ERP 기업 환경에서와 마찬가지로, 목표는 단순히 사용자를 어딘가에 맞추는 것이 아닙니다. 사용자를 어딘가에 맞추는 것이 목표가 아닙니다. 목표는 하루 중 가장 바쁜 시간 동안 응답 시간을 수용 가능하게 유지하는 것입니다.

예제 3: 사용자를 여러 호스트에 분산시킬 때

계산이 제한된 버스트 용량을 가진 밀집 호스트를 생성하면, 더 나은 답변은 수직 확장보다는 아키텍처적일 수 있습니다. 세션 호스트는 무거운 작업을 수행하도록 설정할 수 있으며, RD 연결 브로커, 게이트웨이 및 라이센스와 같은 역할에는 서로 다른 리소스 프로필이 부여될 수 있습니다. 여러 호스트에 사용자 부하를 분산시키는 것은 복원력, 유지 관리 유연성 및 장애 조치 계획을 개선할 가능성이 높습니다.

MSP에게 있어, 이는 단일 서버 논의 대신 터미널 서버 계산기가 농장 크기 논의로 전환되는 결정적인 순간인 경우가 많습니다.

어떤 일반적인 크기 조정 실수가 일반적으로 터미널 서버 성능을 저하시킵니까?

크기 오류는 일반적으로 수학만으로 발생하지 않습니다. 그것은 잘못된 가정에서 비롯됩니다.

라이센스를 성능 용량과 혼동하기

라이센스는 액세스가 어떻게 할당되고 구성되는지를 알려줍니다. 서버가 허용 가능한 성능으로 지원할 수 있는 동시 사용자 수에 대해서는 알려주지 않습니다.

브라우저에 부담이 크고 인쇄에 부담이 큰 세션 무시

많은 환경에서 여전히 현대 브라우저 사용, PDF 처리 및 인쇄가 세션 호스트에 얼마나 많은 부하를 추가할 수 있는지를 과소평가하고 있습니다. 이러한 활동은 비즈니스 애플리케이션 자체가 소박하더라도 사용자 그룹을 가벼운 수준에서 중간 수준으로, 또는 중간 수준에서 무거운 수준으로 전환할 수 있습니다.

평균 부하에 대한 크기 조정만

평균 부하는 사용자가 불만을 제기하는 순간이 드물다. 불만은 로그인 폭풍, 동시에 파일 열기, 보고서 실행 또는 아침 피크 시간에 발생한다. Microsoft는 사용자당 코어 비율이 낮을 때 더 나은 폭주 용량이 중요하다고 언급하며, 이는 최대 밀도를 목표로 하기보다는 여유 공간을 남기는 것을 지원한다.

RDS 스택의 나머지를 잊어버리기

세션 호스트는 주요 리소스 소비자이지만, 환경에서 유일한 역할은 아닙니다. PeteNetLive의 역할 분담은 배포가 소규모 단일 호스트 설정을 넘어 성장할 때 연결 브로커, 게이트웨이, 웹 액세스 및 라이센스를 별도로 고려해야 한다는 유용한 알림입니다.

모니터링이 귀하의 크기 추정치를 검증해야 하는 이유는 무엇입니까?

터미널 서버 계산기는 계획 기준을 제공합니다. 증거를 제공하지는 않습니다. 증거를 위해서는 사용량을 모니터링해야 합니다.

기준선에서 증명까지: 필수로서의 모니터링

이전 기사에서는 지속 가능한 사용자 용량이 실용적인 모니터링 질문인 이유를 설명합니다. 여기서 목표는 롤아웃 전에 해당 용량의 첫 번째 버전을 추정하는 방법을 보여주는 것입니다. 모니터링은 우리가 언급한 많은 수치를 얻을 수 있습니다. 우리는 귀하의 구상된 요구 사항을 평가하기 위해 실험실 환경에서 테스트할 것을 권장합니다.

TSplus Server Monitoring은 어디에서 차이를 만드나요?

TSplus 서버 모니터링 적합하다 크기 추정치가 배포된 후. 이는 CPU 포화, 메모리 압박, 저장소 병목 현상 또는 사용 급증이 계획에 사용된 가정과 일치하는지 확인하는 데 도움이 됩니다. 이는 호스트 크기를 조정하거나 사용자를 재분배하거나 다른 서버를 추가하기 전에 증거가 필요한 SMB IT 관리자 및 MSP에게 특히 유용합니다.

리소스를 투영하는 방법을 아는 것 외에, 모니터링 시스템을 통해 계산이 올바른지 확인할 수 있는 다른 방법은 무엇인가요? Server Monitoring은 실시간 모니터링과 설정한 임계값에 도달할 때마다 정보를 제공하는 알림을 제공합니다. .

TSplus 소프트웨어는 애플리케이션과 데스크톱의 안전한 지속적 제공을 위해 설계되었습니다.

TSplus Remote Access는 더 넓은 이야기에서 배달 계층으로 속하며, Advanced Security는 애플리케이션 서버를 보호하기 위해 맞춤 제작되었습니다. 또한, TSplus Remote Support는 이러한 서버와 그 이상을 문제 해결 및 유지 관리하기 위한 필수 키트를 제공합니다. 환경이 올바르게 설정되면, TSplus Remote Access는 Citrix보다 더 간단하게 데스크톱과 애플리케이션을 게시하며 예산을 초과하지 않습니다. 웹 액세스 및 중앙 집중식 배달과 같은 기능을 테스트하면 임시 RDP 액세스를 넘어서는 방법을 맛볼 수 있습니다.

결론

터미널 서버 계산기는 마법 같은 답변을 약속해서는 안 됩니다. 이제 단계별로 터미널 서버 리소스를 계산할 시간입니다: 동시 사용자 수로 시작하고, 작업 부하 강도를 분류하며, 현실적인 세션 행동에서 CPU와 RAM을 추정하고, 저장소를 확인한 다음 피크, 성장 및 장애 조치를 위한 여유를 추가합니다.

시스템 관리자, SMB IT 관리자 또는 MSP로서, 이는 귀하에게 실용적인 첫 번째 추정치를 제공할 것입니다. 그 이후에는 실제로 검증이 필요합니다. 신중하게 계획하고, 보수적으로 배포한 다음 모니터링 데이터를 사용하여 호스트가 확인되었는지 여부를 확인하십시오. 호스트 팜 사용자가 의도한 사용자 경험을 유지할 수 있습니다.