الجزء 1. البداية

1.1 مقدمة وبيان المشكلة

في MTS ، نتحكم مركزيًا في جودة شبكات نقل البيانات أو ، بشكل أكثر بساطة ، شبكة النقل (يجب عدم الخلط بينها وبين شبكة النقل اللوجيستي) ، المشار إليها فيما يلي باسم TS. وفي إطار نشاطنا ، يتعين علينا باستمرار حل مهمتين رئيسيتين:

تم الكشف عن تدهور خدمات العملاء (فيما يتعلق بخدمات النقل الجوي) - من الضروري تحديد مسار اتصالهم عبر TS ، ومعرفة ما إذا كان سبب تدهور الخدمات هو أي جزء من TS. علاوة على ذلك ، سوف نسمي هذه المشكلة المباشرة.
يتم الكشف عن تدهور جودة قناة النقل أو تسلسل القناة - من الضروري تحديد الخدمات التي تعتمد على هذه القناة / القنوات لتحديد التأثير. علاوة على ذلك ، سوف نسمي هذه المشكلة المعكوسة.

تُفهم خدمات TS على أنها أي توصيل لمعدات العميل. يمكن أن تكون هذه محطات قاعدة (BS) ، وعملاء B2B (باستخدام MTS TS لتنظيم الوصول إلى الإنترنت و / أو شبكات VPN المتراكبة) ، وعملاء الوصول الثابت (ما يسمى بالوصول واسع النطاق) ، إلخ. إلخ

لدينا نظامان مركزيان للمعلومات:

نظام مراقبة الأداء	معلمات الشبكة وبيانات الهيكل

المقاييس ، KPI TS	معلمات التكوين ، قنوات L2 / L3

أي شبكة نقل هي في جوهرها رسم بياني موجه

G = (V, E)

$G=(V,E)$ فيها كل حافة

(u, v) i n E

$(u,v) in E$ عرض النطاق الترددي غير سالب. لذلك ، منذ البداية ، تم البحث عن حلول لهذه المشاكل في إطار نظرية الرسم البياني.

أولاً ، تم حل مسألة مقارنة مؤشرات الجودة لـ TS والخدمات مع طوبولوجيا TS من خلال الجمع بين بيانات الهيكل والجودة وتقديمها في شكل رسم بياني للشبكة.

تم تنفيذ عرض الرسم البياني الذي تم تكوينه وفقًا لبيانات الهيكل والأداء باستخدام برنامج Gephi مفتوح المصدر . هذا جعل من الممكن حل مشكلة التمثيل التلقائي للطوبولوجيا ، دون عمل يدوي على تحديثها. تبدو هكذا:

هنا ، العقد هي ، في الواقع ، عقد TS (أجهزة التوجيه ، المفاتيح) والعقد الأساسية ، الحواف هي قنوات TS. يشير الترميز اللوني ، على التوالي ، إلى وجود تدهور في الجودة وحالة معالجة هذه التدهورات.

يبدو أنه واضح تمامًا ويمكنك العمل ، لكن:

يمكن حل المشكلة المباشرة (من الخدمة إلى مسار الخدمة) بدقة تامة فقط بشرط أن يكون هيكل TS نفسه بسيطًا للغاية - شجرة أو مجرد اتصال تسلسلي ، بدون أي حلقات ومسارات بديلة.
يمكن حل المشكلة العكسية في ظل ظروف مماثلة ، ولكن في نفس الوقت ، على مستوى التجميع وجوهر الشبكة ، من المستحيل حل هذه المشكلة من حيث المبدأ ، لأنه تخضع هذه الأجزاء لبروتوكولات توجيه ديناميكية ولها العديد من المسارات البديلة المحتملة.

أيضًا ، ضع في اعتبارك أن هيكل الشبكة أكثر تعقيدًا بشكل عام (الجزء أعلاه محاط بدائرة باللون الأحمر):

وهذه ليست أصغر شريحة - فهناك المزيد والمزيد من التعقيد في الطوبولوجيا:

لذلك ، كان هذا الخيار مناسبًا للتحليل التأملي للحالات الفردية ، ولكن ليس بأي حال من الأحوال للعمل المبسط ، علاوة على ذلك ، ليس لأتمتة الحل المباشر والعكس.

الجزء 2. أتمتة v1.0

دعني أذكرك بالمهام التي قمنا بحلها:

تحديد مسار الخدمة عبر المركبة - مهمة مباشرة.
تحديد الخدمات التابعة من قناة TC - مشكلة معكوسة.

2.1. خدمات النقل للمحطات الأساسية (BS)

بشكل عام ، يبدو تنظيم النقل من العقدة المركزية (وحدة التحكم / البوابة) إلى BS كما يلي:

فيما يتعلق بأجزاء التجميع وجوهر TS ، يتم إجراء الاتصالات من خلال خدمات النقل لشبكة MPLS: L2 / L3 VPN ، VLL. في مقاطع الوصول ، يتم إجراء الاتصالات ، كقاعدة عامة ، من خلال شبكات محلية ظاهرية مخصصة.

اسمحوا لي أن أذكرك بأن لدينا قاعدة بيانات حيث تكمن جميع المعلمات والطوبولوجيا الفعلية (خلال فترة معينة) للمركبة.

2.2. حل قطعة الطلب الهاتفي (الوصول)

نأخذ بيانات حول VLAN للواجهة المنطقية BS ، وخطوة بخطوة "ننتقل" من خلال الروابط ، التي تحتوي منافذها على معرف Vlan هذا ، حتى نصل إلى جهاز توجيه الحدود (MBN).

لحل مثل هذه المشكلة البسيطة ، انتهى بي الأمر إلى:

اكتب خوارزمية للتتبع خطوة بخطوة لـ "انتشار" VlanID من BS عبر قنوات شبكة التجميع
ضع في اعتبارك فجوات البيانات الموجودة. كان هذا صحيحًا بشكل خاص بالنسبة للمفاصل بين العقد على المواقع.
في الواقع ، اكتب خوارزمية SPF لإسقاط الفروع المسدودة في النهاية التي لا تؤدي إلى جهاز التوجيه MVN.

خرجت الخوارزمية من عملية رئيسية واحدة وسبع عمليات فرعية. استغرق الأمر 3-4 أسابيع من وقت العمل الخالص لتنفيذه وتصحيحه.

بالإضافة إلى ذلك ، كنا سعداء بشكل خاص ...

2.2.1. SQL JOIN

بحكم هيكلها ، فإن النموذج العلائقي لاجتياز الرسم البياني يتطلب نهجًا تعاوديًا واضحًا مع عمليات الربط في كل مستوى ، مع اجتياز نفس مجموعة السجلات بشكل متكرر. وهذا بدوره يؤدي إلى تدهور أداء النظام ، خاصة على مجموعات البيانات الكبيرة.

لأسباب واضحة ، لا يمكنني الاستشهاد بمحتويات الاستعلامات في قاعدة البيانات هنا ، ولكن تقييم - كل "حافة" في نص الاستعلام هي اتصال الجدول التالي ، وهو أمر ضروري ، في هذه الحالة ، للحصول على مراسلات موحدة بين Port و VlanID:

وهذا الطلب للحصول ، في شكل موحد ، على توصيلات VlanID المتقاطعة داخل المحول:

بالنظر إلى أن عدد المنافذ كان عدة عشرات الآلاف ، وأن شبكة VLAN كانت أكثر بعشر مرات ، كان كل هذا مترددًا جدًا في التقليب والانعطاف. ويجب تقديم مثل هذه الطلبات لكل عقدة و VlanID. و "تفريغ كل شيء دفعة واحدة وحساب" أمر مستحيل منذ ذلك الحين إنه حساب متسلسل للمسار c مع عمليات خطوة بخطوة تعتمد على نتائج الخطوة السابقة.

2.3 تحديد مسار الخدمة في المقاطع الموجهة

بدأنا هنا ببائع MVN واحد يوفر نظام إدارته بيانات عن LSPs الحالية والاحتياطية عبر قطاع MPLS. من خلال معرفة واجهة الوصول التي تم توصيلها بالوصول (L2 Vlan) ، كان من الممكن العثور على LSP ومن ثم ، من خلال سلسلة من الطلبات إلى نظام NBI ، الحصول على مسار LSP ، الذي يتكون من أجهزة توجيه وروابط بينها.

على غرار المقطع المبدّل ، أدى وصف تفريغ مسار LSP لخدمة MPLS إلى خوارزمية تحتوي بالفعل على 17 إجراءً فرعيًا.
يعمل الحل فقط على الشرائح التي يخدمها هذا البائع
كان من الضروري تحديد تعريف المفاصل بين خدمات MPLS (على سبيل المثال ، في وسط المقطع كانت هناك خدمة VPLS عامة ، وتباعدت إما EPIPE أو L3VPN عنها)

لقد عملنا على هذه المشكلة لبائعي MVN الآخرين ، حيث لم تكن هناك أنظمة تحكم ، أو لم يقدموا بيانات عن ممر LSP الحالي من حيث المبدأ. لقد وجدنا حلاً للعديد ، ولكن - لم يعد عدد مزودي خدمة الإنترنت الذين يمرون عبر جهاز التوجيه هو عدد VanIDs المسجل على المحول. تأخير مثل هذا الحجم من البيانات "عند الطلب" (بعد كل شيء ، نحن بحاجة إلى معلومات تشغيلية) - هناك مخاطرة بإيقاف الأجهزة.

بالإضافة إلى ذلك ، نشأت أسئلة إضافية:

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

2.4. .

يجب تدوين البيانات المستلمة حول مسارات اتصال الخدمات في مكان ما ، حتى نتمكن لاحقًا من الرجوع إليها عند حل مشاكلنا المباشرة والمعكوسة.

تم استبعاد خيار التخزين في قاعدة بيانات علائقية على الفور: هل من الصعب جدًا تجميع البيانات من العديد من المصادر بحيث يتم فرزها لاحقًا في مجموعات الجداول التالية؟ هذه ليست طريقتنا. علاوة على ذلك ، تذكر عن الصلات متعددة الطوابق وأدائها.

يجب أن تحتوي البيانات على معلومات حول بنية الخدمة وتبعيات مكوناتها: الروابط ، والعقد ، والمنافذ ، إلخ.

كحل اختبار ، تم اختيار تنسيق XML و Native-XML DB - Exist.

نتيجة لذلك ، تمت كتابة كل خدمة في قاعدة البيانات بالتنسيق (تم حذف التفاصيل من أجل الاكتناز):

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

تم إجراء استعلام البيانات للمشكلات المباشرة والعكسية باستخدام بروتوكول XPath:

الكل. الآن يعمل النظام - بالنسبة لطلب يحمل اسم BS ، يتم إرجاع طوبولوجيا اتصاله عبر شبكة النقل ، لطلب مع اسم العقدة ومنفذ TS ، يتم إرجاع قائمة BS التي تعتمد عليها للاتصال. لذلك ، توصلنا إلى الاستنتاجات التالية ...

2.5

بدلاً من التوجه إلى نتائج الجزء الثاني

2.5.1. للمقطع المحول (الشبكات على محولات L2 Ethernet)

مطلوب بيانات كاملة عن الهيكل ومراسلات Port - VlanID. إذا لم تكن هناك بيانات VlanID على ارتباط ما ، فستتوقف الخوارزمية ، ولم يتم العثور على المسار
استعلامات متعددة المستويات غير منتجة مقابل قاعدة بيانات علائقية. عندما يظهر بائع جديد بتفاصيله الخاصة ، المعلمات - إضافة الطلبات في جميع مراحل العمل

2.5.2. لقطاع موجه

مقيدة بقدرات MVN SU لتوفير البيانات حول طوبولوجيا خدمات LSP MPLS.
– , .. LSP .
LSP – ( , “” ).

2.5.3.

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

2.6. -

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

بعد أن قمنا بتقييم الخيارات الممكنة لتنفيذ رغباتنا ، قررنا فئة الأنظمة التي من شأنها توفير كل هذا "خارج الصندوق" - وهذا ما يسمى. قواعد بيانات الرسم البياني.

على الرغم من أن الجملة الأخيرة تُقرأ على أنها شيء خطي وبسيط ، نظرًا لأنه لم يسبق لأي منا (وأخصائيي تكنولوجيا المعلومات لدينا ، كما اتضح) أن واجه فئة قاعدة البيانات هذه ، فقد توصلوا إلى القرار إلى حد ما عن طريق الصدفة: تم ذكر قواعد بيانات مماثلة (ولكن لم أفهم) في دورة نظرة عامة على البيانات الضخمة. على وجه الخصوص ، ذكر المنتج Neo4j... لم يقتصر الأمر على تلبية جميع متطلباتنا ، بناءً على الوصف ، بل إنه يحتوي أيضًا على إصدار مجتمع وظيفي مجاني تمامًا. أولئك. - ليس نسخة تجريبية مدتها 30 يومًا ، ولا تقطع الوظائف الرئيسية ، بل منتج يعمل بالكامل يمكنك دراسته ببطء. لم يكن الدور الأخير (إن لم يكن الرئيسي) في الاختيار قد تم لعبه من خلال الدعم الواسع لخوارزميات الرسم البياني .

الجزء 3. مثال على تنفيذ المشكلة المباشرة في Neo4j

من أجل عدم سحب السرد الخطي حول كيفية تنفيذ نموذج TS في قاعدة بيانات الرسم البياني Neo4j ، سنعرض النتيجة النهائية على الفور بمثال.

3.1. تتبع مسار واجهة Iub لـ 3G BS

يمر مسار توصيل الخدمة عبر جزأين - MVN موجه ، وخط ترحيل لاسلكي (تعمل محطات الترحيل الراديوي كمفاتيح إيثرنت). يتم تحديد المسار عبر مقطع RRL بنفس الطريقة الموضحة في الجزء 2 - عن طريق مرور VlanID لواجهة BS على طول مقطع RRL إلى موجه الحدود MVN. يربط مقطع MVN الحد (مع مقطع RRL) - بالموجه الذي تتصل به وحدة التحكم BS (RNC).

في البداية ، من المعلمة Iub ، نعرف بالضبط MVN هو بوابة BS (حد MVN) ، وأي وحدة تحكم تخدمها BS.

بناءً على هذه الشروط الأولية ، سنقوم ببناء استعلامين لقاعدة البيانات لكل قسم. يتم إنشاء جميع الاستعلامات إلى قاعدة البيانات بلغة Cypher... حتى لا يتشتت انتباهك عن وصفه الآن ، فكر في الأمر ببساطة على أنه "SQL للرسوم البيانية".

3.1.1. جزء RRL. مسار VlanID

طلب Cypher لتتبع مسار الخدمة بناءً على بيانات طوبولوجيا VlanID و L2 المتوفرة:

جزء من استعلام Cypher (مع الإنشاء - تمرير نتائج مرحلة واحدة من الاستعلام إلى المرحلة التالية (تسلسل المعالجة))	نتائج الاستعلام الوسيطة (تمثيل مرئي في وحدة تحكم Neo4j - " متصفح Neo4j ")
الحصول على عقدتي BS و MVN التي سيتم البحث بينهما في مسار خدمة Iub `match (bts:node {name:'BTS_29__N}), (mbh:node {name:'MBH_29_YYYYY_N}) with bts, mbh`
تلقي عقد Vlan لواجهة BS Iub `match (bts)-[:port_attach]->(:port)-[:vlan]->(vlan:vlan) with bts as bts, vlan.vlanid AS vlan_bts , mbh`
نختار عقد السيارة في نفس الموقع مع BS ، على المنافذ التي تم تسجيل VlanID Iub BS فيها `MATCH ((bts)-->(pl_bts:PL)-->(n:node)-[:port_attach]->(pid:port)-->(v:vlan)) where (v.vlanid=vlan_bts and v.updated > bts.updated - 864000000) with distinct(v) as v,n,mbh,vlan_bts, bts`
باستخدام خوارزمية Dijkstra ، نجد أقصر مسار من VlanID الخاص بـ TS لموقع BS إلى حد MVN `CALL apoc.algo.dijkstra(v, mbh, 'port_attach>\|port_hosted>\|<node_vlan\|v_ptp_vlan>\|ptp_vlan>\|located_at>\|to_node>', 'weight',10000000000.0,1) YIELD path as path_pl_mbh`
من سلسلة Vlan ، نحصل على قائمة بالعقد والمنافذ والتوصيلات بين المنافذ ، والتي ستكون في النهاية هي الطريقة لتوصيل خدمة Iub من BS إلى جهاز توجيه الحدود `WITH FILTER(node in nodes(path_pl_mbh) WHERE (node:vlan)) as vlans_node , path_pl_mbh, bts ,mbh , vlan_bts unwind vlans_node as vlan_node match (vlan_node)-->(p1:port) match p=(p1)-[:port_hosted\|to_port\|v_to_port\|to_node\|located_at]->() return p, bts, mbh` نتيجة:

كما ترى ، تم الحصول على المسار ، حتى على الرغم من النقص الجزئي في البيانات. في هذه الحالة ، لا توجد معلومات حول تقاطع منفذ BS مع منفذ محطة ترحيل الراديو.

3.1.2. جزء RRL. مسار طوبولوجيا L2

لنفترض أنه تم إجراء محاولة في الفقرة 3.1.1. فشل بسبب الغياب الكامل أو الجزئي للبيانات في معلمة VlanID. بمعنى آخر ، لم يتم إنشاء مثل هذه السلسلة المستمرة التي تصل إلى عقدة MVN:

ثم يمكنك محاولة تعريف اتصال الخدمة على أنه أقصر مسار إلى MVN وفقًا لطوبولوجيا L2:

match (bts:node {name:'BTS_29__N}), (mbh:node {name:'MBH_29_YYYYY_N})
with bts, mbh
CALL apoc.algo.dijkstra(bts, mbh, 'located_at>|to_node>|to_port>|v_to_port>|port_hosted>|port_attach>', 'weight',1.0,1) YIELD path as p
return p

نتيجة:

كما ترى ، يتم الحصول على نفس النتيجة. هنا ، يتم تعويض نقص المعلومات حول تقاطع BS مع RRS عن طريق تمرير الاتصال عبر الكائن (العقدة) بالموقع الذي توجد فيه. بالطبع ، ستكون دقة هذه الطريقة أقل منذ ذلك الحين بشكل عام ، قد لا يتم تسجيل Vlan على طول أقصر مسار اقترحته خوارزمية Dijkstra. لكن الطلب يتكون من عمليتين فقط.

3.1.3 قطاع MVN. تتبع المسار من الحد MVN إلى وحدة التحكم

هنا نستخدم أيضًا خوارزمية Dijkstra.

مسار واحد بأقل تكلفة

match (mbh:node {name:’MBH_29_XXX’}), (rnc:node {name:’RNC_YYY’})
CALL apoc.algo.dijkstra(mbh,rnc, 'port_attach>|port_hosted>|<node_vlan|ptp_vlan>|located_at>|to_node>|to_port_mbh>', 'weight',10000000000.0,1) YIELD path as path
return path

أفضل مسارين بأقل تكلفة (رئيسي + بديل)

match (mbh:node {name:’MBH_29_XXX’}), (rnc:node {name:’RNC_YYY’})
CALL apoc.algo.dijkstra(mbh,rnc, 'port_attach>|port_hosted>|<node_vlan|ptp_vlan>|located_at>|to_node>|to_port_mbh>', 'weight',10000000000.0,2) YIELD path as path
return path

أفضل 3 مسارات بأقل تكلفة (رئيسي + بديلان)

match (mbh:node {name:’MBH_29_XXX’}), (rnc:node {name:’RNC_YYY’})
CALL apoc.algo.dijkstra(mbh,rnc, 'port_attach>|port_hosted>|<node_vlan|ptp_vlan>|located_at>|to_node>|to_port_mbh>', 'weight',10000000000.0,3) YIELD path as path
return path

وبالمثل ، في هذه الحالة ، لا توجد معلومات حول الوصلات المباشرة لـ MVN مع RNC. لكن هذا لا يمنعنا من بناء مسار خدمة ، حتى لو افترضته الخوارزمية (المزيد حول هذا لاحقًا).

3.2 تكاليف العمالة

يختلف تنفيذ المشكلة المباشرة ، الموضح الآن ، بشكل لافت للنظر عن نهج "تطوير خوارزمية ، وبرنامج ، وطريقة تخزين واسترجاع النتائج" - كل ذلك يعود إلى "كتابة استعلام إلى قاعدة البيانات". بالنظر إلى المستقبل ، نلاحظ أن الدورة بأكملها من تطوير نموذج رسم بياني بسيط ، وتحميل البيانات إلى Neo4j من قاعدة بيانات علائقية ، وكتابة الاستعلامات ، وحتى الحصول على النتيجة ، استغرقت يومًا واحدًا.

3-4 أشهر مقابل يوم واحد !!! كان هذا هو السبب الأخير للمغادرة النهائية لقاعدة بيانات الرسم البياني.

الجزء 4. رسم قاعدة بيانات Neo4j وتحميل البيانات فيها

4.1 مقارنة بين قواعد البيانات العلائقية والرسم البياني

الخصائص المقارنة	قاعدة بيانات علائقية	الرسم البياني DB
مخزن البيانات	يتم تخزين البيانات في مجموعة من الجداول المنفصلة ، يمكن تحديد العلاقات بين صفوفها بواسطة الحقول الرئيسية من خلال علاقات خاصة: واحد لواحد ، واحد إلى كثير ، كثير إلى كثير.	( / ). .
	, , , , , . / , . , ,	( ) . . – . . : , , .
JOIN	, – . , .. NESTED-LOOP	( ). – JOIN , .
JOIN chain	JOIN – . .. JOIN . “ ” – Oracle, Neo4j:	. – .
- /	, ,	يقطع الطلب بالضبط ذلك الجزء من الرسم البياني المرتبط بالعقد / الروابط ذات الأهمية ويعمل معها فقط ، بينما يمكن أن يكون حجم قاعدة بيانات الرسم البياني موجودًا. على سبيل المثال ، يأتي الطلب من العقدة "MVN-X" ، في حين أن الإجمالي في الرسم البياني يمكن أن يكون 1000 و 1 مليون عقدة MVN - سيظل البحث داخل "مقطع" الرسم البياني ، بما في ذلك "MVN-X" فقط.

4.2 نموذج البيانات

النموذج الأساسي لعرض TS حتى مستوى طوبولوجيا L3 بما في ذلك:

بالطبع ، النموذج أكثر شمولاً من النموذج المقدم ، ويحتوي أيضًا على خدمات MPLS وواجهات افتراضية ، ولكن من أجل البساطة ، دعنا نفكر في جزء محدود منه.

في مثل هذا النموذج ، يمكن تمثيل العلاقة بين عنصري شبكة من نفس المنطقة على النحو التالي:

4.3 تحميل البيانات

نقوم بتحميل البيانات من قاعدة بيانات المعلمات وطوبولوجيا السيارة. للتحميل إلى Neo4j من قاعدة بيانات SQL ، يتم استخدام مكتبة APOC - apoc.load.jdbc ، والتي تأخذ كمدخل سلسلة اتصال إلى RDBMS ونص استعلام SQL ، وتعيد مجموعة من السلاسل التي تم تعيينها إلى العقد أو الروابط أو المعلمات من خلال تعبيرات CYHPER. يتم تنفيذ هذه العمليات طبقة تلو الأخرى لكل نوع من كائن النموذج.

على سبيل المثال ، تصريح لتحميل / تحديث العقد التي تمثل عناصر الشبكة (العقد):

with "jdbc:oracle:thin:usr /passw@IP:1521/db" as url // DB connection string
CALL apoc.load.jdbc(url,
" select distinct mr,region_code,site_code,node, nodeip,TYPE,VENDOR, coalesce(updated, trunc(localtimestamp-7)) as updated
from (
    select distinct mr,region_code,site_code,node, nodeip,TYPE,VENDOR, updated from GRAPH_IPMPLS_NE
    union
    select distinct mr,region_code,site_code,node, nodeip,TYPE,VENDOR, updated from GRAPH_RRN_NE
    union
    select distinct mr,region_code,site_code,node, nodeip,TYPE,VENDOR, updated from GRAPH_CONTROLLERS_NE
) t
where mr is not null and region_code is not null and site_code is not null "
) YIELD row

استدعاء الإجراء apoc.load.jdbc ،

والحصول على مجموعة بيانات

match (reg:Region {region_code:row.REGION_CODE})-->(pl:PL {SiteCode:row.SITE_CODE}) 
with pl, row, {updated:row.UPDATED, weight:1000000000000} as conn_params

لكل صف من مجموعة البيانات

حسب المنطقة ورمز الموقع ، يتم البحث عن العقد التي

تمثل المواقع المقابلة

	merge (pl)<-[loc:located_at]-(n:node {ip:row.NODEIP})
	merge (pl)-[to_n:to_node]->(n)
		set n.name=row.NODE
		set n.region_code = row.REGION_CODE
		set n.type = row.TYPE
		set n.updated = row.UPDATED
		set n.vendor = row.VENDOR
		set loc += conn_params
		set to_n += conn_params

لكل كائن موقع ، يتم تحديث

عناصر الشبكة المرتبطة (العقدة).

يتم استخدام تعليمة MERGE + SET ،

والتي تقوم بتحديث معلمات الكائن

إذا كانت موجودة بالفعل في قاعدة البيانات ، وإذا لم تكن موجودة بالفعل

، فإنها تنشئ الكائن.

يتم أيضًا تسجيل معلمات عقدة العقدة واتصالاتها بعقدة PL .

وهكذا - عبر جميع مستويات نموذج TS.

يُستخدم الحقل المحدَّث للتحكم في ملاءمة البيانات الموجودة في العمود - يتم حذف الكائنات التي لم يتم تحديثها لفترة أطول من فترة معينة.

الجزء 5. حل المشكلة العكسية في Neo4j

عندما بدأنا لأول مرة ، أثار تعبير "تتبع الخدمة" في المقام الأول الارتباطات التالية:

أي أن المسار الحالي للخدمة يتم تتبعه مباشرة ، في وقت معين.

هذا ليس بالضبط ما لدينا في قاعدة بيانات الرسم البياني. في GDB ، يتم تتبع الخدمة وفقًا لعلاقات الكائنات التي تحدد تكوينها في كل عنصر شبكة معني. أي ، يتم تمثيل التكوين في شكل نموذج رسم بياني ، والتتبع الناتج هو مرور عبر النموذج الذي يمثل هذا التكوين.

نظرًا لأنه ، على عكس المقطع المحول ، يتم تحديد مسارات الخدمة الفعلية في مقطع mpls بواسطة بروتوكولات ديناميكية ، كان علينا قبول بعض ...

5.1 الافتراضات للقطاعات الموجهة

لان من بيانات التكوين الخاصة بخدمات mpls ، لا توجد طريقة لتحديد مسارها الدقيق من خلال المقاطع التي يتم التحكم فيها بواسطة بروتوكولات التوجيه الديناميكي (خاصة إذا تم استخدام هندسة المرور) - يتم استخدام خوارزمية Dijkstra للحل.

نعم ، هناك أنظمة إدارة يمكنها توفير المسار الفعلي لخدمة LSPs عبر واجهة NBI ، ولكن لدينا حتى الآن بائع واحد فقط ، وهناك أكثر من بائع واحد في قطاع MVN.

نعم ، هناك أنظمة لتحليل بروتوكولات التوجيه داخل AS ، والتي من خلال الاستماع إلى تبادل بروتوكولات IGP ، يمكنها تحديد المسار الحالي لبادئة الاهتمام. ولكن هناك مثل هذه الأنظمة - مثل طائرة بوينج التي تم إسقاطها ، وبالنظر إلى أن مثل هذا النظام يحتاج إلى أن يتم نشره على جميع AS في نفس الفتحة الخلفية المتنقلة - فإن تكلفة الحل ، إلى جانب جميع التراخيص ، ستكون تكلفة طائرة بوينج التي أسقطها جسر من الحديد الزهر مرتبط بصاروخ أنجارا عند التزود بالوقود بالكامل. وهذا على الرغم من حقيقة أن مثل هذه الأنظمة لا تحل تمامًا مشكلة محاسبة المسارات عبر العديد من أنظمة AS باستخدام BGP.

لذلك - حتى الآن. بالطبع ، أضفنا العديد من الدعائم لشروط خوارزمية 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 محطات قاعدية ، ونتيجة لذلك ، أدى نشر شبكة Vlan العابرة مع Modem1.

هذا النهج له عدة مشاكل:

بالنسبة للمنافذ ، يجب معرفة شبكة محلية ظاهرية (Vlan) التي تم تكوينها وتحميلها في النموذج.
نظرًا لاحتمال التجزئة ، لا تخرج سلسلة Vlan دائمًا إلى العقدة الطرفية
من المستحيل تحديد ما إذا كانت العقدة الأخيرة في سلسلة Vlan تنتمي إلى عقدة طرفية أو ما إذا كانت الخدمة مستمرة بالفعل.

أي أنه من الملائم دائمًا تتبع خدمة ما بين العقد / نقاط نهاية مقطعها ، بدلاً من تتبعها من "وسط" عشوائي ومن طبقة OSI واحدة.

5.2.2. جزء موجه

مع مقطع موجه ، كما هو موضح بالفعل في البند 5.1 ، ليست هناك حاجة للاختيار - لا توجد وسيلة لحل المشكلة العكسية بناءً على بيانات التكوين الحالي لبعض ارتباط MPLS الوسيط - لا يحدد التكوين بشكل صريح تتبع الخدمة.

5.3 القرار

تم اتخاذ القرار على النحو التالي.

يتم التحميل الكامل لطراز السيارة ، بما في ذلك BS وأجهزة التحكم
بالنسبة لجميع BS ، يتم حل المشكلة المباشرة - تتبع خدمات Iub و S1 من BS إلى حد MVN ، ثم من MVN الحدودي إلى وحدات التحكم أو البوابات المقابلة.
تتم كتابة نتائج التتبع في قاعدة بيانات SQL عادية بالتنسيق: اسم BS - مجموعة عناصر مسار الخدمة

وفقًا لذلك ، عند الوصول إلى قاعدة البيانات باستخدام الشرط Node TS أو Node TS + Port ، يتم إرجاع قائمة بالخدمات (BS) ، تحتوي مصفوفة المسار على العقدة المطلوبة أو Node + Port.

الجزء 6. النتائج والاستنتاجات

6.1 النتائج

ونتيجة لذلك يعمل النظام على النحو التالي:

في الوقت الحالي ، لحل المشكلة المباشرة ، أي عند تحليل أسباب تدهور الخدمات الفردية ، تم تطوير تطبيق ويب يظهر نتيجة التتبع (المسار) من Neo4j ، مع بيانات متراكبة حول جودة وأداء الأقسام الفردية للمسار.

للحصول على قائمة بالخدمات التي تعتمد على عقد أو قنوات TS (حل المشكلة العكسية) ، تم تطوير API للأنظمة الخارجية (على وجه الخصوص ، Remedy).

6.2 الاستنتاجات

رفع كلا الحلين أتمتة تحليل جودة الخدمات وشبكة النقل إلى مستوى جديد نوعيًا.
بالإضافة إلى ذلك ، في ظل وجود بيانات جاهزة حول مسارات خدمات BS ، أصبح من الممكن توفير البيانات بسرعة لوحدات الأعمال حول الإمكانية التقنية لتضمين عملاء B2B في مواقع محددة - من حيث سعة وجودة المسار.
أثبت Neo4j أنه أداة قوية جدًا لحل مشاكل الرسم البياني للشبكة. الحل موثق جيدًا ، ولديه دعم واسع في مجتمعات المطورين المختلفة ، ويتم تطويره وتحسينه باستمرار.

6.3 الخطط

لدينا خطط:

توسيع القطاعات التكنولوجية على غرار قاعدة بيانات Neo4j
تطوير وتنفيذ خوارزميات التتبع لخدمات النطاق العريض
زيادة أداء منصة الخادم

شكرآ لك على أهتمامك!

خدمات التتبع في شبكة النقل المتنقلة. كيف وصلنا إلى قاعدة بيانات الرسم البياني Neo4j