Tag Archives: live-migration

주변기술 시리즈 #4, KVM live-migration internal

주변기술 시리즈 #4, KVM live-migration (가상머신의 라이브마이그레이션)

가상화 기술의 장점중 하나가 바로 라이브마이그레이션입니다. 라이브마이그레이션이 필요한 이유는 여러가지가 있으나 결과적으로 가상머신의 downtime을 줄이고 서비스의 High Availability를 달성하기 위함이라고 볼 수 있습니다. 심지어 service의 life-cycle이 상대적으로 짧고, HA를 application layer에 의존하도록 하는 IaaS cloud computing 플랫폼에서도 대세는 라이브마이그레이션을 지원하는 방향으로 가고 있습니다. OpenStack의 지원이 그 단적인 예라고 할 수 있지요.

라이브마이그레이션을 위한 조건 및 실패사례는 이전 포스팅을 참고하시고요,
https://ovirtkorea.wordpress.com/2014/06/23/%EC%8B%A4%EC%A0%84-%ED%99%9C%EC%9A%A9%ED%8C%81-%EB%9D%BC%EC%9D%B4%EB%B8%8C-%EB%A7%88%EC%9D%B4%EA%B7%B8%EB%A0%88%EC%9D%B4%EC%85%98-%EC%A4%80%EB%B9%84/

최근에 KVM 라이브마이그레이션 시에 내부적으로 어떤 일들이 읽어나는지, 왜 메모리 변화가 큰(높은 부가) 가상머신의 라이브마이그레이션이 실패하는지에 대한 분석해야할 일이 있었는데요, 관련하여 유용한 자료가 있어 공유합니다.
http://developerblog.redhat.com/2015/03/24/live-migrating-qemu-kvm-virtual-machines/

대략적인 동작은 다음과 같습니다.

  • Stage 1: 가상머신의 모든 메모리를 dirty(복사 대상)으로 설정합니다.
  • Stage 2: 반복적인 iteration을 거쳐 이들 dirty page들을 복사합니다. (1회 iteration을 전송하는 사이에 추가 변경된 page들은 dirty로 재전환), 만약 live migration에 주어진 현재 전송되는 속도(지속적으로 계산)를 고려하여 남은 dirty page가 downtime(기본값 300 ms)내 전송이 가능한 수준이 되면 Stage 3로 전환
  • Stage 3: Source로부터 가상머신을 일시 멈추고, 나머지 dirty page를 destination에 복사합니다. 그리고 destination에서 가상머신을 재시작합니다.

위 과정중에 가장 중요한 부분은 Stage 2 단계로서 이에 영향을 미칠 수 있는 요소는 2가지 입니다.

  • downtime : 허용 가능한 최대 downtime(마이그레이션 마지막 단계에서 일시적, 기본값 300 ms)
  • speed : 초당 전송에 사용할 최대 bandwidth 값(기본 32 MiB/s)

그러나 stage 2에서 전송되는 속도보다 dirty로 변하는 속도가 클 경우에는 결국 라이브 마이그레이션은 실패하게 됩니다. dirty로 변하는 page는 KVM이 추적하게 되며 QEMU에서 KVM API를 통해 각 iteration에서 확인하게 됩니다.

실전 활용팁, 라이브 마이그레이션 준비

Best Practice, live-migration prerequisites

oVirt/RHEV의 강점 중 하나가 online 상에서 가상머신을 서로 다른 ovirt-node(하이퍼바이저, 호스트)로 라이브 마이그레이션이 가능하다는 점 입니다. 서비스의 지속성 관점에서 매우 중요한 기능인데요, 실시간으로 서비스 중단 없이 호스트간에 이동이 가능한만큼 몇가지 조건을 만족시켜줘야 합니다.

* 용어 안내

  • Source 호스트 : 라이브 마이그레이션 대상 가상머신이 실행중인 호스트
  • Destination 호스트 : 실행중인 가상머신이 옮겨갈 대상 호스트

* 라이브 마이그레이션을 위한 조건

  1. Source, Destination 호스트가 모두 동일한 oVirt Cluster 소속, 동일한 CPU 호환성을 가져야 함 (Intel/AMD 벤더 및 CPU microarchitecture – Nehalem, SandyBridge 등)
  2. Source, Destination 호스트가 모두 Up 상태
  3. Source, Destination 호스트의 oVirt/RHEV Management Network 또는 Migration Network(3.3 이후)를 통해 접근 가능
  4. 대상 가상머신이 사용하는 oVirt/RHEV 스토리지 도메인에 Source, Destination 호스트가 모두 접근 가능
  5. Destination 호스트에 대상 가상머신 실행에 필요한 충분한 여유 메모리
  6. Source, Destination 호스트간 DNS 또는 /etc/hosts에 host명 resolve 필요
  7. 대상 가상머신에 ISO 이미지가 mount되어 있거나 attach 되면 안됨
  8. oVirt/RHEV 3.1-> oVirt/RHEV 3.0 라이브 마이그레이션은 지원하지 않음

* 대표적 라이브 마이그레이션 실패 사례

  • ISO 파일을 마운트 한 상태에서 시도 ==> umount, detach 후 재시도
  • 오래된 vdsm, libvirt 버전 사용 ==> 가능한 3.2 이후 최신 버전 사용 (3.4 권장)
  • 라이브 마이그레이션에 사용되는 네트워크 대여폭 부족에 따른 취소 ==> 대여폭 확보, 또는 3.3 이후 버전에서는 별도의 live-migration network 분리
  • 가상머신의 높은 부하로 인해 주어진 시간내 마이그레이션을 성공할 수 없는 경우 취소 ==> 부하가 줄었을 때 재시도, 또는 vdsm 설정에서” migration_downtime” 값을 늘린 후 재시도
  • RHEL 5.7 이전 버전에서 시스템 패닉 발생 ==> nmi_watchdog=0 커널 옵션 추가

 

참고 자료 : https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.4/html/Administration_Guide/Live_migration_prerequisites.html