[Openstack] 오픈스택 컴포넌트 이해

이번주차의 목표 - 오픈스택 컴포넌트 이해

• 오픈스택 컴포넌트의 통신 과정
• keystone
• nova
• glance
• swift

 

스터디 1주 차에서 VMware와 OpenStack의 차이점이 무엇인지 궁금했었다. 이번에 OpenStack 공식문서를 돌아다니다 VMware Migration to OpenStack에 대한 글이 있었고 어느 정도 궁금했던 부분이 풀렸다.

해당글은 간단하게 OpenStack과 VMware Feature 비교표를 보여주고 있다.

• 독점 가상화플랫폼 VMware와 오픈소스 플랫폼 OpenStack의 기능 중 일대일 대응으로 동일하게 적용되는 기능은 없으나 OpenStack과 오픈소스에서 제공하는 서비스를 결합하여 구현할 수 있다.

VMware OpenStack Feature Comparison

위 사진외에도 여러 VMware플랫폼에서 제공하는 서비스들에 대한 비교가 있어 링크를 참고한다.

---

Openstack Service Architecture

오픈스택에서 제공해주고 있는 Architecture 다이어그램으로 오픈스택 서비스의 대한 흐름 및 컴포넌트를 파악할 수 있다.

 

The following diagram shows the relationships among the OpenStack services

Conceptual Architecture

• Clients Level의  인증 인가를 관리하는 Keystone, 모니터링 서비스 Ceilometer, UI 서비스 Horizon
• Neutron
  • VMs에 서로 통신가능한 네트워크를 제공
  • Ironic 서비스의 PXE(Preboot Execution Environment) 부팅하면서 필요한 환경을 설치할 때의 네트워크를 제공
• Cinder
  • VM에 필요한 볼륨을 제공
  • persistent volume
• Swift
  • Cinder의 백업 볼륨을 제공
  • Glance 서비스의 이미지를 저장할 공간, 데이터베이스 백업 용도, binary 형태의 데이터 저장 공간 제공 등 비정형 데이터 저장공간을 제공
• Nova
  • 인스턴스 부팅 시 데이터 처리
  • VM, 데이터베이스 인스턴스(Trove) 프로비저닝
• Glance
  • 여러 서비스들이 사용하는 이미지, 백업 snapshot을 등록하는 서비스 제공
  • 실제 이미지는 Swift에 저장

 

logical architecture에서는 각 컴포넌트들이 실제 요청에 대해서 어떤 Logic을 타는지 이해할 수 있도록 보여주며 api 호출 시 어떤 컴포넌트들이 호출되어 처리되는지 이해할 수 있다.

Horizion(Dashboard)에서 사용자의 요청이 API형태로 각 서비스를 호출하고, Queue 형태로 처리되는 방식임을 볼 수 있다.

To design, deploy, and configure OpenStack, administrators must understand the logical architecture.

Logical Architecture

---

KeyStone

• Openstack-keystone
  • 관리자 권한과 API 호출 시 필요한 인증 서비스를 제공한다.
• keystone
  • CLI에서 사용자가 API 요청 시 사용자 확인

---

Nova

• openstack-nova-api
  • Compute Services(인스턴스 부트) 요청을 핸들링
• openstack-nova-cert
  • 인증 관리
• openstack-nova-compute
  • VM 인스턴스를 생성하고 종료하는 기능 제공
  • Compute Database에 인스턴스의 상태를 저장하는 기능
• openstack-nova-conductor
  • compute 노드가 Compute database에 대해 접근 시 보안 점검
• openstack-nova-consoleauth
  • 콘솔 인증인가 핸들링
• openstack-nova-network
  • public, private 환경에 있는 VM에 대한 네트워크 트래픽 핸들링
• openstack-nova-novncproxy
  • VM이 VNC 프록시를 통해 VNC 콘솔에 접근 기능 제공
• openstack-nova-scheduler
  • 올바른 VM에 요청이 전달되도록 하며 가중치나 필터 설정에 따라 작동하도록 지원

VM 인스턴스를 생성하는 과정

13년도 자료를 참고, Quantum -> Neutron으로 rename 되었음

 

1. 대시보드/CLI에서 사용자 자격 증명을 가져와 keystone에 인증을 받음
2. keystone에서 인증된 사용자에게 REST API 호출 시 사용되는 인증 토큰을 반환
3. 대시보드/CLI에서 새 인스턴스 생성 요청을 REST API 요청으로 nova-api로 보낸다
4. nova-api에서 keystone으로 해당 요청의 token이 권한을 가지는지 확인 요청한다
5. keystone은 token을 검증하고 인증 헤더를 반환
6. nova-api는 nova-database에 새 인스턴스를 추가 요청
7. nova-database에서 새 인스턴스에 대항 정보를 생성
8. nova-api는 host id가 지정된 인스턴스 항목을 가져와 nova-scheduler에 rpc.call 요청
   1. RPC (Remote Procedural Call)
9. nova-scheduler가 큐에서 요청을 선택
10. nova-scheduler는 nova-database에서 필터링 및 가중치 등 host 정보를 요청
11. host id 및 필터링, 가중치 정보를 반환받아 compute node를 선정
12. nova-scheduler가 nova-compute에 rpc.cast 요청을 보내 인스턴스를 launch 요청
13. nova-compute가 큐에서 요청을 선택
14. nova-compute는 RAM, CPU, Disk와 같은 정보를 가져오기 위해 nova-conductor에 rpc.call 요청을 보냄
15. nova-conductor가 큐에서 요청을 선택
16. nova-conductor가 nova-database에 데이터 요청
17. nova-database에서 인스턴스 정보를 반환
18. nova-compute는 큐에서 인스턴스 정보를 선택
19. nova-compute는 인증 토큰을 glance-api에 전달하여 이미지 저장소에서 Image URI by Image ID를 가져와 저장소에서 이미지를 업로드하여 REST 호출
20. glance-api는 keystone에 인증 token을 검증
21. 검증이 완료되면 nova-compute는 이미지 메타데이터를 받아옴
22. nova-compute는 네트워크 API에 인증 token을 전달하여 인스턴스가 IP 주소와 같은 네트워크 정보를 요청한다
23. 네트워크 서버는 keystone으로 인증 token을 검증
24. 검증이 완료되면 nova-compute가 네트워크 정보를 가져옴
25. nova-compute는 볼륨을 인스턴스에 연결하기 위해 token을 cinder-api에 전달하여 REST 호출
26. cinder-api는 keystone으로 token을 검증
27. 검증이 완료되면 nova-compute가 블록 스토리지 정보를 가져옴
28. nova-compute는 하이퍼바이저 드라이버를 위한 데이터를 생성(on libvirt or api)하고 하이퍼바이저에서 요청을 실행

---

Glance

• openstack-glance-api
  • Storage Back-end와 통신하여 image에 관한 조회/수정/등록 서비스를 제공한다
• openstack-glance-registry
  • 이미지에 대한 메타데이터를 관리

---

Swift

• openstack-swift-account, container, object
  • account, container, object에 관한 데이터를 저장
• openstack-swift-proxy
  • API로 노출되어 사용되는 요청에 대해 authentication, route 기능, object를 사용자에게 stream 형태로 제공 

---

번외 스토리지편

 

오픈스택에서 스토리지 컴포넌트는 블록 스토리지 Cinder와 오브젝트 스토리지 Swift가 있다고 한다.

Swift의 용도 중 하나는 Cinder 백업 데이터를 저장하는 역할도 한다고 한다.

 

실무에서는 백업을 다양한 정책으로 적용한다.

 

1. FS 백업 (데이터 백업)

2. FULL 백업 (데이터, OS 등 전체 백업)

3. 증분 백업 (DB와 같이 큰 데이터의 경우.. 변경량만큼 백업(스토리지 명령어))

4. 스냅샷 백업 (시점 백업 - 원본 손상 시 복구 불가 - ex) OS 깨짐)

...

 

리눅스 기반 서버들은 상당히 예민하다

하나의 일환으로 서버 점검 중 리눅스 커널 lib 중 네트워크 관련된 소스의 소프트링크를 날려 먹은 적이 있었는데

서버가 켜지다가 멈추고 VM접근이 안되었다.

- 보통 문제가 있으면 리눅스 싱글모드로 접근할 수 있는데 싱글모드도 접근되지 않음

• 리눅스 싱글모드(Single User Mode)는 시스템 관리자가 문제를 해결하거나 시스템 유지보수를 수행하기 위해 사용하는 단일 사용자 모드

또한 차세대 프로젝트를 하다 보면 운영 데이터를 가지고 테스트 작업을 하고 싶을 때 데이터를 복제하여 테스트 환경에 데이터를 꽂는다.

그런데 실제 운영서버들에서 테스트해야 할 단계가 오면?

운영데이터에서 테스트하다 보면 데이터 변조가 발생한다. 테스트 전 데이터를 백업해 놓고 테스트가 끝난 후 데이터를 복구하는 상황도 온다.

 

그렇다면 실제 어떤 프로세스를 가지고 데이터 백업, 복구를 진행하는지 정도는 알고 있다면 나중에 도움이 될 것 같아 추후 실습을 하다가 혹은 프로젝트를 하다가 기회가 있다면 이러한 사고를 가지고 직접 데이터를 백업 및 복구해보는 경험을 쌓으면 좋을 것 같다.

 

 

백업 워크플로

---

References

레드햇 Openstack platform Architecture Guide

 

오픈스택 코리아 그룹 스터디 레포

 

블록 스토리지 백업 가이드

블록 스토리지 백업 가이드 | Red Hat Product Documentation