Oceń powiązania w środkowej części schematu. Wrócimy do nich poniżej
W pewnym momencie możesz napotkać problem, że duże, złożone sieci oparte na L2 są nieuleczalnie chore. Przede wszystkim z problemami związanymi z przetwarzaniem ruchu BUM i działaniem protokołu STP. Po drugie — z całkowicie moralnie przestarzałą architekturą. Powoduje to niemiłe problemy w postaci przestojów i trudności w zarządzaniu.
Mieliśmy dwa równoległe projekty, w których klienci trzeźwo ocenili wszystkie zalety i wady opcji i wybrali dwa różne rozwiązania oparte na nakładkach, które my wdrożyliśmy.
Mieliśmy możliwość dokładnego porównania realizacji. Nie eksploatacji, o której warto mówić po dwóch-trzech latach.
Zatem, czym jest fabryka sieciowa z nakładanymi sieciami i SDN?
Co zrobić z palącymi problemami klasycznej architektury sieci?
Każdego roku pojawiają się nowe technologie i pomysły. W praktyce pilna potrzeba przebudowy sieci nie pojawiała się przez dość długi czas, ponieważ wszystko można było robić ręcznie według starych dobrych metod. Co z tego, że mamy XXI wiek? W końcu administrator musi pracować, a nie siedzieć w swoim biurze.
Potem rozpoczął się boom na budowę dużych centrów danych. Wtedy stało się jasne, że osiągnięto limit rozwoju klasycznej architektury nie tylko pod względem wydajności, niezawodności, skalowalności. Jednym z rozwiązań tych problemów była idea budowy nakładanych sieci nad routowalnym backbone.
Ponadto, wraz z rozwojem sieci, problem zarządzania takimi fabrykami stał się pilny, co doprowadziło do pojawienia się rozwiązań sieci programowalnych umożliwiających zarządzanie całą infrastrukturą sieciową jako całością. A gdy sieć jest zarządzana z jednego punktu, innym komponentom infrastruktury IT łatwiej jest nawiązywać z nią interakcje, a takie procesy interakcji łatwiej jest automatyzować.
Praktycznie każdy duży producent nie tylko sprzętu sieciowego, ale także wirtualizacji, ma w swoim portfolio warianty takich rozwiązań.
Pozostaje tylko ustalić, co będzie odpowiednie dla jakich potrzeb. Na przykład, dla szczególnie dużych firm, które mają świetny zespół programistów i dział operacyjny, gotowe rozwiązania od dostawców nie zawsze zaspokajają wszystkie potrzeby, dlatego sięgają po rozwój własnych rozwiązań SD (software defined). Na przykład, są to dostawcy chmur, którzy nieustannie poszerzają ofertę usług dla swoich klientów, a gotowe rozwiązania po prostu nie są w stanie nadążyć za ich potrzebami.
Dla średnich firm funkcjonalność oferowana przez dostawcę w postaci gotowego rozwiązania wystarcza w 99 procentach przypadków.
Czym są sieci overlay?
Na czym polega idea sieci overlay? W zasadzie bierzesz klasyczną sieć routowalną i budujesz nad nią jeszcze jedną sieć, aby uzyskać więcej funkcji. Najczęściej chodzi o efektywne rozkładanie obciążenia na sprzęt i łącza komunikacyjne, znaczne zwiększenie limitu skalowalności, poprawę niezawodności i wiele dodatków w zakresie bezpieczeństwa (dzięki segmentacji). A rozwiązania SDN dodatkowo oferują bardzo, bardzo, bardzo wygodne elastyczne zarządzanie i czynią sieć bardziej przejrzystą dla jej użytkowników.
Ogólnie rzecz biorąc, gdyby sieci lokalne były wynalezione w latach 2010-tych, wyglądałyby zupełnie inaczej niż to, co odziedziczyliśmy po wojskowych z lat 70-tych.
Z punktu widzenia technologii budowy fabryk z wykorzystaniem sieci overlay, obecnie istnieje wiele realizacji producentów i projektów internetowych RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve i inne). Tak, są standardy, ale realizacja tych standardów przez różnych producentów może się różnić, dlatego tworząc takie fabryki, całkowite porzucenie vendor locka można uznać jedynie za teoretyczną możliwość na papierze.
Kwestie związane z rozwiązaniami SD są jeszcze bardziej skomplikowane, każdy dostawca ma swoją wizję. Są całkowicie otwarte rozwiązania, które teoretycznie można dostosować samodzielnie, a także całkowicie zamknięte.
Cisco oferuje swoje rozwiązanie SDN dla centrów danych – ACI. Oczywiście jest to w 100% rozwiązanie vendor-lock, jeśli chodzi o wybór sprzętu sieciowego, ale jednocześnie w pełni integruje się z systemami wirtualizacji, konteneryzacji, bezpieczeństwa, orkiestracji, balancerami obciążenia i innymi. W praktyce jednak wciąż jest to rodzaj czarnej skrzynki, bez możliwości pełnego dostępu do wszystkich procesów wewnętrznych. Nie wszyscy klienci godzą się na takie rozwiązanie, ponieważ całkowicie polegasz na jakości napisanego kodu rozwiązania i jego realizacji, ale z drugiej strony producent dysponuje jednym z najlepszych wsparć technicznych na świecie i ma dedykowany zespół zajmujący się wyłącznie tym rozwiązaniem. W przypadku pierwszego projektu wybrano właśnie Cisco ACI.
Dla drugiego projektu wybrano rozwiązanie od Junipera. Producent również oferuje swoje SDN dla centrów danych, ale klient podjął decyzję o rezygnacji z wdrożenia SDN. Jako technologię budowy sieci wybrano fabrykę EVPN VXLAN bez użycia zcentralizowanych kontrolerów.
Do czego to potrzebne
Utworzenie fabryki pozwala na zbudowanie łatwo skalowalnej, odpornej na awarie i niezawodnej sieci. Architektura (leaf-spine) uwzględnia specyfikę centrów danych (ścieżki ruchu, minimalizacja opóźnień i wąskich gardeł w sieci). Rozwiązania SD w centrach danych pozwalają na wygodne, szybkie i elastyczne zarządzanie taką fabryką oraz integrację jej z ekosystemem centrów danych.
Obaj klienci musieli zbudować zapasowe centra danych dla zapewnienia odporności na awarie, oprócz tego ruch między centrami danych musiał być szyfrowany.
Pierwszy klient już rozważał rozwiązania bez fabryki jako możliwy standard swoich sieci, ale podczas testów mieli problemy z kompatybilnością STP między różnymi producentami sprzętu. Występowały przestoje, które powodowały awarie usług. Dla klienta było to krytyczne.
Cisco już była standardem korporacyjnym klienta, przyglądali się ACI i innym opcjom i zdecydowali, że warto wybrać to rozwiązanie. Podobała im się automatyzacja zarządzania jednym przyciskiem przez jedyny kontroler. Usługi konfigurują się szybciej, zarządzanie również jest szybsze. Zdecydowali się zapewnić szyfrowanie ruchu uruchamiając MACSec między przełącznikami IPN a SPINE. Dzięki temu udało się uniknąć wąskiego gardła w postaci bramy kryptograficznej, zaoszczędzić na nich i maksymalnie wykorzystać pasmo.
Drugi klient wybrał rozwiązanie bez kontrolera od Juniper, ponieważ w ich istniejącym centrum danych była już mała instalacja z realizacją fabryki EVPN VXLAN. Jednak tam nie była ona odporna na awarie (używano jednego przełącznika). Podjęto decyzję o rozbudowie infrastruktury głównego centrum danych i zbudowaniu fabryki w zapasowym centrum danych. Istniejący EVPN nie był wykorzystywany w pełni: enkapsulacja VXLAN w zasadzie nie była stosowana, ponieważ wszystkie hosty były podłączone do jednego przełącznika, a wszystkie adresy MAC i /32 adresy hostów były lokalne, bramą dla nich był ten sam przełącznik, nie było innych urządzeń, do których należałoby budować tunel VXLAN. Zdecydowano się zapewnić szyfrowanie ruchu z wykorzystaniem technologii IPSEC między zaporami (wydajności MSE było wystarczająco).
Również przetestowali ACI, ale zdecydowali, że z powodu vendor lock będzie musieli kupić zbyt wiele sprzętu, w tym wymienić niedawno zakupiony nowy sprzęt, co po prostu nie ma ekonomicznego sensu. Tak, fabryka Cisco integruje się ze wszystkim, ale w obrębie samej fabryki możliwe są tylko jej własne urządzenia.
Z drugiej strony, jak mówiono wcześniej, fabrykę EVPN VXLAN z dowolnym sąsiednim producentem tak łatwo nie wymieszasz, ponieważ realizacje protokołu się różnią. To jak krzyżowanie Cisco z Huawei w jednej sieci — wyglądają na to, że standardy są wspólne, ale trzeba będzie się trochę napracować. Ponieważ to bank, a testy kompatybilności byłyby bardzo długie, zdecydowano, że lepiej zaopatrzyć się w sprzęt tego samego producenta teraz, i nie angażować się zbytnio w funkcjonalność wykraczającą poza podstawową.
Plan migracji
Dwa centra danych oparte na ACI:
Organizacja współpracy między centrami danych. Wybrano rozwiązanie Multi-Pod — każde centrum danych jest pod-em. Uwzględniono wymagania dotyczące skalowalności pod względem liczby przełączników oraz opóźnień między podami (RTT poniżej 50 ms). Podjęto decyzję o niedokonywaniu budowy rozwiązania Multi-Site dla ułatwienia zarządzania (w przypadku rozwiązania Multi-Pod używany jest jeden interfejs zarządzania, podczas gdy dla Multi-Site byłyby dwa interfejsy, co wymagałoby Multi-Site Orchestratora), a także dlatego, że nie było konieczności geograficznego rezerwowania lokalizacji.
Z punktu widzenia migracji usług z sieci Legacy, wybrano najbardziej przejrzysty wariant, stopniowo przenosząc VLAN-y przypisane do określonych usług.
Podczas migracji każdemu VLAN-owi tworzono odpowiadający EPG (End-point-group) w fabryce. Najpierw sieć rozwijała się między starą siecią a fabryką w L2, a następnie, po migracji wszystkich hostów, brama była przenoszona do fabryki, a interakcja EPG z istniejącą siecią odbywała się przez L3OUT, przy czym interakcja między L3OUT a EPG była opisana za pomocą kontraktów. Przykładowy schemat:
Przykładowa struktura większości polityk fabryki ACI na poniższym rysunku. Cała konfiguracja oparta jest na politykach, zagnieżdżonych w innych politykach i tak dalej. Na początku bardzo trudno to zrozumieć, ale stopniowo, jak pokazuje praktyka, administratorzy sieci przyzwyczajają się do tej struktury w ciągu około miesiąca, a później dopiero przychodzi zrozumienie, jak bardzo jest ona wygodna.
Porównanie
W rozwiązaniu Cisco ACI należy zakupić więcej sprzętu (oddzielne przełączniki do interakcji Inter-Pod oraz kontrolery APIC), co sprawia, że jest to droższe. Rozwiązanie Juniper nie wymagało zakupu kontrolerów ani sprzętu pomocniczego; można częściowo wykorzystać już istniejący sprzęt klienta.
Oto architektura EVPN VXLAN fabryki dla dwóch centrów danych drugiego projektu:
W ACI otrzymujesz gotowe rozwiązanie — nie musisz grzebać, nie musisz optymalizować. Przy początkowym zapoznaniu się klienta z fabryką nie są potrzebni programiści ani osoby wspierające kod i automatyzację. Wystarczy tylko eksploatacja, wiele ustawień można wykonać za pomocą kreatora, co nie zawsze jest zaletą, szczególnie dla osób przyzwyczajonych do wiersza poleceń. W każdym razie potrzebny jest czas, aby przestawić myślenie na nowe tory, na szczególności ustawień poprzez polityki i obsługę wielu zagnieżdżonych polityk. Bardzo wskazane jest również posiadanie jasnej struktury nazewnictwa polityk i obiektów. W przypadku jakiegokolwiek problemu z logiką działania kontrolera, jego rozwiązanie możliwe jest tylko przez wsparcie techniczne.
W EVPN — konsola. Cierp, albo się ciesz. Znany interfejs dla starej gwardii. Tak, dostępna jest typowa konfiguracja i przewodniki. Trzeba będzie studiować dokumentację. Różne konstrukcje, wszystko jasne i szczegółowe.
Oczywiście, w obu przypadkach lepiej przy migracji najpierw przenieść mniej krytyczne usługi, na przykład środowiska testowe, a dopiero potem, po uchwyceniu wszystkich błędów, przystąpić do produkcji. I nie konfiguruj w piątek wieczorem. Nie warto wierzyć dostawcy, że wszystko będzie w porządku, zawsze lepiej się zabezpieczyć.
Za ACI płacisz więcej, chociaż obecnie Cisco aktywnie promuje to rozwiązanie i często oferuje na nie dobre zniżki, ale oszczędzasz na serwisowaniu. Zarządzanie i jakakolwiek automatyzacja fabryki EVPN bez kontrolera wymaga inwestycji i regularnych wydatków — monitorowanie, automatyzacja, wdrażanie nowych usług. Przy tym początkowe uruchomienie w ACI trwa dłużej o 30–40 procent. Dzieje się tak, ponieważ dłużej tworzony jest cały zestaw niezbędnych profili i polityk, które będą następnie używane. Ale w miarę rozwoju sieci liczba potrzebnych konfiguracji maleje. Wykorzystujesz już wcześniej stworzone polityki, profile, obiekty. Możesz elastycznie konfigurować segmentację i bezpieczeństwo, centralnie zarządzać kontraktami odpowiadającymi za zezwolenie na różne interakcje między EPG — objętość pracy znacznie maleje.
W EVPN trzeba skonfigurować każde urządzenie w fabryce, prawdopodobieństwo błędu jest większe.
Jeśli ACI wprowadza się wolniej, to EVPN jest prawie dwa razy dłużej w fazie testów. W przypadku Cisco zawsze można wezwać inżyniera wsparcia i zapytać o sieć jako całość (ponieważ jest to objęte rozwiązaniem), natomiast w przypadku Juniper Networks kupujesz tylko sprzęt, i to jego się objęto. Pakiety z urządzenia odeszły? Cóż, teraz to już wasz problem. Ale można otworzyć sprawę w kwestii wyboru rozwiązania lub projektowania sieci — wtedy doradzą, by zakupić profesjonalną usługę, za dodatkową opłatą.
Wsparcie ACI jest naprawdę świetne, ponieważ jest oddzielne: osobny zespół zajmuje się tylko tym tematem. Są również specjaliści mówiący po rosyjsku. Przewodnik jest szczegółowy, a rozwiązania są z góry określone. Obserwują i doradzają. Szybko walidują projekt, co często ma znaczenie. Juniper Networks robi to samo, ale znacznie wolniej (w naszym przypadku tak było, teraz ponoć powinno być lepiej), co zmusza cię do samodzielnego działania tam, gdzie mógłby doradzić inżynier rozwiązań.
Cisco ACI wspiera integrację z systemami wirtualizacji i konteneryzacji (VMware, Kubernetes, Hyper-V) oraz centralne zarządzanie. Istnieją również usługi sieciowe i bezpieczeństwa — load balancing, firewalle, WAF, IPS i inne... Dobra mikromsegmentacja od zaraz. W drugim rozwiązaniu integracja z usługami sieciowymi odbywa się z trudnościami, dlatego lepiej najpierw poczytać fora na ten temat z osobami, które już to robiły.
Podsumowanie
Dla każdego konkretnego przypadku należy dobierać rozwiązanie, nie tylko na podstawie kosztów sprzętu, ale także trzeba uwzględnić dalsze wydatki na eksploatację oraz główne problemy, z którymi boryka się klient, oraz jakie ma plany na rozwój infrastruktury IT.
ACI, dzięki dodatkowym urządzeniom, jest droższe, ale rozwiązanie gotowe bez konieczności dopracowywania, natomiast drugie rozwiązanie jest bardziej skomplikowane i kosztowne z punktu widzenia eksploatacji, ale tańsze.
Jeśli chcecie omówić, ile może kosztować wdrożenie sieciowej fabryki u różnych dostawców oraz jaka potrzebna jest architektura, można się spotkać i porozmawiać. Do roboczego szkicu architektury (na podstawie którego można obliczyć budżety) podpowiemy za darmo, szczegółowe opracowanie oczywiście będzie płatne.
Władimir Klepcze, sieci korporacyjne.
Źródło: habr.com
