Azure Stack HCI 기준 참조 아키텍처

이 기준 참조 아키텍처는 고가용성 가상화 및 컨테이너화된 워크로드를 배포하고 관리할 수 있는 신뢰할 수 있는 플랫폼을 보장하기 위해 Azure Stack HCI 23H2 이상 인프라를 구성하기 위한 워크로드 관련 지침 및 권장 사항을 제공합니다. 이 아키텍처는 로컬 컴퓨팅, 스토리지 및 네트워킹 기능을 제공하는 물리적 노드에 대한 리소스 구성 요소 및 클러스터 디자인 선택에 대해 설명합니다. 또한 Azure 서비스를 사용하여 Azure Stack HCI의 일상적인 관리를 간소화하고 간소화하는 방법을 설명합니다.

Azure Stack HCI에서 실행되도록 최적화된 워크로드 아키텍처 패턴에 대한 자세한 내용은 Azure Stack HCI 워크로드 탐색 메뉴에 있는 콘텐츠를 참조하세요.

이 아키텍처는 스토리지 전환된 네트워크 디자인을 사용하여 다중 노드 Azure Stack HCI 클러스터를 배포하는 방법에 대한 시작점입니다. Azure Stack HCI 클러스터에 배포된 워크로드 애플리케이션은 잘 설계되어야 합니다. 잘 설계된 워크로드 애플리케이션은 중요한 워크로드 서비스의 여러 인스턴스 또는 고가용성을 사용하여 배포해야 하며 적절한 BCDR(비즈니스 연속성 및 재해 복구) 제어가 있어야 합니다. 이러한 BCDR 컨트롤에는 정기적인 백업 및 재해 복구 장애 조치(failover) 기능이 포함됩니다. HCI 인프라 플랫폼에 집중하기 위해 이러한 워크로드 디자인 측면은 이 문서에서 의도적으로 제외됩니다.

Azure Well-Architected Framework의 5가지 핵심 요소에 대한 지침 및 권장 사항에 대한 자세한 내용은 Azure Stack HCI Well-Architected Framework 서비스 가이드를 참조 하세요.

아티클 레이아웃

아키텍처

자세한 내용은 관련 리소스를 참조 하세요.

잠재적인 사용 사례

Azure Stack HCI의 일반적인 사용 사례에는 워크로드 요구 사항을 해결하기 위한 솔루션을 제공하는 온-프레미스 또는 에지 위치에서 HA(고가용성) 워크로드를 실행하는 기능이 포함됩니다. 마케팅 목록의 구성원을 관리할 수 있습니다.

• 온-프레미스에 배포된 하이브리드 클라우드 솔루션을 제공하여 데이터 주권, 규정 및 규정 준수 또는 대기 시간 요구 사항을 해결합니다.

• 단일 위치 또는 여러 위치에 배포되는 HA 가상화 또는 컨테이너 기반 에지 워크로드를 배포하고 관리합니다. 이 전략을 사용하면 비즈니스에 중요한 애플리케이션 및 서비스가 복원력 있고 비용 효율적이며 확장 가능한 방식으로 작동할 수 있습니다.

• Microsoft, 클라우드 기반 배포, 중앙 집중식 관리, 모니터링 및 경고에서 인증된 솔루션을 사용하여 TCO(총 소유 비용)를 낮춥니다.

• Azure 및 Azure Arc를 사용하여 여러 위치에 워크로드를 일관되고 안전하게 배포하여 중앙 집중식 프로비저닝 기능을 제공합니다. Azure Portal, Azure CLI 또는 IaC(Infrastructure as Code) 템플릿과 같은 도구는 컨테이너화 또는 기존 워크로드 가상화에 Kubernetes를 사용하여 자동화 및 반복성을 구동합니다.

• 엄격한 보안, 규정 준수 및 감사 요구 사항을 준수합니다. Azure Stack HCI는 기본적으로 구성된 강화된 보안 상태 또는 기본적으로 보안 상태를 사용하여 배포됩니다. Azure Stack HCI는 인증된 하드웨어, 보안 부팅, TPM(신뢰할 수 있는 플랫폼 모듈), VBS(가상화 기반 보안), Credential Guard 및 적용된 Windows Defender 애플리케이션 제어 정책을 통합합니다. 또한 클라우드용 Microsoft Defender 및 Microsoft Sentinel과 같은 최신 클라우드 기반 보안 및 위협 관리 서비스와 통합됩니다.

시나리오 정보

다음 섹션에서는 이 참조 아키텍처에 대한 시나리오 및 잠재적 사용 사례에 대한 자세한 정보를 제공합니다. 이러한 섹션에는 Azure Stack HCI에 배포할 수 있는 비즈니스 이점 및 예제 워크로드 리소스 종류 목록이 포함되어 있습니다.

Azure Stack HCI에서 Azure Arc 사용

Azure Stack HCI는 Azure Arc를 사용하여 TCO 및 운영 오버헤드를 줄여 Azure와 직접 통합됩니다. Azure Stack HCI는 Azure를 통해 배포 및 관리되며, Azure Arc 리소스 브리지 구성 요소의 배포를 통해 Azure Arc의 기본 제공 통합을 제공합니다. 이 구성 요소는 HCI 클러스터 배포 프로세스 중에 설치됩니다. Azure Stack HCI 클러스터 노드는 클러스터의 클라우드 기반 배포를 시작하기 위한 필수 조건으로 서버용 Azure Arc에 등록됩니다. 배포하는 동안 수명 주기 관리자, Microsoft Edge 장치 관리, 원격 분석 및 진단과 같은 필수 확장이 각 클러스터 노드에 설치됩니다. Azure Monitor 및 Log Analytics를 사용하여 Azure Stack HCI Insights를 사용하도록 설정하여 배포 후 HCI 클러스터를 모니터링할 수 있습니다. Azure Stack HCI 에 대한 기능 업데이트는 고객 환경을 향상시키기 위해 주기적으로 릴리스됩니다. 업데이트는 Azure Update Manager를 통해 제어 및 관리됩니다.

워크로드 배포의 대상으로 Azure Stack HCI 클러스터 사용자 지정 위치를 선택하여 Azure Portal을 사용하는 Azure Arc VM(가상 머신), Azure Arc 지원 AKS(Azure Kubernetes Service) 및 Azure Virtual Desktop 세션 호스트와 같은 워크로드 리소스를 배포할 수 있습니다. 이러한 구성 요소는 중앙 집중식 관리, 관리 및 지원을 제공합니다. 기존 Windows Server Datacenter 핵심 라이선스에 대해 Active Software Assurance가 있는 경우 Azure Stack HCI, Windows Server VM 및 AKS 클러스터에 Azure 하이브리드 혜택 적용하여 비용을 추가로 절감할 수 있습니다. 이 최적화는 이러한 서비스에 대한 비용을 효과적으로 관리하는 데 도움이 됩니다.

Azure 및 Azure Arc 통합은 다음을 포함하도록 Azure Stack HCI 가상화 및 컨테이너화된 워크로드의 기능을 확장합니다.

• Azure Stack HCI의 VM에서 실행되는 기존 애플리케이션 또는 서비스에 대한 Azure Arc VM입니다.

• Kubernetes를 오케스트레이션 플랫폼으로 사용하면 도움이 되는 컨테이너화된 애플리케이션 또는 서비스에 대한 Azure Stack HCI 의 AKS입니다.

• Azure Virtual Desktop 을 사용하여 Azure Stack HCI(온-프레미스)에서 Azure Virtual Desktop 워크로드에 대한 세션 호스트를 배포합니다. Azure에서 컨트롤 및 관리 평면을 사용하여 호스트 풀 만들기 및 구성을 시작할 수 있습니다.

• 컨테이너화된 Azure SQL Managed Instance 또는 Azure Stack HCI에서 호스트되는 Azure Arc 지원 AKS를 사용하는 Azure Database for PostgreSQL 서버에 대한 Azure Arc 지원 데이터 서비스 입니다.

• Event Grid broker 및 Event Grid 연산자 구성 요소를 배포하기 위한 Kubernetes용 Azure Arc 지원 Azure Event Grid 확장입니다. 이 배포를 사용하면 이벤트 처리를 위해 Event Grid 토픽 및 구독과 같은 기능을 사용할 수 있습니다.

• Azure Machine Learning을 실행하는 컴퓨팅 대상으로 Azure Stack HCI에 배포된 AKS 클러스터를 사용하여 Azure Arc 지원 기계 학습 이 방법을 사용하여 에지에서 기계 학습 모델을 학습하거나 배포할 수 있습니다.

Azure Arc 연결 워크로드는 Azure Arc VM 확장을 사용하여 게스트 OS 구성을 자동화하거나 Azure Policy를 통해 업계 규정 또는 회사 표준 준수를 평가하는 등 Azure Stack HCI 배포를 위한 향상된 Azure 일관성 및 자동화를 제공합니다. Azure Portal 또는 IaC 자동화를 통해 Azure Policy를 활성화할 수 있습니다.

Azure Stack HCI 기본 보안 구성 활용

Azure Stack HCI 기본 보안 구성은 보안 및 규정 준수 비용을 간소화하기 위한 심층 방어 전략을 제공합니다. 소매, 제조 및 원격 사무실 시나리오를 위한 IT 서비스의 배포 및 관리는 고유한 보안 및 규정 준수 과제를 제시합니다. IT 지원이 제한되거나 데이터 센터가 부족하거나 전용 데이터 센터가 없는 환경에서는 내부 및 외부 위협에서 워크로드를 보호하는 것이 중요합니다. Azure Stack HCI에는 이러한 문제를 해결하는 데 도움이 되는 기본 보안 강화 및 Azure 서비스와의 긴밀한 통합이 있습니다.

Azure Stack HCI 인증 하드웨어는 기본 제공 보안 부팅, UEFI(Unified Extensible Firmware Interface) 및 TPM 지원을 보장합니다. 이러한 기술을 VBS와 함께 사용하여 보안에 민감한 워크로드를 보호합니다. BitLocker 드라이브 암호화를 사용하여 부팅 디스크 볼륨 및 스토리지 공간 다이렉트 볼륨을 암호화할 수 있습니다. SMB(서버 메시지 블록) 암호화는 클러스터(스토리지 네트워크)의 서버 간 트래픽 자동 암호화와 클러스터 노드와 다른 시스템 간의 SMB 트래픽 서명을 제공합니다. SMB 암호화는 릴레이 공격을 방지하고 규정 표준을 쉽게 준수하도록 도와줍니다.

클라우드용 Defender Azure Stack HCI VM을 온보딩하여 클라우드 기반 동작 분석, 위협 감지 및 수정, 경고 및 보고를 활성화할 수 있습니다. Azure Policy를 사용하여 업계 규정 및 회사 표준 준수를 평가할 수 있도록 Azure Arc에서 Azure Stack HCI VM을 관리합니다.

구성 요소

이 아키텍처는 온-프레미스 또는 에지 위치에 Azure Stack HCI 클러스터를 배포하는 데 사용할 수 있는 물리적 서버 하드웨어로 구성됩니다. 플랫폼 기능을 향상시키기 위해 Azure Stack HCI는 지원 리소스를 제공하는 Azure Arc 및 기타 Azure 서비스와 통합됩니다. Azure Stack HCI는 사용자 애플리케이션 또는 비즈니스 시스템을 배포, 관리 및 운영하는 복원력 있는 플랫폼을 제공합니다. 플랫폼 리소스 및 서비스는 다음 섹션에 설명되어 있습니다.

플랫폼 리소스

아키텍처에는 다음과 같은 필수 리소스 및 구성 요소가 필요합니다.

• Azure Stack HCI 는 물리적 서버 하드웨어 및 네트워킹 인프라를 사용하여 온-프레미스 또는 에지 위치에 배포되는 HCI(하이퍼 컨버지드 인프라) 솔루션입니다. Azure Stack HCI는 VM, Kubernetes 클러스터 및 Azure Arc에서 사용하도록 설정된 기타 서비스와 같은 가상화된 워크로드를 배포하고 관리하는 플랫폼을 제공합니다. Azure Stack HCI 클러스터는 OEM(원래 장비 제조업체) 파트너가 제공하는 유효성 검사, 통합 또는 프리미엄 하드웨어 범주를 사용하여 단일 노드 배포에서 최대 16개의 노드로 확장할 수 있습니다.

• Azure Arc 는 Azure Resource Manager를 기반으로 관리 모델을 Azure Stack HCI 및 기타 비 Azure 위치로 확장하는 클라우드 기반 서비스입니다. Azure Arc는 Azure를 제어 및 관리 평면으로 사용하여 VM, Kubernetes 클러스터, 컨테이너화된 데이터 및 기계 학습 서비스와 같은 다양한 리소스를 관리할 수 있도록 합니다.

• Azure Key Vault 는 비밀을 안전하게 저장하고 액세스하는 데 사용할 수 있는 클라우드 서비스입니다. 비밀은 API 키, 암호, 인증서, 암호화 키, 로컬 관리자 자격 증명 및 BitLocker 복구 키와 같이 액세스를 엄격하게 제한하려는 모든 항목입니다.

• 클라우드 감시 는 장애 조치(failover) 클러스터 쿼럼 역할을 하는 Azure Storage의 기능입니다. Azure Stack HCI 클러스터 노드는 이 쿼럼을 투표에 사용하여 클러스터의 고가용성을 보장합니다. 스토리지 계정 및 감시 구성은 Azure Stack HCI 클라우드 배포 프로세스 중에 만들어집니다.

• Update Manager 는 Azure Stack HCI에 대한 업데이트를 관리하고 관리하도록 설계된 통합 서비스입니다. 업데이트 관리자를 사용하여 Windows 및 Linux VM에 대한 게스트 OS 업데이트 규정 준수를 포함하여 Azure Stack HCI에 배포된 워크로드를 관리할 수 있습니다. 이 통합 접근 방식은 단일 대시보드를 통해 Azure, 온-프레미스 환경 및 기타 클라우드 플랫폼에서 패치 관리를 간소화합니다.

플랫폼 지원 리소스

이 아키텍처에는 플랫폼의 기능을 향상시키기 위한 다음과 같은 선택적 지원 서비스가 포함되어 있습니다.

• Monitor 는 클라우드 및 온-프레미스 워크로드에서 진단 로그 및 원격 분석을 수집, 분석 및 작동하기 위한 클라우드 기반 서비스입니다. 모니터를 사용하여 포괄적인 모니터링 솔루션을 통해 애플리케이션 및 서비스의 가용성과 성능을 최대화할 수 있습니다. Azure Stack HCI Insights를 배포하여 DCR(모니터 데이터 수집 규칙) 만들기를 간소화하고 Azure Stack HCI 클러스터의 모니터링을 신속하게 사용하도록 설정합니다.

• Azure Policy 는 Azure 및 온-프레미스 리소스를 평가하는 서비스입니다. Azure Policy는 정책 정의라고 하는 비즈니스 규칙에 해당 리소스의 속성을 사용하여 Azure Arc와의 통합을 통해 리소스를 평가하여 정책 설정을 사용하여 VM 게스트 구성을 적용하는 데 사용할 수 있는 규정 준수 또는 기능을 결정합니다.

• 클라우드용 Defender 포괄적인 인프라 보안 관리 시스템입니다. 데이터 센터의 보안 태세를 향상시키고 하이브리드 워크로드에 대한 고급 위협 방지 기능을 제공합니다. Azure에 있든 다른 곳에 있든 온-프레미스 환경에 상주하든 관계없이.

• Azure Backup 은 데이터를 백업하고 Microsoft Cloud에서 복구하는 간단하고 안전하며 비용 효율적인 솔루션을 제공하는 클라우드 기반 서비스입니다. Azure Backup Server는 Azure Stack HCI에 배포된 VM의 백업을 수행하고 Backup 서비스에 저장하는 데 사용됩니다.

• Site Recovery 는 재해 또는 중단이 있는 경우 비즈니스 앱 및 워크로드가 장애 조치(failover)되도록 하여 BCDR 기능을 제공하는 재해 복구 서비스입니다. Site Recovery는 기본 사이트(온-프레미스)와 보조 위치(Azure) 간에 물리적 서버 및 VM에서 실행되는 워크로드의 복제 및 장애 조치(failover)를 관리합니다.

클러스터 디자인 선택

Azure Stack HCI 클러스터를 설계할 때 워크로드 성능 및 복원력 요구 사항을 이해하는 것이 중요합니다. 이러한 요구 사항에는 Azure Stack HCI 클러스터에 배포된 모든 워크로드에 대한 RTO(복구 시간 목표) 및 RPO(복구 지점 목표) 시간, 컴퓨팅(CPU), 메모리 및 스토리지 요구 사항이 포함됩니다. 워크로드의 몇 가지 특성은 의사 결정 프로세스에 영향을 미치며 다음을 포함합니다.

• 하드웨어 보안 기술 기능, CPU 수, GHz 주파수(속도) 및 CPU 소켓당 코어 수를 비롯한 CPU(중앙 처리 장치) 아키텍처 기능.

• AI 또는 기계 학습, 추론 또는 그래픽 렌더링과 같은 워크로드의 GPU(그래픽 처리 장치) 요구 사항입니다.

• 노드당 메모리 또는 워크로드를 실행하는 데 필요한 실제 메모리의 양입니다.

• 규모가 1~16개인 클러스터의 실제 노드 수입니다. 스토리지 스위치리스 네트워크 아키텍처를 사용하는 경우 최대 노드 수는 3개입니다.

  • 컴퓨팅 복원력을 유지하려면 클러스터에서 N+1 개 이상의 노드 용량을 예약해야 합니다. 이 전략을 사용하면 정전 또는 하드웨어 오류와 같은 갑작스런 중단으로 인한 업데이트 또는 복구를 위해 노드 드레이닝이 가능합니다.

  • 중요 비즈니스용 또는 중요 업무용 워크로드의 경우 N+2 노드 용량을 예약하여 복원력을 높이는 것이 좋습니다. 예를 들어 클러스터의 두 노드가 오프라인 상태이면 워크로드가 온라인 상태로 유지될 수 있습니다. 이 방법은 계획된 업데이트 절차 중에 워크로드를 실행하는 노드가 오프라인 상태가 되고 두 노드가 동시에 오프라인 상태가 되는 시나리오에 대한 복원력을 제공합니다.

• 스토리지 복원력, 용량 및 성능 요구 사항:

  • 복원력: 인프라 및 사용자 볼륨에 대해 데이터의 복사본 3개를 제공하는 3방향 미러링을 사용하도록 설정하려면 3개 이상의 노드를 배포하는 것이 좋습니다. 3방향 미러링으로 스토리지의 성능과 최대 안정성이 향상됩니다.

  • 용량: 내결함성 또는 복사본 후 필요한 총 사용 가능한 스토리지를 고려합니다. 이 숫자는 3방향 미러링을 사용하는 경우 용량 계층 디스크의 원시 스토리지 공간의 약 33%입니다.

  • 성능: 애플리케이션의 블록 크기를 곱할 때 워크로드에 대한 스토리지 처리량 기능을 결정하는 플랫폼의 IOPS(초당 입력/출력 작업)입니다.

Azure Stack HCI 배포를 디자인하고 계획하려면 Azure Stack HCI 크기 조정 도구를 사용하고 HCI 클러스터 크기를 조정하기 위한 새 프로젝트를 만드는 것이 좋습니다. 크기 조정 도구를 사용하려면 워크로드 요구 사항을 이해해야 합니다. 클러스터에서 실행되는 워크로드 VM의 수와 크기를 고려할 때 vCPU 수, 메모리 요구 사항 및 VM에 필요한 스토리지 용량과 같은 요소를 고려해야 합니다.

크기 조정 도구 기본 설정 섹션에서는 시스템 유형(프리미어, 통합 시스템 또는 유효성 검사된 노드) 및 CPU 제품군 옵션과 관련된 질문을 안내합니다. 또한 클러스터에 대한 복원력 요구 사항을 선택하는 데 도움이 됩니다. 다음을 수행해야 합니다.

• 클러스터 전체에서 최소 N+1 노드 또는 하나의 노드를 예약합니다.

• 추가 복원력을 위해 클러스터 전체에서 N+2 노드 용량을 예약합니다. 이 옵션을 사용하면 시스템이 두 노드에 동시에 영향을 주는 업데이트 또는 기타 예기치 않은 이벤트 중에 노드 오류를 견딜 수 있습니다. 또한 나머지 온라인 노드에서 워크로드를 실행할 수 있는 충분한 용량이 클러스터에 있는지 확인합니다.

이 시나리오에서는 사용자 볼륨에 대해 3방향 미러링을 사용해야 하며, 이는 3개 이상의 실제 노드가 있는 클러스터의 기본값입니다.

Azure Stack HCI 크기 조정 도구의 출력은 Sizer Project의 입력 값에 따라 필요한 워크로드 용량 및 플랫폼 복원력 요구 사항을 제공할 수 있는 권장 하드웨어 솔루션 SKU 목록입니다. 사용 가능한 OEM 하드웨어 파트너 솔루션에 대한 자세한 내용은 Azure Stack HCI 솔루션 카탈로그를 참조 하세요. 요구 사항을 충족하기 위해 솔루션 SKU의 권한을 부여하려면 선호하는 하드웨어 솔루션 공급자 또는 SI(시스템 통합) 파트너에게 문의하세요.

실제 디스크 드라이브

저장소 공간 Direct는 성능 및 용량에 따라 달라지는 여러 실제 디스크 드라이브 유형을 지원합니다. Azure Stack HCI 클러스터를 디자인할 때 선택한 하드웨어 OEM 파트너와 협력하여 워크로드의 용량 및 성능 요구 사항을 충족하는 가장 적절한 실제 디스크 드라이브 유형을 결정합니다. 예를 들어 HDD(하드 디스크 드라이브) 또는 SSD(반도체 드라이브) 및 NVMe 드라이브가 있습니다. 이러한 드라이브를 플래시 드라이브 또는 SCM(스토리지 클래스 메모리)이라고 하는 PMem(영구 메모리) 스토리지라고도 합니다.

플랫폼의 안정성은 물리적 디스크 유형과 같은 중요한 플랫폼 종속성의 성능에 따라 달라집니다. 요구 사항에 적합한 디스크 유형을 선택해야 합니다. 고성능 또는 짧은 대기 시간 요구 사항이 있는 워크로드에는 NVMe 또는 SSD 드라이브와 같은 모든 플래시 스토리지 솔루션을 사용합니다. 이러한 워크로드는 높은 트랜잭션 데이터베이스 기술, 프로덕션 AKS 클러스터 또는 대기 시간이 짧거나 처리량이 높은 스토리지 요구 사항이 있는 중요 업무용 또는 중요 비즈니스용 워크로드를 포함하지만 이에 국한되지 않습니다. 모든 플래시 배포를 사용하여 스토리지 성능을 최대화합니다. 모든 NVMe 드라이브 또는 모든 SSD 드라이브 구성은 특히 소규모에서 스토리지 효율성을 향상시키고 캐시 계층으로 사용되는 드라이브가 없으므로 성능을 최대화합니다. 자세한 내용은 All-flash 기반 스토리지를 참조하세요.

범용 워크로드의 경우 NVMe 드라이브 또는 캐시용 SSD 및 용량용 HDD와 같은 하이브리드 스토리지 구성은 더 많은 스토리지 공간을 제공할 수 있습니다. 단점은 워크로드가 캐시 작업 집합을 초과하고 HDD가 NVMe 및 SSD 드라이브에 비해 실패 값 사이의 평균 시간이 낮을 경우 회전 디스크의 성능이 낮다는 것입니다.

클러스터 스토리지의 성능은 각 드라이브 유형의 성능 특성 및 선택한 캐싱 메커니즘에 따라 달라지는 실제 디스크 드라이브 형식의 영향을 받습니다. 실제 디스크 드라이브 유형은 모든 저장소 공간 직접 디자인 및 구성의 필수적인 부분입니다. Azure Stack HCI 워크로드 요구 사항 및 예산 제약 조건에 따라 성능을 최대화하거나, 용량을 최대화하거나, 성능과 용량의 균형을 맞추는 혼합 드라이브 형식 구성을 구현하도록 선택할 수 있습니다.

저장소 공간 Direct는 스토리지 성능을 최대화하는 기본 제공 영구, 실시간 읽기, 쓰기, 서버 쪽 캐시를 제공합니다. 애플리케이션 및 워크로드의 작업 세트를 수용할 수 있도록 캐시를 크기 조정하고 구성해야 합니다. 저장소 공간 직접 가상 디스크 또는 볼륨은 특히 워크로드 VHD(가상 하드 디스크) 또는 VHDX(가상 하드 디스크 v2) 파일에 대한 버퍼되지 않은 입력 액세스의 경우 Hyper-V 성능을 향상시키기 위해 CSV(클러스터 공유 볼륨) 메모리 내 읽기 캐시와 함께 사용됩니다.

네트워크 설계

네트워크 디자인은 네트워크의 물리적 인프라 및 논리적 구성 내에서 구성 요소의 전반적인 배열입니다. 관리, 컴퓨팅 및 스토리지 네트워크 의도의 모든 조합에 동일한 실제 NIC(네트워크 인터페이스 카드) 포트를 사용할 수 있습니다. 모든 의도 관련 목적을 위해 동일한 NIC 포트를 사용하는 것을 완전히 수렴된 네트워킹 구성이라고 합니다.

완전히 수렴된 네트워킹 구성이 지원되지만 성능 및 안정성을 위한 최적의 구성은 스토리지 의도에서 전용 네트워크 어댑터 포트를 사용하는 것입니다. 따라서 이 기준 아키텍처는 관리 및 컴퓨팅 의도를 위해 수렴되는 두 개의 네트워크 어댑터 포트와 스토리지 의도에 대한 두 개의 전용 네트워크 어댑터 포트가 있는 스토리지 전환 네트워크 아키텍처를 사용하여 다중 노드 Azure Stack HCI 클러스터를 배포하는 방법에 대한 예제 지침을 제공합니다. 자세한 내용은 Azure Stack HCI의 클라우드 배포에 대한 네트워크 고려 사항을 참조 하세요.

이 아키텍처에는 2개 이상의 실제 노드와 최대 16개의 노드 규모가 필요합니다. 각 노드에는 두 개의 ToR(Top-of-Rack) 스위치에 연결된 4개의 네트워크 어댑터 포트가 필요합니다. 두 ToR 스위치는 MLAG(다중 섀시 링크 집계 그룹) 링크를 통해 상호 연결되어야 합니다. 스토리지 의도 트래픽에 사용되는 두 개의 네트워크 어댑터 포트는 RDMA(원격 직접 메모리 액세스)를 지원해야 합니다. 이러한 포트에는 최소 연결 속도 10Gbps가 필요하지만 25Gbps 이상의 속도를 권장합니다. 관리 및 컴퓨팅 의도에 사용되는 두 개의 네트워크 어댑터 포트는 SET(스위치 포함 팀) 기술을 사용하여 수렴됩니다. SET 기술은 링크 중복성 및 부하 분산 기능을 제공합니다. 이러한 포트에는 최소 연결 속도 1Gbps가 필요하지만 10Gbps 이상의 속도를 권장합니다.

물리적 네트워크 토폴로지

다음 물리적 네트워크 토폴로지에서는 노드와 네트워킹 구성 요소 간의 실제 물리적 연결을 보여 줍니다.

이 기준 아키텍처를 사용하는 다중 노드 스토리지 전환 Azure Stack HCI 배포를 디자인할 때 다음 구성 요소가 필요합니다.

• 이중 ToR 스위치:

  • 이중 ToR 네트워크 스위치는 네트워크 복원력과 가동 중지 시간 없이 스위치에 펌웨어 업데이트를 서비스하거나 적용하는 기능에 필요합니다. 이 전략은 SPoF(단일 실패 지점)를 방지합니다.

  • 이중 ToR 스위치는 스토리지 또는 동서 트래픽에 사용됩니다. 이러한 스위치는 손실 없는 RDMA 통신을 제공하도록 정의된 특정 스토리지 VLAN(가상 로컬 영역 네트워크) 및 PFC(우선 순위 흐름 제어) 트래픽 클래스가 있는 두 개의 전용 이더넷 포트를 사용합니다.

  • 이러한 스위치는 이더넷 케이블을 통해 노드에 연결됩니다.

• 두 개 이상의 실제 노드와 최대 16개의 노드:

  • 각 노드는 Azure Stack HCI OS를 실행하는 물리적 서버입니다.

  • 각 노드에는 총 4개의 네트워크 어댑터 포트가 필요합니다. 즉, 스토리지용 RDMA 지원 포트 2개와 관리 및 컴퓨팅 트래픽을 위한 두 개의 네트워크 어댑터 포트가 필요합니다.

  • 스토리지는 두 ToR 스위치 각각에 대한 하나의 경로로 연결하는 두 개의 전용 RDMA 지원 네트워크 어댑터 포트를 사용합니다. 이 방법은 SMB 직접 스토리지 트래픽에 대한 링크 경로 중복성 및 전용 우선 순위 대역폭을 제공합니다.

  • 관리 및 컴퓨팅은 링크 경로 중복성을 위해 두 ToR 스위치 각각에 하나의 경로를 제공하는 두 개의 네트워크 어댑터 포트를 사용합니다.

• 외부 연결:

  • 이중 ToR 스위치는 내부 회사 LAN과 같은 외부 네트워크에 연결하여 에지 테두리 네트워크 디바이스를 사용하여 필요한 아웃바운드 URL에 대한 액세스를 제공합니다. 이 디바이스는 방화벽 또는 라우터일 수 있습니다. 이러한 스위치는 Azure Stack HCI 클러스터 또는 남북 트래픽을 오가는 경로 트래픽을 전환합니다.

  • 외부 남북 트래픽 연결은 클러스터 관리 의도 및 컴퓨팅 의도를 지원합니다. 이는 복원력을 보장하기 위해 스위치 포함 팀(SET)과 Hyper-V 내의 가상 스위치를 통해 수렴되는 노드당 두 개의 스위치 포트와 두 개의 네트워크 어댑터 포트를 사용하여 수행됩니다. 이러한 구성 요소는 Azure Portal, CLI 또는 IaC 템플릿을 사용하여 Resource Manager에서 만든 논리 네트워크 내에 배포된 Azure Arc VM 및 기타 워크로드 리소스에 대한 외부 연결을 제공하기 위해 작동합니다.

논리 네트워크 토폴로지

논리 네트워크 토폴로지에서는 물리적 연결에 관계없이 디바이스 간에 네트워크 데이터가 흐르는 방식에 대한 개요를 보여 줍니다.

Azure Stack HCI에 대한 이 다중 노드 스토리지 전환 기준 아키텍처에 대한 논리적 설정 요약은 다음과 같습니다.

• 이중 ToR 스위치:

  • 클러스터를 배포하기 전에 필요한 VLAN ID, 최대 전송 단위 설정 및 관리, 컴퓨팅 및 스토리지 포트에 대한 데이터 센터 브리징 구성으로 두 ToR 네트워크 스위치를 구성해야 합니다. 자세한 내용은 Azure Stack HCI에 대한 물리적 네트워크 요구 사항을 참조하거나 스위치 하드웨어 공급업체 또는 SI 파트너에게 도움을 요청하세요.

• Azure Stack HCI는 네트워크 ATC 접근 방식을 사용하여 네트워크 자동화 및 의도 기반 네트워크 구성을 적용합니다.

  • 네트워크 ATC는 네트워크 트래픽 의도를 사용하여 최적의 네트워킹 구성 및 트래픽 흐름을 보장하도록 설계되었습니다. 네트워크 ATC는 클러스터 관리, 워크로드 컴퓨팅 및 클러스터 스토리지 의도와 같이 다양한 네트워크 트래픽 의도(또는 유형)에 사용되는 실제 네트워크 어댑터 포트를 정의합니다.

  • 의도 기반 정책은 Azure Stack HCI 클라우드 배포 프로세스의 일부로 지정된 매개 변수 입력을 기반으로 노드 네트워크 구성을 자동화하여 네트워크 구성 요구 사항을 간소화합니다.

• 외부 통신:

  • 노드 또는 워크로드가 회사 LAN, 인터넷 또는 다른 서비스에 액세스하여 외부에서 통신해야 하는 경우 이중 ToR 스위치를 사용하여 라우팅합니다. 이 프로세스는 이전 실제 네트워크 토폴로지 섹션에 설명되어 있습니다.

  • 두 ToR 스위치가 계층 3 디바이스 역할을 하는 경우 라우팅을 처리하고 클러스터를 넘어 방화벽 또는 라우터와 같은 에지 테두리 디바이스에 대한 연결을 제공합니다.

  • 관리 네트워크 의도는 클러스터 관리 IP 주소 및 컨트롤 플레인 리소스가 외부에서 통신할 수 있도록 하는 수렴형 SET 팀 가상 인터페이스를 사용합니다.

  • 컴퓨팅 네트워크 의도의 경우 환경에 대한 특정 VLAN ID를 사용하여 Azure에서 하나 이상의 논리 네트워크를 만들 수 있습니다. VM과 같은 워크로드 리소스는 이러한 ID를 사용하여 실제 네트워크에 대한 액세스 권한을 부여합니다. 논리 네트워크는 컴퓨팅 및 관리 의도에 대해 SET 팀을 사용하여 수렴되는 두 개의 실제 네트워크 어댑터 포트를 사용합니다.

• 스토리지 트래픽:

  • 실제 노드는 ToR 스위치에 연결된 두 개의 전용 네트워크 어댑터 포트를 사용하여 서로 통신하여 스토리지 트래픽에 대해 높은 대역폭 및 복원력을 제공합니다.

  • SMB1 및 SMB2 스토리지 포트는 별도의 두 개의 비주유 네트워크(또는 계층 2) 네트워크에 연결됩니다. 각 네트워크에는 ToR 스위치의 기본 스토리지 VLAN ID(711 및 712)의 스위치 포트 구성과 일치해야 하는 특정 VLAN ID가 구성되어 있습니다.

  • Azure Stack HCI 노드 OS 내의 두 스토리지 의도 네트워크 어댑터 포트에 구성된 기본 게이트웨이 는 없습니다.

  • 각 노드는 스토리지 풀, 가상 디스크 및 볼륨에 사용되는 원격 물리적 디스크와 같은 클러스터의 저장소 공간 직접 기능에 액세스할 수 있습니다. 이러한 기능에 대한 액세스는 각 노드에서 사용할 수 있는 두 개의 전용 스토리지 네트워크 어댑터 포트를 통해 SMB 직접 RDMA 프로토콜을 통해 촉진됩니다. SMB 다중 채널은 복원력에 사용됩니다.

  • 이 구성은 미러된 볼륨에 대한 일관된 데이터 복사본 유지 관리와 같은 스토리지 관련 작업에 충분한 데이터 전송 속도를 제공합니다.

네트워크 스위치 요구 사항

이더넷 스위치는 Azure Stack HCI에 필요한 다양한 사양을 충족하고 IEEE SA(전기 및 전자 엔지니어 표준 협회)에서 설정해야 합니다. 예를 들어 다중 노드 스토리지 전환 배포의 경우 스토리지 네트워크는 RoCE v2 또는 iWARP를 통해 RDMA에 사용됩니다. 이 프로세스를 수행하려면 스토리지 트래픽 클래스에 대한 무손실 통신을 보장하기 위해 IEEE 802.1Qbb PFC가 필요합니다. ToR 스위치는 VLAN용 IEEE 802.1Q 및 링크 계층 검색 프로토콜에 대한 IEEE 802.1AB에 대한 지원을 제공해야 합니다.

Azure Stack HCI 배포에 기존 네트워크 스위치를 사용하려는 경우 네트워크 스위치 및 구성에서 제공해야 하는 필수 IEEE 표준 및 사양 목록을 검토합니다. 새 네트워크 스위치를 구매할 때 스위치 공급업체에 문의하여 디바이스가 Azure Stack HCI IEEE 사양 요구 사항을 충족하는지 확인하거나 Azure Stack HCI 네트워크 요구 사항을 지원하는 하드웨어 공급업체 인증 스위치 모델 목록을 검토 합니다.

IP 주소 요구 사항

다중 노드 스토리지 전환 배포에서 필요한 IP 주소 수는 각 실제 노드를 추가하여 단일 클러스터 내에서 최대 16개의 노드까지 증가합니다. 예를 들어 Azure Stack HCI의 2노드 스토리지 전환 구성을 배포하려면 클러스터 인프라에 최소 11 x IP 주소를 할당해야 합니다. 마이크로 구분 또는 소프트웨어 정의 네트워킹을 사용하는 경우 더 많은 IP 주소가 필요합니다. 자세한 내용은 Azure Stack HCI에 대한 2노드 스토리지 참조 패턴 IP 주소 요구 사항 검토를 참조하세요.

Azure Stack HCI에 대한 IP 주소 요구 사항을 설계하고 계획할 때는 Azure Stack HCI 클러스터 및 인프라 구성 요소에 필요한 것 이상으로 워크로드에 필요한 추가 IP 주소 또는 네트워크 범위를 고려해야 합니다. Azure Stack HCI에 AKS를 배포하려는 경우 Azure Arc 네트워크 요구 사항에서 사용하도록 설정된 AKS를 참조 하세요.

모니터링

모니터링 및 경고를 향상하려면 Azure Stack HCI에서 Monitor Insights를 사용하도록 설정합니다. 인사이트는 Azure 일관된 환경을 사용하여 여러 온-프레미스 클러스터를 모니터링하고 관리하도록 확장할 수 있습니다. Insights는 클러스터 성능 카운터 및 이벤트 로그 채널을 사용하여 주요 Azure Stack HCI 기능을 모니터링합니다. 로그는 모니터 및 Log Analytics를 통해 구성된 DCR에서 수집됩니다.

Azure Stack HCI Insights는 모니터 및 Log Analytics를 사용하여 빌드되어 항상 사용자 지정할 수 있는 확장 가능한 최신 솔루션을 보장합니다. Insights는 Azure Stack HCI의 주요 기능을 모니터링하기 위해 만든 특수 통합 문서와 함께 기본 메트릭이 있는 기본 통합 문서에 대한 액세스를 제공합니다. 이러한 구성 요소는 거의 실시간으로 모니터링 솔루션을 제공하고 그래프 만들기, 집계 및 필터링을 통한 시각화 사용자 지정, 사용자 지정 리소스 상태 경고 규칙 구성을 사용하도록 설정합니다.

업데이트 관리

Azure Stack HCI 클러스터 및 Azure Arc VM과 같은 배포된 워크로드 리소스를 정기적으로 업데이트하고 패치해야 합니다. 정기적으로 업데이트를 적용하면 조직에서 강력한 보안 상태를 유지하고 자산의 전반적인 안정성과 지원 가능성을 향상시킬 수 있습니다. 보안 패치 및 OS 업데이트의 조기 검색 및 적용을 위해 자동 및 주기적인 수동 평가를 사용하는 것이 좋습니다.

인프라 업데이트

Azure Stack HCI는 고객 환경을 개선하고 새로운 기능과 기능을 추가하기 위해 지속적으로 업데이트됩니다. 이 프로세스는 분기별로 새로운 기준 빌드를 제공하는 릴리스 열차를 통해 관리됩니다. 기준 빌드는 Azure Stack HCI 클러스터에 적용되어 최신 상태로 유지됩니다. 정기적인 기준 빌드 업데이트 외에도 Azure Stack HCI는 월별 OS 보안 및 안정성 업데이트로 업데이트됩니다.

Update Manager는 Azure Stack HCI에 대한 업데이트를 적용, 보기 및 관리하는 데 사용할 수 있는 Azure 서비스입니다. 이 서비스는 Azure Portal을 사용하여 전체 인프라 및 에지 위치에서 모든 Azure Stack HCI 클러스터를 보고 중앙 집중식 관리 환경을 제공하는 메커니즘을 제공합니다. 자세한 내용은 다음 리소스를 참조하세요.

• Azure Stack HCI 릴리스 정보

• Azure Stack HCI 수명 주기 주기

• Azure Stack HCI의 업데이트 단계 검토

• Azure Update Manager를 사용하여 Azure Stack HCI 업데이트

3~6개월마다 새로운 드라이버 및 펌웨어 업데이트를 정기적으로 확인하는 것이 중요합니다. Azure Stack HCI 하드웨어 에 프리미어 솔루션 범주 버전을 사용하는 경우 솔루션 빌더 확장 패키지 업데이트 가 업데이트 관리자와 통합되어 간소화된 업데이트 환경을 제공합니다. 유효성이 검사된 노드 또는 통합 시스템 범주를 사용하는 경우 하드웨어에 대한 펌웨어 및 드라이버 업데이트가 포함된 OEM별 업데이트 패키지를 다운로드하고 실행해야 할 수도 있습니다. 하드웨어에 대한 업데이트를 제공하는 방법을 확인하려면 하드웨어 OEM 또는 SI 파트너에게 문의하세요.

워크로드 게스트 OS 패치

AUM(Azure Update Manager)을 사용하여 Azure Stack HCI에 배포된 Azure Arc VM을 등록하여 Azure Stack HCI 클러스터 물리적 노드를 업데이트하는 데 사용되는 것과 동일한 메커니즘을 사용하여 통합 패치 관리 환경을 제공할 수 있습니다. AUM을 사용하여 게스트 유지 관리 구성을 만들 수 있습니다. 이러한 구성은 필요한 경우 다시 부팅 설정 재부팅, 일정(날짜, 시간 및 반복 옵션), 범위에 대한 Azure Arc VM의 동적(구독) 또는 정적 목록과 같은 설정을 제어합니다. 이러한 설정은 워크로드 VM의 게스트 OS 내에 OS 보안 패치가 설치되는 경우에 대한 구성을 제어합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

안정성

안정성은 애플리케이션이 고객에 대한 약속을 충족할 수 있도록 합니다. 자세한 내용은 안정성 핵심 요소 개요를 참조하세요.

잠재적 오류 지점 식별

모든 아키텍처는 오류에 취약합니다. 오류를 예측하고 오류 모드 분석을 사용하여 완화를 준비할 수 있습니다. 다음 표에서는 이 아키텍처에서 잠재적인 실패 지점의 네 가지 예를 설명합니다.

자세한 내용은 실패 모드 분석을 수행하기 위한 권장 사항을 참조 하세요.

안정성 대상

이 섹션에서는 예제 시나리오에 대해 설명합니다. Contoso Manufacturing이라는 가상의 고객은 이 참조 아키텍처를 사용하여 Azure Stack HCI를 배포합니다. 요구 사항을 해결하고 온-프레미스에서 워크로드를 배포 및 관리하려고 합니다. Contoso Manufacturing은 비즈니스 및 애플리케이션 관련자가 서비스에 대해 동의하는 99.8%의 내부 SLO(서비스 수준 목표) 목표를 가지고 있습니다.

• 99.8%의 작동 시간 또는 가용성의 SLO는 Azure Stack HCI에서 실행되는 Azure Arc VM을 사용하여 배포된 애플리케이션에 대해 다음 기간의 허용된 가동 중지 시간 또는 사용 불가 기간을 초래합니다.

  • 매주: 20분 10초

  • 매월: 1시간 26분 56초

  • 분기별: 4시간, 20분, 49초

  • 연간: 17시간, 23분, 16초

• Contoso Manufacturing은 SLO 대상을 충족하기 위해 PoLP(최소 권한) 원칙을 구현하여 Azure Stack HCI 클러스터 관리자 수를 신뢰할 수 있고 자격을 갖춘 소수의 개인으로 제한합니다. 이 방법을 사용하면 프로덕션 리소스에서 실수로 수행되거나 실수로 수행되는 작업으로 인한 가동 중지 시간을 방지할 수 있습니다. 또한 AD DS(온-프레미스 Active Directory Domain Services) 도메인 컨트롤러에 대한 보안 이벤트 로그를 모니터링하여 SIEM(보안 정보 이벤트 관리) 솔루션을 사용하여 Azure Stack HCI 클러스터 관리자 그룹에 대한 추가 및 제거 작업이라고 하는 사용자 계정 그룹 멤버 자격 변경 내용을 검색하고 보고합니다. 모니터링은 안정성을 높이고 솔루션의 보안을 향상시킵니다.

  자세한 내용은 ID 및 액세스 관리에 대한 권장 사항을 참조하세요.

• Contoso Manufacturing의 프로덕션 시스템에는 엄격한 변경 제어 절차가 적용됩니다. 이 프로세스를 수행하려면 프로덕션 환경에서 구현하기 전에 대표적인 테스트 환경에서 모든 변경 내용을 테스트하고 유효성을 검사해야 합니다. 주간 변경 자문 위원회 프로세스에 제출된 모든 변경 내용에는 자세한 구현 계획(또는 소스 코드에 대한 링크), 위험 수준 점수, 포괄적인 롤백 계획, 릴리스 후 테스트 및 확인, 검토 또는 승인할 변경에 대한 명확한 성공 기준이 포함되어야 합니다.

  자세한 내용은 안전한 배포 방법에 대한 권장 사항을 참조 하세요.

• 월별 보안 패치 및 분기별 기준 업데이트 는 사전 프로덕션 환경에서 유효성을 검사한 후에만 프로덕션 Azure Stack HCI 클러스터에 적용됩니다. 업데이트 관리자 및 클러스터 인식 업데이트 기능은 VM 라이브 마이그레이션을 사용하여 월별 서비스 작업 중에 중요 비즈니스용 워크로드의 가동 중지 시간을 최소화하는 프로세스를 자동화합니다. Contoso Manufacturing 표준 운영 프로시저를 사용하려면 릴리스 날짜 4주 이내에 모든 프로덕션 시스템에 보안, 안정성 또는 기준 빌드 업데이트가 적용되어야 합니다. 이 정책이 없으면 프로덕션 시스템은 월별 OS 및 보안 업데이트를 통해 지속적으로 최신 상태를 유지할 수 없습니다. 오래된 시스템은 플랫폼 안정성 및 보안에 부정적인 영향을 미칩니다.

  자세한 내용은 보안 기준 설정에 대한 권장 사항을 참조하세요.

• Contoso Manufacturing은 매일, 매주 및 매월 백업을 구현하여 매일 백업의 마지막 6 x일(월요일부터 토요일까지), 마지막 3 x 매주(매주 일요일) 및 3 x 월별 백업을 유지하며, 각 일요일 주 4는 문서화 및 감사 가능한 롤링 일정 기반 일정을 사용하여 월 1, 2 및 월 3 백업으로 유지됩니다. 이 방법은 사용 가능한 데이터 복구 지점 수와 오프사이트 또는 클라우드 백업 스토리지 서비스의 비용 절감 간에 적절한 균형을 맞추기 위해 Contoso 제조 요구 사항을 충족합니다.

  자세한 내용은 재해 복구 전략 설계에 대한 권장 사항을 참조 하세요.

• 데이터 백업 및 복구 프로세스는 6개월마다 각 비즈니스 시스템에 대해 테스트 됩니다. 이 전략은 BCDR 프로세스가 유효하고 데이터 센터 재해 또는 사이버 인시던트가 발생할 경우 비즈니스가 보호된다는 보증을 제공합니다.

  자세한 내용은 안정성 테스트 전략 설계에 대한 권장 사항을 참조 하세요.

• 이 문서의 앞에서 설명한 운영 프로세스 및 절차와 Azure Stack HCI에 대한 잘 설계된 프레임워크 서비스 가이드의 권장 사항을 통해 Contoso Manufacturing은 99.8% SLO 목표를 충족하고 전 세계에 배포된 여러 제조 사이트에서 Azure Stack HCI 및 워크로드 배포를 효과적으로 확장 및 관리할 수 있습니다.

  자세한 내용은 안정성 대상을 정의하기 위한 권장 사항을 참조 하세요.

중복

단일 Azure Stack HCI 클러스터에 배포하는 워크로드를 로컬 중복 배포로 고려합니다. 클러스터는 플랫폼 수준에서 고가용성을 제공하지만 클러스터를 단일 랙에 배포해야 합니다. 중요 비즈니스용 또는 중요 업무용 사용 사례의 경우 두 개 이상의 개별 Azure Stack HCI 클러스터에 워크로드 또는 서비스의 여러 인스턴스를 배포하는 것이 좋습니다.

활성/수동 복제, 동기 복제 또는 SQL Server Always On과 같은 비동기 복제를 제공하는 워크로드에 업계 표준 고가용성 패턴을 사용합니다. 별도의 물리적 위치에 배포하는 Azure Stack HCI 클러스터에서 실행되는 여러 워크로드 인스턴스에서 사용자 요청을 라우팅하는 NLB(외부 네트워크 부하 분산) 기술을 사용할 수도 있습니다. 파트너 외부 NLB 디바이스를 사용하는 것이 좋습니다. 또는 Azure ExpressRoute 또는 VPN 터널을 사용하여 온-프레미스 서비스에 연결하는 Azure 애플리케이션 게이트웨이 인스턴스와 같이 하이브리드 및 온-프레미스 서비스에 대한 트래픽 라우팅을 지원하는 부하 분산 옵션을 평가할 수 있습니다.

자세한 내용은 중복성을 위한 디자인에 대한 권장 사항을 참조 하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

보안 고려 사항은 다음과 같습니다.

• Azure Stack HCI 플랫폼의 보안 기반: Azure Stack HCI 는 TPM, UEFI 및 보안 부팅과 함께 유효성이 검사된 하드웨어 구성 요소를 사용하여 Azure Stack HCI 플랫폼 및 워크로드 보안을 위한 보안 기반을 구축하는 기본 보안 제품입니다. 기본 보안 설정을 사용하여 배포하는 경우 Azure Stack HCI에는 Windows Defender 애플리케이션 제어, Credential Guard 및 BitLocker가 사용하도록 설정됩니다. PoLP를 사용하여 권한 위임을 간소화하려면 플랫폼 관리자를 위한 Azure Stack HCI 관리자, 워크로드 운영자를 위한 Azure Stack HCI VM 기여자 또는 Azure Stack HCI VM 판독기와 같은 Azure Stack HCI 기본 제공 RBAC(역할 기반 액세스 제어) 역할을 사용합니다.

• 기본 보안 설정: Azure Stack HCI 보안 기본값 은 배포 중에 Azure Stack HCI 클러스터에 대한 기본 보안 설정을 적용하고 드리프트 제어 가 노드를 알려진 양호한 상태로 유지할 수 있도록 합니다. 보안 기본 설정을 사용하여 클러스터의 클러스터 보안, 드리프트 제어 및 보안 코어 서버 설정을 관리할 수 있습니다.

• 보안 이벤트 로그: Azure Stack HCI syslog 전달 은 관련 보안 이벤트 로그를 검색하여 자체 SIEM 플랫폼에서 보존할 이벤트를 집계하고 저장하여 보안 모니터링 솔루션과 통합됩니다.

• 위협 및 취약성으로부터 보호: 클라우드용 Defender 다양한 위협 및 취약성으로부터 Azure Stack HCI 클러스터를 보호합니다. 이 서비스는 Azure Stack HCI 환경의 보안 태세를 개선하는 데 도움이 되며 기존 위협과 진화하는 위협으로부터 보호할 수 있습니다.

• 위협 감지 및 수정: Microsoft Advanced Threat Analytics 는 Azure Stack HCI 클러스터 노드 및 Windows Server VM 워크로드에 인증 서비스를 제공하는 AD DS를 대상으로 하는 위협과 같은 위협을 감지하고 수정합니다.

• 네트워크 격리: 필요한 경우 네트워크를 격리합니다. 예를 들어 별도의 VLAN 및 네트워크 주소 범위를 사용하는 여러 논리 네트워크를 프로비전할 수 있습니다. 이 방법을 사용하는 경우 Azure Stack HCI 클러스터 노드가 ToR 스위치 또는 게이트웨이를 통해 VLAN 네트워크와 통신할 수 있도록 관리 네트워크가 각 논리 네트워크 및 VLAN에 연결할 수 있는지 확인합니다. 이 구성은 인프라 관리 에이전트가 워크로드 게스트 OS와 통신할 수 있도록 허용하는 등 워크로드를 관리하는 데 필요합니다.

  자세한 내용은 세분화 전략을 빌드하기 위한 권장 사항을 참조 하세요.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

비용 최적화 고려 사항은 다음과 같습니다.

• 라이선스에 대한 클라우드 스타일 청구 모델: Azure Stack HCI 가격 책정은 Azure Stack HCI 클러스터의 물리적 프로세서 코어당 고정 요금이 있는 월간 구독 청구 모델을 따릅니다. 다른 Azure 서비스를 사용하는 경우 추가 사용 요금이 적용됩니다. 활성 Software Assurance를 사용하여 Windows Server Datacenter Edition에 대한 온-프레미스 코어 라이선스를 소유한 경우 이러한 라이선스를 교환하여 Azure Stack HCI 클러스터 및 Windows Server VM 구독 요금을 활성화하도록 선택할 수 있습니다.

• Azure Arc VM에 대한 자동 VM 게스트 패치: 이 기능은 수동 패치 및 관련 유지 관리 비용의 오버헤드를 줄이는 데 도움이 됩니다. 이 작업은 시스템을 보다 안전하게 만드는 데 도움이 될 뿐만 아니라 리소스 할당을 최적화하고 전반적인 비용 효율성에 기여합니다.

• 비용 모니터링 통합: 모니터링 비용을 통합하려면 Azure Stack HCI용 업데이트 관리자를 사용하여 Azure Stack HCI Insights 및 패치를 사용합니다. Insights는 Monitor를 사용하여 풍부한 메트릭 및 경고 기능을 제공합니다. Azure Stack HCI의 수명 주기 관리자 구성 요소는 업데이트 관리자와 통합되어 다양한 구성 요소에 대한 업데이트 워크플로를 단일 환경으로 통합하여 클러스터를 최신 상태로 유지하는 작업을 간소화합니다. 모니터 및 업데이트 관리자를 사용하여 리소스 할당을 최적화하고 전반적인 비용 효율성에 기여합니다.

  자세한 내용은 직원 시간을 최적화하기 위한 권장 사항을 참조하세요.

• 초기 워크로드 용량 및 증가: Azure Stack HCI 배포를 계획할 때 초기 워크로드 용량, 복원력 요구 사항 및 향후 증가 고려 사항을 고려합니다. 2개 또는 3개 노드의 스토리지 스위치 없는 아키텍처를 사용하면 스토리지 클래스 네트워크 스위치를 조달할 필요가 없는 등의 비용을 줄일 수 있는지 고려합니다. 추가 스토리지 클래스 네트워크 스위치를 조달하는 것은 새 Azure Stack HCI 클러스터 배포의 비용이 많이 드는 구성 요소일 수 있습니다. 대신 관리 및 컴퓨팅 네트워크에 기존 스위치를 사용하여 인프라를 간소화할 수 있습니다. 워크로드 용량 및 복원력 요구 사항이 3노드 구성 이상으로 확장되지 않는 경우 관리 및 컴퓨팅 네트워크에 기존 스위치를 사용하고 3노드 스토리지 스위치 없는 아키텍처를 사용하여 Azure Stack HCI를 배포할 수 있는지 고려합니다.

  자세한 내용은 구성 요소 비용을 최적화하기 위한 권장 사항을 참조 하세요.

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.

운영 우수성 고려 사항은 다음과 같습니다.

• Azure와 통합된 간소화된 프로비전 및 관리 환경: Azure의 클라우드 기반 배포는 Azure Stack HCI 클러스터를 만드는 방법을 보여 주는 마법사 기반 인터페이스를 제공합니다. 마찬가지로 Azure는 Azure Stack HCI 클러스터 및 Azure Arc VM을 관리하는 프로세스를 간소화합니다. ARM 템플릿을 사용하여 Azure Stack HCI 클러스터의 포털 기반 배포를 자동화할 수 있습니다. 이 템플릿은 특히 중요 비즈니스용 워크로드를 실행하기 위해 Azure Stack HCI 클러스터가 필요한 소매점 또는 제조 사이트와 같은 에지 시나리오에서 대규모로 Azure Stack HCI를 배포하는 일관성과 자동화를 제공합니다.

• Virtual Machines의 자동화 기능: Azure Stack HCI는 Azure CLI, ARM 또는 Bicep 템플릿을 사용하여 Azure Arc VM의 자동화된 배포를 통해 Azure Arc VM과 같은 워크로드를 관리하기 위한 광범위한 자동화 기능을 제공하며, Azure Arc EXTENSION for Updates 및 Azure Update Manager를 사용하여 각 Azure Stack HCI 클러스터를 업데이트하는 Virtual Machine OS 업데이트를 제공합니다. 또한 Azure Stack HCI는 Windows PowerShell을 사용하여 Azure CLI 및 비 Azure Arc VM을 사용하여 Azure Arc VM 관리를 지원합니다. Azure Stack HCI 서버 중 하나에서 로컬로 또는 관리 컴퓨터에서 원격으로 Azure CLI 명령을 실행할 수 있습니다. Azure Automation 및 Azure Arc와의 통합은 Azure Arc 확장을 통해 VM 워크로드에 대한 광범위한 추가 자동화 시나리오를 용이하게 합니다.

  자세한 내용은 IaC 사용에 대한 권장 사항을 참조 하세요.

• AKS의 컨테이너에 대한 자동화 기능: Azure Stack HCI는 AKS에서 컨테이너와 같은 워크로드를 관리하기 위한 광범위한 자동화 기능을 제공합니다. Azure CLI를 사용하여 AKS 클러스터의 배포를 자동화할 수 있습니다. Kubernetes용 Azure Arc 확장을 사용하여 AKS 워크로드 클러스터를 업데이트합니다. Azure CLI를 사용하여 Azure Arc 지원 AKS를 관리할 수도 있습니다. Azure Stack HCI 서버 중 하나에서 로컬로 또는 관리 컴퓨터에서 원격으로 Azure CLI 명령을 실행할 수 있습니다. Azure Arc 확장을 통해 컨테이너화된 워크로드에 대한 광범위한 추가 자동화 시나리오를 위해 Azure Arc와 통합합니다.

  자세한 내용은 자동화를 사용하도록 설정하기 위한 권장 사항을 참조 하세요.

성능 효율성

성능 효율성은 사용자가 배치된 요구 사항을 효율적인 방식으로 충족하기 위해 워크로드의 크기를 조정할 수 있는 기능입니다. 자세한 내용은 성능 효율성 핵심 요소 개요를 참조하세요.

성능 효율성 고려 사항은 다음과 같습니다.

• 워크로드 스토리지 성능: DiskSpd 도구를 사용하여 Azure Stack HCI 클러스터의 워크로드 스토리지 성능 기능을 테스트하는 것이 좋습니다. VMFleet 도구를 사용하여 부하를 생성하고 스토리지 하위 시스템의 성능을 측정할 수 있습니다. VMFleet을 사용하여 스토리지 하위 시스템 성능을 측정해야 하는지 여부를 평가합니다.

  • 프로덕션 워크로드를 배포하기 전에 Azure Stack HCI 클러스터 성능에 대한 기준을 설정하는 것이 좋습니다. DiskSpd는 관리자가 클러스터의 스토리지 성능을 테스트할 수 있도록 하는 다양한 명령줄 매개 변수를 사용합니다. DiskSpd의 주요 기능은 읽기 및 쓰기 작업 및 출력 성능 메트릭(예: 대기 시간, 처리량 및 IOP)을 발급하는 것입니다.

    자세한 내용은 성능 테스트에 대한 권장 사항을 참조하세요.

• 워크로드 스토리지 복원력: 스토리지 복원력, 사용량(또는 용량) 효율성 및 성능의 이점을 고려합니다. Azure Stack HCI 볼륨에 대한 계획에는 복원력, 사용 효율성 및 성능 간의 최적 균형을 식별하는 것이 포함됩니다. 이러한 특성 중 하나를 최대화하면 일반적으로 하나 이상의 다른 특성에 부정적인 영향을 미치기 때문에 이 균형을 최적화하기가 어려울 수 있습니다. 복원력을 높이면 사용 가능한 용량이 줄어듭니다. 따라서 선택한 복원력 유형에 따라 성능이 달라질 수 있습니다. 복원력과 성능이 우선 순위이고 3개 이상의 노드를 사용하는 경우 기본 스토리지 구성은 인프라 및 사용자 볼륨 모두에 3방향 미러링을 사용합니다.

  자세한 내용은 용량 계획에 대한 권장 사항을 참조하세요.

• 네트워크 성능 최적화: 네트워크 성능 최적화를 고려합니다. 디자인의 일부로 최적의 네트워크 하드웨어 구성을 결정할 때 예상되는 네트워크 트래픽 대역폭 할당을 포함해야 합니다.

  • Azure Stack HCI에서 컴퓨팅 성능을 최적화하려면 GPU 가속을 사용할 수 있습니다. GPU 가속은 데이터 인사이트 또는 추론을 포함하는 고성능 AI 또는 기계 학습 워크로드에 유용합니다. 이러한 워크로드는 데이터 중력 또는 보안 요구 사항과 같은 고려 사항으로 인해 에지 위치에 배포해야 합니다. 하이브리드 배포 또는 온-프레미스 배포에서는 GPU를 비롯한 워크로드 성능 요구 사항을 고려해야 합니다. 이 방법을 사용하면 Azure Stack HCI 클러스터를 디자인하고 조달할 때 올바른 서비스를 선택할 수 있습니다.

    자세한 내용은 올바른 서비스를 선택하기 위한 권장 사항을 참조 하세요.

시나리오 배포

다음 섹션에서는 필수 구성 요소 작업 및 고려 사항을 포함하여 Azure Stack HCI를 배포하는 데 사용되는 상위 수준 작업 또는 일반적인 워크플로의 예제 목록을 제공합니다. 이 워크플로 목록은 예제 가이드로만 사용됩니다. 조직, 지리적 또는 프로젝트별 요구 사항에 따라 달라질 수 있는 모든 필수 작업의 전체 목록이 아닙니다.

시나리오: 온-프레미스 또는 에지 위치에 하이브리드 클라우드 솔루션을 배포하여 데이터 처리 기능에 대한 로컬 컴퓨팅을 제공하고 Azure 일관성 있는 관리 및 청구 환경을 사용하려는 경우 프로젝트 또는 사용 사례 요구 사항이 있습니다. 자세한 내용은 이 문서의 잠재적 사용 사례 섹션에 설명 되어 있습니다 . 나머지 단계에서는 Azure Stack HCI가 프로젝트에 대해 선택한 인프라 플랫폼 솔루션이라고 가정합니다.

1. 관련 이해 관계자로부터 워크로드 및 사용 사례 요구 사항을 수집합니다. 이 전략을 통해 프로젝트는 Azure Stack HCI의 기능과 기능이 워크로드 규모, 성능 및 기능 요구 사항을 충족하는지 확인할 수 있습니다. 이 검토 프로세스에는 워크로드 규모 또는 크기 이해와 Azure Arc VM, AKS, Azure Virtual Desktop 또는 Azure Arc 지원 Data Services 또는 Azure Arc 지원 Machine Learning 서비스와 같은 필수 기능이 포함되어야 합니다. 워크로드 RTO 및 RPO(안정성) 값 및 기타 비기능 요구 사항(성능/부하 확장성)은 이 요구 사항 수집 단계의 일부로 문서화되어야 합니다.

2. 권장 하드웨어 파트너 솔루션에 대한 Azure Stack HCI 크기 조정기 출력을 검토합니다. 이 출력에는 권장되는 물리적 서버 하드웨어 만들기 및 모델, 실제 노드 수, 워크로드를 배포하고 실행하는 데 필요한 각 물리적 노드의 CPU, 메모리 및 스토리지 구성에 대한 사양에 대한 세부 정보가 포함됩니다.

3. Azure Stack HCI 크기 조정 도구를 사용하여 워크로드 유형 및 크기를 모델화하는 새 프로젝트를 만듭니다. 이 프로젝트에는 VM의 크기 및 수와 해당 스토리지 요구 사항이 포함됩니다. 이러한 세부 정보는 이전 클러스터 디자인 선택 섹션에서 설명한 대로 시스템 유형, 기본 CPU 제품군 및 고가용성 및 스토리지 내결함성을 위한 복원력 요구 사항과 함께 입력됩니다.

4. 권장 하드웨어 파트너 솔루션에 대한 Azure Stack HCI Sizer 출력을 검토합니다. 이 솔루션에는 권장되는 물리적 서버 하드웨어(만들기 및 모델), 물리적 노드 수 및 워크로드를 배포하고 실행하는 데 필요한 각 물리적 노드의 CPU, 메모리 및 스토리지 구성에 대한 사양에 대한 세부 정보가 포함됩니다.

5. 하드웨어 OEM 또는 SI 파트너에게 문의하여 권장 하드웨어 버전과 워크로드 요구 사항의 적합성을 추가로 한정합니다. 사용 가능한 경우 OEM별 크기 조정 도구를 사용하여 의도한 워크로드에 대한 OEM 관련 하드웨어 크기 조정 요구 사항을 확인합니다. 이 단계에는 일반적으로 솔루션의 상업적 측면에 대한 하드웨어 OEM 또는 SI 파트너와의 논의가 포함됩니다. 이러한 측면에는 따옴표, 하드웨어의 가용성, 리드 타임 및 파트너가 프로젝트 또는 비즈니스 결과를 가속화하는 데 도움이 되는 전문 또는 부가 가치 서비스가 포함됩니다.

6. 네트워크 통합을 위해 두 개의 ToR 스위치를 배포합니다. 고가용성 솔루션의 경우 HCI 클러스터에는 두 개의 ToR 스위치를 배포해야 합니다. 각 물리적 노드에는 4개의 NIC가 필요하며, 그 중 2개는 RDMA가 가능해야 하며, 각 노드에서 두 개의 ToR 스위치로의 두 개의 링크를 제공합니다. 각 스위치에 연결된 두 개의 NIC는 컴퓨팅 및 관리 네트워크에 대한 아웃바운드 남북 연결을 위해 수렴됩니다. 다른 두 개의 RDMA 지원 NIC는 스토리지 동서 트래픽 전용입니다. 기존 네트워크 스위치를 사용하려는 경우 스위치의 만들기 및 모델이 Azure Stack HCI에서 지원하는 승인된 네트워크 스위치 목록에 있는지 확인합니다.

7. 하드웨어 OEM 또는 SI 파트너와 협력하여 하드웨어 배달을 준비합니다. SI 파트너 또는 직원은 하드웨어를 온-프레미스 데이터 센터 또는 에지 위치에 통합해야 합니다(예: 물리적 노드에 대한 하드웨어, 물리적 네트워크 및 전원 공급 장치 케이블 연결).

8. Azure Stack HCI 클러스터 배포를 수행합니다. 선택한 솔루션 버전(프리미어 솔루션, 통합 시스템 또는 유효성 검사된 노드)에 따라 하드웨어 파트너, SI 파트너 또는 직원이 Azure Stack HCI 소프트웨어를 배포할 수 있습니다. 이 단계는 물리적 노드 Azure Stack HCI OS를 Azure Arc 지원 서버에 온보딩한 다음, Azure Stack HCI 클라우드 배포 프로세스를 시작하는 것으로 시작합니다. 고객 및 파트너는 요청 및 하드웨어 솔루션 범주의 특성에 따라 지원 + 문제 해결 아이콘을 선택하거나 하드웨어 OEM 또는 SI 파트너에게 문의하여 Azure Portal에서 Microsoft와 직접 지원 요청을 제기할 수 있습니다.

   팁

   Azure Stack HCI 23H2 클러스터 참조 구현은 ARM 템플릿 및 매개 변수 파일을 사용하여 Azure Stack HCI의 전환된 다중 서버 배포를 배포하는 방법을 보여 줍니다. 또는 Bicep 예제에서는 Bicep 템플릿을 사용하여 필수 구성 요소 리소스를 포함하여 Azure Stack HCI 클러스터를 배포하는 방법을 보여 줍니다.

9. 자동화를 위해 Azure Portal, CLI 또는 ARM + Azure Arc 템플릿을 사용하여 Azure Stack HCI에서 고가용성 워크로드를 배포합니다. Azure Arc VM, AKS, Azure Virtual Desktop 세션 호스트 또는 Azure Stack HCI의 AKS 확장 및 컨테이너화를 통해 사용하도록 설정할 수 있는 다른 Azure Arc 지원 서비스와 같은 워크로드 리소스를 배포할 때 새 HCI 클러스터의 사용자 지정 위치 리소스를 대상 지역으로 사용합니다.

10. 플랫폼의 보안 및 안정성을 향상시키기 위해 월별 업데이트를 설치합니다. Azure Stack HCI 클러스터를 최신 상태로 유지하려면 Microsoft 소프트웨어 업데이트 및 하드웨어 OEM 드라이버 및 펌웨어 업데이트를 설치해야 합니다. 이러한 업데이트는 플랫폼의 보안 및 안정성을 향상시킵니다. Update Manager 는 업데이트를 적용하고 단일 클러스터 또는 여러 클러스터에 업데이트를 설치하는 중앙 집중식 확장성 솔루션을 제공합니다. 선택한 하드웨어 솔루션 범주 유형(프리미어 솔루션, 통합 시스템 또는 유효성 검사된 노드)에 따라 이 프로세스가 달라질 수 있으므로 하드웨어 OEM 파트너에게 문의하여 하드웨어 드라이버 및 펌웨어 업데이트를 설치하는 프로세스를 확인하세요. 자세한 내용은 인프라 업데이트를 참조 하세요.

관련 참고 자료

• 하이브리드 아키텍처 디자인
• Azure 하이브리드 옵션
• 하이브리드 환경의 자동화
• 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 Arc 지원 데이터 서비스란?
• Azure Arc 지원 서버란?
• Backup 서비스란?

특정 Azure 서비스에 대한 세부 정보에 대한 제품 설명서:

• Azure Stack HCI
• Azure Arc
• Key Vault
• Azure Blob Storage
• 모니터
• Azure Policy
• Azure Container Registry
• Defender for Cloud
• Site Recovery
• Backup

Microsoft Learn 모듈:

• 모니터 구성
• Azure에서 사이트 복구 솔루션 디자인
• Azure Arc 지원 서버 소개
• Azure Arc 지원 데이터 서비스 소개
• AKS 소개
• 어디서나 Machine Learning을 사용하여 모델 배포 크기 조정 - 기술 커뮤니티 블로그
• AKS 및 Azure Arc 지원 Machine Learning을 사용하여 어디서나 Machine Learning 실현 - 기술 커뮤니티 블로그
• Azure Arc 지원 기계 학습을 사용하는 AKS 하이브리드 및 Stack HCI의 기계 학습 - 기술 커뮤니티 블로그
• Machine Learning의 Kubernetes 컴퓨팅 대상 소개
• VM 업데이트 유지
• Automation 상태 구성을 사용하여 VM 설정 보호
• Backup을 사용하여 VM 보호