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)
--netelemports: id, id_netelements, nr_tuby/wiązki, nr_włókna/pary, typ_złącza(ze słownika)
--netlinks: netelemports_id, netelemports_id, link_type(rozłączne/nierozłączne), opcjonalnie(link_speed, link_tech, length)
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) podobnie byłoby z portami SFP (chyba że od razu definiujemy SFP_UTP, SFP_SC-PC, etc albo mapę wyjątków)
Przy połączeniach radiowych p2mp proponuję założyć ilość klientów do podpięcia jako ilość portów.
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 ) //Ernest
Jarek _______________________________________________ lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms