App-V 용량 계획
적용 대상: Windows Server 2016
다음 권장 사항은 organization App-V 인프라에 적합한 용량 계획 정보를 결정하는 데 도움이 되는 기준으로 사용할 수 있습니다.
중요
이 섹션의 정보는 App-V 배포를 계획하기 위한 일반 가이드로만 사용합니다. 시스템 용량 요구 사항은 하드웨어 및 애플리케이션 환경의 특정 세부 정보에 따라 달라집니다. 또한 이 문서에 표시된 성능 번호는 예제이며 결과는 다를 수 있습니다.
프로젝트 scope 확인
App-V 인프라를 디자인하기 전에 가상으로 사용할 수 있는 애플리케이션을 결정하고 대상 사용자 및 해당 위치를 식별합니다. 이 정보는 프로젝트에서 구현해야 하는 App-V 인프라 유형을 결정합니다. 프로젝트의 scope 대한 결정은 organization 특정 요구 사항에 따라 결정해야 합니다.
| 작업 | 추가 정보 |
|---|---|
| 애플리케이션 scope 확인 | 가상화하려는 애플리케이션에 따라 App-V 인프라를 다양한 방식으로 설정할 수 있습니다. 설정에서 이 사용자 지정은 첫 번째 작업이 가상화하려는 애플리케이션을 정의하는 것임을 의미합니다. |
| 위치 scope 확인 | "위치 scope"은 가상화된 애플리케이션(예: 엔터프라이즈 수준 또는 특정 지리적 위치)을 실행하려는 실제 위치를 나타냅니다. 가상 애플리케이션을 실행할 사용자 모집단(예: 단일 부서)을 참조할 수도 있습니다. 연결 경로, 각 위치에 사용 가능한 대역폭, 가상화된 애플리케이션을 사용하는 사용자 수 및 WAN 연결 속도를 포함하는 네트워크 맵을 가져와야 합니다. |
필요한 App-V 인프라 확인
Microsoft Systems Center Configuration Manager 같은 ESD(전자 소프트웨어 배포) 솔루션을 사용하여 App-V 환경을 관리할 수도 있습니다. 자세한 내용은 전자 소프트웨어 배포를 사용하여 App-V 패키지를 배포하는 방법을 참조하세요.
독립 실행형 모델 - 독립 실행형 모델을 사용하면 가상 애플리케이션을 스트리밍 없이 배포할 수 있도록 Windows Installer를 사용할 수 있습니다. 독립 실행형 모드의 App-V에는 시퀀서와 클라이언트만 필요합니다. 추가 구성 요소가 필요하지 않습니다. 애플리케이션은 시퀀싱이라는 프로세스를 사용하여 가상화를 위해 준비됩니다. 자세한 내용은 App-V Sequencer 및 클라이언트 배포 계획을 참조하세요. 독립 실행형 모델은 다음 시나리오에 권장됩니다.
- 연결이 끊긴 원격 사용자가 있는 경우 App-V 인프라에 연결할 수 없습니다.
- Configuration Manager 같은 소프트웨어 관리 시스템을 실행하는 경우
- 네트워크 대역폭 제한으로 전자 소프트웨어 배포가 금지되는 경우
전체 인프라 모델 - 전체 인프라 모델은 소프트웨어 배포, 관리 및 보고 기능을 제공합니다. 또한 네트워크를 통해 애플리케이션의 스트리밍을 포함합니다. App-V 전체 인프라 모델은 애플리케이션을 모든 클라이언트에 게시하는 데 사용할 수 있는 하나 이상의 App-V 관리 서버로 구성됩니다. 게시하면 대상 컴퓨터에 가상 애플리케이션 아이콘과 바로 가기가 배치됩니다. 로컬 사용자에게 애플리케이션을 스트리밍할 수도 있습니다. 관리 서버를 설치하는 방법에 대한 자세한 내용은 App-V Server 배포 계획을 참조하세요. 전체 인프라 모델은 다음 시나리오에 권장됩니다.
- 관리 서버를 사용하여 대상 컴퓨터에 애플리케이션을 게시하려는 경우
- 대상 컴퓨터에 애플리케이션을 신속하게 프로비전합니다.
- App-V 보고를 사용하려는 경우.
중요
App-V 전체 인프라 모델을 사용하려면 Microsoft SQL Server 구성 데이터를 저장해야 합니다. 자세한 내용은 App-V 지원 구성을 참조하세요.
엔드 투 엔드 서버 크기 조정 지침
다음 섹션에서는 엔드투엔드 App-V 크기 조정 및 계획에 대해 설명합니다. 자세한 내용은 후속 섹션을 참조하세요.
참고
클라이언트의 왕복 응답 시간은 App-V 클라이언트를 실행하는 컴퓨터가 게시 서버에서 성공적인 알림을 받는 데 걸리는 시간입니다. 게시 서버의 왕복 응답 시간은 게시 서버를 실행하는 컴퓨터가 관리 서버에서 성공적인 패키지 메타데이터 업데이트를 받는 데 걸리는 시간입니다.
- 20,000명의 클라이언트는 단일 게시 서버를 대상으로 하여 허용 가능한 왕복 시간(<3초)에 패키지 새로 고침을 가져올 수 있습니다.
- 단일 관리 서버는 허용되는 왕복 시간(<5초)에 패키지 메타데이터 새로 고침을 위해 최대 50개의 게시 서버를 지원할 수 있습니다.
App-V 관리 서버 용량 계획 권장 사항
App-V 게시 서버에는 패키지 새로 고침 요청 및 패키지 새로 고침 응답에 대한 관리 서버가 필요합니다. 그런 다음 관리 서버는 정보를 검색하기 위해 관리 데이터베이스로 정보를 보냅니다. App-V 관리 서버 지원 구성에 대한 자세한 내용은 App-V 지원 구성을 참조하세요.
참고
App-V 게시 서버의 기본 새로 고침 시간은 10분입니다.
여러 동시 게시 서버가 단일 관리 서버에 연결하여 패키지 메타데이터 새로 고침을 수행할 경우 다음 세 가지 요소가 게시 서버의 왕복 응답 시간에 영향을 줍니다.
- 동시 요청을 만드는 게시 서버의 수입니다.
- 관리 서버에 구성된 연결 그룹 수입니다.
- 관리 서버에 구성된 액세스 그룹의 수입니다.
다음 표에서는 왕복 시간에 영향을 주는 각 요인에 대해 자세히 설명합니다.
참고
왕복 응답 시간은 관리 서버에서 성공적인 패키지 메타데이터 업데이트를 받기 위해 App-V 게시 서버를 실행하는 컴퓨터에서 소요되는 시간입니다.
| 왕복 응답 시간에 영향을 미치는 요인 | 설명 |
|---|---|
| 패키지 메타데이터 새로 고침을 동시에 요청하는 게시 서버의 수입니다. | 단일 관리 서버는 게시 메타데이터를 동시에 요청하는 최대 320개 게시 서버에 응답할 수 있습니다. 예를 들어 30개 게시 서버가 동시에 게시 메타데이터를 요청하는 경우 왕복 응답 시간은 약 40초이지만 50개 미만 서버의 경우 5초 미만입니다. 50~320개의 게시 서버에서 응답 팀은 선형으로 증가합니다(약 2×). |
| 관리 서버에 구성된 연결 그룹 수입니다. | 최대 100개의 연결 그룹의 경우 게시 서버의 왕복 응답 시간에 큰 변화가 없습니다. 100~400개의 연결 그룹의 경우 왕복 응답 시간이 약간 선형으로 증가합니다. |
| 관리 서버에 구성된 액세스 그룹의 수입니다. | 최대 40개의 액세스 그룹의 경우 게시 서버의 왕복 응답 시간이 선형(약 3×) 증가합니다. |
다음 표에서는 각 이전 요소에 대한 샘플 값을 표시합니다. 각 변형에서 120개의 패키지가 App-V 관리 서버에서 새로 고쳐집니다.
| 시나리오 | 변형 | 연결 그룹 수 | 액세스 그룹 수 | 게시 서버 수 | 네트워크 연결 유형 | 왕복 응답 시간(초) | 관리 서버 CPU 사용률 |
|---|---|---|---|---|---|---|---|
| 게시 서버는 메타데이터를 동시에 게시하기 위해 관리 서버에 연결합니다. | 게시 서버 수입니다. | 0 0 0 0 0 0 |
1 1 1 1 1 1 |
50 100 200 300 315 320 |
LAN | 5 10 19 32 30 37 |
17 17 17 15 17 15 |
| 게시 메타데이터에는 연결 그룹이 포함됩니다. | 연결 그룹 수 | 10 20 100 150 300 400 |
1 1 1 1 1 1 |
100 100 100 100 100 100 |
LAN | 10 11 11 16 22 25 |
17 19 22 19 20 20 |
| 게시 메타데이터에는 액세스 그룹이 포함됩니다. | 액세스 그룹 수 | 0 0 0 0 |
1 10 20 40 |
100 100 100 100 |
LAN | 10 43 153 535 |
17 26 24 24 |
관리 서버를 실행하는 컴퓨터의 CPU 사용률은 대상 게시 서버 수에 관계없이 약 25%입니다. Microsoft SQL Server 데이터베이스 트랜잭션/초, 일괄 처리 요청/초 및 사용자 연결은 게시 서버 수와 관계없이 동일합니다. 예를 들어 transactions/sec는 약 30이고, 일괄 처리 요청은 약 200개이고, 사용자는 약 6개를 연결합니다.
관리 서버와 게시 서버가 둘 사이의 느린 연결 네트워크를 활용하는 지리적으로 분산된 배포를 통해 게시 서버의 왕복 응답 시간은 단일 관리 서버에서 100개의 동시 요청에 대해서도 허용 가능한 시간 제한(<5초) 내에 있습니다.
| 시나리오 | 변형 | 연결 그룹 수 | 액세스 그룹 수 | 게시 서버 수 | 네트워크 연결 유형 | 왕복 응답 시간(초) | 관리 서버 CPU 사용률(%) |
|---|---|---|---|---|---|---|---|
| 게시 서버와 관리 서버 간의 네트워크 연결 | 1.5Mbps 느린 링크 네트워크 | 0 0 |
1 1 |
50 100 |
1.5Mbps 케이블 DSL | 4 5 |
1 2 |
| 게시 서버와 관리 서버 간의 네트워크 연결 | LAN/WiFi 네트워크 | 0 0 |
1 1 |
100 200 |
WiFi | 11 20 |
15 17 |
관리 서버와 게시 서버가 느린 연결 네트워크를 통해 연결되었는지, 고속 네트워크를 통해 연결되었는지에 관계없이 관리 서버는 30분 안에 약 15,000개의 패키지 새로 고침 요청을 처리할 수 있습니다.
App-V Reporting Server 용량 계획 권장 사항
App-V 클라이언트는 보고 서버에 보고 데이터를 보냅니다. 그런 다음 보고 서버는 Microsoft SQL Server 데이터베이스에 정보를 기록하고 App-V 클라이언트를 실행하는 컴퓨터에 성공적인 알림을 다시 반환합니다. App-V Reporting Server의 지원되는 구성에 대한 자세한 내용은 App-V 지원 구성을 참조하세요.
참고
왕복 응답 시간은 App-V 클라이언트를 실행하는 컴퓨터가 보고 서버에 보고 정보를 보내고 보고 서버에서 성공적인 알림을 받는 데 걸리는 시간입니다.
| 시나리오 | 요약 |
|---|---|
| 여러 App-V 클라이언트는 보고 정보를 보고 서버로 동시에 보냅니다. | 보고 서버의 왕복 응답 시간은 500개 클라이언트의 경우 2.6초입니다. 보고 서버의 왕복 응답 시간은 클라이언트 1000개에 대해 5.65초입니다. 왕복 응답 시간은 클라이언트 수에 따라 선형으로 증가합니다. |
| 보고 서버에서 처리한 초당 요청 수입니다. | 단일 보고 서버와 단일 데이터베이스는 초당 최대 139개의 요청을 처리할 수 있습니다. 평균은 초당 121개 요청입니다. 동일한 Microsoft SQL Server 데이터베이스에 보고하는 두 개의 보고 서버의 도움으로 단일 보고 서버와 같은 평균 요청/초는 약 127개이며 최대 초당 요청은 278개입니다. 단일 보고 서버는 500개의 동시/활성 연결을 처리할 수 있습니다. 단일 보고 서버는 최대 1,500개의 동시 연결을 처리할 수 있습니다. |
| 보고 데이터베이스. | Microsoft SQL Server 실행하는 컴퓨터의 잠금 경합은 요청/초의 제한 요소입니다. 처리량 및 응답 시간은 데이터베이스 크기와 독립적입니다. |
임의 지연 계산
임의 지연은 보고 서버로 데이터를 보낼 최대 지연 시간(분)을 지정합니다. 예약된 작업이 시작되면 클라이언트는 0 과 ReportingRandomDelay 사이에 임의 지연을 생성하고 데이터를 보내기 전에 지정된 기간을 기다립니다.
임의 지연 = 초당 4개 × 클라이언트/평균 요청 수입니다.
예: 초당 요청이 120개인 500개 클라이언트에 대한 임의 지연은 4× 500/120 = 약 17분입니다.
App-V 게시 서버 용량 계획 권장 사항
App-V 클라이언트를 실행하는 컴퓨터는 App-V 게시 서버에 연결하여 게시 새로 고침 요청을 보내고 응답을 받습니다. 왕복 응답 시간은 App-V 클라이언트를 실행하는 컴퓨터에서 측정되고 프로세서 시간은 게시 서버에서 측정됩니다. App-V 게시 서버 지원 구성에 대한 자세한 내용은 App-V 지원 구성을 참조하세요.
중요
다음 목록에는 App-V 게시 서버를 설정할 때 고려해야 할 기본 요소가 표시됩니다.
- 단일 게시 서버에 동시에 연결하는 클라이언트 수입니다.
- 각 새로 고침의 패키지 수입니다.
- 클라이언트와 App-V 게시 서버 간의 환경에서 사용 가능한 네트워크 대역폭입니다.
| 시나리오 | 요약 |
|---|---|
| 여러 App-V 클라이언트가 단일 게시 서버에 동시에 연결됩니다. | 이중 코어 프로세서를 실행하는 게시 서버는 새로 고침을 동시에 요청하는 최대 5,000개의 클라이언트에 응답할 수 있습니다. 5,000~10,000개의 클라이언트의 경우 게시 서버에 최소 쿼드 코어가 필요합니다. 10,000~20,000개의 클라이언트의 경우 게시 서버에는 보다 효율적인 응답 시간을 위해 이중 쿼드 코어가 있어야 합니다. 쿼드 코어가 있는 게시 서버는 3초 이내에 최대 10,000개의 패키지를 새로 고칠 수 있습니다. (10,000개의 동시 클라이언트를 지원합니다.) |
| 각 새로 고침의 패키지 수입니다. | 패키지 수가 증가하면 응답 시간이 약 40% 증가합니다(최대 1,000개 패키지). |
| App-V 클라이언트와 게시 서버 간의 네트워크입니다. | 느린 네트워크(1.5Mbps 대역폭)를 통해 LAN(최대 1,000명의 사용자)에 비해 응답 시간이 97% 증가합니다. |
참고
게시 서버 CPU 사용량은 동시 요청을 처리해야 하는 시간 간격 동안 항상 높습니다(>대부분의 경우 90%). 게시 서버는 1초에 약 1,500개의 클라이언트 요청을 처리할 수 있습니다.
| 시나리오 | 변형 | App-V 클라이언트 수 | 패키지 수 | 게시 서버의 프로세서 구성 | 네트워크 연결 유형 | App-V 클라이언트 왕복 시간(초) | 서버 CPU 사용률 게시(%) |
|---|---|---|---|---|---|---|---|
| App-V 클라이언트는 게시 새로 고침 요청을 보내고 120개의 패키지가 포함된 각 요청에 대한 응답을 받습니다. | 클라이언트 수 | 100 1,000 5,000 10,000 |
120 120 120 120 |
듀얼 코어 듀얼 코어 쿼드 코어 쿼드 코어 |
LAN | 1 2 2 3 |
100 99 89 77 |
| 각 새로 고침의 여러 패키지. | 패키지 수 | 1,000 1,000 |
500 1,000 |
쿼드 코어 | LAN | 2 3 |
92 91 |
| 클라이언트와 게시 서버 간의 네트워크입니다. | 1.5Mbps 느린 링크 네트워크 | 100 500 1,000 |
120 120 120 |
쿼드 코어 | 1.5Mbps 대륙 내 네트워크 | 3 10(0.2% 실패율) 7(1% 실패율) |
App-V 스트리밍 용량 계획 권장 사항
App-V 클라이언트를 실행하는 컴퓨터는 스트리밍 서버에서 가상 애플리케이션 패키지를 스트리밍합니다. 왕복 응답 시간은 App-V 클라이언트를 실행하는 컴퓨터에서 측정되며 전체 패키지를 스트리밍하는 데 걸리는 시간입니다.
중요
다음 목록에서는 App-V 스트리밍 서버를 설정할 때 고려해야 할 기본 요소를 식별합니다.
- 단일 스트리밍 서버에서 애플리케이션 패키지를 동시에 스트리밍하는 클라이언트 수입니다.
- 스트리밍되는 패키지의 크기입니다.
- 클라이언트와 스트리밍 서버 간의 환경에서 사용 가능한 네트워크 대역폭입니다.
| 시나리오 | 요약 |
|---|---|
| 여러 App-V 클라이언트는 단일 스트리밍 서버에서 애플리케이션을 동시에 스트리밍합니다. | 동일한 서버에서 동시에 스트리밍하는 클라이언트 수가 증가하는 경우 패키지 다운로드/스트리밍 시간과 선형 관계가 있습니다. |
| 스트리밍되는 패키지의 크기입니다. | 패키지 크기는 크기가 약 1GB인 더 큰 패키지에 대해서만 스트리밍/다운로드 시간에 상당한 영향을 줍니다. 3MB에서 100MB에 이르는 패키지 크기의 경우 스트리밍 시간은 20초에서 100초까지이며 동시 클라이언트는 100개입니다. |
| App-V 클라이언트와 스트리밍 서버 간의 네트워크입니다. | 느린 네트워크(1.5Mbps 대역폭)에서 LAN(최대 100명의 사용자)에 비해 응답 시간이 70~80% 증가합니다. |
다음 표에는 이전 목록의 각 요소에 대한 샘플 값이 표시됩니다.
| 시나리오 | 변형 | App-V 클라이언트 수 | 각 패키지의 크기 | 네트워크 연결 유형 | App-V 클라이언트의 왕복 시간(초) |
|---|---|---|---|---|---|
| 여러 App-V 클라이언트가 스트리밍 서버에서 가상 애플리케이션 패키지를 스트리밍합니다. | 클라이언트 수입니다. | 100 200 1,000 100 200 1,000 |
3.5MB 3.5MB 3.5MB 5MB 5MB 5MB |
LAN | 29 39 391 35 68 461 |
| 스트리밍되는 각 패키지의 크기입니다. | 각 패키지의 크기입니다. | 100 200 100 200 |
21MB 21MB 109MB 109MB |
LAN | 33 83 100 160 |
| 클라이언트와 App-V 스트리밍 서버 간의 네트워크 연결. | 1.5Mbps 느린 링크 네트워크. | 100 100 |
3.5MB 5MB |
1.5Mbps 대륙 내 네트워크 | 102 121 |
각 App-V 스트리밍 서버는 가상화된 애플리케이션을 동시에 스트리밍하는 최소 200개의 클라이언트를 처리할 수 있어야 합니다.
참고
스트리밍하는 데 걸리는 실제 시간은 주로 동시에 스트리밍하는 클라이언트 수, 패키지 수, 패키지 크기, 서버의 네트워크 활동 및 네트워크 조건에 따라 결정됩니다.
예를 들어 평균 사용자는 100개의 동시 클라이언트가 서버에서 스트리밍되는 경우 2분 이내에 100MB 패키지를 스트리밍할 수 있습니다. 그러나 1GB 크기의 패키지에는 최대 30분이 걸릴 수 있습니다. 대부분의 실제 환경에서 스트리밍 수요는 균일하게 분산되지 않으므로 필요한 스트리밍 서버 수를 적절하게 조정하려면 사용자 환경에 있는 대략적인 최대 스트리밍 요구 사항을 이해해야 합니다.
애플리케이션을 미리 캐시하는 경우 스트리밍 서버에서 지원할 수 있는 클라이언트 수를 늘리고 최대 스트리밍 요구 사항을 줄일 수 있습니다. 또한 주문형 스트리밍 배달 및 스트림 최적화 패키지를 사용하여 스트리밍 서버에서 지원할 수 있는 클라이언트 수를 늘릴 수도 있습니다.
App-V 서버 역할 결합
크기 조정 및 내결함성 요구 사항을 할인하면 Active Directory 연결 위치가 작동해야 하는 최소 서버 수는 1입니다. 이 서버는 관리 서버, 관리 서버 서비스 및 Microsoft SQL Server 역할을 호스트합니다. 이 적용 범위는 서로 충돌하지 않으므로 원하는 조합으로 서버 역할을 정렬할 수 있음을 의미합니다.
크기 조정 요구 사항에도 불구하고 내결함성 구현이 작동해야 하는 최소 서버 수는 4개입니다. 관리 서버 및 Microsoft SQL Server 역할은 내결함성 구성의 배치를 지원합니다. 관리 서버 서비스를 역할과 결합할 수 있지만 단일 실패 지점으로 남아 있습니다.
사용할 수 있는 내결함성 전략과 기술이 많지만 모든 것이 지정된 서비스에 적용되는 것은 아닙니다. 또한 App-V 역할이 결합된 경우 비호환성으로 인해 특정 내결함성 옵션의 작동이 중지될 수 있습니다.