오픈스택 연구하기 : 코어프로젝트
- 3. Cloud & Container/Openstack
- 2019. 10. 11.
오픈스택 연구하기 : 코어프로젝트
안녕하세요 김민욱입니다.
이번 포스팅에서는 오픈스택에 대해서 말씀드리고자 합니다. 사실 오픈스택은 이미 많이 알려져 있는 프로젝트이기도 하고 그만큼 오래되었기 때문에 손쉽게 자료도 구하실 수 있습니다. 그럼에도 불구하고 해당 포스팅을 진행하는 이유는 제 블로그의 다른 내용을 보다가 오픈스택에 대해 궁금해하실 분들이 계실까 봐 번거로이 다른 블로그에서 찾기보다는 간편하게 오픈스택에 대해 대략적으로 파악하실 수 있게 오픈스택에 대해 포스팅하고자 합니다.
*이미지 출처 : [1]
2010년 6월 NASA와 RackSpace가 함께 개발한 Cloud OS인 Openstack을 오픈소스로 발표하였습니다. 그렇다면 왜 Openstack을 Cloud OS라고 할까요? 운영체제는 하드웨어와 사용자 사이에서 사용자의 편의를 제공하는 여러 인터페이스, 드라이버 등을 제공함으로써 하드웨어를 사용가능하게 하면서 관리해줍니다. 마찬가지로 Openstack 역시 Cloud OS로써 클라우드가 제공하는 여러 기능들을 사용자가 편리하게 사용할 수 있도록 기능을 제공하고 있습니다.
Openstack은 6개월에 한 번씩 새로운 Release 버전이 발표되는데 알파벳 순서대로 이름이 지정됩니다. 2019년 4월 10일에 Stein이 Release 되었고, 현재의 마스터 버전( 가장 최신 개발 내용이 적용된 버전)은 Train입니다. 또한 이러한 주기에 맞춰 6개월에 한 번씩 전 세계 도시들에 한 번씩 Summit을 열어 새로운 업데이트 내용을 발표하거나 새로운 프로젝트, 여러 주제들을 발표하는 자리를 마련하기도 합니다.
Openstack은 코드를 포함하는 실제 프로젝트를 의미하는 것이 아닙니다. Openstack은 커뮤니티의 이름이고, 실제 코드로 구현된 프로젝트들은 Nova, Neutron 등의 이름으로 존재하게 됩니다. 아마 30개가 넘는 프로젝트들이 있습니다. 그중에서도 Openstack을 구성하는데 필수적인 프로젝트를 코어 프로젝트라고 하는데 컴퓨팅, 네트워크, 이미지, 저장소 등의 기능을 제공하는 프로젝트 등을 의미합니다.
Openstack은 이제 새롭다기보다는 기본적인, 익숙한 프로젝트입니다. 따라서 이번 포스팅에서는 Openstack의 방대한 내용을 다루기보다는 Openstack이 무엇인지 궁금한 분들께서 Openstack에 대해 감을 잡으실 수 있도록 큰 그림으로 각 코어 프로젝트들을 간략하게 설명하겠습니다.
Openstack Architecture
이번 포스팅에서는 우선적으로 큰 그림에서 Openstack 아키텍처를 연구해보고, Openstack의 기본적인 구성요소 Message Queue, Restful API 등과 함께 전체 구성을 확인한 뒤, 프로젝트 하나하나 한번 어떤 구성을 가지는지 확인해보도록 하겠습니다.
*이미지 출처 : [2]
그림 2에서는 Openstack 구조를 나타냅니다. 사실 여기 나와 있는 프로젝트만 보더라도 굉장히 복잡해 보이는데, 여기에 여러 프로젝트를 추가할 경우 더욱 복잡해질 수 있습니다.(오픈스택에 포함된 프로젝트가 30개가 넘습니다.) 이번 포스팅에서는 Nova, Neutron, Keystone, Glance, Horizon에 대해서만 다룰 예정이므로 해당 구조에서는 앞에서 언급한 5개의 프로젝트에 대해서만 봐주시면 될 것 같습니다.
Openstack은 Horizon이라는 웹 UI와 CLI를 지원하고 있습니다. 어찌 되었든 Horizon에서 버튼을 누르거나 CLI 명령어를 입력하여 Client 라이브러리를 통해 Restful API를 요청합니다. 요청을 보내기 전에는 keystone이라고 불리는 인증 프로젝트로부터 토큰 값을 가져와 각 프로젝트의 API에 접근할 수 있는 권한을 받아옵니다.
성공적으로 권한을 받고 만약 가상 머신을 생성할 경우 nova-api에게 Restful API를 통해 가상 머신 생성을 요청합니다. 그럼 nova-api는 nova 프로젝트를 구성하는 여러 프로세스들에게 Message Queue 즉 RabbitMQ와 같은 메시지 서비스를 이용하여 내부적으로 상호 작용을 하거나, 정보를 교환합니다. 최종적으로 nova 프로젝트는 KVM과 같은 하이퍼바이져에게 가상 머신 생성을 요청합니다.
대략적으로 말씀을 드렸으나, Opnstack은 이렇게 여러 프로젝트들의 상호작용을 통해 클라우드 서비스를 이용하는데 제일 중요한 것은 프로젝트와 프로젝트 사이에서는 HTTP Restful API를 이용하고, 한 프로젝트 내부의 여러 프로세스들은 메시지 큐를 이용해 통신합니다.
Core(1) : Nova
*이미지 출처 : [1]
Openstack에서 가장 중요한 프로젝트 중 하나인 Nova는 Openstack Compute Project로 가상 머신의 라이프사이클을 관리하고 있습니다. 따라서 VM 생성/삭제에 대한 명령은 모두 Nova를 통해 이루어지게 됩니다. 뿐만 아니라 주기적인 헬스체크를 통해 Openstack을 구성하는 하드웨어 Controller 노드와 Compute노드 간의 연결도 점검하고 있습니다.
*이미지 출처 : [3]
그림 4에서는 Nova 구조를 나타냅니다. Nova-API에 접근하기 위해서는 Keystone으로부터 먼저 접근 권한을 얻어야 합니다. 프로그래밍 레벨에서 Keystone 접근 권한은 사용자 아이디 패스워드 등을 Keystone 클라이언트 라이브러리에게 보내어 토큰을 받는 방식이 있습니다. 이후 Nova-API에게 HTTP Restful API를 통해 명령 수행 전달합니다. 이후 Nova-API는 내부 컴포넌트들에게 명령을 전달하기 위해 HTTP 요청에서 Message Queue로 변경하기도 합니다.
[구성요소]
DataBase : 프로젝트와 관련된 정보들이 저장되는데 Nova의 경우에는 API 정보(주소 등이 들어갑니다.), 가상 머신 정보(상태, 생성시기 등)등이 데이터 베이스 저장되고 필요시 데이터 베이스를 통해 읽어지게 됩니다.
Scheduler : 해당 컴포넌트는 잔여 리소스에 따라 어떤 노드에 인스턴스를 생성할지를 결정합니다.
Neturon : 가상 머신 생성 후 Nova는 Neutron에게 요청하여 생성된 가상 머신의 네트워크 설정을 요청합니다.
Compute : 최종적으로 가상 머신을 생성하기 위해 하이퍼바이져(KVM 등)에게 생성 명령을 요청하거나 가상 머신과의 상호 작용을 담당하고 있습니다.
Conductor : 가상 머신의 스케일 관련 작업(Resize)을 수행합니다. 또한 문서에서는 데이터베이스 프락시, 오브젝트 변환을 처리한다고 합니다. 아마 오브젝트 변환에 대한 처리는 가상 머신 스냅샷을 찍게 되면 Swift에 이를 오브젝트로 저장할 수 있는데, 스냅샷을 오브젝트로 변환한다는 말이 아닐까 합니다.
여기까지가 Nova에 대해 간략히 설명을 드렸습니다. 간단하게 말씀드리면, Nova api는 가상 머신 생성 요청을 받으면 Message queue를 통해 각 컴포넌트와 상호작용을 진행합니다. 각 컴포넌트들은 필요한 명령을 수행하면서 Neutron, Glance와 같이 외부 프로젝트와 연동하고 최종적으로 하이퍼바이져를 통해 가상 머신을 생성합니다.
Core(2) : Neutron
*이미지 출처 : [1]
지금부터는 Openstack Network 프로젝트인 Neutron에 대해 설명드리겠습니다. 클라우드에서 가장 어려운 부분을 뽑으라면 아마 네트워크 파트를 뽑을 수 있을 것 같습니다. L2, L3 뿐만 아니라 Routing, Floating ip, VLAN, VXLAN, GRE 등과 같은 네트워크 기능이 소프트웨어로 구현되어 있고 그들에 대한 기본적인 지식이 필요합니다. 따라서 너무 깊게 설명하기보다는 대충 이런 기능이 있다 정도만 봐도 괜찮을 것 같습니다.
*이미지 출처 : [4]
그림 6에서는 비교적 간단한 Neutron의 컴포넌트들을 나타내고 있습니다. 먼저 Neutron 또한 Database를 가지고 있습니다. 여기에 저장되는 정보로는 서브넷, 라우터, 포트, ip 등이 저장되어 있고 필요시 neutron-server는 데이터 베이스 접근하여 사용자에게 정보를 제공하기도 합니다.
Neutron 또한 Nova와 마찬가지로 내부 통신은 Message Queue로 이루어지고 L2, L3, DHCP agent 등이 있습니다. 먼저 그럼 DHCP부터 알아보겠습니다. DHCP는 Dynamic Host Configuration Protocol의 약자로 IP 주소를 동적으로 할당합니다. 반대의 경우에는 Static 즉 정적 할당이 있습니다. 따라서 DHCP 에이전트는 네트워크에 DHCP 서비스를 제공하게 됩니다. 실제로 가상 머신이 특정 네트워크에 연결될 경우 DHCP 서비스가 활성화되어 있다면 네트워크 주소가 랜덤 하게 할당됩니다. 또한 DHCP의 범위까지 설정할 수 있습니다.
Openstack 네트워크에서는 가상 라우터 즉 L3 기능을 제공합니다 L3는 3 계층으로 IP를 이용해 VM과 외부 네트워크 간 통신을 위한 NAT 기능을 제공하게 됩니다. 따라서 실제로 특정 컴퓨트 노드의 가상 머신이 외부로 패킷을 보내기 위해서는 컨트롤러 노드의 L3-에이전트가 제공하는 기능이 필요합니다. L2-agent는 무엇일까요? 마찬가지로 2 계층 네트워크 통신을 위한 기능을 제공하고 있습니다. 한마디로 L3-agent는 라우터가 하는 역할을 가상으로 Openstack 내부적으로 제공하고, L2-agent는 스위치가 하는 역할을 가상으로 제공합니다.
이처럼 Neutron은 여러 계층의 에이전트를 통해 가상화된 내부 네트워크를 구축하고 있습니다. 이를 통해 가상 머신이 외부로부터 데이터를 주고받을 수 있도록 합니다. 추가적으로 Neutron은 SDN 컨트롤러와 연결하기 위한 plugin agent를 제공하고 있습니다.
Core(3) : Keystone
*이미지 출처 : [1]
이번에는 Openstack의 Authentication Project인 Keystone에 대해 설명드리겠습니다. Keystone은 Nova, Neutron에 이어 굉장히 중요한 프로젝트입니다. 모든 프로젝트에 접근하기 위한 키를 쥐고 있기 때문에 Openstack 클라우드 보안에 핵심적인 역할을 하고 있습니다.
그림 8에서는 Keystone 구조를 나타내는데 사실 구조는 굉장히 단순합니다. 다른 프로젝트들에서 HTTP 송수신 및 내부에 Message Queue를 전달하는 API 프로세스와 동일하게 Keystone은 Keystone-all이라는 프로세스를 가지고 있습니다.
만약 다른 API 프로세스에게 접근하기 위하 인증 요청을 Keystone을 통해 하게 되고 Keystone은 Database으로부터 값을 비교하거나 새로운 값을 저장하게 됩니다( 이때 보통 사용자 아이디, 패스워드, 테넌트 이름 등이 요구됩니다.) 이렇게 Keystone으로부터 인증을 받게 되면 토큰 값이 되돌아오게 되는데 이를 통해 다른 프로젝트에게 요청을 보낼 수 있습니다.
Keystone에 대해 더 깊게 설명하려면, 내부적인 프로그램 프로세스를 참고해야 합니다. 따라서 단순하게 Keystone을 통해 인증값을 받고 인증값이 다른 프로젝트에게 API 요청을 할 수 있도록 만드는 열쇠라고 생각하시면 될 것 같습니다.
Core(4) : Glance
*이미지 출처 : [1]
Openstack에서는 가상 머신을 생성할 때 어떤 가상 머신을 생성하는지에 대해 Image가 필요합니다. 이는 Ubuntu, Suse 등과 같은 리눅스 배포판의 이미지입니다. 이들은 Cloud 전용 이미지에서 Qcow2 이미지 즉 QEMU라고 불리는 에뮬레이터에서 동작하기 위한 이미지로 변환됩니다. 따라서 해당 이미지는 계속 저장되어 있다가 Nova가 VM을 생성할 때 Nova의 호출에 따라 이미지를 불러오고 해당 이미지를 바탕으로 가상 머신을 생성하게 됩니다.
*이미지 출처 : [5]
그림 10에서는 Openstack Glance 구조를 나타냅니다. Glance에 대해서 깊게 보는 것은 양이 너무 많기 때문에 이번에는 위에서 언급한 것처럼 큰 그림만 보도록 하겠습니다. 마찬가지로 CLI 혹은 Web UI를 통해 Keystone 인증을 받습니다. 그 뒤 해당 인증을 통해 Glance에 접근하게 됩니다. 그다음 필요한 이미지 정보를 데이터베이스에서 가져오고, 미리 저장된 이미지를 불러와 가상 머신을 생성할 수 있도록 합니다. Qcow2등 Glance를 통해 생성한 이미지는 로컬 파일 시스템에서 확인할 수 있습니다.
Core(5) : Horizon
Horizon은 간단하게 웹 UI를 의미합니다. CLI가 명령어의 집합으로 사용자의 명령어를 Client 라이브러리를 통해 각 프로젝트들에게 전달한다면, Horizon은 웹 UI를 통해 사용자의 명령을 받아들이고 이를 HTTP를 이용하여 각 프로젝트들에게 전달하게 됩니다.
그림 12에서는 Openstack Dashboard를 나타냅니다. 좌측에는 여러 가지 기능을 사용할 수 있는 패널들이 존재하고 각 패널의 클릭했을 때 프로젝트에게 요청을 하게 됩니다. 요청된 데이터는 중앙에 띄워서 관리자가 Dashboard를 통해 데이터를 확인할 수 있도록 합니다. 참고로 Horizon은 Python Django를 기반으로 합니다.
결론
이번 포스팅에서는 오픈스택 코어 프로젝트 전반에 걸쳐서 간략하게 큰 그림으로 이해하는 것을 목표로 설명하였습니다. 내용이 방대하기 때문에 깊이보다는 어떤 콘셉트의 프로젝트인지 이해를 돕고자 하였습니다.
혹 틀리거나 잘못된 내용이 있다면 피드백 주시면 즉시 수정하겠습니다.
감사합니다.
인용글
[1] Openstack Logo : https://www.openstack.org/brand/openstack-logo
[2] Openstack Architecture : https://docs.openstack.org/install-guide/get-started-logical-architecture.html
[3] Openstack Nova Architecture : https://docs.openstack.org/nova/pike/user/architecture.html
[4] Openstack Neutron Architecture : https://docs.openstack.org/security-guide/networking/architecture.html
[5] Openstack Glance Architecture : https://docs.openstack.org/glance/pike/contributor/architecture.html
업데이트로그
------------------------------------------------------------------------------------------------------------------------------
해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.