Azure Files 배포 계획

Azure Files는 서버리스 Azure 파일 공유를 직접 탑재하거나 Azure 파일 동기화를 사용하여 온-프레미스에서 Azure 파일 공유를 캐싱하는 두 가지 주요 방법으로 배포할 수 있습니다. 배포 고려 사항은 선택한 옵션에 따라 달라집니다.

• Azure 파일 공유 직접 탑재: Azure Files는 SMB(서버 메시지 블록) 또는 NFS(네트워크 파일 시스템) 액세스를 제공하므로 OS에서 사용할 수 있는 표준 SMB 또는 NFS 클라이언트를 사용하여 온-프레미스 또는 클라우드에서 Azure 파일 공유를 탑재할 수 있습니다. Azure 파일 공유는 서버리스이므로, 프로덕션 시나리오를 위한 솔루션을 배포할 때 파일 서버 또는 NAS 디바이스를 관리할 필요가 없습니다. 즉 소프트웨어 패치를 적용하거나 실제 디스크를 교환할 필요가 없습니다.

• Azure 파일 동기화를 사용하여 온-프레미스에서 Azure 파일 공유 캐시: Azure 파일 동기화를 사용하면 온-프레미스 파일 서버의 유연성, 성능 및 호환성을 유지하면서 Azure Files에서 조직의 파일 공유를 중앙 집중화할 수 있습니다. Azure 파일 동기화는 온-프레미스(또는 클라우드) Windows Server를 SMB Azure 파일 공유의 빠른 캐시로 변환합니다.

이 문서에서는 온-프레미스 또는 클라우드 클라이언트에서 직접 탑재할 Azure 파일 공유를 배포하기 위한 고려 사항을 주로 다룹니다. Azure 파일 동기화 배포를 계획하려면 Azure 파일 동기화 배포에 대한 계획을 참조하세요.

사용 가능한 프로토콜

Azure Files는 Azure 파일 공유를 탑재하기 위한 두 가지 업계 표준 파일 시스템 프로토콜, 즉 SMB(서버 메시지 블록) 프로토콜 및 NFS(네트워크 파일 시스템) 프로토콜을 제공하므로 워크로드에 가장 적합한 프로토콜을 선택할 수 있습니다. 동일한 스토리지 계정 내에서 SMB와 NFS Azure 파일 공유를 만들 수 있지만 Azure 파일 공유는 동일한 파일 공유에서 SMB와 NFS 프로토콜을 둘 다 지원하지 않습니다. NFS 4.1은 현재 새 FileStorage 스토리지 계정 유형 내에서만 지원됩니다(프리미엄 파일 공유만 해당).

SMB 및 NFS 파일 공유를 둘 다 사용하면 Azure Files는 스토리지 요구 사항에 맞게 스케일 업할 수 있고 수천 개의 클라이언트에서 동시에 액세스할 수 있는 엔터프라이즈급 파일 공유를 제공합니다.

관리 개념

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 파일 공유만 다른 Azure 파일 공유와 함께 스토리지 계정에 배포합니다. GPv2 스토리지 계정을 사용하면 혼합 목적 스토리지 계정을 보유할 수 있지만 Azure 파일 공유 및 Blob 컨테이너와 같은 스토리지 리소스에서 스토리지 계정의 제한을 공유하므로 리소스를 함께 혼합하면 성능 문제를 해결하기가 더 어려워질 수 있습니다.

• Azure 파일 공유를 배포할 때 스토리지 계정의 IOPS 제한 사항에 주의합니다. 이상적으로 파일 공유를 스토리지 계정과 1:1로 매핑하는 것이 좋습니다. 그러나 조직과 Azure 모두의 다양한 제한과 제약으로 인해 항상 가능한 것은 아닙니다. 하나의 스토리지 계정에 파일 공유를 하나만 배포할 수 없는 경우 많은 작업을 수행하는 공유와 적은 작업을 수행하는 공유를 고려하여 가장 많이 사용하는 파일 공유가 동일한 스토리지 계정에 함께 포함되지 않도록 하십시오.

• 사용자 환경에서 GPv2 및 FileStorage 계정을 배포하고, GPv1 및 클래식 스토리지 계정은 있는 경우에만 업그레이드합니다.

ID

Azure 파일 공유에 액세스하려면 파일 공유의 사용자를 인증하고 공유에 액세스할 수 있는 권한을 부여해야 합니다. 이 작업은 파일 공유에 액세스하는 사용자의 ID를 기반으로 수행합니다. Azure Files는 다음 인증 방법을 지원합니다.

• 온-프레미스 Active Directory Domain Services(AD DS 또는 온-프레미스 AD DS): Azure 스토리지 계정은 Windows Server 파일 서버 또는 NAS 디바이스와 마찬가지로 고객이 소유한 Active Directory Domain Services 도메인에 조인할 수 있습니다. 도메인 컨트롤러를 온-프레미스, Azure VM 또는 다른 클라우드 공급자의 VM으로 배포할 수 있습니다. Azure Files는 도메인 컨트롤러가 호스트되는 위치와는 무관합니다. 스토리지 계정이 도메인에 조인되면 최종 사용자는 PC에 로그인할 때 쓴 사용자 계정으로 파일 공유를 탑재할 수 있습니다. AD 기반 인증은 Kerberos 인증 프로토콜을 사용합니다.
• Microsoft Entra Domain Services: Microsoft Entra Domain Services는 Azure 리소스에 사용할 수 있는 Microsoft 관리형 도메인 컨트롤러를 제공합니다. Microsoft Entra Domain Services에 스토리지 계정을 조인하는 도메인에는 고객이 소유한 AD DS에 조인하는 도메인과 비슷한 이점이 있습니다. 이 배포 옵션은 AD 기반 사용 권한이 필요한 애플리케이션 리프트 앤 시프트 시나리오에 가장 유용합니다. Microsoft Entra Domain Services는 AD 기반 인증을 제공하므로 이 옵션 또한 Kerberos 인증 프로토콜을 사용합니다.
• 하이브리드 ID용 Microsoft Entra Kerberos: Microsoft Entra Kerberos를 사용하면 Microsoft Entra ID를 통해 클라우드에 동기화되는 온-프레미스 AD ID인 하이브리드 사용자 ID를 인증할 수 있습니다. 이 구성은 Microsoft Entra ID를 사용하여 SMB 프로토콜로 파일 공유에 액세스하기 위한 Kerberos 티켓을 발급합니다. 즉, 최종 사용자는 Microsoft Entra 하이브리드 조인 및 Microsoft Entra 가입 VM의 도메인 컨트롤러에 대한 네트워크 연결 없이 인터넷을 통해 Azure 파일 공유에 액세스할 수 있습니다.
• Linux 클라이언트용 SMB를 통한 Active Directory 인증: Azure Files는 AD DS 또는 Microsoft Entra Domain Services를 통해 Kerberos 인증 프로토콜을 사용하여 Linux 클라이언트용 SMB를 통한 ID 기반 인증을 지원합니다.
• Azure 스토리지 계정 키: Azure 스토리지 계정 키를 사용하여 Azure 파일 공유를 탑재할 수도 있습니다. 이 방식으로 파일 공유를 탑재하면 스토리지 계정 이름이 사용자 이름으로 사용되고 스토리지 계정 키가 암호로 사용됩니다. 탑재된 파일 공유에는 ACL이 있는 경우에도 공유되는 모든 파일 및 폴더에 대한 모든 권한이 있으므로 스토리지 계정 키를 사용하여 Azure 파일 공유를 탑재하는 것은 실질적으로 관리자 작업입니다. 스토리지 계정 키를 사용하여 SMB를 통해 탑재하는 경우에는 NTLMv2 인증 프로토콜이 사용됩니다. 스토리지 계정 키를 사용하여 Azure 파일 공유에 액세스하려는 경우 네트워킹 섹션에 설명된 대로 프라이빗 엔드포인트 또는 서비스 엔드포인트 사용을 권합니다.

온-프레미스 파일 서버에서 마이그레이션하거나 Windows 파일 서버 또는 NAS 어플라이언스와 같이 동작하기 위해 Azure Files에서 새 파일 공유를 만드는 고객의 경우에는,스토리지 계정을 고객 소유의 AD DS에 조인하는 도메인을 권합니다. 스토리지 계정을 고객 소유 AD DS에 조인하는 도메인에 대한 자세한 내용은 개요 - Azure 파일 공유에 대해 SMB를 통한 온-프레미스 Active Directory Domain Services 인증을 참조하세요.

네트워킹

Azure 파일 공유를 직접 탑재하려면 다음과 같은 이유로 네트워킹 구성을 고려해야 하는 경우가 많습니다.

• SMB 파일 공유에서 통신에 사용하는 445 포트는 아웃바운드(인터넷) 트래픽에 대해 많은 조직 및 ISP(인터넷 서비스 공급자)에서 자주 차단합니다.
• NFS 파일 공유는 네트워크 수준 인증을 사용하므로 제한된 네트워크를 통해서만 액세스할 수 있습니다. NFS 파일 공유를 사용하려면 항상 일정 수준의 네트워킹 구성이 필요합니다.

네트워킹을 구성하기 위해 Azure Files는 인터넷에 액세스할 수 있는 퍼블릭 엔드포인트를 제공하고, 퍼블릭 엔드포인트를 지정된 가상 네트워크로 제한하는 Azure 네트워킹 기능(예: 서비스 엔드포인트)과 가상 네트워크 IP 주소 공간 내에서 개인 IP 주소를 스토리지 계정에 제공하는 프라이빗 엔드포인트의 통합을 제공합니다. 퍼블릭 엔드포인트 또는 서비스 엔드포인트 사용에 대한 추가 요금은 없지만 프라이빗 엔드포인트에는 표준 데이터 처리 요금이 적용됩니다.

즉, 다음 네트워크 구성을 고려해야 합니다.

• 필요한 프로토콜이 SMB이고 SMB를 통한 모든 액세스가 Azure의 클라이언트에서 오는 경우 특별한 네트워킹 구성이 필요하지 않습니다.
• 필요한 프로토콜이 SMB이고 온-프레미스 클라이언트에서 액세스하는 경우 온-프레미스에서 Azure 네트워크로의 VPN 또는 ExpressRoute 연결이 필요하며 Azure Files가 프라이빗 엔드포인트를 사용하여 내부 네트워크에 공개됩니다.
• 필요한 프로토콜이 NFS인 경우 서비스 엔드포인트 또는 프라이빗 엔드포인트를 사용하여 네트워크를 지정된 가상 네트워크로 제한할 수 있습니다. 고정 IP 주소가 필요하거나 워크로드에 고가용성이 필요한 경우 프라이빗 엔드포인트를 사용합니다. 서비스 엔드포인트를 사용하면 영역 중단과 같은 드문 이벤트로 인해 스토리지 계정의 기본 IP 주소가 변경될 수 있습니다. 데이터는 파일 공유에서 계속 사용할 수 있지만 클라이언트는 공유를 다시 탑재해야 합니다.

Azure Files 네트워킹을 구성하는 방법에 대한 자세한 내용은 Azure Files 네트워킹 고려 사항을 참조하세요.

퍼블릭 엔드포인트를 사용하여 파일 공유에 직접 연결하거나 프라이빗 엔드포인트와 VPN/ExpressRoute 연결을 사용하는 것 외에도 SMB는 SMB over QUIC라는 추가 클라이언트 액세스 전략을 제공합니다. SMB over QUIC는 QUIC 전송 프로토콜을 통한 SMB 액세스를 위해 구성이 없는(zero-config) "SMB VPN"을 제공합니다. Azure Files는 SMB over QUIC를 직접 지원하지 않지만, Azure 파일 동기화를 사용하여 Windows Server 2022 Azure Edition VM에서 Azure 파일 공유의 간단한 캐시를 만들 수 있습니다. 이 옵션에 대한 자세한 내용은 Azure 파일 동기화를 사용하는 SMB over QUIC를 참조하세요.

암호화

Azure Files는 다음 두 가지 유형의 암호화를 지원합니다.

• 전송 중 암호화 - Azure 파일 공유를 탑재/액세스할 때 사용되는 암호화와 관련이 있습니다
• 미사용 암호화 - 데이터가 디스크에 저장될 때 암호화되는 방식과 관련이 있습니다

전송 중 암호화

기본적으로 모든 Azure 스토리지 계정에는 전송 중 암호화가 사용하도록 설정되어 있습니다. 즉, SMB를 통해 파일 공유를 탑재하거나 FileREST 프로토콜(예: Azure Portal, PowerShell/CLI 또는 Azure SDK)을 통해 액세스할 때 Azure Files는 암호화 또는 HTTPS를 사용하는 SMB 3.x를 통해 만든 연결만 허용합니다. SMB 3.x를 지원하지 않는 클라이언트 또는 SMB 3.x를 지원하지만 SMB 암호화를 지원하지 않는 클라이언트는 전송 중 암호화를 사용하도록 설정된 경우 Azure 파일 공유를 탑재할 수 없습니다. 암호화를 통해 SMB 3.x를 지원하는 운영 체제에 대한 자세한 내용은 Windows, macOS 및 Linux용 설명서를 참조하세요. 모든 현재 버전의 PowerShell, CLI 및 SDK는 HTTPS를 지원합니다.

Azure 스토리지 계정에 대해 전송 중 암호화를 사용하지 않도록 설정할 수 있습니다. 또한 암호화가 사용하지 않도록 설정되면 Azure Files에서 암호화 없는 SMB 2.1 및 SMB 3.x와 HTTP를 통한 암호화되지 않은 FileREST API 호출도 허용합니다. 전송 중 암호화를 사용하지 않도록 설정하는 주된 이유는 Windows Server 2008 R2 또는 이전 버전의 Linux 배포와 같은 이전 운영 체제에서 실행해야 하는 레거시 애플리케이션을 지원하기 위해서입니다. Azure Files는 Azure 파일 공유와 동일한 Azure 지역 내에서만 SMB 2.1 연결을 허용합니다. Azure 파일 공유의 Azure 지역 외부(예: 온-프레미스 또는 다른 Azure 지역)에 있는 SMB 2.1 클라이언트는 파일 공유에 액세스할 수 없습니다.

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

전송 중 암호화에 대한 자세한 내용은 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에는 데이터를 백업하고 복구하며 보안 위협으로부터 보호할 수 있도록 하는 다중 계층화된 접근 방식이 있습니다. Azure Files 데이터 보호 개요를 참조하세요.

일시 삭제

일시 삭제는 실수로 삭제될 때 파일 공유를 복구할 수 있는 스토리지 계정 수준 설정입니다. 파일 공유가 삭제되면 영구적으로 삭제되는 대신 일시 삭제된 상태로 전환됩니다. 일시 삭제된 공유를 영구적으로 삭제하기 전에 복구할 수 있는 시간을 설정하고, 이 보존 기간 동안 언제든지 공유 삭제를 취소할 수 있습니다.

일시 삭제는 새 스토리지 계정에 대해 기본적으로 사용하도록 설정됩니다. 공유 삭제를 자주 할 것으로 예상되는 워크플로가 있는 경우에는 보존 기간을 짧게 설정하거나 일시 삭제를 사용하지 않도록 설정할 수 있습니다.

일시 삭제에 대한 자세한 내용은 실수로 인한 데이터 삭제 방지를 참조하세요.

Backup

Azure 파일 공유를 공유 스냅샷(공유의 읽기 전용 지정 시간 복사본)으로 백업할 수 있습니다. 스냅샷은 증분형이므로 이전 스냅샷 이후 변경된 데이터만을 포함합니다. 각 파일 공유마다 최대 200개의 스냅샷을 보유하고 최대 10년 동안 유지할 수 있습니다. PowerShell 또는 CLI(명령줄 인터페이스)를 통해 Azure Portal에서 수동으로 스냅샷을 만들거나 Azure Backup을 사용할 수 있습니다.

Azure 파일 공유에 대한 Azure Backup은 스냅샷 예약과 보존에 대해 다룹니다. GFS(grandfather-father-son) 기능을 사용하는 경우 매일, 매주, 매월, 매년 스냅샷을 만들 수 있으며 각각 고유한 보존 기간이 설정됩니다. 또한 Azure Backup은 일시 삭제의 사용을 가능하게 조직하고 스토리지 계정 내의 파일 공유가 백업에 구성되는 즉시 스토리지 계정에 삭제 잠금을 수행합니다. 마지막으로, Azure Backup은 고객이 백업 공간을 통합하여 볼 수 있도록 특정 키 모니터링과 경고 기능을 제공합니다.

Azure Backup을 사용해 Azure Portal에서 항목 수준과 공유 수준 복원을 모두 수행할 수 있습니다. 복원 지점(특정 스냅샷), 특정 파일 또는 디렉터리(관련된 경우) 및 복원하려는 위치(원래 위치나 대체 위치)를 선택하기만 하면 됩니다. 백업 서비스는 스냅샷 데이터 복사를 처리하고 포털의 복원 진행률을 보여줍니다.

Microsoft Defender for Storage를 사용하여 Azure Files 보호

스토리지용 Microsoft Defender는 스토리지 정에 대한 잠재적 위협을 탐지하는 Azure 네이티브 보안 인텔리전스 계층입니다. Azure Files가 생성한 데이터 평면 및 컨트롤 플레인 원격 분석을 분석하여 포괄적인 보안을 제공합니다. Microsoft 위협 인텔리전스에서 제공하는 고급 위협 탐지 기능을 사용하여 탐지된 위협을 완화하고 향후 공격을 방지하는 단계를 포함하여 상황에 맞는 보안 경고를 제공합니다.

스토리지용 Defender는 Azure Files에서 생성한 원격 분석 스트림을 지속적으로 분석합니다. 잠재적으로 악의적인 활동이 감지되면 보안 경고가 생성됩니다. 이러한 경고는 조사 단계, 수정 작업 및 보안 권장 사항과 함께 의심스러운 작업에 대한 세부 정보와 함께 클라우드용 Microsoft Defender에 표시됩니다.

스토리지용 Defender는 전체 파일 해시(REST API에만 지원됨)를 기반으로 스토리지 계정에 업로드된 랜섬웨어, 바이러스, 스파이웨어 및 기타 맬웨어 등의 알려진 맬웨어를 검색합니다. 이렇게 하면 맬웨어가 조직에 침입하여 더 많은 사용자와 리소스에 확산되는 것을 방지할 수 있습니다. 맬웨어 검사와 해시 평판 분석의 차이점 이해를 참조하세요.

스토리지용 Defender는 Storage 계정 데이터에 액세스하지 않으며 성능에 영향을 주지 않습니다. 스토리지용 Microsoft Defender는 구독 수준(권장됨) 또는 리소스 수준에서 사용하도록 설정할 수 있습니다.

스토리지 계층

Azure Files는 SSD(반도체 디스크) 및 HDD(하드 디스크 드라이브)의 두 가지 미디어 계층을 제공하므로 시나리오의 성능 및 가격 요구 사항에 맞게 공유를 조정할 수 있습니다.

• SSD(프리미엄): SSD 파일 공유는 IO 집약적 워크로드에 대해 대부분의 IO 작업에 대해 한 자리 밀리초 내에 일관된 고성능 및 짧은 대기 시간을 제공합니다. SSD 파일 공유는 데이터베이스, 웹 사이트 호스팅 및 개발 환경과 같은 다양한 워크로드에 적합합니다. SSD 파일 공유는 SMB(서버 메시지 블록) 및 NFS(네트워크 파일 시스템) 프로토콜 모두에서 사용할 수 있습니다. SSD 파일 공유는 프로비전된 v1 청구 모델에서 사용할 수 있습니다. SSD 파일 공유는 HDD 파일 공유보다 더 높은 가용성 SLA 를 제공합니다("Azure Files 프리미엄 계층" 참조).

• HDD(표준): HDD 파일 공유는 범용 파일 공유에 대한 비용 효율적인 스토리지 옵션을 제공합니다. 프로비전된 v2 및 종량제 청구 모델에서 사용할 수 있는 HDD 파일 공유는 새 파일 공유 배포에 프로비전된 v2 모델을 권장합니다. SLA에 대한 자세한 내용은 Azure 서비스 수준 계약 페이지("스토리지 계정" 참조)를 참조하세요.

워크로드에 대한 미디어 계층을 선택할 때 성능 및 사용 요구 사항을 고려합니다. 워크로드에 한 자릿수 대기 시간이 필요하거나 온-프레미스에서 SSD 스토리지 미디어를 사용하는 경우 SSD 파일 공유 계층이 가장 적합할 수 있습니다. 대기 시간이 짧을 경우(예: Azure에서 온-프레미스에 탑재된 팀 공유 또는 Azure 파일 동기화 사용하여 온-프레미스에 캐시된 팀 공유) 비용 관점에서 HDD 파일 공유가 더 적합할 수 있습니다.

스토리지 계정에서 파일 공유를 만든 후에는 다른 미디어 계층으로 직접 이동할 수 없습니다. 예를 들어 HDD 파일 공유를 SSD 미디어 계층으로 이동하려면 새 SSD 파일 공유를 만들고 원래 공유의 데이터를 FileStorage 계정의 새 파일 공유로 복사해야 합니다. AzCopy를 사용하여 Azure 파일 공유 간에 데이터를 복사하는 것이 좋지만, Windows용 robocopy 또는 macOS 및 Linux용 rsync와 같은 도구를 사용할 수도 있습니다.

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

중복

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로 청구됩니다.

중복성에 대한 자세한 내용은 Azure Files 데이터 중복을 참조하세요.

표준 ZRS 가용성

표준 범용 v2 스토리지 계정에 대한 ZRS는 Azure 지역의 하위 집합에 사용할 수 있습니다.

프리미엄 ZRS 가용성

프리미엄 파일 공유에 대한 ZRS는 Azure 지역의 하위 집합에 사용할 수 있습니다.

표준 GZRS 가용성

GZRS는 Azure 지역의 하위 집합에 사용할 수 있습니다.

재해 복구 및 장애 조치(Failover)

계획되지 않은 지역 서비스 중단의 경우 Azure 파일 공유에 대한 DR(재해 복구) 계획이 있어야 합니다. DR 및 스토리지 계정 장애 조치(failover)와 관련된 개념 및 프로세스를 이해하려면 Azure Files 재해 복구 및 장애 조치(failover)를 참조하세요.

마이그레이션

대부분의 경우에는 조직에 net 새 파일 공유를 설정하지 않고 대신 기존 파일 공유를 온-프레미스 파일 서버 또는 NAS 디바이스에서 Azure Files로 마이그레이션합니다. 마이그레이션을 성공적으로 수행하려면 시나리오에 적합한 마이그레이션 전략과 도구를 선택하는 것이 중요합니다.

마이그레이션 개요 문서에서는 기본 사항에 대해 간략하게 설명하고 시나리오를 다루는 마이그레이션 지침을 안내하는 표를 볼 수 있습니다.

다음 단계

• Azure 파일 동기화 배포에 대한 계획
• Azure Files 배포
• Azure 파일 동기화 배포
• 시나리오에 대한 마이그레이션 지침을 찾으려면 마이그레이션 개요 문서를 확인하세요.