# Openstack 아키텍쳐

---------------

1. Openstack concept diagram : API 호출 관계 에 따른 구성도

- 모든 API 는 Keystone 을 통해 인증 이후 각 service 를 호출한다 

   (단, swift 인증은 거쳐도 되고 자체 인증으로 처리해도 된다)

- 이 구성을 하기 위한 설치 순서는

- Keystone

- Swift : Glance 가 저장할 img 파일 저장 용도

- Glance : Nova 에서 사용할 VM 이미지의 profile 보유

- Nova, Cinder, Newtron

- Ceilometer : 각 service 에 대한 미터링

- Horizon

- Heat

2. Openstack logical diagram : concept diagram 보다 밑단의 구성도

- nova, cinder 는 각각 오래 걸리는 API 호출로, message queue 서비스를 이용하여 처리한다

- 두 서비스의 flow 및 구성이 비슷하다

- 각 service 는 각자의 정보를 저장하는 database 를 보유하고 있으며, 

   keystone 과 통신할 때 인가 정보(policy backend 를 가지고 있다)

- horizon 에서 제공하는 서비스가 openstack 의 전체 기능은 아니다

   각 서비스에 대한 미구현한 API 기능이 있을 수 있다

3. Openstack 을 이용한 cloud 아키텍쳐 설계

- 사용 목적을 고려하여 tenant의 수와 각각의 역할, 필요한 service(nova, swift, cinder ... ) 을 생각한다

- 주요 아키텍쳐 방향

- 약결합 시스템(Loosely Coupled System) 으로 각각의 service 를 선택, 추가 하기 용이하다

- 필요한 service 를 선택할 수 있다 == 모든 service 를 반드시 설치해야 하는 것은 아니다

- backend service 를 선택할 수 있는 폭이 넓다

- keystone 이 필요한 RDB 는 mariaDB, MySQL 선택이 자유롭다

- keystone 이 필요한 memory DB는 memcachedDB, redis 선택이 자유롭다

- 환경의 제약이 없다

- 멀티 리전으로 구성하고자 한다면 keystone 을 따로 node 로 구성해야 한다

- 리전별로 service end point 가 다를수 있기 때문이다

4. Openstack 아키텍쳐 모델 sample

- 2 nodes : 컨트롤 node(nova-compute, nova-스케쥴러 포함) + 컴퓨트 node (+ 네트워크 node : 생략가능)

- 3 node : 컨트롤 node + 네트워크 node (NSX, ovs) + 컴퓨트 nodes 

         

# Openstack 주요 서비스 2

---------------

1. quantum == network service

    - VM (nova 가 생성한 instance) 에 networking 을 제공하는 서비스

    - 이전에도 nova-network 모듈을 통해 flat network 은 구성이 가능하다(vLan)

    - multi level 네트워크 는 안된다 (router, load balancer)

    - 주요 기능

    - overlayer L2 API 지원 : vxlan(NSX), gre(OVS)

    - router API 지원

    - load balancer API 지원

    - flow :

    - api > newtron API > newtron plugin > NSX, OVS, 기타 가상화 스위치

2. Neutron == network service, https://wiki.openstack.org/wiki/Neutron

    - quantum 프로젝트의 이름 소송 문제로 프로젝트 이름을 바꿈

    - package 는 q 로 시작한다 (nova 와 헷갈리는 것을 방지 하기 위해서)

    - 구성

    - server

    - Queue

    - ML2 (The Modular Layer 2) : plugin 의 표준화

    - agent <-> provider

    - type driver : The ml2 plugin currently includes drivers for the local, flat, vlan, gre and vxlan network types

    - mechanism driver : The interface currently supports the creation, update, and deletion of network and port resources

    - database

    - 3node 기본 구성

         http://naleejang.tistory.com/107

3. cinder == block storage service

    - VM 에 외부 volume 을 제공해주는 서비스, https://wiki.openstack.org/wiki/Cinder

    - VM 과 독립적인 life cycle 을 가진다 (VM 에 별도로 attach, detach 한다)

    - 블럭 스토리지 란?

- 블럭 단위로 저장하는 저장소 (iSCSI (openstack의 defualt), FC ...)

    - VM 에 attach 하거나 detach 할수 있다 (VM 에 대한 하드디스크)

    - detach 조건은 mount 되지 않은 상태 일때

    - cinder 이전에는?

    - Diablo 버전에서 nova api 의 extension (nova-volume api)으로 시작함 > cinder 등장 이후 nova volume api deprecated 됨

    - Cinder hypervisor support matrix

    - 가상화 지원하는 업체별로 기능을 지원해주는 정도에 차이가 있다

    - https://wiki.openstack.org/wiki/CinderSupportMatrix

    - 호리즌 메뉴에서는 nova > volume 에서 동작한다

- 빈 volume 으로 생성 하거나 img 포함한 볼륨(glance에서 받아온다)

4. Heat == orchestration service

    - 쉽게 인프라를 배포할 수 있도록 지원하는 템플릿 기반 서비스(가장 마지막 설치), https://wiki.openstack.org/wiki/Heat

    - flavor 란 : VM 의 profile (CPU, Memory, Disk 를 규격화 한 템플릿)

    - 오케스트레이션에서 사용되는 템플릿 언어는 인프라뿐만 아니라 서비스 및 응용 프로그램의 전체 프로비저닝을 자동화하고, 컴퓨팅, 스토리지 및 네트워킹 구성뿐만 아니라 배포 후 작업을 지정할 수 있다

    - Heat 컴포넌트

   - Heat-api : RPC Heat 엔진에 전송하여 요청된 API를 처리하는 REST API 를 제공

        - Heat-api-cfn : backend 서비스(AWS CloudFormation, etc) API 를 호환

        - Heat-engine : 템플릿을 생성하고, 주 작업을 수행

5. Ceilometer == telemetry service

    - 자원의 사용량 및 성능을 측정하여 사용자가 자원의 상태를 모니터링 할 수 있는 기능, https://wiki.openstack.org/wiki/Telemetry

    - 사용자에게 Openstack 에서 생기는 모든 task 에 대한 logging , 퍼포먼스 정보를 전달

    - flow

   - ceilometer-agent-compute : 각각의 컴퓨팅 노드에 설치되어 실행되며, 자원 활용 통계로 사용됩니다.

        - ceilometer-agent-central :

    - 중앙 관리 서버에서 실행

         - 인스턴스에 연결되지 않은 자원이나 컴퓨트 노드에 대한 활용 가능 자원 통계를 폴링

             - ceilometer-collector : 

    - 중앙 관리 서버에서 실행

    - 메시지 큐(에이전트에서 오는 미터링 데이터에 대한 알림)를 모니터링

        - ceilometer-alarm-notifier : 하나 이상의 중앙 관리 서버에서 실행되며, 샘플 수집을 위한 임계 값의 평가에 따라 알람을 설정

   - 데이터 저장소 : 데이터베이스 동시 처리능력을 읽고 저장

        - ceilometer-api : 하나 이상의 중앙 관리 서버에서 실행되며 데이터 저장소로부터의 데이터 액세스를 제공

6. Trove == database service

    - 관계형 데이터베이스의 기능을 활용 할 수 있도록 지원

    - flow

    - Python-troveclient : 커맨드 라인 방식의 Trove API를 실행

    - Trove-api : RESTful방식의 JSON을 지원, Trove 인스턴스 관리 및 프로비저닝

    - Trove-conductor : 호스트에서 실행되는 서비스로 호스트의 정보를 업데이트할 경우 게스트 인스턴스 메시지를 수신

    - Trove-taskmanager : 인스턴스 관련 task 관리 (프로비저닝, lifecycle, etc)

    - Trove-guestagent : 게스트 인스턴스 내에서 실행, 데이터베이스 작업을 실행 및 관리

참고

http://naleejang.tistory.com/110

# Openstack 주요 서비스 1

---------------

0. Openstack 의 설치가 서비스간의 의존도를 파악하면 순서를 파악하기 용이하다

- keystone > glance > nova > ... >horizon

- swift 는 별도이다 (swift 는 원래 인증절차를 가지고 있었다 + keystone 인증도 가능하도록 지원한다)

1. nova == compute service

- NASA 의 compute 프로젝트로 시작

- flow

- Client API call > ... >  메시지 큐 > nova-스케쥴러 > internal 통신(RPC) > nova-compute > hypervisor(ESXi, KVM, Hyper-V, etc)

- 동작이 오래 걸릴 수 있기 때문에 Client 에게 미리 response 를 보낸 후, 메시지 큐를 이용한다

- nova-compute 1 : 1 hypervisor

- HTTPS:443 -> vCenter

- XCP -> Xen server

- libvirt Driver (하이퍼바이저 를 wraping 한다) -> KVM, Virtual Box, (Ironic, 물리머신 Juno 이후에 지원함)

- 기타 support 하는 hypervisor 정보 :  

 - https://wiki.openstack.org/wiki/HypervisorSupportMatrix

              - 지원하는 기능에 따라서 그룹 A/B/C 로 나뉜다

- nova-network 모듈 : newtron service 없이도 flat network 은 구성이 가능하다 (vLan)

- nova-database 모듈: instance 정보, request정보 들을 관리한다

2. swift == object storage service

- Rackspace 의 프로젝트로 시작

- 4개의 내부 모듈로 구성

- swift proxy : API 통신

- container : 파일을 저장하기 위한 필수 layer

- account : 자체 user (glance 등과 통신에 필요한) 및 object 에 대한 권한 부여를 위한 user 정보 layer

- object : 실제 파일이 저장되는 layer

- 특징

- 표준 범용 하드웨어 규격으로 설치할 수 있도록 설계됨

- 언제든지 망가질수 있다 == 데이터 관리의 중요성(default 3 replica) 홀수개의 replica 유지

- 높은 확장성

- 대용량 object storage 로 저장하는 것만큼 파일의 위치를 저장, 기억하는 것도 중요함 : hashing 기술

- 알파벳 순 정렬 : 중간추가, 정리가 어렵다 대용량에 맞지 않는 방법이다

- 카테고리화 : hashing (space to space 맵핑)

3. glance == VM Image Manager

- nova 에서 사용할 boot disk image

- end user 가 정할 수 없다

- 보동 image 의 size 는 수십 MB ~ 수십 GB

- vmdk, iso, vdi ...

- FTP 와 원리가 비슷하다

- FTP : 21(meta),22(data) port 를 쓴다

- glance : 2개의 end point URL 이 있다 (image meta), (image data)

- image data 저장소로 swift(최근 default) 로 쓰는 경우가 많다

4. keystone == identity service 사용자 인증 서비스

- 주요 기능 : 유저 인증을 통한 token 발급, end point 카탈로그를 보여준다

- service catalog > 리전에 dependancy 를 가진다

- public URL : end user 에게 보여주는 용

- internal URL : 내부 모듈 에게 제공하는 용

- admin URL : 관리 용

- 4 개의 backend service 를 가지고 있다

- identuty, catalog, token backend : keystone 내부 모듈로, 위 flow 로 기능 참조

- policy backend 의 경우, 각 service 에 존재하며 (keystone 에 존재하지 않는다) 권한에 대한 정보를 가지고 있다

- 인증 authentication 사용자  < -- 비교 -- >  인가 authorization 권한

- CF > 보안 강도에 따른 보안 솔루션

5. horizon == Dashboard GUI 서비스

- 사용조건 : openstack 의 계정이 있어야 한다

- 약 1시간 단위로 갱신되는 session 정보를 가지고 있다 != keystone 인증과 다르다

- 아파치 웹서버를 사용하며, 파이썬장고 프레임웍으로 구현됨

0. OpenStack 을 배우기 위해 필요한 사전 지식

- linux networking

- shell scripting

- virtualization concepts (QEMU/KVM/Xen)

- Python

- Mysql or other relational database

- MessageQueue service

1. Openstack 이란

- Openstack 은 IaaS 형태의 클라우드 컴퓨팅 오픈 소스 프로젝트

- Cloud mgmt platform that supports "API"

- virtualization 과는 layer 다르다

- client -> API -> Openstack -> libvirt -> VMware / KVM / Hyper-V

- virtualization 목적 : 물리적인 resource 를 숨긴다

- cloud 목적 : 가상화 자원을 활용한다

- Apache license 프로젝트로 개발한 code 에 대해 공개할 필요가 없다

- GPL license 의 경우, 사용은 free 지만 이를 사용하는 code 역시 free 가 된다

2. Openstack history

- Austin

- nova[compute service]

- swift[object storage service]

- ------------------ nova : glance 없이 동작 할수 있다/없다 ------------------

- Bexar, Cactus, Diablo

- glance[VM Image Manager] : nova 에서 사용할 boot disk image

- ------------------ 인증 서비스가 생기면서 기존 api 를 모두 deprecated 했다 ------------------

- Essex

- keystone[identity service] : 사용자 인증 서비스

- horizon[Dashboard] : Dashboard GUI 서비스

- ------------------ nova 프로젝트에서 네트워크 layer 가 분리되었다 ------------------

- Folsom, Grizzly

- quantum[network service]

- cinder[block storage service]

- Havana, Icehouse

- quantum[network service] --> Neutron[network service]

- Heat[orchestration service] : 쉽게 인프라를 배포할 수 있도록 지원하는 템플릿 기능을 지원

- Ceilometer[telemetry service] : 미터링 및 모니터링 기능

- ------------------ swift 의 provider 가 추가되었다 ------------------

- Juno

- ------------------ nova 가 지원하는 hypervisor 가 변했다 ------------------

- Kilo

3. 참고

- openstack 홈페이지 http://www.openstack.org/

- openstack 문서 http://docs.openstack.org/

- 코드 개발 및 관리 https://launchpad.net/openstack

- 코드 다운로드 http://git.openstack.org/cgit

- 공식교육교재 http://docs.openstack.org/icehouse/training-guides/content/

# cloud computing

-------

1. 위키디피아 정의 : 인터넷 기반(cloud)의 컴퓨팅(computing) 기술  

2. NIST 에서 cloud computing 에 대해서 간략하게 정리한 개념

- http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

- Essential Characteristics: 반드시 있어야 하는 특징

- On-demand self-service : 누구의 부탁없이 스스로 필요한 것을 조달하여 사용해야 한다

- Broad network access : 네트워크 접속이 있어야 한다

- Resource pooling : 리소스에 대한 할당과 회수가 이루어저야 한다

- Rapid elasticity : 탄력적인 운영이 필요하다 자원의 확장, 감축이 자유로워야 한다

- 비지니스에 큰 도움이 된다. 기존 인프라 환경은 급변하는 비지니스 모델을 맞추기 어렵다

- Measured service : 모니터링 및 미터링이 필수적이다 (tracking, logging 도구)

- Service Models:

- Software as a Service (SaaS)

- Platform as a Service (PaaS)

- Infrastructure as a Service (IaaS)

- Deployment Models:

- Private cloud : 특정 기업, 사용자에 한해 cloud 제공

- Community cloud : ??

- Public cloud : AWS 과 같이 모두에게 제공되는 cloud

- Hybrid cloud : Public 보다 Private 에 가깝다  

3. cloud 에 어울리는 서비스

- scale up : 

- 종적 증설

- 사양, 스펙 에 대한 업그레이드 가 필요한 서비스

- L4 router, DB 서비스

- scale out :

- 횡적 증설

- server 댓수 증가 가 필요한 서비스

- web server, 임시적 서비스, 테스트 서비스

1. 5 Types of Migration

- cold : VM power off 상태에서의 마이그레이션

- suspended : VM stop process == VM의 CPU, memory data 는 살아있는 상태에서의 마이그레이션

- vMotion : VM runnging 상태에서의 Live migration

- storage vMotion : VM runnging 상태에서의 storage 영역의 마이그레이션

            - data mover : DataStore 간 데이터를 copy 한다

            - data mover > Mirror Driver : VM 의 어떤 data 를 copy 했는지 알려준다

            - Mirror Driver > data mover : VM 의 어떤 data 를 copy 하여 되는지 알려준다

                . 변경된 데이터 역시 다시 옮기게끔 한다

            - 100 % 데이터 마이그레이션이 종료되어야 새로운 데이터스토어를 보게끔 ESXi 가 VM 과 데이터스토어 사이에 새로이 process 를 띄운다

- cross-host vMotion = storage vMotion + vMotion

. vMotion after storage vMotion

2. vMotion : migration VM to other ESXi == Live migration

- 조건 Pre-requirement

0. 하나의 data center 에서 마이그레이션이 이루어져야 한다

. DC : 물리적으로 하나의 지역이라는 의미가 아니라 Logical 하게 하나의 지역을 뜻함

150 ms / rtt 이상 걸리면 안된다

1. shared storage 가 있어야 한다

Fibre Channel SAN(Storage Area Network) OR iSCSI 및 NAS

2. VMkernel port group for vMotion 이 있어야 한다

3. same port group & same PG configuration

4. same CPU Architecture

5. 옮겨가려는 ESXi 에 충분한 memory 가 있어야 한다

- vMotion 실행되는 이유

- resource 부족

- ESXi crush 나 down

- 특징

- vMotion traffic 이 발생한다

- vMotion 중에도 application 은 동직할 수 있다

3. 3 가지의 failure 시나리오

- ESXi failure ( Master ESXi  -- heardbeat --- Slave ESXi )

            - vm 도 죽는다 >> 다른 ESXi 에서 생성해야 한다

            - shared storage 가 필요하다

- VM failure ( ESXi -- heardbeat --- VM )

    - FDM (Fault Domain Manager) 을 통해 vm 을 모니터링 한다

            - vm hang : 마우스 안움직이고, reboot 도 안된다 == stop all process

                . over utilized

                . os crush or fail

            - ESXi 가 user 동작없이 reset 을 시도한다????

- Application failure ( VM --- how to monitor --- app )

            - AppHA : vmware

            - Hypric : third party library

4. HA (High Availability)

- minimum down time을 지향하기 위한 방법

- HA 구성 순서

1. create Cluster

2. add ESXi

- 내부적으로 3가지 동작이 일어난다

. HA preparation happens

. vCenter 에 의해 HA Agent on ESXi(FDM aka Fault Domain Manager) 설치한다

. Election 을 통해 Master 와 Slave 가 결정된다 

 : lexical 투표방식은 ESXi에 랜덤으로 숫자를 부여하여 처음엔 큰 수 제외, 다음엔 큰 수 선택

3. setting Cluster Options > vSphere HA

- Enable Host Monitoring : ESXi 가 VM 의 상태를 확인하기 위한 옵션

- Admission Control : failure 한 VM 을 동작하기 위해 resource 를 guest VM 에 reserve (not allocate) 해주느냐 마느냐 선택

- specify failover hosts : dedicate 한 서버를 구축하여 HA 를 구성한다

- percentage of cluster resource : cluster 의 남은 reserved resource 의 대한 % 로 계산

- host failovers the cluster tolerates

- VM Options : 

- VM restart priority

- Host Isolation Response (leave powerd on(mgmt 에만 문제가 있을때) / Power off / Shutdown(안전한 방법))

※ Isolation 를 판단하는 방법 : (network 통신을 하지 못하는 경우)

ㄴ 인근 ESXi 로 부터 heardbeat 를 못받는다

ㄴ election 을 시도하는데 못받아온다

ㄴ getway로 ping 을 테스트 한다

- VM Monitoring : VM only, VM and application

- EVC : Enhanced vMotion Compatibility (AMD or Intel)

5. DRS http://searchvmware.techtarget.com/definition/VMware-DRS

- distributed resource scheduler

- 2 가지 기능

1. initial placement

2. load balancing

- 3가지 options

1. manually > recommendation by DRS

2. partially automatic > (load balancering 은 오토로)

3. fully automatic