성규 유Openstack-Ansible
안녕하세요. 이번에는 Openstack에서 Ansible의 장점을 취합하여 구성하는 Openstack-Ansible 에 대해서 알아보고 구성에서 중요한 openstack_user_config YAML 파일을 뜯어보고자 합니다.
1. Openstack
Openstack은 가상자원을 사용하는 IaaS 형태의 클라우드 컴퓨팅 오픈소스 플랫폼입니다.
특징으로 Private / Public 클라우드를 구축하고 관리하는데 용이하며 컴퓨팅, 네트워킹, 스토리지, 인증 등의 각종 서비스들이 모듈화되어 구성이 가능합니다.
가장 큰 장점으로 프라이빗 클라우드를 추가 비용없이 구축하는데 매우 용이한 점을 들 수있고, 모듈의 추가/삭제/변경을 지원하여 최적화하기 좋다는 점 또한 무시할 수 없습니다.
허나, 6개월의 짧은 수명 주기를 가지고 있는 점과 방대한 개별 벤더의 모듈을 적용하기까지 어려우며 노드별로 확장될 경우 상대적으로 안정성이 떨어진다는 단점을 가지고 있습니다.
2. Ansible
Ansible은 IaC 기반의 네트워크 장비를 포함한 인프라 관리 소프트웨어 도구로, 소프트웨어 프로비저닝, 자동화된 설정 관리, 애플리케이션 배포가 가능한 오픈소스 프로젝트입니다.
특징으로 멱등성, 지속적인 배포, 보안 및 신뢰성에 크게 중점을 두고 있고 사용자 친화적으로 분산 구조 설계가 가능합니다.
장점으로 역시 YAML 언어로 구성이 가능해 쉽고 단순한 구조로 접근성, 가독성이 높으며 변수 기능으로 재사용성을 크게 끌어올릴 수 있다는 점입니다.
그에 따른 단점은 다른 인프라 관리 도구에 비해 덜 강력하다는 점, DSL로 로직을 수행하기 때문에 수시로 문서 확인을 하며 점검해야하는 점, 변수를 사용하나 확인이 어려워 복잡성이 증가되는 점, 개별 파일마다 형식의 일관성이 없는 점, 위 문제들의 복합적인 문제로 성능 속도가 저하되는 점 등이 있습니다.
3. Openstack-Ansible
따라서 Openstack의 개별 노드마다 사용자가 직접 설정함으로 일관성을 해칠 가능성을 배제하며 구축의 난이도를 낮추기 위한 방안으로 Ansible와 결합된 Openstack-Ansible 프로젝트가 Openstack Mitaka (Ver. 13)부터 시작되었습니다.
장점으로는 인프라, 벤더 별로 나누어진 모듈들에 대한 일관성을 상대적으로 높일 수 있고 동일 구성 노드에 대한 추가, 삭제가 매우 용이하다는 점입니다. 또한, 상대적으로 강력한 Openstack으로 인해 Ansible의 단점인 약한 퍼포먼스가 보완됩니다. 빠른 검증을 위한 AIO(All-in One) 툴을 제공하는 것도 특징입니다.
역시 단점 또한 존재하는데, Openstack의 구축 난이도가 상당히 낮춰졌으나 YAML 파일 작성법 등 사용이 어느정도 숙지되어야 하는 점이 있으며, 전반적으로 구성을 사전에 계획적으로 진행해야 합니다. 그에 따라 사용중인 모듈에 대한 추가, 삭제에 어려움이 있을 수 있으며 구성 변경 시 고려해야 하는 사항이 기존에 비해 많습니다.
상기한 단점을 감안하더라도 Openstack-Ansible은 매력적인 도구로 생각되며, 다양한 활용 방안을 생각해 볼 수 있을 것 같습니다.
4. 구성 요소
Openstack-Ansible의 구성 요소는 다음과 같습니다.
필수
– Deployment Host
– Infrastructure Control Plane Host
선택
– Log Server
– Compute Host
– NAS
권장 구성은 위의 그림과 같으며 상황에 맞추어 변동이 있을 수 있습니다.
이 중 가장 기반이 되는 Deployment Host 는 최소 사양이 다음과 같습니다.
HW 요구 사항
– 8 CPU
– 16 GB Memory
– 80GB 이상의 디스크 용량
SW 요구 사항 (Openstack Bobcat / 2023.05 Release 기준)
– SSH
– Python 3.8.x / Python 3.10.x
– locale en.US_UTF8
테스트는 상기 요구 사항을 준수하여 진행되었으나 이번 게시글에서는 별도의 구축 테스트는 설명하지 않으니 참고 부탁드리겠습니다.
동일한 내용은 https://docs.openstack.org/openstack/openstack-ansible 에서 확인 가능합니다.
AIO 설치과정
그림과 같이 Deployment host와 Target hosts를 먼저 준비하고 deployment 설정을 진행한 후
Ansible playbook을 실행하여 Openstack operation 검증하는 과정을 거쳐 Openstack을 사용할 수 있게 합니다.
지원하는 OS는 SUSE, Rocky 8/9(구 CentOS), Ubuntu 20/22.04 를 각각 지원합니다.
개인적으로 테스트를 진행은 Rocky 9을 Deployment Host의 OS로 사용하였으나, 하단에 기술될 YAML 파일에서는 어느 OS를 사용하여도 무방합니다.
5. openstack_user_config
구축 과정 중 필수로 준비되어야 하는 openstack_user_config.yml YAML 파일에 대해 알아보겠습니다.
이 파일에서는 Openstack를 구성하는 모듈에 대해서 구술된 YAML 파일로 최초 Openstack-ansible 설치 시 example 파일로 확인할 수 있습니다.
설명은 구간별로 진행됩니다.
(1) Networks
cidr_networks:
container: 172.29.236.0/22
tunnel: 172.29.240.0/22
used_ips: 172.29.244.0/22
snet: 172.29.248.0/22
used_ips:
- 172.29.236.1
- "172.29.236.100,172.29.236.200"
- "172.29.240.100,172.29.240.200"
- "172.29.244.100,172.29.244.200"
provider_networks:
- network:
group_binds:
- all_containers
- hosts
type: "raw"
container_bridge: "br-mgmt"
container_interface: "eth1"
container_type: "veth"
ip_from_q: "management"
is_management_address: true
- network:
group_binds:
- glance_api
- cinder_api
- cinder_volume
- nova_compute
type: "raw"
container_bridge: "br-storage"
container_type: "veth"
container_interface: "eth2"
container_mtu: "9000"
ip_from_q: "storage"
- network:
group_binds:
- neutron_linuxbridge_agent
container_bridge: "br-vxlan"
container_type: "veth"
container_interface: "eth10"
container_mtu: "9000"
ip_from_q: "tunnel"
type: "vxlan"
range: "1:1000"
net_name: "vxlan"
- network:
group_binds:
- neutron_linuxbridge_agent
container_bridge: "br-vlan"
container_type: "veth"
container_interface: "eth11"
type: "vlan"
range: "101:200,301:400"
net_name: "vlan"
- network:
group_binds:
- neutron_linuxbridge_agent
container_bridge: "br-vlan"
cont ainer_type: "veth"
container_interface: "eth12"
host_bind_override: "eth12"
type: "flat"
net_name: "flat"
nova, neutron의 네트워크 관련 설정으로
각각 사용 용도에 맞추어 Deployment용 네트워크, Storage용 네트워크, 클라우드용 네트워크로 구분되었습니다.
group_bind 항목으로 모듈에 대한 관리가 이루어짐을 확인할 수 있습니다.
(2) Infrastructure
shared-infra_hosts:4
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
repo-infra_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
coordination_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
os-infra_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
identity_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
network_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
network-infra_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
network-agent_hosts:
net1:
ip: 172.29.236.201
net2:
ip: 172.29.236.202
net3:
ip: 172.29.236.203
compute_hosts:
compute1:
ip: 172.29.236.121
storage-infra_hosts:
infra1:
ip: 172.29.236.101
infra2:
ip: 172.29.236.102
infra3:
ip: 172.29.236.103
storage_hosts:
lvm-storage1:
ip: 172.29.236.131
host의 IP 설정 구간입니다. 각각 101~103까지 Infra host에 할당하고 모듈마다 묶어주었습니다.
Deployment host는 별도로 분리하여 작성된 점 확인할 수 있습니다.
(3) Storage
container_vars:
cinder_storage_availability_zone: cinderAZ_1
cinder_default_availability_zone: cinderAZ_1
cinder_backends:
lvm:
volume_backend_name: LVM_iSCSI
volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group: cinder-volumes
iscsi_ip_address: "{{ cinder_storage_address }}"
limit_container_types: cinder_volume
container_vars:
cinder_storage_availability_zone: cinderAZ_2
cinder_default_availability_zone: cinderAZ_1
cinder_backends:
netapp:
volume_backend_name: NETAPP_iSCSI
volume_driver: cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_family: ontap_7mode
netapp_storage_protocol: iscsi
netapp_server_hostname: hostname
netapp_server_port: 443
netapp_login: username
netapp_password: password
container_vars:
cinder_storage_availability_zone: cinderAZ_2
cinder_default_availability_zone: cinderAZ_1
cinder_backends:
limit_container_types: cinder_volume
qnap:
volume_backend_name: "QNAP 1 VOLUME"
volume_driver: cinder.volume.drivers.qnap.QnapISCSIDriver
qnap_management_url : http://10.10.10.5:8080
qnap_poolname: "Storage Pool 1"
qnap_storage_protocol: iscsi
qnap_server_port: 8080
iscsi_ip_address: 172.29.244.5
san_login: username
san_password: password
san_thin_provision: True
container_vars:
cinder_storage_availability_zone: cinderAZ_3
cinder_default_availability_zone: cinderAZ_1
cinder_backends:
limit_container_types: cinder_volume
volumes_hdd:
volume_driver: cinder.volume.drivers.rbd.RBDDriver
rbd_pool: volumes_hdd
rbd_ceph_conf: /etc/ceph/ceph.conf
rbd_flatten_volume_from_snapshot: 'false'
rbd_max_clone_depth: 5
rbd_store_chunk_size: 4
rados_connect_timeout: -1
volume_backend_name: volumes_hdd
rbd_user: "{{ cinder_ceph_client }}"
rbd_secret_uuid: "{{ cinder_ceph_client_uuid }}"
container_vars:
manila_default_share_type: cephfs1
manila_backends:
cephfs1:
driver_handles_share_servers: False
share_backend_name: CEPHFS1
share_driver: manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_conf_path: /etc/ceph/ceph.conf
cephfs_auth_id: manila
cephfs_cluster_name: ceph
cephfs_enable_snapshots: False
filter_function: "share.size >= 0"
goodness_function: "share.size >= 0"
container_vars:
manila_default_share_type: cephfsnfs1
manila_backends:
cephfsnfs1:
driver_handles_share_servers: False
share_backend_name: CEPHFSNFS1
share_driver: manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_ganesha_server_ip: 172.16.24.200
cephfs_protocol_helper_type: NFS
cephfs_conf_path: /etc/ceph/ceph.conf
cephfs_auth_id: manila
filter_function: "share.size >= 0"
goodness_function: "share.size >= 0"
container_vars:
manila_default_share_type: nfs-share1
manila_backends:
nfs-share1:
share_backend_name: NFS_SHARE1
share_driver: manila.share.drivers.lvm.LVMShareDriver
driver_handles_share_servers: False
lvm_share_volume_group: manila-shares
lvm_share_export_ips: 10.1.1.1
filter_function: "share.size >= 0"
goodness_function: "share.size >= 0"
container_vars:
manila_default_share_type: generic
manila_backends:
generic:
share_backend_name: GENERIC
share_driver: manila.share.drivers.generic.GenericShareDriver
driver_handles_share_servers: True
service_instance_flavor_id: 100
service_image_name: manila-service-image
service_instance_user: manila
service_instance_password: manila
interface_driver: manila.network.linux.interface.BridgeInterfaceDriver
filter_function: "share.size >= 0"
goodness_function: "share.size >= 0"
Storage는 가용 가능한 모듈들이 전부 작성되어 있으며, 크게 iscsi , ceph, manila로 구성 가능한 점 확인할 수 있습니다.
이런 스토리지 플랫폼을 cinder와 연동하여 구성하도록 작성되어 있으며, 별도의 가용영역을 구별하여 동시에 선택할 수 있는 점이 눈에 띕니다.
(4) HA Proxy
haproxy_hosts:
lb1:
ip: 172.29.236.100
lb2:
ip: 172.29.236.101
in ``user_variables.yml``:
haproxy_keepalived_external_vip_cidr: 192.168.0.4/25
haproxy_keepalived_internal_vip_cidr: 172.29.236.54/16
haproxy_keepalived_external_interface: br-flat
haproxy_keepalived_internal_interface: br-mgmt
추가로 이중화 구성을 위해 HA Proxy, Keepalived가 기본 구성으로 포함되어 있습니다.
nat 구성에 따라 별도의 interface를 할당 또한 지원합니다.
6. 정리
Ansible의 장점인 다양한 Inventory로 인한 모듈 제공 및 사용성 , Openstack의 높은 호환성과 구현력이 합쳐져 시너지를 낼 수 있게 도와주는 어플리케이션이라고 보여집니다.
물론 Puppet, Chef 등의 다른 관리 시스템 사용, 혹은 100%의 Application Container로 Openstack을 배포하고자 하는 경우, deb나 rpm으로 서비스 배포를 시도하는 경우에는 적합하지 않을 수 있다고 Openstack-Ansible 가이드 문서에서도 명시가 되어 있는 사항임으로 반드시 선택 전 고려를 해야합니다.
허나 LXC Container를 이용하여 상대적으로 적은 코드로 Openstack의 배포를 하고자 하는 경우 Openstack-Ansible은 좋은 선택이 될 수 있을듯 합니다.
다음 글에서는 상기 작성된 YAML 파일을 포함하여 구축 방법에 대해 상세히 알아보고 운영 방법, 활용법에 대해 알아보겠습니다.
감사합니다.