가상 머신(VM) 인스턴스 또는 베어메탈 인스턴스의 기본 하드웨어에 계획된 유지보수 이벤트 중에는 호스트 서버를 사용할 수 없습니다. 호스트 이벤트 중에도 인스턴스를 계속 실행하려면 Compute Engine에서 인스턴스를 같은 영역에 있는 다른 호스트 서버로 라이브 마이그레이션합니다. 호스트 이벤트에 대한 자세한 내용은 호스트 이벤트 정보를 참조하세요.
라이브 마이그레이션을 이용하면 Google Cloud 가 워크로드를 중단하거나, 인스턴스를 재부팅하거나, 인스턴스 속성(예: IP 주소, 메타데이터, 블록 스토리지 데이터, 애플리케이션 상태, 네트워크 설정)을 수정하지 않고 유지보수를 수행할 수 있습니다.
라이브 마이그레이션은 다음 상황 중에도 인스턴스를 계속 실행할 수 있습니다.
인프라 유지보수. 인프라 유지보수에는 호스트 하드웨어, 데이터 센터의 네트워크 및 전원 그리드, 호스트 운영체제(OS) 및 BIOS가 포함됩니다.
보안 관련 업데이트 및 시스템 구성 변경사항. 여기에는 보안 패치 설치, 호스트 OS 이미지 및 패키지 스토리지를 위한 호스트 루트 파티션 크기 변경과 같은 이벤트가 포함됩니다.
하드웨어 오류 여기에는 메모리, CPU, 네트워크 인터페이스 카드 및 디스크의 장애가 포함됩니다. 전체 서버 장애가 발생하기 전에 장애가 감지되면 Compute Engine이 예방 차원에서 새 호스트 서버로 인스턴스 라이브 마이그레이션을 수행합니다. 하드웨어가 완전히 고장나거나 그 밖의 이유로 라이브 마이그레이션이 불가능한 경우 인스턴스가 종료되고 자동으로 다시 시작됩니다.
Compute Engine은 마이그레이션할 호스트 유지보수 정책이 설정된 VM의 라이브 마이그레이션만 수행합니다. 호스트 유지보수 정책을 변경하는 방법은 VM 호스트 유지보수 정책 설정을 참조하세요.
라이브 마이그레이션 프로세스와 로컬 SSD 디스크
Compute Engine은 로컬 SSD 디스크가 연결된 인스턴스에 라이브 마이그레이션을 수행할 수 있습니다(Z3 인스턴스 제외). Compute Engine은 계획된 유지보수가 수행되기 전에 미리 로컬 SSD 데이터와 함께 VM 인스턴스를 새 머신으로 이동합니다.
제한사항
다음 VM 유형에 라이브 마이그레이션이 지원되지 않습니다.
베어메탈 인스턴스. 베어메탈 머신 유형으로 생성된 인스턴스는 라이브 마이그레이션을 지원하지 않습니다. 이러한 인스턴스의 유지보수 동작은 각각 TERMINATE 및 RESTART로 설정됩니다.
대부분의 컨피덴셜 VM 인스턴스. 컨피덴셜 VM 인스턴스의 라이브 마이그레이션은 AMD SEV를 실행하는 AMD EPYC Milan CPU 플랫폼이 있는 N2D 머신 유형에서만 지원됩니다. 다른 모든 컨피덴셜 VM 인스턴스는 라이브 마이그레이션을 지원하지 않으며 호스트 유지보수 이벤트 중에 중지 및 다시 시작(원하는 경우)하도록 설정해야 합니다. 자세한 내용은 라이브 마이그레이션을 참조하세요.
GPU가 연결된 VM. GPU가 연결된 VM 인스턴스는 중지 후 원하는 경우 다시 시작되도록 설정해야 합니다. Compute Engine은 GPU 유형에 따라 연결된 GPU가 있는 VM 인스턴스가 중지되기 전에 알림을 제공합니다.
대부분의 GPU의 경우 Compute Engine에서 60분 전 알림을 제공합니다.
AI 하이퍼컴퓨터 Cluster Director에서 실행되는 GPU 계열의 경우 Compute Engine에서 10분 전 알림을 제공합니다.
스토리지 최적화 VM. vCPU가 88개 이상 있는 Z3 VM은 라이브 마이그레이션을 지원하지 않습니다. 이러한 VM의 유지보수 동작은 TERMINATE 및 RESTART로 설정됩니다.
Compute Engine은 인스턴스 종료 후 디스크 지속성의 설명대로 유지보수 이벤트 중에 티타늄 SSD의 데이터를 보존합니다.
라이브 마이그레이션 프로세스의 작동 방식
VM에 라이브 마이그레이션이 예약되면 Compute Engine이 알림을 제공하므로, 라이브 마이그레이션으로 인한 워크로드 및 애플리케이션 중단을 준비할 수 있습니다. 라이브 마이그레이션 중에 Google Cloud 는 일반적으로 1초 미만의 최소 중단 시간을 모니터링합니다. VM이 라이브 마이그레이션되도록 설정되지 않으면 Compute Engine이 호스트 유지보수 중에 VM을 종료합니다. 호스트 이벤트 중에 종료되도록 설정된 VM이 중지 및 다시 시작(원하는 경우)됩니다.
Google Cloud 는 실행 중인 VM을 한 호스트에서 다른 호스트로 마이그레이션할 때, 게스트 OS 및 게스트 OS와 통신하는 모든 것에 투명한 방식으로 소스에서 대상으로 VM의 전체 상태를 마이그레이션합니다.
이러한 작업이 매끄럽게 진행되도록 하는 데 많은 구성요소가 관련되어 있지만 다음 이미지에서 이러한 단계를 간단히 보여줍니다.
라이브 마이그레이션 구성요소
이 프로세스는 VM을 현재 호스트 머신에서 내보내야 한다는 알림으로 시작합니다. 이러한 알림은 새로운 BIOS 버전을 사용할 수 있음을 알리는 파일 변경, 하드웨어 작업 예약 유지보수 또는 임박한 하드웨어 오류로부터 발생하는 자동 신호로부터 시작될 수 있습니다.
Google Cloud의 클러스터 관리 소프트웨어는 이러한 이벤트를 상시적으로 감시하고 단일 고객이 한 번에 마이그레이션할 수 있는 VM 수 및 용량 사용률과 같이, 데이터 센터를 제어하는 정책에 따라 이벤트를 예약합니다.
마이그레이션할 VM이 선택된 다음에는 Google Cloud 가 이전이 임박한 게스트에 알림을 제공합니다. 대기 기간이 지난 후 대상 호스트가 선택되고 해당 호스트에게 마이그레이션되는 "소스" VM을 받아들일 새로운 빈 "대상" VM을 설정하라는 요청이 전송됩니다. 소스와 대상 사이의 연결을 설정하기 위해서는 인증이 사용됩니다.
VM 마이그레이션은 세 단계로 이루어집니다.
소스 브라운아웃. VM은 계속 소스에서 실행되며 대부분의 상태가 소스에서 대상으로 전송됩니다. 예를 들어Google Cloud 는 모든 게스트 메모리를 대상으로 복사하고 소스에서 변경된 페이지를 추적합니다. 게스트 메모리 크기와 페이지가 변경되는 속도에 따라 소스 브라운아웃에 소요되는 시간이 달라집니다.
블랙아웃. VM이 어디에서도 실행되지 않는 매우 짧은 순간입니다. 이 단계에서는 소스 VM이 일시 중지되고, 대상에서 VM 실행을 시작하기 위해 필요한 모든 나머지 상태가 전송됩니다. 소스 브라운아웃 단계 중 상태 변경사항을 전송해도 반환 결과가 감소하는 시점에 도달하면 VM이 블랙아웃 단계로 전환됩니다. 전송되는 메모리의 바이트 수와 게스트 VM이 변경되는 속도를 비교하는 알고리즘이 사용됩니다.
블랙아웃 이벤트 중에 시스템 시계가 최대 5초 앞으로 건너뛸 수 있습니다. 블랙아웃 이벤트가 5초를 초과하면 Google Cloud 가 VM 게스트 패키지의 일부로 포함된 데몬을 사용하여 시계를 중지하고 동기화합니다.
대상 브라운아웃 VM이 대상 VM에서 실행됩니다. 소스 VM도 존재하며, 대상 VM에 대한 지원을 제공할 수 있습니다. 예를 들어 네트워크 패브릭에 대상 VM의 새로운 위치가 적용될 때까지 소스 VM은 대상 VM과 주고받는 패킷의 전달 서비스를 제공합니다.
마지막으로 마이그레이션이 완료되고 시스템이 소스 VM을 삭제합니다. 수행된 마이그레이션은 VM의 Cloud Logging 로그에서 확인할 수 있습니다.
단독 테넌트 VM의 라이브 마이그레이션
워크로드가 실행될 때 VM을 다른 단독 테넌트 노드 또는 노드 그룹으로 이동해야 할 수 있습니다. VM을 노드 그룹으로 이동하면 Compute Engine이 VM을 배치할 노드를 결정합니다. 단독 테넌시에 대한 자세한 내용은 단독 테넌시 개요를 참조하세요.
단독 테넌트 VM을 다른 노드 또는 노드 그룹으로 이동하려면 라이브 마이그레이션을 수동으로 시작할 수 있습니다. 또한 라이브 마이그레이션을 수동으로 시작하여 멀티 테넌트 호스트의 VM을 단독 테넌트 노드로 이동할 수 있습니다. 자세한 내용은 수동으로 VM 라이브 마이그레이션을 참조하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-29(UTC)"],[[["\u003cp\u003eCompute Engine performs live migration to move a virtual machine (VM) to a new host server during maintenance events without interrupting workloads or modifying instance properties.\u003c/p\u003e\n"],["\u003cp\u003eLive migration occurs during infrastructure maintenance, security updates, system changes, and hardware failures, ensuring continuous operation of instances.\u003c/p\u003e\n"],["\u003cp\u003eVMs with Local SSD disks can be live-migrated, though large amounts of data can lead to longer periods of performance degradation or data loss.\u003c/p\u003e\n"],["\u003cp\u003eCertain VM types, such as bare metal instances, most Confidential VMs, VMs with GPUs, Cloud TPUs, and Z3 VMs, do not support live migration and instead terminate and optionally restart during host maintenance.\u003c/p\u003e\n"],["\u003cp\u003eThe live migration process involves a notification, followed by a "brownout" where VM state is transferred, a brief "blackout" when the VM pauses, and then a "target brownout" as the VM executes on the new host, with minimal disruption to the workload.\u003c/p\u003e\n"]]],[],null,["*** ** * ** ***\n\nDuring a planned maintenance event for the underlying hardware of a virtual\nmachine (VM) instance or bare\nmetal instance, the host server is unavailable. To keep an\ninstance running during a host event, Compute Engine performs a\n*live migration* of the instance to another host server in the same zone. For\nmore information about host events, see\n[About host events](/compute/docs/instances/host-maintenance-overview).\n\nLive migration lets Google Cloud perform maintenance without\ninterrupting a workload, rebooting an instance, or modifying any of the\ninstance's properties, such as IP addresses, metadata, block storage data,\napplication state, or network settings.\n\nLive migration keeps instances running during the following situations:\n\n- **Infrastructure maintenance.** Infrastructure maintenance includes host\n hardware, network and power grids in data centers, and host operating\n system (OS) and BIOS.\n\n- **Security-related updates and system configuration changes.** These include\n events such as installing security patches and changing the size of the host\n root partition for storage of the host OS image and packages.\n\n- **Hardware failures.** This includes failures in memory, CPUs, network\n interface cards, and disks. If the failure is detected before there is\n a complete server failure, then Compute Engine performs a preventative\n live migration of the instance to a new host server. If the hardware fails\n completely or otherwise prevents live migration, then the instance terminates\n and restarts automatically.\n\nCompute Engine only performs a live migration of VMs that have the\nhost maintenance policy set to migrate. For information about how to change the\nhost maintenance policy, see\n[Set VM host maintenance policy](/compute/docs/instances/host-maintenance-options).\n\nLive migration process and Local SSD disks\n\nCompute Engine can live migrate instances with Local SSD disks\nattached (excluding Z3 instances with more than 18 TiB of attached\nTitanium SSD). Compute Engine moves the VM instances along with\ntheir Local SSD data to a new machine in advance of any planned maintenance.\n| **Caution:** Instances with a large amount of Local SSD data can experience a longer period of performance degradation or Local SSD data loss during the migration to the new host server.\n\nLimitations\n\nLive migration is not supported for the following VM types:\n\n- **Bare metal instances** . Instances created with a [bare metal machine type](/compute/docs/instances/bare-metal-instances) don't support live migration. The maintenance behavior for these instances is set to `TERMINATE` and `RESTART`, respectively.\n- **Most Confidential VM instances** . Live migration for Confidential VM instances is only supported on N2D machine types with AMD EPYC Milan CPU platforms running AMD SEV. All other Confidential VM instances don't support live migration, and must be set to stop and optionally restart during a host maintenance event. See [Live migration](/confidential-computing/confidential-vm/docs/troubleshoot-live-migration) for more details.\n- **VMs with GPUs attached**. VM instances with GPUs attached must be set\n to stop and optionally restart. Compute Engine offers a notice\n before a VM instance with a GPU attached is stopped, depending on the GPU\n type:\n\n - For most GPUs, Compute Engine provides a 60-minute notice.\n - For GPU families running on AI Hypercomputer Cluster Director, Compute Engine provides a 10-minute notice.\n\n To learn more about these maintenance event notices, read\n [Query metadata\n server for maintenance event notices](/compute/docs/metadata/getting-live-migration-notice).\n\n To learn more about handling host maintenance with GPUs, read\n [Handling host maintenance](/compute/docs/gpus/gpu-host-maintenance)\n in the GPUs documentation.\n- **Cloud TPUs** . [Cloud TPUs](/tpu/docs/tpus) don't support live migration.\n- **Storage-optimized VMs** . Z3 VMs with more than 18 TiB of attached Titanium SSD don't support live migration. The maintenance behavior for these VMs is set to `TERMINATE` and `RESTART`.Compute Engine preserves the data on Titanium SSD during the maintenance event, as described in [Disk persistence following instance termination](/compute/docs/instances/host-maintenance-overview#disk-persistence).\n\n\u003cbr /\u003e\n\nHow does the live migration process work?\n\nWhen a VM is scheduled to live migrate, Compute Engine provides a\n[notification](/compute/docs/metadata/getting-live-migration-notice) so that\nyou can prepare your workloads and applications for this live migration\ndisruption. During live migration, Google Cloud observes a minimum\ndisruption time, which is typically much less than 1 second. If a VM is not\nset to live migrate, Compute Engine terminates the VM during host\nmaintenance. VMs that are set to terminate during a host event\n[stop and (optionally) restart](/compute/docs/instances/host-maintenance-overview#terminate_and_optionally_restart).\n\nWhen Google Cloud migrates a running VM from one host to another, it\nmoves the complete state of the VM from the source to the destination in a way\nthat is transparent to the guest OS and anything communicating with it.\n\nThere are many components involved in making this work seamlessly, but the\nhigh-level steps are shown in the following illustration:\n[](/static/compute/images/live-migration.svg) *Live migration components*\n\nThe process begins with a notification that a VM needs to be moved from its\ncurrent host machine. The notification might start with a file change indicating\nthat a new BIOS version is available, a hardware operation scheduling\nmaintenance, or an automatic signal from an impending hardware failure.\n\nGoogle Cloud's cluster management software constantly watches for these\nevents and schedules them based on policies that control the data centers, such\nas capacity utilization rates and the number of VMs that a single customer can\nmigrate at once.\n\nAfter a VM is selected for migration, Google Cloud provides a\nnotification to the guest that a migration is happening soon. After a waiting\nperiod, a target host is selected and the host is asked to set up a new, empty\n\"target\" VM to receive the migrating \"source\" VM. Authentication is used to\nestablish a connection between the source and the target.\n\nThere are three stages involved in the VM's migration:\n\n1. **Source brownout.** The VM is still executing on the source, while\n most state is sent from the source to the target. For example,\n Google Cloud copies all the guest memory to the target, while\n tracking the pages that have been changed on the source. The time spent in\n source brownout is a function of the size of the guest memory and the rate\n at which pages are being changed.\n\n2. **Blackout.** A very brief moment when the VM is not running anywhere, the\n source VM is paused and all the remaining state required to begin running\n the VM on the target is sent. The VM enters the blackout stage when sending\n state changes during the source brownout stage reaches a point of\n diminishing returns. An algorithm is used that balances numbers of bytes of\n memory being sent against the rate at which the guest VM is making changes.\n\n During blackout events, the system clock appears to jump forward, up to 5\n seconds. If a blackout event exceeds 5 seconds, Google Cloud stops\n and synchronizes the clock using a daemon that is included as part of the\n VM guest packages.\n3. **Target brownout.** The VM executes on the target VM. The source VM\n is present and might provide support for the target VM. For\n example, until the network fabric has caught up with the new location of the\n target VM, the source VM provides forwarding services for packets to and from\n the target VM.\n\nFinally, the migration is complete and the system deletes the source VM. You can\nsee that the migration took place in the [Cloud Logging logs](/compute/docs/instances/monitor-plan-host-maintenance-event#check-logs-for-maintenance)\nfor your VM.\n| **Note:** During live migration, VMs might experience a decrease in performance in disk, CPU, memory, and network utilization for a short period of time.\n\nLive migration of sole-tenant VMs\n\nAs your workload runs, you might want to move VMs to a different sole-tenant\nnode or node group. If you move a VM to a group of nodes, Compute Engine\ndetermines which node to place it on. For information about sole-tenancy, see\n[Sole-tenancy overview](/compute/docs/nodes/sole-tenant-nodes).\n\nTo move sole-tenant VMs to a different node or node group, you can manually\ninitiate a live migration. You can also manually initiate a live migration to\nmove a VM on a multi-tenant host into a sole-tenant node. For more information,\nsee [Manually live migrate VMs](/compute/docs/nodes/about-manual-live-migration).\n\nWhat's next\n\n- Set [VM host maintenance policy](/compute/docs/instances/setting-vm-host-options)\n options to configure your instances to live migrate.\n\n- Learn how to [get live migration notices](/compute/docs/metadata/getting-live-migration-notice#maintenanceevents)\n so you can trigger tasks that you want to perform prior to a\n maintenance event.\n\n- Read tips for [designing a robust system](/compute/docs/tutorials/robustsystems)\n that can handle service disruptions."]]
