Compute 인스턴스의 고가용성
컴퓨팅 인스턴스의 고가용성 구성
초록
1장. 개요
이 가이드에서는 인스턴스 HA(인스턴스 고가용성) 를 구현하는 방법을 설명합니다. 인스턴스 HA를 사용하면 호스트 컴퓨팅 노드가 중단될 때 Red Hat OpenStack Platform이 다른 컴퓨팅 노드에서 인스턴스를 자동으로 다시 붙여넣을 수 있습니다.
인스턴스 HA는 호스트 컴퓨팅 노드가 실패할 때마다 인스턴스 비우기를 자동화합니다. 인스턴스 HA에서 트리거한 비우기 프로세스는 인스턴스 에 설명된 대로 사용자가 수동으로 수행할 수 있는 작업과 유사합니다. 인스턴스 HA는 공유 스토리지 및 로컬 스토리지 환경에서 작동합니다. 즉, 비어 있는 인스턴스가 새 호스트 내의 동일한 네트워크 구성(정적 IP, 유동 IP 등)과 새 호스트 내의 특성을 처음부터 생성하더라도 해당 인스턴스가 동일한 네트워크 구성(정적 IP, 유동 IP 등)을 유지합니다.
인스턴스 HA는 세 가지 리소스 에이전트에 의해 관리됩니다.
에이전트 이름 | 클러스터 내 이름 | Role |
---|---|---|
fence_compute | fence-nova | 노드를 사용할 수 없게 되는 경우 비우기 위해 컴퓨팅 노드 표시 |
NovaEvacuate | nova-evacuate | 실패한 노드에서 인스턴스를 비우고 컨트롤러 노드 중 하나에서 실행됩니다. |
nova-compute-wait | nova-compute-checkevacuate | 작동하는 Compute 호스트로 완전히 비우면 인스턴스에서 Compute 서비스를 다시 시작합니다. |
이 가이드에서는 Ansible을 통해 오버클라우드에서 인스턴스 HA 활성화에 중점을 둡니다. 프로세스를 간소화하기 위해 이 가이드에는 필요한 플레이북이 포함된 사전 패키징된 TAR 아카이브도 포함되어 있습니다.
인스턴스 HA에서 수행하는 감지 및 비우기 프로세스에 대한 간략한 설명은 부록 A. 인스턴스 HA를 통한 자동 제거 에서 참조하십시오.
2장. 환경 요구 사항 및 사용량
인스턴스 HA를 활성화하려면 Red Hat OpenStack Platform 오버클라우드가 다음 요구 사항을 충족해야 합니다.
- 환경은 Red Hat OpenStack Platform director를 사용하여 배포되었습니다. 자세한 내용은 Director Installation and Usage 를 참조하십시오.
- 컨트롤 플레인에서 펜싱이 수동으로 활성화되어 있습니다.
다음 패키지는 모든 노드에 설치됩니다.
-
fence-agents-4.0.11-66.el7_4.3
이상 -
Pacemaker-1.1.16-12.el7.x86_64
이상 -
resource-agents-3.9.5-105.el7.x86_64
이상
-
- 환경은 컴퓨팅 및 컨트롤 플레인을 모두 완전히 중단할 수 있습니다.
- 공유 스토리지는 임시 및 블록 스토리지에 대해 환경 내에서 활성화됩니다. 관련 정보는 2.1절. “공유 스토리지의 예외” 을 참조하십시오.
AMQP(Message Broker)는 각 컴퓨팅 노드의 호스트 이름을 유효한 것으로 인식합니다. 컴퓨팅 노드의 호스트 이름을 확인하려면 다음을 수행합니다.
heat-admin@compute-n $ sudo crudini --get /etc/nova/nova.conf DEFAULT host
각 컴퓨팅 노드는 $OS_AUTH_URL 에 설정된 엔드포인트에 연결할 수 있어야 합니다. 또한 이 환경 변수를 다음과 같이 설정해야 합니다.
- 오버클라우드의 인증 서비스(외부 네트워크에 액세스해야 함) 또는
- 내부 인증 URL입니다.
인스턴스 HA가 활성화되면 오버클라우드 업그레이드 또는 확장 작업이 불가능합니다. 이렇게 하려는 모든 시도는 실패합니다. 여기에는 마이너 업그레이드 및 주요 업그레이드가 포함됩니다.
오버클라우드를 업그레이드하거나 확장하기 전에 먼저 인스턴스 HA를 비활성화합니다. 자세한 내용은 5장. rollback에서 참조하십시오.
3장. Deployment
다음 절차에서는 Ansible 을 사용하여 인스턴스 HA를 활성화하는 것입니다. Ansible에 대한 자세한 내용은 Ansible 설명서를 참조하십시오.
3.1. 필수 Ansible 구성 파일 생성
Ansible을 통해 인스턴스 HA를 활성화하려면 인벤토리 파일 및 SSH 인수 파일이 필요합니다. 두 파일 모두 오버클라우드에서 인스턴스 HA를 구현하는 데 필요한 Ansible 변수를 전달합니다.
인벤토리 파일
인벤토리 파일은 ansible 플레이북의 다른 대상 호스트를 나열합니다. 첫 번째 섹션은 각 노드(이름별)와 함께 각 노드, 사용자 이름, Ansible이 각 플레이북 명령에 사용해야 하는 개인 키 파일을 나열합니다. 예를 들면 다음과 같습니다.
overcloud-controller-0 ansible_host=overcloud-controller-0 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa
두 번째 섹션에는 다음 제목(또는 노드 유형) 아래에 각 노드가 나열됩니다. compute
,undercloud
,overcloud
또는 controller
.
/home/stack/hosts
라는 인벤토리 파일을 생성합니다. 다음 샘플은 이에 필요한 구문을 보여줍니다.
undercloud ansible_host=undercloud ansible_user=stack ansible_private_key_file=/home/stack/.ssh/id_rsa overcloud-compute-1 ansible_host=overcloud-compute-1 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa overcloud-compute-0 ansible_host=overcloud-compute-0 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa overcloud-controller-2 ansible_host=overcloud-controller-2 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa overcloud-controller-1 ansible_host=overcloud-controller-1 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa overcloud-controller-0 ansible_host=overcloud-controller-0 ansible_user=heat-admin ansible_private_key_file=/home/stack/.ssh/id_rsa [compute] overcloud-compute-1 overcloud-compute-0 [undercloud] undercloud [overcloud] overcloud-compute-1 overcloud-compute-0 overcloud-controller-2 overcloud-controller-1 overcloud-controller-0 [controller] overcloud-controller-2 overcloud-controller-1 overcloud-controller-0
언더클라우드와 오버클라우드 모두에서 모든 호스트에 대한 전체 인벤토리를 생성하려면 다음 명령을 실행합니다.
stack@director $ tripleo-ansible-inventory --list
이 명령은 JSON 형식으로 세부적이고 업데이트된 인벤토리를 생성합니다. 자세한 내용은 Ansible Automation 실행을 참조하십시오.
SSH 인수 파일
SSH 인수 파일은 Ansible에 각 대상 호스트에서 플레이북을 실행하는 데 필요한 필수 자격 증명 및 인증 설정을 전달합니다.
다음 명령을 사용하여 SSH 인수 파일을 만듭니다( /home/stack
).
stack@director $ cat /home/stack/.ssh/id_rsa.pub >> /home/stack/.ssh/authorized_keys stack@director $ echo -e "Host undercloud\n Hostname 127.0.0.1\n IdentityFile /home/stack/.ssh/id_rsa\n User stack\n StrictHostKeyChecking no\n UserKnownHostsFile=/dev/null\n" > ssh.config.ansible stack@director $ source /home/stack/stackrc stack@director $ openstack server list -c Name -c Networks | awk '/ctlplane/ {print $2, $4}' | sed s/ctlplane=//g | while read node; do node_name=$(echo $node | cut -f 1 -d " "); node_ip=$(echo $node | cut -f 2 -d " "); echo -e "Host $node_name\n Hostname $node_ip\n IdentityFile /home/stack/.ssh/id_rsa\n User heat-admin\n StrictHostKeyChecking no\n UserKnownHostsFile=/dev/null\n"; done >> ssh.config.ansible
이러한 명령을 수행하면 /home/stack/ssh.config.ansible
이라는 SSH 인수 파일이 생성되고 각 오버클라우드 노드에 대한 호스트별 연결 옵션이 포함됩니다. 예를 들면 다음과 같습니다.
Host overcloud-controller-0 Hostname 192.168.24.11 IdentityFile /home/stack/.ssh/id_rsa User heat-admin StrictHostKeyChecking no UserKnownHostsFile=/dev/null
3.2. 언더클라우드 준비
인벤토리 파일 및 SSH 인수 파일 ( 3.1절. “필수 Ansible 구성 파일 생성”에서)을 생성한 후 이제 인스턴스 HA를 위해 오버클라우드를 준비할 수 있습니다.
-
stack
사용자로 언더클라우드에 로그인합니다. 이 TAR 아카이브 를
/home/stack/
로 다운로드합니다. Ansible을 통해 인스턴스 HA를 활성화하는 데 필요한 플레이북, 역할 및 기타 유틸리티가 포함되어 있습니다.참고여기에 제공된 TAR 아카이브 는 업스트림 GIT 리포지토리의 테스트 및 수정된 버전입니다. 이 리포지토리를 복제하려면 다음을 실행합니다.
stack@director $ git clone git://github.com/redhat-openstack/tripleo-quickstart-utils
이 리포지토리는 통지 없이 업데이트할 수 있으므로 이 단계에서 사용할 수 있는 아카이브와 다를 수 있습니다.
TAR 아카이브를 추출합니다.
stack@director $ tar -xvf ansible-instanceha.tar
다음 콘텐츠를 사용하여
/home/stack/ansible.cfg
를 생성합니다.[defaults] roles_path = /home/stack/ansible-instanceha/roles
ansible.cfg
, hosts(인벤토리 파일) 및ssh.config.ansible
(SSH 인수 파일)을 다음 환경 변수로 내보냅니다.stack@director $ export ANSIBLE_CONFIG="/home/stack/ansible.cfg" stack@director $ export ANSIBLE_INVENTORY="/home/stack/hosts" stack@director $ export ANSIBLE_SSH_ARGS="-F /home/stack/ssh.config.ansible"
-
오버클라우드의 노드 정의 템플릿(기본적으로
instackenv.json
)이/home/stack/
에 있는지 확인합니다. 노드 정의 템플릿에 대한 자세한 내용은 오버클라우드 노드 등록을 참조하십시오.
3.3. 인스턴스 HA 활성화
언더클라우드가 완전히 준비되면 3.2절. “언더클라우드 준비” 에서 다운로드하여 추출한 지정된 플레이북을 실행할 수 있습니다. 이러한 플레이북을 사용하면 컨트롤러 및 컴퓨팅 노드에 대해 STONITH를 구성하거나 구성하지 않고 인스턴스 HA를 활성화할 수 있습니다. STONITH에 대한 자세한 내용은 컨트롤러 노드 펜싱을 참조하십시오.
다음 각 명령에서 RELEASE 를 Red Hat OpenStack Platform Cryostat- Cryostatnamely, rhos-8
.NET 버전의 해당 코드로 바꿉니다.
인스턴스 HA를 활성화하고 컨트롤러 및 컴퓨팅 노드 모두에 대해 STONITH를 구성하려면 다음을 수행합니다.
stack@director $ ansible-playbook /home/stack/ansible-instanceha/playbooks/overcloud-instance-ha.yml \ -e release="RELEASE"
기본적으로 플레이북은 공유 스토리지가 활성화된 instance-ha 솔루션을 설치합니다. 오버클라우드에서 공유 스토리지를 사용하지 않는 경우 instance_ha_shared_storage=false
옵션을 사용합니다.
stack@director $ ansible-playbook /home/stack/ansible-instanceha/playbooks/overcloud-instance-ha.yml \ -e release="RELEASE" -e instance_ha_shared_storage=false
인스턴스 HA의 공유 스토리지에 대한 자세한 내용은 2.1절. “공유 스토리지의 예외” 을 참조하십시오.
컨트롤러 및 컴퓨팅 노드 모두에 대해 STONITH를 구성하지 않고 인스턴스 HA를 활성화하려면 다음을 수행합니다.
stack@director $ ansible-playbook /home/stack/ansible-instanceha/playbooks/overcloud-instance-ha.yml \ -e release="RELEASE" -e stonith_devices=”none”
인스턴스 HA를 활성화하고 컴퓨팅 노드에서만 STONITH를 구성하려면 다음을 수행합니다(예: 컨트롤러 노드에 STONITH가 이미 구성된 경우).
stack@director $ ansible-playbook /home/stack/ansible-instanceha/playbooks/overcloud-instance-ha.yml \ -e release="RELEASE" -e stonith_devices=”computes”
4장. 테스트
다음 절차에는 컴퓨팅 노드의 의도적으로 충돌하는 작업이 포함됩니다. 이렇게 하면 인스턴스 HA를 통해 인스턴스 자동 비우기를 강제 적용합니다.
해당 인스턴스를 호스팅하는 컴퓨팅 노드를 중단하기 전에 오버클라우드에서 하나 이상의 인스턴스를 부팅합니다.
stack@director $ . overcloudrc stack@director $ nova boot --image cirros --flavor 2 test-failover stack@director $ nova list --fields name,status,host
방금 부팅한 인스턴스를 호스팅하는 컴퓨팅 노드에 로그인합니다 (예:
compute-n
).stack@director $ . stackrc stack@director $ ssh -lheat-admin compute-n heat-admin@compute-n $
노드를 충돌합니다.
heat-admin@compute-n $ echo c > /proc/sysrq-trigger
몇 분 후에 이러한 인스턴스가 온라인 컴퓨팅 노드에서 다시 시작되었는지 확인합니다. 확인하려면 다음을 수행합니다.
stack@director $ nova list --fields name,status,host stack@director $ nova service-list
5장. rollback
인스턴스 HA가 활성화되면 업그레이드 또는 확장 작업이 불가능합니다. 이렇게 하려는 모든 시도는 실패합니다. 여기에는 마이너 업그레이드 및 주요 업그레이드가 포함됩니다. 오버클라우드를 업그레이드하거나 확장하기 전에 먼저 인스턴스 HA를 비활성화합니다.
인스턴스 HA를 비활성화하려면 언더클라우드에서 stack
사용자로 다음을 실행합니다.
stack@director $ ansible-playbook /home/stack/ansible-instanceha/playbooks/overcloud-instance-ha.yml \ -e release="RELEASE" -e instance_ha_action="uninstall"
RELEASE 를 해당 버전의 Red Hat OpenStack Platform Cryostat- Cryostatnamely, rhos-8
으로 바꿉니다.
인스턴스 HA를 활성화할 때 stonith_devices
옵션을 사용한 경우 롤백 중에 동일한 옵션을 지정해야 합니다. 예를 들어 인스턴스 HA 구성에 STONITH가 비활성화된 경우( 3.3절. “인스턴스 HA 활성화”에서와 같이) 다음을 사용합니다.
stack@director $ ansible-playbook /home/stack/ansible-instanceha/playbooks/overcloud-instance-ha.yml \
-e release="RELEASE" -e instance_ha_action="uninstall" -e stonith_devices=”none”
부록 A. 인스턴스 HA를 통한 자동 제거
인스턴스 HA를 사용하면 해당 노드가 실패하면 OpenStack에서 컴퓨팅 노드에서 인스턴스를 비우는 프로세스를 자동화합니다. 다음 프로세스는 컴퓨팅 노드 오류 발생 시 트리거되는 이벤트 시퀀스를 설명합니다.
-
컴퓨팅 노드에 실패하면
IPMI
에이전트가 첫 번째 펜싱 을 수행하고 전원이 꺼지도록 노드를 물리적으로 재설정합니다. 온라인 컴퓨팅 노드에서 인스턴스를 비우면 오버클라우드에서 데이터 손상 또는 동일한 여러 인스턴스가 실행될 수 있습니다. 노드의 전원이 꺼지면 펜싱된 것으로 간주됩니다. 물리적 IPMI 펜싱 후
fence-nova
에이전트는 두 번째 수준 펜싱 을 수행하고 fenced 노드를"evacuate=yes"
클러스터 per-node 속성으로 표시합니다. 이를 위해 에이전트는 다음을 실행합니다.$ attrd_updater -n evacuate -A name="evacuate" host="FAILEDHOST" value="yes"
여기서 FAILEDHOST 는 실패한 컴퓨팅 노드의 호스트 이름입니다.
-
nova-evacuate
에이전트는 백그라운드에서 지속적으로 실행되며"evacuate=yes"
속성이 있는 노드에서 주기적으로 클러스터를 확인합니다.nova-evacuate
에서 펜싱된 노드에 이 속성이 있음을 감지하면 에이전트는 Evacuate Instances 에 설명된 대로 동일한 프로세스를 사용하여 노드를 비우기 시작합니다. -
한편 실패한 노드는 IPMI 재설정에서 부팅되는 동안
nova-compute-checkevacuate
에이전트는nova-evacuate
가 비우기로 완료되었는지 확인하기 전에(기본적으로 120초 동안) 대기합니다. 그렇지 않으면 동일한 시간 간격 후에 다시 확인합니다. -
nova-compute-checkevacuate
에서 인스턴스가 완전히 비어 있는지 확인하면 다른 프로세스를 트리거하여 호스트 인스턴스에 펜싱된 노드를 다시 사용할 수 있도록 합니다.
부록 B. Ansible 플레이북을 통해 자동화된 수동 작업
이 문서에서 제공하는 Ansible 기반 솔루션은 지원되는 방식으로 인스턴스 HA를 구성하기 위한 수동 절차를 자동화하도록 설계되었습니다. 참조를 위해 이 부록은 솔루션에 의해 자동화된 단계를 제공합니다.
1. 컴퓨팅 노드에서 libvirtd 및 모든 OpenStack 서비스를 비활성화하여 시작합니다.
heat-admin@compute-n # sudo openstack-service stop heat-admin@compute-n # sudo openstack-service disable heat-admin@compute-n # sudo systemctl stop libvirtd heat-admin@compute-n # sudo systemctl disable libvirtd
2. pacemaker-remote 와 함께 사용할 인증 키를 만듭니다.
컴퓨팅 노드 중 하나에서 이 단계를 수행합니다.
heat-admin@compute-1 # sudo mkdir -p /etc/pacemaker/ heat-admin@compute-1 # sudo dd if=/dev/urandom of=/etc/pacemaker/authkey bs=4096 count=1 heat-admin@compute-1 # sudo cp /etc/pacemaker/authkey ./ heat-admin@compute-1 # sudo chown heat-admin:heat-admin authkey
3. 이 키를 director 노드에 복사한 다음 나머지 컴퓨팅 및 컨트롤러 노드에 복사합니다.
stack@director # scp authkey heat-admin@node-n:~/ heat-admin@node-n # sudo mkdir -p --mode=0750 /etc/pacemaker heat-admin@node-n # sudo chgrp haclient /etc/pacemaker heat-admin@node-n # sudo chown root:haclient /etc/pacemaker/authkey
4. 모든 컴퓨팅 노드에서 pacemaker-remote 를 활성화합니다.
heat-admin@compute-n # sudo systemctl enable pacemaker_remote heat-admin@compute-n # sudo systemctl start pacemaker_remote
5. pacemaker(1.1.12-22.el7_1.4.x86_64
) 및 resource-agents(3.9.5-40.el7_1.5.x86_64
) 패키지의 필수 버전이 컨트롤러 및 컴퓨팅 노드에 설치되어 있는지 확인합니다.
heat-admin@controller-n # sudo rpm -qa | egrep \'(pacemaker|resource-agents)'
6. BZ#1257414 에 필요한 다음 제약 조건 해결 방법을 적용합니다.
이 문제는 RHSA-2015:1862 에서 해결되었으며 환경에 필요하지 않을 수 있습니다.
heat-admin@controller-1 # sudo pcs constraint order start openstack-nova-novncproxy-clone then openstack-nova-api-clone heat-admin@controller-1 # sudo pcs constraint order start rabbitmq-clone then openstack-keystone-clone heat-admin@controller-1 # sudo pcs constraint order promote galera-master then openstack-keystone-clone heat-admin@controller-1 # sudo pcs constraint order start haproxy-clone then openstack-keystone-clone heat-admin@controller-1 # sudo pcs constraint order start memcached-clone then openstack-keystone-clone heat-admin@controller-1 # sudo pcs constraint order promote redis-master then start openstack-ceilometer-central-clone require-all=false heat-admin@controller-1 # sudo pcs resource defaults resource-stickiness=INFINITY
7. overcloudrc 파일을 사용하여 NovaEvacuate 활성/패시브 리소스를 생성하여 auth_url
,username
,tenant
및 password
값을 제공합니다.
stack@director # scp overcloudrc heat-admin@controller-1:~/ heat-admin@controller-1 # . ~/overcloudrc heat-admin@controller-1 # sudo pcs resource create nova-evacuate ocf:openstack:NovaEvacuate auth_url=$OS_AUTH_URL username=$OS_USERNAME password=$OS_PASSWORD tenant_name=$OS_TENANT_NAME \ 1
- 1
- 공유 스토리지를 사용하지 않는 경우 no_shared_storage=1 옵션을 포함합니다. 자세한 내용은 2.1절. “공유 스토리지의 예외”를 참조하십시오.
8. 유동 IP 리소스 및 Image 서비스(glance), OpenStack Networking(neutron), Compute(nova) 서비스 후에 nova-evacuate 가 시작되었는지 확인합니다.
heat-admin@controller-1 # for i in $(sudo pcs status | grep IP | awk \'{ print $1 }\'); do sudo pcs constraint order start $i then nova-evacuate ; done heat-admin@controller-1 # for i in openstack-glance-api-clone neutron-metadata-agent-clone openstack-nova-conductor-clone; do sudo pcs constraint order start $i then nova-evacuate require-all=false ; done
9. 컨트롤 플레인에서 모든 OpenStack 리소스를 비활성화합니다.
heat-admin@controller-1 # sudo pcs resource disable openstack-keystone --wait=540
여기에 사용된 시간 초과(--wait=540)는 예로만 사용됩니다. ID 서비스 중지에 필요한 시간 및 하드웨어의 전원에 따라 시간 초과 기간을 늘리는 것이 좋습니다.
10. cibadmin
데이터를 사용하여 현재 컨트롤러 목록을 생성합니다.
heat-admin@controller-1 # controllers=$(sudo cibadmin -Q -o nodes | grep uname | sed s/.*uname..// | awk -F\" \'{print $1}') heat-admin@controller-1 # echo $controllers
11. 이 목록을 사용하여 이러한 노드를 osprole=controller
속성이 있는 컨트롤러로 태그합니다.
heat-admin@controller-1 # for controller in ${controllers}; do sudo pcs property set --node ${controller} osprole=controller ; done
12. 환경에 이미 존재하는 stonith 장치 목록을 빌드합니다.
heat-admin@controller-1 # stonithdevs=$(sudo pcs stonith | awk \'{print $1}') heat-admin@controller-1 # echo $stonithdevs
13. 컨트롤 플레인 서비스에 태그를 지정하여 위에서 확인한 컨트롤러에서만 실행되도록 하여 나열된 stonith 장치를 건너뜁니다.
heat-admin@controller-1 # for i in $(sudo cibadmin -Q --xpath //primitive --node-path | tr ' ' \'\n' | awk -F "id=\'" '{print $2}' | awk -F "\'" '{print $1}' | uniq); do
found=0
if [ -n "$stonithdevs" ]; then
for x in $stonithdevs; do
if [ $x = $i ]; then
found=1
fi
done
fi
if [ $found = 0 ]; then
sudo pcs constraint location $i rule resource-discovery=exclusive score=0 osprole eq controller
fi
done
14. neutron-openvswitch-agent:부터 pacemaker 에서 컴퓨팅 노드 리소스를 채우십시오.
heat-admin@controller-1 # sudo pcs resource create neutron-openvswitch-agent-compute systemd:neutron-openvswitch-agent op start timeout 200s stop timeout 200s --clone interleave=true --disabled --force heat-admin@controller-1 # sudo pcs constraint location neutron-openvswitch-agent-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute heat-admin@controller-1 # sudo pcs constraint order start neutron-server-clone then neutron-openvswitch-agent-compute-clone require-all=false
그런 다음 compute libvirtd 리소스입니다.
heat-admin@controller-1 # sudo pcs resource create libvirtd-compute systemd:libvirtd op start timeout 200s stop timeout 200s --clone interleave=true --disabled --force heat-admin@controller-1 # sudo pcs constraint location libvirtd-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute heat-admin@controller-1 # sudo pcs constraint order start neutron-openvswitch-agent-compute-clone then libvirtd-compute-clone heat-admin@controller-1 # sudo pcs constraint colocation add libvirtd-compute-clone with neutron-openvswitch-agent-compute-clone
그런 다음 openstack-ceilometer-compute 리소스:
heat-admin@controller-1 # sudo pcs resource create ceilometer-compute systemd:openstack-ceilometer-compute op start timeout 200s stop timeout 200s --clone interleave=true --disabled --force heat-admin@controller-1 # sudo pcs constraint location ceilometer-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute heat-admin@controller-1 # sudo pcs constraint order start openstack-ceilometer-notification-clone then ceilometer-compute-clone require-all=false heat-admin@controller-1 # sudo pcs constraint order start libvirtd-compute-clone then ceilometer-compute-clone heat-admin@controller-1 # sudo pcs constraint colocation add ceilometer-compute-clone with libvirtd-compute-clone
다음은 nova-compute 리소스입니다.
heat-admin@controller-1 # . /home/heat-admin/overcloudrc heat-admin@controller-1 # sudo pcs resource create nova-compute-checkevacuate ocf:openstack:nova-compute-wait auth_url=$OS_AUTH_URL username=$OS_USERNAME password=$OS_PASSWORD tenant_name=$OS_TENANT_NAME domain=localdomain op start timeout=300 --clone interleave=true --disabled --force heat-admin@controller-1 # sudo pcs constraint location nova-compute-checkevacuate-clone rule resource-discovery=exclusive score=0 osprole eq compute heat-admin@controller-1 # sudo pcs constraint order start openstack-nova-conductor-clone then nova-compute-checkevacuate-clone require-all=false heat-admin@controller-1 # sudo pcs resource create nova-compute systemd:openstack-nova-compute --clone interleave=true --disabled --force heat-admin@controller-1 # sudo pcs constraint location nova-compute-clone rule resource-discovery=exclusive score=0 osprole eq compute heat-admin@controller-1 # sudo pcs constraint order start nova-compute-checkevacuate-clone then nova-compute-clone require-all=true heat-admin@controller-1 # sudo pcs constraint order start nova-compute-clone then nova-evacuate require-all=false heat-admin@controller-1 # sudo pcs constraint order start libvirtd-compute-clone then nova-compute-clone heat-admin@controller-1 # sudo pcs constraint colocation add nova-compute-clone with libvirtd-compute-clone
15. 컴퓨팅 노드에 stonith 장치를 추가합니다. 각 컴퓨팅 노드에 대해 다음 명령을 실행합니다.
heat-admin@controller-1 # sudo pcs stonith create ipmilan-overcloud-compute-N fence_ipmilan pcmk_host_list=overcloud-compute-0 ipaddr=10.35.160.78 login=IPMILANUSER passwd=IPMILANPW lanplus=1 cipher=1 op monitor interval=60s;
다음과 같습니다.
-
N 은 각 컴퓨팅 노드의 식별 수입니다(예:
ipmilan-overcloud-compute
-1,ipmilan-overcloud-compute-2
등). - IPMILANUSER 및 IPMILANPW 는 IPMI 장치의 사용자 이름 및 암호입니다.
16. 별도의 fence-nova stonith 장치를 생성합니다.
heat-admin@controller-1 # . overcloudrc heat-admin@controller-1 # sudo pcs stonith create fence-nova fence_compute \ auth-url=$OS_AUTH_URL \ login=$OS_USERNAME \ passwd=$OS_PASSWORD \ tenant-name=$OS_TENANT_NAME \ record-only=1 --force
17. 펜싱 후 컴퓨팅 노드를 복구할 수 있는지 확인합니다.
heat-admin@controller-1 # sudo pcs property set cluster-recheck-interval=1min
18. 컴퓨팅 노드 리소스를 생성하고 노드의 물리적 펜스 장치와 fence-nova 를 모두 포함하도록 stonith 수준 1 을 설정합니다. 각 컴퓨팅 노드에 대해 다음 명령을 실행합니다.
heat-admin@controller-1 # sudo pcs resource create overcloud-compute-N ocf:pacemaker:remote reconnect_interval=60 op monitor interval=20 heat-admin@controller-1 # sudo pcs property set --node overcloud-compute-N osprole=compute heat-admin@controller-1 # sudo pcs stonith level add 1 overcloud-compute-N ipmilan-overcloud-compute-N,fence-nova heat-admin@controller-1 # sudo pcs stonith
N 을 각 compute 노드의 식별 번호로 바꿉니다(예: overcloud-compute-1
,overcloud-compute-2
등). 이러한 식별 번호를 사용하여 각 컴퓨팅 노드와 이전에 생성된 stonith 장치(예: overcloud-compute-1
및 ipmilan-overcloud-compute-1
)와 일치시킵니다.
19. 컨트롤 및 컴퓨팅 플레인 서비스를 활성화합니다.
heat-admin@controller-1 # sudo pcs resource enable openstack-keystone heat-admin@controller-1 # sudo pcs resource enable neutron-openvswitch-agent-compute heat-admin@controller-1 # sudo pcs resource enable libvirtd-compute heat-admin@controller-1 # sudo pcs resource enable ceilometer-compute heat-admin@controller-1 # sudo pcs resource enable nova-compute-checkevacuate heat-admin@controller-1 # sudo pcs resource enable nova-compute
20. 실패한 리소스를 정리하기 전에 환경이 안정될 때까지 잠시 기다립니다.
heat-admin@controller-1 # sleep 60 heat-admin@controller-1 # sudo pcs resource cleanup heat-admin@controller-1 # sudo pcs status heat-admin@controller-1 # sudo pcs property set stonith-enabled=true