A Cisco ACI szkript e varázslatos darabja segítségével gyorsan beállíthatja a hálózatot.
A Cisco ACI adatközpont hálózati gyára öt éve létezik, de Habré erről nem igazán árult el semmit, ezért úgy döntöttem, javítok rajta egy kicsit. Saját tapasztalatból mondom el, hogy mi ez, mi a haszna és hol van gereblye.
Mi ez és honnan származik?
Mire 2013-ban bejelentették az ACI-t (Application Centric Infrastructure), a versenytársak egyszerre három oldalról haladtak az adatközponti hálózatok hagyományos megközelítésén.
Egyrészt az OpenFlow-ra épülő "első generációs" SDN-megoldások azt ígérték, hogy rugalmasabbá és egyben olcsóbbá teszik a hálózatokat. Az ötlet az volt, hogy a hagyományosan védett kapcsolószoftverrel végzett döntéshozatalt egy központi vezérlőre helyezzék át.
Ennek a vezérlőnek egyetlen víziója lenne mindenről, ami történik, és ennek alapján programozná az összes kapcsoló hardverét az egyes folyamok feldolgozására vonatkozó szabályok szintjén.
Másrészt az overlay hálózati megoldások lehetővé tették a szükséges kapcsolódási és biztonsági szabályzatok megvalósítását a fizikai hálózaton végbemenő változtatások nélkül, szoftveralagutak kiépítésével a virtualizált gazdagépek között. Ennek a megközelítésnek a legismertebb példája a Nicira volt, amelyet addigra már 1,26 milliárd dollárért felvásárolt a VMWare, és a jelenlegi VMWare NSX létrejöttét eredményezte. Némi pikantériát adott a helyzetnek, hogy a Nicira társalapítói ugyanazok az emberek voltak, akik korábban az OpenFlow kiindulópontjánál álltak, most pedig azt mondják, hogy egy adatközpont-gyár felépítéséhez. .
És végül, a nyílt piacon elérhető kapcsolóchipek (amit kereskedői szilíciumnak neveznek) elértek egy olyan érettségi fokot, ahol valódi veszélyt jelentenek a hagyományos kapcsológyártók számára. Ha korábban minden gyártó önállóan fejlesztett chipeket a kapcsolóihoz, akkor idővel a külső gyártók, elsősorban a Broadcom chipjei csökkenteni kezdték a távolságot a gyártó chipekkel a funkciók tekintetében, és meghaladták őket az ár/teljesítmény arány tekintetében. Ezért sokan azt hitték, hogy a saját tervezésű chipeken történő kapcsolások napjai meg vannak számlálva.
Az ACI a Cisco (pontosabban az egykori alkalmazottai által alapított Insieme cég) "aszimmetrikus válasza" lett a fentiekre.
Mi a különbség az OpenFlow-tól?
A funkciók elosztását tekintve az ACI valójában az OpenFlow ellentéte.
Az OpenFlow architektúrában a vezérlő felelős a részletes szabályok (folyamatok) megírásáért.
az összes kapcsoló hardverében, vagyis egy nagy hálózatban több tízmillió rekord karbantartásáért és – ami a legfontosabb – módosításáért felelhet a hálózat több száz pontján, így teljesítménye és megbízhatósága szűk keresztmetszetet jelent a hálózatban. nagy megvalósítás.
Az ACI fordított megközelítést alkalmaz: természetesen van vezérlő is, de a kapcsolók magas szintű deklaratív házirendeket kapnak tőle, és a kapcsoló maga hajtja végre a megjelenítést a hardverben meghatározott beállítások részleteire. A vezérlő újraindítható vagy teljesen kikapcsolható, és semmi rossz nem fog történni a hálózattal, kivéve persze az irányítás hiányát ebben a pillanatban. Érdekes módon az ACI-ben vannak olyan helyzetek, amikor az OpenFlow továbbra is használatos, de helyileg a gazdagépen belül az Open vSwitch programozáshoz.
Az ACI teljes egészében VXLAN-alapú overlay szállításra épül, de egyetlen megoldás részeként tartalmazza az alapul szolgáló IP-átvitelt. A Cisco ezt "integrált fedvény" kifejezésnek nevezte. Az ACI-ben az átfedések végpontjaként a legtöbb esetben gyári kapcsolókat használnak (ezt linksebességgel teszik). A gazdagépeknek nem kell tudniuk semmit a gyárról, a tokozásról stb., azonban bizonyos esetekben (például OpenStack gazdagépek csatlakoztatásához) VXLAN forgalmat is lehet vinni rájuk.
Az átfedések az ACI-ben nem csak a szállítási hálózaton keresztüli rugalmas kapcsolódás biztosítására szolgálnak, hanem metainformációk átvitelére is (például biztonsági szabályzatok alkalmazására).
A Broadcom chipjeit korábban a Cisco használta a Nexus 3000 sorozatú kapcsolókban. A kifejezetten az ACI támogatására kiadott Nexus 9000 családban eredetileg egy hibrid modellt valósítottak meg, ami Merchant + nevet kapott. A switch egyszerre használta az új Broadcom Trident 2 chipet és a Cisco által kifejlesztett kiegészítő chipet, amely megvalósítja az ACI minden varázsát. Nyilvánvalóan ez lehetővé tette a termék megjelenésének felgyorsítását és a váltás árának a Trident 2-re épülő modellekhez közeli szintre csökkentését. Ez a megközelítés elegendő volt az ACI szállítások első két-három évében. Ez idő alatt a Cisco kifejlesztette és piacra dobta a következő generációs Nexus 9000-et saját chipjein, nagyobb teljesítménnyel és funkciókészlettel, de azonos árszinten. A gyári interakcióra vonatkozó külső előírások teljes mértékben megmaradnak. Ugyanakkor a belső töltés teljesen megváltozott: valami refaktorálás, de vasra.
Hogyan működik a Cisco ACI architektúra
A legegyszerűbb esetben az ACI a Klose hálózat, vagy ahogy szokták mondani, a Spine-Leaf topológiájára épül. A gerincszintű kapcsolók kettőtől (vagy egytől, ha nem törődünk a hibatűréssel) hatig lehetnek. Ennek megfelelően minél több van belőlük, annál nagyobb a hibatűrés (annál kisebb a sávszélesség és a megbízhatóság csökkenése egy gerinc balesete vagy karbantartása esetén) és az általános teljesítmény. Minden külső kapcsolat a levélszintű kapcsolókhoz megy: ezek a szerverek, és a külső hálózatokhoz L2-n vagy L3-on keresztül történő dokkolás, valamint az APIC vezérlők csatlakoztatása. Általánosságban elmondható, hogy az ACI-vel nem csak a konfiguráció, hanem a statisztikai adatok gyűjtése, a hibafigyelés és így tovább - minden a vezérlők interfészén keresztül történik, amelyekből három szabványos méretű implementáció van.
Soha nem kell a konzollal csatlakozni a kapcsolókhoz, még a hálózat indításához sem: a vezérlő maga észleli a kapcsolókat, és gyárat állít össze belőlük, beleértve az összes szervizprotokoll beállítását, ezért egyébként nagyon fontos, hogy szereléskor írja le a telepítendő berendezés sorozatszámát, hogy később ne kelljen találgatnia, melyik kapcsoló melyik rackben található. A hibaelhárításhoz szükség esetén SSH-n keresztül csatlakozhatunk a kapcsolókhoz: elég óvatosan reprodukálják a szokásos Cisco show parancsokat.
Belsőleg IP-szállítást használ a gyár, így nincs benne Spanning Tree és egyéb régmúlt borzalmak: minden link érintett, meghibásodás esetén a konvergencia nagyon gyors. A szövetben a forgalom VXLAN-alapú alagutakon keresztül történik. Pontosabban a Cisco maga iVXLAN-beágyazásnak nevezi, és abban különbözik a normál VXLAN-tól, hogy a hálózati fejléc lefoglalt mezői szolgáltatási információk továbbítására szolgálnak, elsősorban a forgalom EPG-csoporthoz való viszonyáról. Ez lehetővé teszi a csoportok közötti interakció szabályainak megvalósítását a berendezésben, a számok felhasználásával ugyanúgy, mint a címeket a szokásos hozzáférési listákban.
Az alagutak lehetővé teszik az L2 szegmensek és az L3 szegmensek (azaz VRF) nyújtását a belső IP átvitelen keresztül. Ebben az esetben az alapértelmezett átjáró elosztásra kerül. Ez azt jelenti, hogy minden kapcsoló felelős a szövetbe belépő forgalom irányításáért. A forgalomáramlás logikáját tekintve az ACI hasonló a VXLAN/EVPN szövethez.
Ha igen, mik a különbségek? Minden más!
Az első számú különbség, amellyel az ACI-vel találkozik, az, hogy a szerverek hogyan csatlakoznak a hálózathoz. A hagyományos hálózatokban mind a fizikai szerverek, mind a virtuális gépek bevonása a VLAN-okba megy, és minden más tőlük táncol: kapcsolat, biztonság, stb. Az ACI-ben egy olyan kialakítást használnak, amelyet a Cisco EPG-nek (End-point Group) hív, ahonnan nincs hova menekülni. Lehetséges-e egyenlőségjelet tenni a VLAN-hoz? Igen ám, de ebben az esetben van esély arra, hogy elveszítsd a legtöbbet, amit az ACI ad.
Az EPG-vel kapcsolatban minden hozzáférési szabály megfogalmazva van, az ACI-ben pedig alapból a „fehér lista” elve érvényesül, vagyis csak olyan forgalom engedélyezett, amelynek áthaladása kifejezetten engedélyezett. Vagyis létrehozhatjuk a "Web" és a "MySQL" EPG csoportokat, és definiálhatunk egy szabályt, amely csak a 3306-os porton engedélyezi a kommunikációt közöttük. Ez úgy működik, hogy nem kötődik hálózati címekhez, sőt ugyanazon az alhálózaton belül!
Vannak ügyfeleink, akik éppen ennek a funkciónak köszönhetően választották az ACI-t, mivel ez lehetővé teszi a szerverek közötti (virtuális vagy fizikai - mindegy) hozzáférés korlátozását anélkül, hogy az alhálózatok között húzná őket, vagyis anélkül, hogy megérintené a címzést. Igen, igen, tudjuk, hogy senki sem írja elő kézzel az IP-címeket az alkalmazások konfigurációjában, igaz?
Az ACI forgalmi szabályait szerződéseknek nevezzük. Egy ilyen szerződésben egy többrétegű alkalmazásban egy vagy több csoport vagy szint szolgáltatóvá (mondjuk adatbázis-szolgáltatássá), mások fogyasztóvá válnak. A szerződés egyszerűen átadhatja a forgalmat, vagy csinálhat valami bonyolultabbat is, például tűzfalra vagy kiegyenlítőre irányíthatja, és megváltoztathatja a QoS értékét is.
Hogyan kerülnek a szerverek ezekbe a csoportokba? Ha ezek fizikai szerverek vagy valami olyan meglévő hálózatban található, amelybe VLAN-trunkot hoztunk létre, akkor az EPG-ben való elhelyezésükhöz a switch portra és a rajta használt VLAN-ra kell mutatni. Amint láthatja, a VLAN-ok ott jelennek meg, ahol nem nélkülözheti őket.
Ha a szerverek virtuális gépek, akkor elég a csatlakoztatott virtualizációs környezetre hivatkozni, és akkor minden magától történik: létrejön egy portcsoport (VMWare szempontjából) a virtuális gép csatlakoztatásához, a szükséges VLAN-ok vagy VXLAN-ok. Ha hozzá van rendelve, akkor a szükséges kapcsolóportokon regisztrálják őket, stb. Tehát bár az ACI egy fizikai hálózat köré épül, a virtuális szerverek kapcsolatai sokkal egyszerűbbnek tűnnek, mint a fizikaiaké. Az ACI már rendelkezik beépített kapcsolattal a VMWare és MS Hyper-V rendszerekkel, valamint támogatja az OpenStack és a RedHat virtualizációt. Valamikor a konténerplatformok beépített támogatása is megjelent: Kubernetes, OpenShift, Cloud Foundry, miközben ez a házirendek alkalmazására és a felügyeletre egyaránt vonatkozik, vagyis a hálózati rendszergazda azonnal láthatja, hogy melyik állomáson melyik pod működik, mely csoportokba tartoznak.
Amellett, hogy egy adott portcsoportba tartoznak, a virtuális szerverek további tulajdonságokkal is rendelkeznek: név, attribútumok stb., amelyek kritériumként használhatók egy másik csoportba történő átvitelhez, például amikor egy virtuális gépet átneveznek, vagy egy további címke jelenik meg a azt. A Cisco ezt mikroszegmentációs csoportoknak nevezi, bár általában maga a tervezés, amely képes számos biztonsági szegmens létrehozására EPG-k formájában ugyanazon az alhálózaton, szintén meglehetősen mikroszegmentáció. Nos, az eladó jobban tudja.
Az EPG-k önmagukban pusztán logikai konstrukciók, nem kötődnek meghatározott kapcsolókhoz, szerverekhez stb., így velük és az ezekre épülő konstrukciókkal (alkalmazásokkal és bérlőkkel) olyan dolgokat is megtehetsz, amelyeket hétköznapi hálózatokban nehéz elvégezni, például klónozni. Ennek eredményeként tegyük fel, hogy nagyon könnyű klónozni egy éles környezetet, hogy olyan tesztkörnyezetet kapjunk, amely garantáltan megegyezik az éles környezettel. Megteheti manuálisan is, de jobb (és egyszerűbb) az API-n keresztül.
Általánosságban elmondható, hogy az ACI vezérlési logikája egyáltalán nem hasonlít ahhoz, amivel Ön általában találkozik
az ugyanattól a Ciscótól származó hagyományos hálózatokban: a szoftver interfész az elsődleges, a GUI vagy a CLI pedig másodlagos, mivel ugyanazon az API-n keresztül működnek. Ezért szinte mindenki, aki részt vesz az ACI-ben, egy idő után elkezd navigálni a menedzsmenthez használt objektummodellben, és automatizál valamit, hogy megfeleljen az igényeinek. Ezt a legegyszerűbben Pythonból lehet megtenni: erre vannak kényelmes kész eszközök.
Ígért gereblye
A fő probléma az, hogy az ACI-ben sok minden másképp történik. Ahhoz, hogy normálisan kezdjen vele dolgozni, újra kell képeznie. Ez különösen igaz a nagy ügyfelek hálózati üzemeltetési csapataira, ahol a mérnökök kérésre évek óta „írnak fel VLAN-t”. Az a tény, hogy a VLAN-ok már nem VLAN-ok, és nem kell kézzel VLAN-okat létrehozni ahhoz, hogy új hálózatokat helyezzenek el virtualizált gazdagépekbe, teljesen lerobbantja a tetőt a hagyományos hálózatépítőkről, és ragaszkodásra készteti őket az ismert megközelítésekhez. Megjegyzendő, hogy a Cisco megpróbálta kicsit édesíteni a pirulát, és egy „NXOS-szerű” CLI-t adott a vezérlőhöz, amivel a hagyományos kapcsolókhoz hasonló felületről lehet konfigurálni. De még mindig, ahhoz, hogy normálisan elkezdhesse használni az ACI-t, meg kell értenie, hogyan működik.
Ár tekintetében a nagy és közepes méretekben az ACI hálózatok valójában nem különböznek a Cisco berendezések hagyományos hálózataitól, mivel ugyanazokat a switcheket használják felépítésükhöz (a Nexus 9000 ACI és hagyományos módban is működhet, és mára a fő eszközzé vált. „munkaló” új adatközponti projektekhez). A két kapcsolóból álló adatközpontok esetében azonban természetesen érezhető a vezérlők jelenléte és a Spine-Leaf architektúra. Nemrég megjelent egy Mini ACI gyár, amelyben a három vezérlőből kettőt virtuális gépek váltanak fel. Ez csökkenti a költségkülönbséget, de továbbra is megmarad. Az ügyfél számára tehát a választást az határozza meg, hogy mennyire érdeklik a biztonsági funkciók, a virtualizációval való integráció, az egyetlen vezérlési pont stb.
Forrás: will.com