이 문서는 Azure Stack HCI 기준 참조 아키텍처를 기반으로 하는 시리즈의 일부입니다. 3노드 스토리지 스위치리스 디자인을 사용하여 Azure Stack HCI를 효과적으로 배포하려면 기준 아키텍처를 이해하는 것이 중요합니다. 이 프로세스에는 로컬 컴퓨팅, 스토리지 및 네트워킹 기능을 제공하는 실제 노드에 대한 클러스터 디자인 선택 사항을 숙지하는 작업이 포함됩니다. 이 지식은 성공적인 배포에 필요한 변경 내용을 식별하는 데 도움이 됩니다. 이 문서의 지침은 2노드 스토리지 스위치리스 배포에도 적용되며 실제 노드 수가 3개에서 2개로 감소하는 경우에 필요한 조정을 수행합니다.
스토리지 스위치리스 네트워크 디자인은 스토리지 트래픽에 사용되는 네트워크 어댑터 포트를 연결하기 위한 스토리지 클래스 네트워크 스위치의 요구 사항을 제거합니다. 대신 노드는 인터링크 이더넷 케이블을 사용하여 직접 연결됩니다. 이 구성은 소매, 제조 또는 원격 사무실 시나리오에서 일반적으로 사용됩니다. 이 구성은 스토리지 복제 트래픽에 광범위한 데이터 센터 네트워크 스위치가 없거나 필요하지 않은 더 작은 에지 사용 사례에도 적합합니다.
이 참조 아키텍처는 가상화된 워크로드를 배포하고 관리하기 위한 복원력 있는 인프라 플랫폼으로 Azure Stack HCI를 구성하기 위한 워크로드 관련 지침 및 권장 사항을 제공합니다. Azure Stack HCI에서 실행되도록 최적화된 워크로드 아키텍처 패턴에 대한 자세한 내용은 Azure Stack HCI 워크로드 탐색 메뉴 아래에 있는 콘텐츠를 참조하세요.
이 아키텍처는 스토리지 스위치리스 네트워킹 디자인을 사용하는 3노드 Azure Stack HCI 클러스터의 시작점입니다. Azure Stack HCI 클러스터에 배포된 워크로드 애플리케이션은 잘 설계되어야 합니다. 이 방법에는 중요한 워크로드 서비스의 고가용성을 위해 여러 인스턴스를 배포하고 일반 백업 및 DR 장애 조치 기능과 같은 적절한 BCDR(비즈니스 연속성 및 재해 복구) 제어를 구현하는 것이 포함됩니다. HCI 인프라 플랫폼에 집중하기 위해 이러한 워크로드 디자인 측면은 이 문서에서 의도적으로 제외됩니다. Azure Well-Architected Framework의 5가지 핵심 요소에 대한 지침 및 권장 사항에 대한 자세한 내용은 Azure Stack HCI Well-Architected Framework 서비스 가이드를 참조 하세요.
아티클 레이아웃
| 아키텍처 | 디자인 의사 결정 | 잘 설계된 프레임워크 접근 방식 |
|---|---|---|
| ▪ 아키텍처 다이어그램 ▪ 잠재적인 사용 사례 ▪ 이 시나리오 배포 |
▪ 클러스터 디자인 선택 ▪ 네트워킹 |
▪ 비용 최적화 ▪ 성능 효율성 |
팁
이 참조 구현에서는 ARM 템플릿 및 매개 변수 파일을 사용하여 3노드 스토리지 스위치리스 Azure Stack HCI 솔루션을 배포하는 방법을 설명합니다.
아키텍처
이러한 리소스에 대한 자세한 내용은 관련 리소스를 참조 하세요.
잠재적인 사용 사례
다음 사용 사례 요구 사항을 해결하려면 이 디자인과 Azure Stack HCI 기준 참조 아키텍처에 설명된 디자인을 사용합니다.
단일 위치에 배포된 HA(고가용성) 또는 컨테이너 기반 에지 워크로드를 배포하고 관리하여 비즈니스에 중요한 애플리케이션 및 서비스가 복원력 있고 비용 효율적이며 확장 가능한 방식으로 작동할 수 있도록 합니다.
스토리지 스위치 없는 네트워크 디자인은 스토리지 트래픽에 사용되는 네트워크 어댑터 포트를 연결하기 위해 스토리지 클래스 네트워크 스위치를 배포해야 하는 요구 사항을 제거합니다.
스토리지 스위치 없는 네트워크 디자인을 사용하여 스토리지 트래픽에 대한 스토리지 클래스 네트워크 스위치의 조달 및 구성과 관련된 비용을 줄일 수 있지만 실제 노드에 필요한 네트워크 어댑터 포트 수가 증가합니다.
아키텍처 구성 요소
아키텍처 리소스는 대부분 기준 참조 아키텍처에서 변경되지 않습니다. 자세한 내용은 Azure Stack HCI 배포에 사용되는 플랫폼 리소스 및 플랫폼 지원 리소스 를 참조하세요.
클러스터 디자인 선택
클러스터 디자인 옵션을 결정할 때 기준 참조 아키텍처를 참조하세요. 이러한 인사이트와 Azure Stack HCI Sizer 도구를 사용하여 워크로드 요구 사항에 따라 Azure Stack HCI 클러스터의 크기를 적절하게 조정합니다.
스토리지 스위치리스 디자인을 사용하는 경우 3노드 클러스터가 지원되는 최대 크기임을 기억해야 합니다. 이 제한 사항은 워크로드의 용량 요구 사항이 3노드 클러스터 사양의 물리적 용량 기능을 초과하지 않도록 해야 하기 때문에 클러스터 디자인 선택에 대한 주요 고려 사항입니다. 추가 노드 제스처를 수행하여 3개 노드를 넘어 스토리지 스위치리스 클러스터를 확장할 수 없으므로 워크로드 용량 요구 사항을 미리 이해하고 향후 성장을 계획하는 것이 매우 중요 합니다. 이렇게 하면 워크로드가 Azure Stack HCI 클러스터 하드웨어의 예상 수명 동안 스토리지 및 컴퓨팅 용량을 초과하지 않도록 할 수 있습니다.
주의
스토리지 스위치리스 네트워크 아키텍처에 대해 지원되는 최대 클러스터 크기는 3개의 실제 노드입니다. 워크로드에 대한 현재 및 향후 증가 용량 요구 사항을 포함하는 등 클러스터 디자인 단계에서 이 제한을 고려해야 합니다.
네트워크 설계
네트워크 디자인은 네트워크 내에서 물리적 및 논리적 구성 요소의 전반적인 배열을 나타냅니다. Azure Stack HCI에 대한 3노드 스토리지 스위치리스 구성에서는 스토리지 트래픽에 외부 스위치를 사용하지 않고 3개의 실제 노드가 직접 연결됩니다. 이러한 직접 상호 연결된 이더넷 연결은 스위치에서 서비스 및 우선 순위 지정 구성의 스토리지 품질을 정의하거나 적용할 필요가 없으므로 복잡성을 줄여 네트워크 설계를 간소화합니다. ECN(명시적 정체 알림), PFC(우선 순위 흐름 제어) 또는 RoCE v2 및 iWARP에 필요한 QoS(서비스 품질)와 같은 무손실 RDMA 통신을 뒷받침하는 기술은 필요하지 않습니다. 그러나 이 구성은 최대 3개의 노드를 지원하므로 배포 후에 더 많은 노드를 추가하여 클러스터의 크기를 조정할 수 없습니다.
참고 항목
이 3노드 스토리지 스위치리스 아키텍처에는 모든 네트워크 의도에 대한 중복 링크를 제공하는 6개의 네트워크 어댑터 포트 가 필요합니다. 작은 폼 팩터 하드웨어 SKU를 사용하려는 경우 또는 추가 네트워크 카드를 위해 서버 섀시에 물리적 공간이 제한된 경우 이를 고려합니다. 자세한 내용은 선호하는 하드웨어 제조업체 파트너를 참조하세요.
물리적 네트워크 토폴로지
실제 네트워크 토폴로지에서는 노드와 네트워킹 구성 요소 간의 실제 실제 연결을 보여 줍니다. 3노드 스토리지 스위치리스 Azure Stack HCI 배포를 위한 노드와 네트워킹 구성 요소 간의 연결은 다음과 같습니다.
3개 노드(또는 서버):
각 노드는 Azure Stack HCI OS에서 실행되는 물리적 서버입니다.
각 노드에는 총 6개의 네트워크 어댑터 포트(스토리지용 RDMA 지원 포트 4개, 관리 및 컴퓨팅용 포트 2개)가 필요합니다.
스토리지 트래픽:
세 노드는 각각 스토리지용 이중 전용 물리적 네트워크 어댑터 포트를 통해 상호 연결됩니다. 다음 다이어그램에서는 이 프로세스를 보여 줍니다.
스토리지 네트워크 어댑터 포트는 이더넷 케이블을 사용하여 각 노드에 직접 연결하여 스토리지 트래픽에 대한 전체 메시 네트워크 아키텍처를 형성합니다.
이 디자인은 링크 중복성, 전용 짧은 대기 시간, 높은 대역폭 및 높은 처리량을 제공합니다.
HCI 클러스터 내의 노드는 이러한 링크를 통해 직접 통신하여 동서 트래픽이라고도 하는 스토리지 복제 트래픽을 처리합니다.
이 직접 통신을 통해 스토리지에 대한 추가 네트워크 스위치 포트가 필요하지 않으며 네트워크 스위치에서 SMB Direct 또는 RDMA 트래픽에 QoS 또는 PFC 구성을 적용해야 하는 요구 사항이 제거됩니다.
스위치리스 상호 연결 네트워크 구성에 대한 권장 OS 드라이버, 펌웨어 버전 또는 펌웨어 설정은 하드웨어 제조업체 파트너 또는 NIC(네트워크 인터페이스 카드) 공급업체에 문의하세요.
이중 ToR(Top-of-Rack) 스위치:
이 구성은 스토리지 트래픽에 대해 전환되지 않지만 외부 연결을 위해 ToR 스위치가 필요합니다. 이 연결을 남북 트래픽이라고 하며 클러스터 관리 의도 및 워크로드 컴퓨팅 의도가 포함됩니다.
각 노드의 스위치에 대한 업링크는 두 개의 네트워크 어댑터 포트를 사용합니다. 이더넷 케이블은 이러한 포트를 각 ToR 스위치에 하나씩 연결하여 링크 중복성을 제공합니다.
이중 ToR 스위치를 사용하여 서비스 작업에 중복성을 제공하고 외부 통신을 위한 부하 분산을 제공하는 것이 좋습니다.
외부 연결:
이중 ToR 스위치는 내부 회사 LAN과 같은 외부 네트워크에 연결하고, 방화벽 또는 라우터와 같은 에지 테두리 네트워크 디바이스를 사용하여 필요한 아웃바운드 URL에 대한 액세스를 제공합니다.
두 ToR 스위치는 관리 및 컴퓨팅 의도와 관련된 트래픽을 포함하여 Azure Stack HCI 클러스터의 남북 트래픽을 처리합니다.
논리 네트워크 토폴로지
논리 네트워크 토폴로지에서는 물리적 연결에 관계없이 디바이스 간에 네트워크 데이터가 흐르는 방식에 대한 개요를 제공합니다. 다음 목록에는 3노드 스토리지 스위치리스 Azure Stack HCI 클러스터에 대한 논리적 설정이 요약되어 있습니다.
이중 ToR 스위치:
- 클러스터를 배포하기 전에 관리 및 컴퓨팅 포트에 필요한 VLAN ID와 MTU(최대 전송 단위) 설정을 사용하여 두 ToR 네트워크 스위치를 구성해야 합니다. 자세한 내용은 물리적 네트워크 요구 사항을 참조하거나 스위치 하드웨어 공급업체 또는 SI(시스템 통합자) 파트너에게 도움을 요청하세요.
Azure Stack HCI는 네트워크 ATC 서비스를 사용하여 네트워크 자동화 및 의도 기반 네트워크 구성을 적용합니다.
네트워크 ATC는 네트워크 트래픽 의도를 사용하여 최적의 네트워킹 구성 및 트래픽 흐름을 보장하도록 설계되었습니다. 네트워크 ATC는 클러스터 관리, 워크로드 컴퓨팅 및 클러스터 스토리지 의도와 같이 다양한 네트워크 트래픽 의도(또는 유형)에 사용되는 실제 네트워크 어댑터 포트를 정의합니다.
의도 기반 정책은 Azure Stack HCI 클라우드 배포 프로세스의 일부로 지정된 매개 변수 입력을 기반으로 노드 네트워크 구성을 자동화하여 네트워크 구성 요구 사항을 간소화합니다.
외부 통신:
노드 또는 워크로드가 회사 LAN, 인터넷 또는 다른 서비스에 액세스하여 외부에서 통신해야 하는 경우 이중 ToR 스위치를 사용하여 라우팅합니다. 이 프로세스는 이전 물리적 네트워크 토폴로지 섹션에서 설명합니다.
두 ToR 스위치가 계층 3 디바이스 역할을 하는 경우 라우팅을 처리하고 클러스터를 넘어 방화벽 또는 라우터와 같은 에지 테두리 디바이스에 대한 연결을 제공합니다.
관리 네트워크 의도는 클러스터 관리 IP 주소 및 컨트롤 플레인 리소스가 외부에서 통신할 수 있도록 하는 SET(Converged Switch Embedded Teaming) 가상 인터페이스를 사용합니다.
컴퓨팅 네트워크 의도의 경우 환경에 대한 특정 VLAN ID를 사용하여 Azure에서 하나 이상의 논리 네트워크를 만들 수 있습니다. VM(가상 머신)과 같은 워크로드 리소스는 이러한 ID를 사용하여 실제 네트워크에 대한 액세스 권한을 부여합니다. 논리 네트워크는 컴퓨팅 및 관리 의도에 SET를 사용하여 수렴되는 두 개의 실제 네트워크 어댑터 포트를 사용합니다.
스토리지 트래픽:
노드는 노드당 4개의 직접 상호 연결 이더넷 포트를 사용하여 스토리지 트래픽을 위해 서로 직접 통신합니다. 이 포트는 스토리지 트래픽에 대해 6개의 개별 비 라우팅 가능(또는 계층 2) 네트워크를 사용합니다.
Azure Stack HCI 노드 OS 내의 4개의 스토리지 의도 네트워크 어댑터 포트에 구성된 기본 게이트웨이 는 없습니다.
각 노드는 스토리지 풀, 가상 디스크 및 볼륨에서 사용되는 원격 실제 디스크와 같은 클러스터의 S2D 기능에 액세스할 수 있습니다. 이러한 기능에 대한 액세스는 각 노드에서 사용할 수 있는 두 개의 전용 스토리지 네트워크 어댑터 포트를 통해 SMB 직접 RDMA 프로토콜을 통해 촉진됩니다. SMB 다중 채널은 복원력에 사용됩니다.
이 구성은 미러된 볼륨에 대한 일관된 데이터 복사본 유지 관리와 같은 스토리지 관련 작업에 충분한 데이터 전송 속도를 보장합니다.
IP 주소 요구 사항
스토리지 상호 연결에 대한 이중 링크가 있는 Azure Stack HCI의 3노드 스토리지 스위치리스 구성을 배포하려면 클러스터 인프라 플랫폼에서 최소 20 x IP 주소를 할당해야 합니다. 하드웨어 제조업체 파트너가 제공하는 VM 어플라이언스를 사용하거나 마이크로 세그멘션 또는 SDN(소프트웨어 정의 네트워킹)을 사용하는 경우 더 많은 IP 주소가 필요합니다. 자세한 내용은 Azure Stack HCI에 대한 3노드 스토리지 참조 패턴 IP 요구 사항 검토를 참조 하세요.
Azure Stack HCI에 대한 IP 주소 요구 사항을 설계하고 계획할 때는 Azure Stack HCI 클러스터 및 인프라 구성 요소에 필요한 것 이상으로 워크로드에 필요한 추가 IP 주소 또는 네트워크 범위를 고려해야 합니다. Azure Stack HCI에서 AKS(Azure Kubernetes Services)를 사용하려는 경우 Azure Arc 네트워크 요구 사항에 따라 사용하도록 설정된 AKS를 참조 하세요.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
Important
Azure Stack HCI 기준 참조 아키텍처에 설명된 잘 설계된 프레임워크 고려 사항을 검토합니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
비용 최적화 고려 사항은 다음과 같습니다.
- 스위치리스 클러스터 상호 연결 및 스위치 기반 클러스터 상호 연결 스위치리스 상호 연결 토폴로지 전체 메시를 형성하기 위해 각 노드의 이중 포트 또는 중복 RDMA 지원 네트워크 어댑터 포트 간의 연결로 구성됩니다. 각 노드에는 다른 모든 노드에 대한 두 개의 직접 연결이 있습니다. 이 구현은 간단하지만 2노드 또는 3노드 클러스터에서만 지원됩니다. 4개 이상의 노드가 있는 Azure Stack HCI 클러스터에는 스토리지 전환된 네트워크 아키텍처가 필요합니다. 이 아키텍처를 사용하여 추가 노드 작업을 지원하지 않는 스토리지 스위치리스 디자인과 달리 배포 후에 더 많은 노드를 추가할 수 있습니다.
성능 효율성
성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.
성능 효율성 고려 사항은 다음과 같습니다.
- 클러스터를 다시 배포하고 스토리지 트래픽에 대한 네트워크 스위치, 포트 및 케이블 및 기타 필수 노드와 같은 추가 네트워킹 기능을 추가하지 않고는 기존 3노드 스토리지 스위치 없는 HCI 클러스터의 확장(또는 추가 노드 작업 수행)을 늘릴 수 없습니다. 세 개의 노드는 스토리지 스위치리스 네트워크 디자인에 대해 지원되는 최대 클러스터 크기입니다. 하드웨어가 향후 워크로드 용량 증가를 지원할 수 있도록 클러스터 디자인 단계에 이 제한을 적용합니다.
시나리오 배포
Azure Stack HCI 솔루션을 디자인, 조달 및 배포하는 방법에 대한 자세한 내용은 Azure Stack HCI 기준 참조 아키텍처의 이 시나리오 배포 섹션을 참조하세요.
3노드 스토리지 스위치리스 아키텍처를 사용하여 Azure Stack HCI를 배포하는 방법의 예로 다음 배포 자동화 템플릿을 사용합니다.
팁
배포 자동화: 이 참조 템플릿은 ARM 템플릿 및 매개 변수 파일을 사용하여 3노드 스토리지 스위치리스 Azure Stack HCI 솔루션을 배포하는 방법을 설명합니다.
관련 참고 자료
- 하이브리드 아키텍처 디자인
- Azure 하이브리드 옵션
- 하이브리드 환경의 Azure Automation
- Azure Automation 상태 구성
- Azure Arc를 사용하여 온-프레미스 및 다중 클라우드 환경에서 SQL Server 인스턴스 관리를 최적화합니다.
다음 단계
제품 설명서:
- Azure Stack HCI 버전 23H2 릴리스 정보
- Azure Stack HCI의 AKS
- Azure Stack HCI용 Azure Virtual Desktop
- Azure Stack HCI 모니터링이란?
- Azure Stack HCI에서 Site Recovery를 사용하여 VM 워크로드 보호
- Azure Monitor 개요
- 변경 내용 추적 및 인벤토리 개요
- Azure Update Manager 개요
- Azure Arc 지원 데이터 서비스란?
- Azure Arc 지원 서버란?
- Azure Backup이란?
- Azure Machine Learning의 Kubernetes 컴퓨팅 대상 소개
특정 Azure 서비스에 대한 제품 설명서:
- Azure Stack HCI
- Azure Arc
- Azure Key Vault
- Azure Blob Storage
- 모니터
- Azure Policy
- Azure Container Registry
- Microsoft Defender for Cloud
- Azure Site Recovery
- Backup
Microsoft Learn 모듈:
- 모니터 구성
- Azure에서 사이트 복구 솔루션 디자인
- Azure Arc 지원 서버 소개
- Azure Arc 지원 데이터 서비스 소개
- AKS 소개
- 어디서나 Azure Machine Learning을 사용하여 모델 배포 크기 조정 - 기술 커뮤니티 블로그
- AKS 및 Arc 지원 기계 학습을 사용하여 어디서나 Machine Learning 실현 - 기술 커뮤니티 블로그
- Azure Arc 지원 기계 학습을 사용하는 AKS 하이브리드 및 Stack HCI의 기계 학습 - 기술 커뮤니티 블로그
- 가상 머신 업데이트 유지
- Azure Automation 상태 구성을 사용하여 가상 머신 설정 보호
- Backup을 사용하여 VM 보호