Compute 인스턴스의 고가용성


Red Hat OpenStack Platform 8

컴퓨팅 인스턴스의 고가용성 구성

OpenStack Documentation Team

초록

Red Hat OpenStack Platform에서 Compute 인스턴스의 고가용성(인스턴스 HA) 구성을 위한 가이드입니다. 이 문서에서는 Ansible을 통해 인스턴스 HA를 활성화하는 데 중점을 둡니다.

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에서 참조하십시오.

2.1. 공유 스토리지의 예외

일반적으로 인스턴스 HA를 활성화하려면 공유 스토리지가 필요합니다. no-shared-storage 옵션을 사용하려는 경우 비우는 동안 InvalidSharedStorage 오류가 수신될 수 있으며 인스턴스는 다른 노드에서 전원을 켜지 않습니다. 그러나 모든 인스턴스가 블록 스토리지(cinder) 볼륨에서 부팅되도록 구성된 경우 인스턴스의 디스크 이미지를 저장하기 위해 공유 스토리지가 필요하지 않습니다. no-shared-storage 옵션을 사용하여 모든 인스턴스를 비울 수 있습니다.

비우는 동안 인스턴스가 블록 스토리지 볼륨에서 부팅되도록 구성된 경우 비우는 인스턴스가 동일한 볼륨에서 부팅되지만 다른 컴퓨팅 노드에서 부팅해야 할 수 있습니다. 따라서 OS 이미지 및 애플리케이션 데이터가 블록 스토리지 볼륨에 유지되므로 비우는 인스턴스가 즉시 작업을 다시 시작할 수 있습니다.

참고

이 가이드의 ansible 기반 배포 절차에서는 no-shared-storage 옵션을 사용한 설치를 지원합니다.

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를 위해 오버클라우드를 준비할 수 있습니다.

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. 이 TAR 아카이브/home/stack/ 로 다운로드합니다. Ansible을 통해 인스턴스 HA를 활성화하는 데 필요한 플레이북, 역할 및 기타 유틸리티가 포함되어 있습니다.

    참고

    여기에 제공된 TAR 아카이브 는 업스트림 GIT 리포지토리의 테스트 및 수정된 버전입니다. 이 리포지토리를 복제하려면 다음을 실행합니다.

    stack@director $ git clone git://github.com/redhat-openstack/tripleo-quickstart-utils

    이 리포지토리는 통지 없이 업데이트할 수 있으므로 이 단계에서 사용할 수 있는 아카이브와 다를 수 있습니다.

  3. TAR 아카이브를 추출합니다.

    stack@director $ tar -xvf ansible-instanceha.tar
  4. 다음 콘텐츠를 사용하여 /home/stack/ansible.cfg 를 생성합니다.

    [defaults]
    roles_path = /home/stack/ansible-instanceha/roles
  5. 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"
  6. 오버클라우드의 노드 정의 템플릿(기본적으로 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를 통해 인스턴스 자동 비우기를 강제 적용합니다.

  1. 해당 인스턴스를 호스팅하는 컴퓨팅 노드를 중단하기 전에 오버클라우드에서 하나 이상의 인스턴스를 부팅합니다.

    stack@director $ . overcloudrc
    stack@director $ nova boot --image cirros --flavor 2 test-failover
    stack@director $ nova list --fields name,status,host
  2. 방금 부팅한 인스턴스를 호스팅하는 컴퓨팅 노드에 로그인합니다 (예: compute-n).

    stack@director $ . stackrc
    stack@director $ ssh -lheat-admin compute-n
    heat-admin@compute-n $
  3. 노드를 충돌합니다.

    heat-admin@compute-n $ echo c > /proc/sysrq-trigger
  4. 몇 분 후에 이러한 인스턴스가 온라인 컴퓨팅 노드에서 다시 시작되었는지 확인합니다. 확인하려면 다음을 수행합니다.

    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에서 컴퓨팅 노드에서 인스턴스를 비우는 프로세스를 자동화합니다. 다음 프로세스는 컴퓨팅 노드 오류 발생 시 트리거되는 이벤트 시퀀스를 설명합니다.

  1. 컴퓨팅 노드에 실패하면 IPMI 에이전트가 첫 번째 펜싱 을 수행하고 전원이 꺼지도록 노드를 물리적으로 재설정합니다. 온라인 컴퓨팅 노드에서 인스턴스를 비우면 오버클라우드에서 데이터 손상 또는 동일한 여러 인스턴스가 실행될 수 있습니다. 노드의 전원이 꺼지면 펜싱된 것으로 간주됩니다.
  2. 물리적 IPMI 펜싱 후 fence-nova 에이전트는 두 번째 수준 펜싱 을 수행하고 fenced 노드를 "evacuate=yes" 클러스터 per-node 속성으로 표시합니다. 이를 위해 에이전트는 다음을 실행합니다.

    $ attrd_updater -n evacuate -A name="evacuate" host="FAILEDHOST" value="yes"

    여기서 FAILEDHOST 는 실패한 컴퓨팅 노드의 호스트 이름입니다.

  3. nova-evacuate 에이전트는 백그라운드에서 지속적으로 실행되며 "evacuate=yes" 속성이 있는 노드에서 주기적으로 클러스터를 확인합니다. nova-evacuate 에서 펜싱된 노드에 이 속성이 있음을 감지하면 에이전트는 Evacuate Instances 에 설명된 대로 동일한 프로세스를 사용하여 노드를 비우기 시작합니다.
  4. 한편 실패한 노드는 IPMI 재설정에서 부팅되는 동안 nova-compute-checkevacuate 에이전트는 nova-evacuate 가 비우기로 완료되었는지 확인하기 전에(기본적으로 120초 동안) 대기합니다. 그렇지 않으면 동일한 시간 간격 후에 다시 확인합니다.
  5. 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,tenantpassword 값을 제공합니다.

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 등).
  • IPMILANUSERIPMILANPW 는 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-1ipmilan-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

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.