前回の記事では、Big Switch NetworksのBig Switch FabricのSDNソリューションのアーキテクチャとキーポイントを読者に紹介しようとしました。 このパートでは、インタラクションインターフェイスとファクトリー機能の概要を示します。
Big Cloud Fabricインターフェース
前の部分で述べたように、ファクトリーコントローラーは、制御、分析、外部システムとの統合の単一ポイントです。 フル機能のCLIと非常に便利なWebベースのインターフェースの両方が設定、監視、トラブルシューティングに利用できるという事実にもかかわらず、それらは本質的に単一のREST APIのクライアントです。 多くのメーカーは、製品とやり取りするためのRESTインターフェイスを提供していますが、ネットワークデバイスの世界では、CLI / WEBよりも機能性が低いことが多く、すべての機能やメカニズムへのアクセスを提供していないため、使用の可能性が大幅に制限されています。 同様に、BCFで選択されたアプローチは、機能の損失を完全に排除します。CLIまたはWebインターフェースで実行できるすべてが、REST APIを使用した実装に利用可能です。 さらに、REST APIを使用するプロセス自体は可能な限り便利で簡単になります。CLIにdebug restコマンドを入力するだけで、CLIに入力された各コマンドに対して、リクエストのメソッド、パス、本文、およびレスポンスのコードと本文が表示されます。 したがって、ルーチンプロセスを自動化するスクリプトを記述するために、ドキュメント（これも存在します）に座る必要はもうありません。CLIで必要な操作を一度実行し、結論に基づいてテンプレートを描画するだけで十分です。
Webベースの管理インターフェイスについても言及したいと思います。 ネットワークの世界では、CLIコンソールが設定、トラブルシューティングに最も便利なツールであると考えられています。 これは、一般的に受け入れられているAPIが登場し、機器でスクリプトを直接実行する前に、CLIが日常的な操作を自動化する大きな機会を提供し、多くの場合Webインターフェイスよりもはるかに有益だったという事実によるものです。 ただし、BCFコントローラーでは、Webインターフェイスが非常に便利で理解しやすく機能的であるため、テスト中、エンジニアは実質的にCLIサービスに頼ることはありませんでした。すべての設定と診断情報は便利で直感的なグラフィカルインターフェイスで利用できました。 優れたエルゴノミクスと理解可能な論理構造に加えて、Webインターフェースには、一見取るに足りないように見えるが非常に有用な多くの詳細が含まれており、これらを使用することで満足感を得ることができます。 たとえば、スイッチを追加するときは、アーキテクチャでどのロールを使用するか（スパインまたはリーフ）を選択する必要があります。 ただし、これらの単語のいずれかがスイッチに割り当てられた名前に含まれている場合、役割は自動的に提供されます。 些細なことですが、素晴らしい。
GUIホームページのスクリーンショット（クリック可能な画像）
Big Cloud Fabricの機能
ラボでBCFのテストを開始したとき、実際の経験に基づいた方法論が準備されました。 かなり若い製品が同じ機能を持ち、通信市場の昔の人と同様のメカニズムとプロトコルのセットをサポートするかどうかはわからなかったため、データセンターでの使用が保証されている機能とメカニズムが含まれていました。 ただし、すでにBCFのドキュメントを調査する最初の段階では、テストされた関数の量を大幅に増やす必要がありました。すべての関数が非常に興味深く需要があったからです。 しかし、私たちが最も感銘を受けたのは、宣言されたすべての関数が時計のように機能したことです。単一のテストが失敗したり、コメントを使用して機能したことはありません。 一般に、BCFで作業する感覚は、「迅速、簡単、便利」と簡単に説明できます。
BCFの論理構造は、ネットワークスペシャリストが完全に理解できる要素で構成されています。これにより、BCFは他のメーカーの同様のソリューションと区別されます。 BCFの論理構造の構造単位はテナントです。これは実際には古典的なVRFです。 テナントでは、ブロードキャストセグメントとそのルーティングインターフェイスが配置され、それらの間の通信はシステムルーター（システムテナント）を介して実行されます。 セグメントには、エンドの物理ホストまたは仮想ホストが含まれます。 外部デバイスとのペアリングは、静的ルーティングとBGPプロトコルの両方を使用して編成できます。 ただし、論理構造のこのような単純さの背後には、機能と柔軟性が開発されています。
Big Cloud Fabricロジック（クリック可能な画像）
クラシックスイッチとは異なり、異なるVLAN IDのパケットを送信するサーバーは、同じブロードキャストセグメントのメンバーになることができ、同時に同じVLAN IDを異なるセグメントに割り当てることができます。 メインゲートウェイのバックアッププロトコルを使用する必要はありません;実際、この機能を実装するデバイスはありません。 ファクトリスイッチはヘッダーを上書きし、パケットを別のサブネットに転送できます。 作成されたアクセスポリシーとサービスチェーン（ACL、ポリシーベースルーティング）は、特定のスイッチまたはインターフェイスではなく、上位の論理構造に関連付けられているため、ファクトリ全体で機能します。
シンプルなツールがBCFであると同時に、ファクトリのマルチキャストトラフィックの切り替えとルーティングは、テナントの設定の[ マルチキャスト有効化]スライダーを切り替えるだけで構成されているという事実から判断することもできます。選択されたテナント内のサブネット、および各テナントは、不正なパケット送信のリスクなしに同じマルチキャストグループのセットで動作できます。 これを、従来の大規模なデータセンターネットワーク（PIM、IGMP、IGMPスヌーピング）でのマルチキャストルーティングのセットアップと比較してください。これはすべてのデバイスにあります。
このように、技術仕様にはおなじみのプロトコルが記載されていませんが、BCFの中央集中型アーキテクチャにより、データセンターネットワークに必要な機能を実装できるだけでなく、大幅に拡張できます。 これは、監視、トラブルシューティング、および分析に関しては特に顕著です。 ファブリックSPANメカニズムを使用すると、L2〜L4パラメータでフィルタリングされた工場全体のトラフィックを任意のスイッチの任意のポートにミラーリングできます。 たとえば、すべてのファクトリHTTPトラフィックを分析ツールにミラーリングするタスクは、約2分で単一のFabric SPANポリシーを作成することで達成されます。 従来のデータセンターネットワークでは、この問題を解決するにはかなり長い時間がかかるだけでなく、追加の機器を使用する必要があります。
別のかなり一般的な状況は、特定のプロトコルを使用する2つのサーバー間に接続がないことです。 この場合、従来のネットワークでは、ping、traceroute、telnet、ルーティングテーブルの分析、ITUアクセスリストなどのアクティブなトラブルシューティングが開始されます-ボックスごと、コンソールごと。 BCFでは、パスのテストツールを実行するだけで同様のタスクが解決されます。送信元と宛先のアドレス、プロトコル、ポートを指定するだけで十分です。コントローラーは、トラフィックのパス、問題のポイント、説明（ある場合）をグラフィック形式で表示します。 同時に、ツールには2つの動作モードがあります。最初の結果は、コントローラーが構築してスイッチにアップロードしたテーブルの分析に基づいており、2番目は、各スイッチで必要なパケットがどのように処理されているかを確認し、このようにしてトラフィックの動きの実際の画像が取得されます。 原則として、テストパスツールを使用したトラブルシューティングプロセスは1分以内で完了し、単一のグラフィカルインターフェイスから実行されます。
テストパスツールのスクリーンショット（クリック可能な画像）
それとは別に、分析情報を収集、処理、提供する工場の能力についてお話したいと思います。 繰り返しますが、集中化されたコントロールプレーンを備えたBCFアーキテクチャのおかげで、コントローラーは、スイッチ、インターフェイスカウンター、エラー、ログなどのハードウェアの状態に関する「生の」データを収集する単一のポイントです。 コントローラは、受信した情報を処理し、イベントを相互に関連付け、履歴を保存し、便利でカスタマイズ可能な形式で結果を提示します。 分析は、物理インフラストラクチャで発生するイベント（ポートの問題、ハードウェアの問題、高負荷インターフェイスなど）、および論理構造イベント（仮想マシンのオン/オフ/移動、ホスト/セグメント間のトラフィック強度など）として利用できます。 ） 実際、データセンターのネットワークインフラストラクチャと共に、ログ収集および分析サーバーとデータベースに追加投資することなく、強力な分析システムを取得します。
Big Cloud Fabric分析システムのスクリーンショット（クリック可能な画像）