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 コントロールには、通常のバックアップとディザスター リカバリーフェールオーバー機能が含まれます。 HCI インフラストラクチャ プラットフォームに重点を置くために、これらのワークロード設計の側面については、この記事から意図的に除外されています。

Azure Well-Architected Framework の 5 つの柱のガイドラインと推奨事項の詳細については、「Azure Stack HCI Well-Architected Framework サービス ガイド」を参照してください。

記事のレイアウト

Architecture

詳細については、「関連リソース」を参照してください。

考えられるユース ケース

Azure Stack HCI の一般的なユース ケースには、オンプレミスまたはエッジの場所で高可用性 (HA) ワークロードを実行する機能が含まれており、ワークロードの要件に対処するためのソリューションが提供されます。 次のことを実行できます。

• データ主権、規制とコンプライアンス、または待機時間の要件に対処するためにオンプレミスにデプロイされたハイブリッド クラウド ソリューションを提供します。

• 1 つの場所または複数の場所にデプロイされる HA 仮想化またはコンテナー ベースのエッジ ワークロードをデプロイおよび管理します。 この戦略により、ビジネスクリティカルなアプリケーションとサービスを、回復性があり、コスト効率が高く、スケーラブルな方法で動作させることができます。

• Microsoft によって認定されたソリューション、クラウドベースのデプロイ、一元管理、監視とアラートを使用して、総保有コスト (TCO) を低減します。

• Azure と Azure Arc を使用して複数の場所にワークロードを一貫して安全にデプロイすることで、一元的なプロビジョニング機能を提供します。 Azure Portal、Azure CLI、コードとしてのインフラストラクチャ (IaC) テンプレートなどのツールでは、コンテナー化または従来のワークロード仮想化に Kubernetes を使用して、自動化と再現性を促進します。

• 厳格なセキュリティ、コンプライアンス、監査の要件に準拠します。 Azure Stack HCI は、既定で構成されている強化されたセキュリティ体制、または既定のセキュリティ保護を使用してデプロイされます。 Azure Stack HCI には、認定ハードウェア、セキュア ブート、トラステッド プラットフォーム モジュール (TPM)、仮想化ベースのセキュリティ (VBS)、Credential Guard、および適用された Windows Defender アプリケーション制御ポリシーが組み込まれています。 また、Microsoft Defender for Cloud や Microsoft Sentinel などの最新のクラウドベースのセキュリティおよび脅威管理サービスとも統合されます。

シナリオの詳細

次のセクションでは、この参照アーキテクチャのシナリオと潜在的なユース ケースについて詳しく説明します。 これらのセクションには、ビジネス上の利点の一覧と、Azure Stack HCI にデプロイできるワークロード リソースの種類の例が含まれています。

Azure Arc と Azure Stack HCI の使用

Azure Stack HCI は、Azure Arc を使用して Azure と直接統合し、TCO と運用上のオーバーヘッドを低減します。 Azure Stack HCI は Azure を介してデプロイおよび管理されます。これにより、Azure Arc リソース ブリッジ コンポーネントのデプロイを通して Azure Arc の組み込みの統合が提供されます。 このコンポーネントは、HCI クラスターのデプロイ プロセス中にインストールされます。 Azure Stack HCI クラスター ノードは、クラスターのクラウドベースのデプロイを開始するための前提条件として、Azure Arc for servers に登録されます。 デプロイ時に、ライフサイクル マネージャー、Microsoft Edge デバイス管理、テレメトリと診断など、必須の拡張機能が各クラスター ノードにインストールされます。 Azure Stack HCI Insights を有効にすると、デプロイ後に Azure Monitor とログ分析を使用して HCI クラスターを監視できます。 カスタマー エクスペリエンスを向上させるために、Azure Stack HCI の機能更新プログラムが定期的にリリースされています。 更新プログラムは、Azure Update Manager を使用して制御および管理されます。

Azure Arc 仮想マシン (VM)、Azure Arc 対応 Azure Kubernetes Service (AKS)、Azure Portal を使用する Azure Virtual Desktop セッション ホストなどのワークロード リソースをデプロイするには、ワークロード デプロイのターゲットとして Azure Stack HCI クラスターのカスタムの場所を選択します。 これらのコンポーネントは、一元的な管理とサポートを提供します。 既存の Windows Server Datacenter コア ライセンスでアクティブなソフトウェア アシュアランスがある場合は、Azure Stack HCI、Windows Server VM、AKS クラスターに Azure ハイブリッド特典を適用することで、コストをさらに削減できます。 この最適化は、これらのサービスのコストを効果的に管理するのに役立ちます。

Azure と Azure Arc を統合すると、Azure Stack HCI 仮想化およびコンテナー化されたワークロードの機能が拡張され、次のものが含まれるようになります。

• Azure Arc VM Azure Stack HCI 上の VM で実行される従来のアプリケーションまたはサービス用です。

• Kubernetes をオーケストレーション プラットフォームとして使用することでメリットを得られるコンテナ化されたアプリケーションまたはサービス用の AKS on Azure Stack HCI。

• Azure Stack HCI (オンプレミス) に Azure Virtual Desktop ワークロードのセッション ホストをデプロイする Azure Virtual Desktop。 Azure のコントロールと管理プレーンを使用して、ホスト プールの作成と構成を開始することができます。

• コンテナー化された Azure SQL Managed Instance、または Azure Stack HCI でホストされている Azure Arc-enabled AKS を使用する Azure Database for PostgreSQL サーバー用の Azure Arc 対応データ サービス。

• Event Grid ブローカーと Event Grid 演算子コンポーネントをデプロイする Kubernetes 用の Azure Arc 対応 Azure Event Grid 拡張機能。 このデプロイにより、Event Grid トピックやイベント処理のサブスクリプションなどの機能が有効になります。

• Azure Arc 対応機械学習。Azure Machine Learning を実行するためのコンピューティング先として Azure Stack HCI にデプロイされた AKS クラスターを使用します。 このアプローチを使用して、エッジで機械学習モデルをトレーニングまたはデプロイすることができます。

Azure Arc に接続されたワークロードでは、Azure Stack HCI デプロイの Azure 整合性と自動化が強化されます。これには、Azure Arc VM 拡張機能を使用したゲスト OS 構成の自動化や、Azure Policy を使用した業界の規制や企業標準への準拠の評価などがあります。 Azure Policy は、Azure Portal または IaC 自動化を使用してアクティブ化できます。

Azure Stack HCI の既定のセキュリティ構成を利用する

Azure Stack HCI の既定のセキュリティ構成では、セキュリティとコンプライアンスのコストを簡素化するための多層防御戦略が提供されます。 小売業、製造業、リモート オフィスのシナリオ向けの IT サービスのデプロイと管理には、固有のセキュリティとコンプライアンスの課題があります。 内部および外部の脅威に対するワークロードのセキュリティ保護は、IT サポートが限られている環境や、データセンターが不足している環境、または専用になっている環境では重要です。 Azure Stack HCI には、既定のセキュリティ強化と Azure サービスとの緊密な統合があり、これらの課題に対処するのに役立ちます。

Azure Stack HCI 認定ハードウェアによって、セキュアブート、Unified Extensible Firmware Interface (UEFI)、および TPM のサポートが組み込まれています。 これらのテクノロジを VBS と組み合わせて使用して、セキュリティに依存するワークロードを保護します。 BitLocker ドライブ暗号化を使用して、ブート ディスク ボリュームと保存されている記憶域スペース ダイレクト ボリュームを暗号化できます。 サーバー メッセージ ブロック (SMB) 暗号化では、クラスター内の (ストレージ ネットワーク上の) サーバー間のトラフィックの自動暗号化と、クラスター ノードと他のシステム間の SMB トラフィックの署名が提供されます。 SMB 暗号化は、リレー攻撃を防ぎ、規制基準への準拠を容易にするのにも役立ちます。

Defender for Cloud に 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) パートナーによって提供される検証済み、統合済み、または Premium のハードウェア カテゴリを使用して、単一ノードのデプロイから最大 16 ノードにスケーリングできます。

• Azure Arc は、Azure Resource Manager に基づく管理モデルを Azure Stack HCI やその他の Azure 以外の場所に拡張するクラウドベースのサービスです。 Azure Arc は、Azure をコントロールと管理プレーンとして使用することで、VM、Kubernetes クラスター、コンテナー化されたデータや機械学習サービスなどのさまざまなリソースの管理を可能にします。

• Azure Key Vault は、シークレットを安全に格納してアクセスするために使用できるクラウド サービスです。 シークレットとは、API キー、パスワード、証明書、暗号化キー、ローカル管理者の資格情報、BitLocker 回復キーなど、アクセスを厳しく制限するすべてのものです。

• クラウド監視は、フェールオーバー クラスター クォーラムとして機能する Azure Storage の機能です。 Azure Stack HCI クラスター ノードでは、投票にこのクォーラムが使用されるため、クラスターの高可用性が確保されます。 ストレージ アカウントと監視構成は、Azure Stack HCI クラウド デプロイ プロセス中に作成されます。

• Update Manager は、Azure Stack HCI の更新プログラムを管理および制御するために設計された統合サービスです。 Update Manager を使用すると、Windows および Linux VM のゲスト OS 更新コンプライアンスを含む、Azure Stack HCI にデプロイされているワークロードを管理することができます。 この統合されたアプローチにより、1 つのダッシュボードを使用して、Azure、オンプレミス環境、およびその他のクラウド プラットフォーム全体でのパッチ管理が効率化されます。

プラットフォームをサポートするリソース

このアーキテクチャには、プラットフォームの機能を強化するための次のオプションのサポート サービスが含まれています。

• Monitor は、クラウドとオンプレミスのワークロードから診断ログとテレメトリを収集、分析、および処理するためのクラウドベースのサービスです。 Monitor を使用すると、包括的な監視ソリューションを通してアプリケーションおよびサービスの可用性とパフォーマンスを最大化できます。 Azure Stack HCI Insights をデプロイして、監視データ コレクション ルール (DCR) の作成を簡略化し、Azure Stack HCI クラスターの監視をすばやく有効にします。

• Azure Policy は、Azure とオンプレミスのリソースを評価するサービスです。 Azure Policy では、Azure Arc の統合を通じて、リソースのプロパティをポリシー定義と呼ばれるビジネス ルールと比較してリソースを評価し、ポリシー設定を使用して VM ゲスト構成を適用するために使用できるコンプライアンスまたは機能を決定します。

• Defender for Cloud は、包括的なインフラストラクチャ セキュリティ管理システムです。 データセンターのセキュリティ体制が強化され、ハイブリッド ワークロードが存在している場所が Azure なのか他の場所なのかにかかわらず、オンプレミス環境全体で高度な脅威保護が提供されます。

• Azure Backup はクラウドベースのサービスです。データをバックアップし、それを Microsoft Cloud から復旧するための、シンプルで安全かつコスト効率の高いソリューションを提供しています。 Azure Backup Server は、Azure Stack HCI にデプロイされている VM のバックアップを作成し、それらをバックアップ サービスに格納するために使用されます。

• Site Recovery は、災害や障害が発生した場合にビジネス アプリとワークロードをフェールオーバーできるようにすることで BCDR 機能を提供するディザスター リカバリー サービスです。 Site Recovery は、物理マシンと VM で実行されるワークロードのレプリケーションとフェールオーバーをプライマリ サイト (オンプレミス) とセカンダリ ロケーション (Azure) の間で管理します。

クラスター設計の選択肢

Azure Stack HCI クラスターを設計するときは、ワークロードのパフォーマンスと回復性の要件を理解することが重要です。 これらの要件には、Azure Stack HCI クラスターにデプロイされているすべてのワークロードの目標復旧時間 (RTO) と目標復旧時点 (RPO) 時間、コンピューティング (CPU)、メモリ、ストレージの要件が含まれます。 ワークロードには意思決定プロセスに影響を与える特性がいくつかあり、次のものが含まれます。

• ハードウェア セキュリティ テクノロジ機能、CPU の数、GHz 周波数 (速度)、CPU ソケットあたりのコア数を含む、中央処理装置 (CPU) アーキテクチャ機能。

• AI や機械学習、推論、グラフィックス レンダリングなど、ワークロードのグラフィックス処理装置 (GPU) の要件。

• ノードあたりのメモリ、またはワークロードの実行に必要な物理メモリの量。

• スケール内の 1 から 16 個のノードであるクラスター内の物理ノードの数。 ストレージ スイッチレス ネットワーク アーキテクチャを使用する場合、ノードの最大数は 3 です。

  • コンピューティングの回復性を維持するには、クラスター内の少なくとも N+1 ノード分の容量を確保する必要があります。 この戦略により、停電やハードウェア障害などの突然の停止からの更新または復旧のためにノードのドレインが可能になります。

  • ビジネス クリティカルまたはミッション クリティカルなワークロードの場合は、回復性を高めるために、N+2 ノードに相当する容量を確保することを検討してください。 たとえば、クラスター内の 2 つのノードがオフラインでも、ワークロードがオンラインのまま続行できます。 このアプローチにより、計画された更新手順中にワークロードを実行しているノードがオフラインになり、結果として 2 つのノードが同時にオフラインになるシナリオでの回復性が提供されます。

• ストレージの回復性、容量、およびパフォーマンスの要件:

  • 回復性: 3 つ以上のノードをデプロイして、インフラストラクチャとユーザー ボリュームに対してデータの 3 つのコピーを提供する、3 方向ミラーリングを有効にすることをお勧めします。 3 方向ミラーリングにより、パフォーマンスが向上し、ストレージの信頼性が最大限に高まります。

  • 容量: フォールト トレランス (複製) 後に必要な使用可能なストレージの合計が考慮されます。 この数値は、3 方向ミラーリングを使用する場合、容量層ディスクの raw ストレージ領域の約 33% です。

  • パフォーマンス: アプリケーションのブロック サイズを乗算したときのワークロードのストレージ スループット機能を決定するプラットフォームの 1 秒あたりの入出力処理 (IOPS)。

Azure Stack HCI デプロイを設計して計画するには、Azure Stack HCI サイズ設定ツールを使用して、HCI クラスターのサイズを設定するための新しいプロジェクトを作成することをお勧めします。 サイズ設定ツールを使用するには、ワークロードの要件を理解している必要があります。 クラスターで実行されるワークロード VM の数とサイズを考慮する場合は、vCPU の数、メモリ要件、VM に必要なストレージ容量などの要因を必ず考慮してください。

サイズ設定ツールの [ユーザー設定] セクションでは、システムの種類 (Premier、統合システム、または検証済みノード) と CPU ファミリ オプションに関連する質問についてガイドします。 また、クラスターの回復性要件を選択する際にも役立ちます。 次のことを確認します。

• クラスター全体で、少なくとも N + 1 ノード分の容量または 1 つのノードを確保します。

• クラスター全体で N + 2 ノード分の容量を確保して、追加の回復性を持たせます。 このオプションを使用すると、更新時のノードで障害が発生した場合やその他の予期しないイベント時に 2 つのノードが同時に影響を受ける場合に、システムが耐えることができます。 また、残りのオンラインのノードでワークロードを実行するのに十分な容量をクラスター内に確保できます。

このシナリオでは、ユーザー ボリュームに対して 3 方向ミラーリングを使用する必要があります。これは、3 つ以上の物理ノードを持つクラスターの既定値です。

Azure Stack HCI サイズ設定ツールからの出力は、Sizer Project の入力値に基づいて、必要なワークロード容量とプラットフォームの回復性要件を提供できる、推奨されるハードウェア ソリューション SKU の一覧です。 使用可能な OEM ハードウェア パートナー ソリューションの詳細については、「Azure Stack HCI ソリューション カタログ」を参照してください。 要件を満たすためにソリューション SKU を適切にサイズ変更するには、お好みのハードウェア ソリューション プロバイダーまたはシステム統合 (SI) パートナーにお問い合わせください。

物理ディスク ドライブ

記憶域スペース ダイレクトでは、パフォーマンスと容量が異なる複数の物理ディスク ドライブの種類がサポートされます。 Azure Stack HCI クラスターを設計するときは、選択したハードウェア OEM パートナーと協力して、ワークロードの容量とパフォーマンスの要件を満たすために最適な物理ディスク ドライブの種類を決定してください。 たとえば、回転式ハード ディスク ドライブ (HDD)、ソリッド ステート ドライブ (SSD) ドライブ、NVMe ドライブなどがあります。 これらのドライブは、多くの場合、フラッシュ ドライブまたは永続メモリ (PMem) ストレージと呼ばれます。これは、ストレージ クラス メモリ (SCM) とも呼ばれています。

プラットフォームの信頼性は、物理ディスクの種類など、重要なプラットフォームの依存関係のパフォーマンスによって異なります。 要件に適したディスクの種類を確実に選択してください。 高パフォーマンスまたは低遅延の要件があるワークロードには、NVMe ドライブや SSD ドライブなどのオール フラッシュ ストレージ ソリューションを使用します。 これらのワークロードには、高度なトランザクション データベース テクノロジ、運用 AKS クラスター、低遅延または高スループットのストレージ要件を持つミッション クリティカルまたはビジネス クリティカルなワークロードが含まれますが、これらに限定されません。 オールフラッシュの展開は、ストレージのパフォーマンスを最大化するために使用します。 すべての NVMe ドライブまたはすべての SSD ドライブ構成 (特に小規模) では、ドライブがキャッシュ層として使用されないため、記憶域の効率が向上し、パフォーマンスが最大化されます。詳細については、「オール フラッシュ ベースの記憶域」を参照してください。

汎用ワークロードの場合、NVMe ドライブやキャッシュ用 SSD、容量用の HDD など、ハイブリッド ストレージ構成では、より多くの記憶域領域が提供される場合があります。 トレードオフとして、ワークロードがキャッシュのワーキング セットを超えると、回転式ディスクのパフォーマンスが低下し、HDD の平均故障間隔は NVMe ドライブと SSD ドライブと比べて低くなります。

クラスター ストレージのパフォーマンスは、物理ディスク ドライブの種類によって影響を受けます。これは、各ドライブの種類のパフォーマンス特性と、選択したキャッシュ メカニズムによって異なります。 物理ディスク ドライブの種類は、記憶域スペース ダイレクトの設計と構成に不可欠な部分です。 Azure Stack HCI のワークロード要件と予算の制約によっては、パフォーマンスを最大化したり、容量を最大化したり、パフォーマンスと容量間のバランスを取る混合ドライブ タイプの構成を実装したりすることができます。

記憶域スペース ダイレクトには、ストレージのパフォーマンスを最大化する、組み込み、永続的、読み取り、書き込みのサーバー側キャッシュが用意されています。 キャッシュは、アプリケーションとワークロードのワーキングセットに対応するようにサイズを設定し、構成する必要があります。 記憶域スペース ダイレクト仮想ディスク (ボリューム) は、クラスター共有ボリューム (CSV) のメモリ内読み取りキャッシュと組み合わせて使用され、特にワークロード仮想ハード ディスク (VHD) または仮想ハード ディスク v2 (VHDX) ファイルへのバッファーなしの入力アクセスにおいて、Hyper-V のパフォーマンスを向上させます。

ネットワーク設計

ネットワーク設計は、ネットワークの物理インフラストラクチャと論理構成内のコンポーネントの全体的な配置です。 同じ物理ネットワーク インターフェイス カード (NIC) ポートを、管理、コンピューティング、およびストレージ ネットワーク インテントのすべての組み合わせに使用できます。 インテントに関連するすべての目的で同じ NIC ポートを使用することは、完全に収束されたネットワーク構成と呼ばれます。

完全に収束されたネットワーク構成もサポートされていますが、パフォーマンスと信頼性に最適な構成は、ストレージ インテントで専用ネットワーク アダプター ポートを使用することです。 したがって、このベースライン アーキテクチャでは、管理とコンピューティングのインテントに収束された 2 つのネットワーク アダプター ポートと、ストレージ インテント用の 2 つの専用ネットワーク アダプター ポートを備えたストレージ切り替えネットワーク アーキテクチャを使用して、マルチノード Azure Stack HCI クラスターをデプロイする方法のガイダンスの例を示します。 詳細については、「Azure Stack HCI のクラウド デプロイに関するネットワーク上の考慮事項」を参照してください。

このアーキテクチャでは、2 つ以上の物理ノードが必要で、最大 16 ノードまで拡張できます。 各ノードには、2 つの Top-of-Rack (ToR) スイッチに接続されている 4 つのネットワーク アダプター ポートが必要です。 2 つの ToR スイッチは、マルチシャーシ リンク アグリゲーション グループ (MLAG) リンクを介して相互接続する必要があります。 ストレージ インテント トラフィックに使用される 2 つのネットワーク アダプター ポートは、リモート ダイレクト メモリ アクセス (RDMA)をサポートする必要があります。 これらのポートには 10 Gbps の最小リンク速度が必要ですが、25 Gbps 以上の速度をお勧めします。 管理とコンピューティングのインテントに使用される 2 つのネットワーク アダプター ポートは、スイッチ埋め込みチーミング (SET) テクノロジを使用して収束されます。 SET テクノロジは、リンクの冗長性と負荷分散機能を提供します。 これらのポートには 1 Gbps の最小リンク速度が必要ですが、10 Gbps 以上の速度をお勧めします。

物理ネットワーク トポロジ

次の物理ネットワーク トポロジは、ノードとネットワーク コンポーネント間の実際の物理接続を示しています。

このベースライン アーキテクチャを使用するマルチノード ストレージ切り替え Azure Stack HCI デプロイを設計する場合は、次のコンポーネントが必要です。

• デュアル ToR スイッチ:

  • デュアル ToR ネットワーク スイッチは、ネットワークの回復性と、ダウンタイムを発生させることなくスイッチにファームウェア更新プログラムを提供または適用する機能に必要です。 この戦略により、単一障害点 (SPoF) を防ぐことができます。

  • デュアル ToR スイッチは、ストレージ (east-west) のトラフィックに使用されます。 これらのスイッチは、特定の記憶域仮想ローカル エリア ネットワーク (VLAN) と、無損失 RDMA 通信を提供するために定義された優先度フロー制御 (PFC) トラフィック クラスを持つ 2 つの専用イーサネット ポートを使用します。

  • これらのスイッチは、イーサネット ケーブルを介してノードに接続します。

• 2 つ以上の物理ノードと最大 16 個のノード:

  • 各ノードは、Azure Stack HCI OS を実行する物理サーバーです。

  • 各ノードには、合計で 4 つのネットワーク アダプター ポートが必要です。ストレージ用の 2 つの RDMA 対応ポートと、管理トラフィックとコンピューティング トラフィック用の 2 つのネットワーク アダプター ポートです。

  • ストレージは、2 つの ToR スイッチのそれぞれに 1 つのパスで接続する 2 つの専用 RDMA 対応ネットワーク アダプター ポートを使用します。 この方法では、SMB ダイレクト ストレージ トラフィックに対するリンク パスの冗長性と専用の優先帯域幅が提供されます。

  • 管理とコンピューティングでは、リンク パスの冗長性のために、2 つの ToR スイッチのそれぞれに 1 つのパスを提供する 2 つのネットワーク アダプター ポートを使用します。

• 外部接続:

  • デュアル ToR スイッチは、社内 LAN などの外部ネットワークに接続し、エッジ ボーダー ネットワーク デバイスを使用して必要な送信 URL にアクセスできるようにします。 このデバイスには、ファイアウォールまたはルーターを使用できます。 これらのスイッチは、Azure Stack HCI クラスターとの間で送受信されるトラフィック、または north-south トラフィックをルーティングします。

  • 外部の north-south トラフィック接続では、クラスター管理のインテントとコンピューティングのインテントがサポートされます。 これは、回復性を確保するために、スイッチ埋め込みチーミング (SET) と Hyper-V 内の仮想スイッチを介して収束されるノードごとに、2 つのスイッチ ポートと 2 つのネットワーク アダプター ポートを使用することで実現されます。 これらのコンポーネントは、Azure Portal、CLI、または IaC テンプレートを使用して Resource Manager で作成された論理ネットワーク内にデプロイされた Azure Arc VM やその他のワークロード リソースに外部接続を提供する役割を果たしています。

論理ネットワーク トポロジ

論理ネットワーク トポロジは、物理接続に関係なく、デバイス間のネットワーク データフローの概要を示します。

Azure Stack HCI のこのマルチノード ストレージ切り替えベースライン アーキテクチャの論理セットアップの概要を、次に示しています。

• デュアル ToR スイッチ:

  • クラスターをデプロイする前に、2 つの ToR ネットワーク スイッチを、必要な VLAN ID、最大転送ユニット設定、管理、コンピューティング、およびストレージ ポートのデータセンター ブリッジ構成で構成する必要があります。 詳細については、「Azure Stack HCI の物理ネットワーク要件」を参照するか、スイッチ ハードウェア ベンダーまたは SI パートナーにサポートを依頼してください。

• Azure Stack HCI では、Network ATC アプローチを使用して、ネットワーク自動化とインテントベースのネットワーク構成を適用します。

  • ネットワーク ATC は、ネットワーク トラフィック インテントを使用して、最適なネットワーク構成とトラフィック フローを確保するように設計されています。 ネットワーク ATC では、クラスター管理、ワークロード コンピューティング、クラスター ストレージ のインテントなど、さまざまなネットワーク トラフィックのインテント (または種類) に使用される物理ネットワーク アダプター ポートを定義します。

  • インテント ベースのポリシーは、Azure Stack HCI クラウド デプロイ プロセスの一部として指定されたパラメーター入力に基づいてノード ネットワーク構成を自動化することで、ネットワーク構成要件を簡略化します。

• 外部通信:

  • ノードまたはワークロードが、社内 LAN、インターネット、または別のサービスにアクセスして外部と通信する必要がある場合は、デュアル ToR スイッチを使用してルーティングします。 このプロセスの概要については、前の「物理ネットワーク トポロジ」セクションを参照してください。

  • 2 つの ToR スイッチがレイヤー 3 デバイスとして動作する場合は、これらのスイッチはルーティングを処理し、クラスターを超えてファイアウォールやルーターなどのエッジ ボーダー デバイスへの接続を提供します。

  • 管理ネットワークのインテントでは、収束された SET チーム仮想インターフェイスを使用します。これにより、クラスター管理 IP アドレスとコントロール プレーン リソースが外部と通信できるようになります。

  • コンピューティング ネットワークのインテントでは、環境に合わせて特定の VLAN ID を持つ 1 つ以上の論理ネットワークを Azure に作成することができます。 VM などのワークロード リソースでは、これらの ID を使用して物理ネットワークへのアクセスを許可します。 論理ネットワークは、コンピューティングと管理のインテントに SET チームを使用して収束される 2 つの物理ネットワーク アダプター ポートを使用します。

• ストレージ トラフィック:

  • 物理ノードは、ToR スイッチに接続されている 2 つの専用ネットワーク アダプター ポートを使用して相互に通信し、ストレージ トラフィックに高帯域幅と回復性を提供します。

  • SMB1 および SMB2 ストレージ ポートは、2 つの独立したルーティング不可能な (またはレイヤー 2) ネットワークに接続します。 各ネットワークには、特定の VLAN ID が設定されており、これは ToR スイッチの既定のストレージ VLAN ID (711 と 712) のスイッチ ポート設定と一致する必要があります。

  • Azure Stack HCI ノード OS 内の 2 つのストレージ インテント ネットワーク アダプター ポートには、既定のゲートウェイは構成されていません。

  • 各ノードは、記憶域プール、仮想ディスク、ボリュームで使用されるリモート物理ディスクなど、クラスターの記憶域スペース ダイレクト機能にアクセスできます。 これらの機能へのアクセスは、各ノードで使用可能な 2 つの専用記憶域ネットワーク アダプター ポートを介して、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 アドレスの数が 1 つのクラスター内で最大 16 ノードまで増加します。 たとえば、Azure Stack HCI の 2 ノードのストレージ切り替え構成をデプロイするには、クラスター インフラストラクチャに少なくとも 11 個の IP アドレスを割り当てる必要があります。 マイクロセグメンテーションまたはソフトウェア定義ネットワークを使用する場合は、さらに多くの IP アドレスが必要です。 詳細については、「Azure Stack HCI の 2 ノード ストレージ参照パターンの IP アドレス要件を確認する」を参照してください。

Azure Stack HCI の IP アドレス要件を設計して計画するときは、Azure Stack HCI クラスターとインフラストラクチャ コンポーネントに必要な IP アドレスまたはネットワーク範囲を超えて、ワークロードに必要な追加の IP アドレスまたはネットワーク範囲を考慮してください。 Azure Stack HCI に AKS をデプロイする予定の場合は、「Azure Arc ネットワーク要件で有効になっている AKS」を参照してください。

監視

監視とアラートを強化するには、Azure Stack HCI で Monitor Insights を有効にします。 Insights は、Azure の一貫性のあるエクスペリエンスを使用することによって、複数のオンプレミス クラスターを監視および管理するためにスケールすることができます。 Insights では、クラスター パフォーマンス カウンターとイベント ログ チャネルを使用して、Azure Stack HCI の主要な機能を監視します。 ログは、Monitor とログ分析を使用して構成された DCR によって収集されます。

Azure Stack HCI Insights は、Monitor とログ分析を使用して構築されており、高度にカスタマイズ可能で常に最新のスケーラブルなソリューションが保証されます。 Insights では、Azure Stack HCI の主な機能を監視するために作成された特殊なブックと共に、基本的なメトリックを含む既定のブックにアクセスできます。 これらのコンポーネントは、ほぼリアルタイムの監視ソリューションを実現し、グラフの作成、集計とフィルター処理による視覚化のカスタマイズ、カスタム リソース正常性アラート ルールの構成を可能にしています。

Update Management

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 ハードウェアに Premier ソリューション カテゴリ バージョンを使用する場合、ソリューション ビルダー拡張機能パッケージの更新プログラムは Update Manager と統合され、これによりシンプルな更新エクスペリエンスが提供されます。 検証済みノードまたは統合システム カテゴリを使用する場合は、ハードウェアのファームウェアとドライバーの更新プログラムを含む OEM 固有の更新プログラム パッケージをダウンロードして実行する必要がある場合があります。 ハードウェアの更新プログラムの提供方法を確認するには、ハードウェア OEM または SI パートナーにお問い合わせください。

ワークロード ゲスト OS の修正プログラムの適用

Azure Stack HCI にデプロイされた Azure Arc VM は、Azure Update Manager (AUM) を使用して登録することができ、これにより、Azure Stack HCI クラスターの物理ノードの更新に使用されるのと同じメカニズムを使用して、統一されたパッチ管理エクスペリエンスを実現することができます。 AUM を使用すると、ゲスト メンテナンス構成を作成できます。 これらの構成では、必要に応じて再起動する再起動設定、スケジュール (日付、時刻、および繰り返しオプション)、スコープの Azure Arc VM の動的 (サブスクリプション) または静的リストなどの設定を制御します。 これらの設定は、ワークロード VM のゲスト OS 内に OS セキュリティ パッチがインストールされるタイミングの構成を制御します。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

潜在的な障害ポイントを特定する

すべてのアーキテクチャは、障害の影響を受けやすくなります。 障害モード解析によって障害を予測し、軽減策を準備しておくことができます。 次の表では、このアーキテクチャで障害が発生する可能性がある 4 つの例を示します。

詳細については、「エラー モード分析を実行するための推奨事項」を参照してください。

信頼性のターゲット

このセクションでは、シナリオの例について説明します。 Contoso Manufacturing という架空の顧客が、この参照アーキテクチャを使用して Azure Stack HCI のデプロイを行います。 同社は、要件に対処し、オンプレミスでワークロードをデプロイおよび管理したいと考えています。 Contoso Manufacturing では、ビジネスとアプリケーションの利害関係者がサービスに対して合意する、99.8% のサービスレベル目標 (SLO) を社内で設定しています。

• SLO のアップタイム (可用性) が 99.8% の場合、Azure Stack HCI 上で実行される Azure Arc VM を使用してデプロイされたアプリケーションに対して、ダウンタイム (または使用不能) が許容される時間は次のようになります。

  • 週: 20 分 10 秒。

  • 月: 1 時間 26 分 56 秒。

  • 四半期: 4 時間 20 分 49 秒

  • 年: 17 時間 23 分 16 秒

• SLO ターゲットを満たすために Contoso Manufacturing では、最小限の特権の原則 (PoLP) を実装して、Azure Stack HCI クラスター管理者の数を信頼できる資格のある少数の個人のグループに制限します。 このアプローチは、運用リソースに対して不注意な、または偶発的なアクションが実行されることによるダウンタイムを防ぐのに役立ちます。 さらに、オンプレミスの Active Directory Domain Services (AD DS) ドメイン コントローラーのセキュリティ イベント ログの監視を行い、セキュリティ情報イベント管理 (SIEM) ソリューションを使用して、Azure Stack HCI クラスター管理者グループのユーザー アカウント グループ メンバーシップの変更 (追加と削除のアクション) を検出して報告します。 監視を行うことで、信頼性が向上し、ソリューションのセキュリティが向上します。

  詳細については、「ID およびアクセス管理に関する推奨事項」をご覧ください。

• Contoso Manufacturing の本番システムでは、厳密な変更管理手順が適用されています。 このプロセスでは、本番環境への導入前に、代表となるテスト環境ですべての変更をテストし、検証することが義務付けられています。 週次変更諮問委員会プロセスに送信されるすべての変更には、詳細な実装計画 (またはソース コードへのリンク)、リスク レベル スコア、包括的なロールバック計画、リリース後のテストと検証、および変更をレビューまたは承認するための明確な成功基準が含まれている必要があります。

  詳細については、「安全なデプロイ方法に関する推奨事項」を参照してください。

• 毎月のセキュリティ パッチと四半期ごとのベースライン更新プログラムは、運用前環境で検証された後にのみ、運用環境の Azure Stack HCI クラスターに適用されます。 Update Manager とクラスター対応の更新機能により、VM ライブ マイグレーションを使用するプロセスが自動化され、毎月の保守作業時のビジネス クリティカルなワークロードのダウンタイムが最小限に抑えられます。 Contoso Manufacturing の標準的な運用手順では、リリース日から 4 週間以内にすべての運用システムにセキュリティ、信頼性、またはベースライン ビルドの更新プログラムが適用されている必要があります。 このポリシーがないと、運用システムは、毎月の OS とセキュリティの更新プログラムで常に最新の状態を維持することができません。 古いシステムは、プラットフォームの信頼性とセキュリティに悪影響を及ぼします。

  詳細については、「セキュリティ ベースラインを確立するための推奨事項」を参照してください。

• Contoso Manufacturing では、毎日、毎週、および毎月のバックアップを実装し、過去 6 日間の毎日のバックアップ (月曜日から土曜日)、過去 3 週間の特定の曜日 (毎週日曜日)、および 3 か月間毎月 (第 4 週の日曜日のバックアップを １か月目、２か月目、３か月目として保持) のバックアップを保持します。これは、カレンダー ベースのローリング スケジュールを使用して実行され、ドキュメント化され監査可能なものとなります。 このアプローチは、使用可能なデータ復旧ポイントの数とオフサイトまたはクラウド バックアップ ストレージ サービスのコストの削減との間の適切なバランスを取るための、Contoso の製造要件を満たします。

  詳細については、「ディザスター リカバリー戦略を設計するための推奨事項」を参照してください。

• データのバックアップと復旧のプロセスのテストが実施され、これは 6 か月ごとに各ビジネス システムに対して行われます。 この戦略により、BCDR プロセスが有効であり、データセンターでの障害やサイバー インシデントが発生した場合にビジネスが保護されることを保証することができます。

  詳細については、「信頼性テスト戦略の設計に関する推奨事項」を参照してください。

• この記事で前述した運用プロセスと手順、および「Azure Stack HCI での Well-Architected Framework サービスのガイド」にある推奨事項により、Contoso Manufacturing は 99.8% の SLO ターゲットを満たし、世界中に分散している複数の製造拠点で Azure Stack HCI とワークロードのデプロイを効果的にスケーリングおよび管理することができます。

  詳細については、「信頼性目標の定義に関する推奨事項」を参照してください。

冗長性

"ローカル冗長展開" として 1 つの Azure Stack HCI クラスターに展開するワークロードを考えてみましょう。 クラスターはプラットフォーム レベルで高可用性を提供しますが、クラスターを 1 つのラックにデプロイする必要があります。 ビジネス クリティカルまたはミッション クリティカルなユース ケースの場合は、ワークロードまたはサービスの複数のインスタンスを 2 つ以上の個別の Azure Stack HCI クラスターにまたがって、理想的には、別々の物理的な場所にデプロイすることをお勧めします。

アクティブ/パッシブ レプリケーション、同期レプリケーション、または SQL Server Always On などの非同期レプリケーションを提供するワークロードには、業界標準の高可用性パターンを使用します。 また、別の物理的な場所にデプロイする Azure Stack HCI クラスターで実行される複数のワークロード インスタンス間でユーザー要求をルーティングする、外部ネットワーク負荷分散 (NLB) テクノロジを使用することもできます。 パートナーの外部 NLB デバイスの使用を検討してください。 あるいは、Azure ExpressRoute または VPN トンネルを使用してオンプレミス サービスに接続する Azure Application Gateway インスタンスなど、ハイブリッド サービスとオンプレミス サービスのトラフィック ルーティングをサポートする負荷分散オプションを査定することもできます。

詳細については、「冗長性の設計に関する推奨事項」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

セキュリティに関する考慮事項は次のとおりです。

• 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 for Cloud は、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 の価格は、月次サブスクリプションの課金モデルに従います。1 つの Azure Stack HCI クラスター内の物理プロセッサ コアあたりの料金が定額です。 他の Azure サービスを使用する場合は、追加の使用料金が適用されることがあります。 Windows Server Datacenter エディションのオンプレミス コア ライセンスを所有しており、有効なソフトウェア アシュアランスがある場合は、これらのライセンスを交換して、Azure Stack HCI クラスターと Windows Server VM サブスクリプション料金をアクティブ化することを選択できます。

• Azure Arc VM の VM ゲストの自動パッチ適用: この機能は、手動パッチ適用のオーバーヘッドと関連するメンテナンス コストを削減するのに役立ちます。 この機能を使用することは、システムの安全性を高めるだけでなく、リソースの割り当てを最適化し、全体的なコスト効率の向上に寄与します。

• コストの監視の統合: コストの監視を統合するには、Azure Stack HCI Insights を使用し、Azure Stack HCI に Update Manager を使用して修正プログラムを適用します。 Insights では、豊富なメトリックとアラート機能を提供する Monitor が使用されます。 Azure Stack HCI のライフサイクル マネージャー コンポーネントは Update Manager と統合して、さまざまなコンポーネントの更新ワークフローを 1 つのエクスペリエンスに統合することで、クラスターを最新の状態に維持するタスクを簡略化します。 Monitor と Update Manager を使用してリソースの割り当てを最適化し、全体的なコスト効率に貢献します。

  詳細については、「職員の時間を最適化するための推奨事項」を参照してください。

• 初期ワークロードの容量と拡張: 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 Arc VM などのワークロードを管理するためのさまざまな自動化機能が用意されています。たとえば、Azure CLI、ARM、Bicep テンプレートを使用した Azure Arc VM の自動デプロイや、Azure Arc Extension for Updates と Azure Update Manager を使用した仮想マシン OS の更新による 各 Azure Stack HCI クラスターの更新などがあります。 また、Azure Stack HCI では、AzureArc VM の管理を Azure CLI で、非 Azure Arc VM の管理を Windows PowerShell でサポートします。 Azure CLI コマンド は、いずれかの Azure Stack HCI サーバーからローカルで実行するか、管理コンピューターからリモートで実行することができます。 Azure Automation と Azure Arc との統合により、Azure Arc 拡張機能を通じて VM ワークロードに対するさまざまな追加の自動化シナリオが容易になります。

  詳細については、「IaC の使用に関する推奨事項」を参照してください 。

• AKS 上のコンテナーの自動化機能: Azure Stack HCI には、AKS 上のコンテナーなどのワークロードを管理するためのさまざまな自動化機能が用意されています。 AKS クラスターのデプロイを自動化するには、Azure CLI を使用することができます。 Kubernetes 更新プログラムの Azure Arc 拡張機能を使用して AKS ワークロード クラスターを更新します。 Azure CLI を使用して Azure Arc-enabled AKS を管理することもできます。 Azure CLI コマンド は、いずれかの Azure Stack HCI サーバーからローカルで実行するか、管理コンピューターからリモートで実行することができます。 Azure Arc と統合すると、Azure Arc 拡張機能を使用してコンテナー化されたワークロードに対するさまざまな追加の自動化シナリオを実現できます。

  詳細については、「自動化を有効にするための推奨事項」を参照してください。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

パフォーマンスの効率に関する考慮事項は次のとおりです。

• ワークロード ストレージのパフォーマンス: Azure Stack HCI クラスターのワークロード ストレージパフォーマンス機能をテストするために、DiskSpd ツールの使用を検討してください。 VMFleet ツールを使用して、負荷を生成し、ストレージ サブシステムのパフォーマンスを測定できます。 ストレージ サブシステムのパフォーマンスを測定するために VMFleet を使用する必要があるかどうか評価を行いまます。

  • 運用環境のワークロードをデプロイする前に、Azure Stack HCI クラスターのパフォーマンスのベースラインを確立することをお勧めします。 DiskSpd は、管理者がクラスターのストレージ パフォーマンスをテストできるようにするさまざまなコマンド ライン パラメーターを使用します。 DiskSpd の主な機能は、読み取り操作と書き込み操作を発行し、パフォーマンス メトリック (待ち時間、スループット、IOPS など) を出力することです。

    詳細については、「パフォーマンス テストに関する推奨事項」を参照してください。

• ワークロード ストレージの回復性: ストレージの回復性、使用 (または容量) の効率、パフォーマンスの利点を考慮します。 Azure Stack HCI ボリュームの計画には、回復性、使用効率、およびパフォーマンスの最適なバランスを特定する作業が含まれます。 これらの特性の 1 つを最大化すると、通常、他の 1 つ以上の特性に悪影響を及ぼすため、このバランスを最適化することが難しい場合があります。 回復性を高めると、使用可能な容量が減少します。 その結果、選択した回復性の種類によってパフォーマンスが異なる場合があります。 回復性とパフォーマンスが優先され、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 service などの必要な機能を理解することが含まれます。 ワークロード RTO と RPO (信頼性) の値およびその他の非機能要件 (パフォーマンス/負荷のスケーラビリティ) は、この要件収集手順の一部として文書化する必要があります。

2. 推奨されるハードウェア パートナー ソリューションについて、Azure Stack HCI サイジングの出力を確認します。 この出力には、推奨される物理サーバー ハードウェアの作成とモデル、物理ノードの数、ワークロードのデプロイと実行に必要な各物理ノードの CPU、メモリ、およびストレージ構成の仕様の詳細が含まれます。

3. Azure Stack HCI サイズ設定ツールを使用してワークロードの種類とスケールをモデル化する新しいプロジェクトを作成します。 このプロジェクトには、VM のサイズと数、およびそれらのストレージ要件が含まれます。 これらの詳細は、前の「クラスター設計の選択肢」セクションで説明したように、システムの種類、優先 CPU ファミリ、および高可用性とストレージのフォールト トレランスに関する回復性要件の選択肢と共に入力されます。

4. 推奨されるハードウェア パートナー ソリューションについて、Azure Stack HCI サイジングの出力を確認します。 このソリューションには、推奨される物理サーバー ハードウェア (メーカーとモデル)、物理ノードの数、ワークロードのデプロイと実行に必要な各物理ノードの CPU、メモリ、およびストレージ構成の仕様の詳細が含まれます。

5. ハードウェア OEM または SI パートナーに問い合わせて、推奨されるハードウェア バージョンとワークロード要件の適合性をさらに確認します。 使用可能な場合は、OEM 固有のサイズ設定ツールを使用して、目的のワークロードの OEM 固有のハードウェア サイズ要件を決定します。 通常、この手順には、ソリューションの商用側面について、ハードウェア OEM または SI パートナーとの打合せが含まれます。 これらの側面には、見積もり、ハードウェアの可用性、リード タイム、パートナーがプロジェクトやビジネスの成果を加速するために提供する専門的なサービスや付加価値サービスが含まれます。

6. ネットワーク統合のために 2 つの ToR スイッチをデプロイします。 高可用性ソリューションの場合、HCI クラスターには 2 つの ToR スイッチをデプロイする必要があります。 各物理ノードには 4 つの NIC が必要です。そのうちの 2 つは RDMA 対応である必要があり、各ノードから 2 つの ToR スイッチへの 2 つのリンクを提供します。 各スイッチに接続された 2 つの NIC は、コンピューティング ネットワークと管理ネットワークの North-South の送信接続用に収束されます。 他の 2 つの RDMA 対応 NIC は、ストレージの East-West のトラフィック専用です。 既存のネットワーク スイッチを使用する予定の場合は、スイッチの作成とモデルが、Azure Stack HCI でサポートされているネットワーク スイッチの承認された一覧にあることを確認してください。

7. ハードウェア OEM または SI パートナーと協力して、ハードウェアの配送を手配します。 その後、SI パートナーまたは自社の従業員が、ハードウェアのラッキングやスタッキング、物理ネットワーク、物理ノードの電源ユニットの配線など、オンプレミスのデータセンターまたはエッジ ロケーションへのハードウェアの統合を行う必要があります。

8. Azure Stack HCI クラスターのデプロイを実行します。 選択したソリューションのバージョン (Premier ソリューション、統合システム、または検証済みノード) に応じて、ハードウェア パートナー、SI パートナー、または自社の従業員が、Azure Stack HCI ソフトウェアをデプロイできます。 この手順は、Azure Stack HCI OS の物理ノードを Azure Arc 対応サーバーにオンボードしてから、Azure Stack HCI クラウド デプロイ プロセスを開始することから始めます。 お客様とパートナーは、要求の性質とハードウェア ソリューション カテゴリに応じて、Azure Portal でサポートとトラブルシューティングのアイコンを選択して Microsoft に直接サポート要求を送信するか、ハードウェア OEM または SI パートナーに連絡することができます。

   ヒント

   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 は更新プログラムを適用し、1 つのクラスターまたは複数のクラスターに更新プログラムをインストールするための一元的でスケーラブルなソリューションを提供します。 ハードウェア ドライバーとファームウェアの更新プログラムをインストールするプロセスについては、ハードウェア OEM パートナーに問い合わせて決定してください。このプロセスは、選択したハードウェア ソリューション カテゴリの種類 (Premier ソリューション、統合システム、または検証済みノード) によって異なる可能性があります。 詳細については、「インフラストラクチャの更新」を参照してください。

関連リソース

• ハイブリッド アーキテクチャの設計
• Azure ハイブリッド オプション
• ハイブリッド環境における自動化
• Azure Automation State Configuration
• 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 ワークロードを保護する
• モニターの概要
• 変更履歴とインベントリの概要
• Update Manager の概要
• 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 Monitor を構成する
• Azure でサイトの回復ソリューションを設計する
• Azure Arc 対応サーバーの概要
• Azure Arc 対応データ サービスの概要
• AKS の概要
• Scale model deployment with Machine Learning anywhere (Machine Learning を使用して任意の場所でモデル デプロイをスケーリングする) - 技術コミュニティ ブログ
• Realizing Machine Learning anywhere with AKS and Azure Arc-enabled Machine Learning (AKS と Azure Arc 対応 Machine Learning を使用して任意の場所で機械学習を実現する) - 技術コミュニティ ブログ
• Machine learning on AKS hybrid and Stack HCI using Azure Arc-enabled machine learning (Azure Arc 対応 Machine Learning を使用した AKS ハイブリッドと Stack HCI での機械学習) - Tech Community ブログ
• Machine Learning での Kubernetes コンピューティング先の概要
• 仮想マシンを最新の状態に保つ
• Automation State Configuration を使用して仮想マシンの設定を保護する
• Backup を使用して VM を保護する