오픈 스택의 Nova는 가상 머신 라이프 사이클 관리자로서, 아마존 EC2와 동일한 역할을 한다. https://github.com/openstack/nova

(초창기에는 Nova가 오픈스택의 전부였다고 한다....)

즉 서버 가상화를 수행할 수 있다. 

초기의 Nova는 오픈 스택의 핵심이었다고 한다. Nova가 서버, 네트워크, 볼륨을 모두 관리하다가 Nova 볼륨은 Cinder로 Nova 네트워크는 Neutron으로 프로젝트가 분리되었다. 

데이터독의 Nova 아키텍처는 간단하다. 

이미지 출처 : https://datadog-prod.imgix.net/img/blog/openstack-monitoring-nova/nova-high-level-3.png?fit=max

좀 더 좋은 이미지를 살펴봤다. 예전 오픈 스택에는 다음과 같은 아키텍처 그림이 있었다고 하나. 지금은 오픈 스택 싸이트에서는 보이지 않는다.

내부는 RabbitMQ를 사용하고 있다. 

이미지 출처 : http://cloudn1n3.blogspot.kr/2014/11/openstack-series-part-4-nova-compute.html

공식문서(openstack.org)의 아키텍처는 다음과 같다. 

• DB: 데이터 저장용 
• API: HTTP 요청을 받고 커맨드를 변환해 oslo.messaging 큐 또는 HTTP로 다른 컴포넌트와 통신한다.
• Scheduler: 인스턴스를 실행한다.
• Network: ip 포워딩, 브릿지, vlan을 관리한다.
• Compute: 하이퍼바이저와 가상 머신과의 통신을 관리한다. 
  
• Conductor: 코디네이션(빌드/리사이즈)가 필요하다라는 요청을 처리한다. 마치 데이터베이스 프록시처럼 동작한다.

Nova를 설명한 쉬운 자료.

Nova에 대한 자세한 내용은 아래 슬라이드를 보니 도움이 된다. 

Nova와 AMQP와의 연동 방법, 인스턴스가 만들어질 때까지의 동작 순서를 설명한다.

USER STORIES

KakaoTalk speaks volumes about the future of cloud services

But there are three key factors to the success of OpenStack. One is excellent people. If you let them get to work, you don’t have to worry about anything. Two is to be aligned with pre-existing computing resources (people call this ‘legacy’ but I don’t use this term, because to us, then, OpenStack is becoming legacy.) OpenStack resources follow the same rules / policy / authentication. We have a simple policy for all compute resources, this makes less developing work for the OpenStack cloud but it’s still a big job…The last one is collaboration. We don’t want to make another huge silo system that makes things worse and harder down the road. We are the experts on OpenStack, and we have to be. Other members in our infra team are also experts in their fields and we respect their knowledge, point-of-view and experiences. Without their help, the cloud doesn’t work.

http://superuser.openstack.org/articles/kakaotalk-speaks-volumes-about-the-future-of-cloud-services/

https://netdevconf.org/1.2/slides/oct7/09_andrew_kong_netdefconf_2016.pdf

2015 Tech Planet 자료 

(pdf)

http://readme.skplanet.com/wp-content/uploads/3-4-%EA%B3%B5%EC%9A%A9%EC%A4%80_Scalable-Network-for-the-Next-Generation-Resource-Scheduling1.pdf

(pdf)

http://www.krnet.or.kr/board/include/download.php?no=2121&db=dprogram&fileno=2 

오픈 스택 스토리지는 3가지 스토리지 타입이 있다. Nova, Cinder, Swift가 있다. 

자세한 비교표는 아래와 같다. 이 중 Nova는 Computing 역할을 한다. 

Cinder는 아마존의 Elastic Block Service(EBS)와 비교된다. 더 정확히 말하면 추상화 api라고 보면 된다.

    

화면은 다음과 같다.

출처 : https://cloudarchitectmusings.com/2013/11/18/laying-cinder-block-volumes-in-openstack-part-1-the-basics/

cinder의 각 컴포넌트 기능은 다음과 같다. 

• cinder-api – API 서버
• cinder-scheduler – 볼륨 요청을 적절한 볼륨 서비스로 스케쥴하고 보낸다. 기본 설정은 라운드 로빈이지만 Filter Scheduler를 복잡한 스케쥴을 할 수 있다.
• cinder-volume – 블럭 스토리지 디바이스를 관리한다.
• cinder-backup – 볼륨을 여러 백업 장치에 복사한다.

Nova와 어떻게 연동되는지 https://cloudarchitectmusings.com/2013/11/18/laying-cinder-block-volumes-in-openstack-part-1-the-basics/의 내용의 일부를 발번역했다. 

1. 볼륨은 cinder create 커맨드를 통해 생성된다. cinder create 커맨드는 논리 볼륨(LV)에 "cinder-volumes" 볼륨 그룹( VG)으로 생성한다.

2. 해당 볼륨은 nova volume-attach 커맨드를 통해 인스턴스에 붙는다. nova volumne-attach 커맨드는 컴퓨트 노드의 iSCSI IQN을 생성한다. 

3. 인스턴스를 실행하는 컴퓨터 노드는 이제 iSCSI 액티브 세션을 갖고 있고 새로운 로컬 스토리지를 얻는다.

4. Libvirt는 인스턴스에 대한 스토리지로 로컬 스토리를 사용한다. 인스턴스는 새로운 디스크를 얻었다. 보통 /dev/vdX디스크라 되어 있다.

다음은 슬라이드 자료이다. 

오픈 스택에 Kolla라는 프로젝트가 있다. 배포 프로젝트라 할 수 있다. 

https://github.com/openstack/kolla

Kolla는 오픈 스택을 베어메탈 또는 가상장비에 배포할 수 있도록 Docker 컨터이너, ansible 플레이북을 제공(https://docs.openstack.org/kolla-ansible/latest/)하고 kubernetes위의 오픈 스택을 배포할 수 있는 kubernetes 템플릿(https://docs.openstack.org/kolla-kubernetes/latest/)을 제공한다.  즉 오픈 스택 커스터마이징 기능을 제공한다. 

ansible 관점으로 본 kolla 자료를 살펴볼 수 있다.

kolla는 zookeeper를 사용하는데, 즉 configure management가 되니. 오픈 스택의 운영 관점의 이슈를 해결할 수 있는 큰 장점으로 사용하고 있다.

아래 유투브를 보면 Kolla로 zero downtime을 진행했다고 하는 실례를 알 수 있다. 

ceph(http://ceph.com/)는 하나의 통합 시스템으로 object, block, file storage 인터페이스를 제공하는 분산 object store이다. 확장이 쉽고 SPOF가 없다. LPGL(https://github.com/ceph/ceph) 라이선스이다.

ceph 아키텍처는 다음과 같다. 

RADOS는 Reliable Autonomic Distributed Object Store의 약자이고 object storage이다.

RADOS 데몬은 크게 4가지로 나눈다. (위키 https://en.wikipedia.org/wiki/Ceph_(software))

* Cluster monitors (ceph-mon) that keep track of active and failed cluster nodes (모니터 - 3개)

* Metadata servers (ceph-mds) that store the metadata of inodes and directories (메타 정보)

* Object storage devices (ceph-osd) that actually store the content of files in a XFS file system. (실제 저장소)

* Representational state transfer (RESTful) gateways (ceph-rgw) that expose the object storage layer as an interface compatible with Amazon S3 or OpenStack Swift APIs (API 게이트 웨이)

RADOSGW는 게이트웨이를 의미하고 LIBRADOS를 통해  3rd 언어에서 쓸 수 있다. 

다음은 OSD와 MON, FS 간의 내부 구조이다. mon은 일반적으로 3개로 구축해서 문제를 감지하도록 한다.

ceph의 RBD(RADOS Block Devices)는 커널 모듈 또는 librbd 라이브러리를 사용해 ODS와 통신한다.

http://docs.ceph.com/docs/master/rbd/rbd/

다음 슬라이드를 보면 ceph의 내부 구조를 이해하는데 도움을 받는다. 

 Ceph 최적화 자료 - 성능 자료

(기존 스토리 대비..)

더 좋은 공부를 위해서 아래 내용 참조하면 좋은 것 같다. 

https://www.virtualtothecore.com/en/adventures-ceph-storage-part-1-introduction/

https://www.virtualtothecore.com/en/adventures-ceph-storage-part-2-architecture-dummies/

https://www.virtualtothecore.com/en/adventures-ceph-storage-part-3-design-nodes/

https://www.virtualtothecore.com/en/adventures-ceph-storage-part-4-deploy-the-nodes-in-the-lab/

https://www.virtualtothecore.com/en/adventures-with-ceph-storage-part-5-install-ceph-in-the-lab/

https://www.virtualtothecore.com/en/adventures-with-ceph-storage-part-6-mount-ceph-as-a-block-device-on-linux-machines/

https://www.virtualtothecore.com/en/adventures-with-ceph-storage-part-7-add-a-node-and-expand-the-cluster-storage/

https://www.virtualtothecore.com/en/adventures-with-ceph-storage-part-8-veeam-clustered-repository/

https://www.virtualtothecore.com/en/adventures-with-ceph-storage-part-9-failover-scenarios-during-veeam-backups/

https://www.virtualtothecore.com/en/my-adventures-with-ceph-storage-part-10-upgrade-the-cluster/

가상화 아키텍처는 크게 두가지, 호스트형 가상화(type2)와 베어메탈 가상화(type1)로 분류된다. 호스트형 가상화는 호스트 운영체제가 있고 그 위에 VM을 올리는 구조이지만 베어메탈 가상화는 어떤 소프트웨어도 설치하지 않은 채 하드웨어 상에서 하이퍼바지어가 설치되고 이 위에 가상 머신을 구현한다. 

출처 : http://www.ni.com/white-paper/9629/en/

장비가 아닌 스위치를 기반의 가상화가 진행되고 있는 베어메탈 스위치가 나타나게 되었다고 한다. 스위치를 가상화하는 SDN(Software Defined Network)기술이 나타나기 시작했다. 가격도 싸고 클라우드 환경에 맞는 네트워크 스위치를 소프트웨어로 콘트롤할 수 있게 되었다.

017 

오픈 스택 2컨퍼런스에서 SDN,NFV를 보고 너무 생소해서 교양 차원에서 copy&paste .. 끄적끄적 정리했다.

이미 ETSI 표준도 존재한다.

http://www.cctvnews.co.kr/news/articleView.html?idxno=49643

이를 기반으로 spteck(구 - 이노에이스)에서 오픈 스택 적용 사례를 발표했다. 개인적으로 관심이 생기게 되었다..

오늘 큐브 스프레이라는 것을 알게 되었다. 

기존에는 Kargo라는 이름이었다. https://github.com/kubernetes-incubator/kargo 로 가면 Kubespary github 페이지로 이동한다. 

큐브스프레이(kubespray)는 Kubernetes를 설치할 수 있는 ansible 묶음이다.

https://github.com/kubernetes-incubator/kubespray

관련 동영상이다. 

좋은 참조 자료이다.

http://qiita.com/albatross/items/7f472a973d0c04041a4d