DataBox를 사용하여 NAS(네트워크 연결 스토리지)에서 Azure 파일 공유로 마이그레이션

아티클
05/16/2024

이 마이그레이션 문서는 NAS 및 Azure DataBox라는 키워드와 관련된 여러 문서 중 하나입니다. 이 문서가 다음 시나리오에 적용되는지 확인합니다.

데이터 원본: NAS(네트워크 연결 스토리지)
마이그레이션 경로: NAS ⇒ DataBox ⇒ Azure 파일 공유
온-프레미스에 캐싱 파일 없음: 최종 목표는 클라우드에서 직접 Azure 파일 공유를 사용하는 것이므로 Azure 파일 동기화를 사용할 계획이 없습니다.

시나리오가 다른 경우 마이그레이션 가이드 표를 살펴보세요.

이 문서에서는 NAS 어플라이언스에서 작동하는 Azure 파일 공유로 마이그레이션하는 데 필요한 계획, 배포 및 네트워킹 구성을 통해 엔드투엔드 방식으로 안내합니다. 이 가이드에서는 Azure DataBox를 대량 데이터 전송(오프라인 데이터 전송)에 사용합니다.

적용 대상

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

마이그레이션 목표

목표는 NAS 어플라이언스의 공유를 Azure로 이동하여 기본 Azure 파일 공유가 되도록 하는 것입니다. Windows Server 없이도 네이티브 Azure 파일 공유를 사용할 수 있습니다. 이 마이그레이션은 마이그레이션하는 동안 프로덕션 데이터의 무결성과 가용성을 보장하는 방식으로 수행해야 합니다. 후자는 가동 중지 시간을 최소로 유지하여 정기적인 유지 보수 기간에 맞추거나 약간 초과할 수 있습니다.

마이그레이션 개요

마이그레이션 프로세스는 몇 가지 단계로 구성됩니다. Azure 스토리지 계정 및 파일 공유를 배포하고 네트워킹을 구성해야 합니다. 그런 다음, Azure DataBox 및 RoboCopy를 사용해 파일을 마이그레이션하여 변경 내용을 파악합니다. 마지막으로, 사용자와 앱을 새로 만든 Azure 파일 공유로 잘라냅니다. 다음 섹션에서는 마이그레이션 프로세스의 단계에 대해 자세히 설명합니다.

팁

이 문서로 돌아가는 경우 오른쪽의 탐색 영역을 사용하여 중단한 마이그레이션 단계로 이동합니다.

1단계: 필요한 Azure 파일 공유 수 확인

이 단계에서는 필요한 Azure 파일 공유 수를 결정합니다. 현재 로컬에서 SMB 공유로 사용자 및 앱과 공유하는 볼륨에는 이보다 많은 폴더가 있을 수 있습니다. 클라우드로 마이그레이션하려는 파일 공유 수에 따라 1:1 매핑을 사용하거나 공유 그룹화를 선택할 수 있습니다.

1:1 매핑 사용

공유 수가 충분히 적은 경우 1:1 매핑을 사용하는 것이 좋습니다. 이 시나리오는 Azure 파일 공유에 1:1 매핑되는 온-프레미스 공유를 생각해보면 쉽게 상상할 수 있습니다.

파일 공유의 수가 많은 경우에는 공유 그룹화를 고려합니다. 예를 들어 HR(인사) 부서에 15개의 공유가 있는 경우 모든 HR 데이터를 단일 Azure 파일 공유에 저장하는 것을 고려할 수 있습니다. 이런 방식으로 이 그룹의 온-프레미스 공유에는 클라우드에서 단일 Azure 파일 공유만 필요합니다.

2단계: Azure 스토리지 리소스 배포

이 단계에서는 Azure Storage 계정 및 계정 내의 파일 공유를 프로비전합니다.

Azure 파일 공유는 Azure 스토리지 계정의 클라우드에 배포됩니다. 표준 파일 공유의 경우, 이러한 정렬로 인해 스토리지 계정은 IOPS 및 처리량과 같은 성능 수치를 위한 크기 조정 대상이 됩니다. 단일 스토리지 계정에 여러 파일 공유를 배치하는 것은 이러한 공유에 대한 IOPS 및 처리량 공유 풀을 만드는 것을 의미합니다.

일반적으로 보관 공유가 있거나 일상 활동이 적을 것으로 예상되는 경우 여러 Azure 파일 공유를 동일한 스토리지 계정으로 풀할 수 있습니다. 그러나 매우 활발하게 공유(많은 사용자 및/또는 애플리케이션에서 사용하는 공유)가 수행되는 경우 각각 하나의 파일 공유를 사용하여 스토리지 계정을 배포하는 것이 좋습니다. 이러한 제한 사항은 FileStorage(프리미엄) 스토리지 계정에는 적용되지 않습니다. 이 경우 성능이 명시적으로 프로비전되고 각 공유에 대해 보장됩니다.

참고 항목

Azure 지역별로 구독당 스토리지 계정 수가 250개로 제한됩니다. 할당량을 늘리면 지역당 최대 500개의 스토리지 계정을 만들 수 있습니다. 자세한 내용은 Azure Storage 계정 할당량 증가를 참조하세요.

스토리지 계정을 배포할 때 고려해야 할 또 다른 사항은 중복도입니다. Azure Files 중복도를 참조하세요.

공유 목록을 만든 경우 각 공유를 생성될 스토리지 계정에 매핑해야 합니다.

리소스의 이름도 중요합니다. 예를 들어 HR 부서의 여러 공유를 Azure 스토리지 계정 하나로 그룹화하는 경우 스토리지 계정의 이름을 적절하게 지정해야 합니다. 마찬가지로 Azure 파일 공유의 이름을 지정할 때 온-프레미스 파일 공유에 사용되는 이름과 비슷한 이름을 사용해야 합니다.

이제 SMB 파일 공유 만들기의 지침에 따라 적절한 수의 Azure 파일 공유가 있는 적절한 수의 Azure Storage 계정을 배포합니다. 대부분의 경우 각 스토리지 계정의 지역이 동일한지 확인해야 합니다.

3단계: 필요한 Azure DataBox 어플라이언스 수 확인

이 단계는 이전 단계를 완료한 경우에만 시작합니다. 이 시점에서 Azure 스토리지 리소스(스토리지 계정 및 파일 공유)를 만들어야 합니다. DataBox 주문 중에 DataBox에서 데이터를 이동할 스토리지 계정을 지정해야 합니다.

이 단계에서는 이전 단계의 마이그레이션 계획 결과를 사용 가능한 DataBox 옵션의 제한에 매핑해야 합니다. 이러한 고려 사항은 선택해야 하는 DataBox 옵션 및 NAS 공유를 Azure 파일 공유로 이동하는 데 필요한 옵션 수를 계획하는 데 도움이 됩니다.

필요한 유형의 디바이스 수를 확인하려면 다음과 같은 중요한 제한 사항을 고려합니다.

모든 Azure DataBox에서 데이터를 최대 10개의 스토리지 계정으로 이동할 수 있습니다.
각 DataBox 옵션에는 자체의 사용 가능한 용량이 제공됩니다. DataBox 옵션을 참조하세요.

만들도록 결정한 스토리지 계정 수와 각 계정의 공유에 대한 마이그레이션 계획을 참조하세요. 그런 다음, NAS에서 각 공유의 크기를 확인합니다. 이 정보를 결합하면 어떤 어플라이언스에서 어떤 스토리지 계정으로 데이터를 보내야 하는지 결정하고 최적화할 수 있습니다. 두 개의 DataBox 디바이스에서 파일을 동일한 스토리지 계정으로 이동하도록 할 수 있지만, 단일 파일 공유의 콘텐츠를 두 개의 DataBox에 분할하지 마세요.

DataBox 옵션

표준 마이그레이션의 경우 다음 두 가지 DataBox 옵션 중 하나 또는 조합을 선택해야 합니다.

DataBox는 가장 일반적인 옵션입니다. NAS와 비슷하게 작동하는 러기드 DataBox 어플라이언스가 배송됩니다. 사용 가능한 용량은 80TiB입니다. 자세한 내용은 DataBox 설명서를 참조하세요.
DataBox Heavy 옵션은 1PiB의 용량으로 NAS와 비슷하게 작동하는 휠 방식의 러기드 DataBox 어플라이언스를 특징으로 합니다. 사용 가능한 용량은 암호화 및 파일 시스템 오버헤드로 인해 약 20% 적습니다. 자세한 내용은 DataBox Heavy 설명서를 참조하세요.

Warning

Data Box Disks는 Azure 파일 공유로 마이그레이션하는 데 권장되지 않습니다. Data Box Disks는 ACL(액세스 권한) 및 기타 특성과 같은 파일 메타데이터를 보존하지 않습니다.

4단계: 임시 Windows Server 프로비전

Azure DataBox가 도착할 때까지 기다리는 동안 RoboCopy 작업을 실행하는 데 필요한 하나 이상의 Windows Server를 이미 배포할 수 있습니다.

이러한 서버의 첫 번째 사용은 파일을 DataBox에 복사하는 것입니다.
이러한 서버의 두 번째 사용은 DataBox를 전송하는 동안 NAS 어플라이언스에서 발생한 변경 내용을 가져오는 것입니다. 이 방법은 원본 쪽의 가동 중지 시간을 최소로 유지합니다.

RoboCopy 작업이 작동하는 속도는 주로 다음과 같은 요인에 따라 달라집니다.

원본 및 대상 스토리지의 IOPS
사용 가능한 네트워크 대역폭
문제 해결 섹션에서 자세히 알아보기: IOPS 및 대역폭 고려 사항
네임스페이스에서 파일 및 폴더를 빠르게 처리하는 기능
문제 해결 섹션에서 자세히 알아보기: 처리 속도
RoboCopy 실행 간의 변경 횟수
문제 해결 섹션에서 자세히 알아보기: 불필요한 작업 방지

임시 Windows Server에 제공할 RAM 및 스레드 수를 결정하는 경우 참조된 세부 정보를 고려해야 합니다.

5단계: Azure 파일 공유 사용 준비

이 단계는 시간을 절약하기 위해 DataBox가 도착할 때까지 기다리는 동안 진행해야 합니다. 이 단계의 정보를 사용하면 Azure 및 Azure 외부의 서버 및 사용자가 Azure 파일 공유를 활용하도록 설정하는 방법을 결정할 수 있습니다. 가장 중요한 결정은 다음과 같습니다.

네트워킹: 네트워크에서 SMB 트래픽을 라우팅할 수 있도록 합니다.
인증: Kerberos 인증을 사용하도록 Azure 스토리지 계정을 구성합니다. 앱 및 사용자는 스토리지 계정에 조인하는 AdConnect 및 Domain을 통해 AD ID를 인증에 사용할 수 있습니다.
권한 부여: 각 Azure 파일 공유에 대한 공유 수준 ACL을 통해 AD 사용자 및 그룹이 지정된 공유에 액세스할 수 있으며 Azure 파일 공유 내에서 네이티브 NTFS ACL에 인계됩니다. 그러면 파일 및 폴더 ACL을 기반으로 하는 권한 부여가 온-프레미스 SMB 공유에 대해 수행되는 것과 같은 방식으로 작동합니다.
비즈니스 연속성: Azure 파일 공유를 기존 환경에 통합하려면 기존 공유 주소를 유지해야 하는 경우가 많습니다. DFS 네임스페이스를 아직 사용하지 않는 경우 환경에서 이를 설정하는 것이 좋습니다. 사용자 및 스크립트에서 사용하는 공유 주소를 변경하지 않고 유지할 수 있습니다. 마이그레이션 후 DFS 네임스페이스 대상을 Azure 파일 공유로 리디렉션하여 DFS-N을 SMB에 대한 네임스페이스 라우팅 서비스로 사용합니다.

이 비디오는 간단한 다섯 가지 단계를 통해 Azure 파일 공유를 정보 근로자 및 앱에 직접 안전하게 노출하는 방법에 대한 가이드 및 데모입니다.
다음 항목에 대한 동영상 참조 전용 설명서입니다. Azure Active Directory는 이제 Microsoft Entra ID입니다. 자세한 내용은 Azure AD의 새 이름을 참조하세요.

6단계: DataBox에 파일 복사

DataBox가 도착하면 DataBox를 설정해야 합니다. 이때 NAS 어플라이언스에 대한 네트워크 연결이 원활해야 합니다. 주문한 DataBox 유형에 대한 설정 설명서를 따릅니다.

DataBox 유형에 따라 사용 가능한 DataBox 복사 도구가 있을 수 있습니다. 이 시점에서 파일이 DataBox에 완전히 충실하게 복사되지 않으므로 Azure 파일 공유로 마이그레이션하는 것은 권장되지 않습니다. 대신 RoboCopy를 사용하세요.

DataBox가 도착하면 주문할 때 지정한 각 스토리지 계정에 사용할 수 있는 미리 프로비전된 SMB 공유가 있습니다.

파일이 프리미엄 Azure 파일 공유로 이동하는 경우 프리미엄 "파일 스토리지" 스토리지 계정당 하나의 SMB 공유가 있습니다.
파일이 표준 스토리지 계정으로 이동하는 경우 표준(GPv1 및 GPv2) 스토리지 계정당 세 개의 SMB 공유가 있습니다. _AzFiles로 끝나는 파일 공유만 마이그레이션과 관련이 있습니다. 모든 블록 및 페이지 Blob 공유는 무시합니다.

Azure DataBox 설명서의 단계를 수행합니다.

연결된 DataBox 설명서에는 RoboCopy 명령이 지정되어 있습니다. 그러나 이 명령은 전체 파일 및 폴더 충실도를 유지하는 데 적합하지 않습니다. 대신 다음 명령을 사용하세요.

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>

개별 RoboCopy 플래그에 대한 자세한 내용은 다음 RoboCopy 섹션의 표를 확인하세요.
/MT:n 스레드 수의 크기를 적절하게 조정하고, RoboCopy 속도를 최적화하고, RoboCopy를 데이터 센터의 적절한 환경으로 만드는 방법에 대한 자세한 내용은 RoboCopy 문제 해결 섹션을 살펴보세요.

팁

Robocopy의 대안으로 Data Box는 데이터 복사 서비스를 만들었습니다. 이 서비스를 사용하여 파일을 완전히 충실하게 Data Box에 로드할 수 있습니다. 이 데이터 복사 서비스 자습서를 따르고 올바른 Azure 파일 공유 대상을 설정했는지 확인합니다.

7단계: NAS에서 RoboCopy 가져오기

이 단계는 DataBox에서 모든 파일과 폴더가 계획된 Azure 파일 공유에 배치되었다고 보고하면 계속 진행할 수 있습니다. DataBox 복사가 시작된 이후 NAS의 데이터가 변경되었을 수 있는 경우에만 RoboCopy 가져오기가 필요합니다. 보관을 위해 공유를 사용하는 특정 시나리오에서는 마이그레이션이 완료될 때까지 NAS에서 공유 변경을 중지할 수 있습니다. 또한 마이그레이션 중에 NAS 공유를 읽기 전용으로 설정하여 비즈니스 요구 사항을 충족할 수 있습니다.

마이그레이션 중에 공유를 읽기/쓰기로 설정해야 하고 짧은 가동 중지 기간만 허용할 수 있는 경우 Azure 파일 공유에 대한 사용자 액세스를 직접 장애 조치(failover)하기 전에 이 RoboCopy 가져오기 단계를 완료해야 합니다.

이 단계에서는 RoboCopy 작업을 실행하여 공유를 DataBox에 포크한 이후 클라우드 공유를 NAS의 최신 변경 내용으로 가져옵니다. 이러한 보완 RoboCopy는 NAS 공유에서 발생한 변동의 양에 따라 빠르게 완료되거나 다소 시간이 걸릴 수 있습니다.

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

NAS 어플라이언스에서 첫 번째 위치를 식별합니다.
일치하는 Azure 파일 공유를 식별합니다.
Azure 파일 공유를 로컬 네트워크 드라이브로 임시 Windows Server에 탑재합니다.
설명한 대로 RoboCopy를 사용하여 복사를 시작합니다.

RoboCopy를 사용하려면 먼저 SMB를 통해 Azure 파일 공유에 액세스할 수 있도록 해야 합니다. 가장 쉬운 방법은 공유를 로컬 네트워크 드라이브로 RoboCopy에 사용하려는 Windows Server에 탑재하는 것입니다.

Important

Azure 파일 공유를 로컬 Windows Server에 탑재하려면 먼저 단계: Azure 파일 공유 사용 준비를 완료해야 합니다!

준비가 되면 Windows에서 Azure 파일 공유 사용 방법 문서를 검토하고, NAS RoboCopy 가져오기를 시작하려는 Azure 파일 공유를 탑재합니다.

RoboCopy

다음 RoboCopy 명령은 차이(업데이트된 파일 및 폴더)만 NAS 스토리지에서 Azure 파일 공유로 복사합니다.

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`과 같은 샘플 스크립트의 플래그를 제거해야 할 수 있습니다.
`/Z`	주의해서 사용 다시 시작 모드에서 파일을 복사합니다. 이 스위치는 불안정한 네트워크 환경에서만 권장됩니다. 추가 로깅으로 인해 복사 성능이 크게 저하됩니다.
`/ZB`	주의해서 사용 다시 시작 모드를 사용합니다. 액세스가 거부되는 경우 이 옵션은 백업 모드를 사용합니다. 이 옵션을 선택하면 검사점 설정으로 인해 복사 성능이 크게 저하됩니다.

Important

Windows Server 2022를 사용하는 것이 좋습니다. Windows Server 2019를 사용하는 경우 최신 패치 수준 또는 최소 OS 업데이트 KB5005103이 설치되어 있는지 확인합니다. 특정 Robocopy 시나리오에 대한 중요한 수정 사항이 포함되어 있습니다.

팁

RoboCopy에서 프로덕션 환경에 영향을 주거나 많은 오류를 보고하거나 예상한 만큼 빠르게 진행되지 않는 경우 문제 해결 섹션을 확인하세요.

사용자 전환

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

첫 번째 실행은 대량의 변동 데이터를 Azure 파일 공유로 이동하는 것입니다. 이 첫 번째 복사에는 시간이 걸릴 수 있습니다. RoboCopy 속도에 영향을 줄 수 있는 항목에 대한 자세한 내용은 문제 해결 섹션을 확인하세요.

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

동일한 공유에 대해 RoboCopy를 두 번째로 실행하면 더 빨리 완료됩니다. 이는 마지막 실행 이후에 발생한 변경 내용만 전송하면 되기 때문입니다. 동일한 공유에 대해 반복되는 작업을 실행할 수 있습니다.

가동 중지 시간이 허용하는 범위 내에 있는 경우 NAS 기반 공유에 대한 사용자 액세스 권한을 제거해야 합니다. 이를 위해 사용자가 파일 및 폴더 구조와 콘텐츠를 변경하지 못하도록 하는 단계를 수행할 수 있습니다. 예를 들어 DFS 네임스페이스가 없는 위치를 가리키거나 공유에서 루트 ACL을 변경하는 것입니다.

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

공유를 Windows Server 폴더에 만들고, 이를 가리키도록 DFS-N 배포를 조정할 수 있습니다. NAS SMB 공유에서와 동일한 공유 수준의 권한을 설정해야 합니다. 엔터프라이즈급 도메인 조인 NAS가 있는 경우 사용자가 Active Directory에 있고 RoboCopy에서 파일과 메타데이터를 있는 그대로 복사하므로 사용자 SID가 자동으로 일치합니다. NAS에서 로컬 사용자를 사용한 경우 해당 사용자를 Windows Server 로컬 사용자로 다시 만들고, RoboCopy에서 Windows Server로 이동한 기존 SID를 새 Windows Server 로컬 사용자의 SID에 매핑해야 합니다.

공유/공유 그룹을 공통 루트 또는 볼륨으로 마이그레이션하는 작업이 완료되었습니다.

이러한 복사본 중 일부를 병렬로 실행할 수 있습니다. 한 번에 하나의 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 작업이 다시 시도합니다. 사용 중이거나 시간 제한 문제로 인해 실패한 파일은 결국 이러한 방식으로 성공적으로 복사될 수 있습니다.

다음 단계

Azure 파일 공유에 대해 더 자세히 검색할 수 있습니다. 다음 문서는 고급 옵션, 모범 사례를 이해하는 데 도움이 되며, 문제 해결 도움말도 포함되어 있습니다. 해당 문서는 필요에 따라 Azure 파일 공유 설명서로 연결됩니다.

다음을 통해 공유