티스토리 뷰
지금까지 오픈스택이 무엇인지, 레드햇 오픈스택의 배포방식과 배포 프로세스, 버전별 오픈스택 컨테이너 기술 변화등을 알아보았습니다. 이번 포스팅에서는 RHOSP13(Red Hat OpenStack Platform 13) 버전과 RHOSP16 버전의 시스템 아키텍처를 알아보고, 컨테이너화된 오픈스택 서비스 운영을 알아보도록 하겠습니다.
RHOSP13 and RHOSP16 시스템 아키텍처
오픈스택 13 버전 설치가 완료되면 아래 아키텍처처럼 언더클라우드에 컨테이너 이미지를 다운로드 받기 위한 Docker 데몬과 레지스트리가 설치됩니다. 그리고, 오픈스택 서비스들은 여전히 패키지 방식으로 설치되어 프로세스로 실행됩니다. 오버클라우드에는 컨테이너를 실행하기 위한 Docker 데몬이 프로세스로 실행되며, 그 위에 오픈스택 서비스들이 모두 컨테이너로 실행이 됩니다. 컴퓨트 노드에는 KVM 하이퍼바이저가 실행중이며, 컨테이너로 실행중인 Nova 서비스에 가상서버(VM)가 생성됩니다.
오픈스택 16 버전은 RHEL 8에 설치가 되며, 언더클라우드와 오버클라우드의 오픈스택 서비스가 모두 컨테이너로 실행이 됩니다.
언더클라우드에는 컨테이너 이미지를 다운로드 받을 Podman 레지스트리만 설치가 되며, Podman은 Docker와 다르게 데몬으로 실행되지 않습니다. 대신 Podman 라이브러리를 통해 컨테이너 개개별로 프로세스처럼 실행이 됩니다. 오픈스택 16 버전으로 오면서 오버클라우드에서 사용하던 OpenvSwitch 는 이제 OVN으로 구성되며, 오픈스택 위에 오픈쉬프트가 설치되면, Ceilometer와 연동되어 Ceilometer 에서 수집한 데이터들을 오픈쉬프트의 Prometheus와 Grapana에서 확인할 수 있습니다.
컨테이너화 된 오픈스택 서비스 운영
오픈스택 서비스 설치가 끝난 후에도 필요에 의해 환경설정을 변경할 수 있고, 트러블슈팅을 위해 서비스 로그 등을 확인해야 할 경우가 종종 발생을 하곤 합니다. 하지만, 이젠 기존 패키지 방식으로 설치된 오픈스택 환경처럼 운영할 수 없습니다. 그렇다고 컨테이너에 접속해 환경설정을 수정한다고 해서 해당 설정이 적용이 되는것은 아닙니다. 환경설정을 적용하기 위해서는 컨테이너를 재실행해야 하는데, 컨테이너 내에서 수정한 환경설정 내용은 컨테이너가 재실행되는 순간 초기화가 되기 때문입니다.
따라서, 컨테이너화 된 오픈스택 환경을 잘 이해해야 오픈스택 서비스를 잘 운영할 수 있습니다. 오픈스택 각각의 서비스들은 해당 서비스에 맞게 환경설정과 로그를 저장하는 디렉토리가 별도로 매핑되어 있습니다. 환경설정 파일 같은 경우에는 /var/lib/config-data/puppet-generated 디렉토리에 가면 서비스별 디렉토리가 있고, 해당 서비스 디렉토리에 들어가면 환경설정을 수정할 수 있습니다. 그리고, 수정을 하면 반드시 컨테이너를 재실행해야만, 수정한 환경설정을 적용할 수 있습니다. 로그를 확인할 경우에는 /var/log/containers 디렉토리에서 각 오픈스택 서비스의 로그들을 확인할 수 있습니다. 이는 컨테이너화 된 모든 오픈스택 버전에서 동일하게 적용됩니다.
컨테이너화가 되면서 오픈스택 서비스들은 마이크로 서비스화가 되었습니다. 따라서, 각 오픈스택 서비스별로 자원을 함께 공유하기도 하고, 로그 디렉토리 역시 서비스별로 함께 사용을 합니다. 오픈스택의 컨테이너 서비스들은 모든 컨테이너가 호스트 네트워크를 사용하며, 서비스들이 유기적으로 연결되어 있습니다.
오픈스택 운영에서 중요한 건 Docker와 Podman의 커맨드 사용법일 것입니다. Docker Client의 커맨드와 Podman의 커맨드는 매우 유사합니다. Docker와 Podman 커맨드를 이용하여 컨테이너, 이미지, 네트워크, 볼륨 및 시스템을 관리할 수 있으며, 커맨드 사용법 또한 동일합니다. 대신 Docker 커맨드에는 Podman 커맨드에서 제공하지 않는 6가지 기능이 있으며, Podman 에는 Docker에서 제공하지 않은 2가지 기능이 존재합니다.
Docker는 기본 기능 이외에 Swarm, Swarm node를 관리할 수 있는 명령어와 Plugins, Secrets, Services 및 Docker Stack를 관리할 수 있는 명령어가 있습니다. Swarm은 Docker Engine이 설치된 노드들을 클러스터링화하고, 관리하기 위한 기능입니다. 이외에 기존에 존재하는 볼륨이나 네트워크, 인증 등을 추가하고 관리할 수 있는 Plugin 기능이 별도로 존재하며, Redis나 MariaDB와 같은 서비스를 구성하기위한 Services 기능등이 존재합니다. Podman은 컨테이너를 관리하기 위한 핵심 기능들만 Docker와 동일한 명령어 셋을 지원하며, Docker에는 없는 Pod라는 개념이 있으며, 이를 관리할 수 있는 기능이 존재합니다. 그리고, 컨테이너가 정상적으로 수행되고 있는지를 체크하는 healthcheck 기능이 있습니다.
이렇게 해서 총 3편에 걸쳐 오픈스택의 컨테이너 기술에 대해 알아보았습니다. 다음 포스팅에서는 오픈쉬프트를 중심으로 한 컨테이너 기술들을 살펴보겠습니다.
'Cloud' 카테고리의 다른 글
쿠버네티스! 오픈쉬프트! 그리고 컨테이너 II (1) | 2020.11.24 |
---|---|
쿠버네티스! 오픈쉬프트! 그리고 컨테이너 I (0) | 2020.11.16 |
오픈스택과 컨테이너 II (1) | 2020.11.09 |
오픈스택과 컨테이너 I (0) | 2020.11.06 |
컨테이너 역사 (1) | 2020.11.04 |
- Total
- Today
- Yesterday
- 컨테이너
- install
- Swift
- 설치
- Python
- openstack
- 우분투
- ubuntu
- Network
- command
- NOVA
- 하둡
- 김미경
- sdn
- Java
- 레드햇
- 명령어
- neutron
- 오픈쉬프트
- 쿠버네티스
- 후기
- cpu
- 뉴트론
- Redhat
- 파이썬
- 오픈스택
- 클라우드
- OVN
- 세미나
- 네트워크
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |