Az utolsó néhány évben a Cisco aktívan népszerűsíti az új adatátviteli hálózatépítési architektúrát a data center-ekben — Application Centric Infrastructure (más néven ACI). Néhányan már találkoztak vele. Vannak akik már meg is valósították a saját vállalataikban, beleértve Oroszországot is. Az IT-szakemberek és IT-vezetők többsége számára az ACI vagy egy érthetetlen mozaikszó, vagy csupán egy jövőről való elmélkedés.
Ebben a cikkben megpróbáljuk közelebb hozni ezt a jövőt. Beszámolunk az ACI alapvető architektúrájáról, valamint illusztrálni fogjuk a gyakorlati alkalmazását. Továbbá, a közeljövőben vizuális bemutatót szervezünk az ACI működéséről, amelyre bárki, aki érdeklődik, jelentkezhet.
A legújabb hálózatépítési architektúráról 2019 májusában Szentpéterváron lehet majd többet megtudni. Minden részlet – itt: . Jelentkezzenek!
Háttér
A hagyományos és legnépszerűbb hálózatépítési modell a háromszintű hierarchikus modell: mag -> elosztás (aggregáció) -> hozzáférés. Évek óta ez a modell volt a mérce, amelyhez a gyártók különböző, funkcióban megfelelő hálózati eszközöket készítettek.
Korábban, amikor az informatikai technológiák egyfajta szükséges (és, őszintén szólva, nem mindig kívánt) kiegészítése voltak az üzletnek, ez a modell kényelmes, viszonylag statikus és megbízható volt. Azonban most, amikor az IT az üzlet fejlődésének egyik hajtóereje, sok esetben pedig magának az üzletnek a része lett, a modell statikussága súlyos problémákat okoz.
A modern üzlet különféle bonyolult követelmények nagy mennyiségét generálja a hálózati infrastruktúrával szemben. E követelmények teljesítésének időkerete közvetlenül befolyásolja az üzlet sikerességét. Ezekben a körülmények között a késlekedés elfogadhatatlan, a klasszikus hálózatépítési modell pedig gyakran nem teszi lehetővé az üzleti igények időben történő kielégítését.
Például egy új, összetett üzleti alkalmazás megjelenése nagy mennyiségű, azonos típusú rutinfeladat elvégzését követeli meg a hálózati adminisztrátoroktól különböző hálózati eszközökön, különböző szinteken. Ezenkívül ez sok időbe telik, és növeli annak kockázatát, hogy hibát követnek el, ami súlyos IT-szolgáltatási leálláshoz és ennek következményeként pénzügyi károkhoz vezethet.
A probléma gyökere nem is annyira az időkeretekben vagy a követelmények összetettségében rejlik. A lényeg az, hogy ezeket a követelményeket »le kell fordítani« az üzleti alkalmazások nyelvéről a hálózati infrastruktúra nyelvére. Mint tudjuk, bármilyen fordítás mindig a jelentés részleges elvesztésével jár. Amikor az alkalmazás tulajdonosa az alkalmazása működési logikájáról beszél, a hálózati adminisztrátor VLAN-csoportokat és Access listákat ért különböző eszközökön, amelyeket karban kell tartani, aktualizálni és dokumentálni.
A felhalmozott tapasztalat és a folyamatos kapcsolattartás az ügyfelekkel lehetővé tette a Cisco számára, hogy új adatátviteli hálózati építési elveket tervezzen és valósítson meg, amelyek megfelelnek a modern tendenciáknak, és első sorban az üzleti alkalmazások logikáján alapulnak. Innen ered a név — Application Centric Infrastructure.
Az ACI architektúra.
Az ACI architektúráját leghelyesebb logikai oldalról vizsgálni. Az alapjául szolgáló, automatizált politikák modelljére épít, amelynek objektumait a legmagasabb szinten a következő komponensekre lehet felosztani:
- Nexus kapcsolók alapú hálózat.
- APIC vezérlő klaszter;
- Alkalmazásprofilt;

Vizsgáljuk meg alaposabban minden szintet – közben a egyszerűtől a bonyolult felé haladunk.
Nexus kapcsolók alapú hálózat
Az ACI gyárban lévő hálózat hasonlít a hagyományos hierarchikus modellre, de sokkal egyszerűbben épül fel. A hálózat szervezéséhez Leaf-Spine modellt használnak, amely elfogadott megközelítéssé vált az új generációs hálózatok megvalósítására. Ez a modell két szintből áll: Spine és Leaf.

A Spine szint kizárólag a teljesítményért felelős. A Spine kapcsolók összesített teljesítménye megegyezik az egész gyár teljesítményével, ezért ezen a szinten 40G vagy annál nagyobb porttal rendelkező kapcsolókat kell használni.
A gerinchálózatok minden következő szintű kapcsolójához csatlakoznak: a Leaf kapcsolókhoz, amelyekhez a végső hosztok csatlakoznak. A Leaf kapcsolók fő szerepe a portkapacitás.
Így a skálázás kérdései könnyen megoldhatók: ha meg kell növelnünk a gyár áteresztőképességét, Spine kapcsolókat adunk hozzá, ha pedig növelni kell a portkapacitást, akkor Leaf kapcsolókat.
Mindkét szinthez a Cisco Nexus 9000 sorozatú kapcsolókat használják, amelyek a Cisco fő eszközei az adatközponti hálózatok kiépítésében, függetlenül azok architektúrájától. A Spine szinthez Nexus 9300 vagy Nexus 9500 kapcsolók, a Leaf szinthez pedig csak Nexus 9300 kapcsolók tartoznak.
Az ACI gyárban használt Nexus kapcsolók modellje az alábbi ábrán látható.

APIC (Application Policy Infrastructure Controller) vezérlő klaszterek
Az APIC vezérlők speciális fizikai szerverek, azonban kis bevezetéseknél egyetlen fizikai APIC vezérlő és két virtuális használata is megengedett.
Az APIC vezérlők irányítási és megfigyelési funkciókat látnak el. Fontos megemlíteni, hogy a vezérlők soha nem vesznek részt az adatok átvitelében, tehát ha az összes vezérlő a klaszterben meghibásodik, az nem befolyásolja a hálózat stabil működését. Továbbá meg kell jegyezni, hogy az APIC-ok segítségével az adminisztrátor teljes mértékben kezeli az összes fizikai és logikai erőforrást a gyárban, és bármilyen módosításhoz nem szükséges újra csatlakozni a megfelelő eszközhöz, mivel az ACI egy egységes kezelési pontot használ.

Most térjünk át az ACI egyik fő komponensére – az alkalmazásprofilokra.
Alkalmazásprofil (Application Network Profile) – ez az ACI logikai alapja. Az alkalmazásprofilok határozzák meg a politikákat a különböző hálózati szegmensek közötti interakcióra, és magukat a hálózati szegmenseket írják le. Az ANP lehetővé teszi a fizikai szinttől való eltérést, és lényegében bemutatja, hogyan kell megszervezni az interakciót a különböző hálózati szegmensek között az alkalmazás szempontjából.
Az alkalmazásprofilok kapcsolatcsoportokból (End-point groups – EPG) állnak. A kapcsolatcsoport egy logikai csoportja a hosztoknak (virtuális gépek, fizikai szerverek, konténerek stb.), amelyek egy biztonsági szegmensben találhatók (nem a hálózati, hanem a biztonsági értelemben). Azok a végső hosztok, amelyek egy EPG-hez tartoznak, sok kritérium alapján meghatározhatók. Általában a következők használatosak:
- Fizikai port
- Logikai port (portcsoport a virtuális kapcsolón)
- VLAN ID vagy VXLAN
- IP-cím vagy IP-alhálózat
- Szerverattribútumok (név, elhelyezkedés, operációs rendszer verziója stb.)
A különböző EPG-k közötti interakciókhoz van egy entitás, amelyet szerződéseknek neveznek. A szerződés meghatározza a különböző EPG-k közötti kapcsolatokat. Más szóval, a szerződés meghatározza, hogy egy EPG milyen szolgáltatást nyújt a másik EPG számára. Például létrehozunk egy szerződést, amely lehetővé teszi a forgalom áthaladását HTTPS protokollon. Ezután ezt a szerződést összekapcsoljuk például az EPG Web (webszerver csoport) és az EPG App (alkalmazásszerver csoport) között, így ezek a két végponti csoport képes lesz HTTPS protokollon forgalmat cserélni.
Az alábbi ábrán látható az EPG-k közötti kapcsolatok beállításának példája a szerződéseken keresztül egy ANP keretein belül.

ACI-fabric keretein belül bármennyi alkalmazásprofil létrehozható. Ezenkívül a szerződések nem kötődnek konkrét alkalmazásprofilhoz, azokat (és kell) különböző ANP-k EPG-jének összekapcsolásához használni.
Lényegében minden alkalmazás, amelynek valamilyen formában szüksége van a hálózatra, saját profiljával van leírva. Például a fenti ábrán egy szabványos háromszintes alkalmazás architektúrája látható, amely N darab külső hozzáférési szerverből (Web), alkalmazásszerverből (App) és DB (adatbázis) szerverből áll, valamint leírja a közöttük lévő interakciós szabályokat. A hagyományos hálózati infrastruktúrában ez egy szabályok összessége lett volna, amelyeket a különböző eszközökön írtak le az infrastruktúrában. Az ACI architektúrában ezeket a szabályokat egy alkalmazásprofil keretein belül írjuk le. Az ACI az alkalmazásprofilok segítségével jelentősen egyszerűsíti a sokféle beállítás létrehozását a különböző eszközökön, ezeket egyetlen profilba csoportosítva.
Az alábbi ábrán egy életszerűbb példát láthatunk. A Microsoft Exchange alkalmazásprofil, amely több EPG-ből és szerződésből áll.

A központi kezelés, automatizálás és monitorozás az ACI egyik kulcsfontosságú előnye. Az ACI gyár megszabadítja az adminisztrátorokat a routin munkától, amely a különböző switcheken, routereken és tűzfalakon nagy mennyiségű szabály létrehozásával jár (a klasszikus manuális beállítási módszer továbbra is engedélyezett és használható). Az alkalmazásprofilok és más ACI objektumok beállításai automatikusan érvényesülnek az ACI gyárban. Még ha a fizikai szerverek más switchek portjaiba is kerülnek, nem szükséges megduplázni a régi switchek beállításait az újokon, és törölni a felesleges szabályokat. A hoszt EPG-hez való tartozása alapján a gyár automatikusan elvégzi ezeket a beállításokat, és automatikusan tisztítja a nem használt szabályokat.
Az ACI integrált biztonsági politikái fehérlistás elv szerint valósulnak meg, vagyis ami kifejezetten nincs engedélyezve, az alapértelmezetten tilos. A hálózati berendezések konfigurációinak automatikus frissítésével (a „megtalált” nem használt szabályok és engedélyek eltávolítása) ez a megközelítés jelentősen növeli a hálózat biztonsági szintjét és szűkíti a potenciális támadási felületet.
Az ACI lehetővé teszi a hálózati interakciót nemcsak virtuális gépek és konténerek, hanem fizikai szerverek, hardveres Sűrűsítő és harmadik fél hálózati berendezéseinek között is, ami az ACI-t jelenleg egyedülálló megoldássá teszi.
A Cisco új megközelítése az adatátviteli hálózat létrehozására alkalmazáslogika alapján nemcsak automatizálást, biztonságot és központosított kezelést jelent. Ez egy modern, vízszintesen skálázható hálózat is, amely megfelel a korszerű üzleti igényeknek.
Az ACI alapú hálózati infrastruktúra megvalósítása lehetővé teszi, hogy a vállalat minden részlege egy nyelven beszéljen. Az adminisztrátor csak az alkalmazás működési logikája szerint jár el, amelyben a szükséges szabályok és kapcsolatok le vannak írva. Az alkalmazás működési logikája szerint vezetnek az alkalmazás tulajdonosai és fejlesztői, a biztonsági szolgáltatás, a közgazdászok és az üzlet tulajdonosai is.
Ezért a Cisco gyakorlati úton valósítja meg az új generációs adatközponti hálózat koncepcióját. Szeretné ezt saját szemével látni? Jöjjön el a bemutatóra Alkalmazáscentrikus Infrastruktúra Szentpéterváron, és dolgozzon a jövő adatközponti hálózatával már most.
Az eseményre regisztrálhat .
Forrás: habr.com
