5 Lut
2016
5 Lut
'16
19:10
W dniu 05.02.2016 19:07, Jaroslaw Dziubek napisał(a): > [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 ;) Będziemy się zrzucać dopóki nie zrobisz porządnie :) -- Pozdrawiam Tomasz Chiliński, Chilan