Azure Stack HCI 버전 23H2의 클라우드 배포에 대한 네트워크 고려 사항
적용 대상: Azure Stack HCI, 버전 23H2
이 문서에서는 클라우드 배포를 위한 Azure Stack HCI 버전 23H2 시스템 네트워크를 설계하고 계획하는 방법을 설명합니다. 계속하기 전에 다양한 Azure Stack HCI 네트워킹 패턴 및 사용 가능한 구성을 숙지하세요.
네트워크 디자인 프레임워크
다음 다이어그램에서는 클러스터 크기, 클러스터 스토리지 연결, 네트워크 트래픽 의도, 관리 연결 및 네트워크 어댑터 구성 등 Azure Stack HCI 시스템에 대한 네트워크 디자인 프레임워크를 정의하는 다양한 결정 및 단계를 보여 줍니다. 각 디자인 결정은 다음 단계에서 사용할 수 있는 디자인 옵션을 사용하거나 허용합니다.
1단계: 클러스터 크기 결정
Azure Stack HCI 시스템의 크기를 확인하려면 Azure Stack HCI 크기 도구를 사용하여 VM(가상 머신) 수, VM 크기 및 Azure Virtual Desktop, SQL Server 또는 AKS와 같은 VM의 워크로드 사용과 같은 프로필을 정의할 수 있습니다.
Azure Stack HCI 시스템 서버 요구 사항 문서에 설명된 대로 Azure Stack HCI 시스템에서 지원되는 최대 서버 수는 16개입니다. 워크로드 용량 계획을 완료하면 인프라에서 워크로드를 실행하는 데 필요한 서버 노드 수를 잘 이해해야 합니다.
워크로드에 4개 이상의 노드가 필요한 경우: 스토리지 네트워크 트래픽에 스위치리스 구성을 배포하고 사용할 수 없습니다. 스토리지 트래픽을 처리하려면 RDMA(원격 직접 메모리 액세스)를 지원하는 물리적 스위치를 포함해야 합니다. Azure Stack HCI 클러스터 네트워크 아키텍처에 대한 자세한 내용은 네트워크 참조 패턴 개요를 참조하세요.
워크로드에 3개 이하의 노드가 필요한 경우: 스토리지 연결에 대한 스위치리스 또는 전환된 구성을 선택할 수 있습니다.
나중에 3개 이상의 노드로 확장하려는 경우 스토리지 네트워크 트래픽에 실제 스위치를 사용해야 합니다. 스위치리스 배포에 대한 스케일 아웃 작업을 수행하려면 Microsoft가 Azure Stack HCI에 대한 소프트웨어 개발 주기의 일부로 적극적으로 유효성을 검사하지 않는 노드 간에 네트워크 케이블을 수동으로 구성해야 합니다.
클러스터 크기 결정에 대한 요약된 고려 사항은 다음과 같습니다.
| 의사 결정 | 고려 사항 |
|---|---|
| 클러스터 크기(클러스터당 노드 수) | Azure Portal 또는 Azure Resource Manager 템플릿을 통한 스위치리스 구성은 노드 클러스터 1개, 2개 또는 3개에서만 사용할 수 있습니다. 노드가 4개 이상인 클러스터에는 스토리지 네트워크 트래픽에 대한 물리적 스위치가 필요합니다. |
| 요구 사항 확장 | 오케스트레이터를 사용하여 클러스터를 확장하려는 경우 스토리지 네트워크 트래픽에 실제 스위치를 사용해야 합니다. |
2단계: 클러스터 스토리지 연결 확인
물리적 네트워크 요구 사항에 설명된 대로 Azure Stack HCI는 스토리지 네트워크 트래픽에 대한 두 가지 유형의 연결을 지원합니다.
- 실제 네트워크 스위치를 사용하여 트래픽을 처리합니다.
- 스토리지 트래픽에 대한 크로스오버 네트워크 또는 파이버 케이블을 사용하여 노드 간 노드를 직접 연결합니다.
각 옵션의 장점과 단점은 위에 연결된 문서에 설명되어 있습니다.
앞에서 설명한 것처럼 클러스터의 크기가 3개 이하의 노드인 경우에만 두 옵션 중에서 결정할 수 있습니다. 4개 이상의 노드가 있는 모든 클러스터는 스토리지에 대한 네트워크 스위치를 사용하여 자동으로 배포됩니다.
클러스터에 노드가 3개 미만인 경우 스토리지 연결 결정은 다음 단계에서 정의할 수 있는 네트워크 의도의 수와 유형에 영향을 줍니다.
예를 들어 스위치리스 구성의 경우 두 개의 네트워크 트래픽 의도를 정의해야 합니다. 크로스오버 케이블을 사용하는 동서 통신의 스토리지 트래픽은 남북 연결이 없으며 네트워크 인프라의 나머지 부분과 완전히 격리됩니다. 즉, 관리 아웃바운드 연결 및 컴퓨팅 워크로드에 대한 두 번째 네트워크 의도를 정의해야 합니다.
각 실제 네트워크 어댑터 포트를 하나만 사용하여 각 네트워크 의도를 정의할 수 있지만 내결함성을 제공하지는 않습니다. 따라서 각 네트워크 의도에 대해 항상 두 개 이상의 실제 네트워크 포트를 사용하는 것이 좋습니다. 스토리지에 네트워크 스위치를 사용하기로 결정한 경우 단일 네트워크 의도에서 스토리지를 포함한 모든 네트워크 트래픽을 그룹화할 수 있습니다. 이를 하이퍼컨버지드 또는 완전히 수렴된 호스트 네트워크 구성이라고도 합니다.
클러스터 스토리지 연결 결정에 대한 요약된 고려 사항은 다음과 같습니다.
| 의사 결정 | 고려 사항 |
|---|---|
| 스토리지 스위치 없음 | Azure Portal 또는 Resource Manager 템플릿 배포를 통한 스위치리스 구성은 노드 클러스터 1개, 2개 또는 3개에서만 지원됩니다. Azure Portal 또는 Resource Manager 템플릿을 사용하여 1개 또는 2개의 노드 스토리지 스위치리스 클러스터를 배포할 수 있습니다. Resource Manager 템플릿을 사용하여 3개의 노드 스토리지 스위치리스 클러스터를 배포할 수 있습니다. 스케일 아웃 작업은 스위치리스 배포에서 지원되지 않습니다. 배포 후 노드 수를 변경하려면 수동 구성이 필요합니다. 스토리지 스위치리스 구성을 사용하는 경우 네트워크 의도가 2개 이상 필요합니다. |
| 스토리지에 대한 네트워크 스위치 | 오케스트레이터를 사용하여 클러스터를 확장하려는 경우 스토리지 네트워크 트래픽에 실제 스위치를 사용해야 합니다. 1에서 16 사이의 노드 수와 함께 이 아키텍처를 사용할 수 있습니다. 적용되지는 않지만 모든 네트워크 트래픽 유형(관리, 컴퓨팅 및 스토리지)에 단일 의도를 사용할 수 있습니다. |
다음 다이어그램에서는 다양한 배포에 사용할 수 있는 스토리지 연결 옵션을 요약합니다.
3단계: 네트워크 트래픽 의도 확인
Azure Stack HCI의 경우 모든 배포는 호스트 네트워크 구성에 네트워크 ATC를 사용합니다. 네트워크 의도는 Azure Portal을 통해 Azure Stack HCI를 배포할 때 자동으로 구성됩니다. 네트워크 의도 및 문제를 해결하는 방법에 대한 자세한 내용은 공통 네트워크 ATC 명령을 참조 하세요.
이 섹션에서는 네트워크 트래픽 의도에 대한 디자인 결정의 의미와 프레임워크의 다음 단계에 미치는 영향을 설명합니다. 클라우드 배포의 경우 네트워크 트래픽을 하나 이상의 의도로 그룹화하기 위한 네 가지 옵션 중에서 선택할 수 있습니다. 사용 가능한 옵션은 클러스터의 노드 수와 사용된 스토리지 연결 유형에 따라 달라집니다.
사용 가능한 네트워크 의도 옵션은 다음 섹션에서 설명합니다.
네트워크 의도: 모든 트래픽 그룹화
네트워크 ATC는 관리, 컴퓨팅 및 스토리지 네트워크 트래픽을 포함하는 고유한 의도를 구성합니다. 이 의도에 할당된 네트워크 어댑터는 모든 네트워크 트래픽에 대한 대역폭 및 처리량을 공유합니다.
이 옵션을 사용하려면 스토리지 트래픽에 대한 물리적 스위치가 필요합니다. 스위치리스 아키텍처가 필요한 경우 이러한 유형의 의도를 사용할 수 없습니다. 스토리지 연결에 대한 스위치리스 구성을 선택하면 Azure Portal에서 이 옵션을 자동으로 필터링합니다.
고가용성을 보장하려면 네트워크 어댑터 포트를 두 개 이상 사용하는 것이 좋습니다.
스토리지에 대한 RDMA 트래픽을 지원하려면 10Gbps 이상의 네트워크 인터페이스가 필요합니다.
네트워크 의도: 그룹 관리 및 컴퓨팅 트래픽
네트워크 ATC는 두 가지 의도를 구성합니다. 첫 번째 의도에는 관리 및 컴퓨팅 네트워크 트래픽이 포함되고 두 번째 의도에는 스토리지 네트워크 트래픽만 포함됩니다. 각 의도에는 다른 네트워크 어댑터 포트 집합이 있어야 합니다.
다음과 같은 경우 전환된 스토리지 연결과 스위치리스 스토리지 연결 모두에 이 옵션을 사용할 수 있습니다.
고가용성을 보장하기 위해 각 의도에 대해 두 개 이상의 네트워크 어댑터 포트를 사용할 수 있습니다.
스토리지에 네트워크 스위치를 사용하는 경우 RDMA에 실제 스위치가 사용됩니다.
스토리지에 대한 RDMA 트래픽을 지원하려면 10Gbps 이상의 네트워크 인터페이스가 필요합니다.
네트워크 의도: 컴퓨팅 및 스토리지 트래픽 그룹화
네트워크 ATC는 두 가지 의도를 구성합니다. 첫 번째 의도에는 컴퓨팅 및 스토리지 네트워크 트래픽이 포함되고 두 번째 의도에는 관리 네트워크 트래픽만 포함됩니다. 각 의도는 다른 네트워크 어댑터 포트 집합을 사용해야 합니다.
이 옵션을 사용하려면 동일한 포트가 컴퓨팅 트래픽과 공유되기 때문에 스토리지 트래픽에 대한 물리적 스위치가 필요하며, 여기에는 남북 통신이 필요합니다. 스위치 없는 구성이 필요한 경우 이 유형의 의도를 사용할 수 없습니다. 스토리지 연결에 대한 스위치리스 구성을 선택하면 Azure Portal에서 이 옵션을 자동으로 필터링합니다.
이 옵션을 사용하려면 RDMA에 대한 물리적 스위치가 필요합니다.
고가용성을 보장하려면 네트워크 어댑터 포트를 두 개 이상 사용하는 것이 좋습니다.
RDMA 트래픽을 지원하기 위해 컴퓨팅 및 스토리지 의도에 10Gbps 이상의 네트워크 인터페이스를 사용하는 것이 좋습니다.
관리 의도가 컴퓨팅 의도 없이 선언된 경우에도 네트워크 ATC는 SET(Switch Embedded Teaming) 가상 스위치를 만들어 관리 네트워크에 고가용성을 제공합니다.
네트워크 의도: 사용자 지정 구성
하나 이상의 의도에 관리 트래픽이 포함되는 한 사용자 고유의 구성을 사용하여 최대 3개의 의도를 정의합니다. 두 번째 컴퓨팅 의도가 필요한 경우 이 옵션을 사용하는 것이 좋습니다. 이 두 번째 컴퓨팅 의도 요구 사항에 대한 시나리오에는 원격 스토리지 트래픽, VM 백업 트래픽 또는 고유한 유형의 워크로드에 대한 별도의 컴퓨팅 의도가 포함됩니다.
스토리지 의도가 다른 의도와 다른 경우 전환된 스토리지 연결과 스위치리스 스토리지 연결 모두에 이 옵션을 사용합니다.
다른 컴퓨팅 의도가 필요하거나 다른 네트워크 어댑터를 통해 고유한 유형의 트래픽을 완전히 분리하려는 경우 이 옵션을 사용합니다.
고가용성을 보장하려면 각 의도에 대해 두 개 이상의 네트워크 어댑터 포트를 사용합니다.
RDMA 트래픽을 지원하기 위해 컴퓨팅 및 스토리지 의도에 10Gbps 이상의 네트워크 인터페이스를 사용하는 것이 좋습니다.
다음 다이어그램에서는 다양한 배포에 사용할 수 있는 네트워크 의도 옵션을 요약합니다.
4단계: 관리 및 스토리지 네트워크 연결 확인
이 단계에서는 인프라 서브넷 주소 공간, 이러한 주소가 클러스터에 할당되는 방법 및 인터넷에 대한 아웃바운드 연결을 위한 노드 및 DNS(도메인 이름 시스템) 또는 Active Directory Services와 같은 기타 인트라넷 서비스에 대한 프록시 또는 VLAN ID 요구 사항이 있는 경우 정의합니다.
라우팅, 방화벽 또는 서브넷 요구 사항을 예상할 수 있도록 배포를 시작하기 전에 다음 인프라 서브넷 구성 요소를 계획하고 정의해야 합니다.
네트워크 어댑터 드라이버
운영 체제를 설치하고 노드에서 네트워킹을 구성하기 전에 네트워크 어댑터에 OEM 또는 네트워크 인터페이스 공급업체에서 제공하는 최신 드라이버가 있는지 확인해야 합니다. 기본 Microsoft 드라이버를 사용할 때 네트워크 어댑터의 중요한 기능이 표시되지 않을 수 있습니다.
관리 IP 풀
Azure Stack HCI 시스템의 초기 배포를 수행하는 경우 기본적으로 배포되는 인프라 서비스에 대한 연속 IP의 IP 범위를 정의해야 합니다.
범위가 현재 및 미래의 인프라 서비스에 충분한 IP를 갖도록 하려면 6개 이상의 연속 사용 가능한 IP 주소 범위를 사용해야 합니다. 이러한 주소는 클러스터 IP, Azure Resource Bridge VM 및 해당 구성 요소에 사용됩니다.
인프라 네트워크에서 다른 서비스를 실행할 것으로 예상되는 경우 풀에 인프라 IP의 추가 버퍼를 할당하는 것이 좋습니다. 원래 계획한 풀의 크기가 소진된 경우 PowerShell을 사용하여 인프라 네트워크에 배포한 후 다른 IP 풀을 추가할 수 있습니다.
배포하는 동안 인프라 서브넷에 대한 IP 풀을 정의할 때는 다음 조건을 충족해야 합니다.
| # | 조건 |
|---|---|
| 1 | IP 범위는 연속 IP를 사용해야 하며 해당 범위 내에서 모든 IP를 사용할 수 있어야 합니다. 이 IP 범위는 배포 후 변경할 수 없습니다. |
| 2 | IP 범위는 클러스터 노드 관리 IP를 포함하지 않아야 하지만 노드와 동일한 서브넷에 있어야 합니다. |
| 3 | 관리 IP 풀에 대해 정의된 기본 게이트웨이는 인터넷에 대한 아웃바운드 연결을 제공해야 합니다. |
| 4 | DNS 서버는 Active Directory 및 인터넷을 사용하여 이름 확인을 확인해야 합니다. |
| 5 | 관리 IP에는 아웃바운드 인터넷 액세스가 필요합니다. |
관리 VLAN ID
Azure HCI 클러스터의 관리 서브넷은 대부분의 경우 VLAN ID 0으로 선언되는 기본 VLAN을 사용하는 것이 좋습니다. 그러나 네트워크 요구 사항이 인프라 네트워크에 특정 관리 VLAN을 사용하는 경우 관리 트래픽에 사용하려는 실제 네트워크 어댑터에서 구성해야 합니다.
관리에 두 개의 실제 네트워크 어댑터를 사용하려는 경우 두 어댑터에서 VLAN을 설정해야 합니다. 이 작업은 서버의 부트스트랩 구성의 일부로 수행되어야 하며 Azure Arc에 등록되기 전에 이 VLAN을 사용하여 노드를 성공적으로 등록해야 합니다.
물리적 네트워크 어댑터에서 VLAN ID를 설정하려면 다음 PowerShell 명령을 사용합니다.
이 예제에서는 물리적 네트워크 어댑터 NIC1에서 VLAN ID 44를 구성합니다.
Set-NetAdapter -Name "NIC1" -VlanID 44
VLAN ID가 설정되고 노드의 IP가 실제 네트워크 어댑터에서 구성되면 오케스트레이터는 관리에 사용되는 실제 네트워크 어댑터에서 이 VLAN ID 값을 읽고 저장하므로 배포 중에 Azure Resource Bridge VM 또는 기타 인프라 VM에 사용할 수 있습니다. 물리적 스위치 VLAN이 제대로 라우팅되지 않으면 노드와 Azure 간의 연결이 끊어질 위험이 있으므로 Azure Portal에서 클라우드를 배포하는 동안 관리 VLAN ID를 설정할 수 없습니다.
가상 스위치를 사용하여 VLAN ID 관리
일부 시나리오에서는 배포가 시작되기 전에 가상 스위치를 만들어야 하는 요구 사항이 있습니다.
참고 항목
가상 스위치를 만들기 전에 Hype-V 역할을 사용하도록 설정해야 합니다. 자세한 내용은 필수 Windows 역할 설치를 참조 하세요.
가상 스위치 구성이 필요하고 특정 VLAN ID를 사용해야 하는 경우 다음 단계를 수행합니다.
1. 권장되는 명명 규칙을 사용하여 가상 스위치 만들기
Azure Stack HCI 배포는 네트워크 ATC를 사용하여 관리, 컴퓨팅 및 스토리지 의도에 대한 가상 스위치 및 가상 네트워크 어댑터를 만들고 구성합니다. 기본적으로 네트워크 ATC는 의도에 대한 가상 스위치를 만들 때 가상 스위치에 특정 이름을 사용합니다.
동일한 명명 규칙을 사용하여 가상 스위치 이름의 이름을 지정하는 것이 좋습니다. 가상 스위치에 권장되는 이름은 다음과 같습니다.
"ConvergedSwitch($IntentName)"는 $IntentName 배포 중에 포털에 입력된 의도의 이름과 일치해야 합니다. 이 문자열은 다음 단계에서 설명한 대로 관리에 사용되는 가상 네트워크 어댑터의 이름과도 일치해야 합니다.
다음 예제에서는 권장되는 명명 규칙을 $IntentName사용하여 PowerShell을 사용하여 가상 스위치를 만드는 방법을 보여줍니다. 네트워크 어댑터 이름 목록은 관리 및 컴퓨팅 네트워크 트래픽에 사용할 실제 네트워크 어댑터 목록입니다.
$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $true
2. 모든 노드에 필요한 네트워크 ATC 명명 규칙을 사용하여 관리 가상 네트워크 어댑터 구성
가상 스위치 및 연결된 관리 가상 네트워크 어댑터가 만들어지면 네트워크 어댑터 이름이 네트워크 ATC 명명 표준을 준수하는지 확인합니다.
특히 관리 트래픽에 사용되는 가상 네트워크 어댑터의 이름은 다음 규칙을 사용해야 합니다.
- 네트워크 어댑터 및 가상 네트워크 어댑터의 이름을 사용해야
vManagement($intentname)합니다. - 이 이름은 대/소문자를 구분합니다.
$Intentname는 모든 문자열일 수 있지만 가상 스위치에 사용되는 이름과 같아야 합니다. 의도 이름을 정의할 때 Azure Portal에서 이 동일한 문자열을Mgmt사용해야 합니다.
관리 가상 네트워크 어댑터 이름을 업데이트하려면 다음 명령을 사용합니다.
$IntentName = "MgmtCompute"
#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"
#Rename NetAdapter because during creation, Hyper-V adds the string “vEthernet” to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"
3. 모든 노드에 대한 관리 가상 네트워크 어댑터에 대한 VLAN ID 구성
가상 스위치 및 관리 가상 네트워크 어댑터가 만들어지면 이 어댑터에 필요한 VLAN ID를 지정할 수 있습니다. VLAN ID를 가상 네트워크 어댑터에 할당하는 다른 옵션이 있지만 유일하게 지원되는 옵션은 명령을 사용하는 Set-VMNetworkAdapterIsolation 것입니다.
필요한 VLAN ID가 구성되면 관리 가상 네트워크 어댑터에 IP 주소 및 게이트웨이를 할당하여 다른 노드, DNS, Active Directory 및 인터넷과의 연결이 있는지 확인할 수 있습니다.
다음 예제에서는 기본값 대신 VLAN ID 8 를 사용하도록 관리 가상 네트워크 어댑터를 구성하는 방법을 보여줍니다.
Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID "8"
4. 배포 중 관리 의도에 대한 실제 네트워크 어댑터 참조
새로 만든 가상 네트워크 어댑터는 Azure Portal을 통해 배포할 때 사용 가능한 것으로 표시되지만 네트워크 구성은 네트워크 ATC를 기반으로 한다는 점을 기억해야 합니다. 즉, 관리 또는 관리 및 컴퓨팅 의도를 구성할 때 해당 의도에 사용되는 실제 네트워크 어댑터를 선택해야 합니다.
참고 항목
네트워크 의도에 대한 가상 네트워크 어댑터를 선택하지 마세요.
동일한 논리가 Azure Resource Manager 템플릿에 적용됩니다. 네트워크 의도에 사용하려는 실제 네트워크 어댑터를 지정해야 하며 가상 네트워크 어댑터는 지정하지 않아야 합니다.
다음은 VLAN ID에 대한 요약된 고려 사항입니다.
| # | 고려 사항 |
|---|---|
| 1 | Azure Arc에 서버를 등록하기 전에 관리를 위해 물리적 네트워크 어댑터에 VLAN ID를 지정해야 합니다. |
| 2 | Azure Arc에 서버를 등록하기 전에 가상 스위치가 필요한 경우 특정 단계를 사용합니다. |
| 3 | 관리 VLAN ID는 배포 중에 호스트 구성에서 인프라 VM으로 이월됩니다. |
| 4 | Azure Portal 배포 또는 Resource Manager 템플릿 배포에 대한 VLAN ID 입력 매개 변수가 없습니다. |
스토리지에 대한 사용자 지정 IP
기본적으로 네트워크 ATC는 다음 표에서 스토리지에 대한 IP 및 VLAN을 자동으로 할당합니다.
| 스토리지 어댑터 | IP 주소 및 서브넷 | VLAN |
|---|---|---|
| pNIC1 | 10.71.1.x | 711 |
| pNIC2 | 10.71.2.x | 712 |
| pNIC3 | 10.71.3.x | 713 |
그러나 배포 요구 사항이 기본 IP 및 VLAN과 맞지 않는 경우 스토리지에 고유한 IP, 서브넷 및 VLAN을 사용할 수 있습니다. 이 기능은 ARM 템플릿을 사용하여 클러스터를 배포할 때만 사용할 수 있으며 템플릿에서 다음 매개 변수를 지정해야 합니다.
- enableStorageAutoIP: 지정되지 않은 경우 이 매개 변수는 true로 설정됩니다. 배포하는 동안 사용자 지정 스토리지 IP를 사용하도록 설정하려면 이 매개 변수를 false로 설정해야 합니다.
- storageAdapterIPInfo: 이 매개 변수는 "enableStorageAutoIP" 매개 변수와 종속성을 가지며 스토리지 자동 IP 매개 변수가 false로 설정된 경우 항상 필요합니다. ARM 템플릿의 "storageAdapterIPInfo" 매개 변수 내에서 사용자 고유의 IP 및 서브넷 마스크를 사용하여 각 노드 및 네트워크 어댑터에 대해 "ipv4Address" 및 "subnetMask" 매개 변수를 지정해야 합니다.
- vlanId: 위에서 설명한 대로 이 매개 변수는 네트워크 ATC 기본 VLAN을 변경할 필요가 없는 경우 사용합니다. 그러나 이러한 기본 VLAN이 네트워크에서 작동하지 않는 경우 각 스토리지 네트워크에 대해 고유한 VLAN ID를 지정할 수 있습니다.
다음 ARM 템플릿에는 스토리지용 네트워크 스위치가 있는 두 노드 HCI 클러스터의 예가 포함되어 있습니다. 여기서 스토리지 IP는 사용자 지정 스토리지 IP를 사용하여 노드 배포 2개를 사용자 지정 합니다.
노드 및 클러스터 IP 할당
Azure Stack HCI 시스템의 경우 서버 노드 및 클러스터 IP에 IP를 할당하는 두 가지 옵션이 있습니다.
정적 및 DHCP(동적 호스트 구성 프로토콜) 프로토콜이 모두 지원됩니다.
적절한 노드 IP 할당은 클러스터 수명 주기 관리의 핵심입니다. Azure Arc에서 노드를 등록하기 전에 정적 옵션과 DHCP 옵션 중에서 결정합니다.
Arc Resource Bridge 및 네트워크 컨트롤러와 같은 인프라 VM 및 서비스는 관리 IP 풀의 고정 IP를 계속 사용합니다. 즉, DHCP를 사용하여 노드 및 클러스터 IP에 IP를 할당하기로 결정하더라도 관리 IP 풀은 여전히 필요합니다.
다음 섹션에서는 각 옵션의 의미에 대해 설명합니다.
고정 IP 할당
노드에 고정 IP를 사용하는 경우 관리 IP 풀을 사용하여 사용 가능한 IP를 가져오고 배포하는 동안 클러스터 IP에 자동으로 할당합니다.
관리 IP 풀에 대해 정의된 IP 범위의 일부가 아닌 노드에 대해 관리 IP를 사용하는 것이 중요합니다. 서버 노드 IP는 정의된 IP 범위의 동일한 서브넷에 있어야 합니다.
노드의 모든 실제 네트워크 어댑터에 대해 기본 게이트웨이 및 구성된 DNS 서버에 대해 하나의 관리 IP만 할당하는 것이 좋습니다. 이렇게 하면 관리 네트워크 의도가 만들어지면 IP가 변경되지 않습니다. 이렇게 하면 Azure Arc 등록 중에를 포함하여 배포 프로세스 중에 노드가 아웃바운드 연결을 유지할 수 있습니다.
라우팅 문제를 방지하고 아웃바운드 연결 및 Arc 등록에 사용할 IP를 식별하기 위해 Azure Portal은 둘 이상의 기본 게이트웨이가 구성되어 있는지 유효성을 검사합니다.
OS 구성 중에 가상 스위치 및 관리 가상 네트워크 어댑터를 만든 경우 노드의 관리 IP를 해당 가상 네트워크 어댑터에 할당해야 합니다.
DHCP IP 할당
노드에 대한 IP를 DHCP 서버에서 가져오는 경우 클러스터 IP에도 동적 IP가 사용됩니다. 인프라 VM 및 서비스에는 여전히 고정 IP가 필요하며 이는 관리 IP 풀 주소 범위가 노드 및 클러스터 IP에 사용되는 DHCP 범위에서 제외되어야 임을 의미합니다.
예를 들어 인프라 정적 IP에 대해 관리 IP 범위가 192.168.1.20/24에서 192.168.1.30/24로 정의된 경우 서브넷 192.168.1.0/24에 대해 정의된 DHCP 범위에는 인프라 서비스와의 IP 충돌을 방지하기 위해 관리 IP 풀에 해당하는 제외가 있어야 합니다. 또한 노드 IP에 DHCP 예약을 사용하는 것이 좋습니다.
관리 의도를 만든 후 관리 IP를 정의하는 프로세스에는 네트워크 의도에 대해 선택된 첫 번째 실제 네트워크 어댑터의 MAC 주소를 사용하는 과정이 포함됩니다. 이 MAC 주소는 관리 목적으로 만들어진 가상 네트워크 어댑터에 할당됩니다. 즉, DHCP 서버에서 첫 번째 실제 네트워크 어댑터가 가져오는 IP 주소는 가상 네트워크 어댑터가 관리 IP로 사용하는 것과 동일한 IP 주소입니다. 따라서 노드 IP에 대한 DHCP 예약을 만드는 것이 중요합니다.
클라우드 배포 중에 사용되는 네트워크 유효성 검사 논리는 구성에 기본 게이트웨이가 있는 여러 물리적 네트워크 인터페이스를 검색하면 실패합니다. 호스트 IP 할당에 DHCP를 사용해야 하는 경우 위에서 설명한 대로 SET (임베디드 팀 전환) 가상 스위치 및 관리 가상 네트워크 어댑터를 미리 만들어야 하므로 관리 가상 네트워크 어댑터만 DHCP 서버에서 IP 주소를 획득합니다.
클러스터 노드 IP 고려 사항
IP 주소에 대한 요약된 고려 사항은 다음과 같습니다.
| # | 고려 사항 |
|---|---|
| 1 | 노드 IP는 정적 주소인지 동적 주소인지에 관계없이 정의된 관리 IP 풀 범위의 동일한 서브넷에 있어야 합니다. |
| 2 | 관리 IP 풀에는 노드 IP가 포함되어서는 안됩니다. 동적 IP 할당을 사용하는 경우 DHCP 제외를 사용합니다. |
| 3 | 노드에 대해 DHCP 예약을 가능한 한 많이 사용합니다. |
| 4 | DHCP 주소는 노드 IP 및 클러스터 IP에 대해서만 지원됩니다. 인프라 서비스는 관리 풀의 정적 IP를 사용합니다. |
| 5 | 관리 네트워크 의도가 만들어지면 첫 번째 물리적 네트워크 어댑터의 MAC 주소가 관리 가상 네트워크 어댑터에 할당됩니다. |
프록시 요구 사항
온-프레미스 인프라 내에서 인터넷에 액세스하려면 프록시가 필요할 가능성이 큽니다. Azure Stack HCI는 인증되지 않은 프록시 구성만 지원합니다. Azure Arc에서 노드를 등록하려면 인터넷 액세스가 필요하므로 서버 노드를 등록하기 전에 프록시 구성을 OS 구성의 일부로 설정해야 합니다. 자세한 내용은 프록시 설정 구성을 참조 하세요.
Azure Stack HCI OS에는 모든 OS 구성 요소가 인터넷에 액세스할 수 있도록 동일한 프록시 구성이 필요한 세 가지 서비스(WinInet, WinHTTP 및 환경 변수)가 있습니다. 노드에 사용되는 동일한 프록시 구성은 Arc Resource Bridge VM 및 AKS로 자동으로 전달되어 배포 중에 인터넷에 액세스할 수 있도록 합니다.
프록시 구성에 대한 요약된 고려 사항은 다음과 같습니다.
| # | 고려 사항 |
|---|---|
| 1 | Azure Arc에서 노드를 등록하기 전에 프록시 구성을 완료해야 합니다. |
| 2 | WinINET, WinHTTP 및 환경 변수에 동일한 프록시 구성을 적용해야 합니다. |
| 3 | 환경 검사기는 프록시 구성이 모든 프록시 구성 요소에서 일관되도록 합니다. |
| 4 | Arc Resource Bridge VM 및 AKS의 프록시 구성은 배포 중에 오케스트레이터에 의해 자동으로 수행됩니다. |
| 5 | 인증되지 않은 프록시만 지원됩니다. |
방화벽 요구 사항
현재 Azure Stack HCI 및 해당 구성 요소가 성공적으로 연결할 수 있도록 방화벽에서 여러 인터넷 엔드포인트를 열어야 합니다. 필요한 엔드포인트의 자세한 목록은 방화벽 요구 사항을 참조 하세요.
Azure Arc에서 노드를 등록하기 전에 방화벽 구성을 수행해야 합니다. 독립 실행형 버전의 환경 검사기를 사용하여 방화벽이 이러한 엔드포인트로 전송되는 트래픽을 차단하지 않는지 확인할 수 있습니다. 자세한 내용은 Azure Stack HCI 환경 검사기를 참조하여 Azure Stack HCI에 대한 배포 준비 상태를 평가합니다.
다음은 방화벽에 대한 요약된 고려 사항입니다.
| # | 고려 사항 |
|---|---|
| 1 | Azure Arc에서 노드를 등록하기 전에 방화벽 구성을 수행해야 합니다. |
| 2 | 독립 실행형 모드의 환경 검사기를 사용하여 방화벽 구성의 유효성을 검사할 수 있습니다. |
5단계: 네트워크 어댑터 구성 확인
네트워크 어댑터는 사용되는 네트워크 트래픽 유형(관리, 컴퓨팅 및 스토리지)에 따라 정규화됩니다. Windows Server 카탈로그를 검토할 때 Windows Server 2022 인증은 어댑터가 정규화된 네트워크 트래픽을 나타냅니다.
Azure Stack HCI용 서버를 구매하기 전에 Azure Stack HCI에서 세 가지 트래픽 유형이 모두 필요하므로 관리, 컴퓨팅 및 스토리지에 적합한 어댑터가 하나 이상 있어야 합니다. 클라우드 배포는 네트워크 ATC를 사용하여 적절한 트래픽 유형에 대한 네트워크 어댑터를 구성하므로 지원되는 네트워크 어댑터를 사용하는 것이 중요합니다.
네트워크 ATC에서 사용하는 기본값은 클러스터 네트워크 설정에 설명되어 있습니다. 기본값을 사용하는 것이 좋습니다. 이렇게 하면 필요한 경우 Azure Portal 또는 Resource Manager 템플릿을 사용하여 다음 옵션을 재정의할 수 있습니다.
- 스토리지 VLAN: 이 값을 스토리지에 필요한 VLAN으로 설정합니다.
- 점보 패킷: 점보 패킷의 크기를 정의합니다.
- 네트워크 직접: 네트워크 어댑터에 대해 RDMA를 사용하지 않도록 설정하려면 이 값을 false로 설정합니다.
- 네트워크 직접 기술: 이 값을
RoCEv2설정합니다.iWarp - 트래픽 우선 순위 데이터 센터 브리징(DCB): 요구 사항에 맞는 우선 순위를 설정합니다. Microsoft 및 고객이 유효성을 검사하기 때문에 기본 DCB 값을 사용하는 것이 좋습니다.
네트워크 어댑터 구성에 대한 요약된 고려 사항은 다음과 같습니다.