Azure Stack Hub에 대한 네트워크 통합 계획

이 문서에서는 Azure Stack Hub를 기존 네트워킹 환경에 가장 잘 통합하는 방법을 결정하는 데 도움이 되는 Azure Stack Hub 네트워크 인프라 정보를 제공합니다.

참고

Azure Stack Hub에서 외부 DNS 이름(예: www.bing.com)을 resolve DNS 요청을 전달하려면 DNS 서버를 제공해야 합니다. Azure Stack Hub DNS 요구 사항에 대한 자세한 내용은 Azure Stack Hub 데이터 센터 통합 - DNS를 참조하세요.

물리적 네트워크 디자인

Azure Stack Hub 솔루션에는 운영 및 서비스를 지원하기 위해 복원력 있고 고가용성 물리적 인프라가 필요합니다. Azure Stack Hub를 네트워크에 통합하려면 ToR(Top-of-Rack 스위치)에서 가장 가까운 스위치 또는 라우터로의 업링크가 필요합니다. 이 설명서에서는 Border라고 합니다. ToR은 단일 또는 한 쌍의 테두리로 업링크될 수 있습니다. ToR은 자동화 도구에 의해 미리 구성되며, BGP 라우팅을 사용할 때 ToR과 Border 간에 최소 1개의 연결이 예상되며, 정적 라우팅을 사용할 때 ToR과 Border 간에 최소 두 개의 연결(ToR당 하나)이 있으며, 두 라우팅 옵션에 대해 최대 4개의 연결이 필요합니다. 이러한 연결은 SFP+ 또는 SFP28 미디어 및 최소 1GB 속도로 제한됩니다. 가용성을 위해 OEM(원래 장비 제조업체) 하드웨어 공급업체에 검사. 다음 다이어그램에서는 권장되는 디자인을 제공합니다.

대역폭 할당

Azure Stack Hub는 Windows Server 2019 장애 조치(failover) 클러스터 및 공간 다이렉트 기술을 사용하여 빌드됩니다. Azure Stack Hub 물리적 네트워크 구성의 일부는 트래픽 분리 및 대역폭 보장을 활용하여 Spaces Direct 스토리지 통신이 솔루션에 필요한 성능 및 규모를 충족할 수 있도록 하기 위해 수행됩니다. 네트워크 구성은 트래픽 클래스를 사용하여 공간 다이렉트, RDMA 기반 통신을 Azure Stack Hub 인프라 및/또는 테넌트에서 네트워크 사용률과 분리합니다. Windows Server 2019에 대해 정의된 현재 모범 사례에 맞게 Azure Stack Hub는 장애 조치(failover) 클러스터링 제어 통신을 지원하기 위해 서버와 서버 통신을 추가로 분리하기 위해 추가 트래픽 클래스 또는 우선 순위를 사용하도록 변경하고 있습니다. 이 새 트래픽 클래스 정의는 사용 가능한 실제 대역폭의 2%를 예약하도록 구성됩니다. 이 트래픽 클래스 및 대역폭 예약 구성은 Azure Stack Hub 솔루션의 ToR(Top-of-rack) 스위치와 Azure Stack Hub의 호스트 또는 서버에서 변경하여 수행됩니다. 고객 테두리 네트워크 디바이스에서는 변경이 필요하지 않습니다. 이러한 변경은 장애 조치(failover) 클러스터 통신에 더 나은 복원력을 제공하며 네트워크 대역폭이 완전히 소비되고 결과적으로 장애 조치(failover) 클러스터 제어 메시지가 중단되는 상황을 방지하기 위한 것입니다. 장애 조치(failover) 클러스터 통신은 Azure Stack Hub 인프라의 중요한 구성 요소이며 장기간 중단된 경우 Spaces Direct 스토리지 서비스 또는 테넌트 또는 최종 사용자 워크로드 안정성에 영향을 주는 기타 서비스의 불안정성이 발생할 수 있습니다.

참고

설명된 변경 내용은 2008 릴리스에서 Azure Stack Hub 시스템의 호스트 수준에서 추가됩니다. ToR 네트워크 스위치에서 필요한 변경을 준비하려면 OEM에 문의하세요. 이 ToR 변경은 2008 릴리스로 업데이트하기 전이나 2008년으로 업데이트한 후에 수행할 수 있습니다. 장애 조치(failover) 클러스터 통신을 개선하려면 ToR 스위치에 대한 구성 변경이 필요합니다.

논리 네트워크

논리 네트워크는 기본 물리적 네트워크 인프라의 추상화입니다. 호스트, VM(가상 머신) 및 서비스에 대한 네트워크 할당을 구성하고 간소화하는 데 사용됩니다. 논리 네트워크 만들기의 일환으로 네트워크 사이트는 각 물리적 위치에서 논리 네트워크와 연결된 VLAN(가상 로컬 영역 네트워크), IP 서브넷 및 IP 서브넷/VLAN 쌍을 정의하기 위해 만들어집니다.

다음 표에서는 계획해야 하는 논리 네트워크 및 연결된 IPv4 서브넷 범위를 보여 줍니다.

논리 네트워크	설명	크기
퍼블릭 VIP	Azure Stack Hub는 이 네트워크의 총 31개의 주소를 사용하며 나머지는 테넌트 VM에서 사용됩니다. 31개 주소에서 8개의 공용 IP 주소가 Azure Stack Hub 서비스의 작은 집합에 사용됩니다. App Service 및 SQL 리소스 공급자를 사용하려는 경우 7개의 주소가 더 사용됩니다. 나머지 16개 IP는 향후 Azure 서비스를 위해 예약되어 있습니다.	/26(호스트 62개) - /22(호스트 1022개) 권장 = /24(호스트 254개)
인프라 전환	라우팅을 위한 지점 및 지점 간의 IP 주소, 전용 스위치 관리 인터페이스 및 스위치에 할당된 루프백 주소입니다.	/26
인프라	통신할 Azure Stack Hub 내부 구성 요소에 사용됩니다.	/24
프라이빗	스토리지 네트워크, 프라이빗 VIP, 인프라 컨테이너 및 기타 내부 함수에 사용됩니다. 자세한 내용은 이 문서의 프라이빗 네트워크 섹션을 참조하세요.	/20
BMC	물리적 호스트의 BMC와 통신하는 데 사용됩니다.	/26

참고

포털의 경고는 운영자에게 PEP cmdlet Set-AzsPrivateNetwork 를 실행하여 새 /20 개인 IP 공간을 추가하도록 알릴 것입니다. /20 개인 IP 공간 선택에 대한 자세한 내용과 지침은 이 문서의 프라이빗 네트워크 섹션을 참조하세요.

네트워크 인프라

Azure Stack Hub에 대한 네트워크 인프라는 스위치에 구성된 여러 논리 네트워크로 구성됩니다. 다음 다이어그램에서는 이러한 논리 네트워크와 TOR(Top-of-Rack), BMC(베이스보드 관리 컨트롤러) 및 테두리(고객 네트워크) 스위치와 통합하는 방법을 보여 줍니다.

BMC 네트워크

이 네트워크는 모든 기본 보드 관리 컨트롤러(BMC 또는 서비스 프로세서라고도 함)를 관리 네트워크에 연결하는 데만 사용됩니다. 예를 들어 iDRAC, iLO, iBMC 등이 있습니다. BMC 노드와 통신하는 데는 하나의 BMC 계정만 사용됩니다. 있는 경우 HLH(하드웨어 수명 주기 호스트)는 이 네트워크에 있으며 하드웨어 유지 관리 또는 모니터링을 위한 OEM 관련 소프트웨어를 제공할 수 있습니다.

또한 HLH는 DVM(배포 VM)을 호스트합니다. DVM은 Azure Stack Hub 배포 중에 사용되며 배포가 완료되면 제거됩니다. DVM은 여러 구성 요소를 테스트, 유효성 검사 및 액세스하기 위해 연결된 배포 시나리오에서 인터넷에 액세스해야 합니다. 이러한 구성 요소는 회사 네트워크 내부 및 외부에 있을 수 있습니다(예: NTP, DNS 및 Azure). 연결 요구 사항에 대한 자세한 내용은 Azure Stack Hub 방화벽 통합의 NAT 섹션을 참조하세요.

프라이빗 네트워크

이 /20(4096 IP) 네트워크는 Azure Stack Hub 지역에 비공개이며(Azure Stack Hub 시스템의 테두리 스위치 디바이스를 넘어 라우팅하지 않음) 여러 서브넷으로 나뉩니다. 다음은 몇 가지 예입니다.

• 스토리지 네트워크: 공간 다이렉트 및 SMB(서버 메시지 블록) 스토리지 트래픽 및 VM 실시간 마이그레이션 사용을 지원하는 데 사용되는 /25(128 IP) 네트워크입니다.
• 내부 가상 IP 네트워크: 소프트웨어 부하 분산 장치의 내부 전용 VIP 전용 /25 네트워크입니다.
• 컨테이너 네트워크: 인프라 서비스를 실행하는 컨테이너 간의 내부 전용 트래픽 전용 /23(512 IP) 네트워크입니다.

Azure Stack Hub 시스템에는 추가 /20 개인 내부 IP 공간이 필요합니다 . 이 네트워크는 Azure Stack Hub 시스템에 비공개이며(Azure Stack Hub 시스템의 테두리 스위치 디바이스를 넘어 라우팅되지 않음) 데이터 센터 내의 여러 Azure Stack Hub 시스템에서 다시 사용할 수 있습니다. 네트워크는 Azure Stack에 비공개이지만 데이터 센터의 다른 네트워크와 겹치지 않아야 합니다. /20 개인 IP 공간은 컨테이너에서 Azure Stack Hub 인프라를 실행할 수 있는 여러 네트워크로 나뉩니다. 또한 이 새로운 개인 IP 공간을 사용하면 배포 전에 필요한 라우팅 가능한 IP 공간을 줄이기 위한 지속적인 노력을 할 수 있습니다. 컨테이너에서 Azure Stack Hub 인프라를 실행하는 목표는 사용률을 최적화하고 성능을 향상시키는 것입니다. 또한 /20 개인 IP 공간은 배포 전에 필요한 라우팅 가능한 IP 공간을 줄이는 지속적인 노력을 가능하게 하는 데도 사용됩니다. 개인 IP 공간에 대한 지침은 RFC 1918을 따르는 것이 좋습니다.

1910년 이전에 배포된 시스템의 경우 이 /20 서브넷은 1910으로 업데이트한 후 시스템에 입력할 추가 네트워크가 됩니다. Set-AzsPrivateNetwork PEP cmdlet을 통해 시스템에 추가 네트워크를 제공해야 합니다.

참고

/20 입력은 1910년 이후의 다음 Azure Stack Hub 업데이트에 대한 필수 구성 요소로 사용됩니다. 1910년 이후에 다음 Azure Stack Hub 업데이트가 릴리스되고 설치하려고 하면 다음과 같이 수정 단계에 설명된 대로 /20 입력을 완료하지 않은 경우 업데이트가 실패합니다. 위의 수정 단계가 완료될 때까지 관리자 포털에 경고가 표시됩니다. 이 새 프라이빗 공간을 사용하는 방법을 이해하려면 데이터 센터 네트워크 통합 문서를 참조하세요.

수정 단계: 수정하려면 지침에 따라 PEP 세션을 엽니다. /20 크기의 개인 내부 IP 범위를 준비하고 다음 예제 Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20를 사용하여 PEP 세션에서 다음 cmdlet을 실행합니다. 작업이 성공적으로 수행되면 구성에 추가된 Azs 내부 네트워크 범위라는 메시지가 표시됩니다. 성공적으로 완료되면 경고가 관리자 포털에서 닫힙니다. 이제 Azure Stack Hub 시스템을 다음 버전으로 업데이트할 수 있습니다.

Azure Stack Hub 인프라 네트워크

이 /24 네트워크는 내부 Azure Stack Hub 구성 요소 전용이므로 서로 통신하고 데이터를 교환할 수 있습니다. 이 서브넷은 Azure Stack Hub 솔루션 외부에서 데이터 센터로 라우팅할 수 있습니다. 이 서브넷에서 공용 또는 인터넷 라우팅 가능 IP 주소를 사용하지 않는 것이 좋습니다. 이 네트워크는 Border에 보급되지만 대부분의 IP는 ACL(Access Control 목록)으로 보호됩니다. 액세스에 허용되는 IP는 PEP(권한 있는 엔드포인트) 및 Azure Stack Hub Backup과 같은 /27 네트워크 및 호스트 서비스에 해당하는 작은 범위 내에 있습니다.

공용 VIP 네트워크

공용 VIP 네트워크는 Azure Stack의 네트워크 컨트롤러에 할당됩니다. 스위치의 논리 네트워크가 아닙니다. SLB는 주소 풀을 사용하고 테넌트 워크로드에 /32 네트워크를 할당합니다. 스위치 라우팅 테이블에서 이러한 /32 IP는 BGP를 통해 사용 가능한 경로로 보급됩니다. 이 네트워크에는 외부 액세스 가능 또는 공용 IP 주소가 포함되어 있습니다. Azure Stack Hub 인프라는 이 공용 VIP 네트워크에서 처음 31개의 주소를 예약하고 나머지는 테넌트 VM에서 사용합니다. 이 서브넷의 네트워크 크기는 최소 /26(호스트 64개)에서 최대 /22(호스트 1022개)에 이르기까지 다양할 수 있습니다. /24 네트워크를 계획하는 것이 좋습니다.

온-프레미스 네트워크에 연결

Azure Stack Hub는 가상 머신, 부하 분산 장치 등과 같은 고객 리소스에 가상 네트워크를 사용합니다.

가상 네트워크 내의 리소스에서 온-프레미스/회사 리소스로 연결하는 여러 가지 옵션이 있습니다.

• 공용 VIP 네트워크의 공용 IP 주소를 사용합니다.
• Virtual Network 게이트웨이 또는 NVA(네트워크 가상 어플라이언스)를 사용합니다.

S2S VPN 터널을 사용하여 리소스를 온-프레미스 네트워크 간에 연결하는 경우 리소스에 공용 IP 주소도 할당되어 있고 해당 공용 IP 주소를 통해 더 이상 연결할 수 없는 시나리오가 발생할 수 있습니다. 원본이 NVA 솔루션에 대한 로컬 네트워크 게이트웨이 경로(Virtual Network Gateway) 또는 사용자 정의 경로에 정의된 동일한 서브넷 범위에 속하는 공용 IP에 액세스하려고 하면 Azure Stack Hub는 구성된 라우팅 규칙에 따라 S2S 터널을 통해 트래픽 아웃바운드를 원본으로 다시 라우팅하려고 시도합니다. 반환 트래픽은 공용 IP 주소로 원본 NATed가 아닌 VM의 개인 IP 주소를 사용합니다.

이 문제에 대한 두 가지 해결 방법이 있습니다.

• 공용 VIP 네트워크로 전송되는 트래픽을 인터넷으로 라우팅합니다.
• 공용 VIP 네트워크로 향하는 로컬 네트워크 게이트웨이에 정의된 서브넷 IP를 NAT에 NAT에 추가합니다.

인프라 네트워크 전환

이 /26 네트워크는 라우팅 가능한 지점 간 IP /30(호스트 IP 2개) 서브넷과 대역 내 스위치 관리 및 BGP 라우터 ID를 위한 전용 /32 서브넷인 루프백을 포함하는 서브넷입니다. 이 IP 주소 범위는 Azure Stack Hub 솔루션 외부에서 데이터 센터로 라우팅할 수 있어야 합니다. 개인 IP 또는 공용 IP일 수 있습니다.

스위치 관리 네트워크

이 /29(6개의 호스트 IP) 네트워크는 스위치의 관리 포트 연결 전용입니다. 배포, 관리 및 문제 해결을 위해 대역 외 액세스를 허용합니다. 위에서 언급한 스위치 인프라 네트워크에서 계산됩니다.

허용된 네트워크

배포 워크시트에는 운영자가 신뢰할 수 있는 데이터 센터 네트워크 범위에서 네트워크 디바이스 관리 인터페이스 및 HLH(하드웨어 수명 주기 호스트)에 대한 액세스를 허용하도록 일부 ACL(액세스 제어 목록)을 변경할 수 있는 필드가 있습니다. 액세스 제어 목록이 변경되면 운영자는 특정 네트워크 범위 내의 관리 jumpbox VM이 스위치 관리 인터페이스 및 HLH OS에 액세스하도록 허용할 수 있습니다. 연산자는 이 목록에 하나 이상의 서브넷을 제공할 수 있습니다. 비워 두면 기본적으로 액세스를 거부합니다. 이 새로운 기능은 Azure Stack Hub 스위치 구성의 특정 설정 수정에 설명된 대로 배포 후 수동 개입의 필요성을 대체합니다.

다음 단계

• 가상 네트워크 트래픽 라우팅
• 네트워크 계획: 테두리 연결에 대해 알아봅니다.