Tag Archives: Virtualization

Tech #4 : VMware VSphere 4.1의 Network 구성

VMware VSphere 4.1에서는 Network의 자원 관리를 보다 적절하게 실현하기 위한 기능으로 “Network I/O Control”가 도입되었다고 한다. 또, NIC Teaming의 Load Balance Algorizm 으로 “Load Based Teamin”이라고 하는 신 Algorizm이 이용가능하게 되었다고 한다.

일단, 이전의 ESX(Classic)은 가상화을 행하는 “VMKernel”의 영역과 관리기능을 제공하는 “Service Console” 영역이었으나, Server의 처리 능력 향상에 비례하여, 가상 Machine의 집약 능력도 향상하는데 이는 보다 광대역의 Network 환경이 요구된 다는 걸 의미한다. 그걸 말해 주듯 이제 10Gbits Internet도 보급되기 시작했고, 10Gbits EtherNet의 Controller나 Switch를 포함하는 Blade Server도 등장하여 본격적인 궤도에 올랐다고 볼 수 있다.

10Gbis Ethernet의 사용을 전제로 System을 구축 할 경우 여러가지 Data 통신을 통합하는 시도도 많아 질 수 있고, 가상 Machine이 이용하는 Network를 포함한 관리 Network, iSCSI나 NFS 등의 Storge Network, vMotion이나 VMware FT가 이용하는 Data Transfer 등도 통합 해야 할 것이다. 통합을 위해서는 다른 Resource에 의해 대부분의 Performance가 점유되어 가상 Machine 전체가 Slow down 되는 경우를 피해야 하고, 그에 맞는 설계를 할 필요가 있다.

여기서, Network 자원 관리가 중요 해 지는데, Previous Version에서도 “Traffic Shaving”란 기능을 제공 했었고, 이건 가상 Port 또는 Port Group가 이용가능한 대역의 상한치를 지정하는 기능으로, 표준 가상 Switch에서는 Outbound Traffic, 분산가상 Switch에서는 Inbound, Outbound Traffic 가각의 Traffic에 대한 설정이 가능, 단 Traffic Shaving은 간단하게 이용가능한 상한치를 제어하는 기능 뿐으로 Unused 대역에 대한 다른 용도로의 전환은 불가능 하다. 아래 그림 처럼 Unused 영역이 있어도 상한치 이상을 사용 할 수 없다.

 

보다 이상적인 Network 자원 관리를 실현 하기 위하여 자원의 간섭이 있을 시, 미리 설정을 해 둔 비율로 Balance를 맞춰, 자원이 비어 있는 상황에서는 그 자원을 필요한 용도로 전환 하는 것이 가능 해야 한다. 아래의 그림과 같다.

 

CPU자원과 Memory 자원에 관해서도 위와 같은 자원 관리 구성이 Previous Version에 대해서도 제공 되었다. vSphere 4.1에서는 Network 자원에 관한 동일한 기능이 제공 되어 지는데, Network I/O Control이 그것이다.

Network I/O Control

vSphere 4.1의 new function “Network I/O Control”은 앞에서 설명 했던 것 처럼 유연한 Network 자원 관리를 실현하는 메카니즘이고, 현재 Enterprise Plus Edition에서 제공하고 있다. 또, 이 기능은 분산 가상 Switch 상에서 제공되는 기능이고, 표준 가상 Switch상에서는 이용 할 수 없다.

Network I/O Control에서 Network Traffic을 아래와 같이 6 class로 구분할 수 있다.

  1. FT Traffic
  2. iSCSI Traffic
  3. vMotion Traffic
  4. Management Traffic
  5. NFS Traffic
  6. Virtual Machine Traffic

User는 각각의 Class에 대해 “Limit” 혹은 “Share”라는 값을 설정 할 수 있고, “Limit”는 해당 Class가 사용 가능한 최대치이고, Mbps로 설정한다. “Share”는 “자원 간섭이 있을 시 Balance 값”으로 1 ~ 100의 정수값을 설정한다.

Network I/O control의 동작

Network I/O Control은 ESX로부터의 Outbound Traffic에 대해서만 유효하고, Inbound Traffic은 제어 대상이 아니다. 또, “Share 값의 계산은 최종적으로 각 ESX Host 단위” 도 주의 할 점이다. 분산 가상 Switch를 구성할 경우, 보통 각 ESX에 구성하는 Uplink의 수나 물리 Adapter의 대역등은 공통이지만, 그렇지 않은 경우는 주의가 필요하다. 1Gbps의 NIC으로만 구성되는 Host와 10Gbps의 NIC을 보유하는 Host가 같이 있는 경우는 Share 값의 계산 결과로 확보되는 대역이 Host에 따라 다른 경우가 있다. 

“Limit”나 “Share”의 설정은 동시에 유효화가 가능하고, Share값 계산의 결과 획득 가능한 대역이 Limit에서 제한하고 있는 값보다 큰 경우 Limit의 값이 적용된다.

Load Based Teaming

LBT는 복수의 물리 NIC을 통합 가능한 대역의 확보와 이중화를 제공하는 “NIC Teamng”이 적용된다. 복수의 물리 NIC으로 Link을 구성함과 더불어 각 Traffic이 어떻게 물리 NIC을 결정하는 가의 알고리즘이 필요하게 된다. 해당 알고리즘은 아래와 같다.

  1. Port ID Based
    Default로 이용되는 알고리즘으로 Port ID란 가상 Switch내의 Port ID. 가상 NIC이 접속하고 있는 가상 Port별로 이용하는 물리 NIC이 결정 된다. 즉, 하나의 가상 NIC을 하나의 물리 NIC을 대응하는 방식이지만, 복수의 가상 Machine인 환경에선 부하 분산도 기대 할 수 있다.
  2. Source MAC
    Traffic의 Source측의 MAC Address, 말하자면 가상 NIC의 MAC Address 정보를 기초로 한 Hash값을 두고 물리 NIC을 결정하는 알고리즘. 하나의 가상 NIC이 최종적으로 하나의 물리 NIC을 댕응하는 점에서는 Port ID Based와 같다.  많은 경우 Port ID Based의 부하분산은 유효하지만, 운영하는 형태에 따라서는 물리 NIC의 사용률이 균일하지 않은 경우가 있다. 예를 들면 물리 NIC x 2로 Teaming된 가상 Switch에 20대의 가상 Machine이 접속되어 있는 상황을 가정하면  System 운영 특성 상 홀수번째의 가상 Machine이 Active로 동작하고, 짝수번째의 가상 Machine은 대기하고 있다면, 이 경우 부하분산 알고리즘으로 Port ID Based를 이용하면 결과적으로 한쪽의 물리 NIC에 Traffic이 집중되어 버린다. 이런 경우 Source MAC을 이용하여 양측의 물리NC이 균일하게 사용되도록 할 수 있다.
  3. IP Hash
    IP Hash는 각 Traffic의 Source IP Address, Destination IP Address들을 바탕으로 Hash값을 계산하고, 이용하는 물리 NIC을 결정한다. 복수의 Destniation이 있는 경우, 하나의 가상 NIC이 복수의 물리 NIC을 사용 할 때 유리하다. IP Hash를 사용할 때는 물리 Switch측에 IEEE 802.3ad Link Aggregation을 유효화 시킬 필요가 있다.
  4. Load Based
    물리 NIC의 대역 사용 상황에 따라, 동적인 가상 Port와 물리 NIC간의 관계를 변경 한다. 초기 배치는 Port ID Based와 같은 방식으로 구성되지만, 운영 중 부하의 쏠림이 발생할 것 같으면 자동적으로 이 Mapping 을 변경 한다. vSphere 4.1로 부터 제공되는 기능으로 분산가상 Swtch만 지원 한다.

Load Based Teaming의 동작

LBT를 선택하면, 물리 NIC의 부하상황에 맞춰 가상 Port와 물리 NIC의 Mapping을 자동적으로 변경하게 된다. 이 때의 판단 기준은 Default로는 “물리 NIC의 대역 사용률이 75%를 넘는 경우가 30초이상 지속적으로 발생 할 때” .  Network Traffic은 순간적인 것, 지속적인 것이 있는데, 너무 과민하게 설정을 할 경우 오히려 역효과가 날 수 있다.

Network I/O Control, Load Based Teamin은 Enterprise Plus License가 필요하다.  쩝.. 슬픈 일이군..

Tech #3 : What is the Virtualization Technology?

(2007년 3월 1일)

“Server의 가상화”는 기업에 있어 이미 필수 기술이 되었다고 해도 과언이 아니다. 가상화에 있어 처리능력의 증강을 원한다면, 새로운 H/W를 구입할 필요는 없다. 그것은 말하자면, H/W구입비라고 하는 지출을 줄이는 것이기도 하고, Data Center의 Space와 전기 및 냉각에 드는 Cost를 절약하는 것이기도 하다. 물리적인 Server가 아닌 가상 Server를 선택하는 것은 기업에게 재무의 건전성을 부여하고, IT지출을 삭감하는 효과가 있다라고 하는 것이다. 여기에서 그런 Merit를 가진 가상화 Architecture 면으로부터 다시금 정리 해 보았다.

Nill Macarista
InforWorld Online 미국판

가상화의 기술, 가상화라는 Concept자체는 결코 새로운 것이 아니다. 실제, 이미 1970년대에 Main Frame Computer는 복수의 OS Instance를 동시에 실행하고 있었따. 그것이 가상화의 시작이 된다. 그 후, S/W와 H/W가 진화하여, 가상화는 더욱 가깝게 체감할 수 있는 기술이 되었다. 현재, 업계표준이 되어 있을 정도로 일반적인 Server에서도 가상화를 행하는 것이 가능하다.

지금, 시장에서는 proprietary로부터 Open Source까지, Data Center Manager가 선택하기 곤란할 정도로 많은 종류의 가상화 Solution이 넘쳐나고 있다. 여기서는 가상화에 대한 Approach 방법(Achitecture)에 있어 “완전 가상화” “모의 가상화” “OS Level의 가상화”의 3가지로 분류하고, 각각의 기술적인 특징을 소개한다.

※ Proprietary란,“전용의” “독자의” “독점적인” “소유권, 점유권이 있는” “비공개의”의 이미로, Computer관련용어로서는 Open의 Opposite word이다.
표준화가 진행된 PC (Client / Server System, Web System)에 따라 System을 “Open System”이라고 부를 때, Main Frame System과 같은 특정 Maker등에 따른 특정의 독자사양으로 구성된 Computer System을 “Proprietary System”이라고 한다.
또, Linux에 대표되는 Source Code가 공개된 S/W를 “Open Source Software” “Free Software”라고 부르는 것에 반해, Windows나 MAC OS와 같은 Software Maker가 Source Code(지적소유권)을 독점 소위 점유하고 있는 Soft는 “Proprietary Soft”라고 불린다.

완전 가상화 (Full Virtualization)
가상화 Solution 중에 가장 많이 보급된 것이 “Hipervisor”라고 불리우는 Architecture를 사용한 “완전 가상화”이다. 이것은 가상 Server와 H/W간에 추상적인 Layer(가상화 Layer를 실장한 전용 Kernel)을 배치하는 Architecture이다.
이 Approach를 채용하고 있는 상용제품으로는 “WMware”와 Micro Soft의 “Virtual PC”가 있고, Linux용 Open Source 제품으로는 “KVM (Kernel-based Virtual Machine)”가 있다.
Hipervivor는 CPU명령에 관여하여, H/W Controller와 주변기기로의 Access를 중개한다. 사실상, 어떤 OS라도 수정없이 가상 Server상에 Install할 수 있고, 그 Guest OS는 가상환경에 있다는 인식없이 가동한다. 더불어 이 Architecture의 결점은 Hipervivor에 의해 Processor에 큰 Overhead가 걸리는 것이다.
완전 가상화 환경에 있어 Hipervivor는 H/W상에서 직접 가동하고, Host OS(Kernel)로서 기능(다른 말로 하자면, Windows나 Linux 같은 일반 Host OS를 필요로하지 않음)한다. 그 Hipervivor가 관리하는 가상 Server상에서 Guest OS가 움직이는 셈이다.

 

모의 가상화 (Para Vritualization)
완전 가상화에서는 여러가지 가상 Server를 관리하고, 나아가 각각을 독립 가동시키고 있는 Hipervivor의 요구가 모든 Processor에 집약(그 때, Guest OS는 일절 가상화에는 관여하지 않음)된다.
이 부담을 경감시키기위한 수단의 한가지가 Guest OS에 관여 가상화 환경을 인식시키도록 함과 더불어 Hipervivor와 연계시키는 것이다. 이것이 “모의 가상화”라고 불리는 Approach이다.
이 모의 가상화 방식을 채용하고 있는 대표적인 제품이 Open Source “Xen”이다. Xen에서는 Kernel부분에 변경을 가함으로서 처음으로 Xen Hipervivor의 가상 Server상에서 Guest OS가 가동가능하게 된다. 이로 인해 BSD, Linux, Solaris와 같은 Open Source OS는 Support하지만, 수정을 할 수 없는 Windows등의 Proprietary System의 가상화에는 적합하지 않다.
모의 가상화의 우위성은 “Performance”에 있다. Hipervivor와 연계하는 모의 가상화 Server는 가상화되고 있지 않은 Server와 거의 동등한 성능을 발휘한다. Micro Soft와 VMware가 각각 자사제품을 보완하기 위해 모의 가상화기술에 힘을 쏟고 있는 상황을 보면, 그것이 충분히 매력적인 기술이라는 것을 알려주는 것이다.

 

OS Level의 가상화 (OS Level Virtualization)
OS Level의 가상화로는 문자그 의미대로 OS(Host OS)의 기능에 의해 가상화를 실현하는 Architecture가 있다. Hipervivor Layer는 존재하지 않고, Host OS가 스스로 H/W Resource를 분할 하거나, 각 Server를 독립 운영시키거나 한다. 모든 가상 Server가 동일 OS상에서 가동하는 점이, 다른 가상화 기술과의 큰 차이(그러나, 각 Instance는 고유의 Application과 User Account를 보유함)이다.
이 Architecture의 결점은 “유연성”이 결여되어 있는 것이지만, 그 반면 “Native Speed 향상이 가능하다”라는 이점도 있다. 또, 모든 가상 Server에 단일 표준의 OS가 적용되어지기 때문에, 다른 환경에 비해서 관리가 용이하다는 점도 Merit로 여겨진다.

CPU의 가상화 대응
Main Frame과는 다르게 PC의 H/W는 원래 가상화를 고려하여 설계되었다고 말 할 수 없다. 그로인해 최근까지 부하는 모든 S/W에 걸리지만, AMD와 Intel이 최신세대 Processor에서 처음으로 CPU Level에의 가상화를 Support하기 시작한 걸로 인해, 상황은 크게 바뀌려고 하고 있다.
더불어, AMD와 Intel의 Technology는 동일한 Merit를 가지고 있지만, 불행하게도 Code의 호환성은 없다.
그렇다하더라고, H/W Level의 가상화 Support로 인해, 가상 Server로부터 I/O Channel이나 H/W Resource로의 Access관리는 H/W측에서 행해지게 되고, Hipervivor가 부담해 오던 관리부하는 상당히 경감되었다. 또, OS(Windows를 포함)에 관여하지 않고도, 모의 가상화 환경으로 가동시킬 수 있게 되었다.
더욱이, CPU Level의 가상화 환경을 실현하기 위해서는 가상화 S/W를 다시 만들어야 하는 절차가 필요하다고 한다. 그러면서도, 이 기술이 가져다 주는 Merit는 그 부분을 고려하고도 남을 정도로 크기 때문에, 결국 이런 저런 종류의 가상화 S/W가 이 기술을 Support하게 될 것이다.

각각의 기술의 비교
지금까지 소개했던 가상화 방법 중 어느것을 채용할지는 각각의 기업(Data Center)이 놓여있는 상황에 따라 다를 것이다. 예로, 단일 OS Platform을 기반으로 하는 Server군의 경우에는 OS Level의 가상화로 통합하는 방법이 적합하다고 말 할 수 있다.
한편, 모의 가상화 방법을 채용하면 – 특히 가상화에 대응하는 Processor와의 연계가 완성되어 있는 경우에는 – 높은 성능을 유지하면서, 다른 종류의 Guest OS System 환경이 구축가능한 Merit를 흡수하는 것이 가능하다.
또, 완전 가상화는 3가지의 가상화 방법 중 성능면에서는 가장 떨어지지만, Guest OS간의 완전한 독립성을 유지할 수 있는 Merit를 가진다. 많은(종류의) Guest OS를 Support하고 싶을 때, 소위 S/W 품질보증이나 Test를 행하고 싶을 때에는 이 방법이 적합하다고 할 수 있다.
완전 가상화 Solution은 그 외에도 여러가지 특징이 있다. 예로, 가상 Server의 특정시점에서의 상태 정보를 취득하고, 보존해 두는 “Snapshot”기능을 이용하면, 여지껏 간단하게 장애복구 대책을 실시 할 수 있다. 또, 최근에 이 기능을 활요하여, 자사제품의 평가판을 Pre-Package화한 가상 Server Image로서 Download 제공하고 있는 S/W 기업도 증가하고 있다.
그렇다하더라도, 가상화 기술/Architecture를 막론하고, 가상 Server에는 물리 Server라는 지금까지와 같은, 계속적인 Support와 Maintenance를 필요로 한다. 이미, 기존의 IT환경으로부터 효율적인 Cost 효과에 우수한 가상화 환경으로의 이행을 간단하게 행하기 위한 Tool을 시작, 여러가지 가상 Server 용 관리제품이 시장에 투입되고 있기 때문에, 그것들을 활용하면서 보다 좋은 가상화 환경의 실현 해 나갈 수 있다.

 

※ 위 글은 아래의 링크의 기사를 번역한 글입니다. 다소 오역이 있을 수 있습니다.

http://www.computerworld.jp/topics/vt/59310-1.html