Cisco ACI – Pierwsze wyjście z mroku

Miałem przyjemność uczestniczyć w warsztatach organizowanych przez Cisco z zakresu rozwiązania Application Centric Infrastructure. Warsztaty te były podzielone to było na kilka części dzięki, którym udało się dotknąć w różnych aspektach rozwiązania ACI. Jest to pierwszy z artykułów z serii, która będzie miała na celu przybliżenie tematyki SDN w odsłonie Cisco.

Zatem, o co chodzi z ACI? Szereg perturbacji pomiędzy korporacjami VMware oraz Cisco i ich walka o rozwiązanie firmy Nicira doprowadziła do rozbieżności w wizji dalszej współpracy pomiędzy gigantami. Najbardziej na tym ucierpiały rozwiązania oparte o integrację VMware i Cisco takie jak konwergentne rozwiązanie vBlock czy wirtualny przełącznik Nexus 1000V. Działania te doprowadziły do rozłamu, które spowodowały powstanie rozwiązania Application Centric Infrastructure. Czy to dobrze, czy źle czas pokaże… Na ten moment najistotniejsze jest to, że architektura ta jest zupełnie nowym podejściem do rozwiązań sieciowych w datacenter. A samo wdrażanie ACI bardziej można postrzegać jako rewolucję w DC niż proces naturalnej ewolucji.

Architektura ACI

Stosując rozwiązanie ACI odchodzi się od wieków znanej i promowanej przez dużych vendorów architektury sieciowej składającej się z trzech warstw:

• Access
• Aggregation
• Core

Na rzecz rozwiązania bazującego na dwóch poziomach i ostatnio bardzo modnego czyli:

• Leaf
• Spine

Cisco ACI wpasowuje się we wszystkie obszary związane z budową sieci definiowanej programowo czyli SDN. Za równo w zakresie transportu danych jak i konfiguracji usług oraz polityk dostarczanych przez to rozwiązanie.

Sercem ACI jest kontroler APIC, który odpowiada za zarządzanie całą siecią zbudowaną w oparciu o Application Centric Infrastructure. Kontroler ten dostępny jest jako moduł do największego modelu Cisco z serii Nexus 9000. I jak łatwo się domyślić sprzętowo na ten moment ACI jest zamknięte wyłączenie na Cisco zarówno Nexus jak i USC.

Architektura leaf-spine wymaga, aby połączenia pomiędzy liściem (leaf), a rdzeniem (spine) były realizowane w oparciu o linki QSFP+ używane w standardzie 40G Ethernet.

Z założenia ACI jest architektura, która wydziela sieci klienckie (tzw. tenant) i koncentruje się na dostarczaniu aplikacji, a właściwie to dostępu do nich, co realizuje poprzez szereg polityk.

Na każdego Tenant-a przypada gro definicji go opisującego przedstawionych na rysunku poniżej.

Na temat każdego z tych elementów można by przygotować osoby artykuł co też najpewniej się stanie (niecierpliwych odsyłam do małego jak na Cisco przystało dokumentu – niecałe 200 stron o dumnej nazwie: Cisco Application Centric Infrastructure Fundamentals).

Aby było CIEKAWIEJ poniżej zrzut ekranu po zalogowaniu do nowego rozwiązania dostarczonego przez Cisco.

Interfejs jak na wersje 1.0.2 wymaga jeszcze trochę dopracowania. Co jest zadziwiającym podejściem to GUI na zasadzie Matrioszki, czyli wybierając jakąś opcję otwiera się nam nowe okno z nowymi ustawieniami i dzieje się tak długo, aż dotrzemy do pozycji tak gębko zaszytej, że pozostaje nam wytrwale już klikać Apply i Close. Interfejs ten jest dostępny przez www i pomimo swojego skomplikowania po kilku dniach klikania okazał się w dość przejrzysty, a jak na Cisco przystało działał bardzo stabilnie.

Przykład ustawiania części polityki znajduje się na rysunku poniżej.

Wyklinanie wielopoziomowego GUI na końcu drogi doprowadza nas do stanu gdzie określamy zestaw polityk składających się z reguł QoS oraz filtrów dla każdej z aplikacji jaka znajduje się w tenancie.

Drobny przykład

Aplikacja udostępniająca stronę www posiada zestaw reguł QoS oraz filtrów zezwalających wyłącznie na ruch do portu 80, natomiast komunikacja pomiędzy serwerem www, a serwerem aplikacyjnym jest zezwolona do określonej usługi portach. Analogiczna sytuacja jest określona pomiędzy serwerem bazodanowym, a serwerem aplikacyjnym. Ładny rysunek przedstawiający przykładowego tenatna znajduje się poniżej.

Wizualizacja po stronie interfejsu ACI powyższej polityki przedstawia się następująco:

Podsumowanie

Moim zdaniem Cisco z ACI wprowadzi w najbliższym czasie ogromną rewolucję. Dotychczasowe rozwiązania okażą się mało skalowalne i mało wydajne w obliczu konterenyzacji oraz wirtualizacji wszelkich obszarów IT. Raptem kilka lat temu, gdy była mowa o wirtualizacji serwerów był odczuwalny ogromny opór. Dzisiaj jest zupełnie odwrotnie, w momencie w którym mówimy, że czegoś nie wirtualizujemy powstaje szereg pytań dlaczego?

W datacenter gdzie sercem sieci jest Nexus 9000, a właściwie dwa – bo HA i takie tam. Jednym z naszych głównych celów staje się w pełni wykorzystać wszystkie funkcjonalności jakie dostarcza ACI. W końcu zapłaciliśmy za to rozwiązanie nieskończoną liczbę pieniędzy i zmusiliśmy się oprzeć cały stos sieciowy wyłącznie na jednym dostawy jakim jest Cisco. Zatem integracja i funkcjonalności to jedyne co usprawiedliwia nasz wybór. Dorzućmy do tego rodzinę serwerów UCS, integrację z vSphere 5.5 (nie wiadomo jak to będzie z wersją 6.0), za chwilę Hyper-V, a za dwie OpenStack… Dostaniemy niezwykle funkcjonalny kombajn sieciowy osiągając upragniony cel – uproszczenie infrastruktury, skalowalność, intekompatybilność software i jeden punkt kontaktu technicznego. Niestety jak to bywa z wyborem „koszernego” dostawcy, możemy na 100% zamknąć sobie drogę na inne rozwiązania sprzętowe. Czy to jest dobre? Jak to w informatyce bywa nie ma na to jednoznacznej odpowiedzi. Nieśmiertelne „to zależy” znów bierze górę… Wydaję się, że każdy przez pryzmat swojej infrastruktury powinien odpowiedzieć sobie na to pytanie. Tym niemniej Nexus 9K + ACI powinny się znaleźć w naszej i tak już opasłej liście rzeczy „do testów” bo trudno wyrazić uniwersalną opinię o tym produkcie bez przyłożenia go do rzeczywistości.