오픈스택 아키텍처 살펴보기

오픈스택은 프로젝트 마다 자신의 고유 기능을 갖고 있으며 서로 유기적으로 연결된다고 할 수 있습니다. 예를 들어 Nova 는 VM (Virtual Machine) 생성/삭제/조회와 관련된 기능을 갖고 있으며, Glance 는 OS 이미지 생성/삭제/조회 기능을 갖고 있습니다. VM 을 생성하기 위해서는 OS 이미지 파일이 필요한데 Glance 와 통신하여 이미지를 가져옵니다. 오픈스택의 프로젝트는 모두 다음과 같은 공통점이 있습니다.

  • Rest API 를 위한 API 서버가 있다.
  • 비지니스 로직을 담당하는 1이상의 데몬 서버가 있다.
  • 인증을 위한 Keystone 플러그인이 있다.
  • Rest API 를 쉽게 호출할 수 있게 client 라이브러리를 가지고 있다.
  • 필요한 메타 데이터 정보는 DB 를 활용한다.

위와 같은 공통된 아키텍처의 특징 때문에 다음과 같은 규칙도 있습니다.

  • 프로젝트간 통신은 Rest API 를 사용한다. 예를 들어 Nova 서버에서 Glance API 서버에 호출하기 위해서는 Nova 서버에 python-glanceclient 라이브러리를 import 해서 쉽게 호출할 수 있습니다.
  • 프로젝트내에 데몬 간의 통신은 Queue 를 통해서 한다. Queue 를 활용할 때도 규칙이 있는데 이 부분은 소스를 설명하면서 추후에 하도록 하겠습니다.

Conceptual architecture

아래 다이어그램은 중요 프로젝트에 대한 오픈스택의 conceptual architecture 입니다.

openstack_kilo_conceptual_arch

출처 : http://docs.openstack.org/admin-guide/common/get-started-conceptual-architecture.html#get-started-conceptual-architecture

오픈스택은 Infrastructure 를 제공하는 S/W 이므로 결국 VM 을 중심으로 모든 작업이 이루어집니다. 그런 의미에서 VM 이 중심에 있고, 나머지 박스는 각 프로젝트를 표현하고 있습니다. (개인적으로 제 마음에는 안들지만 따로 그리기에는 힘들어서 그냥 이대로) Horizon 이나 CLI 를 통해 VM create 요청이 오면 Nova API 서버가 제일 먼저 요청을 받습니다. Nova 는 Keystone 을 호출해서 인증을 체크하고 리소스 스케줄링으로 VM 이 생성될 Compute Host 서버를 선정합니다. 이어서 Neutron 을 호출해서 네트워크의 fixed ip (private ip) 를 결정한 후 Glance 를 호출해서 OS 이미지를 가져옵니다. 이 때 Glance 가 바라보는 이미지 저장소는 Swift, file system, Ceph 등 다양하게 지정할 수 있습니다. 마지막으로 하이퍼바이저를 호출해서 VM 인스턴스를 생성합니다. 각각의 과정은 단계별 진행사항을 알 수 있도록 상태값을 데이터베이스에 저장합니다.

어떻게 보면 오픈스택은 MSA (Microservices Architecture) 아키텍처로 구성되어 있습니다. 각 서비스들이 Rest API 로 통신하고 이런 서비스를 lookup 할 수 있게 Keystone 을 통해서 endpoint 서비스를 제공하고 있습니다. 물론 서비스 하나의 덩치가 이제는 무지 커졌긴 하지만 말입니다.

Nova API

오픈스택 소스를 분석할려면 entry point 인 API 서버 부터 시작해야 하는데 처음 소스를 접한다면 제대로 이해하기가 쉽지 않습니다. 서비스를 어떻게 시작하는지, 프로세스는 몇 개를 띄우는지를 설명하지는 않겠습니다. 여기서는 HTTP Request 가 어떻게 Routing 되는지를 설명하도록 하겠습니다.

우선 제일 먼저 Nova 소스를 아래와 같이 받습니다.

$ git clone http://git.openstack.org/openstack/nova.git && cd nova/nova

다른 프로젝트의 소스들은 다음의 링크에서 받을 수 있습니다. https://git.openstack.org/cgit

1 레벨 디렉토리만을 표시하여 보여주고 있으며 API 는 두번째 폴더인 api 폴더에 있습니다.

nova-directory

API 는 WSGI 및 Routes 라이브러리를 활용하는데 오픈스택은 Oslo 라는 OpenStack Common Libraries 를 통해서 지원을 하고 있습니다. Oslo 는 python 라이브러리의 장점이자 단점인 디펜던시 때문에 나타난 프로젝트로 데몬 서비스와 같은 공통적인 부분을 관리하고 있습니다.

서비스를 Invoke 하는 부분은 nova/wsgi.py 에 나와 있습니다.

nova_wsgi_src

URI 에 포함되는 단어로 python 파일을 invoke 하는 구조 입니다. 예를 들어 VM 을 생성하는 URI는 POST 방식의 "/servers" 로 필요한 인자 값은 HTTP Request Body 로 보내며, VM 리스트를 조회하는 URI 는 GET 방식의 "/servers" 입니다. 이렇게 URI 가 servers 라면 해당 소스는 nova/api/openstack/compute/servers.py 를 호출하게 됩니다. POST 방식의 VM 의 생성은 servers.py 의 ServersController 클래스내 create 메소드를 호출하게 됩니다.

nova_api_openstack_compute_servers_src_png

create 메소드에서는 인자로 넘어온 Request 객체와 Body 객체를 활용해서 클라이언트가 요청한 VM 생성 파라미터값을 파싱하여 이후 로직을 타게 됩니다.

다음에는 API 이후에 진행되는 VM 생성 소스를 살펴보도록 하겠습니다.

Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.