Tag: cloud


[번역] Comparing Network Virtualization Techniques Available in the Cloud

아틀란타 서밋에서 CloudScaling의 발표를 보다가 OpenContrail에 관심이 생겨 조사해봤는데, 그들의 블로그에 클라우드 네트워킹을 이해하는데 아주 좋은 자료가 있어 번역해 봤습니다. 아주 어색하니 주의하시길..


클라우드 네트워크를 가상화하는 데 사용되는 기술은 빠르게 진화하고 있다. 서로 다른 기술의 다른 점을 알아내고, 그들의 접근 방법의 장점과 장점을 이해하는 것은 대게 사소한 일이 아니다.

여기서는 1) 레거시의 가상화된 환경에서 사용되는 네트워크 가상화 기술에 대해서 설명하고 2) 레거시와 클라우드 데이터 센터 간의 차이에 대해서 이야기하고 3) 클라우드 데이터 센터에서 사용되는 가상화 기술을 비교한다.

post_745_image1
Figure 1: Legacy Datacenter Network

그림 1은 서버 가상화를 실행하는 기존의 데이터 센터를 보여준다.

일반적으로 네트워크는 여러 L2 도메인으로 분할된다. 각각의 L2 도메인은 ToRs (Top of Rack) 집합으로 구성되고, 이것은 한 쌍의 Aggregation switch로 연결된다. 가상화된 서버는 ToR 스위치에 연결되어 있다. "End-of-Row" 스위치를 포함한 여러 변형도 있다. 하지만 근본적으로는 작고 잘 정의된 구간의 L2 도메인으로 분할이 된다. 이 디자인은 tree topology를 만든다. 따라서 각각의 노드는 기본적으로 심각한 over-subscribtion 상태에 놓이게 된다. 네트워크의 성능은 "capacity planning" 프로세스를 통하여 각 aggregation switch에 link, ports 등을 추가하여 관리된다. 대부분의 경우, 네트워크는 그들이 같은 아키텍처를 기반으로하는 경우에도, 데이터 센터의 다른 부분에서는 다르게 보인다.

post_745_image2 Figure 2: Network Virtualization in legacy Datacenters

그림 2는 네트워크 가상화가 어떻게 이러한 레거시 네트워크에서 구현되는지 보여준다. 일반적으로 Ethernet trunk(모두 또는 선택된 VLAN을 전송한다)는 ToR 스위치에서 각 가상 서버까지 연결된다. 서버 내에서 생성된 가상 머신은 하나 또는 그 이상의 VLAN에 연결된다. 그림에서 보는 것과 같이 VLAN의 구간(span)은 L2 도메인의 크기에 제한된다.

대부분의 경우 L2/ L3 aggregation switch에서는 하나의 라우팅 영역이 지원된다. 모든 VLAN 간 트래픽은 aggregation switch에서 라우팅된다. 패킷 필터 (ACLs, access control list)도 일반적으로 각 VLAN 인터페이스 포트에 있는 aggregation switch에서 적용이 된다.

post_745_image3 Figure 3: Multi-tenancy in legacy datacenter

멀티 테넌트간에 주소 공간의 중복(overlappng-ip)을 지원하는 시나리오를 사용하기 원하는 사람들은 VRF-lite(Virtual Routing Forwarding without MPLS) 또는 정식으로 MPLS와 같이 VRF를 사용하여 aggregation 계층에 각 테넌트를 위한 독립된 라우팅 공간을 만든다.

많은 경우 이 방법은 테넌트에 dedicated된 물리 방화벽과 로드밸런서 어플라이언스를 포함한다. 그림 3에서 보는 것처럼, 코어 계층은 테넌트를 여러 L2 도메인에 걸처 확장하기 위해 MPLS(LDP등 control plane 프로토콜과 같이) 활성화가 필요할 것이다.

post_745_image4 Figure 4: Basic Network Virtualization in Cloud Datacenters

많은 요즘 클라우드 데이터센터는 ToR 스위치에 L3(Routing)을 사용하여 만들어졌다. 이것은 원래 OSPF나 BGP 같은 L3 라우팅 프로토콜이 밀접하게 서로 맞물린 토폴로지(예, CLOS)를 쉽게 지원하고, 여러 비용이 동등한 경로로 flow를 분산하여 대칭적으로(균등하게) IP fabric의 효율적인 사용을 돕기 때문에 가능하다. 또한 IP 네트워크는 여러 데이터센터 및 기타 등등에 걸칠 수 있는 유비쿼터스(Ubiquity)의 특성 때문에 선택된다. 이러한 데이터센터에서는 L2 도메인이 부족하기 때문에 VLAN을 만드는 것은 아주 적합하지 않다. 따라서 VXLAN(또는 NVREG)와 같은 이더넷 프레임을 IP 네트워크를 통해 전송되는 IP 패킷으로 encapsulation하는 encapsulation 방법이 일부 채택되고 있다.

그림 4에서 각각 같은 색의 점선은 같은 L2 네트워크를 표시한다. 각 가상화된 서버에서 실행되는 soft switch(virtual swift)만이 일반적인 L2다. L2 LAN을 떠나가는 모든 트래픽은 가상 머신에서 실행되는 소프트웨어 라우터로 보내진다. 어떤 경우에는 가상 스위치에 LAN 간에 트래픽을 스위칭하는 기능이 있을 수 있다. 하지만 게이트웨이는 일반적으로 가상머신으로 실행되는 소프트웨어 라우터이다.

이러한 설정에서, 각각의 테넌트는 잠재적으로 게이트웨이로 동작하는 소프트웨어 라우터를 가진다. 그들은 필요한 용량에 따라서 추가 라우터를 얻는다. 라우터는 패킷 필터링, NAT(Network Address Translation)과 같은 정책을 구현한다.

post_745_image5 Figure 5: Multi-tenant Cloud Datacenters with advanced server based capabilities

그러나, 많은 소프트웨어 라우터를 운영의 복잡성을 방지 하는데 도움을 주는 기술이 있다.

그림 5는 가상화된 서버 내부의 각 소프트웨어 스위치들이 어떻게 switching, routing, inline packet en(de)capsulation을 실행하는지 보여준다. 따라서 각 가상화된 서버안에 있는 커널 모듈이 직접적으로 NAT, 패킷 필터링, 외부 접속을 수행하는 multiple-VRF 라우터처럼 동작합니다. 이러한 deployment에서는 많은 소프트웨어 라우터를 생성하면서 자연스럽게 따라오는 운영 이슈에 직면하지 않습니다.

post_745_image6
Figure 6: Virtual Services within multi-tenant cloud datacenters

그림 5에 설명된 기술을 활용한 deployment는 클라우드 데이터센터 안의 가상머신을 멀티 테넌트로 쉽게 추상화 할 수 있다. 각각의 테넌트는 네트워크간에 보안정책 안에서 여러 개의 가상 네트워크를 가질 수 있다. 이 테넌트는 또한 각 인스턴스 기반의 security group을 가지거나 가상 네트워크간에 필요하면 가상화된 서비스 인스턴스(예, virtual firewall, virtual DDos 방어기 등등)를 추가할 수 있다.

일반적으로 이러한 데이터센터는 외부 퍼블릭 네트워크에 게이트웨이로 동작할 IP en(de)capsulation 및 MBGP(multi-protocol BGP)를 지원하는 표준 라우터가 필요하다. 따라서 이 접근법에서는 라우터 안의 ASIC의 극한의 전송 능력이 활용된다.

이 접근법의 또 다른 장점은 게이트웨이 라우터의 동일한 세트를 통해 서비스 제공자 L3VPN 인프라와 쉽게 통합된다는 것이다.

post_745_image7 Figure 7: Multi-tenant multi-datacenter cloud network

그림 7은 네트워크 가상화 기술이 어떻게 여러 데이터센터 너머로 쉽게 멀티 테넌트 클라우드 인프라를 구성하는지 보여준다. 일반적으로 다른 데이터센터를 서로 연결하는 하부의 구성요소(underlying fabric)은 IP다. IP encapsulation을 사용하는 클라우드 가상화 기술은 쉽게 여러 데이터센터간에 확장할 수 있다.

모든 데이터 센터는 일반적인 라우터 게이트웨이를 사용하여, 외부 네트워크 또는 서비스 제공 업체 L3VPN 인프라에 액세스 할 수 있다.

결론

중요한 클라우드 서비스 제공 업체와 대형 엔터프라이즈 네트워크는 구식의 L2-L3 분리에 기반에서 네트워크 scaling에 인위적인 제약조건을 두지 않는 클라우드 네트워크 가상화 기술에 관심을 기울이고 있다. 그들은 멀티 데이터센터, scale-out 방식으로 대용량으로 운영되는 멀티 테넌트 L2-L3 지원하는 기술과 솔류션을 찾고있다. 그래서 이 기술은, 오픈소스화 되는 것 뿐만 아니라 프로토콜 통신(interaction)에서도 공개 표준에 기반을 두어 명확하게 설명되는 것이 필요하다.

흥미롭게도, OpenContrail과 같이 사용되는 이 기술(그림 5, 6, 7)은 이러한 요구사항중 많은 것에 만족된다. 시간은 Vendor/ Provider/ Enterprise가 자신의 전반적인 선택을 이끌어줄 어떤 전략적 기술을 선택할지 알려줄 것입니다.


원문: http://opencontrail.org/comparing-network-virtualization-techniques-available-in-the-cloud/


이 글을 읽고 막연하게만 생각했던 SDN이 어떤 것이고 어디서 필요한 것인지 감을 잡았고.. 앞으로 우리가 어떻게 네트워크 모델을 잡아야 하는지 길이 보이는군요.. ^^ 자 보이시나요?


NIST의 클라우드 컴퓨팅에 대한 정의(The NIST Definition of Cloud Computing)

[toc]클라우드 컴퓨팅에 대한 NIST의 정의(http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf)를 번역해 보았습니다. 역시 번역하고 보니 구글 번역이나 그게 그거인듯.... 어색하시면 원문 보세요~


클라우드 컴퓨팅은 언제 어디서든(ubiquitous), 간편하게, 요청에 의해서 최소한의 관리 노력과 최소한의 서비스 제공자와의 상호 작용에 의해 빨리 준비되고 배포되는 설정 가능한 공유 컴튜팅 자원(네트워크, 서버, 스토리지, 어플리케이션, 서비스) 풀에 네트워크 접근을 가능하게 하는 모델이다. 클라우드 모델은 다섯 가지의 핵심 특성과 세 가지의 서비스 모델 그리고 네 가지의 배포 모델로 구성된다.

핵심 특성(Essential Characteristics)

요청에 의한 스스로 서비스(On-demand self-service)

소비자는 필요에 의해서 각각의 서비스 제공자의 사람과 상호작용 없이 자동으로 서버 시간과 네트웍 스토리지 같은 컴퓨팅 능력을 독자적으로 준비할 수 있다.

광대역 네트워크 접근(Broad network access)

능력은 네트웍을 통해서 사용가능하고 기본 메커니즘으로 접근된다. 이러한 접근은 다양한 thin 또는  thick 클라이언트 플렛폼(모바일, 타블렛, 노트북, 워크스테이션)에서의 사용을 활성화 시킨다.

리소스 풀링(Resource pooling)

다수의 소비자에게 서비스되기 위해 풀링 되는 제공자의 컴퓨팅 리소스는 multi-tenant 모델을 사용한다. 다른 물리적 그리고 가상 리소스는 소비자의 요구에 의해 동적으로 할당(assign)되고 해지(reassign)된다. 여기에는 위치 독립적인 생각이 있어서, 고객은 일반적으로 서비스되는 리소스의 정확한 지역에 대한 조절이나 정보가 없다. 하지만 상위 레벨의 추상화(국가, 주, 데이터센터)에 의해서 지역을 지정할 수 있다. 리소스의 예는 스로리지, 프로세싱, 메모리, 네트워크 대역폭을 포함한다.

재빠른 민첩성(Rapid elasticity)

능력들은 민첩하게 제공되고 해지될 수 있다. 어떤 경우에는 자동으로 요청에 의해서 재빠르게 적합한  규모를 늘리고 줄일 수 있다. 소비자에게 이런 능력은 보통 제한이 없이 보이고, 언제든지 어떠한 양이라도 적절하게 제공되는 것으로 보인다.

측정되는 서비스(Measured service)

클라우드 시스템은 서비스(스토리지, 프로세싱, 대역폭, 활성 유저 계정) 타입에 따른 적당한 추상화 레벨에 대해서 계량 능력(metering capability)[1]에 사용되는 리소스의 사용을 자동으로 조절하고 최적화 한다. 리소스 사용은 모니터링, 조절, 보고되고 제공자와 사용자에게 서비스의 사용량이 투명하게 제공된다.

서비스 모델(Service Models):

서비스로의 소프트웨어(Software as a Service (SaaS)).

소비자에게 제공되는 능력은 클라우드 인프라[2]에서 동작되는 제공자의 어플리케이션을 사용하는 것이다. 어플리케이션은 웹 브라우저와 같은 thin client(예, 웹 기반 이메일) 뿐만 아니라 프로그램 인터페이스 등 다양한 클라이언트를 통하여 접근할 수 있다. 소비자는 클라우드 인프라 아래에 존재하는 네트워크, 서버, 운영체제, 스토리지, 심지어 각각의 각각의 어플리케이션의 능력들을 관리하거나 컨트럴 하지 않는다. 제한된 사용자 지정 어플리케이션 설정 변경은 가능하다.

서비스로서의 플렛폼(Platform as a Service (PaaS)).

소비자에게 제동되는 기능은 제공자에 의해서 지원되는 프래그래밍 언어, 라이브러리, 서비스 그리고 도구를 이용하여 사용자가 만들거나 이미 만들어진 어플리케이션을 확보하여 클라우드 인프라 위에 배포하는 것이다.[3] 소비자는 네크워크, 서버, 운영체제, 스토리지 같은 클라우드 인프라 아래에 있는 것을 관리하지 않는다. 그러나 배포된 어플리케이션을 어플리케이션이 호스팅되는 환경 설정에 대한 변경을 통하여 제어한다.

서비스로서의 인프라(Infrastructure as a Service (IaaS)).

소비자에게 제공되는 능력은 프로세싱, 스토리지, 네트워크 그리고 다른 기초적인 컴퓨팅 리소스의 공급이다. 소비자는 배포하고 운영체제와 애플리케이션을 포함한 임의적인 소프트웨어를 실행할 수 있다. 소비자는 클라우드 인프라 아래를 관리하거나 제어하지 않지만 운영체제 위의 스토리지와 배포된 어플리케이션은 컨트럴한다. 선택된 네트워킹 요소들에 대한 일부 제한한 컨트럴(예, 호스트 방화벽)이 가능하다.

배포 모델(Deployment Models):

프라이빗 클라우드(Private cloud)

클라우드 인프라는 여러 소비자로 구성된 하나의 기관(예, 하나의 부서)에 독점적인 사용을 위해서 제공된다. 그 기관 또는 제 3자 또는 그 조합(combination)에 의해서 소유, 관리, 운영되며, 해당 기관의 영업장 안에 위치할 수 있지만 아닐 수 있다.

커뮤니티 클라우드(Community cloud)

클라우드 인프라는 공동의 관심사(임무, 보안 요구 사항, 정책과 여려 준수 고려 사항)를 공유하는 특정 소비자 공동체의 독점적인 사용을 위해 제공된다. 공동체의 하나 또는 그 이상의  기관, 제 3자, 그 조합(combination)에 의해서 소유, 관리, 운영되며 해당 기관의 영업장 안에 위치할 수 있지만 아닐 수 있다.

퍼블릭 클라우드(Public cloud)

클라우드 인프라는 일반 대중을 대상으로 한 공개된 사용을 위해 제공된다. 비지니스, 아카데미 또는 정부기관 또는 그 조합에 의해서 소유, 관리, 운영되며 클라우드 제공자의 영업장에 위치한다.

하이브리드 클라우드(Hybrid cloud)

클라우드 인프라는 2개 또는 그 이상의 구별되는 클라우드 인프라(프라이빗, 커뮤니티, 퍼플릭)로 구성된다. 각각은 독립적인 개체로 유지되지만 데이터와 어플리케이션의 이동성(portability)(클라우드간의 로드발런싱으로 클라우드간의 경계를 넘어감)를 가능하게 하는 표준 또는 독점 기술(proprietary technology)로 같이 묶인다.

  1. [1]일반적을 사용에 따른 지불(pay-per-use)과 사용에 따른 요금(charge-per-use)으로 이루어진다.
  2. [2]클라우드 인프라는 클라우드 컴퓨팅의 다섯가지 핵심 특성을 가능케 하는 하드웨어와 소프트웨어의 집합이다. 클라우드 인프라는 물리 계층과 추상 계층을 동시에 포함하는 것으로 볼 수 있다. 물리계층은 클라우드 서비스를 제공하게 지원하는데 필요한, 일반적으로 서버, 스토리지 그리고 네트워크 콤포넌트를 포함하는 하드웨어 리소스로 구성된다. 추상계층은 물리 서버에 걸쳐서 설치되는 소프트웨어로 클라우드의 핵심 특성을 나타낸다. 개념적으로 추상계층은 물리계층 위에 위치한다.
  3. [3]이 능력은 필연적으로 프로그래밍 언어, 라이브러리, 서비스, 툴의 다른 출처에서의 호환성있는 사용을 불가능하게 한다.

클라우드… 들어가기 전에…

요즘엔 클라우드 관련 일을 하느라 정신이 없습니다. 정리도 하는 겸 몇자 적어보렵니다.

클라우드라고 하면 요즘은 일종의 패션인 것 같다. 그리고 이 단어 자체가 의미하는 것으 뭐랄까 여러 가지가 있어서 가끔 이야기하다가 헷갈린다. DropBox, Evernote, Daum 클라우드 등.. 이런 서비스형 클라우드가 있는가 하면 Amazon Web Service, RackSpace, uCloud Server등 컴퓨팅 클라우드 최근에는 빅데이터 관련에도 클라우드라는 말을 사용한다.

저는 이중에 컴퓨팅 클라우드와 관련된 일을 하고 있습니다. aws와 같은 public computing cloud service를 어떻게 하면 잘 그리고 효율적으로 만들 수 있을까를 고민하고 있습니다. 그리고 당연히 private computing cloud service도 고민하고 있죠.

따라서 이제부터 말하는 클라우드는 컴퓨팅 클라우드가 되겠습니다.

그럼 클라우드는 왜 필요한가 하면, 대표적인 서비스인 aws의 예를 들면 아마존은 원래 전자상거래 사이트입니다. 그래서 트래픽이 특히 몰리는 추수감서절 같은 때를 대비하여 컴퓨팅 자원을 많이 확보해 놓습니다. 당연히 대목을 잡아야지요. 대목에는 미리 준비한 자원을 이용해서 장사를 잘 했습니다.

그런데 대목이 끝나고 보니까 많이 준비해놓은 컴퓨팅 자원이 놀기 시작합니다. 실상 컴퓨터(대부분의 서버도)를 모니터링 해보면 컴퓨팅 자원을 완전히 다 쓰고 있지 않고 놀고 있는 자원이 많다는 것을 알 수 있습니다. 이게 아마존 사장의 눈에 뜨인 겁니다. 노는 자원을 어떻게 할용해 볼까 고민고민하다가 눈에 띄인게 가상화 기술이고, 이를 이용해서 노는 컴퓨팅 자원을 일반인에게 팔아보자, 서비스해 보자라는 것에서 시작한 것이죠.

즉, 컴퓨팅 자원을 효율적으로 사용하여, 불필요하게 낭비되는 비용을 줄이자가 컴퓨텅 클라우드의 시작이고, 지금도 가장 중요한 컴퓨팅 클라우드의 핵심입니다. 이런 관점에서 아래의 개념들이 나오는 것이지요.

  • 컴퓨팅 자원을 빌려쓰자: IP address, cpu, memory, disk, network....
  • 쓰는 만끔 지불한다: 시간 요금제
  • 사용이 끝나면 반납하자: 자원의 유연한 할당, elastic computing
  • 급하게 필요할 때는 빨리 빌리자: fast provisioning

여기서 가상화 기술이 아주 중요하게 나옵니다. 가상화 기술은 클라우드와 상관없이 60년대 부터 발전한 기술입니다. 하지만 위의 모든 것들을 아주 쉽게 가능하게 해주는 기술이 가상화죠. 컴퓨팅 자원들을 가상화 하지 않는다면 위의 것을 하기 위해서 사람이 엄청 열심히 일해야겠죠? 실제로 클라우드 초기에 호스팅 업체들의 주장중 하나가 "우리도 요청하면 하루 안에 사용 가능한 컴퓨팅 리소스를 제공한다. 그래서 우리도 클라우드다"라고 했었지요. 하지만 이를 이루기 위해서는 수만은 엔지니어가 고생하는 모습을 쉽게 상상할 수 있습니다.

따라서 아래의 개념이 따라옵니다.

  • 모든 것은 자동화된 시스템이 제공한다.

즉 클라우드에서는 사람이 하는 일이 없습니다. 물리적인 셋업과 기본적인 가상화 솔루션이 올라간 이후에는 사용자가 자원을 요청하면 모든 것이 솔루션에 의해서 자동으로 처리됩니다. 안그러면 클라우드가 아니죠~

가상화라면 생각되는게 물리 서버(서버라고 하면 물리 기계 뿐만 아니라 서비스와 혼동하여 물리 서버 또는 호스트란 용어를 사용합니다.) 하나에 여러 논리적인 호스트를 동시에 실행하는 것이니 당연히 생각하기에도 혼자 모든 호스트의 자원을 사용할 때 보다 성능이 당연히 떨어집니다. 게임 좋아하시는 분들은 에뮬레이터 상상하시면 되겠네요. 그래서 가상화된 서버(Virtual Machine, VM, 물리 서버에서 호스팅되는 호스트) 일반적으로 성능이 좋지 않습니다. 또한 물리 서버의 제약하에서 움직이기 때문에 무한정 CPU, 메모리를 늘려 성능을 올릴 수 없습니다. 그래서 클라우드는 scale-out을 지향합니다.

  • 작은 것들이 모여서 큰 일을 합니다: scale-out

구글이나 패이스북, 멀리 갈 것 없이 네이버, 다음처럼 대규모의 서비스를 하기 위해서 한대가 모든 것을 처리하지 않고 여러 서버들이 서로 힘을 합쳐서 처리하는 방식이죠. 십시일반으로 작은 VM들이 모여서 큰 규모의 처리를 합니다.

근데 또 생각해보면 작은 것들을 많이 모아서 하자니.. 미리 그 것들은 준비해 놓아야하고, 결국 요청이 없을 때는 이 가상머신이 또 노는 현상이 발생합니다. 이것은 클라우드의 효율적인 자원 활용에 맞지 않지요.

그래서 나오는 이야기들이 autoscaling입니다.

  • 자원이 더 필요 할 때만 scale-out 하자: autoscaling
  • 로드 밸런싱 좀 잘 해줘~: Elastic LB
  • 언제 자원이 더 필요 할 지는 모니터링이 필요하다: Amazon CloudWatch

여기까지 클라우드에서 설정을 해 놓으면 사용자 트래픽이 없을때는 최소한의 VM만 유지하다가, 트래픽이 늘어나면 자동으로 VM을 늘려가면서 트래픽을 처리하는 것이죠. 이 모든 것이 관리자의 판단이 없이 미리 설정된 값에 따라서 자동으로 진행됩니다.

이런 관점에서 보면 전통적인 시스템 관리자 입장에서는 뭔가 이전과는 다른 현상들이 일어납니다. 관리하는 VM이 점점 많아지고, 게다가 이 VM이 모두 동작상태가 아닌 대기 상태일 수 있습니다. 이러다 보니 서버들 간에 패키지나 설정들의 통일성이 없어질 가능성이 높아집니다. 관리자 입장에서는 여간 곤혹스럽지 않을 수 없습니다.

그래서 나온 것이 서버의 형상관리가 필요한 것이죠.

  • 서버들의 상태를 자동으로 동일하게 맞추자: chef, puppet

이러다 보니 서버 관리의 대부분을 자동화하는 툴이 하게 됩니다. 게다가 chef, puppet들은 개발자들이 사용하던 프로그래밍 방식을 사용하여 작업하게 됩니다. 기존 서버 관리자 입장에서는 전혀 하지 않던 개발을 운영을 위해 하게 됩니다.

  • DevOps: 개발과 운영은 같은거다. 운영도 개발의 일부다. 운영자도 개발해!
  • NoOps: 운영. 이제 필요없다.

실제로 클라우드를 관심있게 본 시스템 운영자들은 클라우드를 밥줄을 뺏어가는 녀석으로 인식하여 적대적으로 대하는 분도 봤고, 반대로 적극적으로 클라우드 업계로 뛰어든 분도 있습니다. ^^

또 다른 운영자 입장에서의 변화는, 이전까지는 물리 서버의 IP address는 그 물리 서버에 고정된 것으로 생각하고 작업을 해왔습니다. 그런데 클라우드 자체가 리소스를 빌려 쓰는 개념이다보니, VM에 할당된 public / private  ip address는 고정이 아니고 vm을 재시작, 정지, 이동(migration)하는 경우 변경될 수 있습니다.

클라우드에서 이에 대한 해법을 제시한 것이 다음과 같습니다.

  • VM에 고정된 public ip를 달란 말이다: ElasticIP

IP는 고정해서 뭔가 기본적인 요구는 해결되는 것 같은데, 호스팅 서비스처럼 나만의 서브넷을 구성하고 싶은 경우 등 전통적인 호스팅을 사용했을 때 사용했던 방법들을 사용하고 싶은 사람들이 있습니다. 클라우드는 클라우드 답게라지만, 클라우드가 해법을 제공하지 못하는 것도 많으니깐요.

  • 다 좋은데, 내 맘대로 하고 싶단 말이다. : Virtual Private Cloud

쓰다보니 어째 아마존의 서비스를 나열 한 것 같습니다. 맞습니다. 아마존이 가장 먼저 대중화 했고, 현재 가장 잘 나가고 있는 컴퓨팅 클라우드고 사실상의 표준이니까요. 저희도 열심히 고민고민 하면서 아마존 보다 더 좋은 구조를 내려고 했지만, 항상 결론은 아마존이 다 그렇게 한 이유가 있었고, 결국은 아마존 방식이 가장 효율적인 경우가 많았습니다. 현재는 아마존이 최강니깐요.

그리고 마지막으로 컴퓨팅 쪽은 가상화가 기술이 이제 성숙기에 접어든 상황이라 판단이 되는데, 아직 시작도 하지 못한 부분은 있습니다. 바로 라우터, 스위치로 대표되는 네트웍이죠

  • 서버만 가상화냐? 네트웍도 가상화하자! : Network Virtualization

현재 SDN(Software-defined network)라는 커다란 흐름 밑에 OpenVSwitch로 소프트웨어 적으로 컨트럴 가능한 스위치를 구성하고, OpenFlow를 이용하여 네트웍 자원은 중앙 집중 관리가 가능하게 하는 방향인 것 같습니다. OpenVSwitch는 리눅스 커널 3.3에 들어가 있고, XenServer 6.x에도 지원이 들어간다고 합니다. 아직은 성숙화 되지 않았지만, 아마 올해 말에는 본격적으로 네트웍 가상화가 화두가 될 것으로 생각하고 저희도 이 쪽에 연구를 계속할 겁니다.

원래는 글을 풀어가면서 Xen, XenServer, CloudStack, OpenStack, OpenVSwitch, OpenFlow 등으로 이어가려고 했는데, 엉뚱하게 클라우드에 대한 기본적인 설명과 용어만 나열하다 끝나네요.


클라우드 컴퓨팅의 장점

Naver Platform Day 2011을 훑어보다 정리합니다.

구체적으로 사용자 측면에서 클라우드 서비스의 장점

  • 자본 비용과 운용, 유지의 부담 없이 저렴하게 고기능의 정보 처리 기능을 이용할 수 있다.
  • 시스템 구축, 개발 기간이 단축되고 수요 변동에 유연하고 즉각적으로 대응할 수 있다.
  • 네트워크를 통해 협업, 데이터 수집, 제어가 용이하다.
  • 장비 분실 등에 따른 정보 유출 위험을 감소시킨다.
  • 클라우드 기반의 지속성에 의해 사업의 연속성이 향상된다.
  • 사용한 비용만 청구받고 지불하면 된다.

사업자 측면에서의 장점

  • 가상화, 분산 처리 기술을 활용함으로써 다양한 정보 처리 수요에 대해 자원을 효율적으로 제공할 수 있다.
  • 애플리케이션 표준화를 통해 소프트웨어 자원을 효율적으로 활용할 수 있다.
  • 서비스 자동화 및 지속성을 통해 운용, 보수, 갱신을 합리화할 수 있다
  • 다른 클라우드 서비스를 사업자 측에 결합해 저렴한 가격으로 다양한 서비스를 제공할 수 있다.
  • 사용자의 수와 상관없이 서비스를 공급할 수 있는 분산, 가상화의 특징이 있다.

결국 합리화, 최적화, 비용 절감!

쓸데없이 자원 관리하는데 노력을 들이지 말고 클라우드에 맞기고, 남는 시간에 당신의 비지니스에 집중하라~

클라우드 호스팅과 클라우드 IaaS의 차이는

  • on-demand self-service로 사용할 수 있느냐?
  • 사용랑 기반으로 과금하느냐?

  • Copyright © 1996-2010 Your wish is my command. All rights reserved.
    iDream theme by Templates Next | Powered by WordPress