onePK - jak zostac sieciowym bogiem cisco

Swobodne rozmowy na nie-sieciowe tematy
Wiadomość
Autor
Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 400
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

#31

#31 Post autor: konradrz »

Kyniu pisze:Aplikacja kliencka się sypie bo szanowni programiści założyli że klient na odpowiedź z serwera, w dużej, rozległe sieci, gdzie aplikacja pracuje na VPN'ach pokleconych na łączach od rożnych dostawców, czeka, uwaga, ..... 25 ms po czym wywala jakieś głupie , niezrozumiałe komunikaty błędów. A co na to programiści? No że nie ich wina, bo w LAnie im działa. I to wina sieciowców że na WANie mają i do 100 ms opóźnienia
Zgoda, ale nie wiem czy zwróciłeś uwagę że ja mówiłem o intra-DC, a nie inter-DC.
Oczywiście, rozumiem że to tylko przykład -- ale z drugiej strony, jeśli nie zaczniemy od programistów więcej wymagać, to się nigdy nie nauczą.
Kyniu pisze:
Uch, jak ja mam z tymi sekjuritami na pieńku... Kompletna zgoda.
No tak, bo przecież programista nie wie na jakim porcie będzie działała jego aplikacja, nie wie jakiego protokołu będzie potrzebowała i kto to widział by blokować jakieś porty.
A tu się kompletnie nie zrozumieliśmy. Ja mam na pieńku z sekjurity nie za wymagania co do portów itd, ale za to, że każdy request idący do nich ginie w jakichś czeluściach, a po tygodniu-albo-i-więcej jest odpowiedź (czy to zgoda czy odmowa), na której to nie potrzebowali więcej niż godziny. Wiesz, w rodzaju "mamy już 50 serwerów http, chcemy dodać dwa kolejne, taka sama konfiguracja, czy możemy port 443 mieć otwarty" i na tydzień (optymistycznie) toto znika w dziale bezpieczeństwa.

A i nie róbmy z programistów idiotów. Jeśli się im powie "mają być porty a nie sokety, i mają być szczegółowo opisane itd" to oni naprawdę mogą taki kod stworzyć. Wszystko zależy jakiego project managera masz.

Awatar użytkownika
konradrz
CCIE
CCIE
Posty: 400
Rejestracja: 23 sty 2008, 14:21
Lokalizacja: Singapore, SG
Kontakt:

#32

#32 Post autor: konradrz »

lbromirs pisze:Inna sprawa, na ile "wygrzane" są te pluginy. Na razie, są żałośnie niedogrzane.
I właśnie dokładnie do tego piję. Wielcy operatorzy mogą sobie napisać poprawny kod do automagicznych zmian globalnych tabel czy nowego rozkładu ruchu po tunelach (vide B4 czy SWAN) czy czegożtam. Ale jakoś kod takiej jakości (jeszcze?) do OpenDaylightów się nie przedostał. [edit] Wydaje mi się, że po prostu dużym firmom nie opłaca się "za darmochę" takiego kodu oddawać - w końcu mogą sobie za niego ileśtam policzyć, a jak klienta stać to sobie może kupić. A jak nie stać, to niech ma hobbistycznej jakości kod (niekiedy poprawny, niekiedy - jak zauważyłeś - nie bałdzo).

Kyniu
wannabe
wannabe
Posty: 3595
Rejestracja: 04 lis 2006, 16:23
Kontakt:

#33

#33 Post autor: Kyniu »

konradrz pisze:ale z drugiej strony, jeśli nie zaczniemy od programistów więcej wymagać, to się nigdy nie nauczą.
Ależ ja im nie bronię by wreszcie pokazali co potrafią. Tylko najpierw niech pokażą.
konradrz pisze:A i nie róbmy z programistów idiotów.
To nie ja pisałem ich kod by mi teraz imputować, że robię z nich idiotów. Sami z siebie robią owocami swojej pracy.

Awatar użytkownika
maverik
member
member
Posty: 39
Rejestracja: 09 maja 2013, 14:31

#34

#34 Post autor: maverik »

Można być adminem i na potrzeby swojej firmy napisać dobry kod rozwijany w jądrze Linuksa.

http://cat.piasta.pl/dnetmap/

dorvin
CCIE
CCIE
Posty: 1688
Rejestracja: 21 sty 2008, 13:21
Lokalizacja: Wrocław
Kontakt:

#35

#35 Post autor: dorvin »

konradrz pisze:
dorvin pisze:Tylko widzisz... SDN niekiedy zaczyna być postrzegany jako sieć programowana przez programistów aplikacji (!!!).
Wiesz, tak naprawdę (w sieciach intra-DC) to się spokojnie da zrobić. Tu właśnie widzę przyszłość dla (szeroko pojętego) "prostego" SDN.
Sieciowcy prekonfigurują sieć fizyczną (underlay), robią jakieś tam założenia (dozwolone zakresy IP, zakresy VLAN/VXLAN, itd itp) - po prostu "niech se robią w tej sieci co chcą, ale tak by nie miało to szans na stworzenie problemów u innych użytkowników" i tyle. A potem app-dev już sobie "wykraja" logiczną sieć dla siebie (wewnętrznie to będzie VXLAN+VRF, ale app-dev gość nawet nie musi o tym wiedzieć).
Ale czego tak naprawdę potrzebują app-dev? 2 rzeczy: być w stanie pobrać/wysłać dane do innej maszyny oraz wykonać jakąś operację na zdalnej maszynie. Koniec. Jakoś mało tego... Dodajmy do listy potrzeby sysadmins - uruchomić nowy serwer jakiejś usługi w dowolnym miejscu sieci i żeby funkcjonował tak samo, jak wszystkie pozostałe serwery tej usługi (adresacja, VLAN, polityki FW, proxy itp.). Czy do tego potrzebują możliwości sterowania drogą, jaką obiorą pakiety w sieci? Wpływania na decyzje routingowe? Injectowania pakietów? Zwłaszcza przy Twoim założeniu, że "gość nawet nie musi o tym wiedzieć". Niech sobie mają możliwość zarejestrowania automatycznie aplikacji i niech system im ustawi odpowiednio parametry sieciowe i polityki bezpieczeństwa, ale moim zdaniem na tym powinien się skończyć ich wpływ na SDN.

Owszem, przeniesienie logiki decyzyjnej urządzeń sieciowych do scentralizowanego (załóżmy) systemu ma szanse przynieść sporo korzyści, ale wydaje mi się, że raczej poprzez ujednolicenie konfiguracji dla różnych platform, a nie możliwość zaawansowanego sterowania przez aplikację.

Przy odpowiednio skonstruowanej sieci fizycznej (pasmo, latency) jak najbardziej to może działać.
Będzie działać, póki app-dev nie wkurzy się, że ruch mu się wywala na IPSach i w ramach "dobrych programistycznych praktyk rozwiązywania problemów" nie przepuści sobie ruchu bokiem. Albo nie przemarkuje sobie polityk QoS, bo "serwer za wolno odpowiada".

dorvin
CCIE
CCIE
Posty: 1688
Rejestracja: 21 sty 2008, 13:21
Lokalizacja: Wrocław
Kontakt:

#36

#36 Post autor: dorvin »

lbromirs pisze: Zamiast usiąść (tak jak chciał zrobić Google, ale mu się przestało chcieć) i włożyć fundusze w dopracowanie tych protokołów, wymyśla się nowe, odkrywając koło na nowo i popełniając znowu te same błędy. Przypomina to historię kolegów z dalkiego wschodu, którzy po paru latach pracy nad separacją ruchu aplikacji w overlayach odkryli od nowa VLANy... czyli tag który ma "na razie" 4094 różnych wartości, "ale na razie tyle wystarczy".
O tak, dokładnie! Piękne podsumowanie obecnej sytuacji na rynku IT.

ODPOWIEDZ