CloudStack 2.2.x - Networking Model 분석

Cloud 2011. 10. 30. 06:00
from : http://redmine.nehome.net/redmine/projects/cloudstack/wiki/CloudStack_22x_-_Networking_Model_%EB%B6%84%EC%84%9D


CloudStack 2.2.x - Networking Model 분석 (1차)

Reference : 첨부파일

Account??? Guset???

  • Account???
    - i.g) 팀 조직.

- Virtual-Network 모드에서 RouteVM 단위. 즉 RouteVM을 포함해, 그 밑에 전체 Instance들이 존재. 또는 Direct-Network모드에서는 단순히 Instances 전체.
  • User (하기에 나오는 Guest도 같은 의미인듯 하나, 확실치는 않음).
    - i.g) 팀내 팀원.

- Virtual-Network이든 Direct-Network이든, 그 Account("팀")내에서 다시, 일부 VM들에 대해 권한을 가진 사용자.

Networking 모델 카테고리

  • Basic
    - use untagged VLAN (Not support Isolation)
  • Advanced-Virtual
    - Use VLANs for Isolation

- Use RouteVM

- VPN Available

- LoadBalancer Available

- 1:1 NAT Available

- Public IP Required

- Metering Available
  • Advanced-Direct
    - Use VLANs for Isolation

VLAN with Advanced Mode

3-type VLANs

  • Public VLAN
    - Public IP들을 위해 예약된 VLAN ID범위.

- Zone내의 모든 Pod들에 걸쳐 Trunking.

- RouteVM들에 개별적으로 할당되는 VLAN으로 예상.
(Zone VLAN에 이미 격리되어 있던Instance들에서 발생되는 패킷중 NAT되는 패킷에 대한 격리 모델인듯...)
  • Zone VLAN
    - Guest(Account)들의 가상네트워크를 위해 예약된 VLAN ID범위.

- Zone내의 모든 Pod들에 걸쳐 Trunking.

- Instances(VM)이 운영중인 Guest의 가상네트워크 마다 1개의 VLAN ID가 할당.
  • Direct VLAN
    - Direct(tagged) 네트워크를 위해 예약된 VLAN ID범위.

- VLAN 설정시 Scope에 따라 아래 2가지중 선택. (일반적으로 대부분 Zone-Wide가 권장됨.)

    1. Zone-Wide : 모든 Account가 이용 가능.

    2. Account-Specific : 하나의 Account만 이용 가능.

- Zone내의 모든 Pod들에 걸쳐 Trunking.

- 관리자가 필요시 제공.

- Zone-VLANs 처럼 관리를 위해, CloudStack에게 별도로 범위는 사전 부여하지 않음.

Physical-Host & Physical-Storage

  • Untagged & Private-Network 영역에 위치.
  • 각각의 Pod에 있는 Untagged & Private-Network는 Unique VLAN이어야 하고, L3 스위치에 존재하는(Routing가능한) IP 범위에 속해야 한다.

CloudStack VLAN 범위 예약 내역

  • VLAN ID는 4094(?)으로 제한된 자원.
  • 적절히 용도와 용량에 맞게 CloudStakc에서는 Network모델에 따라 적절한 범위를 권고함.
  • VLAN을 사용자하지 않는 Basic모드에서는 해당사항이 없고, 오직 Advanced-Virtual/Advanced-Direct에서만 해당.

VLAN for Advanced Virtual Networking

  • Zone 레벨에서 하나의 Guest에게 필요한 VLAN
    (다소 애매한 부분... Account아이디 단위로 하위의 모든 Guest User들을 통합해 하나의 VLAN이 할당되는 것인지, 아니면, 그 Guest User마다 또 개별적으로 VLAN을 부여하는 것인지는... 현재로서는 전자 내용으로 판단됨...)
VLAN IDs Use
< 500 관리목적으로 예약되어 있고, 개별 Pod들을 위한 Untagged & Private-Network 영역.
500 ~ 599 Public VLANs
600 ~ 999 Zone VLANs
> 1000 별도 예약

VLAN for Advanced Direct-Tagged Networking

  • Direct(Public IP가 Instance에 직접 할당)이므로 RouteVM존재가 없다. 당연히 Public VLAN 역시 필요 없다.
VLAN IDs Use
< 300 관리목적으로 예약되어 있고, 개별 Pod들을 위한 Untagged & Private-Network 영역.
300 ~ 499 Direct Attached VLANs
> 500 별도 예약(상기 Virtual-Networkin이용시 해당 VLAN영역이 포함.)

VLAN for Virtual Networking & Direct-Tagged Networking

  • 상기 두가지 모델의 혼합 형태이다. 즉, 둘다 하나의 Zone에서 혼용할때 VLAN영역 분할 권장 테이블.
  • VLAN 영역이 달라지지 않는다. 애초부터 혼합을 염두해고, 앞선 두 모델에서 서로의 영역을 벗어나 권장하고 있으므로...
  • 그냥 Advanced타입의 두 모델 Virtual Networking, Direct-Tagged Networking을 합친 것...
VLAN IDs Use
< 300 관리목적으로 예약되어 있고, 개별 Pod들을 위한 Untagged & Private-Network 영역.
300 ~ 499 Direct Attached VLANs
500 ~ 599 Public VLANs
600 ~ 999 Zone VLANs
> 1000 별도 예약

IP Address 할당 체계

  • 여러가지 방식의 IP 할당 체계 제공.
  • 어떤 방식 필요한지는, 어떤 Networking 모델(상기 3개 중..)이 사용중이냐에 따라 달라짐.

Public-IP

  • Advanced 모델(엄밀히 Virtual-Networking)에서는, 기본적으로 Account당 1개의 Public IP가 제공됨.
  • 이 Public-IP는 RouteVM이 가지고, 하부에서 사설IP(Guest-CIDR)를 가진 Instance들에 대한 NAT역할 수행.
  • 필요시, Guest(Account내의 User??)는, Public-IP를 추가/할당 할 수 있다.
  • 관리자는 사전에 Public IP 범위를 지정해 두어야 한다.
  • 프라이빗클라우드 환경하에서는, Public-IP로 RFC1918 address를 사용할 수도 있다.

Private-IP

  • Pod에 존재하는 Host들에 할당되는 IP. (관리용도의 접근만 가능하면 됨.)
  • 일반적으로 RFC1918 주소들이 사용됨.
  • Console-Proxy와 Secondary-Storage-VM들 역시, 이 Private-IP가 할당.(Pod들의 CIDR내에 위치.)
  • 관리자는 Pod내의 System(Host)들을 위해 사전에 준비/설정.
  • KVM/XenServer기반에서는, Pod당 요구되는 Private-IP들의 주소 개수는 호스트당 1개.
  • 즉 Pod당 Private-IP대역(서로 다른?? 같아도 되는지는..)이 필요하고, Pod내의 Host에는 1개씩의 IP가 소요됨.
  • Pod규모의 증설 상황을 고려해, 가능한 충분히 많은 여유 Pirvate-IP를 Pod마다 확보가 유리.
  • Advanced Virtual-Networking 모델에서, Private-IP들의 필요 개수는 해당 Pod내에서 구동되어지는 Hypervisor가 무엇이냐에 따라 달라진다.
    [on Advanced Virtual-Networking]

- KVM/XenServer의 경우, 이론적으로 65,000개 이상으로 IP Block으로 사용이 가능.(즉, 이론적으로는 1개의 Pod내에 65000개 이상의 Host구축이 가능하다는 의미로 보임.)

- 이와는 대조적으로 VMware ESXI의 경우, 특유의 지정된 Subneting구조로 인해, 하나의 Pod내에서 단지 255개의 Pirvate-IP만 제공된다.(VMware관련된 추가 내용은 문서 참조)

- 요약하자면, Pod의 규모는 시간이 지남에 따라 증가할텐데, 이에 맞춰 Host추가를 위한 충분한 IP할당이 가능한 것이 유리.

- i.g)이유는 Guest들의 Virtual Route(RouteVM)들의 적정한 분산이 필요하기 때문. 만일 어느시점부터 Pod내 Account가 증가하여 하나의 Host에 다수의 RouteVM이 배치될 수 밖에 없는 상황이 발생할 수도 있다.. 그렇게 되면???

Direct-IP

  • Basic 모드에서는, Pod의 CIDR범위 내의 IP가 Instance에 직접 할당.
  • 사전에 관리자에 의해 가용 Direct-IP 범위가 지정되어 있어야 한다.
  • Host의 Untagged VLAN과 같은 영역에 포함.
  • 즉, Instance와 Host는 동일 레벨의 IP를 사용하고 동일 VLAN에 속함.
  • Advanced 모델중, Direct-Tagged 모드에서는 VLAN-ID와 IP범위 그리고 Gateway가 정의되고, 그 이후, 임의의 IP가 Instance에 직접 할당.

Guest-IP (on Advanced Virtual-Networking)

  • Virtual-Networkin 모델하에서, Instance들에 할당되는 IP.
  • 관리자에 의해 사전에 [Global Configuration]에서 CIDR 지정/설정.
  • ClouStack에서는 보통 일반적으로, 10.0.0.0/24 를 사용함.
  • Account별로 동일 적용되는 IP. 즉, "A" Account내에서도 10.0.0.0/24내에서 VM들의 IP가 주어지고, 동일 Pod이더라도 "B" Account에서도 10.0.0.0/24내에서 VM들의 IP가 주어진다. 앞서 살펴 본대로 VLAN으로, 또 RouteVM내의 NAT/iptables으로 Isolation되므로 가능.
  • VM의 IP할당 주체는 RouteVM이다. (DHCP서버 기능 담당.)

Layer-3 Switch

  • 가용 Zone레벨에서 L3 스위치는 Core 스위칭 레이어.
  • L3 스위치는 하기와 같은 내용으로 미리 프로그램되어 있어야 한다.
    - Direct-Tagged 또는, Virtual-Networking 모델(혼용 모델 제외)이라면, L3 스위치는 Pod단위에서 Public-VLANs, Zone-VLANs, Direct-Attached-VLANs 에 대해 Trunk 설정.

- L3 스위치는 Untagged & Private-Network(Host와 SSVM, Console-Proxy)에 대한 Gateway기능을 담당하게 설정.

- 개별 Pirvate-IP 범위에 대한 분리된 VLAN은 L3 스위치에서 생성.

- (Note) Direct-Tagged & Virtual-Networking의 혼용 모델에서, VLAN은 본 내용과 아래 [Layer-2 Switch]섹션 내용을 참고해, L2/L3 스위치에서 적절히 설정해야 함.

Layer-2 Switch

  • L2스위치는 Pod내부에서의 Acceess switching 담당.
  • Pod내에 존재하는 모든 Computing(Host)들에 대해 Public-VLANs, Zone-VLANs, Direct-Attached-VLANs 에 대해 Trunk 설정.
  • Computing(Host)과 StorageVM(SSVM)을 포함한 Private-IP Networking을 위해 Untagged 트래픽에 대한 Switch 가능하도록 설정.
  • 앞서 이야기된 L3 스위치는 Private-IP Networking의 Gateway역할을 제공.

END

  • 첨부파일을 참조 해서 미천한 네트워크 지식으로 일단 요약 정리한 것이라, 오류나 잘못된 부분 댓글 피드백 바람....
저작자표시 비영리 변경금지

'Cloud' 카테고리의 다른 글

[Virtualization] PDF 서버 가상화 비용, 트렌드 등에 관한 전문가 개요 (Link)  (0) 2011.11.28
데스크톱 가상화 : VDI로 도약하기  (0) 2011.11.14
클라우드프론티어2011..............  (0) 2011.10.26
(낙서) 자체 전산실 구축에 비해 Cloud(클라우드)가 제공해줄 수 있는 가치는 뭘까.......  (1) 2011.04.04
CloudStack 2.2.2 Release -> 2.2.3  (0) 2011.03.17
Posted by 사랑줍는거지
,

티스토리툴바