Azure 파일 동기화로 StorSimple 8100 및 8600 마이그레이션

StorSimple 8000 시리즈에는 8100 또는 8600 실제 온-프레미스 어플라이언스와 해당 클라우드 서비스 구성 요소가 포함되어 있습니다. StorSimple 8010 및 8020 가상 어플라이언스도 이 마이그레이션 가이드에서 다룹니다. 선택적 Azure 파일 동기화를 사용하여 이러한 어플라이언스 중 하나에서 Azure 파일 공유로 데이터를 마이그레이션할 수 있습니다. Azure 파일 동기화는 StorSimple 온-프레미스 기능을 대체하는 전략적 장기 Azure 서비스입니다. 이 문서에서는 Azure 파일 동기화로 성공적으로 마이그레이션하기 위해 필요한 배경 지식과 마이그레이션 단계를 제공합니다.

1단계: 마이그레이션 준비

이 섹션에는 StorSimple 볼륨에서 Azure 파일 공유로 마이그레이션을 시작할 때 수행해야 하는 단계가 포함되어 있습니다.

재고품

마이그레이션 계획을 시작할 때 가장 먼저 마이그레이션할 모든 StorSimple 어플라이언스와 볼륨을 파악합니다. 그런 다음 최상의 마이그레이션 경로를 결정할 수 있습니다.

• StorSimple 물리적 어플라이언스(8000 시리즈)는 이 마이그레이션 가이드를 사용합니다.
• StorSimple 가상 어플라이언스(1200 시리즈)는 다른 마이그레이션 가이드를 사용합니다.

마이그레이션 비용 요약

StorSimple Data Manager 리소스의 마이그레이션 작업을 통해 StorSimple 볼륨에서 Azure 파일 공유로 마이그레이션하는 작업은 무료입니다. 마이그레이션 도중 및 마이그레이션 후에 다른 비용이 발생할 수 있습니다.

• 네트워크 송신: StorSimple 파일은 특정 Azure 지역 내의 스토리지에 있습니다. 동일한 Azure 지역의 스토리지 계정으로 마이그레이션하는 Azure 파일 공유를 프로비전하는 경우 송신 비용이 발생하지 않습니다. 그러나 이 마이그레이션의 일부로 파일을 다른 지역의 스토리지 계정으로 이동하는 경우 송신 비용이 적용됩니다.
• Azure 파일 공유 트랜잭션: 파일이 Azure 파일 공유에 복사되는 경우(마이그레이션 과정에서 또는 마이그레이션 이외의 과정에서) 파일 및 메타데이터가 작성될 때 트랜잭션 비용이 적용됩니다. 마이그레이션 중에 트랜잭션 최적화 계층에서 Azure 파일 공유를 시작하고, 마이그레이션이 완료된 후 원하는 계층으로 전환하는 것이 가장 좋은 방법입니다. 이 문서에 설명된 단계에서는 적절한 지점에서 이를 호출합니다.
• Azure 파일 공유 계층 변경: Azure 파일 공유 계층을 변경하면 트랜잭션 비용이 발생합니다. 대부분의 경우 이전 지점의 조언을 따르는 것이 더 비용 효율적입니다.
• 스토리지 비용: 마이그레이션 과정에서 Azure 파일 공유에 파일이 복사되기 시작하면 스토리지가 사용되고 비용이 청구됩니다. 마이그레이션된 백업은 Azure 파일 공유 스냅샷이 됩니다. 파일 공유 스냅샷은 포함된 내용 중 다른 부분에만 스토리지 용량을 사용합니다.
• StorSimple: StorSimple 어플라이언스 및 스토리지 계정의 프로비전을 해제할 때까지 스토리지, 백업 및 어플라이언스에 대한 StorSimple 비용이 계속 발생합니다.

직접 공유 액세스 대 Azure 파일 동기화

Azure 파일 공유는 파일 서비스 배포를 구성할 수 있는 새로운 기회를 제공합니다. Azure 파일 공유는 친숙한 Kerberos 인증 및 기존 NTFS 권한(파일 및 폴더 ACL)이 기본적으로 작동하는 SMB 프로토콜을 통해 사용자가 직접 액세스하도록 설정할 수 있는 클라우드의 SMB 공유입니다. Azure 파일 공유에 대한 ID 기반 액세스에 대해 자세히 알아보세요.

직접 액세스의 대안은 Azure 파일 동기화입니다. Azure 파일 동기화는 온-프레미스에서 자주 사용되는 파일을 캐시하는 StorSimple의 직접적인 아날로그 기능입니다.

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

• 모든 Windows Server에서 성능 액세스 캐시를 만드는 파일 동기화 및 클라우드 계층화
• SMB, 파일 REST 등의 여러 프로토콜을 통해 액세스할 수 있는 Azure의 기본 스토리지인 파일 공유

Azure 파일 공유는 특성, 권한 및 타임스탬프와 같은 중요한 파일 충실도 측면을 보존합니다. Azure 파일 공유를 사용하면 애플리케이션 또는 서비스에서 더 이상 클라우드에 저장된 파일 및 폴더를 해석할 필요가 없습니다. 익숙한 프로토콜과 클라이언트를 통해 기본적으로 액세스할 수 있습니다. Azure 파일 공유를 사용하면 범용 파일 서버 데이터 및 애플리케이션 데이터를 클라우드에 저장할 수 있습니다.

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

• Azure 파일 동기화 계획 가이드
• Azure 파일 동기화 배포 가이드

StorSimple 서비스 데이터 암호화 키

StorSimple 어플라이언스를 처음으로 설정할 때 서비스 데이터 암호화 키가 생성되고 키를 안전하게 저장하라는 지침이 표시됩니다. 이 키는 StorSimple 어플라이언스가 파일을 저장하는 연결된 Azure 스토리지 계정의 모든 데이터를 암호화하는 데 사용됩니다.

마이그레이션이 성공하려면 서비스 데이터 암호화 키가 필요합니다. 사용자의 기록에서 사용자의 인벤토리에 있는 각 어플라이언스에 대해 하나씩 이 키를 검색합니다.

레코드에서 키를 찾을 수 없는 경우 어플라이언스에서 새 키를 생성할 수 있습니다. 각 어플라이언스에는 고유한 암호화 키가 있습니다.

서비스 데이터 암호화 키 변경

서비스 데이터 암호화 키는 StorSimple 관리자 서비스에서 StorSimple 디바이스로 전송된 스토리지 계정 자격 증명 등의 기밀 고객 데이터를 암호화하는 데 사용됩니다. IT 조직에 스토리지 디바이스에 대한 키 회전 정책이 있는 경우 이러한 키를 주기적으로 변경해야 합니다. 키 변경 프로세스는 StorSimple Manager 서비스에서 관리하는 디바이스가 단일 디바이스인지, 여러 디바이스인지에 따라 약간 달라질 수 있습니다. 자세한 내용은 StorSimple 보안 및 데이터 보호로 이동합니다.

서비스 데이터 암호화 키는 3단계 프로세스에 따라 변경됩니다.

1. Azure Resource Manager에 Windows PowerShell 스크립트를 사용하여 서비스 데이터 암호화 키를 변경하도록 디바이스에 권한을 부여합니다.
2. StorSimple용 Windows PowerShell을 사용하여 서비스 데이터 암호화 키 변경을 시작합니다.
3. 둘 이상의 StorSimple 디바이스를 사용하는 경우에는 다른 디바이스에서 서비스 데이터 암호화 키를 업데이트합니다.

1단계: Windows PowerShell 스크립트를 사용하여 디바이스에 서비스 데이터 암호화 키를 변경할 권한을 부여합니다.

일반적으로 디바이스 관리자는 서비스 관리자가 디바이스에 서비스 데이터 암호화 키를 변경할 수 있는 권한을 부여하도록 요청합니다. 그러면 서비스 관리자는 디바이스에 키를 변경할 수 있는 권한을 부여합니다.

Azure Resource Manager 기반 스크립트를 사용하여 이 단계를 수행합니다. 서비스 관리자는 권한을 부여할 수 있는 디바이스를 선택할 수 있습니다. 그러면 디바이스에 서비스 데이터 암호화 키 변경 프로세스를 시작할 수 있는 권한이 부여됩니다.

스크립트를 사용하는 방법에 대한 자세한 내용은 Authorize-ServiceEncryptionRollover.ps1로 이동합니다.

서비스 데이터 암호화 키를 변경할 권한이 부여될 수 있는 디바이스

서비스 데이터 암호화 키 변경을 시작할 권한을 부여받으려면 디바이스가 다음 조건을 충족해야 합니다.

• 디바이스는 온라인 상태여야 서비스 데이터 암호화 키 변경 권한 부여 대상이 됩니다.
• 키 변경이 시작되지 않은 경우 30분 후에 동일한 디바이스에 권한을 다시 부여할 수 있습니다.
• 이전에 권한을 부여받은 디바이스에서 키 변경을 시작하지 않은 경우 다른 디바이스에 권한을 부여할 수 있습니다. 새 디바이스에 권한을 부여하면 이전 디바이스는 변경을 시작할 수 없습니다.
• 서비스 데이터 암호화 키 롤오버가 진행 중인 동안에는 디바이스에 권한을 부여할 수 없습니다.
• 서비스에 등록된 디바이스 중 일부만 롤오버한 경우에는 디바이스에 권한을 부여할 수 있습니다.

2단계: StorSimple용 Windows PowerShell을 사용하여 서비스 데이터 암호화 키 변경 시작

이 단계는 권한이 부여된 StorSimple 디바이스의 StorSimple용 Windows PowerShell 인터페이스에서 수행됩니다.

디바이스 직렬 콘솔을 사용하여 Windows PowerShell 인터페이스에 연결하는 경우 다음 단계를 수행합니다.

서비스 데이터 암호화 키 변경을 시작하려면

1. 옵션 1을 선택하여 모든 권한으로 로그온합니다.

2. 명령 프롬프트에서 다음을 입력합니다.

   Invoke-HcsmServiceDataEncryptionKeyChange

3. cmdlet이 성공적으로 완료되면 새 서비스 데이터 암호화 키를 얻을 수 있습니다. 이 키를 복사하고 저장해 두었다가 이 프로세스의 3단계에서 사용합니다. 이 키는 StorSimple 관리자 서비스에 등록된 나머지 모든 디바이스를 업데이트하는 데 사용됩니다.

   참고 항목

   이 프로세스는 StorSimple 디바이스에 권한을 부여한 후 4시간 이내에 시작되어야 합니다.

   이 새 키는 서비스로 전송되어 서비스에 등록된 모든 디바이스에 푸시됩니다. 서비스 대시보드에 경고가 표시됩니다. 서비스는 등록된 디바이스에서 모든 작업을 사용할 수 없도록 설정합니다. 그러면 디바이스 관리자는 다른 디바이스에서 서비스 데이터 암호화 키를 업데이트해야 합니다. 그러나 I/O(클라우드로 데이터를 보내는 호스트)는 중단되지 않습니다.

   단일 디바이스를 서비스에 등록한 경우 이제 롤오버 프로세스가 완료되었으므로 다음 단계를 건너뛸 수 있습니다. 여러 디바이스를 서비스에 등록한 경우 3단계를 진행합니다.

3단계: 다른 StorSimple 디바이스에서 서비스 데이터 암호화 키 업데이트

여러 디바이스를 StorSimple 관리자 서비스에 등록한 경우 StorSimple 디바이스의 Windows PowerShell 인터페이스에서 다음 단계를 수행해야 합니다. StorSimple Manager 서비스로 등록된 나머지 StorSimple 디바이스를 업데이트하는 데 2단계에서 가져온 키를 사용해야 합니다.

다음 단계를 수행하여 디바이스에서 서비스 데이터 암호화를 업데이트합니다.

물리적 디바이스에서 서비스 데이터 암호화 키를 업데이트하려면

1. StorSimple용 Windows PowerShell을 사용하여 콘솔에 연결합니다. 옵션 1을 선택하여 모든 권한으로 로그온합니다.
2. 명령 프롬프트에 다음을 입력합니다. Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
3. 2단계: StorSimple용 Windows PowerShell을 사용하여 서비스 데이터 암호화 키 변경 시작에서 얻은 서비스 데이터 암호화 키를 제공합니다.

모든 8010/8020 클라우드 어플라이언스에서 서비스 데이터 암호화 키를 업데이트하려면

1. Update-CloudApplianceServiceEncryptionKey.ps1 PowerShell 스크립트를 다운로드하여 설치합니다.
2. PowerShell을 열고 명령 프롬프트에서 다음을 입력합니다. Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

이 스크립트는 디바이스 관리자 아래의 모든 8010/8020 클라우드 어플라이언스에 서비스 데이터 암호화 키가 설정되었는지 확인합니다.

알려진 제한 사항

StorSimple Data Manager 및 Azure 파일 공유에는 마이그레이션을 방지할 수 있으므로 시작하기 전에 고려해야 할 몇 가지 제한 사항이 있습니다.

• StorSimple 어플라이언스의 NTFS 볼륨만 지원됩니다. ReFS 볼륨은 지원되지 않습니다.
• Windows Server 동적 디스크에 배치된 볼륨은 지원되지 않습니다.
• BitLocker로 암호화되거나 데이터 중복 제거가 사용하도록 설정된 볼륨에서는 서비스가 작동하지 않습니다.
• 손상된 StorSimple 백업은 마이그레이션할 수 없습니다.
• 방화벽 또는 프라이빗 엔드포인트 전용 통신과 같은 특수 네트워킹 옵션은 StorSimple 백업이 저장되는 원본 스토리지 계정이나 Azure 파일 공유를 보유하는 대상 스토리지 계정에서 사용하도록 설정할 수 없습니다.

파일 충실도

알려진 제한 사항의 어떤 제한 사항도 마이그레이션을 방해하지 않는 경우에도 Azure 파일 공유에 저장할 수 있는 항목에는 여전히 제한 사항이 있습니다.

파일 충실도는 파일을 구성하는 다양한 특성, 타임스탬프 및 데이터를 나타냅니다. 마이그레이션에서 파일 충실도는 원본(StorSimple 볼륨)의 정보를 대상 Azure 파일 공유 로 얼마나 잘 변환(마이그레이션)할 수 있는지 측정합니다.

Azure Files는 NTFS 파일 속성의 하위 집합을 지원합니다. Windows ACL, 일반 메타데이터 및 일부 타임스탬프가 마이그레이션됩니다.

다음 항목은 마이그레이션을 방지하지 않지만 마이그레이션 중에 항목별 문제를 일으킬 수 있습니다.

• 타임스탬프: 파일 변경 시간이 설정되지 않습니다. 현재 REST 프로토콜을 통한 읽기 전용입니다. 파일의 마지막 액세스 타임스탬프는 Azure 파일 공유에 저장된 파일에 대해 지원되는 특성이 아니기 때문에 이동되지 않습니다.
• 대체 데이터 스트림은 Azure 파일 공유에 저장할 수 없습니다. 대체 데이터 스트림이 포함된 파일은 복사되지만 프로세스의 파일에서 대체 데이터 스트림이 제거됩니다.
• 바로 가기 링크, 하드 링크, 분기 동기화 및 재분석 지점은 마이그레이션 중에 건너뜁니다. 마이그레이션 복사 로그에는 건너뛴 각 항목과 이유가 나열됩니다.
• EFS 암호화된 파일이 복사되지 않습니다. 복사 로그에는 "액세스가 거부되었습니다"라는 메시지와 함께 복사에 실패한 항목이 표시됩니다.
• 손상된 파일은 건너뜁니다. 복사 로그에는 StorSimple 디스크에서 손상된 각 항목에 대해 "치명적인 디바이스 하드웨어 오류로 인해 요청이 실패했습니다.", "파일 또는 디렉터리가 손상되었거나 읽을 수 없습니다." 또는 "ACL(액세스 제어 목록) 구조가 잘못되었습니다." 등의 다양한 오류가 나열될 수 있습니다.
• 4TiB보다 큰 개별 파일은 건너뜁니다.
• 파일 경로 길이는 2048자 이하여야 합니다. 경로가 더 긴 파일과 폴더는 건너뜁니다.
• 재분석 지점을 건너뜁니다. Microsoft 데이터 중복 제거/SIS 재분석 지점 또는 타사 재분석 지점은 마이그레이션 엔진에서 확인할 수 없으며 영향을 받는 파일 및 폴더의 마이그레이션을 방지할 수 없습니다.

이 문서의 끝부분에 있는 문제 해결 섹션에는 항목 수준 및 마이그레이션 작업 수준 오류 코드와 가능한 경우 완화 옵션에 대한 자세한 내용이 있습니다.

StorSimple 볼륨 백업

StorSimple은 볼륨 수준에서 차등 백업을 제공합니다. Azure 파일 공유에도 공유 스냅샷이라고 하는 이 기능이 있습니다.

마이그레이션 작업에서는 라이브 볼륨의 데이터가 아닌 백업만 이동할 수 있습니다. 최근 백업은 라이브 데이터와 가장 가까우며, 따라서 항상 마이그레이션에서 이동할 백업 목록에 포함되어야 합니다.

마이그레이션에서 이전 백업을 이동해야 하는지 여부를 결정합니다. 마이그레이션 작업이 더 빨리 완료되도록 이 목록을 가능한 한 작게 유지하는 것이 모범 사례입니다.

반드시 마이그레이션해야 하는 중요한 백업을 확인하려면 백업 정책의 검사 목록을 만듭니다. 예시:

• 최근 백업.
• 12개월 동안 한 달에 한 번 백업
• 3년 동안 1년에 한 번 백업

마이그레이션 작업을 만들 때 이 목록을 사용하여 요구 사항을 충족하기 위해 마이그레이션해야 하는 정확한 StorSimple 볼륨 백업을 식별할 수 있습니다.

마이그레이션을 위해 백업을 선택하기 전에 모든 StorSimple 백업 보존 정책을 일시 중단하는 것이 가장 좋습니다. 백업을 마이그레이션하는 데 며칠 또는 몇 주가 걸릴 수 있습니다. StorSimple은 백업을 삭제하는 백업 보존 정책을 제공합니다. 이 마이그레이션을 위해 선택한 백업은 마이그레이션되기 전에 삭제될 수 있습니다.

기존 StorSimple 볼륨을 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 파일 공유(동기화 외부)에서 직접 변경한 내용을 더 빠르게 검색하고 동기화할 수 있습니다.

배포 맵에 대한 구조적 접근 방법

이후 단계에서 클라우드 스토리지를 배포하기 전에 온-프레미스 폴더와 Azure 파일 공유 간에 맵을 만드는 것이 중요합니다. 그런 다음 이 매핑은 프로비저닝할 Azure 파일 동기화 동기화 그룹 리소스 및 개수를 알려줍니다. 동기화 그룹은 Azure 파일 공유와 서버의 폴더를 함께 연결하고 동기화 연결을 설정합니다.

필요한 Azure 파일 공유 수를 결정하려면 다음 제한 및 모범 사례를 검토하세요. 그러면 맵을 최적화하는 데 도움이 됩니다.

• Azure 파일 동기화 에이전트가 설치된 서버는 최대 30개의 Azure 파일 공유와 동기화될 수 있습니다.

• Azure 파일 공유는 스토리지 계정 내에 배포됩니다. 이러한 정렬로 인해 스토리지 계정은 IOPS 및 처리량과 같은 성능 수치를 위한 크기 조정 대상이 됩니다.

  Azure 파일 공유를 배포할 때 스토리지 계정의 IOPS 제한 사항에 주의합니다. 파일 공유를 스토리지 계정과 1:1로 매핑하는 것이 이상적입니다. 그러나 조직과 Azure 모두의 다양한 제한과 제약으로 인해 항상 가능한 것은 아닙니다. 하나의 스토리지 계정에 파일 공유를 하나만 배포할 수 없는 경우 어떤 공유가 작업 수행이 활발한지와 덜 사용되는지를 고려하여 가장 많이 사용하는 파일 공유가 동일한 스토리지 계정에 함께 포함되지 않도록 하세요.

  Azure 파일 공유를 기본적으로 사용하는 Azure에 앱을 올리려는 경우 Azure 파일 공유의 성능이 더 필요할 수 있습니다. 이러한 유형의 사용이 나중에라도 가능성이 있는 경우 고유한 스토리지 계정에서 단일 표준 Azure 파일 공유를 만드는 것이 가장 좋습니다.

• Azure 지역별로 구독당 스토리지 계정 수가 250개로 제한됩니다.

동기화 범위당 항목 수를 적게 유지하는 것이 가장 좋습니다. 이는 폴더를 Azure 파일 공유에 매핑할 때 고려해야 할 중요한 요소입니다. Azure 파일 동기화는 공유당 1억 항목(파일 및 폴더)을 사용하여 테스트되었습니다. 그러나 단일 공유에서 2천만 또는 3천만 미만의 항목 수를 유지하는 것이 가장 좋습니다. 이러한 수치를 초과하기 시작하는 경우 네임스페이스를 여러 공유로 분할합니다. 이러한 수치를 초과하기 전에는 여러 온-프레미스 공유를 동일한 Azure 파일 공유로 계속 그룹화할 수 있습니다. 이 방법은 확장의 여지를 제공합니다.

상황에 따라 폴더 집합이 앞에서 언급한 새로운 공통 루트 폴더 접근 방식을 사용하여 동일한 Azure 파일 공유에 논리적으로 동기화할 수 있습니다. 하지만 폴더를 다시 그룹화하여 Azure 파일 공유 한 개가 아니라 두 개에 동기화하는 것이 더 나을 수 있습니다. 이 방법을 사용하여 파일 공유당 파일 및 폴더 수를 서버 전체에 분산된 상태로 유지할 수 있습니다. 또한 온-프레미스 공유를 분할하고 더 많은 온-프레미스 서버에서 동기화하여 추가 서버마다 30개 이상의 Azure 파일 공유와 동기화하는 기능을 추가할 수 있습니다.

일반적인 파일 동기화 시나리오 및 고려 사항

매핑 테이블 만들기

이전 정보를 사용하여 필요한 Azure 파일 공유 수와 기존 데이터의 어떤 부분이 어떤 Azure 파일 공유로 끝날지 결정하세요.

필요할 때 참고할 수 있도록 생각을 기록하는 표를 만듭니다. 여러 Azure 리소스를 한 번에 프로비전할 때 매핑 계획의 세부 사항을 지나치기 쉬우므로 구성된 상태로 유지하는 것이 중요합니다. 다음 Excel 파일을 다운로드하여 매핑을 만드는 데 도움이 되는 템플릿으로 사용합니다.

네임스페이스 매핑 템플릿을 다운로드합니다.

스토리지 계정 수

각각 더 적은 수의 Azure 파일 공유를 보유하는 여러 스토리지 계정을 배포하면 마이그레이션에 도움이 될 것입니다.

파일 공유가 매우 활발한 경우(여러 사용자 또는 애플리케이션에서 파일 공유를 사용하는 경우) 두 개의 Azure 파일 공유가 스토리지 계정의 성능 제한에 도달할 수 있습니다. 이 때문에 각각 고유한 개별 파일 공유가 있고 일반적으로 스토리지 계정당 공유가 2~3개 이하인 여러 스토리지 계정으로 마이그레이션하는 것이 더 나은 경우가 많습니다. 가장 좋은 것은 각각 파일 공유가 하나씩 있는 스토리지 계정을 배포하는 것입니다. Azure 파일 공유에 보관 공유가 있다면 여러 Azure 파일 공유를 동일한 스토리지 계정으로 풀링할 수 있습니다.

이러한 고려 사항은 Azure 파일 동기화보다 직접 클라우드 액세스(Azure VM 또는 서비스를 통해)에 더 많이 적용됩니다. 이러한 공유에서 Azure 파일 동기화를 독점적으로 사용하려는 경우 여러 항목을 단일 Azure Storage 계정으로 그룹화하는 것이 좋습니다. 나중에 앱을 클라우드로 리프트 앤 시프트하여 파일 공유에 직접 액세스할 수 있습니다. 이 시나리오에서는 IOPS 및 처리량을 높이면 도움이 되기 때문입니다. 또는 IOPS 및 처리량이 높으면 좋은 Azure 서비스로 시작할 수도 있습니다.

공유 목록을 만든 후 각 공유를 상주할 스토리지 계정에 매핑합니다. Azure 지역을 결정하고, 각 스토리지 계정과 Azure 파일 동기화 리소스가 선택한 지역과 일치하는지 확인합니다.

스토리지 계정 설정

스토리지 계정에는 다양한 구성을 수행할 수 있습니다. 다음 검사 목록을 사용하여 스토리지 계정 구성을 확인합니다. 마이그레이션이 완료된 후 네트워킹 구성을 변경할 수 있습니다.

1단계 요약

1 단계를 마치면 다음과 같이 됩니다.

• StorSimple 디바이스 및 볼륨의 개요를 이해했습니다.
• 각 StorSimple 디바이스의 서비스 데이터 암호화 키를 검색했으므로 Data Manager 서비스에서 클라우드의 StorSimple 볼륨에 액세스할 수 있습니다.
• 어떤 볼륨과 백업(최근 백업이 아닌 백업이 있는 경우)을 마이그레이션해야 하는지 계획이 있습니다.
• 볼륨을 적절한 수의 Azure 파일 공유 및 스토리지 계정에 매핑하는 방법을 알고 있습니다.

2단계: Azure 스토리지 및 마이그레이션 리소스 배포

이 섹션에서는 Azure에 필요한 여러 리소스 종류의 배포에 대한 고려 사항을 설명합니다. 일부는 마이그레이션 후 데이터를 포함하고 있고 일부는 마이그레이션에만 필요합니다. 배포 계획을 완료하기 전에는 리소스 배포를 시작하지 마세요. Azure 리소스를 배포한 후에는 리소스의 특정 양상을 변경하기가 어렵거나 불가능할 수 있습니다.

스토리지 계정 배포

여러 Azure 스토리지 계정을 배포해야 하는 경우가 많습니다. 각 파일은 배포 계획에 따라 더 적은 수의 Azure 파일 공유를 보유합니다. Azure Portal로 이동하여 계획된 스토리지 계정을 배포합니다. 새 스토리지 계정에 대해 다음과 같은 기본 설정을 준수하는 것이 좋습니다.

구독

StorSimple 배포에 사용한 것과 동일한 구독을 사용하거나 다른 구독을 사용할 수 있습니다. 유일한 제한 사항은 구독이 StorSimple 구독과 동일한 Microsoft Entra 테넌트에 있어야 한다는 것입니다. 마이그레이션을 시작하기 전에 StorSimple 구독을 적절한 테넌트로 이동하는 것이 좋습니다. 개별 StorSimple 리소스는 다른 테넌트 또는 구독으로 이동할 수 없으므로 전체 구독만 이동할 수 있습니다.

Resource group

Azure의 리소스 그룹은 리소스 구성 및 관리자 관리 권한을 지원합니다. 자세히 알아보기.

스토리지 계정 이름

스토리지 계정의 이름은 파일 공유에 액세스하는 데 사용되는 URL의 일부가 되며 특정 문자 제한 사항이 있습니다. 스토리지 계정 이름은 전 세계에서 고유해야 하고, 소문자와 숫자만 사용할 수 있고, 길이는 3~24자여야 하고, 하이픈이나 밑줄 같은 특수 문자를 사용할 수 없다는 명명 규칙을 고려해야 합니다. Azure Storage 리소스 명명 규칙을 참조하세요.

위치

스토리지 계정의 Azure 지역이 중요합니다. Azure 파일 동기화를 사용하는 경우 모든 스토리지 계정은 스토리지 동기화 서비스 리소스와 동일한 지역에 있어야 합니다. 사용자가 선택하는 Azure 지역은 로컬 서버 및 사용자와 가까이 있거나 중앙에 있어야 합니다. 리소스를 배포한 후에는 해당 지역을 변경할 수 없습니다.

현재 StorSimple 데이터(스토리지 계정)가 있는 다른 지역을 선택할 수 있습니다. 하지만 그렇게 하면 마이그레이션 중에 송신 요금이 부과됩니다. 데이터는 StorSimple 지역을 나가서 새로운 스토리지 계정 영역으로 들어갑니다. 동일한 Azure 지역 내에 머물면 대역폭 요금이 적용되지 않습니다.

성능

Azure 파일 공유 또는 표준 스토리지에 프리미엄 스토리지(SSD)를 선택하는 옵션이 있습니다. 표준 스토리지에는 파일 공유에 대한 여러 계층이 포함되어 있습니다. 표준 스토리지는 StorSimple에서 마이그레이션하는 대부분의 고객에게 적합한 옵션입니다.

• 프리미엄 Azure 파일 공유의 성능이 필요하면 프리미엄 스토리지를 선택합니다.
• 핫 데이터 및 보관 데이터를 포함하는 범용 파일 서버 워크로드에는 표준 스토리지를 선택합니다. 클라우드의 공유에 있는 유일한 워크로드가 Azure 파일 동기화인 경우 표준 스토리지를 선택합니다.
• 프리미엄 파일 공유의 경우 스토리지 계정 만들기 마법사에서 파일 공유를 선택합니다.

복제

여러 가지 복제 설정이 있습니다. 다음 두 가지 옵션 중에서만 선택합니다.

• LRS(로컬 중복 스토리지) .
• 일부 Azure 지역에서 사용할 수 있는 ZRS(영역 중복 스토리지).

Azure 파일 공유

스토리지 계정을 만든 후 스토리지 계정의 파일 공유 섹션으로 이동하여 1단계의 마이그레이션 계획에 따라 적절한 수의 Azure 파일 공유를 배포합니다. Azure의 새 파일 공유에 대한 다음 기본 설정을 준수하는 것이 좋습니다.

StorSimple Data Manager

마이그레이션 작업을 보관하는 Azure 리소스를 StorSimple Data Manager라고 합니다. 새 리소스를 선택하고 새 리소스를 검색합니다. 다음으로 만들기를 선택합니다.

이 임시 리소스는 오케스트레이션에 사용됩니다. 마이그레이션이 완료된 후 이 리소스의 프로비전을 해제합니다. StorSimple 스토리지 계정과 동일한 구독, 리소스 그룹 및 지역에 배포해야 합니다.

Azure 파일 동기화

Azure 파일 동기화를 사용하면 자주 액세스하는 파일의 온-프레미스 캐싱을 추가할 수 있습니다. StorSimple의 캐싱 기능과 마찬가지로, Azure 파일 동기화 클라우드 계층화 기능은 Windows Server 인스턴스와 다중 사이트 동기화에서 사용 가능한 캐시 용량에 대한 향상된 제어 기능과 함께 로컬 액세스 대기 시간을 제공합니다. 온-프레미스 캐시가 목표인 경우 로컬 네트워크에서 충분한 직접 연결 스토리지 용량이 있는 Windows Server VM(물리적 서버 및 장애 조치(failover) 클러스터도 지원됨)을 준비합니다.

2단계 요약

2단계를 완료했으므로 스토리지 계정이 배포되고 모든 Azure 파일 공유가 스토리지 계정에 배포되었습니다. StorSimple Data Manager 리소스도 있습니다. 후자는 마이그레이션 작업을 구성할 때 3단계에서 사용됩니다.

3단계: 마이그레이션 작업 만들기 및 실행

이 섹션에서는 마이그레이션 작업을 설정하고, 선택한 대상 Azure 파일 공유에 복사해야 하는 StorSimple 볼륨의 디렉터리를 매핑하는 방법을 설명합니다.

시작하려면 StorSimple Data Manager로 이동하고, 메뉴에서 작업 정의를 찾고, + 작업 정의를 선택합니다. 올바른 대상 스토리지 유형은 기본값인 Azure 파일 공유입니다.

마이그레이션할 볼륨 백업 선택

마이그레이션할 백업 선택과 관련하여 중요한 사항이 있습니다.

• 마이그레이션 작업은 라이브 볼륨 데이터가 아닌 백업만 이동할 수 있습니다. 따라서 최근 백업은 라이브 데이터와 가장 가까이 있으며 항상 마이그레이션에서 이동할 백업 목록에 포함되어야 합니다. 백업 선택 대화 상자를 열면 기본적으로 선택됩니다.
• 최근 백업이 가장 최신인지 확인하여 라이브 공유의 델타를 최대한 작게 유지합니다. 마이그레이션 작업을 만들기 전에 다른 볼륨 백업을 수동으로 트리거하고 완료해 보는 것도 좋습니다. 실시간 공유에 대한 작은 변화로 마이그레이션 환경이 개선됩니다. 이 델타가 0일 수 있는 경우(목록에서 최신 백업이 수행된 후 StorSimple 볼륨에 더 이상 변경이 발생하지 않음을 의미), 사용자 컷오버가 대폭 간소화되고 속도가 빨라집니다.
• 백업은 Azure 파일 공유 오름차순(오래된 항목순)으로 다시 재생되어야 합니다. 마이그레이션 작업을 실행한 후에는 마이그레이션 백업을 Azure 파일 공유의 백업 목록으로 "정렬"할 수 없습니다. 따라서 작업을 만들기 전에 백업 목록이 완료되었는지 확인해야 합니다.
• 작업을 만든 후에는 작업을 실행하지 않아도 작업의 이 백업 목록을 수정할 수 없습니다.
• 백업을 선택하려면 마이그레이션할 StorSimple 볼륨이 온라인 상태여야 합니다.

디렉터리 매핑

디렉터리 매핑은 마이그레이션 작업의 선택 사항입니다. 이 섹션을 비워 두면 StorSimple 볼륨의 루트에 있는 모든 파일과 폴더가 대상 Azure 파일 공유의 루트로 이동됩니다. 대부분의 경우 전체 볼륨의 콘텐츠를 Azure 파일 공유에 저장하는 것은 가장 좋은 방법이 아닙니다. 볼륨 콘텐츠를 Azure의 여러 파일 공유에 분할하는 것이 좋은 경우가 많습니다. 아직 계획을 작성하지 않은 경우 Azure 파일 공유에 StorSimple 볼륨 매핑을 먼저 살펴보세요.

마이그레이션 계획을 작성할 때 StorSimple 볼륨의 폴더를 여러 Azure 파일 공유에 분할해야겠다고 결정했을 수 있습니다. 이 경우 다음과 같은 방법으로 분할할 수 있습니다.

1. 볼륨의 폴더를 마이그레이션하는 여러 작업을 정의합니다. 각 폴더에는 동일한 StorSimple 볼륨 원본이 포함되지만 Azure 파일 공유는 대상과 다릅니다.
2. 작업 만들기 양식의 디렉터리 매핑 섹션을 사용하고 특정 매핑 의미 체계에 따라 StorSimple 볼륨의 어떤 폴더를 지정된 파일 공유로 마이그레이션해야 하는지 정확하게 지정합니다.

의미 체계 요소

매핑은 왼쪽에서 오른쪽으로, 즉, [\원본 경로] > [\대상 경로]로 표시됩니다.

예제

User data 폴더의 콘텐츠를 대상 파일 공유의 루트로 이동합니다.

\User data > \

전체 볼륨 콘텐츠를 대상 파일 공유의 새 경로로 이동합니다.

\ > \Apps\HR tracker

원본 폴더 콘텐츠를 대상 파일 공유의 새 경로로 이동합니다.

\HR resumes-Backup > \Backups\HR\resumes

여러 원본 위치를 새 디렉터리 구조로 정렬합니다.

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

의미 체계 규칙

• 항상 루트 수준을 기준으로 폴더 경로를 지정합니다.
• 루트 수준 표시기 "\"로 각 폴더 경로를 시작합니다.
• 드라이브 문자를 포함하지 않습니다.
• 여러 경로를 지정할 때 원본 또는 대상 경로는 겹칠 수 없습니다.
  잘못된 원본 경로 겹침 예:
  \folder\1 > \folder
  \folder\1\2 > \folder2
  잘못된 대상 경로 겹침 예:
  \folder > \
  \folder2 > \
  
• 존재하지 않는 원본 폴더는 무시됩니다.
• 대상에 존재하지 않는 폴더 구조가 만들어집니다.
• Windows와 마찬가지로 폴더 이름은 대/소문자를 구분하지 않지만 대/소문자를 유지합니다.

마이그레이션 작업 실행

마이그레이션 작업은 리소스 그룹에 배포한 Data Manager 리소스의 작업 정의 아래에 나열됩니다. 작업 정의 목록에서 실행하려는 작업을 선택합니다.

열리는 작업 블레이드에서 작업의 현재 상태와 선택한 백업 목록을 볼 수 있습니다. 백업 목록은 가장 오래된 것부터 최신순으로 정렬되며 이 순서대로 Azure 파일 공유로 마이그레이션됩니다.

항목별 오류

마이그레이션 작업의 백업 목록에는 복사 중에 발생할 수 있는 문제를 나열하는 두 개의 열이 있습니다.

• 복사 오류
  이 열에는 복사해야 했지만 복사되지 않은 파일 또는 폴더가 나열됩니다. 이러한 오류는 종종 복구할 수 있습니다. 백업이 이 열에 항목 문제를 나열하면 복사 로그를 검토합니다. 이러한 파일을 마이그레이션해야 하는 경우 백업 다시 시도를 선택합니다. 이 옵션은 백업 처리가 완료되면 사용할 수 있게 됩니다. 마이그레이션 작업 관리 섹션에서 옵션에 대해 자세히 설명합니다.
• 지원되지 않는 파일
  이 열에는 마이그레이션할 수 없는 파일 또는 폴더가 나열됩니다. Azure Storage에는 현재 또는 논리적으로 Azure 파일 공유에 저장할 수 없는 파일 이름, 경로 길이 및 파일 형식에 대한 제한이 있습니다. 마이그레이션 작업은 이러한 종류의 오류에 대해 일시 중지되지 않습니다. 백업 마이그레이션을 다시 시도하면 결과가 변경되지 않습니다. 백업이 이 열에 항목 문제를 나열하면 복사 로그를 검토하고 기록해 두세요. 이러한 문제가 마지막 백업에서 발생하고 복사 로그에서 파일 이름, 경로 길이 또는 영향을 미치는 기타 문제로 인해 실패했음을 발견한 경우, 라이브 StorSImple 볼륨의 문제를 해결하고 StorSimple 볼륨 백업을 수행하고 해당 백업만으로 새 마이그레이션 작업을 만들 수 있습니다. 그런 다음 이 수정된 네임스페이스를 마이그레이션하면 Azure 파일 공유의 최신/라이브 버전이 됩니다. 이는 수동적이고 시간이 많이 걸리는 프로세스입니다. 복사 로그를 주의 깊게 검토하고 가치가 있는지 평가합니다.

이러한 로그는 성공한 네임스페이스 항목과 복사 실패한 항목이 나열된 *.csv 파일입니다. 오류는 이전에 논의된 범주로 더 나뉩니다. 로그 파일 위치에서 "failed"를 검색하여 실패한 파일에 대한 로그를 찾을 수 있습니다. 결과는 복사에 실패한 파일에 대한 로그 세트여야 합니다. 이 로그를 크기별로 정렬합니다. 17바이트 크기로 추가 로그가 생성될 수 있습니다. 이러한 로그는 비어 있으며 무시해도 됩니다. 정렬을 사용하면 콘텐츠가 있는 로그에 집중할 수 있습니다.

복사 성공이 기록된 로그 파일에도 동일한 프로세스가 적용됩니다.

마이그레이션 작업 관리

마이그레이션 작업의 상태는 다음과 같습니다.

• 실행되지 않음
  정의되었지만 실행되지 않은 새 작업입니다.
• 대기 중
  이 상태의 작업은 마이그레이션 서비스에서 리소스가 프로비전되기를 기다리고 있습니다. 준비가 되면 자동으로 다른 상태로 전환됩니다.
• 실패
  실패한 작업에 치명적인 오류가 발생하여 추가 백업을 처리할 수 없습니다. 작업이 이 상태로 들어갈 것으로 예상되지 않습니다. 지원 요청이 최선의 작업입니다.
• 취소됨 / 취소
  전체 마이그레이션 작업 또는 작업 내의 개별 백업을 취소할 수 있습니다. 취소된 마이그레이션 작업은 백업 처리를 중지하므로 취소된 백업은 처리되지 않습니다. 작업을 취소하는 데 오랜 시간이 걸릴 것으로 예상합니다. 이는 새 작업을 만드는 데 방해가 되지 않습니다. 가장 좋은 작업은 작업이 완전히 취소됨 상태가 되도록 하는 것입니다. 실패/취소된 작업을 무시하거나 나중에 삭제할 수 있습니다. StorSimple 마이그레이션이 끝날 때 Data Manager 리소스를 삭제하기 전에 작업을 삭제할 필요가 없습니다.

병렬로 작업 실행

Azure 파일 공유로 마이그레이션해야 하는 고유한 공유가 있는 여러 StorSimple 볼륨이 있을 수 있습니다. 병렬로 얼마나 많은 작업을 수행할 수 있는지 이해하는 것이 중요합니다. 사용자 환경에 적용되지 않는 제한 사항이 있으며 작업이 동시에 실행되는 경우 전체 마이그레이션을 저하시키거나 억제합니다.

마이그레이션 작업 정의에는 제한이 없습니다. 동일하거나 다른 StorSimple 어플라이언스에서 동일한 StorSimple 원본 볼륨, 동일한 Azure 파일 공유를 정의할 수 있습니다. 그러나 실행에는 다음과 같은 제한 사항이 있습니다.

• 동일한 StorSimple 원본 볼륨이 있는 하나의 마이그레이션 작업만 동시에 실행할 수 있습니다.
• 동일한 대상 Azure 파일 공유가 있는 하나의 마이그레이션 작업만 동시에 실행할 수 있습니다.
• 다음 작업을 시작하기 전에 이전 작업이 copy stage에 있고 최소 30분 동안 파일 이동 진행률이 표시되는지 확인합니다.
• 이전 규칙을 준수하는 한 StorSimple 디바이스 관리자당 최대 4개의 마이그레이션 작업을 병렬로 실행할 수 있습니다.

마이그레이션 작업을 시작하려고 하면 이전 규칙이 확인됩니다. 실행 중인 작업이 있으면 새 작업을 시작하지 못할 수도 있습니다. 새 작업을 시작하기 전에 완료해야 하는 현재 실행 중인 작업의 이름을 나열하는 경고를 받게 됩니다.

3단계 요약

3단계를 마치면 StorSimple 볼륨에서 Azure 파일 공유로 마이그레이션하는 작업을 한 번 이상 실행하게 됩니다. 실행을 통해 지정된 백업을 Azure 파일 공유 스냅샷으로 마이그레이션합니다. 이제 공유에 대한 Azure 파일 동기화 설정(공유에 대한 마이그레이션 작업이 완료된 후) 또는 Azure 파일 공유에 대한 정보 작업자 및 앱의 직접 공유 액세스에 집중할 수 있습니다.

4단계: Azure 파일 공유에 액세스

Azure 파일 공유에 액세스하는 두 가지 주요 전략은 다음과 같습니다.

• Azure 파일 동기화: 온-프레미스 Windows Server 인스턴스에 Azure 파일 동기화를 배포합니다. Azure 파일 동기화는 StorSimple과 마찬가지로 로컬 캐시의 모든 장점을 갖고 있습니다.
• 직접 공유 액세스: 직접 공유 액세스를 배포합니다. 지정된 Azure 파일 공유에 대한 액세스 시나리오에서 로컬 캐싱이 도움이 되지 않거나 더 이상 온-프레미스 Windows Server 인스턴스를 호스트할 수 없는 경우 이 전략을 사용합니다. 여기서 사용자와 앱은 SMB 프로토콜을 통해 SMB 공유에 계속 액세스할 수 있습니다. 이러한 공유는 더 이상 온-프레미스 서버에 없고 클라우드에서 직접 사용할 수 있습니다.

이 가이드의 1단계에서 가장 적합한 옵션을 이미 결정했습니다.

이 섹션의 나머지 부분에서는 배포 지침을 중점적으로 설명합니다.

Azure 파일 동기화 배포

Azure 파일 동기화의 일부를 배포할 시간입니다.

1. Azure 파일 동기화 클라우드 리소스를 만듭니다.
2. 온-프레미스 서버에 Azure 파일 동기화 에이전트를 배포합니다.
3. 서버를 클라우드 리소스에 등록합니다.

아직 동기화 그룹을 만들지 마세요. Azure 파일 공유와의 동기화는 Azure 파일 공유로 마이그레이션하는 작업이 완료된 후에 설정해야 합니다. 마이그레이션이 완료되기 전에 Azure 파일 동기화를 사용하기 시작하면 컷오버를 시작할 시간이 언제인지 쉽게 알 수 없기 때문에 마이그레이션이 불필요하게 어려워집니다.

Azure 파일 동기화 클라우드 리소스 배포

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

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

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

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

온-프레미스 Windows Server 인스턴스 배포

• Windows Server 2019(2012R2 이상)를 가상 머신 또는 물리적 서버로 만듭니다. Windows Server 장애 조치(failover) 클러스터도 지원됩니다. StorSimple 8100 또는 8600 앞의 서버를 다시 사용하지 마세요.
• DAS(직접 연결된 스토리지)를 프로비저닝하거나 추가합니다. Network Attached Storage는 지원되지 않습니다.

새 Windows Server 인스턴스에 StorSimple 8100 또는 8600 어플라이언스가 로컬로 캐싱에 사용할 수 있는 양보다 많거나 같은 스토리지를 제공하는 것이 가장 좋습니다. StorSimple 어플라이언스를 사용한 것과 같은 방식으로 Windows Server 인스턴스를 사용할 것입니다. 어플라이언스와 같은 양의 스토리지가 있으면 캐싱 환경이 완전히 같지는 않아도 비슷합니다. Windows Server 인스턴스의 스토리지를 마음대로 추가하거나 제거할 수 있습니다. 이 기능을 통해 로컬 볼륨 크기와 캐싱에 사용할 수 있는 로컬 스토리지의 양을 스케일링할 수 있습니다.

파일 동기화에 사용할 Windows Server 인스턴스 준비

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

Windows Server 인스턴스에서 Azure 파일 동기화 구성

이 프로세스를 진행하려면 등록된 온-프레미스 Windows Server 인스턴스가 준비되어 있고 인터넷에 연결되어 있어야 합니다.

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

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

직접 공유 액세스 배포

4단계 요약

이 단계가 끝나면 StorSimple Data Manager에서 여러 마이그레이션 작업을 만들고 실행했습니다. 이러한 작업은 파일 및 폴더와 해당 백업을 Azure 파일 공유로 마이그레이션했습니다. 또한 Azure 파일 동기화를 배포했거나 직접 공유 액세스를 위한 네트워크 및 스토리지 계정을 준비했습니다.

5단계: 사용자 중단

이 단계에서는 마이그레이션을 완료합니다.

• 가동 중지 시간을 계획합니다.
• 3단계에서 마이그레이션 작업을 실행하는 동안 StorSimple 쪽에서 사용자와 앱이 생성한 변경 내용을 업데이트합니다.
• Azure 파일 동기화를 사용하여 사용자를 새 Windows Server 인스턴스로 장애 조치(failover)하거나 직접 공유 액세스를 통해 Azure 파일 공유로 장애 조치(failover)합니다.

가동 중지 시간 계획

이 마이그레이션 방법에서는 사용자 및 앱에 대한 약간의 가동 중지 시간이 필요합니다. 목표는 가동 중지 시간을 최소화하는 것입니다. 다음 사항을 고려하면 도움이 됩니다.

• 마이그레이션 작업을 실행하는 동안 StorSimple 볼륨을 계속 사용할 수 있도록 유지합니다.
• 공유에 대한 데이터 마이그레이션 작업 실행이 완료된 후에는 StorSimple 볼륨 또는 공유에서 사용자 액세스 권한(최소한 쓰기 권한)을 제거해야 합니다. 최종 RoboCopy는 Azure 파일 공유를 업데이트합니다. 그 후 사용자를 중단할 수 있습니다. RoboCopy를 실행하는 위치는 Azure 파일 동기화를 사용하도록 선택했는지 아니면 직접 공유 액세스를 사용하도록 선택했는지에 따라 달라집니다. 다음 섹션에서는 해당 주제를 다룹니다.
• RoboCopy 업데이트가 완료되면 Azure 파일 공유를 사용하여 직접 또는 Azure 파일 동기화를 사용하는 Windows Server 인스턴스의 SMB 공유를 통해 새 위치를 사용자에게 표시할 수 있습니다. DFS-N 배포를 사용하면 중단을 신속하고 효율적으로 처리하는 데 도움이 되는 경우가 자주 있습니다. 이 배포는 기존 공유 주소를 일관적으로 유지하고 마이그레이션된 파일 및 폴더가 포함된 새 위치를 다시 가리킵니다.

보관 데이터의 경우 StorSimple 볼륨(또는 하위 폴더)에서 가동 중지 시간을 가져오고, StorSimple 볼륨 백업을 한 번 더 수행하고, 마이그레이션한 다음, 사용자와 앱이 액세스할 수 있도록 마이그레이션 대상을 여는 것이 완전히 실행 가능한 액세스 방식입니다. 이렇게 하면 보완 RoboCopy가 필요하지 않습니다. 그러나 이 접근 방식은 마이그레이션해야 하는 파일 및 백업의 수에 따라 며칠 또는 그 이상으로 늘어날 수 있는 가동 중지 시간이 길어지는 대가를 치르게 됩니다. 이는 장기간 쓰기 권한 없이 수행할 수 있는 보관 워크로드에 대한 옵션일 가능성이 높습니다.

네임스페이스가 서버와 완전히 동기화된 시간 확인

Azure 파일 공유에 Azure 파일 동기화를 사용하는 경우 로컬 RoboCopy를 시작하기 전에 전체 네임스페이스가 서버에 완전히 다운로드되었는지 확인해야 합니다. 네임스페이스를 다운로드하는 데 걸리는 시간은 Azure 파일 공유의 항목 수에 따라 달라집니다. 네임스페이스가 서버에 완전히 도착했는지 확인하는 두 가지 방법이 있습니다.

Azure Portal

Azure Portal을 사용하여 네임스페이스가 완전히 도착한 시간을 확인할 수 있습니다.

• Azure Portal에 로그인하고 동기화 그룹으로 이동합니다. 동기화 그룹과 서버 엔드포인트의 동기화 상태를 확인합니다.
• 알고 싶은 방향은 다운로드입니다. 서버 엔드포인트가 새로 프로비저닝되면 네임스페이스를 다운로드 중이라는 의미의 초기 동기화가 표시됩니다. 초기 동기화를 제외한 상태 작업 후, 서버에서 네임스페이스가 완전히 채워집니다.

이제 로컬 RoboCopy를 진행할 수 있습니다.

Windows Server 이벤트 뷰어

또한 Windows Server 인스턴스에서 이벤트 뷰어를 사용하여 네임스페이스가 완전히 도착한 시간을 확인할 수 있습니다.

1. 이벤트 뷰어를 열고 애플리케이션 및 서비스로 이동합니다.
2. Microsoft\FileSync\Agent\Telemetry로 이동하여 엽니다.
3. 완료된 동기화 세션에 해당하는 최신 9102 이벤트를 찾습니다.
4. 세부 정보를 선택하고, SyncDirection 값이 Download인 이벤트가 표시되는지 확인합니다.
5. 네임스페이스가 서버에 완전히 다운로드된 시간을 확인할 수 있도록 Scenario, FullGhostedSync 값, HResult = 0인 이벤트가 하나 있습니다.
6. 해당 이벤트를 놓친 경우 SyncDirection = Download이고 Scenario = "RegularSync"인 다른 9102 이벤트를 찾아볼 수도 있습니다. 이러한 이벤트 중 하나를 찾았다는 것은 현재 동기화할 항목이 있는지 여부에 관계 없이 네임스페이스 다운로드가 완료되었으며 동기화가 일반 동기화 세션으로 진행되었다는 뜻입니다.

최종 RoboCopy

지금은 온-프레미스 Windows Server 인스턴스와 StorSimple 8100 또는 8600 어플라이언스 간에 차이가 있습니다.

1. 마이그레이션이 진행되는 동안 StorSimple 쪽에서 사용자 또는 앱이 생성한 변경 내용을 업데이트해야 합니다.
2. Azure 파일 동기화를 사용하는 경우: StorSimple 어플라이언스에는 채워진 캐시가 있거나 현재 로컬로 저장된 파일 콘텐츠 없이 네임스페이스만 있는 Windows Server 인스턴스가 있습니다. 최종 RoboCopy는 로컬로 캐시된 파일 콘텐츠를 가능한 만큼 풀링하여 로컬 Azure 파일 동기화 캐시를 신속하게 시작하고 Azure 파일 동기화 서버에 맞게 조정할 수 있습니다.
3. 일부 파일은 잘못된 문자로 인해 마이그레이션 작업에서 남겨질 수 있습니다. 이 경우 Azure 파일 동기화를 사용하는 Windows Server 인스턴스로 이러한 파일을 복사합니다. 나중에 동기화되도록 조정할 수 있습니다. 특정 공유에 대해 Azure 파일 동기화를 사용하지 않는 경우 StorSimple 볼륨에서 잘못된 문자로 파일 이름을 바꾸는 것이 좋습니다. 그런 다음, Azure 파일 공유에 대해 직접 RoboCopy를 실행합니다.

마이그레이션 작업을 마지막으로 실행한 이후에 변경된 파일과 이전에 이러한 작업을 통해 이동하지 않은 파일만 복사하려고 합니다. 마이그레이션이 완료된 후 나중에 서버에서 파일이 이동하지 않은 이유와 관련된 문제를 해결할 수 있습니다. 자세한 내용은 Azure 파일 동기화 문제 해결을 참조하세요.

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> 

RoboCopy 명령의 원본 및 대상 위치를 구성할 때 원본과 대상의 구조를 검토하여 일치하는지 확인해야 합니다. 마이그레이션 작업의 디렉터리 매핑 기능을 사용하는 경우 루트 디렉터리 구조가 StorSimple 볼륨의 구조와 다를 수 있습니다. 이 경우 하위 디렉터리마다 하나씩 여러 개의 RoboCopy 작업이 필요할 수 있습니다. 명령이 예상대로 수행되는지 확실하지 않은 경우에는 /L 매개 변수를 사용할 수 있습니다. 이 매개 변수는 실제로 변경하지 않고 명령을 시뮬레이션합니다.

이 RoboCopy 명령은 /MIR을 사용하므로 동일한 파일(예: 계층화된 파일)을 이동하지 않습니다. 하지만 원본 및 대상 경로가 잘못된 경우 /MIR은 StorSimple 소스 경로에 없는 Windows Server 인스턴스 또는 Azure 파일 공유의 디렉터리 구조까지 제거합니다. 마이그레이션된 콘텐츠를 마이그레이션이 진행되는 동안 수행된 최신 변경 내용으로 업데이트하는 목표를 달성하려면 RoboCopy 작업과 정확히 일치해야 합니다.

RoboCopy 로그 파일을 검토하여 남겨진 파일이 있는지 확인합니다. 문제가 있으면 수정하고 RoboCopy 명령을 다시 실행합니다. 관심 있는 파일 또는 폴더와 관련된 미해결 문제를 수정하기 전에는 StorSimple 리소스의 프로비전을 해제하지 마세요.

Azure 파일 동기화를 사용하여 원하는 Azure 파일 공유를 캐시하지 않고 직접 공유 액세스를 선택한 경우:

1. Azure 파일 공유를 로컬 Windows 머신의 네트워크 드라이브로 탑재합니다.
2. StorSimple과 탑재된 Azure 파일 공유 간에 RoboCopy를 수행합니다. 파일이 복사되지 않으면 StorSimple 쪽에서 이름을 수정하여 잘못된 문자를 제거합니다. 그런 다음, RoboCopy를 다시 시도합니다. StorSimple을 불필요하게 회수하는 일 없이, 이전에 나열된 RoboCopy 명령을 여러 번 실행할 수 있습니다.

문제 해결 및 최적화

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

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

IOPS 및 대역폭 고려 사항

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

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

• 사용자 환경에서 마이그레이션을 실행하는 데 가장 적합한 시간(낮, 업무 외 시간 또는 주말 동안)을 고려합니다.
• 또한 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 실행은 처리 항목에 의해 점진적으로 영향을 받습니다. 차등 실행에서 변경 사항이 적으면 네트워크를 통한 데이터 전송이 줄어듭니다. 이제 속도는 네트워크 링크를 통해 이동하는 것보다 네임스페이스 항목을 처리하는 기능에 따라 달라집니다. 후속 실행의 경우 스레드 수 값을 프로세서 코어 수 및 코어당 스레드 수와 일치시킵니다. 프로덕션 서버에서 수행할 수 있는 다른 작업을 위해 코어를 예약해야 하는지 여부를 고려하세요.

불필요한 작업 방지

네임스페이스의 대규모 변경 사항을 방지합니다. 예를 들어 디렉터리 간에 파일을 이동하거나, 대규모로 속성을 변경하거나, 사용 권한(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는 원본, 대상 또는 세 번째 머신에서 실행할 수 있습니다.

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

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

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

사용자 전환

Azure 파일 동기화를 사용하는 경우 StorSimple 볼륨에 있는 공유와 일치하는 Azure 파일 동기화 사용 Windows Server 인스턴스에서 SMB 공유를 만들어야 합니다. 이 단계를 앞부분에 배치하고 일찍 수행하면 여기서 시간을 낭비하지 않을 수 있습니다. 그러나 이 시점 전에는 누구에게도 Windows Server 인스턴스를 변경하는 액세스 권한이 없어야 합니다.

DFS-N을 배포한 경우 DFN-네임스페이스가 새 서버 폴더 위치를 가리키게 할 수 있습니다. DFS-N을 배포하지 않았으며 Windows Server 인스턴스를 사용하여 8100 또는 8600 어플라이언스를 로컬로 프론팅한 경우 해당 서버를 도메인에서 분리할 수 있습니다. 그런 다음, 새 Azure 파일 동기화 사용 Windows Server 인스턴스를 도메인 가입합니다. 중단이 사용자, 그룹 정책 및 스크립트에 대해 투명하게 유지되도록 이 프로세스 중에 이전 서버와 동일한 서버 이름과 공유 이름을 서버에 지정합니다.

DFS-N에 대해 자세히 알아보세요.

6단계: 프로비저닝 해제

리소스의 프로비전을 해제하면 해당 리소스와 해당 데이터의 구성에 대한 액세스 권한이 사라집니다. 프로비전 해제는 실행 취소할 수 없습니다. 다음 사항을 확인하기 전에는 진행하지 마세요.

• 마이그레이션이 완료되었습니다.
• 프로비전을 해제할 StorSimple 파일, 폴더 또는 볼륨 백업에 대한 종속성이 없습니다.

시작하기 전에, 잠시 프로덕션 환경에서 새 Azure 파일 동기화 배포를 관찰하는 것이 좋습니다. 이 시간을 통해 발생 가능성이 있는 문제를 해결할 수 있습니다. Azure 파일 동기화 배포를 적어도 며칠 정도 관찰한 후, 다음 순서로 리소스의 프로비전을 해제하면 됩니다.

1. Azure Portal을 통해 StorSimple Data Manager 리소스의 프로비전을 해제합니다. 모든 DTS 작업이 함께 삭제됩니다. 복사 로그는 쉽게 검색할 수 없습니다. 레코드에 중요한 복사 로그인 경우 프로비전을 해제하기 전에 검색합니다.
2. StorSimple 물리적 어플라이언스가 마이그레이션되었는지 확인하고 등록을 취소합니다. 마이그레이션되었는지 확실하지 않으면 계속하지 마세요. 여전히 필요한 리소스를 프로비전 해제하는 경우 데이터 또는 해당 구성을 복구할 수 없습니다.
   필요에 따라 우선 StorSimple 볼륨 리소스의 프로비전을 해제할 수 있습니다. 그러면 어플라이언스의 데이터가 정리됩니다 이 프로세스는 며칠이 걸릴 수 있으며 어플라이언스의 데이터를 과학적으로 제로 아웃하지 않습니다. 이것이 중요한 경우 프로비전 해제와 별도로 정책에 따라 디스크 제로화를 처리합니다.
3. StorSimple 디바이스 관리자에 더 이상 등록된 디바이스가 남아 있지 않으면 디바이스 관리자 리소스 자체를 제거할 수 있습니다.
4. 이제 Azure에서 StorSimple 스토리지 계정을 삭제할 시간입니다. 마찬가지로 마이그레이션이 완료되었으며 이 데이터에 종속된 사람 또는 항목이 하나도 없는 것을 확인한 후 계속 진행합니다.
5. 데이터 센터에서 StorSimple 물리적 어플라이언스를 분리합니다.
6. StorSimple 어플라이언스가 본인 소유인 경우에는 PC 재활용이 가능합니다. 임대 디바이스인 경우에는 임대인에게 알리고 디바이스를 적절하게 반환합니다.

마이그레이션이 완료되었습니다.

문제 해결

StorSimple Data Manager 마이그레이션 서비스를 사용하는 경우 여러 가지 이유로 전체 마이그레이션 작업 또는 개별 파일이 실패할 수 있습니다. 파일 충실도 섹션에는 지원되는 시나리오와 지원되지 않는 시나리오에 대한 자세한 내용이 있습니다. 다음 표에는 오류 코드, 오류 세부 정보 및 가능한 경우 완화 옵션이 나와 있습니다.

작업 수준 오류

항목 수준 오류

마이그레이션 작업 실행의 복사 단계에서 개별 네임스페이스 항목(파일 및 폴더)에 오류가 발생할 수 있습니다. 다음 표에서는 가장 일반적인 오류를 나열하고 가능한 경우 완화 옵션을 제안합니다.

다음 단계

• 클라우드 계층화 정책의 유연성을 알아봅니다.
• Azure 파일 공유에서 Azure Backup을 사용하여 스냅샷을 예약하고 백업 보존 일정을 정의합니다.
• Azure Portal에서 일부 파일이 영구적으로 동기화되지 않는 것이 발견되면 문제 해결 가이드에서 문제 해결 단계를 검토합니다.