lbromirs pisze:No dobrze - o czym właściwie dyskutujemy? Że overlay jest lepsze? Nie jest. Lepsze jest przejście na czyste L3 i ewidentnie w tą stronę idziemy.
Masakra w L2 + overlay, w postaci VXLANów to rozwiązanie przejściowe. Dzisiaj rynek wybrał już raczej rozwiązania "fabric+VXLANy". Proste, fajne, szybko się buduje, ale też z czasem będzie niepotrzebne.
Rozwiązanie L2 + overlay jest lepsze, niż samo L2 ze względu na przesunięcie częsci funkcji sieciowych, które sprawiają, że sieć jest stabilniejsza, bardziej skalowalna i łatwiej zarządzalna. Oczywiście, że lepszy jest fabric + overlay. Nikt tego nie kwestionuje. Jeszcze lepsze L3 + overlay. A najlepsze natywne L3 od końca do końca. Tylko ostatni model nie wszędzie się sprawdzi. Tylko tam, gdzie nie będzie nakładającej się adresacji oraz środowiska multitenant.
lbromirs pisze:Mówisz? Ale ewidentnie bardzo szybko w tą stronę idziemy. To, że firmy muszą przepisać stare aplikacje wymagające L2 już się dzieje. A jak masz aplikację, dla której cały świat to socket IP, potem pozostaje już tylko kwestia zapakowania - czy opłaca się inwestować w ciężki hypervisor, czy raczej w kontener w stylu dockera. Jest jeszcze dużo problemów, ale kontenery są prostsze i łatwiejsze w spakowaniu w cały stosik.
W skali wszystkich firm posiadających swoje DC pozbywanie się zależności od L2 dzieje się bardzo powoli. Jedna, czy dwie nowe aplikacje w ramach firmy nie zmieniają reszty aplikacji. Wyczuwam też, że doklejasz rozwiązanie nakładkowe tylko do aplikacji bazujących na hypervisorze, co jest błędem. Konteneryzacja nie zmienia niczego w naszej dyskusji o sieciach nakładkowych.
lbromirs pisze:Uproszczenie pozorne.
Uproszczenie konkretne, gdy przeniesie się Default GW, czy ACL ze switchy agregujących na serwery.
lbromirs pisze:Zobaczysz, w wersji wirtualnej, sprzętowej i dla konternerów. Jak chcesz masz nawet SDK w Pythonie, można sobie to samemu ściągać. A vROps nie jest chyba za darmo
No nie zobaczysz, gdyż ACI nie wspiera Netflow/sFlow, ACI nie ma dostępu do NetX, ACI nie ma liczników w ramach EPG. A o cenę NSX + vROps się nie martw.
lbromirs pisze:No nie, są. EPG do EPG, EPG<>endpoint, EPG w dowolne miejsce (w tym zewnętrzne - i odwrotnie). To nie flow, zgadza się, ale są per aplikacja.
Tylko pakiety, które przechodzą przez fabric są liczone. Lokalnie zawijane na przełączniku lub na hypervisorze nie są liczone. Dodatkowe obostrzenia można znaleźć tutaj:
http://www.cisco.com/c/en/us/td/docs/sw ... 6e859a1635
lbromirs pisze:TCAM w kontekście L3 w DC? Raczej nie szybko, skoro mamy do dyspozycji overlay. TCAMy w kontekście L3 w ogólności - tak, ale to scenariusze typu SD WAN i/lub styk z internetem.
TCAM w kontekście L2/L3 w DC bez overlaya. Mówisz ciągle, że nie ma korzyści na architekturze L2 + overlay. No właśnie jest, choćby ze względu na TCAM.
lbromirs pisze:Tam gdzie od vPC uciec się nie da, rozmowa o synchronizacji lub jej braku będzie zawsze ciekawa, podobnie jak o całej reszcie L2 - czy to z czy bez hypervisora, a nie tylko hypervisorami dzisiaj żyjemy. Ale mamy już coraz więcej sieci zbudowanych jako uniwersalna matryca bez trudnych operacji na L2 w stylu MC-LAGów czy vPC i tutaj nie ma żadnego problemu. Dokładanie overlaya p.t. "VXLAN" dodaje niepotrzebnej złożoności.
Również dla matrycy jest zysk z overlaya. Choćby ze względu na funkcje rozproszonej bramy, dFW, LB, optymalizacji przepływów czy też kontroli ostatniej mili w DC.
lbromirs pisze:No nie szukam na siłę. Pomyłki tego typu robione masowo z użyciem Ansible i innych frameworków do automatyzacji już się zaczynają wydarzać. Będzie ich więcej. Zapewne (paradoksalnie trochę), błędów robionych za pomocą interfejsu vSphere czy APICa będzie mniej.
Póki co pomyłki konfiguracyjne na przełącznikach agregacyjnych powodujących katastrofę w całym DC jest dużo więcej. Automatyzacja właśnie może pomóc je ograniczyć.
lbromirs pisze:Tak. Ale tutaj overlay nic nie da - mimo pozornego 'uproszczenia', sieć się i tak zawali i tak.
Mniej powodów do katastrofy, ale twierdzisz, że ryzyko to samo. Czyli uważszasz, że przeniesienie funkcji sieciowych na serwery, nie upraszcza sieci fizycznej?
lbromirs pisze:O jakim zcentralizowanym gatewayu mówisz?
O parze vPC, która pełni w DC rolę GW.
lbromirs pisze:Tą parę bramek w NSXie można ściągnąć do ilu... 6s failoveru? To bardzo dużo w porównaniu do dobrze stuningowanego styku L3 z ACI.
Możesz skorzystać z ECMP, czyli 3 sekundy. A nawet 6 sekund, to nie jest dużo przy klastrowaniu ASA, czy OTV. W DC nie jest wymagana konwergencja subsecond. To w sieciach IPTV. Nawet w testach dla instytucji finansowych, które wykonywałem w Cisco maksymalny czas konwergencji był określony na poziomie 5 sekund. Dlatego design sieci DC zawsze warto zacząć od wymagań aplikacji, a nie od bicia piany o każde 50 ms.
lbromirs pisze:No i ponownie - co Ci daje overlay skoro sprzęt pod spodem zawiódł?
Ale co, cały sprzęt zawiódł? W takim przypadku overlay nic nie daje oczywiście. Ale nie o tym była mowa. Podałem przykład, że zastosowanie overlaya powoduje przeniesienie funkcji sieciowych ze switchy agregujących. Zmniejsza to ryzyko popełnienia błędu w środowisku fizycznym. Ktoś powie, że to ryzyko przenosi się w takim razie na środowisko wirtualne, ale dzięki rozproszonym usługom, kontrolerom oraz zarządzaniu ryzyko jest mniejsze.
lbromirs pisze:Nieee, mówię raczej o błędach logicznych wyższego rzędu. Uwaga, wydumany przykład: arbitralnie zdefiniowany próg obciążenia danego zasobu zostaje przekroczony prawidłowym ruchem w wyniku rekonfiguracji polityki rozkładania ruchu pomiędzy endpointy. W wyniku tego część ruchu jest obcinana żeby utrzymać ten próg - zobaczysz to w systemie monitoringu, ale może nie od razu. Czym więcej masz warstw na których coś może pójść źle i czego nie wyłapie walidator sprawdzający lokalnie dane operacyjne (w rozwiązaniu rozproszonym to wręcz niemożliwe) tym bardziej prawdopodobne, że to nie prosty błąd rozłoży Ci czy uszkodzi działający system, ale właśnie nałożenie się polityk - coraz bardziej skomplikowanych.
Ehh... Z takiego teoretyzowania nie uzyskamy jednoznaczych konkluzji. Jak problemy w SDN dojdą do poziomu i częstości występowania problemów w sieci L2, to możemy wrócić do tej części dyskusji. Systemy centralnie zarządzane, nie chodzi tylko o sieci, pokazują, że nie jest tak, jak mówisz.