15.5. virsh를 사용한 실시간 KVM 마이그레이션
virsh 명령을 사용하여 게스트 가상 시스템을 다른 호스트 물리적 시스템으로 마이그레이션할 수 있습니다. migrate 명령은 다음 형식으로 매개변수를 허용합니다.
# virsh migrate --live GuestName DestinationURL
실시간 마이그레이션이 필요하지 않은 경우 --live 옵션이 제거될 수 있습니다. 추가 옵션은 15.5.2절. “virsh migrate 명령의 추가 옵션” 에 기재되어 있습니다.
GuestName
매개변수는 마이그레이션하려는 게스트 가상 머신의 이름을 나타냅니다.
DestinationURL
매개변수는 대상 호스트 물리적 시스템의 연결 URL입니다. 대상 시스템은 동일한 하이퍼바이저를 사용하고 libvirt 를 실행해야 합니다.
참고
일반 마이그레이션 및 peer2peer 마이그레이션의
DestinationURL
매개 변수는 다음과 같은 의미 체계가 다릅니다.
- 일반 마이그레이션:
DestinationURL
은 소스 게스트 가상 머신에 표시된 대로 대상 호스트 물리적 시스템의 URL입니다. - peer2peer 마이그레이션:
DestinationURL
은 소스 호스트 물리적 시스템에 표시되는 것처럼 대상 호스트 물리적 시스템의 URL입니다.
명령이 입력되면 대상 시스템의 루트 암호를 입력하라는 메시지가 표시됩니다.
중요
마이그레이션이 성공하려면 양쪽(소스 및 대상)에서 이름 확인이 작동해야 합니다. 각 측은 다른 쪽을 찾을 수 있어야합니다. 한 쪽을 다른 쪽으로 ping하여 이름 확인이 작동하는지 확인하십시오.
예: virsh를 사용한 실시간 마이그레이션
이 예제에서는 host1.example.com
에서 host2.example.com
으로 마이그레이션합니다. 해당 환경의 호스트 물리적 시스템 이름을 변경합니다. 이 예에서는 guest1-rhel6-64
라는 가상 머신을 마이그레이션합니다.
이 예에서는 공유 스토리지를 완전히 구성하고 모든 사전 요구 사항을 충족한다고 가정합니다(여기서: 마이그레이션 요구사항).
게스트 가상 머신이 실행 중인지 확인
소스 시스템에서host1.example.com
에서guest1-rhel6-64
가 실행 중인지 확인합니다.[root@host1 ~]# virsh list Id Name State ---------------------------------- 10 guest1-rhel6-64 running
게스트 가상 머신 마이그레이션
다음 명령을 실행하여 게스트 가상 머신을 대상host2.example.com
으로 실시간 마이그레이션합니다. 대상 URL 끝에/system
을 추가하여 libvirt에 전체 액세스 권한이 필요하다는 것을 알립니다.# virsh migrate --live
guest1-rhel7-64 qemu+ssh://host2.example.com/system
명령이 입력되면 대상 시스템의 루트 암호를 입력하라는 메시지가 표시됩니다.wait
마이그레이션은 게스트 가상 시스템의 부하 및 크기에 따라 다소 시간이 걸릴 수 있습니다. virsh 는 오류만 보고합니다. 게스트 가상 시스템은 완전히 마이그레이션될 때까지 소스 호스트 물리적 시스템에서 계속 실행됩니다.게스트 가상 머신이 대상 호스트에 도착했는지 확인합니다.
대상 시스템에서host2.example.com
에서guest1-rhel7-64
가 실행 중인지 확인합니다.[root@host2 ~]# virsh list Id Name State ---------------------------------- 10 guest1-rhel7-64 running
이제 실시간 마이그레이션이 완료되었습니다.
참고
libvirt는 TLS/SSL, UNIX 소켓, SSH 및 암호화되지 않은 TCP를 비롯한 다양한 네트워킹 방법을 지원합니다. 다른 방법 사용에 대한 자세한 내용은 18장. 게스트의 원격 관리 을 참조하십시오.
참고
다음 명령을 사용하여 실행 중인 게스트 가상 머신을 마이그레이션할 수 있습니다.
# virsh migrate --offline --persistent
15.5.1. virsh를 사용하여 마이그레이션을 위한 추가 팁
각 마이그레이션이 별도의 명령 쉘에서 실행되는 동시에 여러 실시간 마이그레이션을 수행할 수 있습니다. 그러나 이 작업을 신중하게 수행해야 하며 각 마이그레이션 인스턴스에서 각 사이드(소스 및 대상)에서 하나의 MAX_CLIENT를 사용하므로 신중하게 계산해야 합니다. 기본 설정은 20이므로 설정을 변경하지 않고 10개의 인스턴스를 실행하기에 충분합니다. 설정을 변경해야 하는 경우 절차를 참조하십시오. 절차 15.1. “libvirtd.conf 구성”
- 절차 15.1. “libvirtd.conf 구성” 에 설명된 대로 libvirtd.conf 파일을 엽니다.
- Processing controls 섹션을 찾습니다.
################################################################# # # Processing controls # # The maximum number of concurrent client connections to allow # over all sockets combined. #max_clients = 5000 # The maximum length of queue of connections waiting to be # accepted by the daemon. Note, that some protocols supporting # retransmission may obey this so that a later reattempt at # connection succeeds. #max_queued_clients = 1000 # The minimum limit sets the number of workers to start up # initially. If the number of active clients exceeds this, # then more threads are spawned, upto max_workers limit. # Typically you'd want max_workers to equal maximum number # of clients allowed #min_workers = 5 #max_workers = 20 # The number of priority workers. If all workers from above # pool will stuck, some calls marked as high priority # (notably domainDestroy) can be executed in this pool. #prio_workers = 5 # Total global limit on concurrent RPC calls. Should be # at least as large as max_workers. Beyond this, RPC requests # will be read into memory and queued. This directly impact # memory usage, currently each request requires 256 KB of # memory. So by default upto 5 MB of memory is used # # XXX this isn't actually enforced yet, only the per-client # limit is used so far #max_requests = 20 # Limit on concurrent requests from a single client # connection. To avoid one client monopolizing the server # this should be a small fraction of the global max_requests # and max_workers parameter #max_client_requests = 5 #################################################################
max_clients
및max_workers
매개변수 설정을 변경합니다. 두 매개변수 모두에서 번호가 동일해야 하는 것이 좋습니다.max_clients
는 마이그레이션당 2개의 클라이언트를 사용하며max_workers
는 완료 단계에서 대상에서 1개의 작업자와 대상에서 1개의 작업자를 사용합니다.중요max_clients
및max_workers
매개변수 설정은 libvirtd 서비스에 대한 모든 게스트 가상 시스템 연결의 영향을 받습니다. 즉, 동일한 게스트 가상 머신을 사용하고 동시에 마이그레이션을 수행하는 모든 사용자는max_clients
및max_workers
매개변수 설정에 설정된 제한도 따릅니다. 따라서 동시 실시간 마이그레이션을 수행하기 전에 최대값을 신중하게 고려해야 합니다.중요max_clients
매개변수는 libvirt에 연결할 수 있는 클라이언트 수를 제어합니다. 다수의 컨테이너가 한 번에 시작되면 이 제한에 쉽게 도달하고 초과할 수 있습니다. 이를 방지하기 위해max_clients
매개변수의 값이 증가할 수 있지만 이렇게 하면 인스턴스에 대한 DoS(서비스 거부) 공격에 시스템이 더 취약해질 수 있습니다. 이 문제를 완화하기 위해 Red Hat Enterprise Linux 7.0에 새로운max_anonymous_clients
설정이 도입되어 있지만 아직 인증되지 않은 연결 수를 지정합니다.max_clients
와max_anonymous_clients
조합을 구현하여 워크로드에 맞게 구성할 수 있습니다.- 파일을 저장하고 서비스를 다시 시작합니다.참고시작된 ssh 세션이 많지만 아직 인증되지 않았기 때문에 마이그레이션 연결이 중단된 경우가 있을 수 있습니다. 기본적으로
sshd
에서는 언제든지 10개의 세션만 "사전 인증 상태"에 있을 수 있습니다. 이 설정은 sshd 구성 파일의MaxStartups
매개변수에 의해 제어됩니다(여기서는/etc/ssh/sshd_config
) 일부 조정이 필요할 수 있습니다. DoS 공격(및 일반적으로 리소스 초과 사용)을 방지하기 위해 제한 사항이 적용되므로 이 매개 변수를 조정해야 합니다. 이 값을 너무 높게 설정하면 그 용도가 무효화됩니다. 이 매개변수를 변경하려면/etc/ssh/sshd_config
파일을 편집하고, MaxStartups 행의 시작 부분에서 # 을 제거하고10
(기본값)을 더 높은 숫자로 변경합니다. 파일을 저장하고sshd
서비스를 다시 시작하십시오. 자세한 내용은sshd_config
매뉴얼 페이지를 참조하십시오.