アプリケーション中心のインフラストラクチャ。 未来のネットワーク アーキテクチャ - 推測から行動へ

ここ数年、シスコはデータセンター内にデータ伝送ネットワークを構築するための新しいアーキテクチャを積極的に推進してきました。 アプリケーション セントリック インフラストラクチャ (ACI)。 すでによく知っている人もいます。 そして、ロシアを含む企業でそれを導入することに成功した人もいます。 しかし、ほとんどの IT プロフェッショナルや IT 管理者にとって、ACI は依然としてあいまいな頭字語であるか、単に将来を反映したものにすぎません。
この記事では、この未来を近づけていきたいと思います。 これを行うために、ACI の主要なアーキテクチャ コンポーネントについて説明し、実際に ACI を使用する方法についても説明します。 さらに、近い将来、ACI の視覚的なデモンストレーションを開催する予定です。これには、興味のある IT スペシャリストであれば誰でもサインアップできます。

2019 年 XNUMX 月にサンクトペテルブルクの新しいネットワーク アーキテクチャについて詳しく知ることができます。 すべての詳細は次のとおりです リンク。 サインアップ！

背景
従来の最も一般的なネットワーク構築モデルは、コア -> ディストリビューション (アグリゲーション) -> アクセスという XNUMX レベルの階層モデルです。 長年にわたり、このモデルが標準であり、メーカーはこのモデルに適した機能を備えたさまざまなネットワーク デバイスを製造していました。
以前、情報テクノロジーがビジネスに必要な (そして率直に言って、常に望まれるわけではありません) 付属品だったとき、このモデルは便利で、非常に静的で信頼性の高いものでした。 しかし、IT がビジネス発展の原動力の XNUMX つとなり、多くの場合ビジネス自体が推進されるようになった今、このモデルの静的な性質が大きな問題を引き起こし始めています。

現代のビジネスでは、ネットワーク インフラストラクチャに対して多数の異なる複雑な要件が生成されます。 ビジネスの成功は、これらの要件を実装するタイミングに直接依存します。 このような状況での遅延は容認できず、従来のネットワーク構築モデルでは、すべてのビジネス ニーズをタイムリーに満たすことができないことがよくあります。

たとえば、新しい複雑なビジネス アプリケーションが出現すると、ネットワーク管理者は、多数の異なるネットワーク デバイスに対して、さまざまなレベルで同様の日常的な操作を多数実行する必要があります。 時間がかかるだけでなく、間違いを犯すリスクも高まり、IT サービスの重大なダウンタイムにつながり、結果として経済的損失につながる可能性があります。

問題の根本は、期限そのものや要件の複雑さですらありません。 実際のところ、これらの要件はビジネス アプリケーションの言語からネットワーク インフラストラクチャの言語に「翻訳」する必要があります。 ご存知のとおり、翻訳では必ず意味が部分的に失われます。 アプリケーション所有者がアプリケーションのロジックについて話すとき、ネットワーク管理者は、サポート、更新、文書化が必要な一連の VLAN、数十のデバイス上のアクセス リストを理解します。

蓄積された経験と顧客との継続的なコミュニケーションにより、シスコは、現代のトレンドに適合し、まずビジネス アプリケーションのロジックに基づいたデータセンター データ伝送ネットワークを構築するための新しい原則を設計および実装することができました。 したがって、アプリケーション セントリック インフラストラクチャという名前が付けられました。

ACI アーキテクチャ。
ACI アーキテクチャを物理的な側面からではなく、論理的な側面から考えるのが最も正しいです。 これは自動化ポリシーのモデルに基づいており、最上位のオブジェクトは次のコンポーネントに分割できます。

1. Nexus スイッチをベースとしたネットワーク。
2. APIC コントローラ クラスタ。
3. アプリケーションプロファイル。

各レベルをさらに詳しく見てみましょう。単純なレベルから複雑なレベルに移行していきます。

Nexus スイッチをベースとしたネットワーク
ACI ファクトリのネットワークは従来の階層モデルに似ていますが、構築ははるかに簡単です。 Leaf-Spine モデルはネットワークの編成に使用され、次世代ネットワークを実装するための一般に受け入れられたアプローチとなっています。 このモデルは、それぞれ Spine と Leaf の XNUMX つのレベルで構成されます。

Spine レベルはパフォーマンスのみを担当します。 Spine スイッチの合計パフォーマンスはファブリック全体のパフォーマンスと等しいため、40G 以上のポートを備えたスイッチをこのレベルで使用する必要があります。
スパイン スイッチは、次のレベルのすべてのスイッチ、つまりエンド ホストが接続されているリーフ スイッチに接続します。 リーフ スイッチの主な役割はポート容量です。

したがって、スケーリングの問題は簡単に解決されます。ファブリックのスループットを増やす必要がある場合は、Spine スイッチを追加し、ポート容量を増やす必要がある場合は、Leaf を追加します。
どちらのレベルでも、Cisco Nexus 9000 シリーズ スイッチが使用されます。これは、シスコにとって、アーキテクチャに関係なく、データセンター ネットワークを構築するための主要なツールです。 スパイン層には Nexus 9300 または Nexus 9500 スイッチが使用され、リーフには Nexus 9300 のみが使用されます。
ACI ファクトリで使用される Nexus スイッチのモデル範囲を次の図に示します。

APIC (アプリケーション ポリシー インフラストラクチャ コントローラー) コントローラー クラスター
APIC コントローラーは特殊な物理サーバーですが、小規模な実装の場合は、XNUMX つの物理 APIC コントローラーと XNUMX つの仮想 APIC コントローラーからなるクラスターを使用できます。
APIC コントローラは、制御機能と監視機能を提供します。 重要なことは、コントローラーがデータ転送に参加しないことです。つまり、すべてのクラスター コントローラーに障害が発生しても、ネットワークの安定性にはまったく影響しません。 また、APIC の助けを借りて、管理者は工場のすべての物理的および論理的リソースを完全に管理します。また、ACI は単一の制御点。

次に、ACI の主要コンポーネントの XNUMX つであるアプリケーション プロファイルに移りましょう。
アプリケーションネットワークプロファイル は ACI の論理的基盤です。 すべてのネットワーク セグメント間の対話ポリシーを定義し、ネットワーク セグメント自体を記述するのはアプリケーション プロファイルです。 ANP を使用すると、物理層を抽象化し、実際に、アプリケーションの観点から異なるネットワーク セグメント間の対話をどのように組織する必要があるかを想像できます。

アプリケーション プロファイルは、接続グループ (エンドポイント グループ - EPG) で構成されます。 接続グループは、同じセキュリティ セグメント (ネットワークではなくセキュリティ) 内にあるホスト (仮想マシン、物理サーバー、コンテナなど) の論理グループです。 特定の EPG に属するエンド ホストは、多数の基準によって決定できます。 以下が一般的に使用されます。

• 物理ポート
• 論理ポート（仮想スイッチ上のポートグループ）
• VLAN ID または VXLAN
• IPアドレスまたはIPサブネット
• サーバーの属性 (名前、場所、OS バージョンなど)

さまざまな EPG の相互作用のために、コントラクトと呼ばれるエンティティが提供されます。 コントラクトは、さまざまな EPG 間の関係を定義します。 つまり、コントラクトは、ある EPG が別の EPG にどのようなサービスを提供するかを定義します。 たとえば、トラフィックが HTTPS プロトコルを介して流れることを許可するコントラクトを作成します。 次に、この契約を使用して、たとえば EPG Web (Web サーバーのグループ) と EPG App (アプリケーション サーバーのグループ) に接続します。その後、これら XNUMX つの端末グループは HTTPS プロトコルを介してトラフィックを交換できるようになります。

次の図は、同じ ANP 内の契約を通じて異なる EPG 間の通信を設定する例を示しています。

ACI ファクトリ内には、任意の数のアプリケーション プロファイルを含めることができます。 さらに、コントラクトは特定のアプリケーション プロファイルに関連付けられておらず、異なる ANP 内の EPG を接続するために使用できます (また使用する必要があります)。

実際、何らかの形でネットワークを必要とする各アプリケーションは、独自のプロファイルによって記述されます。 たとえば、上の図は、N 個の外部アクセス サーバー (Web)、アプリケーション サーバー (App)、および DBMS サーバー (DB) で構成される XNUMX 層アプリケーションの標準的なアーキテクチャを示しており、また、これらの間の相互作用のルールも説明しています。彼ら。 従来のネットワーク インフラストラクチャでは、これはインフラストラクチャ内のさまざまなデバイスにわたって記述される一連のルールになります。 ACI アーキテクチャでは、これらのルールを単一のアプリケーション プロファイル内に記述します。 ACI ではアプリケーション プロファイルを使用し、すべての設定を XNUMX つのプロファイルにグループ化することで、さまざまなデバイス上で多数の設定を簡単に作成できます。
下の図は、より現実的な例を示しています。 複数の EPG とコントラクトから作成された Microsoft Exchange アプリケーション プロファイル。

一元管理、自動化、監視は ACI の主な利点の XNUMX つです。 ACI Factory は、管理者を、さまざまなスイッチ、ルーター、ファイアウォール上で多数のルールを作成するという退屈な作業から解放します (ただし、従来の手動構成方法が許可されており、使用することもできます)。 アプリケーション プロファイルおよびその他の ACI オブジェクトの設定は、ACI ファブリック全体に自動的に適用されます。 サーバーをファブリック スイッチの他のポートに物理的に切り替える場合でも、古いスイッチから新しいスイッチに設定を複製したり、不要なルールを削除したりする必要はありません。 ホストの EPG メンバーシップ基準に基づいて、工場ではこれらの設定が自動的に行われ、未使用のルールが自動的にクリーンアップされます。
統合 ACI セキュリティ ポリシーはホワイトリストとして実装されます。つまり、明示的に許可されていないものはデフォルトで禁止されます。 ネットワーク機器構成の自動更新 (「忘れられた」未使用のルールと権限の削除) と併せて、このアプローチにより、ネットワーク セキュリティの全体的なレベルが大幅に向上し、潜在的な攻撃の対象範囲が狭まります。

ACI を使用すると、仮想マシンやコンテナだけでなく、物理サーバー、ハードウェア ファイアウォール、サードパーティのネットワーク機器のネットワーク インタラクションを整理できるため、現時点では ACI がユニークなソリューションになります。
アプリケーション ロジックに基づいてデータ ネットワークを構築するシスコの新しいアプローチは、自動化、セキュリティ、集中管理だけを目的としたものではありません。 また、現代のビジネスのすべての要件を満たす、水平方向に拡張可能な最新のネットワークでもあります。
ACI に基づくネットワーク インフラストラクチャを実装すると、企業のすべての部門が同じ言語を使用できるようになります。 管理者は、必要なルールと接続を記述するアプリケーションのロジックによってのみ指示されます。 アプリケーションのロジックだけでなく、アプリケーションの所有者や開発者、情報セキュリティ サービス、経済学者や経営者もそれに従っています。

このように、シスコは次世代データセンター ネットワークのコンセプトを実践しています。 これを自分の目で見てみたいですか？ デモンストレーションに来てください アプリケーション中心のインフラストラクチャ サンクトペテルブルクに拠点を置き、将来のデータセンター ネットワークを現在活用しています。
イベントに登録できます リンク.

出所： habr.com