Azure NetApp Files 네트워크 계획 지침
네트워크 아키텍처 계획은 모든 애플리케이션 인프라 설계의 핵심 요소입니다. 이 문서는 Azure NetApp Files의 다양한 기능을 활용하기 위해 워크로드에 대한 효과적인 네트워크 아키텍처를 설계하는 데 도움이 됩니다.
Azure NetApp Files 볼륨은 Microsoft Azure Virtual Network 내에서 위임된 서브넷이라는 특수 용도의 서브넷에 포함되도록 설계되었습니다. 따라서 VNet(가상 네트워크) 피어링을 통해 Azure 내에서 또는 Virtual Network 게이트웨이(ExpressRoute 또는 VPN Gateway)를 통해 온-프레미스에서 직접 볼륨에 액세스할 수 있습니다. 서브넷은 Azure NetApp Files 전용이며 인터넷에 연결되지 않습니다.
새 볼륨에 표준 네트워크 기능을 설정하고 기존 볼륨의 네트워크 기능을 수정하는 옵션은 모든 Azure NetApp Files 지원 지역에서 지원됩니다.
구성 가능한 네트워크 기능
지원되는 지역에서는 새 볼륨을 만들거나 기존 볼륨을 수정하여 표준 또는 기본 네트워크 기능을 사용할 수 있습니다. 표준 네트워크 기능이 지원되지 않는 지역에서는 기본적으로 볼륨에서 기본 네트워크 기능을 사용하도록 설정됩니다. 자세한 내용은 네트워크 기능 구성을 참조하세요.
Standard
이 설정을 선택하면 위임된 서브넷의 네트워크 보안 그룹 및 사용자 정의 경로와 같은 더 높은 IP 제한 및 표준 VNet 기능과 이 문서에 표시된 추가 연결 패턴을 사용할 수 있습니다.기본
이 설정을 선택하면 고려 사항 섹션에서 설명한 대로 선택적인 연결 패턴과 제한된 IP 크기 조정을 사용할 수 있습니다. 이 설정에는 모든 제약 조건이 적용됩니다.
고려 사항
Azure NetApp Files 네트워크를 계획하는 경우 몇 가지 고려 사항을 잘 알고 있어야 합니다.
제약 조건
다음 표에는 각 네트워크 기능 구성에 대해 지원되는 항목이 설명되어 있습니다.
| 기능 | 표준 네트워크 기능 | 기본 네트워크 기능 |
|---|---|---|
| VNet을 호스팅하는 Azure NetApp Files의 볼륨에 액세스하는 VNet(즉시 피어링된 VNet 포함)의 IP 수 | VM(가상 머신)과 동일한 표준 제한 | 1000 |
| VNet당 Azure NetApp Files 위임된 서브넷 | 1 | 1 |
| Azure NetApp Files 위임된 서브넷의 NSG(네트워크 보안 그룹) | 예 | 아니요 |
| Azure NetApp Files 위임된 서브넷의 UDR(사용자 정의 경로) | 예 | 아니요 |
| 프라이빗 엔드포인트에 대한 연결 | 예* | 아니요 |
| 서비스 엔드포인트에 대한 연결 | 예 | 아니요 |
| Azure NetApp Files 인터페이스의 Azure 정책(예: 사용자 지정 명명 정책) | 아니요 | 아니요 |
| Azure NetApp Files 트래픽의 부하 분산 장치 | 아니요 | 아니요 |
| 이중 스택(IPv4 및 IPv6) VNet | 아님 (IPv4만 지원) |
아님 (IPv4만 지원) |
| 피어된 VNet에서 NVA를 통해 라우팅된 트래픽 | 예 | 아니요 |
* 프라이빗 링크 서브넷의 Azure 네트워크 보안 그룹을 Azure Key Vault에 적용하는 것은 Azure NetApp Files 고객 관리형 키에서 지원되지 않습니다. 네트워크 보안 그룹은 서브넷에서 프라이빗 엔드포인트 네트워크 정책을 사용하도록 설정하지 않는 한, Private Link 연결에 영향을 주지 않습니다. 이 옵션을 사용하지 않도록 유지하는 것이 좋습니다.
지원되는 네트워크 토폴로지
다음 표에서는 Azure NetApp Files의 각 네트워크 기능 구성에서 지원하는 네트워크 토폴로지를 설명합니다.
| 토폴로지 | 표준 네트워크 기능 | 기본 네트워크 기능 |
|---|---|---|
| 로컬 VNet의 볼륨에 연결 | 예 | 예 |
| 피어링된 VNet의 볼륨에 연결(동일한 지역) | 예 | 예 |
| 피어링된 VNet의 볼륨에 대한 연결(지역 간 또는 글로벌 피어링) | 예* | 아니요 |
| ExpressRoute 게이트웨이를 통해 볼륨에 연결 | 예 | 예 |
| ER(ExpressRoute) FastPath | 예 | 아니요 |
| ExpressRoute 게이트웨이를 통한 온-프레미스에서 스포크 VNet의 볼륨으로의 연결 및 게이트웨이 전송을 통한 VNet 피어링 | 예 | 예 |
| VPN 게이트웨이를 통한 온-프레미스에서 스포크 VNet의 볼륨으로의 연결 | 예 | 예 |
| VPN 게이트웨이를 통한 온-프레미스에서 스포크 VNet의 볼륨으로의 연결 및 게이트웨이 전송을 통한 VNet 피어링 | 예 | 예 |
| 활성/수동 VPN 게이트웨이를 통한 연결 | 예 | 예 |
| 활성/활성 VPN 게이트웨이를 통한 연결 | 예 | 아니요 |
| 활성/활성 영역 중복 게이트웨이를 통한 연결 | 예 | 아니요 |
| 활성/수동 영역 중복 게이트웨이를 통한 연결 | 예 | 예 |
| VWAN(Virtual WAN)을 통한 연결 | 예 | 아니요 |
* 이 옵션의 경우 가상 네트워크 피어링 연결을 사용하는 수신 및 송신 트래픽에 대한 요금이 발생합니다. 자세한 내용은 가상 네트워크 가격 책정을 참조하세요. 일반적인 추가 정보는 가상 네트워크 피어링을 참조하세요.
Azure NetApp Files 볼륨용 가상 네트워크
이 섹션에서는 가상 네트워크를 계획하는 데 도움이 되는 개념을 설명합니다.
Azure 가상 네트워크
Azure NetApp Files 볼륨을 프로비전하기 전에 Azure VNet(가상 네트워크)을 만들거나 동일한 구독에 이미 있는 VNet을 사용해야 합니다. VNet은 볼륨의 네트워크 경계를 정의합니다. 가상 네트워크를 만들기에 대한 자세한 내용은 Microsoft Azure Virtual Network 설명서를 참조하세요.
서브넷
서브넷은 그 안의 Azure 리소스가 사용할 수 있는 개별 주소 공간으로 가상 네트워크를 구분합니다. Azure NetApp Files 볼륨은 위임된 서브넷이라는 특수 용도의 서브넷에 포함되어 있습니다.
서브넷 위임은 서브넷에서 서비스 관련 리소스를 만들 수 있는 명시적 권한을 Azure NetApp Files 서비스에 부여합니다. 서비스를 배포하는 데 고유한 식별자가 사용됩니다. 이 경우 Azure NetApp Files에 연결할 수 있도록 네트워크 인터페이스가 만들어집니다.
새 VNet을 사용하는 경우 Azure NetApp Files에 서브넷 위임의 지침에 따라 서브넷을 만들고 Azure NetApp Files에 위임할 수 있습니다. 다른 서비스에 위임되지 않은 기존의 빈 서브넷을 위임할 수도 있습니다.
VNet이 다른 VNet과 피어링되는 경우 VNet 주소 공간을 확장할 수 없습니다. 이러한 이유로 VNet 주소 공간 내에 위임된 서브넷을 새로 만들어야 합니다. 주소 공간을 확장해야 하는 경우 먼저 VNet 피어링을 삭제해야 합니다.
Important
Azure NetApp Files VNet의 주소 공간 크기가 위임된 서브넷보다 큰지 확인합니다.
예를 들어 위임된 서브넷이 /24인 경우 서브넷을 포함하는 VNet 주소 공간은 /23 이상이어야 합니다. 이 지침을 준수하지 않으면 일부 트래픽 패턴에서 예기치 않은 문제가 발생할 수 있습니다. 네트워크 가상 어플라이언스를 통해 Azure NetApp Files에 도달하는 허브 및 스포크 토폴로지를 통과하는 트래픽이 제대로 작동하지 않습니다. 또한 허브 및 스포크 네트워크 토폴로지를 통해 DNS에 도달하려고 하면 SMB 및 CIFS(일반 인터넷 파일 시스템) 볼륨을 만들 때 이 구성이 실패할 수 있습니다.
또한 위임된 서브넷의 크기는 SAP 워크로드의 경우 /25 이상, 다른 워크로드 시나리오의 경우 /26 이상이어야 합니다.
UDR(사용자 정의 경로) 및 NSG(네트워크 보안 그룹)
서브넷에 표준 및 기본 네트워크 기능이 있는 볼륨 조합이 있는 경우 위임된 서브넷에 적용된 UDR(사용자 정의 경로) 및 NSG(네트워크 보안 그룹)는 표준 네트워크 기능이 있는 볼륨에만 적용됩니다.
참고 항목
네트워크 인터페이스 수준의 NSG 연결은 Azure NetApp Files 네트워크 인터페이스에서 지원되지 않습니다.
NVA로 위임된 서브넷 및 다음 홉의 주소 접두사를 사용하여 원본 VM 서브넷에서 UDR을 구성하는 것은 기본 네트워크 기능이 있는 볼륨에 대해 지원되지 않습니다. 이러한 설정으로 인해 연결 문제가 발생합니다.
참고 항목
VNet 게이트웨이(ExpressRoute 또는 VPN) 및 방화벽을 통해 온-프레미스 네트워크에서 Azure NetApp Files 볼륨에 액세스하려면 나열된 Azure NetApp Files 볼륨의 /32 IPv4 주소를 포함하고 방화벽을 다음 홉으로 가리키도록 VNet 게이트웨이에 할당된 경로 테이블을 구성합니다. Azure NetApp Files 볼륨 IP 주소를 포함하는 집계 주소 공간을 사용하면 Azure NetApp Files 트래픽이 방화벽으로 전달되지 않습니다.
참고 항목
VM VNet에서 UDR 경로를 구성하여 지역적으로 VNet 피어링된 Azure NetApp Files 표준 볼륨을 대상으로 하는 패킷의 라우팅을 제어하려면 UDR 접두사는 Azure NetApp Files 볼륨의 위임된 서브넷 크기와 더 구체적이거나 같아야 합니다. UDR 접두사 크기가 위임된 서브넷 크기보다 크면 유효하지 않습니다.
Azure 네이티브 환경
다음 다이어그램에서는 Azure 네이티브 환경을 보여줍니다.
로컬 VNet
기본 시나리오는 동일한 VNet의 VM에서 Azure NetApp Files 볼륨을 만들거나 연결하는 것입니다. 위의 다이어그램에서 VNet 2의 경우 볼륨 1은 위임된 서브넷에 만들어지고 기본 서브넷의 VM 1에 탑재될 수 있습니다.
VNet 피어링
서로의 리소스에 액세스해야 하는 다른 VNet이 동일한 지역에 있는 경우 VNet 피어링을 통해 VNet을 연결하여 Azure 인프라를 통해 보안 연결을 사용하도록 설정할 수 있습니다.
위의 다이어그램에서 VNet 2와 VNet 3을 고려합니다. VM 1이 VM 2 또는 볼륨 2에 연결해야 하거나 VM 2가 VM 1 또는 볼륨 1에 연결해야 하는 경우 VNet 2와 VNet 3 간에 VNet 피어링을 사용하도록 설정해야 합니다.
또한 동일한 지역에서 VNet 1이 VNet 2와 피어링되고, VNet 2가 VNet 3과 피어링되는 시나리오를 고려합니다. VNet 1의 리소스는 VNet 2의 리소스에 연결할 수 있지만, VNet 1과 VNet 3이 피어링되지 않는 한 VNet 3의 리소스에 연결할 수 없습니다.
위의 다이어그램에서 VM 3은 볼륨 1에 연결할 수 있지만, VM 4는 볼륨 2에 연결할 수 없습니다. 이는 스포크 VNet이 피어링되지 않고 VNet 피어링을 통해 전송 라우팅이 지원되지 않기 때문입니다.
글로벌 또는 지역 간 VNet 피어링
다음 다이어그램에서는 지역 간 VNet 피어링을 사용하는 Azure 네이티브 환경을 보여 줍니다.
표준 네트워크 기능을 사용하면 VM이 글로벌 또는 지역 간 VNet 피어링을 통해 다른 지역의 볼륨에 연결할 수 있습니다. 위의 다이어그램에서는 두 번째 지역을 로컬 VNet 피어링 섹션의 구성에 추가합니다. 이 다이어그램에서 VNet 4의 경우 Azure NetApp Files 볼륨이 위임된 서브넷에 만들어지고 애플리케이션 서브넷의 VM5에 탑재될 수 있습니다.
다이어그램에서 지역 1의 VM2는 지역 2의 볼륨 3에 연결할 수 있습니다. 지역 2의 VM5는 지역 1과 지역 2 사이의 VNet 피어링을 통해 지역 1의 볼륨 2에 연결할 수 있습니다.
하이브리드 환경
다음 다이어그램에서는 하이브리드 환경을 보여줍니다.
하이브리드 시나리오에서 온-프레미스 데이터 센터의 애플리케이션은 Azure의 리소스에 액세스해야 합니다. 이는 데이터 센터를 Azure로 확장하거나 Azure 네이티브 서비스를 사용하거나 재해 복구에 사용하려는 경우입니다. 사이트 간 VPN 또는 ExpressRoute를 통해 온-프레미스의 여러 리소스를 Azure의 리소스에 연 하는 방법에 대한 자세한 내용은 VPN Gateway 계획 옵션을 참조하세요.
하이브리드 허브-스포크 토폴로지에서 Azure의 허브 VNet은 온-프레미스 네트워크에 대한 연결의 중심점 역할을 합니다. 스포크는 허브와 피어링되는 VNet이며 워크로드를 격리하는 데 사용할 수 있습니다.
구성에 따라 허브 및 스포크의 리소스에 온-프레미스 리소스를 연결할 수 있습니다.
위에 나와 있는 토폴로지에서 온-프레미스 네트워크는 Azure의 허브 VNet에 연결되어 있으며 허브 VNet과 피어링되는 동일한 지역의 스포크 VNet이 2개 있습니다. 이 시나리오에서 Azure NetApp Files 볼륨에 대해 지원되는 연결 옵션은 다음과 같습니다.
- 온-프레미스 리소스 VM 1과 VM 2는 사이트 간 VPN 또는 ExpressRoute 회로를 통해 허브의 볼륨 1에 연결할 수 있습니다.
- VM 1 및 VM 2 온-프레미스 리소스는 사이트 간 VPN 및 지역 VNet 피어링을 통해 볼륨 2 또는 볼륨 3에 연결할 수 있습니다.
- 허브 VNet의 VM 3은 스포크 VNet 1의 볼륨 2와 스포크 VNet 2의 볼륨 3에 연결할 수 있습니다.
- 스포크 VNet 1의 VM 4와 스포크 VNet 2의 VM 5는 허브 VNet의 볼륨 1에 연결할 수 있습니다.
- 스포크 VNet 1의 VM 4는 스포크 VNet 2의 볼륨 3에 연결할 수 없습니다. 또한 스포크 VNet2의 VM 5는 스포크 VNet 1의 볼륨 2에 연결할 수 없습니다. 이는 스포크 VNet이 피어링되지 않고 VNet 피어링을 통해 전송 라우팅이 지원되지 않기 때문입니다.
- 위의 아키텍처에서 게이트웨이가 스포크 VNet에도 있는 경우 허브의 게이트웨이를 통해 연결하는 온-프레미스에서 ANF 볼륨에 대한 연결이 끊어집니다. 설계상 스포크 VNet의 게이트웨이가 우선하므로 해당 게이트웨이를 통해 연결하는 머신만 ANF 볼륨에 연결할 수 있습니다.