Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

11장. 오버클라우드 확장

주의

Compute 인스턴스에 고가용성을 사용하면(또는 Compute 인스턴스에 대한 고가용성에 설명된 대로 인스턴스 HA) 업그레이드 또는 확장 작업이 불가능합니다. 이 작업을 시도하면 모두 실패합니다.

인스턴스 HA를 활성화한 경우 업그레이드 또는 확장을 수행하기 전에 이를 비활성화합니다. 비활성화하려면 Rollback에 설명된 대로 롤백을 수행합니다.

오버클라우드 생성 후에 노드를 추가하거나 제거해야 할 필요가 있을 수 있습니다. 예를 들면 오버클라우드에 더 많은 Compute 노드를 추가해야 할 수 있습니다. 이러한 경우 오버클라우드를 업데이트해야 합니다.

아래 표를 사용하여 각 노드 유형의 확장 지원 여부를 확인하십시오.

표 11.1. 각 노드 유형의 확장 지원

노드 유형

확장 가능 여부

축소 가능 여부

비고

Controller

N

N

 

Compute

Y

Y

 

Ceph Storage 노드

Y

N

초기 오버클라우드 생성시 적어도 하나의 Ceph Storage 노드가 있어야 합니다.

Block Storage 노드

N

N

 

Object Storage 노드

Y

Y

수동으로 링을 관리해야 함(11.6절. “Object Storage 노드 교체” 참조)

중요

오버클라우드를 확장하려면 적어도 10GB의 사용 가능한 공간이 있어야 합니다. 이 공간은 노드 프로비저닝 프로세스 중에 이미지 변환 및 캐싱에 사용됩니다.

11.1. 기타 노드 추가

director의 노드 풀에 더 많은 노드를 추가하려면 등록할 새 노드 세부 사항이 포함된 새 JSON 파일(예: newnodes.json)을 생성합니다.

{
  "nodes":[
    {
        "mac":[
            "dd:dd:dd:dd:dd:dd"
        ],
        "cpu":"4",
        "memory":"6144",
        "disk":"40",
        "arch":"x86_64",
        "pm_type":"pxe_ipmitool",
        "pm_user":"admin",
        "pm_password":"p@55w0rd!",
        "pm_addr":"192.168.24.207"
    },
    {
        "mac":[
            "ee:ee:ee:ee:ee:ee"
        ],
        "cpu":"4",
        "memory":"6144",
        "disk":"40",
        "arch":"x86_64",
        "pm_type":"pxe_ipmitool",
        "pm_user":"admin",
        "pm_password":"p@55w0rd!",
        "pm_addr":"192.168.24.208"
    }
  ]
}

이러한 매개 변수에 대한 설명은 6.1절. “오버클라우드에 노드 등록”을 참조하십시오.

다음 명령을 실행하여 이러한 노드를 등록합니다.

$ source ~/stackrc
(undercloud) $ openstack overcloud node import newnodes.json

새 노드를 등록한 후에 이러한 노드에 대한 인트로스펙션 프로세스를 시작합니다. 새로운 각 노드에 대해 다음 명령을 사용합니다.

(undercloud) $ openstack baremetal node manage [NODE UUID]
(undercloud) $ openstack overcloud node introspect [NODE UUID] --provide

이 경우 노드의 하드웨어 속성을 감지하여 벤치마킹합니다.

인트로스펙션 프로세스가 완료되면 해당 역할에 대해 각각의 새 노드를 태깅합니다. 예를 들어 Compute 노드의 경우 다음 명령을 사용합니다.

(undercloud) $ openstack baremetal node set --property capabilities='profile:compute,boot_option:local' [NODE UUID]

배포 중에 사용할 부팅 이미지를 설정합니다. bm-deploy-kernelbm-deploy-ramdisk 이미지의 UUID를 확인합니다.

(undercloud) $ openstack image list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 09b40e3d-0382-4925-a356-3a4b4f36b514 | bm-deploy-kernel       |
| 765a46af-4417-4592-91e5-a300ead3faf6 | bm-deploy-ramdisk      |
| ef793cd0-e65c-456a-a675-63cd57610bd5 | overcloud-full         |
| 9a51a6cb-4670-40de-b64b-b70f4dd44152 | overcloud-full-initrd  |
| 4f7e33f4-d617-47c1-b36f-cbe90f132e5d | overcloud-full-vmlinuz |
+--------------------------------------+------------------------+

새 노드의 deploy_kerneldeploy_ramdisk 설정에 대해 이러한 UUID를 설정합니다.

(undercloud) $ openstack baremetal node set --driver-info deploy_kernel='09b40e3d-0382-4925-a356-3a4b4f36b514' [NODE UUID]
(undercloud) $ openstack baremetal node set --driver-info deploy_ramdisk='765a46af-4417-4592-91e5-a300ead3faf6' [NODE UUID]

오버클라우드를 확장하려면 환경 파일 역할에 필요한 노드 수를 지정하고 openstack overcloud deploy를 다시 실행해야 합니다. 예를 들어 5개의 Compute 노드로 확장하려면 다음을 실행합니다.

parameter_defaults:
  ...
  ComputeCount: 5
  ...

업데이트된 파일로 배포 명령을 다시 실행합니다. 이 예시에서는 node-info.yaml라고 합니다.

(undercloud) $ openstack overcloud deploy --templates -e /home/stack/templates/node-info.yaml [OTHER_OPTIONS]

이렇게 하면 전체 오버클라우드 스택이 업데이트됩니다. 이 경우 스택만 업데이트됩니다. 오버클라우드가 삭제되고 스택이 교체되지는 않습니다.

중요

초기 오버클라우드 생성 시의 모든 환경 파일과 옵션을 포함합니다. 여기에는 Compute 이외 노드에 대한 동일한 확장 매개 변수가 포함됩니다.

11.2. Compute 노드 제거

오버클라우드에서 Compute 노드를 제거해야 하는 경우가 있을 수 있습니다. 예를 들면 문제가 있는 Compute 노드를 교체해야 할 수 있습니다.

중요

오버클라우드에서 Compute 노드를 제거하기 전에 노드에서 다른 Compute 노드로 워크로드를 마이그레이션합니다. 자세한 내용은 9.10절. “Compute 노드에서 인스턴스 마이그레이션”을 참조하십시오.

다음으로 오버클라우드에서 노드의 Compute 서비스를 비활성화합니다. 그러면 노드에서 새 인스턴스가 예약되지 않습니다.

$ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service set [hostname] nova-compute --disable

언더클라우드로 다시 전환합니다.

(overcloud) $ source ~/stack/stackrc

오버클라우드 노드를 제거하려면 로컬 템플릿 파일을 사용하여 director에서 overcloud 스택으로 업데이트해야 합니다. 먼저 오버클라우드 스택의 UUID를 확인합니다.

(undercloud) $ openstack stack list

삭제할 노드의 UUID를 확인합니다.

(undercloud) $ openstack server list

다음 명령을 실행하여 스택에서 노드를 삭제하고 그에 따라 플랜을 업데이트합니다.

(undercloud) $ openstack overcloud node delete --stack [STACK_UUID] --templates -e [ENVIRONMENT_FILE] [NODE1_UUID] [NODE2_UUID] [NODE3_UUID]
중요

오버클라우드를 생성할 때 추가 환경 파일을 전달한 경우 -e 또는 --environment-file 옵션을 사용하여 오버클라우드를 불필요하게 수동으로 변경하지 않도록 환경 파일을 다시 지정합니다.

중요

작업을 계속하려면 openstack overcloud node delete 명령을 실행하여 완료합니다. openstack stack list 명령을 사용하여 overcloud 스택이 UPDATE_COMPLETE 상태로 전환했는지 확인합니다.

마지막으로 노드의 Compute 서비스를 제거합니다.

(undercloud) $ source ~/stack/overcloudrc
(overcloud) $ openstack compute service list
(overcloud) $ openstack compute service delete [service-id]

노드의 Open vSwitch 에이전트를 제거합니다.

(overcloud) $ openstack network agent list
(overcloud) $ openstack network agent delete [openvswitch-agent-id]

이제 오버클라우드에서 노드를 제거하여 다른 용도로 노드를 다시 프로비저닝할 수 있습니다.

11.3. Compute 노드 교체

Compute 노드에 장애가 발생하면 해당 노드를 작동하는 노드로 교체할 수 있습니다. Compute 노드 교체에는 다음 프로세스를 사용합니다.

이 프로세스를 수행하면 인스턴스의 가용성에 영향을 주지 않고 노드를 교체할 수 있습니다.

11.4. Controller 노드 교체

특정 상황에서 고가용성 클러스터의 Controller 노드에 장애가 발생할 수 있습니다. 이러한 경우 클러스터에서 해당 노드를 제거하고 새 Controller 노드로 교체해야 합니다. 또한 노드가 클러스터의 다른 노드에 연결되도록 해야 합니다.

이 섹션에서는 Controller 노드를 교체하는 방법에 대해 설명합니다. 프로세스에는 Controller 노드 교체에 대한 요청으로 오버클라우드를 업데이트하는openstack overcloud deploy 명령을 실행하는 작업이 포함됩니다. 이 프로세스는 완전히 자동으로 수행되지 않습니다. 오버클라우드 스택 업데이트 프로세스 중에 openstack overcloud deploy 명령은 특정 시점에서 오류를 보고하고 오버클라우드 스택 업데이트를 중지합니다. 이 시점에서 프로세스를 수행하려면 일부 수동 조작이 필요합니다. 그런 다음 openstack overcloud deploy 프로세스를 계속할 수 있습니다.

중요

다음 절차는 고가용성 환경에만 적용됩니다. Controller 노드를 하나만 사용하는 경우 이 절차를 사용하지 마십시오.

11.4.1. 사전 점검

오버클라우드 Controller 노드를 교체하기 전에 Red Hat OpenStack Platform 환경의 현재 상태를 확인하는 것이 중요합니다. 현재 상태를 확인하면 Controller 교체 프로세스 중에 복잡한 문제가 발생하는 것을 방지할 수 있습니다. 다음 사전 점검 목록을 사용하여 Controller 노드 교체를 수행하는 것이 안전한지 확인합니다. 언더클라우드에서 검사 명령을 모두 실행합니다.

  1. 언더클라우드에서 overcloud 스택의 현재 상태를 확인합니다.

    $ source stackrc
    (undercloud) $ openstack stack list --nested

    overcloud 스택 및 해당 하위 스택에 CREATE_COMPLETE 또는 UPDATE_COMPLETE가 있어야 합니다.

  2. 언더클라우드 데이터베이스 백업을 수행합니다.

    (undercloud) $ mkdir /home/stack/backup
    (undercloud) $ sudo mysqldump --all-databases --quick --single-transaction | gzip > /home/stack/backup/dump_db_undercloud.sql.gz
  3. 새 노드를 프로비저닝할 때 언더클라우드에 이미지 캐싱 및 변환을 수행하는 데 필요한 10GB의 사용 가능한 스토리지가 있는지 확인합니다.
  4. 실행 중인 Controller 노드에서 Pacemaker의 상태를 확인합니다. 예를 들어 192.168.0.47이 실행 중인 Controller 노드의 IP 주소인 경우 다음 명령을 사용하여 Pacemaker 상태 정보를 가져옵니다.

    (undercloud) $ ssh heat-admin@192.168.0.47 'sudo pcs status'

    출력에 기존 노드에서 실행 중인 서비스와 실패한 노드에서 중지된 모든 서비스가 표시됩니다.

  5. 오버클라우드의 MariaDB 클러스터에 있는 각 노드에서 다음 매개 변수를 확인합니다.

    • wsrep_local_state_comment: Synced
    • wsrep_cluster_size: 2

      다음 명령을 사용하여 실행 중인 각 Controller 노드에서 이러한 매개 변수를 확인합니다(각각 IP 주소에 192.168.0.47 및 192.168.0.46 사용).

      (undercloud) $ for i in 192.168.0.47 192.168.0.46 ; do echo "*** $i ***" ; ssh heat-admin@$i "sudo mysql -p\$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password) --execute=\"SHOW STATUS LIKE 'wsrep_local_state_comment'; SHOW STATUS LIKE 'wsrep_cluster_size';\""; done
  6. RabbitMQ 상태를 확인합니다. 예를 들어 192.168.0.47이 실행 중인 Controller 노드의 IP 주소이면 다음 명령을 사용하여 상태 정보를 가져옵니다.

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo docker exec \$(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl cluster_status"

    running_nodes 키는 사용 가능한 두 개의 노드만 표시하고, 실패한 노드는 표시하지 않습니다.

  7. 펜싱이 활성화된 경우 비활성화합니다. 예를 들어 192.168.0.47이 실행 중인 Controller 노드의 IP 주소이면 다음 명령을 사용하여 펜싱을 비활성화합니다.

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property set stonith-enabled=false"

    다음 명령을 사용하여 펜싱 상태를 확인합니다.

    (undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs property show stonith-enabled"
  8. director 노드에서 nova-compute 서비스를 확인합니다.

    (undercloud) $ sudo systemctl status openstack-nova-compute
    (undercloud) $ openstack hypervisor list

    출력에 모든 유지보수 이외의 모드 노드가 up으로 표시됩니다.

  9. 모든 언더클라우드 서비스가 실행 중인지 확인합니다.

    (undercloud) $ sudo systemctl -t service

11.4.2. Ceph Monitor 데몬 삭제

이 절차는 스토리지 클러스터에서 ceph-mon 데몬을 제거합니다. 컨트롤러 노드가 Ceph monitor 서비스를 실행하는 경우 다음 단계에 따라 ceph-mon 데몬을 삭제합니다. 이 절차는 컨트롤러가 도달할 수 있다고 가정합니다.

참고

새로운 Ceph monitor 데몬은 새 컨트롤러가 클러스터에 추가된 뒤에 추가됩니다.

  1. 교체하여 root가 될 컨트롤러에 연결합니다.

    # ssh heat-admin@192.168.0.47
    # sudo su -
    참고

    컨트롤러가 도달하지 못하는 경우 1단계와 2단계를 건너뛰고 모든 작업 컨트롤러 노드에 있는 3단계로 이동합니다.

  2. root로 monitor를 중단합니다.

    # systemctl stop ceph-mon@<monitor_hostname>

    예:

    # systemctl stop ceph-mon@overcloud-controller-2
  3. 클러스터에서 monitor를 삭제합니다.

    # ceph mon remove <mon_id>
  4. Ceph monitor 노드에서 /etc/ceph/ceph.conf의 monitor 항목을 삭제합니다. 예를 들어 controller-2를 삭제하면 controller-2에 대한 IP와 호스트 이름이 삭제됩니다.

    편집 전:

    mon host = 172.18.0.21,172.18.0.22,172.18.0.24
    mon initial members = overcloud-controller-2,overcloud-controller-1,overcloud-controller-0

    편집 후:

    mon host = 172.18.0.22,172.18.0.24
    mon initial members = overcloud-controller-1,overcloud-controller-0
  5. 다른 오버클라우드 노드에 있는 /etc/ceph/ceph.conf를 동일하게 변경합니다.

    참고

    대체 controller 노드가 추가되면 director가 ceph.conf 파일을 관련 오버클라우드 노드에 추가합니다. 일반적으로 이 구성 파일은 director에서만 관리하며 수동으로 편집해서는 안 됩니다. 하지만 이 단계에서 편집하면 새 노드가 추가되기 전에 다른 노드가 재시작되는 경우에 일관성을 보장할 수 있습니다.

  6. 옵션으로 모니터 데이터를 압축하여 다른 서버에 저장할 수 있습니다.

    # mv /var/lib/ceph/mon/<cluster>-<daemon_id> /var/lib/ceph/mon/removed-<cluster>-<daemon_id>

11.4.3. 노드 교체

제거할 노드의 인덱스를 확인합니다. 노드 인덱스는 nova list 출력의 인스턴스 이름에서 접미사입니다.

(undercloud) $ openstack server list
+--------------------------------------+------------------------+
| ID                                   | Name                   |
+--------------------------------------+------------------------+
| 861408be-4027-4f53-87a6-cd3cf206ba7a | overcloud-compute-0    |
| 0966e9ae-f553-447a-9929-c4232432f718 | overcloud-compute-1    |
| 9c08fa65-b38c-4b2e-bd47-33870bff06c7 | overcloud-compute-2    |
| a7f0f5e1-e7ce-4513-ad2b-81146bc8c5af | overcloud-controller-0 |
| cfefaf60-8311-4bc3-9416-6a824a40a9ae | overcloud-controller-1 |
| 97a055d4-aefd-481c-82b7-4a5f384036d2 | overcloud-controller-2 |
+--------------------------------------+------------------------+

이 예에서는 overcloud-controller-1 노드를 제거하고 overcloud-controller-3으로 교체합니다. 먼저, director가 실패한 노드를 다시 프로비저닝하지 않도록 노드를 유지보수 모드로 설정합니다. nova list의 인스턴스 ID를 openstack baremetal node list의 노드 ID와 상호 연결합니다.

(undercloud) $ openstack baremetal node list
+--------------------------------------+------+--------------------------------------+
| UUID                                 | Name | Instance UUID                        |
+--------------------------------------+------+--------------------------------------+
| 36404147-7c8a-41e6-8c72-a6e90afc7584 | None | 7bee57cf-4a58-4eaf-b851-2a8bf6620e48 |
| 91eb9ac5-7d52-453c-a017-c0e3d823efd0 | None | None                                 |
| 75b25e9a-948d-424a-9b3b-f0ef70a6eacf | None | None                                 |
| 038727da-6a5c-425f-bd45-fda2f4bd145b | None | 763bfec2-9354-466a-ae65-2401c13e07e5 |
| dc2292e6-4056-46e0-8848-d6e96df1f55d | None | 2017b481-706f-44e1-852a-2ee857c303c4 |
| c7eadcea-e377-4392-9fc3-cf2b02b7ec29 | None | 5f73c7d7-4826-49a5-b6be-8bfd558f3b41 |
| da3a8d19-8a59-4e9d-923a-6a336fe10284 | None | cfefaf60-8311-4bc3-9416-6a824a40a9ae |
| 807cb6ce-6b94-4cd1-9969-5c47560c2eee | None | c07c13e6-a845-4791-9628-260110829c3a |
+--------------------------------------+------+--------------------------------------+

노드를 유지보수 모드로 설정합니다.

(undercloud) $ openstack baremetal node maintenance set da3a8d19-8a59-4e9d-923a-6a336fe10284

새 노드를 control 프로필로 태깅합니다.

(undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 75b25e9a-948d-424a-9b3b-f0ef70a6eacf

오버클라우드의 데이터베이스는 교체 절차 중에 계속 실행되고 있어야 합니다. 이 절차 중에 Pacemaker에서 Galera를 중지하지 않도록 하려면 실행 중인 Controller 노드를 선택하고, 언더클라우드에서 Controller 노드의 IP 주소를 사용하여 다음 명령을 실행합니다.

(undercloud) $ ssh heat-admin@192.168.0.47 "sudo pcs resource unmanage galera"

제거할 노드 인덱스를 정의하는 YAML 파일(~/templates/remove-controller.yaml)을 생성합니다.

parameters:
  ControllerRemovalPolicies:
    [{'resource_list': ['1']}]
참고

Corosync에서 설정 시도 횟수를 줄임으로써 교체 프로세스 속도를 높일 수 있습니다. ~/templates/remove-controller.yaml 환경 파일에서 CorosyncSettleTries 매개 변수를 지정합니다.

parameter_defaults:
  CorosyncSettleTries: 5

노드 인덱스를 식별한 후 오버클라우드를 재배포하고 remove-controller.yaml 환경 파일을 추가합니다.

(undercloud) $ openstack overcloud deploy --templates --control-scale 3 -e ~/templates/remove-controller.yaml [OTHER OPTIONS]

오버클라우드를 생성할 때 추가 환경 파일이나 옵션을 전달한 경우 오버클라우드가 예기치 않게 변경되지 않도록 여기서 다시 전달합니다.

하지만 -e ~/templates/remove-controller.yaml은 이 인스턴스에서 한 번만 필요합니다.

director에서 기존 노드를 제거하고, 새 노드를 생성한 후 오버클라우드 스택을 업데이트합니다. 다음 명령을 사용하여 오버클라우드 스택의 상태를 확인할 수 있습니다.

(undercloud) $ openstack stack list --nested

11.4.4. 수동 조작

ControllerNodesPostDeployment 단계 중에 ControllerDeployment_Step1UPDATE_FAILED 오류로 오버클라우드 스택 업데이트가 중지됩니다. 이는 일부 Puppet 모듈이 노드 교체를 지원하지 않기 때문입니다. 프로세스의 이 시점에는 일부 수동 조작이 필요합니다. 다음 구성 단계를 따르십시오.

  1. Controller 노드의 IP 주소 목록을 가져옵니다. 예를 들면 다음과 같습니다.

    (undercloud) $ openstack server list -c Name -c Networks
    +------------------------+-----------------------+
    | Name                   | Networks              |
    +------------------------+-----------------------+
    | overcloud-compute-0    | ctlplane=192.168.0.44 |
    | overcloud-controller-0 | ctlplane=192.168.0.47 |
    | overcloud-controller-2 | ctlplane=192.168.0.46 |
    | overcloud-controller-3 | ctlplane=192.168.0.48 |
    +------------------------+-----------------------+
  2. 각 노드의 Corosync 구성에서 장애가 발생한 노드를 삭제하고 Corosync를 다시 시작합니다. 이 예에서는 overcloud-controller-0overcloud-controller-2에 로그인하고 다음 명령을 실행합니다.

    (undercloud) $ for NAME in overcloud-controller-0 overcloud-controller-2; do IP=$(openstack server list -c Networks -f value --name $NAME | cut -d "=" -f 2) ; ssh heat-admin@$IP "sudo pcs cluster localnode remove overcloud-controller-1; sudo pcs cluster reload corosync"; done
  3. 나머지 노드 중 하나에 로그인하고 crm_node 명령을 사용하여 클러스터에서 노드를 삭제합니다.

    (undercloud) $ ssh heat-admin@192.168.0.47
    [heat-admin@overcloud-controller-0 ~]$ sudo crm_node -R overcloud-controller-1 --force

    이 노드에 로그인한 상태를 유지합니다.

  4. RabbitMQ 클러스터에서 장애가 발생한 노드를 삭제합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo docker exec -it $(sudo docker ps -f name=rabbitmq-bundle -q) rabbitmqctl forget_cluster_node rabbit@overcloud-controller-1
  5. Galera 클러스터의 노드 목록을 업데이트하고 클러스터를 새로고침합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource update galera cluster_host_map="overcloud-controller-0:overcloud-controller-0.internalapi.localdomain;overcloud-controller-3:overcloud-controller-3.internalapi.localdomain;overcloud-controller-2:overcloud-controller-2.internalapi.localdomain" wsrep_cluster_address="gcomm://overcloud-controller-0.internalapi.localdomain,overcloud-controller-3.internalapi.localdomain,overcloud-controller-2.internalapi.localdomain"
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource refresh galera
    [heat-admin@overcloud-controller-0 ~]$ sudo pcs resource manage galera
  6. 새 노드를 클러스터에 추가합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster node add overcloud-controller-3
  7. 새 Controller 노드를 시작합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster start overcloud-controller-3

수동 구성이 완료됩니다. 컨트롤러에서 로그인 상태를 유지합니다.

새 터미널을 열고 오버클라우드 배포 명령을 다시 실행하여 stack 업데이트를 계속합니다.

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates --control-scale 3 [OTHER OPTIONS]
중요

오버클라우드를 생성할 때 추가 환경 파일이나 옵션을 전달한 경우 오버클라우드를 예기치 않게 변경하지 않도록 여기서 다시 전달하십시오. 하지만 remove-controller.yaml 파일은 더 이상 필요하지 않습니다.

11.4.5. 오버클라우드 서비스 구성 완료

오버클라우드 stack 업데이트가 완료되면 적절한 클러스터 노드 속성을 설정하여 새롭게 추가된 컨트롤러 노드에서 Pacemaker가 컨트롤러 서비스를 실행하도록 허용합니다. 기존 컨트롤러 노드 중 하나(예: overcloud-controller-0)에서 다음을 실행합니다.

[heat-admin@overcloud-controller-0 ~]$ for i in $(sudo pcs property | grep overcloud-controller-0: | cut -d' ' -f 3- | tr  ' ' '\n' | grep role); do sudo pcs property set --node overcloud-controller-3 $i; done

위의 시점부터 pacemaker가 관리하는 서비스는 새로 추가된 컨트롤러 노드에서 시작됩니다.

최종 스택 확인을 수행하여 서비스가 올바르게 실행 중인지 확인합니다.

[heat-admin@overcloud-controller-0 ~]$ sudo pcs status
참고

서비스가 실패한 경우 pcs resource refresh 명령을 사용하여 문제를 해결한 후 서비스를 다시 시작합니다.

director를 종료합니다.

[heat-admin@overcloud-controller-0 ~]$ exit

11.4.6. L3 에이전트 라우터 호스팅 구성 완료

오버클라우드와 상호 작용할 수 있도록 overcloudrc 파일을 소싱합니다. L3 에이전트가 오버클라우드 환경의 라우터를 제대로 호스팅하는지 라우터에서 확인합니다. 이 예에서 는 이름 r1에 라우터를 사용합니다.

$ source ~/overcloudrc
(overcloud) $ neutron l3-agent-list-hosting-router r1

이 목록에 새 노드 대신 기존 노드가 여전히 표시될 수 있습니다. 기존 노드를 교체하려면 환경에 L3 네트워크 에이전트를 나열합니다.

(overcloud) $ neutron agent-list | grep "neutron-l3-agent"

새 노드와 기존 노드에서 에이전트의 UUID를 식별합니다. 라우터를 새 노드의 에이전트에 추가하고 기존 노드에서 라우터를 제거합니다. 예를 들면 다음과 같습니다.

(overcloud) $ neutron l3-agent-router-add fd6b3d6e-7d8c-4e1a-831a-4ec1c9ebb965 r1
(overcloud) $ neutron l3-agent-router-remove b40020af-c6dd-4f7a-b426-eba7bac9dbc2 r1

라우터에서 최종 확인을 수행하고 모두 활성 상태인지 확인합니다.

(overcloud) $ neutron l3-agent-list-hosting-router r1

이전 Controller 노드를 가리키는 기존 Neutron 에이전트를 삭제합니다. 예를 들면 다음과 같습니다.

(overcloud) $ neutron agent-list -F id -F host | grep overcloud-controller-1
| ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb | overcloud-controller-1.localdomain |
(overcloud) $ neutron agent-delete ddae8e46-3e8e-4a1b-a8b3-c87f13c294eb

11.4.7. Compute 서비스 구성 완료

제거된 노드의 Compute 서비스가 여전히 오버클라우드에 있으므로 제거해야 합니다. 오버클라우드와 상호 작용할 수 있도록 overcloudrc 파일을 소싱합니다. Compute 서비스에서 제거된 노드가 있는지 확인합니다.

[stack@director ~]$ source ~/overcloudrc
(overcloud) $ openstack compute service list --host overcloud-controller-1.localdomain

삭제된 노드의 Compute 서비스를 제거합니다.

(overcloud) $ for SERVICE in $(openstack compute service list --host overcloud-controller-1.localdomain -f value -c ID) ; do openstack compute service delete $SERVICE ; done

11.4.8. 결론

장애가 발생한 Controller 노드 및 해당 관련 서비스가 이제 새 노드로 교체됩니다.

중요

11.6절. “Object Storage 노드 교체”에서 처럼 Object Storage에서 링 파일 자동 빌드를 비활성화한 경우, 새 노드에 대해 Object Storage 링 파일을 수동으로 빌드해야 합니다. 링 파일을 수동으로 빌드하는 작업에 대한 자세한 내용은 11.6절. “Object Storage 노드 교체”를 참조하십시오.

11.5. Ceph Storage 노드 교체

director에서는 director에서 생성한 클러스터에 있는 Ceph Storage 노드를 교체할 수 있습니다. 해당 지침은 Deploying an Overcloud with Containerized Red Hat Ceph 가이드를 참조하십시오.

11.6. Object Storage 노드 교체

이 섹션에서는 클러스터의 무결성을 유지보수하는 동안 Object Storage 노드를 교체하는 방법을 설명합니다. 이 예에서는 두 개의 노드로 구성된 Object Storage 클러스터에서 overcloud-objectstorage-1 노드를 교체해야 합니다. 이 절차에서는 한 개의 노드를 더 추가한 다음 overcloud-objectstorage-1을 제거하는 것을 목표로 합니다(효율적으로 교체).

  1. 다음 컨텐츠가 포함된 ~/templates/swift-upscale.yaml이라는 환경 파일을 생성합니다.

    parameter_defaults:
      ObjectStorageCount: 3

    ObjectStorageCount는 환경에 있는 Object Storage 노드 수를 정의합니다. 이 경우 2개에서 3개 노드로 확장합니다.

  2. swift-upscale.yaml 파일을 오버클라우드의 나머지 환경 파일(ENVIRONMENT_FILES)에 openstack overcloud deploy의 일부로 추가합니다.

    $ source ~/stackrc
    (undercloud) $ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml
    참고

    해당 매개 변수가 이전 환경 파일 매개 변수 보다 우선이 되도록 swift-upscale.yaml을 환경 파일 목록 끝에 추가합니다.

    재배포가 완료되면 이제 오버클라우드에 추가 Object Storage 노드가 포함됩니다.

  3. 이제 데이터를 새 노드에 복제해야 합니다. 노드를 제거하기 전에(이 경우 overcloud-objectstorage-1) replication pass가 새 노드에서 완료될 때까지 대기해야 합니다. /var/log/swift/swift.log에서 복제 전달 진행 상황을 확인할 수 있습니다. 전달이 완료되면 Object Storage 서비스는 다음과 같은 항목을 로그에 기록합니다.

    Mar 29 08:49:05 localhost object-server: Object replication complete.
    Mar 29 08:49:11 localhost container-server: Replication run OVER
    Mar 29 08:49:13 localhost account-server: Replication run OVER
  4. 링에서 이전 노드를 제거하려면 이전 링을 생략하도록 swift-upscale.yaml에서 ObjectStorageCount를 줄입니다. 이 경우에는 2로 줄입니다.

    parameter_defaults:
      ObjectStorageCount: 2
  5. remove-object-node.yaml이라는 새 환경 파일을 생성합니다. 이 파일은 지정된 Object Storage 노드를 식별하고 제거합니다. 다음 컨텐츠는 overcloud-objectstorage-1을 제거하도록 지정합니다.

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  6. 배포 명령에 두 환경 파일을 지정합니다.

    (undercloud) $ openstack overcloud deploy --templates ENVIRONMENT_FILES -e swift-upscale.yaml -e remove-object-node.yaml ...

director가 오버클라우드에서 Object Storage 노드를 삭제하고 노드 제거를 적용하도록 오버클라우드에서 나머지 노드를 업데이트합니다.

11.7. 노드 블랙리스트 지정

업데이트된 배포를 수신하지 못하도록 오버클라우드 노드를 제외할 수 있습니다. 이는 코어 Heat 템플릿 컬렉션에서 업데이트된 매개 변수 및 리소스 세트를 수신하지 못하도록 기존 노드를 제외한 상태에서 새 노드를 확장하려는 시나리오에서 유용합니다. 즉, 블랙리스트로 지정된 노드는 stack 작업의 영향을 받지 않습니다.

환경 파일에서 DeploymentServerBlacklist 매개 변수를 사용하여 블랙리스트를 생성할 수 있습니다.

블랙리스트 설정

DeploymentServerBlacklist 매개 변수는 서버 이름 목록입니다. 새 환경 파일을 작성하거나 기존 사용자 지정 환경 파일에 매개 변수 값을 추가하고 파일을 배포 명령으로 전달합니다.

parameter_defaults:
  DeploymentServerBlacklist:
    - overcloud-compute-0
    - overcloud-compute-1
    - overcloud-compute-2
참고

매개 변수 값의 서버 이름은 실제 서버 호스트 이름이 아니라 OpenStack Orchestration(heat)에 따른 이름입니다.

이 환경 파일을 openstack overcloud deploy 명령에 추가합니다. 예:

$ source ~/stackrc
(undercloud) $ openstack overcloud deploy --templates \
  -e server-blacklist.yaml \
  [OTHER OPTIONS]

Heats는 목록에서 업데이트된 Heat 배포를 수신하는 모든 서버를 블랙 리스트로 지정합니다. stack 작업이 완료되면 블랙리스트로 지정된 서버는 변경되지 않고 이전 상태로 유지됩니다. 또한 작업 중에 os-collect-config 에이전트의 전원을 끄거나 중단할 수 있습니다.

주의
  • 노드를 블랙리스트로 지정할 때 주의하십시오. 요청된 변경 사항이 블랙리스트에서 어떻게 적용되는지 완전히 이해한 경우에만 블랙 리스트를 사용하시기 바랍니다. 블랙리스트 기능을 사용하면 중단된 stack을 생성하거나 오버클라우드를 잘못 구성할 수도 있습니다. 예를 들어 클러스터 구성 변경이 Pacemaker 클러스터의 모든 구성원에게 적용되면 변경 중에 Pacemaker 클러스터 구성원을 블랙리스트로 지정하면 클러스터가 실패할 수 있습니다.
  • 업데이트 또는 업그레이드 절차 중에 블랙리스트 기능을 사용하지 마십시오. 이러한 절차에는 특정 서버에 대해 변경 사항을 격리하는 자체 방식이 있습니다. 자세한 정보는 Upgrading Red Hat OpenStack Platform 문서를 참조하십시오.
  • 블랙리스트에 서버를 추가할 때 블랙리스트에서 서버가 삭제될 때까지 이러한 노드에 대한 추가 변경이 지원되지 않습니다. 업데이트, 업그레이드, 확장, 축소, 노드 교체 등이 이에 해당합니다.

블랙리스트 삭제

이후 stack 작업에 대해 블랙리스트를 삭제하려면 DeploymentServerBlacklist를 편집 하여 빈 어레이를 사용하십시오.

parameter_defaults:
  DeploymentServerBlacklist: []
주의

DeploymentServerBlacklist 매개 변수를 생략하지 마십시오. 매개 변수를 생략하는 경우 오버클라우드 배포에서 이전에 저장한 값을 사용합니다.