Azure Files 및 Azure 파일 동기화의 확장성 및 성능 목표
Azure Files는 SMB(서버 메시지 블록) 및 NFS(네트워크 파일 시스템) 파일 시스템 프로토콜을 통해 액세스할 수 있는 클라우드에서 완전 관리형 파일 공유를 제공합니다. 이 문서에서는 Azure 스토리지 계정, Azure Files 및 Azure 파일 동기화의 확장성 및 성능 목표에 대해 설명합니다.
여기에 나열된 대상은 배포의 다른 변수의 영향을 받을 수 있습니다. 예를 들어 파일의 I/O 성능은 SMB 클라이언트의 동작과 사용 가능한 네트워크 대역폭에 의해 영향을 줄 수 있습니다. Azure Files의 확장성 및 성능이 요구 사항을 충족하는지 확인하려면 사용 패턴을 테스트해야 합니다.
적용 대상
| 파일 공유 유형 | SMB | NFS |
|---|---|---|
| 표준 파일 공유(GPv2), LRS/ZRS |  |
 |
| 표준 파일 공유(GPv2), GRS/GZRS | |
|
| 프리미엄 파일 공유(FileStorage), LRS/ZRS | |
|
Azure Files 크기 조정 목표
Azure 파일 공유는 공유 스토리지 풀을 나타내는 최상위 개체인 스토리지 계정에 배포됩니다. 이 스토리지 풀을 사용하여 여러 파일 공유를 배포할 수 있습니다. 따라서 스토리지 계정, Azure 파일 공유, 개별 파일 등 세 가지 범주를 고려해야 합니다.
스토리지 계정 크기 조정 목표
스토리지 계정 크기 조정 목표는 스토리지 계정 수준에서 적용됩니다. Azure Files에 대한 스토리지 계정에는 두 가지 주요 유형이 있습니다.
범용 버전 2(GPv2) 스토리지 계정: GPv2 스토리지 계정을 사용하면 표준/하드 디스크 기반(HDD 기반) 하드웨어에 Azure 파일 공유를 배포할 수 있습니다. GPv2 스토리지 계정은 Azure 파일 공유 저장 외에도 Blob 컨테이너, 큐 또는 테이블과 같은 다른 스토리지 리소스를 저장할 수 있습니다. 파일 공유는 트랜잭션 최적화(기본값), 핫, 쿨 계층에 배포할 수 있습니다.
FileStorage 스토리지 계정: FileStorage 스토리지 계정을 사용하면 프리미엄/반도체 디스크 기반(SSD 기반) 하드웨어에 Azure 파일 공유를 배포할 수 있습니다. FileStorage 계정은 Azure 파일 공유를 저장하는 데만 사용할 수 있습니다. 다른 스토리지 리소스(Blob 컨테이너, 큐, 테이블 등)는 FileStorage 계정에 배포할 수 없습니다.
| Attribute | GPv2 스토리지 계정(표준) | FileStorage 스토리지 계정(프리미엄) |
|---|---|---|
| 구독당 지역별 스토리지 계정 수 | 2501 | 2501 |
| 최대 스토리지 계정 용량 | 5PiB2 | 100TiB(프로비전됨) |
| 최대 파일 공유 수 | 제한 없음 | 모든 공유의 무제한, 총 프로비전 크기는 최대 스토리지 계정 용량보다 작아야 합니다. |
| 최대 동시 요청 빈도 | 20,000 IOPS2 | 102,400 IOPS |
LRS/GRS에 대한 처리량(수신 + 송신)
|
|
10,340MiB/초 |
ZRS에 대한 처리량(수신 + 송신)
|
|
10,340MiB/초 |
| 이전 행에 나열되지 않은 중복/지역 조합에 대한 처리량(수신 + 송신)입니다. |
|
10,340MiB/초 |
| 최대 가상 네트워크 규칙 수 | 200 | 200 |
| 최대 IP 주소 규칙 수 | 200 | 200 |
| 관리 읽기 작업 | 5분당 800 | 5분당 800 |
| 관리 쓰기 작업 | 초당 10/시간당 1200 | 초당 10/시간당 1200 |
| 관리 목록 작업 | 5분당 100 | 5분당 100 |
1 할당량을 늘리면 지역당 표준 엔드포인트를 사용하여 최대 500개의 스토리지 계정을 만들 수 있습니다. 자세한 내용은 Azure Storage 계정 할당량 증가를 참조하세요. 2 범용 버전 2 스토리지 계정은 더 높은 용량 제한과 요청별 수신에 대한 더 높은 제한을 지원합니다. 계정 제한을 늘리려면 Azure 지원에 문의하세요.
Azure 파일 공유 크기 조정 목표
Azure 파일 공유 크기 조정 목표는 파일 공유 수준에서 적용됩니다.
| Attribute | 표준 파일 공유1 | 프리미엄 파일 공유 |
|---|---|---|
| 파일 공유의 최소 크기 | 최소값 없음 | 100GiB(프로비전됨) |
| 프로비전된 크기 증가/감소 단위 | 해당 없음 | 1GiB |
| 파일 공유의 최대 크기 | 100TiB | 100TiB |
| 파일 공유의 최소 파일 수 | 제한 없음 | 제한 없음 |
| 최대 요청 빈도(최대 IOPS) | 20,000 |
|
| 단일 파일 공유에 대한 처리량(수신 + 송신)(MiB/sec) | 최대 스토리지 계정 제한 | 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |
| 최대 공유 스냅샷 수 | 200 스냅샷 | 200 스냅샷 |
| 최대 개체 이름 길이3(모든 디렉터리, 파일 이름 및 백슬래시 문자를 포함하는 전체 경로 이름) | 2,048자 | 2,048자 |
| 개별 경로 이름 구성 요소의 최대 길이2(경로 \A\B\C\D에서 각 문자는 개별 구성 요소인 디렉터리 또는 파일을 나타냄) | 255자 | 255자 |
| 하드 링크 제한(NFS 전용) | 해당 없음 | 178 |
| 최대 SMB 다중 채널 채널 수 | 해당 없음 | 4 |
| 파일 공유당 저장된 액세스 정책의 최대 수 | 5 | 5 |
1 표준 파일 공유에 대한 제한은 표준 파일 공유에 사용할 수 있는 세 계층(트랜잭션 최적화, 핫, 쿨) 모두에 적용됩니다.
2 Azure Files는 디렉터리 및 파일 이름에 특정 명명 규칙을 적용합니다.
파일 크기 조정 목표
파일 크기 조정 목표는 Azure 파일 공유에 저장된 개별 파일에 적용됩니다.
| attribute | 표준 파일 공유의 파일 | 프리미엄 파일 공유의 파일 |
|---|---|---|
| 최대 파일 크기 | 4TiB | 4TiB |
| 최대 동시 요청 빈도 | 1,000 IOPS | 최대 8,0001 |
| 파일의 최대 수신 | 60MiB/초 | 200MiB/초(SMB 다중 채널로 최대 1GiB/초)2 |
| 파일의 최대 송신 | 60MiB/초 | 300MiB/초(SMB 다중 채널로 최대 1GiB/초)2 |
| 루트 디렉터리의 최대 동시 핸들3 | 10,000개 핸들 | 10,000개 핸들 |
| 루트 디렉터리의 최대 동시 핸들3 | 2,000개 핸들 | 2,000개 핸들 |
1 읽기 및 쓰기 I/O(일반적으로 64KiB 이하의 더 작은 I/O 크기)에 적용됩니다. 읽기 및 쓰기 이외의 메타데이터 작업은 더 낮을 수 있습니다. 이는 소프트 한계이며 이러한 한계를 넘어서면 제한이 발생할 수 있습니다.
2 컴퓨터 네트워크 제한, 사용 가능한 대역폭, I/O 크기, 큐 크기, 기타 요인에 따라 달라집니다. 자세한 내용은 SMB 다중 채널 성능을 참조하세요.
3 Azure Files 루트 디렉터리에서 10,000개의 열린 핸들과 공유 내의 파일 및 디렉터리당 2,000개의 열린 핸들을 지원합니다. 공유당 지원되는 활성 사용자 수는 공유에 액세스하는 애플리케이션에 따라 달라집니다. 애플리케이션이 루트 디렉터리에서 핸들을 열지 않는 경우 Azure Files는 공유당 10,000명이 넘는 활성 사용자를 지원할 수 있습니다. 그러나 Azure Files를 사용하여 대규모 가상 데스크톱 워크로드에 대한 디스크 이미지를 저장하는 경우 루트 디렉터리 핸들 또는 파일/디렉터리당 핸들이 부족할 수 있습니다. 이 경우 여러 Azure 파일 공유를 사용해야 할 수 있습니다. 자세한 내용은 Azure Virtual Desktop에 대한 Azure Files 크기 조정 지침을 참조하세요.
Azure Virtual Desktop에 대한 Azure Files 크기 조정 지침
Azure Files의 인기 있는 사용 사례는 FSLogix 또는 앱 연결을 사용하여 Azure Virtual Desktop에 대한 사용자 프로필 컨테이너 및 디스크 이미지를 저장하는 것입니다. 대규모 Azure Virtual Desktop 배포에서는 단일 Azure 파일 공유를 사용하는 경우 루트 디렉터리 핸들 또는 파일/디렉터리당 핸들이 부족할 수 있습니다. 이 섹션에서는 다양한 유형의 디스크 이미지로 핸들을 사용하는 방법을 설명하고 사용 중인 기술에 따른 크기 조정 지침을 제공합니다.
FSLogix
Azure Virtual Desktop에서 FSLogix를 사용하는 경우 사용자 프로필 컨테이너는 VHD(가상 하드 디스크) 또는 Hyper-V VHDX(가상 하드 디스크) 파일이며 시스템 컨텍스트가 아닌 사용자 컨텍스트에 탑재됩니다. 각 사용자는 파일 공유에 있어야 하는 단일 루트 디렉터리 핸들을 열게 됩니다. 파일 공유(\\storageaccount.file.core.windows.net\sharename) + 프로필 디렉터리(%sid%_%username%) + 프로필 컨테이너(profile_%username.vhd(x))가 있다고 가정했을 때 Azure Files는 최대 10,000명의 사용자를 지원할 수 있습니다.
루트 디렉터리에 대한 동시 핸들 수 한도인 10,000개에 도달하거나 사용자 판단에 따라 성능이 저하되는 경우 추가 Azure 파일 공유를 사용하고 공유 간에 컨테이너를 배포해 봅니다.
Warning
Azure Files는 단일 파일 공유에서 최대 10,000명의 동시 사용자를 지원할 수 있지만, 만든 파일 공유의 크기와 유형에 대해 워크로드를 제대로 테스트하는 것이 중요합니다. 요구 사항은 사용자, 프로필 크기, 워크로드에 따라 달라질 수 있습니다.
예를 들어 동시 사용자가 2,400명인 경우 루트 디렉터리에는 사용자당 1개씩 총 2,400개의 핸들이 필요하며, 이는 열린 핸들 한도인 10,000개보다 적습니다. FSLogix 사용자의 경우 열린 파일 및 디렉터리 핸들 한도인 2,000개에 도달할 가능성은 희박합니다. 사용자당 단일 FSLogix 프로필 컨테이너가 있는 경우 2개의 파일/디렉터리 핸들(프로필 디렉터리용 핸들과 프로필 컨테이너 파일용 핸들)만 사용합니다. 사용자에게 각각 2개의 컨테이너(프로필 및 ODFC)가 있는 경우 ODFC 파일용 핸들은 1개가 더 필요합니다.
CimFS를 사용하여 앱 연결
MSIX 앱 연결 또는 앱 연결을 사용하여 애플리케이션을 동적으로 연결하는 경우 디스크 이미지에 CimFS(Composite Image File System) 또는 VHD/VHDX 파일을 사용할 수 있습니다. 어떤 것을 사용하더라도 크기 한도는 사용자가 아니라 이미지를 탑재하는 VM을 기준으로 적용됩니다. 크기 한도를 계산할 때 사용자 수는 관련이 없습니다. VM이 부팅되면 사용자가 0명이어도 디스크 이미지를 탑재합니다.
CimFS에서 앱 연결을 사용하는 경우 디스크 이미지는 디스크 이미지 파일의 핸들만 사용합니다. 루트 디렉터리 또는 디스크 이미지가 포함된 디렉터리의 핸들을 사용하지 않습니다. 그러나 CimFS 이미지는 .cim 파일과 2개 이상의 다른 파일을 조합한 것이므로 디스크 이미지를 탑재하는 모든 VM에 대해 디렉터리의 3개 파일에 각각 핸들 1개가 필요합니다. 즉, VM이 100개면 파일 핸들 300개가 필요합니다.
앱당 VM 수가 2,000개를 넘으면 파일 핸들이 부족할 수 있습니다. 이 경우 추가 Azure 파일 공유를 사용합니다.
VHD/VHDX를 사용하여 앱 연결
VHD/VHDX 파일로 앱 연결을 사용하는 경우 파일은 사용자 컨텍스트가 아닌 시스템 컨텍스트에 탑재되며 공유되고 읽기 전용입니다. VHDX 파일에서 2개 이상의 핸들을 연결 시스템에서 사용할 수 있습니다. Azure Files 크기 한도를 유지하려면 VM 수에 앱 수를 곱한 수가 10,000개 미만이어야 하며 앱당 VM 수는 2,000개를 초과할 수 없습니다. 따라서 먼저 도달하는 것이 제약 조건이 됩니다.
이 시나리오에서는 단일 VHD/VHDX를 2,000개 탑재하여 파일/디렉터리당 한도에 도달할 수 있습니다. 또는 공유에 여러 VHD/VHDX 파일이 포함된 경우 먼저 루트 디렉터리 한도에 도달할 수 있습니다. 예를 들어 공유 VHDX 파일 100개를 탑재한 VM 100개는 루트 디렉터리 한도인 핸들 10,000개에 도달합니다.
또 다른 예제를 보면 20개 앱에 액세스하는 VM 100개는 루트 디렉터리 핸들 2,000개(100 x 20 = 2,000)가 필요하며, 이는 루트 디렉터리 핸들 한도인 10,000개를 넘지 않습니다. 또한 VHD(X) 이미지를 탑재하는 모든 VM에는 파일 핸들 및 디렉터리/폴더 핸들이 필요하므로 이 경우 핸들 200개(파일 핸들 100개 + 디렉터리 핸들 100개)는 파일/디렉터리당 한도인 핸들 2,000개보다 훨씬 낮습니다.
루트 디렉터리 또는 파일/디렉터리당 최대 동시 핸들 한도에 도달하는 경우 추가 Azure 파일 공유를 사용하세요.
Azure 파일 동기화 크기 조정 목표
다음 표는 Microsoft에서 테스트한 경계를 표시하는 소프트 대상을 나타내며, 적용된 최댓값을 표시하는 하드 대상을 나타냅니다.
| 리소스 | 대상 | 하드 한도 |
|---|---|---|
| 지역당 스토리지 동기화 서비스 수 | 100개 스토리지 동기화 서비스 | 예 |
| 구독당 스토리지 동기화 서비스 수 | 15개 스토리지 동기화 서비스 | 예 |
| 스토리지 동기화 서비스당 동기화 그룹 수 | 200개 동기화 그룹 | 예 |
| 스토리지 동기화 서비스당 등록된 서버 | 서버 99대 | 예 |
| 스토리지 동기화 서비스당 프라이빗 엔드포인트 | 100 프라이빗 엔드포인트 | 예 |
| 동기화 그룹당 클라우드 엔드포인트 수 | 1개 클라우드 엔드포인트 | 예 |
| 동기화 그룹당 서버 엔드포인트 수 | 100개 서버 엔드포인트 | 예 |
| 서버당 서버 엔드포인트 수 | 30개 서버 엔드포인트 | 예 |
| 동기화 그룹당 파일 시스템 개체(디렉터리 및 파일) 수 | 1억 개 개체 | 아니요 |
| 디렉터리에 있는 파일 시스템 개체(디렉터리 및 파일)의 최대 수 (재귀적이지 않음) | 500만 개 개체 | 예 |
| 최대 개체(디렉터리 및 파일) 보안 설명자 크기 | 64KiB | 예 |
| 파일 크기 | 100GiB | 아니요 |
| 계층화할 파일에 대한 최소 파일 크기 | 파일 시스템 클러스터 크기를 기준으로 합니다(이중 파일 시스템 클러스터 크기). 예를 들어 파일 시스템 클러스터 크기가 4KiB이면 최소 파일 크기는 8KiB입니다. | 예 |
참고 항목
Azure 파일 동기화 엔드포인트는 Azure 파일 공유의 크기로 확장할 수 있습니다. Azure 파일 공유 크기 한도에 도달하면 동기화를 작동할 수 없습니다.
Azure 파일 동기화 성능 메트릭
Azure 파일 동기화 에이전트가 Azure 파일 공유에 연결된 Windows Server 컴퓨터에서 실행되므로 유효한 동기화 성능은 인프라에 포함된 많은 요소(Windows Server 및 기본 디스크 구성,서버와 Azure Storage 간의 네트워크 대역폭, 파일 크기, 데이터 세트의 총 크기 및 데이터 세트의 작업 등)에 따라 달라집니다. Azure 파일 동기화가 파일 수준에서 작동하므로 Azure 파일 동기화 기반 솔루션의 성능 특성은 초당 처리된 개체(예: 파일 및 디렉터리)의 수로 측정해야 합니다.
Azure 파일 동기화의 경우 다음과 같은 두 단계에서 성능이 중요합니다.
- 일회성 초기 프로비전: 초기 프로비전에 대한 성능을 최적화하기 위해 최적의 배포 세부 정보는 Azure 파일 동기화에 온보딩을 참조하세요.
- 진행 중인 동기화: Azure 파일 공유에서 데이터를 처음으로 시드한 후에 Azure 파일 동기화는 여러 엔드포인트를 동기화된 상태로 유지합니다.
참고 항목
동일한 동기화 그룹의 많은 서버 엔드포인트가 동시에 동기화되는 경우 클라우드 서비스 리소스를 놓고 경합하고 있습니다. 결과적으로 업로드 성능이 영향을 받습니다. 극단적인 경우 일부 동기화 세션은 리소스에 액세스하지 못하고 실패합니다. 그러나 이러한 동기화 세션은 곧 다시 시작되고 정체가 줄어들면 결국 성공합니다.
내부 테스트 결과
각 단계(초기 일회용 프로비전 및 지속적인 동기화)에 대한 배포를 계획하는 데 도움이 되도록 다음 구성을 사용하여 시스템에서 내부 테스트 중에 관찰한 결과는 다음과 같습니다.
| 시스템 구성 | 세부 정보 |
|---|---|
| CPU | 64개의 MiB L3 캐시를 포함한 64개의 가상 코어 |
| 메모리 | 128GiB |
| 디스크 | 배터리 지원 캐시를 사용하는 RAID 10을 포함한 SAS 디스크 |
| 네트워크 | 1Gbps 네트워크 |
| 작업 | 범용 파일 서버 |
일회성 초기 프로비전
| 일회성 초기 프로비전 | 세부 정보 |
|---|---|
| 개체 수 | 2500만 개 개체 |
| 데이터 세트 크기 | ~4.7TiB |
| 평균 파일 크기 | ~200KiB(최대 파일: 100GiB) |
| 초기 클라우드 변경 열거 | 초당 개체 80개 |
| 처리량 업로드 | 동기화 그룹당 초당 20 개의 개체 |
| 네임스페이스 다운로드 처리량 | 초당 개체 400개 |
초기 클라우드 변경 열거: 새 동기화 그룹을 만들 때 실행하게 되는 첫 번째 단계는 초기 클라우드 변경 열거입니다. 이 프로세스에서 시스템은 Azure 파일 공유의 모든 항목을 열거합니다. 이 프로세스 중에는 동기화 작업이 없습니다. 클라우드 엔드포인트에서 서버 엔드포인트로 항목이 다운로드되지 않으며, 서버 엔드포인트에서 클라우드 엔드포인트로 항목이 업로드되지 않습니다. 초기 클라우드 변경 열거가 완료되면 동기화 작업이 다시 시작됩니다.
성능 속도는 초당 80개의 개체입니다. 클라우드 공유의 항목 수를 결정하고 다음 수식을 사용해 일 단위로 시간을 계산함으로써 초기 클라우드 변경 열거를 완료하는 데 걸리는 시간을 추정할 수 있습니다.
초기 클라우드 열거 시간(일) = (클라우드 엔드포인트의 개체 수)/(80 * 60 * 60 * 24)
Windows Server에서 Azure 파일 공유로의 초기 데이터 동기화: 모든 데이터가 Windows Server에 존재하기 때문에 Azure 파일 동기화 배포가 빈 Azure 파일 공유로 시작하는 경우가 많습니다. 이러한 경우 초기 클라우드 변경 열거가 빠르며 Windows Server에서 Azure 파일 공유로 변경 내용을 동기화하는 데 대부분의 시간이 소요됩니다.
동기화가 데이터를 Azure 파일 공유로 업로드하는 동안 로컬 파일 서버에는 가동 중지 시간이 발생하지 않으며 관리자는 네트워크 제한을 설정하여 백그라운드 데이터 업로드에 사용되는 대역폭의 양을 제한할 수 있습니다.
초기 동기화는 일반적으로 동기화 그룹당 초당 20 개 파일의 초기 업로드 속도로 제한됩니다. 고객은 다음 수식을 사용해 일 단위로 시간을 계산함으로써 모든 데이터를 Azure에 업로드하는 시간을 추정할 수 있습니다.
동기화 그룹에 파일을 업로드하는 시간(일) = (서버 엔드포인트의 개체 수)/(20 * 60 * 60 * 24)
여러 동기화 그룹에 대해 각각 초당 20 개 항목의 속도로 동시에 업로드를 수행할 수 있기 때문에 여러 개의 서버 엔드포인트와 동기화 그룹으로 데이터를 분할하면 초기 데이터 업로드 속도를 높일 수 있습니다. 따라서 두 개의 동기화 그룹은 합해서 초당 40 개 항목의 속도로 실행됩니다. 완료까지 소요되는 총 시간은 동기화할 파일이 가장 많은 동기화 그룹의 예상 시간과 같습니다.
네임 스페이스 다운로드 처리량 기존 동기화 그룹에 새 서버 엔드포인트를 추가하면 Azure 파일 동기화 에이전트는 클라우드 엔드포인트에서 파일 콘텐츠를 전혀 다운로드하지 않습니다. 먼저 전체 네임스페이스를 동기화한 다음, 백그라운드 회수를 트리거하여 전체 파일을 다운로드하거나 클라우드 계층화를 사용하는 경우 서버 엔드포인트에서 설정된 클라우드 계층화 정책에 파일을 다운로드합니다.
진행 중인 동기화
| 진행 중인 동기화 | 세부 정보 |
|---|---|
| 동기화된 개체 수 | 125000개 개체(~1% 변동) |
| 데이터 세트 크기 | 50GiB |
| 평균 파일 크기 | ~500KiB |
| 처리량 업로드 | 동기화 그룹당 초당 20 개의 개체 |
| 전체 다운로드 처리량* | 초당 개체 60개 |
*클라우드 계층화를 사용하면 일부 파일 데이터만을 다운로드할 때 성능이 더 개선될 수도 있습니다. Azure 파일 동기화는 엔드포인트 중 하나에서 캐시된 파일의 데이터가 변경될 때에만 해당 데이터를 다운로드합니다. 계층화되거나 새로 생성된 파일의 경우 에이전트는 파일 데이터를 다운로드하지 않습니다. 대신 모든 서버 엔드포인트에 네임스페이스만을 동기화합니다. 에이전트는 사용자가 액세스할 때 계층화된 파일의 부분 다운로드도 지원합니다.
참고 항목
이 숫자는 사용자가 경험하게 될 성능을 나타내는 것이 아닙니다. 실제 성능은 이 섹션의 시작 부분에 설명된 대로 여러 요소에 따라 달라집니다.
배포에 대한 일반적인 지침으로 다음 사항에 유의해야 합니다.
- 개체 처리량은 서버의 동기화 그룹 수에 비례하여 크기를 조정합니다. 서버의 여러 동기화 그룹으로 데이터를 분할하면 처리량이 향상됩니다. 처리량은 서버 및 네트워크에 의해서도 제한됩니다
- 개체 처리량은 초당 MiB 처리량에 반비례합니다. 더 작은 파일의 경우 초당 처리된 개체 수 측면에서 더 높은 처리량이 발생하지만 초당 MiB 처리량은 더 낮습니다. 반대로 큰 파일의 경우 초당 처리되는 개체는 적지만 초당 MiB 처리량은 높습니다. 초당 MiB 처리량은 Azure Files 크기 조정 목표에 의해 제한됩니다.