この記事は、Azure ローカル ベースライン参照アーキテクチャに基づくシリーズの一部です。 の 3 ノード ストレージ スイッチレス 設計を使用して Azure Local を効果的にデプロイするには、ベースライン アーキテクチャを理解することが重要です。 このプロセスには、ローカルコンピューティング、ストレージ、およびネットワーク機能を提供する物理ノードのクラスター設計の選択肢を理解する必要があります。 この知識は、デプロイを成功させるために必要な変更を特定するのに役立ちます。 この記事のガイダンスは、2 ノード ストレージ スイッチレス 展開にも適用され、物理ノードの数が 3 から 2 に減少する場合に必要な調整を行います。
記憶域スイッチレス ネットワーク設計では、ストレージ トラフィックに使用されるネットワーク アダプター ポートを接続するためのストレージ クラス ネットワーク スイッチの要件が削除されます。 代わりに、ノードは、リンク間イーサネット ケーブルを使用して直接接続されます。 この構成は、小売、製造、またはリモート オフィスのシナリオでよく使用されます。 この構成は、ストレージ レプリケーション トラフィックに広範なデータセンター ネットワーク スイッチがない、または必要としない小規模なエッジ ユース ケースにも適しています。
この参照アーキテクチャでは、仮想化されたワークロードをデプロイおよび管理するための回復性の高いインフラストラクチャ プラットフォームとして Azure Local を構成するための、ワークロードに依存しないガイダンスと推奨事項が提供されます。 Azure Local で実行するように最適化されたワークロード アーキテクチャ パターンの詳細については、Azure Local ワークロード ナビゲーション メニューにあるコンテンツを参照してください。
このアーキテクチャは、ストレージ スイッチレス ネットワーク設計を使用する、
記事のレイアウト
| 建築 | 設計上の決定 | Well-Architected Framework のアプローチ |
|---|---|---|
| ▪ アーキテクチャ図の ▪ 潜在的なユース ケース ▪ このシナリオ をデプロイする |
▪ クラスターの設計の選択 ▪ ネットワーク |
▪ コストの最適化 ▪ パフォーマンス効率の |
先端
この リファレンス実装 では、ARM テンプレートとパラメーター ファイルを使用して、3 ノード ストレージスイッチレス Azure ローカル ソリューション をデプロイする方法について説明します。
建築
これらのリソースの詳細については、「関連リソース
潜在的なユース ケース
次のユース ケース要件に対処するには、この設計と、Azure ローカル ベースライン参照アーキテクチャ で説明されている設計を使用します。
高可用性 (HA) 仮想化またはコンテナーベースのエッジ ワークロードを 1 か所にデプロイしてデプロイし、ビジネスクリティカルなアプリケーションとサービスを回復性があり、コスト効率に優れ、スケーラブルな方法で動作できるように管理します。
記憶域スイッチレス ネットワーク設計では、ストレージ クラスのネットワーク スイッチをデプロイして、ストレージ トラフィックに使用されるネットワーク アダプター ポートを接続する必要がなくなります。
記憶域スイッチレス ネットワーク設計を使用すると、ストレージ トラフィック用のストレージ クラス ネットワーク スイッチの調達と構成に関連するコストを削減できますが、物理ノードに必要なネットワーク アダプター ポートの数は増えます。
アーキテクチャ コンポーネント
アーキテクチャ リソースは、ベースライン参照アーキテクチャとほとんど変わりません。 詳細については、Azure ローカル デプロイに使用
クラスターの設計の選択
クラスターの設計オプションを決定する場合は、ベースライン参照アーキテクチャのを参照してください。 これらの分析情報と Azure Local Sizer Tool を使用して、ワークロードの要件に従って Azure Local インスタンスを適切にスケーリングします。
記憶域スイッチレス設計を使用する場合は、3 ノード クラスターがサポートされる最大サイズであることを覚えておく必要があります。 この制限は、ワークロードの容量要件が 3 ノード クラスター仕様の物理容量機能を超えないようにする必要があるため、クラスター設計の選択に関する重要な考慮事項です。 3 つのノードを超えてストレージ スイッチレス クラスターを拡張する追加ノード ジェスチャを実行することはできないため、ワークロードの容量要件を事前に理解し、将来の成長を計画することが非常に重要な
注意
記憶域スイッチレス ネットワーク アーキテクチャでサポートされる最大クラスター サイズは、3 つの物理ノードです。 ワークロードの現在および将来の拡張容量の要件など、クラスターの設計フェーズでこの制限を考慮してください。
ネットワーク設計
ネットワーク設計とは、ネットワーク内の物理コンポーネントと論理コンポーネントの全体的な配置を指します。 Azure Local の 3 ノード ストレージ スイッチレス構成では、ストレージ トラフィックに外部スイッチを使用せずに 3 つの物理ノードが直接接続されます。 これらの直接リンクされたイーサネット接続により、サービスのストレージ品質と優先順位付け構成をスイッチに定義または適用する必要がないため、複雑さが軽減され、ネットワーク設計が簡素化されます。 RoCE v2 と iWARP に必要な、明示的な輻輳通知 (ECN)、優先順位フロー制御 (PFC)、サービス品質 (QoS) など、無損失 RDMA 通信を支えるテクノロジは必要ありません。 ただし、この構成では最大 3 つのノードがサポートされています。つまり、デプロイ後にノードを追加してクラスターをスケーリングすることはできません。
手記
この 3 ノード ストレージ スイッチレス アーキテクチャでは、すべてのネットワーク意図に冗長リンクを提供する 6 つのネットワーク アダプター ポート
物理ネットワーク トポロジ
物理ネットワーク トポロジは、ノードとネットワーク コンポーネント間の実際の物理接続を示しています。 3 ノード ストレージ スイッチレス Azure ローカル デプロイのノードとネットワーク コンポーネント間の接続は次のとおりです。
3 つのノード (またはサーバー):
各ノードは、Azure Stack HCI OS 上で実行される物理サーバーです。
各ノードには、合計で 6 つのネットワーク アダプター ポートが必要です。ストレージには 4 つの RDMA 対応ポート、管理とコンピューティングには 2 つのポートが必要です。
ストレージ トラフィック:
3 つのノードはそれぞれ、記憶域用のデュアル専用物理ネットワーク アダプター ポートを介して相互接続されます。 次の図は、このプロセスを示しています。
ストレージ ネットワーク アダプター ポートは、イーサネット ケーブルを使用して各ノードに直接接続し、ストレージ トラフィック用のフル メッシュ ネットワーク アーキテクチャを形成します。
この設計により、リンク冗長性、専用の低待機時間、高帯域幅、高スループットが提供されます。
HCI クラスター内のノードは、これらのリンクを介して直接通信して、ストレージ レプリケーション トラフィック (東西トラフィックとも呼ばれます) を処理します。
この直接通信により、記憶域に追加のネットワーク スイッチ ポートが不要になり、ネットワーク スイッチ上の SMB ダイレクトまたは RDMA トラフィックに QoS またはPFC 構成を適用する必要がなくなります。
スイッチレス相互接続ネットワーク構成に推奨される OS ドライバー、ファームウェアバージョン、またはファームウェア設定については、ハードウェア製造元のパートナーまたはネットワーク インターフェイス カード (NIC) ベンダーにお問い合わせください。
デュアルトップオブラック(ToR)スイッチ:
この構成は、ストレージ トラフィック スイッチレス ですが、外部接続には ToR スイッチが必要です。 この接続は南北トラフィックと呼ばれ、クラスター
管理 インテントと、コンピューティング 意図ワークロードが含まれます。 各ノードからのスイッチへのアップリンクは、2 つのネットワーク アダプター ポートを使用します。 イーサネット ケーブルは、これらのポートを各 ToR スイッチに 1 つずつ接続して、リンクの冗長性を提供します。
デュアル ToR スイッチを使用して、サービス操作と外部通信の負荷分散に冗長性を提供することをお勧めします。
外部接続:
デュアル ToR スイッチは、内部企業 LAN などの外部ネットワークに接続し、ファイアウォールやルーターなどのエッジ ボーダー ネットワーク デバイスを使用して、必要な送信 URL へのアクセスを提供します。
2 つの ToR スイッチは、管理とコンピューティングの意図に関連するトラフィックを含め、Azure ローカル インスタンスの南北トラフィックを処理します。
論理ネットワーク トポロジ
論理ネットワーク トポロジでは、物理接続に関係なく、デバイス間のネットワーク データフローの概要が提供されます。 次の一覧は、3 ノード ストレージスイッチレス Azure Local インスタンスの論理セットアップをまとめたものです。
デュアル ToR スイッチ:
- クラスターをデプロイする前に、2 つの ToR ネットワーク スイッチを、管理ポートとコンピューティング ポートに必要な VLAN ID と最大伝送ユニット (MTU) 設定で構成する必要があります。 詳細については、物理ネットワーク要件 を参照するか、スイッチ ハードウェア ベンダーまたはシステム インテグレーター (SI) パートナーにサポートを依頼してください。
Azure Local では、ネットワーク ATC サービスを使用して、ネットワーク自動化と インテントベースのネットワーク構成 を適用します。
ネットワーク ATC は、ネットワーク トラフィック 意図使用して、最適なネットワーク構成とトラフィック フローを確保するように設計されています。 ネットワーク ATC では、クラスター 管理、ワークロード コンピューティング、クラスター ストレージ インテントなど、さまざまなネットワーク トラフィックの意図 (または種類) に使用される物理ネットワーク アダプター ポートを定義します。
意図ベースのポリシーでは、Azure ローカル クラウド デプロイ プロセスの一部として指定されたパラメーター入力に基づいてノード ネットワーク構成を自動化することで、ネットワーク構成の要件が簡素化されます。
外信：
ノードまたはワークロードが企業の LAN、インターネット、または別のサービスにアクセスして外部と通信する必要がある場合は、デュアル ToR スイッチを使用してルーティングします。 このプロセスについては、前の「物理ネットワーク トポロジの」セクション
説明します。 2 つの ToR スイッチがレイヤー 3 デバイスとして機能する場合は、ルーティングを処理し、クラスターを超えて、ファイアウォールやルーターなどのエッジ ボーダー デバイスへの接続を提供します。
管理ネットワーク意図では、集中型スイッチ埋め込みチーミング (SET) 仮想インターフェイスを使用します。これにより、クラスター管理 IP アドレスとコントロール プレーン リソースが外部と通信できるようになります。
コンピューティング ネットワークの目的では、環境に合わせて特定の VLAN ID を持つ 1 つ以上の論理ネットワークを Azure に作成できます。 仮想マシン (VM) などのワークロード リソースでは、これらの ID を使用して物理ネットワークへのアクセスを許可します。 論理ネットワークは、コンピューティングと管理の意図に SET を使用して収束される 2 つの物理ネットワーク アダプター ポートを使用します。
ストレージ トラフィック:
ノードは、ストレージ トラフィックに対して 6 つの独立した非ルーティング (またはレイヤー 2) ネットワークを使用するノードごとに 4 つの直接接続イーサネット ポートを使用して、ストレージ トラフィック用に直接相互に通信します。
Azure Stack HCI OS 内の 4 つのストレージインテント ネットワーク アダプター ポートに既定のゲートウェイ が構成されていない
。 各ノードは、記憶域プール、仮想ディスク、ボリュームで使用されるリモート物理ディスクなど、クラスターの S2D 機能にアクセスできます。 これらの機能へのアクセスは、各ノードで使用可能な 2 つの専用ストレージ ネットワーク アダプター ポートを介して、SMB ダイレクト RDMA プロトコルを介して容易になります。 SMB マルチチャネルは回復性のために使用されます。
この構成により、ミラー化されたボリュームのデータの一貫性のあるコピーを維持するなど、ストレージ関連の操作に十分なデータ転送速度が確保されます。
IP アドレスの要件
ストレージ 相互接続用のデュアル リンクを使用して Azure Local の 3 ノード ストレージ スイッチレス構成をデプロイするには、クラスター インフラストラクチャ プラットフォームで少なくとも 20 個の IP アドレスを割り当てる必要があります。 ハードウェア製造元パートナーから提供された VM アプライアンスを使用する場合、またはマイクロセグメント化またはソフトウェア定義ネットワーク (SDN) を使用する場合は、さらに多くの IP アドレスが必要です。 詳細については、「Azure Localの 3 ノード ストレージ参照パターン IP 要件を確認する」を参照してください。
Azure Local の IP アドレス要件を設計して計画するときは、Azure Local インスタンスとインフラストラクチャ コンポーネントに必要な IP アドレスまたはネットワーク範囲を超えて、ワークロードに必要な追加の IP アドレスまたはネットワーク範囲を考慮してください。 Azure Local で Azure Kubernetes Services (AKS) を使用する予定の場合は、Azure Arc ネットワーク要件によって有効になっている AKS
考慮 事項
これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Frameworkの
大事な
Azure ローカル ベースライン参照アーキテクチャので説明されている Well-Architected Framework の考慮事項を確認します。
コストの最適化
コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の柱の概要」を参照してください。
コストの最適化に関する考慮事項は次のとおりです。
- スイッチレス クラスター 相互接続とスイッチベースのクラスター 相互接続。 スイッチレス 相互接続トポロジは、フル メッシュを形成するために、各ノードのデュアル ポート または冗長の RDMA 対応ネットワーク アダプター ポート間の接続で構成されます。 各ノードは、他のすべてのノードに 2 つの直接接続を持ちます。 この実装は簡単ですが、2 ノードまたは 3 ノードのクラスターでのみサポートされます。 4 つ以上のノードを持つ Azure Local インスタンスには、ネットワーク アーキテクチャ 切り替えた
ストレージが必要です。 このアーキテクチャを使用すると、ノードの追加操作をサポートしないストレージ スイッチレス設計とは異なり、デプロイ後にノードを追加できます。
パフォーマンス効率
パフォーマンス効率は、ユーザーの要求に効率的に対応するためにワークロードをスケーリングする機能です。 詳細については、「パフォーマンス効率の柱の概要を参照してください。
パフォーマンスの効率性に関する考慮事項は次のとおりです。
- クラスターを再デプロイし、ネットワーク スイッチ、記憶域トラフィック用のポート、ケーブル、その他の必要なノードなどの追加のネットワーク機能を追加せずに、既存の 3 ノード ストレージ スイッチレス HCI クラスターのスケールを増やしたり、ノードの追加操作を実行したりすることはできません。 記憶域スイッチレス ネットワーク設計でサポートされる最大クラスター サイズは、3 つのノードです。 この制限をクラスター設計フェーズに組み込んで、ハードウェアが将来のワークロード容量の増加をサポートできるようにします。
このシナリオをデプロイする
Azure ローカル ソリューションを設計、調達、デプロイする方法の詳細については、「
3 ノード ストレージスイッチレス アーキテクチャを使用して Azure Local をデプロイする方法の例として、次のデプロイ自動化テンプレートを使用します。
先端
デプロイ自動化: この リファレンス テンプレート では、ARM テンプレートとパラメーター ファイルを使用して、3 ノード ストレージスイッチレス Azure ローカル ソリューション をデプロイする方法について説明します。
関連リソース
- ハイブリッド アーキテクチャの設計
- Azure ハイブリッド オプション を
する - ハイブリッド環境での Azure Automation の
- 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 ワークロードを保護する
- Azure Monitor の概要
- 変更履歴とインベントリの概要
- Azure Update Manager の概要
- Azure Arc 対応データ サービスとは
- Azure Arc 対応サーバーとは
- Azure Backup とは
- Azure Machine Learning での Kubernetes コンピューティング ターゲットの概要
特定の Azure サービスの製品ドキュメント:
- Azure ローカル の
- Azure Arc の
- Azure Key Vault を
する - Azure Blob Storage の
- Monitor
- Azure Policy の
- Azure Container Registry の
- Microsoft Defender for Cloud の
- Azure Site Recovery を
する - バックアップ
Microsoft Learn モジュール:
- Monitor の構成
- Azure でサイト回復ソリューションを設計する
- Azure Arc 対応サーバーの概要
- Azure Arc 対応データ サービスの概要
- AKS の概要
- Azure Machine Learning を使用した スケール モデルのデプロイ - Tech Community ブログ
- AKS と Arc 対応機械学習を使用してどこでも機械学習を実現する - Tech Community ブログ
- Azure Arc 対応機械学習を使用した AKS ハイブリッドと Stack HCI での機械学習の - Tech Community ブログ
- 仮想マシンを更新したまま
- Azure Automation State Configuration を使用して仮想マシンの設定を保護する
- バックアップ を使用して VM を保護する