Dzięki temu magicznemu skryptowi Cisco ACI można szybko skonfigurować sieć.
Sieć fabryka dla centrum danych Cisco ACI istnieje już od pięciu lat, ale na Habrze praktycznie nic o niej nie napisano, więc postanowiłem to nieco naprawić. Podzielę się swoim doświadczeniem, czym to jest, jakie ma korzyści i gdzie są jej pułapki.
Co to jest i skąd się wzięło?
W momencie ogłoszenia ACI (Application Centric Infrastructure) w 2013 roku tradycyjne podejścia do sieci centrum danych były atakowane przez konkurencję jednocześnie z trzech stron.
Z jednej strony rozwiązania SDN "pierwszej generacji" oparte na OpenFlow obiecywały uczynić sieci bardziej elastycznymi i jednocześnie tańszymi. Idea polegała na przeniesieniu podejmowania decyzji, tradycyjnie realizowanego przez zastrzeżone oprogramowanie przełączników, na centralny kontroler.
Ten kontroler miałby wspólną wizję wszystkiego, co się dzieje i na podstawie tego programowałby urządzenia wszystkich przełączników na poziomie reguł przetwarzania konkretnych strumieni.
Z drugiej strony rozwiązania oparte na overlayach dawały możliwość realizacji potrzebnej łączności i polityki bezpieczeństwa bez jakichkolwiek zmian w fizycznej sieci, budując programowe tunel między zwirtualizowanymi hostami. Najbardziej znanym przykładem takiego podejścia było rozwiązanie od Nicira, które w tym czasie zostało już zakupione przez VMWare za 1,26 miliarda dolarów i dało początek obecnemu VMWare NSX. Sytuację urozmaicało to, że współzałożycielami Nicira byli ci sami ludzie, którzy wcześniej stali u podstaw OpenFlow, teraz twierdząc, że do zbudowania fabryki centrum danych .
I wreszcie, układy scalone przełączników dostępne na rynku otwartym (to, co nazywa się merchant silicon) osiągnęły dojrzałość, która stała się realnym zagrożeniem dla tradycyjnych producentów przełączników. Kiedyś każdy dostawca samodzielnie opracowywał układy scalone dla swoich przełączników, ale z upływem czasu układy scalone od zewnętrznych producentów, przede wszystkim od Broadcom, zaczęły zbliżać się do układów scalonych dostawców pod względem funkcji oraz przewyższać je w stosunku cena/wydajność. Dlatego wielu uważało, że dni przełączników działających na układach scalonych opracowanych na własny rachunek są policzone.
ACI stało się «asymetryczną odpowiedzią» Cisco (dokładniej, firmy Insieme, założonej przez byłych pracowników Cisco) na wszystkie wymienione kwestie.
Jakie są różnice w porównaniu do OpenFlow?
Z punktu widzenia podziału funkcji ACI jest w istocie przeciwieństwem OpenFlow.
W architekturze OpenFlow kontroler odpowiada za zapisanie szczegółowych reguł (strumieni) w sprzęcie wszystkich przełączników, co oznacza, że w dużej sieci może spoczywać na nim odpowiedzialność za utrzymanie, a co ważniejsze, zmianę dziesiątek milionów zapisów w setkach punktów w sieci. Dlatego jego wydajność i niezawodność w dużych wdrożeniach stają się wąskim gardłem.
W ACI zastosowano odwrotne podejście: kontroler oczywiście istnieje, ale przełączniki otrzymują od niego wysokopoziomowe polityki deklaratywne, a ich renderowanie w szczegółach konkretnych ustawień w sprzęcie dokonuje sam przełącznik. Kontroler można zrestartować lub całkowicie wyłączyć, a sieci nic złego się nie stanie, poza oczywiście brakiem możliwości zarządzania w tym momencie. Interesujące jest to, że w ACI istnieją sytuacje, w których OpenFlow jest jednak stosowane, ale lokalnie w obrębie hosta do programowania Open vSwitch.
ACI jest w całości zbudowane na owerleyowym transporcie opartym na VXLAN, ale jednocześnie obejmuje w ramach jednego rozwiązania także leżący u podstaw transport IP. Cisco nazwało to terminem «zintegrowany owerley». Jako punkt terminacji owerleyów w ACI w większości przypadków wykorzystuje się przełączniki fabryki (robią to z prędkością kanału). Hosty nie muszą nic wiedzieć o fabryce, enkapsulacjach itp., chociaż w niektórych przypadkach (np. dla podłączenia hostów OpenStack) ruch VXLAN może być do nich dostarczany.
Owerleje są stosowane w ACI nie tylko do zapewnienia elastycznej łączności przez sieć transportową, ale także do przesyłania metainformacji (jest ona używana, na przykład, do stosowania polityk bezpieczeństwa).
Owerleje są wykorzystywane w ACI nie tylko do zapewnienia elastycznej łączności w sieci transportowej, ale także do przesyłania metainformacji (która jest wykorzystywana, na przykład, do wdrażania polityk bezpieczeństwa).
Układy scalone firmy Broadcom były wcześniej używane przez Cisco w przełącznikach serii Nexus 3000. W rodzinie Nexus 9000, która została specjalnie stworzona do obsługi ACI, początkowo wdrożono hybrydowy model nazwany Merchant+. W przełączniku jednocześnie wykorzystywano nowy chip Broadcom Trident 2 oraz dodatkowy chip zaprojektowany przez Cisco, który realizował całą magię ACI. Wygląda na to, że pozwoliło to przyspieszyć wprowadzenie produktu na rynek i obniżyć cenę przełącznika do poziomu zbliżonego do modeli opartych wyłącznie na Trident 2. Tego podejścia wystarczyło na pierwsze dwa-trzy lata dostaw ACI. W tym czasie Cisco opracowało i wprowadziło na rynek kolejną generację Nexus 9000 opartą na własnych chipach o wyższej wydajności i zestawie funkcji, ale w tej samej kategorii cenowej. Zewnętrzne specyfikacje w zakresie interakcji w fabryce pozostały całkowicie niezmienione. Wnętrze natomiast zostało całkowicie zmienione: coś w rodzaju refaktoryzacji, ale dla sprzętu.
Jak działa architektura Cisco ACI
W najprostszym przypadku ACI jest zbudowane na topologii sieci Clos, która często nazywana jest Spine-Leaf. Przełączników na poziomie Spine może być od dwóch (lub jednego, gdy nie zależy nam na odporności na awarie) do sześciu. Oczywiście, im więcej ich jest, tym wyższa jest odporność na awarie (mniejsze obniżenie pasma i niezawodności w przypadku awarii lub serwisowania jednego Spine) oraz ogólna wydajność. Wszystkie zewnętrzne połączenia są realizowane przez przełączniki na poziomie Leaf: są to zarówno serwery, jak i połączenia z zewnętrznymi sieciami przez L2 lub L3, oraz podłączenie kontrolerów APIC. Ogólnie rzecz biorąc, z ACI nie tylko konfiguracja, ale także zbieranie statystyk, monitorowanie awarii itp. - wszystko odbywa się przez interfejs kontrolerów, których w typowych wdrożeniach jest trzy.
Nie ma potrzeby nigdy podłączać się do przełączników przez konsolę, nawet podczas uruchamiania sieci: kontroler samodzielnie wykrywa przełączniki i tworzy z nich fabrykę, włączając w to ustawienia wszystkich protokołów pomocniczych. Dlatego przy montażu bardzo ważne jest zapisanie numerów seryjnych zainstalowanego sprzętu, aby później nie zastanawiać się, który przełącznik znajduje się w której szafie. W razie potrzeby można połączyć się z przełącznikami za pomocą SSH: na nich starannie odtworzono typowe komendy show Cisco.
Wewnątrz fabryka wykorzystuje transport IP, więc nie ma żadnego Spanning Tree ani innych koszmarów przeszłości: wszystkie połączenia są aktywne, a zbieżność w przypadku awarii jest bardzo szybka. Ruch w fabryce przesyłany jest przez tunelowanie oparte na VXLAN. Dokładniej, sama Cisco nazywa enkapsulację iVXLAN, która różni się od zwykłego VXLAN tym, że zarezerwowane pola w nagłówku sieciowym wykorzystywane są do przesyłania informacji sterujących, w pierwszej kolejności — o relacji ruchu do grupy EPG. Dzięki temu można wdrażać zasady interakcji między grupami w sprzęcie, używając ich numerów tak, jak w zwykłych listach dostępu wykorzystuje się adresy.
Tunele pozwalają na rozciąganie zarówno segmentów L2, jak i L3 (czyli VRF) przez wewnętrzny transport IP. Domyślną bramą jest rozproszona. Oznacza to, że każdy switch zajmuje się routowaniem ruchu wchodzącego do fabryki. W części logiki przesyłania ruchu ACI jest podobne do fabryki opartej na VXLAN/EVPN.
Jeśli tak, to jakie są różnice? We wszystkim innym!
Różnica numer jeden, z którą się spotykasz w ACI, to sposób, w jaki serwery są podłączane do sieci. W tradycyjnych sieciach podłączenie zarówno serwerów fizycznych, jak i wirtualnych odbywa się do VLAN-ów, i od nich zależy wszystko inne: łączność, bezpieczeństwo itd. W ACI stosuje się konstrukcję, którą Cisco nazywa EPG (End-point Group), od której nie można uciec. Czy można to porównać do VLAN? Tak, ale w takim przypadku istnieje ryzyko utraty większości tego, co oferuje ACI.
W odniesieniu do EPG formułowane są wszystkie zasady dostępu, a w ACI domyślnie stosuje się zasadę 'białej listy', co oznacza, że dozwolony jest tylko ruch, którego przepuszczenie zostało wyraźnie włączone. Możemy tworzyć grupy EPG 'Web' i 'MySQL' i zdefiniować regułę, która zezwala na interakcję między nimi tylko przez port 3306. To będzie działać bez przypisania do adresów sieciowych, nawet w obrębie tej samej podsieci!
Mamy klientów, którzy wybrali ACI właśnie z powodu tej funkcji, ponieważ umożliwia ona ograniczenie dostępu między serwerami (wirtualnymi lub fizycznymi — to bez znaczenia), bez przenoszenia ich między podsieciami, a więc bez dotykania adresacji. Tak, tak, wiemy, nikt przecież nie wpisuje ręcznie adresy IP w konfiguracjach aplikacji, prawda?
Zasady ruchu w ACI nazywane są kontraktami. W takim kontrakcie jedna lub więcej grup lub poziomów w aplikacji o wielowarstwowej architekturze staje się dostawcą usługi (powiedzmy, usługi bazy danych), a inne — konsumentem. Kontrakt może po prostu przekazywać ruch, ale może też robić coś bardziej skomplikowanego, na przykład kierować go do zapory sieciowej lub równoważnika obciążenia oraz zmieniać wartość QoS.
Jak serwery trafiają do tych grup? Jeśli są to serwery fizyczne lub coś włączonego do istniejącej sieci, w którą utworzyliśmy trunk VLAN, to aby umieścić je w EPG, trzeba wskazać port przełącznika i używany na nim VLAN. Jak widać, VLAN-y pojawiają się tam, gdzie nie da się bez nich obejść.
Jeżeli natomiast serwery to maszyny wirtualne, wystarczy odwołać się do podłączonego środowiska wirtualizacji, a reszta wydarzy się automatycznie: utworzy się grupa portów (mówiąc w terminologii — VMWare) do podłączenia VM, przypisane zostaną niezbędne VLAN-y lub VXLAN-y, zapisane na wymaganych portach przełączników itd. Tak więc, chociaż ACI zbudowane jest wokół sieci fizycznej, połączenia w przypadku serwerów wirtualnych wyglądają znacznie prościej niż w przypadku fizycznych. W ACI już wbudowane są powiązania z VMWare i MS Hyper-V, a także wsparcie dla OpenStack i RedHat Virtualization. Od pewnego czasu dostępne jest również wbudowane wsparcie dla platform kontenerowych: Kubernetes, OpenShift, Cloud Foundry, przy czym dotyczy to zarówno stosowania polityk, jak i monitorowania, co oznacza, że administrator sieci może natychmiast zobaczyć, na których hostach jakie pod-y działają i do jakich grup trafiły.
Oprócz włączenia do danej grupy portowej, maszyny wirtualne mają dodatkowe właściwości: nazwę, atrybuty itd., które można wykorzystać jako kryteria do ich przeniesienia do innej grupy, powiedzmy, przy zmianie nazwy VM lub pojawieniu się dodatkowej etykiety. Cisco nazywa to mikroskalowalnymi grupami, chociaż w dużej mierze sama konstrukcja z możliwością tworzenia wielu segmentów bezpieczeństwa w postaci EPG w tej samej podsieci — również jest całkiem wykonalną mikroskalowalnością. Cóż, vendor wie lepiej.
EPG są czysto logicznymi konstrukcjami, niezwiązanymi z konkretnymi przełącznikami, serwerami itd., więc można z nimi i konstrukcjami opartymi na nich (aplikacjami i tenantami) robić rzeczy, które trudno zrealizować w tradycyjnych sieciach, na przykład klonować. W rezultacie, bardzo łatwo jest stworzyć klon środowiska produkcyjnego, aby uzyskać środowisko testowe, które jest dokładnie identyczne z produkcją. Można to zrobić ręcznie, ale lepiej (i prościej) — przez API.
Logika zarządzania w ACI zupełnie różni się od tego, z czym zazwyczaj się spotykasz
w tradycyjnych sieciach od Cisco: interfejs programowania jest priorytetowy, a GUI lub CLI są drugorzędne, ponieważ działają przez ten sam API. Dlatego prawie każdy, kto pracuje z ACI, po pewnym czasie zaczyna orientować się w modelu obiektowym używanym do zarządzania i automatyzować określone zadania według swoich potrzeb. Najłatwiej jest to robić w Pythonie: istnieją wygodne gotowe narzędzia.
Obiecane pułapki
Głównym problemem jest to, że wiele rzeczy w ACI jest zrobionych inaczej. Aby rozpocząć z nią normalną pracę, trzeba się przestawić. Dotyczy to szczególnie zespołów ds. operacji sieciowych w dużych firmach, gdzie inżynierowie przez lata zajmują się 'przypisywaniem VLANów' zgodnie z prośbami. To, że teraz VLAN to już nie VLAN, a do tworzenia nowych sieci w wirtualizowanych hostach nie trzeba w ogóle ręcznie tworzyć VLANów, całkowicie 'zmienia reguły gry' dla tradycyjnych sieciowców i zmusza ich do trzymania się znanych metod. Należy zauważyć, że Cisco starała się nieco osłodzić tę zmianę i dodała w kontrolerze 'NXOS-podobny' CLI, który pozwala na konfigurację z interfejsu przypominającego tradycyjne przełączniki. Jednak aby zacząć korzystać z ACI, trzeba zrozumieć, jak to działa.
Z perspektywy ceny, dla dużych i średnich sieci ACI, nie ma zasadniczej różnicy między tradycyjnymi sieciami opartymi na sprzęcie Cisco, ponieważ do ich budowy wykorzystuje się te same przełączniki (Nexus 9000 mogą działać zarówno w trybie ACI, jak i tradycyjnym, i obecnie stały się głównym "koniem roboczym" dla nowych projektów w dziedzinie centrów danych). W przypadku centrów danych z dwoma przełącznikami, obecność kontrolerów i architektury Spine-Leaf oczywiście wpływa na sytuację. Niedawno powstała Mini ACI-fabryka, w której dwa z trzech kontrolerów zostały zastąpione maszynami wirtualnymi. To pozwala na zmniejszenie różnicy kosztów, ale ta wciąż istnieje. Dlatego wybór klienta jest podyktowany tym, na ile jest zainteresowany funkcjami bezpieczeństwa, integracji z wirtualizacją, jednorodnym punktem zarządzania i innymi.
Źródło: habr.com
