С помощта на този вълшебен парче скрипт Cisco ACI можете бързо да настроите мрежата.
Мрежовата фабрика за ЦОД Cisco ACI съществува вече пет години, но в Хабра не е казано нищо съществено за нея, затова реших да го поправя. Ще споделя от личния си опит какво е това, каква полза носи и къде е капанът.
Какво е това и откъде идва?
Към момента на обявяването на ACI (Application Centric Infrastructure) през 2013 година, традиционните подходи към мрежите на ЦОД бяха заплашени от конкуренция от три страни.
От една страна, SDN решенията "първо поколение" на базата на OpenFlow обещаваха да направят мрежите по-гъвкави и по-евтини едновременно. Идеята беше да се прехвърли вземането на решения, което традиционно се извършва от собствен софтуер на комутаторите, на централен контролер.
Този контролер щеше да има единно виждане за всичко, което се случва, и на основата на това да програмира хардуера на всички комутатори на ниво правила за обработка на конкретни потоци.
От друга страна, оверлейните мрежови решения даваха възможност да се реализира необходимата свързаност и политики за сигурност без промени в физическата мрежа, изграждайки софтуерни тунели между виртуализираните хостове. Най-известният пример за такъв подход беше решението от Nicira, която по това време вече беше придобита от VMWare за 1,26 милиарда долара и даде начало на настоящия VMWare NSX. Някакво пикантно относно ситуацията беше, че съоснователите на Nicira бяха същите хора, които преди това бяха зад основоположниците на OpenFlow и сега заявяваха, че за изграждането на фабрика за ЦОД .
Накрая, чиповете за комутация, налични на открития пазар (това, което се нарича merchant silicon), достигнаха зрялост, при която станаха реална заплаха за традиционните производители на комутатори. Ако преди всеки вендор сам проектираше чипове за своите комутатори, с времето чиповете от трети производители, най-вече от Brоadcom, започнаха да съкращават дистанцията с вендорските чипове по функции, а по отношение на цена/производителност ги превъзхождаха. Докато много хора смятаха, че дните на комутаторите на чипове с собствена разработка са преброени.
ACI стана "асиметричен отговор" на Cisco (по-точно, на влязлата в състава компания Insieme, основана от бивши служители на Cisco) на всичко това.
Каква е разликата с OpenFlow?
От гледна точка на разпределението на функциите, ACI всъщност е противоположност на OpenFlow.
В архитектурата на OpenFlow контролерът отговаря за записването на детайлни правила (поток),
в хардуера на всички комутатори, т.е. в голяма мрежа той може да носи отговорността за поддържане и, най-важното, изменение на десетки милиони записи в стотици точки в мрежата, поради което производителността и надеждността му в голямо внедряване стават тясно място.
В ACI се използва обратен подход: контролерът, разбира се, съществува, но комутатори получават от него висококачествени декларативни политики, а техният рендеринг в детайли конкретни настройки в хардуера се извършва от самия комутатор. Контролерът може да бъде рестартиран или изключен, и с мрежата не би се случило нищо лошо, освен, разбира се, липсата на възможност за управление в този момент. Интересно е, че в ACI има ситуации, в които OpenFlow все пак се използва, но локално в рамките на хоста за програмиране на Open vSwitch.
ACI е изцяло изградена на базата на оверлейен транспорт с VXLAN, но също така включва в рамките на единно решение и основния IP транспорт. Cisco нарече това термин "интегриран оверлей". Като точка на терминиране на оверлеите в ACI в повечето случаи се използват комутатори от фабриката (правят го с канална скорост). Хостовете не са длъжни да знаят нещо за фабриката, инкапсуляцията и т.н., но в редица случаи (например, за свързване на OpenStack хостове) VXLAN трафикът може да достига и до тях.
Оверлеите в ACI се използват не само за осигуряване на гъвкава свързаност чрез транспортната мрежа, но и за предаване на метаинформация (тя се използва, например, за приложението на политиките за сигурност).
Чиповете от Broadcom вече се използваха от Cisco в комутаторите от серия Nexus 3000. В семейството Nexus 9000, специално издадено за поддръжка на ACI, първоначално беше реализирана хибридна модел, наречен Merchant+. В комутатора едновременно се използваха новият чип Broadcom Trident 2 и допълнителният чип, разработен от Cisco, който реализираше цялата магия на ACI. Очевидно това е позволило да се ускори въвеждането на продукта и да се намали цената на комутатора до ниво, близко до моделите, базирани само на Trident 2. Този подход беше достатъчен за първите две-три години на доставки на ACI. През това време Cisco разработи и издаде на пазара следващото поколение Nexus 9000 на собствените си чипове с по-висока производителност и набор от функции, но на същото ценово ниво. Външните спецификации по отношение на взаимодействието в фабриката останаха напълно непроменени. Въпреки това, вътрешната структура беше напълно променена: нещо като рефакторинг, но за хардуера.
Как е структурирана архитектурата на Cisco ACI
В най-простия случай ACI се изгражда по топологията на Clos, или, както често се нарича, Spine-Leaf. Може да има от два (или един, ако не се интересуваме от отказоустойчивост) до шест комутатора от Spine ниво. Съответно, колкото повече са те, толкова по-висока е отказоустойчивостта (по-малко намаляване на пропускателната способност и надеждността при авария или обслужване на един Spine) и общата производителност. Всички външни свързвания идват в комутаторите от Leaf ниво: това са и сървъри, и свързаност с външни мрежи по L2 или L3, и свързване на контролерите APIC. С ACI не само настройката, но и събиране на статистика, мониторинг на повреди и др. — всичко това се извършва през интерфейса на контролерите, от които в инсталации с нормален размер — три броя.
Никога не е необходимо да се свързвате с комутаторите чрез конзола, дори за стартиране на мрежата: контролерът сам открива комутаторите и изгражда фабриката от тях, включително настройки на всички служебни протоколи. Затова, за монтаж, е много важно да запишете сериен номер на инсталираното оборудване, за да не се чудите по-късно кой комутатор е в коя стойка. За troubleshooting при необходимост може да се свържете с комутаторите по SSH: при тях са достатъчно точно възпроизведени обичайните show-команди на Cisco.
Вътре във фабриката се използва IP транспорт, така че няма Spanning Tree и други страхотии от миналото: всичките линкове са активни, а съвместимостта при откази е много бърза. Трафикът в фабриката се предава чрез тунели, основаващи се на VXLAN. По-точно, самата Cisco нарича инкапсулацията iVXLAN, и тя се различава от обикновения VXLAN по това, че резервираните полета в мрежовия заглавие се използват за предаване на служебна информация, най-вече - относно отношението на трафика към групата EPG. Това позволява реализирането на правила за взаимодействие между групите в апаратурата, използвайки техните номера, така както в обикновените списъци за достъп се използват адреси.
Тунелите позволяват разширяване чрез вътрешния IP транспорт и L2 сегменти, и L3 (т.е. VRF). В този случай шлюзът по подразбиране е разпределен. Това означава, че маршрутизацията на входящия трафик във фабриката се извършва от всеки комутатор. По отношение на логиката на предаване на трафика, ACI е подобен на фабрика, основана на VXLAN/EVPN.
Ако е така, какви са разликите? В всичко останало!
Разликата номер едно, с която се сблъсквате в ACI, е как се свързват сървърите в мрежата. В традиционните мрежи свързването на физическите сървъри и виртуалките става в VLAN-ове, и от тях зависи всичко останало: свързаност, сигурност и т.н. В ACI обаче се използва конструкция, която Cisco нарича EPG (End-point Group), от която няма как да се избегне. Може ли да я приравним на VLAN? Да, но в този случай има опасност да загубим голяма част от това, което ACI предлага.
Относно EPG се формулират всички правила за достъп, а в ACI по подразбиране се използва принципът на "белия списък", т.е. разрешен е само трафикът, който е разрешен изрично. Тоест можем да създадем EPG групи "Web" и "MySQL" и да определим правило, което позволява взаимодействие между тях само по порт 3306. Това ще работи без свързаност към мрежови адреси и дори в рамките на една подсистема!
Имаме клиенти, които избраха ACI именно заради тази функция, тъй като тя позволява ограничаване на достъпа между сървърите (виртуални или физически - не е важно), без да ги местим между подсистемите, а следователно, без да засягаме адресацията. Да-да, знаем, никой не записва ръчно IP адреси в конфигурациите на приложенията, нали?
Правилата за преминаване на трафик в ACI се наричат контракти. В такъв контракт една или повече групи или нива в многозвенно приложение стават доставчици на услуги (да речем, услуги за база данни), а другите — потребители. Контрактът може просто да пропуска трафика, или да направи нещо по-сложно, например да насочи трафика към защитна стена или балансировчик, а също така да промени стойността на QoS.
Как сървърите попадат в тези групи? Ако това са физически сървъри или нещо, включено в съществуваща мрежа, в която сме създали VLAN-транк, то за да ги поставим в EPG, е необходимо да посочим порт на комутатора и използвания VLAN. Както виждаме, VLAN-ите се появяват там, където те са незаменими.
Ако сървърите са виртуални машини, достатъчно е да се позовем на свързаната среда за виртуализация и всичко ще се случи само: ще се създаде порт-група (говорейки в терминологията на VMWare) за свързване на VM, ще се назначат необходимите VLAN-и или VXLAN-и, ще се запишат на необходимите портове на комутаторите и т.н. Така че, въпреки че ACI е изградена около физическа мрежа, свързването на виртуални сървъри изглежда много по-просто, отколкото за физически. В ACI вече е внедрена интеграция с VMWare и MS Hyper-V, а също така има поддръжка за OpenStack и RedHat Virtualization. От известно време се появи и вградена поддръжка за контейнерни платформи: Kubernetes, OpenShift, Cloud Foundry, като тя засяга както прилагането на политики, така и мониторинга, т.е. мрежовият администратор може веднага да види на кой хост какви поди работят и в какви групи са попаднали.
Освен включването в определена порт-група, виртуалните сървъри имат допълнителни свойства: име, атрибути и т.н., които могат да се използват като критерии за преместването им в друга група, например при преименуване на VM или появата на допълнителен етикет. Cisco нарича това микросегментационни групи, въпреки че, ако сме откровени, самата конструкция, позволяваща създаването на много сегменти за сигурност под формата на EPG в същата подсет, също е напълно микросегментация. Но на производителя му е ясно.
EPG самите по себе си са чисто логически конструкции, които не са свързани с конкретни комутатори, сървъри и т.н., така че с тях и базираните на тях конструкции (приложения и тенанти) могат да се правят неща, които е трудно да се осъществят в стандартни мрежи, например, клониране. В резултат на това, е много лесно да се създаде клон на продуктивна среда, за да се получи тестова среда, която е гарантирано идентична на продуктивната. Може да се направи ръчно, но е по-добре (и по-лесно) — чрез API.
Като цяло логиката за управление в ACI изобщо не прилича на това, което обикновено срещаш
в традиционните мрежи на същата Cisco: софтуерният интерфейс е основен, а GUI или CLI са вторични, тъй като работят чрез същото API. Затова почти всеки, който работи с ACI, след известно време започва да се ориентира в обектната модель, използвана за управление, и да автоматизира нещо според собствените си нужди. Най-лесно е да се прави от Python: за него има удобни готови инструменти.
Обещаните грабли
Главната проблема е, че много неща в ACI са направени по различен начин. За да започнеш нормално да работа с нея, трябва да се преобучиш. Особено това важи за екипите за мрежова експлоатация при големи клиенти, където инженерите години наред се занимават с "регистрация на VLAN-ове" по заявки. Това, че сега VLAN вече не е VLAN, а за прокарване на нови мрежи в виртуализирани хостове да се създават VLAN-ове ръчно изобщо не е необходимо, напълно "събаря" традиционните мрежови специалисти и ги кара да се задържат за познатите подходи. Трябва да се отбележи, че Cisco се опита да направи нещата малко по-лесни и добави в контролера "NXOS-подобен" CLI, който позволява настройка от интерфейс, подобен на традиционните комутатори. Но все пак, за да започнеш нормално да ползваш ACI, ще трябва да разбереш как работи.
От гледна точка на цената на големи и средни мрежи ACI, те не се различават особено от традиционните мрежи на оборудване Cisco, тъй като за изграждането им се използват едни и същи комутатори (Nexus 9000 могат да работят както в ACI, така и в традиционен режим и в момента са основната "работна коня" за нови проекти в ЦОД). Но за ЦОД, съставени от два комутатора, наличието на контролери и Spine-Leaf архитектура, разбира се, правят разликата. Съвсем наскоро се появи Mini ACI фабрика, в която двата контролера от три са заменени с виртуални машини. Това позволява да се намали разликата в цената, но тя все пак остава. Тъй като за клиента, изборът зависи от това доколко той се интересува от функции за сигурност, интеграция с виртуализация, единна точка за управление и други.
Източник: habr.com
