Bagian 1. Awal

1.1 Pendahuluan dan pernyataan masalah

Di MTS, kami secara terpusat mengontrol kualitas jaringan transmisi data atau, lebih sederhananya, jaringan transportasi (jangan disamakan dengan jaringan transportasi logistik), yang selanjutnya disebut TS. Dan, dalam kerangka aktivitas kami, kami terus-menerus harus menyelesaikan dua tugas utama:

1. Degradasi layanan klien (dalam kaitannya dengan TS) telah terdeteksi - jalur koneksi mereka perlu ditentukan melalui TS, dan cari tahu apakah alasan penurunan layanan adalah bagian dari TS. Selanjutnya, kami akan menyebutnya Masalah Langsung.
2. Penurunan kualitas saluran transportasi atau urutan saluran terdeteksi - perlu untuk menentukan layanan mana yang bergantung pada saluran / saluran ini untuk menentukan dampaknya. Selanjutnya, kami akan menyebutnya Masalah Invers.

Layanan TS dipahami sebagai koneksi peralatan klien. Ini bisa berupa stasiun pangkalan (BS), klien B2B (menggunakan MTS TS untuk mengatur akses ke Internet dan / atau jaringan VPN overlay), klien akses tetap (disebut akses broadband), dll. dll.



Kami memiliki dua sistem informasi terpusat yang kami miliki:



Setiap jaringan transportasi secara inheren merupakan grafik berarah $$$G=(V,E)$di mana setiap sisi $$$(u,v) in E$memiliki bandwidth non-negatif. Oleh karena itu, sejak awal pencarian solusi atas permasalahan tersebut dilakukan dalam kerangka teori graf.



Pertama, masalah membandingkan indikator kualitas TS dan layanan dengan topologi TS diselesaikan dengan menggabungkan dan menyajikan topologi dan data kualitas dalam bentuk grafik jaringan.



Tampilan grafik yang dibentuk sesuai topologi dan data kinerja diimplementasikan menggunakan perangkat lunak Gephi open source . Ini memungkinkan untuk memecahkan masalah representasi otomatis dari topologi, tanpa pekerjaan manual pada pembaruannya. Ini terlihat seperti ini:





Di sini, node sebenarnya adalah node TS (router, switch) dan yang dasar, ujungnya adalah saluran TS. Kode warna, masing-masing, menunjukkan adanya penurunan kualitas dan status perlakuan dari degradasi tersebut.



Tampaknya ini cukup jelas dan Anda dapat bekerja, tetapi:

• Masalah langsung (dari jalur layanan ke jalur layanan) dapat diselesaikan dengan cukup akurat hanya dengan syarat topologi TS itu sendiri cukup sederhana - pohon atau hanya koneksi serial, tanpa cincin dan rute alternatif.
• Masalah terbalik dapat diselesaikan dalam kondisi yang sama, tetapi pada saat yang sama, pada tingkat agregasi dan inti jaringan, pada prinsipnya tidak mungkin untuk menyelesaikan masalah ini, karena segmen ini diatur oleh protokol routing dinamis dan memiliki banyak rute alternatif potensial.

Juga, perlu diingat bahwa, secara umum, topologi jaringan jauh lebih rumit (bagian di atas dilingkari merah):





Dan ini bukan segmen terkecil - ada topologi yang jauh lebih dan lebih kompleks:





Jadi, opsi ini cocok untuk analisis meditatif dari kasus-kasus individu, tetapi tidak untuk kerja alur dan, terlebih lagi, tidak untuk mengotomatiskan solusi langsung dan mundur.

---

Bagian 2. Otomatisasi v1.0

Izinkan saya mengingatkan Anda tugas apa yang telah kami selesaikan:

1. Menentukan jalur layanan melalui kendaraan - Tugas langsung.
2. Penentuan layanan dependen dari saluran TC - Masalah terbalik.

2.1. Layanan transportasi untuk Stasiun Pangkalan (BS)

Secara umum, organisasi pengangkutan dari node pusat (pengontrol / gateway) ke BS terlihat seperti ini:





Pada segmen agregasi dan inti TS, koneksi dibuat melalui layanan transportasi jaringan MPLS: L2 / L3 VPN, VLL. Pada segmen akses, koneksi dilakukan, sebagai aturan, melalui VLAN khusus.



Izinkan saya mengingatkan Anda bahwa kami memiliki database di mana semua parameter aktual (dalam periode tertentu) dan topologi kendaraan berada.

2.2. Solusi segmen dial-up (akses)

Kami mengambil data tentang VLAN dari antarmuka logis BS, dan langkah demi langkah "masuk" melalui tautan, port yang berisi ID Vlan ini, hingga kami mencapai router perbatasan (MBN).





Untuk mengatasi pernyataan masalah yang begitu sederhana, saya akhirnya harus:

1. Tulis algoritme untuk penelusuran langkah demi langkah "propagasi" VlanID dari BS melalui saluran jaringan agregasi
2. Pertimbangkan kesenjangan data yang ada. Hal ini terutama berlaku untuk sambungan antara node di situs.
3. Nyatanya, tulis algoritma SPF untuk menjatuhkan cabang buntu di ujung yang tidak mengarah ke router MVN.

Algoritma ini keluar dari satu proses utama dan tujuh sub-proses. Butuh 3-4 minggu waktu kerja murni untuk menerapkan dan men-debugnya.



Selain itu, kami sangat senang ...

2.2.1. SQL BERGABUNG

Karena strukturnya, model relasional untuk melintasi grafik memerlukan pendekatan rekursif eksplisit dengan operasi gabungan di setiap level, sambil berulang kali melintasi satu rangkaian rekaman. Hal ini, pada gilirannya, menyebabkan penurunan kinerja sistem, terutama pada kumpulan data yang besar.



Untuk alasan yang jelas, saya tidak dapat mengutip konten kueri ke database di sini, tetapi mengevaluasi - setiap "langkan" dalam teks kueri adalah sambungan dari tabel berikutnya, yang diperlukan untuk, dalam hal ini, memperoleh korespondensi terpadu antara Port dan VlanID:





Dan permintaan ini untuk mendapatkan, dalam bentuk terpadu, koneksi silang VlanID di dalam sakelar:





Mengingat jumlah port beberapa puluh ribu, dan VLAN 10 kali lebih banyak, semua ini sangat enggan untuk melempar dan berputar. Dan permintaan seperti itu harus dibuat untuk setiap node dan VlanID. Dan "membongkar semuanya sekaligus dan menghitung" tidak mungkin, karena itu adalah komputasi sekuensial dari jalur c dengan operasi langkah demi langkah yang bergantung pada hasil langkah sebelumnya.

2.3. Menentukan Jalur Layanan di Segmen yang Dirutekan

Di sini kami mulai dengan satu vendor MVN yang sistem manajemennya menyediakan data tentang LSP saat ini dan siaga di segmen MPLS. Mengetahui antarmuka Akses yang terhubung ke akses (L2 Vlan), LSP dapat ditemukan dan kemudian, melalui serangkaian permintaan ke sistem NBI, dapatkan jalur LSP, yang terdiri dari router dan tautan di antara mereka.

• Mirip dengan segmen yang dialihkan, deskripsi pembongkaran jalur LSP dari layanan MPLS menghasilkan algoritme yang sudah memiliki 17 subrutin.
• Solusi tersebut hanya bekerja pada segmen yang dilayani oleh vendor ini
• Perlu untuk memutuskan definisi sambungan antara layanan MPLS (misalnya, di tengah segmen terdapat layanan VPLS umum, dan EPIPE atau L3VPN menyimpang darinya)

Kami menangani masalah ini untuk vendor MVN lainnya, yang tidak memiliki sistem kontrol, atau mereka tidak memberikan data tentang jalur LSP saat ini pada prinsipnya. Kami menemukan solusi untuk beberapa, tetapi - jumlah LSP yang melewati router bukan lagi jumlah VanID, yang terdaftar di sakelar. Menunda volume data "sesuai permintaan" (bagaimanapun juga, kita membutuhkan informasi operasional) - ada risiko meletakkan perangkat keras.



Selain itu, pertanyaan tambahan muncul:

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

2.4. .

Data yang diterima tentang jalur koneksi layanan harus ditulis di suatu tempat, sehingga nanti kami dapat merujuknya saat memecahkan masalah Direct dan Invers kami.



Opsi untuk menyimpan dalam database relasional segera dikesampingkan: apakah begitu sulit untuk menggabungkan data dari banyak sumber sehingga nanti dapat disortir ke dalam set tabel berikutnya? Ini bukan metode kami. Selain itu, ingatlah tentang pertemuan bertingkat dan kinerjanya.



Data harus berisi informasi tentang struktur layanan dan ketergantungan komponennya: tautan, node, port, dll.



Sebagai solusi uji, format XML dan Native-XML DB - Exist dipilih.



Akibatnya, setiap layanan ditulis ke database dalam format (detail dihilangkan demi kekompakan):

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

Kueri data untuk masalah langsung dan terbalik dilakukan menggunakan protokol XPath:





Semua. Sekarang sistem bekerja - untuk permintaan dengan nama BS, topologi koneksinya melalui jaringan transport dikembalikan, untuk permintaan dengan nama node dan port TS, daftar BS yang bergantung padanya untuk koneksi dikembalikan. Oleh karena itu, kami membuat kesimpulan berikut ...

2.5.

Daripada menuju temuan di Bagian 2

2.5.1. Untuk segmen yang dialihkan (jaringan pada sakelar Ethernet L2)

• Data lengkap topologi dan Port - korespondensi VlanID diperlukan. Jika tidak ada data VlanID di beberapa tautan, algoritme berhenti, jalur tidak ditemukan
• Kueri multilevel yang tidak produktif terhadap database relasional. Ketika vendor baru muncul dengan spesifikasinya sendiri, parameter - menambahkan permintaan di semua tahap pekerjaan

2.5.2. Untuk segmen yang dirutekan

• Dibatasi oleh kemampuan MVN SU untuk menyediakan data tentang topologi layanan LSP MPLS.
• – , .. LSP .
• LSP – ( , “” ).

2.5.3.

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

2.6. -

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

Setelah kami menilai opsi yang memungkinkan untuk implementasi keinginan kami, kami memutuskan kelas sistem yang akan menyediakan semua ini "di luar kotak" - inilah yang disebut. database grafik.



Meskipun kalimat terakhir dibaca sebagai sesuatu yang linier dan sederhana, mengingat bahwa sebelumnya tidak satupun dari kami (dan spesialis IT kami, ternyata, juga) pernah menemukan kelas database seperti itu, mereka mengambil keputusan secara tidak sengaja: database serupa disebutkan (tetapi tidak mengerti) di kursus ikhtisar Big Data. Secara khusus, disebutkan produk Neo4j... Tidak hanya itu, dilihat dari deskripsinya, memenuhi semua persyaratan kami, ia juga memiliki versi komunitas fungsional yang sepenuhnya gratis. Itu. - bukan uji coba 30 hari, bukan fungsi utama, tetapi produk yang berfungsi penuh yang dapat Anda pelajari secara perlahan. Bukan peran terakhir (jika bukan utama) dalam pilihan dimainkan oleh dukungan luas dari algoritma grafik .

---

Bagian 3. Contoh implementasi masalah langsung di Neo4j

Agar tidak menarik narasi linier tentang bagaimana model TS diimplementasikan dalam database grafik Neo4j, kami akan segera menunjukkan hasil akhir dengan sebuah contoh.

3.1. Menelusuri jalur antarmuka Iub untuk 3G BS

Rute layanan berjalan di sepanjang dua segmen - MVN yang dirutekan, dan jalur relai radio yang diaktifkan (stasiun relai radio bekerja sebagai sakelar Ethernet). Jalur melalui segmen RRL ditentukan dengan cara yang sama seperti yang dijelaskan pada Bagian 2 - dengan melewatkan VlanID antarmuka BS di sepanjang segmen RRL ke router perbatasan MVN. Segmen MVN menghubungkan router perbatasan (dengan segmen RRL) - dengan router tempat pengontrol BS (RNC) terhubung.



Awalnya, dari parameter Iub, kita tahu persis MVN mana yang merupakan gateway untuk BS (MVN batas), dan kontroler mana yang dilayani oleh BS.



Berdasarkan kondisi awal ini, kami akan membuat 2 kueri ke database untuk setiap segmen. Semua pertanyaan ke database dibangun dalam bahasa Cypher... Agar tidak terganggu oleh deskripsinya sekarang, anggap saja sebagai "SQL untuk grafik".

3.1.1. Segmen RRL. Jalur VlanID

Permintaan Cypher untuk melacak jalur layanan berdasarkan data topologi VlanID dan L2 yang tersedia:



Seperti yang Anda lihat, jalur telah diperoleh, meskipun sebagian data kurang. Dalam hal ini, tidak ada informasi tentang persimpangan port BS dengan port stasiun relai radio.

3.1.2. Segmen RRL. Jalur topologi L2

Katakanlah upaya dilakukan dalam klausul 3.1.1. gagal karena tidak adanya data lengkap atau sebagian pada parameter VlanID. Dengan kata lain, rantai kontinu seperti itu yang mencapai simpul MVN tidak dibangun:



Kemudian Anda dapat mencoba untuk menetapkan koneksi layanan sebagai jalur terpendek ke MVN menurut topologi L2:



Seperti yang Anda lihat, hasil yang sama diperoleh. Di sini, kurangnya informasi tentang persimpangan BS dengan RRS dibuat dengan melewatkan koneksi melalui objek (node) dari situs tempat mereka berada. Tentu saja, keakuratan metode ini akan berkurang secara umum, Vlan mungkin tidak terdaftar di sepanjang jalur terpendek yang disarankan oleh algoritma Dijkstra. Tetapi permintaan tersebut hanya terdiri dari dua operasi.

3.1.3 segmen MVN. Menelusuri jalur dari MVN batas ke pengontrol

Di sini kami juga menggunakan algoritma Dijkstra.



Demikian juga, dalam kasus ini, tidak ada informasi tentang sambungan langsung MVN dengan RNC. Tapi ini tidak mencegah Anda membangun jalur layanan, bahkan jika diasumsikan oleh algoritme (lebih lanjut tentang itu nanti).

3.2. Biaya tenaga kerja

Implementasi Masalah Langsung, yang ditunjukkan sekarang, sangat berbeda dari pendekatan "mengembangkan algoritme, program, metode penyimpanan dan pengambilan hasil" - semuanya bermuara pada "menulis kueri ke database". Ke depan, kami mencatat bahwa seluruh siklus mulai dari mengembangkan model grafik sederhana, memuat data ke Neo4j dari database relasional, menulis kueri, dan hingga hasilnya diperoleh, memakan waktu total satu hari.



3-4 bulan vs 1 hari !!! Ini adalah alasan terakhir untuk keberangkatan terakhir ke database grafik.

---

Bagian 4. Grafik database Neo4j dan memuat data ke dalamnya

4.1. Perbandingan database relasional dan grafik

4.2. Model data

Model dasar presentasi TS hingga level topologi L3 termasuk:





Tentu saja, modelnya lebih luas daripada yang disajikan, dan juga berisi layanan MPLS dan antarmuka virtual, tetapi untuk kesederhanaan, kami akan mempertimbangkan fragmen terbatas.



Dalam model seperti itu, hubungan antara dua elemen jaringan dari region yang sama dapat direpresentasikan sebagai:

4.3. Memuat data

Kami memuat data dari database parameter dan topologi kendaraan. Untuk memuat ke Neo4j dari database SQL, pustaka APOC digunakan - apoc.load.jdbc , yang mengambil string koneksi ke RDBMS dan teks kueri SQL sebagai masukan, dan mengembalikan sekumpulan string yang dipetakan ke node, tautan, atau parameter melalui ekspresi CYHPER. Operasi seperti itu dilakukan lapis demi lapis untuk setiap jenis objek model.



Misalnya, izin untuk memuat / memperbarui node yang mewakili elemen jaringan (Node):



Dan seterusnya - di semua tingkat model TS.



Bidang Diperbarui digunakan untuk mengontrol relevansi data di kolom - objek yang tidak diperbarui lebih lama dari periode tertentu akan dihapus.

---

Bagian 5. Memecahkan masalah terbalik di Neo4j

Saat kami pertama kali memulai, ekspresi "layanan pelacakan" pertama kali memunculkan asosiasi berikut:





Artinya, jalur layanan saat ini dilacak secara langsung, pada waktu tertentu.



Ini tidak persis seperti yang kita miliki dalam database grafik. Di GDB, layanan dilacak sesuai dengan hubungan objek yang menentukan konfigurasinya di setiap elemen jaringan yang terlibat. Artinya, konfigurasi direpresentasikan dalam bentuk model grafik , dan jejak yang dihasilkan adalah melewati model yang mewakili konfigurasi ini.



Karena, tidak seperti segmen yang diaktifkan, rute layanan aktual di segmen mpls ditentukan oleh protokol dinamis, kami harus menerima beberapa ...

5.1. Asumsi untuk Segmen yang Diarahkan

Karena dari data konfigurasi layanan mpls, tidak mungkin untuk menentukan jalur yang tepat melalui segmen yang dikendalikan oleh protokol routing dinamis (terutama jika Teknik Lalu Lintas digunakan) - untuk solusinya, algoritma Dijkstra digunakan.

Ya, ada sistem manajemen yang dapat menyediakan jalur layanan LSP yang sebenarnya melalui antarmuka NBI, tetapi sejauh ini kami hanya memiliki satu vendor seperti itu, dan terdapat lebih dari satu vendor di segmen MVN.



Ya, ada sistem untuk menganalisis protokol perutean dalam AS, yang, dengan mendengarkan pertukaran protokol IGP, dapat menentukan rute saat ini dari awalan yang diinginkan. Tetapi ada sistem seperti itu - seperti Boeing yang jatuh, dan mengingat bahwa sistem seperti itu perlu diterapkan pada semua AS dari lubang belakang seluler yang sama - biaya solusi, bersama dengan semua lisensi, adalah biaya sebuah Boeing yang ditembak jatuh oleh jembatan besi yang diikat ke roket Angara ketika bahan bakar terisi penuh. Dan ini terlepas dari kenyataan bahwa sistem seperti itu tidak sepenuhnya menyelesaikan masalah penghitungan rute melalui beberapa AS menggunakan BGP.



Oleh karena itu - sejauh ini. Tentu saja, kami menambahkan beberapa props ke kondisi algoritme Dijkstra standar:

• Akuntansi status antarmuka / port. Tautan yang terputus meningkatkan biaya dan menuju ke ujung opsi jalur yang memungkinkan.
• Akuntansi untuk status tautan cadangan. Menurut sistem Pemantauan Kinerja, kehadiran hanya lalu lintas keepalive di saluran mpls dihitung, masing-masing, biaya saluran tersebut juga meningkat.

5.2. Bagaimana mengatasi masalah terbalik di Neo4j

Peringatan. Tugas kebalikannya adalah mendapatkan daftar layanan yang bergantung pada saluran atau node tertentu dari jaringan transportasi (TS).

5.2.1. Segmen L2 yang diganti

Untuk segmen yang diaktifkan, di mana jalur layanan dan konfigurasi layanan secara praktis sama, masalahnya masih dapat diselesaikan melalui permintaan CYPHER. Misalnya, untuk penerbangan relai radio dari hasil pemecahan masalah Langsung pada klausul 3.1.1., Kami akan membuat permintaan dari modem tautan relai radio - kami akan "memperluas" semua rantai Vlan yang melewatinya:

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

Node merah menunjukkan modem yang Vlan-nya kami terapkan. 3 BS dilingkari, sebagai hasilnya, penyebaran transit Vlan dengan Modem1 dipimpin.





Pendekatan ini memiliki beberapa masalah:

• Vlan yang dikonfigurasi harus dikenal untuk port dan dimuat ke model.
• Karena kemungkinan fragmentasi, rantai Vlan tidak selalu keluar ke simpul terminal
• Tidak mungkin untuk menentukan apakah simpul terakhir dalam rantai Vlan milik simpul terminal atau jika layanan benar-benar berlanjut.

Artinya, akan selalu lebih mudah untuk melacak layanan antara node akhir / titik segmennya, daripada dari "tengah" sembarang, dan dari satu lapisan OSI.

5.2.2. Segmen yang dirutekan

Dengan segmen yang dirutekan, seperti yang telah dijelaskan di klausul 5.1, tidak perlu memilih - tidak ada cara untuk menyelesaikan masalah terbalik berdasarkan data konfigurasi saat ini dari beberapa tautan MPLS perantara - konfigurasi tidak secara eksplisit menentukan jejak layanan.

5.3. Keputusan

Keputusan diambil sebagai berikut.

• Pemuatan penuh model kendaraan dilakukan, termasuk BS dan pengontrol
• Untuk semua BS, masalah langsung diselesaikan - penelusuran layanan Iub, S1 dari BS ke MVN batas, dan kemudian dari MVN batas ke pengontrol atau gateway yang sesuai.
• Hasil pelacakan ditulis ke database SQL biasa dalam format: Nama BS - larik elemen jalur layanan

Oleh karena itu, ketika mengakses database dengan kondisi Node TS atau Node TS + Port, daftar layanan (BS) dikembalikan, larik jalur yang berisi Node atau Node + Port yang diperlukan.

---

Bagian 6. Hasil dan kesimpulan

6.1. hasil

Hasilnya, sistem bekerja sebagai berikut:





Saat ini, untuk memecahkan masalah langsung, yaitu ketika menganalisis penyebab degradasi layanan individu, aplikasi web dikembangkan yang menunjukkan hasil jejak (jalur) dari Neo4j, dengan data yang ditumpangkan pada kualitas dan kinerja masing-masing bagian jalur.





Untuk mendapatkan daftar layanan yang bergantung pada node atau saluran TS (solusi dari masalah terbalik), API untuk sistem eksternal (khususnya, Perbaikan) dikembangkan.

6.2. kesimpulan

• Kedua solusi tersebut meningkatkan otomatisasi analisis kualitas layanan dan jaringan transportasi ke tingkat yang baru secara kualitatif.
• Selain itu, dengan adanya data siap pakai pada rute layanan BS, menjadi mungkin untuk menyediakan data dengan cepat untuk unit bisnis tentang kemungkinan teknis termasuk klien B2B di lokasi tertentu - dalam hal kapasitas dan kualitas rute.
• Neo4j telah membuktikan dirinya sebagai alat yang sangat ampuh untuk memecahkan masalah grafik jaringan. Solusinya didokumentasikan dengan baik , mendapat dukungan luas di berbagai komunitas pengembang, dan terus dikembangkan dan ditingkatkan.

6.3. Rencana

Kami punya rencana:

• perluasan segmen teknologi yang dimodelkan dalam database Neo4j
• pengembangan dan implementasi algoritma pelacakan untuk layanan broadband
• peningkatan kinerja platform server

Terima kasih atas perhatian Anda!