May 30, 2012

VDI를 위한 스토리지 프로토콜

김우용 기자 yong2@zdnet.co.kr 2012.05.29 / PM 02:09

가상 데스크톱 인프라(VDI) 프로젝트는 통상적으로 사용자당 80만~120만원 수준으로 예산을 책정한다. 프로젝트 규모가 클수록 사용자당 도입가격은 줄어든다. 이는 일반 기업이 직원에게 지급하는 데스크톱PC, 노트북 등의 가격과 유사한 수준이다.

VDI는 각 직원에게 지급됐던 CPU, 메모리, 하드디스크 등을 중앙의 데이터센터로 한데 모으는 것이다. PC용과 서버용 CPU의 가격이 같을 수 없고, 디스크도 마찬가지다. 제대로 된 성능을 내려면 기업 내 백본 네트워크 인프라도 대폭 업그레이드해야 한다.

일반 사용자에게 지급되는 씬클라이언트나 제로클라이언트의 가격자체는 PC보다 저렴하지만 전체적인 구축 비용은 PC지급 수준과 비교할 수 없을 정도로 막대하다. 때문에 무턱대고 VDI 프로젝트를 대규모로 기획했던 기업들은 구축 과정에서 계속 늘어나는 투자비용에 사업 자체를 포기하기 쉽다.

무엇보다 VDI프로젝트의 구축비용을 키우는 요소는 스토리지다. 어떤 스토리지를 사용하느냐에 따라 VDI프로젝트의 단가가 결정된다. 여기서 스토리지 프로토콜의 대결이 시작된다.

■1차 대결, FC SAN이냐 NAS냐

VDI를 위한 스토리지 프로토콜의 첫번째 대결은 FC SAN과 NAS 간 벌어졌다.

초기 VDI프로젝트는 SAN 중심이었다. 데이터 전송과 성능 안정성에서 SAN이 앞도적이기 때문이다. 하지만 SAN은 장비 자체의 비용도 비싸 증설하기 쉽지 않다.

이후엔 이더넷을 이용하는 네트워크 스토리지(NAS)가 주목받았다. SAN에 비해 저렴한 가격 덕분이다. 하지만 NAS는 데이터의 안정성을 100% 보장하지 못한다는 한계가 있다.

이후의 해법으로 SAN과 NAS를 혼용하는 방법이 도입됐다. 운영체제, 애플리케이션 설치 영역을 SAN으로, 사용자 데이터 저장 영역을 NAS로 구성한다. 빠르게 증설해야 하는 데이터 영역을 NAS로 하는 만큼 증설비용을 줄일 수 있지만, 네트워크에서 문제가 생긴다. 서버와 스토리지를 연결하는 방식이 복잡해지고, 비용도 늘어나기 때문이다.

■유니파이드 스토리지와 I/O통합

SAN과 NAS의 대결에서 승자는 없었다. SAN과 NAS를 적절히 혼합하는 사용법이 대세를 이루고 있다. 그와 함께 한 장비에서 SAN과 NAS를 모두 지원하는 유니파이드 스토리지가 주목받았다.

SAN과 NAS를 장비 하나에서 모두 지원한다는 발상은 I/O 자체를 통합하는 수준으로 이어졌다. 어떤 식으로든 서버와 스토리지가 FC 프로토콜을 유지하는 한 케이블이 복잡해지고 서버의 NIC, HBA 카드 비용이 늘어나기 때문이다.

I/O통합의 첫 시작은 iSCSI 프로토콜이다. TCP/IP 프로토콜에 SCSI 명령어 세트를 매핑해 전송한다. IP 네트워크를 이용한 SAN 환경이라 볼 수 있다. 또 다른 통합 프로토콜은 FCoE다. FCoE는 물리적으론 이더넷망을 사용하지만 FC SAN 프로토콜을 그대로 사용한다.

2차 대결은 FCoE와 iSCSI의 구도다. 그러나 두 프로토콜 역시 저마다의 장단점을 갖고 있다. FCoE는 기존 스토리지와 동일한 명령어를 사용하면서 데이터 전송의 안정성이 높지만, iSCSI에 비해 비싸다. 반대로 iSCSI는 FCoE보다 싸지만, 데이터 안정성이 부족하다.

이는 근본을 이루는 FC SAN과 TCP/IP의 데이터 전송방식 차이에서 비롯된다. FC는 데이터를 전송할 때 받는 쪽에서 준비를 완료해야 전송한다. 연결이 끊어지면 전송하지 않는다. 반면, TCP/IP는 기본적으로 받는 쪽 상황을 고려하지 않는다. 무조건 데이터를 보내고, 받은 쪽에서 받았다는 신호를 보내지 않으면 재전송한다.

■TCP/IP의 불안함, VDI에 맞나

TCP/IP를 사용하는 스토리지는 필연적으로 데이터 유실 우려가 있다. 서버와 스토리지의 연결이 끊길 경우 스토리지 쪽에 저장되지 않아도 서버는 계속 데이터를 전송한다. 때문에 iSCSI 스토리지만 사용하게 되면 설치 영역의 안정성을 보장하기 어렵다.

네트워크업체 관계자는 “이더넷은 태생부터 안정성을 고려하지 않고 만들어졌다”라며 “TCP/IP는 최고 성능을 보장하기보다, 최선을 다할 뿐이다”라고 표현했다.

망을 활용하는 효율성도 문제점으로 지적된다. IP프로토콜은 1회 전송용량이 기본 400KB다. 반면 FC 프로토콜은 2200KB다. 같은 용량의 파일이나 블록이라도 FC 프토토콜이 더 적은 크기로 잘라 전송한다. 이더넷은 전송용량을 늘리는 작업을 별도로 해줘야 한다. 네트워크 계층마다 전송용량을 모두 통일하지 않으면 최소 용량으로 전송된다.

고가용성을 위한 이중화 설계에서도 차이가 있다. IP망은 액티브/스탠바이 구조다. 하나가 죽었을 때 예비 자원이 작동한다. 예비 네트워크가 작동하는 사이 데이터 안정성을 보장하지 않는다. FC는 기본 액티브/액티브 구조다. 하나가 죽어도 다운타임이 없다.

이에 네트워크업계는 iSCSI 스토리지를 VDI에 적용하는 것은 신중해야 한다는 입장을 밝힌다. 비용부담만 아니라면 안전한 FC를 사용하는 게 오히려 낫다는 주장도 있다.

반대 의견도 있다. iSCSI 스토리지는 델의 이퀄로직이 가장 널리 알려져 있다. 안진수 델코리아 마케팅이사는 “iSCSI가 VDI에서 데이터 안정성이 부족하다는 지적은 TCP/IP를 너무 부각시킨 주장이다”라며 “SAN으로 구성하는 VDI는 비용과 성능 때문에 규모를 확장할 수 없다”라고 설명했다.

하지만 VDI용 스토리지 프로토콜에 대한 의견은 모두 극단적으로 하나만 선택하는 접근방법이 문제라는 쪽으로 모인다. 사용자의 운영 및 이용 상황에 따라 적절한 방식을 혼합해야 한다는 것이다. 한 스토리지 업체 관계자는 “스토리지에서 프로토콜을 무엇으로 하느냐는 이제 무의미해졌다”라며 “스토리지 대부분이 SAN, NAS, iSCSI, FCoE 등 프로토콜 전체를 지원하는 경우가 많은 만큼 아키텍처 설계단계에서 적절히 혼용하는 게 필요하다”라고 조언했다.

May 22, 2012

USB 크기 200g 안드로이드 미니 PC

박수형 기자 psooh@zdnet.co.kr 2012.05.19 / AM 07:34

리코매직(Rikomagic)이라는 중국 회사가 8.8cm 길이의 안드로이드 기반 미니 PC를 판매하기 시작했다. 가격은 배송비를 포함해 단돈 74달러(약 8만7천원)에 불과하다.

씨넷 아시아는 18일 MK802라는 저가 미니 PC를 소개했다.

MK802는 폭 3.5cm, 두께 1.2cm, 길이 8.8cm로 USB 메모리 드라이브 크기다. 무게는 200g이다. 크기는 작지만 PC 본체 기능을 모두 갖췄다. 제조사는 스마트 TV 셋톱박스로 사용할 수 있다고 설명했다.

MK802는 안드로이드 4.0 아이스크림샌드위치로 구동되며 1.5기가헤르츠의 올위너(AllWinner) A10 ARM CPU와 말리(Mali) 400 GPU, 512메가바이트의 DDR3 메모리를 탑재했다. 또 기본 저장 공간으로 4기가바이트의 플래시 메모리를 갖추고 있다.

▲ 손가락 크기의 안드로이드 4.0 미니 PC, MK802.

다양한 포트를 갖춰 활용성이 뛰어난 편이다. 우선 HDMI 포트를 통해 풀HD 동영상을 출력할 수 있다. 미니 사이즈가 아닌 풀 사이즈 USB 포트로 여러 기기와 연결할 수 있으며, 마이크로 USB 포트도 사용할 수 있다. 또 마이크로SD 슬롯을 통해 데이터 저장 공간을 확장할 수 도 있다.

인터넷 연결은 내장된 와이파이 안테나로 가능하다.

이와 같은 미니 PC는 라즈베리 파이(Raspberry Pi) 프로젝트가 잘 알려져 있다. 라즈베리 파이 PC는 개발 도상국 어린이를 위해 교육용으로 만들어졌다.

반면 MK802는 스마트TV 셋톱박스로 활용도가 더욱 높다고 외신은 평했다. MK802와 같은 제품은 지난 2월부터 판매된 FXI 코튼 캔디(Cotton Candy)가 대표적이다.

FXI 코튼 캔디는 듀얼 코어 칩셋을 사용해 MK802보다 성능이 우수하다. 하지만 가격은 199달러로 MK802와 비교해 2배 이상 비싼 편이다.

외신은 “일본, 싱가포르, 말레이시아 등의 아시아 지역에서 온라인 몰을 통해 판매중”이라고 전했다.

구글 “오픈플로 라우터·스위치 개발중“

김우용 기자 yong2@zdnet.co.kr 2012.04.18 / AM 10:38

구글이 소프트웨어 정의 네트워크(SDN, Software Defined Networking)를 이용하는 대대적인 네트워크 재정비에 나섰다. 오픈소스 기술인 ‘오픈플로’로 네트워크 장비를 직접 제작하고, 전세계의 구글 인프라 트래픽 관리를 자동화하는 작업이다.

17일(현지시간) 미국 지디넷은 우르스 휄즐 구글 수석부사장이 오픈네트워킹서밋에 참석해 밝힌 구글의 네트워크 혁신작업을 소개했다.

우르스 휄즐 수석부사장은 구글의 네트워크 혁신 계획에 오픈플로를 채택해 전환작업을 진행중이라고 밝혔다.

그에 따르면 현재 구글은 서버를 만들었듯 자체 네트워크 장비를 개발중이다. 라우터, 스위치로 시스코, 주니퍼 등의 장비 대신 구글 라우터, 구글 스위치를 사용하게 된다는 것이다.

구글 라우터는 전세계 데이터센터를 연결하는 내부 백본망 G스케일 네트워크의 근간을 이룬다. 구글 스위치는 데이터센터 내부의 이더넷망을 관리하며, 데이터센터-데이터센터 간 ‘대규모 L2 네트워크’를 형성한다.

오픈플로는 구글 네트워크 재정비의 핵심이다. 오픈플로는 패킷 스위칭과 관리기능을 하나의 장비에서 분리하고 관리 소프트웨어를 구글 서버에 설치하는 것으로 구현된다. 소프트웨어는 트래픽과 오프로드를 각 지역에 적절히 전송하는 역할을 담당한다. 구글은 또한 백업과 기타 핵심업무를 예측하는데 이를 사용한다.

SDN의 일종인 오픈플로는 시스코, HP, 주니퍼, 브로케이드 등 장비업체에 상관없이 사용자가 네트워크 통제권을 갖는 표준 프로토콜이다. 스탠포드대학과 UC버클리대학에서 개발을 시작해, 현재 IBM, HP, 주니퍼네트웍스, 브로케이드 등이 후원하며, 지난해 3월 오픈네트워킹파운데이션(ONF)이 설립돼 개발에 속도를 내고 있다.

네트워크 장비는 제조업체마다 플랫폼이 다르다. 중앙처리장치는 각 업체마다 다른 ASIC을 사용하며, 운영체제(OS)도 각각이다. 사용자는 라우터, 스위치 등의 공급업체를 다르게 구매할 경우 제어기능이 다른 탓에 통일된 정책을 적용하기 어렵다. 각 업체마다 제공하는 기능과 성능에 차이를 보인다는 원인도 있다.

갈수록 데이터센터가 대형화하고 늘어나면서, 네트워크 자원의 효율적인 관리는 구글의 골칫거리다. 오픈플로는 비용과 자원을 절약하면서, 네트워크 자원을 입맛에 맞게 효율적으로 관리할 수 있는 해법으로 주목받는다.

오픈플로는 소프트웨어로 이뤄진 멀티테넌트 네트워크를 만든다. 네트워크 장비에 담겨있던 컨트롤 플레인(OS)과 데이터 플레인 중 제어 부분을 x86서버에 SW로 설치하고, 단순 트래픽 전송기능과 통신포트만 다수 보유한 박스를 연결하는 것으로 구현된다.

오픈플로 사용자는 데이터센터 구축 시 물리적 네트워크 인프라를 조정할 필요가 없으며, 가상화 환경에서 패킷 라우팅 경로 지정, 로드밸런싱, 접근 권한 설정 등을 할 수 있다.

구글의 네트워크는 두 종류다. G메일, 구글플러스 등에 대한 일반사용자의 네트워크와 구글의 데이터센터들을 연결하는 내부 백본망이다.

외부 사용자의 네트워크 트래픽은 일정 패턴을 갖는다. 시간에 따라 사용자 트래픽이 몰렸다가 줄어드는 현상이 반복된다. 이는 예측가능한 트래픽이다.

반면, 내부 백본방의 경우는 조금 다르다. 이는 데이터센터에서 데이터센터로 수페타바이트 규모의 데이터를 옮기는 과정에서 일어난다. 특정 데이터 트래픽이 일시에 몰리는 현상이 불시에 일어나고 이를 예측해 관리하는 게 기존 인프라로선 매우 어려운 일이다.

몰리는 트래픽을 적절히 분산하거나 경로를 설정해주는 등의 트래픽 엔지니어링이 필요한데, 데이터센터에서 데이터센터로 보내는 트래픽 중 각자 다른 비즈니스 우선순위를 세우고, 더 중요한 트래픽을 먼저 내보내는 것을 계량화하는 작업이 현재로선 불가능에 가깝다.

그는 “오픈플로를 채택한다는 생각이 구글 전체 역사상 네트워크에 가장 큰 변화일 것”이라고 말했다. 그는 “네트워크 장비 하드웨어를 만드는 것은 어렵지 않다”라며 “만들기 어려운 것은 소프트웨어”라고 덧붙였다.

엔비디아, 클라우드 GPU 기술 공개…기업·게임용 플랫폼 출시

2012년 05월 17일 00:24:17 / 백지영 기자 jyp@ddaily.co.kr

[디지털데일리 백지영기자] 그래픽처리장치(GPU)는 과연 클라우드 컴퓨팅 환경의 혁신 요소로 떠오를까.

16일 엔비디아(www.nvidia.co.kr CEO 젠슨 황)는 미국 캘리포니아 새너제이에서 개최된 GPU 테크놀로지 컨퍼런스(GTC) 2012에서 자사의 케플러(Kepler) 아키텍처를 기반으로 한 클라우드 GPU 기술을 공개했다.

기업들은 이를 통해 데스크톱 가상화(VDI)를 이용할 수도 있고, 개인 사용자들은 게임을 할 수도 있다.

이번에 엔비디아가 발표한 클라우드 GPU 기술은 GPU의 막대한 컴퓨팅 역량을 활용해 클라우드 컴퓨팅을 가속하는 기술이다. 이는 대규모 데이터센터를 위해 설계된 엔비디아의 새로운 케플러 GPU 아키텍처를 기반으로 하고 있다. 개발에만 5년이 걸렸을 정도로 엔디비디아의 혁신 기술이다.

이날 엔비디아는 크게 2가지의 플랫폼을 공개했다.

첫번째는 기업용 케플러 클라우드 기술인 엔비디아 VGX 플랫폼이다. 이는 가상화 데스크톱(VDI)을 가속화할 수 있도록 한다. 직원들이 가상 데스크톱에 접속해 PC나 워크스테이션과 맞먹는 그래픽 및 GPU 컴퓨팅 성능을 제공받을 수 있게 해주는 것이다.

씬클라이언트나 노트북, 태블릿, 스마트폰 등 어느 기기에서나 운영체제(OS)와 상관없이 각종 애플리케이션을 모두 손쉽고 빠르게 사용할 수 있다.

이를 위해 엔비디아는 VGX 보드를 설계했다. 이는 데이터센터용으로 디자인된 최초의 GPU보드로, 하나의 보드로 가동되는 단일 서버에서 최고 100명의 사용자를 서비스할 수 있다.

VGX 보드는 각 192개의 엔비디아 쿠다(CUDA) 아키텍처 코어를 가진 네 개의 GP와 4GB의 프레임 버퍼를 갖추고 있다. 메모리 16GB, GPU 4개를 갖췄으며 서버 내 업계표준 PCI 익스프레스(PCIe)에 삽입된다.

이외에 VGX 플랫폼 내에는 VGX 하이퍼바이저를 포함시켜 시트릭스 젠서버 등 상용 하이퍼바이저에 통합돼 GPU의 가상화를 가능하게 했으며, 사용자선택기기(USM) 옵션을 통해 기업이 네트워크 내 각 사용자의 요건에 맞춰 그래픽 기능을 설정할 수 있게 했다.

이는 올해 말 엔비디아 하드웨어 OEM 및 VDI 파트너를 통해 기업 전반에 제공될 예정이다.

또 한가지는 게임용 케플러 클라우드 기술인 엔비디아 지포스 그리드 플랫폼이다.

이는 클라우드 게이밍 서비스를 제공하는 GaaS(gaming-as-a-service) 업체들이 이를 이용해 게이밍 경험을 원격으로 제공할 수 있게 한다.

GaaS 제공업체는 이를 이용해, 차세대 게임을 어느 디바이스에서나 지연 없이 스트리밍할 수 있게 됐다는 설명이다. 게이머 입장에서는 TV와 스마트폰, 태블릿 등 iOS 혹은 안드로이드 기반 어느 기기에서나 최신 첨단 게임을 플레이할 수 있게 된다.

이는 전용 초저지연(Ultra-low-latency) 스트리밍 기술을 갖춘 엔비디아 지포스 그리드 GPU와 클라우드 그래픽 소프트웨어는 새로운 플랫폼을 구동하는 핵심기술을 통해 가능한 것이다.

젠슨 황 엔비디아 CEO는 “케플러 클라우드 GPU 기술은 클라우드 컴퓨팅을 새로운 단계로 발전시켰다”며 “이는 원격 근무자를 비롯해 더 이상 PC나 콘솔에 구애받기 원하지 않는 게이머에게도 놀라운 경험을 제공할 것”이라고 말했다.

<백지영 기자>jyp@ddaily.co.kr

May 21, 2012

대형 은행 연이어 데스크톱 가상화 도입 보류…관련업계 타격

발행일 2012.05.20 신혜권기자 hkshin@etnews.com 신한은행에 이어 기업은행도 데스크톱 가상화 전사 확산을 보류하고 문서중앙화만 도입하기로 했다. 은행권 데스크톱 가상화 시장 공략을 준비했던 관련 업체는 전략 수정이 불가피해졌다.

기업은행은 고객센터와 충주연수원에 데스크톱 가상화를 적용한 데 이어 전사 확산을 검토했지만 성능과 비용부담으로 도입을 보류하기로 결정했다고 20일 밝혔다. 대신 신한은행과 마찬가지로 문서중앙화만 도입할 계획이다.

기업은행은 지난 2010년 11월 용인수지 고객센터에 있는 상담용 PC 300여대를 대상으로 데스크톱 가상화를 적용했다. 당시 데스크톱 가상화 관리 솔루션은 VM웨어 제품이 도입됐고 구축은 한국EMC가 수행했다. 이어 충주연수원 PC에도 데스크톱 가상화를 도입했다.

이후 기업은행은 IT본부와 본점 부서에 확대 적용하는 방안을 검토했으나 문제가 있다고 판단, 최근 도입을 보류하기로 했다. 가장 큰 문제는 더딘 속도다. 중앙 서버에서 화면을 불러 오기 때문에 모니터에서 화면 변경이 느리다.

일부 보안 소프트웨어(SW)와 충돌하는 현상도 도입을 보류한 원인이다. 기업은행은 가상화 환경에서 SW 구동 테스트를 실시한 결과, 디지털저작권관리(DRM)와 키보드보안 솔루션 등 일부 SW가 가상화 솔루션과 충돌했다.

가상화 기반으로 공공기관 접속이 잘 이뤄지지 않는 것도 문제다. 국세청 연말정산사이트 등은 가상화 기반 IP를 해킹 IP로 간주, 접속 자체를 차단하고 있다. 업무량이 많은 사람은 디스크 저장 공간 불편함도 제기됐다.

PC 도입보다 세 배 이상 부담해야 하는 초기 구축비용도 부담이다. 기업은행 한 관계자는 “장기적으로 비용 절감 효과가 있겠지만 당장 도입비용이 너무 많이 들어 부담 된다”고 말했다. 기업은행은 내년부터 단계적으로 문서중앙화를 추진할 계획이다.

신한은행도 지난 2010년 IT총괄부 직원 PC 60대를 대상으로 데스크톱 가상화를 도입, 추가 확대를 검토했으나 지난 2월 백지화 했다. 신한은행 역시 성능 문제와 비용 부담으로 도입하지 않기로 했다. 신한은행은 올해 본부 부서 직원 2000명을 대상으로 문서중앙화를 실시한 뒤 단계적으로 1만5000명의 영업점 직원으로 확대할 예정이다.

당초 은행권 데스크톱 가상화 시장 확대를 기대했던 VM웨어 등 관련 업체는 난감해진 상황이다. 대형 은행은 PC 사용 규모가 커 전사 도입을 하면 상당한 규모로 사업이 진행된다. 잇단 대형 은행의 데스크톱 가상화 보류 결정으로 은행권 시장 공략을 강화할 계획이었던 관련업체들은 당분간 좀 더 지켜보자는 입장이다.

신혜권기자 hkshin@etnews.com

May 15, 2012

Google's largest internal network interconnects its Data Centers using Software Defined Network (SDN) in the WAN

Google's use of SDN in its internal WAN backbone:

Urs Hölzle,Sr VP of Technical Infrastructure at Google presented the opening keynote speech at the 2012 Open Network Summit, April 17 in Santa Clara, CA.  The audience was surprised to learn that Google had built its own switches and SDN confrollers for use in its internal backbone network - the one which is used to interconnect its data centers.

Here are the key points made in Mr. Hölzle's presentation:                                                                                        

Google currently operates two WAN backbones, according to Hölzle:

1] I-Scale is the public Internet-facing backbone that carries user traffic to and from Google's data centers. It must have bulletproof performance.

2] G-Scale is the internal backbone that carries traffic between Google's data centers worldwide. The G-Scale network has been used to experiment with SDN.

  • Google chose to pursue SDN in order to separate hardware from software. This enables the company to choose hardware based on necessary features and to choose software based on protocol requirements.
  • SDN provides logically, centralized network control. The goal is to be more deterministic, more efficient and more fault-tolerant.
  • SDN enables better centralized traffic engineering, such as an ability for the network to converge quickly to target optimum on a link failure.  Determinist behavior should simplify planning vs over provisioning for worst case variability.
  • The SDN controller uses modern server hardware, giving it more flexibility than conventional routers.
  • Switches are virtualized with real OpenFlow and the company can attach real monitoring and alerting servers. Testing is vastly simplified.
  • The move to SDN is really about picking the right tool for the right job.
  • Google's OpenFlow WAN activity really started moving in 2010. Less than two years later, Google is now running the G-Scale network on OpenFlow-controlled switches. 100% of its production data center to data center traffic is now on this new SDN-powered network.
  • Google built their own OpenFlow switch because none were commercially available. The switch was built from merchant silicon. It has scaled to hundred of nonblocking 10GE ports.
  • Google's practice is to simplify every software stack and hardware element as much as possible, removing anything that is not absolutely necessary.
  • Multiple switch chassis are used in each domain.
  • Google is using open source routing stacks for BGP and ISIS.
  • The OpenFlow-controlled switches (designed and built by Google) look like regular routers. BGP/ISIS/OSPF now interfaces with OpenFlow controller to program the switch state.
  • A preliminary version of the Open Flow protocol is being used now.  (The Open Flow standard is still maturing).
  • All data center backbone traffic is now carried by this new SDN based network. The old network has been shut down.
  • Google started rolling out centralized traffic engineering in January.
  • Google is already seeing higher network utilization and gaining the benefit of flexible management of end-to-end paths for maintenance.
  • Over the past six months, the new network has seen a high degree of stability with minimal outages.
  • The new SDN-powered network is meeting the company's SLA objectives.
  • It is still too early to quantify the economics.
  • A key SDN benefit is the unified view of the network fabric -- higher QoS awareness and predictability.

http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=35604

Mr. Hölzle said that Google’s software-defined networking system has been running for about six months and that it was therefore too early to accurately benchmark cost savings. “This will have a bigger impact in costs than any technical change like a larger router, or 10 gigabit optical switches instead of 2.5 gigabit.  I would expect the cost reduction to come from better system utilization, and substantially easier management,” he said.

“In utilization alone, we are hoping for a 20 percent to 30 percent reduction,” he continued.  Google’s very specific network applications, like search, made it hard to say what others could expect to save. Hölzle thought that the savings would be enough to compel large Internet service providers to change their systems to S.D.N. over the next five years.

Surprisingly, perhaps, Mr. Hölzle thought that the incumbent networking providers would lead the transition. Start-up networking companies likeNicira have created a stir with their SDN approaches, but Mr. Hölzle thought that the big service providers would have a level of trust with the incumbent network equipment companies (We don't necessarily agree- there are no incumbent networking companies that are leaders in SDNs).

“The natural players are the ones already in the field – Cisco, Alcatel, Juniper,” he said, noting that NEC was an early leader in S.D.N. “They have the networking management software, just at the level of hardware ports, not data flows.” Google talks with all of these companies about their S.D.N. plans, Mr. Hölzle said. Within a year or two, he thought, Google would be purchasing S.D.N.-related products from one or more of these companies.

http://bits.blogs.nytimes.com/2012/04/18/google-opens-the-network-kimono/

============================================================================================

SDN use in global WANs:

There were also presentations from NEC, NTT, Verizon and other WAN players endorsing SDN and Open Flow at this conference.  NEC said it's Open Flow controller, together with IBM switches, would be deployed in the WAN as early as this July.   NTT stated that a global  cloud virtualization service that leverages SDN will also be launched this summer. 

http://www.convergedigest.com/Bandwidth/newnetworksarticle.asp?ID=35620

==================================================================================

Complete program with selected presentations is at:   http://opennetsummit.org/index.html

============================================================================================

Editorial:

GigaOM wrote that the conference was like "a giant science fair for the networking industry. There are arcane demonstrations detailing how software-defined networks and the OpenFlow protocol will change the way networks are built, managed and operated. There are speakers from Google, Verizon and Yahoo detailing their projects and successes with OpenFlow as well as investors and bankers swarming the whole event."

"The creation of the OpenFlow protocol, which separates the act of directing how packets move across a network from the physical act of moving those packets, has helped create excitement around networking, and is precipitating change. The change is actually the creation of software-defined networks that are programmable (for the record, a software defined network doesn’t need OpenFlow). There’s also a third change that’s been going on regarding the commoditization of networking hardware and the rise of merchant silicon."

http://gigaom.com/cloud/will-openflow-really-be-the-android-of-networking/

Opinion Piece:

Forbes magazine pointed out that SDN networks are “more secure, more dependable and much easier to manage” because the software that controls network traffic is separate from the physical routers and switches.

"By separating the software that controls network traffic from the physical routers and switches, SDN should make networks more secure, more dependable and much easier to manage. Because SDN runs on commodity hardware, it could translate into siginficant savings for network operators. Perhaps most important, it opens up the network to the possibility of vast innovation.

For Google, software defined networking represented a better way of moving traffic between its global data centers. According to Holzle, things that were hard to do on processors embedded in a networking box become much easier when they separately designed and merely communicated to the hardware using OpenFlow. “You can use all the [computer] tools for software development and that makes it faster to develop software that is higher in quality,” he said.

One of the big advantages for Google is better traffic management—this new approach basically ensures that every lane on its global network of data highways is smoothly moving packets toward their destinations. “Soon we will be able to get very close to 100 percent utilization of our network,” Holzle said. This is a big increase from the industry expectation of thirty to forty percent utilization."

http://www.forbes.com/sites/eliseackerman/2012/04/18/google-unveils-secret-worldwide-networking-project/

=======================================================================================

The market segments where SDN might be advantageously used include:

  • Cloud Services Providers / large website data centers
  • Universities and research campus networks
  • Metro Area CSP data center interconnect 
  • Enterprise data centers
  • Internet service provider core routed networks
  • Campus LAN
  • Enterprise WAN 

http://www.networkworld.com/community/blog/openflow-software-defined-networking-and-enterprise-wan?page=0%2C1

========================================================================================

Author's NOTE:  Please contact this author if you are interested in more information about what was presented and discussed at the 2012 Open Network Summit:  alan.weissberger@ieee.org. 

Aug 11, 2011

애플리케이션 가상화, 과거와 미래

플랫폼 가상화 대 애플리케이션 가상화
가상 머신(VM)은 그 첫 번째 세대로 60년 전에 IBM에서 대규모의 비용이 많이 드는 메인프레임 시스템을 공유하는 하나의 방법으로서 제작되었다. 그리고 비록 그 개념이 현재 IBM 시스템에 적용된다고 하더라도 VM의 대중적인 개념은 확장되었고 가상화 범위 밖의 수많은 영역에 적용되었다.

가상 머신 근원
VM에 대한 전체 가상화를 지원하는 첫 번째 운영 체제는 Conversational Monitor System(CMS)이다. CMS는 전체 가상화 및 반가상화(paravirtualization) 둘 다 지원했다. 1970년대 초반에 IBM은 시스템의 VM 제품군을 도입했으며, 이는 해당 VM Control Program의 위에 여러 단일 사용자 운영 체제—초기 유형 1 하이퍼바이저를 실행했다.
1960년대에 IBM이 대중화한 가상화의 영역은 플랫폼(또는 시스템) 가상화로 알려졌다. 이러한 가상화의 형태로 내재된 하드웨어 플랫폼은 수많은 다른 운영 체제 및 사용자와 이를 공유하기 위해 가상화되었다.
VM의 또 다른 애플리케이션은 머신 독립성의 특성을 제공하는 것이다. 애플리케이션(또는 프로세스) 가상화라는 이러한 양식은 추상화된 환경(애플리케이션용)을 제작하여, 실제 환경에 독립적으로 만든다.

애플리케이션 가상 머신의 측면
애플리케이션 가상화 공간에서 VM은 애플리케이션의 실행에 하드웨어 독립적인 환경을 제공하는 데 사용된다. 예를 들어, 그림 1을 살펴보자. 맨 위에 개발자들이 애플리케이션을 구축하기 위해 사용하는 고급 언어가 있다. 컴파일 프로세스를 통해 이 상위 레벨 코드는 오브젝트 코드라는 중간 표현으로 컴파일된다. 비가상화 환경에서 이 오브젝트 코드(이는 머신 독립적임)는 실제 플랫폼에서 실행을 위한 네이티브 머신 코드로 컴파일된다. 하지만 애플리케이션 가상화 환경에서 오브젝트 코드는 추상 머신 내에서 실행을 제공하기 위해 해석된다. 여기에서 핵심적인 장점은 동일한 오브젝트 코드가 추상 머신(해석기)을 지원하는 어느 하드웨어 플랫폼에서나 실행될 수 있다는 점이다.

그림 1. 플랫폼 독립성을 위한 애플리케이션 VM

오브젝트 코드를 실행하는 이식 가능한 환경을 작성하는 것 외에도 애플리케이션 가상화는 호스트에서 실행하는 다른 애플리케이션과 VM을 격리시키는 환경을 제공한다. 이 설정은 자세한 자원 관리 및 보안과 같은 수많은 장점이 있다.
VM을 위한 오브젝트 코드는 바이트코드라고도 하며, 특히 해석기가 실행하는 명령어 세트를 정의한다. 가상 명령어를 효율적으로 구현한 구현방식에서부터 진화한 바이트코드라는 용어는 단순성과 성능을 위해 단일 바이트로 설정한다.
이제 애플리케이션 가상화에 대한 일부 역사적인 사용을 살펴보고, 일부 현대적인 사용을 알아보자.

가상 머신 역사
애플리케이션 가상화의 가장 초기 사용 중 하나는 Basic Combined Programming Language(BCPL)용으로 1960년대에 나타났다. BCPL는 케임브리지 대학교의 Martin Richards가 개발한 명령형 언어였고 오늘날 사용하는 C 언어로 진화한 B 언어의 선구자이다.
BCPL, 과거와 현재
BCPL이 1966년도부터 생겨났다고 하더라도 이는 제작자인 Martin Richards에 의해 오늘날에도 여전히 활발히 개발되고 있다. BCPL의 첫 번째 컴파일러는 최초로 개발된 시간 공유 운영 체제 중 하나인 Compatible Time Sharing System 아래 IBM 7094 시스템용으로 쓰여졌다. 오늘날 Linux와 같은 다양한 시스템에서 BCPL을 사용할 수 있다.
비록 BCPL이 고급 언어였지만(C와 마찬가지로), 컴파일러가 생성한 중간 코드는 O-code(오브젝트 코드)라고 불렸다. O-code는 실제 머신(VM으로)에서 해석되거나 O-code에서 호스트의 네이티브 머신 언어로 컴파일될 수 있다. 이 기능은 머신 독립성의 맥락에서 수많은 장점을 제공했다. 첫 번째로 실제 머신에서부터 O-code를 추상화하여 이는 다양한 호스트에서 간편하게 해석될 수 있었다. 두 번째로, O-code는 네이티브 머신으로 컴파일될 수 있으며, 이는 O-code를 네이티브 머신 명령어로 변환하는(더 간단한 작업) 하나의 컴파일러 및 여러 컴파일러의 개발을 허용했다. 이 머신 독립성은 머신들에 걸쳐 언어를 이식 가능하게 만들기 때문에 이러한 가용성으로 인해 대중적이 되었다.
1970년대 초반에 샌디에고의 캘리포니아 대학교에서는 컴파일된 Pascal을 실행하기 위한 VM 접근방식을 구현했다. 이들은 중간 표현을 p-code라고 했으며, 이는 Pascal 컴파일러의 개발을 간소화하기 위해 내재된 하드웨어의 독립성을 추구했다(추상 모조 머신 아키텍처에 의존하는 것이 아니라). Forth 언어도 VM을 적용했다. 즉, 이는 영주소(zero-address) 또는 스택 기반 아키텍처이다.
1972년에 Xerox PARC는 실행을 위해 VM에 의존하는 Smalltalk 언어를 도입했다. Smalltalk는 오브젝트의 개념을 근거로 제작된 첫 번째 언어 중 하나이다. Smalltalk와 p-code 둘 다 오늘날 존재하는 가장 중요한 VM 기반 언어 중 하나인 Java 언어에 크게 영향을 주었다. Java는 1995년에 Sun Microsystems가 개발하여 처음 나타났고 Java Virtual Machine을 통해 플랫폼 독립적인 프로그래밍의 개념을 개발했다. 그 이후로 Java 기술은 웹 애플리케이션의 빌딩 블록이 되었다. 서버측 스크립트에서 클라이언트측 애플릿에 이르기까지 Java 기술은 VM 기술의 인식을 제고했고, JIT(Just-In-Time) 컴파일 기술을 사용하여 해석과 네이티브 실행 사이를 연결한 더 새로운 기술을 도입했다.
많은 다른 언어는 VM의 개념을 포함한다. Erlang 언어(Ericsson이 개발함)는 VM을 사용하여 Erlang 바이트코드를 실행하고 소스의 추상 구문 트리로부터 Erlang을 해석한다. 경량 Lua 언어(브라질의 리우데자네이루에서 Pontifical Catholic University에서 개발됨)는 레지스터 기반 VM을 포함한다. Lua 프로그램이 실행될 때, 이는 바이트코드로 변환된 다음에 VM에서 실행된다. 나중에 이 기사는 어느 언어에나 사용될 수 있는 바이트코드 표준을 살펴본다.

오늘날 가상 머신
실제 호스트로 추상을 제공하는 VM의 사용은 역사적으로 일반적인 메소드이고 오늘날 진화하며 애플리케이션을 찾는다. VM의 개념을 미래로 나아가게 하는 몇 가지 더 새로운 오픈 소스 솔루션에 대해 살펴보자.

Dalvik VM
Dalvik은 Android 운영 체제를 위해 Google이 개발한 오픈 소스 VM 기술이다. Android는 모바일 장치를 위해 소프트웨어 스택을 통합하는 수정된 Linux 커널이다(그림 2 참조). 스택 기반 아키텍처에 의존하는 많은 VM 기술과 마찬가지로, Dalvik VM은 레지스터 기반 가상 아키텍처이다(아키텍처 및 명령어 세트에 대 자세한 정보는 참고자료 참조). 비록 스택 기반 아키텍처가 개념적으로 간단하고 효율적일지라도 이는 더 큰 규모의 프로그램과 같이(스택 유지보수로 인해) 새로운 비효율성을 도입할 수 있다.

그림 2. Dalvik 소프트웨어 스택의 간단한 아키텍처

Dalvik이 VM 아키텍처이기 때문에, 이는 VM이 이해하는 바이트코드로 컴파일되는 고급 언어에 의존한다. 불필요한 일을 하는 대신에, Dalvik은 애플리케이션 개발을 위한 고급 언어로서 Java 언어에 의존한다. Dalvik도 dx라는 특수 도구에 의존하여 Java 클래스 파일을 Dalvik VM 실행 파일로 변환한다. 성능을 위해 VM은 JIT 컴파일을 비롯하여 추가 최적화를 위해 Dalvik 실행 파일(dex)를 추가로 수정할 수 있으며, 이는 dex 명령어를 네이티브 성능을 위한 네이티브 명령어로 변환한다. 이 프로세스는 동적 변환으로도 알려져 있고 VM 기술의 성능을 높이기 위한 대중적인 기술이다.
그림 2와 같이 Dalvik 실행 파일(VM의 인스턴스와 함께)은 Linux 사용자 공간에서 단일 프로세스로 격리된다. Dalvik VM은 동시에 여러 VM의 실행(독립적인 프로세스로)을 지원하도록 제작되었다.
Dalvik VM은 표준 Java 런타임에서 구현되지 않으므로 이에 대해 라이센스를 상속하지 않는다. 대신에, Dalvik은 Apache 2.0 라이센스에 의해 게시된 클린룸(clean-room) 구현 방식이다.

Parrot
또 다른 흥미로운 오픈 소스 VM 프로젝트는 Parrot이다. Parrot은 동적 언어(유형 시스템을 변경하는 등 컴파일 시 일반적으로 수행되는 런타임 시 특정 조작을 수행하는 언어)를 효율적으로 실행하도록 설계된 또 다른 레지스터 기반 VM 기술이다.
Parrot은 원래 PerI6용 런타임으로 설계되었지만, 이는 많은 언어의 바이트코드의 실행에 유연한 환경이다(그림 3 참조). Parrot은 컴파일러 라이터에 유용한 Parrot Abstract Syntax Tree(PAST), 사람들이나 컴파일러가 자동으로 쓸 수 있는 상위 레벨 표현인 Parrot Intermediate Representation(PIR) 및 중간 이하 표현이지만 사람 및 컴파일러 둘 다에 유용한 Parrot Assembly(PASM)를 비롯하여 몇 가지 입력 양식을 지원한다. 각 양식은 Parrot VM에서 Parrot 바이트코드로 변환되고 실행된다.

그림 3. Parrot VM의 간단한 아키텍처

Parrot은 많은 언어를 지원하지만, 매우 흥미로운 하나의 측면은 함수형 언어에 대한 특정 지원 비롯하여 정적 및 동적 언어에 대한 지원이다. 목록 1은 PASM의 간단한 사용을 보여준다. Ubuntu로 Parrot을 설치하려면 다음과 같이 간단히 apt-get을 사용한다.
sudo apt-get install parrot

다음 세션은 Parrot에서 간단한 문자열 조작 프로그램을 시연한다. 비록 Parrot이 이 코드를 어셈블리로 구현할지라도, 이는 사용될 수 있는 어셈블리보다 훨씬 더 기능이 풍부하다는 점을 확인하자. Parrot에서 명령어는 dest,src 구문을 사용하므로, 목록 1은 텍스트로 로드되는 문자열 레지스터를 보여준다. length 명령어는 문자열의 길이를 판별하고 정수 레지스터로 이를 로드한다. print 명령어는 인수를 표준 출력(stdout)으로 내보내고 concat은 문자열 연결을 구현한다.

목록 1. PASM 예제

$ more test.pasm
set S1, "Parrot"
set S2, "VM"
length I1, S1
print I1
print "\n"

concat S3, S1, S2
print S3
print "\n"

end
$
parrot test.pasm
6
ParrotVM
$

Parrot 내에서 명령어의 풍부한 세트를 발견할 것이다(자세한 내용은 참고자료 참조). 작성자는 최소화에 대해 풍성한 기능을 선택하여, Parrot VM용 컴파일러를 코드하고 빌드하기에 간편하게 된다.
PASM이 제공하는 상위 레벨 추상을 통해서도 PIR은 상위 레벨 프로그래머에게 훨씬 더 편안하다. 목록 2는 PIR로 쓰이고 Parrot VM으로 실행되는 예제 프로그램을 제공한다. 이 예제는 수를 제곱하고 이를 리턴하는 square라는 서브루틴을 선언한다. 이 프로세스는 결과를 인쇄하기 위해 기본 서브루틴으로 호출된다(이를 먼저 실행하기 위해 Parrot에 알려주도록 :main으로 레이블됨).

목록 2. PIR 예제

$ more test.pir
.sub square
.param int arg
arg *= arg
.return(arg)
.end

.sub main :main
.local int value
value = square(19)
print value
print "\n"
.end
$ parrot test.pir
361
$

Parrot은 높은 효율성도 추구하는 머신 독립적인 애플리케이션의 개발에 풍부한 애플리케이션 가상화 환경을 제공한다. C, Lua, Python, Scheme, Smalltalk 및 기타 등등을 비롯하여 Parrot을 위해 설계된 컴파일러 프론트 엔드를 지원하는 언어를 많이 찾을 수 있다.
위로
애플리케이션 가상 머신의 다른 사용
지금까지 최근 두 개의 예제를 비롯하여 애플리케이션 가상화의 역사적인 사용을 확인했다. Dalvik은 현재 핸드셋 내에서 애플리케이션 개발을 구동하고 있고, Parrot은 정적 및 동적 언어용 컴파일러 라이터에 효율적인 프레임워크를 제공한다. 하지만, 애플리케이션 가상화의 개념은 지금까지 탐색된 접근방식을 넘어 수많은 다른 영역에서 구현된다.
특히 흥미로운 한 가지 사용은 독자가 지금 사용하고 있는 컴퓨터에서 실행하고 있을 가능성이 높다. BIOS 대체인 새로운 Extensible Firmware Interface(EFI)를 사용하는 시스템은 EFI Byte Code(EBC)라고 하는 것에서 펌웨어 드라이버를 구현할 수 있다. 시스템 펌웨어는 EBC 이미지가 로드될 때 호출되는 해석기를 포함한다. 이 개념은 Forth(자체적인 VM을 포함하는 언어)를 사용하는 Sun Microsystem의 Open Firmware에서도 구현되었다.
게임 분야에서 애플리케이션 가상화의 사용은 새로운 것이 아니다. 많은 현대식 게임은 플레이어 외의 캐릭터 작동의 스크립팅 및 바이트코드를 실행하는 언어(예: Lua)를 사용하는 다른 게임 분야를 포함한다. 하지만 게임 분야에서 애플리케이션 가상화의 개념은 실제로는 훨씬 멀리 되돌아간다.
Zork와 같은 텍스트 기반 어드벤처를 도입한 회사인 Infocom은 1979년에 머신 독립 부문에서 가치를 확인했다. Infocom은 Z-machine(이후에 Zork로 이름 지정됨)이라는 VM을 제작했다. Z-machine은 다른 아키텍처로 더 간편하게 포트되는 어드벤처 게임을 허용한 VM이다. 전체 어드벤처를 새 시스템으로 포트하기 위해 보유하는 것이 아니라 해석기가 Z-machine을 표현하는 것으로 포트될 것이다. 이 기능은 다른 언어 지원이 있고 전체적으로 다른 머신 아키텍처를 가질 수 있는 다른 시스템으로 포팅 프로세스를 간소화했다. 비록 Infocom의 목표가 당시의 아키텍처들 사이에 포팅하는 부분에서 골치거리를 완화하는 것이지만, 그들의 작업은 포팅을 계속 간소화했으며 결과적으로 새 세대로 액세스 가능한 이러한 게임들(심지어 모바일 플랫폼에서)을 제작하고 있다.
VM의 다른 게임 애플리케이션은 ScummVM(이는 VM 환경에 Script Creation Utility for Maniac Mansion(SCUMM) 스크립팅 언어를 제공함(1987년에 작성됨))을 포함한다. SCUMM은 그래픽 어드벤처 게임의 개발을 간소화하기 위해 LucasArts가 개발했다. ScummVM은 이제 다양한 플랫폼에서 많은 텍스트 및 그래픽 어드벤처 게임을 하는 데 사용된다.
위로
추가 주제
플랫폼(또는 시스템) 가상화가 우리가 서버와 데스크탑 둘 다 공급하고 관리하는 방법을 변경한 것처럼 애플리케이션 가상화는 호스트 시스템에서부터 애플리케이션을 추상화하는 효율적인 메커니즘을 계속 제공한다. 이러한 접근방식의 인기를 고려하면, 애플리케이션 가상화를 훨씬 더 유연하고 효율적으로 만드는 소프트웨어 및 하드웨어 모두의 진화를 확인하는 것이 흥미로울 것이다.

참고자료
교육
developerWorks에 실린 가상화에 대한 기사 또는 Tim의 모든 기사를 더 찾아보자.

Wikipedia는 VM(플랫폼 및 애플리케이션 모두)에 대해 자세히 학습하는 훌륭한 자원 세트를 제시한다. 특히 p-code machines 전용 페이지 외에도 virtual machines에 대한 페이지를 확인하자.

B 언어와 그 다음의 C 언어의 선구자격인 BCPL은 Martin Richards가 1967년에 만들었다. Project MAC의 일부로 최초의 온라인 BCPL 참조 매뉴얼을 읽을 수 있다. 또한 BCPL 홈 사이트에서 최신 버전을 다운로드할 수도 있다.

EFI Byte Code 또는 EBC는 이식 가능한 컴포넌트 드라이브의 해석적 계층을 지정한다. Boot Loaders: Small, Fast System Initialization(Dr. Dobb's, 2010년 9월)에서 EBC 및 UEFI에 대해 자세히 배울 수 있다.

Forth는 비록 1970년대 이후로 나타났지만, VM 언어로서 애플리케이션을 계속 찾고 있다. 항공 우주 과학, 임베드된 시스템 BIOS 및 자원이 드물게 존재하는 다른 애플리케이션에 적용된 Forth를 확인할 것이다. Forth Interest Group에서 Forth에 대해 자세히 배워보자.

Twitter의 developerWorks를 팔로우하고 developerWorks에 대한 Linux 트윗의 피드를 구독하거나 Twitter에서 M. Tim Jones를 팔로우하자.

developerWorks Linux 존에서는 수백 개의 기술자료 목록과 함께, Linux 개발자와 관리자를 위한 다양한 다운로드, 토론 포럼 및 다른 참고자료를 찾을 수 있다.

developerWorks 기술 행사 및 웹 캐스트를 통해 다양한 IBM 제품 및 IT 산업 주제에 대한 최신 정보를 얻을 수 있다.

무료 developerWorks Live! briefing을 통해 최신 IBM 제품 및 도구에 대한 정보뿐만 아니라 IT 업계의 최신 경향까지도 빠르게 확인할 수 있다.

developerWorks on-demand demos에서는 입문자를 위한 제품 설치 및 설정부터 숙련된 개발자를 위한 고급 기능까지 망라된 다양한 데모를 제공한다.

제품 및 기술 얻기
Dalvik은 Android 운영 체제를 위한 VM 환경이다. Dalvik은 Dan Bornstein이 개발했으며 Android의 일부로 Google이 유지보수하고 있다. 바이트코드로 Dalvik 머신에 대해 자세히 알아보자(사용자 문서에서 확인 가능). Android 개발 소개(Frank Ableson저, developerWorks, 2009년 5월)에서 Dalvik에 대해 더 자세히 배울 수도 있다.

Parrot은 Parrot 바이트코드에 대해 다양한 중간 표현을 통해 정적 및 동적 언어를 효율적으로 실행하도록 설계된 VM이다. Parrot은 오픈 소스로 사용 가능하고 수많은 언어로 사용될 수 있다. Parrot의 명령어 세트에 대해 자세히 배우려면 Parrot 내부에서 사용 가능한 opcode를 확인하자.

애플리케이션 VM은 게임 개발 업계에서는 대중적이다. Infocom은 텍스트 어드벤처 게임 부문에서(예: Zork) 이를 최초로 사용한 업체 중 하나이다. Z-machine이라고 하는 Infocom VM 뿐만 아니라 다양한 플랫폼에 존재하는 해석기에 대해 자세히 학습할 수 있다. 또 다른 VM의 애플리케이션은 LucasArts가 그래픽 어드벤처에 사용한 SCUMM이다. SCUMM은 ScummVM으로서 오픈 소스로 구현되었고 새 하드웨어에 이전 게임들을 되살리고 있다.

자신에게 가장한 적합한 방법으로 IBM 제품을 평가해 보자. 평가판 제품을 다운로드하거나, 온라인으로 제품을 사용해 보거나, 클라우드 환경에서 제품을 사용하거나, SOA Sandbox에서 SOA(Service Oriented Architecture)를 효과적으로 구현하는 방법을 배울 수 있다.

토론
developerWorks community에 참여한다. 개발자가 이끌고 있는 블로그, 포럼, 그룹 및 Wiki를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.

필자소개

M. Tim Jones는 임베디드 펌웨어 아키텍트이자 Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming(2판이 나왔다), AI Application Programming(2판이 나왔다), BSD Sockets Programming from a Multilanguage Perspective의 저자이기도 하다. Jones의 공학 배경은 정지 위성을 위한 커널 개발에서 시작해 임베디드 시스템 아키텍처와 네트워크 프로토콜 개발에 이르기까지 다양한 분야를 아우른다. Jones는 콜로라도 주, 롱몬트 소재 Emulex 사에서 컨설턴트 엔지니어로 활약한다.

Jul 20, 2011

가상화 솔루션 선두 ‘VM웨어’ 맹추격하는 ‘MS 하이퍼-V’

x86 계열 서버에서 하이퍼바이저(Hipervisor) 가상화 소프트웨어 도입 조직의 58%가 VM웨어(VMware)를 사용하고 있고, 그 나머지를 시트릭스(Ctrix)와 MS 하이퍼-V(Hyper-V)가 함께 분할하고 있다는 조사 결과가 발표되었다.

가상화 전문 관리 업체 빔(Veeam)사가 시장 조사 기관 밴슨 본(Vanson Bourne)에 의뢰하여 550개 대기업을 대상으로 실시한 조사 결과, 대상 기관의 92%가 가상화 기술을 도입하였고, 평균 470 대의 가상 머신을 운영하는 것으로 밝혀졌다.

가상화 하이퍼바이저로 VM웨어가 가장 널리 사용되고 있지만, 과거에 비해 시트릭스와 MS 하이퍼바이저를 같이 운영하는 경우도 늘고 있다. 이는 VM웨어의 최신 가격 인상과 함께 시트릭스와 MS의 적극적인 시장 침투의 노력으로 보고 있다.

58% 점유율을 차지한 VM웨어에 이어 시트릭스가 20.2%로 그 뒤를 따랐고 MS 하이퍼-V는 18.6%를 차지했다. 그리고 가상화 도입한 전체 데이터로 보면 VM웨어가 84% 도입되어 기본적인 하이퍼 바이저로 사용되지만 MS 하이퍼-V가 61%, 또 55.4%는 시트릭스를 그리고 젠서버(XenServer)도 12%가 사용되며 VM웨어 이외의 다른 하이퍼바이저도 대거 함께 사용하는 것으로 파악됐다.

조사 결과에서 눈에 띄는 점은 MS 하이퍼-V 의 약진이다, 가상화 시장에서 점유율이 60%에 육박하는 VM웨어가 여전히 미션 크리티컬 애플리케이션을 실행하기 위한 최고의 선택으로 인지되고 있지만 최근 MS 하이퍼-V가 시트릭스보다 점유율을 더욱 빨리 확대해 가고 있는 것으로 조사됐다.

이는 2011년 1사분기 가상화 시장을 조사한 IDC 결과에서 더 두드러진다. IDC도 역시 VM웨어가
58%를 점유하는 것으로 조사했으나 MS가 26%, 시트릭스는 8%의 결과로 발표했다. 이는 새로운 x86 서버의 20%가 MS 가상화 기술을 미리 설치하거나 배포 시에 기본으로 설치되는 것이 이유라고 IDC는 분석하고 있다. 또한 VM웨어의 새로운 라이선스 가격 인상이 고객들 사이에서 불만이 되고 있으며 이로 인해 MS의 점유율이 더욱 상승할 수 있다고 지적하고 있다.

MS 하이퍼-V는 윈도우 서버가 공급될 때 독자 실행형(stand-alone) 제품 사용에 대해서는 무료이며, 대부분의 VM웨어 고객이 가상화를 시작할 때 함께 사용하고 있다. 시장 조사 기관인 가트너는 최근 기상화 도구의 '매직 사분면(Magic Quadrant)'에서 맨 앞 VM웨어 뒤에 시트릭스를 제치고 MS를 배치시켰다.

빔 사는 이번 밴슨 본((Vanson Bourne)조사는 적어도 1,000 명의 직원을 거느리고 미국, 영국, 프랑스,​​ 독일의 544 기업, 기관에서 의사 결정권자에 의해 조사된 결과임을 알렸다.

Jul 7, 2011

데스크탑 가상화 시장

데스크톱 가상화 시장 전망
KISTI 미리안 『글로벌동향브리핑』 2011-06-30

IT 시장조사기관인 ABI Research社는 “데스크탑 가상화 : 가상화 비즈니스 데스크탑 PC의 글로벌 시장 현황(Desktop Virtualization: The Global Market for Virtualized Business Desktop PCs)”이라는 제하의 보고서를 통해 데스크탑 가상화 이면의 주요 기술, 개발 환경 및 주요 트렌드, 발전 동인 및 변화상, 향후 전망 등을 제시하였다.

ABI Research社의 同 조사보고서에 의하면, 전 세계 호스팅되는 가상 데스크탑 시장은 2009년 약 5억 달러 규모에서 2016년에 이르면 거의 50억 달러에 이를 것으로 전망된다. 조사에 의하면, 북미와 유럽이 전망 데이터의 대부분에 걸쳐 가상화 데스크탑 시장의 대부분을 점유할 것으로 예측되었다.

ABI Research社의 자동화, 에너지 및 신기술 분야 연구책임자인 래리 피셔(Larry Fisher)는 가상화 데스크톱 기반(VDI, Virtual desktop infrastructure) 시장이 향후 5년 동안 인상적인 상승폭을 기록할 것이라고 예측했다. 구매자들은 원칙적으로 대기업들로서 自社의 데스크탑 지원 및 관리 비용을 절감하려는 노력의 일환으로 이를 도입하고, 아울러 컴플라이언스(compliance) 혹은 보안 등을 이유로 데이터센터에 自社의 데이터를 보관할 필요가 있는 기업들이 해당된다고 그는 설명했다.

기업들은 또한 가상 데스크탑 도입을 통해 전체적으로 에너지 수요가 낮아지는 점을 매력적으로 여기고 있으며, 아울러 가상 데스크탑을 통한 비즈니스 연속성(business continuity)과 재난 복구(disaster recovery) 능력 등에 많은 관심을 보이는 것으로 나타났다. 피셔는 가상화 데스크탑을 통해 기업의 IT 부서들은 상대적으로 용이하게 다양한 범위의 디바이스를 기업 네트워크에 통합할 수 있다고 덧붙였다.

예를 들어 가상화 데스크탑을 통해 이용자들은 자신이 보유한 iPads, 스마트폰, 기타 다양한 디바이스를 통해 기업의 데스크탑 PC에 접속할 수 있다고 그는 말했다. 호스팅되는 가상화 데스크탑을 도입하게 되는 가장 큰 이유 중 하나는 가상화 데스크탑 기반의 구축이 다른 기존의 데스크탑 PC 환경에서보다 동일한 기능을 제공하면서도 편의성이 더욱 뛰어나고, 보다 경제적인 기술의 적용이라는 점을 IT 정책 결정자들이 인식하고 있다는 점이라고 그는 지적했다.

Jul 4, 2011

VXI, 시스코 데스크탑 가상화 아키택쳐

[연재] VXI, 시스코 데스크탑 가상화 아키택쳐 - 1. VXI란 무엇인가?
UC Solutions 2011/06/30 19:04
                                                                                               글 싣는 순서  
                                                                                            1. VXI란 무엇인가?
                                                                                            2. Cisco VXC의 이해 
                                                                                            3. VXI Architecture

데스크탑 가상화라는 생소한 분야를 공부하면서 정리한다는 것이 쉽지 않지만, UC 엔지니어에게 꼭 필요한 부분이라 데스크탑 가상화를 정리해 보겠습니다. 이제 클라우드가 거스를 수 없는 대세이기에 데스크탑 가상화 환경에서도 안정적인 Collaboration 서비스가 가능하도록 하는 것이 UC 엔지니어의 역할입니다. 제가 늘 그렇듯이 이런 생소한 기술은 UC 엔지니어가 알아야 하는 수준으로 아는 만큼만 정리하겠습니다.
데스크탑 가상화의 개요
데스크탑 가상화 (Desktop Virtualization)는 사용자의 데스크탑 PC를 데이터센터의 가상 데스크탑(Virtual Desktop))으로 옮겨 놓고, 사용자는 원격으로 접속하여 운영 체제 및 어플리케이션을 이용하는 기술입니다.즉, 데스크탑 가상화는 “The Network is Desktop” 이라고 정의할 수 있습니다.

 

사용자의 인터페이스를 담당하는 모니터, 키보드, 마우스 및 주변 기기는 사용자측에 그대로 두고, 데스크탑 본체 (CPU, 메모리, 하드디스크 등)는 데이터센터 내에 위치하게 되는 구조입니다. 이런 데스크탑 가상화에 대한 일반적인 이점은 다음과 같습니다.

관리의 편이성
비즈니스 유연성
데이터 유출 방지
TCO 절감
좀 더 쉽게 이해할 수 있도록 풀어서 설명하면 다음과 같습니다.  



언제 어디서나 네트워크를 접속하여  가상 데스크탑으로 접속하여 업무를 지속할 수 있음
관리자는 사용자의 요구 사항에 맞게 고성능 및 개인화된 가상 데스크탑을 손쉽게 구성
음성 및 영상과 같은 Rich Media를 활용이 가능
도입을 고려하는 기업에서는 TCO (Total Cost of Ownership, 총 소유 비용)가 절감된다는 것은 이해하지만, 초기 투자비용이 의외로 많이 들어가는 것이 구축을 망설입니다. 데스크탑 가상화 시장은 보안이 중요한 금융이나 R&D 센터에서 먼저 시작하고 있으며, 시장의 확대 속도가 매우 클 것으로 기대하고 있습니다.

 

일반적인 데스크탑 가상화 구성
데스크탑 가상화의 대표적인 솔루션은 VMware View, Citrix Xendesktop, Microsoft Terminal Service의 삼국시대입니다만, 국내에서는 VMware View 와 Citrix Xendesktop이 주로 경쟁합니다. Microsoft는 Windows OS 위에 가상머신 (Virtual Machine)을 구성하므로 비효율적이라는 지적입니다. 이 글에서도 VMware와 시트릭스(Citrix)를 대상으로 이야기를 전개하겠습니다.

아래 그림은 데스크탑 가상화 솔루션의 구성에 대해 쉽게 이해할 수 있게 되어 있습니다.  기본적으로 서버 가상화와 크게 다르지 않으므로 단말과 Conection Broker에 대해서 살펴보겠습니다. 일반적으로 단말들은 Connection Broker에 접속하여 인증 및 Target VM (Virtual Meachine)을 식별한 후 Virtual Infrastucture Management를 이용하여 사용자 정책을 받습니다. 그 후에 단말은 데이터센터 내 VM에 직접 접속하며 Display Protocol을 이용하여 정보를 송수신 합니다.

데스크탑 가상화에서 단말을 제로 클라이언트 (Zero Client), 씬 클라이언트 (Thin Client), 씩 클라이언트 (Thick Client)로 구분합니다. 단말은 모니터, 키보드, 마우스, 마이크, 스피커와 같은 주변기기를 연결할 수 있는 인터페이스와 네트워크 인터페이스를 가지고 있으며, 가상 데스크탑 (Virtual PC)과 연결을 위한 Embeded OS가 로드됩니다. 데스크탑 가상화 클라이언트에 대해 살펴보겠습니다.  

Thick Client
Thick Client는 일반 윈도우즈나 리눅스 OS로 구동되는 일반 PC나 노트북으로 가상 데스크탑에 접속을 위해어플리케이션을 사용합니다. 네트워크에 연결되어서는 가상 데스크탑에 접속해서 사용하며, 네트워크와 단절된 상태도 단말에서 업무가 가능한 것이 특징입니다. 



Thick Client는 OS 관련 라이센스가 두배가 드는 단점이 있습니다. 즉, Local 단말을 위한 Windows 7 OS 하나와 가상 데스크탑을 위한 OS 하나가 추가로 필요합니다.

Thin Client
Thine Client는 리눅스 또는 윈도우즈와 같은 OS를 커스터마이징한 embedded OS로 동작하며, 일반적으로  저 사양의 PC, 넷북과 같은 형태로 최소한의 CPU, 메모리, 하드디스크를 가집니다.  

  

아이패드와 안드로이드 테블릿도 이 영역에 포함될 수 있습니다. 전통적인 PC 제조업체에서는 Thin Client를 적극적으로 홍보하는 경향이 있습니다.

Zero Client
Zero Client는 가장 단순한 형태의 장비로 embedded OS로 동작합니다. 컴퓨팅 파워를 필요로 하는 모든 기능은 가상 데스크탑에서 이루어지며, Zero Client는 사용자 인터페이스만을 집적합니다. Zero Client는 CPU, 메모리, 하드디스크 등의 부품없이 네트워크 접속과 주변기기 연결만을 제공합니다.



Zero Client의 장점은 OS가 없으므로 OS 라이센스 비용이 필요 없고, 단말기 관리가 쉽고, 전력 소모가 적다는 것이다. 또한, 장애나 고장이 발생할 확률이 적고 장비가 단순하여 운영 및 유지 비용이 저렴합니다. 단점으로는 사용자를 위한 공간이 전혀 없고, 가상 데스크탑만을 활용함으로써 네트워크 접속 차단시 아무것도 하 수 없습니다. 보안을 중요시 하는 기업이 선호합니다. 
데스크탑 가상화 도입 시 모든 단말을 교체할 필요가 없으므로 PC 교체 주기에 맞추어 순차적으로 교체하는 것이 일반적입니다. 

Connection Broker는 단말이 가상 데스크탑에 접속할 수 있도록 도와주는 소프트웨어로 다음과 같은 기능을 수행합니다.

사용자 인증
사용자가 특정 VM에 대한 접속 관리
사용자가 다수의 VM Pools (VM 그룹) 관리
사용자의 상태 모니터링
사용자의 접속이 끊어졌을 때 VM 재할당
Connection Broker는 가상 데스크탑 접속을 위한 시작점으로 로드밸런싱을 위한 L4 스위치와 함께 구성됩니다.
Desktop Virtualization Protocol의 이해
데스크탑 가상화에서 단말과 VM간의 통신은 Desktop Virtualization Protocol 또는 Display Procotol을 이용합니다. 가상 데스크탑에서 프로세싱된 모든 결과물은 Display Protocl을 통하여 단말에 전달됩니다. 각 가상화 솔루션 업체마다 다른 프로토콜을 사용하며, 대표적인 PCoIP와 ICA에 대해서만 살펴보겠습니다.

Citrix의 ICA / HDX (TCP 기반)
ICA는 Citrix의 데스크탑 가상화 프로토콜로써, TCP를 사용하며 최대 32개의 가상 채널을 형성합니다. 기본적으로 암호화 및 압축을 지원합니다. 특히, XenDesktop의 HDX (High-Definition user experience)는 시트릭스의 가상 데스크탑 및 애플리케이션을 고화질로 전송할 수 있도록 하는 기술입니다. 특히, 3D, 그래픽, 영상 등에서 효과적인 성능을 발휘할 수 있으며, 사용자 측의 디지털 카메라, 스마트폰, 스캐너 등의 주변기기를 손쉽게 연결할 수 있도록 도와줍니다.

 

VMware의 PCoIP / Teradici (UDP 이용)
PC over IP는 VMware의 데스크탑 가상화 프로토콜로써, 지연 및 효율적인 대역폭 활용이 특징입니다. 최대 4개의 모니터 및 2560*1600 까지의 해상도를 지원합니다. PCoIP는 VMware의 자회사인 Teradici에서 개발한 프로토콜로 서버에서 그래픽 렌더링 및 프로세싱을 대부분 처리하고, 그 결과를 비트맵으로 전송합니다. 
 
이 두 프로토콜의 가장 큰 차이는 Layer 4 전송 프로토콜을 무엇으로 사용하는 가가 가장 큰 차이이지만, 어플리케이션에 따라 성능의 차이를 보일 수가 있습니다. 기업의 업무 특성상 어떤 프로토콜을 주로 사용하느냐에 따라 선택이 달라질 수 있을 것입니다.  

 

데스크탑 가상화 구성 시 드러나는 문제점
지금까지 데스크탑 가상화의 일반적인 내용을 기반으로 데스크탑 가상화 구축 시에 발생할 수 있는 문제점을 살펴보겠습니다. 예를 들면, 기존의 PC 환경에서 사용자 입출력 인터페이스 (마우스, 키보드, 모니터)에 지연이나 지터가 발생하지 않지만, 데스크탑 가상화로 이전 시에 네트워크를 통한 사용자 입출력에 지터나 지연이 발생할 수 있습니다. 즉, 사용자의 경험이 네트워크를 통해 그대로 전이되어야 합니다. 이러한 부분에 대한 문제점들을 살펴보겠습니다.

기존의 WAN 대역폭으로 인한 사용자 경험 저하 
영상 스트리밍을 사용자가 본다고 가정해 봅시다. 아래 그림과 같이 가상 데스크탑에 도착한 스트리밍 영상은 LAN을 이용하여 도착하였으므로 깨끗한 화질을 유지하겠지만, 불필요한 프로세싱 파워 소모 및 데이터 센터내의 불필요한 네트워크 대역폭 소모가 발생합니다. Display Protocol을 이용하여 사용자 단말에 VM의 프로세싱 결과가 전송될 때 영상의 조각화(Pixelization)이 발생합니다. 기존의 WAN 대역폭으로는 처리할 수 없는 것이 일반적입니다.  



따라서, 데스크탑 가상화에서는 WAN구간의 대역폭을 충분히 확보하는 것이 필요하지만, 대역폭을 무한정 늘릴 수 없다는 것이 한계입니다. 

네트워크는 Display Protocol 내의 음성, 영상 및 데이터를 따로 구분할 수 없음
VM 내의 모니터 정보를 다운로드 받는 클라이언트의 입장에서 네트워크가 음성, 영상, 데이타를 구분하여 효과적인 QoS를 제공하길 원하지만, Branch Router의 입장에서는 패킷마다의 우선 순위를 구분하기 어렵습니다. 즉, Display Protocol은 가장 최적의 서비스를 받아야 하는 영상 및 음성 프로토콜을 따로 구분하지 않습니다. 


위에서 제기된 문제점을 단순화 하면, 가장 큰 문제는 데이터센터 내의 헤어핀(Hairpin) 현상입니다. 아래 그림을 보듯이 두 개의 Thin Client가 각자의 소프트 폰으로 영상 통화를 할 때 시스코 CUCM을 통해 시그널링을 처리하고, 실제 영상은 두 가상 데스크탑간에 주고 받습니다. 영상과 음성은 Display Protocol을 이용하여 Thin Client로 전달될 것입니다. 두 개의 씬 클라이언트가 같은 지사에 위치하고 있다고 가정한다면, 음성 트래픽이 가상 데스크탑 간에 교환됨으로 인해 불필요한 WAN 대역폭을  점유하고, 영상 및 음성 품질 저하를 일으키는 원인입니다. 이 것을 Hairpin 현상이라고 합니다.



데스크탑 가상화 도입을 위해서는 happin 현상에 대한 고려가 필요합니다. 현재의 QoS가 적용된 네트워크처럼 멀티미디어 패킷이 우선 순위를 부여 받아 효율적인 라우팅 및 스위칭이 데스크탑 가상화 환경에서도 가능해야 하며, 데이터센터 내에서 VM간의 불필요한 멀티미디어 트래픽의 교환이 아닌 클라이언트간에 직접적인 트래픽 교환이 이루어져야 합니다. 
 

Cisco VXI의 개요 
데스크탑 가상화 (Desktop Virtualization)와 Collaboration 이 잘 융합되어 기존의 문제점을 해결할 수 있도록 하기 위한 솔루션이 바로 VXI (Virtual Experience Infrastructure) 아키택쳐입니다. 즉, VXI는 데스크탑 가상화 환경에서 Collaboration과 Rich media를 최적의 상태로 전달하여 사용자 경험을 그대로 유지할 수 있도록 하기 위한 End-to-End 시스템입니다.



VXI 아키택쳐는 데스크탑 가상화를 세 영역의 솔루션 셋으로 구분하여 각각에서의 역할을 정의합니다. 세 영역은 VM이 마운트되는 스토리지와 서버가 있는 Virtualized Data Center, Virualization-Aware Borderless Network, 가상화 클라이언트가 있는 Virtualized Collaborative Workspace 영역입니다. 각 영역에서의 역할과 필요한 요소 장비 및 기술은 다음 장에서 설명드리겠습니다. 



Cisco VXI를 가장 잘 표현하는 것은 “VXI = VDI + Collaboration” 입니다. VXI는 기존의 데스크탑 가상화를 주도하는 VMware나 Citirix에서 고려하지 못하는 네트워크와 Workspace에 대한 부분을 보충하는 것입니다. 따라서, 효율적인 데스크탑 가상화를 위해 다음과 같은 것을 함께 고려해야 합니다. 

End-to-End Architecture & Validation
Rich Media 및 UC
Enhanced Security
어플리케이션 가속
PoE 및 EnergyWise
 

VXI를 이용한 hairphine 해결방안
앞서 언급한 데이터센터 내의 헤어핀 문제를 해결하면, 그로 인해 파생되는 다양한 문제점을 해결할 수 있습니다. VXI에서 제공하는 방안은 다음과 같습니다.

Desk Phone Control (Click to Call)
가상 데스크탑의 소프트폰을 Phone Control 모드로 전환하여 사용합니다. 사용자의 책상위의 전화기를 직접 제어할 수 있어서 시그널링은 데이터센터의 CUCM을 거치지만, 음성 및 영상은 직접 End-to-end로 전달됩니다.즉, 시그널링은 가상 데스크탑을 활요하지만, Media는 사용자의 전화기를 통해 이루어지는 구조입니다.

Desk Phone Control을 이용하게 되면 다음과 같은 이점을 얻을 수 있습니다.

- WAN 대역폭의 소모를 줄이고 품질 확보
- 음성 및 영상은 직접 RTP 프로토콜을 통해 전달되므로 QoS 적용이 가능
- 기존의 CAC (Call Admission Control) 적용이 가능
- 119, 112 와 같은 긴급 호 서비스 및 지역 별 Dial-Plan 적용이 가능

Embeded Communicator on Thin Client
Desk Phone Control을 통한 방법은 지금 당장 사용할 수 있지만, 소프트 폰 모드에서 사용할 수 없다는 단점이 있습니다. 그래서, Thin Clinet에 직접 소프트폰 기능을 삽입하여 가상 데스크탑의 소프트폰과 상호 작용하여 헤어핀 문제를 해결합니다.

 
 
마치며
지금까지 데스크탑 가상화와 VXI의 필요성에 대해 살펴보았습니다. 시스코는 VXI 아키택쳐가 발표하고 난 후 지난 달 데스크탑 가상화 단말 (VXC)을 출시하였습니다. VXC는 데스크탑 가상화를 위한 제로 클라이언트와 씬 클라이언트로 구성되어 있습니다. 이에 대한 자세한 사항은 다음 장에서 설명하겠습니다.


여담 - UC 엔지니어의 기술 트리
“UC on UCS 길라잡이” 라는 연재를 통해 서버 가상화에 대한 비즈니스적인 접근이 아닌 기술 위주의 글을 올렸었습니다. 이때, UC 엔지니어의 필수 기술 트리로 서버 가상화 기술인 VMware를 공부할 것을 강조했습니다. 이 연재를 통해 UC 엔지니어의 기술 트리에 데스크탑 가상화 기술을 하나 더 추가해야 할 듯 싶습니다.

UC 및 Collaboration 엔지니어가 서버 가상화 기술과 데스크탑 가상화 기술을 가져야 하는 이유는 클라우드의 활황세에 있습니다. 클라우드 기반으로 모든 시스템이 이전하는 환경에서 기반 기술에 대한 이해없이 UC를 설계할 수 없습니다. 즉, IP 네트워크를 이해하지 못하고 IP Telephony를 설계할 수 없는 것과 마찬가지입니다. 

UC 엔지니어의 기술 트리에는 Routing & Switching 일반, VoIP, IP Telephony, Virtualization은 필수적으로 갖추어야 하며, Contact Center 및 Video 를 옵션으로 갖춘다면 천하무적 UC 엔지니어가 되지 않나 싶습니다. 물론, R&S나 Virtualization을 다른 전문 엔지니어만큼 알 필요는 없습니다.  

다행인지 불행인지 UC 분야는 은퇴할 때까지 끊임없이 공부해야 하는 업종입니다. -,-:?

----------------------------------------------------------------------------------------------
라인하트 (CCIEV #18487)
ucwana@gmail.com (라인하트의 구글 이메일)
http://twitter.com/ucwana (라인하트의 트위터 )
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스)
정리하고 보니 나도 디지털 네이티브 ^______________________________________________________________^

Posted by 라인하트
ICA, PCoIP, thick Client, thin client, VXI, Zero Client, 가상화, 데스크탑 가상화
트랙백 0개, 댓글 0개가 달렸습니다.
트랙백 주소 : http://www.nexpert.net/trackback/312

Name
Password
Homepage
비밀글


이전 1 2 3 4 5 ... 234 다음