Tämän maagisen Ciscon ACI-skriptin avulla voit nopeasti perustaa verkon.
Cisco ACI -palvelinkeskuksen verkkotehdas on ollut olemassa viisi vuotta, mutta Habré ei kertonut siitä oikeastaan mitään, joten päätin korjata sitä hieman. Kerron omasta kokemuksestani, mikä se on, mitä hyötyä siitä on ja missä sillä on harava.
Mikä se on ja mistä se tuli?
Siihen mennessä, kun ACI (Application Centric Infrastructure) julkistettiin vuonna 2013, kilpailijat etenivät perinteisiä lähestymistapoja datakeskusverkkoihin kolmelta puolelta kerralla.
Toisaalta OpenFlowiin perustuvat "ensimmäisen sukupolven" SDN-ratkaisut lupasivat tehdä verkoista joustavampia ja samalla halvempia. Ajatuksena oli siirtää perinteisesti omalla kytkinohjelmistolla tehty päätöksenteko keskusohjaimelle.
Tällä ohjaimella olisi yksi näkemys kaikesta, mitä tapahtuu, ja sen perusteella se ohjelmoisi kaikkien kytkimien laitteistot tiettyjen virtausten käsittelyn sääntöjen tasolla.
Toisaalta overlay-verkkoratkaisut mahdollistivat tarvittavien liitettävyys- ja suojauspolitiikkojen toteuttamisen ilman fyysisen verkon muutoksia, rakentamalla ohjelmistotunneleita virtualisoitujen isäntien välille. Tunnetuin esimerkki tästä lähestymistavasta oli Nicira, jonka VMWare oli tuolloin jo ostanut 1,26 miljardilla dollarilla ja josta syntyi nykyinen VMWare NSX. Tilanteeseen lisäsi hieman pikantiteettia se, että Niciran perustajat olivat samat henkilöt, jotka olivat aiemmin OpenFlow'n alkulähteillä, sanoen nyt, että palvelinkeskustehtaan rakentamiseksi .
Ja lopuksi, avoimilla markkinoilla saatavilla olevat vaihtosirut (niin sanottu kauppiaspii) ovat saavuttaneet kypsyysasteen, jossa niistä on tullut todellinen uhka perinteisille kytkimien valmistajille. Jos aiemmin jokainen myyjä kehitti itsenäisesti siruja kytkimilleen, niin ajan myötä kolmansien osapuolien valmistajien, pääasiassa Broadcomin, sirut alkoivat vähentää etäisyyttä toimittajasirujen kanssa toimintojen suhteen ja ylittivät ne hinta/suorituskykysuhteessa. Siksi monet uskoivat, että heidän oman suunnittelunsa sirujen kytkimien päivät olivat luettuja.
ACI:sta on tullut Ciscon "epäsymmetrinen vastaus" (tarkemmin sanottuna sen entisten työntekijöiden perustama Insieme-yhtiö) kaikkeen yllä olevaan.
Mitä eroa OpenFlowilla on?
Mitä tulee toimintojen jakautumiseen, ACI on itse asiassa OpenFlow'n vastakohta.
OpenFlow-arkkitehtuurissa ohjain vastaa yksityiskohtaisten sääntöjen (kulkujen) kirjoittamisesta.
kaikkien kytkimien laitteistossa, eli suuressa verkossa, se voi olla vastuussa kymmenien miljoonien tietueiden ylläpidosta ja, mikä tärkeintä, muuttamisesta verkon sadoissa pisteissä, joten sen suorituskyky ja luotettavuus muodostuvat pullonkaulaksi suuri toteutus.
ACI käyttää käänteistä lähestymistapaa: tietysti on myös ohjain, mutta kytkimet saavat siitä korkean tason deklaratiiviset käytännöt, ja kytkin itse suorittaa niiden renderöinnin laitteiston tiettyjen asetusten yksityiskohtiin. Ohjain voidaan käynnistää uudelleen tai sammuttaa kokonaan, eikä verkkoon tapahdu mitään pahaa, paitsi tietysti tämän hetken hallinnan puute. Mielenkiintoista on, että ACI:ssä on tilanteita, joissa OpenFlowta käytetään edelleen, mutta paikallisesti isännässä Open vSwitch -ohjelmointiin.
ACI on rakennettu kokonaan VXLAN-pohjaiseen overlay-siirtoon, mutta sisältää taustalla olevan IP-siirron osana yhtä ratkaisua. Cisco kutsui tätä "integroiduksi peittokuvaksi". Päätepisteenä ACI:ssa peittokuvalle useimmissa tapauksissa käytetään tehdaskytkimiä (ne tekevät tämän linkin nopeudella). Isäntien ei tarvitse tietää mitään tehtaasta, kapseloinnista jne., mutta joissain tapauksissa (esimerkiksi OpenStack-isäntien yhdistämiseksi) VXLAN-liikenne voidaan tuoda niille.
ACI:ssa peittoja käytetään paitsi joustavan yhteyden tarjoamiseen siirtoverkon kautta, myös metatietojen siirtämiseen (käytetään esimerkiksi suojauskäytäntöjen soveltamiseen).
Cisco käytti Broadcomin siruja aiemmin Nexus 3000 -sarjan kytkimissä. Nexus 9000 -perheessä, joka julkaistiin erityisesti tukemaan ACI:tä, toteutettiin alun perin hybridimalli, jonka nimi oli Merchant +. Kytkimessä käytettiin samanaikaisesti sekä uutta Broadcom Trident 2 -sirua että Ciscon kehittämää täydentävää sirua, joka toteuttaa kaiken ACI:n taikuuden. Ilmeisesti tämä mahdollisti tuotteen julkaisun nopeuttamisen ja kytkimen hintalapun alenemisen yksinkertaisesti Trident 2:een perustuvien mallien tasolle. Tämä lähestymistapa riitti ACI-toimitusten kahdeksi tai kolmeksi ensimmäiseksi vuodeksi. Tänä aikana Cisco on kehittänyt ja julkaissut seuraavan sukupolven Nexus 9000:n omilla siruillaan, joilla on enemmän suorituskykyä ja ominaisuuksia, mutta samalla hintatasolla. Ulkoiset spesifikaatiot vuorovaikutuksen suhteen tehtaalla säilyvät täysin. Samaan aikaan sisäinen täyttö on täysin muuttunut: jotain refaktorointia, mutta raudalle.
Kuinka Cisco ACI -arkkitehtuuri toimii
Yksinkertaisimmassa tapauksessa ACI on rakennettu Klose-verkon tai, kuten usein sanotaan, Spine-Leafin topologiaan. Selkärangan tason kytkimiä voi olla kahdesta (tai yhdestä, jos emme välitä vikasietoisuudesta) kuuteen. Vastaavasti mitä enemmän niitä on, sitä korkeampi on vikasietokyky (pienempi kaistanleveys ja luotettavuuden heikkeneminen onnettomuuden tai yhden selkärangan huollon sattuessa) ja kokonaissuorituskyky. Kaikki ulkoiset yhteydet menevät lehtitason kytkimiin: nämä ovat palvelimia ja telakka ulkoisiin verkkoihin L2:n tai L3:n kautta sekä APIC-ohjaimet. Yleisesti ottaen ACI:llä ei vain konfigurointia, vaan myös tilastojen keräämistä, vikojen seurantaa ja niin edelleen - kaikki tehdään ohjaimien rajapinnan kautta, joita on kolme vakiokokoisissa toteutuksissa.
Sinun ei tarvitse koskaan muodostaa yhteyttä kytkimiin konsolilla, edes verkon käynnistämiseksi: ohjain itse tunnistaa kytkimet ja kokoaa niistä tehtaan, mukaan lukien kaikkien palveluprotokollien asetukset, joten on muuten erittäin tärkeää kirjoita asennettavien laitteiden sarjanumerot muistiin asennuksen yhteydessä, jotta sinun ei myöhemmin tarvitse arvailla, mikä kytkin on missä telineessä sijaitsee. Vianmääritystä varten voit tarvittaessa muodostaa yhteyden kytkimiin SSH:n kautta: ne toistavat tavalliset Ciscon show-komennot melko huolellisesti.
Tehdas käyttää sisäisesti IP-siirtoa, joten siinä ei ole Spanning Treeä ja muita menneisyyden kauhuja: kaikki linkit ovat mukana, ja konvergenssi häiriötilanteissa on erittäin nopeaa. Liikenne kudoksessa välittyy VXLAN-pohjaisten tunneleiden kautta. Tarkemmin sanottuna Cisco itse kutsuu iVXLAN-kapselointia, ja se eroaa tavallisesta VXLANista siinä, että verkon otsikon varattuja kenttiä käytetään palveluinformaation välittämiseen, ensisijaisesti liikenteen suhteesta EPG-ryhmään. Tämä mahdollistaa ryhmien välisen vuorovaikutuksen sääntöjen toteuttamisen laitteessa käyttämällä niiden numeroita samalla tavalla kuin osoitteita käytetään tavallisissa pääsylistoissa.
Tunnelit mahdollistavat sekä L2-segmenttien että L3-segmenttien (eli VRF) venytyksen sisäisen IP-kuljetuksen kautta. Tässä tapauksessa oletusyhdyskäytävä jaetaan. Tämä tarkoittaa, että jokainen kytkin on vastuussa kankaaseen tulevan liikenteen ohjaamisesta. Liikennevirtalogiikan kannalta ACI on samanlainen kuin VXLAN/EVPN-kudos.
Jos on, mitä eroja niillä on? Kaikki muu!
Suurin ero, jonka kohtaat ACI:n kanssa, on se, miten palvelimet yhdistetään verkkoon. Perinteisissä verkoissa sekä fyysisten palvelimien että virtuaalikoneiden sisällyttäminen menee VLAN-verkkoihin, ja kaikki muu tanssii niistä: liitettävyys, tietoturva jne. ACI:ssa käytetään mallia, jota Cisco kutsuu EPG:ksi (End-point Group), josta alkaen ei pääse mihinkään. Onko mahdollista rinnastaa se VLANiin? Kyllä, mutta tässä tapauksessa on mahdollisuus menettää suurin osa siitä, mitä ACI antaa.
EPG:n osalta kaikki pääsysäännöt on muotoiltu, ja ACI:ssä käytetään oletusarvoisesti "valkoisen listan" periaatetta, eli vain liikenne on sallittua, jonka läpikulku on nimenomaisesti sallittu. Eli voimme luoda "Web" ja "MySQL" EPG-ryhmät ja määritellä säännön, joka sallii viestinnän niiden välillä vain portissa 3306. Tämä toimii ilman verkko-osoitteisiin sidottua ja jopa samassa aliverkossa!
Meillä on asiakkaita, jotka ovat valinneet ACI:n juuri tämän ominaisuuden takia, koska sen avulla voit rajoittaa palvelinten välistä pääsyä (virtuaalista tai fyysistä - ei väliä) vetämällä niitä aliverkkojen välillä, eli koskematta osoitteisiin. Kyllä, kyllä, tiedämme, että kukaan ei määrää IP-osoitteita sovelluskokoonpanoissa käsin, eikö niin?
ACI:n liikennesääntöjä kutsutaan sopimuksiksi. Tällaisessa sopimuksessa yhdestä tai useammasta ryhmästä tai tasosta monitasoisessa sovelluksessa tulee palveluntarjoaja (esimerkiksi tietokantapalvelu), toisista tulee kuluttaja. Sopimus voi yksinkertaisesti siirtää liikennettä tai se voi tehdä jotain hankalampaa, esimerkiksi ohjata sen palomuuriin tai tasapainottimeen ja myös muuttaa QoS-arvoa.
Miten palvelimet pääsevät näihin ryhmiin? Jos nämä ovat fyysisiä palvelimia tai jotain, joka sisältyy olemassa olevaan verkkoon, johon loimme VLAN-rungon, niin sijoittaaksesi ne EPG:hen, sinun on osoitettava kytkimen porttia ja siinä käytettyä VLAN:ia. Kuten näet, VLAN-verkkoja esiintyy siellä, missä et voi tehdä ilman niitä.
Jos palvelimet ovat virtuaalikoneita, riittää, että viitataan yhdistettyyn virtualisointiympäristöön, ja sitten kaikki tapahtuu itsestään: VM:n yhdistämistä varten luodaan porttiryhmä (VMWaren kannalta), tarvittavat VLAN- tai VXLAN-verkot. Jos ne määritetään, ne rekisteröidään tarvittaviin kytkinportteihin jne. Joten vaikka ACI on rakennettu fyysisen verkon ympärille, virtuaalipalvelimien yhteydet näyttävät paljon yksinkertaisemmilta kuin fyysisten palvelimien. ACI:lla on jo sisäänrakennettu liitäntä VMWaren ja MS Hyper-V:n kanssa sekä tuki OpenStackille ja RedHat Virtualisaatiolle. Jossain vaiheessa on ilmaantunut myös sisäänrakennettu tuki konttialustoille: Kubernetes, OpenShift, Cloud Foundry, vaikka se koskee sekä käytäntöjen soveltamista että valvontaa, eli verkon ylläpitäjä näkee heti, millä isännillä mitkä podit toimivat ja mihin ryhmiin he kuuluvat.
Tiettyyn porttiryhmään kuulumisen lisäksi virtuaalipalvelimilla on lisäominaisuuksia: nimi, attribuutit jne., joita voidaan käyttää kriteereinä siirrettäessä ne toiseen ryhmään, esimerkiksi kun virtuaalikone nimetään uudelleen tai lisätunniste ilmestyy se. Cisco kutsuu tätä mikrosegmentointiryhmiksi, vaikka itse suunnittelu, jossa on mahdollisuus luoda useita suojaussegmenttejä EPG:iden muodossa samaan aliverkkoon, on myös melkoinen mikrosegmentointi. No, myyjä tietää paremmin.
EPG:t itsessään ovat puhtaasti loogisia rakenteita, joita ei ole sidottu tiettyihin kytkimiin, palvelimiin jne., joten niillä ja niihin perustuvilla rakenteilla (sovellukset ja vuokralaiset) voi tehdä asioita, joita on vaikea tehdä tavallisissa verkoissa, kuten kloonata. Tämän seurauksena oletetaan, että tuotantoympäristön kloonaaminen on erittäin helppoa, jotta saadaan testiympäristö, joka on taatusti identtinen tuotantoympäristön kanssa. Voit tehdä sen manuaalisesti, mutta se on parempi (ja helpompaa) API:n kautta.
Yleisesti ottaen ACI:n ohjauslogiikka ei ole ollenkaan samanlainen kuin tavallisesti
perinteisissä verkoissa samasta Ciscosta: ohjelmistorajapinta on ensisijainen ja GUI tai CLI ovat toissijaisia, koska ne toimivat saman API:n kautta. Siksi melkein kaikki ACI:ssä mukana olevat alkavat jonkin ajan kuluttua navigoida hallintaan käytetyssä objektimallissa ja automatisoida jotain tarpeidensa mukaan. Helpoin tapa tehdä tämä on Pythonista: siihen on käteviä valmiita työkaluja.
Luvattu rake
Suurin ongelma on, että monet asiat ACI:ssa tehdään eri tavalla. Jotta voit aloittaa työskentelyn sen kanssa normaalisti, sinun on koulutettava uudelleen. Tämä pätee erityisesti suurten asiakkaiden verkkotoimintojen ryhmiin, joissa insinöörit ovat "määrääneet VLANeja" vuosia pyynnöstä. Se, että nyt VLAN-verkot eivät ole enää VLAN-verkkoja ja sinun ei tarvitse luoda VLAN-verkkoja käsin uusien verkkojen rakentamiseksi virtualisoituihin isänteihin, räjäyttää perinteisiltä verkon käyttäjiltä täysin katon ja saa heidät tarttumaan tuttuihin lähestymistapoihin. On syytä huomata, että Cisco yritti hieman makeuttaa pilleriä ja lisäsi ohjaimeen "NXOS-tyyppisen" CLI: n, jonka avulla voit tehdä konfiguroinnin perinteisten kytkimien kaltaisesta käyttöliittymästä. Mutta silti, jotta voit aloittaa ACI:n käytön normaalisti, sinun on ymmärrettävä, miten se toimii.
Hinnaltaan suuressa ja keskikokoisessa mittakaavassa ACI-verkot eivät todellisuudessa eroa perinteisistä Cisco-laitteiden verkoista, koska niiden rakentamiseen käytetään samoja kytkimiä (Nexus 9000 voi toimia ACI-tilassa ja perinteisessä tilassa ja niistä on nyt tullut tärkein "työhevonen" uusille datakeskusprojekteille). Mutta kahden kytkimen datakeskuksissa ohjaimien ja Spine-Leaf-arkkitehtuurin läsnäolo tietysti tuntee itsensä. Äskettäin on ilmestynyt Mini ACI -tehdas, jossa kaksi kolmesta ohjaimesta on korvattu virtuaalisilla koneilla. Tämä pienentää kustannuseroa, mutta se pysyy silti. Asiakkaan valinnan määrää siis se, kuinka paljon hän on kiinnostunut tietoturvaominaisuuksista, integraatiosta virtualisointiin, yhdestä ohjauspisteestä ja niin edelleen.
Lähde: will.com