[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:
- Skopiowanie definicji portów do tabeli przechowującej porty
powiązane > z konkretnym urządzeniem.
- 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) - kabel: - medium (optyka/miedź) - rodzaj (dla optyki: jednotubowy, wielotubowy, KLD, splitter) - 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.
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)
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.
Dobrze byłoby też jakoś znaczyć "master port"/uplink w kilku przypadkach będzie przydatne (splittery , radio p2mp, ja bardzo chętnie wykorzystałbym do określenia ścieżki podłączenia /od klienta końcowego do master_routera/ ;P )
Dobry pomysł.
Jarek