태그: VMware

VMware ESXi에 설치된 LSI(Avago/Broadcom) 레이드카드 모니터링하기

 

물리 서버에 설치된 LSI 레이드 카드는 MSM(MegaRAID Storage Manager)를 통해서 모니터링이 가능합니다.

하지만,  OS로 ESXi를 사용한다면 MSM은 기본적으로 레이드 카드를 인식하지 못 합니다. 물론 ESXi도 레이드 카드의 정보를 불러오지 못합니다.
ESXi 호스트에 설치된 LSI 레이드 카드를 모니터링 하려면 먼저 LSI SMIS Provider를 설치해야 합니다.

1) https://www.broadcom.com/support/download-search 에서 적절한 카테고리를 선택한 뒤 키워드로 “SMIS”를 입력하면

Latest SMIS Providers라고 되어 있는 소프트웨어 패키지를 다운로드 할 수 있습니다.

2) ESXi 호스트에 이 vib를 설치합니다.

3) 호스트를 재부팅하고, ESXi 호스트의 방화벽을 비활성화합니다. (주의: 프로덕션 환경에서 방화벽을 비활성화하는 것은 위험할 수 있음)

이것으로 ESXi 호스트의 준비가 끝났습니다.

 

 

다음으로, 적절한 PC에 매니지먼트 프로그램을 설치해야 합니다.

2018년부터 MSM이 Deprecated 되고, 대신 LSI Storage Authority가 MSM을 대체하였습니다.

 

1) Broadcom 다운로드 페이지에서 LSA를 다운로드, 설치하고 localhost:2463으로 접속하면 LSA가 설치된 컴퓨터가 보일 것입니다.

2) 무시하고 Manual Discovery를 선택합니다.

3) 타깃 ESXi 호스트의 IP를 입력 후 Search를 클릭하면 호스트가 보일 것입니다. Add 버튼을 눌러 Remote Server 목록에 추가합니다.

4) Sign In을 눌러, 서버에 로그인합니다. 이 때 사용되는 인증은 ESXi의 인증과 동일합니다.

5) MSM과 비슷하게 LSI 레이드 카드를 원격으로 관리할 수 있습니다.

 

Appendix A. Troubleshooting

Problem) 정상적인 인증을 입력하였음에도 Error Code:65537 : Logon failure: unknown user name or bad password 이라는 메시지가 뜨며, 로그온이 되지 않는다.

Solution) “LSAService” 서비스를 재시작한다.

 

Appendix B. ESXi 방화벽 설정

ESXi의 방화벽은 로드될 때 /etc/vmware/firewall/에 있는 .xml 파일들을 전부 참조한다.

따라서 적당한 이름의 xml파일을 생성하고, 다음과 같이 입력하면 방화벽이 활성화 된 상태에서도 LSA를 사용할 수 있다.

 

ESXi 호스트의 방화벽 설정은 호스트가 재부팅되면 초기화되기 때문에, 이것을 영구적으로 적용하려면 커스텀 vib를 만들 필요가 있다.

이것은 추후 별도의 글을 통해 설명할 것이다.

PowerCLI OSCustomizationNicMapping Default Gateway 문제

VMware의 PowerCLI를 통한 deployment 기능 중 OS Customization이 있습니다.

웹 콘솔에서는 ‘VM 사용자 지정 규격’이라고 불리는 기능인데, VMware Tools가 설치된 VM을 대상으로 (일반적으로) 최초 부팅 때 어느 정도의 기본적인 설정을 적용할 수 있게 해 줍니다. 웹 콘솔에서는 유연성이 부족하여 사용하지 않았지만, PowerCLI를 사용한다면 아주 유연한 배포 스크립트를 작성할 수 있습니다.

그 중 네트워크 설정을 제어하는 OSCustomizationNicMapping에서 IpMode로 UseStaticIP를 사용할 경우, Default Gateway를 입력할 것을 요구하는 문제가 있습니다.

덕분에 기본적으로 제공하는 cmdlet은

1. 모든 NIC에 DHCP를 적용하거나
2. 하나의 NIC를 사용하고 고정 IP를 할당하거나
3. DHCP와 고정 IP를 섞어서 사용하되, 디폴트 게이트웨이는 고정 IP의 것을 사용하거나

라는 세가지 케이스에 한해 사용할 수 있습니다.

대체 왜 이렇게 구현해뒀는지 도무지 이해를 할 수가 없습니다.

저는 고정 IP 하나를 사용하고, DHCP를 통해 디폴트 게이트웨이를 가져와야 했으므로, 하위 클래스를 통해 직접 CustomizationSpec 객체를 생성하였습니다.

기본적인 틀은 VMware Forum의 글에서 확인하실 수 있으며, Windows가 아닌 리눅스 시스템에 적용하기 위한 차이점, DHCP 할당을 위한 설정을 언급하도록 하겠습니다.

1. 리눅스 VM에 적용하기 위한 설정

– $item.Info.Type 을 “Windows”에서 “Linux”로 변경합니다.
– $item.Spec.Identity = New-Object VMware.Vim.CustomizationSysPrep 대신 $item.Spec.Identity = New-Object VMware.Vim.CustomizationLinuxPrep을 사용합니다.
– 리눅스 VM에서는 윈도의 Workgroup, FullName 대신 Domain을 반드시 입력해야 합니다. 따라서 $item.Spec.Identity.domain을 입력해 줍니다.
– $item.Spec.Identity.hostName을 반드시 입력해야 하는데, 요구하는 Type이 String이 아닙니다.
$LinuxPrepName = New-Object VMware.Vim.CustomizationFixedName
$LinuxPrepName.Name = <String>
$item.Spec.Identity.hostName = $LinuxPrepName

으로 입력해 줍니다.

2. DHCP IP 할당

$nic = New-Object VMware.Vim.CustomizationAdapterMapping
$nic.Adapter = New-Object VMware.Vim.CustomizationIPSettings
$nic.Adapter.Ip = New-Object VMware.Vim.CustomizationDhcpIpGenerator
$item.Spec.NicSettingMap += $nic

이제 원하는 OS Customization Spec을 생성할 수 있습니다.

ESXi Maximum virtual machines limit reached 오류

ESXi는 CPU에 따라 하나의 코어에서 실행될 수 있는 vCPU의 개수에 제한을 둔다.

이 값은 기본적으로 런타임에 결정되며, CPU의 성능에 따라서 더 많은 vCPU를 실행할 수 있게 된다.

 

그런데 VM을 배포하다 보면 이 vCPU 제한을 초과하는 경우가 생길 수 있다.
VMware에서 권장하는 것은 하드웨어의 업그레이드지만, 피치 못할 경우 커널 패러매터를 수정하여 vCPU 제한을 늘릴 수 있다.

ESXi 쉘에 접근하여 다음과 같은 명령을 입력한다.

그리고 ESXi 호스트를 재부팅하면 변경된 설정이 적용된다.

이 기능은 VMware의 권장 설정을 벗어나는 것으로, 시스템을 불안정하게 만들 수 있다.
테스트 환경에서만 적용하고, 프로덕션 환경에서는 하드웨어 업그레이드로 대응하기를 권한다.

VMware Horizon 7 – Latency에 따른 PCoIP 이미징 성능 평가

 

1. 들어가며

VMware Horizon을 사용하면서 늘 하나의 의문이 맴돌았습니다.
‘대한민국 안에서는 전송 지연이 아주 적지만, 만약 지연이 크다면 성능에 어떤 악영향을 미칠 것인가?’

아무리 구글을 뒤져봐도 실제 환경에서 이런 테스트를 한 사람이 없어서, 직접 측정해보기로 했습니다.

결론부터 이야기하자면, 이미징 성능은 지연시간에 큰 영향을 받지 않았지만 입력 지연은 그대로 드러났습니다.
Teradici에서는 입력 지연 때문에 30ms 이하의 지연을 유지하라고 권고한 것으로 보입니다.

 

2. 테스트 환경

서버(VM): Intel Xeon E7-4890v2 (VM에 24Thread 할당) / Windows 7 SP1 / Horizon Agent 7.1
클라이언트: Dell P45 Zero Client (Tera2140 탑재)

제로 클라이언트는 WAN 환경에서 Horizon Security Gateway를 통해 VM에 접속하였으며, 회선의 Round-Trip Latencty는 10ms입니다.
여기서 의사적인 네트워크 지연을 만들기 위하여 리눅스 머신과 제로 클라이언트를 브릿지, Traffic Control을 적용했습니다.

테스트는 Youtube에서 동영상을 재생하여 재생시간 동안의 세션 데이터를 수집하는 방법으로 이루어졌습니다. 테스트에 사용한 동영상은 링크에서 확인하실 수 있습니다.

제로 클라이언트가 아닌 Horizon Client에서의 성능도 확인해보고 싶었으나, 현재 사용중인 시스템의 CPU 성능이 낮아 이미징 디코딩에 지연이 발생하였습니다.
테스트 환경이 개선되면 추가하도록 하겠습니다.

 

3. 테스트 결과

PCoIP Statistics Viewer를 통해 세션 정보를 수집, 그래프로 나타냈습니다.
TX Bandwidth는 Kbit, Round Trip Latency는 ms, Encoded Frames은 fps입니다.

3-1. 10ms 지연

 

3-2. 30ms 지연

6번 샘플부터 동영상 재생이 시작됩니다.

 

3-3. 50ms 지연

5번 샘플부터 동영상 재생이 시작됩니다.

 

3-4. 100ms 지연

21번 샘플부터 동영상 재생이 시작됩니다.

 

3-5. 130ms 지연

10번 샘플부터 동영상 재생이 시작됩니다.

결론적으로 동영상 재생에 있어서 latency의 영향은 그다지 느껴지지 않았고, 140ms 지연에서 음성이 밀리는 현상도 일어나지 않았습니다.
하지만 latency가 낮을수록 화면이 전환될 때 생기는 짧은 끊김 현상이 일어나는 빈도가 적었고, 무엇보다 입력 지연은 latency의 영향을 그대로 드러내었습니다.
30ms 이하의 환경에서는 입력 지연을 그다지 체감할 수 없었으므로, 쾌적한 사용을 위해서는 30ms 이하의 지연시간을 유지할 필요가 있겠습니다.

오히려 주목해야 할 부분은 바로 TX Bandwidth입니다. 1080P 단일 모니터를 사용했음에도 불구하고 피크 비트레이트가 무려 55Mbps에 육박하는 것을 확인할 수 있었습니다.
최상의 이미지 퀄리티를 얻기 위해서는 대역폭의 확보가 매우 중요하며, 만약 대역폭을 충분히 확보하지 못했다면 Maximum Image Quality를 적절한 수준까지 낮춰야 할 것입니다.

 

5. 시연 영상

140ms의 지연이 걸리는 환경에서 원본 영상과 1:1 비교를 해 보았습니다.

중간 중간 화면 전환시 끊기는 것을 제외하면 부드럽게 재생되는 것을 확인할 수 있습니다.
∗해상도와 모니터의 수에 따라 이 결과는 얼마든지 달라질 수 있습니다.

6. 결론

PCoIP를 사용할 때 지연시간의 영향은 응용에 따라 크게 느껴질 수도 있고, 작게 느껴질 수도 있습니다.
만약 키보드와 마우스를 사용하여 생산적인 일을 할 때 지연시간이 크다면 사용자가 체감하는 성능은 최악일 것입니다.
하지만 단순히 디스플레이 용도라면 지연시간은 크게 중요하지 않습니다. 오히려 대역폭을 더 중시해야 할 것입니다.

이번 테스트를 하면서 중간 중간 0.4~0.6% 가량의 패킷 로스가 발생하였는데, 패킷 로스가 발생하는 타이밍에 맞추어 끊김이 일어났습니다.
결국 자연스러운 이미지를 얻고 싶다면 가장 먼저 패킷 로스를 확인하고, 그 다음으로 대역폭을 확인하고, 마지막으로 지연 시간을 확인하면 되겠습니다.

입력 지연이 중요하다면 지연시간을 최우선으로 낮춰야 할 것입니다.

Teradici Remote Workstation Card 사용기

1. 들어가며

Teradici Remote Workstation Card는 물리 머신에 장착하여 PCoIP를 통해 호스트로 접근할 수 있게 해 주는 장비이다.
Tera2 계열 제품군으로 Tera2220과 Tera2240이 있으며, 각각 지원하는 모니터의 최대 대수는 2/4대이다.

이번에 사용한 모델은 Tera2240을 탑재한 것으로, 2560×1600 해상도의 모니터를 2대까지 지원한다.

디스플레이 연결을 위한 포트로 mDP 4개를 제공하며, 기가비트 이더넷으로 연결된다.
한 가지 특기할 점은 유사 솔루션들은 드라이버를 통해 그래픽 데이터를 전송받고, 그것을 하드웨어에서 처리하여 내보내는데, Remote Workstation Card는 디스플레이 입력 단자가 그래픽카드의 출력 단자에 직접 연결된다.
따라서 소프트웨어 드라이버 기반의 솔루션들에서 보이는 어플리케이션 호환성 문제나 이미징 성능 저하 문제를 해결할 수 있었다.

 

2. Teradici Remote Workstation Card 설치

카드를 Dell Precision R7910에 설치하였다. PCI-E 슬롯에 장착한 뒤 케이블을 연결해 준다.
이 때 2560×1600 해상도를 지원하려면 반드시 DP 케이블을 사용해야 한다.

 

카드에 할당된 IP 주소를 통해 접속하면 관리자 페이지에 접근할 수 있다. 여기서 Remote Workstation Card의 설정과 세션 정보, 통계 등을 볼 수 있다.

소프트웨어 클라이언트를 사용할 것이라면 호스트 드라이버 기능을 활성화해주자.

하드웨어 장착이 완료되면 소프트웨어를 설치해주어야 한다. 나는 VMware Horizon을 통해 접속할 것이므로 먼저 Horizon Agent를 설치하고 PCoIP Host Software를 설치했다.
Host Software는 여기서 다운로드할 수 있다.

소프트웨어 설치가 완료되었다면 이제 외부로부터의 접속이 가능하다. 본인이 사용하는 클라이언트를 이용하여 호스트에 접속할 수 있을 것이다.
다만 최상의 성능을 위해서는 제로 클라이언트를 사용할 것을 권장한다.

 

3. 실성능 평가

그렇다면 실제 성능은 어느 정도일까? 백문이 불여일견, 직접 보도록 하자

Tera2321 제로 클라이언트를 통해 2560×1440 해상도로 Youtube 4K 60fps 동영상을 재생하는 모습이다.

Horizon Security Gateway를 통해 WAN으로 접속하였으며, Round-trip-latency는 약 10ms이다.

 

4. 마무리

Teradici Remote Workstation Card와 PCoIP Zero Client의 조합은 현재 사용할 수 있는 기술 중 최고의 퍼포먼스를 보여준다고 해도 과언이 아닐 것이다.
본인이 그래픽 작업을 하며, 어디에서나 끊김없이 작업할 수 있는 환경이 필요하다면 Teradici Remote Workstation Card의 사용을 검토해 보자.

여기서는 접속을 위해 VMware Horizon을 사용하였지만, Teradici의 제품군만으로도 동일한 환경을 구축할 수 있다. 이 경우 라이센스 비용을 크게 절감할 수 있을 것이다.

 

NVIDIA GRID를 이용한 VMware Horizon 기반 VDI 구성

 

가상 데스크탑 환경(VDI)에서 클라이언트에게 3D 가속 기능을 제공하는 것은 쉽지 않다. 때문에 제대로 된 가속 성능을 제공하려면 NVIDIA에서 나온 GRID 시리즈를 사용해야만 한다. 요새는 별도의 GRID 라인업 대신 테슬라에 vGPU 라이센스를 적용,활성화 하는 방식을 택하고 있지만, 세팅에 사용한 것이 GRID K2였기에 라이센스 추가 없이 사용할 수 있었다.

GRID를 사용할 수 있는 플랫폼은 VMware사의 Horizon과 Xen의 XenDesktop이 있는데, 실제 NVIDIA와의 연계 및 사후지원을 고려한다면 Horizon이 적절한 선택일 것이다. 물론 가격은 XenDesktop쪽이 더 싸지만.

ESXi 호스트에서 GRID K2 두장으로 K6000급의 가속 성능을 가지는 VM 4대를 생성하였다. VM의 댓수는 주로 그래픽 메모리의 크기에 좌우되며, K2의 경우 최대 16대까지의 VM을 할당할 수 있다.

구현해놓고 든 생각이지만, 역시 소규모 시스템에 Horizon을 위시한 VDI 솔루션은 적합하지 않다. 기본적으로 요구하는 인프라가 상당하며, 이것을 관리할 수 있는 인원이 상주하고 있어야 하기 때문이다. 그 인원이 여러 트러블슈팅까지 수행할 수 있어야 한다면? 그것 또한 비용이다.

활용도 또한 애매하다고 볼 수 있다. 원격으로 접근할 수 있는 워크스테이션 정도의 역할을 가지는데, 적절한 공간만 있다면 물리 장비에 Teradici Workstation Card를 설치하는 것으로 동등한 수준의 환경을 제공할 수 있기 때문이다.

결국 원래 개발 용도대로 다량의 VM에 3D 가속 기능을 제공하고 싶을 경우에 가장 적합한 솔루션이라고 볼 수 있겠다.

 

VMware Horizon 7과 EUC Unified Access Gateway 배포

 

VMware Horizon  7로 넘어오면서 VMware Access Point가 EUC Unified Access Gateway로 변경되었다. Access Gateway는 Security Server를 대체하며, 리눅스 어플라이언스의 형태로 배포되기에 추가적인 윈도 서버 라이센스가 필요없다는 장점이 있다.

그럼 이제 EUC Unified Access Gateway의 배포 방법을 알아보도록 하자.

 

1. VMware에서 EUC Unified Access Gateway의 OVA 파일을 다운받는다. 이 때 FIPS와 일반 버전 두 종류의 어플라이언스가 존재하는데, FIPS는 미국 정부의 보안 표준인 FIPS 140-2를 준수하는 버전을 말한다. FIPS 버전의 OVA를 배포할 경우, FIPS 140-2에 포함된 암호화 라이브러리를 사용하는 제한된 서비스만을 제공하게 된다.

2. vCenter Web Client를 열고, 네트워크 프로토콜 프로파일을 작성한다. 네트워크 프로토콜 프로파일은 데이터센터의 네트워크 설정에서 만들 수 있다. 나는 2개의 링크를 사용할 것이기에 2개의 네트워크 프로토콜 프로파일을 작성하였다.

3. OVA 템플릿을 배포한다. 2개의 NIC를 사용할 것이기에 2NIC를 선택하였다.

 

4. 매니지먼트 네트워크와 백엔드 네트워크를 내부망으로, 인터넷을 미리 고정 IP를 할당해 둔 외부망과 연결한다.
이 때 네트워크 프로토콜 프로파일이 없으면 설정을 적용할 수 없으니, 반드시 미리 작성해 두고 OVA를 배포하자.

 

5. EUC Access Gateway의 네트워크 설정을 배포한다. 이 때 처음 나오는 DNS/Gateway/Netmask는 외부망의 정보를 입력한다.
그리고 두번째 나오는 DNS에는 내부 DNS를, 디폴트 게이트웨이는 역시 외부망의 정보를 입력한다.
마지막으로 STATICV4를 입력한 뒤 적절한 IP 주소를 용도에 맞춰 할당해 준다.

이것으로 EUC Unified Access Gateway의 배포가 완료되었다.

EUC Unified Access Gateway 어플라이언스의 배포가 완료된 뒤에는, 사전에 할당해두었던 내부망 IP 주소를 참고하여
https://EUC_Access_Gateway_FQDN:9443/admin으로 접속하여 초기 설정을 진행하면 된다.

VMware Horizon 6.2 설치/구성 – (5) Direct Connection 설치/구성

 

1. VMware Horizon View Agnet / Direct Connection Plug-In 설치

VMware Horizon은 피치 못할 이유나, 기타 구성 문제로 View Connection Server를 통한 접속이 불가능한 경우를 위해 클라이언트에서 VM으로 직접 접속이 가능한 Direct Connection이라는 플러그인을 제공하고 있습니다.

View Agent 설치 후 Direct Connection 플러그인을 설치하면, 클라이언트에서 해당 VM의  FQDN으로 직접 접속이 가능해집니다.

 

Horizon Agent와 Direct Connection은 기본적으로 VMware 하이퍼바이저 위에서 동작하도록 설정되어 있으나 KVM, Hyper-V, 심지어는 물리 머신 위에 설치할 수도 있습니다.

기본적으로, 이 경우에는 설치할 때 해당 게스트를 관리할 Connection Server의 주소를 제공해야 합니다.

KakaoTalk_20160519_230754148

그러나, VMware에서는 이 제한을 우회할 수 있는 방법을 제공합니다.

명령 프롬프트를 열고, Horizon Agent 설치 파일이 있는 폴더로 이동합니다. 그리고 다음과 같은 명령으로 설치 프로세스를 시작합니다.

이제 Connection Server의 주소를 제공하지 않고도 설치가 진행됩니다.

Agent의 설치가 완료된 뒤, Direct Connection을 설치하면 클라이언트로부터의 직접 접속이 가능해집니다.

  설치 과정에서 Horizon 라이센스의 검증은 이루어지지 않습니다. 하지만 이 VM/물리 머신에 접속하는 세션도 Horizon의 기능을 이용하는 것이기에, 적절한 수량의 Concurrently Connected User 라이센스가 필요합니다.

 

2. NAT / 포트포워딩 설정하기

NAT가 적용된 호스트에 접속하기 위해서는 포트포워딩이 필요합니다. PCoIP는 SSL 연결에 443, PCoIP 연결에 TCP/UDP 4172를 사용합니다.

또한, 올바른 External IP Address를 설정해야 합니다. 3번PCoIP Session 설정 (ADM파일 이용)을 참조하십시오.

 

이 설정은 레지스트리를 수정하는 것으로 수행될 수도 있습니다. 레지스트리 설정값은 다음과 같습니다.

파워 쉘 스크립트를 이용하여 유동 IP 환경에 대응하는 것 또한 가능합니다.

예제 파워 쉘 스크립트입니다.

이 스크립트를 작업 스케줄러에 등록하고, 주기적으로 실행시켜줄 수 있습니다. 해당 스크립트를 실행하기 위해서는 스크립트 실행 권한과 관리자 권한이 필요합니다.

스크립트 실행 권한을 얻기 위해서는 파워 쉘을 관리자 권한으로 실행하고 다음 명령어를 입력합니다.

 

3. PCoIP Session 설정 (ADM 파일 이용)

  그룹 정책 관리 탬플릿(ADM)을 이용하기 위해서는 사용중인 Windows의 버젼이 Professional 이상이어야 합니다.

3-1. 로컬 그룹 정책을 편집하기 위하여 gpedit.msc를 실행합니다.

Group_Policy-1

3-2. 컴퓨터 구성 – 관리 탬플릿을 우클릭, 탬플릿 추가/제거를 선택합니다.

 

Group_Policy-2

3-3. Horizon View Agent Direct Connection의 관리 템플릿을 추가합니다. 경로는 <Agent 설치 폴더>\extras\ 입니다.

 

Group_Policy-3

3-4. ADM을 통하여 Direct Connection 세션의 설정을 변경할 수 있습니다.

View Administrator의 그것에 비하여 설정할 수 있는 옵션이 적지만, 반드시 필요한 설정들은 다 사용할 수 있습니다.

 

4. 테스트 결과 / 확인된 문제들

1-1. KVM / Windows 10 에서의 정상 동작을 확인하였습니다.

1-2. 물리 머신의 Windows 8.1 / Hyper-V 위의 Windows 8.1에서 마우스 포인터가 사라지고, 키보드가 먹통이 되는 문제를 확인하였습니다. Windows 8.1과의 호환성 문제인지, Hyper-V와 물리 머신 드라이버의 호환 문제인지는 확인되지 않았습니다.

에러 로그는 다음과 같습니다.

확인 결과 Hyper-V의 통합 드라이버가 문제를 발생시키는 것으로 보입니다. / Integration Service 비활성화 후 진행, 여전히 동작하지 않습니다.

1-3. Windows 10 / Hyper-V 또한 동작하지 않습니다. Hyper-V와 호환되지 않는 것으로 보입니다.

5. 함께 보기

 

1. VMware Horizon 6.2 설치/구성 – (0) VMware Horizon 소개

2. VMware Horizon 6.2 설치/구성 – (1) 사전 준비와 설치 

3. VMware Horizon 6.2 설치/구성 – (2) VMware Horizon 설정

4. VMware Horizon 6.2 설치/구성 – (3) 보안 서버에 SSL 인증서 배포하기

5. VMware Horizon 6.2 설치/구성 (4) – ThinApp 배포하기

6. VMware Horizon 6.2 설치/구성 – (5) Direct Connection 설치/구성(현재 포스트)

 

Teradici사의 PCoIP 솔루션 정리

 

Teradici는 PCoIP라는 원격 제어 프로토콜을 개발한 회사이며, PCoIP는 VMware Horizon과 Amazon Workspace에서 사용되고 있다.

비슷하게 HDX라는 프로토콜을 개발한 Citrix와는 달리, PCoIP는 단일 소프트웨어로도 판매된다.

그럼, Teradici사의 하드웨어/소프트웨어 솔루션 라인업을 알아보도록 하자.

 

하드웨어 솔루션

 

1. PCoIP Remote Workstation Card

 

All Rights Reserved by LeadTek

Teradici사의 Tera 시리즈 칩을 탑재한 확장 카드이다. 그래픽 카드의 출력 포트와 연결되어 비디오 스트림을 수신하고, PCoIP 패킷을 광케이블 혹은 UTP 케이블을 통해 전송한다.

사진의 Workstation Card는 Tera2220을 탑재하고 있다.

이 카드를 꽂은 PC/워크스테이션에 PCoIP Host Software를 설치하면 Zero Client/PCoIP Software Client를 통해 원격에서 접근할 수 있게 된다.

 

2. PCoIP Zero Client

PCoIP 프로토콜을 하드웨어적으로 지원하는 Tera2(Tera2321/2140)을 탑재한 장비다. 전용 칩을 사용하기에 Thin Client보다 빠르며, 전력을 적게 소모한다.

VMware Horizon, Amazon Workspace와 Teradici Pervasive Computing Platform과 함께 사용된다.

 

 

 

소프트웨어 솔루션

Teradici-PCoIP

1. Teradici Pervasive Computing Platform

Teradici의 VDI 솔루션. Desktop Edition과 Graphics Edition으로 나뉜다. Graphics Edition은 Desktop Edition에 GPU 지원이 추가된 제품이다.

Pervasive Computing Platform은 Agent, Connection Manger, Security Server로 구성된다. 그런데, 어디서 많이 본 듯한 느낌이 들지 않는가?

그렇다. VMware Horizon의 구성과 매우 유사하다. 용도도 같고.. Xen Desktop도 그렇고 결국 개념이 비슷하면 구현 또한 비슷해지는 듯 하다.

VMware Horizon/Xen Desktop과의 차이점은 중앙 관리 기능을 제외한 1:1 연결 기능을 제외하고, 이에 대한 라이센스도 같이 판매한다는 것이다.

VMware Horizon도 Direct Connection이라는 플러그인을 통해 브로커(Horizon Connection Server) 없는 접속을 지원하긴 하지만, 이를 위한 라이센스를 따로 판매하지는 않는다. VADC(View Agent Direct Connection)을 이용하기 위해서는 Horizon Suite의 Concurrently Connected Desktop 라이센스 개수가 충분해야 한다. 강제성이 없긴 하지만.

반면에, Teradici의 Pervasive Computing Platform은 이러한 연결을 위한 라이센스를 영구 라이센스 1카피당 199달러에 판매하고 있다.

그리고 VMware Horizon이 VMware vSphere에 의존적인 것에 비하여 Teradici는 다양한 Hypervisor 위에서 사용할 수 있다는 장점이 있다. 이 점은 Xen Desktop 또한 마찬가지이다.

 

2. PCoIP Management Console

 

PCoIP Management Console

Teradici의 Tera 칩셋을 사용한 Zero Client들을 관리하기 위한 소프트웨어이다.

Teradici의 다른 솔루션과 다르게 무료인 Standard Edition과 유료인 Enterprise Edition이 나뉘어져 있으며, Enterprise Edition은 각 클라이언트의 중앙 집중 제어 기능과, 관리 가능한 클라이언트 대수 제한(2000대)가 해제되었다.