Red Hat OpenStack Platform 업데이트 유지

Red Hat OpenStack Platform 16.2

Red Hat OpenStack Platform의 마이너 업데이트 수행

초록

RHOSP(Red Hat OpenStack Platform) 환경의 마이너 업데이트를 수행하여 최신 패키지 및 컨테이너로 업데이트할 수 있습니다.

preface

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. 어떻게 하면 더 잘할 수 있는지 알려주십시오.

DDF( Direct Documentation Feedback) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 의견을 받으려면 피드백 DDF 추가 기능을 사용하십시오.

  1. 다중 페이지 HTML 형식으로 문서를 봅니다.
  2. 문서 오른쪽 상단에 Feedback 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 의견을 사용하여 피드백 추가 필드를 완료합니다.
  6. 선택 사항: 문서 팀이 문제에 대한 명확한 설명을 위해 귀하에게 연락할 수 있도록 이메일 주소를 추가하십시오.
  7. Submit 을 클릭합니다.

1장. 마이너 업데이트 준비

RHOSP(Red Hat OpenStack Platform) 16.2 환경을 최신 패키지 및 컨테이너로 업데이트합니다.

다음 버전을 업데이트할 수 있습니다.

이전 RHOSP 버전새로운 RHOSP 버전

Red Hat OpenStack Platform 16.1.z

Red Hat OpenStack Platform 16.2 최신

Red Hat OpenStack Platform 16.2.z

Red Hat OpenStack Platform 16.2 최신

RHOSP 마이너 업데이트 프로세스 워크플로

RHOSP 환경을 업데이트하려면 다음 단계를 완료해야 합니다.

  1. RHOSP 마이너 업데이트를 위해 환경을 준비합니다.
  2. 언더클라우드를 최신 OpenStack 16.2.z 버전으로 업데이트합니다.
  3. 오버클라우드를 최신 OpenStack 16.2.z 버전으로 업데이트합니다.
  4. 모든 Red Hat Ceph Storage 서비스를 업그레이드합니다.
  5. 통합 명령을 실행하여 오버클라우드 스택을 새로 고칩니다.

다중 스택 인프라가 있는 경우 각 오버클라우드 스택을 한 번에 하나씩 완전히 업데이트합니다. DCN(Distributed Compute node) 인프라가 있는 경우 중앙 위치에서 오버클라우드를 완전히 업데이트한 다음 각 에지 사이트에서 오버클라우드를 한 번에 하나씩 업데이트합니다.

RHOSP 환경을 업데이트하기 전에 고려해야 할 사항

업데이트 프로세스 중에 안내하려면 다음 정보를 고려하십시오.

  • Red Hat은 언더클라우드 및 오버클라우드 컨트롤 플레인을 백업하는 것이 좋습니다. 노드 백업에 대한 자세한 내용은 언더클라우드 및 컨트롤 플레인 노드 백업 및 복원을 참조하십시오.
  • 업데이트를 차단할 수 있는 알려진 문제를 숙지하십시오.
  • 업데이트를 시작하기 전에 가능한 업데이트 및 업그레이드 경로를 숙지하십시오. 자세한 내용은 1.1절. “롱라이프 릴리스의 업그레이드 경로”의 내용을 참조하십시오.
  • 현재 유지 관리 릴리스를 확인하려면 $ cat /etc/rhosp-release 를 실행합니다. 환경을 업데이트한 후 업데이트를 검증하기 위해 이 명령을 실행할 수도 있습니다.

업데이트를 차단할 수 있는 알려진 문제

성공적인 마이너 버전 업데이트에 영향을 줄 수 있는 다음과 같은 알려진 문제를 검토합니다.

BZ#1975240 - 16.1에서 16.2로 업데이트, tsx 플래그를 활성화하면 업데이트 중에 계산 노드가 다시 시작되고 ping 손실이 발생합니다.

RHEL(Red Hat Enterprise Linux) 버전 8.3부터 Intel TSX(Transactional Synchronization Extensions) 기능 지원은 기본적으로 비활성화되어 있습니다. 이로 인해 다음 마이그레이션 시나리오에서 호스트 간 인스턴스 실시간 마이그레이션 문제가 발생합니다.

  • TSX 커널 인수가 비활성화된 호스트로 마이그레이션

TSX 기능을 지원하는 Intel 호스트에서 실시간 마이그레이션이 실패할 수 있습니다. 이 문제의 영향을 받는 CPU에 대한 자세한 내용은 영향을 받는 구성을 참조하십시오.

자세한 내용은 다음 Red Hat Knowledgebase 솔루션 OpenStack 게스트에 미치는 Intel TSX 영향에 대한 지침을 참조하십시오.

BZ#1872404 - 쿼럼을 유지 관리하는 동안 노드를 병렬로 재시작하면 예기치 않은 노드 종료가 발생합니다.
이 문제가 해결될 때까지는 구성 가능 역할에 따라 노드의 경우 컨트롤러,메시징,계산,Ceph 및 기타 역할을 업데이트하기 전에 Database 역할을 먼저 업데이트해야 합니다.
BZ#2027787 - undercloud upgrade to 16.2 because of missing dependencies of swtpm
성공적으로 업그레이드할 수 없는 advanced-virt-for-rhel-8-x86_64-eus-rpmsadvanced-virt-for-rhel-8-x86_64-rpms 리포지토리에 알려진 문제가 있습니다. 업그레이드 전에 이러한 리포지토리를 비활성화하려면 OSP 16.2에 Red Hat Knowledgebase 솔루션 advanced-virt-for-rhel-8-x86_64-rpms 를 참조하십시오.
BZ#2009106 - tripleo_nova_libvirt가 두 번 다시 시작한 후 podman panic
Podman 및 libvirt 서비스의 변경과 관련하여 RHOSP 16.2.1에서 16.2.2로 업그레이드하는 것과 관련하여 RHOSP 16.1에서 16.2.2로 업그레이드하는 경우 알려진 문제가 있습니다. 업그레이드하기 전에 워크로드를 마이그레이션하지 않으면 업그레이드에 실패할 수 있습니다.
BZ#2094265 - 16.2.1, 16.2.0 또는 ML2/OVN 배포의 16.2.2 이상으로 16.1 릴리스 중 데이터 플레인 중단, BZ#2111871 - 오버클라우드 external-update run --stack overcloud --tags ovn으로 인해 네트워크 중단이 발생했습니다.

심각한 연결 손실은 16.2.0, 16.2.1 또는 모든 16.1 릴리스에서 RHOSP를 16.2.2 또는 16.2.3으로 업데이트할 때 워크로드에 영향을 미칠 수 있습니다.

이 버그는 RHOSP 16.2.2. 및 16.2.3에 도입된 OVN(Open Virtual Network) 21.12의 데이터베이스 스키마 변경에 의해 트리거됩니다. OVN 21.12에는 이전 버전에 없는 새 열이 포함되어 있습니다. OVN 데이터베이스 스키마를 변경하면 OpenStack에 문제가 발생하지 않아야 하지만 이 특정 변경 사항은 버그의 영향을 받습니다.

특히 다음 명령을 실행할 때 변수 시간(20초에서 3분)에 대한 인스턴스 연결이 손실됩니다.

$ openstack overcloud external-update run --stack overcloud --tags ovn

이러한 다운타임은 예기치 않은 것이며 Red Hat Engineering 팀에서 조사 중입니다. 사용 중인 환경에서 다운타임을 허용할 수 없는 경우 해결 방법이 있을 때까지 대기 중인 환경 업데이트를 기다리는 것이 좋습니다.

BZ2129445 - 16.2.0에서 알려진 문제 nova_libvirt 태그: 16.2.0-55.1638436404 libvirt 버전이 RHOSP 16.2.0에서 RHOSP 16.2.x로 마이너 업데이트 후 관리할 수 없는 상태가 됩니다.

libvirt 버전과 호환되지 않는 심각한 영향을 평가할 때까지 RHOSP 16.2.0에서 16.2.2 또는 16.2.3으로 업데이트하지 마십시오. 이 평가를 완료하려면 모든 컴퓨팅 노드의 nova_libvirt 컨테이너의 libvirt 패키지를 확인합니다.

$ sudo podman exec nova_libvirt rpm -q libvirt

libvirt 버전이 7.0인 경우 배포가 버그의 영향을 받지 않습니다. 업데이트를 수행할 수 있습니다.

libvirt 버전이 7.6인 경우 배포가 버그의 영향을 받습니다. 업데이트가 위험합니다. 다음 옵션 중 하나를 선택합니다.

  • 대기: 릴리스될 때 RHOSP 16.2.4로 직접 업데이트합니다. 이 릴리스에는 호환되지 않는 문제에 대한 수정 사항이 포함되어 있습니다. 이 옵션은 업데이트를 연기할 수 있는 경우 기본 옵션입니다.
  • 핫 수정: Red Hat 지원 담당자에게 문의하여 문제를 해결하는 핫 수정 패치가 고객의 환경이 호환되는지 확인하십시오. 즉각적인 업데이트가 필요한 경우 이 옵션을 사용합니다.

버전 호환성이 없는 업데이트를 이미 수행한 경우 문제를 해결하는 방법에 대한 지침은 RHOSP16.2.0에서 RHOSP16.2.z로 배포를 업그레이드한 후 인스턴스를 관리할 수 없습니다.

절차

마이너 업데이트를 위해 RHOSP 환경을 준비하려면 다음 절차를 완료합니다.

1.1. 롱라이프 릴리스의 업그레이드 경로

업데이트 또는 업그레이드를 시작하기 전에 가능한 업데이트 및 업그레이드 경로를 숙지하십시오.

참고

/etc/rhosp-release/etc/redhat-release 파일에서 현재 RHOSP 및 RHEL 버전을 볼 수 있습니다.

표 1.1. 버전 경로 업데이트

현재 버전대상 버전

RHOSP 10.0.x on RHEL 7.x

RHEL 7.7 최신의 RHOSP 10.0 latest

RHOSP 13.0.x on RHEL 7.x

RHEL 7.9 최신의 RHOSP 13.0 latest

RHEL 8.2의 RHOSP 16.1.x

RHEL 8.2 최신의 RHOSP 16.1 최신

RHEL 8.2의 RHOSP 16.1.x

RHEL 8.4 latest의 RHOSP 16.2 latest

RHEL 8.4의 RHOSP 16.2.x

RHEL 8.4 latest의 RHOSP 16.2 latest

표 1.2. 버전 경로 업그레이드

현재 버전대상 버전

RHEL 7.7의 RHOSP 10

RHEL 7.9 최신의 RHOSP 13

RHEL 7.9의 RHOSP 13

RHEL 8.2 최신의 RHOSP 16.1 최신

RHEL 7.9의 RHOSP 13

RHEL 8.4 latest의 RHOSP 16.2 latest

자세한 내용은 업그레이드 프레임 워크 (13 to 16.2) 를 참조하십시오.

Red Hat은 환경을 다음 라이프 사이클 릴리스로 업그레이드하는 두 가지 옵션을 제공합니다.

인플레이스 업그레이드
기존 환경에서 서비스 업그레이드를 수행합니다. 이 가이드는 주로 이 옵션에 중점을 둡니다.
병렬 마이그레이션
새 Red Hat OpenStack Platform 16.2 환경을 생성하고 워크로드를 현재 환경에서 새 환경으로 마이그레이션합니다. Red Hat OpenStack Platform 병렬 마이그레이션에 대한 자세한 내용은 Red Hat Global Professional Services에 문의하십시오.
중요

이 표의 기간은 내부 테스트를 기반으로 최소 추정치이며 모든 프로덕션 환경에 적용되지 않을 수 있습니다. 예를 들어 하드웨어 사양이 낮거나 연장된 부팅 기간이 있는 경우 이러한 기간 동안 더 많은 시간을 허용합니다. 각 작업의 업그레이드 기간을 정확하게 측정하려면 프로덕션 환경과 유사한 하드웨어를 사용하여 테스트 환경에서 이러한 절차를 수행하십시오.

표 1.3. 업그레이드 경로의 영향 및 기간

 인플레이스 업그레이드병렬 마이그레이션

언더클라우드의 업그레이드 기간

각 주요 작업에 대한 예상 기간은 다음과 같습니다.

  • Leapp 업그레이드 명령의 경우 30분
  • Leapp 재부팅 시 30분
  • director 업그레이드의 경우 40분

없음. 기존 언더클라우드 외에 새 언더클라우드를 생성하고 있습니다.

오버클라우드 컨트롤 플레인의 업그레이드 기간

각 컨트롤러 노드에 대한 추정치입니다.

  • Leapp 업그레이드 및 재부팅 시 60분
  • 서비스 업그레이드를 위한 60분

없음. 기존 컨트롤 플레인 외에도 새 컨트롤 플레인을 생성하고 있습니다.

컨트롤 플레인의 중단 기간

부트스트랩 컨트롤러 노드의 서비스 업그레이드 기간(약 60분)입니다.

없음. 두 오버클라우드 모두 워크로드 마이그레이션 중에 작동합니다.

컨트롤 플레인 중단의 결과

중단 중에 OpenStack 작업을 수행할 수 없습니다.

중단이 없습니다.

오버클라우드 데이터 플레인의 업그레이드 기간

각 컴퓨팅 노드 및 Ceph Storage 노드에 대한 추정치입니다.

  • Leapp 업그레이드 및 재부팅 시 60분
  • 서비스 업그레이드의 경우 30분

없음. 기존 데이터 플레인 외에도 새 데이터 플레인을 생성하고 있습니다.

데이터 플레인의 중단 기간

노드에서 노드로의 워크로드 마이그레이션으로 인해 중단이 최소화됩니다.

오버클라우드에서 오버클라우드로의 워크로드 마이그레이션으로 인해 중단이 최소화됩니다.

추가 하드웨어 요구 사항

추가 하드웨어가 필요하지 않습니다.

새 언더클라우드 및 오버클라우드를 생성하려면 추가 하드웨어가 필요합니다.

1.2. Red Hat Enterprise Linux 릴리스에 대한 환경 잠금

RHOSP(Red Hat OpenStack Platform) 16.2는 RHEL(Red Hat Enterprise Linux) 8.4에서 지원됩니다. 업데이트를 수행하기 전에 운영 체제를 최신 마이너 릴리스로 업그레이드하지 않도록 언더클라우드 및 오버클라우드 리포지토리를 RHEL 8.4 릴리스로 고정합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. RhsmVars 매개변수가 포함된 파일인 오버클라우드 서브스크립션 관리 환경 파일을 편집합니다. 이 파일의 기본 이름은 usually rhsm.yml 입니다.
  4. 서브스크립션 관리 구성에 rhsm_release 매개변수가 포함되어 있는지 확인합니다. rhsm_release 매개변수가 없으면 해당 매개변수를 추가하고 8.4로 설정합니다.

    parameter_defaults:
      RhsmVars:
        …​
        rhsm_username: "myusername"
        rhsm_password: "p@55w0rd!"
        rhsm_org_id: "1234567"
        rhsm_pool_ids: "1a85f9223e3d5e43013e3d6e8ff506fd"
        rhsm_method: "portal"
        rhsm_release: "8.4"
  5. Overcloud 서브스크립션 관리 환경 파일을 저장합니다.
  6. 오버클라우드의 정적 인벤토리 파일을 생성합니다.

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

    오버클라우드의 기본 오버클라우드 이름과 다른 오버클라우드 이름을 사용하는 경우 --plan 옵션으로 오버클라우드 이름을 설정합니다.

  7. 모든 노드에서 운영 체제 버전을 RHEL 8.4로 잠그는 작업이 포함된 플레이북을 생성합니다.

    $ cat > ~/set_release.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: set release to 8.4
          command: subscription-manager release --set=8.4
          become: true
    EOF
  8. set_release.yaml 플레이북을 실행합니다.

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/set_release.yaml --limit <undercloud>,<Controller>,<Compute>
    • 모든 RHOSP 노드에 콘텐츠를 적용하려면 --limit 옵션을 사용합니다. < undercloud > , < Controller > , < Compute >를 해당 노드를 포함하는 사용자 환경의 Ansible 그룹으로 바꿉니다.
    • 이러한 노드에 다른 서브스크립션을 사용하는 경우 Ceph Storage 노드에서 이 플레이북을 실행할 수 없습니다.
참고

노드를 버전으로 수동으로 잠그려면 노드에 로그인하고 subscription-manager release 명령을 실행합니다.

$ sudo subscription-manager release --set=8.4

1.3. EUS (Extended Update Support) 리포지토리로 변경

RHOSP(Red Hat OpenStack Platform) 서브스크립션에는 RHEL (Red Hat Enterprise Linux) 8.4 Extended Update Support (EUS)용 리포지토리가 포함되어 있습니다. EUS 리포지토리에는 RHEL 8.4의 최신 보안 패치 및 버그 수정이 포함됩니다. 업데이트를 수행하기 전에 다음 리포지토리로 전환합니다.

표 1.4. RHEL 8.4용 EUS 리포지토리

표준 리포지터리EUS 리포지토리

rhel-8-for-x86_64-baseos-rpms

rhel-8-for-x86_64-baseos-eus-rpms

rhel-8-for-x86_64-appstream-rpms

rhel-8-for-x86_64-appstream-eus-rpms

rhel-8-for-x86_64-highavailability-rpms

rhel-8-for-x86_64-highavailability-eus-rpms

중요

EUS 리포지토리를 사용하여 특정 버전의 Podman과 호환성을 유지해야 합니다. Podman의 최신 버전은 Red Hat OpenStack Platform 16.2에서 테스트되지 않으며 예기치 않은 결과를 초래할 수 있습니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. RhsmVars 매개변수가 포함된 파일인 오버클라우드 서브스크립션 관리 환경 파일을 편집합니다. 이 파일의 기본 이름은 usually rhsm.yml 입니다.
  4. 서브스크립션 관리 구성의 rhsm_repos 매개변수를 확인합니다. 이 매개변수에 EUS 리포지토리가 없는 경우 관련 리포지토리를 EUS 버전으로 변경합니다.

    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          *- rhel-8-for-x86_64-baseos-eus-rpms*
          *- rhel-8-for-x86_64-appstream-eus-rpms*
          *- rhel-8-for-x86_64-highavailability-eus-rpms*
          - ansible-2.9-for-rhel-8-x86_64-rpms
          - openstack-16.2-for-rhel-8-x86_64-rpms
          - rhceph-4-tools-for-rhel-8-x86_64-rpms
          - fast-datapath-for-rhel-8-x86_64-rpms
  5. Overcloud 서브스크립션 관리 환경 파일을 저장합니다.
  6. 오버클라우드의 정적 인벤토리 파일을 생성합니다.

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

    오버클라우드의 기본 오버클라우드 이름과 다른 오버클라우드 이름을 사용하는 경우 --plan 옵션으로 오버클라우드 이름을 설정합니다.

  7. 모든 노드에서 리포지토리를 RHEL 8.4 EUS로 설정하는 작업이 포함된 플레이북을 생성합니다.

    $ cat > ~/change_eus.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change to eus repos
          command: subscription-manager repos --disable=rhel-8-for-x86_64-baseos-rpms --disable=rhel-8-for-x86_64-appstream-rpms --disable=rhel-8-for-x86_64-highavailability-rpms --enable=rhel-8-for-x86_64-baseos-eus-rpms --enable=rhel-8-for-x86_64-appstream-eus-rpms --enable=rhel-8-for-x86_64-highavailability-eus-rpms
          become: true
    EOF
  8. change_eus.yaml 플레이북을 실행합니다.

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/change_eus.yaml --limit <undercloud>,<Controller>,<Compute>
    • --limit 옵션을 사용하여 콘텐츠를 모든 Red Hat OpenStack Platform 노드에 적용합니다. < undercloud > , < Controller > , < Compute >를 해당 노드를 포함하는 사용자 환경의 Ansible 그룹으로 바꿉니다.
    • 이러한 노드에 다른 서브스크립션을 사용하는 경우 Ceph Storage 노드에서 이 플레이북을 실행할 수 없습니다.

1.4. Red Hat Openstack Platform 및 Ansible 리포지토리 업데이트

RHOSP(Red Hat OpenStack Platform) 16.2 및 Ansible 2.9 패키지를 사용하도록 리포지토리를 업데이트합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. RhsmVars 매개변수가 포함된 파일인 오버클라우드 서브스크립션 관리 환경 파일을 편집합니다. 이 파일의 기본 이름은 usually rhsm.yml 입니다.
  4. 서브스크립션 관리 구성의 rhsm_repos 매개변수를 확인합니다. rhsm_repos 매개변수에서 RHOSP 16.1 및 Ansible 2.8 리포지토리를 사용하는 경우 리포지토리를 올바른 버전으로 변경합니다.

    parameter_defaults:
      RhsmVars:
        rhsm_repos:
          - rhel-8-for-x86_64-baseos-eus-rpms
          - rhel-8-for-x86_64-appstream-eus-rpms
          - rhel-8-for-x86_64-highavailability-eus-rpms
          *- ansible-2.9-for-rhel-8-x86_64-rpms*
          *- openstack-16.2-for-rhel-8-x86_64-rpms*
          - fast-datapath-for-rhel-8-x86_64-rpms
  5. Overcloud 서브스크립션 관리 환경 파일을 저장합니다.
  6. 오버클라우드의 정적 인벤토리 파일을 생성합니다.

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

    오버클라우드의 기본 오버클라우드 이름과 다른 오버클라우드 이름을 사용하는 경우 --plan 옵션으로 오버클라우드 이름을 설정합니다.

  7. 모든 RHOSP 노드에서 리포지토리를 RHOSP 16.2로 설정하는 작업이 포함된 플레이북을 생성합니다.

    $ cat > ~/update_rhosp_repos.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change osp repos
          command: subscription-manager repos --disable=openstack-16.1-for-rhel-8-x86_64-rpms --enable=openstack-16.2-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms
          become: true
    EOF
  8. update_rhosp_repos.yaml 플레이북을 실행합니다.

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_rhosp_repos.yaml --limit <undercloud>,<Controller>,<Compute>
    • 모든 RHOSP 노드에 콘텐츠를 적용하려면 --limit 옵션을 사용합니다. < undercloud > , < Controller > , < Compute >를 해당 노드를 포함하는 사용자 환경의 Ansible 그룹으로 바꿉니다.
    • 이러한 노드에 다른 서브스크립션을 사용하는 경우 Ceph Storage 노드에서 이 플레이북을 실행할 수 없습니다.
  9. 모든 Ceph Storage 노드에서 리포지토리를 RHOSP 16.2로 설정하는 작업이 포함된 플레이북을 생성합니다.

    $ cat > ~/update_ceph_repos.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: change ceph repos
          command: subscription-manager repos --disable=openstack-16-deployment-tools-for-rhel-8-x86_64-rpms --enable=openstack-16.2-deployment-tools-for-rhel-8-x86_64-rpms --disable=ansible-2.8-for-rhel-8-x86_64-rpms --enable=ansible-2.9-for-rhel-8-x86_64-rpms
          become: true
    EOF
  10. update_ceph_repos.yaml 플레이북을 실행합니다.

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/update_ceph_repos.yaml --limit CephStorage

    --limit 옵션을 사용하여 콘텐츠를 Ceph Storage 노드에 적용합니다.

1.5. container-tools 모듈 버전 설정

container-tools 모듈을 버전 3.0 으로 설정하여 모든 노드에서 올바른 패키지 버전을 사용하도록 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

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

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

    오버클라우드의 기본 오버클라우드 이름과 다른 오버클라우드 이름을 사용하는 경우 --plan 옵션으로 오버클라우드 이름을 설정합니다.

  4. container-tools 모듈을 모든 노드에서 버전 3.0 으로 설정하는 작업이 포함된 플레이북을 생성합니다.

    $ cat > ~/container-tools.yaml <<'EOF'
    - hosts: all
      gather_facts: false
      tasks:
        - name: disable default dnf module for container-tools
          command: dnf module reset -y container-tools
          become: true
        - name: set dnf module for container-tools:3.0
          command: dnf module enable -y container-tools:3.0
          become: true
    EOF
  5. 모든 노드에 대해 container-tools.yaml 플레이북을 실행합니다.

    $ ansible-playbook -i ~/inventory.yaml -f 25 ~/container-tools.yaml

1.6. 컨테이너 이미지 준비 파일 업데이트

컨테이너 준비 파일은 ContainerImagePrepare 매개변수가 포함된 파일입니다. 이 파일을 사용하여 언더클라우드 및 오버클라우드의 컨테이너 이미지를 가져오는 규칙을 정의합니다.

환경을 업데이트하기 전에 파일을 확인하여 올바른 이미지 버전을 가져옵니다.

절차

  1. 컨테이너 준비 파일을 편집합니다. 이 파일의 기본 이름은 일반적으로 containers-prepare-parameter.yaml 입니다.
  2. 각 규칙 세트에 대해 tag 매개변수가 16.2 로 설정되어 있는지 확인합니다.

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
          ...
          *tag: '16.2'*
        tag_from_label: '{version}-{release}'
    참고

    16.2 또는 16.2.2 와 같은 특정 태그를 업데이트에 사용하지 않으려면 태그 키-값 쌍을 제거하고 tag _from_label 만 지정합니다. 이는 설치된 Red Hat OpenStack Platform 버전을 사용하여 업데이트 프로세스의 일부로 사용할 태그 값을 결정합니다.

  3. 이 파일을 저장합니다.

1.7. SSL/TLS 구성 업데이트

resource_registry 에서 NodeTLSData 리소스를 제거하여 SSL/TLS 구성을 업데이트합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. 사용자 지정 오버클라우드 SSL/TLS 공용 엔드포인트 파일을 편집합니다. 이 파일은 일반적으로 ~/templates/enable-tls.yaml 입니다.
  4. resource_registry:에서 NodeTLSData 리소스를 제거합니다.

    resource_registry:
      *OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml*
      ...

    Overcloud 배포에서는 HAProxy의 새 서비스를 사용하여 SSL/TLS가 활성화되어 있는지 확인합니다.

    참고

    enable-tls.yaml 파일의 resource_registry 섹션에 있는 유일한 리소스인 경우 전체 resource_registry 섹션을 제거합니다.

  5. SSL/TLS 공용 엔드포인트 파일을 저장합니다.
  6. Red Hat OpenStack Platform 16.1에서 업데이트하는 경우 모든 업데이트 전 점검에 대해 Red Hat IdM(Identity Manager)에서 권한을 업데이트해야 합니다. ssh 를 사용하여 IdM을 실행하는 서버에 로그인한 다음 다음 명령을 실행합니다.

    $ kinit admin
    $ ipa privilege-add-permission 'Nova Host Management' --permission 'System: Modify Realm Domains'

1.8. 오버클라우드에서 펜싱 비활성화

오버클라우드를 업데이트하기 전에 펜싱이 비활성화되었는지 확인합니다.

컨트롤러 노드 업데이트 프로세스 중에 펜싱을 환경에 배포하면 오버클라우드에서 특정 노드를 비활성화한 것으로 탐지하고 펜싱 작업을 시도하여 의도하지 않은 결과가 발생할 수 있습니다.

오버클라우드에서 펜싱을 활성화한 경우 의도하지 않은 결과를 피하려면 업데이트 기간 동안 펜싱을 일시적으로 비활성화해야 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. 컨트롤러 노드에 로그인하고 Pacemaker 명령을 실행하여 펜싱을 비활성화합니다.

    $ ssh heat-admin@<controller_ip> "sudo pcs property set stonith-enabled=false"

    & lt;controller_ip& gt;를 컨트롤러 노드의 IP 주소로 바꿉니다. openstack server list 명령을 사용하여 컨트롤러 노드의 IP 주소를 찾을 수 있습니다.

  4. fencing.yaml 환경 파일에서 업데이트 프로세스 중에 펜싱을 계속 비활성화하도록 EnableFencing 매개변수를 false 로 설정합니다.

2장. 언더클라우드 업데이트

director를 사용하여 언더클라우드 노드의 기본 패키지를 업데이트할 수 있습니다. 언더클라우드 및 오버클라우드 이미지를 최신 RHOSP(Red Hat OpenStack Platform) 16.2 버전으로 업데이트하려면 다음 절차를 완료합니다.

사전 요구 사항

  • 언더클라우드를 최신 RHOSP 16.2 버전으로 업데이트하려면 먼저 모든 업데이트 준비 절차를 완료해야 합니다. 자세한 내용은 1장. 마이너 업데이트 준비의 내용을 참조하십시오.

2.1. 컨테이너화된 언더클라우드의 마이너 업데이트 수행

director는 언더클라우드 노드의 기본 패키지를 업데이트하는 명령을 제공합니다. director를 사용하여 현재 RHOSP 환경 버전에서 마이너 업데이트를 수행합니다.

절차

  1. 언더클라우드 노드에서 stack 사용자로 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. dnf update 명령으로 director 주요 패키지를 업데이트합니다.

    $ sudo dnf update -y python3-tripleoclient* tripleo-ansible ansible
  4. openstack undercloud upgrade 명령을 사용하여 언더클라우드 환경을 업데이트합니다.

    $ openstack undercloud upgrade
  5. 언더클라우드 업데이트 프로세스가 완료될 때까지 기다립니다.
  6. 언더클라우드를 재부팅하여 운영 체제의 커널 및 기타 시스템 패키지를 업데이트합니다.

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

2.2. 오버클라우드 이미지 업데이트

director가 최신 버전의 RHOSP 소프트웨어로 노드를 세부 검사 및 프로비저닝할 수 있도록 현재 오버클라우드 이미지를 새 버전으로 교체해야 합니다.

사전 요구 사항

절차

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

    $ 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-16.2.tar /usr/share/rhosp-director-images/ironic-python-agent-latest-16.2.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 /var/lib/ironic/httpboot
중요
  • 오버클라우드 노드를 배포할 때 오버클라우드 이미지 버전이 해당 heat 템플릿 버전에 해당하는지 확인합니다. 예를 들어 RHOSP 16.2 heat 템플릿이 있는 RHOSP 16.2 이미지만 사용합니다.
  • Red Hat 고객 포털 또는 Red Hat Satellite Server를 사용하는 연결된 환경을 배포한 경우 오버클라우드 이미지 및 패키지 리포지토리 버전이 동기화되지 않을 수 있습니다. 오버클라우드 이미지 및 패키지 리포지토리 버전이 일치하는지 확인하려면 virt-customize 툴을 사용하면 됩니다. 자세한 내용은 Red Hat Knowledgebase 솔루션 virt-customize를 사용하여 Red Hat Linux OpenStack Platform Overcloud 이미지 수정 을 참조하십시오.
  • overcloud-full 이미지가 이전 overcloud-full 이미지를 대체합니다. 이전 이미지를 변경한 경우 특히 나중에 새 노드를 배포하려는 경우 새 이미지의 변경 사항을 반복해야 합니다.

3장. 오버클라우드 업데이트

언더클라우드를 업데이트한 후 오버클라우드 및 컨테이너 이미지 준비 명령을 실행하고, 노드를 업데이트하고, 오버클라우드 업데이트 통합 명령을 실행하여 오버클라우드를 업데이트할 수 있습니다. 마이너 업데이트 중에 컨트롤 플레인 API를 완전히 사용할 수 있습니다.

사전 요구 사항

  • 언더클라우드 노드를 최신 버전으로 업데이트했습니다. 자세한 내용은 2장. 언더클라우드 업데이트의 내용을 참조하십시오.
  • stack 사용자 홈 디렉터리에서 로컬 코어 템플릿 세트를 사용하는 경우, 템플릿을 업데이트하고 Advanced Overcloud Customization 가이드에서 Customized Core Heat Templates를 사용하여 권장 워크플로를 사용해야 합니다. 오버클라우드를 업그레이드하기 전에 로컬 복사본을 업데이트해야 합니다.

절차

오버클라우드를 업데이트하려면 다음 절차를 완료해야 합니다.

3.1. 오버클라우드 업데이트 준비 실행

업데이트 프로세스를 위해 오버클라우드를 준비하려면 openstack overcloud update prepare 명령을 실행하여 오버클라우드 계획을 RHOSP(Red Hat OpenStack Platform) 16.2로 업데이트하고 업데이트를 위해 노드를 준비해야 합니다.

사전 요구 사항

  • Ceph 서브스크립션을 사용하고 Ceph 스토리지 노드에 overcloud-minimal 이미지를 사용하도록 director가 구성된 경우 roles_data.yaml 역할 정의 파일에서 rhsm_ enforce 매개변수가 False 로 설정되어 있는지 확인해야 합니다.
  • 사용자 정의 NIC 템플릿을 렌더링한 경우 오버클라우드 버전과 호환되지 않도록 업데이트된 버전의 openstack-tripleo-heat-templates 컬렉션을 사용하여 템플릿을 다시 생성해야 합니다. 사용자 지정 NIC 템플릿에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 사용자 지정을 위해 기본 네트워크 인터페이스 템플릿 렌더링 을 참조하십시오.

절차

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

    $ source ~/stackrc
  2. update 준비 명령을 실행합니다.

    $ openstack overcloud update prepare \
        --templates \
        --stack <stack_name> \
        -r <roles_data_file> \
        -n <network_data_file> \
        -e <environment_file> \
        -e <environment_file> \
        ...

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

    • 오버클라우드 스택 이름이 기본 오버클라우드와 다른 경우 업데이트 준비 명령에 --stack 옵션을 포함하고 <stack_name> 을 스택 이름으로 교체합니다.
    • 고유한 사용자 지정 역할을 사용하는 경우 사용자 지정 역할(<roles_data> ) 파일(-r)을 포함합니다.
    • 사용자 지정 네트워크를 사용하는 경우 구성 가능 네트워크( <network_data> ) 파일(-n)을 포함합니다.
    • 고가용성 클러스터를 배포하는 경우 업데이트 준비 명령에 --ntp-server 옵션을 포함하거나 환경 파일에 NtpServer 매개변수 및 값을 포함합니다.
    • 모든 사용자 지정 구성 환경 파일(-e).
  3. 업데이트 준비 프로세스가 완료될 때까지 기다립니다.

3.2. 컨테이너 이미지 준비 실행

오버클라우드를 업데이트하기 전에 환경에 필요한 모든 컨테이너 이미지 구성을 준비하고 최신 RHOSP 16.2 컨테이너 이미지를 언더클라우드에 가져와야 합니다.

컨테이너 이미지 준비를 완료하려면 container_image_prepare 태그가 있는 작업에 대해 openstack overcloud external-update run 명령을 실행해야 합니다.

참고

오버클라우드 인 기본 스택 이름을 사용하지 않는 경우 스택 이름을 --stack <stack _name > 옵션으로 설정하고 < stack_name >을 스택 이름으로 교체합니다.

절차

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

    $ source ~/stackrc
  2. container_image_prepare 태그가 있는 작업에 대해 openstack overcloud external-update run 명령을 실행합니다.

    $ openstack overcloud external-update run --stack <stack_name> --tags container_image_prepare

3.3. 선택 사항: 모든 오버클라우드 서버에서 ovn-controller 컨테이너 업데이트

Modular Layer 2 Open Virtual Network 메커니즘 드라이버(ML2/OVN)를 사용하여 오버클라우드를 배포한 경우 ovn-controller 컨테이너를 최신 RHOSP 16.2 버전으로 업데이트합니다. 이 업데이트는 ovn-controller 컨테이너를 실행하는 모든 오버클라우드 서버에서 수행됩니다.

중요

다음 절차에서는 Controller 역할이 할당된 서버에서 ovn-controller 컨테이너를 업데이트하기 전에 Compute 역할이 할당된 서버에서 ovn-controller 컨테이너를 업데이트합니다.
이 절차에 따라 ovn-northd 서비스를 실수로 업데이트한 경우 가상 머신에 도달하거나 새 가상 머신 또는 가상 네트워크를 생성할 수 없습니다. 다음 절차에서는 연결을 복원합니다.

참고

분산 컴퓨팅 노드(edge) 아키텍처의 경우 모든 컨트롤러 노드 업데이트 섹션을 진행하기 전에 Compute, DistributedCompute 또는 DistributedComputeHCI 노드를 사용하여 각 스택에 대해 이 절차를 완료해야 합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    $ source ~/stackrc
  3. ovn 태그가 있는 작업에 대해 openstack overcloud external-update run 명령을 실행합니다.

    $ openstack overcloud external-update run --stack <stack_name> --tags ovn
    • 오버클라우드 스택 이름이 기본 스택 이름 overcloud 와 다른 경우 스택 이름을 --stack 옵션으로 설정하고 < stack_name >을 스택 이름으로 교체합니다.
  4. ovn-controller 컨테이너 업데이트가 완료될 때까지 기다립니다.

3.4. 모든 컨트롤러 노드 업데이트

모든 컨트롤러 노드를 최신 RHOSP 16.2 버전으로 업데이트합니다. openstack overcloud update run 명령을 실행하고 --limit Controller 옵션을 포함하여 컨트롤러 노드로만 작업을 제한합니다. 마이너 업데이트 중에 컨트롤 플레인 API를 완전히 사용할 수 있습니다.

중요

구성 가능 역할을 기반으로 하는 노드의 경우 BZ#1872404 가 해결될 때까지 컨트롤러,메시징,계산,Ceph 및 기타 역할을 업데이트하기 전에 Database 역할을 먼저 업데이트해야 합니다.

참고

오버클라우드 인 기본 스택 이름을 사용하지 않는 경우 스택 이름을 --stack <stack _name > 옵션으로 설정하고 < stack_name >을 스택 이름으로 교체합니다.

절차

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

    $ source ~/stackrc
  2. update 명령을 실행합니다.

    $ openstack overcloud update run --stack <stack_name> --limit Controller
  3. 컨트롤러 노드 업데이트가 완료될 때까지 기다립니다.

3.5. 모든 컴퓨팅 노드 업데이트

모든 컴퓨팅 노드를 최신 RHOSP 16.2 버전으로 업데이트합니다. 컴퓨팅 노드를 업데이트하려면 openstack overcloud update run 명령을 실행하고 --limit Compute 옵션을 포함하여 작업을 Compute 노드로만 제한합니다.

병렬 처리 고려 사항

많은 수의 컴퓨팅 노드를 업데이트할 때 성능을 개선하기 위해 백그라운드에서 여러 업데이트 작업을 실행하고 각 작업을 구성하여 20개의 개별 노드 그룹을 업데이트할 수 있습니다. 예를 들어 배포에 80개의 컴퓨팅 노드가 있는 경우 다음 명령을 실행하여 컴퓨팅 노드를 병렬로 업데이트할 수 있습니다.

$ openstack overcloud update run -y --limit 'Compute[0:19]' > update-compute-0-19.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[20:39]' > update-compute-20-39.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[40:59]' > update-compute-40-59.log 2>&1 &
$ openstack overcloud update run -y --limit 'Compute[60:79]' > update-compute-60-79.log 2>&1 &

노드 공간을 분할하는 이 방법은 임의의이며 업데이트되는 노드를 제어할 수 없습니다. 노드 선택이 tripleo-ansible-inventory 명령을 실행할 때 생성하는 인벤토리 파일을 기반으로 합니다.

특정 컴퓨팅 노드를 업데이트하려면 쉼표로 구분하여 배치에서 업데이트할 노드를 나열합니다.

$ openstack overcloud update run --limit <Compute0>,<Compute1>,<Compute2>,<Compute3>
참고

오버클라우드 인 기본 스택 이름을 사용하지 않는 경우 스택 이름을 --stack <stack _name > 옵션으로 설정하고 < stack_name >을 스택 이름으로 교체합니다.

절차

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

    $ source ~/stackrc
  2. update 명령을 실행합니다.

    $ openstack overcloud update run --stack <stack_name> --limit Compute
  3. 컴퓨팅 노드 업데이트가 완료될 때까지 기다립니다.

3.6. 모든 HCI 컴퓨팅 노드 업데이트

HCI( Hyperconverged Infrastructure) 컴퓨팅 노드를 최신 RHOSP 16.2 버전으로 업데이트합니다. HCI 컴퓨팅 노드를 업데이트하려면 openstack overcloud update run 명령을 실행하고 --limit ComputeHCI 옵션을 포함하여 HCI 노드로만 작업을 제한합니다. 컨테이너화된 Red Hat Ceph Storage 4 클러스터에 대한 업데이트를 수행하려면 openstack overcloud external-update run --tags ceph 명령을 실행해야 합니다.

사전 요구 사항

  • ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에서 Red Hat Ceph Storage 클러스터 상태가 정상이고 pg 상태가 active+clean 인지 확인합니다.

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph 클러스터가 정상이면 HEALTH_OK 상태를 반환합니다.

    Ceph 클러스터 상태가 비정상인 경우 HEALTH_WARN 또는 HEALTH_ERR 의 상태를 반환합니다. 문제 해결 지침은 Red Hat Ceph Storage 4 문제 해결 가이드를 참조하십시오.

절차

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

    $ source ~/stackrc
  2. update 명령을 실행합니다.

    $ openstack overcloud update run --stack <stack_name> --limit ComputeHCI
    • & lt;stack_name >을 스택 이름으로 바꿉니다. 지정하지 않는 경우 기본값은 오버클라우드 입니다.
  3. 노드 업데이트가 완료될 때까지 기다립니다.
  4. Ceph Storage 업데이트 명령을 실행합니다.

    $ openstack overcloud external-update run --stack <stack_name> --tags ceph
  5. 컴퓨팅 HCI 노드 업데이트가 완료될 때까지 기다립니다.

3.7. 모든 DistributedComputeHCI 노드 업데이트

분산 계산 노드 아키텍처와 관련된 역할을 업데이트합니다. 분산 컴퓨팅 노드를 업그레이드하는 경우 DistributedComputeHCI 노드를 먼저 업데이트한 다음 DistributedComputeHCIScaleOut 노드를 업데이트합니다.

참고

기본 스택 이름을 사용하지 않는 경우 스택 이름을 --stack_name> 옵션으로 설정하고 <_stack _name_>을 스택 이름으로 교체합니다.

사전 요구 사항

  • ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에서 Red Hat Ceph Storage 클러스터 상태가 정상이고 pg 상태가 active+clean 인지 확인합니다.

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph 클러스터가 정상이면 HEALTH_OK 상태를 반환합니다.

    Ceph 클러스터 상태가 비정상인 경우 HEALTH_WARN 또는 HEALTH_ERR 의 상태를 반환합니다. 문제 해결 지침은 Red Hat Ceph Storage 4 문제 해결 가이드를 참조하십시오.

절차

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

    $ source ~/stackrc
  2. update 명령을 실행합니다.

    $ openstack overcloud update run --stack <stack_name> --limit DistributedComputeHCI
  3. DistributedComputeHCI 노드 업데이트가 완료될 때까지 기다립니다.
  4. Ceph Storage 업데이트 명령을 실행합니다.

    $ openstack overcloud external-update run --stack <stack_name> --tags ceph
  5. DistributedComputeHCI 노드 업데이트가 완료될 때까지 기다립니다.
  6. 동일한 프로세스를 사용하여 DistributedComputeHCIScaleOut 노드를 업데이트합니다.

3.8. 모든 Ceph Storage 노드 업데이트

Red Hat Ceph Storage 노드를 최신 RHOSP 16.2 버전으로 업데이트합니다.

중요

RHOSP 16.2는 RHEL 8.4에서 지원됩니다. 그러나 Ceph Storage 역할 업데이트에 매핑된 호스트는 최신 주요 RHEL 릴리스로 업데이트합니다. 자세한 내용은 Red Hat Ceph Storage를 참조하십시오. 지원되는 구성.

사전 요구 사항

  • ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에서 Red Hat Ceph Storage 클러스터 상태가 정상이고 pg 상태가 active+clean 인지 확인합니다.

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph 클러스터가 정상이면 HEALTH_OK 상태를 반환합니다.

    Ceph 클러스터 상태가 비정상인 경우 HEALTH_WARN 또는 HEALTH_ERR 의 상태를 반환합니다. 문제 해결 지침은 Red Hat Ceph Storage 4 문제 해결 가이드를 참조하십시오.

절차

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

    $ source ~/stackrc
  2. update 명령을 실행합니다.

    $ openstack overcloud update run --stack  <stack_name> --limit CephStorage
    • & lt;stack_name >을 스택 이름으로 바꿉니다. 지정하지 않는 경우 기본값은 오버클라우드 입니다.
  3. 노드 업데이트가 완료될 때까지 기다립니다.
  4. Ceph Storage container update 명령을 실행하여 외부 프로세스로 ceph- anible을 실행하고 Red Hat Ceph Storage 4 컨테이너를 업데이트합니다.

    $ openstack overcloud external-update run --tags ceph
  5. Ceph Storage 컨테이너 업데이트가 완료될 때까지 기다립니다.

3.9. 온라인 데이터베이스 업데이트 수행

일부 오버클라우드 구성 요소에는 데이터베이스 테이블의 온라인 업데이트 또는 마이그레이션이 필요합니다. 온라인 데이터베이스 업데이트를 수행하려면 online_upgrade 태그가 있는 작업에 대해 openstack overcloud external-update run 명령을 실행합니다.

온라인 데이터베이스 업데이트는 다음 구성 요소에 적용됩니다.

  • OpenStack Block Storage(cinder)
  • OpenStack Compute(nova)

절차

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

    $ source ~/stackrc
  2. online_upgrade 태그를 사용하는 작업에 대해 openstack overcloud external-update run 명령을 실행합니다.

    $ openstack overcloud external-update run --tags online_upgrade

3.10. 업데이트 종료

최신 RHOSP 16.2 버전으로 업데이트를 완료하려면 오버클라우드 스택을 업데이트해야 합니다. 이렇게 하면 스택 리소스 구조가 OSP 16.2의 일반 배포와 일치하며 나중에 표준 openstack overcloud deploy 기능을 수행할 수 있습니다.

절차

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

    $ source ~/stackrc
  2. 오버클라우드에서 펜싱을 다시 활성화하려면 fencing.yaml 환경 파일에서 EnableFencing 매개변수를 true 로 설정합니다.
  3. 업데이트 완료 명령을 실행합니다.

    $ openstack overcloud update converge \
        --templates \
        --stack <stack_name> \
        -r <roles_data_file> \
        -n <network_data_file> \
        -e <environment_file> \
        -e <environment_file> \
        ...
        ...

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

    • EnableFencing 매개변수가 true 로 설정된 fencing.yaml 환경 파일.
    • 오버클라우드 스택 이름이 기본 오버클라우드와 다른 경우 업데이트 준비 명령에 --stack 옵션을 포함하고 <stack_name> 을 스택 이름으로 교체합니다.
    • 사용자 지정 역할을 사용하는 경우 사용자 지정 역할 ( <roles_data> ) 파일 (-r)을 포함합니다.
    • 사용자 지정 네트워크를 사용하는 경우 구성 가능 네트워크( <network_data> ) 파일(-n)을 포함합니다.
    • 모든 사용자 지정 구성 환경 파일(-e).
  4. 업데이트 완료가 완료될 때까지 기다립니다.

4장. 오버클라우드 재부팅

마이너 RHOSP(Red Hat OpenStack Platform)를 최신 16.2 버전으로 업데이트한 후 오버클라우드를 재부팅합니다. 재부팅은 연결된 커널, 시스템 수준 및 컨테이너 구성 요소 업데이트를 통해 노드를 새로 고칩니다. 이러한 업데이트는 성능 및 보안 이점을 제공합니다. 재부팅 절차를 수행하기 위해 가동 중지 시간을 계획하십시오.

다음 지침을 사용하여 다른 노드 유형을 재부팅하는 방법을 확인하십시오.

4.1. 컨트롤러 노드 및 구성 가능 노드 재부팅

구성 가능 역할을 기반으로 컨트롤러 노드 및 독립 실행형 노드를 재부팅하고 Compute 노드 및 Ceph Storage 노드를 제외합니다.

절차

  1. 재부팅하려는 노드에 로그인합니다.
  2. 선택 사항: 노드에서 Pacemaker 리소스를 사용하는 경우 클러스터를 중지합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo pcs cluster stop
  3. 노드를 재부팅합니다.

    [heat-admin@overcloud-controller-0 ~]$ sudo reboot
  4. 노드가 부팅될 때까지 기다립니다.

검증

  1. 서비스가 활성화되었는지 확인합니다.

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

      [heat-admin@overcloud-controller-0 ~]$ sudo pcs status
    2. 노드에서 Systemd 서비스를 사용하는 경우 모든 서비스가 활성화되었는지 확인합니다.

      [heat-admin@overcloud-controller-0 ~]$ sudo systemctl status
    3. 노드에서 컨테이너화된 서비스를 사용하는 경우 노드의 모든 컨테이너가 활성화되었는지 확인합니다.

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

4.2. Ceph Storage(OSD) 클러스터 재부팅

Ceph Storage(OSD) 노드 클러스터를 재부팅하려면 다음 단계를 완료합니다.

사전 요구 사항

  • ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에서 Red Hat Ceph Storage 클러스터 상태가 정상이고 pg 상태가 active+clean 인지 확인합니다.

    $ sudo podman exec -it ceph-mon-controller-0 ceph -s

    Ceph 클러스터가 정상이면 HEALTH_OK 상태를 반환합니다.

    Ceph 클러스터 상태가 비정상인 경우 HEALTH_WARN 또는 HEALTH_ERR 의 상태를 반환합니다. 문제 해결 지침은 Red Hat Ceph Storage 4 문제 해결 가이드를 참조하십시오.

절차

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

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd set norebalance
    참고

    다중 스택 또는 DCN(Distributed Compute node) 아키텍처가 있는 경우 nooutnorebalance 플래그를 설정할 때 클러스터 이름을 지정해야 합니다. 예: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster_name>

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

    $ sudo reboot
  4. 노드가 부팅될 때까지 기다립니다.
  5. 노드에 로그인하고 클러스터 상태를 확인합니다.

    $ sudo podman exec -it ceph-mon-controller-0 ceph status

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

  6. 노드에서 로그아웃하고, 다음 노드를 재부팅한 후 상태를 확인합니다. 모든 Ceph Storage 노드가 재부팅될 때까지 이 프로세스를 반복합니다.
  7. 완료되면 ceph-mon 서비스를 실행하는 Ceph Monitor 또는 컨트롤러 노드에 로그인하고 클러스터 재조정을 다시 활성화합니다.

    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset noout
    $ sudo podman exec -it ceph-mon-controller-0 ceph osd unset norebalance
    참고

    다중 스택 또는 DCN(Distributed Compute node) 아키텍처가 있는 경우 nooutnorebalance 플래그를 설정할 때 클러스터 이름을 지정해야 합니다. 예: sudo podman exec -it ceph-mon-controller-0 ceph osd set noout --cluster_name>

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

    $ sudo podman exec -it ceph-mon-controller-0 ceph status

4.3. 컴퓨팅 노드 재부팅

Red Hat OpenStack Platform 환경에서 인스턴스 다운 타임을 최소화할 수 있도록 인스턴스 마이그레이션 워크플로우 는 재부팅할 컴퓨팅 노드에서 인스턴스를 마이그레이션하기 위해 완료해야 하는 단계를 간략하게 설명합니다.

참고

소스 컴퓨팅 노드에서 다른 컴퓨팅 노드로 인스턴스를 마이그레이션하지 않으면 소스 컴퓨팅 노드에서 인스턴스가 다시 시작될 수 있으므로 업그레이드에 실패할 수 있습니다. 이는 Podman 및 libvirt 서비스의 변경과 관련된 알려진 문제와 관련이 있습니다.

인스턴스 워크플로 마이그레이션

  1. 노드를 재부팅하기 전에 인스턴스를 다른 컴퓨팅 노드로 마이그레이션할지 여부 결정
  2. 새 인스턴스를 프로비저닝하지 않도록 재부팅할 컴퓨팅 노드를 선택하고 비활성화합니다.
  3. 인스턴스를 다른 컴퓨팅 노드로 마이그레이션
  4. 빈 컴퓨팅 노드 재부팅
  5. 빈 컴퓨팅 노드 활성화

사전 요구 사항

  • 컴퓨팅 노드를 재부팅하기 전에 노드가 재부팅되는 동안 인스턴스를 다른 컴퓨팅 노드로 마이그레이션할지 여부를 결정해야합니다.

    컴퓨팅 노드 간에 가상 머신 인스턴스를 마이그레이션할 때 발생할 수 있는 마이그레이션 제약 조건 목록을 검토합니다. 자세한 내용은 Configuring the Compute Service for Instance Creation에서 마이그레이션 제한 조건을 참조하십시오.

  • 인스턴스를 마이그레이션할 수 없는 경우 다음과 같은 코어 템플릿 매개변수를 설정하여 컴퓨팅 노드를 재부팅한 후의 인스턴스 상태를 제어할 수 있습니다.

    NovaResumeGuestsStateOnHostBoot
    재부팅한 후에 컴퓨팅 노드에서 인스턴스를 동일한 상태로 되돌릴지 여부를 결정합니다. False로 설정하면 인스턴스가 다운된 상태로 유지되며 수동으로 시작해야 합니다. 기본값은 False 입니다.
    NovaResumeGuestsShutdownTimeout

    재부팅하기 전에 인스턴스가 종료될 때까지 대기하는 시간(초)입니다. 이 값을 0으로 설정하지 않는 것이 좋습니다. 기본값은 300 입니다.

    오버클라우드 매개변수 및 사용법에 관한 자세한 내용은 Overcloud Parameters를 참조하십시오.

    절차

    1. stack 사용자로 언더클라우드에 로그인합니다.
    2. 모든 컴퓨팅 노드 및 해당 UUID를 나열합니다.

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

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

    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. 선택 사항: 인스턴스를 다른 컴퓨팅 노드로 마이그레이션하려면 다음 단계를 완료합니다.

      1. 인스턴스를 다른 컴퓨팅 노드로 마이그레이션하려면 다음 명령 중 하나를 사용합니다.

        • 인스턴스를 다른 호스트로 마이그레이션하려면 다음 명령을 실행합니다.

          (overcloud) $ openstack server migrate <instance_id> --live <target_host> --wait
        • nova-scheduler에서 대상 호스트를 자동으로 선택하도록 합니다.

          (overcloud) $ nova live-migration <instance_id>
        • 한 번에 모든 인스턴스를 실시간 마이그레이션합니다.

          $ nova host-evacuate-live <hostname>
          참고

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

      2. 마이그레이션이 완료될 때까지 기다립니다.
      3. 마이그레이션을 성공적으로 완료했음을 확인합니다.

        (overcloud) $ openstack server list --host <hostname> --all-projects
      4. 컴퓨팅 노드에 남은 항목이 없을 때까지 인스턴스를 계속 마이그레이션합니다.
    6. 컴퓨팅 노드에 로그인하고 노드를 재부팅합니다.

      [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