절차

1. ceph-mon 서비스를 실행 중인 노드에 로그인합니다. 이 노드는 일반적으로 컨트롤러 노드 또는 독립 실행형 Ceph 모니터 노드입니다.

2. Ceph 클러스터의 상태 보기:

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

3. 클러스터의 상태가 HEALTH_OK 이고 모든 OSD(오브젝트 스토리지 데몬)가 활성화되어 있는지 확인합니다.

절차

1. root 사용자로 언더클라우드에 로그인합니다.

2. 데이터베이스를 백업합니다.

   [root@director ~]# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql

3. 백업 디렉터리를 생성하고 디렉터리의 사용자 소유권을 stack 사용자로 변경합니다.

   [root@director ~]# mkdir /backup
   [root@director ~]# chown stack: /backup

   이 디렉터리를 사용하여 Undercloud 데이터베이스 및 파일 시스템이 포함된 아카이브를 저장합니다.

4. 백업 디렉터리로 변경합니다.

   [root@director ~]# cd /backup

5. 데이터베이스 백업 및 구성 파일을 보관합니다.

   [root@director ~]# tar --xattrs --xattrs-include='*.*' --ignore-failed-read -cf \
       undercloud-backup-$(date +%F).tar \
       /root/undercloud-all-databases.sql \
       /etc \
       /var/log \
       /var/lib/glance \
       /var/lib/certmonger \
       /var/lib/docker \
       /var/lib/registry \
       /srv/node \
       /root \
       /home/stack

   • --ignore-failed-read 옵션은 언더클라우드에 적용되지 않는 디렉터리를 건너뜁니다.
   • --xattrs 및 --xattrs-include='.' 옵션에는 오브젝트 스토리지(swift) 및 SELinux에 대한 메타데이터를 저장하는 데 필요한 확장 속성이 포함되어 있습니다.

   그러면 undercloud-backup-<date>.tar.gz라는 파일이 생성됩니다. 여기서 <date> 는 시스템 날짜입니다. 이 tar 파일을 안전한 위치에 복사합니다.

절차

1. 데이터베이스 백업을 수행합니다.

   1. 컨트롤러 노드에 로그인합니다. 언더클라우드에서 오버클라우드에 액세스할 수 있습니다.

      $ ssh heat-admin@192.0.2.100

   2. root 사용자로 변경합니다.

      $ sudo -i

   3. 백업을 저장할 임시 디렉터리를 생성합니다.

      # mkdir -p /var/tmp/mysql_backup/

   4. 데이터베이스 암호를 가져와서 MYSQLDBPASS 환경 변수에 저장합니다. 암호는 /etc/puppet/hieradata/service _configs.json 파일의 mysql::server::root_ password 변수에 저장됩니다. 다음 명령을 사용하여 암호를 저장합니다.

      # MYSQLDBPASS=$(sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password)

   5. 데이터베이스를 백업합니다.

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "select distinct table_schema from information_schema.tables where engine='innodb' and table_schema != 'mysql';" | xargs mysqldump -uroot -p$MYSQLDBPASS --single-transaction --databases > /var/tmp/mysql_backup/openstack_databases-$(date +%F)-$(date +%T).sql

      이렇게 하면 /var/tmp/mysql_backup/openstack_databases-<date>.sql이라는 데이터베이스 백업을 덤프합니다. 여기서 <date> 는 시스템 날짜와 시간입니다. 이 데이터베이스 덤프를 안전한 위치에 복사합니다.

   6. 모든 사용자 및 권한 정보를 백업합니다.

      # mysql -uroot -p$MYSQLDBPASS -s -N -e "SELECT CONCAT('\"SHOW GRANTS FOR ''',user,'''@''',host,''';\"') FROM mysql.user where (length(user) > 0 and user NOT LIKE 'root')" | xargs -n1 mysql -uroot -p$MYSQLDBPASS -s -N -e | sed 's/$/;/' > /var/tmp/mysql_backup/openstack_databases_grants-$(date +%F)-$(date +%T).sql

      이렇게 하면 /var/tmp/mysql_backup/openstack_databases_grants-<date>.sql이라는 데이터베이스 백업을 덤프합니다. 여기서 <date> 는 시스템 날짜와 시간입니다. 이 데이터베이스 덤프를 안전한 위치에 복사합니다.

2. Pacemaker 구성을 백업합니다.

   1. 컨트롤러 노드에 로그인합니다.

   2. 다음 명령을 실행하여 현재 Pacemaker 구성의 아카이브를 생성합니다.

      # sudo pcs config backup pacemaker_controller_backup

   3. 결과 아카이브(pacemaker_controller_backup.tar.bz2)를안전한 위치에 복사합니다.

3. OpenStack Telemetry 데이터베이스를 백업합니다.

   1. 컨트롤러에 연결하고 MongoDB 기본 인스턴스의 IP를 가져옵니다.

      # MONGOIP=$(sudo hiera -c /etc/puppet/hiera.yaml mongodb::server::bind_ip)

   2. 백업을 생성합니다.

      # mkdir -p /var/tmp/mongo_backup/
      # mongodump --oplog --host $MONGOIP --out /var/tmp/mongo_backup/

   3. /var/tmp/mongo_backup/ 의 데이터베이스 덤프를 안전한 위치로 복사합니다.

4. Redis 클러스터를 백업합니다.

   1. HAProxy에서 Redis 끝점을 가져옵니다.

      # REDISIP=$(sudo hiera -c /etc/puppet/hiera.yaml redis_vip)

   2. Redis 클러스터의 마스터 암호를 가져옵니다.

      # REDISPASS=$(sudo hiera -c /etc/puppet/hiera.yaml redis::masterauth)

   3. Redis 클러스터에 대한 연결을 확인합니다.

      # redis-cli -a $REDISPASS -h $REDISIP ping

   4. Redis 데이터베이스를 덤프합니다.

      # redis-cli -a $REDISPASS -h $REDISIP bgsave

      데이터베이스 백업을 기본 /var/lib/redis/ 디렉토리에 저장합니다. 이 데이터베이스 덤프를 안전한 위치에 복사합니다.

5. 각 컨트롤러 노드에서 파일 시스템을 백업합니다.

   1. 백업을 위한 디렉터리를 생성합니다.

      # mkdir -p /var/tmp/filesystem_backup/

   2. 다음 tar 명령을 실행합니다.

      # tar --acls --ignore-failed-read --xattrs --xattrs-include='*.*' \
          -zcvf /var/tmp/filesystem_backup/`hostname`-filesystem-`date '+%Y-%m-%d-%H-%M-%S'`.tar \
          /etc \
          /srv/node \
          /var/log \
          /var/lib/nova \
          --exclude /var/lib/nova/instances \
          /var/lib/glance \
          /var/lib/keystone \
          /var/lib/cinder \
          /var/lib/heat \
          /var/lib/heat-config \
          /var/lib/heat-cfntools \
          /var/lib/rabbitmq \
          /var/lib/neutron \
          /var/lib/haproxy \
          /var/lib/openvswitch \
          /var/lib/redis \
          /var/lib/os-collect-config \
          /usr/libexec/os-apply-config \
          /usr/libexec/os-refresh-config \
          /home/heat-admin

      --ignore-failed-read 옵션은 누락된 디렉터리를 무시합니다. 이는 특정 서비스가 자체 사용자 지정 역할에서 사용하거나 구분되지 않은 경우 유용합니다.

   3. 결과 tar 파일을 안전한 위치에 복사합니다.

6. 오버클라우드에서 삭제된 행을 보관합니다.

   1. 삭제된 아카이브 인스턴스를 확인합니다.

      $ source ~/overcloudrc
      $ nova list --all-tenants --deleted

   2. 아카이브에 보관된 인스턴스가 없는 경우 오버클라우드 컨트롤러 노드 중 하나에서 다음 명령을 입력하여 삭제된 인스턴스를 보관합니다.

      # su - nova -s /bin/bash -c "nova-manage --debug db archive_deleted_rows --max_rows 1000"

      삭제된 모든 인스턴스를 보관할 때까지 이 명령을 다시 실행합니다.

   3. 오버클라우드 컨트롤러 노드 중 하나에 다음 명령을 입력하여 아카이브에서 삭제된 모든 인스턴스를 삭제합니다.

      # su - nova -s /bin/bash -c "nova-manage --debug db purge --all --all-cells"

   4. 보관된 나머지 인스턴스가 없는지 확인합니다.

      $ nova list --all-tenants --deleted

절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. 기본 OpenStack Platform 서비스를 중지합니다.

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   참고

   이로 인해 언더클라우드에 대해 짧은 다운타임이 발생합니다. Undercloud 업그레이드 중에 Overcloud가 계속 작동합니다.

3. RHEL 버전을 RHEL 7.7로 설정합니다.

   $ sudo subscription-manager release --set=7.7

4. python-tripleoclient 패키지 및 해당 종속성을 업데이트하여 마이너 버전 업데이트에 대한 최신 스크립트가 있는지 확인합니다.

   $ sudo yum update -y python-tripleoclient

5. openstack undercloud upgrade 명령을 실행합니다.

   $ openstack undercloud upgrade

6. 명령이 실행을 완료할 때까지 기다립니다.

7. 언더클라우드를 재부팅하여 운영 체제의 커널 및 기타 시스템 패키지를 업데이트합니다.

   $ sudo reboot

8. 노드가 부팅될 때까지 기다립니다.
9. stack 사용자로 언더클라우드에 로그인합니다.

절차

1. 사용자 지정 환경 파일에서 vhost 사용자 소켓 디렉터리를 변경합니다(예: network-environment.yaml ).

   parameter_defaults:
     NeutronVhostuserSocketDir: "/var/lib/vhost_sockets"

2. ovs-dpdk-permissions.yaml 파일을 openstack overcloud deploy 명령에 추가하여 OVS-DPDK의 qemu 그룹 설정을 hugetlbfs 로 구성합니다.

    -e environments/ovs-dpdk-permissions.yaml

3. 모든 인스턴스의 vHost 사용자 포트가 in dpdkvhostuserclient 모드인지 확인합니다. 자세한 내용은 수동으로 vhost 사용자 포트 모드 변경을 참조하십시오.

절차

1. yum 로그를 확인하여 새 이미지 아카이브를 사용할 수 있는지 확인합니다.

   $ sudo grep "rhosp-director-images" /var/log/yum.log

2. 새 아카이브를 사용할 수 있는 경우 현재 이미지를 새 이미지로 바꿉니다. 새 이미지를 설치하려면 먼저 stack 사용자 홈(/home/stack/images)의 images 디렉터리에서 기존 이미지를 제거합니다.

   $ rm -rf ~/images/*

3. 언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.

   $ source ~/stackrc

4. 아카이브를 추출합니다.

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-10.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-10.0.tar; do tar -xvf $i; done

5. 의 최신 이미지를 director로 가져오고 새 이미지를 사용하도록 노드를 구성합니다.

   $ cd ~/images
   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/
   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f csv --quote none | sed "1d" | paste -s -d " ")

6. 이미지 업데이트를 완료하려면 새 이미지가 있는지 확인합니다.

   $ openstack image list
   $ ls -l /httpboot

   또한 director는 이전 이미지를 유지하고 업데이트 시의 타임스탬프를 사용하여 이름을 바꿉니다. 이러한 이미지가 더 이상 필요하지 않은 경우 삭제합니다.

절차

1. rhel_reg_release 매개변수의 서브스크립션 관리 구성을 확인합니다. 이 매개변수가 설정되지 않은 경우 포함시키고 버전 7.7을 설정해야 합니다.

   parameter_defaults:
     ...
     rhel_reg_release: "7.7"

   오버클라우드 서브스크립션 관리 환경 파일에 변경 사항을 저장해야 합니다.

2. 원래의 openstack overcloud deploy 명령 및 --update-plan-only 옵션을 포함하여 현재 계획을 업데이트합니다. 예를 들면 다음과 같습니다.

   $ openstack overcloud deploy --update-plan-only \
     --templates  \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /home/stack/templates/network-environment.yaml \
     -e /home/stack/templates/storage-environment.yaml \
     -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml \
     [-e <environment_file>|...]

   --update-plan-only 는 director에 저장된 Overcloud 계획만 업데이트합니다. 오버클라우드와 관련된 환경 파일과 해당 업데이트 경로를 포함하려면 -e 옵션을 사용합니다. 후속 환경 파일에 정의된 매개 변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다. 다음 목록은 환경 파일 순서의 예입니다.

   • heat 템플릿 컬렉션의 초기화 파일(environments/network-isolation.yaml)을 포함한 네트워크 분리 파일 및 사용자 정의 NIC 구성 파일입니다.
   • 모든 외부 로드 밸런싱 환경 파일.
   • 모든 스토리지 환경 파일.
   • Red Hat CDN 또는 Satellite 등록의 환경 파일
   • 기타 사용자 지정 환경 파일

3. 오버클라우드의 정적 인벤토리 파일을 생성합니다.

   $ tripleo-ansible-inventory --ansible_ssh_user heat-admin --static-yaml-inventory ~/inventory.yaml

   오버클라우드 이름을 오버클라우드의 기본 오버클라우드 이름에 다르게 사용하는 경우 --plan 옵션을 사용하여 오버클라우드 이름을 설정합니다.

4. 모든 노드에서 운영 체제 버전을 Red Hat Enterprise Linux 7.7로 설정하는 작업이 포함된 플레이북을 생성합니다.

   $ cat > ~/set_release.yaml <<'EOF'
   - hosts: all
     gather_facts: false
     tasks:
       - name: set release to 7.7
         command: subscription-manager release --set=7.7
         become: true
   EOF

5. set_release.yaml 플레이북을 실행합니다.

   $ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit undercloud,Controller,Compute

   --limit 옵션을 사용하여 콘텐츠를 모든 Red Hat OpenStack Platform 노드에 적용합니다.

6. openstack overcloud update 명령을 사용하여 모든 노드에서 패키지 업데이트를 수행합니다.

   $ openstack overcloud update stack -i overcloud

   i는 각 노드를 순차적으로 업데이트하기 위해 대화형 모드를 실행합니다. 업데이트 프로세스가 노드 업데이트를 완료하면 스크립트에서 확인할 중단점을 제공합니다. i 옵션을 사용하지 않으면 업데이트가 첫 번째 중단점에서 일시 중지된 상태로 유지됩니다. 따라서 -i 옵션을 포함해야 합니다.

   스크립트는 다음 기능을 수행합니다.

   1. 스크립트는 노드에서 하나씩 실행됩니다.

      1. 컨트롤러 노드의 경우 전체 패키지 업데이트가 표시됩니다.
      2. 다른 노드의 경우 Puppet 모듈만 업데이트됩니다.

   2. Puppet은 한 번에 모든 노드에서 실행됩니다.

      1. 컨트롤러 노드의 경우 Puppet 실행은 구성을 동기화합니다.
      2. 다른 노드의 경우 Puppet에서 나머지 패키지를 업데이트하고 구성을 동기화합니다.

7. 업데이트 프로세스가 시작됩니다. 이 프로세스 중에 director는 IN_PROGRESS 상태를 보고하고 중단 지점을 지우도록 정기적으로 프롬프트를 표시합니다. 예를 들면 다음과 같습니다.

   starting package update on stack overcloud
   IN_PROGRESS
   IN_PROGRESS
   WAITING
   on_breakpoint: [u'overcloud-compute-0', u'overcloud-controller-2', u'overcloud-controller-1', u'overcloud-controller-0']
   Breakpoint reached, continue? Regexp or Enter=proceed (will clear 49913767-e2dd-4772-b648-81e198f5ed00), no=cancel update, C-c=quit interactive mode:

   Enter를 눌러 on_breakpoint 목록의 마지막 노드에서 중단 지점을 지웁니다. 그러면 해당 노드의 업데이트가 시작됩니다.

8. 스크립트는 노드의 업데이트 순서를 자동으로 미리 정의합니다.

   • 개별적으로 각 컨트롤러 노드
   • 개별 컴퓨팅 노드 각각
   • 각 Ceph Storage 노드 개별적으로
   • 다른 모든 노드 개별적으로

   이 주문을 사용하여 업데이트가 성공적으로 수행되도록 특히 다음 명령을 사용하는 것이 좋습니다.

   1. 각 컨트롤러 노드의 중단 지점을 개별적으로 지웁니다. 업데이트 후 노드의 서비스를 다시 시작해야 하는 경우 각 컨트롤러 노드에 개별 패키지 업데이트가 필요합니다. 이로 인해 다른 컨트롤러 노드의 고가용성 서비스로 중단이 줄어듭니다.
   2. 컨트롤러 노드를 업데이트한 후 각 컴퓨팅 노드의 중단 지점을 지웁니다. 컴퓨팅 노드 이름을 입력하여 특정 노드에서 중단 지점을 지우거나 Python 기반 정규 표현식을 사용하여 여러 컴퓨팅 노드에서 한 번에 중단 지점을 지울 수 있습니다.
   3. 각 Ceph Storage 노드의 중단 지점을 지웁니다. Ceph Storage 노드 이름을 입력하여 특정 노드에서 중단 지점을 지우거나 Python 기반 정규 표현식을 사용하여 여러 Ceph Storage 노드에서 한 번에 중단 지점을 지울 수 있습니다.
   4. 나머지 중단 지점을 지웁니다. 나머지 노드를 업데이트합니다. 노드 이름을 입력하여 특정 노드에서 중단 지점을 지우거나 Python 기반 정규 표현식을 사용하여 한 번에 여러 노드에서 중단 지점을 지울 수 있습니다.
   5. 모든 노드가 업데이트가 완료될 때까지 기다립니다.

9. update 명령은 업데이트가 완료되면 COMPLETE 상태를 보고합니다.

   ...
   IN_PROGRESS
   IN_PROGRESS
   IN_PROGRESS
   COMPLETE
   update finished with status COMPLETE

10. 컨트롤러 노드에 펜싱을 구성한 경우 업데이트 프로세스에서 해당 노드를 비활성화할 수 있습니다. 업데이트 프로세스가 완료되면 컨트롤러 노드 중 하나에서 다음 명령을 사용하여 펜싱을 다시 활성화합니다.

    $ sudo pcs property set stonith-enabled=true

절차

1. 재부팅하려는 노드에 로그인합니다.

2. 선택 사항: 노드에서 Pacemaker 리소스를 사용하는 경우 클러스터를 중지합니다.

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

3. 노드를 재부팅합니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo reboot

4. 노드가 부팅될 때까지 기다립니다.

5. 서비스를 확인합니다. 예를 들면 다음과 같습니다.

   1. 노드에서 Pacemaker 서비스를 사용하는 경우 노드가 클러스터에 다시 가입했는지 확인합니다.

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

   2. 노드에서 Systemd 서비스를 사용하는 경우 모든 서비스가 활성화되었는지 확인합니다.

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

   3. 모든 컨트롤러 및 구성 가능한 노드에 대해 이 단계를 반복합니다.

절차

1. Ceph MON 또는 컨트롤러 노드에 로그인하고 Ceph Storage 클러스터 재조정을 일시적으로 비활성화합니다.

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. 재부팅할 첫 번째 Ceph Storage 노드를 선택하고 로그인합니다.

3. 노드를 재부팅합니다.

   $ sudo reboot

4. 노드가 부팅될 때까지 기다립니다.

5. Ceph MON 또는 컨트롤러 노드에 로그인하고 클러스터 상태를 확인합니다.

   $ sudo ceph -s

   pgmap이 모든 pgs를 정상(active+clean)으로 보고하는지 확인합니다.

6. Ceph MON 또는 컨트롤러 노드에서 로그아웃하고 다음 Ceph Storage 노드를 재부팅한 후 상태를 확인합니다. 모든 Ceph Storage 노드를 재부팅할 때까지 이 프로세스를 반복합니다.

7. 완료되면 Ceph MON 또는 컨트롤러 노드에 로그인하고 클러스터 재조정을 다시 활성화합니다.

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

8. 최종 상태 검사를 수행하여 클러스터가 HEALTH_OK를 보고하는지 확인합니다.

   $ sudo ceph status

절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. 재부팅하려는 컴퓨팅 노드를 확인하려면 모든 컴퓨팅 노드를 나열합니다.

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

3. 오버클라우드에서 컴퓨팅 노드를 선택하여 비활성화합니다.

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set <hostname> nova-compute --disable

4. 컴퓨팅 노드에 모든 인스턴스를 나열합니다.

   (overcloud) $ openstack server list --host <hostname> --all-projects

5. 인스턴스를 마이그레이션합니다. 마이그레이션 전략에 대한 자세한 내용은 컴퓨팅 노드 간 가상 머신 마이그레이션을 참조하십시오.

6. Compute 노드에 로그인하여 재부팅합니다.

   [heat-admin@overcloud-compute-0 ~]$ sudo reboot

7. 노드가 부팅될 때까지 기다립니다.

8. 컴퓨팅 노드를 활성화합니다.

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service set <hostname> nova-compute --enable

9. 컴퓨팅 노드가 활성화되어 있는지 확인합니다.

   (overcloud) $ openstack compute service list

절차

1. 노드에 로그인합니다.

2. yum 을 실행하여 시스템 패키지를 확인합니다.

   $ sudo yum list qemu-img-rhev qemu-kvm-common-rhev qemu-kvm-rhev qemu-kvm-tools-rhev openvswitch

3. ovs-vsctl 을 실행하여 현재 실행 중인 버전을 확인합니다.

   $ sudo ovs-vsctl --version

4. 모든 노드에 대해 이 단계를 반복합니다.

절차

1. 언더클라우드 액세스 세부 정보를 가져옵니다.

   $ source ~/stackrc

2. 실패한 Systemd 서비스를 확인합니다.

   $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. 언더클라우드의 사용 가능한 공간을 확인합니다.

   $ df -h

   "Undercloud Requirements(Undercloud 요구 사항)" 를 기준으로 사용하여 사용 가능한 공간이 적절한지 확인합니다.

4. 언더클라우드에 NTP가 설치되어 있으면 클록이 동기화되었는지 확인합니다.

   $ sudo ntpstat

5. 언더클라우드 네트워크 서비스를 확인합니다.

   $ openstack network agent list

   모든 에이전트는 Alive 이고 해당 상태는 UP 이어야 합니다.

6. 언더클라우드 계산 서비스를 확인합니다.

   $ openstack compute service list

   모든 에이전트의 상태가 활성화되고 상태가 up이어야 합니다

절차

1. 언더클라우드 액세스 세부 정보를 가져옵니다.

   $ source ~/stackrc

2. 베어 메탈 노드의 상태를 확인합니다.

   $ openstack baremetal node list

   모든 노드에 유효한 전원 상태(on)가있어야 하며 유지 관리 모드는 false 여야 합니다.

3. 실패한 Systemd 서비스를 확인합니다.

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. 모든 서비스에 대한 HAProxy 연결을 확인합니다. haproxy.stats 서비스에 대한 컨트롤 플레인 VIP 주소 및 인증 정보를 가져옵니다.

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /etc/haproxy/haproxy.cfg'

5. 이전 단계에서 얻은 연결 및 인증 정보를 사용하여 RHOSP 서비스의 연결 상태를 확인합니다.

   SSL이 활성화되지 않은 경우 다음 cURL 요청에서 다음 세부 정보를 사용합니다.

   $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   SSL이 활성화된 경우 다음 cURL 요청에서 다음 세부 정보를 사용합니다.

   curl -s -u admin:<PASSWORD> "https://<HOSTNAME>:1993/;csv" | egrep -vi "(frontend|backend)" | awk -F',' '{ print $1" "$2" "$18 }'

   < PASSWORD > 및 < IP ADDRESS > 또는 < HOSTNAME > 값을 haproxy.stats 서비스의 각 정보로 바꿉니다. 결과 목록은 각 노드의 OpenStack Platform 서비스와 해당 연결 상태를 표시합니다.

6. 오버클라우드 데이터베이스 복제 상태를 확인합니다.

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo clustercheck" ; done

7. RabbitMQ 클러스터 상태를 확인합니다.

   $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo rabbitmqctl node_health_check" ; done

8. Pacemaker 리소스 상태를 확인합니다.

   $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   다음 항목 검색:

   • 온라인 의 모든 클러스터 노드.
   • 모든 클러스터 노드에서 중지된 리소스가 없습니다.
   • 실패한 pacemaker 작업이 없습니다.

9. 각 오버클라우드 노드의 디스크 공간을 확인합니다.

   $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. Overcloud Ceph Storage 클러스터 상태를 확인합니다. 다음 명령은 컨트롤러 노드에서 ceph 툴을 실행하여 클러스터를 확인합니다.

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. Ceph Storage OSD에서 사용 가능한 공간이 있는지 확인합니다. 다음 명령은 컨트롤러 노드에서 ceph 툴을 실행하여 사용 가능한 공간을 확인합니다.

    $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

    중요

    각 Ceph 개체 스토리지 데몬(OSD)에 대한 PG(배치 그룹) 수는 기본적으로 250개를 초과해서는 안 됩니다. OSD당 더 많은 PG로 Ceph 노드를 업그레이드하면 경고 상태가 되며 업그레이드 프로세스가 실패할 수 있습니다. 업그레이드 프로세스를 시작하기 전에 OSD당 PG 수를 늘릴 수 있습니다. 이 문제를 진단하고 해결하는 방법에 대한 자세한 내용은 하나 이상의 OSD에 할당된 Ceph PG가 250보다 높기 때문에 OpenStack FFU 문서를 10에서 13번으로 참조하십시오.

12. 오버클라우드 노드에서 클록이 동기화되었는지 확인합니다.

    $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. 오버클라우드 액세스 세부 정보를 소싱합니다.

    $ source ~/overcloudrc

14. 오버클라우드 네트워크 서비스를 확인합니다.

    $ openstack network agent list

    모든 에이전트는 Alive 이고 해당 상태는 UP 이어야 합니다.

15. 오버클라우드 계산 서비스를 확인합니다.

    $ openstack compute service list

    모든 에이전트의 상태가 활성화되고 상태가 up이어야 합니다

16. 오버클라우드 볼륨 서비스를 확인합니다.

    $ openstack volume service list

    모든 에이전트의 상태가 활성화되고 상태가 up 이어야 합니다.

1. 오버클라우드 액세스 세부 정보를 소싱합니다.

   $ source ~/overcloudrc

2. 스냅샷을 만들 인스턴스의 서버 ID를 찾습니다.

   $ openstack server list

3. 스냅샷을 생성하기 전에 소스 인스턴스를 종료하여 모든 데이터가 디스크로 플러시되었는지 확인합니다.

   $ openstack server stop SERVER_ID

4. 인스턴스의 스냅샷 이미지를 생성합니다.

   $ openstack image create --id SERVER_ID SNAPSHOT_NAME

5. 이 스냅샷 이미지를 사용하여 새 인스턴스를 부팅합니다.

   $ openstack server create --flavor DPDK_FLAVOR --nic net-id=DPDK_NET_ID--image SNAPSHOT_NAME INSTANCE_NAME

6. 필요한 경우 새 인스턴스 상태가 ACTIVE인지 확인합니다.

   $ openstack server list

절차

1. 각 노드에서 다음 명령을 실행하여 노드의 전체 yum 기록을 파일에 저장합니다.

   $ sudo yum history list all > /home/heat-admin/$(hostname)-yum-history-all

2. 각 노드에서 다음 명령을 실행하여 마지막 yum 히스토리 항목의 ID를 저장합니다.

   $ sudo yum history list all | head -n 5 | tail -n 1 | awk '{print $1}' > /home/heat-admin/$(hostname)-yum-history-all-last-id

3. 이러한 파일을 안전한 위치에 복사합니다.

절차

1. stack 사용자로 director에 로그인합니다.

2. 현재 OpenStack Platform 리포지토리를 비활성화합니다.

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-10-rpms

3. 새 OpenStack Platform 리포지토리를 활성화합니다.

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-11-rpms

4. 오버클라우드 기본 이미지에 대한 업데이트를 비활성화합니다.

   $ sudo yum-config-manager --setopt=exclude=rhosp-director-images* --save

5. 기본 OpenStack Platform 서비스를 중지합니다.

   $ sudo systemctl stop 'openstack-*' 'neutron-*' httpd

   참고

   이로 인해 언더클라우드에 대해 짧은 다운타임이 발생합니다. Undercloud 업그레이드 중에 Overcloud가 계속 작동합니다.

6. 기본 프로비저닝/제어 플레인 네트워크가 192.0.2.0/24 에서 192.168.24.0/24 로 변경되었습니다. 이전 undercloud.conf 파일에서 기본 네트워크 값을 사용한 경우 프로비저닝/컨트롤 플레인 네트워크가 192.0.2.0/24 로 설정됩니다. 즉, 192.0.2.0/24 네트워크를 계속 사용하려면 undercloud.conf 파일에서 특정 매개변수를 설정해야 합니다. 이러한 매개변수는 다음과 같습니다.

   • local_ip
   • network_gateway
   • undercloud_public_vip
   • undercloud_admin_vip
   • network_cidr
   • masquerade_network
   • dhcp_start
   • dhcp_end

   향후 업그레이드 중에 192 .0.2.0/24 CIDR을 계속 사용하도록 undercloud. conf 에서 네트워크 값을 설정합니다. openstack undercloud upgrade 명령을 실행하기 전에 네트워크 구성이 올바르게 설정되었는지 확인합니다.

7. yum 을 실행하여 director의 기본 패키지를 업그레이드합니다.

   $ sudo yum update -y instack-undercloud openstack-puppet-modules openstack-tripleo-common python-tripleoclient

8. 다음 명령을 실행하여 언더클라우드를 업그레이드합니다.

   $ openstack undercloud upgrade

9. 언더클라우드 업그레이드 프로세스가 완료될 때까지 기다립니다.

절차

1. stack 사용자로 director에 로그인합니다.

2. 현재 OpenStack Platform 리포지토리를 비활성화합니다.

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-11-rpms

3. 새 OpenStack Platform 리포지토리를 활성화합니다.

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-12-rpms

4. 오버클라우드 기본 이미지에 대한 업데이트를 비활성화합니다.

   $ sudo yum-config-manager --setopt=exclude=rhosp-director-images* --save

5. yum 을 실행하여 director의 기본 패키지를 업그레이드합니다.

   $ sudo yum update -y python-tripleoclient

6. /home/stack/undercloud.conf 파일을 편집하고 enabled_drivers 매개 변수에 pxe_ ssh 드라이버가 포함되어 있지 않은지 확인합니다. 이 드라이버는 더 이상 사용되지 않으며 Red Hat OpenStack Platform에서 제거된 VBMC(Virtual Baseboard Management Controller)를 사용합니다. 이 새로운 드라이버 및 마이그레이션 지침에 대한 자세한 내용은 Director 설치 및 사용 가이드의 부록 "Virtual Baseboard Management Controller (Virtual Baseboard Management Controller)" 를 참조하십시오.

7. 다음 명령을 실행하여 언더클라우드를 업그레이드합니다.

   $ openstack undercloud upgrade

8. 언더클라우드 업그레이드 프로세스가 완료될 때까지 기다립니다.

절차

1. stack 사용자로 director에 로그인합니다.

2. 현재 OpenStack Platform 리포지토리를 비활성화합니다.

   $ sudo subscription-manager repos --disable=rhel-7-server-openstack-12-rpms

3. RHEL 버전을 RHEL 7.9로 설정합니다.

   $ sudo subscription-manager release --set=7.9

4. 새 OpenStack Platform 리포지토리를 활성화합니다.

   $ sudo subscription-manager repos --enable=rhel-7-server-openstack-13-rpms

5. 오버클라우드 기본 이미지에 대한 업데이트를 다시 활성화합니다.

   $ sudo yum-config-manager --setopt=exclude= --save

6. yum 을 실행하여 director의 기본 패키지를 업그레이드합니다.

   $ sudo yum update -y python-tripleoclient

7. 다음 명령을 실행하여 언더클라우드를 업그레이드합니다.

   $ openstack undercloud upgrade

8. 언더클라우드 업그레이드 프로세스가 완료될 때까지 기다립니다.

9. 언더클라우드를 재부팅하여 운영 체제의 커널 및 기타 시스템 패키지를 업데이트합니다.

   $ sudo reboot

10. 노드가 부팅될 때까지 기다립니다.

절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. openstack-glance-registry 서비스를 중지하고 비활성화합니다.

   $ sudo systemctl stop openstack-glance-registry
   $ sudo systemctl disable openstack-glance-registry

3. mongod 서비스를 중지하고 비활성화합니다.

   $ sudo systemctl stop mongod
   $ sudo systemctl disable mongod

절차

1. 오버클라우드 배포의 registry.redhat.io 에서 직접 이미지를 가져오려면 이미지 매개변수를 지정하는 환경 파일이 필요합니다. 다음 명령을 실행하여 컨테이너 이미지 환경 파일을 생성합니다.

   (undercloud) $ sudo openstack overcloud container image prepare \
     --namespace=registry.redhat.io/rhosp13 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml

   • 선택적 서비스에 대한 환경 파일을 포함하려면 -e 옵션을 사용합니다.
   • r 옵션을 사용하여 사용자 지정 역할 파일을 포함합니다.
   • Ceph Storage를 사용하는 경우 Ceph Storage 컨테이너 이미지 위치를 정의하는 추가 매개변수를 포함합니다. --set ceph_namespace,--set ceph_image,--set ceph_tag.

2. overcloud_images.yaml 파일을 수정하고 다음 매개변수를 포함하여 배포 중에 registry.redhat.io 로 인증합니다.

   ContainerImageRegistryLogin: true
   ContainerImageRegistryCredentials:
     registry.redhat.io:
       <USERNAME>: <PASSWORD>

   • &lt ;USERNAME > 및 < PASSWORD >를 registry.redhat.io 의 인증 정보로 바꿉니다.

     overcloud_images.yaml 파일에는 언더클라우드의 이미지 위치가 포함되어 있습니다. 배포를 통해 이 파일을 포함합니다.

     참고

     openstack overcloud deploy 명령을 실행하기 전에 원격 레지스트리에 로그인해야 합니다.

     (undercloud) $ sudo docker login registry.redhat.io

절차

1. 로컬 Undercloud 레지스트리의 주소를 찾습니다. 주소는 다음 패턴을 사용합니다.

   <REGISTRY_IP_ADDRESS>:8787

   이전에 undercloud. conf 파일의 local_ip 매개변수로 설정한 언더클라우드 의 IP 주소를 사용합니다. 아래 명령의 경우 주소는 192.168.24.1:8787 로 간주됩니다.

2. registry.redhat.io 에 로그인합니다.

   (undercloud) $ docker login registry.redhat.io --username $RH_USER --password $RH_PASSWD

3. 이미지를 로컬 레지스트리에 업로드하는 템플릿을 생성하고 해당 이미지를 참조하는 환경 파일을 생성합니다.

   (undercloud) $ openstack overcloud container image prepare \
     --namespace=registry.redhat.io/rhosp13 \
     --push-destination=192.168.24.1:8787 \
     --prefix=openstack- \
     --tag-from-label {version}-{release} \
     --output-env-file=/home/stack/templates/overcloud_images.yaml \
     --output-images-file /home/stack/local_registry_images.yaml

   • 선택적 서비스에 대한 환경 파일을 포함하려면 -e 옵션을 사용합니다.
   • r 옵션을 사용하여 사용자 지정 역할 파일을 포함합니다.
   • Ceph Storage를 사용하는 경우 Ceph Storage 컨테이너 이미지 위치를 정의하는 추가 매개변수를 포함합니다. --set ceph_namespace,--set ceph_image,--set ceph_tag.

4. 다음 두 파일이 생성되었는지 확인합니다.

   • 원격 소스의 컨테이너 이미지 정보가 포함된 local_registry_images.yaml 이 파일을 사용하여 Red Hat Container Registry(registry.redhat.io)에서 언더클라우드로 이미지를 가져옵니다.
   • overcloud_images.yaml - 언더클라우드의 최종 이미지 위치가 포함됩니다. 배포와 함께 이 파일을 포함합니다.

5. 원격 레지스트리에서 컨테이너 이미지를 가져와서 언더클라우드 레지스트리로 푸시합니다.

   (undercloud) $ openstack overcloud container image upload \
     --config-file  /home/stack/local_registry_images.yaml \
     --verbose

   네트워크 및 언더클라우드 디스크의 속도에 따라 필요한 이미지를 가져오는 데 다소 시간이 걸릴 수 있습니다.

   참고

   컨테이너 이미지는 약 10GB의 디스크 공간을 사용합니다.

6. 이미지가 이제 Undercloud의 docker-distribution 레지스트리에 저장됩니다. 언더클라우드의 docker-distribution 레지스트리에서 이미지 목록을 보려면 다음 명령을 실행합니다.

   (undercloud) $  curl http://192.168.24.1:8787/v2/_catalog | jq .repositories[]

   참고

   _catalog 리소스는 자체적으로 100개의 이미지만 표시합니다. 더 많은 이미지를 표시하려면 _catalog 리소스와 함께 ?n=<interger > 쿼리 문자열을 사용하여 더 많은 수의 이미지를 표시합니다.

   (undercloud) $  curl http://192.168.24.1:8787/v2/_catalog?n=150 | jq .repositories[]

   특정 이미지의 태그 목록을 보려면 skopeo 명령을 사용합니다.

   (undercloud) $ curl -s http://192.168.24.1:8787/v2/rhosp13/openstack-keystone/tags/list | jq .tags

   태그가 지정된 이미지를 확인하려면 skopeo 명령을 사용합니다.

   (undercloud) $ skopeo inspect --tls-verify=false docker://192.168.24.1:8787/rhosp13/openstack-keystone:13.0-44

절차

1. 로컬 레지스트리로 이미지를 가져올 템플릿을 생성합니다.

   $ source ~/stackrc
   (undercloud) $ openstack overcloud container image prepare \
     --namespace=rhosp13 \
     --prefix=openstack- \
     --output-images-file /home/stack/satellite_images

   • 선택적 서비스에 대한 환경 파일을 포함하려면 -e 옵션을 사용합니다.
   • r 옵션을 사용하여 사용자 지정 역할 파일을 포함합니다.
   • Ceph Storage를 사용하는 경우 Ceph Storage 컨테이너 이미지 위치를 정의하는 추가 매개변수를 포함합니다. --set ceph_namespace,--set ceph_image,--set ceph_tag.
   참고

   openstack overcloud container image prepare 명령의 이 버전은 registry.redhat.io 의 레지스트리를 대상으로 이미지 목록을 생성합니다. 이후 단계에서 사용한 openstack overcloud container image prepare 명령과 다른 값이 사용됩니다.

2. 이렇게 하면 컨테이너 이미지 정보가 포함된 satellite_images 라는 파일이 생성됩니다. 이 파일을 사용하여 컨테이너 이미지를 Satellite 6 서버에 동기화합니다.

3. satellite_images 파일에서 YAML 관련 정보를 제거하고 이미지 목록만 포함하는 플랫 파일로 변환합니다. 다음 sed 명령은 다음을 수행합니다.

   (undercloud) $ awk -F ':' '{if (NR!=1) {gsub("[[:space:]]", ""); print $2}}' ~/satellite_images > ~/satellite_images_names

   그러면 Satellite 서버로 가져온 이미지 목록이 제공됩니다.

4. satellite_images_names 파일을 Satellite 6 hammer 툴이 포함된 시스템으로 복사합니다. 또는 Hammer CLI 가이드의 지침에 따라 hammer 툴을 언더클라우드에 설치합니다.

5. 다음 hammer 명령을 실행하여 Satellite 조직에 새 제품(OSP13 Containers)을 생성합니다.

   $ hammer product create \
     --organization "ACME" \
     --name "OSP13 Containers"

   이 사용자 지정 제품에 이미지를 저장합니다.

6. 제품에 기본 컨테이너 이미지를 추가합니다.

   $ hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name rhosp13/openstack-base \
     --name base

7. satellite_images 파일에서 오버클라우드 컨테이너 이미지를 추가합니다.

   $ while read IMAGE; do \
     IMAGENAME=$(echo $IMAGE | cut -d"/" -f2 | sed "s/openstack-//g" | sed "s/:.*//g") ; \
     hammer repository create \
     --organization "ACME" \
     --product "OSP13 Containers" \
     --content-type docker \
     --url https://registry.redhat.io \
     --docker-upstream-name $IMAGE \
     --name $IMAGENAME ; done < satellite_images_names

8. 컨테이너 이미지를 동기화합니다.

   $ hammer product synchronize \
     --organization "ACME" \
     --name "OSP13 Containers"

   Satellite 서버가 동기화를 완료할 때까지 기다립니다.

   참고

   설정에 따라 hammer에서 Satellite 서버 사용자 이름과 암호가 필요할 수 있습니다. hammer를 구성한 후 구성 파일을 사용하여 자동으로 로그인할 수 있습니다. Hammer CLI Guide의 "Authentication" 섹션을 참조하십시오.

9. Satellite 6 서버에서 콘텐츠 뷰를 사용하는 경우 새 콘텐츠 뷰 버전을 생성하여 이미지를 통합할 수 있습니다.

10. base 이미지에 사용할 수 있는 태그를 확인합니다.

    $ hammer docker tag list --repository "base" \
      --organization "ACME" \
      --product "OSP13 Containers"

    OpenStack Platform 컨테이너 이미지에 대한 태그가 표시됩니다.

11. 언더클라우드로 돌아가서 Satellite 서버에서 이미지에 대한 환경 파일을 생성합니다. 다음은 환경 파일을 생성하기 위한 예제 명령입니다.

    (undercloud) $ openstack overcloud container image prepare \
      --namespace=satellite6.example.com:5000 \
      --prefix=acme-osp13_containers- \
      --tag-from-label {version}-{release} \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    참고

    이 버전의 openstack overcloud container prepare 명령은 Satellite 서버를 대상으로 합니다. 이전 단계에서 사용한 openstack overcloud container image prepare 명령과 다른 값을 사용합니다.

    이 명령을 실행할 때 다음 데이터를 포함합니다.

    • --namespace - Satellite 서버에 있는 레지스트리의 URL 및 포트입니다. Red Hat Satellite의 레지스트리 포트는 5000입니다. 예를 들면 --namespace=satellite6.example.com:5000 입니다.

      참고

      Red Hat Satellite 버전 6.10을 사용하는 경우 포트를 지정할 필요가 없습니다. 기본 포트 443 이 사용됩니다. 자세한 내용은 " RHOSP13 배포를 Red Hat Satellite 6.10에 어떻게 적용할 수 있습니까?"에서 참조하십시오.

    • --prefix= - 접두사는 소문자를 사용하고 밑줄에 공백을 대체하는 라벨의 Satellite 6 규칙을 기반으로 합니다. 접두사는 콘텐츠 뷰 사용 여부에 따라 달라집니다.

      • 콘텐츠 뷰를 사용하는 경우 구조는 [org]-[environment]-[content view]-[product]-입니다. 예를 들면 acme-production-myosp13-osp13_containers- 입니다.
      • 콘텐츠 뷰를 사용하지 않는 경우 구조는 [org]-[product]-입니다. 예를 들면 acme-osp13_containers- 입니다.
    • --tag-from-label {version}-{release} - 각 이미지의 최신 태그를 식별합니다.
    • -e - 옵션 서비스의 환경 파일을 포함합니다.
    • -R - 사용자 지정 역할 파일을 포함합니다.

    • --set ceph_namespace,--set ceph_image,--set ceph_tag - Ceph Storage를 사용하는 경우 추가 매개 변수를 포함하여 Ceph Storage 컨테이너 이미지 위치를 정의합니다. 이제 ceph_image에는 Satellite별 접두사가 포함됩니다. 이 접두사는 --prefix 옵션과 동일한 값입니다. 예를 들면 다음과 같습니다.

      --set ceph_image=acme-osp13_containers-rhceph-3-rhel7

      이렇게 하면 오버클라우드에서 Satellite 명명 규칙을 사용하여 Ceph 컨테이너 이미지를 사용합니다.

12. overcloud_images.yaml 파일에는 Satellite 서버에 이미지 위치가 포함되어 있습니다. 배포를 통해 이 파일을 포함합니다.

절차

1. 사용자 정의 환경 파일을 확인합니다.

   $ cat ~/templates/custom_environment.yaml

2. 파일 콘텐츠에서 resource_registry 섹션이 있는지 확인합니다.

3. resource_registry 섹션에서 구성 가능한 서비스를 확인합니다. 다음 네임스페이스를 사용하여 구성 가능한 서비스를 구성합니다.

   OS::TripleO::Services

   예를 들어 다음 구성 가능 서비스는 OpenStack Bare Metal Service(ironic) API용입니다.

   OS::TripleO::Services::IronicApi

4. 구성 가능 서비스가 Puppet별 Heat 템플릿에 매핑되는지 확인합니다. 예를 들면 다음과 같습니다.

   resource_registry:
     OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/puppet/services/ironic-api.yaml

5. 컨테이너화된 Heat 템플릿 버전이 /usr/share/openstack-triple-heat-template/docker/services/ 에 있는지 확인하고 서비스를 컨테이너화된 버전으로 다시 매핑합니다.

   resource_registry:
     OS::TripleO::Services::IronicApi: /usr/share/openstack-triple-heat-template/docker/services/ironic-api.yaml

   또는 /usr/share/openstack-tripleo-heat-templates/environments/ 에 있는 서비스에 대해 업데이트된 환경 파일을 사용합니다. 예를 들어 OpenStack Bare Metal Service(ironic)를 활성화하기 위한 최신 환경 파일은 컨테이너화된 서비스 매핑을 포함하는 /usr/share/openstack-tripleo-heat-templates/environments/services/ironic.yaml 입니다.

   사용자 지정 서비스에서 컨테이너화된 서비스를 사용하지 않는 경우 Puppet별 Heat 템플릿에 대한 매핑을 유지합니다.

절차

1. director 관리 또는 외부 Ceph Storage 클러스터를 사용하는 경우 ceph-ansible 패키지를 설치합니다.

   1. 언더클라우드에서 Ceph Tools 리포지토리를 활성화합니다.

      [stack@director ~]$ sudo subscription-manager repos --enable=rhel-7-server-rhceph-3-tools-rpms

   2. ceph-ansible 패키지를 언더클라우드에 설치합니다.

      [stack@director ~]$ sudo yum install -y ceph-ansible

2. Ceph별 환경 파일을 확인하고 Ceph별 heat 리소스에서 컨테이너화된 서비스를 사용하는지 확인합니다.

   • director에서 관리하는 Ceph Storage 클러스터의 경우 resource_register 의 리소스가 docker/services/ceph-ansible 의 템플릿을 가리키는지 확인합니다.

     resource_registry:
       OS::TripleO::Services::CephMgr: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mgr.yaml
       OS::TripleO::Services::CephMon: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-mon.yaml
       OS::TripleO::Services::CephOSD: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-osd.yaml
       OS::TripleO::Services::CephClient: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-client.yaml

     중요

     이 구성은 /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml 환경 파일에 포함되어 있으며, -e 를 사용하여 향후 모든 배포 명령에 포함할 수 있습니다.

     참고

     환경에서 사용하려는 환경 또는 템플릿 파일이 /usr/share 디렉터리에 없는 경우 파일의 절대 경로를 포함해야 합니다.

   • 외부 Ceph Storage 클러스터의 경우 resource_register의 리소스가 docker/services/ceph-ansible 의 템플릿을 가리키는지 확인합니다.

     resource_registry:
       OS::TripleO::Services::CephExternal: /usr/share/openstack-tripleo-heat-templates/docker/services/ceph-ansible/ceph-external.yaml

     중요

     이 구성은 /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml 환경 파일에 포함되어 있으며, -e 를 사용하여 향후 모든 배포 명령에 포함할 수 있습니다.

3. director가 관리하는 Ceph Storage 클러스터의 경우 새 CephAnsibleDisksConfig 매개변수를 사용하여 디스크가 매핑되는 방법을 정의합니다. 이전 버전의 Red Hat OpenStack Platform에서는 ceph::profile::params::osds hieradata를 사용하여 OSD 레이아웃을 정의했습니다. 이 hieradata를 CephAnsibleDisksConfig 매개변수 구조로 변환합니다. 다음 예제에서는 공동 배치 및 비할당 Ceph 저널 디스크의 경우 hieradata를 CephAnsibleDisksConfig 매개변수 구조로 변환하는 방법을 보여줍니다.

   중요

   osd_scenario 를 설정해야 합니다. osd_scenario 설정을 해제하면 배포에 실패할 수 있습니다.

   • Ceph 저널 디스크를 배치하는 시나리오에서는 hieradata에 다음이 포함된 경우 다음을 실행합니다.

     parameter_defaults:
       ExtraConfig:
         ceph::profile::params::osd_journal_size: 512
         ceph::profile::params::osds:
           '/dev/sdb': {}
           '/dev/sdc': {}
           '/dev/sdd': {}

     CephAnsibleDisksConfig 매개변수를 사용하여 hieradata를 변환하고 ceph::profile::params::osds 를 {} 로 설정합니다.

     parameter_defaults:
       CephAnsibleDisksConfig:
         devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         journal_size: 512
         osd_scenario: collocated
       ExtraConfig:
           ceph::profile::params::osds: {}

   • 저널이 더 빠른 전용 장치에 있고 비할당되는 시나리오에서는 hieradata에 다음이 포함된 경우 다음을 수행합니다.

     parameter_defaults:
       ExtraConfig:
         ceph::profile::params::osd_journal_size: 512
         ceph::profile::params::osds:
           '/dev/sdb':
              journal: ‘/dev/sdn’
           '/dev/sdc':
              journal: ‘/dev/sdn’
           '/dev/sdd':
              journal: ‘/dev/sdn’

     CephAnsibleDisksConfig 매개변수를 사용하여 hieradata를 변환하고 ceph::profile::params::osds 를 {} 로 설정합니다.

     parameter_defaults:
       CephAnsibleDisksConfig:
         devices:
         - /dev/sdb
         - /dev/sdc
         - /dev/sdd
         dedicated_devices:
         - /dev/sdn
         - /dev/sdn
         - /dev/sdn
         journal_size: 512
         osd_scenario: non-collocated
       ExtraConfig:
         ceph::profile::params::osds: {}

   ceph-ansible 에 사용되는 OSD 디스크 레이아웃 옵션 전체 목록은 /usr/share/ceph-ansible/group_vars/osds.yml.sample 의 샘플 파일을 확인합니다.

4. -e 옵션을 사용하여 향후 배포 명령을 사용하여 새 Ceph 구성 환경 파일을 포함합니다. 여기에는 다음 파일이 포함됩니다.

   • director에서 관리하는 Ceph Storage:

     • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml.
     • Ansible 기반 디스크 매핑이 있는 환경 파일.
     • Ceph Storage 사용자 지정이 포함된 추가 환경 파일입니다.

   • 외부 Ceph Storage:

     • /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible-external.yaml
     • Ceph Storage 사용자 지정이 포함된 추가 환경 파일입니다.

절차

1. director의 동적 Ansible 스크립트가 OpenStack Platform 12 버전으로 업데이트되었으며, 이 버전에서는 Overcloud 계획에서 RoleNetHostnameMap Heat 매개 변수를 사용하여 인벤토리를 정의합니다. 그러나 현재 오버클라우드에서는 RoleNetHostnameMap 매개변수가 없는 OpenStack Platform 11 템플릿 버전을 사용합니다. 즉, 다음 명령을 사용하여 생성할 수 있는 임시 정적 인벤토리 파일을 생성해야 합니다.

   $ openstack server list -c Networks -f value | cut -d"=" -f2 > overcloud_hosts

2. 다음이 포함된 Ansible 플레이북(undercloud-ca.yml)을 생성합니다.

   ---
   - name: Add undercloud CA to overcloud nodes
     hosts: all
     user: heat-admin
     become: true
     vars:
       ca_certificate: /etc/pki/ca-trust/source/anchors/cm-local-ca.pem
     tasks:
       - name: Copy undercloud CA
         copy:
           src: "{{ ca_certificate }}"
           dest: /etc/pki/ca-trust/source/anchors/
       - name: Update trust
         command: "update-ca-trust extract"
       - name: Get the swift endpoint
         shell: |
           sudo hiera swift::keystone::auth::public_url | awk -F/ '{print $3}'
         register: swift_endpoint
         delegate_to: 127.0.0.1
         become: yes
         become_user: stack
       - name: Verify URL
         uri:
           url: https://{{ swift_endpoint.stdout }}/healthcheck
           return_content: yes
         register: verify
       - name: Report output
         debug:
           msg: "{{ ansible_hostname }} can access the undercloud's Public API"
         when: verify.content == "OK"

   이 플레이북에는 각 노드에서 다음을 수행하는 여러 작업이 포함되어 있습니다.

   • Undercloud의 인증 기관 파일을 Overcloud 노드에 복사합니다. 언더클라우드에서 생성한 경우 기본 위치는 /etc/pki/ca-trust/source/anchors/cm-local-ca.pem 입니다.
   • 명령을 실행하여 Overcloud 노드에서 인증 기관 신뢰 데이터베이스를 업데이트합니다.
   • Overcloud 노드에서 언더클라우드의 Object Storage Public API를 확인하고 성공했는지 보고합니다.

3. 다음 명령을 사용하여 플레이북을 실행합니다.

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml

   이는 임시 인벤토리를 사용하여 Ansible에 오버클라우드 노드를 제공합니다.

   사용자 지정 인증 기관 파일을 사용하는 경우 ca_certificate 변수를 위치로 변경할 수 있습니다. 예를 들면 다음과 같습니다.

   $ ansible-playbook -i overcloud_hosts undercloud-ca.yml -e ca_certificate=/home/stack/ssl/ca.crt.pem

4. 결과 Ansible 출력에 노드에 대한 디버그 메시지가 표시되어야 합니다. 예를 들면 다음과 같습니다.

   ok: [192.168.24.100] => {
       "msg": "overcloud-controller-0 can access the undercloud's Public API"
   }

절차

1. 환경 파일을 선택하고 ExtraConfig 매개변수가 있는지 확인합니다.

   $ grep ExtraConfig ~/templates/custom-config.yaml

2. 선택한 파일에서 모든 역할(예: ControllerExtraConfig)에 대한 ExtraConfig 매개변수를 표시하는 경우 해당 파일의 전체 매개변수 구조를 확인합니다.

3. 매개 변수에 SECTION/parameter 구문과 값이 오는 puppet Hierdata가 포함된 경우 매개 변수로 대체되었을 수 있습니다. 예를 들면 다음과 같습니다.

   parameter_defaults:
     ExtraConfig:
       neutron::config::dhcp_agent_config:
         'DEFAULT/dnsmasq_local_resolv':
           value: 'true'

4. director의 Puppet 모듈을 확인하여 매개변수가 Puppet 클래스 내에 있는지 확인합니다. 예를 들면 다음과 같습니다.

   $ grep dnsmasq_local_resolv

   이 경우 새 인터페이스로 변경합니다.

5. 다음은 구문의 변경 사항을 보여주는 예입니다.

   • 예 1:

     parameter_defaults:
       ExtraConfig:
         neutron::config::dhcp_agent_config:
           'DEFAULT/dnsmasq_local_resolv':
             value: 'true'

     변경 사항:

     parameter_defaults:
       ExtraConfig:
         neutron::agents::dhcp::dnsmasq_local_resolv: true

   • 예 2:

     parameter_defaults:
       ExtraConfig:
         ceilometer::config::ceilometer_config:
           'oslo_messaging_rabbit/rabbit_qos_prefetch_count':
             value: '32'

     변경 사항:

     parameter_defaults:
       ExtraConfig:
         oslo::messaging::rabbit::rabbit_qos_prefetch_count: '32'

절차

1. 다음 명령을 실행하여 노드 IP 주소 목록을 OVERCLOUD_HOSTS 환경 변수에 저장합니다.

   $ source ~/stackrc
   $ export OVERCLOUD_HOSTS=$(openstack server list -f value -c Networks | cut -d "=" -f 2 | tr '\n' ' ')

2. 다음 스크립트를 실행합니다.

   $ /usr/share/openstack-tripleo-heat-templates/deployed-server/scripts/enable-ssh-admin.sh

3. 업그레이드를 진행합니다.

   • 사전 프로비저닝된 노드와 함께 openstack overcloud upgrade run 명령을 사용하는 경우 --ssh-user tripleo-admin 매개변수를 포함합니다.

   • Compute 또는 Object Storage 노드를 업그레이드하는 경우 다음을 사용하십시오.

     1. upgrade-non-controller.sh 스크립트와 함께 -U 옵션을 사용하고 stack 사용자를 지정합니다. 이는 사전 프로비저닝된 노드의 기본 사용자가 heat-admin 이 아니라 stack 이기 때문입니다.

     2. 노드의 IP 주소를 --upgrade 옵션과 함께 사용합니다. 이는 노드가 director의 Compute(nova) 및 Bare Metal(ironic) 서비스로 관리되지 않고 노드 이름이 없기 때문입니다.

        예를 들면 다음과 같습니다.

        $ upgrade-non-controller.sh -U stack --upgrade 192.168.24.100

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 배포에 적합한 모든 관련 옵션 및 환경 파일을 사용하여 fast forward upgrade prepare 명령을 실행합니다.

   $ openstack overcloud ffwd-upgrade prepare \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   환경과 관련된 다음 옵션을 포함합니다.

   • 사용자 지정 구성 환경 파일(-e). 예를 들면 다음과 같습니다.

     • 컨테이너 이미지 위치가 있는 환경 파일(overcloud_images.yaml). 업그레이드 명령은 --container-registry-file 사용에 대한 경고를 표시할 수 있습니다. 이 옵션은 컨테이너 이미지 환경 파일에 -e 를 사용하기 위해 더 이상 사용되지 않으므로 이 경고를 무시할 수 있습니다.
     • 해당하는 경우 deprecated_cli_options.yaml 을 사용하여 더 이상 사용되지 않는 CLI 옵션을 Heat 매개변수에 매핑하는 환경 파일입니다.
     • 해당하는 경우 custom _repositories_script.yaml을 사용하여 사용자 지정 리포지토리 스크립트가 있는 환경 파일입니다.
     • Ceph Storage 노드를 사용하는 경우 관련 환경 파일입니다.
     • 사용자 환경과 관련된 추가 환경 파일입니다.
   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   • 해당하는 경우 --roles-file 을 사용하는 사용자 지정역할( roles_data) 파일을 사용합니다.
   중요

   ffwd-upgrade 명령을 수행할지 묻는 프롬프트가 표시됩니다. yes 를 입력합니다.

   참고

   openstack ffwd-upgrade prepare 명령을 여러 번 실행할 수 있습니다. 명령이 실패하면 템플릿의 문제를 수정한 다음 명령을 다시 실행할 수 있습니다.

3. 오버클라우드 플랜이 OpenStack Platform 13 버전으로 업데이트됩니다. fast forward 업그레이드 준비가 완료될 때까지 기다립니다.
4. 업그레이드를 수행하기 전에 Overcloud의 스냅샷 또는 백업을 생성합니다.

5. fast forward upgrade 명령을 실행합니다.

   $ openstack overcloud ffwd-upgrade run

   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   중요

   ffwd-upgrade 명령을 수행할지 묻는 프롬프트가 표시됩니다. yes 를 입력합니다.

   참고

   openstack ffwd-upgrade run 명령을 여러 번 실행할 수 있습니다. 명령이 실패하면 템플릿의 문제를 수정한 다음 명령을 다시 실행할 수 있습니다.

6. fast forward 업그레이드가 완료될 때까지 기다립니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 모놀리식 컨트롤러 노드를 사용하는 경우 컨트롤러 역할에 대해 upgrade 명령을 실행합니다.

   $ openstack overcloud upgrade run --nodes Controller --skip-tags validation

   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.

3. 컨트롤러 서비스를 여러 역할로 분할하는 경우 다음을 수행합니다.

   1. Pacemaker 서비스를 사용하여 역할에 대한 업그레이드 명령을 실행합니다.

      $ openstack overcloud upgrade run --nodes ControllerOpenStack --skip-tags validation
      $ openstack overcloud upgrade run --nodes Database --skip-tags validation
      $ openstack overcloud upgrade run --nodes Messaging --skip-tags validation
      $ openstack overcloud upgrade run --nodes Telemetry --skip-tags validation

      • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.

   2. Networker 역할에 대해 upgrade 명령을 실행합니다.

      $ openstack overcloud upgrade run --nodes Networker --skip-tags validation

      • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.

   3. Compute 또는 CephStorage 역할을 제외하고 나머지 사용자 지정 역할에 대해 업그레이드 명령을 실행합니다.

      $ openstack overcloud upgrade run --nodes ObjectStorage --skip-tags validation

      • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --nodes compute-0 --skip-tags validation

   참고

   OpenStack Platform 서비스는 오버클라우드에서 비활성화되어 있고 검증할 수 없기 때문에 --skip-tags 검증을 사용합니다.

   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
3. 테스트 노드 업그레이드가 완료될 때까지 기다립니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --nodes Compute --skip-tags validation

   참고

   OpenStack Platform 서비스는 오버클라우드에서 비활성화되어 있고 검증할 수 없기 때문에 --skip-tags 검증을 사용합니다.

   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   • 사용자 지정 Compute 역할을 사용하는 경우 --nodes 옵션을 사용하여 역할 이름을 포함해야 합니다.
3. 컴퓨팅 노드 업그레이드가 완료될 때까지 기다립니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --nodes CephStorage --skip-tags validation

   참고

   OpenStack Platform 서비스는 오버클라우드에서 비활성화되어 있고 검증할 수 없기 때문에 --skip-tags 검증을 사용합니다.

   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
3. 노드 업그레이드가 완료될 때까지 기다립니다.

4. Ceph Storage 업그레이드 명령을 실행합니다. 예를 들면 다음과 같습니다.

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e <ENVIRONMENT FILE> \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /home/stack/templates/custom_repositories_script.yaml
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       --ceph-ansible-playbook '/usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml,/usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml'

   환경과 관련된 다음 옵션을 포함합니다.

   • 사용자 지정 구성 환경 파일(-e). 예를 들면 다음과 같습니다.

     • 컨테이너 이미지 위치가 있는 환경 파일(overcloud_images.yaml). 업그레이드 명령은 --container-registry-file 사용에 대한 경고를 표시할 수 있습니다. 이 옵션은 컨테이너 이미지 환경 파일에 -e 를 사용하기 위해 더 이상 사용되지 않으므로 이 경고를 무시할 수 있습니다.
     • 해당하는 경우 deprecated_cli_options.yaml 을 사용하여 더 이상 사용되지 않는 CLI 옵션을 Heat 매개변수에 매핑하는 환경 파일입니다.
     • 해당하는 경우 custom _repositories_script.yaml을 사용하여 사용자 지정 리포지토리 스크립트가 있는 환경 파일입니다.
     • Ceph Storage 노드의 관련 환경 파일입니다.
     • 사용자 환경과 관련된 추가 환경 파일입니다.
   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   • 해당하는 경우 --roles-file 을 사용하는 사용자 지정역할( roles_data) 파일을 사용합니다.
   • 다음 ansible 플레이북:
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
5. Ceph Storage 노드 업그레이드가 완료될 때까지 기다립니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --roles ComputeHCI

   사용자 지정 스택 이름을 사용하는 경우 --stack 옵션을 사용하여 이름을 upgrade 명령에 전달합니다.

3. Ceph Storage 업그레이드 명령을 실행합니다. 예를 들면 다음과 같습니다.

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   환경과 관련된 다음 옵션을 포함합니다.

   • 사용자 지정 구성 환경 파일(-e). 예를 들면 다음과 같습니다.

     • 컨테이너 이미지 위치가 있는 환경 파일(overcloud_images.yaml). 업그레이드 명령은 --container-registry-file 사용에 대한 경고를 표시할 수 있습니다. 이 옵션은 컨테이너 이미지 환경 파일에 -e 를 사용하기 위해 더 이상 사용되지 않으므로 이 경고를 무시할 수 있습니다.
     • 해당하는 경우 deprecated_cli_options.yaml 을 사용하여 더 이상 사용되지 않는 CLI 옵션을 Heat 매개변수에 매핑하는 환경 파일입니다.
     • 해당하는 경우 custom _repositories_script.yaml을 사용하여 사용자 지정 리포지토리 스크립트가 있는 환경 파일입니다.
     • Ceph Storage 노드의 관련 환경 파일입니다.
   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   • 해당하는 경우 --roles-file 을 사용하는 사용자 지정역할( roles_data) 파일을 사용합니다.
   • 다음 ansible 플레이북:
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
4. Ceph Storage 노드 업그레이드가 완료될 때까지 기다립니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 컴퓨팅 노드에 대한 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --roles Compute
   If using a custom stack name, pass the name with the --stack option.

3. 노드 업그레이드가 완료될 때까지 기다립니다.

4. ComputeHCI 노드에 대한 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --roles ComputeHCI
   If using a custom stack name, pass the name with the --stack option.

5. 노드 업그레이드가 완료될 때까지 기다립니다.

6. Ceph Storage 노드에 대한 업그레이드 명령을 실행합니다.

   $ openstack overcloud upgrade run --roles CephStorage

7. Ceph Storage 노드 업그레이드가 완료될 때까지 기다립니다.

8. Ceph Storage 업그레이드 명령을 실행합니다. 예를 들면 다음과 같습니다.

   $ openstack overcloud ceph-upgrade run \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <ENVIRONMENT FILE>

   환경과 관련된 다음 옵션을 포함합니다.

   • 사용자 지정 구성 환경 파일(-e). 예를 들면 다음과 같습니다.

     • 컨테이너 이미지 위치가 있는 환경 파일(overcloud_images.yaml). 업그레이드 명령은 --container-registry-file 사용에 대한 경고를 표시할 수 있습니다. 이 옵션은 컨테이너 이미지 환경 파일에 -e 를 사용하기 위해 더 이상 사용되지 않으므로 이 경고를 무시할 수 있습니다.
     • 해당하는 경우 deprecated_cli_options.yaml 을 사용하여 더 이상 사용되지 않는 CLI 옵션을 Heat 매개변수에 매핑하는 환경 파일입니다.
     • 해당하는 경우 custom _repositories_script.yaml을 사용하여 사용자 지정 리포지토리 스크립트가 있는 환경 파일입니다.
     • Ceph Storage 노드의 관련 환경 파일입니다.
     • 사용자 환경과 관련된 추가 환경 파일입니다.
   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   • 해당하는 경우 --roles-file 을 사용하는 사용자 지정역할( roles_data) 파일을 사용합니다.
   • 다음 ansible 플레이북:
   • /usr/share/ceph-ansible/infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml
   • /usr/share/ceph-ansible/infrastructure-playbooks/rolling_update.yml
9. Ceph Storage 노드 업그레이드가 완료될 때까지 기다립니다.

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. fast forward upgrade finalization 명령을 실행합니다.

   $ openstack overcloud ffwd-upgrade converge \
       --templates \
       -e /home/stack/templates/overcloud_images.yaml \
       -e /home/stack/templates/deprecated_cli_options.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
       -e /home/stack/templates/ceph-customization.yaml \
       -e <OTHER ENVIRONMENT FILES>

   환경과 관련된 다음 옵션을 포함합니다.

   • 사용자 지정 구성 환경 파일(-e). 예를 들면 다음과 같습니다.

     • 컨테이너 이미지 위치가 있는 환경 파일(overcloud_images.yaml). 업그레이드 명령은 --container-registry-file 사용에 대한 경고를 표시할 수 있습니다. 이 옵션은 컨테이너 이미지 환경 파일에 -e 를 사용하기 위해 더 이상 사용되지 않으므로 이 경고를 무시할 수 있습니다.
     • 해당하는 경우 deprecated_cli_options.yaml 을 사용하여 더 이상 사용되지 않는 CLI 옵션을 Heat 매개변수에 매핑하는 환경 파일입니다.
     • Ceph Storage 노드를 사용하는 경우 관련 환경 파일입니다.
     • 사용자 환경과 관련된 추가 환경 파일입니다.
   • 사용자 지정 스택 이름을 사용하는 경우 --stack 옵션으로 이름을 전달합니다.
   • 해당하는 경우 --roles-file 을 사용하는 사용자 지정역할( roles_data) 파일을 사용합니다.
   중요

   ffwd-upgrade 명령을 수행할지 묻는 프롬프트가 표시됩니다. yes 를 입력합니다.

3. fast forward 업그레이드 완료가 완료될 때까지 기다립니다.

절차

1. 재부팅하려는 노드에 로그인합니다.

2. 선택 사항: 노드에서 Pacemaker 리소스를 사용하는 경우 클러스터를 중지합니다.

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

3. 노드를 재부팅합니다.

   [heat-admin@overcloud-controller-0 ~]$ sudo reboot

4. 노드가 부팅될 때까지 기다립니다.

5. 서비스를 확인합니다. 예를 들면 다음과 같습니다.

   1. 노드에서 Pacemaker 서비스를 사용하는 경우 노드가 클러스터에 다시 가입했는지 확인합니다.

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

   2. 노드에서 Systemd 서비스를 사용하는 경우 모든 서비스가 활성화되었는지 확인합니다.

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status

   3. 모든 컨트롤러 및 구성 가능한 노드에 대해 이 단계를 반복합니다.

절차

1. Ceph MON 또는 컨트롤러 노드에 로그인하고 Ceph Storage 클러스터 재조정을 일시적으로 비활성화합니다.

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. 재부팅할 첫 번째 Ceph Storage 노드를 선택하고 로그인합니다.

3. 노드를 재부팅합니다.

   $ sudo reboot

4. 노드가 부팅될 때까지 기다립니다.

5. Ceph MON 또는 컨트롤러 노드에 로그인하고 클러스터 상태를 확인합니다.

   $ sudo ceph -s

   pgmap이 모든 pgs를 정상(active+clean)으로 보고하는지 확인합니다.

6. Ceph MON 또는 컨트롤러 노드에서 로그아웃하고 다음 Ceph Storage 노드를 재부팅한 후 상태를 확인합니다. 모든 Ceph Storage 노드를 재부팅할 때까지 이 프로세스를 반복합니다.

7. 완료되면 Ceph MON 또는 컨트롤러 노드에 로그인하고 클러스터 재조정을 다시 활성화합니다.

   $ sudo ceph osd unset noout
   $ sudo ceph osd unset norebalance

8. 최종 상태 검사를 수행하여 클러스터가 HEALTH_OK를 보고하는지 확인합니다.

   $ sudo ceph status

절차

1. stack 사용자로 언더클라우드에 로그인합니다.

2. 재부팅하려는 컴퓨팅 노드를 확인하려면 모든 컴퓨팅 노드를 나열합니다.

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

3. 오버클라우드에서 컴퓨팅 노드를 선택하여 비활성화합니다.

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service list
   (overcloud) $ openstack compute service set <hostname> nova-compute --disable

4. 컴퓨팅 노드에 모든 인스턴스를 나열합니다.

   (overcloud) $ openstack server list --host <hostname> --all-projects

5. 인스턴스를 마이그레이션합니다. 마이그레이션 전략에 대한 자세한 내용은 컴퓨팅 노드 간 가상 머신 마이그레이션을 참조하십시오.

6. Compute 노드에 로그인하여 재부팅합니다.

   [heat-admin@overcloud-compute-0 ~]$ sudo reboot

7. 노드가 부팅될 때까지 기다립니다.

8. 컴퓨팅 노드를 활성화합니다.

   $ source ~/overcloudrc
   (overcloud) $ openstack compute service set <hostname> nova-compute --enable

9. 컴퓨팅 노드가 활성화되어 있는지 확인합니다.

   (overcloud) $ openstack compute service list

절차

1. Ceph MON 또는 컨트롤러 노드에 로그인하고 Ceph Storage 클러스터 재조정을 일시적으로 비활성화합니다.

   $ sudo ceph osd set noout
   $ sudo ceph osd set norebalance

2. stack 사용자로 언더클라우드에 로그인합니다.

3. 모든 컴퓨팅 노드 및 해당 UUID를 나열합니다.

   $ source ~/stackrc
   (undercloud) $ openstack server list --name compute

   재부팅하려는 컴퓨팅 노드의 UUID를 확인합니다.

4. 언더클라우드에서 컴퓨팅 노드를 선택하여 비활성화합니다.

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

5. 컴퓨팅 노드에 모든 인스턴스를 나열합니다.

   (overcloud) $ openstack server list --host [hostname] --all-projects

6. 다음 명령 중 하나를 사용하여 인스턴스를 마이그레이션합니다.

   1. 인스턴스를 선택한 특정 호스트로 마이그레이션합니다.

      (overcloud) $ openstack server migrate [instance-id] --live [target-host]--wait

   2. nova-scheduler에서 대상 호스트를 자동으로 선택하도록 합니다.

      (overcloud) $ nova live-migration [instance-id]

   3. 한 번에 모든 인스턴스를 실시간 마이그레이션합니다.

      $ nova host-evacuate-live [hostname]

      참고

      nova 명령으로 인해 몇 가지 사용 중단 경고가 표시될 수 있으며, 이러한 경고는 무시해도 됩니다.

7. 마이그레이션이 완료될 때까지 기다립니다.

8. 마이그레이션을 성공적으로 완료했음을 확인합니다.

   (overcloud) $ openstack server list --host [hostname] --all-projects

9. 선택한 컴퓨팅 노드에 남은 항목이 없을 때까지 인스턴스를 계속 마이그레이션합니다.

10. Ceph MON 또는 컨트롤러 노드에 로그인하고 클러스터 상태를 확인합니다.

    $ sudo ceph -s

    pgmap이 모든 pgs를 정상(active+clean)으로 보고하는지 확인합니다.

11. 컴퓨팅 HCI 노드를 재부팅합니다.

    $ sudo reboot

12. 노드가 부팅될 때까지 기다립니다.

13. 컴퓨팅 노드를 다시 활성화합니다.

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

14. 컴퓨팅 노드가 활성화되어 있는지 확인합니다.

    (overcloud) $ openstack compute service list

15. 노드에서 로그아웃하고, 다음 노드를 재부팅한 후 상태를 확인합니다. 모든 Ceph Storage 노드가 재부팅될 때까지 이 프로세스를 반복합니다.

16. 완료되면 Ceph MON 또는 컨트롤러 노드에 로그인하고 클러스터 재조정을 다시 활성화합니다.

    $ sudo ceph osd unset noout
    $ sudo ceph osd unset norebalance

17. 최종 상태 검사를 수행하여 클러스터가 HEALTH_OK를 보고하는지 확인합니다.

    $ sudo ceph status

절차

1. 언더클라우드 액세스 세부 정보를 가져옵니다.

   $ source ~/stackrc

2. 실패한 Systemd 서비스를 확인합니다.

   (undercloud) $ sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker'

3. 언더클라우드의 사용 가능한 공간을 확인합니다.

   (undercloud) $ df -h

   "Undercloud Requirements(Undercloud 요구 사항)" 를 기준으로 사용하여 사용 가능한 공간이 적절한지 확인합니다.

4. 언더클라우드에 NTP가 설치되어 있는 경우 시계가 동기화되었는지 확인합니다.

   (undercloud) $ sudo ntpstat

5. 언더클라우드 네트워크 서비스를 확인합니다.

   (undercloud) $ openstack network agent list

   모든 에이전트는 Alive 이고 해당 상태는 UP 이어야 합니다.

6. 언더클라우드 계산 서비스를 확인합니다.

   (undercloud) $ openstack compute service list

   모든 에이전트의 상태가 활성화되고 상태가 up이어야 합니다

절차

1. 언더클라우드 액세스 세부 정보를 가져옵니다.

   $ source ~/stackrc

2. 베어 메탈 노드의 상태를 확인합니다.

   (undercloud) $ openstack baremetal node list

   모든 노드에 유효한 전원 상태(on)가있어야 하며 유지 관리 모드는 false 여야 합니다.

3. 실패한 Systemd 서비스를 확인합니다.

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo systemctl list-units --state=failed 'openstack*' 'neutron*' 'httpd' 'docker' 'ceph*'" ; done

4. 실패한 컨테이너화된 서비스를 확인합니다.

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'exited=1' --all" ; done
   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker ps -f 'status=dead' -f 'status=restarting'" ; done

5. 모든 서비스에 대한 HAProxy 연결을 확인합니다. haproxy.stats 서비스의 컨트롤 플레인 VIP 주소 및 인증 세부 정보를 가져옵니다.

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE sudo 'grep "listen haproxy.stats" -A 6 /var/lib/config-data/puppet-generated/haproxy/etc/haproxy/haproxy.cfg'

   다음 cURL 요청에서 이러한 세부 정보를 사용합니다.

   (undercloud) $ curl -s -u admin:<PASSWORD> "http://<IP ADDRESS>:1993/;csv" | egrep -vi "(frontend|backend)" | cut -d, -f 1,2,18,37,57 | column -s, -t

   <PASSWORD> 및 <IP ADDRESS> 세부 정보를 haproxy.stats 서비스의 실제 세부 정보로 바꿉니다. 결과 목록은 각 노드의 OpenStack Platform 서비스와 해당 연결 상태를 표시합니다.

   참고

   노드가 Redis 서비스를 실행하는 경우 하나의 노드만 해당 서비스의 ON 상태를 표시합니다. 이는 Redis가 한 번에 하나의 노드에서만 실행되는 액티브-패시브 서비스이기 때문입니다.

6. 오버클라우드 데이터베이스 복제 상태를 확인합니다.

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec clustercheck clustercheck" ; done

7. RabbitMQ 클러스터 상태를 확인합니다.

   (undercloud) $ for NODE in $(openstack server list --name controller -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo docker exec $(ssh heat-admin@$NODE "sudo docker ps -f 'name=.*rabbitmq.*' -q") rabbitmqctl node_health_check" ; done

8. Pacemaker 리소스 상태를 확인합니다.

   (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo pcs status"

   다음 항목 검색:

   • 온라인 의 모든 클러스터 노드.
   • 모든 클러스터 노드에서 중지된 리소스가 없습니다.
   • 실패한 pacemaker 작업이 없습니다.

9. 각 오버클라우드 노드의 디스크 공간을 확인합니다.

   (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo df -h --output=source,fstype,avail -x overlay -x tmpfs -x devtmpfs" ; done

10. Overcloud Ceph Storage 클러스터 상태를 확인합니다. 다음 명령은 컨트롤러 노드에서 ceph 툴을 실행하여 클러스터를 확인합니다.

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph -s"

11. Ceph Storage OSD에서 사용 가능한 공간이 있는지 확인합니다. 다음 명령은 컨트롤러 노드에서 ceph 툴을 실행하여 사용 가능한 공간을 확인합니다.

    (undercloud) $ NODE=$(openstack server list --name controller-0 -f value -c Networks | cut -d= -f2); ssh heat-admin@$NODE "sudo ceph df"

12. 오버클라우드 노드에서 클록이 동기화되었는지 확인합니다.

    (undercloud) $ for NODE in $(openstack server list -f value -c Networks | cut -d= -f2); do echo "=== $NODE ===" ; ssh heat-admin@$NODE "sudo ntpstat" ; done

13. 오버클라우드 액세스 세부 정보를 소싱합니다.

    (undercloud) $ source ~/overcloudrc

14. 오버클라우드 네트워크 서비스를 확인합니다.

    (overcloud) $ openstack network agent list

    모든 에이전트는 Alive 이고 해당 상태는 UP 이어야 합니다.

15. 오버클라우드 계산 서비스를 확인합니다.

    (overcloud) $ openstack compute service list

    모든 에이전트의 상태가 활성화되고 상태가 up이어야 합니다

16. 오버클라우드 볼륨 서비스를 확인합니다.

    (overcloud) $ openstack volume service list

    모든 에이전트의 상태가 활성화되고 상태가 up 이어야 합니다.

절차

1. 언더클라우드 액세스 세부 정보를 가져옵니다.

   $ source ~/stackrc

2. stack 사용자 홈(/home/stack/images)의 images 디렉터리에서 기존 이미지를 제거합니다.

   $ rm -rf ~/images/*

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

   $ cd ~/images
   $ for i in /usr/share/rhosp-director-images/overcloud-full-latest-13.0.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-13.0.tar; do tar -xvf $i; done
   $ cd ~

4. 최신 이미지를 director로 가져옵니다.

   $ openstack overcloud image upload --update-existing --image-path /home/stack/images/

5. 새 이미지를 사용하도록 노드를 구성합니다.

   $ openstack overcloud node configure $(openstack baremetal node list -c UUID -f value)

6. 새 이미지가 있는지 확인합니다.

   $ openstack image list
   $ ls -l /httpboot

절차

1. stackrc 파일을 소싱합니다.

   $ source ~/stackrc

2. 배포 명령을 실행하고 오버클라우드와 관련된 모든 환경 파일을 포함합니다.

   $ openstack overcloud deploy \
       --templates \
       -e <ENVIRONMENT FILE>

   환경과 관련된 다음 옵션을 포함합니다.

   • -e 를 사용하여 사용자 지정 구성 환경 파일.
   • 해당하는 경우 --roles-file 을 사용하는 사용자 지정역할( roles_data) 파일을 사용합니다.
3. 배포가 완료될 때까지 기다립니다.