[Friday, 05 February 2016], Ernest napisał(a):
W dniu 02/05/2016 o 01:19 PM, Jaroslaw Dziubek pisze:
Nie kasuje tekstu zeby bylo mozna ogarnac calosc ;)
Dla uzupełnienia:
- Obiekty - netobjects
- Kable - netcables
- Połączenia - netconnects
- Elementy - netobjectelements
[Friday, 05 February 2016], Ernest napisał(a):
W dniu 02/05/2016 o 10:38 AM, Jaroslaw Dziubek pisze:
Jak widać na demo jest jakiś zarys paszportyzacji jednak jak zacząłem wprowadzać dane okazało się, że pierwotne założenia mało odpowiadają rzeczywistości (wynika to m.in. z faktu, że sam dopiero startuje ze światłowodowami).
Nowa koncepcja:
- Obiekty sieciowe
- typ: mufa/przełącznica/docelowo również obiekty do obsługi miedzi (np. patchpanel)
- obiekt musi byc przypisany do węzła sieciowego
- pozostałe dane: producent, model, pojemność (ilość portów)
- Kable
- medium: światłowód/miedź
- typ: dla światłowodu: jednotubowy, wielotubowy, łatwego dostępu, splitter optyczny
- węzeł źródłowy
- węzeł docelowy
- pozostałe dane: producent, model, ilość włókien, długość
- Połączenia
- rodzaj: stałe (spaw), rozłączalne (wtyk)
- rodzaj: simplex/dumplex (spaw to zawsze simplex)
- strona1:
lub
- wtyk: adapter (FC/ST/SC/LC), konektor (FLAT/PC/UPC/APC)
- kabel1 (kabel:tuba:włókno), kabel2 (jesli duplex)
- strona2:
- jesli to spaw - kabel2
- jesli 2 konektor to połączenie jest patchcordem
- dane dodatkowe (uwagi, plik z pomiarami)
- Elementy obiektów sieciowych:
- połączenia (np. kabel lub splitter z dospawanym pigtailem, patchcord)
- numer portu (w przypadku mufy - można to wykorzystać do numeru tacki)
I teraz dla przełącznicy:
- przełącznica na start jest pusta
- podpinamy do węzła z przełącznicą kable - kabel1 i kabel2
- robimy połączenie - kabel1+pigtail (np. simplex SC/APC) i kabel2+pigtail (oczywiśnie pojedyncze włókno)
- konektor #1 dopinamy do portu #1 - widać że coś jest wpięte, ale port jest nadal wolny
- konektor #2 dopinamy do portu #1 - w tej chwili mamy pełne połączenie
Zastanawiałem się nad tym jak to można zrobić i idealnie byłoby wyszczególnić wszystkie połączenia w przełącznicy na zasadzie: definiujemy zainstalowane kable(liniowe, pigtaile, patchcordy) można jako wskazania do typu (co załatwi parametry kabla /ilość włókien,tub,rodzaj,złączy,etc/)
Kable definiujac w netcables odnosisz do obiektów z netobjects (jako początek i koniec). Teraz do kabla na końcu dokładasz albo drugi kabel (spaw w netconects+mufa w netobjects) albo pigtail (definiowany w netconnects+przełącznica w netobjects) - oczywiście każde włókno to osobny rekord.
następnie robimy połączenia wg schematu src(kabel_id, nr_włókna),dst(kabel_id, nr_włókna), id_tacki, typ_złącza,
Ja planuje dołożyć jeszcze nr tuby.
Słusznie ;)
pozycja_na_tacy/nr_portu, id_przełącznicy jeżeli id_tacki==0 to połączenie zewnętrzne
Zewnętrzne w jakim sensie?
Pomiędzy np przełącznicami (przeł1/p1 <=> przeł2/p2)
Nie ma znaczenia czy patchcordem krosujesz w jednej przełącznicy czy między 2-oma - zawsze musi być zdefiniowany patchcord łączący 2 porty.
Czyli na połączenie pomiędzy kablem zewn i portem przełącznicy potrzebujemy 2 rekordy 1) dla połączenia kabla z pigtailem
To byłoby w tabeli "netconnect" gdzie jednym parametrem bylby
2) dla połaczenia pigtaila z portem przełącznicyGotowy pigtail z netconnects wrzucasz do netobjectelements
Jest tylko problem jak to w miarę czytelnie przedstawić bo na tabelkach ja tego nie widzę ;(
Mniej-wiecej jak powyzej :)
Dla mufy będzie prościej
- do węzła 2 kable
- spawamy 2 kable ze sobą i podajemy numer tacki
W każdym przypadku proponuję przewidzieć możliwość spawania więcej niż jednego kabla.
Ze sobą?? Każdy obiekt ma pojemność - liczba portów albo liczba spawów
- oba powinny odnosić się do tabeli netconnect
Zgadzam się, ale często spawa się (w mufie lub przełącznicy) klika kabli na siebie (więcej niż 2)
Możesz to wyjaśnić (jak już pisałem - pierwsze poważne spawania przede mną) - co rozumiesz pod pojęciem "spawanie kilku kabli na siebie"
Splitter podpinamy identycznie jak kabel - mamy pigtail na końcu ze złączem i wpinamy w odpowiedni port do przełącznicy (albo spawamy z kablem i do mufy)
Każde połączenie docelowo może byc wpięte do urządzenia, którego definicja będzie przerobiona - każde urządzenie będzie miało 3 rodzaje portów:
- miedziane - wykorzystywane jak dotychczas
- światłowodowe - do którego będzie można wpiąć połączenie światłowodowe definiując pozostałe parametry (WDM, GPON, itp)
- radiowe - standardowo p2p, chyba, że będzie zdefiniowany sektor radiowy (wtedy będzie to połączenie p2m)
Gdzie będą zapisywane rodzaje portów urządzeń i jak to będzie powiązane z dotychczasowa definicją urządzenia? Druga rzecz to może zrobić otwartą listę typów portów z parametrami (w sensie wrzucić to do bazy jako słownik i jeśli ktoś będzie potrzebował jakiś nietypowy to sobie dorzuci)
To na razie bardzo luzna koncepcja - będą po prostu 3 typy portów ;)
Bardziej chodziło mi o to, żeby nie tworzyć kolumn typ1, typ2, typ3 bo za chwilę okaże się, że trzeba jakiś inny typ portu .
Ja bym to widział raczej jako wydzielona tabela: netports gdzie byłoby oprocz odniesienia do urządzenia - ilość i rodzaj portu definiowany z jakiejś biblioteki
Dla mnie przydatne byłoby mieszanie typów w jednym urządzeniu (pewnie większość już zetknęła się ze switchami utp/sfp (24UTP+4SFP)==28; albo bramkami VOIP: 1UTP+2voice==3)
Swego czasu kombinowałem ze swoim systemem i miałem to zrobione tak, że w momencie dodawania urządzenia definiowałem 2 tabele 1(urządzenia) i 2(zadeklarowane porty jako lista wskazań na urządzenie).
Nie ma potrzeby - w tej chwili mam netdevlinks i tam można spokojnie to wciskac ;)
Jeżeli przerabiasz core to chyba nie ma potrzeby mnożyć tabel z połączeniami i zrobić jedną ale za to porządną do połączeń logicznych i fizycznych.
Generalnie dlatego jest ta dyskusja (poprzednio nikt się nie zainteresował)
W aktualnym LMS boli mnie np niemożność połączenia routera(4porty ethenet) ze switchem(na 4 porty) albo połączenia fizycznych portów na switchach ale w trybie bonding/trunk lub implementacja MSTP w LMS jest nie do zrobienia(kilka kabli pomiędzy 2 urządzeniami).
W przypadku światłowodów to dość częste - wtyki i kable dupleksowe ;)
Sieci ewoluują i niestety to co wczoraj wydawało się co najmniej dziwne dziś jest codziennością. Prace z bazami danych za to nauczyły mnie maksymalnie grupować podobne/identyczne elementy. Jak Chilan zauważył ze tabela netobjects jest podobna do nodes.
Mam podejrzenie graniczące z pewnością, że oboje mówicie o netnodes a nie o nodes :)
Może ogólnie potraktować sprzęt jako sprzęt bez rozróżnienia na aktywny/pasywny (ew flagą), do niego przypisywać porty, IPki, sieci, klientów, instalacje ;).
Prędzej netdevices bym połączył z netobjects - jak pisałem netnodes to węzeł a w nim mogą być i urządzenia aktywne i pasywne. Nie można ograniczyć węzła (netnodes) do jednego urządzenia.
Zakładając połączenie netobjects i netdevices: - dodajemy pole "pasywne/aktywne" - pole "ports" pozostaje i oznacza na razie po prostu dla pasywnych pojemność tacek na spawy (dla muf) albo ilość poł na adaptery (dla przełącznic) - jeśli założymy, że urządzenie musi być w węźle (co jest dość ryzykowane bo sam uzywam netdevices do wrzucania urządzeń klienckiech do których dopiero podpinam komputery klientó) możnaby wywalić wszelkie pola odnośnie lokalizacji. - opcjonalnie można wogóle zrobić nową tabele "locations" w której będziemy wrzucać kompletne dane lokalizacyjne (adres, teryt i GPS) i dopiero do tych rekordów dawać odnośniki wszędzie.
Tylko to jest tak naprawdę przepisanie całości od nowa i to robota na klika ładnych miesięcy dla kilku osób.
Generalnie i tak chce troche przebudować LMS :)
Minusem tego była objętość bazy gdzie niezależnie od tego czy port jest zajęty to jest w bazie. Plusem za to jest łatwość kreowania połączeń bo to tylko wskazanie port-port oraz uniwersalność podejścia (kwestia zmiany typu portu i możesz podłączyć np telefon no i sprawdzić kompatybilność łączonych portów).
Narzędzia sie później dorobi (chociażby przepinanie na szybko w przełącznicy czy wrzucanie do bazy np. kompletnego splittera z wtyczkami :)
Widzę tylko problem jak toto zaimplementować we wtyczce LMSa ;( chyba że jako osobny moduł a nie wtyczka
Czekam na uwagi (zwłaszcza od osób, które mają światłowody i spojrzą od strony praktycznej)
Jak rozumiem robisz wtyczkę do całościowej obsługi paszportyzacji?
To nie będzie wtyczka - to będzie w core LMS :)
I słusznie, tylko w wersji normalnej czy plus ;)
Normalnej - była zrzutka, ale nie doceniłem rozległości tematu ;)