OpenStack - 이론) Openstack 서비스

API 호출이 일어나는 경우

1. 사용자가 Horizon 대시보드를 통하거나 혹은 직접 컴포넌트에게 요청을 보낼 때

2. 일부 컴포넌트가 다른 컴포넌트에게 요청을 보낼 때

API 요청방법

- API요청을 보내기전에 인증이 필요

- API를 요청하는 사용자 또는 컴포넌트는 사전에 KeyStone API에 대한 EndPoint(URL)만 알고 있어야 한다.

1) 인증

 사용자 또는 컴포넌트는 API 요청을 보내기 전에 KeyStone으로부터 API동작에 대한 TOKEN을 구한다

2) 요청

 TOKEN을 획득하면 대상 API에 대한 EndPoint(URL)가 KeyStone에서 검색된다 

OpenStack 서비스

1. KeyStone - Identify

- Identity 서비스는 각 서비스에 대한 인증 서비스를 제공한다, 인증 서비스는 도메인, 프로젝트, 사용자 및 역할의 조합을 사용

- KeyStone은 역할에 근거하여 사용자들의 접근을 제어한다(RBAC)

- 컨트롤러 노드에 설치된다

- 가용성에 유의해야 함 때문에 KeyStone이 설치될 Controll Node를 보통 3개로 구성

- 인증외에도 사용자관리, 보안그룹관리, 각종서비스의 EndPoint URL(Rest API)을 관리하는 기능 제공

- 사용자(가상머신을 생성 운영하는 사용자)별로 키페어를 생성하여 데이터베이스에 저장

*RBAC(Role Based Access Control) 

- 역할에 근거하여 사용자들의 접근을 제어

KeyStone 구성요소

1. User

- 사람 또는 오픈스택 서비스를 이용하는 서비스(glance, nova) 를 의미

- User는 특정 프로젝트에 할당될 수 있다

- User의 이름은 한도메인 내에서 유일해야 한다

=> 즉 키스토는 이러한 사용자의 인증과, 요청을 처리한다

User 생성

- openstack user create nova --password test --project service

 => password는 test, project는 service로 "nova"라는 사용자를 만든다

2. Authentication (인증)

1) 인증이란 사용자의 신분을 확인하는 절차로 사용자는 증명 자료를 제출하고 KeyStone은 이를 검증한다

2) 사용자는 인증을 위한 자료로 이름,패스워드가 사용되며 인증의 응답으로 KeyStone은 인증토큰을 발행한다

3) 인증 토큰을 사용하여 다른 서비스를 요청할 수 있다.

3. Token(토큰)

- 사용자가 오픈스택 서비스가 제공하는 자원에 접근할때 신분을 증명하기 위해 사용하는 텍스트 데이터

- 사용자가 어떤 자원에 접근이 가능한지 범위가 지정되어 있다

- 주어진 시간 동안만 유효

- 토큰 유형 : fernet, uuid, pki, pkiz

4. Project(프로젝트)

- KeyStone V2까지 Tenant라는 이름으로 사용됨(V3 부터 Project)

- 어떤 자원이나 어플리케이션에 대한 권리를 가진 보안그룹

- 자원 소유권의 기본단위, 프로젝트는 특전한 자원을 소유한다

- 프로젝트는 특정도메인에의해 소유된다

프로젝트 생성

- openstack project create service

 => "service"라는 이름의 Project 생성

5. 엔드포인트

- 사용자가 서비스를 이용하기 위해 연결정보를 제공하는 접근 가능한 네트워크 주소로 URL(IP , PortNUm)을 사용한다

- 엔드포인트 유형 

1) admin - 클라우드 환경을 관리하는 조직내부의 운영자들에게만 접근이 허용된다

2) internal - 내부 서비스간에만 접근이 허용된다

3) public - 인터넷에서 인식이 가능하며 사용자들이 인터넷을 통해 자신의 클라우드 환경을 제어할 때 사용

6. 역할(Role)

- 사용자가 어떤 동작을 수행하도록 허용하는 집합 

- 사용자가 가지는 역할은 사용자에게 발행된 토큰에서 찾을 수 있다

- 사용자가 서비스를 호출하면, 서비스는 토큰에 저장된 사용자의 역할을 해석하여 허용할지를 결정한다

7. 도메인

- 구성요소들을 효과적으로 관리하기 위해 활동 범위가 제한된 사용자, 그룹, 그리고 프로젝트의 집합

- 사용자들은 한 도메인의 관리자로 권한을 부여받을 수 있고 그 관리자는 도메인 내에서 

  프로젝트, 사용자, 그룹을 생성할 수 있고 그들에게 역할을 부여할 수 있다.

<그림출처 - http://naleejang.tistory.com/106>

KeyStone 논리적 구조

<그림출처 - http://naleejang.tistory.com/106>

1) Token Backend

- 사용자별 토큰을 관리한다

- Memcached를 사용했음

*MemCached란 

- 메모리에 Key-value형태로 데이터를 저장하여 데이터베이스의 부하를 분산

2) Catalog Backend

- 모든 서비스의 End Point URL을 관리한다

- Maria DB(Mysql)를 사용했음

3) Policy Backend

- project, 사용자계정 및 Role등을 관리한다

- Maria DB(Mysql)를 사용했음

4) Identity Backend 

- 사용자 인증을 관리한다

- Maria DB(Mysql)를 사용했음

KeyStone 동작 절차

1. 사용자가 KeyStone으로부터 범위 비지정(UnScoped) 토큰 획득

1) 사용자가 Nova 서비스가 제공하는 가상머신을 제공하기위해 KeyStone에 접속한다

2) 키스톤은 사용자에게 신분증명을 요구한다

3) 사용자는 아이디와 패스워드를 제출하여 신분을 증명한다

4) KeyStone은 인증에 성공한 사용자에게 UnScoped 토큰을 발급한다 이때의 토큰에는 사용자가 사용가능한

서비스들에 대한 범위가 포함되어있지 않다(아직 다른 서비스들에게 접근 불가능)

2. KeyStone이 사용자가 접속 가능한 프로젝트 찾기

1) 신분증명을 완료하여 UnScoped 토큰을 받은 사용자는 이 토큰을 통해 자신이 접속가능한 프로젝트를 요청한다

2) KeyStone은 이사용자에게 할당된 역할에 따라 프로젝트의 종류와 수행 가능한 EndPoint 목록을 작성한다

(아직 사용자에게 이러한 목록을 보내지 않음을 주의)

3. 사용자가 KeyStone으로 부터 범위 지정(Scpoed) 토큰 획득

1) KeyStone은 사용자가 접속가능한 프로젝트 목록과 사용자가 사용을 원하는 프로젝트를 결정한다

2) 위의 정보(프로젝트와 역할)가 포함된 토큰을 사용자에게 보낸다

4. 사용자가 서비스에게 서비스 요청하기

1) 범위가지정된 토큰을 받은 사용자는 토큰 내부의 Endpoint를 확인하고 서비스에게 서비스를 요청한다

5. 요청을 받은 서비스가 KeyStone에게 토큰 검증 의뢰하기

1) 서비스는 사용자가 요청과 함께 제출한 토큰의 메타데이터 정보가 유효한지 검증하기 위해 KeyStone에게 의뢰

2) KeyStone은 서비스로 부터 받은(사용자가 서비스에게 제출한) 메타데이터와

    Policy Backend에 저장된 메타데이터와 비교 (RBAC)

6. 검증이 완료된 토큰을 서비스에게 제공

1) 사용자가 요청한 서비스에 접근이 가능한지 토큰의 메타데이터의 검증을 마친 KeyStone은 그 결과를 서비스에게 제공

7. 서비스가 사용자의 요청 실행하기

1) 서비스는 KeyStone으로부터 토큰 검증을 완료한 후 인스턴스를 실행하라 또는 볼륨을 생성하라 등의 요청을 수행한다

8. 결과 보고하기

1) 서비스는 사용자의 요청에 대해서 실행에 대한 결과를 사용자에게 보고한다

2. Glance - Images

- 이미지를 관리하는 서비스이다

- 인스턴스를 생성하는 이미지를 제공하는 서비스

- 사용되는 실제 이미지들을 swift같은 오브젝트 스토리지에 저장된다(Nova가 rest api를 통해 이미지를 제공받을 수 있게)

- 이미지를 잘 이해해야한다 운영체제를 설치하기 위한 ISO이미지만이 이미지가 아니다

*이미지의 의미

1) 운영체제 설치 이미지, 

2) 설치가 완료되어 서비스 가능한 이미지, 

3) 운영중인 운영체제를 복제하여 만든 이미지, 

4) 백업을 위해 복제한 스냅샷 이미지등등

구성요소

1) glance-api

- 이미지 검색, 스토리지에 대한 사용자의 API요청을 받음

- /etc/glance/glance-api.conf 를 사용

2) glance -registry

- 이미지에 대한 메타데이터 정보를 저장

- /etc/glance/glance-api.conf 파일 사용

3) Database

- 이미지 메타데이터를 저장

- Mysql 또는 Maria DB 사용

4) Storage

- 이미지 저장을 위해 사용

- AWS의 S3 또는 OpenStack의 Swift등과 같은 외부 구성요소와 통합가능한 장치

구조

1. Glance Store

- Glance와 저장소(Swift,S3) 사이에서 상호간의 동작을 위해 사용

- Glance Store Drivers 를 이용

2. Glance Domain Controller

- 권한 부여,알림, 정책 데이터베이스 연결등을 수행하는 미들웨어

3. DAL(Database Abstraction Layer)

- Glance와 Database 사이의 통신을 담당하는 API

지원하는 이미지 포맷

1) 디스크 포맷

1. RAW

2. VHD

3. VMDK

4. qcow2

5. VDI

6. ISO

7. AMI,ARI, AKI :아마존

2) 컨테이너

1. bare

2. ovf

3. aki , ami : 아마존

4. ova : tar 아카이브 파일

4. docker 

*Flavor

- 가상의 자원을 표현하는 용어

- 인스턴스가 가상의 CPU, RAM, DISK 등의 크기가 얼마인지를 정의

Glance의 이미지 제공 방법

1. 명령창에서 virt-install 명령어를 이용하여 생성

2. 각 OS회사에서 배포하는 클라우드 이미지를 사용

3. virt-manager GUI 프로그램을 사용

3. Nova - Compute 

- Glance에서 제공하는 이미지를 이용하여 인스턴스를 제공하는 서비스

- 컴퓨터 노드에 설치되어 CPU, Memory, Network, Storage를 이용해 가상머신 서비스를 제공 (OpenStack의 Iaas)

- 가상화 기능을 포함하지 않는다

- 하이퍼 바이저와 상호작용 하는 드라이버를 이용하여 외부에서 가상머신을 제어하는 기능

- 1) 인증을위해 KeyStone 2) 이미지를 제공받기 위해 Glance 3) 네트워크를 제공하기 위해 Neutron

  4) 사용자들에게 인스턴스 관리 서비스 제공을 위해 Horizon 5) 스토리지 제공을위해 Swift, Cinder 등과 상호작용

*VNC 

- virtual netowkr Computong

- 관리자에게 인스턴스로 원격 데스크톱 접속을 허용하는 서비스(6080 Port)

구성요소

1. nova-api

- 사용자가 nova 서비스를 요청하기 위한 endpoint 제공

2. nova-compute

- KVM이 사용하는 libvirt 같은 하이퍼 바이저 API를 통해 KVM을 제어하여 가상머신을 생성하는 데몬

- Message Queue로 부터 명령을 받아 인스턴스 시작과 같은 시스템 명령을 실행

- Database에 인스턴스 상태를 업데이트 시킴

3. nova-scheduler

- Message Queue에서 가상머신(인스턴스)에 대한 요청을 받으면 어떤 컴퓨트노드에서 실행할지 결정하는 서비스

4. nova-conductor

- nova-compute 와 Database 사이에서 상호 연동을 중재

(=> nova-compute 서비스가 Database에 직접 접속하는 것을 차단함을 의미한다)

5. nova-console

- 인스턴스로의 콘솔 접속을 제공 

6. nova-consoleauth

- 인스턴스로의 콘솔 접속시 사용자에 대한 토큰 인증을 수행

7. nova-novncproxy

-  vnc를 통해 실행중인 인스턴스에 접근 가능한 프록시 서비스 제공

8. Message Queue

- 오픈스택 서비스들의 중앙에 위치하여 각서비스들간의 통신을 지원하는 역할 수행

9. Database

- 사용 가능한 네트워크, 프로젝트 등의 정보저장

- 사용중인 인스턴스에 대한 정보저장

Nova Database

1. nova_cell0

- nova-api, nova-conductor, nova-compute 서비스에 의해 사용되며 스케줄링에 실패한 인스턴스 정보가 저장됨

2. nova_placement

- 인스턴스 생성에 필요한 자원과 전체 사용량에 대한 정보를 저장

Nova 동작 절차

1. 사용자가 Horizon이 제공하는 대시보드를 이용하여 가상머신을 생성

2. 대시보드는 Horizon에게 사용자의 요청을 전달

3. Horizon은 Controller Node의 Nova-api의 가상 머신 생성 API를 호출

4. Nova-api는 가상머신 생성 명령을 RabbitMQ(메시지 큐)에 저장

5. Nova Scheduler가 RabbitMQ(메시지 큐)의 명령들을 스케줄링하여 실행 우선순위를 정함

6. Nova-compute는 RabbitMQ에 스케줄링된 명령어를 가져온다

7. 하이퍼바이저 드라이버를 통해 설치된 하이퍼바이저에 가상머신 생성을 요청

8. 하이퍼바이저는 가상머신 생성에 필요한 자원을 할당받아 가상머신을 생성한다

9. 이미지가 필요하다면 Glance 서비스의 API를 호출하여 이미지를 제공 받는다

*. 인증, 권한제어, 자원할당등의 상세한 과정은 생략

확인 명령어

1. lsmod | grep kvm

- kvm 모듈이 지원 되는지 확인

*lsmod - 커널에서 지원하는 모듈을 보여준다

2. openstack compute service list

- 현재 실행중인 nova service 목록을 확인

3. openstack hypervisor list

- 컨트롤러 노드에서 하이퍼바이저로 사용되는 컴퓨터 노드를 확인 가능

4. lsmod | grep vhos

- 커널에 vhost 모듈이 로딩됐는지 확인한다

5. modprobe vhost_net

- vhost_net을 활성화 시키는 명령어

6. echo vhost_net >> /etc/modules 

- 부팅시 위의 모듈이 자동으로 로딩되게 하는 명령어

*vhost-net

- virtio 네트워크 인터페이스를 위해 사용된다

*virtio 

- 가상화 환경에서 네트워크와 디스크 장치 드라이버를 위해 사용되는 가상화 표준 이름

4. Neutron - Networking

- openstack 네트워킹 개념 - https://printf.kr/archives/307

- 네트워킹 기능 제공

- Nova가 관리하는 가상 머신들이 사용하는 네트워크

- 스위치, 서브넷 및 라우터를 포함하여 가상 네트워크 생성 관리를 처리

- 가상 방화벽 , VPN, 로드밸런서 등의 기능제공 

- 관리자, 사용자들이 가상으로 구축한 네트워크를 실제로 구현하기 위해서 관련 소프트웨어와 드라이버가 필요

  , 이에 neutron에서는 ML2를 사용

네트워크 종류

1. 프로바이더 네트워크

- 오픈스택의 가상머신들이 속한 가상 네트워크를 실제 물리적 NIC와 Bridge로 연결하여 네트워크를 제공한다

1. Controller Node와 Compute Node의 NIC가 실제 물리적으로 연결되어 있는 상태이다

   => 우리는 VMware에서 동작 시킬 것이므로 Bridge 카드를 부여하면 된다, *이때 Bridge카드에는 IP가 부여 되지 않는다

2. Provider Physical network(실제 물리 네트워크망) 와, Provider virtual network(가상의 네트워크 망) 가

    각각의 망을 연결하는 Provider Bridge에 연결됨으로써 인스턴스(가상머신)들에게 네트워크를 제공한다

2. 셀프서비스 네트워크

- L3 서비스와 함께 프로바이더 네트워크를 증가시키는 역할

- IP주소를 인스턴스에 제공하는 DHCP 서버를 포함

- 이네트워크의 인스턴스는 외부 네트워크(인터넷)에 자동으로 접속 할 수 있다.(플롯팅 IP주소가 필요)

용어

1. OVS(Open vSwitch)

- 가상 네트워크에서 VM(가상머신) 을 위해서 제공되는 스위치를 의미

- 소프트웨어로 구현한 가상의 스위치

- 호스트 운영체제에서 소프트웨어적으로 제공하기 때문에 가상 스위치라고 한다

 (SDN 이라고 한다(Software Defined Switch))

- 실제 스위치와도 연결 가능

- GRE, VXLAN 과같은 터널링 기능도 지원이 가능

2. Floating IP(플롯팅 IP)

- 외부 네트워크에 위치한 호스트가 오픈스택 네트워크에 생성된 인스턴스에 접속하기위해 사용되는 IP주소

   (AWS의 public IP)

3. VXLAN

- VXLAN은 L3 네트워크 위에 가상의 L2 네트워크를 오버레이하는 기술이다. 오버레이된 네트워크들을 VXLAN 

 segment 라고 하며 각각의 segment에 포함된 VM끼리만 통신이 가능하다. 각 VXLAN segment는 24비트의 식별자(VXLAN Network Identifier)를 가지며, 최대 1600만개 이상의 VXLAN 세그먼트가 만들어질 수 있다. VXLAN Netrowk Identifier(이하 VNI)는 내부의 캡슐화된 이더넷 프레임이 어떤 VM으로부터 나왔는지 특정하며, 때문에 세그먼트들 사이의 MAC을 오버래핑 하더라도, 트래픽이 세그먼트들을 ‘통과하는’일은 일어나지 않는다. 이러한 캡슐화 때문에 VXLAN은 L3 네트워크에서 L2 네트워크를 구성하는 터널링 기술로 불리기도 한다. 이 터널이 stateless 하기 때문에 각각의 프레임들은 일정한 규칙에 따라 캡슐화될 필요가 있다.

동작

1. VXLAN이 적용된 VM은 VXLAN을 인지하지 못한다. 이 VM은 다른 VM과 통신하기 위하여 일반적인 MAC 프레임을 전송한다.

2. 물리 호스트 위의 VTEP는 프레임을 수신하고, 해당 VM이 속한 VNI를 찾는다. 그리고 목적지 MAC이 같은 세그먼트에 속하는 VM이라면, 원격 VTEP의 MAC을 매핑한다. 이 시점에서의 패킷 구조는 IP-MAC 헤더-원본 L2 프레임이다.

3. L3 네트워크를 타고 전송된 프레임이 원격 VTEP에 도착한다. 원격 VTEP는 VNI를 검증하고 목적지 VM이 해당 VNI에 속해있는지 확인한 뒤, 프레임의 캡슐화를 풀고, VM에 전달한다.

구조

1. neutron-server

- 네트워크 또는 서브넷 생성 및 라우터 삭제 그리고 Database 관리 요청을 API를 통해 받아들인다음

  이러한 요청을 neutron 에이전트에 전달하기 위해 RPC를 사용하여 메시지 큐서버와 통신한다.

- 일반적으로 Controller Node에 설치

2. 오픈스텍 network-plugin-agent

- 네트워크 포트에 대한 탈부착

- 네트워크 또는 서브넷 생성 

- IP주소를 제공함

- L2 agent, L3 agent, DHCP agent 등이 사용된다

1) L2 agent

- 디바이스가 추가 또는 삭제되는 상황을 모니터링

- Linux Bridge, OVS(Open vSwitch), 보안그룹 및 VLAN 태깅도 처리 가능

- network Node 또는 Compute Node에 설치

2) L3 agent

- neutron-server로부터 라우팅관리, IP 플로팅 에대한 메시지를 받아서 관리

- 내부 네트워크간 데이터 전달 또는 내외부 전달 수행

- Network Node에 위치

3) DHCP agent

- IP주소 할당에 사용된다

- dnsmasq 기능을 이용하여 DHCP 서버로 사용된다

- 가상 머신이 DHCP 요청을 dnsmasq에 보내고 dnsmasq가 IP를 그 가상머신에게 보낸다

4) Metadata agent

- 인스턴스 내부의 클라이언트의 metadata 요청을 Nova metadata 서비스에 전달

- RPC를 통해 Neutron Server와 통신

Neutron Server 구성 요소

1. 서비스

1) Neutron Server

- 여러 플러그인 , 드라이버를 사용하여 네트워크를 구축

2) Neutron L2 agent 

- 가상 인프라 환경을 구축하고 유지

- OVS(Open vSwitch, Linux Bridge) 사용

3) Neutron L3 agent

- neutron 라우터와 이와 관련된 기능을 구축 및 유지

2. 플러그인

1) Core Plugin

- Neutron API를 구현

- 네트워크, 포트, 서브넷이 표현하는 논리적 네트워크를 L2 agent에 의해 적용되도록 한다

2) Service Plugin

- 라우팅, 방화벽, 로드밸런서 등의 네트워크 서비스를 추가

3. 드라이버

1) Type Driver

- 프로바이더 네트워크를 검증하고 프로젝트 네트워크를 할당 

- Local, Flat, VLAN, GRE, VXLAN

 a. Local : 단일 노드에서 테스트용으로 사용

 b. Flat : 모든 인스턴스가 동일 네트워크에 위치 

 예를 들어 컴퓨트 노드와 네트워크 노드가 213.0.113.0/24 를 사용하면 가상머신에도 이 네트워크를 제공

 c. GRE : 사설 통신을 가능하게 하는 터널링 기술

 d. VXLAN : VLAN에 X(extensible)를 더한 것으로 L2의 확장을 의미한다

2) Mechanism Driver

- 오픈스택 네트워크가 지원하는 타입중에서 어떤 타입 드라이버로의 접근이 가능한지를 정의하기 위해서 사용

- 네트워크, 포트 자원 생성, 및 업데이트 삭제 작업 지원

- Open vSwitch, Linux Bridge

ML2

- 가상 네트워크를 구축하기 위해 사용하는 neutron의 핵심 플러그인

- open vSwitch, Linux bridge 모두 ML2 드라이버를 통해 구현

1) 타입 드라이버 (Type Driver)

- OpenStack 네트워크가 기술적으로 어떻게 실현되는지 정의한다

- Local, Flat, VLAN, VXLAN, GRE

2) 메커니즘 드라이버 (Mechanism Drivers)

- ML2는 타입 드라이버 이외에 메커니즘 드라이버를 제공한다. 기존 Neutron을 설치할 경우에는 Linuxbridge나 OpenvSwitch를 설치하여 사용하였다. 이때 어떤 컴퓨트 노드는 Linuxbridge가 설치되어 있고 다른 컴퓨트 노드는 OpenvSwitch가 설치되어 있다고 가정했을 경우 이 두 컴퓨트 노드는 서로 연동을 할 수가 없었다. 그래서 나온 개념이 바로 ML2의 메커니즘 드라이버이다. 메커니즘 드라이버의 Agent는 기존에 사용하던 OpenvSwitch, Linuxbridge, Hyper-V등을 그대로 사용할 수 있으며, Arista 메커니즘 드라이버나 Cisco Nexus 메커니즘 드라이버를 사용할 수 있다.

*위그림을 보면 ML2 Plugin을 통해 서로다른 Agent를 가진 Host 간에도 모듈 연동이 가능함을 볼 수 있다.

Neutron 동작 절차

1) Controller Node의 Neutron Server 가 Client로 부터 Horizon 또는 명령행을 통해 API 요청을 받는다

2) Neutron Server는 처리를 위해 ML2 플러그인을 호출하는데 이때 이미 OVS Mechanism Driver를 

   메모리에 로딩한 상태 이며 따라서 이요청을 OVS 드라이버에게 전달한다

3) OVS드라이버는 해당 요청을 처리하며 Compute Node의 OVS agent에게 RPC 메시지를 보낸다

4) OVS agent는 RPC 메시지를 받고 OVS Switch에 연결된 인스턴스 설정을 진행한다

5) 유사한 방식으로 Network Node의 DHCP agent는 DHCP 서버를 설정한다 

6) DHCP agent는 OVS Switch 를 통해 알맞은 네트워크 정보를 인스턴스에게 전달한다

 

*OpenStack 구축시 네트워크 구성

1) Tenant Private Net - 내부의 VM들 간 통신을 위한 Private Network

   - OpenStack 구축 후 VM들을 위해 관리자가 따로 만들어주는 네트워크

2) enp0s8 - OpenStack을 관리하기 위한 NIC

- 실제 PC의 NIC

3) enp0s3 - VM들이 외부 인터넷을 사용하기위한 NIC   

 - 실제 PC의 NIC

5.  Horizon - DashBoard

- 대시보드 서비스는 웹을 통해 사용자나 관리자가 오픈스택의 자원과서비스를 이용할 수 있도록 사용자 인터페이스를 제공

- 통상적으로 ControllNode에 설치하며 Apache 또는 Nginx 웹서버를 사용한다.

- 사용자는 Horizon을 통해 1)가상머신생성 2) 가상머신에 네트워크를 구성 3) 보안규칙 설정등의 다양한 기능사용 가능

- 파이썬을 이용하여 커스터마이징 가능

사용 과정

1) 사용자 또는 관리자가 오픈스택 서비스를 관리하기위해 Horizon에 접속을 시도한다 

2) Horizon 서비스 접속시 사용자 또는 관리자는 KeyStone으로 부터 인증을 통과해야 한다

3) 인증에 통과한 사용자의 세션정보는 Memcached와 같은 세션 백엔드 저장장치에 보관된다

4) Horizon 서비스에 접속된 사용자 또는 관리자는 OpenStack의 서비스들에 대한 관리가 가능하다

5) 서비스간의 통신은 Message Queue를 통해 이루어진다.(RabbitMQ)

6. Cinder - Block Storage

- 컴퓨터 노드와  스토리지 노드가 같은 노드에 구성되었다면 로컬의 물리볼륨을 사용하고 

   컴퓨터 노드와 스토리지노드가 네트워크로 연결되었다면 iSCSI 또는 NFS로 연결된 물리 볼륨을 사용 

- 어떤 물리 볼륨을 사용할지는 /etc/cinder/cinder.conf에 설정된 enabled_backends와 valume_driver 파라미터 에 의해 결정된다.

- Cinder가 제공하는 블록스토리지 볼륨은 오직 하나의 가상머신에서만 사용이 가능하며 공유가 불가능하다.

용어

1) 물리 스토리지 - 스토리지 노드에 실제 연결된 물리적 디스크 LVM과 같은 볼륨 매니저를 통해 스토리지 

  노드의 운영체제에 마운트되는 스토리지

2) 블록 스토리지 - Cinder-Volume 에 의해 물리적 스토리지로 부터 생성되는 논리적 볼륨

- 가상머신에 제공할 볼륨을 생성

3) VolumeProvider - 블록 스토리지로 부터 생성된 볼륨을 가상 머신에 할당

    - volume Provider가 할당해준 볼륨을 Nova가 설치된 노드의 Nova-compute가 attach 시킨다

4) Cinder-api - Cinder를 통해 스토리지 서비스를 제공하는 API제공

5) Cinder-Scheduler - 볼륨 서비스 요청의 실행과 전달 관리

6) Cinder - Volume - 백엔드의 블록 스토리지 장치를 관리

7) Cinder-backup - Cinder가 제공하는 블록스토리즈를 Swift로 백업하는 기능 제공

구성방법

1. 컨트롤러 노드 또는 컴퓨터 노드에 설치 - 테스트환경에서 충분한 노드 확보가 어려운 경우 구성

2. 독립적인 스토리지 노드로 구성

제공방법

1. 각각의 컴퓨터 노드에 구성

2. 외부 스토리지를 구성하여 공유 - iSCSI 나 NFS로 연결 

7. Heat - Auto Scaling