С помощта на тази магическа част от Cisco ACI скрипт, можете бързо да настроите мрежа.
Мрежовата фабрика за центъра за данни Cisco ACI съществува от пет години, но Хабре всъщност не каза нищо за това, така че реших да го поправя малко. Ще ви кажа от собствен опит какво е това, каква е ползата от него и къде има рейк.
Какво е това и откъде идва?
По времето, когато ACI (Application Centric Infrastructure) беше обявено през 2013 г., конкурентите напредваха в традиционните подходи към мрежите на центрове за данни от три страни едновременно.
От една страна, SDN решенията от "първо поколение", базирани на OpenFlow, обещаха да направят мрежите по-гъвкави и по-евтини в същото време. Идеята беше да се премести вземането на решения, традиционно извършвано от собствен софтуер за превключване, към централен контролер.
Този контролер ще има единна визия за всичко, което се случва и на базата на това ще програмира хардуера на всички комутатори на ниво правила за обработка на конкретни потоци.
От друга страна, мрежовите решения за наслагване направиха възможно прилагането на необходимите политики за свързаност и сигурност без никакви промени във физическата мрежа, изграждайки софтуерни тунели между виртуализирани хостове. Най-известният пример за този подход беше Nicira, която дотогава вече беше придобита от VMWare за $1,26 милиарда и даде началото на сегашния VMWare NSX. Известна пикантност на ситуацията беше добавена от факта, че съоснователите на Nicira бяха същите хора, които преди това стояха в началото на 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 архитектурата
В най-простия случай ACI е изграден върху топологията на мрежата Klose или, както често се казва, Spine-Leaf. Превключвателите на ниво гръбначен стълб могат да бъдат от два (или един, ако не ни интересува устойчивостта на грешки) до шест. Съответно, колкото повече от тях, толкова по-висока е устойчивостта на грешки (колкото по-ниска е честотната лента и намаляването на надеждността в случай на авария или поддръжка на един Spine) и общата производителност. Всички външни връзки отиват към комутатори на ниво лист: това са сървъри и докинг с външни мрежи през 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 trunk, тогава, за да ги поставите в 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 factory, в който два от трите контролера са заменени с виртуални машини. Това намалява разликата в разходите, но все още остава. Така че за клиента изборът се диктува от това доколко той се интересува от функции за сигурност, интеграция с виртуализация, единна точка на контрол и т.н.
Източник: www.habr.com