Za pomocą tego magicznego kawałka skryptu Cisco ACI możesz szybko skonfigurować sieć.
Fabryka sieci dla centrum danych Cisco ACI istnieje od pięciu lat, ale Habré tak naprawdę nic o niej nie mówił, więc postanowiłem ją trochę naprawić. Opowiem z własnego doświadczenia, co to jest, do czego służy i gdzie ma zgrabiarkę.
Co to jest i skąd się wzięło?
Do czasu ogłoszenia ACI (Application Centric Infrastructure) w 2013 r. konkurenci rozwijali tradycyjne podejście do sieci centrów danych z trzech stron jednocześnie.
Z jednej strony rozwiązania SDN „pierwszej generacji” oparte na OpenFlow obiecywały uczynić sieci bardziej elastycznymi i jednocześnie tańszymi. Pomysł polegał na przeniesieniu procesu decyzyjnego tradycyjnie wykonywanego przez zastrzeżone oprogramowanie przełączników do centralnego kontrolera.
Kontroler ten miałby jedną wizję wszystkiego, co się dzieje i na tej podstawie programowałby sprzętowo wszystkie przełączniki na poziomie reguł przetwarzania określonych przepływów.
Z drugiej strony nakładkowe rozwiązania sieciowe umożliwiły wdrożenie niezbędnych polityk łączności i bezpieczeństwa bez żadnych zmian w sieci fizycznej, budując tunele programowe między zwirtualizowanymi hostami. Najbardziej znanym przykładem takiego podejścia była Nicira, która do tego czasu została już przejęta przez VMWare za 1,26 miliarda dolarów i dała początek obecnemu VMWare NSX. Pikanterii sytuacji dodawał fakt, że współzałożycielami Nicira byli ci sami ludzie, którzy wcześniej stali u początków OpenFlow, teraz twierdząc, że aby zbudować fabrykę data center .
I wreszcie, chipy przełączające dostępne na wolnym rynku (tzw. krzem handlowy) osiągnęły etap dojrzałości, w którym stały się realnym zagrożeniem dla tradycyjnych producentów przełączników. Jeśli wcześniej każdy sprzedawca niezależnie opracowywał chipy dla swoich przełączników, to z czasem chipy innych producentów, głównie Broadcom, zaczęły zmniejszać dystans do chipów dostawców pod względem funkcji i przewyższać je pod względem stosunku ceny do wydajności. Dlatego wielu uważało, że dni przełączników na chipach własnego projektu są policzone.
ACI stało się „asymetryczną odpowiedzią” Cisco (a dokładniej firmy Insieme, założonej przez jej byłych pracowników) na wszystkie powyższe.
Jaka jest różnica w OpenFlow?
Pod względem dystrybucji funkcji ACI jest właściwie przeciwieństwem OpenFlow.
W architekturze OpenFlow kontroler odpowiada za pisanie szczegółowych reguł (przepływów)
w sprzęcie wszystkich przełączników, czyli w dużej sieci, może odpowiadać za utrzymanie i co najważniejsze zmianę dziesiątek milionów rekordów w setkach punktów w sieci, przez co jego wydajność i niezawodność staje się wąskim gardłem w duża realizacja.
ACI stosuje podejście odwrotne: oczywiście jest też kontroler, ale przełączniki otrzymują od niego deklaratywne polityki wysokiego poziomu, a sam przełącznik wykonuje ich renderowanie w szczegóły określonych ustawień w sprzęcie. Kontroler można zrestartować lub całkowicie wyłączyć, a sieci nic złego się nie stanie, poza oczywiście brakiem kontroli w tym momencie. Co ciekawe, zdarzają się sytuacje w ACI, w których OpenFlow jest nadal używany, ale lokalnie w hoście do programowania Open vSwitch.
ACI jest zbudowany w całości na transporcie nakładkowym opartym na VXLAN, ale zawiera bazowy transport IP jako część jednego rozwiązania. Firma Cisco nazwała to terminem „zintegrowanej nakładki”. Jako punkt końcowy dla nakładek w ACI w większości przypadków używane są przełączniki fabryczne (robią to z szybkością łącza). Hosty nie muszą wiedzieć nic o fabryce, enkapsulacji itp., jednak w niektórych przypadkach (na przykład w celu połączenia hostów OpenStack) ruch VXLAN może być do nich kierowany.
Nakładki wykorzystywane są w ACI nie tylko do zapewnienia elastycznej łączności poprzez sieć transportową, ale także do przesyłania metainformacji (służy np. do stosowania polityk bezpieczeństwa).
Chipy firmy Broadcom były wcześniej używane przez Cisco w przełącznikach serii Nexus 3000. W rodzinie Nexus 9000, wydanej specjalnie do obsługi ACI, oryginalnie zaimplementowano model hybrydowy, który nosił nazwę Merchant +. Przełącznik wykorzystywał jednocześnie nowy układ Broadcom Trident 2 oraz uzupełniający układ opracowany przez firmę Cisco, który implementuje całą magię ACI. Najwyraźniej pozwoliło to przyspieszyć premierę produktu i obniżyć cenę przełącznika do poziomu zbliżonego do modeli opartych po prostu na Trident 2. Takie podejście wystarczyło na pierwsze dwa, trzy lata dostaw ACI. W tym czasie firma Cisco opracowała i wprowadziła na rynek następną generację Nexusa 9000 na własnych układach scalonych, charakteryzujących się większą wydajnością i zestawem funkcji, ale w tej samej cenie. Specyfikacje zewnętrzne w zakresie interakcji w fabryce są całkowicie zachowane. W tym samym czasie całkowicie zmieniło się wypełnienie wewnętrzne: coś w rodzaju refaktoryzacji, ale dla sprzętu.
Jak działa architektura Cisco ACI
W najprostszym przypadku ACI jest zbudowane na topologii sieci Klose lub, jak to się często mówi, Spine-Leaf. Przełączniki na poziomie kręgosłupa mogą mieć od dwóch (lub jednego, jeśli nie zależy nam na tolerancji błędów) do sześciu. W związku z tym, im więcej z nich, tym wyższa odporność na uszkodzenia (mniejsza przepustowość i redukcja niezawodności w przypadku awarii lub konserwacji jednego Spine) i ogólna wydajność. Wszystkie połączenia zewnętrzne idą do przełączników na poziomie liścia: są to serwery i dokowanie z sieciami zewnętrznymi przez L2 lub L3 oraz łączenie kontrolerów APIC. Ogólnie rzecz biorąc, w przypadku ACI nie tylko konfiguracja, ale także zbieranie statystyk, monitorowanie awarii itp. - wszystko odbywa się za pośrednictwem interfejsu kontrolerów, których w implementacjach o standardowej wielkości są trzy.
Nigdy nie trzeba łączyć się z przełącznikami za pomocą konsoli, nawet w celu uruchomienia sieci: kontroler sam wykrywa przełączniki i składa z nich fabrykę, w tym ustawienia wszystkich protokołów serwisowych, dlatego przy okazji bardzo ważne jest, aby podczas instalacji zapisz numery seryjne instalowanego sprzętu, aby później nie musieć zgadywać, który przełącznik znajduje się w której szafie. Aby rozwiązać problemy, jeśli to konieczne, możesz połączyć się z przełącznikami przez SSH: dość dokładnie odtwarzają one zwykłe polecenia pokazowe Cisco.
Wewnętrznie fabryka korzysta z transportu IP, więc nie ma w niej Spanning Tree i innych horrorów przeszłości: wszystkie łącza są zaangażowane, a konwergencja w przypadku awarii jest bardzo szybka. Ruch w tkaninie przesyłany jest tunelami opartymi o VXLAN. Mówiąc dokładniej, sama Cisco nazywa enkapsulacją iVXLAN i różni się od zwykłego VXLAN tym, że zarezerwowane pola w nagłówku sieci służą do przesyłania informacji o usługach, przede wszystkim o stosunku ruchu do grupy EPG. Pozwala to na zaimplementowanie zasad interakcji pomiędzy grupami w sprzęcie, wykorzystując ich numery w taki sam sposób, jak adresy używane są w zwykłych listach dostępu.
Tunele umożliwiają rozciąganie zarówno segmentów L2, jak i L3 (tj. VRF) przez wewnętrzny transport IP. W takim przypadku domyślna brama jest dystrybuowana. Oznacza to, że każdy przełącznik jest odpowiedzialny za kierowanie ruchu przychodzącego do sieci szkieletowej. Pod względem logiki przepływu ruchu, ACI jest podobne do tkaniny VXLAN/EVPN.
Jeśli tak, jakie są różnice? Wszystko inne!
Najważniejszą różnicą, jaką napotykasz w przypadku ACI, jest sposób, w jaki serwery są podłączone do sieci. W tradycyjnych sieciach włączenie zarówno serwerów fizycznych, jak i maszyn wirtualnych trafia do sieci VLAN, a wszystko inne tańczy z nich: łączność, bezpieczeństwo itp. W ACI używany jest projekt, który Cisco nazywa EPG (End-point Group), z którego nie ma gdzie uciec. Czy można to zrównać z VLAN? Tak, ale w tym przypadku istnieje szansa na utratę większości tego, co daje ACI.
W odniesieniu do EPG formułowane są wszystkie reguły dostępu, aw ACI domyślnie stosowana jest zasada „białej listy”, to znaczy dozwolony jest tylko ruch, którego przejście jest wyraźnie dozwolone. Oznacza to, że możemy utworzyć grupy EPG „Web” i „MySQL” i zdefiniować regułę zezwalającą na komunikację między nimi tylko na porcie 3306. Będzie to działać bez przywiązania do adresów sieciowych, a nawet w tej samej podsieci!
Mamy klientów, którzy wybrali ACI właśnie ze względu na tę funkcję, ponieważ pozwala ona ograniczyć dostęp między serwerami (wirtualnymi lub fizycznymi - to nie ma znaczenia) bez przeciągania ich między podsieciami, czyli bez dotykania adresacji. Tak, tak, wiemy, że nikt nie przepisuje ręcznie adresów IP w konfiguracjach aplikacji, prawda?
Zasady ruchu w ACI nazywane są umowami. W takiej umowie jedna lub więcej grup lub poziomów w aplikacji wielowarstwowej staje się dostawcą usług (np. usługi bazy danych), inne stają się konsumentami. Kontrakt może po prostu przepuszczać ruch lub może zrobić coś bardziej skomplikowanego, na przykład skierować go do zapory lub balansera, a także zmienić wartość QoS.
Jak serwery trafiają do tych grup? Jeśli są to fizyczne serwery lub coś zawartego w istniejącej sieci, do której utworzyliśmy łącze VLAN trunk, to aby umieścić je w EPG, należy wskazać port przełącznika i używaną na nim sieć VLAN. Jak widać, sieci VLAN pojawiają się tam, gdzie nie można się bez nich obejść.
Jeżeli serwery są maszynami wirtualnymi, to wystarczy odwołać się do podłączonego środowiska wirtualizacji, a wtedy wszystko samo się zrobi: zostanie utworzona grupa portów (w zakresie VMWare) do podłączenia VM, niezbędne VLANy lub VXLANy zostaną zostaną przypisane, zostaną zarejestrowane na niezbędnych portach przełącznika itp. Tak więc, chociaż ACI jest zbudowane wokół sieci fizycznej, połączenia dla serwerów wirtualnych wyglądają znacznie prościej niż dla fizycznych. ACI ma już wbudowaną łączność z VMWare i MS Hyper-V, a także obsługę wirtualizacji OpenStack i RedHat. Od pewnego czasu pojawiło się też wbudowane wsparcie dla platform kontenerowych: Kubernetes, OpenShift, Cloud Foundry, przy czym dotyczy to zarówno stosowania polityk, jak i monitorowania, czyli administrator sieci od razu widzi, na jakich hostach działają jakie pody i do jakich grup należą.
Oprócz przynależności do określonej grupy portów serwery wirtualne mają dodatkowe właściwości: nazwę, atrybuty itp., które mogą służyć jako kryteria przenoszenia ich do innej grupy, na przykład w przypadku zmiany nazwy maszyny wirtualnej lub pojawienia się dodatkowego znacznika w To. Cisco nazywa to grupami mikrosegmentacji, chociaż w zasadzie sam projekt z możliwością tworzenia wielu segmentów bezpieczeństwa w postaci EPG w tej samej podsieci jest również dość mikrosegmentacją. Cóż, sprzedawca wie lepiej.
EPG same w sobie są konstrukcjami czysto logicznymi, niezwiązanymi z konkretnymi przełącznikami, serwerami itp., dzięki czemu można z nimi i opartymi na nich konstrukcjami (aplikacjami i dzierżawcami) robić rzeczy, które są trudne do wykonania w zwykłych sieciach, takie jak klonowanie. W rezultacie powiedzmy, że bardzo łatwo jest sklonować środowisko produkcyjne, aby uzyskać środowisko testowe, które z pewnością będzie identyczne ze środowiskiem produkcyjnym. Możesz to zrobić ręcznie, ale jest to lepsze (i łatwiejsze) przez API.
Ogólnie rzecz biorąc, logika sterowania w ACI wcale nie jest podobna do tego, co zwykle spotykasz
w tradycyjnych sieciach tego samego Cisco: interfejs oprogramowania jest nadrzędny, a GUI lub CLI drugorzędne, ponieważ działają przez to samo API. Dlatego prawie wszyscy zaangażowani w ACI po jakimś czasie zaczynają poruszać się po modelu obiektowym służącym do zarządzania i automatyzować coś pod swoje potrzeby. Najłatwiej to zrobić w Pythonie: są do tego wygodne, gotowe narzędzia.
Obiecany rake
Główny problem polega na tym, że wiele rzeczy w ACI robi się inaczej. Aby zacząć z nim normalnie pracować, musisz się przekwalifikować. Jest to szczególnie prawdziwe w przypadku zespołów operacji sieciowych u dużych klientów, gdzie inżynierowie od lat „przepisują sieci VLAN” na żądanie. Fakt, że teraz sieci VLAN nie są już sieciami VLAN i nie trzeba tworzyć sieci VLAN ręcznie, aby umieścić nowe sieci w zwirtualizowanych hostach, całkowicie zdmuchuje dach z tradycyjnych sieciowców i sprawia, że trzymają się znanych podejść. Warto zaznaczyć, że Cisco postarało się nieco osłodzić pigułkę i dodało do kontrolera CLI „podobne do NXOS”, co pozwala na konfigurację z poziomu interfejsu podobnego do tradycyjnych przełączników. Ale nadal, aby zacząć normalnie korzystać z ACI, musisz zrozumieć, jak to działa.
Pod względem ceny, na dużą i średnią skalę, sieci ACI właściwie nie różnią się od tradycyjnych sieci na sprzęcie Cisco, gdyż do ich budowy wykorzystywane są te same przełączniki (Nexus 9000 może pracować w trybie ACI oraz w trybie tradycyjnym i stał się obecnie głównym „koń pociągowy” dla nowych projektów centrów danych). Ale w przypadku centrów danych składających się z dwóch przełączników obecność kontrolerów i architektury Spine-Leaf jest oczywiście odczuwalna. Niedawno pojawiła się fabryka Mini ACI, w której dwa z trzech kontrolerów zastąpiono maszynami wirtualnymi. Zmniejsza to różnicę w kosztach, ale nadal pozostaje. Tak więc dla klienta wybór jest podyktowany tym, jak bardzo jest zainteresowany funkcjami bezpieczeństwa, integracją z wirtualizacją, jednym punktem kontroli i tak dalej.
Źródło: www.habr.com