8 Lut
2016
8 Lut
'16
13:32
W dniu 02/08/2016 o 11:39 AM, Jaroslaw Dziubek pisze:
> [Monday, 08 February 2016], Ernest napisał(a):
>
>> W dniu 02/08/2016 o 09:18 AM, Jaroslaw Dziubek pisze:
>>> [Sunday, 07 February 2016], ernest napisał(a):
>>>
>>>> On Sun, 7 Feb 2016 11:47:06 +0100 Jaroslaw Dziubek <yaro@perfect.net.pl> wrote
>>>>
>>>>> [Sunday, 07 February 2016], ernest napisał(a):
>>>>>
>>>>>> On Sun, 7 Feb 2016 09:35:22 +0100 Jaroslaw Dziubek <yaro@perfect.net.pl>
>>>>>> wrote
>>>>>>> [Saturday, 06 February 2016], Tomasz Chiliński napisał(a):
>>>>>>>
>>>>>>>>>>> Chodziło mi o dodawanie
>>>> urządzenia(switch/przełącznica/splitter)
>>>>>> jeśli
>>>>>>>>>>> miałbyś gdzieś zdefiniowane jaką ma konfigurację to jeden
>>>> klik i
>>>>>> masz
>>>>>>>>>>> wszystkie możliwe porty dostępne do połączeń.
>>>>>>>>>>> Nie musisz za każdym razem definiować na nowo że (Switch xxx ==
>>>>>>>>>>> 12*e10/100+2*SFP+5*e1giga)
>>>>>>>>>> Spoko - takie gotowe schematy mogą być, ale IMHO nic nie zastąpi
>>>>>>>>>> elastyczności rozwiązania które zaproponowałem (można przecież
>>>>>> zrobić
>>>>>>>>>> jak pisałem automat do dodawania konkretnego zestawu portów dla
>>>>>>>>>> standardowych urządzeń).
>>>>>>>>> No można to zrobić tak jak jest teraz w netdevices
>>>> (producent/model)
>>>>>>>>> możesz
>>>>>>>>> wpisać ale możesz też wybrać ze słownika
>>>>>>>> Moim zdaniem zdecydowanie pełna definicja portów urządzenia powinna
>>>>>>>> trafić
>>>>>>>> jako rekordy w tabeli powiązanej z modelami urządzeń, bo to
>>>> naturalne.
>>>>>>>> Tworzenie nowego urządzenia i wybranie modelu powodowałoby jedno z
>>>>>>>> dwóch:
>>>>>>>> 1) Skopiowanie definicji portów do tabeli przechowującej porty
>>>>>>> powiązane > z konkretnym urządzeniem.
>>>>>>>> 2) Urządzenie na podstawie przypisanego modelu miałoby dostęp do
>>>>>>>> informacji
>>>>>>>> o posiadanych przeze nie portach (bez kopiowania definicji portów do
>>>>>>>> urządzenia).
>>>>>>>> Przy tym rozwiązaniu trzeba rozważyć czy będzie można edytować
>>>>>> definicje
>>>>>>>> portów
>>>>>>>> modelu w przypadku, gdy ma już jakieś reprezentacje w postaci
>>>> urządzeń.
>>>>>>> Nie do końca łapie Twoją propozycję: netelements + netports
>>>> (definicja
>>>>>>> pojedynczego portu) x ilosc portow w urzadzeniu?
>>>>>>> Wtedy połączenie byłoby między id_port1 a id_port2?
>>>>>> Można tak czyli w netports mialbys od razu wszystkie zadeklarowane porty
>>>>>> (opcja którą proponuję od początku) i wtedy połączenia to relacja
>>>>>> portid-portid lub w netports tylko deklaracja że typ portu x ilość i
>>>> wtedy
>>>>>> właściwa deklaracja portu następowałaby dopiero w chwili dodawania
>>>>>> połączenia
>>>>> Jesli porty mialyby byc definiowane od razu to baza bylaby dosc duza -
>>>>> przelacznica 144 porty to od reki 144 rekordy ;)
>>>> tylko od ręki masz info do czego jest podłączony każdy port zaś sama
>>>> ilość rekordów przy dobrze zrobionych indexach to jest nic.
>>>> Co miesiąc obrabiam tabelę z ~100M rekordów i wyciągam z niej dane w kilka
>>>> sekund dość specyficznym zapytaniem złożonym chyba z 7 joinów i kilku
>>>> warunków a tutaj będzie co najwyżej dwa złączenia i rekordów tyle co
>>>> portów globalnie (przy 100switchy 24p będziesz miał 2400 rekordów co nie
>>>> jest zabójcze jakoś myślę, że spokojnie do 100k-200k rekordów będzie
>>>> można pracować swobodnie).
>>>>
>>>>> Pytanie jak robimy netconnections. W tej chwili mamy netlinks ktore ma
>>>>> id_urzadzenia1, id_urzadzenia2 + numery portów w tych urzadzeniach +
>>>>> opis medium i predkosci.
>>>> Przy połączeniu id_port-id_port zostaje do połączenia dołożyć:
>>>> link_type, link_tech, link_speed, długość(przydatne np na serwerowni i
>>>> opcjonalnie: id_kabel, tuba, włókno.
>>>> Można też pierwsze 3 parametry połączenia przypisać do definicji portu.
>>>>> Wydaje sie, ze trzebaby to podzielic na 2 rodzaje: fizyczne i logiczne
>>>>> (wtedy identycznie z netelements robimy 2 widoki).
>>>>>
>>>>> Połączenie fizyczne łączyłoby (w przypadku światłowodów):
>>>>> - port w przełącznicy/urządzeniu z portem w przełącznicy/urządzeniu
>>>> (czyli
>>>>> patchcord). - port w przełącznicy/urządzeniu z kablem (czyli pigtail)
>>>>> - kabel z kablem (czyli spaw)
>>>>> W przypadku miedzi:
>>>>> - port w urządzeniu/patchpanelu z portem w urządzeniu/patchpanelu
>>>> (patchcord)
>>>>> - kabel z portem w urządzeniu/patchpanelu
>>>>> - kabel z kablem (beczka?)
>>>>>
>>>>> Logiczne (to na przyszłość):
>>>>> - miedziane i radiowe p2p - porty w 2 urządzeniach
>>>>> - radiowe m2p - port w urządzeniu w sektorem radiowym
>>>>>
>>>>> Opis połączenia (zakładam, że każdy port będzie osobnym rekordem)
>>>>> - id_kabel1+tuba1+włókno1
>>>>> - id_kabel2+tuba2+włókno2
>>>>> - id_konektor1 (można brać z bazy typów konektorów albo ze słownika) +
>>>>> id_port1 - id_konektor2 + id_port2 (j.w.)
>>>>> - opis + plik z pomiarami spawu
>>>>> Przykłady (co niewymienione jest null):
>>>>> - id_kabel1+id_kabel2+id_port1 not null - spaw
>>>>> - id_kabel1+id_konektor2+id_port2 not null - kabel1+pigtail w port2
>>>>> - konektor1+port1+konektor2+port2 not null - patchcord między port1 i port2
>>>>> - id_kabel1+id_kabel2+id_konektor1+id_port1 - wtyk duplex w port1
>>>>>
>>>> To chyba jeszcze bardziej uprościłoby sprawę potraktowanie kabla jako
>>>> urządzenia z ilością portów.
>>>> Czyli miałbyś tabele:
>>>> --netelements ze znacznikami aktywny/pasywny,
>>>> grupa(kabelFO/kabelCU/kabelUTP/taca/przełącznica/mufa/swictch/kowerter/bramkaVOIP/),
>>>> długość(w przypadku grupy kable), lokalizacja końcówek(może być
>>>> ustawiona jedna)
>>> Hmm.. Ja bym to widział tak:
>>> - aktywny/pasywny
>>> - grupa:
>>> - aktywny - w zasadzie każde urządzenie powinno być trakowane tak
>>> samo - jako zestaw portów
>>> - pasywny - tutaj tak samo - kwestia jak rozwiązać sprawę tacek na
>>> spawy, ale to tylko byc może kwestia ograniczenia sie do
>>> pojemności tacki i numeru (wystarczy informacja, ze spaw jest na
>>> 2. tacce)
>> Jeśli potraktujesz mufę i przełącznicę tak samo to nie ma większego
>> problemu, tyle że przełącznica to tak naprawdę mufa(tacki ze spawami) +
>> porty rozłączalne czyli trzeba by potraktować przełącznicę jak 2
>> urządzenia i robić spaw kabel-kabel lub kabel-pigtail(port) i wychodzi
>> na to, że przełącznicę trzeba potraktować tak: pojemność tacek + porty
>> na froncie
>> albo
>> jako blackbox i (nie przejmując się tackami) zestawiać połączenia
>> kabel_a <=> kabel_b z opcjonalnym wskazaniem na nr portu
>> /coś jakby przełącznicę postawić obok zestawu połączeń/ tylko wtedy
>> problemem są porty w przełącznicy, które są obsadzone z jednej
>> strony(pospawane)
>> ( nie przejmować się inwentaryzacją spawów co w działającej sieci ze
>> sporą ilością przeróbek jest bardzo utrudnione)
> Ja u siebie wychodze z zalozenia, ze lepiej pomeczyc sie raz przy
> dodawaniu/zmianach niz potem spedzic kilka(nascie) minut na szukaniu
> "skad ten kabel przychodzi i gdzie idzie". Samego spawu pewnie nie da
> sie oznaczyć, ale już spokojnie kabel wchodzący do przełącznicy
> ometkowac i później w LMS szukać tylko etykiety (masz nazwe kabla,
> numer/kolor tuby i numer/kolor włókna)
>
>> Jeszcze jeden pomysł (wydaje mi się, że najlepszy).
>> Gdyby tak przy łączeniach dopuścić relację wiele->jednego (jeżeli
>> "port==port przełącznicy" to dla pełnego połączenia musi mieć 2
>> wskazania w netlinks /takie porty przelotowe "dwustronne"/) to miałoby
>> zastosowanie tylko w przełącznicach i patch panelach. Łatwo wtedy
>> złapać, że port jest pospawany ale niepodłączony.
> Problem generalnie nie jest w tym co i gdzie wrzucic, ale jak
> zapanować nad tym co masz wolne - przełącznica czy mufa ma swoja
> pojemnosc i moze sie okazac, ze bedziesz chcial cos pospawac a nie
> masz juz miejsca na tackach.
>
> Ja widze 2 opcje przy przełącznicach:
> - porty i tacki definiowane osobno
> - tacki definiowane jako wolne miejsca na spawy PONAD ilosc portow
>
> Mysle, ze tacke mozna spokojnie zdefiniowac jako port o pojemnosci np.
> 12 połączeń (wtedy widać ile spawów jest zajęte) a pole komutacyjne
> jako port o pojemności 2 (czyli 2 wtyki w adapterze). Wtedy dałoby się
> to ogarnąć (dodatkowo port w urządeniu miałby pojemność 1 - jedna
> wtyczka). Samo netlinks mogłowy wtedy wskazywac tyle razy ile miałby
> pojemności port (warto pewnie oznaczać przy portach
> przełącznicy/patchpanelu czy wtyczka "wchodzi" od tylu czy przodu)
>
> Czyli:
> - port definiujemy jako SC/APC
> - do niego wpinamy netlinks:
> - kabel1+id_port oraz jako 2. rekord kabel2+id_port (wtedy port jest zajety i mamy pelne polaczenie)
> - kabel1+id_port - mamy port gotowy do podlaczenia czegos
> - id_port1+id_port2 - patchcord między portami
odnośnie patchcordów często przydatna jest informacja o długości
Czyli tak dla podsumowania:
w netelements lądują: switch, kabel, przełącznica,
urządzenie_klienckie(instalacja)(?), stacja_bazowa, spliter
netelements: producent, model, typ(Akt./Pas.), właściciel,
lokalizacja(?), lokalizacja_b(?), długość, projekt_UE, netnodeid
porttyp: (słownik)technologia, lambda/częstotliwość
złącze: (słownik) /przewiduję złącze spaw/
netelemports: (tyle rekordów ile zadeklarowanych portów łącznie z
komutacją na tackach ale globalnie)
a) switch: złącze, porttyp, uplink,
etykieta, max_prędkość, ilość_dowiązań=1
b) kabel: tuba/wiązka, włókno/para,
ilość_dowiązań=2
c) przełącznica: złącze, porttyp, uplink=null,
etykieta, ilość_dowiązań=2
d) urządzenia_klienckie: złącze, porttyp, uplink=null?,
etykieta, max_prędkość, ilość_dowiązań=1
e) stacja_bazowa: złącze, porttyp, uplink, etykieta,
max_prędkość, ilość_dowiązań=1 (lub "n" w przyp radio)
f) spliter: złącze, porttyp, uplink,
etykieta, podział, ilość_dowiązań=1
Qrde kable się z tego wyłamują
Chyba, że zrobić tabele:
netcables( Producent, model, lokalizacja_a, lokalizacja_b, długość)
netcablewires: tuba/wiązka, włókno/para, medium?(są kable mieszane
Cu/FO)
Wtedy:
netlinks: netelemport_a, netelemport_b, netcablewires(jeśli 0 to
patchcord), długość(jeśli 0 to długość kabla)
>
> Nadal pozostaje pytanie o netlinks. Ja bym się trzymał mojego pomysłu,
> ze mozemy miec:
> - 2* kabel
> - 2* port
> Co nam umozliwi zdefiniowanie wszystkich mozliwosci - od spawu (wtedy
> id_port oznacza tacke spawow) po patchcord (kable ustawione na null)
>
>
>
>>> - kabel:
>>> - medium (optyka/miedź)
>>> - rodzaj (dla optyki: jednotubowy, wielotubowy, KLD, splitter)
>> dla miedzi też proponuję jakieś parametry np UTP, FTP, skrętka
>> telefoniczna wieloparowa
> Jasne - na miedzi sie nie skupiam bo to generalnie bedzie duzo
> prostsze do opisania (tutaj bedzie tez np. koncentryk)
>
>>> - długość (dla splittera - podział x:y)
>>> - lokalizacja (węzeł) - w przypadku kabla to 2 lokalizacje
>>>
>>> Z tym, że parametry w osobnych tabelach: netelemactive,
>>> netelempassive, netelemcable
>>>
>>>> --netelemports: id, id_netelements, nr_tuby/wiązki, nr_włókna/pary,
>>>> typ_złącza(ze słownika)
>>> Do tego etykieta_portu.
>>>
>>> Problem bedzie wtedy będziesz chciał spiąć 2 kable ze sobą w
>>> przełącznicy na porcie (powiedzmy 5) - jeden kabel normalnie oznaczysz
>>> na porcie, ale drugiego nie będzie jak wpiąć bo port już będzie
>>> zapięty. Gdybyś wpiął go do innego portu w przełącznicy - to OK
>>> zepniesz patchcordem z netlinks, ale bezpośrednio się nie da.
>>>> --netlinks: netelemports_id, netelemports_id,
>>>> link_type(rozłączne/nierozłączne), opcjonalnie(link_speed, link_tech,
>>>> length)
>>> Pytanie najważniejsze: jak chcemy oznaczać połączenia logiczne w
>>> stoѕunku do fizycznych. Teoretycznie można przyjąć, że mając
>>> połączenie fizyczne między portem A urzadzenia 1 a portem B
>>> urządzeniam 2 to wybieramy najniższe z możliwych połączeń
>>> (przykładowo łączysz port 1000BaseTX z portem 100BaseTX to połączenie
>>> będzie 100Mbit/s FD, a np. przy połączeniu radiowym między 802.11a a
>>> 802.11ac MIMO 2x2 - jedynie 54Mbit/s) i raczej nie powinno to być
>>> oznaczane w netlinks bo później wychodzą jakies bzdury.
>> Nie do końca. Wiadomo, że wybierając połączenie
>> 802.11ac(klient)->802.11a(stacja) będziesz miał 54Mbps ale w drugą
>> stronę (przy p2mp) do urządzenia 802.11ac możesz podpiąć 802.11ac/n/a i
>> to w zależności od tego jakie będziesz miał parametry sygnału możesz
>> ograniczyć prędkość ;)
> W przypadku radia nigdy nie osiągniesz pełnej przepustowości, ale
> zakładając że masz 2 końce (nawet przy p2mp) to bierzesz prędkość
> wolniejszego końca (klient ac wpięty do nadajnika an nadal będzie
> działał jako an :)
>
>>>> Trochę kombinacji byłoby w przypadku połączeń portów z różnymi
>>>> złączami np SC-PC<=>SC-APC (to wymagałoby zdefinowania patchcordu w
>>>> netelements)
>>> A to akurat nie problem - skoro port1 to SC/APC a port2 to LC/PC
>>> (ekstremalne wiem) to kabel łączący będzie to spełniał :)
>>>
>>>> podobnie byłoby z portami SFP (chyba że od razu definiujemy
>>>> SFP_UTP, SFP_SC-PC, etc albo mapę wyjątków)
>>> SFP i SFP+ to inna bajka - skoro mamy typ_złącza (ze słownika) to nie
>>> problem w słowniku (albo nawet w osobnej tabeli) zdefiniować dany typ
>>> wkładki (od razu definiując typ gniazda i możliwą predkość - np.
>>> wkładka SFP+ firmy xx to duplex LC/APC i prędkość 10Gbit, a wkładka
>>> SFP firmy yy to WDM czyli simplex LC/APC i prędkość 1Gbit)
>> Tak, tylko to daje dodatkowe urządzenie pt. wkładka SFP (2porty a-SFP,
>> b-SC/PC) i dopiero to łączysz (ale może to i dobrze bo pozwoli na pełną
>> inwentaryzację sprzętu)
> Wiesz - pusty port SFP bylby pustym portem SFP (bez opisu gniazda,
> predkosci itp) - dopiero włożenie wkładki "wypełnia" opis portu
> odpowienimi parametrami.
Myślę, że to dość dobry pomysł (nie komplikuje relacji w bazie)
>
>>>> Przy połączeniach radiowych p2mp proponuję założyć ilość klientów do
>>>> podpięcia jako ilość portów.
>>> Nie - niech to będzie otwarte - podłączasz wtedy pod port radiosector
>>> i masz zasięg, a podłączasz ile chcesz.
>> Ale wtedy wywali się pomysł połączeń port-port zresztą każda stacja
>> bazowa ma określoną pojemność optymalną i maksymalną (literatura przy
>> 2.4G podawała 16 /max 32/) to i tak byłyby porty wirtualne.
>> Można zdefiniować na jakimś wysokim poziomie np 100,150,200...
> Ja mam u siebie porty radiowe ustawione na 41 (40 po radiu, 1 po
> lanie), ale IMHO to zly pomysl - wolalbym uniknac taki ograniczeń.
> Oczywiscie kazdy moze sobie zalozyc, ze po podlaczeniu 24 klienta na
> an nalezy nadajnik "rozbic" na 2, ale to juz wola/chec uzytkownika.
> Program nie powinien blokowac tego (mozna conajwyzej zrobic
> ostrzezenie - tylko po co? :D ).
Żadne blokowanie, jeśli braknie tych wirtualnych portów to zawsze można
dołożyć (tyle że już ręcznie /nie ze schematu urządzenia/) za to
znacznie uprości zestawianie połączeń.
>
>
> Jarek
> _______________________________________________
> lms mailing list
> lms@lists.lms.org.pl
> http://lists.lms.org.pl/mailman/listinfo/lms
>
--
Pozdrawiam
Michał Szmigielski
/ernesttar/