Cisco ACI データセンターのネットワーク ファブリック - 管理者を支援します

Cisco ACI スクリプトのこの魔法の部分を利用すると、ネットワークを迅速にセットアップできます。

Cisco ACI データセンターのネットワーク ファクトリは XNUMX 年前から存在していましたが、ハブレ氏はそれについて特に何も語らなかったので、少し修正することにしました。 私自身の経験から、それが何であるか、それが何に使用されるか、そしてどこに熊手があるのか​​を説明します。

それは何ですか、そしてどこから来たのですか？

2013 年に ACI (アプリケーション セントリック インフラストラクチャ) が発表されるまでに、競合他社はデータセンター ネットワークへの従来のアプローチを XNUMX つの側面から同時に進めていました。

一方で、OpenFlow に基づく「第 XNUMX 世代」の SDN ソリューションは、ネットワークをより柔軟にし、同時に安価にすることを約束しました。 このアイデアは、従来、独自のスイッチ ソフトウェアによって行われてきた意思決定を中央コントローラに移すことでした。

このコントローラーは、起こっていることすべてを単一のビジョンで把握し、これに基づいて、特定のフローを処理するためのルールのレベルですべてのスイッチのハードウェアをプログラムします。
一方、オーバーレイ ネットワーク ソリューションでは、物理ネットワークをまったく変更せずに、仮想化ホスト間にソフトウェア トンネルを構築することで、必要な接続ポリシーとセキュリティ ポリシーを実装することが可能になりました。 このアプローチの最もよく知られた例は Nicira で、当時すでに VMWare に 1,26 億 XNUMX 万ドルで買収され、現在の VMWare NSX が誕生しました。 Nicira の共同創設者が以前 OpenFlow の起源に立った人物と同じ人物であり、現在ではデータセンター工場を建設するためにこう言っているという事実によって、状況の一部に面白みが加わりました。 OpenFlowは適さない.

そして最後に、公開市場で入手可能なスイッチング チップ (いわゆるマーチャント シリコン) が成熟段階に達し、従来のスイッチ メーカーにとって本当の脅威となっています。 以前は各ベンダーがスイッチ用のチップを独自に開発していましたが、時間が経つにつれて、主に Broadcom などのサードパーティ メーカーのチップが機能の点でベンダー チップとの距離を縮め始め、価格/性能比の点でベンダー チップを上回りました。 したがって、多くの人は、独自設計のチップにスイッチが搭載される時代はもう終わりだと信じていました。

ACI は、上記すべてに対するシスコの「非対称対応」（より正確には、元従業員によって設立された同社の Insieme 会社）となっています。

OpenFlowとの違いは何ですか?

機能の分散という点では、ACI は実は OpenFlow の逆です。
OpenFlow アーキテクチャでは、コントローラーは詳細なルール (フロー) を記述する責任があります。
すべてのスイッチのハードウェア、つまり大規模なネットワークでは、スイッチはネットワーク内の数百のポイントで数千万のレコードを維持し、最も重要なことに変更する責任を負っている可能性があるため、そのパフォーマンスと信頼性がボトルネックになります。大規模な実装。

ACI は逆のアプローチを使用します。もちろんコントローラーもありますが、スイッチはコントローラーから高レベルの宣言ポリシーを受け取り、スイッチ自体がハードウェアの特定の設定の詳細へのレンダリングを実行します。 コントローラーは再起動することも、完全にオフにすることもできます。もちろん、現時点で制御ができないことを除いて、ネットワークに悪いことは何も起こりません。 興味深いことに、ACI には OpenFlow が依然として使用されている状況がありますが、Open vSwitch プログラミングのためにホスト内でローカルに使用されています。

ACI は完全に VXLAN ベースのオーバーレイ トランスポートに基づいて構築されていますが、単一ソリューションの一部として基礎となる IP トランスポートが含まれています。 シスコではこれを「統合オーバーレイ」という用語と呼んでいます。 ACI のオーバーレイの終端ポイントとして、ほとんどの場合、工場出荷時のスイッチが使用されます (これはリンク速度で行われます)。 ホストはファクトリやカプセル化などについて何も知る必要はありませんが、場合によっては (OpenStack ホストに接続する場合など)、VXLAN トラフィックがホストに送信される可能性があります。

ACI ではオーバーレイは、トランスポート ネットワークを介した柔軟な接続を提供するためだけでなく、メタ情報を転送するためにも使用されます (セキュリティ ポリシーの適用などに使用されます)。

Broadcom のチップは、以前 Cisco の Nexus 3000 シリーズ スイッチで使用されていましたが、ACI をサポートするために特別にリリースされた Nexus 9000 ファミリでは、当初は Merchant + と呼ばれるハイブリッド モデルが実装されていました。 このスイッチは、新しい Broadcom Trident 2 チップと、ACI の魔法をすべて実装する Cisco が開発した補完チップの両方を同時に使用しました。 どうやら、これにより、製品のリリースを早め、スイッチの価格を単に Trident 2 ベースのモデルに近いレベルまで下げることが可能になりました。このアプローチは、ACI の納入の最初の 9000 ～ XNUMX 年間には十分でした。 この間、シスコは、より高いパフォーマンスと機能セットを備えた、同じ価格レベルの自社チップを搭載した次世代 Nexus XNUMX を開発し、発売しました。 工場内の相互作用に関する外部仕様は完全に保持されます。 同時に、内部の充填は完全に変更されました。リファクタリングのようなものですが、ハードウェア向けです。

Cisco ACI アーキテクチャの仕組み

最も単純なケースでは、ACI はクローゼ ネットワーク (よく言われるように、Spine-Leaf) のトポロジに基づいて構築されます。 スパイン レベルのスイッチは 2 つ (フォールト トレランスを気にしない場合は 3 つ) から XNUMX つまで可能です。 したがって、それらの数が多いほど、フォールト トレランスが向上し (XNUMX つの Spine の事故やメンテナンスが発生した場合の帯域幅と信頼性の低下が少なくなり)、全体的なパフォーマンスが向上します。 すべての外部接続はリーフレベル スイッチに送られます。これらはサーバーであり、LXNUMX または LXNUMX 経由で外部ネットワークとドッキングし、APIC コントローラーに接続します。 一般に、ACI では、構成だけでなく、統計情報の収集、障害の監視などもすべてコントローラーのインターフェイスを通じて行われ、標準サイズの実装ではコントローラーのインターフェイスが XNUMX つあります。

ネットワークを開始する場合でも、コンソールでスイッチに接続する必要はありません。コントローラー自体がスイッチを検出し、すべてのサービス プロトコルの設定を含むファクトリーを組み立てます。したがって、ちなみに、次のことが非常に重要です。後でどのスイッチがどのラックに配置されているかを推測する必要がないように、設置中に設置する機器のシリアル番号を書き留めてください。 トラブルシューティングのために、必要に応じて SSH 経由でスイッチに接続できます。通常の Cisco show コマンドが非常に注意深く再現されます。

工場では内部的に IP トランスポートを使用しているため、スパニング ツリーや過去のその他の恐ろしい問題はありません。すべてのリンクが関与しており、障害が発生した場合のコンバージェンスは非常に高速です。 ファブリック内のトラフィックは、VXLAN に基づいたトンネルを通じて送信されます。 より正確には、Cisco 自体は iVXLAN カプセル化と呼んでいます。これは、ネットワーク ヘッダーの予約フィールドを使用して、主にトラフィックと EPG グループの関係に関するサービス情報を送信するという点で通常の VXLAN とは異なります。 これにより、通常のアクセス リストでアドレスが使用されるのと同じ方法でグループの番号を使用して、装置内のグループ間の相互作用のルールを実装できます。

トンネルを使用すると、L2 セグメントと L3 セグメント (つまり VRF) の両方を内部 IP トランスポート経由で拡張できます。 この場合、デフォルトゲートウェイは分散されます。 これは、各スイッチがファブリックに入るトラフィックのルーティングを担当することを意味します。 トラフィック フロー ロジックの観点から見ると、ACI は VXLAN/EVPN ファブリックに似ています。

もしそうなら、違いは何ですか? ほかのすべて！

ACI との最大の違いは、サーバーがネットワークに接続される方法です。 従来のネットワークでは、物理サーバーと仮想マシンの両方が VLAN に組み込まれ、接続性、セキュリティなど、その他すべてが VLAN に依存します。ACI では、Cisco が EPG (エンドポイント グループ) と呼ぶ設計が使用されています。逃げられる場所はありません。 VLANと同等と考えて良いのでしょうか？ はい、ただしこの場合、ACI が提供するものの大部分が失われる可能性があります。

EPG に関しては、すべてのアクセス ルールが策定されており、ACI ではデフォルトで「ホワイト リスト」原則が使用されます。つまり、明示的に通過を許可するトラフィックのみが許可されます。 つまり、「Web」および「MySQL」EPG グループを作成し、ポート 3306 でのみそれらの間の通信を許可するルールを定義できます。これは、ネットワーク アドレスに関連付けられずに、さらには同じサブネット内でも機能します。

この機能により、サブネット間でサーバーをドラッグすることなく、つまりアドレス指定に触れることなく、サーバー (仮想か物理かは関係ありません) 間のアクセスを制限できるため、まさにこの機能を理由に ACI を選択したお客様もいらっしゃいます。 はい、はい、アプリケーション構成で IP アドレスを手動で規定する人はいないことはわかっていますよね?

ACI のトラフィック ルールはコントラクトと呼ばれます。 このような契約では、多層アプリケーション内の XNUMX つ以上のグループまたはレベルがサービス プロバイダー (データベース サービスなど) になり、その他はコンシューマになります。 コントラクトは単にトラフィックを通過させることもできますが、ファイアウォールやバランサーにトラフィックを転送したり、QoS 値を変更したりするなど、より複雑な処理を実行することもできます。

サーバーはどのようにしてこれらのグループに入るのでしょうか? これらが物理サーバー、または VLAN トランクを作成した既存のネットワークに含まれているものである場合、それらを EPG に配置するには、スイッチ ポートとそこで使用される VLAN を指定する必要があります。 ご覧のとおり、VLAN なしでは成り立たない場所に VLAN が表示されます。

サーバーが仮想マシンの場合、接続されている仮想化環境を参照するだけで十分です。その後、すべてが自動的に行われます。VM に接続するために (VMWare に関して) ポート グループが作成され、必要な VLAN または VXLAN が作成されます。そのため、ACI は物理ネットワークを中心に構築されていますが、仮想サーバーの接続は物理サーバーの接続よりもはるかに簡単に見えます。 ACI にはすでに VMWare および MS Hyper-V との接続機能が組み込まれており、OpenStack および RedHat Virtualization もサポートされています。 ある時点から、Kubernetes、OpenShift、Cloud Foundry などのコンテナ プラットフォームの組み込みサポートも登場しましたが、これはポリシーの適用と監視の両方に関係しています。つまり、ネットワーク管理者は、どのホストでどのポッドが動作しているかをすぐに確認でき、彼らがどのグループに分類されるか。

仮想サーバーには、特定のポート グループに含まれるだけでなく、名前や属性などの追加プロパティがあり、仮想サーバーを別のグループに転送するための基準として使用できます。たとえば、VM の名前が変更されたときや追加のタグがポート グループに表示されたときなどです。それ。 シスコではこれをマイクロ セグメンテーション グループと呼んでいますが、概して、同じサブネット上に EPG の形式で多数のセキュリティ セグメントを作成できる設計自体もかなりのマイクロ セグメンテーションです。 まあ、ベンダーの方がよく知っています。

EPG 自体は純粋に論理的な構造であり、特定のスイッチやサーバーなどに関連付けられていないため、クローン作成など、通常のネットワークでは実行が難しい作業を実行したり、EPG に基づいて構築したり (アプリケーションやテナント) できます。 その結果、実稼働環境と同一であることが保証されたテスト環境を取得するために、実稼働環境のクローンを作成することが非常に簡単になったとします。 手動で行うこともできますが、API を使用した方が優れています (そして簡単です)。

一般に、ACI の制御ロジックは、通常遭遇するものとはまったく似ていません。
同じ Cisco の従来のネットワークでは、ソフトウェア インターフェイスがプライマリであり、GUI または CLI は同じ API を介して動作するためセカンダリです。 したがって、ACI に関わるほぼ全員が、しばらくすると、管理に使用されるオブジェクト モデルを操作し、ニーズに合わせて何かを自動化し始めます。 これを行う最も簡単な方法は Python を使用することです。これには便利な既製のツールがあります。

約束された熊手

主な問題は、ACI の多くの処理が異なる方法で行われることです。 通常の操作を開始するには、再トレーニングする必要があります。 これは、エンジニアが要求に応じて何年も「VLAN を処方」してきた大規模顧客のネットワーク運用チームに特に当てはまります。 VLAN が VLAN ではなくなり、新しいネットワークを仮想化ホストに敷設するために手動で VLAN を作成する必要がなくなったことにより、従来のネットワーカーは完全に概念を吹き飛ばされ、使い慣れたアプローチにしがみつくことになります。 シスコは、この問題を少し改善しようとして、コントローラに「NXOS のような」CLI を追加しました。これにより、従来のスイッチと同様のインターフェイスから設定を実行できるようになりました。 ただし、ACI を正常に使用し始めるには、ACI がどのように機能するかを理解する必要があります。

価格の点では、大規模および中規模の ACI ネットワークは、構築に同じスイッチが使用されるため、Cisco 機器の従来のネットワークと実際には変わりません（Nexus 9000 は ACI および従来のモードで動作でき、現在ではメイン ネットワークとなっています）新しいデータセンター プロジェクトの「主力」)。 しかし、XNUMX 台のスイッチを備えたデータセンターの場合、コントローラーとスパインリーフ アーキテクチャの存在が当然感じられます。 最近、XNUMX つのコントローラーのうち XNUMX つが仮想マシンに置き換えられる Mini ACI ファクトリーが登場しました。 これによりコストの差は減少しますが、それでも差は残ります。 したがって、顧客にとっての選択は、セキュリティ機能、仮想化との統合、単一制御点などにどれだけ関心があるかによって決まります。

出所： habr.com