Azure 파일 동기화를 사용하여 Linux에서 하이브리드 클라우드 배포로 마이그레이션

이 마이그레이션 문서는 NFS 및 Azure 파일 동기화 키워드와 관련된 여러 문서 중 하나입니다. 이 문서가 시나리오에 적용되는지 확인합니다.

• 데이터 원본: NAS(네트워크 연결 스토리지)
• 마이그레이션 경로: SAMBA가 있는 Linux Server ⇒ Windows Server 2012R2 이상 ⇒ Azure 파일 공유와 동기화
• 온-프레미스에서 파일 캐싱: 그렇습니다. 최종 목표는 Azure 파일 동기화 배포입니다.

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

Azure 파일 동기화는 DAS(직접 연결된 스토리지)를 사용하는 Windows Server 인스턴스에서 작동합니다. Linux 클라이언트, 원격 SMB(원격 서버 메시지 블록) 공유 또는 NFS(네트워크 파일 시스템) 공유와의 동기화는 지원되지 않습니다.

따라서 파일 서비스를 하이브리드 배포로 변환하면 Windows Server로의 마이그레이션이 필요합니다. 이 문서에서는 이러한 마이그레이션의 계획 및 실행 과정을 안내합니다.

적용 대상

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

마이그레이션 목표

목표는 Linux Samba 서버에 있는 공유를 Windows Server 인스턴스로 이동하는 것입니다. 그런 다음, 하이브리드 클라우드 배포에 Azure 파일 동기화를 활용합니다. 이 마이그레이션은 마이그레이션하는 동안 프로덕션 데이터의 무결성과 가용성을 보장하는 방식으로 수행해야 합니다. 후자는 가동 중지 시간을 최소로 유지하여 정기적인 유지 보수 기간에 맞추거나 약간 초과할 수 있습니다.

마이그레이션 개요

Azure Files 마이그레이션 개요 문서에 설명된 것처럼 올바른 복사 도구와 방법을 사용하는 것이 중요합니다. Linux Samba 서버는 로컬 네트워크에 직접 SMB 공유를 표시합니다. 이 마이그레이션 시나리오에서 파일을 이동하는 가장 좋은 방법은 Windows Server에 기본적으로 제공되는 Robocopy입니다.

Linux 서버에서 Samba를 실행하지 않고 Windows Server에서 하이브리드 배포로 폴더를 마이그레이션하려는 경우에는 Robocopy 대신 Linux 복사 도구를 사용할 수 있습니다. 복사 도구의 정확성에 대해 알고 있어야 합니다. 마이그레이션 개요 문서의 마이그레이션 기본 사항 섹션을 검토하여 복사 도구에서 찾으려는 내용을 알아보세요.

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

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

2단계: 온-프레미스에서 적절한 Windows Server 프로비전

• Windows Server 2019 인스턴스를 가상 머신 또는 물리적 서버로 만듭니다. 최소 요구 사항은 Windows Server 2012 R2입니다. Windows Server 장애 조치(failover) 클러스터도 지원됩니다.

• DAS(직접 연결된 스토리지)를 프로비전하거나 추가합니다. NAS(Network Attached Storage)는 지원되지 않습니다.

  Azure 파일 동기화 클라우드 계층화 기능을 사용하는 경우 프로비전하는 스토리지 크기는 Linux Samba 서버에서 현재 사용 중인 것보다 작을 수 있습니다.

프로비전하는 스토리지 크기는 Linux Samba 서버에서 현재 사용 중인 것보다 작을 수 있습니다. 이 구성을 선택하려면 Azure 파일 동기화 클라우드 계층화 기능을 사용해야 합니다. 그러나 이후 단계에서 더 큰 Linux Samba 서버 공간에서 더 작은 Windows Server 볼륨으로 파일을 복사하는 경우에는 일괄 처리로 작업해야 합니다.

1. 디스크에 맞는 파일 세트를 이동합니다.
2. 파일 동기화 및 클라우드 계층화 참여를 허용합니다.
3. 볼륨에 사용 가능한 공간이 더 많이 만들어진 경우 다음 파일 일괄 처리를 진행합니다. 또는 새 /LFSM 스위치 사용에 대한 향후 RoboCopy 섹션에서 RoboCopy 명령을 검토합니다. /LFSM을 사용하면 RoboCopy 작업을 크게 간소화할 수 있지만 사용하는 다른 RoboCopy 스위치와 호환되지 않을 수 있습니다.

Linux Samba 서버에서 파일이 사용하는 Windows Server 인스턴스에 동일한 공간을 프로비전하여 이러한 일괄 처리 방식을 방지할 수 있습니다. Windows에서 중복 제거를 사용하도록 설정하는 것이 좋습니다. 많은 스토리지를 Windows Server 인스턴스에 영구적으로 커밋하지 않으려는 경우 마이그레이션 후와 클라우드 계층화 정책을 조정하기 전에 볼륨 크기를 줄일 수 있습니다. 그러면 Azure 파일 공유의 더 작은 온-프레미스 캐시가 생성됩니다.

배포하는 Windows Server 인스턴스의 리소스 구성(컴퓨팅 및 RAM)은 대부분 동기화할 항목(파일 및 폴더)의 수에 따라 달라집니다. 문제가 있는 경우 더 높은 성능 구성을 사용하는 것이 좋습니다.

동기화해야 하는 항목(파일 및 폴더)의 수를 기준으로 Windows Server 인스턴스 크기를 조정하는 방법에 대해 알아봅니다.

참고 항목

이전 연결 문서에서는 서버 메모리(RAM) 범위를 포함하는 테이블을 제공합니다. 서버에 대해 더 작은 수를 지정할 수 있지만 초기 동기화에 더 많은 시간이 걸릴 수 있습니다.

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

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

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

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

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

4단계: Azure Storage 리소스 배포

이 단계에서는 1단계의 매핑 테이블을 참조하여 정확한 수의 Azure Storage 계정과 해당 계정 내의 파일 공유를 프로비전합니다.

Azure 파일 공유는 Azure 스토리지 계정의 클라우드에 저장됩니다. 다른 수준의 성능 고려 사항이 여기에 적용됩니다.

활성 공유(많은 사용자 및/또는 애플리케이션에서 사용하는 공유)가 많은 경우 두 개의 Azure 파일 공유가 스토리지 계정의 성능 제한에 도달할 수 있습니다.

가장 좋은 방법은 각각 파일 공유가 하나씩 있는 스토리지 계정을 배포하는 것입니다. 보관 공유가 있거나 일상 활동이 적을 것으로 예상되는 경우 여러 Azure 파일 공유를 동일한 스토리지 계정으로 풀할 수 있습니다.

이러한 고려 사항은 Azure 파일 동기화보다 직접 클라우드 액세스(Azure VM을 통해)에 더 많이 적용됩니다. 이러한 공유에서 Azure 파일 동기화만 사용하려는 경우 여러 항목을 단일 Azure Storage 계정으로 그룹화하는 것이 좋습니다.

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

이전 단계에서는 적절한 공유 수를 결정했습니다. 이 단계에서는 스토리지 계정을 파일 공유에 매핑합니다. 이제 적절한 수의 Azure 파일 공유가 포함된 적절한 수의 Azure 스토리지 계정을 배포합니다.

각 스토리지 계정의 지역이 동일하고 이미 배포한 Storage Sync Service 리소스의 지역과 일치해야 합니다.

주의

100TiB 한도가 있는 Azure 파일 공유를 만드는 경우 해당 공유는 로컬 중복 스토리지 또는 영역 중복 스토리지 중복 옵션만 사용할 수 있습니다. 100TiB 파일 공유를 사용하려면 먼저 스토리지 중복도 요구 사항을 고려하세요.

Azure 파일 공유는 기본적으로 여전히 5TiB 한도로 생성됩니다. Azure 파일 공유 만들기의 단계에 따라 대량 파일 공유를 만듭니다.

스토리지 계정을 배포할 때 또 다른 고려 사항은 Azure Storage의 중복도입니다. Azure Storage 중복도 옵션을 참조하세요.

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

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

6단계: Windows Server 배포에서 Azure 파일 동기화 구성

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

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

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

Important

클라우드 계층화는 로컬 서버가 클라우드에 저장되는 것보다 적은 스토리지 용량을 가지면서도 전체 네임스페이스를 사용할 수 있도록 하는 Azure 파일 동기화 기능입니다. 로컬에서 필요한 데이터가 로컬에 캐시되어 빠른 액세스 성능도 제공합니다. 클라우드 계층화는 Azure 파일 동기화 서버 엔드포인트에 대한 선택적 기능입니다.

Warning

Linux Samba 서버에서 사용되는 데이터보다 작은 스토리지를 Windows Server 볼륨에 프로비전한 경우 클라우드 계층화는 필수입니다. 클라우드 계층화를 설정하지 않으면 서버가 모든 파일을 저장할 공간을 확보하지 않습니다. 일시적으로 마이그레이션에 대한 계층화 정책을 볼륨에서 99%의 사용 가능한 공간 비율로 설정합니다. 마이그레이션을 완료한 후 클라우드 계층화 설정으로 돌아가서 정책을 장기적으로 보다 유용한 수준으로 설정합니다.

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

모든 서버 엔드포인트를 만든 후, 동기화가 작동합니다. 테스트 파일을 만들고 서버 위치에서 연결된 Azure 파일 공유로 동기화하는 것을 확인할 수 있습니다(동기화 그룹의 클라우드 엔드포인트에서 설명).

그렇지 않으면 서버 폴더 및 Azure 파일 공유의 두 위치가 모두 비어 있고 데이터를 기다립니다. 다음 단계에서는 Azure 파일 동기화용 Windows Server 인스턴스로 파일을 복사하여 클라우드로 이동하는 작업을 시작합니다. 클라우드 계층화를 사용하도록 설정한 경우 로컬 볼륨의 용량이 부족하면 서버가 파일을 계층화하기 시작합니다.

7단계: Robocopy

기본적인 마이그레이션 방식은 Robocopy를 사용하여 파일을 복사하고 Azure 파일 동기화를 사용하여 동기화를 수행하는 것입니다.

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

1. Linux Samba 서버의 첫 번째 위치를 식별합니다.
2. Azure 파일 동기화가 이미 구성되어 있는 Windows Server 인스턴스에서 일치하는 폴더를 식별합니다.
3. Robocopy를 사용하여 복사를 시작합니다.

다음 Robocopy 명령은 Linux Samba 서버의 스토리지에서 Windows Server 대상 폴더로 파일을 복사합니다. Windows Server가 이를 Azure 파일 공유로 동기화합니다.

Linux Samba 서버에서 파일이 차지하는 것보다 적은 스토리지를 Windows Server 인스턴스에 프로비전한 경우에는 클라우드 계층화가 구성된 것입니다. 로컬 Windows Server 볼륨이 가득 차면 클라우드 계층화가 시작되고 이미 동기화된 파일이 계층화됩니다. 클라우드 계층화는 Linux Samba 서버에서 복사를 계속하기에 충분한 공간을 생성합니다. 클라우드 계층화는 한 시간에 한 번씩 무엇이 동기화되었는지 확인하고 볼륨에서 99%의 사용 가능한 공간 비율에 도달할 수 있도록 디스크 공간을 확보합니다.

Robocopy는 클라우드에 동기화하고 로컬로 계층화하는 것보다 더 빠르게 파일을 이동시켜 로컬 디스크 공간이 부족하게 될 수 있습니다. 그러면 Robocopy가 실패합니다. 이 문제를 방지하는 시퀀스로 공유를 처리하는 것이 좋습니다. 예를 들어 모든 공유에 대해 동시에 Robocopy 작업을 시작하지 않는 것이 좋습니다. 또는 Windows Server 인스턴스에서 현재 사용 가능한 공간 크기에 맞는 공유를 이동하는 것이 좋습니다. Robocopy 작업이 실패하는 경우 다음 미러/제거 옵션을 사용하면 명령을 언제든지 다시 실행할 수 있습니다.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

스위치	의미
/MT:n	Robocopy가 다중 스레드를 실행할 수 있도록 합니다. n의 기본값은 8입니다. 최대 스레드 수는 128개입니다. 스레드 수가 많으면 사용 가능한 대역폭을 포화시키는 데 도움이 되지만 더 많은 스레드로 마이그레이션이 항상 더 빨라지는 것은 아닙니다. Azure Files를 사용한 테스트는 초기 복사 실행에 대해 8에서 20 사이의 균형 잡힌 성능을 보여 줍니다. 후속 /MIR 실행은 사용 가능한 컴퓨팅 및 사용 가능한 네트워크 대역폭의 영향을 점진적으로 받게 됩니다. 후속 실행의 경우 스레드 수 값을 프로세서 코어 수 및 코어당 스레드 수와 좀 더 가깝게 일치시킵니다. 프로덕션 서버에서 수행할 수 있는 다른 작업을 위해 코어를 예약해야 하는지 여부를 고려하세요. Azure Files를 사용한 테스트에 따르면 최대 64개의 스레드가 우수한 성능을 생성하지만 프로세서가 동시에 연결 유지할 수 있는 경우에만 가능합니다.
/R:n	첫 번째 시도에서 복사에 실패한 파일의 최대 다시 시도 횟수입니다. Robocopy는 실행에서 파일이 영구적으로 복사에 실패하기 전에 n번 시도합니다. 실행 성능을 최적화할 수 있습니다. 과거에 시간 초과 문제로 인해 오류가 발생했다고 생각되면 2 또는 3의 값을 선택합니다. 이는 WAN 링크를 통해 더 일반적일 수 있습니다. 파일이 활발하게 사용 중이어서 복사에 실패했다고 생각되면 다시 시도 안 함 또는 값 1을 선택합니다. 몇 초 후에 다시 시도하면 파일의 사용 상태가 변경되는 데 시간이 충분하지 않을 수 있습니다. 파일을 열어 둔 사용자 또는 앱은 몇 시간 더 시간이 필요할 수 있습니다. 이 경우 파일이 복사되지 않았음을 수락하고 계획된 후속 Robocopy 실행 중 하나에서 파일을 포착하면 결국 파일을 성공적으로 복사하는 데 성공할 수 있습니다. 이렇게 하면 다시 시도 시간 초과 후에도 여전히 열려 있는 파일로 인해 궁극적으로 대부분의 복사 실패로 끝나는 많은 다시 시도에 의해 연장되지 않고 현재 실행이 더 빨리 완료될 수 있습니다.
/W:n	Robocopy가 이전 시도 중에 성공적으로 복사하지 못한 파일 복사를 시도하기 전에 대기하는 시간을 지정합니다. n은 다시 시도 사이에 대기하는 시간(초)입니다. /W:n는 /R:n과 함께 사용되는 경우가 많습니다.
/B	백업 애플리케이션이 사용하는 것과 동일한 모드에서 Robocopy를 실행합니다. 이 스위치를 사용하면 Robocopy가 현재 사용자에게 권한이 없는 파일을 이동할 수 있습니다. 백업 스위치는 관리자 권한 콘솔 또는 PowerShell 창에서 Robocopy 명령 실행에 따라 다릅니다. Azure Files용 Robocopy를 사용하는 경우 스토리지 계정 액세스 키와 도메인 ID를 사용하여 Azure 파일 공유를 탑재해야 합니다. 그렇지 않은 경우 오류 메시지가 직관적으로 문제 해결을 유도하지 못할 수 있습니다.
/MIR	(원본을 대상으로 미러링합니다.) Robocopy가 원본과 대상 간의 델타만 복사할 수 있도록 합니다. 빈 하위 디렉터리가 복사됩니다. 대상에서 변경되었거나 존재하지 않는 항목(파일 또는 폴더)이 복사됩니다. 대상에 존재하지만 원본에 존재하지 않는 항목은 대상에서 제거(삭제)됩니다. 이 스위치를 사용하는 경우 원본 및 대상 폴더 구조를 정확하게 일치합니다. 일치는 올바른 원본 및 폴더 수준에서 대상의 일치하는 폴더 수준으로 복사하는 것을 의미합니다. 그래야만 "후속" 복사가 성공할 수 있습니다. 원본과 대상이 일치하지 않는 경우 /MIR을 사용하면 대규모 삭제 및 다시 복사가 수행됩니다.
/IT	특정 미러링 시나리오에서 충실도가 유지되도록 합니다. 예를 들어 파일에서 두 Robocopy 실행 사이에 ACL 변경 및 특성 업데이트가 발생하면 해당 파일은 숨김으로 표시됩니다. /IT가 없으면 Robocopy에서 ACL 변경 사항을 놓치고 대상 위치로 전송되지 않을 수 있습니다.
/COPY:[copyflags]	파일 복사본의 충실도입니다. 기본값: /COPY:DAT. 복사 플래그: D= 데이터, A= 특성, T= 타임스탬프, S= 보안 = NTFS ACL, O= 소유자 정보, U= 감사 정보. 감사 정보는 Azure 파일 공유에 저장할 수 없습니다.
/DCOPY:[copyflags]	디렉터리 복사본의 충실도입니다. 기본값: /DCOPY:DA. 복사 플래그: D= 데이터, A= 특성, T= 타임스탬프.
/NP	각 파일 및 폴더에 대한 복사 진행률이 표시되지 않도록 지정합니다. 진행률을 표시하면 복사 성능이 대폭 저하됩니다.
/NFL	파일 이름을 기록하지 않도록 지정합니다. 복사 성능을 향상시킵니다.
/NDL	디렉터리 이름을 기록하지 않도록 지정합니다. 복사 성능을 향상시킵니다.
/XD	제외할 디렉터리를 지정합니다. 볼륨의 루트에서 Robocopy를 실행할 때 숨겨진 System Volume Information 폴더를 제외하는 것을 고려합니다. 설계된 대로 사용되는 경우, 거기에 있는 모든 정보는 이 정확한 시스템의 정확한 볼륨에 따라 다르며 필요에 따라 재구성할 수 있습니다. 이 정보를 복사하는 것은 클라우드에서 또는 데이터가 다른 Windows 볼륨으로 다시 복사될 때 도움이 되지 않습니다. 이 콘텐츠를 남겨두는 것은 데이터 손실로 간주되어서는 안 됩니다.
/UNILOG:<file name>	상태를 유니코드로 로그 파일에 씁니다. (기존 로그를 덮어씁니다.)
/L	테스트 실행에만 해당 파일만 나열됩니다. 복사되지 않고, 삭제되지 않으며, 타임스탬프가 표시되지 않습니다. 콘솔 출력을 위해 /TEE와 함께 사용되는 경우가 많습니다. 테스트 결과를 적절히 문서화하려면 /NP, /NFL 및 /NDL과 같은 샘플 스크립트의 플래그를 제거해야 할 수 있습니다.
/LFSM	계층화된 스토리지를 사용하는 대상에만 해당 대상이 원격 SMB 공유인 경우 지원되지 않습니다. Robocopy가 “여유 공간 부족 모드”에서 작동하도록 지정합니다. 이 스위치는 Robocopy가 완료되기 전에 로컬 용량이 부족할 수 있는 계층화 스토리지가 있는 대상에만 유용합니다. Azure 파일 동기화 클라우드 계층화에 대해 사용하도록 설정된 대상과 함께 사용하기 위해 특별히 추가되었습니다. Azure 파일 동기화와 독립적으로 사용할 수 있습니다. 이 모드에서 RoboCopy는 파일 복사로 인해 대상 볼륨의 사용 가능한 공간이 "floor"값 아래로 내려갈 때마다 일시 중지됩니다. 이 값은 /LFSM:n 형식의 플래그로 지정할 수 있습니다. 매개 변수 n은 기본 2에서 nKB, nMB 또는 nGB로 지정됩니다. /LFSM이 명시적 floor 값 없이 지정된 경우 floor는 대상 볼륨 크기의 10%로 설정됩니다. 사용 가능한 공간 부족 모드는 /MT, /EFSRAW 또는 /ZB와 호환되지 않습니다. /B에 대한 지원이 Windows Server 2022에 추가되었습니다. 관련 버그 및 해결 방법에 대한 자세한 내용은 아래의 Windows Server 2022 및 RoboCopy LFSM 섹션을 참조하세요.
/Z	주의해서 사용 다시 시작 모드에서 파일을 복사합니다. 이 스위치는 불안정한 네트워크 환경에서만 권장됩니다. 추가 로깅으로 인해 복사 성능이 크게 저하됩니다.
/ZB	주의해서 사용 다시 시작 모드를 사용합니다. 액세스가 거부되는 경우 이 옵션은 백업 모드를 사용합니다. 이 옵션을 선택하면 검사점 설정으로 인해 복사 성능이 크게 저하됩니다.

Important

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

8단계: 사용자 중단

Robocopy 명령을 처음 실행하는 경우 사용자와 애플리케이션은 계속해서 Linux Samba 서버의 파일에 액세스하고 해당 파일을 변경할 수 있습니다. Robocopy가 디렉터리를 처리하고 다음으로 이동한 후 원본 위치(Linux)의 사용자가 파일을 추가, 변경 또는 삭제할 수 있으며, 이것은 현재 Robocopy 실행에서는 처리되지 않습니다. 이 동작이 예상됩니다.

첫 번째 실행은 Azure 파일 동기화를 통해 Windows Server 인스턴스 및 클라우드로 대량 데이터를 이동하는 것입니다. 이 첫 번째 복사본은 다음에 따라 시간이 오래 걸릴 수 있습니다.

• 다운로드 대역폭
• 업로드 대역폭
• 로컬 네트워크 속도 및 Robocopy 스레드 수가 이와 최적으로 일치하는 수
• Robocopy 및 Azure 파일 동기화가 처리해야 하는 항목(파일 및 폴더)의 수

초기 실행이 완료된 후 명령을 다시 실행합니다.

마지막으로 실행한 후에 발생한 변경 내용만 전송하면 되기 때문에 두 번째 실행은 더 빨리 완료됩니다. 두 번째 실행 중에도 새 변경 내용이 누적될 수 있습니다.

특정 위치에 대한 Robocopy 작업을 완료하는 데 걸리는 시간이 가동 중지 시간의 허용 범위 내에 들어올 때까지 이 프로세스를 반복합니다.

허용 가능한 가동 중지 시간을 고려하고 Linux 위치를 오프라인 상태로 전환할 준비가 되면 사용자가 더 이상 해당 위치에 액세스할 수 없도록 공유 루트의 ACL을 변경할 수 있습니다. 또는 Linux 서버에서 이 폴더의 내용이 변경되지 않도록 하는 다른 적절한 단계를 수행할 수 있습니다.

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

공유를 Windows Server 폴더에 만들고, 이를 가리키도록 DFS-N 배포를 조정할 수 있습니다. Linux Samba 서버의 SMB 공유와 동일한 공유 수준의 사용 권한을 설정해야 합니다. Linux Samba 서버에서 로컬 사용자를 사용한 경우 이러한 사용자를 Windows Server 로컬 사용자로 다시 만들어야 합니다. 또한 Robocopy가 Windows Server 인스턴스로 이동된 기존 SID를 새 Windows Server 로컬 사용자의 SID에 매핑해야 합니다. Active Directory 계정과 ACL을 사용한 경우 Robocopy가 이를 그대로 이동하므로 추가 작업은 필요하지 않습니다.

공유 또는 공유 그룹을 공통 루트 또는 볼륨으로 마이그레이션하는 작업이 완료되었습니다(1단계의 매핑에 따름).

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

Warning

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

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

문제 해결

가장 일반적인 문제는 Robocopy 명령이 Windows Server 쪽의 볼륨이 가득 차서 실패하는 것입니다. 클라우드 계층화는 1시간 한 번씩 작동하여 동기화된 로컬 Windows Server 디스크에서 콘텐츠를 비웁니다. 목표는 볼륨에서 사용 가능한 공간이 99%에 도달하는 것입니다.

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

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

Azure 파일 동기화 문제를 해결하려면 다음 섹션의 링크를 확인하세요.

다음 단계

Azure 파일 공유 및 Azure 파일 동기화에 대해 더 자세히 알아볼 수 있습니다. 다음 문서에는 고급 옵션, 모범 사례 및 문제 해결 도움말이 포함되어 있습니다. 해당 문서는 필요에 따라 Azure 파일 공유 설명서로 연결됩니다.

• Azure 파일 동기화 개요
• Azure 파일 동기화 배포
• Azure 파일 동기화 문제 해결