Azure Data Box를 사용하여 데이터를 Azure 파일 동기화로 오프라인 마이그레이션
이 마이그레이션 문서는 Azure 파일 동기화 및 Azure Data Box라는 키워드에 적용되는 여러 문서 중 하나입니다. 이 문서가 다음 시나리오에 적용되는지 확인합니다.
- 데이터 원본: Azure 파일 동기화가 설치되고 원본 파일 세트를 가리키는 Windows Server 2012 R2 이상입니다.
- 마이그레이션 경로: Windows Server 2012 R2 이상 ⇒ Data Box ⇒ Azure 파일 공유 ⇒ Windows Server 원본 파일 위치와 동기화입니다.
- 온-프레미스 파일 캐싱: 예, 최종 목표는 현재 위치에서 파일을 동기화하는 Azure 파일 동기화 배포입니다.
Azure Data Box를 사용하는 것은 온-프레미스 Windows Server에서 대량의 데이터를 이동하여 Azure 파일 공유를 분리한 다음, 필요에 따라 원래 원본 서버에서 Azure 파일 동기화를 추가하는 실행 가능한 경로입니다.
다양한 마이그레이션 경로를 사용할 수 있으므로 올바른 마이그레이션 경로를 따르는 것이 중요합니다.
- 데이터가 Windows Server 2012 R2 이상에 있고, AFS를 해당 서버에 설치하고, 원래 위치를 동기화하려고 합니다. 이 시나리오에서는 모든 파일을 업로드하지 않고, Data Box를 대신 사용한 다음, 파일 동기화를 지속적인 변경에 사용하려고 합니다. 이 시나리오에 해당하는 경우 이 문서에서 마이그레이션 경로에 대해 설명합니다.
- 데이터가 AFS를 설치하지 않거나 설치할 수 없는 원본에 있습니다. 예를 들어 NAS(네트워크 연결 스토리지) 또는 다른 서버가 있습니다. 대신 비어 있는 새 서버를 만들고 해당 서버에서 Azure 파일 동기화를 사용합니다. 이 시나리오에 해당하는 경우 이 문서는 적절한 마이그레이션 가이드가 아닙니다. 대신 Data Box를 통해 NAS에서 Azure 파일 동기화로 마이그레이션을 확인하거나 마이그레이션 개요 페이지에서 이 시나리오에 가장 적합한 가이드를 찾습니다.
- 다른 모든 시나리오의 경우 Azure 파일 공유 마이그레이션 가이드의 표를 확인합니다. 이 개요 페이지는 모든 마이그레이션 시나리오에 적합한 시작점을 제공합니다.
마이그레이션 개요
마이그레이션 프로세스는 몇 가지 단계로 구성됩니다. 다음을 수행해야 합니다.
- 스토리지 계정 및 파일 공유를 배포합니다.
- 하나 이상의 Azure Data Box 디바이스를 배포하여 Windows Server 2012 R2 이상에서 데이터를 이동합니다.
- 신뢰할 수 있는 업로드를 사용하여 Azure 파일 동기화를 구성합니다.
다음 섹션에서는 마이그레이션 프로세스의 단계에 대해 자세히 설명합니다.
팁
이 문서로 돌아가려면 화면 오른쪽의 탐색 영역을 사용하여 이전에 중단한 마이그레이션 단계로 건너뛰세요.
1단계: 필요한 Azure 파일 공유 수 결정
이 마이그레이션 가이드에서는 파일이 포함된 온-프레미스 DAS(직접 연결 스토리지)를 계속 사용해야 합니다. Data Box는 해당 위치에서 공급되고, Azure 파일 동기화가 해당 위치에도 설정됩니다. NAS(네트워크 연결 스토리지)는 이 마이그레이션 경로에서 작동하지 않습니다.
각각 파일 세트가 동기화되는 위치를 결정하는 Azure 파일 동기화 동기화 그룹을 설정하여 동기화할 항목을 결정합니다. 각 동기화 그룹에는 서버 엔드포인트라고 하는 하나 이상의 서버 위치와 클라우드 엔드포인트라고 하는 하나의 Azure 파일 공유 위치가 있습니다.
파일 세트의 하위 경로를 각각의 고유한 Azure 파일 공유에 동기화할 수 있습니다. 즉, 파일 세트를 완전히 포함하도록 여러 동기화 그룹을 설정합니다. 섹션의 나머지 부분에서는 옵션에 대해 설명합니다. 데이터를 재구성해야 하는 경우 이 가이드를 계속 진행하거나 Data Box를 주문하거나 동기화를 설정하기 전에 첫 번째 단계로 재구성해야 합니다.
주의
마이그레이션을 시작하기 전에 파일 및 폴더 구조를 장기적으로 유지하도록 구성해야 합니다. 마이그레이션하는 동안 불필요한 폴더를 재구성하지 않도록 방지합니다. 이렇게 하면 파일을 초기에 Azure로 대량 전송하는 데 Azure Data Box를 사용하는 경우의 긍정적인 효과가 줄어듭니다.
이 단계에서는 필요한 Azure 파일 공유 수를 결정합니다. 단일 Windows Server 인스턴스(또는 클러스터)는 최대 30개의 Azure 파일 공유와 동기화될 수 있습니다.
현재 로컬에서 SMB 공유로 사용자 및 앱과 공유하는 볼륨에는 이보다 많은 폴더가 있을 수 있습니다. 이 시나리오는 Azure 파일 공유에 1:1 매핑되는 온-프레미스 공유를 생각해보면 쉽게 상상할 수 있습니다. 단일 Windows Server 인스턴스에 대해 30개 미만의 충분히 적은 수의 공유가 있는 경우 1:1 매핑을 권장합니다.
30개보다 많은 공유가 있는 경우 온-프레미스 공유를 Azure 파일 공유에 1:1로 매핑할 필요가 없는 경우가 많습니다. 다음 옵션을 고려합니다.
공유 그룹화
예를 들어 HR(인사) 부서에 15개의 공유가 있는 경우 모든 HR 데이터를 단일 Azure 파일 공유에 저장하는 것을 고려할 수 있습니다. 여러 온-프레미스 공유를 하나의 Azure 파일 공유에 저장하더라도 로컬 Windows Server 인스턴스에 일반적인 15개 SMB 공유를 만들 수 없는 것이 아닙니다. 이는 이러한 15개 공유의 루트 폴더를 공통 폴더 아래의 하위 폴더로 구성한다는 것을 의미할 뿐입니다. 그런 다음 이 공통 폴더를 Azure 파일 공유에 동기화합니다. 이런 방식으로 이 그룹의 온-프레미스 공유에는 클라우드에서 단일 Azure 파일 공유만 필요합니다.
볼륨 동기화
Azure 파일 동기화는 볼륨의 루트를 Azure 파일 공유에 동기화할 수 있도록 지원합니다. 볼륨 루트를 동기화하면 모든 하위 폴더 및 파일은 동일한 Azure 파일 공유로 이동합니다.
볼륨 루트를 동기화하는 것이 항상 최선의 방안은 아닙니다. 여러 위치를 동기화하는 데는 이점이 있습니다. 예를 들어 이렇게 하면 동기화 범위당 항목 수를 줄일 수 있습니다. Azure 파일 공유 및 Azure 파일 동기화를 공유당 1억 개의 항목(파일 및 폴더)으로 테스트합니다. 그러나 가장 좋은 방법은 단일 공유에서 숫자를 2천만 또는 3천만 미만으로 유지하는 것입니다. 더 적은 수의 항목으로 Azure 파일 동기화를 설정하는 것은 파일 동기화에만 도움이 되지 않습니다. 항목 수가 적으면 다음과 같은 시나리오에도 도움이 됩니다.
- 클라우드 콘텐츠 초기 검사가 더 빠르게 완료될 수 있으며, 이로 인해 Azure 파일 동기화 사용 서버에 네임스페이스를 표시하기 위한 대기 시간이 줄어듭니다.
- Azure 파일 공유 스냅샷으로부터의 클라우드 쪽 복원이 더 빨라집니다.
- 온-프레미스 서버의 재해 복구 속도가 현저히 향상될 수 있습니다.
- Azure 파일 공유(동기화 외부)에서 직접 변경한 내용을 더 빠르게 검색하고 동기화할 수 있습니다.
팁
보유한 파일 및 폴더 수를 잘 모르는 경우 JAM Software GmbH의 TreeSize 도구를 검토해 보세요.
배포 맵에 대한 구조적 접근 방법
이후 단계에서 클라우드 스토리지를 배포하기 전에 온-프레미스 폴더와 Azure 파일 공유 간에 맵을 만드는 것이 중요합니다. 그런 다음 이 매핑은 프로비저닝할 Azure 파일 동기화 동기화 그룹 리소스 및 개수를 알려줍니다. 동기화 그룹은 Azure 파일 공유와 서버의 폴더를 함께 연결하고 동기화 연결을 설정합니다.
필요한 Azure 파일 공유 수를 결정하려면 다음 제한 및 모범 사례를 검토하세요. 그러면 맵을 최적화하는 데 도움이 됩니다.
Azure 파일 동기화 에이전트가 설치된 서버는 최대 30개의 Azure 파일 공유와 동기화될 수 있습니다.
Azure 파일 공유는 스토리지 계정 내에 배포됩니다. 이러한 정렬로 인해 스토리지 계정은 IOPS 및 처리량과 같은 성능 수치를 위한 크기 조정 대상이 됩니다.
Azure 파일 공유를 배포할 때 스토리지 계정의 IOPS 제한 사항에 주의합니다. 파일 공유를 스토리지 계정과 1:1로 매핑하는 것이 이상적입니다. 그러나 조직과 Azure 모두의 다양한 제한과 제약으로 인해 항상 가능한 것은 아닙니다. 하나의 스토리지 계정에 파일 공유를 하나만 배포할 수 없는 경우 어떤 공유가 작업 수행이 활발한지와 덜 사용되는지를 고려하여 가장 많이 사용하는 파일 공유가 동일한 스토리지 계정에 함께 포함되지 않도록 하세요.
Azure 파일 공유를 기본적으로 사용하는 Azure에 앱을 올리려는 경우 Azure 파일 공유의 성능이 더 필요할 수 있습니다. 이러한 유형의 사용이 나중에라도 가능성이 있는 경우 고유한 스토리지 계정에서 단일 표준 Azure 파일 공유를 만드는 것이 가장 좋습니다.
Azure 지역별로 구독당 스토리지 계정 수가 250개로 제한됩니다.
팁
이 정보를 고려하면 볼륨의 여러 최상위 폴더를 새로운 공통 루트 디렉터리로 그룹화해야 하는 경우가 많습니다. 그런 다음 이 새 루트 디렉터리와 이 디렉터리에 그룹화한 모든 폴더를 단일 Azure 파일 공유로 동기화합니다. 이 기법을 사용하면 Azure 파일 공유 동기화를 서버당 30개 제한을 초과하여 유지할 수 있습니다.
공통 루트 아래의 이 그룹화는 데이터 액세스에 영향을 주지 않습니다. ACL은 그대로 유지됩니다. 이제 공통 루트로 변경된 로컬 서버 폴더에 있을 수 있는 모든 공유 경로(예: SMB 또는 NFS 공유)만 조정하면 됩니다. 아무 것도 변경되지 않습니다.
Important
Azure 파일 동기화에서 가장 중요한 크기 조정 벡터는 동기화해야 하는 항목(파일 및 폴더)의 수입니다. 자세한 내용은 Azure 파일 동기화 크기 조정 목표를 검토하세요.
동기화 범위당 항목 수를 적게 유지하는 것이 가장 좋습니다. 이는 폴더를 Azure 파일 공유에 매핑할 때 고려해야 할 중요한 요소입니다. Azure 파일 동기화는 공유당 1억 항목(파일 및 폴더)을 사용하여 테스트되었습니다. 그러나 단일 공유에서 2천만 또는 3천만 미만의 항목 수를 유지하는 것이 가장 좋습니다. 이러한 수치를 초과하기 시작하는 경우 네임스페이스를 여러 공유로 분할합니다. 이러한 수치를 초과하기 전에는 여러 온-프레미스 공유를 동일한 Azure 파일 공유로 계속 그룹화할 수 있습니다. 이 방법은 확장의 여지를 제공합니다.
상황에 따라 폴더 집합이 앞에서 언급한 새로운 공통 루트 폴더 접근 방식을 사용하여 동일한 Azure 파일 공유에 논리적으로 동기화할 수 있습니다. 하지만 폴더를 다시 그룹화하여 Azure 파일 공유 한 개가 아니라 두 개에 동기화하는 것이 더 나을 수 있습니다. 이 방법을 사용하여 파일 공유당 파일 및 폴더 수를 서버 전체에 분산된 상태로 유지할 수 있습니다. 또한 온-프레미스 공유를 분할하고 더 많은 온-프레미스 서버에서 동기화하여 추가 서버마다 30개 이상의 Azure 파일 공유와 동기화하는 기능을 추가할 수 있습니다.
일반적인 파일 동기화 시나리오 및 고려 사항
| # | 동기화 시나리오 | 지원됨 | 고려 사항(또는 제한 사항) | 솔루션(또는 해결 방법) |
|---|---|---|---|---|
| 1 | 동일한 대상 Azure 파일 공유에 여러 디스크/볼륨 및 여러 공유가 있는 파일 서버(통합) | 아니요 | 대상 Azure 파일 공유(클라우드 엔드포인트)는 하나의 동기화 그룹과의 동기화만 지원합니다. 동기화 그룹은 등록된 서버당 하나의 서버 엔드포인트만 지원합니다. |
1) 하나의 디스크(루트 볼륨)를 대상 Azure 파일 공유에 동기화하는 것으로 시작합니다. 가장 큰 디스크/볼륨부터 시작하면 온-프레미스의 스토리지 요구 사항을 충족하는 데에 도움이 됩니다. 모든 데이터를 클라우드로 계층화하도록 클라우드 계층화를 구성하여 파일 서버 디스크의 공간을 확보합니다. 다른 볼륨/공유의 데이터를 동기화 중인 현재 볼륨으로 이동합니다. 모든 데이터가 클라우드/마이그레이션까지 계층화될 때까지 단계를 하나씩 계속합니다. 2) 한 번에 하나의 루트 볼륨(디스크)을 대상으로 지정합니다. 클라우드 계층화를 사용하여 모든 데이터를 계층화하여 Azure 파일 공유를 대상으로 합니다. 동기화 그룹에서 서버 엔드포인트를 제거하고, 다음 루트 볼륨/디스크를 사용하여 엔드포인트를 다시 만들고, 동기화하고, 이 프로세스를 반복합니다. 참고: 에이전트를 다시 설치해야 할 수 있습니다. 3) 여러 대상 Azure 파일 공유를 사용하는 것이 좋습니다(성능 요구 사항에 따라 동일하거나 다른 스토리지 계정) |
| 2 | 동일한 대상 Azure 파일 공유에 단일 볼륨 및 여러 공유가 있는 파일 서버(통합) | 예 | 등록된 서버당 여러 서버 엔드포인트를 동일한 대상 Azure 파일 공유에 동기화할 수 없습니다(위와 동일) | 여러 공유 또는 최상위 폴더를 보유하는 볼륨의 루트를 동기화합니다. 자세한 내용은 공유 그룹화 개념 및 볼륨 동기화를 참조하세요. |
| 3 | 단일 스토리지 계정에서 여러 Azure 파일 공유에 대한 여러 공유 및/또는 볼륨이 있는 파일 서버(1:1 공유 매핑) | 예 | 단일 Windows Server 인스턴스(또는 클러스터)는 최대 30개의 Azure 파일 공유와 동기화될 수 있습니다. 스토리지 계정은 성능에 대한 스케일링 대상입니다. IOPS 및 처리량은 파일 공유를 통해 공유됩니다. 동기화 그룹당 항목 수를 공유당 1억 개의 항목(파일 및 폴더) 내에 유지합니다. 이상적으로는 주당 2,000만 또는 3,000만 미만을 유지하는 것이 가장 좋습니다. |
1) 여러 동기화 그룹(동기화 그룹 수 = 동기화할 Azure 파일 공유 수)을 사용합니다. 2) 이 시나리오에서는 한 번에 30개 공유만 동기화할 수 있습니다. 해당 파일 서버에 30개 이상의 공유가 있는 경우 공유 그룹화 개념 및 볼륨 동기화를 사용하여 원본의 루트 또는 최상위 폴더 수를 줄입니다. 3) 추가 파일 동기화 서버 온-프레미스를 사용하고 이러한 서버로 데이터를 분할/이동하여 원본 Windows 서버의 제한 사항을 해결합니다. |
| 4 | 여러 스토리지 계정의 여러 Azure 파일 공유에 대한 여러 공유 및/또는 볼륨이 있는 파일 서버(1:1 공유 매핑) | 예 | 단일 Windows Server 인스턴스(또는 클러스터)는 최대 30개의 Azure 파일 공유(동일 또는 다른 스토리지 계정)와 동기화될 수 있습니다. 동기화 그룹당 항목 수를 공유당 1억 개의 항목(파일 및 폴더) 내에 유지합니다. 이상적으로는 주당 2,000만 또는 3,000만 미만을 유지하는 것이 가장 좋습니다. |
위와 동일한 접근 방식 |
| 5 | 동일한 대상 Azure 파일 공유에 단일(루트 볼륨 또는 공유)가 있는 여러 파일 서버(통합) | 아니요 | 동기화 그룹은 다른 동기화 그룹에 이미 구성된 클라우드 엔드포인트(Azure 파일 공유)를 사용할 수 없습니다. 동기화 그룹에는 서로 다른 파일 서버에 서버 엔드포인트가 있을 수 있지만 파일은 구별할 수 없습니다. |
한 번에 하나의 파일 서버를 대상으로 지정하는 추가 고려 사항과 함께 위의 시나리오 1에 나와 있는 지침을 따릅니다. |
매핑 테이블 만들기
이전 정보를 사용하여 필요한 Azure 파일 공유 수와 기존 데이터의 어떤 부분이 어떤 Azure 파일 공유로 끝날지 결정하세요.
필요할 때 참고할 수 있도록 생각을 기록하는 표를 만듭니다. 여러 Azure 리소스를 한 번에 프로비전할 때 매핑 계획의 세부 사항을 지나치기 쉬우므로 구성된 상태로 유지하는 것이 중요합니다. 다음 Excel 파일을 다운로드하여 매핑을 만드는 데 도움이 되는 템플릿으로 사용합니다.
|
네임스페이스 매핑 템플릿을 다운로드합니다. |
2단계: Azure 스토리지 리소스 배포
이 단계에서는 1단계의 매핑 테이블을 참조하여 정확한 수의 Azure Storage 계정과 해당 계정 내의 파일 공유를 프로비전합니다.
Azure 파일 공유는 Azure 스토리지 계정의 클라우드에 저장됩니다. 다른 수준의 성능 고려 사항이 여기에 적용됩니다.
활성 공유(많은 사용자 및/또는 애플리케이션에서 사용하는 공유)가 많은 경우 두 개의 Azure 파일 공유가 스토리지 계정의 성능 제한에 도달할 수 있습니다.
가장 좋은 방법은 각각 파일 공유가 하나씩 있는 스토리지 계정을 배포하는 것입니다. 보관 공유가 있거나 일상 활동이 적을 것으로 예상되는 경우 여러 Azure 파일 공유를 동일한 스토리지 계정으로 풀할 수 있습니다.
이러한 고려 사항은 Azure 파일 동기화보다 Azure VM을 통한 직접 클라우드 액세스에 더 많이 적용됩니다. 이러한 공유에서 Azure 파일 동기화만 사용하려는 경우 여러 개를 단일 Azure Storage 계정으로 그룹화하는 것이 좋습니다.
공유 목록을 만든 경우 각 공유를 해당 스토리지 계정에 매핑해야 합니다.
이전 단계에서는 적절한 공유 수를 결정했습니다. 이 단계에서는 스토리지 계정을 파일 공유에 매핑합니다. 이제 적절한 수의 Azure 파일 공유가 포함된 적절한 수의 Azure 스토리지 계정을 배포합니다.
각 스토리지 계정의 지역이 동일하고 이미 배포한 Storage Sync Service 리소스의 지역과 일치해야 합니다.
주의
100TiB 한도가 있는 Azure 파일 공유를 만드는 경우 해당 공유는 로컬 중복 스토리지 또는 영역 중복 스토리지 중복 옵션만 사용할 수 있습니다. 100TiB 파일 공유를 사용하려면 먼저 스토리지 중복도 요구 사항을 고려하세요.
Azure 파일 공유는 기본적으로 여전히 5TiB 한도로 생성됩니다. Azure 파일 공유 만들기의 단계에 따라 대량 파일 공유를 만듭니다.
스토리지 계정을 배포할 때 또 다른 고려 사항은 Azure Storage의 중복도입니다. Azure Storage 중복도 옵션을 참조하세요.
리소스의 이름도 중요합니다. 예를 들어 HR 부서의 여러 공유를 Azure 스토리지 계정 하나로 그룹화하는 경우 스토리지 계정의 이름을 적절하게 지정해야 합니다. 마찬가지로 Azure 파일 공유의 이름을 지정할 때 온-프레미스 파일 공유에 사용되는 이름과 비슷한 이름을 사용해야 합니다.
3단계: 필요한 Azure Data Box 어플라이언스 수 결정
이 단계는 이전 단계를 완료한 후에만 시작합니다. 이 시점에서 Azure 스토리지 리소스(스토리지 계정 및 파일 공유)를 만들어야 합니다. Data Box를 주문하는 경우 Data Box에서 데이터를 이동하는 스토리지 계정을 지정해야 합니다.
이 단계에서는 이전 단계의 마이그레이션 계획 결과를 사용 가능한 Data Box 옵션의 제한에 매핑해야 합니다. 이러한 고려 사항은 선택할 Data Box 옵션과 NAS 공유를 Azure 파일 공유로 이동하는 데 필요한 옵션의 수를 계획하는 데 도움이 됩니다.
참고 항목
DataBox 디스크는 파일 충실도를 유지하지 않기 때문에 지원되지 않습니다.
필요한 디바이스의 수와 해당 유형을 결정하려면 다음과 같은 중요한 제한 사항을 고려합니다.
- 모든 Azure Data Box 어플라이언스에서 데이터를 최대 10개의 스토리지 계정으로 이동할 수 있습니다.
- 각 Data Box 옵션은 사용 가능한 자체 용량과 함께 제공됩니다. Data Box 옵션을 참조하세요.
만들기로 결정한 스토리지 계정의 수와 각 계정의 공유를 확인하려면 마이그레이션 계획을 참조합니다. 그런 다음, NAS에서 각 공유의 크기를 확인합니다. 이 정보를 결합하면 어떤 어플라이언스에서 어떤 스토리지 계정으로 데이터를 보내야 하는지 결정하고 최적화할 수 있습니다. 두 개의 Data Box 디바이스에서 파일을 동일한 스토리지 계정으로 이동할 수 있지만, 단일 파일 공유의 콘텐츠는 두 개의 Data Box에 분할하지 않습니다.
Data Box 옵션
표준 마이그레이션의 경우 다음 Data Box 옵션 중 하나 또는 조합을 선택합니다.
- Data Box. 이 옵션은 가장 일반적인 옵션입니다. Microsoft는 NAS와 비슷하게 작동하는 러기드 Data Box 어플라이언스를 보냅니다. 사용 가능한 용량은 80TiB입니다. 자세한 내용은 Data Box 설명서를 참조하세요.
- Data Box Heavy. 이 옵션은 NAS와 비슷하게 작동하는 휠 방식의 러기드 Data Box 어플라이언스를 제공합니다. 용량은 1PiB입니다. 암호화 및 파일 시스템 오버헤드로 인해 사용 가능한 용량이 약 20% 줄어듭니다. 자세한 내용은 Data Box Heavy 설명서를 참조하세요.
참고 항목
Data Box 및 Data Box Heavy의 경우 SMB를 통한 데이터 복사만 지원됩니다. 데이터 복사 서비스를 통한 데이터 복사는 파일 충실도를 유지하지 않기 때문에 지원되지 않습니다.
4단계: Data Box에 파일 복사
Data Box가 도착하면 NAS 어플라이언스에 대한 네트워크 연결이 방해받지 않도록 설정해야 합니다. 주문한 Data Box 유형에 대한 설정 설명서를 따릅니다.
Data Box 유형에 따라 Data Box 복사 도구를 사용할 수 있습니다. 이 시점에서 이러한 도구는 파일을 완전히 충실하게 Data Box에 복사하지 않으므로 Azure 파일 공유로 마이그레이션하는 데 사용하지 않는 것이 좋습니다. 대신 Robocopy를 사용하세요.
Data Box가 도착하면 주문할 때 지정한 각 스토리지 계정에 사용할 수 있는 미리 프로비전된 SMB 공유가 있습니다.
- 파일이 프리미엄 Azure 파일 공유로 이동하는 경우 프리미엄 "파일 스토리지" 스토리지 계정당 하나의 SMB 공유가 있습니다.
- 파일이 표준 스토리지 계정으로 이동하는 경우 표준(GPv1 및 GPv2) 스토리지 계정당 세 개의 SMB 공유가 있습니다.
_AzFiles로 끝나는 파일 공유만 마이그레이션과 관련이 있습니다. 모든 블록 및 페이지 Blob 공유는 무시합니다.
Azure Data Box 설명서의 단계를 따릅니다.
- Data Box에 연결합니다.
- 데이터를 Data Box에 복사합니다.
- Azure에 업로드할 Data Box를 준비합니다.
연결된 Data Box 설명서에는 Robocopy 명령이 지정되어 있습니다. 이 명령은 전체 파일 및 폴더 충실도를 유지하는 데 적합하지 않습니다. 대신 다음 명령을 사용하세요.
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
| 스위치 | 의미 |
|---|---|
/MT:n |
Robocopy가 다중 스레드를 실행할 수 있도록 합니다. n의 기본값은 8입니다. 최대 스레드 수는 128개입니다. 스레드 수가 많으면 사용 가능한 대역폭을 포화시키는 데 도움이 되지만 더 많은 스레드로 마이그레이션이 항상 더 빨라지는 것은 아닙니다. Azure Files를 사용한 테스트는 초기 복사 실행에 대해 8에서 20 사이의 균형 잡힌 성능을 보여 줍니다. 후속 /MIR 실행은 사용 가능한 컴퓨팅 및 사용 가능한 네트워크 대역폭의 영향을 점진적으로 받게 됩니다. 후속 실행의 경우 스레드 수 값을 프로세서 코어 수 및 코어당 스레드 수와 좀 더 가깝게 일치시킵니다. 프로덕션 서버에서 수행할 수 있는 다른 작업을 위해 코어를 예약해야 하는지 여부를 고려하세요. Azure Files를 사용한 테스트에 따르면 최대 64개의 스레드가 우수한 성능을 생성하지만 프로세서가 동시에 연결 유지할 수 있는 경우에만 가능합니다. |
/R:n |
첫 번째 시도에서 복사에 실패한 파일의 최대 다시 시도 횟수입니다. Robocopy는 실행에서 파일이 영구적으로 복사에 실패하기 전에 n번 시도합니다. 실행 성능을 최적화할 수 있습니다. 과거에 시간 초과 문제로 인해 오류가 발생했다고 생각되면 2 또는 3의 값을 선택합니다. 이는 WAN 링크를 통해 더 일반적일 수 있습니다. 파일이 활발하게 사용 중이어서 복사에 실패했다고 생각되면 다시 시도 안 함 또는 값 1을 선택합니다. 몇 초 후에 다시 시도하면 파일의 사용 상태가 변경되는 데 시간이 충분하지 않을 수 있습니다. 파일을 열어 둔 사용자 또는 앱은 몇 시간 더 시간이 필요할 수 있습니다. 이 경우 파일이 복사되지 않았음을 수락하고 계획된 후속 Robocopy 실행 중 하나에서 파일을 포착하면 결국 파일을 성공적으로 복사하는 데 성공할 수 있습니다. 이렇게 하면 다시 시도 시간 초과 후에도 여전히 열려 있는 파일로 인해 궁극적으로 대부분의 복사 실패로 끝나는 많은 다시 시도에 의해 연장되지 않고 현재 실행이 더 빨리 완료될 수 있습니다. |
/W:n |
Robocopy가 이전 시도 중에 성공적으로 복사하지 못한 파일 복사를 시도하기 전에 대기하는 시간을 지정합니다. n은 다시 시도 사이에 대기하는 시간(초)입니다. /W:n는 /R:n과 함께 사용되는 경우가 많습니다. |
/B |
백업 애플리케이션이 사용하는 것과 동일한 모드에서 Robocopy를 실행합니다. 이 스위치를 사용하면 Robocopy가 현재 사용자에게 권한이 없는 파일을 이동할 수 있습니다. 백업 스위치는 관리자 권한 콘솔 또는 PowerShell 창에서 Robocopy 명령 실행에 따라 다릅니다. Azure Files용 Robocopy를 사용하는 경우 스토리지 계정 액세스 키와 도메인 ID를 사용하여 Azure 파일 공유를 탑재해야 합니다. 그렇지 않은 경우 오류 메시지가 직관적으로 문제 해결을 유도하지 못할 수 있습니다. |
/MIR |
(원본을 대상으로 미러링합니다.) Robocopy가 원본과 대상 간의 델타만 복사할 수 있도록 합니다. 빈 하위 디렉터리가 복사됩니다. 대상에서 변경되었거나 존재하지 않는 항목(파일 또는 폴더)이 복사됩니다. 대상에 존재하지만 원본에 존재하지 않는 항목은 대상에서 제거(삭제)됩니다. 이 스위치를 사용하는 경우 원본 및 대상 폴더 구조를 정확하게 일치합니다. 일치는 올바른 원본 및 폴더 수준에서 대상의 일치하는 폴더 수준으로 복사하는 것을 의미합니다. 그래야만 "후속" 복사가 성공할 수 있습니다. 원본과 대상이 일치하지 않는 경우 /MIR을 사용하면 대규모 삭제 및 다시 복사가 수행됩니다. |
/IT |
특정 미러링 시나리오에서 충실도가 유지되도록 합니다. 예를 들어 파일에서 두 Robocopy 실행 사이에 ACL 변경 및 특성 업데이트가 발생하면 해당 파일은 숨김으로 표시됩니다. /IT가 없으면 Robocopy에서 ACL 변경 사항을 놓치고 대상 위치로 전송되지 않을 수 있습니다. |
/COPY:[copyflags] |
파일 복사본의 충실도입니다. 기본값: /COPY:DAT. 복사 플래그: D= 데이터, A= 특성, T= 타임스탬프, S= 보안 = NTFS ACL, O= 소유자 정보, U= 감사 정보. 감사 정보는 Azure 파일 공유에 저장할 수 없습니다. |
/DCOPY:[copyflags] |
디렉터리 복사본의 충실도입니다. 기본값: /DCOPY:DA. 복사 플래그: D= 데이터, A= 특성, T= 타임스탬프. |
/NP |
각 파일 및 폴더에 대한 복사 진행률이 표시되지 않도록 지정합니다. 진행률을 표시하면 복사 성능이 대폭 저하됩니다. |
/NFL |
파일 이름을 기록하지 않도록 지정합니다. 복사 성능을 향상시킵니다. |
/NDL |
디렉터리 이름을 기록하지 않도록 지정합니다. 복사 성능을 향상시킵니다. |
/XD |
제외할 디렉터리를 지정합니다. 볼륨의 루트에서 Robocopy를 실행할 때 숨겨진 System Volume Information 폴더를 제외하는 것을 고려합니다. 설계된 대로 사용되는 경우, 거기에 있는 모든 정보는 이 정확한 시스템의 정확한 볼륨에 따라 다르며 필요에 따라 재구성할 수 있습니다. 이 정보를 복사하는 것은 클라우드에서 또는 데이터가 다른 Windows 볼륨으로 다시 복사될 때 도움이 되지 않습니다. 이 콘텐츠를 남겨두는 것은 데이터 손실로 간주되어서는 안 됩니다. |
/UNILOG:<file name> |
상태를 유니코드로 로그 파일에 씁니다. (기존 로그를 덮어씁니다.) |
/L |
테스트 실행에만 해당 파일만 나열됩니다. 복사되지 않고, 삭제되지 않으며, 타임스탬프가 표시되지 않습니다. 콘솔 출력을 위해 /TEE와 함께 사용되는 경우가 많습니다. 테스트 결과를 적절히 문서화하려면 /NP, /NFL 및 /NDL과 같은 샘플 스크립트의 플래그를 제거해야 할 수 있습니다. |
/LFSM |
계층화된 스토리지를 사용하는 대상에만 해당 대상이 원격 SMB 공유인 경우 지원되지 않습니다. Robocopy가 “여유 공간 부족 모드”에서 작동하도록 지정합니다. 이 스위치는 Robocopy가 완료되기 전에 로컬 용량이 부족할 수 있는 계층화 스토리지가 있는 대상에만 유용합니다. Azure 파일 동기화 클라우드 계층화에 대해 사용하도록 설정된 대상과 함께 사용하기 위해 특별히 추가되었습니다. Azure 파일 동기화와 독립적으로 사용할 수 있습니다. 이 모드에서 RoboCopy는 파일 복사로 인해 대상 볼륨의 사용 가능한 공간이 "floor"값 아래로 내려갈 때마다 일시 중지됩니다. 이 값은 /LFSM:n 형식의 플래그로 지정할 수 있습니다. 매개 변수 n은 기본 2에서 nKB, nMB 또는 nGB로 지정됩니다. /LFSM이 명시적 floor 값 없이 지정된 경우 floor는 대상 볼륨 크기의 10%로 설정됩니다. 사용 가능한 공간 부족 모드는 /MT, /EFSRAW 또는 /ZB와 호환되지 않습니다. /B에 대한 지원이 Windows Server 2022에 추가되었습니다. 관련 버그 및 해결 방법에 대한 자세한 내용은 아래의 Windows Server 2022 및 RoboCopy LFSM 섹션을 참조하세요. |
/Z |
주의해서 사용 다시 시작 모드에서 파일을 복사합니다. 이 스위치는 불안정한 네트워크 환경에서만 권장됩니다. 추가 로깅으로 인해 복사 성능이 크게 저하됩니다. |
/ZB |
주의해서 사용 다시 시작 모드를 사용합니다. 액세스가 거부되는 경우 이 옵션은 백업 모드를 사용합니다. 이 옵션을 선택하면 검사점 설정으로 인해 복사 성능이 크게 저하됩니다. |
Important
Windows Server 2022를 사용하는 것이 좋습니다. Windows Server 2019를 사용하는 경우 최신 패치 수준 또는 최소 OS 업데이트 KB5005103이 설치되어 있는지 확인합니다. 특정 Robocopy 시나리오에 대한 중요한 수정 사항이 포함되어 있습니다.
5단계: Azure 파일 동기화 클라우드 리소스 배포
이 가이드를 계속하기 전에 모든 파일이 올바른 Azure 파일 공유에 도착할 때까지 기다립니다. Data Box 데이터를 배송하고 수집하는 프로세스에는 시간이 걸립니다.
이 단계를 완료하려면 Azure 구독 자격 증명이 필요합니다.
Azure 파일 동기화에 대해 구성할 핵심 리소스를 '스토리지 동기화 서비스'라고 합니다. 지금 또는 나중에 동일한 파일 집합을 동기화하는 모든 서버에 대해 하나만 배포하는 것이 좋습니다. 데이터를 교환하면 안 되는 고유한 서버 집합이 있는 경우에만 스토리지 동기화 서비스를 여러 개 만듭니다. 예를 들어 동일한 Azure 파일 공유를 동기화하면 안 되는 서버들이 있을 수 있습니다. 그렇지 않으면 단일 스토리지 동기화 서비스를 사용하는 것이 가장 좋습니다.
스토리지 동기화 서비스에는 사용자의 위치에 가까운 Azure 지역을 선택합니다. 다른 모든 클라우드 리소스는 동일한 지역에 배포해야 합니다. 관리를 간소화하려면 구독에서 동기화 및 스토리지 리소스를 보관하는 새 리소스 그룹을 만듭니다.
자세한 내용은 Azure 파일 동기화 배포에 대한 문서에서 스토리지 동기화 서비스 배포에 대한 섹션을 참조하세요. 문서의 이 섹션만 따릅니다. 이후 단계에서는 문서의 다른 섹션에 대한 링크가 제공됩니다.
6단계: Azure 파일 동기화 에이전트 배포
이 섹션에서는 Windows Server 인스턴스에 Azure 파일 동기화 에이전트를 설치합니다.
배포 가이드에서는 Internet Explorer 보안 강화 구성을 해제해야 함을 보여 줍니다. 이 보안 조치는 Azure 파일 동기화에는 적용되지 않습니다. 이 기능을 끄면 문제 없이 Azure에 인증할 수 있습니다.
PowerShell을 엽니다. 다음 명령을 사용하여 필요한 PowerShell 모듈을 설치합니다. 설치하라는 메시지가 표시되면 전체 모듈과 NuGet 공급자를 설치해야 합니다.
Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync
서버에서 인터넷에 연결하는 데 문제가 있는 경우 지금이 해결할 시간입니다. Azure 파일 동기화는 인터넷에 대해 사용 가능한 모든 네트워크 연결을 사용합니다. 프록시 서버를 인터넷에 연결해야 하는 것도 지원됩니다. 지금 컴퓨터 전체 프록시를 구성하거나 에이전트 설치 중에 Azure 파일 동기화만 사용할 프록시를 지정할 수 있습니다.
프록시를 구성하는 경우 이 서버에 대한 방화벽을 열어야 하므로 이 방법이 허용될 수 있습니다. 서버를 설치하고 서버 등록을 완료하면 네트워크 연결 보고서는 사용자가 선택한 지역에서 Azure 파일 동기화가 통신해야 하는 정확한 Azure 엔드포인트 URL을 표시합니다. 또한 이 보고서는 통신이 필요한 이유를 알려 줍니다. 이 보고서를 사용하여 이 서버 주변의 방화벽을 특정 URL로 잠글 수 있습니다.
방화벽 전체를 열지 않는 보다 보수적인 접근 방식을 취할 수도 있습니다. 대신 상위 수준 DNS 네임스페이스와 통신하도록 서버를 제한할 수 있습니다. 자세한 내용은 Azure 파일 동기화 프록시 및 방화벽 설정을 참조하세요. 자체 네트워킹 모범 사례를 따르세요.
서버 설치 마법사가 끝날 때 서버 등록 마법사가 열립니다. 이전의 스토리지 동기화 서비스의 Azure 리소스에 서버를 등록합니다.
이러한 단계는 배포 가이드 Azure 파일 동기화 에이전트 설치에 자세히 설명되어 있습니다. 여기에는 먼저 설치해야 하는 PowerShell 모듈이 포함됩니다.
최신 에이전트를 사용하세요. Microsoft 다운로드 센터에서 다운로드할 수 있습니다. Azure 파일 동기화 에이전트.
성공적으로 설치하고 서버를 등록한 후에는 이 단계가 성공적으로 완료되었는지 확인할 수 있습니다. Azure Portal의 스토리지 동기화 서비스 리소스로 이동합니다. 왼쪽 메뉴에서 등록된 서버로 이동합니다. 여기에 서버가 나열됩니다.
7단계: 기존 Windows Server에서 Azure 파일 동기화 구성
이 프로세스를 진행하려면 등록된 온-프레미스 Windows Server 인스턴스가 준비되어 있고 인터넷에 연결되어 있어야 합니다.
이 단계에서는 이전 단계에서 Windows Server 인스턴스에 설정한 모든 리소스 및 폴더를 서로 연결합니다.
- Azure Portal에 로그인합니다.
- 스토리지 동기화 서비스 리소스를 찾습니다.
- 각 Azure 파일 공유에 대한 스토리지 동기화 서비스 리소스 내에 새 '동기화 그룹'을 만듭니다. Azure 파일 동기화 용어로, Azure 파일 공유는 동기화 토폴로지에서 동기화 그룹 만들기로 설명하는 '클라우드 엔드포인트'가 됩니다. 동기화 그룹을 만들 때 여기에 동기화되는 파일 집합을 인식할 수 있도록 친숙한 이름을 지정합니다. 일치하는 이름의 Azure 파일 공유를 참조하는지 확인합니다.
- 동기화 그룹을 만든 후에는 해당 그룹에 대한 행이 동기화 그룹 목록에 표시됩니다. 이름(링크)을 선택하여 동기화 그룹의 내용을 표시합니다. 클라우드 엔드포인트 아래에서 Azure 파일 공유를 볼 수 있습니다.
- 서버 엔드포인트 추가 단추를 찾습니다. 프로비전한 로컬 서버의 폴더가 이 서버 엔드포인트의 경로가 됩니다.
서버 엔드포인트 만들기 마법사에 있으면 폴더 경로 아래에 제공된 확인란을 활용합니다. Azure 파일 공유(Data Box에서 이 네임스페이스에 대한 파일과 폴더를 이동함)에서 찾을 수 있는 것과 동일한 파일 및 폴더 구조를 가리키는 경로를 입력한 경우에만 이 항목을 선택합니다.
폴더 계층 구조가 일치하지 않으면 자동으로 해결할 수 없는 차이로 표시됩니다. 불일치를 방지하거나 Data Box 프로세스에 투자하면 아무런 이점이 없습니다. 모든 데이터는 Azure 파일 공유에서 삭제됩니다. 모든 데이터는 로컬 서버에서 업로드해야 합니다. Azure Data Box를 사용하여 대량 마이그레이션의 이점을 얻고 클라우드 공유를 서버의 최신 변경 내용으로 원활하게 업데이트하려면 디렉터리 구조가 일치해야 합니다.
참고 항목
이 확인란을 사용하도록 설정하면 초기 동기화 모드가 Azure 파일 공유의 파일 및 폴더를 이 서버의 경로에 있는 콘텐츠로 명령적으로 덮어쓰도록 설정됩니다. 이 옵션은 동기화 그룹의 첫 번째 서버 엔드포인트에만 사용할 수 있습니다.
이 새 서버 엔드포인트에 대해 신뢰할 수 있는 업로드가 구성되면 필요에 따라 클라우드 계층화를 사용하도록 설정할 수 있습니다.
클라우드 계층화는 로컬 서버가 클라우드에 저장되는 것보다 적은 스토리지 용량을 갖지만 전체 네임스페이스를 사용할 수 있도록 하는 Azure 파일 동기화 기능입니다. 로컬에서 필요한 데이터가 로컬에 캐시되어 빠른 액세스 성능도 제공합니다. 클라우드 계층화는 선택 사항입니다. 각 Azure 파일 동기화 서버 엔드포인트에 대해 개별적으로 설정할 수 있습니다. 이 기능을 사용하여 온-프레미스에 고정된 스토리지 공간을 확보하면서도 여전히 사용자에게 로컬 성능 캐시를 제공하고 더 나은 쿨 데이터를 클라우드에 저장합니다.
클라우드 계층화 개요를 확인하여 자세히 알아보거나 로컬 서버에서 캐시/계층화되는 항목을 미세 조정하는 데 사용할 수 있는 다양한 클라우드 계층화 정책을 자세히 살펴보세요.
마이그레이션 완료
서버 엔드포인트가 만들어지면 동기화가 작동합니다. 그러나 동기화에서 Azure Data Box를 통해 Azure 파일 공유로 이동한 파일과 폴더를 열거(검색)해야 합니다. 네임스페이스의 크기에 따라 최신 서버 변경 내용이 클라우드에 동기화될 때까지 시간이 오래 걸릴 수 있습니다. 사용자는 영향을 받지 않으며 서버의 데이터를 계속 사용할 수 있습니다. 이 전략은 가동 중지 시간이 0인 클라우드 마이그레이션을 달성합니다.
동기화를 위해 구성해야 하는 모든 Azure 파일 공유/서버 위치에 대해 동기화 그룹을 만들고, 일치하는 서버 폴더를 서버 엔드포인트로 추가하는 단계를 반복합니다. Azure Data Box를 사용하여 파일을 여러 Azure 파일 공유로 이동했습니다. 온-프레미스 데이터를 이러한 Azure 파일 공유에 연결하는 모든 서버 엔드포인트가 만들어지면 마이그레이션이 완료됩니다.
다음 단계
Azure 파일 공유 및 Azure 파일 동기화에 대해 더 자세히 알아볼 수 있습니다. 다음 문서는 고급 옵션과 모범 사례를 이해하는 데 도움이 됩니다. 또한 문제 해결에 대한 도움말도 제공합니다. 다음 문서에는 해당하는 경우 Azure 파일 공유 설명서에 대한 링크가 포함되어 있습니다.