С помощта на този магически парче скрипт Cisco ACI можете бързо да конфигурирате мрежата.
Мрежовата фабрика за ЦОД Cisco ACI съществува вече пет години, но за нея не е било казано почти нищо в Хабр, затова реших да поправя това. Ще споделя от собствения си опит какво е това, каква е ползата от нея и къде са подводните камъни.
Какво е това и откъде е дошло?
Към момента на анонса на ACI (Application Centric Infrastructure) през 2013 година традиционните подходи към мрежите на ЦОД бяха подложени на натиск от конкуренти от три страни.
От една страна, SDN решенията "първо поколение" на база OpenFlow обещаваха да направят мрежите по-гъвкави и по-евтини едновременно. Идеята беше да се прехвърли вземането на решения, традиционно извършвано от собствен софтуер на комутаторите, на централен контролер.
Този контролер щеше да има единно виждане за всичко, което се случва, и на базата на това да програмира хардуера на всички комутатори на ниво правила за обработка на конкретни потоци.
От друга страна, оверлейните мрежови решения предоставяха възможност да се реализират необходимата свързаност и политики за сигурност, без да се променя физическата мрежа, изграждайки софтуерни тунели между виртуализираните хостове. Най-известният пример за такъв подход беше решението от Nicira, която по това време вече беше придобита от VMware за 1,26 милиарда долара и даде начало на настоящия VMware NSX. Някаква пикантност на ситуацията добавяше фактът, че съоснователите на Nicira бяха същите хора, които преди стояха в основата на OpenFlow, а сега твърдяха, че за изграждането на фабрика за ЦОД OpenFlow не е подходящ. .
И накрая, комутационните чипове, налични на отворения пазар (т. нар. merchant silicon), достигнаха степен на зрялост, при която те станаха реална заплаха за традиционните производители на комутатори. Докато преди всеки производител сам разработваше чипове за своите комутатори, с времето чиповете от външни производители, предимно от Broadcom, започнаха да съкращават дистанцията с производствените чипове по функции, а по отношение на цена/производителност ги превъзхождаха. Затова много хора считаха, че дните на комутаторите с чипове със собствена разработка са преброени.
ACI стана "асиметричен отговор" на Cisco (по-точно, на компанията Insieme, част от нея, основана от бивши нейни служители) на всичко изброено.
Каква е разликата с 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 не само настройката, но и събирането на статистика, мониторинга на откази и др. всичко се извършва през интерфейса на контролерите, които в обикновените внедрявания - са три.
Към комутаторите не е необходимо да се свързва никога, дори при стартиране на мрежата: контролерът сам открива комутаторите и изгражда фабриката от тях, включително настройките на всички служебни протоколи, поради което е изключително важно при монтажа да бъдат записани серийните номера на инсталираното оборудване, за да не се чудим после кой комутатор се намира в коя ракла. За отстраняване на проблеми, при необходимост, може да се свържете към комутаторите чрез SSH: на тях са достатъчно точно възпроизведени обичайните show-команди на Cisco.
Вътре фабриката използва IP транспорт, така че няма Spanning Tree и други ужасия от миналото: всички връзки са активни и времето за сближаване при откази е много бързо. Трафикът в фабриката се предава през тунели, базирани на VXLAN. По-точно, самата Cisco нарича инкапсулацията iVXLAN, която се отличава от обичайния VXLAN, тъй като резервираните полета в мрежовия заглавие се използват за предаване на служебна информация, преди всичко — за връзката на трафика с групата EPG. Това позволява реализиране на правила за взаимодействие между групите в хардуера, използвайки техните номера по същия начин, както в обичайните списъци за достъп се използват адреси.
Тунелите позволяват разширяване както на L2 сегменти, така и на L3 (тоест VRF) през вътрешния IP транспорт. В този случай шлюзът по подразбиране е разпределен. Това означава, че маршрутизацията на входящия трафик в фабриката се извършва от всеки комутатор. В частта на логиката за предаване на трафик 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
