Azure 파일 동기화 배포에 대한 계획

아티클
04/23/2024

Azure 파일 동기화는 온-프레미스 Windows Server 또는 클라우드 VM에서 여러 Azure 파일 공유를 캐시할 수 있는 서비스입니다.

이 문서에서는 Azure 파일 동기화 개념 및 기능을 소개합니다. Azure 파일 동기화에 익숙해지면 Azure 파일 동기화 배포 가이드에 따라 이 서비스를 사용해 보는 것이 좋습니다.

파일은 클라우드의 Azure 파일 공유에 저장됩니다. Azure 파일 공유는 이러한 서버리스 Azure 파일 공유(SMB)를 직접 탑재하거나 Azure 파일 동기화를 사용하여 온-프레미스에서 Azure 파일 공유를 캐시하는 두 가지 방법으로 사용할 수 있습니다. 선택한 배포 옵션에 따라 배포 계획에서 고려해야 할 측면이 달라집니다.

Azure 파일 공유의 직접 탑재: Azure Files는 SMB 액세스를 제공하므로 Windows, macOS 및 Linux에서 사용할 수 있는 표준 SMB 클라이언트를 사용하여 온-프레미스 또는 클라우드에서 Azure 파일 공유를 탑재할 수 있습니다. Azure 파일 공유는 서버리스이므로, 프로덕션 시나리오를 위한 솔루션을 배포할 때 파일 서버 또는 NAS 디바이스를 관리할 필요가 없습니다. 즉 소프트웨어 패치를 적용하거나 실제 디스크를 교환할 필요가 없습니다.
Azure 파일 동기화를 사용하여 Azure 파일 공유를 온-프레미스로 캐시: Azure 파일 동기화를 사용하면 온-프레미스 파일 서버의 유연성, 성능 및 호환성을 유지하면서 Azure Files에서 조직의 파일 공유를 중앙 집중화할 수 있습니다. Azure 파일 동기화는 온-프레미스(또는 클라우드) Windows Server를 Azure 파일 공유의 빠른 캐시로 변환합니다.

관리 개념

Azure 파일 동기화 배포에는 다음과 같은 세 가지 기본 관리 개체가 있습니다.

Azure 파일 공유: Azure 파일 공유는 Azure 파일 동기화 관계의 클라우드 엔드포인트를 제공하는 서버리스 클라우드 파일 공유입니다. Azure 파일 공유의 파일은 SMB 또는 FileREST 프로토콜을 통해 직접 액세스할 수 있지만, Azure 파일 공유가 Azure 파일 동기화에서 사용되는 경우 주로 Windows Server 캐시를 통해 파일에 액세스하는 것이 좋습니다. 이는 현재 Windows Server와 같은 효율적인 변경 검색 메커니즘이 Azure Files에 없기 때문입니다. 따라서 직접적인 Azure 파일 공유에 대한 변경 내용을 서버 엔드포인트로 다시 전파하는 데 걸릴 수 있습니다.
서버 엔드포인트: Azure 파일 공유에 동기화되는 Windows Server의 경로입니다. 볼륨 또는 볼륨의 루트에 있는 특정 폴더일 수 있습니다. 해당 네임스페이스가 겹치지 않으면 여러 서버 엔드포인트가 동일한 볼륨에 있을 수 있습니다.
동기화 그룹클라우드 엔드포인트 또는 Azure 파일 공유와 서버 엔드포인트 간의 동기화 관계를 정의하는 개체입니다. 동기화 그룹 내 엔드포인트는 서로 동기화된 상태를 유지합니다. 예를 들어 Azure 파일 동기화를 사용하여 관리하려는 두 개의 고유한 파일 세트가 있는 경우 두 개의 동기화 그룹을 만들고 서로 다른 엔드포인트를 각 동기화 그룹에 추가합니다.

Azure 파일 공유는 공유 스토리지 풀을 나타내는 최상위 개체인 스토리지 계정에 배포됩니다. 이 스토리지 풀은 여러 파일 공유는 물론 Blob 컨테이너, 큐 또는 테이블과 같은 기타 스토리지 리소스를 배포하는 데 사용할 수 있습니다. 스토리지 계정에 배포된 모든 스토리지 리소스는 해당 스토리지 계정에 적용되는 제한을 공유합니다. 스토리지 계정의 현재 제한은 Azure Files 확장성 및 성능 대상을 참조하세요.

Azure Files 배포에 사용할 스토리지 계정에는 다음과 같은 두 가지 기본 유형이 있습니다.

범용 버전 2(GPv2) 스토리지 계정: GPv2 스토리지 계정을 사용하면 표준/하드 디스크 기반(HDD 기반) 하드웨어에 Azure 파일 공유를 배포할 수 있습니다. GPv2 스토리지 계정은 Azure 파일 공유 저장 외에도 Blob 컨테이너, 큐 또는 테이블과 같은 다른 스토리지 리소스를 저장할 수 있습니다.
FileStorage 스토리지 계정: FileStorage 스토리지 계정을 사용하면 프리미엄/반도체 디스크 기반(SSD 기반) 하드웨어에 Azure 파일 공유를 배포할 수 있습니다. FileStorage 계정은 Azure 파일 공유를 저장하는 데만 사용할 수 있습니다. 다른 스토리지 리소스(Blob 컨테이너, 큐, 테이블 등)는 FileStorage 계정에 배포할 수 없습니다. FileStorage 계정만 SMB 및 NFS 파일 공유를 모두 배포할 수 있습니다.

Azure Portal, PowerShell 또는 CLI에서 제공하는 몇 가지 다른 스토리지 계정 유형이 있습니다. BlockBlobStorage 및 BlobStorage 스토리지 계정이라는 두 가지 스토리지 계정 유형은 Azure 파일 공유를 포함할 수 없습니다. 다른 두 스토리지 계정 유형은 범용 버전 1(GPv1)과 클래식 스토리지 계정이며, 두 계정 모두 Azure 파일 공유를 포함할 수 있습니다. GPv1 및 클래식 스토리지 계정에는 Azure 파일 공유가 포함될 수 있지만 Azure Files의 대부분의 새 기능은 GPv2 및 FileStorage 스토리지 계정에서만 사용할 수 있습니다. 따라서 새 배포에 대해 GPv2 및 FileStorage 스토리지 계정만 사용하고 환경에 이미 있는 경우 GPv1 및 클래식 스토리지 계정을 업그레이드하는 것이 좋습니다.

Azure 파일 동기화 관리 개념

동기화 그룹은 스토리지 동기화 서비스에 배포됩니다. 이 서비스는 Azure 파일 동기화에 사용할 서버를 등록하고 동기화 그룹 관계를 포함하는 최상위 개체입니다. Storage 동기화 서비스 리소스는 스토리지 계정 리소스의 피어로, Azure 리소스 그룹에 쉽게 배포할 수 있습니다. 스토리지 동기화 서비스는 여러 스토리지 계정과 여러 등록된 Windows Server에서 Azure 파일 공유를 포함하는 동기화 그룹을 만들 수 있습니다.

스토리지 동기화 서비스에서 동기화 그룹을 만들려면 먼저 Windows Server를 스토리지 동기화 서비스에 등록해야 합니다. 그러면 서버 또는 클러스터와 스토리지 동기화 서비스 간의 트러스트 관계를 나타내는 등록된 서버 개체가 만들어집니다. 스토리지 동기화 서비스를 등록하려면 먼저 Azure 파일 동기화 에이전트를 서버에 설치해야 합니다. 개별 서버 또는 클러스터를 한 번에 하나의 스토리지 동기화 서비스에만 등록할 수 있습니다.

동기화 그룹에는 하나의 클라우드 엔드포인트 또는 Azure 파일 공유와 하나 이상의 서버 엔드포인트가 포함됩니다. 서버 엔드포인트 개체에는 Azure 파일 동기화의 캐싱 기능을 제공하는 클라우드 계층화 기능을 구성하는 설정이 포함되어 있습니다. Azure 파일 공유와 동기화하려면 Azure 파일 공유가 포함된 스토리지 계정이 스토리지 동기화 서비스와 동일한 Azure 지역에 있어야 합니다.

Important

동기화 그룹의 클라우드 엔드포인트 또는 서버 엔드포인트의 네임스페이스를 변경하고, 파일을 동기화 그룹의 다른 엔드포인트와 동기화할 수 있습니다. 클라우드 엔드포인트(Azure 파일 공유)를 직접 변경하는 경우 변경 사항은 먼저 Azure 파일 동기화 변경 내용 검색 작업으로 검색되어야 합니다. 변경 내용 검색 작업은 클라우드 엔드포인트에 대해 24시간마다 한 번씩만 시작됩니다. 자세한 내용은 Azure Files 질문과 대답을 참조하세요.

필요한 스토리지 동기화 서비스 수 고려

이전 섹션에서는 Azure 파일 동기화를 구성하기 위한 핵심 리소스인 스토리지 동기화 서비스에 대해 설명합니다. Windows Server는 하나의 스토리지 동기화 서비스에만 등록할 수 있습니다. 따라서 하나의 스토리지 동기화 서비스만 배포하고 해당 서비스에 모든 서버를 등록하는 것이 가장 좋습니다.

다음과 같은 경우에만 여러 스토리지 동기화 서비스를 만듭니다.

서로 데이터를 교환해서는 안 되는 고유한 서버 집합이 있는 경우. 이 경우 다른 스토리지 동기화 서비스의 동기화 그룹에서 클라우드 엔드포인트로 이미 사용 중인 Azure 파일 공유와 동기화할 특정 서버 집합을 제외하도록 시스템을 디자인하려고 합니다. 다른 스토리지 동기화 서비스에 등록된 Windows Server는 동일한 Azure 파일 공유와 동기화할 수 없습니다.
단일 스토리지 동기화 서비스에서 지원할 수 있는 것보다 더 많은 서버 또는 동기화 그룹을 등록해야 하는 경우. 자세한 내용은 Azure 파일 동기화 크기 조정 목표를 검토하세요.

균형 있는 동기화 토폴로지 계획

리소스를 배포하기 전에 Azure 파일을 공유하는 로컬 서버에서 동기화할 항목을 계획하는 것이 중요합니다. 계획을 세우면 필요한 스토리지 계정 수, Azure 파일 공유 수, 동기화 리소스 수를 결정하는 데 도움이 됩니다. 데이터가 현재 Windows Server 또는 장기간 사용하려는 서버에 있지 않더라도 이러한 고려 사항은 여전히 중요합니다. 마이그레이션 섹션의 내용을 참조하면 상황에 적합한 마이그레이션 경로를 결정하는 데 도움이 될 수 있습니다.

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

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

Windows 파일 서버 고려 사항

Windows Server에서 동기화 기능을 사용하도록 설정하려면 다운로드 가능한 Azure 파일 동기화 에이전트를 설치해야 합니다. Azure 파일 동기화 에이전트는 서버 엔드포인트의 변경을 모니터링하고 동기화 세션을 시작하는 백그라운드 Windows 서비스인 FileSyncSvc.exe 및 클라우드 계층화와 빠른 재해 복구를 지원하는 파일 시스템 필터인 StorageSync.sys의 두 가지 주요 구성 요소를 제공합니다.

운영 체제 요구 사항

Azure 파일 동기화를 지원하는 Windows Server 버전은 다음과 같습니다.

버전	지원되는 SKU	지원되는 배포 옵션
Windows Server 2022	Azure, 데이터 센터, 에센셜, 표준 및 IoT	전체 및 핵심
Windows Server 2019	데이터 센터, 필수 요소, 표준 및 IoT	전체 및 핵심
Windows Server 2016	데이터 센터, 에센셜, 표준, 스토리지 서버	전체 및 핵심
Windows Server 2012 R2*	데이터 센터, 에센셜, 표준, 스토리지 서버	전체 및 핵심

*WMF(Windows Management Framework) 5.1을 다운로드하고 설치해야 합니다. Windows Server 2012 R2에 대해 다운로드하고 설치할 적절한 패키지는 Win8.1AndW2K12R2-KB*******-x64.msu입니다.

이후 버전의 Windows Server는 출시되면 추가될 예정입니다.

Important

Windows 업데이트의 최신 업데이트를 사용하여 Azure 파일 동기화와 함께 사용되는 모든 서버를 최신 상태로 유지하는 것이 좋습니다.

최소 시스템 리소스

Azure 파일 동기화에는 하나 이상의 CPU, 최소 2GiB의 메모리 및 NTFS 파일 시스템으로 포맷된 로컬로 연결된 볼륨이 있는 실제 또는 가상 서버가 필요합니다.

Important

서버가 동적 메모리를 사용하도록 설정된 가상 머신에서 실행되는 경우 VM은 2,048MiB 이상의 메모리로 구성해야 합니다.

대부분의 프로덕션 워크로드의 경우 최소 요구 사항만으로 Azure 파일 동기화 서버를 구성하지 않는 것이 좋습니다. 자세한 내용은 추천 시스템 리소스를 참조하세요.

네임스페이스 크기 - 파일 및 디렉터리 수(100만)	일반 용량(TiB)	CPU 코어 수	추천 메모리(GiB)
3	1.4	2	8(초기 동기화)/2(일반적인 변동)
5	2.3	2	16(초기 동기화)/4(일반적인 변동)
10	4.7	4	32(초기 동기화)/8(일반적인 변동)
30	14.0	8	48(초기 동기화)/16(일반적인 변동)
50	23.3	16	64(초기 동기화)/32(일반적인 변동)
100*	46.6	32	128(초기 동기화)/32(일반적인 변동)

평가 cmdlet

Azure 파일 동기화를 배포하기 전에 Azure 파일 동기화 평가 cmdlet을 사용하여 시스템과 호환되는지 여부를 평가해야 합니다. 이 cmdlet은 지원되지 않는 문자 또는 운영 체제 버전과 같은 데이터 세트 및 파일 시스템과 관련된 잠재적인 문제를 확인합니다. 이러한 확인에는 아래에서 설명하는 기능 전부는 아니지만 대부분이 포함됩니다. 배포가 원활하게 진행되도록 하려면 이 섹션의 나머지 부분을 자세히 참조하는 것이 좋습니다.

평가 cmdlet은 Azure PowerShell 설치 및 구성의 지침에 따라 설치할 수 있는 Az PowerShell 모듈을 설치하면 설치될 수 있습니다.

사용

평가 도구는 몇 가지 다른 방법으로 호출할 수 있습니다. 즉 시스템 검사, 데이터 세트 검사 또는 둘 다를 수행할 수 있습니다. 시스템 검사 및 데이터 세트 검사를 모두 수행하려면 다음을 수행합니다.

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

데이터 세트만 테스트하려면 다음을 수행합니다.

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

시스템 요구 사항만 테스트하려면 다음을 수행합니다.

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

결과를 CSV 형식으로 표시하려면 다음을 수행합니다.

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

파일 시스템 호환성

Azure 파일 동기화는 직접 연결된 NTFS 볼륨에서만 지원됩니다. Windows Server의 DAS(직접 연결된 스토리지)는 Windows Server 운영 체제에서 파일 시스템을 소유하고 있음을 의미합니다. DAS는 디스크를 파일 서버에 물리적으로 연결하거나, 가상 디스크를 파일 서버 VM(예: Hyper-V에서 호스트하는 VM)에 연결하거나, ISCSI를 통해 연결하여 제공할 수 있습니다.

NTFS 볼륨만 지원되며, ReFS, FAT, FAT32 및 기타 파일 시스템은 지원되지 않습니다.

다음 표에서는 NTFS 파일 시스템 기능의 interop 상태를 보여 줍니다.

기능	상태 지원	주의
ACL(액세스 제어 목록)	완벽하게 지원	Windows 스타일의 임의 액세스 제어 목록은 Azure 파일 동기화에서 유지되며, 서버 엔드포인트의 Windows Server에서 적용됩니다. 또한 Azure 파일 공유를 직접 탑재하는 경우 ACL을 적용할 수 있지만, 이 경우 추가 구성이 필요합니다. 자세한 내용은 ID 섹션을 참조하세요.
하드 링크	건너뜀
바로 가기 링크	건너뜀
탑재 지점	부분적으로 지원됨	탑재 지점은 서버 엔드포인트의 루트일 수 있지만, 서버 엔드포인트의 네임스페이스에 포함된 경우 건너뜁니다.
분기 동기화	건너뜀	분산 파일 시스템 DfrsrPrivate 및 DFSRoots 폴더를 예로 들 수 있습니다.
재분석 지점	건너뜀
NTFS 압축	부분적으로 지원됨	Azure 파일 동기화는 SVI(시스템 볼륨 정보) 디렉터리가 압축된 볼륨에 있는 서버 엔드포인트를 지원하지 않습니다.
스파스 파일	완벽하게 지원	스파스 파일은 동기화되지만(차단되지 않음) 전체 파일로 클라우드와 동기화됩니다. 클라우드(또는 다른 서버)에서 파일 콘텐츠가 변경될 경우 변경 내용이 다운로드되면 파일은 더 이상 스파스 파일이 아닙니다.
ADS(대체 데이터 스트림)	보존되지만 동기화되지 않음	예를 들어, 파일 분류 인프라에서 만들어진 분류 태그는 동기화되지 않습니다. 각 서버 엔드포인트의 파일에 대한 기존 분류 태그는 그대로 유지됩니다.

또한 Azure 파일 동기화는 다음과 같은 특정 임시 파일 및 시스템 폴더도 건너뜁니다.

파일/폴더	참고 항목
pagefile.sys	시스템에 특정된 파일
Desktop.ini	시스템에 특정된 파일
thumbs.db	미리 보기에 대한 임시 파일
ehthumbs.db	미디어 썸네일의 임시 파일
~$.	Office 임시 파일
*.tmp	임시 파일
*.laccdb	액세스 DB 잠금 파일
635D02A9D91C401B97884B82B3BCDAEA.*	내부 동기화 파일
\System Volume Information	볼륨에 특정된 폴더
$RECYCLE.BIN	폴더
\SyncShareState	동기화할 폴더
.SystemShareInformation	Azure 파일 공유에서 동기화할 폴더

참고 항목

Azure 파일 동기화는 데이터베이스 파일 동기화를 지원하지만 로그 파일과 데이터베이스를 함께 동기화해야 하므로 데이터베이스는 동기화 솔루션(Azure 파일 동기화 포함)에 적합한 워크로드가 아니며, 데이터베이스 손상으로 이어질 수 있는 다양한 이유로 인해 동기화되지 않을 수 있습니다.

로컬 디스크에 필요한 여유 공간의 양을 고려합니다.

Azure 파일 동기화 사용을 계획할 때 서버 엔드포인트를 사용하려는 로컬 디스크에 필요한 여유 공간의 양을 고려합니다.

Azure 파일 동기화를 사용하면 로컬 디스크에서 다음 공간을 차지해야 합니다.

클라우드 계층화 사용:
- 계층화된 파일에 대한 재분석 지점
- Azure 파일 동기화 메타데이터 데이터베이스
- Azure 파일 동기화 열 저장소
- 핫 캐시에서 완전히 다운로드한 파일(있는 경우)
- 사용 가능한 볼륨 공간 정책 요구 사항
클라우드 계층화 사용하지 않음:
- 완전히 다운로드한 파일
- Azure 파일 동기화 열 저장소
- Azure 파일 동기화 메타데이터 데이터베이스

예제를 사용하여 로컬 디스크에서 사용 가능한 공간의 양을 예측하는 방법을 보여 줍니다. Azure Windows VM에 Azure 파일 동기화 에이전트를 설치하고 디스크 F에서 서버 엔드포인트를 만들 계획이라고 가정해 보겠습니다. 100만 개의 파일이 있고 모두 100,000개의 디렉터리 및 4KiB의 디스크 클러스터 크기로 계층화하려고 합니다. 디스크 크기는 1,000GiB입니다. 클라우드 계층화를 사용하고 사용 가능한 볼륨 공간 정책을 20%로 설정하려고 합니다.

NTFS는 계층화된 각 파일에 대해 클러스터 크기를 할당합니다. 100만 개 파일 * 4KiB 클러스터 크기 = 4,000,000KiB(4GiB)

참고 항목

클라우드 계층화의 이점을 충분히 활용하려면 계층화된 각 파일이 클러스터를 차지하므로 더 작은 NTFS 클러스터 크기(64KiB 미만)를 사용하는 것이 좋습니다. 또한 계층화된 파일이 차지하는 공간은 NTFS에서 할당합니다. 따라서 UI에 표시되지 않습니다.
동기화 메타데이터는 항목당 클러스터 크기를 차지합니다. (100만 개 파일 + 100,000개 디렉터리) * 4KiB 클러스터 크기 = 4,400,000KiB(4.4GiB)
Azure 파일 동기화 열 저장소는 파일당 1.1KiB를 차지합니다. 100만 개 파일 * 1.1KiB = 1,100,000KiB(1.1GiB)
사용 가능한 볼륨 공간 정책은 20%입니다. 1,000GiB * 0.2 = 200GiB

이 경우 Azure 파일 동기화에는 이 네임스페이스에 대한 약 209,500,000KiB(209.5GiB)의 공간이 필요합니다. 이 디스크에 필요한 여유 공간이 충분한지 파악하기 위해 원하는 추가 여유 공간에 이 크기를 추가합니다.

장애 조치(Failover) 클러스터링

Windows Server 장애 조치(Failover) 클러스터링은 "범용 파일 서버" 배포 옵션의 Azure 파일 동기화에서 지원됩니다. 장애 조치(failover) 클러스터에서 "일반 사용을 위한 파일 서버" 역할을 구성하는 방법에 대한 자세한 내용은 2노드 클러스터링된 파일 서버 배포를 참조하세요.
Azure 파일 동기화에서 지원하는 유일한 시나리오는 클러스터된 디스크가 있는 Windows Server 장애 조치(Failover) 클러스터입니다.
장애 조치(Failover) 클러스터링은"애플리케이션 데이터용 SOFS(스케일 아웃 파일 서버)" 또는 CSV(클러스터된 공유 볼륨) 또는 로컬 디스크에서 지원되지 않습니다.

참고 항목

동기화가 제대로 작동하려면 장애 조치(Failover) 클러스터의 모든 노드에 Azure 파일 동기화 에이전트를 설치해야 합니다.

데이터 중복 제거

Windows Server 2022, Windows Server 2019 및 Windows Server 2016
데이터 중복 제거는 Windows Server 2016, Windows Server 2019 및 Windows Server 2022의 볼륨에 있는 하나 이상의 서버 엔드포인트에서 클라우드 계층화의 사용 여부에 관계없이 지원됩니다. 클라우드 계층화를 사용하도록 설정된 볼륨에서 데이터 중복 제거를 사용하도록 설정하면 더 많은 스토리지를 프로비저닝하지 않고도 온-프레미스에서 더 많은 파일을 캐시할 수 있습니다.

클라우드 계층화를 사용하도록 설정된 볼륨에서 데이터 중복 제거를 사용하도록 설정하면 서버 엔드포인트 위치 내의 중복 제거 최적화 파일이 클라우드 계층화 정책 설정에 따라 일반 파일과 비슷하게 계층화됩니다. 중복 제거 최적화 파일이 계층화되면 볼륨의 다른 파일에서 더 이상 참조하지 않는 불필요한 청크를 제거하여 디스크 공간을 회수하기 위해 데이터 중복 제거 가비지 수집 작업이 자동으로 실행됩니다.

볼륨 절약은 서버에만 적용되며, Azure 파일 공유의 데이터는 중복 제거되지 않습니다.

참고 항목

Windows Server 2019에서 클라우드 계층화를 사용하도록 설정된 볼륨에서 데이터 중복 제거를 지원하려면 Windows 업데이트 KB4520062 - 2019년 10월 또는 이후 월별 롤업 업데이트를 설치해야 합니다.

Windows Server 2012 R2
Azure 파일 동기화는 Windows Server 2012 R2에서 동일한 볼륨의 데이터 중복 제거 및 클라우드 계층화를 지원하지 않습니다. 볼륨에서 데이터 중복 제거를 사용하도록 설정하면 클라우드 계층화를 사용하지 않도록 설정해야 합니다.

참고

Azure 파일 동기화 에이전트를 설치하기 전에 데이터 중복 제거가 설치되면, 동일한 볼륨에서 데이터 중복 제거 및 클라우드 계층화를 지원하기 위해 다시 시작해야 합니다.
클라우드 계층화를 사용하도록 설정한 후 볼륨에서 데이터 중복 제거를 사용하도록 설정하면, 초기 중복 제거 최적화 작업을 통해 아직 계층화되지 않은 볼륨에서 파일을 최적화하며 클라우드 계층화에 다음과 같은 영향을 미칩니다.
- 사용 가능한 공간 정책은 열 지도를 사용하여 볼륨의 사용 가능한 공간에 따라 파일을 계속 계층화합니다.
- 날짜 정책은 파일에 액세스하는 중복 제거 최적화 작업으로 인해 다른 방법으로 계층화될 수 있는 파일의 계층화를 건너뜁니다.
지속적인 중복 제거 최적화 작업의 경우 파일이 아직 계층화되지 않았으면 MinimumFileAgeDays 데이터 중복 제거 설정에 따라 날짜 정책을 사용하는 클라우드 계층화가 지연됩니다.
- 예: MinimumFileAgeDays 설정이 7일이고 클라우드 계층화 날짜 정책이 30일인 경우 날짜 정책은 37일 후에 파일을 계층화합니다.
- 참고: 파일이 Azure 파일 동기화를 통해 계층화되면 중복 제거 최적화 작업에서 해당 파일을 건너뜁니다.
Azure 파일 동기화 에이전트가 설치된 Windows Server 2012 R2를 실행하는 서버가 Windows Server 2016, Windows Server 2019 또는 Windows Server 2022로 업그레이드되면, 동일한 볼륨에서 데이터 중복 제거 및 클라우드 계층화를 지원하기 위해 다음 단계를 수행해야 합니다.
- Windows Server 2012 R2용 Azure 파일 동기화 에이전트를 제거하고 서버를 다시 시작합니다.
- 새 서버 운영 체제 버전(Windows Server 2016, Windows Server 2019 또는 Windows Server 2022)용 Azure 파일 동기화 에이전트를 다운로드합니다.
- Azure 파일 동기화 에이전트를 설치하고 서버를 다시 시작합니다.
참고: 에이전트를 제거하고 다시 설치하면 서버의 Azure 파일 동기화 구성 설정이 유지됩니다.

분산 파일 시스템(DFS)

Azure 파일 동기화에서는 DFS-N(DFS 네임스페이스) 및 DFS-R(DFS 복제)과의 상호 작용을 지원합니다.

DFS 네임 스페이스(DFS-N): DFS-N 구현 시 Azure File Sync가 완전히 지원됩니다. 하나 이상의 파일 서버에 Azure File Sync 에이전트를 설치하여 서버 엔드포인트와 클라우드 엔드포인트 간에 데이터를 동기화한 다음 DFS-N을 사용하여 네임스페이스 서비스를 제공할 수 있습니다. 자세한 내용은 DFS 네임스페이스 개요 및 Azure Files DFS 네임스페이스를 참조하세요.

DFS-R(DFS 복제): DFS-R 및 Azure 파일 동기화는 모두 복제 솔루션이므로 대부분의 경우 DFS-R을 Azure 파일 동기화로 바꾸는 것이 좋습니다. 그러나 DFS-R과 Azure 파일 동기화를 모두 사용하려는 몇 가지 시나리오가 있습니다.

DFS-R 배포에서 Azure 파일 동기화 배포로 마이그레이션하는 중입니다. 자세한 내용은 DFS 복제(DFS-R) 배포를 Azure 파일 동기화로 마이그레이션을 참조하세요.
파일 데이터 복사본이 필요한 모든 온-프레미스 서버를 인터넷에 직접 연결할 수는 없습니다.
분기 서버는 Azure 파일 동기화를 사용할 단일 허브 서버에 데이터를 통합합니다.

Azure 파일 동기화 및 DFS-R을 나란히 작동하려면 다음을 수행합니다.

Azure 파일 동기화 클라우드 계층화는 DFS-R 복제 폴더를 포함하는 볼륨에서 사용하지 않도록 설정해야 합니다.
서버 엔드포인트는 DFS-R 읽기 전용 복제 폴더에 구성하면 안 됩니다.
단일 서버 엔드포인트만 DFS-R 위치와 겹칠 수 있습니다. 여러 서버 엔드포인트가 다른 활성 DFS-R 위치와 겹치면 충돌이 발생할 수 있습니다.

자세한 내용은 DFS 복제 개요를 참조하세요.

Sysprep

sysprep은 Azure 파일 동기화 에이전트가 설치된 서버에서 사용할 수 없으며, 사용하는 경우 예기치 않은 결과가 발생할 수 있습니다. 에이전트 설치 및 서버 등록은 서버 이미지 배포 및 sysprep 최소 설치 완료 후 발생해야 합니다.

Windows 검색

클라우드 계층화가 서버 엔드포인트에서 활성화되면 계층화된 파일은 건너뛰고 Windows Search를 통해 인덱싱되지 않습니다. 계층화되지 않은 파일은 제대로 인덱싱됩니다.

참고 항목

항상 검색 파일 이름 및 콘텐츠 설정을 클라이언트 머신에서 활성화하면 파일 공유를 검색할 때 Windows 클라이언트가 회수됩니다. 이 설정은 기본적으로 사용하지 않도록 설정됩니다.

다른 HSM(계층적 스토리지 관리) 솔루션

다른 HSM 솔루션은 Azure 파일 동기화와 함께 사용하면 안 됩니다.

성능 및 스케일링 성능

Azure 파일 동기화 에이전트가 Azure 파일 공유에 연결된 Windows Server 컴퓨터에서 실행되므로 유효한 동기화 성능은 인프라에 포함된 많은 요소(Windows Server 및 기본 디스크 구성,서버와 Azure Storage 간의 네트워크 대역폭, 파일 크기, 데이터 세트의 총 크기 및 데이터 세트의 작업 등)에 따라 달라집니다. Azure 파일 동기화가 파일 수준에서 작동하므로 Azure 파일 동기화 기반 솔루션의 성능 특성은 초당 처리된 개체(예: 파일 및 디렉터리)의 수에서 정확하게 측정됩니다.

Azure Portal 또는 SMB를 사용하여 Azure 파일 공유에서 변경한 사항은 즉시 검색되지 않고 서버 엔드포인트의 변경 사항처럼 복제됩니다. Azure Files에는 변경 알림 또는 저널링이 없기 때문에 파일이 변경될 때 동기화 세션을 자동으로 시작할 방법이 없습니다. Windows Server에서 Azure 파일 동기화는 Windows USN 저널링을 사용하여 파일이 변경될 때 자동으로 동기화 세션을 시작합니다.

Azure 파일 공유의 변경 사항을 검색하기 위해 Azure 파일 동기화에는 변경 검색 작업이라는 예약된 작업이 있습니다. 변경 검색 작업은 파일 공유의 모든 파일을 열거한 다음 해당 파일의 동기화 버전과 비교합니다. 변경 검색 작업에서 파일이 변경된 것으로 판단되면 Azure 파일 동기화는 동기화 세션을 시작합니다. 변경 검색 작업은 24시간마다 시작됩니다. 변경 검색 작업은 Azure 파일 공유의 모든 파일을 열거하여 작동하므로 변경 검색은 큰 네임스페이스가 작은 네임스페이스보다 오래 걸립니다. 큰 네임스페이스의 경우 변경된 파일을 확인하는 것이 24시간마다 한 번 이상이 걸릴 수 있습니다.

자세한 내용은 Azure 파일 동기화 성능 메트릭 및 Azure 파일 동기화 스케일링 목표를 참조하세요.

ID

Azure 파일 동기화는 동기화 설정 이외의 특별한 설정 없이 표준 AD 기반 ID를 사용하여 작동합니다. Azure 파일 동기화를 사용하는 경우 일반적으로 대부분의 액세스에서 Azure 파일 공유가 아니라 Azure 파일 동기화 캐싱 서버를 통과합니다. 서버 엔드포인트는 Windows Server에 있고 Windows Server는 오랫동안 AD 및 Windows 스타일 ACL을 지원했으므로 스토리지 동기화 서비스에 등록된 Windows 파일 서버가 도메인에 조인되어 있는지 확인하는 것 외에는 아무 작업도 필요하지 않습니다. Azure 파일 동기화는 ACL을 Azure 파일 공유의 파일에 저장하고 이를 모든 서버 엔드포인트에 복제합니다.

Azure 파일 공유를 직접 변경한 경우에도 동기화 그룹의 서버 엔드포인트와 동기화하는 데 시간이 더 오래 걸리므로 클라우드에서 파일 공유에 대한 AD 권한을 직접 적용할 수도 있습니다. 이렇게 하려면 Windows 파일 서버가 도메인에 조인되는 방법과 마찬가지로 스토리지 계정을 온-프레미스 AD의 도메인에 조인해야 합니다. 스토리지 계정을 고객 소유의 Active Directory의 도메인에 조인하는 방법에 대한 자세한 내용은 Azure Files Active Directory 개요를 참조하세요.

Important

Azure 파일 동기화를 성공적으로 배포하기 위해 스토리지 계정을 Active Directory의 도메인에 조인할 필요가 없습니다. 이는 사용자가 Azure 파일 공유를 직접 탑재할 때 Azure 파일 공유에서 온-프레미스 ACL을 적용할 수 있도록 하는 엄격한 선택적 단계입니다.

네트워킹

Azure 파일 동기화 에이전트는 항상 443 포트에서 HTTPS를 사용하는 Azure 파일 동기화 REST 프로토콜 및 FileREST 프로토콜을 사용하여 스토리지 동기화 서비스 및 Azure 파일 공유와 통신합니다. SMB는 Windows Server와 Azure 파일 공유 간에 데이터를 업로드하거나 다운로드하는 데 사용되지 않습니다. 대부분의 조직에서는 443 포트를 통한 HTTPS 트래픽을 허용하므로 대부분의 웹 사이트를 방문하기 위한 요구 사항에 따라 특별한 네트워킹 구성은 일반적으로 Azure 파일 동기화를 배포하는 데 필요하지 않습니다.

Important

Azure 파일 동기화는 인터넷 라우팅을 지원하지 않습니다. 기본 네트워크 라우팅 옵션인 Microsoft 라우팅은 Azure 파일 동기화에서 지원됩니다.

조직의 정책 또는 고유한 규정 요구 사항에 따라 Azure와의 더 제한적인 통신이 필요할 수 있으므로 Azure 파일 동기화에서 네트워킹을 구성할 수 있는 몇 가지 메커니즘을 제공합니다. 요구 사항에 따라 다음을 수행할 수 있습니다.

ExpressRoute 또는 Azure VPN을 통해 동기화 및 파일 업로드/다운로드 트래픽을 터널링합니다.
Azure Files 및 Azure 네트워킹 기능(예: 서비스 엔드포인트 및 프라이빗 엔드포인트)을 활용합니다.
사용자 환경에서 프록시를 지원하도록 Azure 파일 동기화를 구성합니다.
Azure 파일 동기화에서 네트워크 활동을 제한합니다.

팁

SMB를 통해 Azure 파일 공유와 통신하지만 포트 445가 차단된 경우 포트 443을 통해 QUIC 전송 프로토콜을 사용하여 Azure 파일 공유에 대한 SMB 액세스에 대해 구성이 필요 없는 "SMB VPN"을 제공하는 QUIC를 통해 SMB를 사용하는 것이 좋습니다. Azure Files는 QUIC를 통해 SMB를 직접 지원하지 않지만 Azure 파일 동기화를 사용하여 Windows Server 2022 Azure Edition VM에서 Azure 파일 공유의 간단한 캐시를 만들 수 있습니다. 이 옵션에 대한 자세한 내용은 Azure 파일 동기화를 사용하는 QUIC를 통한 SMB를 참조하세요.

Azure 파일 동기화 및 네트워킹에 대한 자세한 내용은 Azure 파일 동기화 네트워킹 고려 사항을 참조하세요.

암호화

Azure 파일 동기화를 사용하는 경우 고려해야 할 세 가지 암호화 계층이 있습니다. 즉 Windows Server 스토리지의 저장 데이터 암호화, Azure 파일 동기화 에이전트와 Azure 간의 전송 중 데이터 암호화 및 Azure 파일 공유의 저장 데이터 암호화입니다.

Windows Server 저장 데이터 암호화

일반적으로 Azure 파일 동기화에서 작동하는 Windows Server에서 데이터를 암호화하는 두 가지 전략이 있습니다. 즉 파일 시스템 아래의 암호화(파일 시스템 및 여기에 기록된 모든 데이터가 암호화됨) 및 파일 형식 자체 내의 암호화입니다. 이러한 방법은 함께 사용할 수 없습니다. 암호화 목적이 다르므로 원하는 경우 함께 사용할 수 있습니다.

암호화를 파일 시스템 아래에 제공하기 위해 Windows Server에서 BitLocker 받은 편지함을 제공합니다. BitLocker는 Azure 파일 동기화에 완전히 투명합니다. BitLocker와 같은 암호화 메커니즘을 사용하는 주된 이유는 누군가가 디스크를 도용하여 온-프레미스 데이터 센터에서 데이터가 물리적으로 반출되지 않도록 방지하고 데이터에 대한 무단 읽기/쓰기 작업을 수행하는 권한이 없는 OS를 사이드로드하지 않도록 방지할 수 있기 때문입니다. BitLocker에 대한 자세한 내용은 BitLocker 개요를 참조하세요.

BitLocker와 비슷하게 작동하는 타사 제품은 NTFS 볼륨 아래에 위치한다는 점에서 Azure 파일 동기화와 완전히 투명하게 작동해야 합니다.

데이터를 암호화하는 다른 주요 방법은 애플리케이션에서 파일을 저장할 때 파일의 데이터 스트림을 암호화하는 것입니다. 일부 애플리케이션에서 기본적으로 이 작업을 수행할 수 있지만 일반적으로는 그렇지 않습니다. 파일 데이터 스트림을 암호화하는 방법의 예로 AIP(Azure Information Protection)/Azure RMS(Azure Rights Management Services)/Active Directory RMS가 있습니다. AIP/RMS와 같은 암호화 메커니즘을 사용하는 주된 이유는 사용자가 플래시 드라이브와 같은 대체 위치에 복사하거나 권한이 없는 사용자에게 이메일로 전송하여 파일 공유에서 데이터가 반출되지 않도록 방지할 수 있기 때문입니다. 파일의 데이터 스트림이 파일 형식의 일부로 암호화되는 경우 이 파일은 Azure 파일 공유에서 계속 암호화됩니다.

Azure 파일 동기화는 파일 시스템 위에 있지만 파일의 데이터 스트림 아래에 있는 NTFS EFS(NTFS 암호화된 파일 시스템) 또는 타사 암호화 솔루션과 상호 운용되지 않습니다.

전송 중 암호화

참고 항목

Azure 파일 동기화 서비스는 2020년 8월 1일에 TLS1.0 및 1.1 지원을 제거했습니다. 지원되는 모든 Azure 파일 동기화 에이전트 버전은 기본적으로 TLS 1.2를 이미 사용하고 있습니다. 서버에서 TLS 1.2를 사용하지 않도록 설정했거나 프록시가 사용되는 경우 이전 버전의 TLS를 사용하고 있을 수 있습니다. 프록시를 사용하는 경우 프록시 구성을 확인하는 것이 좋습니다. 2020년 5월 1일 이후에 추가된 Azure 파일 동기화 서비스 지역은 TLS1.2만 지원합니다. 자세한 내용은 문제 해결 가이드를 참조하세요.

Azure 파일 동기화 에이전트는 항상 443 포트에서 HTTPS를 사용하는 Azure 파일 동기화 REST 프로토콜 및 FileREST 프로토콜을 사용하여 스토리지 동기화 서비스 및 Azure 파일 공유와 통신합니다. Azure 파일 동기화는 암호화되지 않은 요청을 HTTP를 통해 보내지 않습니다.

Azure 스토리지 계정에는 전송 중 암호화를 요구하는 스위치가 포함되어 있으며, 이는 기본적으로 사용하도록 설정되어 있습니다. 스토리지 계정 수준의 스위치가 사용하지 않도록 설정되어 있는 경우에도(Azure 파일 공유에 대한 암호화되지 않은 연결이 가능하다는 것을 의미함) Azure 파일 동기화는 여전히 암호화된 채널만 사용하여 파일 공유에 액세스합니다.

전송 중 암호화를 스토리지 계정에 사용하지 않도록 설정하는 주요 이유는 Windows Server 2008 R2 또는 이전 Linux 배포와 같은 이전 운영 체제에서 실행하여 Azure 파일 공유와 직접 통신해야 하는 레거시 애플리케이션을 지원하기 때문입니다. 레거시 애플리케이션에서 파일 공유의 Windows Server 캐시와 통신하는 경우 이 설정을 전환해도 아무런 영향을 주지 않습니다.

전송 중 데이터 암호화를 사용하도록 설정하는 것이 좋습니다.

전송 중 암호화에 대한 자세한 내용은 Azure Storage에서 보안 전송 필요를 참조하세요.

Azure Files에 저장된 모든 데이터는 Azure SSE(스토리지 서비스 암호화)를 사용하여 저장 데이터로 암호화됩니다. 스토리지 서비스 암호화는 Windows의 BitLocker와 유사하게 작동하며, 데이터는 파일 시스템 수준 아래에서 암호화됩니다. Azure 파일 공유의 파일 시스템 아래에서 데이터가 암호화되어 디스크로 인코딩되므로 Azure 파일 공유를 읽거나 쓰기 위해 클라이언트의 기본 키에 액세스할 필요가 없습니다. 저장 데이터 암호화는 SMB 및 NFS 프로토콜 모두에 적용됩니다.

기본적으로 Azure Files에 저장된 데이터는 Microsoft 관리형 키로 암호화됩니다. Microsoft는 Microsoft 관리형 키를 사용하여 데이터를 암호화/암호 해독하는 키를 보유하고 있으며 정기적으로 이를 순환시킬 책임이 있습니다. 또한 순환 프로세스를 제어할 수 있는 자체 키를 관리하도록 선택할 수도 있습니다. 고객 관리형 키로 파일 공유를 암호화하도록 선택한 경우, 클라이언트의 읽기 및 쓰기 요청을 수행하기 위해 키에 액세스할 수 있는 권한이 Azure Files에게 부여됩니다. 고객 관리형 키를 사용하여 언제든지 이 권한 부여를 취소할 수 있지만, 그럴 경우 SMB 또는 FileREST API를 통해 더 이상 Azure 파일 공유에 액세스할 수 없습니다.

Azure Files는 Azure Blob 스토리지와 같은 다른 Azure 스토리지 서비스와 동일한 암호화 체계를 사용합니다. Azure SSE(스토리지 서비스 암호화)에 대한 자세한 내용은 미사용 데이터에 대한 Azure 스토리지 암호화를 참조하세요.

스토리지 계층

Azure Files는 시나리오의 성능 및 가격 요구 사항에 맞게 공유를 조정할 수 있는 스토리지, SSD 및 HDD의 두 가지 미디어 계층을 제공합니다.

SSD(프리미엄): 프리미엄 파일 공유는 SSD(반도체 드라이브)를 통해 사용되며, IO를 많이 사용하는 워크로드를 위해 일관된 고성능 및 짧은 대기 시간을 대부분의 IO 작업에 한 자릿수 밀리초 내에 제공합니다. 프리미엄 파일 공유는 데이터베이스, 웹 사이트 호스팅, 개발 환경 등 다양한 워크로드에 적합합니다. 프리미엄 파일 공유는 SMB(서버 메시지 블록) 및 NFS(네트워크 파일 시스템) 프로토콜과 함께 사용할 수 있습니다. 프리미엄 파일 공유는 FileStorage 스토리지 계정 종류로 배포되며, 프로비저닝된 청구 모델에서만 사용할 수 있습니다. 프리미엄 파일 공유의 프로비저닝된 청구 모델에 대한 자세한 내용은 프리미엄 파일 공유에 대한 프로비저닝 이해를 참조하세요. 프리미엄 파일 공유는 표준 파일 공유보다 더 높은 가용성 SLA를 제공합니다("Azure Files 프리미엄 계층" 참조).
HDD(표준): 표준 파일 공유는 HDD(하드 디스크 드라이브)를 사용하며 범용 파일 공유를 위한 비용 효율적인 저장 옵션을 제공합니다. 표준 파일 공유는 범용 버전 2(GPv2) 스토리지 계정 종류로 배포됩니다. SLA에 대한 자세한 내용은 Azure 서비스 수준 계약 페이지("스토리지 계정" 참조)를 참조하세요. 표준 파일 공유는 사용량 기반 가격 책정을 제공하는 종량제 모델을 사용합니다. 파일 공유의 액세스 계층을 사용하면 IOPS 비용에 따라 스토리지 비용을 조정하여 총 청구서를 최적화할 수 있습니다.
- 트랜잭션 최적화 파일 공유는 프리미엄 파일 공유에서 제공하는 짧은 대기 시간이 필요하지 않은 트랜잭션이 많은 워크로드에 대해 최저 비용의 트랜잭션 가격 책정을 제공합니다. 데이터를 Azure Files로 마이그레이션하는 동안 권장됩니다.
- 핫 파일 공유는 두 가지를 모두 잘 측정할 수 있는 워크로드에 대해 균형 잡힌 스토리지 및 트랜잭션 가격 책정을 제공합니다.
- 쿨 파일 공유는 스토리지 집약적인 워크로드에 대해 가장 비용 효율적인 스토리지 가격 책정을 제공합니다.

워크로드에 대한 미디어 계층을 선택할 때 성능 및 사용 요구 사항을 고려합니다. 워크로드에 한 자릿수 대기 시간이 필요하거나 온-프레미스에서 SSD 스토리지 미디어를 사용하는 경우 프리미엄 계층이 가장 적합할 수 있습니다. 예를 들어 Azure에서 온-프레미스에 탑재되거나 Azure 파일 동기화를 사용하여 온-프레미스에 캐시되는 팀 공유와 같이 짧은 대기 시간이 그다지 중요하지 않은 경우 표준 스토리지가 비용 측면에서 더 적합할 수 있습니다.

파일 공유가 스토리지 계정에 만들어지면 이를 다른 스토리지 계정 종류에 대한 전용 계층으로 이동할 수 없습니다. 예를 들어 트랜잭션 최적화 파일 공유를 프리미엄 계층으로 이동하려면, 새 파일 공유를 FileStorage 스토리지 계정에 만들고 원래 공유의 데이터를 FileStorage 계정의 새 파일 공유에 복사해야 합니다. AzCopy를 사용하여 Azure 파일 공유 간에 데이터를 복사하는 것이 좋지만, Windows용 robocopy 또는 macOS 및 Linux용 rsync와 같은 도구를 사용할 수도 있습니다.

자세한 내용은 Azure Files 청구 이해를 참조하세요.

국가별 가용성

현재 대용량 파일 공유가 활성화된 표준 파일 공유(최대 100TiB 용량)에는 특정 제한 사항이 있습니다.

LRS(로컬 중복 스토리지) 및 ZRS(영역 중복 스토리지) 계정만 지원됩니다.
스토리지 계정에서 대용량 파일 공유를 사용하도록 설정하면 GRS(지역 중복 스토리지) 또는 GZRS(지리역 영역 중복 스토리지)를 사용하도록 스토리지 계정을 변환할 수 없습니다.
일단 대용량 파일 공유를 사용하도록 설정하면 사용하지 않도록 설정할 수 없습니다.

표준 SMB Azure 파일 공유와 함께 GRS 또는 GZRS를 사용하려면 대용량 파일 공유 미리 보기에 대한 Azure Files 지역 중복을 참조하세요.

Azure 파일 동기화 지역 가용성

지역별 가용성에 대해서는 지역별 사용 가능한 제품을 참조하세요.

다음 지역에서는 Azure 파일 동기화를 사용하기 전에 Azure Storage에 대한 액세스를 요청해야 합니다.

프랑스 남부
남아프리카 공화국 서부
아랍에미리트 중부

이러한 지역에 대한 액세스를 요청하려면 이 문서의 프로세스를 따르세요.

중복

Azure 파일 공유 데이터를 손실 또는 손상으로부터 보호하기 위해 Azure Files는 기록 시 각 파일의 여러 복사본을 저장합니다. 요구 사항에 따라 다양한 수준의 중복성을 선택할 수 있습니다. 현재 Azure Files는 다음과 같은 데이터 중복도 옵션을 지원합니다.

LRS(로컬 중복 스토리지): LRS를 사용하면 모든 파일이 Azure Storage 클러스터 내에서 세 번 저장됩니다. 이는 불량 디스크 드라이브와 같은 하드웨어 오류로 인한 데이터 손실을 방지합니다. 그러나 데이터 센터 내에서 화재나 홍수와 같은 재해가 발생하는 경우 LRS를 사용하는 스토리지 계정의 모든 복제본이 손실되거나 복구할 수 없게 될 수 있습니다.
ZRS(영역 중복 스토리지): ZRS를 사용하면 각 파일의 복사본 3개가 저장됩니다. 그러나 이러한 복사본은 서로 다른 Azure 가용성 영역에 있는 세 개의 개별 스토리지 클러스터에 물리적으로 격리됩니다. 가용성 영역은 Azure 지역 내의 고유한 물리적 위치입니다. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성됩니다. 스토리지에 대한 쓰기는 가용성 영역 3개 모두에 있는 스토리지 클러스터에 기록되어야만 허용됩니다.
GRS(지역 중복 스토리지): GRS를 사용하면 주 지역과 보조 지역이라는 두 개의 지역이 있습니다. 파일은 주 지역의 Azure Storage 클러스터 내에 세 번 저장됩니다. 쓰기는 Microsoft에서 정의한 보조 지역에 비동기적으로 복제됩니다. GRS는 두 Azure 지역 간에 분산된 데이터의 복사본 6개를 제공합니다. 자연 재해 또는 기타 유사한 이벤트로 인한 Azure 지역의 영구 손실 같은 심각한 재해가 발생하는 경우 Microsoft는 장애 조치(failover)를 수행합니다. 이 경우 보조 지역이 주 지역이 되어 모든 작업을 처리합니다. 주 지역과 보조 지역 간 복제는 비동기적이므로, 심각한 재해가 발생하는 경우 보조 지역에 아직 복제되지 않은 데이터는 손실됩니다. 또한 지역 중복 스토리지 계정의 수동 장애 조치(failover)를 수행할 수도 있습니다.
GZRS(지리적 영역 중복 스토리지): GZRS는 ZRS와 비슷하지만 지역 중복이 있는 것처럼 생각할 수 있습니다. GZRS를 사용하면 파일은 주 지역에 있는 세 개의 고유 스토리지 클러스터에 세 번 저장됩니다. 이 경우 모든 쓰기는 Microsoft에서 정의한 보조 지역에 비동기식으로 복제됩니다. GZRS에 대한 장애 조치 프로세스는 GRS와 동일하게 작동합니다.

최대 5TiB의 표준 Azure 파일 공유는 네 가지 중복 유형을 모두 지원합니다. 5TiB보다 큰 표준 파일 공유는 LRS 및 ZRS만 지원합니다. 프리미엄 Azure 파일 공유는 LRS와 ZRS만 지원합니다.

GPv2(범용 버전 2) 스토리지 계정은 Azure Files가 지원하지 않는 두 가지 다른 중복 옵션인 RA-GRS(읽기 액세스 지역 중복 스토리지)를 읽고 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)를 제공합니다. 이러한 옵션을 설정하여 스토리지 계정에서 Azure 파일 공유를 프로비저닝할 수 있지만 Azure Files는 보조 지역에서 읽기를 지원하지 않습니다. RA-GRS 또는 RA-GZRS 스토리지 계정에 배포된 Azure 파일 공유는 각각 GRS 또는 GZRS로 청구됩니다.

Important

지역 중복 및 지리적 영역 중복 스토리지는 스토리지를 보조 지역에 수동으로 장애 조치할 수 있습니다. Azure 파일 동기화를 사용하는 경우 데이터를 손실할 가능성이 높으므로 재해 발생 외에는 이 작업을 수행하지 않는 것이 좋습니다. 스토리지의 수동 장애 조치를 시작하려는 재해가 발생하는 경우 Microsoft에서 지원 사례를 열어 Azure 파일 동기화에서 보조 엔드포인트와의 동기화를 다시 시작하도록 해야 합니다.

마이그레이션

기존 Windows 파일 서버 2012R2 이상이 있는 경우 데이터를 새 서버로 이동할 필요 없이 Azure 파일 동기화를 직접 설치할 수 있습니다. Azure 파일 동기화 채택의 일부로 새 Windows 파일 서버로 마이그레이션할 계획이거나 데이터가 현재 NAS(Network Attached Storage)에 있는 경우 이 데이터와 함께 Azure 파일 동기화를 사용하는 몇 가지 가능한 마이그레이션 방법이 있습니다. 선택해야 하는 마이그레이션 방법은 현재 데이터가 있는 위치에 따라 달라집니다.

자세한 지침은 Azure 파일 동기화 및 Azure 파일 공유 마이그레이션 개요 문서를 참조하세요.

바이러스 백신

바이러스 백신은 파일에서 알려진 악성 코드를 검색하는 방식으로 작동하므로 바이러스 백신 제품은 계층화된 파일을 회수하여 높은 송신 비용을 초래할 수 있습니다. 계층화된 파일에는 보안 Windows 속성 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS가 설정되어 있으며 소프트웨어 공급업체에 문의하여 이 속성이 설정된 파일 읽기를 건너뛰도록 솔루션을 구성하는 방법을 알아보는 것이 좋습니다(대부분은 자동으로 수행).

Microsoft의 사내 바이러스 백신 솔루션, Windows Defender 및 SCEP(System Center Endpoint Protection) 모두는 이 특성이 설정된 파일 읽기를 자동으로 건너뜁니다. 이러한 솔루션을 테스트하여 하나의 사소한 문제를 확인했습니다. 즉 기존 동기화 그룹에 서버를 추가하면 800바이트보다 작은 파일이 새 서버에서 회수(다운로드)됩니다. 이러한 파일은 새 서버에 남아 있지만 계층화 크기 요구 사항(64kb 초과)을 충족하지 않으므로 계층화되지 않습니다.

참고 항목

바이러스 백신 공급업체는 Microsoft 다운로드 센터에서 다운로드할 수 있는 Azure 파일 동기화 바이러스 백신 호환성 테스트 도구 모음을 사용하여 제품과 Azure 파일 동기화 간의 호환성을 확인할 수 있습니다.

Backup

클라우드 계층화를 사용하는 경우 서버 엔드포인트 또는 서버 엔드포인트가 있는 VM을 직접 백업하는 솔루션을 사용해서는 안 됩니다. 클라우드 계층화를 사용하면 전체 데이터 세트가 Azure 파일 공유에 상주하면서 데이터의 하위 집합만 서버 엔드포인트에 저장됩니다. 사용된 백업 솔루션에 따라 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 특성 집합으로 인해 계층화된 파일을 건너뛰고 백업하지 않거나 이러한 파일이 디스크로 회수되어 높은 송신 요금이 발생합니다. 클라우드 백업 솔루션을 사용하여 Azure 파일 공유를 직접 백업하는 것이 좋습니다. 자세한 내용은 Azure 파일 공유 백업 정보를 참조하거나 백업 공급자에게 문의하여 Azure 파일 공유 백업을 지원하는지 확인하세요.

온-프레미스 백업 솔루션을 사용하려는 경우 클라우드 계층화를 사용하지 않도록 설정된 동기화 그룹의 서버에서 백업을 수행하고 계층화된 파일이 없는지 확인해야 합니다. 복원을 수행할 때 볼륨 수준 또는 파일 수준 복원 옵션을 사용합니다. 파일 수준 복원 옵션을 사용하여 복원된 파일은 동기화 그룹의 모든 엔드포인트에 동기화되고 기존 파일은 백업에서 복원된 버전으로 대체됩니다. 볼륨 수준 복원은 Azure 파일 공유 또는 기타 서버 엔드포인트의 최신 파일 버전을 대체하지 않습니다.

참고 항목

BMR(완전) 복원, VM 복원, 시스템 복원(Windows 기본 제공 OS 복원) 및 계층화된 버전을 사용한 파일 수준 복원(백업 소프트웨어가 전체 파일 대신 계층화된 파일을 백업할 때 발생함)은 예기치 않은 결과를 초래할 수 있으며 클라우드 계층화가 사용하도록 설정된 경우 현재 지원되지 않습니다. VSS 스냅샷(이전 버전 탭 포함)은 클라우드 계층화가 사용하도록 설정된 볼륨에서 지원됩니다. 그러나 PowerShell을 통해 이전 버전과의 호환성을 사용하도록 설정해야 합니다. 방법을 알아보세요.

데이터 분류

데이터 분류 소프트웨어가 설치되어 있는 경우 클라우드 계층화를 사용하도록 설정하면 다음 두 가지 이유로 비용이 증가할 수 있습니다.

클라우드 계층화를 사용하면 가장 많이 사용한 파일이 로컬로 캐시되고 가장 덜 사용한 파일이 클라우드의 Azure 파일 공유에 계층화됩니다. 데이터 분류가 파일 공유에 있는 모든 파일을 정기적으로 검색하는 경우 검색할 때마다 클라우드에 계층화된 파일을 회수해야 합니다.
데이터 분류 소프트웨어가 파일의 데이터 스트림에서 메타데이터를 사용하는 경우 소프트웨어가 분류를 볼 수 있도록 파일을 완전히 회수해야 합니다.

회수 횟수와 회수되는 데이터 양이 모두 증가하면 비용이 증가할 수 있습니다.

Azure 파일 동기화 에이전트 업데이트 정책

Azure 파일 동기화 에이전트는 새 기능을 추가하고 문제를 해결하기 위해 주기적으로 업데이트됩니다. 새 버전을 사용할 수 있으면 Azure 파일 동기화 에이전트를 업데이트하는 것이 좋습니다.

주 및 부 에이전트 버전 비교

주 에이전트 버전에는 새로운 기능이 포함되는 경우가 많으며, 버전 번호의 첫 번째 부분에 증가하는 숫자가 있습니다. 예를 들어 14.0.0.0입니다.
부 에이전트 버전은 "패치"라고도 하며, 주 버전보다 더 자주 릴리스됩니다. 버그가 수정되고 기능이 향상되는 경우가 많지만, 새로운 기능은 없습니다. 예를 들어 14.1.0.0입니다.

업그레이드 경로

Azure 파일 동기화 에이전트 업데이트를 설치하는 데 승인된 다섯 가지 테스트 방법이 있습니다.

Azure 파일 동기화 에이전트 자동 업그레이드 기능을 사용하여 에이전트 업데이트를 설치합니다. Azure 파일 동기화 에이전트가 자동 업그레이드됩니다. 사용 가능한 경우 최신 에이전트 버전을 설치하거나 현재 설치된 에이전트가 거의 만료될 때 업데이트하도록 선택할 수 있습니다. 자세한 내용은 자동 에이전트 수명 주기 관리를 참조하세요.
에이전트 업데이트를 자동으로 다운로드하고 설치하도록 Microsoft 업데이트를 구성합니다. 서버 에이전트에 대한 최신 수정 사항에 액세스할 수 있도록 모든 Azure 파일 동기화 업데이트를 설치하는 것이 좋습니다. Microsoft Update는 자동으로 업데이트를 다운로드하고 설치하여 이 프로세스를 원활하게 만듭니다.
AfsUpdater.exe를 사용하여 에이전트 업데이트를 다운로드하고 설치합니다. AfsUpdater.exe는 에이전트 설치 디렉터리에 있습니다. 실행 파일을 두 번 클릭하여 에이전트 업데이트를 다운로드하고 설치합니다. 릴리스 버전에 따라 서버를 다시 시작해야 할 수 있습니다.
Microsoft 업데이트 패치 파일 또는 .msp 실행 파일을 사용하여 기존 Azure 파일 동기화 에이전트에 패치를 적용합니다. 최신 Azure 파일 동기화 업데이트 패키지는 Microsoft 업데이트 카탈로그에서 다운로드할 수 있습니다. .msp 실행 파일을 실행하면 Microsoft Update에서 자동으로 사용되는 것과 동일한 방법으로 Azure 파일 동기화 설치가 업그레이드됩니다. Microsoft 업데이트 패치를 적용하면 Azure 파일 동기화 설치의 현재 위치 업그레이드가 수행됩니다.
Microsoft 다운로드 센터 최신 Azure 파일 동기화 에이전트 설치 관리자를 다운로드합니다. 기존 Azure 파일 동기화 에이전트 설치를 업그레이드하려면 이전 버전을 제거한 다음, 다운로드한 설치 관리자에서 최신 버전을 설치합니다. Azure 파일 동기화 설치 관리자는 서버 등록, 동기화 그룹 및 다른 모든 설정을 관리합니다.

참고 항목

Azure 파일 동기화 에이전트의 다운그레이드는 지원되지 않습니다. 새 버전에는 이전 버전에 비해 호환성이 손상되는 변경 내용이 포함되어 있어 다운그레이드 프로세스가 지원되지 않는 경우가 많습니다. 현재 에이전트 버전에 문제가 발생하는 경우 지원에 문의하거나 사용 가능한 최신 릴리스로 업그레이드하세요.

자동 에이전트 수명 주기 관리

Azure 파일 동기화 에이전트가 자동 업그레이드됩니다. 두 가지 모드 중 하나를 선택하고 서버에서 업그레이드를 시도할 유지 관리 기간을 지정할 수 있습니다. 이 기능은 에이전트 만료를 방지하는 가드 레일을 제공하거나 번거로움없이 현재 설정을 유지함으로써 에이전트 수명 주기 관리에 도움이 되도록 설계되었습니다.

기본 설정은 에이전트가 만료되지 않도록 합니다. 에이전트의 게시된 만료 날짜로부터 21일 이내에 에이전트는 자체 업그레이드를 시도합니다. 만료 전 21일 내 그리고 선택한 유지 관리 기간에 일주일에 한 번 업그레이드를 시도합니다. 이 옵션을 사용하면 일반 Microsoft 업데이트 패치를 사용할 필요가 없습니다.
필요에 따라 새 에이전트 버전을 사용할 수 있게 되는 즉시 에이전트가 자동으로 업그레이드되도록 선택할 수 있습니다(클러스터형 서버에는 현재 적용할 수 없음). 이 업데이트는 선택한 유지 관리 기간 동안 발생하며 새로운 기능과 개선 사항이 일반 공급되는 즉시 서버에서 이들을 활용할 수 있도록 합니다. 이는 주 에이전트 버전과 서버에 대한 정기 업데이트 패치를 제공하는 걱정 없는 권장 설정입니다. 릴리스된 모든 에이전트는 GA 품질입니다. 이 옵션을 선택하면 Microsoft에서 최신 에이전트 버전을 플라이팅합니다. 클러스터형 서버는 제외됩니다. 플라이팅이 완료되면 Microsoft 다운로드 센터 aka.ms/AFS/agent에서 에이전트를 사용할 수 있게 됩니다.

자동 업그레이드 설정 변경

다음 지침에서는 변경이 필요한 경우 설치 프로그램을 완료한 후 설정을 변경하는 방법을 설명합니다.

PowerShell 콘솔을 열고 동기화 에이전트를 설치한 디렉터리로 이동한 다음 서버 cmdlet을 가져옵니다. 기본적으로 이는 다음과 같습니다.

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Get-StorageSyncAgentAutoUpdatePolicy를 실행하여 현재 정책 설정을 확인하고 변경할 것인지 결정할 수 있습니다.

현재 정책 설정을 지연된 업데이트 트랙으로 변경하려면 다음을 사용할 수 있습니다.

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

현재 정책 설정을 즉시 업데이트 트랙으로 변경하려면 다음을 사용할 수 있습니다.

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

에이전트 수명 주기 및 변경 관리 보장

Azure 파일 동기화는 새로운 기능과 향상된 기능을 지속적으로 도입하는 클라우드 서비스입니다. 즉, 특정 Azure 파일 동기화 에이전트 버전은 제한된 시간 동안만 지원될 수 있습니다. 배포를 쉽게 하기 위해 변경 관리 프로세스에서 에이전트 업데이트/업그레이드를 수용할 수 있는 충분한 시간과 알림을 보장하는 규칙은 다음과 같습니다.

주 에이전트 버전은 최초 릴리스 날짜로부터 최소 6개월 동안 지원됩니다.
주 에이전트 버전의 지원 사이에는 3개월 이상 겹치도록 보장합니다.
만료되기 최소 3개월 전에 만료될 에이전트를 사용하여 등록된 서버에 경고가 발급됩니다. 등록된 서버가 Storage Sync Service의 등록된 서버 섹션 아래에서 이전 버전의 에이전트를 사용하고 있는지 확인할 수 있습니다.
부 에이전트 버전의 수명은 연결된 주 버전에 따라 결정됩니다. 예를 들어 에이전트 버전 14.0.0.0이 만료되도록 설정되면 에이전트 버전 14.*.*.*은 모두 함께 만료되도록 설정됩니다.

참고 항목

만료 경고가 있는 에이전트 버전을 설치하면 경고가 표시되지만 성공합니다. 만료된 에이전트 버전을 설치하거나 연결하려는 시도는 지원되지 않으며 차단됩니다.

Azure 파일 동기화 배포에 대한 계획

관리 개념

Azure 파일 공유 관리 개념

Azure 파일 동기화 관리 개념

필요한 스토리지 동기화 서비스 수 고려

균형 있는 동기화 토폴로지 계획

공유 그룹화

볼륨 동기화

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

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

매핑 테이블 만들기

Windows 파일 서버 고려 사항

운영 체제 요구 사항

최소 시스템 리소스

추천 시스템 리소스

평가 cmdlet

사용

파일 시스템 호환성

로컬 디스크에 필요한 여유 공간의 양을 고려합니다.

장애 조치(Failover) 클러스터링

데이터 중복 제거

분산 파일 시스템(DFS)

Sysprep

Windows 검색

다른 HSM(계층적 스토리지 관리) 솔루션

성능 및 스케일링 성능

ID

네트워킹

암호화

Windows Server 저장 데이터 암호화

전송 중 암호화

Azure 파일 공유 저장 데이터 암호화

스토리지 계층

국가별 가용성

Azure 파일 동기화 지역 가용성

중복

마이그레이션

바이러스 백신

Backup

데이터 분류

Azure 파일 동기화 에이전트 업데이트 정책

주 및 부 에이전트 버전 비교

업그레이드 경로

자동 에이전트 수명 주기 관리

자동 업그레이드 설정 변경

에이전트 수명 주기 및 변경 관리 보장

다음 단계

추가 리소스