Naudodami šį stebuklingą Cisco ACI scenarijaus dalį galite greitai nustatyti tinklą.
Cisco ACI duomenų centro tinklo gamykla gyvuoja penkerius metus, tačiau Habré apie tai nieko nesakė, todėl nusprendžiau šiek tiek pataisyti. Papasakosiu iš savo patirties, kas tai yra, kam jis naudingas ir kur jis turi grėblį.
Kas tai yra ir iš kur jis atsirado?
Iki to laiko, kai 2013 m. buvo paskelbta apie ACI (Application Centric Infrastructure), konkurentai žengė į priekį tradiciniuose duomenų centrų tinkluose iš trijų pusių vienu metu.
Viena vertus, „pirmosios kartos“ SDN sprendimai, pagrįsti „OpenFlow“, žadėjo tinklus padaryti lankstesnius ir tuo pačiu pigesnius. Idėja buvo perkelti sprendimų priėmimą, tradiciškai atliekamą naudojant patentuotą jungiklio programinę įrangą, į centrinį valdiklį.
Šis valdiklis turėtų vieną viziją apie viską, kas vyksta, ir pagal tai užprogramuotų visų jungiklių aparatinę įrangą konkrečių srautų apdorojimo taisyklių lygiu.
Kita vertus, perdangos tinklo sprendimai leido įgyvendinti reikiamas ryšio ir saugumo strategijas visiškai nekeičiant fizinio tinklo, kuriant programinės įrangos tunelius tarp virtualizuotų kompiuterių. Žinomiausias šio požiūrio pavyzdys buvo „Nicira“, kurią VMWare tuo metu jau įsigijo už 1,26 mlrd. USD ir iš jos atsirado dabartinis „VMWare NSX“. Situacijai pikantiškumo pridėjo ir tai, kad „Nicira“ įkūrėjai buvo tie patys žmonės, kurie anksčiau stovėjo prie „OpenFlow“ ištakų, dabar teigdami, kad norint pastatyti duomenų centro gamyklą .
Ir galiausiai, atviroje rinkoje esantys perjungimo lustai (vadinamasis prekybinis silicis) pasiekė tokį brandos etapą, kai tapo realia grėsme tradicinių jungiklių gamintojams. Jei anksčiau kiekvienas pardavėjas savarankiškai kūrė lustus savo jungikliams, tai laikui bėgant trečiųjų šalių gamintojų, visų pirma iš „Broadcom“, lustai pradėjo mažinti atstumą nuo tiekėjo lustų funkcijų atžvilgiu ir pralenkė juos pagal kainos ir našumo santykį. Todėl daugelis manė, kad jų pačių sukurtų lustų įjungimo dienos buvo suskaičiuotos.
ACI tapo „asimetrine Cisco“ reakcija (tiksliau, jos buvusių darbuotojų įkurta „Insieme“ įmonė) į visa tai, kas buvo minėta.
Kuo skiriasi „OpenFlow“?
Kalbant apie funkcijų pasiskirstymą, ACI iš tikrųjų yra OpenFlow priešingybė.
OpenFlow architektūroje valdiklis yra atsakingas už išsamių taisyklių (srauto) rašymą.
visų jungiklių aparatinėje įrangoje, tai yra dideliame tinkle, jis gali būti atsakingas už dešimčių milijonų įrašų palaikymą ir, svarbiausia, keitimą šimtuose tinklo taškų, todėl jo veikimas ir patikimumas tampa kliūtimi didelis įgyvendinimas.
ACI naudoja atvirkštinį metodą: žinoma, yra ir valdiklis, tačiau jungikliai iš jo gauna aukšto lygio deklaratyvią politiką, o pats jungiklis atlieka jų atvaizdavimą į konkrečių aparatinės įrangos nustatymų detales. Valdiklį galima perkrauti arba iš viso išjungti, ir tinklui nieko blogo nenutiks, išskyrus, žinoma, šiuo metu nekontroliuojamą. Įdomu tai, kad ACI yra situacijų, kai „OpenFlow“ vis dar naudojamas, bet vietoje pagrindinio kompiuterio „Open vSwitch“ programavimui.
ACI yra sukurtas tik VXLAN pagrindu pagrįstu perdangos transportavimu, tačiau apima pagrindinį IP transportavimą kaip vieno sprendimo dalį. „Cisco“ tai pavadino „integruotos perdangos“ terminu. Kaip ACI perdangų pabaigos taškas, daugeliu atvejų naudojami gamykliniai jungikliai (jie tai daro ryšio greičiu). Kompiuteriai neprivalo nieko žinoti apie gamyklą, inkapsuliavimą ir pan., tačiau kai kuriais atvejais (pavyzdžiui, norint prijungti „OpenStack“ pagrindinius kompiuterius), VXLAN srautas gali būti nukreiptas į juos.
Perdangos naudojamos ACI ne tik tam, kad būtų užtikrintas lankstus ryšys per transporto tinklą, bet ir perduodama metainformacija (ji naudojama, pavyzdžiui, taikant saugumo politiką).
„Broadcom“ lustus anksčiau „Cisco“ naudojo „Nexus 3000“ serijos jungikliuose. „Nexus 9000“ šeimoje, specialiai išleistoje ACI palaikyti, iš pradžių buvo įdiegtas hibridinis modelis, kuris vadinosi „Merchant +“. Jungiklis vienu metu naudojo ir naująjį Broadcom Trident 2 lustą, ir papildomą Cisco sukurtą lustą, kuris įgyvendina visą ACI magiją. Matyt, tai leido pagreitinti gaminio išleidimą ir sumažinti jungiklio kainą iki lygio, artimo modeliams, pagrįstiems tiesiog Trident 2. Tokio požiūrio pakako pirmiesiems dvejiems ar trejiems ACI pristatymo metams. Per tą laiką „Cisco“ sukūrė ir pristatė naujos kartos „Nexus 9000“ su savo lustais, pasižyminčius didesniu našumu ir funkcijų rinkiniu, tačiau už tą patį kainų lygį. Išorinės specifikacijos, susijusios su sąveika gamykloje, yra visiškai išsaugotos. Tuo pačiu metu visiškai pasikeitė vidinis užpildymas: kažkas panašaus į pertvarkymą, bet skirta techninei įrangai.
Kaip veikia Cisco ACI architektūra
Paprasčiausiu atveju ACI yra sukurta remiantis Klose tinklo topologija arba, kaip dažnai sakoma, Spine-Leaf. Stuburo lygio jungikliai gali būti nuo dviejų (arba vieno, jei nesirūpiname gedimų tolerancija) iki šešių. Atitinkamai, kuo jų daugiau, tuo didesnė gedimų tolerancija (mažesnis pralaidumas ir patikimumo sumažėjimas avarijos ar vieno stuburo priežiūros atveju) ir bendras veikimas. Visi išoriniai ryšiai eina į lapų lygio jungiklius: tai serveriai ir prijungimas prie išorinių tinklų per L2 ar L3 bei jungiantys APIC valdiklius. Apskritai su ACI ne tik konfigūravimas, bet ir statistikos rinkimas, gedimų stebėjimas ir panašiai – viskas daroma per valdiklių sąsają, kurių standartinio dydžio diegimuose yra trys.
Niekada nereikia prisijungti prie jungiklių su konsole, net norint paleisti tinklą: valdiklis pats aptinka jungiklius ir surenka iš jų gamyklą, įskaitant visų aptarnavimo protokolų nustatymus, todėl, beje, labai svarbu montavimo metu užsirašykite montuojamos įrangos serijos numerius, kad vėliau nereikėtų spėlioti, kuris jungiklis kuriame stove yra. Trikčių šalinimui, jei reikia, prie jungiklių galima prisijungti per SSH: jie gana kruopščiai atkuria įprastas Cisco show komandas.
Viduje gamykla naudoja IP transportą, todėl joje nėra Spanning Tree ir kitų praeities baisybių: įtraukiamos visos grandys, o gedimų atveju konvergencija vyksta labai greitai. Eismas audinyje perduodamas tuneliais, paremtais VXLAN. Tiksliau, pati „Cisco“ vadina iVXLAN inkapsuliacija ir nuo įprasto VXLAN skiriasi tuo, kad rezervuoti laukai tinklo antraštėje naudojami paslaugų informacijai perduoti, pirmiausia apie srauto ryšį su EPG grupe. Tai leidžia įgyvendinti įrangos grupių sąveikos taisykles, naudojant jų numerius taip pat, kaip adresai naudojami įprastuose prieigos sąrašuose.
Tuneliai leidžia tiek L2 segmentus, tiek L3 segmentus (t. y. VRF) ištempti per vidinį IP transportą. Tokiu atveju paskirstomas numatytasis šliuzas. Tai reiškia, kad kiekvienas jungiklis yra atsakingas už srauto, patenkančio į audinį, nukreipimą. Kalbant apie eismo srauto logiką, ACI yra panašus į VXLAN / EVPN audinį.
Jei taip, kokie yra skirtumai? Visa kita!
Pagrindinis skirtumas, su kuriuo susiduriate naudodami ACI, yra serverių prijungimas prie tinklo. Tradiciniuose tinkluose tiek fizinių serverių, tiek virtualių mašinų įtraukimas patenka į VLAN, o visa kita šoka nuo jų: jungiamumas, saugumas ir tt ACI naudojamas dizainas, kurį Cisco vadina EPG (End-point Group), iš kurio nėra kur pabėgti. Ar galima tai prilyginti VLAN? Taip, bet tokiu atveju yra galimybė prarasti didžiąją dalį to, ką duoda ACI.
Kalbant apie EPG, suformuluotos visos prieigos taisyklės, o ACI pagal nutylėjimą naudojamas „baltojo sąrašo“ principas, tai yra, leidžiamas tik srautas, kurio praėjimas yra aiškiai leidžiamas. Tai reiškia, kad galime sukurti „Web“ ir „MySQL“ EPG grupes ir apibrėžti taisyklę, leidžiančią tarp jų bendrauti tik per 3306 prievadą. Tai veiks neprisijungus prie tinklo adresų ir net tame pačiame potinklyje!
Turime klientų, kurie pasirinko ACI būtent dėl šios funkcijos, nes ji leidžia apriboti prieigą tarp serverių (virtualią ar fizinę – nesvarbu) nevilkant jų tarp potinklių, tai reiškia, neliečiant adreso. Taip, taip, mes žinome, kad niekas nenurodo IP adresų programų konfigūracijose ranka, tiesa?
Eismo taisyklės ACI vadinamos sutartimis. Tokioje sutartyje viena ar kelios grupės ar lygiai kelių pakopų programoje tampa paslaugų teikėju (tarkime, duomenų bazės paslauga), kiti – vartotoju. Sutartis gali tiesiog perduoti srautą arba padaryti ką nors sudėtingesnio, pavyzdžiui, nukreipti jį į ugniasienę arba balansavimo priemonę, taip pat pakeisti QoS reikšmę.
Kaip serveriai patenka į šias grupes? Jei tai yra fiziniai serveriai ar kažkas, įtrauktas į esamą tinklą, kuriame sukūrėme VLAN magistralę, tada norėdami juos įdėti į EPG, turėsite nurodyti jungiklio prievadą ir jame naudojamą VLAN. Kaip matote, VLAN atsiranda ten, kur be jų neapsieisite.
Jei serveriai yra virtualios mašinos, tada užtenka kreiptis į prijungtą virtualizacijos aplinką, o tada viskas vyks savaime: bus sukurta prievadų grupė (kalbant apie VMWare) VM prijungti, bus reikalingi VLAN arba VXLAN. Priskirti, jie bus užregistruoti reikiamuose komutatorių prievaduose ir pan. Taigi, nors ACI yra sukurta aplink fizinį tinklą, virtualių serverių jungtys atrodo daug paprastesnės nei fizinių. ACI jau turi integruotą ryšį su VMWare ir MS Hyper-V, taip pat palaiko OpenStack ir RedHat Virtualization. Nuo tam tikro momento atsirado ir integruotas konteinerių platformų palaikymas: „Kubernetes“, „OpenShift“, „Cloud Foundry“, nors tai susiję ir su politikos taikymu, ir su stebėjimu, ty tinklo administratorius gali iš karto matyti, kuriuose prieglobos kompiuteriuose veikia ir kurie blokai veikia. į kokias grupes jie patenka.
Be to, kad virtualūs serveriai yra įtraukti į tam tikrą prievadų grupę, jie turi papildomų ypatybių: pavadinimą, atributus ir kt., kurie gali būti naudojami kaip kriterijai juos perkelti į kitą grupę, tarkime, kai VM pervardijama arba joje atsiranda papildoma žyma. tai. „Cisco“ tai vadina mikrosegmentavimo grupėmis, nors apskritai pats dizainas, galintis sukurti daugybę saugos segmentų EPG pavidalu tame pačiame potinklyje, taip pat yra gana mikrosegmentavimas. Na, pardavėjas žino geriau.
Pačios EPG yra grynai loginės konstrukcijos, nesusietos su konkrečiais komutatoriais, serveriais ir pan., todėl su jais ir jų pagrindu sukurtomis konstrukcijomis galite atlikti tokius dalykus (programas ir nuomininkus), kuriuos sunku atlikti įprastuose tinkluose, pavyzdžiui, klonuoti. Dėl to, tarkime, labai lengva klonuoti gamybos aplinką, kad gautumėte bandomąją aplinką, kuri garantuotai bus identiška gamybinei aplinkai. Galite tai padaryti rankiniu būdu, bet tai geriau (ir lengviau) per API.
Apskritai ACI valdymo logika visai nepanaši į tą, kurią paprastai sutinkate
tradiciniuose tinkluose iš tos pačios Cisco: programinės įrangos sąsaja yra pagrindinė, o GUI arba CLI yra antrinė, nes jie veikia per tą pačią API. Todėl beveik visi, dalyvaujantys ACI, po kurio laiko pradeda naršyti valdymui naudojamą objekto modelį ir kažką automatizuoti, kad atitiktų savo poreikius. Lengviausias būdas tai padaryti yra iš Python: tam yra patogių paruoštų įrankių.
Pažadėtas grėblis
Pagrindinė problema yra ta, kad daugelis dalykų ACI atliekami skirtingai. Norint pradėti dirbti su juo įprastai, reikia persikvalifikuoti. Tai ypač pasakytina apie didelių klientų tinklo operacijų komandas, kur inžinieriai metų metus pagal pageidavimą „išrašo VLAN“. Tai, kad dabar VLAN nebėra VLAN ir jums nereikia rankomis kurti VLAN, kad virtualizuotuose pagrindiniuose kompiuteriuose būtų sukurti nauji tinklai, visiškai numuša stogą tradiciniams tinklo kūrėjams ir priverčia juos laikytis pažįstamų metodų. Reikėtų pažymėti, kad „Cisco“ bandė šiek tiek pasaldinti tabletes ir prie valdiklio pridėjo „NXOS“ tipo CLI, leidžiančią atlikti konfigūraciją iš sąsajos, panašios į tradicinius jungiklius. Bet vis tiek, norėdami pradėti naudoti ACI įprastai, turite suprasti, kaip jis veikia.
Kalbant apie kainą, dideliuose ir vidutiniuose masteliuose ACI tinklai iš tikrųjų nesiskiria nuo tradicinių „Cisco“ įrangos tinklų, nes jiems sukurti naudojami tie patys jungikliai („Nexus 9000“ gali veikti ACI ir tradiciniu režimu ir dabar tapo pagrindiniu „darbo arkliukas“ naujiems duomenų centrų projektams). Tačiau dviejų jungiklių duomenų centruose valdikliai ir Spine-Leaf architektūra, žinoma, jaučiasi. Neseniai pasirodė Mini ACI gamykla, kurioje du iš trijų valdiklių pakeisti virtualiomis mašinomis. Tai sumažina sąnaudų skirtumą, tačiau jis vis tiek išlieka. Taigi klientui pasirinkimą padiktuoja tai, kiek jis domisi saugumo funkcijomis, integracija su virtualizacija, vienu valdymo tašku ir pan.
Šaltinis: www.habr.com