개발자는 클라우드 컴퓨팅 플랫폼에 워크로드를 배포할 때 서비스가 실행되는 기본 하드웨어에 대해 생각하지 않는 경우가 많습니다. '클라우드'라는 이상적인 이미지에서 하드웨어 유지 관리와 물리적 한계는 보이지 않습니다. 하지만 안타깝게도 하드웨어는 때때로 유지보수가 필요하며, 이로 인해 다운타임이 발생할 수 있습니다. 이러한 다운타임을 고객에게 전가하지 않고 클라우드의 약속에 부응하기 위해 Linode는 라이브 마이그레이션이라는 도구를 구현합니다.
실시간 마이그레이션은 Linode 인스턴스가 서비스 중단 없이 물리적 시스템 간에 이동할 수 있도록 하는 기술입니다. 실시간 마이그레이션으로 Linode를 이동하면 해당 Linode의 프로세스에 전환이 표시되지 않습니다. 호스트의 하드웨어에 유지 관리가 필요한 경우 실시간 마이그레이션을 사용하여 해당 호스트의 모든 Linode를 새 호스트로 원활하게 전환할 수 있습니다. 이 마이그레이션이 완료되면 물리적 하드웨어를 복구할 수 있으며 가동 중지 시간은 고객에게 영향을 미치지 않습니다.
저에게 이 기술을 개발하는 것은 클라우드 기술과 비클라우드 기술 사이의 결정적인 순간이자 전환점이었습니다. 나는 라이브 마이그레이션 기술에 대한 연약한 부분을 가지고 있는데, 그 이유는 내 인생의 1 년 이상을 작업했기 때문입니다. 이제 여러분 모두와 이야기를 나눌 수 있습니다.
실시간 마이그레이션 작동 방식
Linode의 실시간 마이그레이션은 대부분의 새로운 프로젝트처럼 시작되었습니다. 많은 연구, 일련의 프로토 타입, 많은 동료 및 관리자의 도움을 받았습니다. 첫 번째 움직임은 QEMU 가 실시간 마이그레이션을 처리하는 방법을 조사하는 것이 었습니다. QEMU는 Linode에서 사용하는 가상화 기술이며 실시간 마이그레이션은 QEMU의 기능입니다. 결과적으로 우리 팀의 초점은 이 기술을 발명하는 것이 아니라 Linode에 가져오는 것이었습니다.
그렇다면 실시간 마이그레이션 기술은 QEMU가 구현 한 방식으로 어떻게 작동합니까? 대답은 4 단계 프로세스입니다.
- 대상 qemu 인스턴스는 소스 qemu 인스턴스에 존재하는 것과 정확히 동일한 매개 변수로 회전됩니다.
- 디스크는 라이브 마이그레이션됩니다. 디스크에 대한 모든 변경 사항은 이 전송이 실행되는 동안에도 전달됩니다.
- RAM이 라이브 마이그레이션되었습니다. RAM 페이지에 대한 모든 변경 사항도 전달되어야 합니다. 이 단계에서도 디스크 데이터 변경 사항이 있는 경우 해당 변경 사항은 대상 QEMU 인스턴스의 디스크에도 복사됩니다.
- 컷오버 지점이 실행됩니다. QEMU가 자신 있게 잘라낼 수 있는 RAM의 페이지가 거의 없다고 판단하면 소스 및 대상 QEMU 인스턴스가 일시 중지됩니다. QEMU는 RAM 및 시스템 상태의 마지막 몇 페이지에 걸쳐 복사합니다. 컴퓨터 상태에는 CPU 캐시와 다음 CPU 명령이 포함됩니다. 그런 다음 QEMU는 대상에 시작하도록 지시하고 대상은 소스가 중단 된 위치에서 바로 시작됩니다.
이 단계에서는 QEMU를 사용하여 실시간 마이그레이션을 높은 수준에서 수행하는 방법을 설명합니다. 그러나 대상 QEMU 인스턴스를 시작하는 방법을 정확하게 지정하는 것은 매우 수동적인 프로세스입니다. 또한 프로세스의 각 작업은 적시에 시작되어야 합니다.
Linode에서 실시간 마이그레이션을 구현하는 방법
QEMU 개발자들이 이미 만든 것을 살펴본 후, Linode에서 이것을 어떻게 활용합니까? 이 질문에 대한 답은 우리 팀의 대부분의 작업이 어디에 있었는지입니다.
라이브 마이그레이션 워크플로우의 1단계에 따라, 들어오는 라이브 마이그레이션을 수락하기 위해 대상 QEMU 인스턴스가 스핀업됩니다. 이 단계를 구현할 때 가장 먼저 생각한 것은 현재 리노드의 구성 프로필을 가져와 대상 머신에서 스핀업하는 것이었습니다. 이론적으로는 간단할 수 있지만, 더 생각해 보면 더 복잡한 시나리오가 드러납니다. 특히, 구성 프로파일은 리노드가 부팅된 방법을 알려주지만 부팅 후 리노드의 전체 상태를 반드시 설명하지는 않습니다. 예를 들어, 사용자가 Block Storage 장치를 리노드에 핫 플러그하여 연결했을 수 있으며, 이는 구성 프로파일에 문서화되지 않습니다.
대상 호스트에서 QEMU 인스턴스를 작성하려면 현재 실행 중인 QEMU 인스턴스의 프로파일을 가져와야 했습니다. QMP 인터페이스를 검사하여 현재 실행 중인 QEMU 인스턴스를 프로파일링했습니다. 이 인터페이스는 QEMU 인스턴스가 배치되는 방식에 대한 정보를 제공합니다. 게스트의 관점에서 인스턴스 내부에서 무슨 일이 일어나고 있는지에 대한 정보는 제공하지 않습니다. 디스크가 연결된 위치와 로컬 SSD 및 블록 스토리지 모두에 대해 가상 디스크가 연결된 가상화된 PCI 슬롯을 알려줍니다. QMP를 쿼리하고 QEMU 인스턴스를 검사 및 검사한 후 대상에서 이 시스템을 재현하는 방법을 정확히 설명하는 프로파일이 작성됩니다.
대상 컴퓨터에서 원본 인스턴스의 모양에 대한 전체 설명을 받습니다. 그런 다음 여기에서 인스턴스를 충실하게 재현할 수 있지만 한 가지 차이점이 있습니다. 차이점은 대상 QEMU 인스턴스가 QEMU에 수신 마이그레이션을 수락하도록 지시하는 옵션으로 부팅된다는 것입니다.
이 시점에서 실시간 마이그레이션 문서화에서 휴식을 취하고 QEMU가 이러한 위업을 달성하는 방법을 설명하는 것으로 전환해야 합니다. QEMU 프로세스 트리는 제어 프로세스 및 여러 작업자 프로세스로 배치됩니다. 작업자 프로세스 중 하나는 QMP 호출 반환 또는 실시간 마이그레이션 처리와 같은 작업을 담당합니다. 다른 프로세스는 게스트 CPU에 일대일로 매핑됩니다. 게스트의 환경은 QEMU의 이 쪽과 격리되어 있으며 자체 독립 시스템으로 작동합니다.
이러한 의미에서 우리가 작업하고있는 3 개의 레이어가 있습니다.
- 레이어 1은 관리 레이어입니다.
- 레이어 2는 우리를 위해 이러한 모든 작업을 처리하는 QEMU 프로세스의 일부입니다. 그리고
- 레이어 3은 Linode 사용자가 상호 작용하는 실제 게스트 레이어입니다.
대상이 부팅되고 들어오는 마이그레이션을 수락할 준비가 되면 대상 하드웨어는 원본 하드웨어에 원본이 데이터 전송을 시작해야 함을 알립니다. 소스는 이 신호를 수신하면 시작되고 소프트웨어에서 QEMU에 디스크 마이그레이션을 시작하도록 지시합니다. 소프트웨어는 디스크 진행 상황을 자율적으로 모니터링하여 완료 시점을 확인합니다. 그런 다음 소프트웨어가 자동으로 RAM 마이그레이션으로 전환되면 디스크가 완료됩니다. 그런 다음 소프트웨어는 RAM 마이그레이션을 다시 자율적으로 모니터링한 다음 RAM 마이그레이션이 완료되면 자동으로 컷오버 모드로 전환합니다. 이 모든 것은 Linode의 40Gbps 네트워크를 통해 발생하므로 네트워크 측면이 상당히 빠릅니다.
컷오버: 중요 섹션
단독형 단계는 실시간 마이그레이션의 중요 섹션이라고도 하며, 이 단계를 이해하는 것은 실시간 마이그레이션을 이해하는 데 가장 중요한 부분입니다.
컷오버 지점에서 QEMU는 대상 머신에서 컷오버하고 실행을 시작할 준비가 되었음을 판별했습니다. 소스 QEMU 인스턴스는 양쪽에 일시 중지하도록 지시합니다. 이것은 몇 가지를 의미합니다.
- 손님에 따라 시간이 멈 춥니 다. 게스트가 NTP(네트워크 시간 프로토콜)와 같은 시간 동기화 서비스를 실행하는 경우 NTP는 실시간 마이그레이션이 완료된 후 시간을 자동으로 다시 동기화합니다. 이는 시스템 시계가 몇 초 늦기 때문입니다.
- 네트워크 요청이 중지됩니다. 이러한 네트워크 요청이 SSH 또는 HTTP와 같은 TCP 기반 인 경우 연결이 손실되지 않습니다. 이러한 네트워크 요청이 라이브 스트리밍 비디오와 같은 UDP 기반인 경우 프레임이 몇 개 손실될 수 있습니다.
시간 및 네트워크 요청이 중지되므로 가능한 한 빨리 컷오버가 발생하기를 원합니다. 그러나 컷오버가 성공했는지 확인하기 위해 먼저 확인해야 할 몇 가지 사항이 있습니다.
- 실시간 마이그레이션이 오류 없이 완료되었는지 확인합니다. 오류가 발생하면 롤백하고 소스 Linode의 일시 중지를 해제하고 더 이상 진행하지 않습니다. 이 점은 특히 개발 과정에서 해결하는 데 많은 시행 착오가 필요했고 많은 고통의 원인 이었지만 우리 팀은 마침내 그 바닥에 도달했습니다.
- 네트워킹이 소스에서 꺼지고 대상에서 제대로 시작되는지 확인합니다.
- 나머지 인프라에 이 Linode가 현재 상주하고 있는 물리적 시스템이 무엇인지 정확히 알려주십시오.
컷오버에는 시간 제한이 있으므로 이 단계를 신속하게 완료하고자 합니다. 이러한 사항이 해결되면 컷오버가 완료됩니다. 소스 Linode는 자동으로 완료된 신호를 받고 목적지에 시작하도록 지시합니다. 목적지 Linode는 중단된 위치에서 바로 픽업합니다. 원본과 대상의 나머지 항목은 모두 정리됩니다. 대상 Linode를 향후 어느 시점에서 다시 라이브 마이그레이션해야 하는 경우 프로세스를 반복할 수 있습니다.
엣지 케이스 개요
이 프로세스의 대부분은 구현하기 쉬웠지만 실시간 마이그레이션의 개발은 엣지 케이스에 의해 확장되었습니다. 이 프로젝트를 완료한 데 대한 많은 공로는 완성된 도구의 비전을 보고 작업을 완료하기 위해 리소스를 할당한 관리 팀과 프로젝트를 끝까지 본 직원에게 돌아갑니다.
다음은 엣지 케이스가 발생한 몇 가지 영역입니다.
- Linode 고객 지원 및 하드웨어 운영 팀을 위해 실시간 마이그레이션을 오케스트레이션하기 위한 내부 도구를 구축해야 했습니다. 이것은 당시 우리가 가지고 있었고 사용했던 다른 기존 도구와 유사했지만 구축에 많은 개발 노력이 필요할 정도로 충분히 달랐습니다.
- 이 도구는 데이터 센터의 전체 하드웨어 플릿을 자동으로 살펴보고 각 라이브 마이그레이션 Linode의 대상이 되어야 하는 호스트를 파악해야 합니다. 이 선택을 할 때 관련 사양에는 사용 가능한 SSD 스토리지 공간 및 RAM 할당이 포함됩니다.
- 대상 머신의 물리적 프로세서는 들어오는 Linode와 호환되어야 합니다. 특히 CPU에는 사용자의 소프트웨어가 활용할 수 있는 기능(CPU 플래그라고도 함)이 있을 수 있습니다 . 예를 들어 이러한 기능 중 하나는 하드웨어 가속 암호화를 제공하는 aes입니다. 실시간 마이그레이션을 위한 대상의 CPU는 원본 컴퓨터의 CPU 플래그를 지원해야 합니다. 이것은 매우 복잡한 엣지 케이스로 판명되었으며 다음 섹션에서는이 문제에 대한 해결책을 설명합니다.
- 최종 사용자 개입 또는 실시간 마이그레이션 중 네트워킹 손실을 포함한 오류 사례를 정상적으로 처리합니다. 이러한 실패 사례는 이 게시물의 뒷부분에 자세히 열거되어 있습니다.
- 지속적인 프로세스인 Linode 플랫폼의 변경 사항을 따라잡습니다. 현재와 미래에 Linode에서 지원하는 모든 기능에 대해 해당 기능이 실시간 마이그레이션과 호환되는지 확인해야 합니다. 이 과제는 이 게시물의 끝에 설명되어 있습니다.
CPU 플래그
QEMU에는 게스트 운영 체제에 CPU를 제공하는 방법에 대한 다양한 옵션이 있습니다. 이러한 옵션 중 하나는 호스트 CPU의 모델 번호 및 기능 (CPU 플래그라고도 함)을 게스트에 직접 전달하는 것입니다. 이 옵션을 선택하면 게스트는 방해받지 않는 모든 전력을 사용할 수 있습니다. KVM 가상화 시스템이 허용합니다. 언제 KVM Linode (실시간 마이그레이션 이전)에서 처음 채택되었으며 이 옵션은 성능을 최대화하기 위해 선택되었습니다. 그러나 이 결정은 나중에 실시간 마이그레이션을 개발하는 동안 많은 문제를 제기했습니다.
실시간 마이그레이션에 대한 테스트 환경에서 원본 호스트와 대상 호스트는 두 개의 동일한 컴퓨터였습니다. 현실 세계에서 우리의 하드웨어 플릿은 100% 동일하지 않으며 시스템 간에 차이가 있어 다른 CPU 플래그가 존재할 수 있습니다. 프로그램이 Linode의 운영 체제 내부에로드 될 때 Linode는 해당 프로그램에 CPU 플래그를 제공하고 프로그램은 소프트웨어의 특정 섹션을 메모리에로드하여 해당 플래그를 활용하기 때문에 중요합니다. Linode가 해당 CPU 플래그를 지원하지 않는 대상 시스템으로 실시간 마이그레이션되면 프로그램이 충돌합니다. 이로 인해 게스트 운영 체제가 충돌하고 Linode가 재부팅될 수 있습니다.
우리는 시스템의 CPU 플래그가 게스트에게 표시되는 방식에 영향을 미치는 세 가지 요소를 발견했습니다.
- CPU를 구입한 시기에 따라 CPU 간에 약간의 차이가 있습니다. 연말에 구입한 CPU는 CPU 제조업체가 새 하드웨어를 출시하는 시기에 따라 연초에 구입한 CPU와 다른 플래그를 가질 수 있습니다. Linode는 용량을 추가하기 위해 지속적으로 새로운 하드웨어를 구매하고 있으며 두 개의 다른 하드웨어 주문에 대한 CPU 모델이 동일하더라도 CPU 플래그가 다를 수 있습니다.
- 다른 리눅스 커널은 QEMU에 다른 플래그를 전달할 수 있습니다. 특히, 실시간 마이그레이션의 소스 시스템에 대한 Linux 커널은 대상 시스템의 Linux 커널과 다른 플래그를 QEMU에 전달할 수 있습니다. 원본 컴퓨터에서 Linux 커널을 업데이트하려면 재부팅이 필요하므로 실시간 마이그레이션을 진행하기 전에 커널을 업그레이드하여 이 불일치를 해결할 수 없습니다.
- 마찬가지로 다른 QEMU 버전이 표시되는 CPU 플래그에 영향을 줄 수 있습니다. QEMU를 업데이트하려면 컴퓨터를 재부팅해야 합니다.
따라서 실시간 마이그레이션은 CPU 플래그 불일치로 인한 프로그램 충돌을 방지하는 방식으로 구현되어야 했습니다. 두 가지 옵션을 사용할 수 있습니다.
- QEMU에 CPU 플래그를 에뮬레이트하도록 지시 할 수 있습니다. 이로 인해 빠르게 실행되던 소프트웨어가 이제 느리게 실행되어 이유를 조사할 방법이 없습니다.
- 소스에서 CPU 플래그 목록을 수집하고 계속하기 전에 대상에 동일한 플래그가 있는지 확인할 수 있습니다. 이것은 더 복잡하지만 사용자 프로그램의 속도를 유지합니다. 실시간 마이그레이션에 대해 구현한 옵션입니다.
소스 및 대상 CPU 플래그를 일치시키기로 결정한 후 두 가지 방법으로 구성된 벨트 및 멜빵 접근 방식을 사용하여 이 작업을 수행했습니다.
- 첫 번째 방법은 둘 중 더 간단합니다. 모든 CPU 플래그는 소스에서 대상 하드웨어로 전송됩니다. 대상 하드웨어가 새 qemu 인스턴스를 설정할 때 소스 Linode에 있던 플래그가 적어도 모두 있는지 확인합니다. 일치하지 않으면 실시간 마이그레이션이 진행되지 않습니다.
- 두 번째 방법은 훨씬 더 복잡하지만 CPU 플래그 불일치로 인한 마이그레이션 실패를 방지할 수 있습니다. 실시간 마이그레이션을 시작하기 전에 호환되는 CPU 플래그가 있는 하드웨어 목록을 만듭니다. 그런 다음 이 목록에서 대상 컴퓨터가 선택됩니다.
이 두 번째 방법은 신속하게 수행해야하며 많은 복잡성을 수반합니다. 경우에 따라 900 개 이상의 컴퓨터에서 최대 226 개의 CPU 플래그를 확인해야합니다. 이 226 개의 CPU 플래그 검사를 모두 작성하는 것은 매우 어려우며 유지 관리해야합니다. 이 문제는 궁극적으로 Linode의 설립자 인 Chris Aker가 제안한 놀라운 아이디어로 해결되었습니다.
핵심 아이디어는 모든 CPU 플래그 목록을 만들고이를 이진 문자열로 표현하는 것이 었습니다. 그런 다음 비트 및 연산을 사용하여 문자열을 비교할 수 있습니다. 이 알고리즘을 설명하기 위해 다음과 같은 간단한 예제부터 시작하겠습니다. 이것을 고려하십시오 Python 비트 및 다음을 사용하여 두 숫자를 비교하는 코드:
>>> 1 & 1
1
>>> 2 & 3
2
>>> 1 & 3
1비트 및 연산이 이러한 결과를 갖는 이유를 이해하려면 숫자를 이진수로 나타내는 것이 좋습니다. 이진수로 표시되는 숫자 2와 3에 대한 비트 및 연산을 살펴보겠습니다.
>>> # 2: 00000010
>>> # &
>>> # 3: 00000011
>>> # =
>>> # 2: 00000010비트 및 연산은 서로 다른 두 숫자의 이진수 또는 비트를 비교합니다. 위 숫자의 가장 오른쪽 숫자부터 시작하여 왼쪽으로 진행합니다.
- 2와 3의 가장 오른쪽/첫 번째 비트는 각각 0과 1입니다. 비트 단위 및 결과
0 & 1는 0입니다. - 2와 3의 두 번째 오른쪽 비트는 두 숫자 모두에 대해 1입니다. 비트 단위 및 결과
1 & 11입니다. - 이 숫자에 대한 다른 모든 비트는 0이고 0 & 0에 대한 비트 및 결과는 0입니다.
전체 결과에 대한 이진 표현은 다음과 같습니다. 00000010, 2와 같습니다.
실시간 마이그레이션의 경우 CPU 플래그의 전체 목록은 이진 문자열로 표시되며 각 비트는 단일 플래그를 나타냅니다. 비트가 0이면 플래그가 존재하지 않고 비트가 1이면 플래그가 존재합니다. 예를 들어, 하나의 비트는 aes 플래그에 대응할 수 있고, 다른 비트는 mmx 플래그에 대응할 수 있다. 이진 표현에서 이러한 플래그의 특정 위치는 데이터 센터의 컴퓨터에서 유지 관리, 문서화 및 공유됩니다.
이 목록 표현을 유지 관리하는 것은 CPU 플래그의 존재를 가상으로 확인하는 if 문 세트를 유지 관리하는 것보다 훨씬 간단하고 효율적입니다. 예를 들어 총 7개의 CPU 플래그를 추적하고 확인해야 한다고 가정합니다. 이 플래그는 8 비트 숫자로 저장할 수 있습니다 (향후 확장을 위해 1 비트가 남음). 예제 문자열은 다음과 같을 수 있습니다. 00111011여기서 가장 오른쪽 비트는 AES가 사용으로 설정되었음을 나타내고, 가장 오른쪽 두 번째 비트는 MMX가 사용으로 설정되었음을 표시하고, 세 번째 비트는 다른 플래그가 사용 안함으로 설정되었음을 나타냅니다.
다음 코드 조각에서 볼 수 있듯이 이 플래그 조합을 지원하고 한 주기에서 모든 일치 항목을 반환할 하드웨어를 확인할 수 있습니다. if 문 집합을 사용하여 이러한 일치 항목을 계산했다면 이 결과를 얻으려면 훨씬 더 많은 주기가 필요합니다. 원본 컴퓨터에 4개의 CPU 플래그가 있는 실시간 마이그레이션의 경우 일치하는 하드웨어를 찾는 데 203,400주기가 걸립니다.
실시간 마이그레이션 코드는 원본 및 대상 컴퓨터의 CPU 플래그 문자열에 대해 비트 및 작업을 수행합니다. 결과가 원본 컴퓨터의 CPU 플래그 문자열과 같으면 대상 컴퓨터가 호환되는 것입니다. 이것을 고려하십시오 Python 코드 스 니펫 :
>>> # The b'' syntax below represents a binary string
>>>
>>> # The s variable stores the example CPU flag
>>> # string for the source:
>>> s = b'00111011'
>>> # The source CPU flag string is equivalent to the number 59:
>>> int(s.decode(), 2)
59
>>>
>>> # The d variable stores the example CPU flag
>>> # string for the source:
>>> d = b'00111111'
>>> # The destination CPU flag string is equivalent to the number 63:
>>> int(d.decode(), 2)
63
>>>
>>> # The bitwise and operation compares these two numbers:
>>> int(s.decode(), 2) & int(d.decode(), 2) == int(s.decode(), 2)
True
>>> # The previous statement was equivalent to 59 & 63 == 59.
>>>
>>> # Because source & destination == source,
>>> # the machines are compatible위의 코드 조각에서 대상은 소스보다 더 많은 플래그를 지원했습니다. 시스템은 모든 소스의 CPU 플래그가 대상에 있기 때문에 호환되는 것으로 간주되며, 이는 비트 및 연산이 보장하는 것입니다.
이 알고리즘의 결과는 내부 도구에서 호환되는 하드웨어 목록을 작성하는 데 사용됩니다. 이 목록은 고객 지원 및 하드웨어 운영 팀에 표시됩니다. 이러한 팀은 도구를 사용하여 다양한 작업을 오케스트레이션할 수 있습니다.
- 이 도구는 주어진 Linode에 가장 적합한 호환 하드웨어를 선택하는 데 사용할 수 있습니다.
- 목적지를 지정하지 않고 Linode에 대한 실시간 마이그레이션을 시작할 수 있습니다. 동일한 데이터 센터에서 가장 잘 호환되는 하드웨어가 자동으로 선택되고 마이그레이션이 시작됩니다.
- 호스트의 모든 Linode에 대한 실시간 마이그레이션을 단일 작업으로 시작할 수 있습니다. 이 기능은 호스트에서 유지 보수를 수행하기 전에 사용됩니다. 이 도구는 모든 Linode에 대한 대상을 자동으로 선택하고 각 Linode에 대한 실시간 마이그레이션을 오케스트레이션합니다.
- 유지 관리가 필요한 여러 시스템의 목록을 지정할 수 있으며 도구는 호스트 전체의 모든 Linode에 대한 실시간 마이그레이션을 자동으로 오케스트레이션합니다.
소프트웨어를 "그냥 작동"시키는 데 많은 개발 시간이 소요됩니다.
실패 사례
소프트웨어에서 자주 언급되지 않는 기능 중 하나는 오류 사례를 정상적으로 처리하는 것입니다. 소프트웨어는 "그냥 작동"해야 합니다. 소프트웨어를 "그냥 작동"시키는 데 많은 개발 시간이 소요되며, 이는 실시간 마이그레이션의 경우였습니다. 이 도구가 작동하지 않는 모든 방법에 대해 생각하고 이러한 경우를 정상적으로 처리하는 데 많은 시간을 보냈습니다. 다음은 이러한 시나리오 중 일부와 해결 방법입니다.
- 고객이 Linode의 기능에 액세스하려는 경우 Cloud Manager? 예를 들어 사용자는 리노드를 재부팅하거나 Block Storage 볼륨을 연결할 수 있습니다.
- 답변: 고객은 이를 수행할 권한이 있습니다. 실시간 마이그레이션이 중단되고 진행되지 않습니다. 이 해결 방법은 실시간 마이그레이션을 나중에 시도할 수 있기 때문에 적절합니다.
- 대상 Linode가 부팅에 실패하면 어떻게 됩니까?
- 답변: 원본 하드웨어에 알리고 내부 도구를 엔지니어링하여 데이터 센터에서 다른 하드웨어를 자동으로 선택합니다. 또한 원래 대상의 하드웨어를 조사할 수 있도록 운영 팀에 알립니다. 이는 프로덕션에서 발생했으며 실시간 마이그레이션 구현에서 처리되었습니다.
- 마이그레이션 중에 네트워킹이 손실되면 어떻게 되나요?
- 답변: 실시간 마이그레이션의 진행률을 자율적으로 모니터링하고, 마지막 순간에 진행되지 않은 경우 실시간 마이그레이션을 취소하고 운영 팀에 알립니다. 이것은 테스트 환경 외부에서 발생하지 않았지만 이 시나리오에 대한 구현이 준비되었습니다.
- 인터넷의 나머지 부분이 종료되지만 소스 및 대상 하드웨어가 여전히 실행 및 통신하고 소스 또는 대상 Linode가 정상적으로 실행되면 어떻게됩니까?
- 답변: 실시간 마이그레이션이 위험 섹션에 없으면 실시간 마이그레이션을 중지합니다. 그런 다음 나중에 다시 시도하십시오.
- 중요 섹션에 있는 경우 실시간 마이그레이션을 계속합니다. 이는 소스 Linode가 일시 중지되고 작업을 재개하려면 대상 Linode를 시작해야 하기 때문에 중요합니다.
- 이러한 시나리오는 테스트 환경에서 모델링되었으며 규정된 동작이 최선의 조치인 것으로 확인되었습니다.
변화에 발맞추기
수십만 건의 실시간 마이그레이션이 성공한 후 가끔 묻는 질문은 "실시간 마이그레이션은 언제 완료됩니까?" 실시간 마이그레이션은 시간이 지남에 따라 사용이 확장되고 지속적으로 개선되는 기술이므로 프로젝트 종료를 표시하는 것이 반드시 간단한 것은 아닙니다. 이 질문에 답하는 한 가지 방법은 이 프로젝트의 대량 작업이 언제 완료되는지 고려하는 것입니다. 대답은 신뢰할 수 있고 신뢰할 수있는 소프트웨어의 경우 작업이 오랫동안 수행되지 않는다는 것입니다.
시간이 지남에 따라 Linode에 대한 새로운 기능이 개발됨에 따라 해당 기능에 대한 실시간 마이그레이션과의 호환성을 보장하기 위한 작업을 수행해야 합니다. 일부 기능을 도입할 때 실시간 마이그레이션에 대한 새로운 개발 작업이 없으며 실시간 마이그레이션이 여전히 예상대로 작동하는지 테스트하기만 하면 됩니다. 다른 경우에는 실시간 마이그레이션 호환성 작업이 새 기능 개발 초기에 작업으로 표시됩니다.
소프트웨어의 모든 것과 마찬가지로 연구를 통해 발견되는 더 나은 구현 방법이 항상 있습니다. 예를 들어 Live Migrations의 통합에 대한 보다 모듈식 접근 방식은 장기적으로 유지 관리를 덜 제공할 수 있습니다. 또는 실시간 마이그레이션 기능을 하위 수준 코드에 혼합하면 향후 Linode 기능을 위해 즉시 사용할 수 있도록 하는 데 도움이 될 수 있습니다. 우리 팀은 이러한 모든 옵션을 고려하고 있으며 Linode 플랫폼을 구동하는 도구는 계속 진화 할 살아있는 실체입니다.
내용