З дапамогай вось гэтага чарадзейнага кавалка скрыпту Cisco ACI можна хутка наладзіць сетку.
Сеткавая фабрыка для ЦАД Cisco ACI існуе ўжо пяць гадоў, але на Хабре пра яе толкам нічога не расказана, вось і вырашыў гэта крыху выправіць. Распавяду на сваім досведзе, што гэта такое, якая ад яе карысць і дзе ў яе граблі.
Што гэта і адкуль узялося?
Да моманту анонсу ACI (Application Centric Infrastructure) у 2013 годзе на традыцыйныя падыходы да сетак ЦАД наступалі канкурэнты адразу з трох бакоў.
З аднаго боку, SDN-рашэнні "першага пакалення" на базе OpenFlow абяцалі зрабіць сеткі больш гнуткімі і таннымі адначасова. Ідэя была ў тым, каб вынесці прыняцце рашэнняў, традыцыйна выкананае прапрыетарным софтам камутатараў, на цэнтральны кантролер.
Гэты кантролер меў бы адзінае бачанне ўсяго, што адбываецца і, зыходзячы з гэтага, праграмаваў бы апаратуру ўсіх свіцей на ўзроўні правілаў апрацоўкі канкрэтных патокаў.
З іншага боку, оверлейныя сеткавыя рашэнні давалі магчымасць рэалізоўваць патрэбную складнасць і палітыкі бяспекі наогул без змен у фізічнай сетцы, будуючы праграмныя тунэлі паміж віртуалізаванымі хастамі. Найбольш вядомым прыкладам такога падыходу было рашэнне ад Nicira, якая да таго моманту ўжо была набыта VMWare за 1,26 мільярда долараў і дала пачатак цяперашняму VMWare NSX. Некаторай пікантнасці сітуацыі дадавала тое, што сузаснавальнікамі Nicira з'яўляліся тыя ж людзі, што раней стаялі ля вытокаў 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 будуецца па тапалогіі сеткі Клоза, ці, як яшчэ часта кажуць, Spine-Leaf. Камутатараў Spine-ўзроўню можа быць ад двух (ці аднаго, калі нас не хвалюе адмоваўстойлівасць) да шасці. Адпаведна, чым іх больш, тым вышэй адмоваўстойлівасць (менш зніжэнне паласы і надзейнасці пры аварыі ці абслугоўванні аднаго Spine) і агульная прадукцыйнасць. Усе вонкавыя падлучэнні ідуць у камутатары Leaf-узроўня: гэта і серверы, і стыкоўка з вонкавымі сеткамі па L2 ці па L3, і падлучэнне кантролераў APIC. Наогул з ACI не толькі налада, але і збор статыстыкі, маніторынг адмоў і іншае – усё робіцца праз інтэрфейс кантролераў, якіх ва ўкараненнях звычайнага памеру – тры штукі.
Да камутатараў кансоллю не даводзіцца падлучацца ніколі, нават для запуску сеткі: кантролер сам выяўляе камутатары і збірае з іх фабрыку, уключаючы налады ўсіх службовых пратаколаў, таму, дарэчы, вельмі важна пры мантажы запісаць серыйнікі ўсталёўванага абсталявання, каб потым не варажыць, які камутатар у якой стойцы знаходзіцца. Для траблшутинга да камутатараў пры неабходнасці можна падлучыцца па 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