W dniu 05.02.2016 22:33, ernest napisał(a):
On Fri, 05 Feb 2016 22:12:44 +0100 Tomasz Chiliński <tomasz.chilinski@chilan.com> wrote
[Friday, 05 February 2016], ernest napisał(a):
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
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
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. Chodzi Ci o to, że spawasz 2 włókna na stałe bez wyjścia na port z przodu? Teoretycznie to funkcjonalność mufy - myślałem o zrobieniu mufo-przełącznicy i wychodzi, że trzeba będzie to uwzględnić.
>>> 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ąć
W dniu 05.02.2016 21:03, Jaroslaw Dziubek napisał(a): porty. przede 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
>> Druga rzecz to może zrobić otwartą listę typów portów z >
> 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
powiązane > >> z dotychczasowa definicją urządzenia? parametrami (w > >> sensie wrzucić to do bazy jako słownik i jeśli ktoś będzie > potrzebował > >> jakiś nietypowy to sobie dorzuci) porty byłyby już wpisane do tabeli, Wystarczy wtedy policzyć ilość wpisów z danego typu i/lub urządzenia Niekoniecznie - same porty będą opisywane: typ_portu,ilość. Zajętość będziesz brał z netconnects (netlinks czy czegos w tym rodzaju)
Porty urządzeń, tak jak już pisałem, najlepiej żeby były kopiowane z modelu urządzenia - dzięki temu od razu po dodaniu nowego urządzenia będzie obecny standardowy dla danego modelu zestaw portów, a porty w takim wydaniu nie powinny mieć numerów tylko etykiety tekstowe, bo każdy producent może inaczej je nazywać. Tylko to chyba będzie wymuszało wpisywanie wszystkich portów do tabeli przy "instalacji" nowego urządzenia, ale wg mnie pomysł jest dobry.
No tak. Kopiowanie informacji o portach z modelu do urządzenia. Ewentualnie jeśli dany model ma swoje "wcielenia" w postaci urządzeń to zabronić edycji portów w takim modelu.
Tylko jeszcze doprowadzić do sytuacji, kiedy wszystkie porty(ze wszystkich urządzeń) będą w jednej tabeli i można odpalić wybieranie portu z listy(zamiast aktualnego ręcznego wpisywania).
Tak.
Tylko Tomku jak to zrobić żeby nie rozwalić bieżących instalacji LMS`a/zapewnić bezbolesną migrację/??
Normalnie - trzeba będzie przygotowywać uaktualnienia schematu migrujące dane z tabel do tabel.
Pomoc się zawsze przyda (mam na głowie 2 inne projekty + odpalenie GPON z TV + bieżąca działalność) :)
Z mojej strony możesz liczyć na dofinansowanie prac. Tak trochę offtop. Patrzyłeś może na mojego VOIP`a?? zostawić go jako wtyczkę czy też wrzucić jako zastępstwo aktualnego modułu? bo w planie są kolejne dodatki wymagające jego obecności (na pewno provisioning, generacja konfigów asteriska oraz (być może) billingi/to na 3 części podzielę/) przy okazji miałbyś trochę więcej danych dla PLICBD. W poniedziałek postaram się jakieś repo wyczarować.
Zaczątek na coś dobrego jest, ale właśnie to co piszesz to jest "must-have", żeby zintegrować to z lms (nie jako wtyczkę).
//Ernest
-- Pozdrawiam Tomasz Chiliński, Chilan