Azure Stack Hub 통합 시스템의 데이터 센터 통합 계획 시 고려 사항

아티클
10/30/2024

Azure Stack Hub 통합 시스템에 관심이 있는 경우 배포와 관련된 주요 계획 고려 사항과 시스템이 데이터 센터에 어떻게 적합한지 이해해야 합니다. 이 문서에서는 Azure Stack Hub 통합 시스템에 대한 중요한 인프라 결정을 내리는 데 도움이 되는 이러한 고려 사항에 대한 대략적인 개요를 제공합니다. 이러한 고려 사항을 이해하면 데이터 센터에 Azure Stack Hub를 배포하는 동안 OEM 하드웨어 공급업체와 함께 작업할 때 도움이 됩니다.

참고

Azure Stack Hub 통합 시스템은 권한 있는 하드웨어 공급업체에서만 구매할 수 있습니다.

Azure Stack Hub를 배포하려면 배포가 시작되기 전에 솔루션 공급자에게 계획 정보를 제공하여 프로세스가 빠르고 원활하게 진행되는 데 도움이 됩니다. 필요한 정보는 다양한 영역과 의사 결정자의 지식이 필요할 수 있는 많은 중요한 의사 결정과 함께 네트워킹, 보안 및 ID 정보 전반에 걸쳐 다양합니다. 배포 전에 필요한 모든 정보를 준비하려면 organization 여러 팀의 사용자가 필요합니다. 유용한 조언이 있을 수 있으므로 이 정보를 수집하는 동안 하드웨어 공급업체와 대화하는 데 도움이 될 수 있습니다.

필요한 정보를 조사하고 수집하는 동안 네트워크 환경에 대한 배포 전 구성을 변경해야 할 수 있습니다. 이러한 변경 내용에는 Azure Stack Hub 솔루션에 대한 IP 주소 공간 예약뿐만 아니라 새 Azure Stack Hub 솔루션 스위치에 대한 연결을 준비하기 위해 라우터, 스위치 및 방화벽을 구성하는 것이 포함될 수 있습니다. 계획에 도움이 되도록 주제 영역 전문가가 줄을 서야 합니다.

용량 계획 관련 고려 사항

획득을 위해 Azure Stack Hub 솔루션을 평가할 때 Azure Stack Hub 솔루션의 전체 용량에 직접적인 영향을 주는 하드웨어 구성을 선택합니다. 여기에는 CPU, 메모리 밀도, 스토리지 구성 및 전체 솔루션 크기 조정(예: 서버 수)의 클래식 선택 항목이 포함됩니다. 기존 가상화 솔루션과 달리 사용 가능한 용량을 확인하기 위한 이러한 구성 요소의 간단한 산술 연산은 적용되지 않습니다. 첫 번째 이유는 Azure Stack Hub가 솔루션 자체 내에서 인프라 또는 관리 구성 요소를 호스트하도록 설계되어 있기 때문입니다. 두 번째 이유는 솔루션의 용량 중 일부는 테넌트 워크로드의 중단을 최소화하는 방식으로 솔루션의 소프트웨어를 업데이트하여 복원력을 지원하기 위해 예약되어 있기 때문입니다.

Azure Stack Hub Capacity Planner 스프레드시트는 두 가지 방법으로 용량 계획에 대해 합리적인 결정을 내리도록 지원합니다. 첫 번째는 하드웨어 제품을 선택하고 리소스 조합에 맞게 시도하는 것입니다. 두 번째는 Azure Stack Hub가 실행할 워크로드를 정의하여 이를 지원할 수 있는 사용 가능한 하드웨어 SKU를 보는 것입니다. 마지막으로 스프레드시트는 Azure Stack Hub 계획 및 구성과 관련된 의사 결정을 내리는 데 도움이 되는 가이드로 사용됩니다.

스프레드시트는 자체적인 조사 및 분석을 대신하기 위한 것이 아닙니다. Microsoft는 스프레드시트 내에서 제공되는 정보와 관련하여 명시적이거나 묵시적인 아무런 진술이나 보장을 하지 않습니다.

관리 고려 사항

Azure Stack Hub는 권한 및 네트워크 관점에서 인프라가 모두 잠겨 있는 봉인된 시스템입니다. ACL(네트워크 액세스 제어 목록)은 모든 권한 없는 들어오는 트래픽과 인프라 구성 요소 간의 불필요한 모든 통신을 차단하기 위해 적용됩니다. 이 시스템은 권한이 없는 사용자가 시스템에 액세스하기 어렵게 만듭니다.

일상적인 관리 및 작업의 경우 인프라에 대한 무제한 관리자 액세스 권한이 없습니다. Azure Stack Hub 운영자는 관리자 포털 또는 Azure Resource Manager 통해(PowerShell 또는 REST API를 통해) 시스템을 관리해야 합니다. Hyper-V 관리자 또는 장애 조치(failover) 클러스터 관리자와 같은 다른 관리 도구에서 시스템에 액세스할 수 없습니다. 시스템을 보호하기 위해 타사 소프트웨어(예: 에이전트)를 Azure Stack Hub 인프라의 구성 요소 내에 설치할 수 없습니다. 외부 관리 및 보안 소프트웨어와의 상호 운용성은 PowerShell 또는 REST API를 통해 발생합니다.

경고 조정 단계를 통해 해결되지 않는 문제를 해결하기 위해 더 높은 수준의 액세스 권한이 필요한 경우 Microsoft 지원 문의하세요. 지원을 통해 고급 작업을 위해 시스템에 대한 임시 전체 관리자 액세스를 제공하는 방법이 있습니다.

ID 고려 사항

ID 공급자 선택

Azure Stack Hub 배포에 사용할 ID 공급자(Microsoft Entra ID 또는 AD FS)를 고려해야 합니다. 전체 시스템 재배포 없이는 배포 후에 ID 공급자를 전환할 수 없습니다. Microsoft Entra 계정을 소유하지 않고 클라우드 솔루션 공급자가 제공한 계정을 사용하는 경우 공급자를 전환하고 다른 Microsoft Entra 계정을 사용하기로 결정한 경우 솔루션 공급자에게 문의하여 비용을 지불하면 솔루션을 다시 배포해야 합니다.

ID 공급자 선택은 테넌트 VM(가상 머신), ID 시스템, 사용하는 계정 또는 Active Directory 도메인에 가입할 수 있는지 여부 등에 아무런 영향을 주지 않습니다. 이러한 사항은 별개입니다.

동일한 Microsoft Entra 테넌트 또는 Active Directory를 사용하여 여러 Azure Stack Hub 시스템을 배포할 수 있습니다.

AD FS 및 Graph 통합

AD FS를 ID 공급자로 사용하여 Azure Stack Hub를 배포하도록 선택하는 경우 Azure Stack Hub의 AD FS instance 페더레이션 트러스트를 통해 기존 AD FS instance 통합해야 합니다. 이 통합을 통해 기존 Active Directory 포리스트의 ID를 Azure Stack Hub의 리소스로 인증할 수 있습니다.

Azure Stack Hub의 Graph 서비스를 기존 Active Directory와 통합할 수도 있습니다. 이 통합을 통해 Azure Stack Hub에서 RBAC(Role-Based Access Control)를 관리할 수 있습니다. 리소스에 대한 액세스가 위임되면 Graph 구성 요소는 LDAP 프로토콜을 사용하여 기존 Active Directory 포리스트에서 사용자 계정을 찾습니다.

다음 다이어그램에서는 통합된 AD FS 및 Graph 트래픽 흐름을 보여 줍니다.

AD FS 및 그래프 트래픽 흐름을 보여 주는 다이어그램

라이선스 모델

사용할 라이선스 모델을 결정해야 합니다. 사용 가능한 옵션은 인터넷에 연결된 상태로 Azure Stack Hub를 배포하는지에 따라 달라집니다.

연결된 배포의 경우 종량제 또는 용량 기반 라이선스를 선택할 수 있습니다. 종량제를 사용할 경우 사용량을 보고한 후 Azure Commerce를 통해 청구되기 위해 Azure에 연결해야 합니다.
인터넷에서 연결이 끊긴 경우 용량 기반 라이선스만 지원됩니다.

라이선스 모델에 대한 자세한 내용은 Microsoft Azure Stack Hub 패키징 및 가격 책정을 참조하세요.

명명 결정

Azure Stack Hub 네임스페이스, 특히 지역 이름 및 외부 도메인 이름을 계획하는 방법을 고려해야 합니다. 공용 엔드포인트에 대한 Azure Stack Hub 배포의 외부 FQDN(정규화된 도메인 이름)은 다음 두 이름인 <region>의 조합입니다.<fqdn>. 예를 들어 east.cloud.fabrikam.com. 이 예제에서 Azure Stack Hub 포털은 다음 URL에서 사용할 수 있습니다.

https://portal.east.cloud.fabrikam.com
https://adminportal.east.cloud.fabrikam.com

중요

Azure Stack Hub 배포를 위해 선택한 지역 이름은 고유해야 하며 포털 주소에 표시됩니다.

다음 표에서는 이러한 도메인 명명 결정을 요약합니다.

Name	Description
지역 이름	첫 번째 Azure Stack Hub 지역의 이름입니다. 이 이름은 Azure Stack Hub가 관리하는 공용 VIP(가상 IP) 주소에 대한 FQDN의 일부로 사용됩니다. 일반적으로 지역 이름은 데이터 센터 위치와 같은 물리적 위치 식별자입니다. 지역 이름은 0-9 사이의 문자와 숫자로만 구성되어야 합니다. 특수 문자(예: `-`, `#`등)는 허용되지 않습니다.
외부 도메인 이름	외부 VIP가 있는 엔드포인트에 대한 DNS(Domain Name System) 영역의 이름입니다. 이러한 공용 VIP에 대한 FQDN에서 사용됩니다.
프라이빗(내부) 도메인 이름	인프라 관리를 위해 Azure Stack Hub에서 만든 도메인(및 내부 DNS 영역)의 이름입니다.

인증서 요구 사항

배포의 경우 퍼블릭 엔드포인트에 대한 SSL(Secure Sockets Layer) 인증서를 제공해야 합니다. 높은 수준에서 인증서에는 다음과 같은 요구 사항이 있습니다.

단일 와일드카드 인증서를 사용하거나 전용 인증서 집합을 사용한 다음, 스토리지 및 Key Vault 같은 엔드포인트에 대해서만 와일드카드를 사용할 수 있습니다.
인증서는 신뢰할 수 있는 퍼블릭 CA(인증 기관) 또는 고객 관리 CA에서 발급할 수 있습니다.

Azure Stack Hub를 배포하는 데 필요한 PKI 인증서 및 인증서를 가져오는 방법에 대한 자세한 내용은 Azure Stack Hub 공개 키 인프라 인증서 요구 사항을 참조하세요.

중요

제공된 PKI 인증서 정보는 일반적인 지침으로 사용해야 합니다. Azure Stack Hub용 PKI 인증서를 획득하기 전에 OEM 하드웨어 파트너와 협력하세요. 더 자세한 인증서 지침 및 요구 사항을 제공합니다.

시간 동기화

Azure Stack Hub를 동기화하는 데 사용되는 특정 시간 서버를 선택해야 합니다. 시간 동기화는 Kerberos 티켓을 생성하는 데 사용되므로 Azure Stack Hub 및 해당 인프라 역할에 매우 중요합니다. Kerberos 티켓은 내부 서비스를 서로 인증하는 데 사용됩니다.

시간 동기화 서버에 대한 IP를 지정해야 합니다. 인프라의 대부분의 구성 요소는 URL을 resolve 수 있지만 일부는 IP 주소만 지원합니다. 연결이 끊긴 배포 옵션을 사용하는 경우 Azure Stack Hub의 인프라 네트워크에서 연결할 수 있는 시간 서버를 회사 네트워크에 지정해야 합니다.

중요

시간 서버가 Windows 기반 NTP 서버가 아닌 경우 IP 주소의 끝을 추가 ,0x8 해야 합니다. 예들 들어 10.1.1.123,0x8입니다.

Azure에 Azure Stack Hub 연결

하이브리드 클라우드 시나리오의 경우 Azure Stack Hub를 Azure에 연결하는 방법을 계획해야 합니다. Azure Stack Hub의 가상 네트워크를 Azure의 가상 네트워크에 연결하도록 지원하는 방법에는 다음 두 가지가 있습니다.

사이트 간: IPsec을 통한 VPN(가상 사설망) 연결(IKE v1 및 IKE v2)입니다. 이 유형의 연결에는 VPN 디바이스 또는 RRAS(라우팅 및 원격 액세스 서비스)가 필요합니다. Azure의 VPN 게이트웨이에 대한 자세한 내용은 VPN Gateway 정보를 참조하세요. 이 터널을 통한 통신은 암호화되고 보호합니다. 그러나 대역폭은 터널의 최대 처리량(100-200Mbps)으로 제한됩니다.
아웃바운드 NAT: 기본적으로 Azure Stack Hub의 모든 VM은 아웃바운드 NAT를 통해 외부 네트워크에 연결됩니다. Azure Stack Hub에서 만들어진 각 가상 네트워크는 할당된 공용 IP 주소를 가져옵니다. VM에 공용 IP 주소가 직접 할당되거나 공용 IP 주소가 있는 부하 분산 장치 뒤에 있든 관계없이 가상 네트워크의 VIP를 사용하여 아웃바운드 NAT를 통해 아웃바운드 액세스가 가능합니다. 이 메서드는 VM에서 시작하고 외부 네트워크(인터넷 또는 인트라넷)로 향하는 통신에만 작동합니다. 외부에서 VM과 통신하는 데 사용할 수 없습니다.

하이브리드 연결 옵션

하이브리드 연결의 경우 제공하려는 배포의 종류와 배포할 위치를 고려하는 것이 중요합니다. 테넌트당 네트워크 트래픽을 격리해야 하는지 여부와 인트라넷 또는 인터넷 배포가 있는지를 고려해야 합니다.

단일 테넌트 Azure Stack Hub: 적어도 네트워킹 관점에서 하나의 테넌트인 것처럼 보이는 Azure Stack Hub 배포입니다. 테넌트 구독이 많을 수 있지만 인트라넷 서비스와 마찬가지로 모든 트래픽이 동일한 네트워크를 통해 이동합니다. 한 구독의 네트워크 트래픽은 다른 구독과 동일한 네트워크 연결을 통해 이동하며, 암호화된 터널을 통해 격리할 필요가 없습니다.
다중 테넌트 Azure Stack Hub: Azure Stack Hub 외부에 있는 네트워크에 바인딩된 각 테넌트 구독의 트래픽을 다른 테넌트의 네트워크 트래픽과 격리해야 하는 Azure Stack Hub 배포입니다.
인트라넷 배포: 일반적으로 회사 인트라넷에서 하나 이상의 방화벽 뒤에 있는 개인 IP 주소 공간의 Azure Stack Hub 배포입니다. 공용 IP 주소는 퍼블릭 인터넷을 통해 직접 라우팅할 수 없으므로 실제로 공용 주소가 아닙니다.
인터넷 배포: 퍼블릭 인터넷에 연결되고 공용 VIP 범위에 대한 인터넷 라우팅 가능 공용 IP 주소를 사용하는 Azure Stack Hub 배포입니다. 배포는 여전히 방화벽 뒤에 배치할 수 있지만 공용 VIP 범위는 퍼블릭 인터넷 및 Azure에서 직접 연결할 수 있습니다.

다음 표에는 장점, 단점 및 사용 사례와 함께 하이브리드 연결 시나리오가 요약되어 있습니다.

시나리오	연결 방법	장점	단점	적합한 대상
단일 테넌트 Azure Stack Hub, 인트라넷 배포	아웃바운드 NAT	더 나은 대역폭으로 더 빠른 전송 지원. 간단한 구현, 게이트웨이가 필요하지 않음	트래픽이 암호화되지 않음, 스택 외부에 격리 또는 암호화가 없음	모든 테넌트가 동일하게 신뢰되는 엔터프라이즈 배포 Azure에 대한 Azure ExpressRoute 회로가 있는 엔터프라이즈
다중 테넌트 Azure Stack Hub, 인트라넷 배포	사이트 간 VPN	테넌트 VNet에서 대상으로의 트래픽이 안전함	대역폭이 사이트 간 VPN 터널로 제한됨 가상 네트워크의 게이트웨이와 대상 네트워크의 VPN 디바이스가 필요함	일부 테넌트 트래픽을 다른 테넌트로부터 보호해야 하는 엔터프라이즈 배포
단일 테넌트 Azure Stack Hub, 인터넷 배포	아웃바운드 NAT	더 나은 대역폭으로 더 빠른 전송 지원.	트래픽이 암호화되지 않음, 스택 외부에 격리 또는 암호화가 없음	테넌트가 자체 Azure Stack Hub 배포 및 Azure Stack Hub 환경에 대한 전용 회로를 얻는 호스팅 시나리오. 예: ExpressRoute 및 MPLS(Multiprotocol Label Switching)
다중 테넌트 Azure Stack Hub, 인터넷 배포	사이트 간 VPN	테넌트 VNet에서 대상으로의 트래픽이 안전함	대역폭이 사이트 간 VPN 터널로 제한됨 가상 네트워크의 게이트웨이와 대상 네트워크의 VPN 디바이스가 필요함	공급자가 다중 테넌트 클라우드를 제공하려는 호스팅 시나리오(테넌트가 서로를 신뢰하지 않으며 트래픽을 암호화해야 함)

ExpressRoute 사용

단일 테넌트 인트라넷 및 다중 테넌트 시나리오 모두에 대해 ExpressRoute 를 통해 Azure Stack Hub를 Azure에 연결할 수 있습니다. 연결 공급자를 통해 프로비전된 ExpressRoute 회로가 필요합니다.

다음 다이어그램은 단일 테넌트 시나리오(여기서 “고객의 연결”은 ExpressRoute 회로임)에 대한 ExpressRoute를 보여 줍니다.

단일 테넌트 ExpressRoute 시나리오를 보여 주는 다이어그램

다음 다이어그램은 다중 테넌트 시나리오에 대한 ExpressRoute를 보여 줍니다.

다중 테넌트 ExpressRoute 시나리오를 보여 주는 다이어그램

외부 모니터링

Azure Stack Hub 배포 및 디바이스에서 모든 경고의 단일 보기를 가져오고 경고를 티켓팅을 위해 기존 IT 서비스 관리 워크플로에 통합하려면 Azure Stack Hub를 외부 데이터 센터 모니터링 솔루션과 통합할 수 있습니다.

Azure Stack Hub 솔루션에 포함된 하드웨어 수명 주기 호스트는 OEM 공급업체에서 제공하는 하드웨어용 관리 도구를 실행하는 Azure Stack Hub 외부의 컴퓨터입니다. 이러한 도구 또는 데이터 센터의 기존 모니터링 솔루션과 직접 통합되는 다른 솔루션을 사용할 수 있습니다.

다음 표에는 현재 사용 가능한 옵션 목록이 요약되어 있습니다.

영역	외부 모니터링 솔루션
Azure Stack Hub 소프트웨어	Operations Manager용 Azure Stack Hub 관리 팩 Nagios 플러그 인 REST 기반 API 호출
물리적 서버(IPMI를 통한 BMC)	OEM 하드웨어 - Operations Manager 공급업체 관리 팩 OEM 하드웨어 공급업체 제공 솔루션 하드웨어 공급업체 Nagios 플러그 인. OEM 파트너 지원 모니터링 솔루션(포함)
네트워크 디바이스(SNMP)	Operations Manager 네트워크 디바이스 검색 OEM 하드웨어 공급업체 제공 솔루션 Nagios 스위치 플러그 인
테넌트 구독 상태 모니터링	Windows Azure용 System Center 관리 팩

다음 요구 사항에 유의하세요.

사용하는 솔루션은 에이전트가 없는 솔루션이어야 합니다. Azure Stack Hub 구성 요소에는 타사 에이전트를 설치할 수 없습니다.
System Center Operations Manager를 사용하려면 Operations Manager 2012 R2 또는 Operations Manager 2016이 필요합니다.

백업 및 재해 복구

백업 및 재해 복구 계획에는 IaaS VM 및 PaaS 서비스를 호스트하는 기본 Azure Stack Hub 인프라와 테넌트 앱 및 데이터에 대한 계획이 포함됩니다. 이러한 사항을 개별적으로 계획합니다.

인프라 구성 요소 보호

Azure Stack Hub 인프라 구성 요소를 지정한 SMB 공유에 백업할 수 있습니다.

기존 Windows 기반 파일 서버 또는 타사 디바이스에 외부 SMB 파일 공유가 필요합니다.
네트워크 스위치 및 하드웨어 수명 주기 호스트 백업에도 동일한 공유 사용 OEM 하드웨어 공급업체는 이러한 구성 요소의 백업 및 복원에 대한 지침을 제공하는 데 도움이 됩니다. 이러한 구성 요소는 Azure Stack Hub 외부에 있기 때문입니다. OEM 공급업체의 권장 사항에 따라 백업 워크플로를 실행할 책임이 있습니다.

치명적인 데이터 손실이 발생하는 경우 인프라 백업을 사용하여 다음과 같은 배포 데이터를 다시 배치할 수 있습니다.

배포 입력 및 식별자
서비스 계정
CA 루트 인증서
페더레이션된 리소스(연결되지 않은 배포)
플랜, 제품, 구독 및 할당량
RBAC 정책 및 역할 할당
Key Vault 비밀

경고

기본적으로 Azure Stack Hub 스탬프는 하나의 CloudAdmin 계정으로만 구성됩니다. 계정 자격 증명이 손실, 손상 또는 잠긴 경우 복구 옵션이 없습니다. 권한 있는 엔드포인트 및 기타 리소스에 대한 액세스 권한이 손실됩니다.

자신의 비용으로 스탬프를 다시 배포하지 않도록 추가 CloudAdmin 계정을 만드는것이 좋습니다. 회사의 지침에 따라 이러한 자격 증명을 문서화해야 합니다.

IaaS VM에서 테넌트 앱 보호

Azure Stack Hub는 테넌트 앱과 데이터를 백업하지 않습니다. Azure Stack Hub 외부의 대상에 대한 백업 및 재해 복구 보호를 계획해야 합니다. 테넌트 보호는 테넌트 기반 작업입니다. IaaS VM의 경우 테넌트는 게스트 내 기술을 사용하여 파일 폴더, 앱 데이터 및 시스템 상태를 보호할 수 있습니다. 그러나 기업 또는 서비스 공급자는 같은 테넌트 센터나 외부 클라우드에서 백업 및 복구 솔루션을 제공할 수 있습니다.

Linux 또는 Windows IaaS VM을 백업하려면 게스트 운영 체제에 대한 액세스 권한이 있는 백업 제품을 사용하여 파일, 폴더, 운영 체제 상태 및 앱 데이터를 보호해야 합니다. Azure Backup, System Center Datacenter Protection Manager 또는 지원되는 타사 제품을 사용할 수 있습니다.

재해 발생 시 데이터를 보조 위치에 복제하고 애플리케이션 장애 조치(failover)를 오케스트레이션하기 위해 Azure Site Recovery 또는 지원되는 타사 제품을 사용할 수 있습니다. 또한 Microsoft SQL Server와 같이 네이티브 복제를 지원하는 앱은 앱이 실행되는 다른 위치로 데이터를 복제할 수 있습니다.

자세한 정보

사용 사례, 구매, 파트너 및 OEM 하드웨어 공급업체에 대한 자세한 내용은 Azure Stack Hub 제품 페이지를 참조하세요.
Azure Stack Hub 통합 시스템의 로드맵 및 지역 가용성에 대한 자세한 내용은 백서: Azure Stack Hub: Azure 확장을 참조하세요.

다음 단계

Azure Stack Hub 배포 연결 모델

다음을 통해 공유