Azure Storage Mover의 안정성

아티클
11/20/2024

이 문서에서는 Azure Storage Mover의 안정성 지원을 설명하고 가용성 영역을 통한 지역 내 복원력과 지역 간 재해 복구 및 비즈니스 연속성을 모두 설명합니다. Azure의 안정성 원칙에 대한 자세한 개요는 Azure 안정성을 참조하세요.

가용성 영역 지원

가용성 영역은 각 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 장애 조치(failover)될 수 있습니다.

Azure의 가용성 영역에 대한 자세한 내용은 가용성 영역이란?을 참조하세요.

Azure Storage Mover는 영역 중복 배포 모델을 지원합니다.

Azure Storage Mover 리소스를 배포할 때 리소스의 인스턴스 메타데이터가 저장되는 특정 지역을 선택해야 합니다.

지역에서 가용성 영역을 지원하는 경우 인스턴스 메타데이터는 해당 지역 내의 여러 가용성 영역에서 자동으로 복제됩니다.

Important

Azure Storage Mover 인스턴스 메타데이터에는 프로젝트, 엔드포인트, 에이전트, 작업 정의 및 작업 실행 기록이 포함되지만 마이그레이션할 실제 데이터는 포함되지 않습니다. 마이그레이션 대상으로 사용되는 Azure Storage 계정에는 자체 안정성 지원이 있습니다.

필수 조건

가용성 영역 지원을 사용하여 배포하려면 가용성 영역을 지원하는 지역을 선택해야 합니다. 가용성 영역을 지원하는 지역을 확인하려면 지원되는 지역 목록을 참조하세요.
(선택 사항) 대상 스토리지 계정이 가용성 영역을 지원하지 않고 해당 계정을 AZ 지원으로 마이그레이션하려는 경우 Azure Storage 계정을 가용성 영역 지원으로 마이그레이션을 참조하세요.

영역 다운 환경

영역 전체 가동 중단 동안에는 영역 복구 중에 아무 작업도 필요하지 않습니다. Azure Storage Mover는 정상 영역을 자동으로 활용하도록 자체적으로 복구하고 균형을 다시 조정하도록 디자인되었습니다.

마이그레이션 대상 스토리지 계정에는 자체 복구 단계가 필요할 수 있습니다. 이 요구 사항은 각 스토리지 계정에 대해 선택한 중복 옵션에 따라 달라집니다. 스토리지 계정 재해 복구 가이드를 참조하여 더 많은 단계가 필요한지 확인합니다.

중복 옵션 대신 로컬 스토리지를 선택한 경우 중단 중에 마이그레이션에 사용할 새 스토리지 계정을 만들어야 할 수 있습니다.

지역 간 재해 복구 및 비즈니스 연속성

DR(재해 복구)은 가동 중지 시간 및 데이터 손실을 초래하는 자연 재해 또는 실패한 배포와 같은 영향이 큰 이벤트로부터 복구하는 것입니다. 원인에 관계없이 최상의 재해 해결책은 잘 정의되고 테스트된 DR 계획과 DR을 적극적으로 지원하는 애플리케이션 디자인입니다. 재해 복구 계획을 만들기 전에 재해 복구 전략을 디자인하기 위한 권장 사항을 참조하세요.

DR과 관련하여 Microsoft는 공유 책임 모델을 사용합니다. 공유 책임 모델에서 Microsoft는 기준 인프라 및 플랫폼 서비스를 사용할 수 있도록 보장합니다. 동시에 많은 Azure 서비스는 데이터를 자동으로 복제하거나 실패한 지역에서 대체하여 사용하도록 설정된 다른 지역으로 교차 복제하지 않습니다. 이러한 서비스의 경우 워크로드에 적합한 재해 복구 계획을 설정할 책임이 있습니다. Azure PaaS(Platform as a Service) 제품에서 실행되는 대부분의 서비스는 DR을 지원하는 기능과 지침을 제공하며, 서비스별 기능을 사용하여 빠른 복구를 지원하여 DR 계획을 개발하는 데 도움이 될 수 있습니다.

Storage Mover 에이전트가 등록되면 Storage Mover 리소스가 등록된 지역에 연결됩니다. 에이전트의 Azure 지역에서 중단이 발생하는 경우 에이전트 자체는 영향을 받지 않지만 Azure를 사용하는 관리 작업을 완료하지 못할 수 있습니다. 또한 영향을 받는 지역 내에 있는 스토리지 계정으로의 활성 데이터 마이그레이션은 실패할 수 있습니다.

Storage Mover는 다음 두 가지 형태의 재해 복구를 지원합니다.

Azure 시작 재해 복구
고객이 시작한 재해 복구

Important

온-프레미스 데이터 원본에 대한 재해 복구는 고객의 책임입니다.

Azure 시작 재해 복구

Azure 시작 재해 복구는 지역 쌍이 있는 지역에만 적용됩니다. 지역 간 복제를 활용하는 경우 인스턴스 메타데이터는 각 지역에 복제되지만 해당 지리적 위치를 벗어나는 것은 허용되지 않습니다.

Azure Storage Mover는 Cosmos DB를 사용하여 인스턴스 메타데이터를 저장합니다. Azure Cosmos DB에서 복구할 수 없는 재해가 발생하는 경우에만 데이터 손실이 발생할 수 있습니다. 자세한 내용은 지역 중단을 참조하세요. Azure 시작 복구는 활성-수동이며, 지역의 전체 복구에는 최대 24시간이 소요될 수 있습니다.

고객이 시작한 재해 복구

고객이 시작한 재해 복구는 쌍으로 연결된 지역으로 제한되지 않습니다.

지역 가동 중단이 발생하기 전:

가용성 영역을 지원하는 지역에 Storage Mover 리소스를 만들어 영역 중복 Storage Mover를 배포합니다.
일정에 따라 또는 상당한 변경을 수행한 후 주기적으로 Storage Mover 리소스의 스냅샷을 만듭니다. 버전 제어 시스템을 사용하여 스냅샷을 저장하는 것은 스냅샷 기록을 저장하고 추적하는 좋은 방법입니다. 새 지역에서 리소스를 복구해야 하는 재해 발생 시 마지막으로 성공한 스냅샷을 사용합니다.

지역 가동 중단 동안:

다음 두 가지 작업 중 하나를 수행할 수 있습니다.

Azure가 지역을 복구할 때까지 기다리도록 선택합니다.
리소스를 다른 지역에 다시 배포하여 가동 중지 시간을 최소화합니다. 중단 동안 리소스에 대한 액세스가 영향을 받을 수 있으므로 리소스의 마지막으로 성공한 스냅샷을 사용하려고 합니다.

팁

이러한 전략 중 하나는 재해가 발생하기 전에 추가 단계를 수행해야 할 수 있으므로 그에 따라 검토하고 계획해야 합니다.

다른 지역에 리소스 배포

ARM(Azure Resource Manager) 템플릿으로 리소스를 내보내는 방법에 대한 자세한 지침은 템플릿 내보내기에 대한 설명서를 참조하세요.

Storage Mover 및 관련 리소스가 추가 리소스가 없는 컨테이너에 있는 경우 리소스 그룹 내보내기를 수행하여 현재 상태를 캡처해야 합니다. 그러나 리소스 그룹에 관련 없는 리소스가 포함된 경우 템플릿에서 리소스를 제거하거나 제외해야 할 수 있습니다.

기존 에이전트는 다른 지역에 다시 배포할 수 없습니다. 원래 구성된 지역에서 중단이 발생하는 경우 에이전트를 완전히 등록 취소했다가 다시 등록할 수는 없습니다. 이 문서에서는 새 에이전트가 새 지역 내에 등록되어 있다고 가정합니다.

내보낸 템플릿을 재해 복구에 사용하려면 템플릿을 약간 변경해야 합니다.

먼저 템플릿에서 Microsoft.StorageMover/agents 및 Microsoft.HybridCompute/machines 리소스를 제거합니다. 이러한 리소스에 대한 종속성 참조도 제거해야 합니다.
다음으로, 모든 작업 정의에서 agentResourceId 속성을 제거합니다. 배포 후에 새 에이전트에 할당해야 합니다.
에이전트 및 하이브리드 컴퓨팅 머신 리소스에 대한 모든 참조를 제거한 후 최상위 Storage Mover 리소스의 위치 속성을 업데이트합니다. 현재 배포된 지역의 이름을 새 지역의 이름으로 바꿉니다.
마지막으로, 기존 스토리지 계정 리소스 ID를 유지할지 여부를 결정합니다. 필요한 경우 다른 스토리지 계정으로 바꿉니다.

이전 단계를 완료하고 템플릿 매개 변수가 올바른지 확인하면 템플릿을 새 지역에 배포할 준비가 된 것입니다. 템플릿의 위치 속성과 기본 지역이 동일한 새 리소스 그룹에 템플릿을 배포해야 합니다.

새 에이전트 등록

Azure Storage Mover 에이전트 배포 문서의 단계에 따라 새 Storage Mover 리소스에 새 에이전트를 등록합니다.

작업 정의에 에이전트 할당

새 에이전트를 등록하고 온라인으로 보고한 후 Azure Portal 또는 PowerShell을 사용하여 기존 작업 정의를 새 에이전트에 연결합니다. 편의를 위해 다음과 같은 PowerShell 예제가 제공됩니다.

프로젝트에 대한 작업 정의에 액세스하는 방법에 대한 지침은 새 마이그레이션 작업 정의를 참조하세요.


## Update the agent in a job definition resource
$resourceGroupName  = "[Your resource group name]"
$storageMoverName   = "[Your storage mover name]"
$projectName        = "[Your project name]"
$jobDefName         = "[Your job definition name]"
$agentName          = "[The name of an agent previously registered to the same storage mover resource]"

Update-AzStorageMoverJobDefinition `
    -ResourceGroupName $resourceGroupName `
    -StorageMoverName $storageMoverName `
    -ProjectName $projectName `
    -Name $jobDefName `
    -AgentName $agentName

에이전트에 대상 스토리지 컨테이너에 대한 액세스 권한 부여

마이그레이션 작업을 성공적으로 수행하려면 관리 ID에 데이터 기여자 역할을 할당해야 합니다. 하이브리드 컴퓨팅 리소스의 시스템 관리 ID에 대상 스토리지 계정 리소스에 대한 액세스 권한을 할당합니다. 관리 ID에 리소스에 대한 액세스 권한 할당 문서에서는 대상 리소스에 대한 액세스 권한을 부여하는 방법에 대한 지침을 제공합니다.

이제 새로 배포된 Storage Mover 리소스를 사용하여 마이그레이션 작업을 시작할 준비가 되었습니다.

다음을 통해 공유