RoboCopy를 사용하여 Azure 파일 공유로 마이그레이션

이 마이그레이션 문서에서는 RoboCopy를 사용하여 SMB Azure 파일 공유로 파일을 이동하거나 마이그레이션하는 방법을 설명합니다. RoboCopy는 마이그레이션에 적합한 기능 집합이 있는 신뢰할 수 있고 잘 알려진 파일 복사 유틸리티입니다. SMB 프로토콜을 사용하므로 SMB를 지원하는 모든 원본 및 대상 조합에 광범위하게 적용할 수 있습니다.

• 데이터 원본: NAS(네트워크 연결 스토리지), Windows 또는 Linux 서버, 다른 Azure 파일 공유 등 SMB 프로토콜을 지원하는 모든 원본
• 마이그레이션 경로: 원본 스토리지 ⇒ RoboCopy가 있는 Windows 컴퓨터 ⇒ Azure 파일 공유
• 온-프레미스에 캐싱 파일 없음: 최종 목표는 클라우드에서 직접 Azure 파일 공유를 사용하는 것이므로 Azure 파일 동기화를 사용할 계획이 없습니다.

원본 및 배포 조합에 대한 다양한 마이그레이션 경로가 있습니다. 요구에 가장 적합한 마이그레이션을 찾으려면 마이그레이션 가이드 표를 참조하세요.

적용 대상

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

AzCopy 및 RoboCopy

AzCopy와 RoboCopy는 근본적으로 다른 두 가지 파일 복사 도구입니다. RoboCopy는 모든 버전의 SMB 프로토콜을 사용합니다. AzCopy는 대상이 Azure Storage에 있는 한 데이터를 이동하는 데 사용할 수 있는 "클라우드에서 시작된" 도구입니다. AzCopy는 REST 프로토콜에 따라 달라집니다.

신뢰할 수 있는 Windows 기반 복사 도구인 RoboCopy는 완전 충실도로 파일을 복사하는 경우 홈그라운드의 이점이 있습니다. RoboCopy는 풍부한 기능 집합과 파일 및 폴더를 완전 충실도로 복사하는 기능 덕분에 많은 마이그레이션 시나리오를 지원합니다. 가능한 최대 충실도로 파일을 복사하는 것의 중요성에 대해 자세히 알아보려면 마이그레이션 개요 문서의 파일 충실도 섹션을 확인하세요.

반면 AzCopy는 최근에야 어느 정도 충실도로 파일 복사를 지원하도록 확장되었으며 마이그레이션 도구로 간주되는 데 필요한 첫 번째 기능이 추가되었습니다. 하지만 여전히 차이가 있으며 AzCopy 플래그를 RoboCopy 플래그와 비교할 때 기능에 대한 오해가 생기기 쉽습니다.

예: RoboCopy /MIR은 원본을 대상에 미러링합니다. 즉, 추가, 변경 및 삭제된 파일이 고려됩니다. AzCopy -sync 사용에서의 중요한 차이는 원본에서 삭제된 파일이 대상에서 제거되지 않는다는 것입니다. 따라서 불완전한 차등 복사 기능 집합이 됩니다. AzCopy는 계속 발전할 예정입니다. 현재 Azure 파일 공유를 대상으로 하는 마이그레이션 시나리오에서는 AzCopy를 권장하지 않습니다.

마이그레이션 목표

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

마이그레이션 개요

마이그레이션 프로세스는 몇 가지 단계로 구성됩니다. 먼저 Azure Storage 계정 및 파일 공유를 배포해야 합니다. 다음, 네트워킹을 구성하고 DFS-N(DFS 네임스페이스 배포)을 고려하거나 기존 배포를 업데이트합니다. 실제 데이터 복사 시간이 되면 가동 중지 시간을 최소화하기 위해 차등 RoboCopy 실행 반복을 고려해야 하며 마지막에는 새로 생성된 Azure 파일 공유로 사용자를 전환해야 합니다. 다음 섹션에서는 마이그레이션 프로세스의 단계에 대해 자세히 설명합니다.

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

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

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

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

참고 항목

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

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

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

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

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

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

이 단계의 정보를 사용하면 Azure 및 Azure 외부의 서버 및 사용자가 Azure 파일 공유를 활용하도록 설정하는 방법을 결정할 수 있습니다. 가장 중요한 결정은 다음과 같습니다.

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

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

• ID 기반 인증 개요
• Azure 파일 공유에 대한 네트워킹 개요
• 퍼블릭 및 프라이빗 엔드포인트를 구성하는 방법
• S2S VPN을 구성하는 방법
• Windows P2S VPN을 구성하는 방법
• Linux P2S VPN을 구성하는 방법
• DNS 전달을 구성하는 방법
• DFS-N 구성

Azure 파일 공유 탑재

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

Important

스토리지 계정 액세스 키를 사용하여 Azure 파일 공유를 탑재했는지 확인합니다. 도메인 ID를 사용하지 마세요. 로컬 Windows Server에 Azure 파일 공유를 성공적으로 탑재하려면 2단계: Azure 파일 공유 사용 준비를 완료해야 합니다.

준비가 완료되면 Windows에서 Azure 파일 공유 사용을 검토하세요. 그런 다음, RoboCopy를 시작하려는 Azure 파일 공유를 탑재합니다.

3단계: RoboCopy

다음 RoboCopy 명령은 원본 스토리지에서 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에서 프로덕션 환경에 영향을 주거나 많은 오류를 보고하거나 예상한 만큼 빠르게 진행되지 않는 경우 문제 해결 섹션을 확인하세요.

4단계: 사용자 중단

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

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

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

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

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

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

2단계에서는 사용자가 자신의 ID로 공유에 액세스하도록 구성했으며 사용자가 새 Azure 파일 공유(DFS-N)에 대해 설정된 경로를 사용하도록 전략을 수립해야 합니다.

다른 원본 및 대상 공유 간에 이러한 복사본 중 몇 개를 병렬로 실행해 볼 수 있습니다. 이렇게 할 때는 시스템에 과부하가 걸리지 않도록 네트워크 처리량과 코어 대 스레드 수 비율을 염두에 두십시오.

문제 해결 및 최적화

지정된 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 스위치로 한 번 이상 추가 실행하여 복사되지 않은 파일을 추적해 다시 시도하는 경우입니다.

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

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

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

스토리지 트랜잭션 요금 예측

Azure Files로 마이그레이션을 시작하면 RoboCopy가 파일 및 폴더를 Azure에 복사합니다. Azure Files에 대한 청구 모델에 따라 트랜잭션 요금이 적용될 수 있습니다. 청구 이해를 참조하세요.

표준 Azure 파일 공유에 종량제 청구 모델을 사용하는 경우 마이그레이션에서 생성되는 트랜잭션 수를 예측하기 어려울 수 있습니다.

• 원본의 사용된 스토리지 용량에 따라 트랜잭션 수를 예측할 수 없습니다. 트랜잭션 수는 네임스페이스 항목(파일 및 폴더)의 수와 해당 크기가 아니라 마이그레이션된 속성으로 확장됩니다. 예를 들어, 1GiB의 큰 파일보다 1GiB의 작은 파일을 마이그레이션하는 데 더 많은 트랜잭션이 필요합니다.
• 가동 중지 시간을 최소화하기 위해 원본에서 대상으로의 복사 작업을 여러 번 실행해야 할 수 있습니다. 모든 원본 및 대상 항목은 각 복사 작업 중에 처리되지만 후속 실행은 더 빠르게 완료됩니다. 초기 작업 후에는 복사 실행 간에 도입된 차이점만 네트워크를 통해 전송됩니다. 전송되는 데이터가 적지만 필요한 트랜잭션 수는 동일하게 유지될 수 있음을 이해하는 것이 중요합니다.
• 동일한 파일을 두 번 복사해도 트랜잭션 수가 동일하지 않을 수 있습니다. 이전 복사 실행에서 마이그레이션된 항목을 처리하면 읽기 트랜잭션이 몇 개만 발생할 수 있습니다. 반면, 복사 실행 간에 메타데이터 또는 콘텐츠를 변경하려면 대상을 업데이트하기 위해 더 많은 수의 트랜잭션이 필요할 수 있습니다. 네임스페이스의 각 파일에는 고유한 요구 사항이 있을 수 있으므로 트랜잭션 수가 다를 수 있습니다.

발생하는 트랜잭션 수를 제대로 이해하기 위해 자체 데이터에서 몇 번의 최초 테스트를 실행하는 것이 좋습니다. 이를 통해 파일 마이그레이션에서 생성될 수 있는 총 트랜잭션 수를 더 잘 파악할 수 있습니다.

다음 단계

다음 문서는 고급 옵션 및 모범 사례를 이해하는 데 도움이 됩니다.

• Azure Files란?
• 마이그레이션 개요
• 백업: Azure 파일 공유 스냅샷
• Azure Files에서 DFS 네임스페이스를 사용하는 방법