Мрежна ткаенина за центарот за податоци Cisco ACI - за помош на администраторот

Со помош на ова магично парче Cisco ACI скрипта, можете брзо да поставите мрежа.

Мрежната фабрика за центарот за податоци Cisco ACI постои пет години, но Хабре навистина не кажа ништо за тоа, па решив малку да го поправам. Од мое искуство ќе ви кажам што е тоа, каква е употребата од него и каде има гребло.

Што е тоа и од каде потекнува?

До моментот кога ACI (Application Centric Infrastructure) беше објавена во 2013 година, конкурентите напредуваа на традиционалните пристапи кон мрежите на центрите за податоци од три страни одеднаш.

Од една страна, „првата генерација“ SDN решенија базирани на OpenFlow ветија дека ќе ги направат мрежите пофлексибилни и поевтини во исто време. Идејата беше да се премести донесувањето одлуки што традиционално се прави со комерцијален софтвер за префрлување на централен контролер.

Овој контролер би имал единствена визија за сè што се случува и, врз основа на тоа, би го програмирал хардверот на сите прекинувачи на ниво на правила за обработка на специфични текови.
Од друга страна, преклопените мрежни решенија овозможија да се имплементираат неопходните политики за поврзување и безбедност без никакви промени во физичката мрежа, градејќи софтверски тунели помеѓу виртуелизираните хостови. Најпознат пример за овој пристап беше Nicira, која дотогаш веќе беше купена од VMWare за 1,26 милијарди долари и го роди сегашниот VMWare NSX. Одредена пикантност на ситуацијата беше додадена со фактот дека ко-основачите на Ницира беа истите луѓе кои претходно стоеја во потеклото на OpenFlow, сега велејќи дека за да се изгради фабрика за центри за податоци OpenFlow не е соодветен.

И конечно, преклопните чипови достапни на отворениот пазар (она што се нарекува трговски силикон) достигнаа фаза на зрелост каде што станаа вистинска закана за традиционалните производители на прекинувачи. Ако порано секој продавач самостојно развиваше чипови за своите прекинувачи, тогаш со текот на времето, чиповите од трети производители, првенствено од 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 Architecture

Во наједноставен случај, ACI е изграден на топологијата на мрежата Клосе, или, како што често велат, Spine-Leaf. Прекинувачите на ниво на 'рбетот може да бидат од два (или еден, ако не се грижиме за толеранцијата на дефекти) до шест. Соодветно на тоа, колку повеќе од нив, толку е поголема толеранцијата на грешки (толку е помала пропусноста и намалувањето на доверливоста во случај на несреќа или одржување на еден 'рбет) и севкупните перформанси. Сите надворешни врски одат на прекинувачи на ниво на лист: тоа се сервери и приклучување со надворешни мрежи преку L2 или L3 и поврзување на APIC контролери. Во принцип, со ACI, не само конфигурација, туку и собирање статистики, следење на неуспеси и така натаму - сè се прави преку интерфејсот на контролорите, од кои има три во имплементации со стандардна големина.

Никогаш не треба да се поврзувате со прекинувачите со конзолата, дури и за да ја стартувате мрежата: самиот контролер ги открива прекинувачите и составува фабрика од нив, вклучувајќи ги поставките на сите сервисни протоколи, затоа, патем, многу е важно да се запишете ги сериските броеви на опремата што се инсталира за време на инсталацијата, за подоцна да не морате да погодувате кој прекинувач во кој решетката се наоѓа. За решавање проблеми, доколку е потребно, можете да се поврзете со прекинувачите преку SSH: тие доста внимателно ги репродуцираат вообичаените команди за прикажување на 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 виртуелизација. Од одреден момент, се појави и вградена поддршка за контејнерски платформи: Kubernetes, OpenShift, Cloud Foundry, додека се однесува и на примената на политиките и на мониторингот, односно администраторот на мрежата може веднаш да види на кои хостови работат и во кои групи спаѓаат.

Покрај тоа што се вклучени во одредена група на порти, виртуелните сервери имаат дополнителни својства: име, атрибути итн., кои можат да се користат како критериуми за нивно пренесување во друга група, на пример, кога VM се преименува или се појавува дополнителна ознака во тоа. Cisco ова го нарекува групи на микро-сегментација, иако, во голема мера, самиот дизајн со способност да создаде многу безбедносни сегменти во форма на EPG на истата подмрежа е исто така прилично микро-сегментација. Па, продавачот знае подобро.

Самите EPG се чисто логички конструкции, не се врзани за специфични прекинувачи, сервери итн., така што можете да правите работи со нив и конструкции врз основа на нив (апликации и станари) што е тешко да се направат во обичните мрежи, како што е клонирањето. Како резултат на тоа, да речеме дека е многу лесно да се клонира производствена средина за да се добие средина за тестирање која гарантирано е идентична со производната средина. Можете да го направите тоа рачно, но тоа е подобро (и полесно) преку API.

Генерално, контролната логика во ACI воопшто не е слична на она што обично го среќавате
во традиционалните мрежи од истиот Cisco: софтверскиот интерфејс е примарен, а GUI или CLI се секундарни, бидејќи тие работат преку истиот API. Затоа, скоро сите вклучени во ACI, по некое време, почнуваат да се движат по моделот на објект што се користи за управување и да автоматизираат нешто што одговара на нивните потреби. Најлесен начин да го направите ова е од Python: има погодни готови алатки за тоа.

Ветено гребло

Главниот проблем е што многу работи во ACI се прават поинаку. За да започнете да работите со него нормално, треба да се преквалификувате. Ова е особено точно за тимовите за мрежни операции со големи клиенти, каде што инженерите со години „препишуваат VLAN“ на барање. Фактот што сега VLAN-овите повеќе не се VLAN-ови и не треба рачно да креирате VLAN-и за да поставите нови мрежи во виртуелизирани хостови, целосно го отфрла покривот од традиционалните мрежни уреди и ги тера да се држат до познатите пристапи. Треба да се напомене дека Cisco се обиде малку да ја заслади пилулата и додаде CLI „како NXOS“ на контролорот, што ви овозможува да направите конфигурација од интерфејс сличен на традиционалните прекинувачи. Но, сепак, за да започнете нормално да го користите ACI, треба да разберете како функционира.

Во однос на цената, на големи и средни размери, ACI мрежите всушност не се разликуваат од традиционалните мрежи на опремата на Cisco, бидејќи истите прекинувачи се користат за нивна изградба (Nexus 9000 може да работи во ACI и во традиционален режим и сега станаа главни „работно коњ“ за нови проекти за центри за податоци). Но, за центрите за податоци на два прекинувачи, присуството на контролери и архитектурата на Spine-Leaf, се разбира, се чувствуваат. Неодамна се појави фабрика за Mini ACI, во која два од трите контролери се заменети со виртуелни машини. Ова ја намалува разликата во трошоците, но сепак останува. Значи, за клиентот, изборот е диктиран од тоа колку тој е заинтересиран за безбедносни карактеристики, интеграција со виртуелизација, единствена точка на контрола итн.

Извор: www.habr.com