다음을 통해 공유

Azure 파일 동기화로 StorSimple 1200 마이그레이션

  • 아티클

StorSimple 1200 시리즈는 온-프레미스 데이터 센터에서 실행되는 가상 어플라이언스입니다. 이 어플라이언스에서 Azure 파일 동기화 환경으로 데이터를 마이그레이션할 수 있습니다. Azure 파일 동기화는 StorSimple 어플라이언스를 마이그레이션할 수 있는 기본 전략적 장기 Azure 서비스입니다. 이 문서에서는 Azure 파일 동기화로의 성공적인 마이그레이션을 위한 백그라운드 지식과 마이그레이션 단계를 제공합니다.

참고 항목

StorSimple 서비스(8000 및 1200 시리즈용 StorSimple 디바이스 관리자 및 StorSimple 데이터 관리자 포함)는 지원이 종료되었습니다. StorSimple 지원 종료 세부 정보는 2019년에 Microsoft 수명 주기 정책 및 Azure Communications 페이지에 게시되었습니다. 추가 알림도 메일을 통해 전송되고 Azure Portal 및StorSimple 개요에 게시되었습니다. 도움이 필요하면 Microsoft 지원 서비스에 문의하세요.

적용 대상

파일 공유 유형 SMB NFS
표준 파일 공유(GPv2), LRS/ZRS 예 아니요
표준 파일 공유(GPv2), GRS/GZRS 예 아니요
프리미엄 파일 공유(FileStorage), LRS/ZRS 예 아니요

Azure 파일 동기화

Azure 파일 동기화는 다음과 같은 두 가지 주요 구성 요소를 기반으로 하는 Microsoft 클라우드 서비스입니다.

  • 파일 동기화 및 클라우드 계층화
  • SMB 및 FileREST 등의 여러 프로토콜을 통해 액세스할 수 있는 Azure의 기본 스토리지인 파일 공유 Azure 파일 공유는 기본적으로 네트워크 드라이브로 탑재할 수 있는 Windows 서버의 파일 공유와 비교할 수 있습니다. 특성, 권한 및 타임스탬프와 같이 중요한 파일 충실도 측면을 지원합니다. StorSimple과 달리 클라우드에 저장된 파일 및 폴더를 해석하는 데 애플리케이션/서비스가 필요하지 않습니다. 이상적이고 가장 유연한 방식은 범용 파일 서버 데이터와 일부 애플리케이션 데이터를 클라우드에 저장하는 것입니다.

이 문서에서는 마이그레이션 단계에 초점을 두고 설명합니다. Azure 파일 동기화에 대해 자세히 알아보려면 다음 문서를 참조하는 것이 좋습니다.

마이그레이션 목표

목표는 생산 데이터 무결성을 보장하고 가용성을 보장하는 것입니다. 후자는 정기적인 유지 관리 기간에 맞추거나 약간만 초과할 수 있도록 가동 중지 시간을 최소로 유지해야 합니다.

Azure 파일 동기화로의 StorSimple 1200 마이그레이션 경로

Azure 파일 동기화 에이전트를 실행하려면 로컬 Windows 서버가 필요합니다. Windows Server는 2012R2 서버 이상이면 되지만 Windows Server 2019가 가장 좋습니다.

대체 마이그레이션 경로가 매우 많이 있으므로 모든 경로를 문서화하고 이 문서에서 모범 사례로 권장하는 경로에 대해 위험 또는 단점이 있는 이유를 설명하기에는 너무 긴 문서를 작성해야 합니다.

이 문서 아래에 있는 단계에 대한 마이그레이션 경로 개요

이전 이미지에서는 이 문서의 섹션에 해당하는 단계를 보여 줍니다.

1단계: 온-프레미스 Windows 서버 및 스토리지 프로비저닝

  1. Windows 서버 2019(2012R2 이상)를 VM(가상 머신) 또는 물리적 서버로 만듭니다. Windows Server 장애 조치(failover) 클러스터도 지원됩니다.
  2. DAS(Direct Attached Storage, 지원되지 않는 NAS와 비교)를 프로비저닝하거나 추가합니다. Windows 서버 스토리지 크기는 가상 StorSimple 1200 어플라이언스의 사용 가능한 용량 크기보다 크거나 같아야 합니다.

2단계: Windows 서버 스토리지 구성

이 단계에서는 StorSimple 스토리지 구조(볼륨 및 공유)를 Windows 서버 스토리지 구조에 매핑합니다. 이제 스토리지 구조(즉, 볼륨 수, 볼륨에 대한 데이터 폴더 연결 또는 현재 SMB/NFS 공유 위 또는 아래의 하위 폴더 구조)를 변경하려는 경우 이러한 변경 사항을 고려해야 합니다. Azure 파일 동기화를 구성한 후 파일 및 폴더 구조를 변경하는 것은 복잡할 수 있으며 피해야 합니다. 이 문서에서는 1:1 매핑을 가정하므로 이 문서의 단계를 수행할 때 매핑 변경 사항을 고려해야 합니다.

  • 프로덕션 데이터는 Windows 서버 시스템 볼륨에 없어야 합니다. 시스템 볼륨에서는 클라우드 계층화가 지원되지 않습니다. 그러나 이 기능은 StorSimple 교체와 같은 연속 작업뿐 아니라 마이그레이션에도 필요합니다.
  • StorSimple 1200 가상 어플라이언스와 동일한 수의 볼륨을 Windows 서버에 프로비저닝합니다.
  • 필요한 Windows 서버 역할, 기능 및 설정을 구성합니다. 운영 체제를 안전하게 최신 상태로 유지하려면 Windows Server 업데이트를 옵트인하는 것이 좋습니다. 마찬가지로 Azure 파일 동기화 에이전트를 포함하여 Microsoft 애플리케이션을 최신 상태로 유지하기 위해 Microsoft 업데이트를 선택하는 것이 좋습니다.
  • 다음 단계를 읽기 전에 폴더 또는 공유를 구성하지 마세요.

3단계: 첫 번째 Azure 파일 동기화 클라우드 리소스 배포

이 단계를 완료하려면 Azure 구독 자격 증명이 필요합니다.

Azure 파일 동기화에 대해 구성할 핵심 리소스를 '스토리지 동기화 서비스'라고 합니다. 지금 또는 나중에 동일한 파일 집합을 동기화하는 모든 서버에 대해 하나만 배포하는 것이 좋습니다. 데이터를 교환하면 안 되는 고유한 서버 집합이 있는 경우에만 스토리지 동기화 서비스를 여러 개 만듭니다. 예를 들어 동일한 Azure 파일 공유를 동기화하면 안 되는 서버들이 있을 수 있습니다. 그렇지 않으면 단일 스토리지 동기화 서비스를 사용하는 것이 가장 좋습니다.

스토리지 동기화 서비스에는 사용자의 위치에 가까운 Azure 지역을 선택합니다. 다른 모든 클라우드 리소스는 동일한 지역에 배포해야 합니다. 관리를 간소화하려면 구독에서 동기화 및 스토리지 리소스를 보관하는 새 리소스 그룹을 만듭니다.

자세한 내용은 Azure 파일 동기화 배포에 대한 문서에서 스토리지 동기화 서비스 배포에 관한 섹션을 참조하세요. 문서의 이 섹션만 따릅니다. 이후 단계에서는 문서의 다른 섹션에 대한 링크가 제공됩니다.

4단계: 로컬 볼륨 및 폴더 구조를 Azure 파일 동기화 및 Azure 파일 공유 리소스와 일치

이 단계에서는 필요한 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 파일을 다운로드하여 매핑을 만드는 데 도움이 되는 템플릿으로 사용합니다.


다운로드 컨텍스트를 설정하는 Excel 아이콘. 네임스페이스 매핑 템플릿을 다운로드합니다.

5단계: Azure 파일 공유 프로비저닝

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 파일 공유의 이름을 지정할 때 온-프레미스 파일 공유에 사용되는 이름과 비슷한 이름을 사용해야 합니다.

스토리지 계정 설정

스토리지 계정에는 다양한 구성을 수행할 수 있습니다. 스토리지 계정 구성에서는 다음 체크리스트를 고려해야 합니다. 예를 들어, 마이그레이션이 완료된 후 네트워킹 구성을 변경할 수 있습니다.

  • 방화벽 및 가상 네트워크: 사용 안 함 - IP 제한을 구성하지 않거나 특정 가상 네트워크에 대한 스토리지 계정 액세스를 제한하지 않습니다. 스토리지 계정의 퍼블릭 엔드포인트를 마이그레이션 중에 사용합니다. Azure VM의 모든 IP 주소가 허용되어야 합니다. 마이그레이션 후 스토리지 계정에 대한 방화벽 규칙을 구성하는 것이 좋습니다.
  • 프라이빗 엔드포인트 지원 - 프라이빗 엔드포인트를 사용할 수는 있으나 퍼블릭 엔드포인트를 마이그레이션에 사용하고, 사용 가능한 상태로 유지해야 합니다.

6단계: Windows 서버 대상 폴더 구성

이전 단계에서는 동기화 토폴로지의 구성 요소를 결정하는 모든 측면을 고려했습니다. 이제 업로드할 파일을 수신할 서버를 준비할 차례입니다.

각 폴더를 자체 Azure 파일 공유에 동기화할 모든 폴더를 만듭니다. 이전에 문서화한 폴더 구조를 따르는 것이 중요합니다. 예를 들어, 여러 로컬 SMB 공유를 단일 Azure 파일 공유로 동기화하기로 결정한 경우 이를 볼륨의 공통 루트 폴더 아래에 배치해야 합니다. 이제 볼륨에서 이 대상 루트 폴더를 만듭니다.

프로비전하는 Azure 파일 공유 수는 이 단계에서 만든 폴더 수와 루트 수준에서 동기화하려는 볼륨 수를 더한 수와 일치해야 합니다.

7단계: 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의 스토리지 동기화 서비스 리소스로 이동합니다. 왼쪽 메뉴에서 등록된 서버로 이동합니다. 여기에 서버가 나열됩니다.

8단계 - 동기화 구성

이 단계에서는 이전 단계에서 Windows Server 인스턴스에 설정한 모든 리소스 및 폴더를 서로 연결합니다.

  1. Azure Portal에 로그인합니다.
  2. 스토리지 동기화 서비스 리소스를 찾습니다.
  3. 각 Azure 파일 공유에 대한 스토리지 동기화 서비스 리소스 내에 새 '동기화 그룹'을 만듭니다. Azure 파일 동기화 용어로, Azure 파일 공유는 동기화 토폴로지에서 동기화 그룹 만들기로 설명하는 '클라우드 엔드포인트'가 됩니다. 동기화 그룹을 만들 때 여기에 동기화되는 파일 집합을 인식할 수 있도록 친숙한 이름을 지정합니다. 일치하는 이름의 Azure 파일 공유를 참조하는지 확인합니다.
  4. 동기화 그룹을 만든 후에는 해당 그룹에 대한 행이 동기화 그룹 목록에 표시됩니다. 이름(링크)을 선택하여 동기화 그룹의 내용을 표시합니다. 클라우드 엔드포인트 아래에서 Azure 파일 공유를 볼 수 있습니다.
  5. 서버 엔드포인트 추가 단추를 찾습니다. 프로비전한 로컬 서버의 폴더가 이 서버 엔드포인트의 경로가 됩니다.

Warning

클라우드 계층화를 켜야 합니다. 이는 StorSimple 클라우드 스토리지에 있는 데이터의 전체 크기를 저장하는 데 충분한 공간이 로컬 서버에 없는 경우에 필요합니다. 계층화 정책을 99%의 볼륨 사용 가능한 공간으로 일시적으로 설정하고 마이그레이션이 완료된 후 더 합리적인 수준으로 다시 변경합니다.

동기화하기 위해 구성해야 하는 모든 Azure 파일 공유/서버 위치에 대해 동기화 그룹 생성 및 일치하는 서버 폴더를 서버 엔드포인트로 추가하는 단계를 반복합니다.

9단계: 파일 복사

기본 마이그레이션 방식은 StorSimple 가상 어플라이언스에서 Windows Server로 RoboCopy 및 Azure 파일 공유로 Azure 파일 동기화입니다.

Windows Server 대상 폴더에 첫 번째 로컬 복사를 실행합니다.

  • 가상 StorSimple 어플라이언스의 첫 번째 위치를 식별합니다.
  • Azure 파일 동기화가 이미 구성되어 있는 Windows Server에서 일치하는 폴더를 식별합니다.
  • RoboCopy를 사용하여 복사를 시작합니다.

다음 RoboCopy 명령은 StorSimple Azure Storage에서 로컬 StorSimple로 파일을 회수한 다음 Windows Server 대상 폴더로 이동합니다. Windows Server를 Azure 파일 공유와 동기화합니다. 로컬 Windows Server 볼륨이 가득 차면 클라우드 계층화가 시작되고 이미 동기화된 파일이 계층화됩니다. 클라우드 계층화는 StorSimple 클라우드 어플라이언스에서 복사를 계속하기에 충분한 공간을 생성합니다. 클라우드 계층화는 한 시간에 한 번씩 확인하여 무엇이 동기화되었는지 확인하고 99%의 볼륨 여유 공간에 도달할 수 있도록 디스크 공간을 확보합니다.

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 시나리오에 대한 중요한 수정 사항이 포함되어 있습니다.

RoboCopy 명령을 처음 실행하는 경우 사용자와 애플리케이션은 여전히 StorSimple 파일 및 폴더에 액세스하고 있으며 잠재적으로 변경할 수 있습니다. RoboCopy가 디렉터리를 처리하고 다음 디렉터리로 이동한 후 원본 위치(StorSimple)의 사용자가 현재 RoboCopy 실행에서 처리되지 않는 파일을 추가, 변경 또는 삭제할 수 있습니다. 괜찮습니다.

첫 번째 실행은 대량의 데이터를 다시 온-프레미스로 이동하고 Windows Server로 이동한 다음 Azure 파일 동기화를 통해 클라우드로 백업하는 것입니다. 다음에 따라 시간이 오래 걸릴 수 있습니다.

  • 다운로드 대역폭
  • StorSimple 클라우드 서비스의 회수 속도
  • 업로드 대역폭
  • 두 서비스 중 하나에서 처리해야 하는 항목(파일 및 폴더) 수

초기 실행이 완료되면 명령을 다시 실행합니다.

마지막 실행 후에 발생한 변경 내용만 전송하면 되기 때문에 두 번째 실행은 더 빨리 완료됩니다. 이러한 변경 사항은 최근이기 때문에 이미 StorSimple에 로컬일 가능성이 있습니다. 이렇게 하면 클라우드에서 회수할 필요가 감소하기 때문에 시간이 더 줄어듭니다. 하지만 이 두 번째 실행 중에 새로운 변경 내용이 누적될 수 있습니다.

완료하는 데 걸리는 시간이 허용 가능한 가동 중지 시간에 도달할 때까지 이 프로세스를 반복합니다.

허용 가능한 가동 중지 시간을 고려하고 StorSimple 위치를 오프라인으로 전환할 준비가 되었으면 지금 실행합니다. 예를 들어, 어떤 사용자도 폴더에 액세스할 수 없도록 SMB 공유를 제거하거나 StorSimple에서 이 폴더의 콘텐츠가 변경되지 않도록 방지하는 다른 적절한 단계를 수행합니다.

RoboCopy를 마지막으로 한 번 실행합니다. 그러면 놓쳤을 수도 있는 변경 내용이 복사됩니다. 마지막 단계에 걸리는 시간은 RoboCopy 검색 속도에 따라 달라집니다. 이전 실행에 걸린 시간을 측정하여 시간(가동 중지 시간과 동일)을 예측할 수 있습니다.

공유를 Windows Server 폴더에 만들고, 이를 가리키도록 DFS-N 배포를 조정할 수 있습니다. StorSimple SMB 공유와 동일한 공유 수준의 권한을 설정해야 합니다.

이제 마이그레이션에 매핑한 내용에 따라 공유 또는 공유 그룹을 공통 루트 또는 볼륨으로 마이그레이션하는 작업이 완료되었습니다.

이러한 복사본 중 일부를 병렬로 실행할 수 있습니다. 한 번에 하나의 Azure 파일 공유 범위를 처리하는 것이 좋습니다.

Warning

모든 데이터를 StorSimple에서 Windows Server로 이동하고 마이그레이션이 완료되고 나면 Azure Portal의 모든 동기화 그룹으로 돌아가서 클라우드 계층화 볼륨의 사용 가능한 공간(%) 값을 캐시 사용률에 더 적합한 값(예: 20%)으로 조정합니다.

클라우드 계층화 볼륨 사용 가능한 공간 정책은 잠재적으로 여러 서버 엔드포인트가 동기화되는 볼륨 수준에서 작동합니다. 하나의 서버 엔드포인트에서도 사용 가능한 공간을 조정하는 것을 잊어버린 경우 동기화는 가장 제한적인 규칙을 계속 적용하고 99%의 여유 디스크 공간을 유지하여 로컬 캐시는 예상대로 작동하지 않습니다. 거의 액세스하지 않는 보관 데이터만 포함하는 볼륨의 네임스페이스만 사용하는 것이 목표가 아니라면 모든 서버 엔드포인트에서 사용 가능한 공간 정책을 조정해야 합니다.

문제 해결

발생할 가능성이 높은 문제는 RoboCopy 명령이 Windows Server의 "볼륨 가득 참"으로 인해 실패하는 것입니다. 이 경우 다운로드 속도가 업로드 속도보다 좋을 가능성이 높습니다. 클라우드 계층화는 1시간 한 번씩 작동하여 동기화된 로컬 Windows Server 디스크에서 콘텐츠를 비웁니다.

동기화를 진행하고 클라우드 계층화를 통해 디스크 공간을 확보하도록 합니다. Windows Server의 파일 탐색기에서 이를 확인할 수 있습니다.

Windows Server에 사용 가능한 용량이 충분한 경우에는 명령을 다시 실행하면 문제가 해결됩니다. 이런 상황이 발생해도 큰 문제는 없으며 계속 작업을 진행해도 됩니다. 단지 명령을 다시 실행해야 하는 불편함이 있을 뿐입니다.

다른 Azure 파일 동기화 문제가 발생할 수도 있습니다. 이 경우 Azure 파일 동기화 문제 해결 가이드를 참조하세요.

지정된 RoboCopy 실행의 속도 및 성공률은 몇 가지 요인에 따라 달라집니다.

  • 원본 및 대상 스토리지의 IOPS
  • 원본 및 대상 간의 사용 가능한 네트워크 대역폭
  • 네임스페이스에서 파일 및 폴더를 빠르게 처리할 수 있는 기능
  • RoboCopy 실행 간의 변경 횟수
  • 복사해야 하는 파일의 크기 및 수

IOPS 및 대역폭 고려 사항

이 범주에서는 원본 스토리지, 대상 스토리지 및 연결하는 네트워크의 기능을 고려해야 합니다. 가능한 최대 처리량은 이러한 세 가지 구성 요소 중 가장 느린 크기에 의해 결정됩니다. 최적의 전송 속도를 최상의 기능으로 지원하도록 네트워크 인프라가 구성되어 있는지 확인합니다.

주의

가능한 한 빨리 복사하는 것이 가장 바람직한 경우가 많지만 중요 비즈니스용 작업에 로컬 네트워크 및 NAS 어플라이언스를 활용하는 것을 고려해야 합니다.

마이그레이션을 통해 사용 가능한 리소스를 독점할 수 있는 경우 최대한 빨리 복사하는 것은 바람직하지 않을 수 있습니다.

  • 사용자 환경에서 마이그레이션을 실행하는 데 가장 적합한 시간(낮, 업무 외 시간 또는 주말 동안)을 고려합니다.
  • 또한 Windows Server에서 네트워킹 QoS를 고려하여 RoboCopy 속도를 제한합니다.
  • 마이그레이션 도구에 대한 불필요한 작업을 방지합니다.

RoboCopy는 n이 RoboCopy 패킷 사이에 밀리초 단위로 측정되는 /IPG:n 스위치를 지정하여 패킷 간 지연을 삽입할 수 있습니다. 이 스위치를 사용하면 IO 제한된 디바이스 및 복잡한 네트워크 링크 모두에서 리소스 독점을 방지할 수 있습니다.

특정 Mbps의 정확한 네트워크 대역폭 제한에 /IPG:n을 사용할 수 없습니다. 대신 Windows Server 네트워크 QoS를 사용하십시오. RoboCopy는 모든 네트워킹 요구 사항에 대해 SMB 프로토콜을 전적으로 사용합니다. SMB를 사용하는 것은 RoboCopy가 네트워크 처리량 자체에 영향을 주지 않지만 사용 속도를 저하시킬 수 있는 이유입니다.

NAS에서 관찰된 IOPS에도 유사한 줄의 고려 사항이 적용됩니다. NAS 볼륨의 클러스터 크기, 패킷 크기 및 기타 요인의 배열은 관찰된 IOPS에 영향을 미칩니다. 패킷 간 지연을 도입하는 것이 NAS의 부하를 제어하는 가장 쉬운 방법인 경우가 많습니다. 예를 들어 약 20밀리초(n=20)에서 해당 숫자의 배수까지 여러 값을 테스트합니다. 지연이 발생하면 다른 앱이 예상대로 작동할 수 있는지 평가할 수 있습니다. 이 최적화 전략을 사용하면 사용자 환경에서 최적의 RoboCopy 속도를 찾을 수 있습니다.

처리 속도

RoboCopy는 가리키는 네임스페이스를 트래버스하고 복사할 각 파일 및 폴더를 평가합니다. 모든 파일은 초기 복사 중과 후속 복사 중에 평가됩니다. 예를 들어 동일한 원본 및 대상 스토리지 위치에 대해 RoboCopy /MIR을 반복적으로 실행합니다. 이러한 반복 실행은 사용자 및 앱의 가동 중지 시간을 최소화하고 마이그레이션된 파일의 전반적인 성공률을 개선하는 데 유용합니다.

대역폭을 마이그레이션에서 가장 제한적인 요인으로 고려하는 경우가 많으며, 이는 사실일 수 있습니다. 그러나 네임스페이스를 열거하는 기능은 더 작은 파일이 있는 더 큰 네임스페이스에 대해 복사하는 총 시간에 영향을 줄 수 있습니다. 다른 모든 변수가 동일하게 유지된다고 가정할 때 1TiB의 작은 파일을 복사하는 것은 1TiB의 더 적지만 큰 파일을 복사하는 것보다 훨씬 오래 걸릴 수 있습니다. 따라서 많은 수의 작은 파일을 마이그레이션하는 경우 전송 속도가 느려질 수 있습니다. 이는 예상되는 동작입니다.

이러한 차이의 원인은 네임스페이스를 진행하는 데 필요한 처리 능력입니다. RoboCopy는 /MT:n 매개 변수를 통해 다중 스레드 복사본을 지원합니다. 여기서 n은 사용할 스레드 수를 나타냅니다. 따라서 RoboCopy용 머신을 프로비전할 때 프로세서 코어 수와 제공하는 스레드 수와의 관계를 고려합니다. 가장 일반적인 것은 코어당 두 개의 스레드입니다. 머신의 코어 및 스레드 수는 지정해야 하는 다중 스레드 값 /MT:n을 결정하는 중요한 데이터 포인트입니다. 또한 지정된 머신에서 병렬로 실행하려는 RoboCopy 작업 수도 고려합니다.

스레드 수가 많을수록 작은 파일의 1TiB 예제는 적은 수의 스레드보다 훨씬 빠르게 복사됩니다. 이와 동시에 대용량 파일 1TiB에 추가 리소스를 투자해도 비례적인 이점이 없을 수 있습니다. 높은 스레드 수는 네트워크를 통해 더 많은 대용량 파일을 동시에 복사하려고 시도합니다. 이러한 추가 네트워크 활동은 처리량 또는 스토리지 IOPS에 의해 제약을 받을 가능성을 높입니다.

빈 대상에 대해 첫 번째 RoboCopy를 수행하거나 변경된 파일이 많은 차등 실행 중에 네트워크 처리량에 제약을 받을 수 있습니다. 초기 실행의 경우 높은 스레드 수로 시작합니다. 컴퓨터에서 현재 사용 가능한 스레드를 넘은 높은 스레드 수로 인해 사용 가능한 네트워크 대역폭이 포화될 수 있습니다. 후속 /MIR 실행은 처리 항목에 의해 점진적으로 영향을 받습니다. 차등 실행에서 변경 사항이 적으면 네트워크를 통한 데이터 전송이 줄어듭니다. 이제 속도는 네트워크 링크를 통해 이동하는 것보다 네임스페이스 항목을 처리하는 기능에 따라 달라집니다. 후속 실행의 경우 스레드 수 값을 프로세서 코어 수 및 코어당 스레드 수와 일치시킵니다. 프로덕션 서버에서 수행할 수 있는 다른 작업을 위해 코어를 예약해야 하는지 여부를 고려하세요.

팁

경험 규칙: 대기 시간이 더 긴 네트워크의 많은 데이터를 이동하는 첫 번째 RoboCopy 실행은 스레드 수(/MT:n)를 과도하게 프로비저닝하는 이점을 제공합니다. 후속 실행은 더 적은 차이를 복사하며, 제한된 네트워크 처리량에서 컴퓨팅 제한으로 전환할 가능성이 더 높습니다. 이러한 상황에서는 RoboCopy 스레드 수를 머신에서 실제로 사용할 수 있는 스레드와 일치시키는 것이 좋습니다. 이 시나리오에서 과도하게 프로비저닝하면 프로세서의 컨텍스트가 더 많이 바뀌어 복사본 속도가 느려질 수 있습니다.

불필요한 작업 방지

네임스페이스의 대규모 변경 사항을 방지합니다. 예를 들어 디렉터리 간에 파일을 이동하거나, 대규모로 속성을 변경하거나, 사용 권한(NTFS ACL)을 변경합니다. 특히 ACL 변경은 폴더 계층 구조의 하위 파일에 대해 연계된 변경 효과를 갖고 있기 때문에 높은 영향을 줄 수 있습니다. 결과는 다음과 같을 수 있습니다.

  • ACL 변경의 영향을 받는 각 파일 및 폴더를 업데이트해야 하기 때문에 확장된 RoboCopy 작업 실행 시간
  • 이전에 이동한 재사용 데이터를 다시 복사해야 할 수도 있습니다. 예를 들어 이전에 파일이 이미 복사된 후 폴더 구조가 변경될 때 더 많은 데이터를 복사해야 합니다. RoboCopy 작업은 네임스페이스 변경을 "재생"할 수 없습니다. 다음 작업은 이전에 이전 폴더 구조로 전송된 파일을 제거하고 새 폴더 구조에 파일을 다시 업로드해야 합니다.

또 다른 중요한 측면은 RoboCopy 도구를 효과적으로 사용하는 것입니다. 권장되는 RoboCopy 스크립트를 사용하여 오류에 대한 로그 파일을 만들고 저장합니다. 복사 오류가 발생할 수 있습니다. 이는 정상입니다. 이러한 오류로 인해 RoboCopy와 같은 복사 도구를 여러 라운드 실행해야 하는 경우가 많습니다. NAS에서 DataBox로 또는 서버에서 Azure 파일 공유로의 초기 실행입니다. /MIR 스위치를 사용하여 하나 이상의 추가 실행을 통해 복사되지 않은 파일을 catch하고 다시 시도합니다.

지정된 네임스페이스 범위에 대해 RoboCopy의 여러 라운드 실행을 준비해야 합니다. 연속 실행은 복사할 공간이 적지만 네임스페이스 처리 속도에 따라 점점 더 제한되기 때문에 더 빠르게 완료됩니다. 여러 라운드가 실행되면 RoboCopy가 지정된 실행에서 모든 것을 복사하는 데 불합리하게 어렵게 시도하지 않도록 하여 각 라운드의 속도를 단축할 수 있습니다. 이러한 RoboCopy 스위치는 상당한 차이를 만들 수 있습니다.

  • /R:n n = 실패한 파일 복사를 다시 시도할 빈도
  • /W:n n = 다시 시도 작업 사이의 대기 시간(초)

/R:5 /W:5는 원하는 대로 조정할 수 있는 적절한 설정입니다. 이 예제에서 실패한 파일은 재시도 사이에 5초 대기 시간으로 5번 다시 시도됩니다. 파일을 복사하지 못하면 다음 RoboCopy 작업이 다시 시도합니다. 사용 중이거나 시간 제한 문제로 인해 실패한 파일은 결국 이러한 방식으로 성공적으로 복사될 수 있습니다.

Windows Server 2022 및 RoboCopy LFSM

RoboCopy 스위치 /LFSM을 사용하면 볼륨 전체 오류로 인해 RoboCopy 작업이 실패하지 않도록 할 수 있습니다. RoboCopy는 파일 복사로 인해 대상 볼륨의 사용 가능한 공간이 "floor" 값 아래로 내려갈 때마다 일시 중지됩니다.

Windows Server 2022에서 RoboCopy를 사용하세요. 중요한 버그 픽스 및 스위치가 대부분의 마이그레이션에 필요한 추가 플래그와 호환되도록 하는 기능이 이 버전의 RoboCopy에만 포함되어 있습니다. /B 플래그와의 호환성을 예로 들 수 있습니다.

/B는 백업 애플리케이션이 사용하는 것과 동일한 모드에서 RoboCopy를 실행합니다. 이 스위치를 사용하면 RoboCopy가 현재 사용자에게 권한이 없는 파일을 이동할 수 있습니다.

일반적으로 RoboCopy는 원본, 대상 또는 세 번째 머신에서 실행할 수 있습니다.

Important

/LFSM을 사용하려면 RoboCopy를 Windows Server 2022 대상 Azure 파일 동기화 서버에서 실행해야 합니다.

또한 /LFSM을 사용하는 경우에는 대상에 UNC 경로가 아닌 로컬 경로를 사용해야 합니다. 예를 들어 대상 경로로 \\ServerName\FolderName 같은 UNC 경로 대신 E:\Foldername을 사용해야 합니다.

주의

현재 Windows Server 2022에서 사용 가능한 RoboCopy 버전에는 일시 중지를 파일당 오류 수로 집계하는 버그가 있습니다. 다음 해결 방법을 적용하세요.

권장하는 /R:2 /W:1 플래그는 /LFSM이 유도한 일시 중지로 인해 파일이 실패할 확률을 높입니다. 이 예제에서는 /LFSM이 일시 중지를 유발했기 때문에 3번의 일시 중지 후에 복사되지 않은 파일이 RoboCopy에서 파일을 잘못 실패하게 만듭니다. 이에 대한 해결 방법은 /R:n 및 /W:n에 더 높은 값을 사용하는 것입니다. 예를 들어 /R:10 /W:1800(각각 30분 10회 재시도)으로 하면 좋습니다. 이렇게 하면 대상 볼륨에 공간을 만드는 시간을 Azure 파일 동기화 계층화 알고리즘에 제공할 수 있습니다.

이 버그는 수정되었지만 아직 픽스를 공개적으로 사용할 수 없습니다. 이 단락을 확인하여 픽스의 가용성 및 픽스 배포 방법에 대한 새로운 소식을 확인하세요.

참고 항목

여전히 궁금한 점이 있거나 문제가 있나요?
저희가 도와드리겠습니다. 이메일 주소를 한 단어로: Microsoft Dot com의 Azure Files 마이그레이션

마이그레이션 콘텐츠:

Azure 파일 동기화 콘텐츠: