16.3. 컴퓨팅 노드 간 가상 머신 인스턴스 마이그레이션
오버클라우드의 한 컴퓨팅 노드에서 다른 컴퓨팅 노드로 인스턴스를 마이그레이션하여 유지보수를 수행하거나 워크로드를 리밸런스하거나 장애가 발생한 노드를 교체해야 하는 경우가 있습니다.
- 컴퓨팅 노드 유지보수
- 예를 들어 하드웨어 유지 관리 또는 복구, 커널 업그레이드 및 소프트웨어 업데이트를 수행하기 위해 Compute 노드를 일시적으로 사용해야 하는 경우 컴퓨팅 노드에서 실행 중인 인스턴스를 다른 컴퓨팅 노드로 마이그레이션할 수 있습니다.
- 컴퓨팅 노드 실패
- 컴퓨팅 노드에 오류가 발생하고 서비스를 제공하거나 교체해야 하는 경우 실패한 컴퓨팅 노드에서 정상적인 컴퓨팅 노드로 인스턴스를 마이그레이션할 수 있습니다.
- 실패한 컴퓨팅 노드
- 컴퓨팅 노드가 이미 실패하면 인스턴스를 비울 수 있습니다. 동일한 이름, UUID, 네트워크 주소 및 컴퓨팅 노드가 실패하기 전에 할당된 기타 리소스를 사용하여 다른 컴퓨팅 노드의 원래 이미지에서 인스턴스를 다시 빌드할 수 있습니다.
- 워크로드 리밸런싱
- 하나 이상의 인스턴스를 다른 컴퓨팅 노드로 마이그레이션하여 워크로드를 리밸런싱할 수 있습니다. 예를 들어 컴퓨팅 노드의 인스턴스를 통합하여 전원을 절약하고, 인스턴스를 다른 네트워크 리소스에 물리적으로 더 가까운 컴퓨팅 노드로 마이그레이션하여 대기 시간을 줄이거나, 인스턴스를 컴퓨팅 노드에 배포하여 핫스팟을 방지하고 복원력을 높일 수 있습니다.
director는 안전한 마이그레이션을 제공하기 위해 모든 컴퓨팅 노드를 구성합니다. 모든 컴퓨팅 노드에는 마이그레이션 프로세스 중 다른 컴퓨팅 노드에 대한 액세스 권한을 각 호스트의 사용자에게 제공하기 위해 공유 SSH 키가 필요합니다. director는 OS::TripleO::Services::NovaCompute
구성 가능 서비스를 사용하여 이 키를 생성합니다. 이 구성 가능 서비스는 기본적으로 모든 계산 역할에 포함된 기본 서비스 중 하나입니다. 자세한 내용은 Advanced Overcloud Customization 가이드의 Composable Services and Custom Roles 를 참조하십시오.
작동 중인 컴퓨팅 노드가 있고 백업 목적으로 인스턴스 사본을 만들거나 인스턴스를 다른 환경에 복사하려는 경우 Director 설치 및 사용 가이드의 오버클라우드로 가상 머신을 가져오는 절차를 따르십시오.
16.3.1. 마이그레이션 유형
RHOSP(Red Hat OpenStack Platform)는 다음과 같은 유형의 마이그레이션을 지원합니다.
콜드 마이그레이션
콜드 마이그레이션 또는 실시간이 아닌 마이그레이션에는 소스 컴퓨팅 노드에서 대상 컴퓨팅 노드로 마이그레이션하기 전에 실행 중인 인스턴스를 종료해야 합니다.
![콜드 마이그레이션](https://access.redhat.com/webassets/avalon/d/Red_Hat_OpenStack_Platform-16.2-Configuring_the_Compute_Service_for_Instance_Creation-ko-KR/images/995977130dc356f1a4a064c93904839e/OpenStack_libvirt_Migration_11_0419_cold.png)
콜드 마이그레이션에는 인스턴스에 다운타임이 있습니다. 마이그레이션된 인스턴스는 동일한 볼륨 및 IP 주소에 대한 액세스를 유지 관리합니다.
콜드 마이그레이션에는 소스 및 대상 컴퓨팅 노드가 모두 실행 중이어야 합니다.
실시간 마이그레이션
실시간 마이그레이션에는 인스턴스를 종료하지 않고 소스 컴퓨팅 노드에서 대상 컴퓨팅 노드로 이동하고 상태 일관성을 유지 관리하는 작업이 포함됩니다.
![실시간 마이그레이션](https://access.redhat.com/webassets/avalon/d/Red_Hat_OpenStack_Platform-16.2-Configuring_the_Compute_Service_for_Instance_Creation-ko-KR/images/a6a65e4da9ec28b3b3c6585983ba3590/OpenStack_libvirt_Migration_11_0419_live.png)
실시간 인스턴스 마이그레이션에는 다운타임이 거의 발생하지 않거나 발생하지 않습니다. 그러나 실시간 마이그레이션은 마이그레이션 작업 기간 동안 성능에 영향을 미칩니다. 따라서 인스턴스를 마이그레이션하는 동안 중요한 경로에서 가져와야 합니다.
실시간 마이그레이션을 수행하려면 소스 및 대상 컴퓨팅 노드가 모두 실행 중이어야 합니다.
경우에 따라 인스턴스는 실시간 마이그레이션을 사용할 수 없습니다. 자세한 내용은 마이그레이션 제한 조건을 참조하십시오.
비우기
소스 컴퓨팅 노드가 이미 실패했으므로 인스턴스를 마이그레이션해야 하는 경우 인스턴스를 비울 수 있습니다.
16.3.2. 마이그레이션 제약 조건
마이그레이션 제한 조건은 일반적으로 블록 마이그레이션, 구성 디스크 또는 하나 이상의 인스턴스가 컴퓨팅 노드의 물리 하드웨어에 액세스하는 경우에 발생합니다.
CPU 제약 조건
소스 및 대상 컴퓨팅 노드에 동일한 CPU 아키텍처가 있어야 합니다. 예를 들어 Red Hat은 x86_64
CPU에서 ppc64le
CPU로 인스턴스 마이그레이션을 지원하지 않습니다.
다른 CPU 모델 간 마이그레이션은 지원되지 않습니다. 경우에 따라 CPU 호스트 패스스루를 사용하는 인스턴스와 같이 소스 및 대상 컴퓨팅 노드의 CPU가 정확히 일치해야 합니다. 모든 경우에 대상 노드의 CPU 기능은 소스 노드의 CPU 기능의 상위 세트여야 합니다.
메모리 제약 조건
대상 컴퓨팅 노드에는 사용 가능한 충분한 RAM이 있어야 합니다. 메모리 초과 서브스크립션으로 인해 마이그레이션이 실패할 수 있습니다.
블록 마이그레이션 제약 조건
컴퓨팅 노드에 로컬로 저장된 디스크를 사용하는 인스턴스를 마이그레이션하는 데 Red Hat Ceph Storage와 같이 공유 스토리지를 사용하는 볼륨 지원 인스턴스를 마이그레이션하는 것보다 시간이 훨씬 오래 걸립니다. 이 대기 시간은 기본적으로 OpenStack Compute(nova)가 컨트롤 플레인 네트워크를 통해 컴퓨팅 노드 간에 블록 단위로 로컬 디스크를 마이그레이션하기 때문에 발생합니다. 반대로, 공유 스토리지를 사용하는 볼륨 기반 인스턴스(예: Red Hat Ceph Storage)는 각 컴퓨팅 노드에서 이미 공유 스토리지에 액세스할 수 있기 때문에 볼륨을 마이그레이션할 필요가 없습니다.
많은 RAM을 사용하는 로컬 디스크 또는 인스턴스를 마이그레이션하여 컨트롤 플레인 네트워크의 네트워크 정체는 RabbitMQ와 같은 컨트롤 플레인 네트워크를 사용하는 다른 시스템의 성능에 영향을 줄 수 있습니다.
읽기 전용 드라이브 마이그레이션 제약 조건
드라이브에 읽기 및 쓰기 기능이 모두 있는 경우에만 드라이브 마이그레이션이 지원됩니다. 예를 들어 OpenStack Compute(nova)는 CD-ROM 드라이브 또는 읽기 전용 구성 드라이브를 마이그레이션할 수 없습니다. 그러나 OpenStack Compute(nova)는 vfat
와 같은 드라이브 형식의 구성 드라이브를 포함하여 읽기 및 쓰기 기능을 모두 사용하여 드라이브를 마이그레이션할 수 있습니다.
실시간 마이그레이션 제약 조건
실시간 마이그레이션 인스턴스에는 추가 제약이 있는 경우도 있습니다.
- 마이그레이션 중에 새 작업 없음
- 소스 및 대상 노드의 인스턴스 복사본 간에 상태 일관성을 달성하려면 RHOSP에서 실시간 마이그레이션 중에 새 작업을 방지해야 합니다. 그렇지 않으면 실시간 마이그레이션에서 메모리 상태를 복제하는 속도보다 메모리에 쓰기 속도가 더 빠르게 발생하는 경우 실시간 마이그레이션에 시간이 오래 걸리거나 잠재적으로 끝나지 않을 수 있습니다.
- NUMA를 사용하여 CPU 고정
-
Compute 구성의
NovaSchedulerDefaultFilters
매개변수에는AggregateInstanceExtraSpecsFilter 및
값이 포함되어야 합니다.NUMATopologyFilter
- 다중 셀 클라우드
- 다중 셀 클라우드에서는 동일한 셀의 다른 호스트로 인스턴스를 실시간으로 마이그레이션할 수 있지만, 셀 간에는 인스턴스를 마이그레이션할 수 없습니다.
- 유동 인스턴스
-
유동 인스턴스를 실시간으로 마이그레이션하는 경우 대상 컴퓨팅 노드의
NovaComputeCpuSharedSet
구성이 소스 컴퓨팅 노드의NovaComputeCpuSharedSet
구성과 다른 경우 대상 컴퓨팅 노드에 공유(고정 해제) 인스턴스에 구성된 CPU에 인스턴스가 할당되지 않습니다. 따라서 유동 인스턴스를 실시간 마이그레이션해야 하는 경우 전용(고정) 및 공유(고정되지 않은) 인스턴스에 대해 동일한 CPU 매핑으로 모든 컴퓨팅 노드를 구성하거나 공유 인스턴스에 호스트 집계를 사용해야 합니다. - 대상 컴퓨팅 노드 용량
- 대상 컴퓨팅 노드에는 마이그레이션할 인스턴스를 호스팅할 충분한 용량이 있어야 합니다.
- SR-IOV 실시간 마이그레이션
- SR-IOV 기반 네트워크 인터페이스가 있는 인스턴스를 실시간 마이그레이션할 수 있습니다. 직접 모드 SR-IOV 네트워크 인터페이스가 있는 실시간 마이그레이션 인스턴스로 인해 네트워크 중단이 발생합니다. 이는 마이그레이션 중에 직접 모드 인터페이스를 분리하고 다시 연결해야 하기 때문입니다.
- ML2/OVN 배포에서 패킷 손실
ML2/OVN은 패킷 손실 없이 실시간 마이그레이션을 지원하지 않습니다. 이는 OVN에서 여러 포트 바인딩을 처리할 수 없기 때문에 포트 마이그레이션 시기를 알 수 없기 때문입니다.
실시간 마이그레이션 중에 패키지 손실을 최소화하려면 마이그레이션이 완료되면 대상 호스트에서 인스턴스를 표시하도록 ML2/OVN 배포를 구성하십시오.
parameter_defaults: ComputeExtraConfig: nova::config::nova_config: workarounds/enable_qemu_monitor_announce_self: value: 'True'
- ML2/OVS 배포에서 실시간 마이그레이션
ML2/OVS 배포에서 실시간 마이그레이션 시 패키지 손실을 최소화하려면 ML2/OVS 배포를 구성하여 Networking 서비스(neutron) 실시간 마이그레이션 이벤트를 활성화하고 마이그레이션이 완료되면 대상 호스트에서 인스턴스를 발표합니다.
parameter_defaults: NetworkExtraConfig: neutron::config::neutron_config: nova/live_migration_events: value: 'True' ComputeExtraConfig: nova::config::nova_config: workarounds/enable_qemu_monitor_announce_self: value: 'True'
실시간 마이그레이션을 방지하는 제약 조건
다음 기능을 사용하는 인스턴스를 실시간 마이그레이션할 수 없습니다.
- PCI 통과
- QEMU/KVM 하이퍼바이저는 컴퓨팅 노드의 PCI 장치를 인스턴스에 연결할 수 있도록 지원합니다. PCI 통과를 사용하여 PCI 장치에 대한 인스턴스 전용 액세스를 제공합니다. PCI 장치는 인스턴스의 운영 체제에 물리적으로 연결된 것처럼 표시되고 작동합니다. 그러나 PCI 통과에는 물리적 장치에 대한 직접 액세스 권한이 필요하기 때문에 QEMU/KVM은 PCI 패스스루를 사용하여 인스턴스의 실시간 마이그레이션을 지원하지 않습니다.
- 포트 리소스 요청
보장된 최소 대역폭 QoS 정책과 같이 리소스 요청이 있는 포트를 사용하는 인스턴스를 실시간 마이그레이션할 수 없습니다. 다음 명령을 사용하여 포트에 리소스 요청이 있는지 확인합니다.
$ openstack port show <port_name/port_id>
16.3.3. 마이그레이션 준비
하나 이상의 인스턴스를 마이그레이션하기 전에 마이그레이션할 인스턴스의 컴퓨팅 노드 이름과 ID를 확인해야 합니다.
절차
소스 컴퓨팅 노드 호스트 이름과 대상 컴퓨팅 노드 호스트 이름을 식별합니다.
(undercloud)$ source ~/overcloudrc (overcloud)$ openstack compute service list
소스 컴퓨팅 노드의 인스턴스를 나열하고 마이그레이션할 인스턴스 또는 인스턴스의 ID를 찾습니다.
(overcloud)$ openstack server list --host <source> --all-projects
<source>
를 소스 컴퓨팅 노드의 이름 또는 ID로 바꿉니다.선택 사항: 노드에서 유지보수를 수행하기 위해 소스 컴퓨팅 노드에서 인스턴스를 마이그레이션하는 경우 스케줄러가 유지보수 중에 새 인스턴스를 노드에 할당하지 않도록 노드를 비활성화해야 합니다.
(overcloud)$ openstack compute service set <source> nova-compute --disable
<source>
를 소스 컴퓨팅 노드의 호스트 이름으로 바꿉니다.
이제 마이그레이션을 수행할 준비가 되었습니다. 인스턴스 또는 라이브 마이그레이션 인스턴스에 대한 자세한 내용은 Cold 마이그레이션에 설명된 필수 절차를 따르십시오.
16.3.4. 인스턴스 콜드 마이그레이션
인스턴스를 콜드 마이그레이션하는 경우 인스턴스를 중지하고 다른 컴퓨팅 노드로 이동합니다. 콜드 마이그레이션은 PCI 통과를 사용하는 인스턴스 마이그레이션과 같이 실시간 마이그레이션이 용이하지 않은 마이그레이션 시나리오에 유용합니다. 스케줄러는 대상 컴퓨팅 노드를 자동으로 선택합니다. 자세한 내용은 마이그레이션 제한 조건을 참조하십시오.
절차
인스턴스를 콜드 마이그레이션하려면 다음 명령을 입력하여 인스턴스의 전원을 끄고 이동합니다.
(overcloud)$ openstack server migrate <instance> --wait
-
<instance>
를 마이그레이션할 인스턴스의 이름 또는 ID로 바꿉니다. -
로컬에 저장된 볼륨을 마이그레이션하는 경우
--block-migration
플래그를 지정합니다.
-
- 마이그레이션이 완료될 때까지 기다립니다. 인스턴스 마이그레이션이 완료될 때까지 기다리는 동안 마이그레이션 상태를 확인할 수 있습니다. 자세한 내용은 마이그레이션 상태 확인 을 참조하십시오.
인스턴스의 상태를 확인합니다.
(overcloud)$ openstack server list --all-projects
"VERIFY_RESIZE" 상태는 마이그레이션을 확인하거나 되돌려야 함을 나타냅니다.
마이그레이션이 예상대로 작동된 경우 이를 확인합니다.
(overcloud)$ openstack server resize --confirm <instance>
<instance>
를 마이그레이션할 인스턴스의 이름 또는 ID로 바꿉니다. "ACTIVE" 상태는 인스턴스가 사용할 준비가 되었음을 나타냅니다.마이그레이션이 예상대로 작동하지 않으면 이를 되돌립니다.
(overcloud)$ openstack server resize --revert <instance>
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다.
인스턴스를 다시 시작하십시오.
(overcloud)$ openstack server start <instance>
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다.선택 사항: 유지보수를 위해 소스 컴퓨팅 노드를 비활성화한 경우 새 인스턴스를 할당할 수 있도록 노드를 다시 활성화해야 합니다.
(overcloud)$ openstack compute service set <source> nova-compute --enable
<source>
를 소스 컴퓨팅 노드의 호스트 이름으로 바꿉니다.
16.3.5. 인스턴스 실시간 마이그레이션
실시간 마이그레이션은 다운타임을 최소화하여 소스 컴퓨팅 노드에서 대상 컴퓨팅 노드로 인스턴스를 이동합니다. 실시간 마이그레이션이 모든 인스턴스에 적합하지 않을 수 있습니다. 자세한 내용은 마이그레이션 제한 조건을 참조하십시오.
절차
인스턴스를 실시간 마이그레이션하려면 인스턴스 및 대상 컴퓨팅 노드를 지정합니다.
(overcloud)$ openstack server migrate <instance> --live-migration [--host <dest>] --wait
-
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다. <dest>
를 대상 컴퓨팅 노드의 이름 또는 ID로 바꿉니다.참고openstack server migrate
명령은 기본 공유 스토리지로 인스턴스를 마이그레이션하는 작업을 다룹니다. 로컬에 저장된 볼륨을 마이그레이션하려면--block-migration
플래그를 지정합니다.(overcloud)$ openstack server migrate <instance> --live-migration [--host <dest>] --wait --block-migration
-
인스턴스가 마이그레이션 중인지 확인합니다.
(overcloud)$ openstack server show <instance> +----------------------+--------------------------------------+ | Field | Value | +----------------------+--------------------------------------+ | ... | ... | | status | MIGRATING | | ... | ... | +----------------------+--------------------------------------+
- 마이그레이션이 완료될 때까지 기다립니다. 인스턴스 마이그레이션이 완료될 때까지 기다리는 동안 마이그레이션 상태를 확인할 수 있습니다. 자세한 내용은 마이그레이션 상태 확인 을 참조하십시오.
인스턴스의 상태를 확인하여 마이그레이션에 성공했는지 확인합니다.
(overcloud)$ openstack server list --host <dest> --all-projects
<dest>
를 대상 컴퓨팅 노드의 이름 또는 ID로 바꿉니다.선택 사항: 유지보수를 위해 소스 컴퓨팅 노드를 비활성화한 경우 새 인스턴스를 할당할 수 있도록 노드를 다시 활성화해야 합니다.
(overcloud)$ openstack compute service set <source> nova-compute --enable
<source>
를 소스 컴퓨팅 노드의 호스트 이름으로 바꿉니다.
16.3.6. 마이그레이션 상태 확인
마이그레이션이 완료되기 전에 마이그레이션에는 여러 상태 전환이 포함됩니다. 정상적인 마이그레이션 과정에서 마이그레이션 상태는 일반적으로 다음과 같이 전환됩니다.
- 대기 중: 계산 서비스에서 인스턴스 마이그레이션 요청을 수락했으며 마이그레이션이 보류 중입니다.
- 준비 중: 계산 서비스에서 인스턴스를 마이그레이션할 준비가 되어 있습니다.
- 실행 중: 계산 서비스에서 인스턴스를 마이그레이션합니다.
- 마이그레이션 후: 계산 서비스는 대상 컴퓨팅 노드에 인스턴스를 빌드했으며 소스 컴퓨팅 노드에 리소스를 해제하고 있습니다.
- 완료됨: 계산 서비스는 인스턴스 마이그레이션을 완료하고 소스 컴퓨팅 노드에서 리소스 릴리스를 완료했습니다.
절차
인스턴스의 마이그레이션 ID 목록을 검색합니다.
$ nova server-migration-list <instance> +----+-------------+----------- (...) | Id | Source Node | Dest Node | (...) +----+-------------+-----------+ (...) | 2 | - | - | (...) +----+-------------+-----------+ (...)
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다.마이그레이션 상태를 표시합니다.
$ nova server-migration-show <instance> <migration_id>
-
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다. <migration_id>
를 마이그레이션 ID로 바꿉니다.nova server-migration-show
명령을 실행하면 다음 예제 출력이 반환됩니다.+------------------------+--------------------------------------+ | Property | Value | +------------------------+--------------------------------------+ | created_at | 2017-03-08T02:53:06.000000 | | dest_compute | controller | | dest_host | - | | dest_node | - | | disk_processed_bytes | 0 | | disk_remaining_bytes | 0 | | disk_total_bytes | 0 | | id | 2 | | memory_processed_bytes | 65502513 | | memory_remaining_bytes | 786427904 | | memory_total_bytes | 1091379200 | | server_uuid | d1df1b5a-70c4-4fed-98b7-423362f2c47c | | source_compute | compute2 | | source_node | - | | status | running | | updated_at | 2017-03-08T02:53:47.000000 | +------------------------+--------------------------------------+
작은 정보OpenStack 계산 서비스는 마이그레이션 진행 상황을 복사할 나머지 메모리 바이트 수만큼 측정합니다. 시간이 지남에 따라 이 수가 감소하지 않으면 마이그레이션을 완료할 수 없으며 계산 서비스에서 중단될 수 있습니다.
-
인스턴스 마이그레이션에 시간이 오래 걸리거나 오류가 발생하는 경우가 있습니다. 자세한 내용은 마이그레이션 문제 해결을 참조하십시오.
16.3.7. 인스턴스 비우기
Compute 노드에서 동일한 환경의 새 호스트로 인스턴스를 이동하거나 종료하려면 해당 인스턴스를 비울 수 있습니다.
비우기 프로세스에서는 원래 인스턴스를 삭제하고 원본 이미지, 인스턴스 이름, UUID, 네트워크 주소 및 원래 인스턴스가 할당된 기타 리소스를 사용하여 다른 컴퓨팅 노드에 다시 빌드합니다.
인스턴스에서 공유 스토리지를 사용하는 경우 대상 Compute 노드에서 디스크에 계속 액세스할 수 있으므로 비우기 프로세스 중에 인스턴스 루트 디스크가 다시 빌드되지 않습니다. 인스턴스가 공유 스토리지를 사용하지 않으면 인스턴스 루트 디스크도 대상 컴퓨팅 노드에 다시 빌드됩니다.
-
컴퓨팅 노드가 펜싱된 경우에만 비우기를 수행할 수 있으며 API에서 컴퓨팅 노드의 상태가 "다운" 또는 "강제 종료"임을 보고합니다. 컴퓨팅 노드가 "다운" 또는 "강제 종료"로 보고되지 않으면
evacuate
명령이 실패합니다. - 비우기를 수행하려면 클라우드 관리자여야 합니다.
16.3.7.1. 하나의 인스턴스 비우기
한 번에 하나씩 인스턴스를 비울 수 있습니다.
절차
- 관리자로 실패한 컴퓨팅 노드에 로그인합니다.
컴퓨팅 노드를 비활성화합니다.
(overcloud)[stack@director ~]$ openstack compute service set \ <host> <service> --disable
-
<host>
를 인스턴스를 비울 컴퓨팅 노드의 이름으로 바꿉니다. -
<service>
를 비활성화할 서비스의 이름으로 바꿉니다(예:nova-compute
).
-
인스턴스를 비우려면 다음 명령을 입력합니다.
(overcloud)[stack@director ~]$ nova evacuate [--password <pass>] <instance> [<dest>]
-
비워진 인스턴스에 대해 설정하려면
<pass>
를 관리자 암호로 바꿉니다. 암호를 지정하지 않으면 비우기가 완료되면 임의 암호가 생성되고 출력됩니다. -
<instance>
를 비울 인스턴스의 이름 또는 ID로 바꿉니다. <dest>
를 인스턴스를 비울 컴퓨팅 노드의 이름으로 바꿉니다. 대상 컴퓨팅 노드를 지정하지 않으면 컴퓨팅 스케줄러에서 노드를 선택합니다. 다음 명령을 사용하여 가능한 컴퓨팅 노드를 찾을 수 있습니다.(overcloud)[stack@director ~]$ openstack hypervisor list
-
비워진 인스턴스에 대해 설정하려면
16.3.7.2. 호스트의 모든 인스턴스 비우기
지정된 컴퓨팅 노드의 모든 인스턴스를 비울 수 있습니다.
절차
- 관리자로 실패한 컴퓨팅 노드에 로그인합니다.
컴퓨팅 노드를 비활성화합니다.
(overcloud)[stack@director ~]$ openstack compute service set \ <host> <service> --disable
-
인스턴스를 비울 컴퓨팅 노드의 이름으로
<host>
를 바꿉니다. -
<service>
를 비활성화할 서비스의 이름으로 바꿉니다(예:nova-compute
).
-
인스턴스를 비울 컴퓨팅 노드의 이름으로
지정된 컴퓨팅 노드의 모든 인스턴스를 비웁니다.
(overcloud)[stack@director ~]$ nova host-evacuate [--target_host <dest>] <host>
<dest>
를 인스턴스를 비우려면 대상 컴퓨팅 노드의 이름으로 교체합니다. 대상을 지정하지 않으면 Compute 스케줄러에서 대상을 선택합니다. 다음 명령을 사용하여 가능한 컴퓨팅 노드를 찾을 수 있습니다.(overcloud)[stack@director ~]$ openstack hypervisor list
-
인스턴스를 비울 컴퓨팅 노드의 이름으로
<host>
를 바꿉니다.
16.3.8. 마이그레이션 문제 해결
인스턴스 마이그레이션 중에 다음과 같은 문제가 발생할 수 있습니다.
- 마이그레이션 프로세스에서 오류 발생
- 마이그레이션 프로세스가 종료되지 않음
- 마이그레이션 후 인스턴스의 성능이 저하됩니다.
16.3.8.1. 마이그레이션 중 오류
다음과 같은 문제가 발생하면 마이그레이션 작업이 error
상태로 전환합니다.
- 다른 버전의 RHOSP(Red Hat OpenStack Platform)로 클러스터 실행.
- 찾을 수 없는 인스턴스 ID 지정.
-
마이그레이션하려는 인스턴스가
error
상태입니다. - Compute 서비스가 종료됨
- 경합 상태 발생
-
실시간 마이그레이션이
failed
상태로 전환
실시간 마이그레이션이 failed
상태로 전환된 후에는 일반적으로 error
상태가 됩니다. 다음과 같은 일반적인 문제로 인해 failed
상태가 발생할 수 있습니다.
- 대상 Compute 호스트를 사용할 수 없음
- 스케줄러 예외 발생
- 컴퓨팅 리소스가 부족하여 재빌드 프로세스 실패
- 서버 그룹 확인 실패
- 대상 컴퓨팅 노드로 마이그레이션하기 전에 소스 컴퓨팅 노드의 인스턴스가 삭제됩니다.
16.3.8.2. 끝나지 않는 실시간 마이그레이션
실시간 마이그레이션이 완료되지 않아 마이그레이션이 영구적으로 실행
중 상태가 됩니다. 실시간 마이그레이션이 완료되지 않는 일반적인 이유는 소스 컴퓨팅 노드에서 실행 중인 인스턴스에 대한 클라이언트 요청이 Compute 서비스에서 대상 컴퓨팅 노드에 복제하는 속도보다 빠르게 발생하는 변경 사항을 생성하기 때문입니다.
다음 방법 중 하나를 사용하여 이 상황을 해결하십시오.
- 실시간 마이그레이션 중지
- 실시간 마이그레이션 강제 완료
실시간 마이그레이션 중지
인스턴스 상태가 마이그레이션 프로세스에서 대상 노드에 복사하는 속도보다 빨리 변경되고 인스턴스 작업을 일시적으로 중단하지 않으려는 경우 실시간 마이그레이션을 중단할 수 있습니다.
절차
인스턴스의 마이그레이션 목록을 검색합니다.
$ nova server-migration-list <instance>
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다.실시간 마이그레이션을 중지합니다.
$ nova live-migration-abort <instance> <migration_id>
-
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다. -
<migration_id>
를 마이그레이션 ID로 바꿉니다.
-
실시간 마이그레이션 강제 완료
인스턴스 상태가 마이그레이션 프로세스에서 대상 노드에 복사하는 속도보다 빠르게 변경되고 인스턴스 작업을 일시적으로 일시 중단하여 마이그레이션을 강제 완료하려는 경우 실시간 마이그레이션 절차를 강제 완료할 수 있습니다.
실시간 마이그레이션을 강제 완료하면 상당한 다운 타임이 발생할 수 있습니다.
절차
인스턴스의 마이그레이션 목록을 검색합니다.
$ nova server-migration-list <instance>
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다.실시간 마이그레이션을 강제 완료합니다.
$ nova live-migration-force-complete <instance> <migration_id>
-
<instance>
를 인스턴스의 이름 또는 ID로 바꿉니다. -
<migration_id>
를 마이그레이션 ID로 바꿉니다.
-
16.3.8.3. 마이그레이션 후 인스턴스 성능 저하
NUMA 토폴로지를 사용하는 인스턴스의 경우 소스 및 대상 Compute 노드에 동일한 NUMA 토폴로지 및 구성이 있어야 합니다. 대상 Compute 노드의 NUMA 토폴로지에는 사용 가능한 충분한 리소스가 있어야 합니다. 소스와 대상 Compute 노드 간의 NUMA 구성이 동일하지 않은 경우 인스턴스 성능이 저하되는 동안 실시간 마이그레이션이 성공할 수 있습니다. 예를 들어 소스 Compute 노드는 NIC 1을 NUMA 노드 0에 매핑하지만 대상 Compute 노드는 NIC 1을 NUMA 노드 5에 매핑하는 경우, 마이그레이션 후 인스턴스에서 트래픽을 NIC 1로 라우팅하기 위해 버스를 통해 첫 번째 CPU의 네트워크 트래픽을 NUMA 노드 5가 있는 두 번째 CPU로 라우팅할 수 있습니다. 이로 인해 예상된 동작이 발생할 수 있지만 성능이 저하될 수 있습니다. 마찬가지로 소스 Compute 노드의 NUMA 노드 0에 사용 가능한 CPU 및 RAM이 충분하지만 대상 Compute 노드의 NUMA 노드 0에 일부 리소스를 사용하는 인스턴스가 이미 있는 경우 인스턴스가 올바르게 실행되고 성능이 저하될 수 있습니다. 자세한 내용은 마이그레이션 제한 조건을 참조하십시오.