5 Lut
2016
5 Lut
'16
20:25
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: > > >>> - 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. 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łą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" 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 chce > http://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