서버 가상화와 스토리지 가상화의 성장세에 비하여 주춤하고 있는 가상 데스크탑. 무엇이 VDI 시장의 발목을 잡는가? 가장 큰 원인은 I/O 퍼포먼스 이슈로 주로 출근 시 집중부팅, 백업, 소프트웨어 업데이트, 바이러스 스캐닝에 의해 유발된다. 이러한 문제는 고가의 SSD(솔리드 스테이트 드라이브)를 이용한 인프라를 통해 극복 가능하다. 하지만 이는 비용 증가를 불러일으켜 고객의 진입장벽이 될 수 있는 양면성이 존재한다. 다른 방법을 찾는다면, 보다 면밀한 접근방법을 생각해 볼 수 있는데, 인프라의 퍼포먼스 필요 수준을 측정하여 하드웨어를 필요할 때, 필요한 곳에 투입할 수 있도록 한다면 보다 합리적인 비용에 이러한 문제를 해결 할 수 있지는 않을까?
전반적인 가상화 시장의 규모가 과거 몇 년에 걸쳐 두 배 이상 증가하였다고 한다. 이러한 배경에는 서버 및 스토리지의 활용성 증가를 통하여 비용절감을 실현한 것이 일차적인 시장확대의 추진력이었으며, 보다 1) 신속한 프로비저닝, 2) IT 서비스 품질, 3) 운영 및 유지보수 비용의 감소라는 이차적인 기여 요소들이 존재하였다. 하지만 오범(Ovum)에 따르면, 데스크탑 가상화의 점유율은 전체 기업 PC 시장의 3%(콜센터에서 사용되는 터미널 서비스 제외)에 불과한 상황이다. 씬클라이언트는 기업의 표준화를 확산시키고, 유지보수 비용을 감소시키며, 라이선스 비용(동시 사용 라이선스 기준)을 절감할 수 있지만, 고성능 I/O와 유휴 스토리지에 대한 니즈는 여전히 VDI 시장의 성장에 장애가 되고 있다.
가상 데스크탑 인프라스트럭쳐(VDIs)는 스토리지의 I/O와 저장공간을 과도하게 사용하는 구조를 지니는데, 이는 수백 개 규모의 중간 사이즈 데스크탑 가상화 환경에서도 수 테라바이트를 사용하며, 초당 수천 번의 I/O 발생을 유발합니다."라고 밸류에디드 리셀러 초이스 솔루션 대표 제임스 스테인레이지는 말한다. 대체로 출근시간의 부팅집중과 하이엔드 애플리케이션의 업데이트, 백업 및 바이러스 스캐닝 시 사용자 경험 최적화를 위해서는 SSD와 일반 디스크 사이의 중간 정도 퍼포먼스를 필요로 한다. 만일 SSD로만 구성된 VDI를 고려한다면, 이를 고가에 구매할 여력을 가진 고객은 없을지도 모른다.
이는 모두 측정의 문제다. 우리는 서버 가상화와 가상 데스크탑 환경 수준 측정 툴을 사용하여, 사람들이 애플리케이션을 사용하는 빈도와 시간대, 사용 기능 등을 확인할 수 있으며, 이를 통해 사용량과 사용빈도를 정의한다. 이러한 과정은 최적화된 VDI 설계의 기초가 되는데, 고객은 측정 과정에 비용을 투입하지 않는다 하더라도 언젠가는 그 이상을 지불해야한다는 것을 인식해야 한다. 그만큼 사전에 고객의 교육은 중요한 문제다. 무엇이 스토리지의 요구수준을 끌어가는지 명확하게 인식하여야 데스크탑이 단지 '박스(box)' 문제 이상이라는 것을 깨달을 수 있다.
고객은 가상화라는 말을 자주 듣게 되지만, 정작 그 의미는 모르고 있다. 그저 비용절감이나 운영상의 퍼포먼스를 위해 필요한 투자 정도로 인식하고 있는 것이 현실이다. 얻는 것이 있으면 잃는 것이 있다는 것에 대한 명확한 인식이 필요하다. 기존의 데스크탑을 가상 데스크탑으로의 전환이 완료되면, 고객의 벤더 의존도는 커지게 된다. 구축 초기 환경 평가를 거치지 않게 되면, 추후 확장성 등의 문제가 발생하는데 이러한 이슈는 고객과 벤더 사이의 장기적 관계에 악영향이 될 가능성이 농후하다.
기존의 디스크 어레이(array) 벤더들은 고객이 퍼포먼스의 이슈를 제기할 때, SSD로 교체할 수 있도록 채널 파트너들을 독려할 것이다. 하지만, 애플리케이션과 퍼포먼스 요구수준을 제대로 이해하고 있다면, 적절한 위치에 SSD와 SAS 또는 SATA의 적정량를 배치함으로써 자원의 과다투입을 피할 수 있다. 이를 위한 전제조건은 다양한 유형의 스토리지 간에 QoS(quality of service)를 맞추기 위하여 적합한 스토리지 가상화 컴포넌트를 사용하는 것이다.
원본: Mark Rieger, www.echannelline.com, 2012
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 등 프로토콜 전체를 지원하는 경우가 많은 만큼 아키텍처 설계단계에서 적절히 혼용하는 게 필요하다”라고 조언했다.
가상 데스크톱 인프라(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배 이상 비싼 편이다.
외신은 “일본, 싱가포르, 말레이시아 등의 아시아 지역에서 온라인 몰을 통해 판매중”이라고 전했다.
리코매직(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기가바이트의 플래시 메모리를 갖추고 있다.
다양한 포트를 갖춰 활용성이 뛰어난 편이다. 우선 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메일, 구글플러스 등에 대한 일반사용자의 네트워크와 구글의 데이터센터들을 연결하는 내부 백본망이다.
외부 사용자의 네트워크 트래픽은 일정 패턴을 갖는다. 시간에 따라 사용자 트래픽이 몰렸다가 줄어드는 현상이 반복된다. 이는 예측가능한 트래픽이다.
반면, 내부 백본방의 경우는 조금 다르다. 이는 데이터센터에서 데이터센터로 수페타바이트 규모의 데이터를 옮기는 과정에서 일어난다. 특정 데이터 트래픽이 일시에 몰리는 현상이 불시에 일어나고 이를 예측해 관리하는 게 기존 인프라로선 매우 어려운 일이다.
몰리는 트래픽을 적절히 분산하거나 경로를 설정해주는 등의 트래픽 엔지니어링이 필요한데, 데이터센터에서 데이터센터로 보내는 트래픽 중 각자 다른 비즈니스 우선순위를 세우고, 더 중요한 트래픽을 먼저 내보내는 것을 계량화하는 작업이 현재로선 불가능에 가깝다.
그는 “오픈플로를 채택한다는 생각이 구글 전체 역사상 네트워크에 가장 큰 변화일 것”이라고 말했다. 그는 “네트워크 장비 하드웨어를 만드는 것은 어렵지 않다”라며 “만들기 어려운 것은 소프트웨어”라고 덧붙였다.
구글이 소프트웨어 정의 네트워크(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
[디지털데일리 백지영기자] 그래픽처리장치(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
기업은행은 고객센터와 충주연수원에 데스크톱 가상화를 적용한 데 이어 전사 확산을 검토했지만 성능과 비용부담으로 도입을 보류하기로 결정했다고 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
Tue, 04/24/2012 - 16:51 — Alan Weissberger
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."
=======================================================================================
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
========================================================================================
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.
Subscribe to:
Posts (Atom)