Azure ローカル ベースライン参照アーキテクチャ

このベースライン参照アーキテクチャでは、Azure Local バージョン 23H2、リリース 2311 以降のインフラストラクチャを構成して、高可用性の仮想化およびコンテナー化されたワークロードをデプロイおよび管理できる信頼性の高いプラットフォームを確保するための、ワークロードに依存しないガイダンスと推奨事項を提供します。 このアーキテクチャでは、ローカル コンピューティング、ストレージ、ネットワーク機能を提供する物理ノードのリソース コンポーネントとクラスター設計の選択肢について説明します。 また、Azure サービスを使用して、Azure Local の日常的な管理を簡素化および合理化する方法についても説明します。

Azure Local で実行するように最適化されたワークロード アーキテクチャ パターンの詳細については、Azure Local ワークロード ナビゲーション メニューにあるコンテンツを参照してください。

このアーキテクチャは、ストレージ切り替えネットワーク設計を使用してマルチノード Azure ローカル インスタンスをデプロイする方法の開始点です。 Azure ローカル インスタンスにデプロイされるワークロード アプリケーションは、適切に設計する必要があります。 適切に設計されたワークロード アプリケーションは、複数のインスタンスまたは重要なワークロード サービスの高可用性を使用してデプロイし、適切なビジネス継続性とディザスター リカバリー (BCDR) コントロールを設定する必要があります。 これらの BCDR コントロールには、通常のバックアップとディザスター リカバリーフェールオーバー機能が含まれます。 HCI インフラストラクチャ プラットフォームに重点を置くために、これらのワークロード設計の側面は、この記事から意図的に除外されています。

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

記事のレイアウト

建築

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

潜在的なユース ケース

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

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

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

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

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

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

シナリオの詳細

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

Azure Local で Azure Arc を使用する

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

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

Azure と Azure Arc の統合により、Azure ローカル仮想化ワークロードとコンテナー化ワークロードの機能が拡張され、次のものが含まれます。

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

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

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

• azure Arc 対応データ サービス 、コンテナー化された Azure SQL Managed Instance または Azure ローカルでホストされている Azure Arc 対応 AKS を使用する Azure Database for PostgreSQL サーバーに対して されます。

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

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

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

Azure ローカルの既定のセキュリティ構成を利用する

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

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

Defender for Cloud で Azure ローカル VM をオンボードして、クラウドベースの行動分析、脅威の検出と修復、アラート、レポートをアクティブ化できます。 Azure Policy 使用して、業界の規制や企業標準への準拠を評価できるように、Azure Arc で Azure ローカル VM を管理します。

コンポーネント

このアーキテクチャは、オンプレミスまたはエッジの場所に Azure Local インスタンスをデプロイするために使用できる物理サーバー ハードウェアで構成されています。 プラットフォーム機能を強化するために、Azure Local は、サポート リソースを提供する Azure Arc やその他の Azure サービスと統合されます。 Azure Local には、ユーザー アプリケーションまたはビジネス システムをデプロイ、管理、運用するための回復性のあるプラットフォームが用意されています。 プラットフォームのリソースとサービスについては、次のセクションで説明します。

プラットフォーム リソース

このアーキテクチャには、次の必須のリソースとコンポーネントが必要です。

• Azure Local は、物理サーバーハードウェアとネットワーク インフラストラクチャを使用してオンプレミスまたはエッジの場所にデプロイされるハイパーコンバージド インフラストラクチャ (HCI) ソリューションです。 Azure Local には、VM、Kubernetes クラスター、Azure Arc で有効になっているその他のサービスなどの仮想化されたワークロードをデプロイおよび管理するためのプラットフォームが用意されています。Azure Local インスタンスは、オリジナルの機器メーカー (OEM) パートナーによって提供される検証済み、統合済み、または Premium のハードウェア カテゴリを使用して、単一ノードのデプロイから最大 16 個のノードにスケーリングできます。

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

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

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

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

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

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

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

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

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

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

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

クラスターの設計の選択

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

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

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

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

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

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

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

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

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

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

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

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

サイズ設定ツール 基本設定 セクションでは、システムの種類 (Premier、Integrated System、または Validated Node) と CPU ファミリ のオプションに関連する質問について説明します。 また、クラスターの回復性要件を選択するのにも役立ちます。 次のことを確認します。

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

• 追加の回復性を確保するために、クラスター全体で N + 2 ノード分の容量を予約します。 このオプションを使用すると、2 つのノードに同時に影響を与える更新またはその他の予期しないイベント中のノード障害にシステムが耐えられます。 また、残りのオンライン ノードでワークロードを実行するのに十分な容量がクラスター内にあることを確認します。

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

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

物理ディスク ドライブ

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

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

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

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

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

ネットワーク設計

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

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

このアーキテクチャでは、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 ローカル デプロイを設計する場合は、次のコンポーネントが必要です。

• デュアル ToR スイッチ:

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

  • デュアル ToR スイッチは、ストレージ(東西)のトラフィックに使用されます。 これらのスイッチは、特定の記憶域仮想ローカル エリア ネットワーク (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 ローカル インスタンスまたは南北トラフィックとの間で送受信されるトラフィックをルーティングします。

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

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

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

Azure Local のこのマルチノード ストレージ切り替えベースライン アーキテクチャの論理セットアップの概要は次のとおりです。

• デュアル ToR スイッチ:

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

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

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

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

• 外信：

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

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

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

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

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

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

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

  • Azure Stack HCI OS 内の 2 つのストレージインテント ネットワーク アダプター ポートに既定のゲートウェイ が構成 はありません。

  • 各ノードは、記憶域プール、仮想ディスク、ボリュームで使用されるリモート物理ディスクなど、クラスターの記憶域スペース ダイレクト機能にアクセスできます。 これらの機能へのアクセスは、各ノードで使用可能な 2 つの専用ストレージ ネットワーク アダプター ポートを介して、SMB-Direct RDMA プロトコルを介して容易になります。 SMB マルチチャネルは回復性のために使用されます。

  • この構成では、ミラー化されたボリュームのデータの一貫性のあるコピーを維持するなど、ストレージ関連の操作に十分なデータ転送速度が提供されます。

ネットワーク スイッチの要件

イーサネット スイッチは、Azure Local に必要なさまざまな仕様を満たし、電気電子技術者標準協会 (IEEE SA) によって設定されている必要があります。 たとえば、マルチノード ストレージスイッチドデプロイの場合、ストレージ ネットワークは RoCE v2 または iWARP経由で RDMA を するために使用されます。 このプロセスでは、IEEE 802.1Qbb のPFC を使用して、ストレージ トラフィック クラスの無損失通信を確保する必要があります。 ToR スイッチでは、VLAN の IEEE 802.1Q とリンク層探索プロトコルの IEEE 802.1AB のサポートを提供する必要があります。

Azure ローカル デプロイに既存のネットワーク スイッチを使用する予定の場合は、ネットワーク スイッチと構成で提供する必要がある必須の IEEE 標準と仕様 一覧を確認してください。 新しいネットワーク スイッチを購入する場合は、Azure ローカル ネットワーク要件をサポートするハードウェア ベンダー認定スイッチ モデルの 一覧を確認します。

IP アドレスの要件

マルチノード・ストレージ・スイッチド・デプロイメントでは、1 つのクラスター内で最大 16 ノードまで、各物理ノードを追加すると、必要な IP アドレスの数が増えます。 たとえば、Azure Local の 2 ノード ストレージ切り替え構成をデプロイするには、クラスター インフラストラクチャに少なくとも 11 個の IP アドレスを割り当てる必要があります。 マイクロセグメント化またはソフトウェア定義ネットワークを使用する場合は、さらに多くの IP アドレスが必要です。 詳細については、「Azure Localの 2 ノード ストレージ参照パターンの IP アドレス要件を確認する」を参照してください。

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

モニタリング

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

Azure Local の分析情報は、Monitor と Log Analytics を使用して構築され、常に up-to-date で高度にカスタマイズ可能なスケーラブルなソリューションが保証されます。 Insights では、基本的なメトリックを使用して既定のブックにアクセスできます。また、Azure Local の主な機能を監視するために作成された特殊なブックも提供されます。 これらのコンポーネントは、ほぼリアルタイムの監視ソリューションを提供し、グラフの作成、集計とフィルター処理による視覚化のカスタマイズ、カスタム リソース正常性アラート ルールの構成を可能にします。

更新プログラムの管理

Azure ローカル インスタンスとデプロイされたワークロード リソース (Azure Arc VM など) は、定期的に更新して修正プログラムを適用する必要があります。 更新プログラムを定期的に適用することで、組織が強力なセキュリティ体制を維持し、資産の全体的な信頼性とサポート可能性を向上させることができます。 セキュリティ パッチと OS 更新プログラムの早期検出と適用には、自動および定期的な手動評価を使用することをお勧めします。

インフラストラクチャの更新

Azure Local は、カスタマー エクスペリエンスを向上させ、新しい機能を追加するために継続的に更新されます。 このプロセスは、新しいベースライン ビルドを四半期ごとに提供するリリース トレーニングを通じて管理されます。 ベースライン ビルドは、最新の状態を維持するために Azure Local インスタンスに適用されます。 定期的なベースライン ビルドの更新に加えて、Azure Local は毎月の OS セキュリティと信頼性の更新プログラムで更新されます。

Update Manager は、Azure Local の更新プログラムの適用、表示、管理に使用できる Azure サービスです。 このサービスでは、Azure portal を使用してインフラストラクチャとエッジの場所全体のすべてのAzure Local インスタンスを表示し、一元管理エクスペリエンスを提供するメカニズムを提供します。 詳細については、次のリソースを参照してください。

• Azure ローカル リリース情報について

• Azure Local lifecycle cadence

• Azure Local の更新フェーズを確認する

• Azure Update Manager を使用して Azure Local を更新する

3 か月から 6 か月ごとなど、新しいドライバーとファームウェアの更新プログラムを定期的に確認することが重要です。 Azure ローカル ハードウェアに Premier ソリューション カテゴリ バージョンを使用する場合、ソリューション ビルダー拡張機能パッケージの更新プログラム は Update Manager と統合され、簡略化された更新エクスペリエンスが提供されます。 検証済みノードまたは統合システム カテゴリを使用する場合は、ハードウェアのファームウェアとドライバーの更新プログラムを含む OEM 固有の更新プログラム パッケージをダウンロードして実行する必要がある場合があります。 ハードウェアの更新プログラムの提供方法を確認するには、ハードウェア OEM または SI パートナーにお問い合わせください。

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

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

考慮 事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Frameworkの に関するページを参照してください。

確実

信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。 詳細については、「信頼性の柱の概要」を参照してください。

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

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

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

信頼性のターゲット

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

• 99.8% アップタイム (可用性) の SLO を使用すると、Azure Local で実行される Azure Arc VM を使用してデプロイされたアプリケーションに対して、次のダウンタイム (使用不能) が許容されます。

  • 週単位: 20 分 10 秒

  • 月単位: 1 時間 26 分 56 秒

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

  • 年単位: 17 時間、23 分、16 秒

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

  詳細については、「ID とアクセス管理のに関する 推奨事項」を参照してください。

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

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

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

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

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

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

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

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

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

  詳細については、「信頼性ターゲットを定義するための 推奨事項」を参照してください。

冗長性

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

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

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

安全

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

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

• Azure Local プラットフォームのセキュリティで保護された基盤: Azure Local は、TPM、UEFI、Secure Boot を使用して検証済みのハードウェア コンポーネントを使用して、Azure Local プラットフォームとワークロード セキュリティのセキュリティのためのセキュリティで保護された基盤を構築する、セキュリティで保護された既定の製品です。 既定のセキュリティ設定でデプロイすると、Azure Local では Windows Defender アプリケーション制御、Credential Guard、BitLocker が有効になります。 PoLP を使用してアクセス許可の委任を簡略化するには、Azure Local 組み込みのロールベースのアクセス制御 (RBAC) ロール (プラットフォーム管理者の場合は Azure ローカル管理者、ワークロードオペレーターの場合は Azure ローカル VM 共同作成者、Azure ローカル VM 閲覧者など) を使用します。

• 既定のセキュリティ設定: Azure ローカル セキュリティの既定の では、デプロイ時に Azure ローカル インスタンスの既定のセキュリティ設定が適用され、により、ノードを既知の良好な状態に保つためにドリフト制御 が有効になります。 セキュリティの既定の設定を使用して、クラスターのセキュリティ、ドリフト制御、セキュリティで保護されたコア サーバーの設定を管理できます。

• セキュリティ イベント ログ: Azure Local syslog 転送 は、関連するセキュリティ イベント ログを取得して、独自の SIEM プラットフォームで保持するためのイベントを集計して格納することで、セキュリティ監視ソリューションと統合されます。

• 脅威や脆弱性からの保護: Defender for Cloud は、Azure Local インスタンスをさまざまな脅威や脆弱性から保護します。 このサービスは、Azure ローカル環境のセキュリティ体制を向上させ、既存の脅威や進化する脅威から保護するのに役立ちます。

• 脅威の検出と修復の: Microsoft Advanced Threat Analytics は、Azure ローカル インスタンス ノードとその Windows Server VM ワークロードに認証サービスを提供する、AD DS を対象とする脅威を検出して修復します。

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

  詳細については、「セグメント化戦略を構築するための 推奨事項」を参照してください。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の柱の概要」を参照してください。

コストの最適化に関する考慮事項は次のとおりです。

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

• Azure Arc VMの VM ゲストの自動修正: この機能は、手動修正プログラムのオーバーヘッドと関連するメンテナンス コストを削減するのに役立ちます。 このアクションは、システムの安全性を高めるだけでなく、リソースの割り当てを最適化し、全体的なコスト効率にも貢献します。

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

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

• 初期ワークロード容量と増加: Azure ローカル デプロイを計画するときは、初期ワークロードの容量、回復性の要件、将来の成長に関する考慮事項を検討してください。 2 ノードまたは 3 ノードのストレージ スイッチレス アーキテクチャを使用すると、ストレージ クラスのネットワーク スイッチを調達する必要がなくなるなど、コストを削減できるかどうかを検討してください。 追加のストレージ クラス ネットワーク スイッチを調達することは、新しい Azure ローカル インスタンスデプロイの高価なコンポーネントになる可能性があります。 代わりに、既存のスイッチを管理ネットワークとコンピューティング ネットワークに使用できるため、インフラストラクチャが簡素化されます。 ワークロードの容量と回復性が 3 ノード構成を超えてスケーリングされない場合は、管理ネットワークとコンピューティング ネットワークに既存のスイッチを使用できるかどうかを検討し、3 ノード ストレージスイッチレス アーキテクチャ を使用して Azure Local をデプロイします。

  詳細については、「コンポーネントコストを最適化するための 推奨事項」を参照してください。

オペレーショナル エクセレンス

オペレーショナル エクセレンスには、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスが含まれます。 詳細については、「オペレーショナル エクセレンスの柱の概要」を参照してください。

オペレーショナル エクセレンスに関する考慮事項は次のとおりです。

• Azureと統合された簡略化されたプロビジョニングと管理エクスペリエンス: Azure の クラウドベースのデプロイには、Azure ローカル インスタンスを作成する方法を示すウィザード駆動型インターフェイスが用意されています。 同様に、Azure では、Azure Arc VMを および する Azure ローカル インスタンスを 管理するプロセスが簡略化されます。 ARM テンプレートを使用して、Azure ローカル インスタンス ポータル ベースのデプロイを自動化できます。 このテンプレートは、Azure Local を大規模にデプロイするための一貫性と自動化を提供します。特に、ビジネスクリティカルなワークロードを実行するために Azure Local インスタンスを必要とする小売店や製造サイトなどのエッジ シナリオで提供されます。

• Virtual Machinesの Automation 機能: Azure Local には、Azure Arc VM などのワークロードを管理するためのさまざまな自動化機能が用意されています。Azure CLI、ARM、Bicep テンプレートを使用した Azure Arc VM の自動デプロイ 、Azure Arc Extension for Updates を使用した仮想マシン OS の更新、および Azure Update Manager を使用して Azure Update Manager を更新します。 Azure Local では、Azure CLI を使用して Azure Arc VM 管理 を したり、Windows PowerShell を使用して Azure Arc 以外の VM を したりすることもできます。 Azure CLI コマンドは、いずれかの Azure ローカル コンピューターからローカルに実行することも、管理コンピューターからリモートで実行することもできます。 Azure Automation および Azure Arc との統合により、Azure Arc 拡張機能を介して VM ワークロードに対するさまざまな追加の自動化シナリオが容易になります。

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

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

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

パフォーマンス効率

パフォーマンス効率は、ユーザーの要求に効率的に対応するためにワークロードをスケーリングする機能です。 詳細については、「パフォーマンス効率の柱の概要を参照してください。

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

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

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

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

• ワークロード ストレージの回復性: ストレージの回復性、使用量 (または容量) の効率、パフォーマンス 利点を考慮してください。 Azure ローカル ボリュームの計画には、回復性、使用効率、パフォーマンスの最適なバランスの特定が含まれます。 これらの特性の 1 つを最大化すると、通常、他の 1 つ以上の特性に悪影響を及ぼすため、このバランスを最適化することは困難な場合があります。 回復性を高めることで、使用可能な容量が減少します。 その結果、選択した回復性の種類によってパフォーマンスが異なる場合があります。 回復性とパフォーマンスが優先され、3 つ以上のノードを使用する場合、既定のストレージ構成では、インフラストラクチャとユーザー ボリュームの両方に 3 方向ミラーリングが採用されます。

  詳細については、「容量計画の 推奨事項」を参照してください。

• ネットワーク パフォーマンスの最適化: ネットワーク パフォーマンスの最適化を検討します。 設計の一環として、最適なネットワーク ハードウェア構成を決定するときに、予想される ネットワーク トラフィック帯域幅の割り当て 含めるようにしてください。

  • Azure Local でコンピューティング パフォーマンスを最適化するには、GPU アクセラレーションを使用できます。 GPU アクセラレーションは、データ分析情報や推論 含む高パフォーマンスの AI または機械学習ワークロード に役立ちます。 これらのワークロードでは、データの重力やセキュリティ要件などの考慮事項により、エッジの場所にデプロイする必要があります。 ハイブリッドデプロイまたはオンプレミスのデプロイでは、GPU を含むワークロードのパフォーマンス要件を考慮することが重要です。 このアプローチは、Azure ローカル インスタンスを設計および調達するときに適切なサービスを選択するのに役立ちます。

    詳細については、「適切なサービスを選択するための 推奨事項」を参照してください。

このシナリオをデプロイする

次のセクションでは、前提条件のタスクや考慮事項など、Azure Local のデプロイに使用される高度なタスクまたは一般的なワークフローの一覧の例を示します。 このワークフロー リストは、ガイドの例のみを目的としています。 これは、組織、地理的、またはプロジェクト固有の要件に応じて異なる可能性がある、すべての必要なアクションの完全な一覧ではありません。

シナリオ: オンプレミスまたはエッジの場所にハイブリッド クラウド ソリューションをデプロイするプロジェクトまたはユース ケースの要件、データ処理機能のローカル コンピューティングを提供し、Azure 整合性の管理と課金エクスペリエンスを使用する必要があります。 詳細については、この記事の 潜在的なユース ケース セクションで説明します。 残りの手順では、Azure Local がプロジェクトに対して選択されたインフラストラクチャ プラットフォーム ソリューションであることを前提としています。

1. 関連する利害関係者からワークロードとユース ケースの要件を収集します。 この戦略により、プロジェクトは Azure Local の機能がワークロードのスケール、パフォーマンス、および機能の要件を満たしていることを確認できます。 このレビュー プロセスには、ワークロードのスケールまたはサイズ、および Azure Arc VM、AKS、Azure Virtual Desktop、Azure Arc 対応 Data Services、Azure Arc 対応 Machine Learning Service などの必要な機能を理解する必要があります。 ワークロード RTO と RPO (信頼性) の値とその他の非機能要件 (パフォーマンス/負荷のスケーラビリティ) は、この要件収集手順の一部として文書化する必要があります。

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

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

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

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

6. ネットワーク統合用に 2 つの ToR スイッチを展開します。 高可用性ソリューションの場合、HCI クラスターには 2 つの ToR スイッチをデプロイする必要があります。 各物理ノードには 4 つの NIC が必要です。そのうちの 2 つは RDMA 対応である必要があり、各ノードから 2 つの ToR スイッチへの 2 つのリンクを提供します。 各スイッチに接続された 2 つの NIC は、コンピューティングネットワークと管理ネットワークのアウトバウンド南北接続用に収束されます。 他の 2 つの RDMA 対応 NIC は、ストレージの東西トラフィック専用です。 既存のネットワーク スイッチを使用する予定の場合は、スイッチの make と model が、Azure Localでサポートされているネットワーク スイッチの 承認済みリストにあることを確認します。

7. ハードウェア OEM または SI パートナーと協力して、ハードウェアの配送を手配します。 SI パートナーまたは従業員は、ハードウェアをオンプレミスのデータセンターまたはエッジの場所に統合する必要があります。たとえば、物理ノードのハードウェア、物理ネットワーク、電源ユニットのケーブル接続のラックと積み重ねなどです。

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

   先端

   Azure Stack HCI OS バージョン 23H2 システム リファレンス実装、ARM テンプレートとパラメーター ファイルを使用して、Azure Local の切り替え済みマルチサーバー デプロイをデプロイする方法を示します。 または、Bicep の例 、Bicep テンプレートを使用して、前提条件リソースを含む Azure Local インスタンスをデプロイする方法を示します。

9. Azure Portal、CLI、または ARM + Azure Arc テンプレートを使用して Azure Local に高可用性ワークロードをデプロイ。 Azure Arc VM、AKS、Azure Virtual Desktop セッション ホスト、その他の Azure Arc 対応サービスなどのワークロード リソースをデプロイ 場合は、新しい HCI クラスターの カスタムの場所 リソースをターゲット リージョンとして使用します。このサービスは、AKS 拡張機能と Azure Local でのコンテナー化を通じて有効にできます。

10. プラットフォームのセキュリティと信頼性を向上させるために、毎月の更新プログラムをインストールします。 Azure Local インスタンスを最新の状態に保つには、Microsoft ソフトウェア更新プログラムとハードウェア OEM ドライバーとファームウェアの更新プログラムをインストールすることが重要です。 これらの更新プログラムにより、プラットフォームのセキュリティと信頼性が向上します。 Update Manager は、更新プログラムを適用し、1 つのクラスターまたは複数のクラスターに更新プログラムをインストールするための一元的でスケーラブルなソリューションを提供します。 ハードウェア OEM パートナーに問い合わせて、ハードウェア ドライバーとファームウェアの更新プログラムをインストールするプロセスを決定してください。これは、選択したハードウェア ソリューション カテゴリの種類 (Premier ソリューション、統合システム、または検証済みノード) によって異なる可能性があるためです。 詳細については、「インフラストラクチャの更新」を参照してください。

関連リソース

• ハイブリッド アーキテクチャの設計
• Azure ハイブリッド オプション を する
• ハイブリッド環境での自動化の
• Azure Automation State Configuration の
• Azure Arc を使用してオンプレミス環境とマルチクラウド環境での SQL Server インスタンスの管理を最適化する

次の手順

製品ドキュメント:

• Azure Stack HCI OS バージョン 23H2 リリース情報
• Azure Local での AKS の
• Azure Virtual Desktop for Azure Local
• Azure ローカル監視とは
• Azure ローカル 上の Site Recovery を使用して VM ワークロードを保護する
• モニターの概要
• 変更履歴とインベントリの概要
• Update Manager の概要
• Azure Arc 対応データ サービスとは
• Azure Arc 対応サーバーとは
• バックアップ サービスとは

特定の Azure サービスの詳細については、製品ドキュメントを参照してください。

• Azure ローカル の
• Azure Arc の
• Key Vault の
• Azure Blob Storage の
• Monitor
• Azure Policy の
• Azure Container Registry の
• Defender for Cloud
• Site Recovery
• バックアップ

Microsoft Learn モジュール:

• Monitor の構成
• Azure でサイト回復ソリューションを設計する
• Azure Arc 対応サーバーの概要
• Azure Arc 対応データ サービスの概要
• AKS の概要
• Machine Learning を使用した スケール モデルのデプロイ - Tech Community ブログ
• AKS と Azure Arc 対応 Machine Learning を使用してどこでも Machine Learning を実現する - Tech Community ブログ
• Azure Arc 対応機械学習を使用した AKS ハイブリッドと Stack HCI での機械学習の - Tech Community ブログ
• Machine Learning での Kubernetes コンピューティング ターゲットの概要
• VM を最新の状態に保つ
• Automation 状態構成 を使用して VM 設定を保護する
• バックアップ を使用して VM を保護する