OpenStack 활용 가이드 (1)

OpenStack 활용 가이드

오픈스택을 이용하는 방법은 크게 세 가지라고 생각됩니다.

• CLI를 활용 - 관리자 친화적

• Horizon Dashboard 활용 - 이용자 친화적

• API 활용 - 개발자 친화적

  편리한 사용을 위해서는 대시보드화로 귀결됩니다. 처음으로 오픈스택을 활용하는 법을 배울 때, 오픈스택 튜토리얼 문서에서는 CLI로 설명하지만, Horizon Dashboard로 맛을 보는게 훨씬 더 부담감이 덜하고 진입장벽이 낮을 것 같습니다.

  사실, 설치가 어렵지 오픈스택 사용은 번거롭다는 느낌일 뿐 그다지 어려운 부분은 없습니다. 사용이 어렵다는 것, 기대한 대로 작동이 안 된다는 것은 사실 설치가 잘못되어 있을 가능성이 큽니다.

우선 VIP 대역으로 호라이즌에 접속해 로그인 합시다. /etc/kolla/admin-openrc.sh 파일에 적혀있는대로 아이디는 admin 입니다. 초기 화면은 아래와 같습니다.

이제 왼편 메뉴바에서 필요한 부분들을 살피며, 실제로 오픈스택을 활용하는 방법을 알아보려고 합니다. (앞서 init-runonce을 구동하지 않았다는 가정입니다)

책 ‘쉽게 따라하는 IaaS 구축 가이드(가상화를 이용한 OpenStack 구축)’의 구조와 설명을 많이 활용하였습니다.

1. Project

   프로젝트는 OpenStack의 소프트웨어 instance에 대한 특정 권한을 통해 공통 액세스를 공유하는 1명 이상의 사용자로 구성된 독립적인 그룹이다. project의 개별 entity로 구성된 각 instance 및 network 집합에 대해 project가 생성된다.

   오픈스택에서 프로젝트는 과거에 테넌트(Tenant)라고 불렸습니다. 임차인이란 뜻을 가진 테넌트라는 용어가 왜 사용되었던 걸까요? 바로 클라우드가 가지는 멀티테넌시 성질 때문입니다. 이 문서에 이렇게 표현되어 있습니다.

   멀티테넌시는 단일 소프트웨어 인스턴스로 서로 다른 여러 사용자 그룹에 서비스를 제공할 수 있는 소프트웨어 아키텍처입니다. 서비스로서의 소프트웨어(Software-as-a-Service, SaaS) 제품이 멀티테넌트 아키텍처의 예입니다.

   클라우드 컴퓨팅에서는 서로 다른 고객이 서버 리소스를 나누어 사용하는 공유 호스팅을 멀티테넌시라고 부르기도 합니다.

   멀티테넌시의 반대 개념인 단일 테넌시에서는 소프트웨어 인스턴스 또는 컴퓨터 시스템 하나에 최종 사용자 또는 사용자 그룹이 하나만 있습니다.

   즉 오픈스택에서는 프로젝트를 여러 개 만들어서 하나의 오픈스택 클러스터 하드웨어 자원을 여러 그룹이 나누어 사용할 수 있게 됩니다.

   ‘인증’ → ‘프로젝트’ 를 선택해주시고 ‘프로젝트 생성’을 클릭해주세요.

   프로젝트 정보와 멤버을 보실 수 있으실 텐데 설정에 어려운 부분은 없습니다. 프로젝트의 이름을 적어넣고, admin 사용자를 프로젝트 멤버로 추가하면 되겠습니다.

   

   

   하나의 프로젝트 안에서는 멤버들의 역할을 설정 할 수 있습니다. 예를 들면, 프로젝트 안에 Project Manager, 회계 관리자, 개발자 등등의 역할이 분배되어 있을 때 이를 역할로서 구별해 줄 수 있는 것 입니다. RBAC(Role Based Access Control) 요소라고 볼 수 있겠습니다.

   ‘인증’ → ’역할’을 들어가보시면 여러가지 역할을 만들고 삭제할 수 있습니다. 역할 자체에는 별다른 기능이 들어있지 않습니다. 단순 이름표라고 보시면 됩니다.

   

2. User

   다음은 사용자 추가 하는 방법을 보겠습니다. 현재 저희는 admin 계정으로 오픈스택을 관리하고 있지만, 관리자 권한을 가지지 않은 또 다른 멤버를 추가 해줄 수 있습니다.

   이러한 멤버들은 왼편 항목 중 오픈스택 클러스터 관리와 관련된 부분이 나타나지 않을 것이며 오로지 본인이 포함된 프로젝트 내에서만 활동할 수 있게 됩니다.
   ’인증’ → ‘사용자’ 를 선택하시면 사용자 생성 버튼이 보입니다.

   

   

3. Image

   이미지는 Instance(VM)을 만드는 데 사용됩니다. 부팅 가능한 OS가 설치된 가상 디스크를 포함하는 단일 파일입니다. 윈도우를 설치할 때 사용하는 운영체제 USB 같은 친구라고 생각하시면 됩니다. 다만, 클라우드 환경에서는 cloud-init이 설치된 버젼의 서버 전용 (GUI 사용 x) 운영체제들이 많이 사용됩니다.

   참고로 조금 번거롭긴 하지만, 오픈스택에서 GUI 사용이 가능한 VM을 만들기 위해서는 애초에 GUI가 구동되고 있는 이미지를 만들어 줘야 합니다. (혹은 추후에 gui를 설치하던가요)

   우선 이미지를 등록 하기 전, 필요한 이미지를 다운로드 받아봅시다. 오픈스택 공식 문서 중 이 항목에 사용가능한 이미지를 목록화 시켜 놓았습니다. CirrOS 라는 minimal Linux distribution을 다운 받아봅시다.

   ‘프로젝트’ or ‘관리’ → ‘Compute’ → ‘이미지’ 를 타고 들어오면 다음과 같은 화면이 나타납니다. 위에서 다운 받은 cirros 이미지를 등록 해봅시다. 크기가 작다보니 금방 업로드 됩니다.

   

   

   추가적으로 언급할 만한 부분은 이미지 공유 아래의 가시성 입니다. 이미지를 모든 유저가 사용할 수 있게 할 것인지, 특정 유저 혹은 프로젝트만 사용할 수 있게할 지 지정할 수 있습니다.

   참고로 용량이 큰 centos8_stream.qcow2는 호라이즌 상에서 올라가지 못할 수 있습니다. 그럴 땐 어쩔 수 없이 CLI를 활용해야 합니다. (미래에서 왔는데, 이 이미지 이유를 모르겠는데 ssh 인증이 안되네요…? 못쓸 거 같아요. 우선 등록하는 방법만 인지하고, 추후에 다른 이미지를 찾아봅시다)

   (kolla) $ wget https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-latest.x86_64.qcow2
   (kolla) $ mv CentOS-Stream-GenericCloud-8-latest.x86_64.qcow2 Centos8-Stream.qcow2
   (kolla) $ openstack image create --disk-format qcow2 --public --file ./Centos8-Stream.qcow2 centos8_stream

4. Flavor

   혹시 이전에 구글 클라우드 플랫폼이나, 아마존 웹 서비스를 사용해보신 분들이라면 VM의 하드웨어 자원에 따라 과금 정도가 다른 걸 경험해보신 적 있으실 겁니다. 그런 하드웨어 분류를 정의하는 용어가 Flavor 입니다.

   ‘프로젝트’ or ‘관리’ → ‘Compute’ → ‘Flavor’를 타고 들어오시면 다음과 같은 페이지가 등장합니다.

   

   생성 버튼을 클릭 후 원하는 CPU, RAM, 디스크 spec을 결정하여 저장합시다. 저는 Cirros 용 초 경량 Flavor을 생성했습니다. vcpu 1 개, RAM 1GB, Root 디스크 10GB 입니다.

   

   여기서 vCPU 개념이 나오는데, 일반적으로 하이퍼 쓰레딩 단위로 compute 노드의 CPU수에 따라 사용가능한 단위가 달라집니다. 포항공대의 요구사항(VM 죽이기)을 수행하다 경험적으로 알아낸 사실은, compute 노드 위에서 딱 하나의 vCPU가 VM에 고정적으로 할당되는 것은 아닌 듯 합니다.

   비슷한 케이스로 VMware 운영 상에서 VM 을 생성 할 때 ‘vCPU : 총 할당 vCPU’의 비율을 1 : 3 정도로 배정하는 것이 좋다고 합니다. 1 대 1 할당이 원칙이라고 할 때는 절대로 고려할 수 없는 비율입니다. 1 : 3 수치가 가능한 것은 할당된 VM이 항상 모든 CPU를 100퍼센트 사용하고 있지 않기 때문 입니다.

5. 외부 네트워크

   오픈스택에는 크게 두 가지 개념의 네트워크가 있습니다. provider라고 불리우는 외부(연결)용 네트워크가 있습니다. 오로지 관리자만 생성 및 설정 할 수 있습니다. 외부 네트워크는 유동 IP 주소 풀의 역할을 하며, instance에 대한 외부 액세스를 제공합니다.

   ‘관리’ → ‘네트워크’ → ‘네트워크’ 로 들어가 생성 버튼을 눌러 줍시다.

   

   공급자 네트워크 유형과 물리적인 네트워크를 Flat, physnet1 으로 선택했습니다. 이는 임의로 설정하는 것이 아닌, /etc/kolla/neutron-server/ml2_conf.ini에 정의된 것으로 확인 할 수 있습니다.

   $ cat /etc/kolla/neutron-server/ml2_conf.ini 
   [ml2]
   type_drivers = flat,vlan,vxlan
   tenant_network_types = vxlan
   mechanism_drivers = openvswitch,l2population
   extension_drivers = port_security
   
   [ml2_type_vlan]
   network_vlan_ranges =
   
   [ml2_type_flat]
   flat_networks = physnet1
   
   [ml2_type_vxlan]
   vni_ranges = 1:1000

   

   DHCP 사용을 체크 해제합니다. 왜냐하면 직접적으로 외부 네트워크에 연결되는 것이 아니기 때문입니다.

   

6. 내부 네트워크

   내부 네트워크는 생성된 instance가 사용하는 network 입니다. 공급자 및 인터넷과 같은 외부 network와 상호 작용하려면 가상 router가 필요하며, 일반적으로 instance에 DHCP 및 메타 데이터 서비스를 제공 합니다.

   ‘프로젝트’ → ‘네트워크’ → ‘네트워크’ 생성을 클릭합시다.

   

   (참고 - 아래 스크린샷과 다르게 내부 네트워크의 ip를 10.10.10.0/24 로 변경하였습니다. -> 그런데 이거 또 바뀝니다 밑에서 ㅜㅜ. 값을 따라하지는 마시고, 진행 방법만 봐주세요)

   

7. Router

   네트워크 간의 데이터 패킷을 전달하는 논리적 구성 요소 입니다. L3, NAT 전달을 제공하여 내부 네트워크와 외부 네트워크를 연결해 줍니다.

   ‘프로젝트’ → ‘네트워크’ → ‘라우터’ 에서 생성을 눌러줍시다.

   

   생성 후 목록의 이름을 클릭하여 ‘인터페이스’ 항목으로 들어옵니다.

   

   인터페이스를 다음과 같이 추가합니다.

   

   결과적으로 ‘네트워크 토폴로지’ 상에서 다음과 같은 모습을 확인할 수 있게 됩니다.