이러다 클라우드.

Presentation on theme: "이러다 클라우드."— Presentation transcript:

1 이러다 클라우드

2 Cloud

3 Cloud SaaS Aplication data PaaS Runtime Middleware Os IaaS
Virtualization Server Storage Network

4 Cloud

5 Compute service

6 Storage Service

7 OpenSource platforms Eucalyptus

8 OpenStack

9 OpenStack

10 OpenStack

11 Contents

12 Design

13 Horizon 웹UI 사용자가 인스턴스 생성, 삭제 및 관리 등을 쉽고 빠르게 처리할 수 있도록 해줌
아파치 웹 서버 사용 예정

14 Architecture of Horizon
단순히 자체 모듈만 가지고 있다 그러나 모든 서비스의 API 와 연동이 가능하며 Web서비스를 제공해준다.

15 Horizon

16 Glance 다양한 하이퍼바이저에서 사용할 수 있는 가상머신 이미지를 관리. 인스턴스를 위한 Image 제공 서비스 정의
레드햇/윈도우/우분투/센트OS/등등 인스턴스를 위한 Image 제공 서비스 VM에게 설치 시 필요한 이미지 제공 Storage adapter를 통해 제공

17 Architecture of Glance
Glance-api  이미지 등록,삭제,관리 Glance-registry 등록 시 registy를 통한다. Glance-database 등록 시 이곳에 저장 등록 후 사용 시 이곳에 직접 요청한다. Glance 사용자들은 glance-api를 통해 이미지를 등록, 삭제 및 관리를 할 수 있다.  glance-api는 glance-registry와 glance database에서 이미지가 관리된다.  이미지를 등록할 때는 glance-registry를 통해 glance-database에 저장이 된다.. 등록된 이미지를 사용할 때는 glance-database에 바로 사용요청을 한다.

18 Glance Glance 사용자들은 glance-api를 통해 이미지를 등록, 삭제 및 관리를 할 수 있다.
이미지를 등록, 삭제 및 관리를 할 수 있다.  glance-api는 glance-registry와 glance database에서 이미지가 관리된다.  이미지를 등록할 때는 glance-registry를 통해 glance-database에 저장이 된다.. 등록된 이미지를 사용할 때는 glance-database에 바로 사용요청을 한다.

19 Swift / Cinder

20 Swift 비정형성 데이터 고유 URL 멀티 테넌트 멀티미디어(동상,이미지), 디스크이미지
다양한 곳에서 직접 동시에 접근 가능 멀티 테넌트 저장공간에 제약이 없음 비정형성 데이터를 저장하기에 적합하다. 각각의 오브젝트들은 고유한 URL을 가지고 API로 제어한다. 외부 APP이나 웹 등에서 직접 동시접근이 가능하다. 멀티 테넌트로 구현가능하며 저장공간에 제약이 없다. 각각받는게아니라 큰틀에서 같이쓴다. • 확장성 페타규모의 클러스터로 확장가능하며 확장시에도 빠르고 간단하게 확장가능 • 내구성 복제본은 격리된 환경(Zone)으로 관리하여 안전하게 보관 • 가용성 비공유 구조로 단일 장애점이 없기 때문에 높은 가용성 보유 • 저비용 하드웨어 선택에 특정한 벤더 lock-in이 되지 않았으며 오픈소스를 사용하여 적은 비용에 구축가능

21 Swift Components Service architecture
proxy server - 사용자의 리퀘스트(REST)을 받아서 알맞은 서버로 배분해 주기 위한 서버 이 후 해당 Request가 어떤 물리적인 서버에서 처리해야 할지
 Ring을 이용해서 결정 후 Storage Server로 request -Storage servers(zone) 3종류의 데이터를 각각의 서버가 관리하며 동일한 로직으로 링에서 접근됨 account server - proxy 로 부터 전달 받은 리퀘스트(REST)를 처리해서 account 당 한개의 db 파일에 맞게 리퀘스트를 처리함 container server - proxy 로 부터 전달 받은 리퀘스트(REST)를 처리해서 container 당 한개의 db 파일에 맞게 리퀘스트를 처리함 object server - proxy 로 부터 전달 받은 리퀘스트(REST)를 처리해서 object 당 한개의 오브젝트 파일을 생성 결국 ring에서 알맞은 서버들을 찾음으로 데이터를 분산해서 저장한다.  • Account -사용자의 계정으로 다수의 사용자들이 권한(ACL)에 따라 사용을 정의가능 함 Account의 상태 정보를 저장 Container의 리스트를 관리 • Container -사용자들의 권한(ACL)에 따라 사용가능이 결정되는 폴더와 같은 단위 Container의 상태 정보를 저장 Object의 리스트를 관리 • Object - 실질적으로 관리되는 파일(+메타데이터) Container의 ACL에 적용되어 사용 가능 여부 결정 이런 구조의 자료들을 링이란 요소로 분산 관리한다. 모든 값들이 고유의 URL이 있기 때문에 이를 이용하여 관리한다.

22 Cinder 정형성 데이터 인스턴스에 사용할 수 있는 저장공간을 생성 및 삭제 스냅샷 관리기능 제공 Database
스냅샷을 이용하여 백업/복구/생성 가능 비정형성 데이터를 저장하기에 적합하다. 각각의 오브젝트들은 고유한 URL을 가지고 API로 제어한다. 외부 APP이나 웹 등에서 직접 동시접근이 가능하다. 멀티 테넌트로 구현가능하며 저장공간에 제약이 없다. 각각받는게아니라 큰틀에서 같이쓴다.

23 Architecture of Cinder
Cinder-api 볼륨 추가, 삭제 인스턴스에 할당 가능 Cinder-volume 실제로 생성 및 cinder-database에 정보 업데이트 LVM 물리하드 디스크를 LVM으로 설정한다. 효율적이고 유연하게 관리할 수 있는 방법 - Cinder API를 통해 볼륨을 추가 및 삭제할 수 있습니다. - 신더 볼륨은 볼륨을 실제로 생성하고 데이터베이스에 볼륨정보를 업데이트합니다. - Cinder는 물리 하드 디스크를 LVM(Logical Volume Manager)으로 설정합니다. - 설정한 LVM은 cinder.conf와 nova.conf의 환경설정을 통하여 신더 볼륨을 할당할 수 있습니다. - 신더 API를 통해 생성된 볼륨은 단일 인스턴스 또는 여러 인스턴스에 할당할 수 있습니다.

24 LVM of Cinder LVM Logical Volume Manger 논리 볼륨 할당, 관리
위의 그림은 하드디스크를 어떻게 볼륨 그룹으로 나누고, 볼룸 그룹을 어떻게 논리 볼륨으로 나누었는지에 대한 개념을 쉽게 그림으로 표현해 본 것입니다. LVM을 사용하여 생성된 논리 볼륨 그룹은 여러 개의 논리 볼륨으로 나뉘어지며 이 논리 볼륨에는 마운트 지점 (예, /home 과 /)과 파일 시스템 유형 (예, ext3)이 부여됩니다. 예를 들어, 파티션의 용량이 가득 차게 되면, 논리 볼륨 그룹으로부터 여유 공간을 가져와 논리 볼륨으로 추가하여 그 파티션의 용량을 확장시켜 줍니다. 새로운 하드 드라이브를 운영 체제에 추가시키면, 이 하드 드라이브는 논리 볼륨 그룹과 확장 가능한 파티션인 논리 볼륨으로 추가됩니다. Cinder는 LVM의 이와 같은 특성을 이용하여 논리 볼륨을 생성하고, 생성된 볼륨을 인스턴스에 할당하여 디스크처럼 사용할 수 있습니다.

25 Cinder

26 Contents 안녕하세요 3조 이러다 클라우드 조장인 박준상 입니다.
제가 설명드릴 내용은 전체 OpenStack의 핵심 컴포넌트 8개중, 앞서 설명한 4가지 컴포넌트를 제외한 나머지, compute 서비스인 nova, network 서비스인 neutron, 인증 서비스인 keystone, telemetry 서비스인 ceilometer가 되겠습니다.

27 Nova 가장 먼저 compute 서비스인 nova에 대해서 설명하겠습니다.
nova는 openstack 초창기 모델부터 있었던 openstack의 필수 구성요소 중 하나이고, openstack 내에서 운영체제와 같은 역할을 해줍니다. 이러한 nova는 중요한 요소인 만큼 openstack 곳곳에서 하는 일이 많습니다. nova의 구조를 살펴보면, Queue 중심으로 nova-api, nova-compute, nova-consoleauth, nova-scheduler, nova-conductor, nova-cert가 서로 메세지를 주고 받을 수 있도록 설계되어 있으며, hypervisor는 libvirt나 XenApi를 통해 nova-compute와 연동이 되어 있습니다.

28 Nova Support Hypervisors
Nova가 지원하는 그룹별 Hypervisor 종류 Nova가 지원하는 하이퍼바이저 그룹은 3 가지가 있는데. 가장 기본적인 하이퍼바이저는 그룹 A의 Qemu와 KVM입니다 두번째 그룹 B에서는 Hyper-V, VMware, XenServer를 지원합니다. 세번째 그룹 C에서는 Baremetal, docker, Xen via libvirt, LXC via libvirt 를 지원합니다.

29 Nova Architecture nova-api nova-scheduler nova-compute nova-conductor
- 스케줄링을 위한 알고리즘 구현 nova-compute - VM 인스턴스를 생성하고 제거 nova-conductor nova-compute와 DB 사이에서 상호작용을 조절 nova의 구조를 설명 드리자면 api, scheduler, compute, conductor 총 4 가지로 구분할 수 있습니다. nova-api는 인스턴스 실행과 같은 Nova 에서 가장 핵심적인 역할을 수행합니다 nova-scheduler는 스케줄링을 위한 알고리즘이 구현 되어있습니다 nova-compute는 VM 인스턴스를 생성하고 제거합니다 nova-conductor는 nova-compute와 데이터베이스 사이에서 상호작용을 조절합니다

30 Neutron 다음으로 network 서비스인 neutron에 대해 설명하겠습니다.
기존에는 nova에서 제공하는 nova-network를 통해 network 서비스를 제공했었지만, 생성할 수 있는 ip 개수에 제한이 있는 문제가 있었습니다. 이를 해결하고자 Quantum이라는 network 서비스를 별도로 추가하였지만, 상표권 문제로 인해 Grizzly 업데이트 과정에서 Neutron이라는 이름으로 명칭이 변경되었습니다.

31 Neutron Architecture ML2 Plugin - nova-network의 문제점을 해결하기 위해 나온 plugin
- Type Driver VLAN (Virtual LAN) GRE (Generic Route Encapsulation) VxLAN (Virtual eXtensible LAN) - Mechanism Driver neutron의 기본 plugin은 ML2 plugin입니다. ML2 plugin은 Type Driver와 Mechanism Driver로 구성되어있습니다. Type Driver 종류에는 VLAN, GRE, VxLAN 이 있습니다. 일반적으로 한대의 스위치에는 하나의 랜을 구성할 수 있지만, 내부에 가상으로 추가적인 LAN을 구성하는 것이 VLAN입니다. GRE는 인터넷 프로토콜 위에 다양한 네트워크 레이어 프로토콜 범위를 캡슐화 할 수 있는 터널링 프로토콜로 Cisco에 의해 개발되었습니다. VxLAN은 VLAN의 확장판인데, 대규모의 클라우드 컴퓨팅을 구축할 때 사용됩니다. 기존에 사용하던 방법은 한 컴퓨트 노드에 Linuxbridge가 설치되어 있고, 다른 컴퓨트 노드에 OpenvSwitch가 설치되어 있는 경우, 이 두 가지 컴퓨트 노드들을 서로 연동 할 수 없었습니다. 하지만 ML2 Plugin은 Mechanism Driver를 통해, 다른 Agent가 설치되어 있어도 모두 연동할 수 있는 기능을 제공합니다.

32 Keystone 다음으로는 인증 서비스인 keystone에 관해 설명 하겠습니다.
사용자 등록 및 삭제, 권한 관리, 사용자가 접근할 수 있는 서비스 포인트 관리까지 사용자 인증에 대한 모든 관리를 수행하고 있습니다. 그렇기 때문에 keystone은 모든 서비스들과 연결되어있는 모습을 볼 수 있습니다.

33 Keystone Architecture
token backend - 사용자 별 token 관리 catalog backend - OpenStack 모든 서비스의 end-point URL을 관리 policy backend - tenant, user, role등을 관리 identity backend - 사용자 인증을 관리 keystone의 내부 구조는 token backend, catalog backend, policy backend, identity backend 총 4가지로 구성이 되어있습니다. token backend는 사용자 별 token 관리합니다. catalog backend는 OpenStack 모든 서비스의 end-point URL을 관리합니다. policy backend는 tenant, user, role등을 관리합니다. identity backend는 사용자 인증을 관리합니다.

34 Keystone 앞서 말씀 드렸던 token, tenant, user, role, endpoint url, service의 관계도 입니다. token은 사용자의 인증이 승인되었을 때 주어지는 키, tenant는 사용자 그룹, role은 해당 사용자의 권한이라고 볼 수 있습니다. endpoint url은 서비스에 접근할 수 있는 gate 라고 보시면 됩니다.

35 Ceilometer 마지막으로 telemeter 서비스인 ceilometer에 대해 설명하겠습니다.
ceilometer는 사용자가 openstack에서 배포된 자원의 사용량 및 성능을 측정하여 실시간으로 자원의 상태를 모니터링 할 수 있는 기능을 제공합니다. 또한 여러 분산된 클라우드 시스템의 자원 상태를 모니터링 함으로써, 전체적인 자원의 통계를 확인 할 수 있습니다.

36 Ceilometer Architecture
compute-agent - compute node의 자원 활용가능 통계 central-agent - 인스턴스에 연결되지 않은 자원이나 compute node에 대한 활용가능 자원 통계 collector - alarm이나 message queue를 모니터링 alarm-notifier - 설정된 임계 값에 따라 알림 기능 api - data store로부터의 data access를 제공 ceilometer 내부 구조는 크게 compute-agent, central-agent, collector, alarm-notifier, api 총 5 가지로 구성 되어있습니다. compute-agent는 compute node에서 실행되며, compute node의 자원 활용 통계에 사용됩니다. central-agent는 controller node에서 실행되며, 인스턴스에 연결되지 않은 자원이나 compute node에 대한 활용가능 자원 통계에 사용됩니다. collector는 controller node에서 실행되며, alarm이나 message queue를 모니터링하고 data store에 기록합니다. alarm-notifier는 controller node에서 실행되며, 설정된 임계 값에 따라 알림 기능을 제공합니다. api는 controller node에서 실행되며, data store로부터의 data access를 제공합니다 이상으로 OpenStack의 컴포넌트 설명을 마치겠습니다.

37 구성 요소 Components Network Plug-In Hypervisor Ex) ML2, OpenVSwitch, Ryu
어떤 서비스를 만들 것인가? -> 총 10개의 기본 Component Ex) Swift, Heart, Ceilometer Hypervisor 가상화를 지원하는 CPU? 전가상화 or 반가상화 지원하는 이미지 Format Ex) KVM, vSphere, Hyper-V, Xen OS 선정한 HV를 지원? Open source OS인가? Ex) 우분투, redhat, CentOS Network Plug-In 네트워크 통신 방식 SDN 사용 가능? Ex) ML2, OpenVSwitch, Ryu DataBase SQLAlchemy python drivers을 지원? Ex) MySQL, Galera, MariaDB 다른 프로젝트 팀에서 클라우드 서버 사용 + 교육용 Linux를 시연

38 Architecture (All – IN – ONE)
다른 프로젝트 팀에서 클라우드 서버 사용 + 교육용 Linux를 시연

39 Architecture (2-Nodes)
External Network User 다른 프로젝트 팀에서 클라우드 서버 사용 + 교육용 Linux를 시연

40 Architecture (4-Nodes)
ML2 Plug-in 다른 프로젝트 팀에서 클라우드 서버 사용 + 교육용 Linux를 시연

41 Architecture (3-Nodes)
Hypervisor Swift 다른 프로젝트 팀에서 클라우드 서버 사용 + 교육용 Linux를 시연