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