holssi 님의 블로그
CloudStack 공식문서 보면서 이해 및 설치해보기 (1) 본문
apache cloudstack
공식문서: https://cloudstack.apache.org/
대규모 가상 머신 네트워크를 배포하고 관리하는 오픈소스 클라우드 컴퓨팅 플랫폼
- 다양한 하이퍼바이저 지원: KVM, vSphere(VMware), XenServer, Hyper-V, LXC 및 BareMetal을 지원
한 클라우드 내에서 여러 하이퍼바이저 동시 사용 가능
- 인스턴스 배포시 네트워크 및 스토리지 설정 자동 구성
- REST 방식의 API와 AWS EC2 호환 레이어 제공
필요한 것들
배포 아키텍처
관리서버, 관리 대상 리소스로 구성
배포 과정에서 IP 주소 블록, 스토리지 장치, 하이퍼바이저, VLAN과 같은 리소스 대상 관리를 관리 서버에 등록함
최소 설치 단위는 단일 머신이 관리 서버와 하이퍼바이저 호스트(단, 하이버파이저가 KVM일때)임
관리 서버
- 리소스 조정 및 할당
- apache tomcat 컨테이너에서 실행되고 mysql DB가 필요함
- cloudstack api 제공 및 ec2 인스턴스 위한 api 제공
- 공인 및 사설 ip 주소 할당
- 스토리지 할당
- 스냅샷, ISO 이미지 관리
클라우드 인프라 개요
1. 리전: 관리 서버에 의해 관리되는 하나 이상의 존의 집합
각 리전은 존 중 하나에서 실행되는 자체 관리 서버 클러스터에 의해 제어됨
2. 존: 하나의 데이터 센터, 존은 하나 이상의 파드와 보조 스토리지로 구성
하나의 데이터 센터에 여러 존을 두는 것도 허용함
존 구성
- 하나 이상의 파드: 각 파드에는 하나 이상의 호스트 클러스터와 하나 이상의 기본 스토리지 서버 포함
- 존내의 모든 파드가 공유하는 하나 이상의 기본 스토리지 서버 포함
- 존 내의 모든 파드가 공유하는 보조 스토리지
public, private 둘다 존재하고, private은 특정 도메인을 위해 예약되어 있음
동일 존에 있는 호스트들은 방화벽을 거치지 않고 서로 직접 액세스 가능, 서로 다른 존에 있는 호스트들은 구성된 vpn 터널을 통해 서로 액세스 가능함
* 각 존에 대해 관리자 결정 사항
- 각 존에 배치할 파드 수
- 각 파드에 배치할 클러스터 수
- 각 존에 배치할 기본 스토리지 서버 수와 해당 스토리지 서버의 총 용량
- 보조 스토리지 양
3. 파드: 스위치와 하나 이상의 클러스터를 포함하는 랙 또는 랙의 행
동일한 파드 내에서 호스트들은 동일한 서브넷에 속하게 됨
4. 클러스터: 하나 이상의 동일한 호스트와 기본 스토리지로 구성
호스트들을 그룹화함. xenserver 서버 풀, KVM 서버들의 집합, vCenter에서 미리 구성된 VMware 클러스터
하나의 클러스터 내에 있는 호스트들은 모두 동일한 하드웨어, 하이퍼바이저, 동일한 서브넷에 속하고, 동일한 공유 기본 스토리지에 액세스함.
동일 클러스터내의 호스트 간에는 사용자 서비스 중단 없이 인스턴스를 라이브 마이그레이션함
클러스터의 크기는 하이퍼바이저에 의해 제한됨
5. 호스트: 컴퓨팅 노드이고 주로 하이퍼바이저
호스트는 critrix xenserver, linux kvm 지원 서버, esxi 서버 또는 windows hyper-v 서버가 될 수도 있음
동일한 클러스터 내의 호스트들은 반드시 사양이 동일해야함
호스트 작동을 위한 필수 작업들
- 호스트에 하이퍼바이저 소프트웨어 설치
- 호스트에 IP 주소 할당
- 호스트가 CloudStack 관리 서버(나는 build 서버)가 연결되어 있는지 확인
6. 기본 스토리지: 실제 실행 중인 인스턴스 디스크 이미지를 위해 단일 클러스터에 제공되는 스토리지 리소스
호스트에서 실행되는 모든 인스턴스의 가상 디스크 저장함
kvm 및 vmware 환경에서는 zone 단위로 기본 스토리지를 할당(프로비저닝)할 수도 있음
cloudstack은 특정 기본 스토리지 장치에 게스트 가상 디스크를 할당하는 작업을 자동으로 관리함
* 존 단위 스토리지: 불필요한 데이터 복사 작업을 피하고 싶을때 유용하고, 클러스터 기반 스토리지를 사용하면 해당 클러스터 내의 인스턴스만 데이터에 직접 접근할 수 있음. 만약 다른 클러스터의 인스턴스가 해당 데이터를 사용하게 된다면, 존의 보조 스토리지를 거쳐 클러스터 간 복사 과정을 거쳐야하며 상당한 시간을 소모함
* 하이퍼바이저별 지원 사항
- hyper-v: SMB/CIFS 스토리지 지원, 존 단위 기본 스토리지는 지원하지 않음
- kvm: Ceph/RBD 스토리지 지원하며, 이를 존 단위 기본 스토리지로 사용할 수 있음. 또한 PowerFlex/ScaleO(v3.5)를 클러스터 단위 또는 존 단위로 사용할 수 있음
* 지원 서버
cloudstack은 하이퍼바이저가 지원하는 모든 표준 준수 iSCSI 및 NFS 서버와 호환됨
cloudstack 4.19.1.0 버전부터는 기본 스토리지 범위를 존 전체에서 클러스터 전체로 변경 가능(해당 기본 스토리지를 비활성화한 후에만 범위 변경 옵션이 나타남, KVM 환경의 NFS, KVM 환경의 CEPH/RBD, VMware 환경의 NFS 지원 및 테스트 완료)
7. 보조 스토리지: 디스크 템플릿, ISO 이미지 및 스냅샷을 저장하는 존 단위 리소스
- 템플릿: 인스턴스 부팅하는데 사용되는 OS 이미지
- ISO 이미지: 데이터나 OS 부팅 미디어를 포함하고 있는 디스크 이미지
- 디스크 볼륨 스냅샷: 인스턴스 데이터의 저장된 복사본
* 객체 스토리지: 존 기반의 NFS 보조 스토리지 외에 객체 스토리지를 추가하면, 클라우드 전체의 모든 호스트가 데이터 공유 가능함. 이 경우 nfs를 사용할때처럼 리소스를 존마다 일일이 복사할 필요 없이 어디서든 접근 가능함
hyper-v 호스트의 경우 SMB/CIFS 스토리지 지원함
* 객체 스토리지 플러그인(Swift/S3): cloudstack은 Openstack Switft와 Amazon S3를 지원하는 플러그인 제공함
전체 cloudstack 환경에 Swift나 S3를 설정한 후에, 각 존마다 NFS 보조 스테이징 스토어를 설정함
모든 템플릿과 데이터는 먼저 각 존의 NFS 스테이징 영역을 거친 뒤 Swift나 S3로 전달됨
백엔의 객체 스토리지가 클라우드 전체 리소스 역할을 하므로, 클라우드 내의 어떤 존에서도 동일한 데이터에 접근할 수 있음
8. 객체 스토리지
데이터를 객체 단위로 관리하는 데이터 저장소
지원되는 객체 스토리지 시스템 설정 및 이를 cloudstack에 객체 스토리지 풀로 추가
사용자는 객체 스토리지 풀 내에 버킷을 생성할 수 있음
9. 공유 파일 시스템
nfs를 통해 마운트할 수 있는 cloudstack 관리형 공유 파일 시스템 설정할 수 있음
사용자는 서비스 오퍼링(사양), 디스크 오퍼링, 파일 시스템 형식 및 네트워크를 직접 선택할 수 있음
* 작동 방식
1. 지정된 서비스 오퍼링을 사용해 별도의 인스턴스에 공유 파일 시스템이 배포됨
2. 선택한 디스크 오퍼링을 통해 데이터 볼륨이 생성되고 해당 인스턴스에 연결됨
3. 사용할 파일 시스템 지정
4. 데이터 볼륨 위에 해당 파일 시스템이 생성되고, NFS를 통해 외부로 내보내기가 됨
10. 물리적 네트워크 (실제 네트워크 하드웨어와 배선)
각 존에는 하나 또는 그 이상의 물리적 네트워크를 연결할 수 있음
이 네트워크는 하이퍼바이저 호스트에 있는 NIC에 대응됨
각 물리적 네트워크는 하나 이상의 네트워크 트래픽 유형을 처리할 수 있음
각 네트워크에서 선택할 수 잇는 트래픽 유형은 기본 네트워크 존인지, 어드밴스드 네트워크 존인지에 따라 달라짐
관리자는 다음과 같은 작업을 수행
- 존 내의 물리적 네트워크 추가, 제거 및 업데이트
- vlan 구성
- 하이퍼바이저가 해당 네트워크를 인식할 수 있도록 이름 구성
- 서비스 프로바이더 설정: 방화벽, 로드밸런서 등 해당 물리적 네트워크에서 사용할 수 있는 서비스 제공자 구성
- ip 주소 구성: 물리적 네트워크로 트렁킹되는 IP 주소 구성
* 트렁킹: 하나의 물리적 연결(선)을 통해 여러 개의 서로 다른 네트워크(vlan) 정보 동시에 전달
- 일반 포트: 하나의 선에 하나의 네트워크 정보만 흐름
- 트렁크 포트: 하나의 선에 여러 개의 태그(VLAN ID)를 붙인 패킷들이 섞여서 흐름
* 물리적 네트워크로 트렁킹 된다라는 뜻: 하이퍼바이저 호스트에 연결된 물리적 스위치 포트가 트렁크 모드로 설정되어 있어야하며, 이 선을 통해 여러 VLAN에 속한 IP 패킷들이 태그를 달고 한꺼번에 들어온다
* 네트워크 업링크: 하위 장비에서 상위 계층의 장비로 연결되는 경로
11. 기본 존의 네트워크 트래픽 유형
기본 네트워크를 사용할때는 존 내의 단 하나의 물리적 네트워크만 존재할 수 있음
물리적 네트워크는 다음과 같은 트래픽 유형을 처리함
- 게스트: 엔드 유저가 인스턴스를 실행할때 발생하는 트래픽, 인스턴스들은 게스트 네트워크라고 불리는 네트워크를 통해 서로 통신함
기본 존에서 각 파드는 하나의 브로드캐스트 도메인이며, 따라서 각 파드마다 게스트 네트워크를 위한 서로 다른 IP범위를 가짐
- 관리: cloudstack 내부 리소스들이 서로 통신할때 발생하는 트래픽, 호스트, 시스템vm, cloudstack 관리 서버와 직접 통신하는 기타 컴포넌트간의 통신이 여기에 해당됨, vm이 사용할 ip 범위 구성
- 퍼블릭: 기본 존에는 별도의 퍼블릭 트래픽이 존재하지 않음. 인스턴스를 인터넷에 노출하고 싶은 경우 게스트 네트워크에 공인 라우팅이 가능한 IP 대역을 할당
- 스토리지: 보조 스토리지 트래픽이고 기본 스토리지 트래픽에는 영향을 주지 않음. 템플릿이나 스냅샷 등이 보조 스토리지 vm과 보조 스토리지 서버 사이를 오갈때 발생하는 트래픽. cloudstack에서는 이를 위해 스토리지 NIC라는 별도의 네트워크 인터페이스를 사용함. 고대역폭 네트워크에서 작동하는 스토리지 NIC를 사용하면 템플릿, 스냅샷 빠르게 복사 가능, 스토리지 네트워크용 IP 범위 구성
* NetScaler 로드 밸런스를 사용하고 ELP(Elastic IP) 및 ELB 기능을 활성화한다면, 퍼블릭 트래픽을 처리할 네트워크도 함께 구성해야됨
12. 기본 존 게스트 IP
기본 네트워크를 사용하는 경우, cloudstack은 해당 파드 내의 게스트들에게 파드의 CIDR 범위 내에 있는 IP 주소를 할당함
관리자는 파드에 Direct IP 범위를 추가해야하고, 이 IP들은 호스트와 동일한 VLAN에 속함
13. 어드밴스드 존 네트워크 트래픽 유형
어드밴스드 네트워크를 사용하는 경우 존 내에 여러 개의 물리적 네트워크가 존재할 수 있음
각 물리적 네트워크는 하나 이상의 트래픽 유형을 처리, 관리자는 cloudstack에 각 네트워크가 어떤 유형의 트래픽을 처리할지 설정해야함
1) 게스트: 엔드 유저가 인스턴스를 실행할때 발생하는 트래픽, 인스턴스들은 게스트 네트워크를 통해 서로 통신함
이 네트워크는 격리형과 공유형으로 설정
- 격리형: 각 계정별로 네트워크 격리를 제공하기 위해 VLAN 범위 예약
- 공유형: 모든 게스트 인스턴스가 단일 네트워크 공유함
2) 관리: cloudstack 내부 리소스 간의 통신 트래픽, 호스트, 시스템vm, cloudstack 관리 서버와 직접 통신하는 컴포넌트 간의 통신이 포함됨
3) 퍼블릭: guest 인스턴스는 가상 라우터를 통해 외부 시스템으로 트래픽을 라우팅, 사용자는 UI를 통해 퍼블릭 IP를 획득해서 게스트 네트워크와 퍼블릭 네트워크 간의 NAT 구현
4) 스토리지: 보조 스토리지 트래픽, 기본 스토리지 트래픽에는 영향을 주지 않음. 템플릿이나 스냅샷이 보조 스토리지 VM과 서버 사이를 오갈때 발생하는 트래픽, 고대역폭의 별도 스토리지 NIC를 사용하여 빠른 복사를 지원, 전용 IP 범위를 구성해야함
14. 어드밴스드 존 게스트 IP 주소
관리자는 게스트가 사용할 추가 네트워크를 생성할 수 있음
이 네트워크는 존 전체에 걸쳐 모든 계정이 사용할 수도 있고, 특정 계정 전용으로 제한될 수도 있음
각 네트워크는 VLAN ID, IP범위, 게이트웨이로 정의됨
15. 어드밴스드 존 퍼블릭 IP 주소
게스트가 외부와 통신할때 사용할 추가 퍼블릭 네트워크를 생성할 수 있음
zone 전체에 걸쳐 모든 계정이 사용할 수 있도록 설정하거나, 특정 계정으로만 범위를 제한해서 해당 계정에서 생성된 게스트만 연결되도록 할 수 있음
각 네트워크는 VLAN ID, IP범위, 게이트웨이로 정의됨
16. 시스템 예약 IP 주소
각 zone에서 관리 네트워크를 위한 예약 IP 주소 범위를 구성해야함
cloudstack 관리 서버, 보조 저장소 VM, 콘솔 프록시 VM, DHCP 등 다양한 시스템 VM 간의 통신 담당
예약 IP주소는 클라우드 전체에서 고유해야함. 한 영역의 호스트가 다른 영역의 호스트와 동일한 사설 IP를 가질 수 없음
파드 내의 호스트, 콘솔 프록시 및 보조 저장소 시스템 VM 역시 생성된 파드의 CIDR 내에서 사설 IP를 할당받음
파드에서 사용 가능한 사설 IP 수는 하이퍼바이저 유형에 따라 달라짐
- citrix xenserver & kvm: 링크 로컬 주소를 사용하며, 65000개 이상의 IP를 제공하므로 호스트나 게스트 가상 라우터 확장에 충분함
- vmware esxi: 관리자가 지정한 서브넷 방식을 사용, 보통 255개의 ip를 제공함
* 링크 로컬 주 소: 복잡한 설정 없이 같은 네트워크(링크)안에 있는 장치들끼리만 통신하기 위해 사용하는 자동 할당 주소
네트워킹 개요
1. 기본(basic): 단일 플랫 계층 2네트워크 제공, 게스트 격리는 하이퍼바이저의 브리지 장치를 통해 계층3에서 제공
2. 고급(advanced): vlan과 같은 계층 2 격리 사용, Nicira NVP와 같은 SDN 기술도 포함
설치
소스 코드 직접 빌드 및 배포 방식 -> 효율적이지 않음
깃 clone 방식 -> 불안정한 코드가 포함되어 있읠 수 있음(빌드 과정에서 문제가 발생할 경우, 깃헙의 cloudstack 이슈 페이지 확인)
0. 2대로 구성 + 네트워크 및 방화벽 설정
- management server + nfs server: db(mysql), 가상 머신 이미지, 스냅샷 저장
- compute node: 가상 머신 생성 및 돌아가는 하이퍼바이저 노드
공식 문서에서 ubuntu, centos/rhel(rpm) 지원
| management server + nfs server (build node) |
compute node | |
| vcpu | 4 | 4(인텔 VT-x 또는 AMD-V 가상화 지원 필수) |
| RAM | 16 | 16 |
| Disk | 100GB | 100GB |
| OS | rocky8 | rocky8 |
- cpu: 빌드 속도 및 자바 애플리케이션 실행 고려
- RAM: MYSQL DB, 관리 UI 서비스
- Disk: OS+빌드 소스+Secondary Storage용 NFS 공간 확보
gcp는 가상화 환경(nested virtualization), 네트워크 인터페이스(NIC) 제약이 잇으므로, 설치하기 전에 3가지 확인
1. gcp 인스턴스에서 가상머신 실행하려면 중첩 가상화 활성화 필수
머신 타입 중에 E2 시리지는 중첩 가상화를 제공하지 않아서, compute node 만들때 --enable-nested-virtualization 추가
gcloud compute instances create compute \
--zone=asia-northeast3-a \
--machine-type=n2-standard-4 \
--image-family=rocky-linux-8 \
--image-project=rocky-linux-cloud \
--boot-disk-size=100GB \
--boot-disk-type=pd-standard \
--enable-nested-virtualizationcompute 노드에서 grep -E 'vmx|svm' /proc/cpuinfo 으로 중첩 가상화 확인
방화벽 설정
management <-> compute: 8080(ui), 8250(에이전트 통신, cloudstack protocol binary messaging), 16509(libvirt, 다양한 가상화 기술을 일관된 방식으로 제어하기 위한 오픈소스 API), 22(ssh)
스토리지 (nfs): 111, 2049(secondary storage로 nfs를 쓸 경우)
gcp 콘솔에서 해당 인스턴스들에 IP 전달(IP Forwarding) 옵션을 On으로 설정
1. cloudstack 4.22.0.0 소스 빌드 및 설치 (build 노드)
# 개발 도구 그룹 설치
sudo dnf groupinstall "Development Tools" -y
# Java 11, Maven, MySQL 커넥터 등 필수 패키지 설치
sudo dnf install -y java-11-openjdk-devel genisoimage mysql mysql-server ws-commons-util python3-setuptools createrepo
# Node.js 12 설치 (CloudStack UI 빌드용)
curl -sL https://rpm.nodesource.com/setup_12.x | sudo bash -
sudo dnf install -y nodejs하던 중 ws-commons-util 패키지 떄문에 에러남 -> rocky8의 기본 레포지토리에는 해당 패키지가 포함되어 있지 않아서 발생함
cloudstack 빌드에 필요한 라이브러리는 EPEL 레포에 잇거나 소스 빌드 과정에서 maven이 알아서 라이브러리 형태로 가져옴
cloudstack의 pom.xml(메이븐 설정 파일)에 해당 라이브러리가 의존성으로 정의되어 있어서, 빌드 시점에 maven이 중앙 저장소에서 직접 .jar 파일을 내려 받음
2. 소스 코드 확보 및 검증 (build 노드)
소스 다운로드하고 GPG 키로 무결성 확인
# 1. 소스 파일 (tar.bz2)
wget https://downloads.apache.org/cloudstack/releases/4.22.0.0/apache-cloudstack-4.22.0.0-src.tar.bz2
# 2. 검증 서명 파일 (asc)
wget https://downloads.apache.org/cloudstack/releases/4.22.0.0/apache-cloudstack-4.22.0.0-src.tar.bz2.asc
# 3. KEYS 임포트
wget https://downloads.apache.org/cloudstack/KEYS
gpg --import KEYS
# 4. 서명 확인
gpg --verify apache-cloudstack-4.22.0.0-src.tar.bz2.asc
# 5. 압축 해제 및 다음 단계
tar -jxvf apache-cloudstack-4.22.0.0-src.tar.bz2
cd apache-cloudstack-4.22.0.0-src
3. maven 수동 설치 (build 노드)
# 1. Maven 바이너리 다운로드 (3.8.x 버전 권장)
wget https://archive.apache.org/dist/maven/maven-3/3.8.6/binaries/apache-maven-3.8.6-bin.tar.gz
# 2. 압축 해제 및 이동
tar -xzvf apache-maven-3.8.6-bin.tar.gz
sudo mv apache-maven-3.8.6 /opt/maven
# 3. 환경 변수 설정 (어디서든 mvn을 쓸 수 있게)
sudo tee /etc/profile.d/maven.sh <<EOF
export M2_HOME=/opt/maven
export PATH=\$M2_HOME/bin:\$PATH
EOF
# 4. 환경 변수 적용
source /etc/profile.d/maven.sh
cd /root/apache-cloudstack-4.22.0.0-src
mvn -P deps
4. build 노드에서 빌드
cd ~/apache-cloudstack-4.22.0.0-src/packaging/
./package.sh -d el8
에러. 자바 버전 충돌, rpm 빌드 의존성 미달
자바 버전 확인 및 변경
# 1. Java 11 선택 (목록에서 11버전 숫자를 입력하세요)
sudo alternatives --config java
# 2. Java 컴파일러도 11로 선택
sudo alternatives --config javac
# 3. 환경변수 즉시 적용 (Maven이 참조하도록)
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk
export PATH=$JAVA_HOME/bin:$PATH
# 4. 버전 확인 (11.x.x 가 나와야 합니다)
java -version
rpm 빌드 의존성 미달
# 1. 부족한 패키지 설치
sudo dnf install -y jpackage-utils
# 2. NodeJS 설치 (아까 설치했는데 안 잡힌다면 다시 확인)
sudo dnf install -y nodejs
다시 빌드
# 소스 루트로 이동
cd /root/apache-cloudstack-4.22.0.0-src
# 1. 기존 빌드 기록 삭제 (Clean)
mvn clean
# 2. 의존성 해결 (테스트 제외 옵션 추가)
# -DskipTests: 유닛 테스트를 건너뛰어 빌드 속도를 높이고 위와 같은 테스트 에러를 방지합니다.
mvn -P deps -DskipTests
# 3. 다시 패키징 시도
cd packaging/
./package.sh -d el8
5. 생성된 패키지 확인
# 빌드 서버(Build)에서 실행
find / -name "cloudstack-management-4.22*.rpm" 2>/dev/null하니까 아무것도 출력이 안됨
# 1. RPM 빌드에 필요한 유틸리티 설치
sudo dnf install -y jpackage-utils nodejs
# 2. 패키징 스크립트 다시 실행 (이 과정이 성공해야 파일이 생깁니다)
cd ~/apache-cloudstack-4.22.0.0-src/packaging/
./package.sh -d el8
node.js 버전이 너무 낮아서 발생
현재 설치된 node.js는 10.24.0인데, cloudstack 4.22의 최신 UI 라이브러리들은 최소 14,16,18 버전 요구
npm install 과정에서 라이브러리 빌드(deasync)에 실패하고 전체 RPM 빌드 중단됨
기존 node.js 제거 및 18 버전 설치
# 1. 기존 nodejs 모듈 스트림 초기화
sudo dnf module reset nodejs -y
# 2. Node.js 18 (LTS) 스트림 활성화
sudo dnf module enable nodejs:18 -y
# 3. Node.js 및 관련 도구 재설치
sudo dnf install -y nodejs npm
버전 확인
node -v
클린 빌드 시도
# 소스 루트로 이동
cd ~/apache-cloudstack-4.22.0.0-src
# 1. 빌드 찌꺼기 제거
mvn clean
# 2. 패키징 재시도 (테스트 제외 옵션 권장)
cd packaging/
./package.sh -d el8
rpm 패키지 위치 확인
find / -name "cloudstack-*.rpm" 2>/dev/null
# RPM 파일이 있는 디렉토리로 이동
cd /root/apache-cloudstack-4.22.0.0-src/dist/rpmbuild/RPMS/noarch/
# 관리 서버 및 공통 패키지 설치
sudo dnf install -y cloudstack-management-4.22.0.0-1.noarch.rpm \
cloudstack-common-4.22.0.0-1.noarch.rpm \
cloudstack-ui-4.22.0.0-1.noarch.rpm
6. 데이터베이스 설정
cloudstack은 SELinux가 Enforcing 상태일떄 정상 작동하지 않을 수 있음
# 즉시 적용 (휘발성)
sudo setenforce 0
# 영구 적용 (재부팅 시에도 유지)
sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
# MySQL 서비스 시작
sudo systemctl enable --now mysqld
# DB 초기화
sudo mysql -u root
ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
FLUSH PRIVILEGES;
EXIT;
7. 서비스 상태 확인 및 접속
톰캣 서비스 자체는 떠 있는데 cloudstack 애플리케이션(war)이 정상적으로 초기화되지 못했거나 내부 오류로 중단된 상태
로그를 보니 cloudstack 매니지먼트 서버가 구동되면서 각 모듈(xenserver-discoverer, secondary-storage 등)의 applicaiton context를 불러오지 못하고 계속 해매고 있음
cloudstack이 초기활될때 필수적으로 불러와야하는 설정 리소스(bean)을 찾지 못해서 발생하는 문제
해결
1. cloudstack 데이터베이스 초기화 확인 및 DB 설정 스크립트 재실행
cloudstack-setup-databases cloud:1234@localhost --deploy-as=root:1234
2. 설치된 cloudstack 4.22 버전은 기존의 componentContext.xml 파일 대신 기능별로 분리된 여러 개의 spring 설정 파일들을 조합해서 사용하는 모듈형 구조로 변경되었음
모듈 로딩 설정 파일 확인
cloudstack은 /etc/cloudstack/management/ 디렉토리에 있는 classpath나 모듈 정의 파일을 통해 위에서 찾은 수많은 xml 파일들을 긁어모음 (해당 디렉토리에 db.properties, server.properties 있는지 확인)
누락된 템플릿 강제 복사
빌드된 패키지 구조상 /etc로 가야할 파일들이 소스 폴더에만 머물러 있을 수 있음. 소스 내의 client/conf 디렉토리에 있는 설정 파일들을 수동으로 넣어줌
# 소스 폴더의 conf 내용을 관리 폴더로 복사
sudo cp -r /root/apache-cloudstack-4.22.0.0-src/client/conf/* /etc/cloudstack/management/
# 소유권 변경
sudo chown -R cloud:cloud /etc/cloudstack/management/
http://[Management_Server_외부_IP]:8080/client로 들어가면 됨
