On Fri, 5 Feb 2016 19:07:19 +0100 Jaroslaw Dziubek yaro@perfect.net.pl wrote
[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:
patchcord) - numer portu (w przypadku mufy - można to wykorzystać do numeru tacki) > >>>
- połączenia (np. kabel lub splitter z dospawanym pigtailem,
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.
Właśnie o to mi chodziło ;)
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"
Czasem jest konieczne pospawanie np 3kabli w jednej przełącznicy z czego z dwóch część włókien wylatuje na porty a część jest spawana "na wprost" np 1 tuba kabla 1 na 1 tube z drugiego, a 2 tuba z pierwszego na 1 tubę trzeciego i losowe włókna z każdego kabla na porty przełącznicy. Zauważ,że standardowa przełącznica 19" ma 4 mocowania na kabel.
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
Właśnie o tym pisałem poniżej (to o moich kombinacjach) ;) tyle, że nie ma wtedy potrzeby opisywać ilości portów, bo z założenia wszystkie możliwe porty byłyby już wpisane do tabeli, Wystarczy wtedy policzyć ilość wpisów z danego typu i/lub urządzenia
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ł)
Uprzednio ?? Poprzednio była dyskusja TYLKO o paszportyzacji szkła, a teraz to się robi w zasadzie pełna paszportyzacja połączeń (wszystkich rodzajów) i sprzętu ;)
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 :)
Bardziej o tabelę netdevices. Niestety poza podglądnięciem Twojego dema nie miałem możliwości pozaglądać do środka (jestem poza LMS+), ale osobiści byłbym za tym żeby jakiekolwiek urządzenia wrzucić do jednej tabeli i do tych urządzeń przypisywać inne rzeczy wg zasady Wiele do jednego a same urządzenia na tej samej zasadzie przypisywać do rekordów w netnodes.
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)
Myślę, że mogłoby to tak funkcjonować tylko jest małe ale. Nie masz możliwości mieszania typów portów a w netdevices masz też urządzenia aktywne (do tego z różnymi portami/mediami/)
- 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.
Przy takim założeniu trzebaby dołożyć kolumnę w netnodes (klient_id lub po prostu flagę że to węzeł kliencki) wtedy netnodes robiłoby za listę nazwijmy to instalacji, do takiego węzła wrzucasz sprzęt, do sprzętu przypisujesz IP(niekoniecznie jedno), telefon, VLAN, etc
- 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.
to załatwiłby Ci poprzedni schemat
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 :)
To nie jest troche ;)
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 ;)
No niestety temat jest baaaardzo rozległy, można go podzielić na mniejsze części i podzielić między sobą
-- Yaro
IRL: Jarosław Dziubek | "Większość kobiet wcale nie chcehttp://yaro.perfect.net.pl/ | znać prawdy, jeśli jest niewygodna IRC:Yaro, ICQ:1340145, GG:1392891 | lub przykra." | L. Kroneuberger _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms