UCloud の大規模データセンター ネットワーク管理システム構築への道

大規模データセンターにおけるネットワーク構成の自動配布、運用・保守効率の向上、ハイブリッドクラウドネットワークのリアルタイム接続などのニーズに応えるため、UCloudチームは物理ネットワークオーケストレーター（以下、オーケストレーター）を開発し、リリースしました。これは、ネットワーク運用および保守の自動化を構築するための基本的なアプリケーション システムであり、ネットワーク運用および保守担当者にシンプルで使いやすいネットワーク機器構成ツールを提供し、面倒なスイッチ コマンドの作成から解放し、十分な精度、安定性、セキュリティを備えています。

このシステムにより、データセンター構築時の数万のIDCのネットワーク構築期間が2～3日から2～3時間に短縮され、オンライン成功率も80％から99％に向上しました。このシステムは導入以来、3,000 台以上のスイッチにサービスを提供し、100 を超えるオペレータ専用回線を維持してきました。搭載するネットワークアクセススループットは200Gに達し、DCI（データセンター内部相互接続）スループットは2Tに近く、ユーザーコンソールのネットワーク（物理配線を除く）上でリアルタイムにハイブリッドクラウドサービスをサポートできます。

難易度分析

従来のネットワーク展開は、主に手動構成によって実現されます。ネットワークが一定の規模に達すると、手動構成方法は非効率になり、構成コマンドの数が多くなるとオンライン エラー率が簡単に高くなる可能性があります。会社の現状を考慮し、業界内のオープンソース構成配信ソリューションを分析した結果、NAPALM (Python モジュール) を使用した Python ベースのビジネス構成配信システムを構築することを決定しました。このシステムの内部コードネームは XUANWU (中国語: Xuanwu) です。

NAPALM モジュールの基盤となる構成配布システム (Ansible、Paramiko、Salt など) は汎用的ですが、現在のところ、対応するライブラリをサポートしているのは主流のメーカーのみです。一部の第2層ブランドメーカーは完全なサポートを提供しておらず、独自のサポートを開発する必要があります。メーカーが、豊富で標準的な構成および配信 API を提供することを期待するのは現実的ではありません。業務に応じて、UCloudに適した構成と配信システムを開発する必要があります。

分析の結果、ビジネスベースのネットワーク オーケストレーターを開発するには、次の障害を解決する必要があることがわかりました。

1. 同じ基礎レイヤーに対して、異なる機器メーカーが異なる構成コマンドを提供します。たとえば、同じ要件で静的ルートを作成する場合、Ruijie のコマンドは「ip route 0.0.0.0 0.0.0.0 1.1.1.1」ですが、Huawei のコマンドは「ip route-static 0.0.0.0 0.0.0.0 1.1.1.1」です。

2. 同じデバイスモデルでも、ソフトウェアのバージョンが異なるため、同じ機能を実現するためのコマンドの組み合わせは異なります。たとえば、Huawei の CE6851-48S6Q-HI デバイスもトンネル作成機能を実装しています。バージョンが V1R2 以下の場合、トンネル ポートをアクティブ化するには、service_type が tunnel である集約ポートにバインドする必要があります。それ以降のバージョンでは、バインドは必要ありません。

3. 異なるメーカーの機器には、同じ要件を満たすための異なる構成モードがあります。たとえば、スイッチの物理ポートが特定の集約ポート設定要件に含まれている場合、Huawei は物理ポートを抽象化された集約ポートにバインドするだけで集約ポートのすべてのプロパティを継承できますが、H3C は物理ポートの下で集約ポートのプロパティを再度設定する必要があります。

4. …

あらゆる体型や規模の人が解決できるこれらの問題は、自動化を困難にします。ネットワーク構成の自動化を実現するためには、まずこれらの問題を具体的なシナリオにまとめ、抽象化し、グレーディングや分類によって差異を回避する必要があります。

オーケストレーターアーキテクチャとビジネスモデル構築

多くの社内討議と要約を経て、実際のビジネスがネットワークに求めるのは特定のシナリオであり、それが実際に特定のニーズを満たすことができることがわかりました。たとえば、ビジネス要件としてホスティングからパブリック クラウドへのルートを開くことが必要な場合、ネットワークが実際に実装するのは静的ルートの配信であり、静的ルートの配信が構成シナリオになります。

ここで、シナリオではデバイスの製造元を考慮していないため、次の 2 つの問題が発生することに注意することが重要です。1. 構成コマンドの違い。 2. 設定モードの違い。これら 2 つのレイヤーを抽象化する必要があります。テストと抽象化を行った後、ビジネス モデル用のネットワーク構成配布システムを設計しました。

• ステップ 1: アトミック コマンド クラスを構築します。アトミック コマンドのクラスは、製造元、デバイス モデル、モデル バージョン、バージョン パッチで構成されます。このクラスのアトミック コマンドはエントリ テンプレートです。
• ステップ 2: アトミック コマンドを入力します。まず機能を入力し、次にその機能に対応する元のデバイス コマンドを入力します。
• ステップ 3: テンプレートを作成します。 1 つ以上のアトミック コマンドをドラッグ アンド ドロップして、ビジネス ニーズを満たすテンプレートを構築します。
• ステップ 4: API を作成します。テンプレートに対応する KEY 値を作成し、API の形式でビジネスから柔軟に呼び出せるようにします。

具体的な API 作成プロセスを例にとると、まずデバイスのソフトウェア バージョンとハードウェア バージョンを入力し、ソフトウェアとハ​​ードウェアを 1 つのユニットに結合し、アトミック コマンド仕様に従って GROUP グループのレイヤーを抽象化します。各グループはアトミック コマンド エントリ標準であり、コマンド機能に応じて 1 つ以上のアトミック コマンドを関連付けます。

具体的な構成関係図は以下のとおりです。

図3: API-シナリオ-テンプレート-コマンド機能対応表

シナリオに関係するコマンド関数が作成されると、フロントエンド オーケストレーションを通じてテンプレートが作成され、実際の属性に基づいてフィールドが自動的に生成されます。 KV API モデルは基本的に完成しています。ただし、現時点での作成は、特定のデバイス タイプのシーンにのみ関連付けることができます。他のシーンに他のデバイスがある場合、API は有効になりません。そのため、GROUP グループに関連付けられた複数のシーンを大きなシーングループに追加し、大きな API の形で公開することも必要です。この時点で、API は複数のメーカーの構成コマンドと互換性を持つことができます。

設計と最適化の実践

既存のネットワークの特殊性を考慮すると、オーケストレーターには高い精度、安定性、セキュリティが求められます。上記の特性を満たすために、アーキテクチャ設計とコード開発プロセス中に、システム全体で一連のチューニングも実行されました。

1. Kafka に基づくコマンド実行キューの設計

オーケストレーターは、特定のビジネス アプリケーション シナリオ (以下、シナリオと呼びます) に従って、会社のすべてのアクティブなコンピュータ ルームにスイッチ構成コマンドを発行する必要があります。 IDC ルームを空間次元、構成コマンドの実行順序を時間次元と見なすと、各シナリオの実行は、空間次元と時間次元の両方を考慮して、タイミングの点で適切に制御される必要があります。

設定指示の正確な実行を保証するために、Kafka をベースにしたコマンド実行キュー設計を採用しました。 Kafka メッセージ キューのトピック分類特性とメッセージ キューの生成および消費特性により、命令配信キュー モジュールのタイミング制御要件を適切に考慮できます。トピック分類機能は、IDC コンピュータ ルームの空間次元を処理するために使用でき、メッセージ キューの生成と消費機能は、命令実行の時間次元に対応します。

実際のアプリケーションでは、ビジネス シナリオを解析することにより、IDC コンピュータ ルームに応じて対応する Kafka トピックへのスイッチ構成指示が生成されます。同じ IDC コンピュータ ルームの構成手順は、スイッチに基づいて実行順に該当するトピックに生成されます。

Kafka の 2 つの主要機能を活用し、システムのビジネス シナリオ解析ロジックと組み合わせることで、スイッチ構成指示の時間と空間の次元制御を実現し、指示の正確な配信を実現しました。システムが稼働して以来、誤送信や設定指示の誤りは発生していません。

2. クラスター、マスタースレーブ、マスターマスター設計の応用

ネットワーク運用保守自動化の構築のための基本システムとして、今後は機能の一部または全部をより多くの部門に開放していく予定です。したがって、オーケストレーター サービスの安定性は特に重要です。本システムでは、クラスタリングなどの高可用性技術の使用に関するさまざまな側面を考慮し、次のような安定性向上設計計画を策定しています。

1. Zookeeper クラスター (基本操作)

2. Kafka クラスター（基本操作）

3. Kafka コンシューマー クラスター: 各 IDC コンピュータ ルームに Kafka コンシューマー クラスターを展開し、構成指示メッセージの安定した消費と実行を確保します。

4. MySQL データベース 1 つのマスターと 2 つのスレーブ: データベースの読み取りと書き込みが分離されており、マスター データベースは書き込み操作のみを受け入れ、スレーブ データベースは読み取り操作のみを受け入れるため、マスター データベースの負荷が軽減され、データベース サービスの安定性が向上します。

5. Web サーバー マスター マスター: 2 つの Web バックエンド サーバーを提供し、Nginx プロキシを介して負荷分散を実装し、データベースのデュアル バックアップ設計を組み合わせて、API 要求とデータベース読み取り操作のバランスの取れた分散を実現します。

クラスタリング、マスタースレーブ、マスターマスター設計により、オーケストレーターが提供する Web サービスの安定性が向上し、構成指示メッセージ キューの信頼性が向上しました。システムの運用開始以来、Web サーバーやメッセージ キューのダウンによるサービス停止は発生していません。

3. 権限設計

このシステムでは、既存のネットワーク スイッチに変更を加える必要があります。各ビジネスシナリオの実行は既存のネットワークに影響を与えるため、適切な権限管理も非常に重要です。システムは、オペレーターの権限を 2 つのレベルで制限し、バックエンド トークン認証を有効にします。

1. API 権限: データベースの追加、削除、変更、クエリ、およびビジネス シナリオでの操作の発行 (ロールバック) が含まれ、1 対 1 の API 権限分割によって管理されます。

2. メニュー権限：メニューレベルでのUIインターフェース操作に関与し、フロントエンド操作ページでメニュー項目の権限を分割して管理します。

3. トークン認証: バックエンドが API を呼び出すときにトークン認証が実行されます。トークンはオペレータに一つずつ対応しており、そのオペレータに責任が割り当てられます。

権限認証により、ユーザーの操作習慣を標準化し、セキュリティ意識を強化し、最終的にはシステム全体のセキュリティを向上させることができます。

4. コマンド発行後のリアルタイムフィードバック

従来の手動設定モードでは、各ネットワーク運用保守エンジニアが対応するスイッチにログインして設定指示を発行し、スイッチのエコー情報を観察してコマンド実行結果を確認する必要がありました。このプロセスを再現し、よりわかりやすい情報プロンプトを提供するために、システムはコマンド実行結果のリアルタイム表示機能を統合し、ネットワーク運用保守エンジニアが参照して決定を下すために実行結果の詳細な情報クエリを提供します。

具体的な実装方法は、ビジネス シナリオの実行中に、システムがオーケストレーターのフロントエンド インターフェイスに実行結果情報を表示する 2 つの方法を提供します。

1. 実行ステータス: 各命令の実行ステータスは、発行成功、発行失敗、ロールバック中、ロールバック成功、ロールバック失敗、ログイン失敗の 6 種類に分かれています。ビジネス シナリオの発行プロセス中に、さまざまな境界線の色でリアルタイムに表示されます。

2. コマンド実行エコー情報: ほとんどのコマンドが実行されると、スイッチにエコー情報プロンプトが表示されます。システムはスイッチエコー情報を自動的にキャプチャし、それをフロントエンドにフィードバックして、オペレータに参照情報を提供します。

このようなグラフィックカラーとエコー情報表示は、構成指示の実行効果に関するリアルタイムのフィードバックを提供し、ネットワーク運用および保守エンジニアに参考資料を提供し、自動化レベルを向上させながら操作フィードバックエクスペリエンスを向上させることができます。

5. アトミックコマンドライブラリの構築

同社のスイッチには主にHW、H3C、RUIJIEの3つのブランドがあります。異なるブランドのスイッチ間では設定手順に大きな違いがあります。同時に、各ブランドのスイッチはいくつかのモデルに分けられ、異なるモデル間の一部のコマンドにも一定の違いがあります。

会社で使用されているすべてのスイッチとの互換性を確保するには、すべてのスイッチ モデルを統一的に管理する必要があり、分類された管理を確実にするために、異なるスイッチ モデルに応じて構成指示を入力する必要があります。上記の背景と要件に基づいて、システムは次のサブライブラリを含むアトミック コマンド ライブラリを構築しました。

• a.スイッチ機器ライブラリ: 会社が使用するすべてのスイッチは、メーカー、モデル、バージョン、パッチ別に分類され、整理されています。
• b.スイッチデバイスグループライブラリ：スイッチデバイスライブラリに基づいてグループ化が実行され、同じ構成指示を持つデバイスが同じグループに分割されます。
• 紀元前アトミック コマンド ライブラリ: アトミック コマンドはスイッチ デバイス グループに基づいて入力され、アトミック コマンド機能のディメンションに基づいて分類されます。
• d.アトミック コマンド関数テンプレート ライブラリ: スイッチ コマンドを入力するために使用される関数テンプレート。
• e.アトミック コマンド パラメータ テンプレート ライブラリ: スイッチ コマンドのさまざまなパラメータ テンプレートを入力するために使用されます。

アトミック コマンド ライブラリを確立することで、社内で使用されているすべてのスイッチと、それらに適用される構成手順を統一的に分類して管理できるようになります。スイッチ グループの設計により、同じ構成手順を持つスイッチを同じグループにまとめることができます。同じグループ内のデバイスはアトミック コマンドを共有するため、アトミック コマンドを入力する作業負荷が大幅に軽減されます。さらに、アトミックコマンド機能とパラメータテンプレートライブラリを確立することで、アトミックコマンドの入力方法を標準化し、ビジネスシナリオオーケストレーションの強固な基盤を築くことができます。

6. APIのオープン性と二次開発

このシステムは、アトミック粒度のスイッチ操作 API を提供しており、既存のネットワーク運用および保守操作をサポートするだけでなく、関連する二次システム開発をサポートするための外部呼び出しコンポーネントとしても使用できます。同時に、統一され細かく分類されたAPIエントリを提供することで、既存のネットワークスイッチ操作の集中管理が可能になり、既存ネットワークのセキュリティが向上します。現在、Panguシステム（UCloudサーバー自動配信システム）やUXRプロジェクト向けの基盤呼び出しAPIを提供し、システム開発や関連する業務運営をサポートしています。

やっと

共同デバッグとテストを行った後、システムを複数のビジネス シナリオに適用しましたが、すべて良好なパフォーマンスが得られました。ネットワーク自動オーケストレーションシステムにより、データセンター構築事業において数万のIDCのネットワーク構築サイクルを数日から数時間へと短縮しました。さらに、オンラインでの成功率も当初の80％から99％に向上しました。ハイブリッドクラウドビジネス接続では、ユーザーのコンソール操作（物理的な配線を除く）を通じて、仮想ネットワークのビジネスロジックもリアルタイムに接続できます。