Share via


App-V 5.0 용량 계획

업데이트 날짜: 2014년 2월

적용 대상: Application Virtualization 5.0, Application Virtualization 5.0 SP1, Application Virtualization 5.0 SP2, Application Virtualization 5.0 SP3

다음 권장 사항은 조직의 App-V 5.0 인프라에 적절한 용량 계획 정보를 결정하는 데 도움이 되는 기준으로 사용될 수 있습니다.

중요

이 섹션의 정보는 App-V 5.0 배포 계획에 대한 일반적인 가이드로만 사용하십시오. 시스템 용량 요구 사항은 하드웨어 및 응용 프로그램 환경의 특정 세부 사항에 따라 달라집니다. 또한 이 문서에 나와 있는 성능 수치는 예시된 것이며 실제 결과는 이와 다를 수 있습니다.

프로젝트 범위 결정

App-V 5.0 인프라를 설계하기 전에 프로젝트의 범위를 결정해야 합니다. 범위는 실제로 사용할 수 있으며 대상 사용자 및 해당 위치를 식별하는 데도 사용 가능한 응용 프로그램을 확인함으로써 결정됩니다. 이 정보는 어떤 유형의 App-V 5.0 인프라를 구현해야 하는지 결정하는 데 도움이 됩니다. 프로젝트 범위는 조직의 특정 요구 사항을 바탕으로 결정되어야 합니다.

작업 추가 정보

응용 프로그램 범위 결정

가상화할 응용 프로그램에 따라 App-V 5.0 인프라가 설정되는 방식이 다를 수 있습니다. 먼저, 가상화할 응용 프로그램을 정의합니다.

위치 범위 결정

위치 범위는 가상화된 응용 프로그램을 실행하려는 실제 위치(예: 기업 전체 또는 특정 지리적 위치)를 의미합니다. 또한 가상 응용 프로그램을 실행할 사용자 수(예: 단일 부서)를 의미할 수도 있습니다. 각 위치에 사용 가능한 대역폭과 가상화된 응용 프로그램을 사용하는 사용자 수, WAN 링크 속도뿐 아니라 연결 경로까지 포함된 네트워크 맵을 가져와야 합니다.

필요한 App-V 5.0 인프라 결정

중요

다음 모델은 모두 가상 응용 프로그램을 실행할 컴퓨터에 App-V 5.0 Client가 설치되어 있어야만 사용 가능합니다.

또한 Microsoft Systems Center Configuration Manager와 같은 ESD(전자 소프트웨어 배포) 솔루션을 사용하여 App-V 5.0 환경을 관리할 수도 있습니다. 자세한 내용은 ESD(전자 소프트웨어 배포)를 사용하여 App-V 5.0 패키지 배포을 참조하세요.

  • 독립 실행형 모델 - 독립 실행형 모델을 사용하면 가상 응용 프로그램을 스트리밍 없이 Windows Installer를 통해 배포할 수 있습니다. 독립 실행형 모드의 App-V 5.0은(는) Sequencer 및 클라이언트로 구성되며 추가 구성 요소가 필요하지 않습니다. 시퀀싱이라는 프로세스를 통해 가상화하도록 응용 프로그램이 준비됩니다. 자세한 내용은 App-V 5.0 Sequencer 및 클라이언트 배포 계획을 참조하십시오. 독립 실행형 모델은 다음과 같은 시나리오에 권장됩니다.

    • App-V 5.0 인프라에 연결할 수 없는 원격 사용자의 연결이 끊어진 경우

    • Configuration Manager 2012와 같은 소프트웨어 관리 시스템을 실행 중인 경우

    • 네트워크 대역폭 제한으로 인해 전자 소프트웨어 배포가 금지된 경우

  • 전체 인프라 모델 - 전체 인프라 모델은 소프트웨어 배포, 관리 및 보고 기능에 제공되며, 네트워크에서의 응용 프로그램 스트리밍도 포함합니다. App-V 5.0 전체 인프라 모델은 하나 이상의 App-V 5.0 관리 서버로 구성됩니다. 관리 서버는 응용 프로그램을 모든 클라이언트에 게시하는 데 사용할 수 있습니다. 게시 프로세스가 실행되면 대상 컴퓨터에 가상 응용 프로그램 아이콘 및 바로 가기가 생성됩니다. 응용 프로그램을 로컬 사용자에게 스트림할 수도 있습니다. 관리 서버를 설치하는 방법에 대한 자세한 내용은 App-V 5.0 Server 배포 계획 항목을 참조하십시오. 전체 인프라 모델은 다음과 같은 시나리오에 권장됩니다.

    중요

    App-V 5.0 전체 인프라 모델은 Microsoft SQL Server에서 구성 데이터를 저장해야만 사용할 수 있습니다. 자세한 내용은 App-V 5.0 지원 구성을 참조하세요.

    • 관리 서버를 사용하여 응용 프로그램을 대상 컴퓨터에 게시하려는 경우

    • 응용 프로그램을 대상 컴퓨터에 빠르게 프로비저닝하려는 경우

    • App-V 5.0 보고를 사용하려는 경우

종단 간 서버 크기 조정 지침

다음 섹션에는 종단 간 App-V 5.0 크기 조정 및 계획에 대한 정보가 나와 있습니다. 보다 구체적인 정보는 후속 섹션을 참조하십시오.

참고

클라이언트의 왕복 응답 시간은 App-V 5.0 Client를 실행하는 컴퓨터에서 게시 서버로부터 성공 알림을 받는 데 걸리는 시간입니다. 게시 서버의 왕복 응답 시간은 게시 서버를 실행하는 컴퓨터에서 관리 서버로부터 성공 패키지 메타데이터 업데이트를 받는 데 걸리는 시간입니다.

  • 20,000대의 클라이언트에서 단일 게시 서버를 대상으로 지정하여 허용되는 왕복 시간(3초 미만) 이내에 패키지 새로 고침을 받을 수 있습니다.

  • 단일 관리 서버는 허용되는 왕복 시간(5초 미만) 이내에 최대 50대의 게시 서버에 패키지 메타데이터 새로 고침을 지원할 수 있습니다.

App-V 5.0 관리 서버 용량 계획 권장 사항

App-V 5.0 게시 서버에는 패키지 새로 고침 요청 및 패키지 새로 고침 응답용 관리 서버가 필요합니다. 관리 서버에서는 관리 데이터베이스에 정보를 검색할 정보를 보냅니다. App-V 5.0 관리 서버에서 지원하는 구성에 대한 자세한 내용은 App-V 5.0 지원 구성 항목을 참조하십시오.

참고

App-V 5.0 게시 서버의 기본 새로 고침 시간은 10분입니다.

여러 게시 서버에서 패키지 메타데이터 새로 고침을 위해 단일 관리 서버에 동시에 연결하는 경우 다음과 같은 세 가지 요인에 따라 게시 서버의 왕복 응답 시간이 달라집니다.

  1. 동시 요청을 실행하는 게시 서버 수

  2. 관리 서버에 구성된 연결 그룹 수

  3. 관리 서버에 구성된 액세스 그룹 수

다음 표에는 왕복 시간에 영향을 주는 각 요인에 대한 자세한 내용이 나와 있습니다.

참고

왕복 응답 시간은 App-V 5.0 게시 서버를 실행하는 컴퓨터에서 관리 서버로부터 성공 패키지 메타데이터 업데이트를 받는 데 걸리는 시간입니다.

왕복 응답 시간에 영향을 주는 요인 추가 정보

패키지 메타데이터 새로 고침을 동시에 요청하는 게시 서버 수

  • 단일 관리 서버에서는 메타데이터 게시를 동시에 요청하는 최대 320대의 게시 서버에 응답할 수 있습니다.

  • 320대의 게시 서버에 대한 왕복 응답 시간은 최대 40초입니다.

  • 50대 미만의 게시 서버에서 메타데이터를 동시에 요청할 경우 왕복 응답 시간은 5초 미만입니다.

  • 50~320대의 게시 서버의 경우 응답 시간이 연속적으로 늘어납니다(약 2배).

관리 서버에 구성된 연결 그룹 수

  • 연결 그룹이 100개 이하인 경우 게시 서버의 왕복 응답 시간에 별다른 변화가 없습니다.

  • 연결 그룹이 100~400개인 경우 왕복 응답 시간이 약간 연속적으로 늘어납니다.

관리 서버에 구성된 액세스 그룹 수

  • 액세스 그룹이 40개 이하인 경우 게시 서버의 왕복 응답 시간이 연속적으로 늘어납니다(약 3배).

다음 표에는 앞에서 언급한 각 요인에 대한 샘플 값이 나와 있습니다. 각 변형에서 App-V 5.0 관리 서버로부터 120개의 패키지가 새로 고침된 것으로 가정합니다.

시나리오 변형 연결 그룹 수 액세스 그룹 수 게시 서버 수 네트워크 연결 형식 게시 서버 / 관리 서버 게시 서버의 왕복 응답 시간(초) 관리 서버의 CPU 사용률

게시 서버에서 메타데이터 게시를 위해 관리 서버에 동시에 연결

게시 서버 수

  • 0

  • 0

  • 0

  • 0

  • 0

  • 0

  • 1

  • 1

  • 1

  • 1

  • 1

  • 1

  • 50

  • 100

  • 200

  • 300

  • 315

  • 320

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • 5

  • 10

  • 19

  • 32

  • 30

  • 37

  • 17

  • 17

  • 17

  • 15

  • 17

  • 15

게시 메타데이터에 연결 그룹이 포함됨

연결 그룹 수

  • 10

  • 50

  • 100

  • 150

  • 300

  • 400

  • 1

  • 1

  • 1

  • 1

  • 1

  • 1

  • 100

  • 100

  • 100

  • 100

  • 100

  • 100

  • LAN

  • LAN

  • LAN

  • LAN

  • LAN

  • 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

  • LAN

  • LAN

  • LAN

  • 10

  • 43

  • 153

  • 535

  • 17

  • 26

  • 24

  • 24

관리 서버를 실행하는 컴퓨터의 CPU 사용률은 해당 컴퓨터를 대상으로 하는 게시 서버 수와 관계없이 약 25%입니다. Microsoft SQL Server 데이터베이스 트랜잭션/초, 일괄 요청/초 및 사용자 연결 수는 게시 서버 수와 관계없이 동일합니다. 예: 최대 30개, 일괄 요청 수가 최대 200개, 사용자 연결 수가 최대 6개인 경우를 예로 들 수 있습니다.

관리 서버와 게시 서버 간에 느린 연결 네트워크를 활용하는 지리적으로 분산된 배포를 사용하면 단일 관리 서버에 대한 동시 요청 수가 100개이더라도 게시 서버의 왕복 응답 시간이 허용되는 시간 제한(5초 미만)을 넘지 않습니다.

시나리오 변형 연결 그룹 수 액세스 그룹 수 게시 서버 수 네트워크 연결 형식 게시 서버 / 관리 서버 게시 서버의 왕복 응답 시간(초) 관리 서버의 CPU 사용률

게시 서버와 관리 서버 간의 네트워크 연결

1.5Mbps 느린 연결 네트워크

  • 0

  • 0

  • 1

  • 1

  • 50

  • 100

  • 1.5Mbps 케이블 DSL

  • 1.5Mbps 케이블 DSL

  • 4

  • 5

  • 1

  • 2

게시 서버와 관리 서버 간의 네트워크 연결

LAN / WIFI 네트워크

  • 0

  • 0

  • 1

  • 1

  • 100

  • 200

  • Wifi

  • Wifi

  • 11

  • 20

  • 15

  • 17

관리 서버와 게시 서버가 느린 연결 네트워크를 통해 연결되어 있든지 아니면 고속 네트워크를 통해 연결되어 있든지 상관없이 관리 서버에서는 30분에 약 15,000개의 패키지 새로 고침 요청을 처리할 수 있습니다.

App-V 5.0 보고 서버 용량 계획 권장 사항

App-V 5.0 Client에서는 보고 서버에 보고 데이터를 보냅니다. 그러면 보고 서버에서 Microsoft SQL Server 데이터베이스에 정보를 기록하고 App-V 5.0 Client를 실행하는 컴퓨터에 성공 알림을 다시 반환합니다. App-V 5.0 보고 서버에서 지원하는 구성에 대한 자세한 내용은 App-V 5.0 지원 구성 항목을 참조하십시오.

참고

왕복 응답 시간은 App-V 5.0 Client를 실행하는 컴퓨터에서 보고 서버에 보고 정보를 보내고 보고 서버로부터 성공 알림을 받는 데 걸리는 시간입니다.

시나리오 요약

여러 App-V 5.0 Client에서 보고 서버에 보고 정보를 동시에 보냄

  • 보고 서버로부터 500대의 클라이언트에 대한 왕복 응답 시간은 2.6초입니다.

  • 보고 서버로부터 1000대의 클라이언트에 대한 왕복 응답 시간은 5.65초입니다.

  • 왕복 응답 시간은 클라이언트 수에 따라 연속적으로 늘어납니다.

보고 서버에서 처리되는 초당 요청 수

  • 단일 보고 서버와 단일 데이터베이스에서 초당 최대 139개의 요청을 처리할 수 있습니다. 초당 평균 요청 수는 121개입니다.

  • 동일한 Microsoft SQL Server 데이터베이스에 보고하는 두 대의 보고 서버를 사용할 경우 초당 평균 요청 수는 단일 보고 서버와 유사한 최대 127개이며 초당 최대 요청 수는 278개입니다.

  • 단일 보고 서버에서는 500개의 동시/활성 연결을 처리할 수 있습니다.

  • 단일 보고 서버에서는 최대 1,500개의 동시 연결을 처리할 수 있습니다.

보고 데이터베이스

  • Microsoft SQL Server를 실행하는 컴퓨터의 잠금 경합은 초당 요청 수에 대한 제한 요인입니다.

  • 처리량 및 응답 시간은 데이터베이스 크기에 따라 다릅니다.

임의 지연 계산:

임의 지연은 보고 서버에 보낼 데이터의 최대 지연(분)을 지정합니다. 예정된 작업이 시작될 때 클라이언트에서는 0ReportingRandomDelay 간의 임의 지연을 생성하고 지정된 기간 동안 대기했다가 데이터를 보냅니다.

임의 지연 = 4 * 클라이언트 수 / 초당 평균 요청 수

예: 500대의 클라이언트에서 초당 120개의 요청을 보낼 경우 임의 지연은 4 * 500 / 120 = 최대 17분입니다.

App-V 5.0 게시 서버 용량 계획 권장 사항

App-V 5.0 Client를 실행하는 컴퓨터에서는 App-V 5.0 게시 서버에 연결하여 게시 새로 고침 요청을 보내고 응답을 받습니다. 왕복 응답 시간은 App-V 5.0 Client를 실행하는 컴퓨터에서 측정됩니다. 프로세서 시간은 게시 서버에서 측정됩니다. App-V 5.0 게시 서버에서 지원하는 구성에 대한 자세한 내용은 App-V 5.0 지원 구성 항목을 참조하십시오.

중요

다음 목록에는 App-V 5.0 게시 서버를 설정할 때 고려할 주요 요인이 나와 있습니다.

  • 단일 게시 서버에 동시에 연결하는 클라이언트 수

  • 각 새로 고침의 패키지 수

  • 사용자 환경에서 클라이언트와 App-V 5.0 게시 서버 간에 사용 가능한 네트워크 대역폭

시나리오 요약

여러 App-V 5.0 Client에서 단일 게시 서버에 동시에 연결

  • 듀얼 코어 프로세서를 실행하는 게시 서버에서는 최대 5,000대의 클라이언트에서 동시에 보내는 새로 고침 요청에 응답할 수 있습니다.

  • 클라이언트 수가 5,000~10,000대인 경우 게시 서버에서 쿼드 코어 이상을 실행해야 합니다.

  • 클라이언트 수가 10,000~20,000대인 경우, 보다 효율적인 응답 시간을 위해 게시 서버에서 듀얼 쿼드 코어를 실행해야 합니다.

  • 쿼드 코어를 실행하는 게시 서버에서는 3초 이내에 최대 10,000개의 패키지를 새로 고칠 수 있습니다. 이 경우 10,000대의 동시 클라이언트를 지원합니다.

각 새로 고침의 패키지 수

  • 패키지 수가 증가하면 응답 시간이 40%(최대 10,000개의 패키지)까지 늘어납니다.

App-V 5.0 Client와 게시 서버 간의 네트워크

  • 저속 네트워크(1.5Mbps 대역폭)에서는 LAN(최대 1,000명의 사용자)에 비해 응답 시간이 97% 늘어납니다.

참고

게시 서버에서 동시 요청을 처리해야 하는 동안에는 CPU 사용률이 항상 높습니다(대부분 90%를 초과함). 게시 서버에서는 초당 최대 1,500개의 클라이언트 요청을 처리할 수 있습니다.

시나리오 변형 App-V 5.0 Client 수 패키지 수 게시 서버의 프로세서 구성 네트워크 연결 형식 게시 서버 / App-V 5.0 Client App-V 5.0 Client의 왕복 시간(초) 게시 서버의 CPU 사용률(%)

App-V 5.0 Client에서 게시 새로 고침 요청을 보내고 응답을 받음(각 요청에는 120개의 패키지가 포함됨)

클라이언트 수

  • 100

  • 1000

  • 5000

  • 10000

  • 120

  • 120

  • 120

  • 120

  • 듀얼 코어

  • 듀얼 코어

  • 쿼드 코어

  • 쿼드 코어

  • LAN

  • LAN

  • LAN

  • LAN

  • 1

  • 2

  • 2

  • 3

  • 100

  • 99

  • 89

  • 77

각 새로 고침에 여러 패키지가 포함됨

패키지 수

  • 1000

  • 1000

  • 500

  • 1000

  • 쿼드 코어

  • 쿼드 코어

  • LAN

  • LAN

  • 2

  • 3

  • 92

  • 91

클라이언트와 게시 서버 간의 네트워크

1.5Mbps 느린 연결 네트워크

  • 100

  • 500

  • 1000

  • 120

  • 120

  • 120

  • 쿼드 코어

  • 쿼드 코어

  • 쿼드 코어

  • 1.5Mbps 대륙 내 네트워크

  • 3

  • 10(0.2%의 실패율)

  • 17(1%의 실패율)

App-V 5.0 스트리밍 용량 계획 권장 사항

App-V 5.0 Client를 실행하는 컴퓨터에서는 스트리밍 서버에서 가상 응용 프로그램 패키지를 스트림합니다. 왕복 응답 시간은 App-V 5.0 Client를 실행하는 컴퓨터에서 측정되며, 전체 패키지를 스트림하는 데 걸리는 시간입니다.

중요

다음 목록에는 App-V 5.0 스트리밍 서버를 설정할 때 고려할 주요 요인이 나와 있습니다.

  • 단일 스트리밍 서버에서 응용 프로그램 패키지를 동시에 스트림하는 클라이언트 수

  • 스트림하는 패키지의 크기

  • 사용자 환경에서 클라이언트와 스트리밍 서버 간에 사용 가능한 네트워크 대역폭

시나리오 요약

여러 App-V 5.0 Client에서 단일 스트리밍 서버로부터 응용 프로그램을 동시에 스트림함

  • 동일한 서버에서 동시에 스트림하는 클라이언트 수가 증가하면 패키지 다운로드/스트리밍 시간의 선형 관계가 성립됩니다.

스트림하는 패키지의 크기

  • 패키지 크기는 최대 1GB의 큰 패키지에 대해서만 스트리밍/다운로드 시간에 막대한 영향을 줍니다. 크기가 3~100MB인 패키지의 경우 100대의 동시 클라이언트에 대해 20~100초의 스트리밍 시간이 걸립니다.

App-V 5.0 Client와 스트리밍 서버 간의 네트워크

  • 저속 네트워크(1.5Mbps 대역폭)에서는 LAN(최대 100명의 사용자)에 비해 응답 시간이 70~80% 늘어납니다.

다음 표에는 위 목록의 각 요인에 대한 샘플 값이 나와 있습니다.

시나리오 변형 App-V 5.0 Client 수 각 패키지의 크기 네트워크 연결 형식 스트리밍 서버 / App-V 5.0 Client App-V 5.0 Client의 왕복 시간(초)

여러 App-V 5.0 Client에서 스트리밍 서버로부터 가상 응용 프로그램 패키지를 스트림함

클라이언트 수

  • 100

  • 200

  • 1000



  • 100

  • 200

  • 1000

  • 3.5 MB

  • 3.5 MB

  • 3.5 MB



  • 5 MB

  • 5 MB

  • 5 MB

  • LAN

  • LAN

  • LAN



  • LAN

  • LAN

  • LAN

  • 29

  • 39

  • 391



  • 35

  • 68

  • 461

스트림하는 각 패키지의 크기

각 패키지의 크기

  • 100

  • 200



  • 100

  • 200

  • 21 MB

  • 21 MB



  • 109

  • 109

  • LAN

  • LAN



  • LAN

  • LAN

  • 33

  • 83



  • 100

  • 160

클라이언트와 App-V 5.0 스트리밍 서버 간의 네트워크 연결

1.5Mbps 느린 연결 네트워크

  • 100



  • 100

  • 3.5 MB



  • 5 MB

  • 1.5Mbps 대륙 내 네트워크

  • 102



  • 121

각 App-V 5.0 스트리밍 서버에서 가상화된 응용 프로그램을 동시에 스트림하는 클라이언트를 200대 이상 처리할 수 있어야 합니다.

참고

스트림하는 데 실제로 걸리는 시간은 주로 동시에 스트림하는 클라이언트 수, 패키지 수, 패키지 크기, 서버의 네트워크 활동 및 네트워크 상태에 따라 결정됩니다.

예를 들어 100대의 클라이언트에서 서버로부터 동시에 스트림하는 경우 사용자가 100MB의 패키지를 스트림하는 데 걸리는 시간은 평균적으로 2분 미만입니다. 하지만 패키지 크기가 1GB인 경우에는 30분까지 걸릴 수 있습니다. 대부분의 실제 환경에서는 스트리밍 요구가 균일하게 분산되지 않으므로, 필요한 스트리밍 서버 수를 적절히 조정하려면 사용자 환경에 주어진 대략적인 최대 스트리밍 요구 사항을 파악해야 합니다.

스트리밍 서버에서 지원할 수 있는 클라이언트 수는 크게 늘어날 수 있으며 응용 프로그램을 사전에 캐시하는 경우에는 최대 스트리밍 요구 사항이 줄어듭니다. 필요 시 스트리밍 제공 및 스트림 최적화 패키지를 사용하여 스트리밍 서버에서 지원 가능한 클라이언트 수를 늘릴 수도 있습니다.

App-V 5.0 서버 역할 결합

크기 조정 및 내결함성 요구 사항을 줄이면 Active Directory에 연결하는 위치에 필요한 최소 서버 수가 한 대로 줄어듭니다. 이 서버에서 관리 서버, 관리 서버 서비스, Microsoft SQL Server 역할을 호스트합니다. 따라서 서버 역할은 서로 충돌하지 않으므로 얼마든지 적절히 결합하여 정렬할 수 있습니다.

크기 조정 요구 사항을 무시할 경우에는 내결함성 구현을 제공하는 데 4대 이상의 서버가 필요합니다. 관리 서버와 Microsoft SQL Server 역할 지원은 내결함성 구성에 적용됩니다. 관리 서버 서비스는 모든 역할과 결합할 수 있지만 단일 실패 지점이 남습니다.

다양한 내결함성 전략 및 기술을 사용할 수 있지만 지정된 서비스에 모두 적용 가능한 것은 아닙니다. 그뿐만 아니라, App-V 5.0 역할이 결합될 경우 특정 내결함성 옵션은 비호환성으로 인해 더 이상 적용하지 못할 수 있습니다.

App-V에 대한 제안 사항이 있으신가요?

여기에서 제안 사항을 추가하거나 투표해 보세요. App-V 문제가 있는 경우 App-V TechNet 포럼을 사용하세요.

참고 항목

개념

App-V 5.0 지원 구성
App-V 5.0을 사용한 고가용성 계획

기타 리소스

App-V 배포 계획

-----
TechNet 라이브러리에서 MDOP에 대해 자세히 알아보거나 TechNet 위키에서 문제 해결을 검색하거나 Facebook 또는 Twitter에서 Microsoft를 팔로우할 수 있습니다.
-----