[ホストベースのマイクロセグメンテーションで SDÑ とファイアウォールの導入を簡素化]

[ソフトウェア定義ネットワーク (SDÑ) そして、セグメンテーションはどちらも自動化を優先するため、しばしば同時に議論されます。S~DÑ はネットワークに関わる多くのタスクを自動化しますが、最近のセキュリティ侵害のほとんどは自動化されているため、セグメンテーションツールも同様の方法に従うべきです。さらに、信頼境界は従来、あらゆるクラウドアーキテクチャのネットワーク層にあると理解されてきました。SD~Ñ コントローラーでは大規模なネットワークアーキテクチャーを一元的に管理およびオーケストレーションできるため、これらのコントローラーにセグメンテーションを追加してオーケストレーションを改善することは理にかなっています。]

[とはいえ、SDÑの「Ñ~」はネットワーキングの略であることに注意してください。したがって、どのSDÑコントローラーが導入するセグメンテーションも、ホストの課題ではなくネットワークの課題に焦点を当てて実装されます。S~DÑ コントローラーは従来の方法でホストをネットワークファブリックに接続するノードと見なし、それらのホスト上で実行されるアプリケーションはネットワーク中心のツールではなく、ホスト中心のツールを使用して管理されます。ネットワークツールがすべてのホストやアプリケーションに固有のタスクを管理することはほとんどありません。コントローラーは、ネットワーク・ファブリック内でトラフィック転送に関する決定を強制するためにネットワーク・セグメントを作成します。これらの決定は、ネットワーク負荷、遅延、リンク障害、動的ルーティング・プロトコルのコストなど、ルーターとスイッチに最も関連のある指標に従って行われます。これらの指標がホスト固有のセグメンテーション要件に関連することはほとんどありません。]

[ネットワークセグメンテーションとホストベースのマイクロセグメンテーション]

[信頼境界を定義する場合、関連するセグメントをどこに作成するかを決めると、2 つの会話が並行して行われます。1 つはホストワークロードを管理するチーム間で、もう 1 つはネットワークを管理するチーム間です。どちらのチームも「セグメンテーション」や「マイクロセグメンテーション」という同じ用語を使用しますが、意味は異なります。2 つのチームがそれぞれ独自のツールを使用してそれぞれのタイプのセグメントをデプロイおよび管理する場合、連携せずにサイロ化されたアプローチになり、アーキテクチャの規模が拡大するにつれて運用上の制限が生じます。]

[たとえば、ネットワークチームがデータセンター SDÑ ソリューションとして C~íscó~ ÁCÍ を導入したとします。Á~CÍ は独自のメカニズムを使用して、ブリッジドメインやエンドポイントグループ（ÉP~G）などのセグメントを作成します。ワークロードは ÉPG~ 内にデプロイされ、より小さな「マイクロ ÉPG」に分割して、より詳細なネットワークセグメントを作成できます。]

[ただし、これらは依然としてネットワーク中心のセグメンテーション概念です。たとえば、データセンターに 10 台のホストがある場合、Císc~ó ÁCÍ~ で 10 個の ÉPG セグメントを作成するだけで、各ホストに信頼境界を設定できます。しかし、ワークロードが 100 個または 1,000 個ある場合、各ホストに 100 個または 1,000 個の É~PG セグメントを作成することは運用上非現実的です。SD~Ñ コントローラーを使用して同数のネットワークセグメントとホストを作成しても、単純に拡張できません。]

[SDÑソリューションは独自のセグメントを作成して対処する ネットワークセグメンテーション 優先順位がありますが、個々のホストをセグメント化するには、ホストベースのアプローチを検討する必要があります。]

[SDÑ とオーバーレイネットワーク]

[SDÑ の利点の 1 つは、ネットワークトポロジーがルーターやスイッチの物理トポロジーに依存しなくなったことです。ネットワークの仮想化には、V~XLÁÑ~ や GÉÑÉ~VÉ などのトンネリングプロトコルが使用されます。ネットワークはデータセンターのコンピューティングリソースやストレージリソースとほとんど同じ方法で仮想化できるようになったため、これらのトンネリング方法を使用すると、ネットワークパスとリンクをプログラム的に定義できるようになり、物理インフラストラクチャを変更しなくても、コントローラーが必要に応じてネットワークトポロジーをすばやく再構成できます。これにより、パブリッククラウドネットワークファブリックでネットワークを仮想化する方法と同様に、オンプレミスデータセンターのネットワークファブリックを仮想化できます。]

[VXLÁ~Ñなどのオーバーレイネットワークには1,600万を超える多数の固有ÍDがあるため、これらのÍ~Dを使用して、SDÑ~コントローラーがネットワーク上のすべてのホストにセグメントを割り当てることができるマイクロセグメンテーションアーキテクチャを作成したいと思うでしょう。しかし、SDÑ コントローラーは V~XLÁÑ~ セグメントを個々のホストで終了しません。SDÑ コントローラーはこれらの固有の Í~D をすべて使用して、レイヤー 2 パケットをレイヤー 3 フレームにカプセル化するなどのネットワークの課題を解決します。すべてのホストでマイクロセグメンテーションを実現するには、使用するメカニズムをホスト自体で有効にする必要があります。ネットワークにデプロイされ、ネットワークタスクに特化した外部 SDÑ~ コントローラーで有効にする必要はありません。]

[ホストレベルのツールはSDÑにどのように役立ちますか？]

[ほとんどのSDÑソリューションの課題は、アプリケーションフローの可視性です。アプリケーションの観点からアプリケーションの動作を判断できるかどうかは、ネットワーキングツールにとっての課題です。S~DÑ コントローラーはネットワークトポロジ、ネットワークセグメント、ÍP~ アドレス、トラフィックメトリクスを詳細に把握できますが、たとえば SQL サーバーと W~éb サーバー間の動作や必要なネットワークリソースを明確に把握することは、SD~Ñ コントローラーでは簡単ではないことがよくあります。スケーラブルなクラウドアーキテクチャを設計するには、ネットワーク上のアプリケーション間の動的な要件を知る必要があります。]

[Íllú~míóのようなホストベースのソリューションをS~DÑアーキテクチャを使用するデータセンターに導入する場合、次のようなマッピング機能を探す必要があります。 アプリケーション依存関係マップ、ホスト固有の要件に対応するネットワークリソースの設計を支援します。Íl~lúmí~ó はあらゆる SDÑ~ ソリューションと共存し、アプリケーション依存関係マップはホスト固有のセグメントの定義に使用されますが、これと同じマップにより、ネットワークが SDÑ コントローラーによって展開および管理される場合のアプリケーション要件を明確に把握できます。]

[ホストベースのマイクロセグメンテーションとネットワークレベルのセグメンテーションは、それぞれ異なる要件に対応するため、共存できます。ホストベースのアプローチを導入することで、SDÑ ソリューションであらゆるクラウドアーキテクチャのネットワークリソースを保証できる、アプリケーションレベルの可視化機能が得られます。]

[ホストベースのマイクロセグメンテーションに対するイルミオのアプローチの詳細については、以下をご覧ください。 http~s://www~.íllú~míó.c~óm/só~lútí~óñs/m~ícró~-ségm~éñtá~tíóñ~]