パート1。始まり

1.1はじめにと問題の説明

MTSでは、データ伝送ネットワーク、またはより簡単に言えば、トランスポートネットワーク（ロジスティクストランスポートネットワークと混同しないでください）（以下、TSと呼びます）の品質を一元管理します。そして、私たちの活動の枠組みの中で、私たちは常に2つの主要なタスクを解決する必要があります。

1. （車両に関連する）クライアントサービスの劣化が検出されました-車両を介した接続のパスを特定し、車両のいずれかの部分がサービスの劣化の原因であるかどうかを確認する必要があります。さらに、これを直接問題と呼びます。
2. トランスポートチャネルまたはチャネルシーケンスの品質の低下が検出されました。影響を判断するには、このチャネルに依存しているサービスを特定する必要があります。さらに、これを逆問題と呼びます。

TSサービスは、クライアント機器の接続として理解されます。これらは、ベースステーション（BS）、B2Bクライアント（インターネットおよび/またはオーバーレイVPNネットワークへのアクセスを整理するためにMTS TSを使用）、固定アクセスクライアント（いわゆるブロードバンドアクセス）などです。等



2つの集中型情報システムを自由に利用できます。



トランスポートネットワークは本質的に有向グラフです $$$G=(V,E)$、ここで各エッジ$$$(u,v) in E$負でない容量を有します。したがって、当初から、これらの問題の解決策の探索は、グラフ理論の枠組みの中で行われていました。



まず、TSとサービスの品質指標をTSトポロジと比較する問題は、トポロジと品質データを文字通り組み合わせてネットワークグラフの形式で表示することで解決されました。



トポロジとパフォーマンスデータに従って形成されたグラフのビューは、オープンソースのGephiソフトウェアを使用して実装されました。これにより、トポロジの更新を手動で行うことなく、トポロジの自動表現の問題を解決することができました。次のようになります。





ここで、ノードは実際にはTSのノード（ルーター、スイッチ）であり、基本的なノードであり、エッジはTSのチャネルです。色分けは、それぞれ、品質劣化の存在とこれらの劣化の処理ステータスを示します。



それは非常に明確であり、あなたは働くことができるように思われるでしょう、しかし：

• 直接的な問題（サービスからサービスパスへ）は、TSトポロジ自体が非常に単純である場合にのみ、非常に正確に解決できます。ツリーまたは単なるシリアル接続であり、リングや代替ルートはありません。
• 逆の問題も同様の条件で解決できますが、同時に、集約とネットワークコアのレベルでは、原則としてこの問題を解決することは不可能です。これらのセグメントは動的ルーティングプロトコルによって管理され、多くの潜在的な代替ルートがあります。

また、一般に、ネットワークトポロジははるかに複雑であることに注意してください（上記のフラグメントは赤で囲まれています）。





そして、これは最小のセグメントではありません-トポロジーにはますます複雑になっています：





したがって、このオプションは、個々のケースの瞑想的な分析には適していましたが、フロー作業には適していませんでした。さらに、直接および逆のソリューションの自動化には適していませんでした。

---

パート2。自動化v1.0

私たちが解決したタスクを思い出させてください。

1. 車両を介したサービスのパスの決定-直接タスク。
2. TCチャネルからの依存サービスの決定-逆の問題。

2.1。基地局（BS）の輸送サービス

一般に、中央ノード（コントローラー/ゲートウェイ）からBSへのトランスポートの構成は次のようになります。





アグリゲーションのセグメントとTSのコアでは、接続はMPLSネットワークのトランスポートサービス（L2 / L3 VPN、VLL）を介して行われます。アクセスセグメントでは、接続は原則として専用VLANを介して実行されます。



車両のすべての実際の（特定の期間内の）パラメーターとトポロジーが存在するデータベースがあることを思い出させてください。

2.2。ダイヤルアップセグメントソリューション（アクセス）

BS論理インターフェースのVLANに関するデータを取得し、境界ルーター（MBN）に到達するまで、ポートにこのVlanIDが含まれているリンクを段階的に「通過」します。





このような単純な問題ステートメントを解決するには、次のことを行う必要がありました。

1. BSからアグリゲーションネットワークのチャネルを介したVlanIDの「伝播」を段階的に追跡するためのアルゴリズムを記述します。
2. 既存のデータギャップを考慮してください。これは、サイト上のノード間のジョイントに特に当てはまりました。
3. 実際、MVNルーターにつながらない行き止まりの分岐を最後にドロップするためにSPFアルゴリズムを記述します。

アルゴリズムは、1つのメインプロセスと7つのサブプロセスから生まれました。それを実装してデバッグするのに3-4週間の純粋な作業時間がかかりました。



また、特に嬉しかったです...

2.2.1。SQL JOIN

その構造のおかげで、グラフをトラバースするためのリレーショナルモデルでは、同じレコードセットを繰り返しトラバースしながら、各レベルで結合操作を使用する明示的な再帰的アプローチが必要です。これにより、特に大規模なデータセットでは、システムパフォーマンスが低下します。



明らかな理由で、ここでデータベースへのクエリの内容を引用することはできませんが、評価します-クエリテキストの各「棚」は次のテーブルの接続であり、この場合、PortとVlanIDの間の統一された対応を取得するために必要です。





そして、この要求は、スイッチ内のVlanID相互接続を統一された形式で取得するためのものです。





ポートの数が数万であり、VLANが10倍であることを考えると、これはすべて、投げたり回したりすることに非常に消極的でした。そして、そのような要求は、ノードとVlanIDごとに行う必要がありました。そして、「すべてを一度にアンロードして計算する」ことは不可能です。これは、前のステップの結果に依存する段階的な操作によるパスcの順次計算です。

2.3。ルーティングされたセグメントのサービスパスの決定

ここでは、管理システムがMPLSセグメントを介して現在およびスタンバイLSPに関するデータを提供する1つのMVNベンダーから始めました。アクセスに接続されたアクセスインターフェイス（L2 Vlan）を知っていると、LSPを見つけて、NBIシステムへの一連の要求を通じて、ルーターとそれらの間のリンクで構成されるLSPパスを取得することができました。

• スイッチドセグメントと同様に、MPLSサービスのLSPパスをアンロードするという記述は、すでに17のサブルーチンを持つアルゴリズムをもたらしました。
• このソリューションは、このベンダーが提供するセグメントでのみ機能しました
• MPLSサービス間のジョイントの定義を決定する必要がありました（たとえば、セグメントの中央に一般的なVPLSサービスがあり、EPIPEまたはL3VPNのいずれかがそれから分岐していました）

また、制御システムがない、または原則として現在のLSP通過に関するデータを提供していない、他のMVNベンダーの問題にも取り組みました。いくつかの解決策を見つけましたが、ルーターを通過するLSPの数は、スイッチに登録されているVanIDの数ではなくなりました。このような大量のデータを「オンデマンド」で遅延させる（結局のところ、運用情報が必要です）-ハードウェアをダウンさせるリスクがあります。



さらに、追加の質問が発生しました。

• – , , . .. – MPLS .
• , LSP, . . .

2.4. .

サービス接続のパスに関する受信データは、後で直接および逆の問題を解決するときに参照できるように、どこかに書き留めておく必要があります。



リレーショナルデータベースに保存するオプションはすぐに除外されました。多くのソースからのデータを集約して、後で最終的に次のテーブルセットに分類するのは非常に難しいのでしょうか。これは私たちの方法ではありません。さらに、複数階の結合とそのパフォーマンスについて覚えておいてください。



データには、サービスの構造とそのコンポーネント（リンク、ノード、ポートなど）の依存関係に関する情報が含まれている必要があります。



テストソリューションとして、XML形式とNative-XMLDB-Existが選択されました。



その結果、各サービスは次の形式でデータベースに記録されました（コンパクトにするために詳細は省略されています）。

<services>
	<service> 
		<id>,<description>   (,  )
		<source>    
		<target>    Z
		<<segment>>  L2/L3
			<topology>      (, /, )
		<<joints>>    (, /, )
	</service>
</services>

直接および逆の問題のデータクエリは、XPathプロトコルを使用して実行されました。





すべて。これで、システムは機能しています。BSという名前のリクエストの場合、トランスポートネットワークを介した接続のトポロジが返され、TSのノードとポートの名前を持つリクエストの場合、接続に依存しているBSのリストが返されます。したがって、次の結論を出しました...

2.5。

パート2の調査結果に向かう代わりに

2.5.1。スイッチドセグメント（L2イーサネットスイッチ上のネットワーク）の場合

• トポロジとポートに関する完全なデータ-VlanIDの対応が必要です。一部のリンクにVlanIDデータがない場合、アルゴリズムは停止し、パスが見つかりませんでした
• リレーショナルデータベースに対するマルチレベルの非生産的なクエリ。新しいベンダーが独自の詳細、パラメーターで表示される場合-作業のすべての段階でリクエストを追加します

2.5.2。ルーティングされたセグメントの場合

• LSPMPLSサービスのトポロジに関するデータを提供するMVNSUの機能によって制限されます。
• – , .. LSP .
• LSP – ( , “” ).

2.5.3.

• , , , , ( – , ), , – .
• . 3-4 .
• , .. , MPLS .
• – , .

2.6. -

• , , .. – .
• , -
• (, VlanID)

希望を実現するための可能なオプションを評価した後、これらすべてを「箱から出して」提供するシステムのクラスを決定しました。これはいわゆるいわゆるものです。グラフデータベース。



最後の文は直線的で単純なものとして読まれていますが、以前は誰も（そしてITスペシャリストも）そのようなデータベースクラスに遭遇したことがないことを考えると、彼らは偶然に決定に至りました：同様のデータベースが言及されました（しかしビッグデータ概要コースで）を理解していませんでした。特に、製品Neo4jについて言及しました..。説明から判断すると、すべての要件を満たしているだけでなく、完全に無料の機能コミュニティバージョンもあります。それら。-30日間の試用ではなく、主要な機能を切断することはありませんが、ゆっくりと学習できる完全に機能する製品です。選択における最後の（主要ではないにしても）役割は、グラフアルゴリズムの幅広いサポートによって果たされたわけではありません。

---

パート3。Neo4jでの直接問題の実装例

TSモデルがNeo4jグラフデータベースにどのように実装されているかについての線形の説明を引きずり出さないために、例を使用して最終結果をすぐに示します。

3.1。3GBSのIubインターフェイスのパスをトレースする

サービスを接続するパスは、ルーテッドMVNとスイッチドラジオリレーラインの2つのセグメントを通過します（ラジオリレーステーションはイーサネットスイッチとして機能します）。RRLセグメントを通過するパスは、パート2で説明したのと同じ方法で、RRLセグメントに沿ったBSインターフェイスVlanIDがMVNボーダールーターに渡されることによって決定されます。MVNセグメントは、境界（RRLセグメントを含む）ルーターを、BSコントローラー（RNC）が接続されているルーターに接続します。



最初に、Iubパラメーターから、どのMVNがBSのゲートウェイ（境界MVN）であり、どのコントローラーがBSによって処理されるかが正確にわかります。



これらの初期条件に基づいて、セグメントごとにデータベースへの2つのクエリを作成します。データベースへのすべてのクエリはCypher言語で構築されています..。今の説明に気を取られないように、単に「グラフ用のSQL」と考えてください。

3.1.1。RRLセグメント。VlanIDパス

利用可能なVlanIDおよびL2トポロジデータに基づいてサービスパスをトレースするためのサイファー要求：



ご覧のとおり、データが部分的に不足しているにもかかわらず、パスは取得されています。この場合、BSポートと無線中継局のポートとのジャンクションに関する情報はありません。

3.1.2。RRLセグメント。L2トポロジパス

3.1.1項で試行が行われたとしましょう。VlanIDパラメータのデータが完全にまたは部分的に欠落しているために失敗しました。言い換えると、MVNノードに到達するこのような連続チェーンは構築されません。



次に、L2トポロジに従って、サービス接続をMVNへの最短パスとして定義してみます。



ご覧のとおり、同じ結果が得られます。ここで、BSとRRSのジャンクションに関する情報の不足は、それらが配置されているサイトのオブジェクト（ノード）を介して接続を通過させることによって補われます。もちろん、この方法の精度は低くなります。一般に、Vlanは、Dijkstraのアルゴリズムによって提案された最短パスに沿って登録されない場合があります。ただし、リクエストは2つの操作のみで構成されます。

3.1.3MVNセグメント。境界MVNからコントローラーまでのパスをトレースする

ここでは、Dijkstraのアルゴリズムも使用します。



同様に、この場合、MVNとRNCの直接ジョイントに関する情報はありません。ただし、これは、アルゴリズムによって想定されている場合でも、サービスパスの構築を妨げるものではありません（これについては後で詳しく説明します）。

3.2。人件費

現在示されている直接問題の実装は、「アルゴリズム、プログラム、結果を保存および取得する方法を開発する」というアプローチとは著しく異なります。つまり、すべて「データベースにクエリを書き込む」ことになります。今後、単純なグラフモデルの開発から、リレーショナルデータベースからNeo4jへのデータの読み込み、クエリの作成、そして結果が得られるまでのサイクル全体で、合計1日かかることに注意してください。



3〜4か月vs1日!!! これが、グラフデータベースへの最終的な出発の最後の理由でした。

---

パート4。グラフデータベースNeo4jとそれにデータをロードする

4.1。リレーショナルデータベースとグラフデータベースの比較

4.2。データ・モデル

L3トポロジレベルまでのTSプレゼンテーションの基本モデル：





もちろん、このモデルは提示されたモデルよりも広範囲であり、MPLSサービスと仮想インターフェイスも含まれていますが、簡単にするために、その一部を限定的に検討します。



このようなモデルでは、同じ地域の2つのネットワーク要素間の関係は次のように表すことができます。

4.3。データのロード

車両のパラメータとトポロジーのデータベースからデータをロードします。SQLデータベースからNeo4jにロードするには、APOCライブラリ（apoc.load.jdbc）を使用します。これは、RDBMSへの接続文字列とSQLクエリのテキストを入力として受け取り、CYHPER式を介してノード、リンク、またはパラメータにマップされる文字列のセットを返します。このような操作は、モデルオブジェクトのタイプごとにレイヤーごとに実行されます。



たとえば、ネットワーク要素（ノード）を表すノードをロード/更新するためのパス：



など-TSモデルのすべてのレベルにわたって。



[更新済み]フィールドは、列内のデータの関連性を制御するために使用されます。特定の期間より長く更新されないオブジェクトは削除されます。

---

パート5。Neo4jの逆の問題を解決する

私たちが最初に始めたとき、「サービストレース」という表現は、主に次の関連付けをもたらしました。





つまり、サービスの現在のパスが特定の時間に直接トレースされます。



これは、グラフデータベースにあるものとまったく同じではありません。GDBでは、関連する各ネットワーク要素での構成 を決定するオブジェクトの関係に従って、サービスがトレースされます。つまり、構成はグラフモデルの形式で表され、結果のトレースはこの構成を表すモデルを通過します。



スイッチドセグメントとは異なり、mplsセグメントの実際のサービスルートは動的プロトコルによって決定されるため、いくつかを受け入れる必要がありました...

5.1。ルーテッドセグメントの前提条件

なぜならmplsサービスの構成データから、動的ルーティングプロトコルによって制御されるセグメントを通る正確なパスを決定する方法はありません（特にTraffic Engineeringが使用されている場合）-ソリューションにはDijkstraアルゴリズムが使用されます。

はい、NBIインターフェースを介して実際のサービスLSPのパスを提供できる管理システムがありますが、これまでのところ、そのようなベンダーは1つしかなく、MVNセグメントには複数のベンダーがあります。



はい、AS内のルーティングプロトコルを分析するためのシステムがあります。これは、IGPプロトコルの交換をリッスンすることにより、対象のプレフィックスの現在のルートを判別できます。しかし、ダウンしたボーイングのようなシステムがあり、そのようなシステムを同じモバイルバックホールのすべてのASに展開する必要があることを考えると、ソリューションのコストは、すべてのライセンスとともに、完全に燃料を補給したときにアンガラロケットに接続された鋳鉄製の橋によって撃墜されたボーイングのコストになります。そしてこれは、そのようなシステムが、BGPを使用して複数のASを通るルートを説明する問題を完全に解決しないという事実にもかかわらずです。



したがって、これまでのところ。もちろん、標準のDijkstraのアルゴリズムの条件にいくつかの小道具を追加しました。

• インターフェイス/ポートのステータスの説明。切断されたリンクはコストが増加し、可能なパスオプションの最後に移動します。
• バックアップリンクステータスの説明。パフォーマンス監視システムによれば、mplsチャネル内のキープアライブトラフィックのみの存在がそれぞれ計算され、そのようなチャネルのコストも増加します。

5.2。Neo4jの逆問題を解決する方法

リマインダー。逆のタスクは、トランスポートネットワーク（TS）の特定のチャネルまたはノードに依存するサービスのリストを取得することです。

5.2.1。切り替えられたL2セグメント

サービスパスとサービス構成が実質的に同じであるスイッチドセグメントの場合でも、CYPHER要求によって問題を解決できます。たとえば、3.1.1項の直接問題を解決した結果からの無線リレーフライトの場合、無線リレーリンクモデムから要求を行います。これを通過するすべてのVlanチェーンを「拡張」します。

match (tn:node {name:'RRN_29_XXXX_1'})-->(tn_port:port {name:'Modem-1'})-->(tn_vlan:vlan)
with tn, tn_vlan, tn_port
call apoc.path.spanningTree(tn_vlan,{relationshipFilter:"ptp_vlan>|v_ptp_vlan>", maxLevel:20}) yield path as pp
with tn_vlan,pp,nodes(pp)[-1] as last_node, tn_port
	match (last_node)-[:vlan]->(:port)-->(n:node)
	return pp, n, tn_port

赤いノードは、Vlanを展開しているモデムを示しています。3つのBSが丸で囲まれ、その結果、Modem1を使用したトランジットVlanの展開が主導されました。





このアプローチにはいくつかの問題があります。

• 構成されたVlanは、ポートについて認識され、モデルにロードされている必要があります。
• 断片化の可能性があるため、Vlanチェーンは常にターミナルノードに出力されるとは限りません。
• Vlanチェーンの最後のノードがターミナルノードに属しているのか、それともサービスが実際に続行されているのかを判断することはできません。

つまり、任意の「中間」から、および1つのOSIレイヤーからではなく、エンドノード/セグメントのポイント間でサービスをトレースする方が常に便利です。

5.2.2。ルーティングされたセグメント

ルーテッドセグメントでは、5.1節ですでに説明したように、選択する必要はありません。中間MPLSリンクの現在の構成のデータに基づいて逆の問題を解決する手段はありません。構成はサービストレースを明示的に定義しません。

5.3。決定

決定は以下のように行われました。

• BSとコントローラーを含む車両モデルのフルロードが実行されます
• すべてのBSについて、直接的な問題が解決されます。つまり、BSから境界MVNへ、次に境界MVNから対応するコントローラーまたはゲートウェイへのIub、S1サービスのトレースです。
• トレース結果は、次の形式で通常のSQLデータベースに書き込まれます。BS名-サービスパス要素の配列

したがって、ノードTSまたはノードTS +ポートの条件でデータベースにアクセスすると、サービスのリスト（BS）が返され、そのパス配列には必要なノードまたはノード+ポートが含まれます。

---

パート6。結果と結論

6.1。結果

その結果、システムは次のように機能します。





現時点では、直接的な問題を解決するために、すなわち 個々のサービスの劣化の原因を分析する際に、Neo4jからのトレース結果（パス）を、パスの個々のセクションの品質とパフォーマンスに関するデータを重ね合わせて表示するWebアプリケーションが開発されました。





TSのノードまたはチャネルに依存するサービスのリストを取得するために（逆問題の解決）、外部システム（特にRemedy）用にAPIが開発されました。

6.2。結論

• どちらのソリューションも、サービス品質とトランスポートネットワークの分析の自動化を質的に新しいレベルに引き上げました。
• さらに、BSサービスのルートに関する既製のデータが存在する場合、ルートの容量と品質の観点から、特定のサイトにB2B顧客を含めることの技術的可能性に関するデータをビジネスユニットに迅速に提供することが可能になりました。
• Neo4jは、ネットワークグラフの問題を解決するための非常に強力なツールであることが証明されています。このソリューションは十分に文書化されており、さまざまな開発者コミュニティで幅広くサポートされており、絶えず開発および改善されています。

6.3。予定

計画があります：

• Neo4jデータベースでモデル化された技術セグメントの拡張
• ブロードバンドサービスのトレースアルゴリズムの開発と実装
• サーバープラットフォームのパフォーマンスの向上

清聴ありがとうございました！