5 Lut
2016
5 Lut
'16
19:07
[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:
> >>> - wtyk: adapter (FC/ST/SC/LC), konektor (FLAT/PC/UPC/APC)
> >>> lub
> >>> - 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:
> >>> 1) przełącznica na start jest pusta
> >>> 2) podpinamy do węzła z przełącznicą kable - kabel1 i kabel2
> >>> 3) robimy połączenie - kabel1+pigtail (np. simplex SC/APC) i
> >>> kabel2+pigtail (oczywiśnie pojedyncze włókno)
> >>> 4) konektor #1 dopinamy do portu #1 - widać że coś jest wpięte, ale
> >>> port jest nadal wolny
> >>> 5) 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łącznicy
> > Gotowy 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
> >>> 1) do węzła 2 kable
> >>> 2) 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 ;)
--
Yaro
IRL: Jarosław Dziubek | "Większość kobiet wcale nie chce
http://yaro.perfect.net.pl/ | znać prawdy, jeśli jest niewygodna
IRC:Yaro, ICQ:1340145, GG:1392891 | lub przykra."
| L. Kroneuberger