Red Hat OpenStack Platform 업그레이드
Red Hat OpenStack Platform 업그레이드
초록
1장. 소개
이 문서에서는 Red Hat OpenStack Platform을 최신 상태로 유지하는 프로세스를 제공합니다. 이 문서에서는 Red Hat OpenStack Platform 8(Liberty) 을 대상으로 하는 업그레이드 및 업데이트에 대해 설명합니다.
Red Hat은 Red Hat Enterprise Linux 7의 Red Hat OpenStack Platform 8로의 업그레이드만 지원합니다. 또한 Red Hat은 다음과 같은지 여부에 따라 다음과 같은 다양한 시나리오를 권장합니다.
- director 기반 오버클라우드 또는 수동으로 생성된 환경을 사용하고 있습니다.
- 고가용성 툴을 사용하여 클러스터의 컨트롤러 노드 집합을 관리하고 있습니다.
1.1절. “업그레이드 시나리오 비교” 는 모든 업그레이드 시나리오에 대한 설명을 제공합니다. 이러한 시나리오를 통해 Red Hat OpenStack Platform 8 릴리스로 업그레이드하고 해당 버전 내에서 마이너 업데이트를 제공할 수 있습니다.
1.1. 업그레이드 시나리오 비교
Red Hat은 Red Hat OpenStack Platform 8에 대해 다음 업그레이드 시나리오를 권장합니다. 다음 표에서는 각각에 대한 간략한 설명을 제공합니다.
방법 | 설명 |
---|---|
director 기반 환경: 마이너 버전에 대한 업데이트 수행 | 이 시나리오는 Red Hat OpenStack Platform 8의 마이너 버전에서 최신 Red Hat OpenStack Platform 8 버전으로 업데이트하는 것입니다. 여기에는 director 패키지를 업데이트한 다음 director를 사용하여 Overcloud의 모든 노드에서 패키지 업데이트를 시작합니다. |
director 기반 환경: 주요 버전으로 업그레이드 수행 | 이 시나리오는 Red Hat OpenStack Platform의 주요 버전에서 업그레이드하는 것입니다. 이 경우 절차는 버전 7에서 버전 8로 업그레이드합니다. 여기에는 director 패키지를 업데이트한 다음 director를 사용하여 각 노드에서 업그레이드 스크립트 세트를 제공한 다음 Overcloud 스택 업그레이드를 수행해야 합니다. |
직접이 아닌 환경: OpenStack 서비스 동시에 업그레이드 | 이 시나리오는 관리용으로 director를 사용하지 않는 Red Hat OpenStack Platform 8 환경의 모든 패키지 업그레이드(즉, 수동으로 생성된 환경)를 위한 것입니다. 이 시나리오에서는 모든 패키지가 동시에 업그레이드됩니다. |
비 직접 환경: 표준 환경에서 개별 OpenStack 서비스 업그레이드(Live Compute) | 이 시나리오는 관리(예: 수동으로 생성된 환경)에 director를 사용하지 않는 Red Hat OpenStack Platform 환경 8의 모든 패키지를 업그레이드하는 것입니다. 이 시나리오에서는 각 OpenStack 서비스를 개별적으로 업데이트합니다. |
직접 이외의 환경: 고가용성 환경에서 개별 OpenStack 서비스 업그레이드(Live Compute) | 이 시나리오는 관리(예: 수동으로 생성된 환경)에 director를 사용하지 않는 Red Hat OpenStack Platform 8 환경의 모든 패키지를 업그레이드하고 컨트롤러 기반 OpenStack 서비스에 고가용성 툴을 사용하는 것입니다. 이 시나리오에서는 각 OpenStack 서비스를 개별적으로 업데이트합니다. |
모든 방법의 경우:
- 모든 호스트에서 이 릴리스에 대해 올바른 리포지토리를 활성화했는지 확인합니다.
- 업그레이드에는 일부 서비스 중단이 포함됩니다.
- 컴퓨팅 노드를 재부팅하거나 인스턴스를 명시적으로 종료하지 않는 한 실행 중인 인스턴스는 업그레이드 프로세스의 영향을 받지 않습니다.
Red Hat은 Red Hat OpenStack Platform 베타 릴리스를 지원되는 릴리스로 업그레이드할 수 없습니다.
1.2. 리포지터리 요구 사항
언더클라우드와 오버클라우드 모두 Red Hat Content Delivery Network 또는 Red Hat Satellite 5 또는 6을 통해 Red Hat 리포지토리에 액세스해야 합니다. Red Hat Satellite Server를 사용하는 경우 필요한 리포지토리를 OpenStack Platform 환경에 동기화합니다. 다음 CDN 채널 이름 목록을 가이드로 사용합니다.
이름 | 리포지토리 | 요구 사항 설명 |
Red Hat Enterprise Linux 7 Server(RPM) |
| 기본 운영 체제 리포지토리. |
Red Hat Enterprise Linux 7 Server - Extras(RPM) |
| Red Hat OpenStack Platform 종속성을 포함합니다. |
Red Hat Enterprise Linux 7 Server - RH Common (RPM) |
| Red Hat OpenStack Platform 배포 및 구성을 위한 도구가 포함되어 있습니다. |
Red Hat Satellite Tools for RHEL 7 Server RPMs x86_64 |
| Red Hat Satellite 6으로 호스트를 관리하는 툴입니다. |
Red Hat Enterprise Linux High Availability(RHEL 7 Server용)(RPM) |
| Red Hat Enterprise Linux용 고가용성 툴입니다. 컨트롤러 노드 고가용성에 사용됩니다. |
Red Hat OpenStack Platform 8 director for RHEL 7(RPM) |
| Red Hat OpenStack Platform director 리포지토리. director가 배포한 Overcloud에서 사용할 수 있는 일부 툴도 제공합니다. |
Red Hat OpenStack Platform 8 for RHEL 7(RPM) |
| 코어 Red Hat OpenStack Platform 리포지토리입니다. |
Ceph 클러스터가 있는 경우 다음 리포지토리도 필요합니다.
Red Hat Ceph Storage OSD 1.3 for Red Hat Enterprise Linux 7 Server(RPM) |
| (Ceph Storage 노드용) Ceph Storage Object Storage 데몬용 리포지토리입니다. Ceph Storage 노드에 설치됩니다. |
Red Hat Ceph Storage MON 1.3 for Red Hat Enterprise Linux 7 Server(RPM) |
| (Ceph Storage 노드용) Ceph Storage 모니터 데몬용 리포지토리입니다. Ceph Storage 노드를 사용하는 OpenStack 환경의 Controller 노드에 설치됩니다. |
오프라인 네트워크에서 Red Hat OpenStack Platform 환경에 대한 리포지토리를 구성하려면 Red Hat 고객 포털의 "오프라인 환경에서 Red Hat OpenStack Platform Director 구성" 을 참조하십시오.
2장. director 기반 환경: 마이너 버전에 대한 업데이트 수행
이 섹션에서는 동일한 버전에서 Red Hat OpenStack Platform 환경의 패키지를 업데이트하는 방법을 설명합니다. 이 경우 Red Hat OpenStack Platform 8 내에서 업그레이드됩니다. 여기에는 Undercloud 및 Overcloud의 측면 업데이트가 포함됩니다.
Compute 인스턴스(또는 Compute 인스턴스의 고가용성에 설명된 대로 인스턴스 HA)에 대한 높은 가용성으로는 업그레이드 또는 확장 작업을 수행할 수 없습니다. 이렇게 하려는 모든 시도는 실패합니다.
인스턴스 HA가 활성화된 경우 업그레이드 또는 확장을 수행하기 전에 비활성화합니다. 이렇게 하려면 롤백에 설명된 대로 롤백 을 수행합니다. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/8/html-single/high_availability_for_compute_instances/#rollback
두 경우 모두 다음 워크플로를 수행해야 합니다.
- Red Hat OpenStack Platform director 패키지 업데이트
- Red Hat OpenStack Platform director에서 오버클라우드 이미지 업데이트
- Red Hat OpenStack Platform director를 사용하여 Overcloud 패키지 업데이트
2.1. Director 패키지 업데이트
director는 표준 RPM 방법을 사용하여 환경을 업데이트합니다. 여기에는 yum
을 통해 director 호스트가 최신 패키지를 사용하는지 확인해야 합니다.
-
stack
사용자로 director에 로그인합니다. 주요 OpenStack Platform 서비스를 중지합니다.
$ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
참고이로 인해 언더클라우드의 다운타임이 짧습니다. 언더클라우드 업데이트 중에 오버클라우드가 계속 작동합니다.
python-tripleoclient
패키지 및 해당 종속 항목을 업데이트하여 마이너 버전 업데이트에 대한 최신 스크립트가 있는지 확인합니다.$ yum update python-tripleoclient
director는
openstack undercloud upgrade
명령을 사용하여 Undercloud 환경을 업데이트합니다. 명령을 실행합니다.$ openstack undercloud upgrade
언더클라우드에서 모든 서비스가 활성화되어 있는지 확인합니다.
# sudo systemctl -t service
Overcloud 및 해당 노드가 있는지 확인합니다.
$ source ~/stackrc $ openstack server list $ openstack baremetal node list $ openstack stack list
2.2. 오버클라우드 이미지 업데이트
Undercloud 업데이트 프로세스에서 rhosp-director-images 및
패키지에서 새 이미지 아카이브를 다운로드할 수 있습니다. rhosp-director-images
-ipayum
로그를 확인하여 새 이미지 아카이브를 사용할 수 있는지 확인합니다.
$ sudo grep "rhosp-director-images" /var/log/yum.log
새 아카이브를 사용할 수 있는 경우 현재 이미지를 새 이미지로 교체합니다. 새 이미지를 설치하려면 먼저 stack
사용자의 홈(/home/stack/
)의 images 디렉터리에서 기존 이미지를 제거합니다.
images
$ rm -rf ~/images/*
새 이미지 아카이브를 복사합니다.
$ cp /usr/share/rhosp-director-images/overcloud-full-latest-8.0.tar ~/images/. $ cp /usr/share/rhosp-director-images/ironic-python-agent-latest-8.0.tar ~/images/.
아카이브를 추출합니다.
$ cd ~/images $ for tarfile in *.tar; do tar -xf $tarfile; done
최신 이미지를 director로 가져오고 새 이미지를 사용하도록 노드를 설정합니다.
$ openstack overcloud image upload --update-existing --image-path ~/images/. $ openstack baremetal configure boot
이미지 업데이트를 완료하려면 새 이미지가 있는지 확인합니다.
$ openstack image list $ ls -l /httpboot
이제 director가 업데이트되고 최신 이미지를 사용합니다. 업데이트 후에는 서비스를 다시 시작할 필요가 없습니다.
2.3. 구성 에이전트 업데이트
이 섹션은 Red Hat OpenStack Platform 8.0 초기 릴리스에서 업데이트하는 경우에만 필요합니다. 이전 업데이트에서 이 단계를 수행한 경우 무시할 수 있습니다.
알려진 문제( BZ#12781 참조)로 인해 오버클라우드에는 구성 에이전트를 수동으로 구성해야 합니다. 이를 위해서는 director에서 Overcloud의 각 노드로 새 버전의 설정 에이전트 스크립트를 복사해야 합니다.
director 호스트에 stack
사용자로 로그인하고 Undercloud 설정을 소싱합니다.
$ source ~/stackrc
구성 에이전트(55-heat-config
)를 각 Overcloud 노드에 복사합니다. 다음 명령을 사용하여 모든 호스트에 대해 이 작업을 수행합니다.
$ for i in $(nova list | awk '/Running/ {print $(NF-1)}' | awk -F"=" '{print $NF}' ) ; do echo $i ; scp -o StrictHostKeyChecking=no /usr/share/openstack-heat-templates/software-config/elements/heat-config/os-refresh-config/configure.d/55-heat-config heat-admin@${i}: ; ssh -o StrictHostKeyChecking=no heat-admin@${i} 'sudo /bin/bash -c "cp /home/heat-admin/55-heat-config /usr/libexec/os-refresh-config/configure.d/55-heat-config"' ; done
이렇게 하면 구성 에이전트가 최신 상태로 유지됩니다.
이 Overcloud는 일부 배포 후 파일도 다시 생성해야 합니다. director에는 이 작업을 수행하는 스크립트가 포함되어 있습니다. 각 노드에서 heat-config-rebuild-deployed
스크립트를 복사하고 실행합니다. 다음 명령을 사용하여 모든 노드에 이 작업을 수행합니다.
$ for i in $(nova list | awk '/Running/ {print $(NF-1)}' | awk -F"=" '{print $NF}') ; do echo $i ; scp -o StrictHostKeyChecking=no /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed heat-admin@${i}: ; ssh -o StrictHostKeyChecking=no heat-admin@${i} 'sudo /bin/bash -c "mkdir -p /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin ; cp heat-config-rebuild-deployed /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed ; chmod +x /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed ; /usr/share/openstack-heat-templates/software-config/elements/heat-config/bin/heat-config-rebuild-deployed"' ; done
2.4. 오버클라우드 패키지 업데이트
Overcloud는 표준 RPM 방법을 사용하여 환경을 업데이트합니다. 여기에는 director의 openstack overcloud 업데이트를 사용하여 모든 노드에서 업데이트를
수행해야 합니다.
-e
를 사용하여 오버클라우드와 관련된 환경 파일 및 업그레이드 경로를 포함합니다. 후속 환경 파일에 정의된 매개변수와 리소스가 우선하므로 환경 파일의 순서가 중요합니다. 다음 목록은 환경 파일 순서의 예입니다.
-
heat 템플릿 컬렉션의
overcloud-resource-registry-puppet.yaml
파일입니다.openstack overcloud deploy
명령을 실행할 때 이 파일이 자동으로 포함되어 있지만openstack overcloud update
명령을 실행할 때 이 파일을 포함해야 합니다. -
heat 템플릿 컬렉션의 초기화 파일(
environments/network-isolation.yaml
) 및 사용자 지정 NIC 구성 파일을 포함한 네트워크 분리 파일입니다. - 모든 외부 로드 밸런싱 환경 파일입니다.
- 모든 스토리지 환경 파일.
- Red Hat CDN 또는 Satellite 등록의 환경 파일
- 기타 사용자 지정 환경 파일
모든 노드에서 병렬로 업데이트를 실행하면 문제가 발생할 수 있습니다. 예를 들어 패키지를 업데이트하려면 다른 노드를 중단할 수 있는 서비스를 다시 시작해야 할 수 있습니다. 이로 인해 업데이트 프로세스에서 각 노드를 일련의 Cryostat를 사용하여 업데이트합니다. 즉, 노드가 하나씩 업데이트됩니다. 하나의 노드가 패키지 업데이트를 완료하면 업데이트 프로세스가 다음 노드로 이동합니다. 업데이트 프로세스에는 각 Cryostat에서 확인이 필요한 대화형 모드로 명령을 배치하는 -i
옵션도 필요합니다. -i
옵션이 없으면 업데이트는 첫 번째 Cryostat에서 일시 중지된 상태로 유지됩니다.
다음은 Overcloud를 업데이트하기 위한 예제 업데이트 명령입니다.
$ openstack overcloud update stack overcloud -i \ --templates \ -e /usr/share/openstack-tripleo-heat-templates/overcloud-resource-registry-puppet.yaml \ -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>|...]
이 명령을 실행하면 업데이트 프로세스가 시작됩니다. 이 프로세스 중에 director는 IN_PROGRESS
상태를 보고하고 주기적으로 Cryostat를 삭제하라는 메시지를 표시합니다. 예를 들면 다음과 같습니다.
not_started: [u'overcloud-controller-0', u'overcloud-controller-1', u'overcloud-controller-2'] on_breakpoint: [u'overcloud-compute-0'] Breakpoint reached, continue? Regexp or Enter=proceed, no=cancel update, C-c=quit interactive mode:
Enter를 눌러 on_breakpoint
목록의 마지막 노드에서 Cryostat를 지웁니다. 그러면 해당 노드의 업데이트가 시작됩니다. 노드 이름을 입력하여 특정 노드에서 Cryostat를 지우거나 Python 기반 정규식을 입력하여 한 번에 여러 노드에서 Cryostat를 지울 수도 있습니다. 그러나 한 번에 여러 컨트롤러 노드에서 Cryostat를 지우는 것은 권장되지 않습니다. 모든 노드가 업데이트를 완료할 때까지 이 프로세스를 계속합니다.
업데이트가 완료되면 update 명령은 COMPLETE
상태를 보고합니다.
... IN_PROGRESS IN_PROGRESS IN_PROGRESS COMPLETE update finished with status COMPLETE
컨트롤러 노드에 대한 펜싱을 구성한 경우 업데이트 프로세스에서 해당 노드를 비활성화할 수 있습니다. 업데이트 프로세스가 완료되면 컨트롤러 노드 중 하나에서 다음 명령을 사용하여 펜싱을 다시 활성화합니다.
$ sudo pcs property set stonith-enabled=true
업데이트 프로세스에서 오버클라우드의 노드를 자동으로 재부팅하지 않습니다. 필요한 경우 업데이트가 완료된 후 수동으로 재부팅을 수행합니다.
3장. director 기반 환경: 주요 버전으로 업그레이드 수행
최신 주요 버전으로 업그레이드하기 전에 언더클라우드 및 오버클라우드가 최신 마이너 버전으로 업데이트되었는지 확인합니다. 여기에는 OpenStack Platform 서비스와 기본 운영 체제가 모두 포함됩니다. 마이너 버전 업데이트를 수행하는 프로세스는 Red Hat OpenStack Platform 7 Director 설치 및 사용 가이드의 "환경 업그레이드"를 참조하십시오. 먼저 마이너 버전 업데이트를 수행하지 않고 주요 버전 업그레이드를 수행하면 업그레이드 프로세스가 실패할 수 있습니다.
Compute 인스턴스(또는 Compute 인스턴스의 고가용성에 설명된 대로 인스턴스 HA)에 대한 높은 가용성으로는 업그레이드 또는 확장 작업을 수행할 수 없습니다. 이렇게 하려는 모든 시도는 실패합니다.
인스턴스 HA가 활성화된 경우 업그레이드 또는 확장을 수행하기 전에 비활성화합니다. 이렇게 하려면 롤백에 설명된 대로 롤백 을 수행합니다. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/8/html-single/high_availability_for_compute_instances/#rollback
이 장에서는 환경을 업그레이드하는 방법을 설명합니다. 여기에는 Undercloud 및 Overcloud의 업그레이드 측면이 포함됩니다. 이 업그레이드 프로세스는 다음 주요 버전으로 이동할 수 있는 수단을 제공합니다. 이 경우 Red Hat OpenStack Platform 7에서 Red Hat OpenStack Platform 8로 업그레이드됩니다.
두 경우 모두 다음 워크플로를 수행해야 합니다.
- Red Hat OpenStack Platform director 패키지 업데이트
- Red Hat OpenStack Platform director에서 오버클라우드 이미지 업데이트
- Red Hat OpenStack Platform director를 사용하여 Overcloud 스택 및 해당 패키지 업데이트
버전 업그레이드를 시도하기 전에 3.1절. “중요한 사전 업그레이드 노트” 에서 정보를 읽으십시오.
3.1. 중요한 사전 업그레이드 노트
환경을 업그레이드하기 전에 다음 노트를 읽으십시오.
Red Hat OpenStack Platform director의 업그레이드에는 실시간 프로덕션 환경에서 실행하기 전에 특정 구성으로 전체 테스트가 필요합니다. Red Hat은 director를 통해 표준 옵션으로 제공되는 대부분의 사용 사례와 조합을 테스트했지만 가능한 조합의 수로 인해 완전히 완전한 목록이 될 수 없습니다. 또한 수동으로 또는 사후 구성 후크를 통해 표준 배포에서 구성을 수정한 경우 비프로덕션 환경에서 업그레이드 기능을 테스트하는 것이 훨씬 더 중요합니다. 따라서 다음 사항을 권장합니다.
- 업그레이드 절차의 단계를 시작하기 전에 Undercloud 노드 백업을 수행합니다. 백업 프로시저는 Red Hat OpenStack Platform 백업 및 복원 가이드를 참조하십시오.
- 프로덕션 환경에서 절차를 실행하기 전에 변경한 모든 변경 사항이 포함된 테스트 환경에서 업그레이드 절차를 실행합니다.
- 이 업그레이드 수행에 대한 불만이 있는 경우 Red Hat에 연락하여 업그레이드 프로세스에 대한 지침과 지원을 요청하십시오.
- 이 섹션에 설명된 업그레이드 프로세스는 director를 통한 사용자 정의만 수용합니다. director 외부에서 Overcloud 기능을 사용자 지정한 경우 기능을 비활성화하고 Overcloud를 업그레이드한 후 업그레이드가 완료된 후 기능을 다시 활성화합니다. 즉, 전체 업그레이드가 완료될 때까지 사용자 지정 기능을 사용할 수 없습니다.
Red Hat OpenStack Platform director 8은 중요한 Overcloud 버전을 관리할 수 있습니다. 자세한 내용은 아래 지원 매트릭스를 참조하십시오.
표 3.1. Red Hat OpenStack Platform director 8에 대한 지원 매트릭스 버전
오버클라우드 업데이트
오버클라우드 배포
오버클라우드 확장
Red Hat OpenStack Platform 7
7.0.4 이상
7.0.4 이상
7.0.4 이상
Red Hat OpenStack Platform 8
모든 버전
모든 버전
모든 버전
managing 및 이전 Overcloud 버전을 사용하는 경우 다음 Heat 템플릿 컬렉션을 사용합니다.
Red Hat OpenStack Platform 7의 경우:
/usr/share/openstack-tripleo-heat-templates/kilo/
예를 들면 다음과 같습니다.
$ openstack overcloud deploy -templates /usr/share/openstack-tripleo-heat-templates/kilo/ [OTHER_OPTIONS]
Red Hat OpenStack Platform 7 Overcloud를 관리하는 경우
/home/stack/tripleo-overcloud-passwords
파일에서 RabbitMQ 암호를 버전 7 default로 설정합니다.OVERCLOUD_RABBITMQ_PASSWORD=guest
Satellite 등록에 환경 파일을 사용하는 경우 환경 파일에서 다음 매개변수를 업데이트해야 합니다.
-
rhel_reg_repos
- 새로운 Red Hat OpenStack Platform 8 리포지토리를 포함하여 오버클라우드에 사용할 리포지토리입니다. 리포지토리를 활성화할 때는 1.2절. “리포지터리 요구 사항” 를 참조하십시오. -
rhel_reg_activation_key
- Red Hat OpenStack Platform 8 리포지토리의 새 활성화 키입니다. -
rhel_reg_sat_repo
-katello-agent
와 같은 Red Hat Satellite 6의 관리 도구가 포함된 리포지토리를 정의하는 새 매개변수입니다. Red Hat Satellite 6에 등록하는 경우 이 매개변수를 추가해야 합니다.
-
- Red Hat OpenStack Platform 8의 기본 시간대는 이제 UTC입니다. Red Hat OpenStack Platform 7의 기본 시간대는 EST입니다. 필요한 경우 환경 파일을 포함하여 시간대를 지정합니다.
- 외부 로드 밸런서를 사용하는 경우 Red Hat OpenStack Platform 8에서 새 서비스를 수용하도록 로드 밸런싱 설정을 업데이트합니다. 전체 서비스 및 예제 구성 목록은 External Load Balancing for the Overcloud 가이드의 "서비스 구성 참조" 를 참조하십시오.
- Red Hat OpenStack Platform 8로 주요 업그레이드를 시도하기 전에 언더클라우드 및 오버클라우드를 Red Hat OpenStack Platform 7 및 Red Hat Enterprise Linux 7의 최신 마이너 릴리스로 업그레이드했는지 확인하십시오. 언더클라우드 및 오버클라우드에 대한 패키지 업데이트를 수행하는 방법에 대한 지침은 Red Hat OpenStack Platform 7 Director 설치 및 사용 가이드의 "환경 업그레이드"를 참조하십시오. 커널이 최신 버전으로 업데이트되면 새 커널 매개 변수가 적용되도록 재부팅을 수행합니다.
-
솔루션에 설명된 대로
libvirt
에 버전 잠금을 적용합니다.
3.2. Director 업그레이드
다음 절차의 단계를 시도하기 전에 3.1절. “중요한 사전 업그레이드 노트” 의 정보를 읽으십시오.
stack
사용자로 director에 로그인하고 주요 OpenStack Platform 서비스를 중지합니다.
$ sudo systemctl stop 'openstack-*' 'neutron-*' httpd
이로 인해 언더클라우드의 다운타임이 짧습니다. 언더클라우드 업데이트 중에 오버클라우드가 계속 작동합니다.
director 패키지를 최신 주요 버전으로 업데이트하려면 OpenStack Platform 리포지토리를 이전 버전에서 새 버전으로 변경합니다. 예를 들면 다음과 같습니다.
$ sudo subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms --disable=rhel-7-server-openstack-7.0-director-rpms $ sudo subscription-manager repos --enable=rhel-7-server-openstack-8-rpms --enable=rhel-7-server-openstack-8-director-rpms
이렇게 하면 최신 리포지토리를 사용하도록 yum
이 설정됩니다. yum
을 사용하여 director를 업데이트합니다.
$ sudo yum upgrade
yum 업데이트가
완료된 후 일부 OpenStack 서비스가 실패할 수 있습니다. 이는 예상되는 동작입니다. Undercloud의 upgrade 명령은 이러한 서비스의 구성을 수정합니다.
director는 openstack undercloud upgrade
명령을 사용하여 Undercloud 환경을 업그레이드합니다. 업그레이드 명령을 실행합니다.
$ openstack undercloud upgrade
이렇게 하면 director 설정이 새로 고쳐지고 버전이 변경된 이후 설정되지 않은 설정을 채웁니다. 이 명령을 실행해도 저장된 데이터(예: Overcloud 스택 데이터 또는 사용자 환경의 기존 노드에 대한 데이터는 삭제되지 않습니다.
업데이트가 완료되면 director의 OpenStack 서비스를 확인합니다.
$ sudo systemctl list-units openstack-*
openstack-keystone
가 실패한 서비스로 표시될 수 있습니다. 이제 서비스가 WSGI 애플리케이션으로 httpd
서비스를 통해 실행되기 때문입니다. director 패키지를 업데이트하고 openstack undercloud upgrade
를 실행한 후 openstack-keystone
서비스를 비활성화할 수 있습니다.
업데이트를 완료하려면 Overcloud 및 해당 노드가 있는지 확인합니다.
$ source ~/stackrc $ openstack server list $ ironic node-list $ heat stack-list
Overcloud를 Red Hat OpenStack Platform 8로 업그레이드한 후 다음 사항에 유의하십시오.
SSL을 사용하는 언더클라우드는 업그레이드하는 동안 VIP에 대한 액세스 권한이 손실될 수 있습니다. 이 경우 Undercloud에서
keepalived
서비스를 다시 시작합니다.$ systemctl restart keepalived
Undercloud의
관리자에
는 Red Hat OpenStack Platform 8에 추가 역할(_member_
)이 필요하지 않을 수 있습니다. 이 역할은 Overcloud 통신에 중요합니다. 이 역할을 확인합니다.$ keystone role-list
역할이 없는 경우 역할을 생성합니다.
$ keystone role-create --name _member_
admin
테넌트에서admin
사용자에게 역할을 추가합니다.$ keystone user-role-add --user admin --role _member_ --tenant admin
사용자 지정된 코어 Heat 템플릿을 사용하는 경우 업데이트된 코어 Heat 템플릿과 현재 세트 간의 차이점을 확인하십시오. Red Hat은 후속 릴리스에서 Heat 템플릿 컬렉션에 대한 업데이트를 제공합니다. 수정된 템플릿 컬렉션을 사용하면 사용자 지정 사본과
/usr/share/openstack-tripleo-heat-templates
의 원본 사본이 다를 수 있습니다. 다음 명령을 실행하여 사용자 지정 Heat 템플릿 컬렉션과 업데이트된 원본 버전 간의 차이점을 확인합니다.# diff -Nary /usr/share/openstack-tripleo-heat-templates/ ~/templates/my-overcloud/
이러한 업데이트를 사용자 지정 Heat 템플릿 컬렉션에 적용하거나
/usr/share/openstack-tripleo-heat-templates/
에 템플릿의 새 사본을 생성하고 사용자 지정을 적용해야 합니다.
3.3. Director에서 오버클라우드 이미지 업그레이드
다음 절차의 단계를 시도하기 전에 3.1절. “중요한 사전 업그레이드 노트” 의 정보를 읽으십시오.
이 절차에서는 노드 검색 및 Overcloud 배포를 위한 최신 이미지가 있는지 확인합니다. rhosp-director-images
및 rhosp-director-images-ipa
패키지의 새 이미지는 Undercloud 업그레이드에서 이미 업데이트되었습니다.
stack
사용자 홈(/home/stack/
)의 images 디렉터리에서 기존 이미지를 제거한 다음 새 이미지 아카이브를 복사합니다.
images
$ rm -rf ~/images/* $ cp /usr/share/rhosp-director-images/overcloud-full-latest-8.0.tar ~/images/. $ cp /usr/share/rhosp-director-images/ironic-python-agent-latest-8.0.tar ~/images/.
아카이브를 추출합니다.
$ cd ~/images $ for tarfile in *.tar; do tar -xf $tarfile; done
최신 이미지를 director로 가져오고 새 이미지를 사용하도록 노드를 설정합니다.
$ openstack overcloud image upload --update-existing --image-path ~/images/. $ openstack baremetal configure boot
이미지 업데이트를 완료하려면 새 이미지가 있는지 확인합니다.
$ openstack image list $ ls -l /httpboot
이제 director가 최신 이미지로 업그레이드되었습니다.
Overcloud 이미지 버전이 Undercloud 버전에 해당하는지 확인합니다.
3.4. 오버클라우드 업그레이드
다음 절차의 단계를 시도하기 전에 3.1절. “중요한 사전 업그레이드 노트” 의 정보를 읽으십시오.
이 섹션에서는 오버클라우드 업그레이드에 필요한 단계에 대해 자세히 설명합니다. 각 섹션을 순서대로 따르고 해당 환경과 관련된 섹션만 적용하십시오.
이 프로세스에서는 업그레이드 준비 방법을 제공하기 위해 원래 openstack overcloud deploy
명령을 여러 번 실행해야 합니다. 명령을 실행할 때마다 기존 환경 파일과 함께 다른 업그레이드 환경 파일을 포함합니다. 이러한 새로운 업그레이드 환경 파일은 다음과 같습니다.
-
major-upgrade-pacemaker-init.yaml
- 업그레이드에 초기화를 제공합니다. 여기에는 오버클라우드의 각 노드에서 Red Hat OpenStack Platform 리포지토리를 업데이트하고 특정 노드에 특수 업그레이드 스크립트를 제공하는 작업이 포함됩니다. -
major-upgrade-pacemaker.yaml
- 컨트롤러 노드에 대한 업그레이드를 제공합니다. -
major-upgrade-pacemaker-converge.yaml
- Overcloud 업그레이드 종료 이렇게 하면 결과 업그레이드가 director의 최신 Heat 템플릿 컬렉션의 내용과 일치하도록 정렬됩니다.
이러한 배포 명령 간에 다양한 노드 유형에서 upgrade-non-controller.sh
스크립트를 실행합니다. 이 스크립트는 컨트롤러 이외의 노드에서 패키지를 업데이트합니다.
워크플로
Overcloud 업그레이드 프로세스에서는 다음 워크플로를 사용합니다.
-
major-upgrade-pacemaker-init.yaml
환경 파일을 포함하여 배포 명령을 실행합니다. -
각 Object Storage 노드에서
upgrade-non-controller.sh
를 실행합니다. -
major-upgrade-pacemaker.yaml
환경 파일을 포함하여 배포 명령을 실행합니다. -
각 컴퓨팅 노드에서
upgrade-non-controller.sh
를 실행합니다. -
각 Ceph Storage 노드에서
upgrade-non-controller.sh
를 실행합니다. -
major-upgrade-pacemaker-converge.yaml
환경 파일을 포함하여 배포 명령을 실행합니다.
3.4.1. 관리 네트워크 포함
Red Hat OpenStack Platform 7의 사용자 지정 NIC 템플릿을 사용하는 경우 ManagementSubnetIp
매개변수를 NIC 템플릿의 parameters
섹션에 추가합니다. 예를 들면 다음과 같습니다.
parameters: ManagementIpSubnet: # Only populated when including environments/network-management.yaml default: '' description: IP address/subnet on the management network type: string
3.4.2. 업그레이드 스크립트 설치
이 단계에서는 컨트롤러 이외의 각 노드에 스크립트를 설치합니다. 이 스크립트는 주요 버전 패키지 업그레이드 및 구성을 수행합니다. 각 스크립트는 노드 유형에 따라 다릅니다. 예를 들어 컴퓨팅 노드는 Ceph Storage 노드로 다른 업그레이드 스크립트를 수신합니다.
이 초기화 단계에서는 모든 오버클라우드 노드에서 활성화된 리포지토리도 업데이트됩니다. 즉, 이전 리포지토리를 비활성화하고 새 리포지토리를 수동으로 활성화할 필요가 없습니다.
Undercloud에서 openstack overcloud deploy
를 실행하고 major-upgrade-pacemaker-init.yaml
환경 파일을 포함합니다. 네트워크 격리 및 스토리지와 같이 환경과 관련된 모든 사용자 지정 환경 파일도 포함해야 합니다.
다음은 추가된 파일이 포함된 openstack overcloud deploy
명령의 예입니다. 예를 들면 다음과 같습니다.
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e /home/stack/templates/network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml
Overcloud가 새 환경 파일의 구성으로 업데이트될 때까지 기다립니다.
3.4.3. 오브젝트 스토리지 노드 업그레이드
director는 upgrade-non-controller.sh
명령을 사용하여 major-upgrade-pacemaker-init.yaml
환경 파일에서 각 비Controller 노드에 전달된 업그레이드 스크립트를 실행합니다. 이 단계에서는 다음 명령을 사용하여 각 Object Storage 노드를 업그레이드합니다.
$ for NODE in `nova list | grep swift | awk -F "|" '{ print $2 }'` ; do upgrade-non-controller.sh --upgrade $NODE ; done
각 Object Storage 노드가 업그레이드를 완료할 때까지 기다립니다.
3.4.4. 컨트롤러 노드 업그레이드
컨트롤러 노드를 업그레이드하려면 고가용성 툴을 실행하는 컨트롤러 노드로 전체 업그레이드를 제공하는 다른 환경 파일(major-upgrade-pacemaker.yaml
)을 포함해야 합니다.
Undercloud에서 openstack overcloud deploy
를 실행하고 major-upgrade-pacemaker.yaml
환경 파일을 포함합니다. 네트워크 격리 및 스토리지와 같이 환경과 관련된 모든 사용자 지정 환경 파일도 포함해야 합니다.
다음은 추가된 파일이 포함된 openstack overcloud deploy
명령의 예입니다. 예를 들면 다음과 같습니다.
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker.yaml
Overcloud가 새 환경 파일의 구성으로 업데이트될 때까지 기다립니다.
이 단계에서는 컨트롤러를 업그레이드하는 동안 Neutron 서버 및 L3 에이전트를 비활성화합니다. 즉, 이 단계에서 유동 IP 주소를 사용할 수 없습니다.
이 단계에서 Overcloud 스택이 실패하면 컨트롤러 노드 중 하나에 로그인하고 sudo pcs cluster start
를 실행한 다음 director에서 openstack overcloud deploy
를 재실행합니다.
3.4.5. 컴퓨팅 노드 업그레이드
director는 upgrade-non-controller.sh
명령을 사용하여 major-upgrade-pacemaker-init.yaml
환경 파일에서 각 비Controller 노드에 전달된 업그레이드 스크립트를 실행합니다.
컴퓨팅 노드 및 해당 UUID 목록을 가져옵니다.
$ nova list | grep "compute"
각 노드에서 다음 작업을 개별적으로 수행하여 다운타임이 발생하지 않습니다. 업그레이드할 컴퓨팅 노드를 선택합니다.
- 워크로드를 마이그레이션합니다. Red Hat OpenStack Platform Director 설치 및 사용 가이드의 " Overcloud Compute Node에서 VM 마이그레이션 "을 참조하십시오.
선택한 노드의 Compute 서비스가 비활성화되어 있는지 확인합니다.
$ source ~/overcloudrc $ nova service-list $ nova service-disable [hostname] nova-compute
다음 명령을 사용하여 각 컴퓨팅 노드를 업그레이드합니다.
$ source ~/stackrc $ upgrade-non-controller.sh --upgrade NODE_UUID
NODE_UUID 를 선택한 컴퓨팅 노드의 UUID로 바꿉니다.
컴퓨팅 노드가 업그레이드를 완료할 때까지 기다립니다. 업그레이드가 완료되면 다음 명령을 사용하여 컴퓨팅 노드가 활성화되었는지 확인합니다.
$ source ~/overcloudrc $ nova service-list $ nova service-enable [hostname] nova-compute
각 컴퓨팅 노드에서 이 단계를 반복합니다.
3.4.6. Ceph Storage 노드 업그레이드
director는 upgrade-non-controller.sh
명령을 사용하여 major-upgrade-pacemaker-init.yaml
환경 파일에서 각 비Controller 노드에 전달된 업그레이드 스크립트를 실행합니다. 이 단계에서는 다음 명령을 사용하여 각 Ceph Storage 노드를 업그레이드합니다.
각 Ceph Storage 노드를 업그레이드합니다.
$ for NODE in `nova list | grep ceph | awk -F "|" '{ print $2 }'` ; do upgrade-non-controller.sh --upgrade $NODE ; done
3.4.7. 업그레이드 완료
Overcloud 스택이 현재 Heat 템플릿 컬렉션과 동기화되도록 업그레이드 종료를 통해 director를 실행해야 합니다. 여기에는 openstack overcloud deploy
명령을 사용하여 포함하는 환경 파일(major-upgrade-pacemaker-converge.yaml
)이 포함됩니다.
Undercloud에서 openstack overcloud deploy
를 실행하고 major-upgrade-pacemaker-converge.yaml
환경 파일을 포함합니다. 네트워크 격리 및 스토리지와 같이 환경과 관련된 모든 사용자 지정 환경 파일도 포함해야 합니다.
다음은 추가된 파일이 포함된 openstack overcloud deploy
명령의 예입니다. 예를 들면 다음과 같습니다.
$ openstack overcloud deploy --templates \ --control-scale 3 \ --compute-scale 3 \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-converge.yaml
Overcloud가 새 환경 파일의 구성으로 업데이트될 때까지 기다립니다.
이렇게 하면 Overcloud 업그레이드 절차가 완료됩니다.
3.4.8. 업그레이드 후 노트
Overcloud를 Red Hat OpenStack Platform 8로 업그레이드한 후 다음 사항에 유의하십시오.
컴퓨팅 노드는
neutron-openvswitch-agent
를 사용하여 오류를 보고할 수 있습니다. 이 경우 각 컴퓨팅 노드에 로그인하고 서비스를 다시 시작합니다. 예를 들면 다음과 같습니다.$ sudo systemctl restart neutron-openvswitch-agent
-
업데이트 프로세스에서 오버클라우드의 노드를 자동으로 재부팅하지 않습니다. 필요한 경우 업데이트 명령이 완료된 후 수동으로 재부팅을 수행합니다. 클러스터 기반 노드(예: Ceph Storage 노드 및 컨트롤러 노드)를 개별적으로 재부팅하고 노드가 클러스터에 다시 참여할 때까지 기다립니다. Ceph Storage 노드의 경우
ceph
상태로 확인하고 클러스터 상태가HEALTH OK
인지 확인합니다. 컨트롤러 노드의 경우pcs 리소스
를 확인하고 각 노드에 대해 모든 리소스가 실행 중인지 확인합니다. 경우에 따라 컨트롤러 노드를 재부팅한 후 IPv6 환경에서
corosync
서비스가 시작되지 않을 수 있습니다. 이는 컨트롤러 노드가 정적 IPv6 주소를 구성하기 전에 Corosync가 시작되기 때문입니다. 이러한 경우 컨트롤러 노드에서 Corosync를 수동으로 다시 시작합니다.$ sudo systemctl restart corosync
컨트롤러 노드에 대한 펜싱을 구성한 경우 업데이트 프로세스에서 해당 노드를 비활성화할 수 있습니다. 업데이트 프로세스가 완료되면 컨트롤러 노드 중 하나에서 다음 명령을 사용하여 펜싱을 다시 활성화합니다.
$ sudo pcs property set stonith-enabled=true
다음에 Overcloud 스택을 업데이트하거나 스케일링할 때(예:
openstack overcloud deploy
명령 실행) Overcloud에서 패키지 업데이트를 트리거하는 식별자를 재설정해야 합니다. 환경 파일에 빈UpdateIdentifier
매개변수를 추가하고openstack overcloud deploy
명령을 실행할 때 포함합니다. 다음은 이러한 환경 파일의 예입니다.parameter_defaults: UpdateIdentifier:
4장. 직접이 아닌 환경: OpenStack 서비스 동시에 업그레이드
이 시나리오는 director를 사용하지 않는 환경에서 Red Hat OpenStack Platform 7에서 Red Hat OpenStack Platform 8로 업그레이드합니다. 이 절차에서는 모든 노드에서 모든 서비스를 업그레이드합니다. 이 작업은 다음 워크플로우에 따라 수행됩니다.
- 모든 OpenStack 서비스 비활성화
- 패키지 업그레이드 수행
- 모든 데이터베이스의 동기화 수행
- 모든 OpenStack 서비스 활성화
이 장의 절차는 아키텍처 이름 지정 규칙에 따라 모든 Red Hat OpenStack Platform 설명서를 따릅니다. 이 규칙에 익숙하지 않은 경우 계속하기 전에 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 아키텍처 가이드를 참조하십시오.
4.1. 모든 OpenStack 서비스 비활성화
노드에서 Red Hat OpenStack Platform을 완전히 업그레이드하기 위한 첫 번째 단계는 모든 Openstack 서비스를 종료하는 것입니다. 이 단계는 노드 OpenStack이 관리에 고가용성 툴을 사용하는지(예: 컨트롤러 노드에서 Pacemaker 사용)에 따라 다릅니다. 이 단계에는 두 노드 유형에 대한 지침이 포함되어 있습니다.
표준 노드
모든 표준 노드에 openstack-utils
패키지를 설치합니다.
# yum install openstack-utils
모든 표준 노드에서 모든 OpenStack 서비스를 비활성화합니다.
# openstack-service stop
고가용성 노드
모든 OpenStack 서비스를 비활성화해야 하지만 데이터베이스 및 로드 밸런싱 서비스를 활성 상태로 유지해야 합니다. 예를 들어 Pacemaker에서 HAProxy, Galera 및 MongoDB 서비스를 Unmanaged로 전환합니다.
# pcs resource unmanage haproxy # pcs resource unmanage galera # pcs resource unmanage mongod
클러스터에서 stop-all-resources
속성을 설정하여 나머지 Pacemaker 관리 리소스를 비활성화합니다. Pacemaker 클러스터의 단일 멤버에서 다음을 실행합니다.
# pcs property set stop-all-resources=true
모든 Pacemaker 관리 리소스가 중지될 때까지 기다립니다. pcs status
명령을 실행하여 각 리소스의 상태를 확인합니다.
# pcs status
HAProxy는 사용할 수 없는 서비스에 대한 브로드캐스트 메시지를 표시할 수 있습니다. 이는 정상적인 동작입니다.
4.2. 패키지 업그레이드 수행
다음 단계는 노드의 모든 패키지를 업그레이드합니다. OpenStack 서비스를 사용하여 각 노드에서 이 단계를 수행합니다.
subscription-manager
명령을 사용하여 Red Hat OpenStack Platform 8 리포지토리로 변경합니다.
# subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms # subscription-manager repos --enable=rhel-7-server-openstack-8-rpms
노드에서 yum update
명령을 실행합니다.
# yum update
패키지 업그레이드가 완료될 때까지 기다립니다.
생성된 구성 파일을 검토합니다. 업그레이드된 패키지는 Red Hat OpenStack Platform 8 버전의 서비스에 적합한 .rpmnew
파일을 설치합니다. 새로운 버전의 OpenStack 서비스는 특정 구성 옵션을 사용 중단시킬 수 있습니다. 또한 향후 업그레이드 중에 문제가 발생할 수 있으므로 사용 중단 경고에 대해 OpenStack 로그를 검토해야 합니다. 각 서비스에 대한 새로운 업데이트 및 더 이상 사용되지 않는 구성 옵션에 대한 자세한 내용은 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 구성 참조를 참조하십시오.
환경의 각 노드에서 패키지 업그레이드를 수행합니다.
4.3. 모든 데이터베이스의 동기화 수행
다음 단계는 각 서비스에 대한 데이터베이스를 업그레이드합니다.
ID 서비스에서 만료된 토큰을 플러시하여 데이터베이스를 동기화하는 데 필요한 시간을 줄입니다.
# keystone-manage token_flush
데이터베이스를 사용하는 각 서비스의 데이터베이스 스키마를 업그레이드합니다. 서비스의 데이터베이스를 호스팅하는 노드에서 다음 명령을 실행합니다.
# openstack-db --service SERVICENAME --update
서비스의 프로젝트 이름을 SERVICENAME으로 사용합니다. 예를 들어 ID 서비스의 데이터베이스 스키마를 업그레이드하려면 다음을 수행합니다.
# openstack-db --service keystone --update
서비스 | 프로젝트 이름 |
---|---|
ID | Keystone |
이미지 서비스 | glance |
블록 스토리지 | cinder |
오케스트레이션 | Heat |
Compute | Nova |
네트워킹 | Neutron |
원격 분석 서비스는 데이터베이스 업그레이드를 위해 별도의 명령을 사용합니다.
# ceilometer-dbsync
4.4. 모든 OpenStack 서비스 활성화
마지막 단계에서는 노드에서 OpenStack 서비스를 활성화합니다. 이 단계는 OpenStack이 관리에 고가용성 툴을 사용하는지에 따라 다릅니다. 예를 들어 컨트롤러 노드에서 Pacemaker를 사용합니다. 이 단계에는 두 노드 유형에 대한 지침이 포함되어 있습니다.
표준 노드
모든 OpenStack 서비스를 활성화합니다.
# openstack-service stop
고가용성 노드
Pacemaker를 통해 리소스를 다시 시작합니다. Pacemaker 클러스터의 단일 멤버에서 stop-all-resources
속성을 재설정합니다. 예를 들면 다음과 같습니다.
# pcs property set stop-all-resources=false
모든 리소스가 시작될 때까지 기다립니다. pcs status
명령을 실행하여 각 리소스의 상태를 확인합니다.
# pcs status
데이터베이스 및 로드 밸런서와 같은 관리되지 않는 리소스에 대해 Pacemaker 관리를 활성화합니다.
# pcs resource manage haproxy # pcs resource manage galera # pcs resource manage mongod
4.5. 업그레이드 후 노트
새로운 버전의 OpenStack 서비스는 특정 구성 옵션을 사용 중단시킬 수 있습니다. 또한 향후 업그레이드 중에 문제가 발생할 수 있으므로 사용 중단 경고에 대한 OpenStack 로그를 검토해야 합니다. 각 서비스에 대한 새로운 업데이트 및 더 이상 사용되지 않는 구성 옵션에 대한 자세한 내용은 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 구성 참조를 참조하십시오.
5장. 비 직접 환경: 표준 환경에서 개별 OpenStack 서비스 업그레이드(Live Compute)
이 섹션에서는 HA(고가용성) 환경에서 실시간 컴퓨팅을 사용하여 한 번에 하나의 서비스를 업데이트하여 클라우드 배포를 업그레이드하기 위해 수행해야 하는 단계에 대해 설명합니다. 이 시나리오는 director를 사용하지 않는 환경에서 Red Hat OpenStack Platform 7에서 Red Hat OpenStack Platform 8로 업그레이드합니다.
실시간 컴퓨팅 업그레이드로 소규모 서비스의 경우 단 몇 분, 새로 업그레이드된 Compute 호스트로 이동하는 워크로드의 마이그레이션 간격을 몇 분만 사용하여 Compute 서비스에 대한 중단을 최소화합니다. 기존 워크로드는 무기한 실행될 수 있으며 데이터베이스 마이그레이션을 기다릴 필요가 없습니다.
특정 패키지 종속 항목으로 인해 한 OpenStack 서비스의 패키지를 업그레이드하면 다른 OpenStack 서비스를 업그레이드하기 전에 Python 라이브러리가 업그레이드될 수 있습니다. 이로 인해 특정 서비스가 조기에 실패할 수 있습니다. 이 경우 나머지 서비스를 계속 업그레이드합니다. 이 시나리오가 완료되면 모든 서비스가 작동되어야 합니다.
이 방법은 컴퓨팅 노드를 가져오기 위해 추가 하드웨어 리소스가 필요할 수 있습니다.
이 장의 절차는 아키텍처 이름 지정 규칙에 따라 모든 Red Hat OpenStack Platform 설명서를 따릅니다. 이 규칙에 익숙하지 않은 경우 진행하기 전에 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 아키텍처 가이드를 참조하십시오.
5.1. 사전 업그레이드 작업
각 노드에서 subscription-manager
명령을 사용하여 Red Hat OpenStack Platform 8 리포지토리로 변경합니다.
# subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms # subscription-manager repos --enable=rhel-7-server-openstack-8-rpms
openstack-selinux
패키지를 업그레이드합니다.
# yum upgrade openstack-selinux
이는 SELinux가 활성화된 시스템에서 업그레이드된 서비스가 올바르게 실행되도록 하는 데 필요합니다.
5.2. Identity(keystone) 및 대시보드(horizon) 업그레이드
ID 서비스 및 대시보드 서비스를 비활성화합니다. 구성에 따라 다음 중 하나가 포함됩니다.
대시보드 및 ID 서비스가 모두 WSGI applets로 실행되는 경우
httpd
비활성화:# systemctl stop httpd
별도의 서비스로 실행되는 경우 ID 서비스에 대해
openstack-keystone
를 비활성화한 다음 대시보드에 대해httpd
를 비활성화합니다.# openstack-service stop keystone # systemctl stop httpd
두 서비스의 패키지를 업데이트합니다.
# yum -d1 -y upgrade \*keystone\* # yum -y upgrade \*horizon\* \*openstack-dashboard\* # yum -d1 -y upgrade \*horizon\* \*python-django\*
ID 서비스의 토큰 테이블에 만료된 항목이 많이 있을 수 있습니다. 이렇게 하면 데이터베이스 스키마 업그레이드를 완료하는 데 걸리는 시간이 크게 증가할 수 있습니다. 데이터베이스에서 만료된 토큰을 플러시하고 문제를 완화하려면 ID 데이터베이스 업그레이드를 실행하기 전에 keystone-manage
명령을 사용할 수 있습니다.
# keystone-manage token_flush # openstack-db --service keystone --update
이는 데이터베이스에서 만료된 토큰을 플러시합니다. cron
을 사용하여 이 명령을 주기적으로 실행할 수 있습니다.
서비스를 다시 시작합니다. 구성에 따라 다음 중 하나가 포함됩니다.
대시보드 및 ID 서비스가 모두 WSGI applets로 실행되는 경우
httpd
활성화:# systemctl start httpd
별도의 서비스로 실행되는 경우 ID 서비스에 대해
openstack-keystone
를 활성화한 다음 대시보드에 대해httpd
를 비활성화합니다.# openstack-service start keystone # systemctl start httpd
5.3. Object Storage(swift) 업그레이드
오브젝트 스토리지 호스트에서 다음을 실행합니다.
# openstack-service stop swift # yum -d1 -y upgrade \*swift\* # openstack-service start swift
5.4. Image 서비스 업그레이드(glance)
이미지 서비스 호스트에서 다음을 실행합니다.
# openstack-service stop glance # yum -d1 -y upgrade \*glance\* # openstack-db --service glance --update # openstack-service start glance
5.5. Block Storage(cinder) 업그레이드
블록 스토리지 호스트에서 다음을 실행합니다.
# openstack-service stop cinder # yum -d1 -y upgrade \*cinder\* # openstack-db --service cinder --update # openstack-service start cinder
5.6. 오케스트레이션 업그레이드(heat)
오케스트레이션 호스트에서 다음을 실행합니다.
# openstack-service stop heat # yum -d1 -y upgrade \*heat\* # openstack-db --service heat --update # openstack-service start heat
5.7. Telemetry 업그레이드(ceilometer)
Telemetry 구성 요소 서비스를 호스팅하는 모든 노드에서 다음을 실행합니다.
# openstack-service stop ceilometer # yum -d1 -y upgrade \*ceilometer\*
데이터베이스가 설치된 컨트롤러 노드에서 다음을 실행합니다.
# ceilometer-dbsync
패키지 업그레이드를 완료한 후 Telemetry 구성 요소 서비스를 호스팅하는 모든 노드에서 다음 명령을 실행하여 Telemetry 서비스를 다시 시작합니다.
# openstack-service start ceilometer
5.8. 컴퓨팅 업그레이드 (nova)
컴퓨팅 호스트의 롤링 업그레이드를 수행하는 경우 해당 환경의 호환성을 보장하기 위해 명시적 API 버전 제한을 설정해야 합니다.
컨트롤러 또는 컴퓨팅 노드에서 컴퓨팅 서비스를 시작하기 전에
nova.conf
의[upgrade_levels]
섹션에서compute
옵션을 이전 Red Hat OpenStack Platform 버전(kilo
)으로 설정합니다.# crudini --set /etc/nova/nova.conf upgrade_levels compute kilo
컨트롤러 및 컴퓨팅 노드에서 이러한 변경을 수행해야 합니다.
모든 컴퓨팅 노드를 업그레이드한 후 이 작업을 실행 취소해야 합니다.
컴퓨팅 호스트에서 다음을 실행합니다.
# openstack-service stop nova # yum -d1 -y upgrade \*nova\* # openstack-db --service nova --update
모든 호스트를 업그레이드한 후 이전 단계에서 구성한 API 제한을 제거해야 합니다. 모든 호스트에서 다음을 수행합니다.
# crudini --del /etc/nova/nova.conf upgrade_levels compute
모든 컨트롤러 및 컴퓨팅 노드에서 Compute 서비스를 다시 시작합니다.
# openstack-service start nova
5.9. OpenStack Networking 업그레이드(neutron)
OpenStack Networking 호스트에서 다음을 실행합니다.
# openstack-service stop neutron # yum -d1 -y upgrade \*neutron\* # openstack-db --service neutron --update
OpenStack Networking 서비스를 다시 시작합니다.
# openstack-service start neutron
5.10. 업그레이드 후 작업
개별 서비스 업그레이드를 모두 완료한 후에는 모든 시스템에서 전체 패키지 업그레이드를 수행해야 합니다.
# yum upgrade
이렇게 하면 모든 패키지가 최신 상태인지 확인합니다. 실행 중인 모든 프로세스가 기본 바이너리의 업데이트된 버전을 사용하고 있는지 확인하기 위해 향후 OpenStack 호스트 재시작을 예약할 수 있습니다.
생성된 구성 파일을 검토합니다. 업그레이드된 패키지는 Red Hat OpenStack Platform 8 버전의 서비스에 적합한 .rpmnew
파일을 설치합니다.
새로운 버전의 OpenStack 서비스는 특정 구성 옵션을 사용 중단시킬 수 있습니다. 또한 향후 업그레이드 중에 문제가 발생할 수 있으므로 사용 중단 경고에 대한 OpenStack 로그를 검토해야 합니다. 각 서비스에 대한 새로운 업데이트 및 더 이상 사용되지 않는 구성 옵션에 대한 자세한 내용은 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 구성 참조를 참조하십시오.
6장. 직접 이외의 환경: 고가용성 환경에서 개별 OpenStack 서비스 업그레이드(Live Compute)
이 장에서는 HA(고가용성) 환경에서 실시간 컴퓨팅을 사용하여 한 번에 하나의 서비스를 업데이트하여 클라우드 배포를 업그레이드하기 위해 수행해야 하는 단계를 설명합니다. 이 시나리오는 director를 사용하지 않는 환경에서 Red Hat OpenStack Platform 7에서 Red Hat OpenStack Platform 8로 업그레이드합니다.
실시간 컴퓨팅 업그레이드로 소규모 서비스의 경우 단 몇 분, 새로 업그레이드된 Compute 호스트로 이동하는 워크로드의 마이그레이션 간격을 몇 분만 사용하여 Compute 서비스에 대한 중단을 최소화합니다. 기존 워크로드는 무기한 실행될 수 있으며 데이터베이스 마이그레이션을 기다릴 필요가 없습니다.
특정 패키지 종속 항목으로 인해 한 OpenStack 서비스의 패키지를 업그레이드하면 다른 OpenStack 서비스를 업그레이드하기 전에 Python 라이브러리가 업그레이드될 수 있습니다. 이로 인해 특정 서비스가 조기에 실패할 수 있습니다. 이 경우 나머지 서비스를 계속 업그레이드합니다. 이 시나리오가 완료되면 모든 서비스가 작동되어야 합니다.
이 방법을 사용하려면 Red Hat OpenStack Platform 8 컴퓨팅 노드를 가져오려면 추가 하드웨어 리소스가 필요할 수 있습니다.
이 장의 절차는 아키텍처 이름 지정 규칙에 따라 모든 Red Hat OpenStack Platform 설명서를 따릅니다. 이 규칙에 익숙하지 않은 경우 진행하기 전에 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 아키텍처 가이드를 참조하십시오.
6.1. 사전 업그레이드 작업
각 노드에서 subscription-manager
명령을 사용하여 Red Hat OpenStack Platform 8 리포지토리로 변경합니다.
# subscription-manager repos --disable=rhel-7-server-openstack-7.0-rpms # subscription-manager repos --enable=rhel-7-server-openstack-8-rpms
openstack-selinux
패키지를 업그레이드합니다.
# yum upgrade openstack-selinux
이는 SELinux가 활성화된 시스템에서 업그레이드된 서비스가 올바르게 실행되도록 하는 데 필요합니다.
6.2. MariaDB 업그레이드
MariaDB를 실행하는 각 호스트에서 다음 단계를 수행합니다. 다른 호스트에서 프로세스를 시작하기 전에 한 호스트의 단계를 완료합니다.
로컬 노드에서 서비스 실행을 중지합니다.
# pcs resource ban galera-master $(crm_node -n)
pcs status
가 서비스가 로컬 노드에서 더 이상 실행되지 않음을 표시할 때까지 기다립니다. 이 작업은 몇 분 정도 걸릴 수 있습니다. 로컬 노드는 슬레이브 모드로 전환됩니다.Master/Slave Set: galera-master [galera] Masters: [ overcloud-controller-1 overcloud-controller-2 ] Slaves: [ overcloud-controller-0 ]
결국 노드가 중지됨으로 전환됩니다.
Master/Slave Set: galera-master [galera] Masters: [ overcloud-controller-1 overcloud-controller-2 ] Stopped: [ overcloud-controller-0 ]
관련 패키지를 업그레이드합니다.
# yum upgrade '*mariadb*' '*galera*'
Pacemaker에서 로컬 노드에
galera
리소스를 예약할 수 있도록 허용합니다.# pcs resource clear galera-master
pcs 상태가
galera 리소스가 로컬 노드에서 마스터로 실행 중임을 표시할 때까지 기다립니다.pcs status
명령은 다음과 유사한 출력을 제공해야 합니다.Master/Slave Set: galera-master [galera] Masters: [ overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ]
MariaDB 클러스터가 전체 업그레이드가 완료될 때까지 각 노드에서 개별적으로 이 절차를 수행합니다.
6.3. MongoDB 업그레이드
이 절차에서는 OpenStack Telemetry 서비스의 backend 데이터베이스 역할을 하는 MongoDB를 업그레이드합니다.
Pacemaker의 제어에서
mongod
리소스를 제거합니다.# pcs resource unmanage mongod-clone
모든 컨트롤러 노드에서 서비스를 중지합니다. 각 컨트롤러 노드에서 다음을 실행합니다.
# systemctl stop mongod
관련 패키지를 업그레이드합니다.
# yum upgrade 'mongodb*' 'python-pymongo*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
각 컨트롤러에서 을 실행하여 컨트롤러에서
mongod
서비스를 다시 시작합니다.# systemctl start mongod
Pacemaker 제어에 대한 리소스를 정리합니다.
# pcs resource cleanup mongod-clone
리소스를 Pacemaker 제어로 반환합니다.
# pcs resource manage mongod-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.4. ID 서비스 업그레이드(keystone)
이 절차에서는 모든 컨트롤러 노드에서 ID 서비스의 패키지를 동시에 업그레이드합니다.
Pacemaker의 제어에서 ID 서비스를 제거합니다.
# pcs resource unmanage openstack-keystone-clone
각 컨트롤러 노드에서 다음을 실행하여 ID 서비스를 중지합니다.
# systemctl stop openstack-keystone
관련 패키지를 업그레이드합니다.
# yum upgrade 'openstack-keystone*' 'python-keystone*'
systemd
를 다시 로드하여 각 컨트롤러 노드에서 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
이전 버전의 설치 프로그램에서 만료된 Keystone 토큰을 자동으로 제거하도록 시스템을 구성하지 못할 수 있습니다. 토큰 테이블에 만료된 항목이 많이 있을 수 있습니다. 이렇게 하면 데이터베이스 스키마 업그레이드를 완료하는 데 걸리는 시간이 크게 증가할 수 있습니다.
데이터베이스에서 만료된 토큰을 플러시하여 문제를 완화합니다. Identity 데이터베이스 업그레이드를 실행하기 전에
keystone-manage
명령을 실행합니다.# keystone-manage token_flush
이는 데이터베이스에서 만료된 토큰을 플러시합니다.
cron
을 사용하여 이 명령을 주기적으로(예: 매일) 실행할 수 있습니다.ID 서비스 데이터베이스 스키마를 업데이트합니다.
# openstack-db --service keystone --update
각 컨트롤러 노드에서 다음을 실행하여 서비스를 다시 시작합니다.
# systemctl start openstack-keystone
Pacemaker를 사용하여 ID 서비스를 정리합니다.
# pcs resource cleanup openstack-keystone-clone
리소스를 Pacemaker 제어로 반환합니다.
# pcs resource manage openstack-keystone-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.5. Image 서비스 업그레이드(glance)
이 절차에서는 모든 컨트롤러 노드에서 이미지 서비스에 대한 패키지를 동시에 업그레이드합니다.
Pacemaker에서 이미지 서비스 리소스를 중지합니다.
# pcs resource disable openstack-glance-registry-clone # pcs resource disable openstack-glance-api-clone
-
pcs status
의 출력에 두 서비스 모두 실행을 중지할 때까지 기다립니다. 관련 패키지를 업그레이드합니다.
# yum upgrade 'openstack-glance*' 'python-glance*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
이미지 서비스 데이터베이스 스키마를 업데이트합니다.
# openstack-db --service glance --update
Pacemaker를 사용하여 이미지 서비스를 정리합니다.
# pcs resource cleanup openstack-glance-api-clone # pcs resource cleanup openstack-glance-registry-clone
Pacemaker에서 이미지 서비스 리소스를 다시 시작합니다.
# pcs resource enable openstack-glance-api-clone # pcs resource enable openstack-glance-registry-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.6. Block Storage 서비스(cinder) 업그레이드
이 절차에서는 모든 컨트롤러 노드에서 블록 스토리지 서비스의 패키지를 동시에 업그레이드합니다.
Pacemaker에서 모든 블록 스토리지 서비스 리소스를 중지합니다.
# pcs resource disable openstack-cinder-api-clone # pcs resource disable openstack-cinder-scheduler-clone # pcs resource disable openstack-cinder-volume
-
pcs status
의 출력에 위의 서비스가 실행을 중지했을 때까지 기다립니다. 관련 패키지를 업그레이드합니다.
# yum upgrade 'openstack-cinder*' 'python-cinder*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
블록 스토리지 서비스 데이터베이스 스키마를 업데이트합니다.
# openstack-db --service cinder --update
Pacemaker를 사용하여 Block Storage 서비스를 정리합니다.
# pcs resource cleanup openstack-cinder-volume # pcs resource cleanup openstack-cinder-scheduler-clone # pcs resource cleanup openstack-cinder-api-clone
Pacemaker에서 모든 블록 스토리지 서비스 리소스를 다시 시작합니다.
# pcs resource enable openstack-cinder-volume # pcs resource enable openstack-cinder-scheduler-clone # pcs resource enable openstack-cinder-api-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.7. 오케스트레이션 업그레이드(heat)
이 절차에서는 모든 컨트롤러 노드에서 오케스트레이션 서비스의 패키지를 동시에 업그레이드합니다.
Pacemaker에서 오케스트레이션 리소스를 중지합니다.
# pcs resource disable openstack-heat-api-clone # pcs resource disable openstack-heat-api-cfn-clone # pcs resource disable openstack-heat-api-cloudwatch-clone # pcs resource disable openstack-heat-engine-clone
-
pcs status
의 출력에 위의 서비스가 실행을 중지했을 때까지 기다립니다. 관련 패키지를 업그레이드합니다.
# yum upgrade 'openstack-heat*' 'python-heat*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
오케스트레이션 데이터베이스 스키마를 업데이트합니다.
# openstack-db --service heat --update
Pacemaker를 사용하여 오케스트레이션 서비스를 정리합니다.
# pcs resource cleanup openstack-heat-clone # pcs resource cleanup openstack-heat-api-cloudwatch-clone # pcs resource cleanup openstack-heat-api-cfn-clone # pcs resource cleanup openstack-heat-api-clone
Pacemaker에서 오케스트레이션 리소스를 다시 시작합니다.
# pcs resource enable openstack-heat-clone # pcs resource enable openstack-heat-api-cloudwatch-clone # pcs resource enable openstack-heat-api-cfn-clone # pcs resource enable openstack-heat-api-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.8. Telemetry 업그레이드(ceilometer)
이 절차에서는 모든 컨트롤러 노드에서 Telemetry 서비스의 패키지를 동시에 업그레이드합니다.
Pacemaker에서 모든 Telemetry 리소스를 중지합니다.
# pcs resource disable openstack-ceilometer-central # pcs resource disable openstack-ceilometer-api-clone # pcs resource disable openstack-ceilometer-alarm-evaluator-clone # pcs resource disable openstack-ceilometer-collector-clone # pcs resource disable openstack-ceilometer-notification-clone # pcs resource disable openstack-ceilometer-alarm-notifier-clone # pcs resource disable delay-clone
-
pcs status
의 출력에 위의 서비스가 실행을 중지했을 때까지 기다립니다. 관련 패키지를 업그레이드합니다.
# yum upgrade 'openstack-ceilometer*' 'python-ceilometer*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
다음 명령을 사용하여 Telemetry 데이터베이스 스키마를 업데이트합니다.
# ceilometer-dbsync
Pacemaker를 사용하여 Telemetry 서비스를 정리합니다.
# pcs resource cleanup delay-clone # pcs resource cleanup openstack-ceilometer-alarm-notifier-clone # pcs resource cleanup openstack-ceilometer-notification-clone # pcs resource cleanup openstack-ceilometer-collector-clone # pcs resource cleanup openstack-ceilometer-alarm-evaluator-clone # pcs resource cleanup openstack-ceilometer-api-clone # pcs resource cleanup openstack-ceilometer-central
Pacemaker에서 모든 Telemetry 리소스를 다시 시작합니다.
# pcs resource enable delay-clone # pcs resource enable openstack-ceilometer-alarm-notifier-clone # pcs resource enable openstack-ceilometer-notification-clone # pcs resource enable openstack-ceilometer-collector-clone # pcs resource enable openstack-ceilometer-alarm-evaluator-clone # pcs resource enable openstack-ceilometer-api-clone # pcs resource enable openstack-ceilometer-central
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
이전 버전의 Telemetry 서비스에서 더 이상 사용되지 않는 rpc_backend
매개변수 값을 사용했습니다. /etc/ceilometer/ceilometer.conf
파일에서 rpc_backend
매개변수가 다음으로 설정되어 있는지 확인합니다.
rpc_backend=rabbit
6.9. 컨트롤러 노드에서 Compute 서비스(nova) 업그레이드
이 절차에서는 모든 컨트롤러 노드에서 컴퓨팅 서비스의 패키지를 동시에 업그레이드합니다.
Pacemaker에서 모든 컴퓨팅 리소스를 중지합니다.
# pcs resource disable openstack-nova-novncproxy-clone # pcs resource disable openstack-nova-consoleauth-clone # pcs resource disable openstack-nova-conductor-clone # pcs resource disable openstack-nova-api-clone # pcs resource disable openstack-nova-scheduler-clone
-
pcs status
의 출력에 위의 서비스가 실행을 중지했을 때까지 기다립니다. 관련 패키지를 업그레이드합니다.
# yum upgrade 'openstack-nova*' 'python-nova*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
Compute 데이터베이스 스키마를 업데이트합니다.
# openstack-db --service nova --update
컴퓨팅 호스트의 롤링 업그레이드를 수행하는 경우 Kilo와 Liberty 환경 간의 호환성을 보장하기 위해 명시적 API 버전 제한을 설정해야 합니다.
컨트롤러 또는 컴퓨팅 노드에서 컴퓨팅 서비스를 시작하기 전에
nova.conf
의[upgrade_levels]
섹션에서compute
옵션을 이전 Red Hat OpenStack Platform 버전(kilo
)으로 설정합니다.# crudini --set /etc/nova/nova.conf upgrade_levels compute kilo
이렇게 하면 컨트롤러 노드가 이전 버전을 계속 사용하는 컴퓨팅 노드와 계속 통신할 수 있습니다.
먼저 하나의 컨트롤러 노드에서
pcs resource unmanage
를 실행하여 컴퓨팅 리소스 관리를 해제해야 합니다.# pcs resource unmanage openstack-nova-novncproxy-clone # pcs resource unmanage openstack-nova-consoleauth-clone # pcs resource unmanage openstack-nova-conductor-clone # pcs resource unmanage openstack-nova-api-clone # pcs resource unmanage openstack-nova-scheduler-clone
모든 컨트롤러에서 모든 서비스를 다시 시작합니다.
# openstack-service restart nova
모든 컴퓨팅 호스트를 OpenStack Liberty로 업그레이드한 후 Pacemaker로 제어를 반환해야 합니다.
# pcs resource manage openstack-nova-scheduler-clone # pcs resource manage openstack-nova-api-clone # pcs resource manage openstack-nova-conductor-clone # pcs resource manage openstack-nova-consoleauth-clone # pcs resource manage openstack-nova-novncproxy-clone
Pacemaker에서 모든 컴퓨팅 리소스를 정리합니다.
# pcs resource cleanup openstack-nova-scheduler-clone # pcs resource cleanup openstack-nova-api-clone # pcs resource cleanup openstack-nova-conductor-clone # pcs resource cleanup openstack-nova-consoleauth-clone # pcs resource cleanup openstack-nova-novncproxy-clone
Pacemaker에서 모든 컴퓨팅 리소스를 다시 시작합니다.
# pcs resource enable openstack-nova-scheduler-clone # pcs resource enable openstack-nova-api-clone # pcs resource enable openstack-nova-conductor-clone # pcs resource enable openstack-nova-consoleauth-clone # pcs resource enable openstack-nova-novncproxy-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.10. OpenStack Networking 업그레이드(neutron)
이 절차에서는 모든 컨트롤러 노드에서 네트워킹 서비스의 패키지를 동시에 업그레이드합니다.
Pacemaker에서 OpenStack Networking 정리 스크립트를 트리거하지 않도록 합니다.
# pcs resource unmanage neutron-ovs-cleanup-clone # pcs resource unmanage neutron-netns-cleanup-clone
Pacemaker에서 OpenStack Networking 리소스를 중지합니다.
# pcs resource disable neutron-server-clone # pcs resource disable neutron-openvswitch-agent-clone # pcs resource disable neutron-dhcp-agent-clone # pcs resource disable neutron-l3-agent-clone # pcs resource disable neutron-metadata-agent-clone
관련 패키지 업그레이드
# yum upgrade 'openstack-neutron*' 'python-neutron*'
neutron.conf
파일에서 활성화된 고급 Openstack Networking 서비스용 패키지를 설치합니다. 예를 들어openstack-neutron-vpnaas
,openstack-neutron-fwaas
및openstack-neutron-lbaas
서비스를 업그레이드하려면 다음을 수행합니다.# yum install openstack-neutron-vpnaas # yum install openstack-neutron-fwaas # yum install openstack-neutron-lbaas
이러한 패키지를 설치하면 해당 구성 파일이 생성됩니다.
VPNaaS의 경우
neutron.conf
파일의 LBaaS 서비스 항목을 service_provider 항목을/etc/neutron
에 있는 해당neutron-*aas.conf
파일에 복사하고neutron.conf
파일에서 이러한 항목을 주석 처리합니다.FWaaS 서비스 항목의 경우
service_provider
매개 변수는neutron.conf
파일에 남아 있어야 합니다.LBaaS 에이전트를 실행하는 모든 노드에서
openstack-neutron-lbaas
패키지를 설치합니다.# yum install openstack-neutron-lbaas
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
OpenStack Networking 데이터베이스 스키마를 업데이트합니다.
# openstack-db --service neutron --update
Pacemaker에서 OpenStack Networking 리소스를 정리합니다.
# pcs resource cleanup neutron-metadata-agent-clone # pcs resource cleanup neutron-l3-agent-clone # pcs resource cleanup neutron-dhcp-agent-clone # pcs resource cleanup neutron-openvswitch-agent-clone # pcs resource cleanup neutron-server-clone
Pacemaker에서 OpenStack Networking 리소스를 다시 시작합니다.
# pcs resource enable neutron-metadata-agent-clone # pcs resource enable neutron-l3-agent-clone # pcs resource enable neutron-dhcp-agent-clone # pcs resource enable neutron-openvswitch-agent-clone # pcs resource enable neutron-server-clone
정리 에이전트를 Pacemaker 제어로 반환합니다.
# pcs resource manage neutron-ovs-cleanup-clone # pcs resource manage neutron-netns-cleanup-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.11. 대시보드 업그레이드(horizon)
이 절차에서는 모든 컨트롤러 노드에서 동시에 대시보드 패키지를 업그레이드합니다.
Pacemaker에서 대시보드 리소스를 중지합니다.
# pcs resource disable httpd-clone
-
pcs status
의 출력에 서비스 실행이 중지될 때까지 기다립니다. 관련 패키지를 업그레이드합니다.
# yum upgrade httpd 'openstack-dashboard*' 'python-django*'
systemd
를 다시 로드하여 업데이트된 장치 파일을 고려합니다.# systemctl daemon-reload
모든 컨트롤러에서 웹 서버를 다시 시작하여 모든 변경 사항을 적용합니다.
# service httpd restart
Pacemaker에서 대시보드 리소스를 정리합니다.
# pcs resource cleanup httpd-clone
Pacemaker에서 대시보드 리소스를 다시 시작합니다.
# pcs resource enable httpd-clone
-
pcs status
의 출력에 위의 리소스가 실행 중임을 표시할 때까지 기다립니다.
6.12. 컴퓨팅 (nova) 노드 업그레이드
이 절차에서는 단일 컴퓨팅 노드에서 패키지를 업그레이드합니다. 각 컴퓨팅 노드에서 다음 절차를 개별적으로 실행합니다.
컴퓨팅 호스트의 롤링 업그레이드를 수행하는 경우 Kilo와 Liberty 환경 간의 호환성을 보장하기 위해 명시적 API 버전 제한을 설정해야 합니다.
컨트롤러 또는 컴퓨팅 노드에서 컴퓨팅 서비스를 시작하기 전에 nova.conf
의 [upgrade_levels]
섹션에서 compute
옵션을 이전 Red Hat OpenStack Platform 버전(kilo
)으로 설정합니다.
# crudini --set /etc/nova/nova.conf upgrade_levels compute kilo
이렇게 하면 컨트롤러 노드가 이전 버전을 계속 사용하는 컴퓨팅 노드와 계속 통신할 수 있습니다.
호스트에서 모든 OpenStack 서비스를 중지합니다.
# openstack-service stop
모든 패키지를 업그레이드하십시오.
# yum upgrade
호스트에서 모든 openstack 서비스를 시작합니다.
# openstack-service start
모든 호스트를 업그레이드한 후 이전 단계에서 구성한 API 제한을 제거합니다. 모든 호스트에서 다음을 수행합니다.
# crudini --del /etc/nova/nova.conf upgrade_levels compute
호스트에서 모든 openstack 서비스를 다시 시작하십시오.
# openstack-service restart
6.13. 업그레이드 후 작업
개별 서비스 업그레이드를 모두 완료한 후에는 모든 노드에서 전체 패키지 업그레이드를 수행해야 합니다.
# yum upgrade
이렇게 하면 모든 패키지가 최신 상태인지 확인합니다. 실행 중인 모든 프로세스가 기본 바이너리의 업데이트된 버전을 사용하고 있는지 확인하기 위해 향후 OpenStack 호스트 재시작을 예약할 수 있습니다.
생성된 구성 파일을 검토합니다. 업그레이드된 패키지는 Red Hat OpenStack Platform 8 버전의 서비스에 적합한 .rpmnew
파일을 설치합니다.
새로운 버전의 OpenStack 서비스는 특정 구성 옵션을 사용 중단시킬 수 있습니다. 또한 향후 업그레이드 중에 문제가 발생할 수 있으므로 사용 중단 경고에 대한 OpenStack 로그를 검토해야 합니다. 각 서비스에 대한 새로운 업데이트 및 더 이상 사용되지 않는 구성 옵션에 대한 자세한 내용은 Red Hat OpenStack Platform Documentation Suite 에서 제공되는 구성 참조를 참조하십시오.
7장. Director 기반 업그레이드 문제 해결
이 섹션에서는 두 가지 문제 해결에 대한 조언을 제공합니다.
7.1. 언더클라우드 업그레이드
Undercloud 업그레이드 명령(openstack undercloud upgrade
)이 실패하는 경우 다음 지침을 사용하여 업그레이드 차단 진행 상황을 확인하십시오.
-
openstack undercloud upgrade
명령은 실행되는 동안 진행률 로그를 출력합니다. 업그레이드 프로세스의 어느 시점에서 오류가 발생하면 명령이 오류 발생 시점에서 중지됩니다. 이 정보를 사용하여 업그레이드 진행 상황을 방해하는 문제를 식별합니다. openstack undercloud upgrade
명령은 Puppet을 실행하여 Undercloud 서비스를 구성합니다. 이렇게 하면 다음 디렉터리에 유용한 Puppet 보고서가 생성됩니다.-
/var/lib/puppet/state/last_run_report.yaml
- Undercloud에 대해 생성된 마지막 Puppet 보고서입니다. 이 파일은 실패한 Puppet 작업의 원인을 보여줍니다. -
/var/lib/puppet/state/last_run_summary.yaml
-last_run_report.yaml
파일에 대한 요약입니다. /var/lib/puppet/reports
- Undercloud에 대한 모든 Puppet 보고서입니다.이 정보를 사용하여 업그레이드 진행 상황을 방해하는 문제를 식별합니다.
-
실패한 서비스를 확인합니다.
$ sudo systemctl -t service
서비스가 실패한 경우 해당 로그를 확인합니다. 예를 들어
openstack-ironic-api
가 실패한 경우 다음 명령을 사용하여 해당 서비스의 로그를 확인합니다.$ sudo journalctl -xe -u openstack-ironic-api $ sudo tail -n 50 /var/log/ironic/ironic-api.log
Undercloud 업그레이드를 방해하는 문제를 수정한 후 upgrade 명령을 재실행합니다.
$ openstack undercloud upgrade
업그레이드 명령이 다시 시작되고 Undercloud를 구성합니다.
7.2. 오버클라우드 업그레이드
Overcloud 업그레이드 프로세스가 실패하는 경우 다음 조언을 사용하여 업그레이드 진행 상황을 차단하는 문제를 찾습니다.
Heat 스택 목록을 확인하고
UPDATE_FAILED
상태의 스택을 식별합니다. 다음 명령은 다음 스택을 식별합니다.$ heat stack-list --show-nested | awk -F "|" '{ print $3,$4 }' | grep "UPDATE_FAILED" | column -t
실패한 스택 및 해당 템플릿을 보고 스택 실패 방법을 확인합니다.
$ heat stack-show overcloud-Controller-qyoy54dyhrll-1-gtwy5bgta3np $ heat template-show overcloud-Controller-qyoy54dyhrll-1-gtwy5bgta3np
모든 컨트롤러 노드에서 Pacemaker가 올바르게 실행되고 있는지 확인합니다. 필요한 경우 컨트롤러 노드에 로그인하고 컨트롤러 클러스터를 다시 시작합니다.
$ sudo pcs cluster start
Overcloud 업그레이드를 방해하는 문제를 수정한 후 시도한 실패한 업그레이드 단계에 대해 openstack overcloud deploy
명령을 재실행합니다. 다음은 업그레이드 프로세스의 첫 번째 openstack overcloud deploy
명령의 예입니다. 이 명령은 major-upgrade-pacemaker-init.yaml
을 포함합니다.
$ openstack overcloud deploy --templates \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \ -e network_env.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/major-upgrade-pacemaker-init.yaml
openstack overcloud deploy
는 Overcloud 스택 업데이트를 다시 시도합니다.