Azure Stack HCI での Azure Well-Architected Framework のパースペクティブ

(Azure Stack HCI のプラットフォーム アーキテクチャとワークロード アーキテクチャ) ワークロードの信頼性目標を定義します。

• 可用性目標を評価できるように、サービス レベル目標 (SLO) を設定します。 ワークロードのアップタイムを反映する 99.9%、99.95%、99.995% などの割合で SLO を計算します。 この計算は、Azure Stack HCI クラスターまたはワークロードが出力するプラットフォーム メトリックのみに基づくのではないことに注意してください。 包括的なターゲット測定値を取得するには、リリース中の予想されるダウンタイム、定常的な運用、サポート可能性、その他のワークロード固有や組織固有の要因などの、定量化される微妙な要因を考慮します。

• Microsoft が提供するサービス レベル アグリーメント (SLA) は、しばしば SLO の計算に影響します。 しかし、Microsoft は Azure Stack HCI クラスターや展開されたワークロードのアップタイムと接続に対する SLA を提供しません。お客様のデータセンターの信頼性 ("電源、冷却など") やプラットフォームを管理する人員とプロセスは、Microsoft が制御しないためです。

(Azure Stack HCI のプラットフォーム アーキテクチャ) パフォーマンスと運用が信頼性に与える影響を考慮します。

クラスターまたはその依存関係のパフォーマンスが低下すると、Azure Stack HCI プラットフォームを使用できなくなる可能性があります。 次に例を示します。

• 適切なワークロード容量計画がないと、設計フェーズで "Azure Stack HCI クラスターを適切にサイズ設定" することは困難です。これは、ワークロードが目的の信頼性目標を満たすことができるようにするための要件です。 クラスターの設計中に Azure Stack HCI サイズ設定ツールを使用します。 高可用性 VM が必要な場合は、"ノード数について N+1 という最小要件" を検討してください。 ビジネス クリティカルまたはミッション クリティカルなワークロードについては、回復性が最重要な場合、クラスター サイズに "N+ 2 個のノード" を使用することを検討してください。

• プラットフォームの信頼性は、物理ディスクの種類などの、重要なプラットフォームの依存関係のパフォーマンスによって異なります。 要件に適したディスクの種類を選択する必要があります。 低遅延で高スループットのストレージを必要とするワークロードについては、すべてフラッシュ ("NVMe/SSD のみ") のストレージ構成をお勧めします。 汎用コンピューティングについては、ハイブリッド ストレージ ("キャッシュ用に NVMe または SSD、容量用に HDD") 構成が、より多くのストレージ スペースを提供する場合があります。 しかし、ワークロードがキャッシュのワーキング セットを超えると、回転ディスクのパフォーマンスが大幅に低下することと、HDD の "平均故障間隔" が NVMe/SSD と比較して大幅に短いことがトレードオフになります。

  「パフォーマンス効率」で、これらの例について詳しく説明します。

不適切な Azure Stack HCI 運用は、展開のパッチ適用とアップグレード、テスト、一貫性に影響を与える可能性があります。 次に例をいくつか示します。

• Azure Stack HCI プラットフォームが "最新のハードウェア相手先ブランド供給 (OEM) のファームウェア、ドライバー、イノベーションに合わせて進化" しない場合、プラットフォームは最新の回復性機能を利用しない可能性があります。 ハードウェア OEM ドライバーとファームウェアの更新を定期的に適用してください。 詳細については、Azure Stack HCI ソリューション カタログを参照してください。

• 展開の前に、接続、ハードウェア、ID およびアクセス管理についてターゲット環境をテストする必要があります。 そうしないと、不安定な環境に Azure Stack HCI ソリューションを展開する場合があるため、信頼性の問題が発生する可能性があります。 スタンドアロン モードで環境チェッカー ツールを使用すると、クラスター ハードウェアが使用可能になる前でも問題を検出できます。

  運用ガイダンスについては、「オペレーショナル エクセレンス」を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) クラスターとそのインフラストラクチャの依存関係にフォールト トレランスを提供します。

• ストレージの設計の選択。 ほとんどの展開には、"ワークロードとインフラストラクチャ ボリュームを自動的に作成する" という既定のオプションで十分です。 "必要なインフラストラクチャ ボリュームのみを作成する" 高度なオプションを選択した場合、ワークロードの要件に基づいて "記憶域スペース ダイレクト内に適切なボリュームのフォールト トレランス" を構成します。 これらの決定は、ボリュームのパフォーマンス、容量、回復性の機能に影響します。 たとえば、3 方向ミラーを使用すると、3 個以上のノードを持つクラスターの信頼性とパフォーマンスが向上します。 詳細については、記憶域の効率のためのフォールト トレランスに関する記事および記憶域スペース ダイレクトの仮想ディスクとボリュームの作成に関する記事を参照してください。

• ネットワーク アーキテクチャ。 "検証済みネットワーク トポロジ" を使用して、Azure Stack HCI を展開します。 "4 個以上の物理ノードがある" マルチノード クラスターは、"ストレージ スイッチ" 設計を必要とします。 2 個または 3 個のノードがあるクラスターは、必要に応じて "ストレージ スイッチレス" 設計を使用できます。 クラスター のサイズに関係なく、管理とコンピューティングの目的 ("垂直方向のアップリンク") にデュアル Top-of-Rack (ToR) スイッチを使用して、フォールト トレランスを向上させることをお勧めします。 デュアル ToR トポロジは、スイッチ サービス ("ファームウェア更新") 操作中の回復性も提供します。 詳細については、「検証済みネットワーク トポロジ」を参照してください。

(ワークロード アーキテクチャ) 回復性を提供する冗長性を構築します。

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

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

  詳細については、複数の Azure Stack HCI クラスターにワークロード インスタンスを展開する方法に関する記事を参照してください。

(ワークロード アーキテクチャ) ワークロードの回復ポイントの目標 (RPO) と目標復旧時間 (RTO) という目標に基づいて、復旧可能性を計画およびテストします。

"適切に文書化されたディザスター リカバリー計画" を策定します。 復旧手順を定期的にテストして、ビジネス継続性の計画とプロセスが有効であることを確認します。 Azure Site Recovery が、Azure Stack HCI 上で実行される VM を保護するための実行可能な選択肢であるかどうかを判定します。 詳細については、「Azure Stack HCI で Azure Site Recovery を使用して VM ワークロードを保護する (プレビュー)」を参照してください。

(ワークロード アーキテクチャ) ワークロードのバックアップと復元の手順を構成して定期的にテストします。

"データの復旧と保持" に対するビジネス要件が、ワークロード バックアップの戦略を推進します。 包括的な戦略には、個々の ("特定の時点の") ファイル レベルおよびフォルダー レベルのデータを復元する機能を含む、"ワークロードのオペレーティング システム (OS) とアプリケーションの永続的なデータ" に関する考慮事項が含まれています。 データ復旧とコンプライアンスの要件に基づいてバックアップ保持ポリシーを構成します。これが、使用可能なデータ復旧ポイントの数と有効期間を決定します。 Azure Stack HCI のホスト レベルまたは VM ゲスト レベルのバックアップを有効にする選択肢として、Azure Backup を検討します。 必要に応じて、バックアップに関する独立系ソフトウェア ベンダー パートナーのデータ保護ソリューションを調べます。 詳細については、Azure Backup のガイダンスとベスト プラクティス、および Azure Stack HCI 用 Azure Backup に関するページを参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) セキュリティ ベースラインを確認します。 Azure Stack HCI とセキュリティ標準は、プラットフォームとホストされているワークロードのセキュリティ態勢を強化するためのベースライン ガイダンスを提供します。 ワークロードが特定の規制コンプライアンス法規に準拠する必要がある場合は、Payment Card Industry Data Security Standards や Federal Information Processing Standard 140 などの規制セキュリティ標準を考慮してください。

Azure Stack HCI プラットフォームで提供される既定の設定は、ID 制御、ネットワーク フィルタリング、暗号化などのセキュリティ機能を有効にします。 これらの設定は、新しくプロビジョニングされる Azure Stack HCI クラスターに対して適切なセキュリティ ベースラインを形成します。 組織のセキュリティ要件に基づいて、各設定をカスタマイズできます。

望ましくないセキュリティ構成のドリフトを検出して保護するようにしてください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 脅威の検出、防止、および対応を行います。 Azure Stack HCI 環境を継続的に監視し、既存の脅威と新しく発生する脅威から保護します。

Azure Stack HCI で、Defender for Cloud を有効にすることをお勧めします。 Defender のクラウド セキュリティ態勢管理を使用して基本的な Defender for Cloud プラン ("Free レベル") を有効にすることで、Azure Stack HCI プラットフォームと他の Azure および Azure Arc リソースをセキュリティで保護するために実行できる手順を監視および特定します。

個々のサーバーと Azure Arc VM に対するセキュリティ アラートなどの強化されたセキュリティ機能を利用するために、Azure Stack HCI クラスター ノードと Azure Arc VM で Microsoft Defender for Servers を有効にします。

• Defender for Cloud を使用して、Azure Stack HCI ノードとワークロードのセキュリティ態勢を測定します。 Defender for Cloud には、セキュリティ コンプライアンスの管理に役立つ一元的なエクスペリエンスが用意されています。

• Defender for Servers を使用して、ホストされている VM の脅威と構成の誤りを監視します。 Azure Stack HCI ノードでエンドポイントでの検出と対応の機能を有効にすることもできます。

• すべてのソースのセキュリティと脅威インテリジェンスのデータを、Microsoft Sentinel などの集中的なセキュリティ情報およびイベント管理 (SIEM) ソリューションに集約することを検討してください。

(Azure Stack HCI のプラットフォーム アーキテクチャとワークロード アーキテクチャ) 影響半径を含むセグメント化を作成します。 セグメント化を達成するには、いくつかの戦略があります。

• ID。 プラットフォームとワークロードのロールと責任を分離します。 指定されたロールと一致する特定の操作の実行は、承認された ID のみに許可します。 Azure Stack HCI プラットフォーム管理者は、プラットフォーム業務を行うために、Azure とローカル ドメインの両方の資格情報を使用します。 ワークロード オペレーターとアプリケーション開発者は、ワークロードのセキュリティを管理します。 アクセス許可の委任を簡略化するには、Azure Stack HCI の組み込みロールベースのアクセス制御 (RBAC) ロール (プラットフォーム管理者には "Azure Stack HCI 管理者"、ワークロード オペレーターには "Azure Stack HCI VM 共同作成者" や "Azure Stack HCI VM 閲覧者" など) を使用します。 特定の組み込みロール "アクション" の詳細については、ハイブリッド ロールとマルチクラウド ロールに関する Azure RBAC のドキュメントを参照してください。

• ネットワーク: 必要に応じてネットワークを分離します。 たとえば、別個の仮想ローカル エリア ネットワーク (vLAN) とネットワーク アドレス範囲を使用する複数の論理ネットワークをプロビジョニングできます。 この方法を使用するときは、Azure Stack HCI クラスター ノードが ToR スイッチまたはゲートウェイ経由で vLAN ネットワークと通信できるように、管理ネットワークが各論理ネットワークと vLAN に到達できることを確認してください。 この構成は、インフラストラクチャ管理エージェントがワークロードのゲスト OS と通信できるようにするなどの、ワークロードの可用性管理に必要です。

• 追加情報については、「セグメント化戦略を構築するための推奨事項」を確認してください。

(Azure Stack HCI のプラットフォーム アーキテクチャとワークロード アーキテクチャ) 信頼された ID プロバイダーを使用してアクセスを制御します。 すべての認証と認可の目的に、Microsoft Entra ID をお勧めします。 必要に応じて、ワークロードをオンプレミスの Windows Server Active Directory ドメインに参加させることができます。 強力なパスワード、多要素認証、RBAC、およびシークレットの管理のための制御をサポートする機能を利用します。

(Azure Stack HCI のプラットフォーム アーキテクチャとワークロード アーキテクチャ) ネットワーク トラフィックの分離、フィルター処理、ブロックを行います。フィルター処理のためにパートナー アプライアンスを取り込むことができるように、仮想ネットワーク、ネットワーク セキュリティ グループによるマイクロセグメント化、サービス ポリシーのネットワーク品質、または仮想アプライアンス チェーンを必要とするワークロードのユース ケースが存在する場合があります。 このようなワークロードがある場合は、ネットワーク コントローラーが提供する、サポートされている機能の一覧についてネットワーク参照パターンのソフトウェア定義ネットワークに関する考慮事項を参照してください。

(ワークロード アーキテクチャ) 改ざんから保護するためにデータを暗号化します。 転送中のデータ、保存データ、使用中のデータを暗号化します。

• 保存データの暗号化は、展開中に作成するデータ ボリュームで有効になります。 これらのデータ ボリュームには、インフラストラクチャ ボリュームとワークロード ボリュームの両方が含まれます。 詳細については、「BitLocker 暗号化の管理」を参照してください。

• Azure Arc VM のトラステッド起動を使用し、仮想トラステッド プラットフォーム モジュールを使用できるセキュア ブートなどの、最新のオペレーティング システムの OS 機能を使用して、Gen 2 VM のセキュリティを向上させます。

シークレット管理を運用化します。 組織の要件に基づいて、Azure Stack HCI の展開ユーザー ID に関連付けられている資格情報を変更します。 詳細については、「シークレットのローテーションを管理する」を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) セキュリティ制御を適用します。 Azure Policy を使用して、"アプリケーション制御ポリシーを一貫して適用する必要がある" や "暗号化されたボリュームを実装する必要がある" などの組み込みポリシーを監査および適用します。 これらの Azure ポリシーを使用して、セキュリティの設定を監査し、Azure Stack HCI のコンプライアンス状態を評価できます。 使用可能なポリシーの例については、「Azure ポリシー」を参照してください。

(ワークロード アーキテクチャ) 組み込みポリシーを使用してワークロードのセキュリティ態勢を向上させます。 Azure Stack HCI で実行される Azure Arc VM を評価するために、セキュリティ ベンチマーク、Azure Update Manager、または Azure Policy のゲスト構成拡張機能を使用して組み込みポリシーを適用できます。 さまざまなポリシーを使用して、次の状態を確認できます。

• Log Analytics エージェントのインストール
• 最新のセキュリティ パッチを使用して最新にする必要がある古いシステム更新
• 脆弱性評価と潜在的な軽減策
• セキュリティで保護された通信プロトコルの使用

(Azure Stack HCI のプラットフォーム アーキテクチャとワークロード アーキテクチャ) コスト モデリングの一環として現実的なコストを見積もります。 Azure 料金計算ツールを使用して、Azure Stack HCI、Azure Arc、AKS on Azure Stack HCI などのサービスを選択して構成します。 さまざまな構成と支払いオプションを試して、コストをモデル化します。

(Azure Stack HCI のプラットフォーム アーキテクチャとワークロード アーキテクチャ) Azure Stack HCI ハードウェアのコストを最適化します。 ビジネス要件と商用要件に合ったハードウェア OEM パートナーを選択します。 検証済みノード、統合システム、およびプレミア ソリューションの認定一覧については、Azure Stack HCI ソリューション カタログを参照してください。 ワークロードの特性、サイズ、数量、パフォーマンスをハードウェア パートナーと相談して、Azure Stack HCI ノードとクラスター サイズに対してコスト効率の高いハードウェア ソリューションを適切にサイズ設定できるようにします。

(Azure Stack HCI のプラットフォーム アーキテクチャ) ライセンス コストを最適化します。 Azure Stack HCI ソフトウェアは、"物理 CPU コア単位" でライセンスおよび課金されます。 Azure ハイブリッド特典で既存のオンプレミス コア ライセンスを使用して、Windows Server、SQL Server、または AKS と Azure Arc 対応の Azure SQL Managed Instance を実行する Azure Arc VM などの Azure Stack HCI ワークロードのライセンス コストを削減します。 詳細については、「Azure Hybrid Benefit 節約額計算ツール」を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 環境コストを節約します。 次のオプションがリソース配分状況の最適化に役立つかどうかを評価します。

• Microsoft が提供する割引プログラムを利用します。 Azure ハイブリッド特典を使用して、Azure Stack HCI および Windows Server ワークロードを実行するためのコストを削減することを検討してください。 詳細については、「Azure Stack HCI の Azure ハイブリッド特典」を参照してください。

• キャンペーン プランを調べます。 最初の概念実証つまり検証の登録後の Azure Stack HCI の 60 日間の無料試用版を利用してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 運用コストを節約します。

• パッチ適用、更新、およびその他の操作の技術オプションを評価します。 Update Manager は、Azure ハイブリッド特典と Azure Arc VM 管理が有効になっている Azure Stack HCI クラスターでは無料です。 詳細については、Update Manager の FAQ と Update Manager の価格を参照してください。

• 監視に関連するコストを評価します。 監視と監査のニーズを満たすように、アラート ルールとデータ収集ルール (DCR) を設定します。 ワークロードが取り込み、処理、保持するデータの量は、コストに直接影響します。 スマート保持ポリシーを使用して最適化し、アラートの数と頻度を制限し、ログを保存するための適切なストレージ層を選択します。 詳細については、Log Analytics のコストの最適化ガイダンスを参照してください。

(ワークロード アーキテクチャ) 分離の密度を評価します。 AKS on Azure Stack HCI を使用して、密度を向上させ、ワークロード管理を簡素化して、コンテナー化されたアプリケーションを複数のデータセンターまたはエッジの場所にまたがってスケーリングできるようにします。 詳細については、AKS on Azure Stack HCI の価格を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) Azure Stack HCI のサポート性を向上させます。 監視は、展開時に既定で有効になります。 これらの機能により、プラットフォームのサポート性が強化されます。 テレメトリと診断情報は、すべての Azure Stack HCI クラスター ノードに既定でインストールされる AzureEdgeTelemetryAndDiagnostics 拡張機能を使用して、プラットフォームから安全に共有されます。 詳細については、「Azure Stack HCI の監視」を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) Azure サービスを使用して運用の複雑さを軽減し、管理スケールを増やします。 Azure Stack HCI は Azure と統合されていて、プラットフォームにパッチを適用する Update Manager などのサービスや、監視とアラートのための Azure Monitor を有効にします。 Azure Arc と Azure Policy を使用して、セキュリティ構成とコンプライアンス監査を管理できます。 Defender for Cloud を実装して、サイバーの脅威と脆弱性の管理に役立てます。 これらの運用プロセスと手順のコントロール プレーンとして Azure を使用して、複雑さを軽減し、スケーリングの効率を向上させ、管理の一貫性を向上させます。

(ワークロード アーキテクチャ) ワークロードの IP アドレス ネットワーク範囲の要件を事前に計画します。 Azure Stack HCI には、仮想化またはコンテナー化されたワークロードを展開および管理するためのプラットフォームが用意されています。 ワークロードが使用する論理ネットワークの IP アドレス要件も考慮してください。 次のリソースを確認します。

• Azure Stack HCI ("プラットフォーム") のネットワーク参照アーキテクチャと IP 要件

• Azure Stack HCI に展開されたワークロードには、論理ネットワークが必要です。 具体的な例については、AKS クラスターのネットワーク要件に関する記事、Azure Arc VM の論理ネットワークに関する記事、および Azure Stack HCI を使用した Virtual Desktop に関する記事を参照してください。

(ワークロード構成) Azure Stack HCI に展開するワークロードの監視とアラートを有効にします。 仮想マシン用 Azure Monitor、Arc VM 用 VM Insights、または Container Insights とマネージド Prometheus AKS クラスターを使用できます。

ワークロードに対して一元化された Log Analytics ワークスペースを使用する必要があるかどうかを評価します。 共有ログ シンク ("データの場所") の例については、「ワークロードの管理と監視に関する推奨事項」を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 安全な展開のために適切な検証手法を使用します。 Azure Stack HCI ソリューションを展開する前に、スタンドアロン モードの環境チェッカー ツールを使用してターゲット環境の準備状況を評価します。 このツールは、必要な接続、ハードウェア、Windows Server Active Directory、ネットワーク、Azure Arc 統合という前提条件の適切な構成を検証します。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 最新情報を取得して、最新に維持します。 Azure Stack HCI ソリューション カタログを使用して、最新のハードウェア OEM イノベーションに適合する Azure Stack HCI クラスター展開を維持します。 追加の統合、ターンキー展開機能、シンプルな更新エクスペリエンスを活用するために、プレミアム ソリューションを使用することを検討してください。

Update Manager を使用してプラットフォームを更新し、OS、コア エージェント、ソリューション拡張機能を含むサービスを管理します。 最新の状態を維持し、可能な場合は拡張機能に対して [自動アップグレードを有効にする] 設定を使用することを検討してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) Azure Stack HCI 検証済みハードウェアを使用するか、OEM パートナー オファリングの統合システムを使用します。 Azure Stack HCI カタログのプレミアム ソリューション ビルダーを使用して、Azure Stack HCI 環境のパフォーマンスを最適化することを検討してください。

(Azure Stack HCI のプラットフォーム ストレージ アーキテクチャ) ワークロードのパフォーマンスと容量の要件に基づいて、適切な Azure Stack HCI クラスター ノードの物理ディスクの種類を選択します。 低遅延で高スループットのストレージを必要とする高パフォーマンスなワークロードについては、オールフラッシュ (NVMe/SSD のみ) のストレージ構成の使用を検討してください。 汎用コンピューティングまたは大規模なストレージ容量の要件については、提供するストレージ容量を増やす可能性があるハイブリッド ストレージ (キャッシュ レベルには SSD または NVMe、容量レベルには HDD) の使用を検討してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) クラスターの設計 ("展開前") フェーズ中に Azure Stack HCI サイズ設定ツールを使用します。 Azure Stack HCI クラスターは、ワークロードの容量、パフォーマンス、回復性の要件を入力として使用して、適切なサイズに設定する必要があります。 このサイズにより、計画された ("メンテナンス") イベントや計画外 ("電源障害やハードウェア障害") イベントなどで、同時にオフラインにできる物理ノードの最大数 ("クラスター クォーラム") が決まります。 詳細については、「クラスター クォーラムの概要」を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 高パフォーマンスまたは低遅延の要件があるワークロードには、オールフラッシュ (NVMe または SSD) ベースのソリューションを使用します。 これらのワークロードには、高度なトランザクション データベース テクノロジ、運用 AKS クラスター、低遅延または高スループットのストレージ要件があるミッション クリティカルまたはビジネス クリティカルなワークロードが含まれますが、これらに限定されません。 オールフラッシュの展開は、ストレージのパフォーマンスを最大化するために使用します。 NVMe のみ、または SSD のみの構成 ("特に非常に小さな規模で") は、キャッシュ レベルとして使用されるドライブがないため、ストレージ効率を向上させ、パフォーマンスを最大化します。 詳細については、オールフラッシュベースのストレージに関する記事を参照してください。

(Azure Stack HCI のプラットフォーム アーキテクチャ) 運用環境のワークロードを展開する前に、Azure Stack HCI クラスター ストレージのパフォーマンス ベースラインを確立します。 1 つの Azure Stack HCI クラスターまたは複数のクラスターのパフォーマンスを同時に監視するように、Insights を使用した Azure Stack HCI 機能の監視を構成します。

(Azure Stack HCI のプラットフォーム アーキテクチャ) Azure Stack HCI クラスターに対して Insights を有効にしたら、Resilient File System (ReFS) の重複除去と圧縮の機能に対する監視の使用を検討してください。 ワークロード ストレージの使用量と容量の要件に基づいて、この機能を使用する必要があるかどうかを判断します。 この機能は、ReFS の重複除去と圧縮の節約、パフォーマンスへの影響、ジョブに対する監視を提供します。 詳細については、「ReFS 重複除去と圧縮を監視する」を参照してください。

最小要件として、クラスターノードが Update Management を使用して更新を実行するときにクラスター ノードを確実にドレインできるように、クラスター全体で 1 x physical nodes (N+1) 相当の容量を予約することを計画します。 ビジネス クリティカルまたはミッション クリティカルなユース ケースのために、2 physical nodes (N+2) ノード相当の容量を予約することを検討してください。