"마이그레이션" 작업: DataLine 클라우드로 이동하는 방법

약 7년 전, 최초의 프로젝트가 간단하고 소박하게 클라우드로 이전되었습니다. 가상 머신 이미지가 FTP 서버에 업로드되었거나 하드 드라이브에 전달되었습니다. 그런 다음 특수 가져오기 서버를 통해 VM이 클라우드에 업로드되었습니다.

클라이언트가 하루나 이틀 동안 가상 머신을 끄는 것이 문제가 되지 않는 경우(또는 다른 옵션이 없는 경우) 이 작업을 수행할 수 있습니다. 그러나 가동 중지 시간이 최대 XNUMX시간이면 이 방법은 작동하지 않습니다. 오늘은 가동 중지 시간을 최소화하면서 클라우드로 마이그레이션하는 데 도움이 되는 도구와 마이그레이션 프로세스 자체의 작동 방식을 알려 드리겠습니다.

Veeam 백업 및 복제를 통한 마이그레이션

백업 및 복제본 생성을 위한 도구인 Veeam Backup and Replication은 누구나 알고 있습니다. 우리는 이를 사이트 간 마이그레이션과 개인 가상화에서 클라우드로 클라이언트를 전송하는 데 사용합니다. 클라이언트의 가상 머신이 vCenter에 복제된 후 엔지니어가 이를 vCloud Director에 추가합니다.

기본 복제는 전원이 켜진 가상 시스템에서 발생합니다. 합의된 시간에 클라이언트 측 시스템이 꺼집니다. 첫 번째 복제 이후 발생한 변경 사항을 전달하기 위해 복제가 다시 실행됩니다. 그 후 가상 머신이 클라우드에서 시작됩니다.

일반적으로 클라이언트 인프라에서 머신을 끄는 순간부터 클라우드에서 머신을 켜는 순간까지 15분을 넘지 않고 20~XNUMX분이 소요됩니다.

이 경우 원래 가상 머신은 클라이언트 사이트에 남아 있습니다. 갑자기 문제가 발생하면 언제든지 롤백하고 켤 수 있습니다. 이 방법은 Veeam이 필요하지 않다는 점에서도 고객에게 편리합니다.

사례 1
클라이언트는 VMware 기반의 자체 가상 인프라(40TB 용량의 VM 30개)를 보유하고 있었습니다. 클러스터가 구축된 장비는 이미 노후화됐고, 고객은 굳이 새로 구입하지 않기로 결정하고 퍼블릭 클라우드로 이전했다. 중요한 시스템의 가동 중지 시간 요구 사항은 30시간을 넘지 않았습니다. Veeam 복제가 도구로 선택되었습니다. 또 다른 장점은 고객의 인터넷 제공업체가 우리 데이터 센터에 있어 좋은 채널 구성이 가능했다는 것입니다. 마이그레이션에는 약 한 달이 걸렸으며 전환 중 가동 중지 시간은 가상 머신 그룹당 최대 XNUMX분이었습니다.

Veeam Cloud Connect로 마이그레이션

Veeam Cloud Connect는 가상 머신 복제를 설정하고 서비스 제공업체의 클라우드에서 복제본을 실행하는 데 도움이 되는 도구입니다. 업데이트 후 2019 올해에는 가상 머신을 vCloud Director에 직접 복제하는 것이 가능해졌습니다. 유일한 조건은 클라이언트 측에서 Veeam Backup and Replication이 버전 9 이상을 배포해야 한다는 것입니다. 간략히(상세 버전) 여기에), 전체 과정은 다음과 같습니다.

vCloud Director에서는 필요한 리소스와 네트워크를 갖춘 조직이 생성됩니다. Veeam Cloud Connect에서 계정을 생성하면 클라이언트가 Veeam B&R에서 해당 계정에 연결하고 DataLine 제공업체와 조직을 선택하고 복제 작업을 구성합니다. 이러한 마이그레이션 중에 가동 중지 시간이 15~20분 이내에 발생한다는 사실 외에도 클라이언트는 공급자의 기술 지원에 전혀 의존하지 않고 전체 프로세스를 독립적으로 관리합니다. 복제 작업 생성, 복제 자체 끄기 머신을 새로 설치하고 새 사이트에서 시작합니다.

사례 2
마이그레이션이 계획된 클라이언트의 인프라는 벨로루시에 있었습니다. 인터넷 채널이 90Mbit/초라는 사실에도 불구하고 총 용량이 27TB인 100개의 VM을 전송해야 했습니다. 백업을 만들고 즉시 클라우드에 업로드하는 경우 일부 VM의 경우 며칠이 걸릴 수 있습니다. 이 시간 동안 VM에서 큰 델타가 증가하여 시스템 성능에 부정적인 영향을 미칠 수 있으며, 더 나쁜 경우 데이터 저장소의 공간이 부족해질 수 있습니다. 우리는 다음과 같이 진행했습니다. 먼저 클라이언트는 로컬 전체 백업을 수행하고 Veeam Cloud Connect를 통해 해당 복사본을 클라우드로 전송했습니다. 그런 다음 증분을 만들어 클라우드로 전송했습니다. 원래 가상 머신은 계속 실행되었습니다. VM을 종료한 후 클라이언트는 또 다른 증분을 만들어 클라우드로 전송했습니다. 우리 쪽에서는 전체 백업에서 가상 머신을 배포한 다음 여기에 2개의 증분을 롤업했습니다. 이 방식을 통해 궁극적으로 당사 사이트로 전환할 때 다운타임을 XNUMX시간으로 최소화할 수 있었습니다.

VMware vCloud 가용성을 통한 마이그레이션

올해 3.0월 VMware는 vCloud Availability XNUMX을 출시했습니다. 이를 통해 서로 다른 클라우드(vCloud Director - vCloud Director) 간에 가상 머신을 마이그레이션하고 개인 클라이언트 가상화 스탠드에서 클라우드(vCenter - vCloud Director)로 마이그레이션할 수 있습니다. 가장 편리한 점은 vCloud Director 인터페이스와의 통합입니다. 이는 복제 관리 프로세스를 크게 단순화하고 전환 중 다운타임을 최소화합니다.

이 도구를 사용하여 클라이언트 중 하나를 모스크바 클라우드에서 상트페테르부르크의 클라우드로 마이그레이션했습니다. 총 용량이 18TB인 14개의 가상 머신을 전송해야 했습니다. 상트페테르부르크 클라우드에 클라이언트를 위한 조직이 만들어졌고 필요한 네트워크가 구성되었습니다. 다음으로 클라이언트는 vCloud Director 인터페이스에서 vCloud Availability 설정으로 이동하여 복제 작업을 생성하고 편리한 시간에 상트페테르부르크 사이트로 전환했습니다. 전환 중 다운타임은 12분이었습니다.

상트페테르부르크와 모스크바의 DataLine 클라우드 간 마이그레이션 계획.

vCloud Availability에는 클라이언트 사이트에서 클라우드로 VM을 마이그레이션하는 메커니즘이 있습니다. 이를 위해 특별한 vCloud Availability 애플리케이션이 클라이언트의 vCenter에 배포됩니다. 간단한 설정 후 클라우드에 연결하고 마이그레이션 작업을 구성합니다. 또한 클라이언트는 전체 프로세스를 독립적으로 관리하며 마이그레이션 시간을 최소화합니다.

가상 머신을 개인 설치에서 클라우드로 마이그레이션하기 위한 계획입니다.

VMware vCloud Availability에는 그 밖에도 다양한 사용 사례가 있습니다. 이에 대해서는 곧 별도의 기사에서 다루겠습니다.

마이그레이션 준비

도구를 선택하고 실제로 마이그레이션을 시작하려면 다음 사항을 결정해야 합니다.

우리는 어디에서 마이그레이션합니까? 비공개 솔루션에서 마이그레이션하는 경우 도구를 완전히 자유롭게 선택할 수 있습니다. 공급자로부터 멀어지면 더 복잡해집니다. 두 공급자의 인프라를 연결하고 단순히 VM을 끌어서 놓는 것은 보안상의 이유로 작동하지 않을 가능성이 높습니다. 때로는 고객이 거절하려는 제공자가 장난을 치기 시작하고 시간을 지체하기도 합니다. VM을 디스크 및 FTP에 업로드하거나 애플리케이션 수준에서 마이그레이션하는 등 기존 방식으로 공급자로부터 벗어날 수 있습니다. 후자의 이름은 조건부이며 다음과 같습니다.

사례 3
고객의 SAP 시스템을 유럽 공급자(34TB 용량의 VM 54개)로부터 마이그레이션해야 했습니다. 클라이언트에는 클라우드의 리소스가 할당되었습니다. 우리와 유럽 공급자의 인프라 사이에 네트워크 연결이 구성되었습니다. 필요한 구성이 롤오버되어 애플리케이션 서버가 재배포되었습니다. 대규모 데이터베이스는 클라우드에 백업을 업로드하여 마이그레이션되었습니다. 다음으로, 우리 사이트와 원본 사이트의 데이터베이스 간에 복제가 구성되었습니다. 합의된 시간에 우리는 클라우드의 데이터베이스로 전환했습니다.

데이터 볼륨 및 인터넷 채널. 우리는 일반적으로 클라이언트에게 메모리, CPU 및 디스크 매개변수가 포함된 시스템별 업로드를 제공하도록 요청합니다. 채널이 가상 머신의 복제본이나 백업을 직접 보내기에 충분한지 평가합니다.

허용되는 가동 중지 시간. 다양한 시스템 및 그에 따른 가상 머신의 경우 비즈니스 중요성에 따라 다를 수 있습니다. 일반적으로 고객은 마이그레이션 중 가동 중지 시간에 대한 미리 준비된 요구 사항을 제공하며 이를 기반으로 적절한 도구와 마이그레이션 계획을 선택합니다. 우리는 사소한 다운타임이라도 클라이언트의 최종 사용자가 눈치채지 못하도록 밤이나 주말에 최종 전환 일정을 잡으려고 노력합니다.

이 데이터를 기반으로 도구를 선택하고 마이그레이션 자체를 시작할 수 있습니다. 다음에 일어나는 일은 다음과 같습니다.

1. 네트워크 연결을 설정합니다. 우리는 클라우드와 고객 인프라 간의 네트워크 연결을 구성합니다. 가상 머신은 이 네트워크를 통해 복사됩니다. Veeam 백업 및 복제를 사용하는 경우 이는 전용 채널이며 VPN 채널인 경우는 적습니다. Veeam Cloud Connect의 경우 모든 것이 인터넷이나 동일한 전용 채널을 통해 전달됩니다.

   그런 다음 클라우드의 VM에 대해 네트워크가 구성됩니다. 자동차는 대개 그룹으로 하루 이상 이동합니다. VM을 가져와 실행한 후에는 원래 사이트에 남아 있는 시스템과 통신해야 합니다.

2. 마이그레이션 일정. 자동차가 많을 때에는 그룹으로 나누어 일괄적으로 운반하는 것이 합리적입니다. 고객과 함께 우리는 언제 어떤 시스템을 이동할 것인지, 최종 복제 및 새 사이트로의 전환이 언제 수행될 것인지를 지정하는 계획에 동의합니다.
3. 마이그레이션을 테스트합니다. 테스트 가상 머신을 마이그레이션하고 사이트 간 네트워크 연결, 소스 사이트의 머신에 대한 가상 머신 가용성, 계정 권한 등 모든 것이 올바르게 구성되었는지 확인합니다. 이 테스트는 전투 이동 단계에서 장애를 방지하는 데 도움이 됩니다.

그게 전부입니다. 댓글로 질문하고 마이그레이션 경험에 대해 알려주세요.

출처 : habr.com