Cisco ACI
Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új.
Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot.
Mint azt egy korábbi bejegyzésemben írtam, alapvetően két megközelítés létezik egymással párhuzamosan - de akár egymást kiegészítve is - a DC hálózatok világában.
A szoftver alapú és hardver alapú SDN megoldás.
Cisco ACI mindenképp a legutóbbi kategóriába tartozik, ugyanis a DC fabric kialakítása során meghatározott hardver elemekre van szükség, ahhoz, hogy SD-DataCenter-t tudjunk felépíteni.
Cisco ACI a nexus 9000 sorozatba tartozó hardverek APIC-kel felépített fabric hálózata, amely a DC-ben lévő host-ok számára biztosít elosztott Layer2 és Layer3 szolgáltatásokat.
ACI topológia kötött, abból megfontolásból, hogy egy adott speciális terület hálózati igényeit hivatott kiszolgálni, ezek pedig a DC alkalmazások...
Az ACI - és egyébként a hardver alapú hálózat-virtualizációs megoldások - alkalmazástól , operációs rendszertől, virtualizációtól vagy bare metal megoldástól függetlenül azonos kommunikációs megoldást kínál a DC-ben lévő host-ok számára...
SPINE - LEAF topológia
 |
| forrás |
Miben különbözök SPINE a Collapsed CORE rétegtől, és LEAF az ACCESS-től?
Fizikai funkcióját tekintve semmi, mert hát LEAF adja a port kapacitást a host-ok számára, míg a SPINE switch-ek száma, típusa és LEAF-el való összekötések számossága határozza meg a DC átviteli kapacitását.
Viszont más forgalom karakterisztikára van optimalizálva, mint egy Collapsed CORE - ACCESS, ahol a hangsúly az észak-déli irányú átvitelen van, ezzel szemben a SPINE-LEAF a kelet-nyugati irányú forgalmi karakterisztikára van optimalizálva.
Fizikai rétegnél magasabb funkcionalitásban viszont sokkal szembetűnőbb az eltérés, ugyanis míg a hagyományos L2 DC felépítésben egy ACCESS switch-nek alig van több feladata a VLAN-ok terminálásánál, addig a LEAF switch-ek esetében már komoly routing képességekre is szükség lehet, az overlay topológia kialakítása miatt.
Míg CORE switch-ek esetében L3 gateway funkció is fontos szerep, ebben a topológiában a ezt a border-nek kinevezett LEAF switch hivatott szolgáltatni.
A SPINE switch átviteltechnikai szempontból, egy köztes réteg, ami a backplane kapacitást és a redundanciát biztosítja a LEAF réteg számára.
Ebben kulcs szerepe az ECMP-nek és az IP fabric-nak van, ugyanis az ACI fabric nem más mint egy olyan route-olt IP hálózat, ami támogatja az ECMP-t.
Bekötést tekintve LEAF switch-ek SPINE-okhoz csatlakoznak, de minden egyes bekötés egy route-olt interface-et jelent, ami felett a Layer2 összeköttetések VXLAN overlay-en valósulnak meg. Tehát a fizikai és logikai topológiának ebben a hálózat-virtualizációs környezetben kitüntetett szerepe van, ellentétben mondjuk egy NSX alapú megoldással, ahol csak a host-ok közti IP kapcsolat a fontos (természetesen validated design-okban spine-leaf szerepel ott is a javasolt IP fabric-ként).
ACI szolgáltatások
- Mikroszegmentáció
- Anycast gateway funkcionalitás, diszributed routing
- Multi-site DC
- Hálózat automatizáció, API interface
 |
| forrás |
Mikroszegmentáció
 |
| forrás |
Nagyon fontos dolog szerintem, hogy a mikroszegmentáció a hálózati rétegben valósul meg elsősorban, és nem a hypervisor szintjén.
Persze lehetőség van Cisco AVS (Application Virtual Switch) telepítésére,viszont jó kérdés, hogy egy licencelt vmware környezetben hypervisor hiba esetén fordulhatunk-e a vmware-hez? A kérdésre a válasz: newman.cloud.
Mindenesetre nem tekinthető stateful packet filternek sem a megoldás (TCP esetén még talán), mert gyakorlatban ezek szegmentációk ACL-ként valósulnak meg. Természetesen ACI-ból konfigurálni, még mindig egyszerűbb a contract-okat az EPG-k között, mint 20,30 switchen ACL-t konfigurálni. Továbbá az EPG-k közti contract-ok vonatkoznak bare metal-ra, hyperV-re kvm-re és vmware környezetekre egyaránt, így egységes szegmentációt lehet kialakítani alkalmazásnak megfelelően, függetlenül a futtató környezettől...
 |
| forrás |
Anycast gateway, disztributed routing
Végre nincsenek kőbe vésett VLAN-ok, és IP-k, hiszen minden L3 funkcionalitás aminek egy host-nak szüksége van rendelkezésre áll az egész fabric-ban, helytől függetlenül.
Hogyan képzeljük az anycast gateway-t a DC-ben?
Nos ehhez alaposabban bele kellene menni VXLAN alapú overlay hálózatok, illetve egyéb hasonló overlay protokollok működésébe, úgyhogy maradjunk egyenlőre abban, hogy very important magic... de később majd készítek róla egy külön bejegyzést.
Multi-site DC
ACI-ban most már sok lehetőség van arra, hogy több telephelyen lévő adatközpontunkat egy integrált DC-ként kezeljük, legalábbis a hálózat szempontjából.Ahogy szépen lassan feljődött az ACI erre egyre több lehetőséget kaptunk, az első ilyen stretched ACI fabric (v1.1), ami telephelyek közti közvetlen fizikai kapcsolaton keresztül biztosítja az ACI cluster kialakítását. Ennek egyik nagyobb hátránya, hogy fabric kialakítása egy network szegmensben történt meg, a DC-k logikailag egy zónába tartoztak.
Az ACI 2.0-tól elérhetővé vált a multi-pod kialakítás, ami MP-BGP-EVPN segítségével biztosította különböző zónák egységes ACI menedzsmentjét.
3.0-tól érhető el a Multi-site kivitel, ami egy extra kontroll réteg segítségével biztosítja a különböző ACI pod-ok feletti egységes vezérlést.
 |
| forrás |
Hálózat automatizáció, API interface
Szerintem a hálózat-virtualizációs technológiák terén az egyik legfontosabb elem, az automatizálás lehetősége, ami nem csak a plug&play rendszerbe illesztést jelenti, hanem a logikai struktúrák kialakítása is sokkal gyorsabban történhet, amennyiben hajlandóak vagyunk REST API-on keresztül külső akár általunk fejlesztett szoftver segítségével létrehozni új hálózati beállításokat.Summa, summárum
Mindent összevetve a Cisco ACI egy lehetőség arra az esetre, ha kész SDN megoldást szeretnénk bevezetni a hálózat rétegbe, de ne feledjük el, hogy nem az egyetlen megoldás.Magyarországon szerintem ACI-hoz hasonló technológiák létjogosultsága leginkább az automatizáció és hálózat vizibilitás kapcsán van. ACI-ról fogok még bejegyzést írni, ezt most csak egy kis ízelítőnek szánom.
ACI mellett természetesen létezik más hardver fabric alapú megoldás adatközponti hálózat-virtualizációra, olyan is melyek MP-BGP-EVPN VXLAN alapon működnek, ezekről majd más bejegyzés során szeretnék írni, és persze ne feleljünk olyan kiváló szoftver alapú megoldásokat sem mint a vmware NSX-T.
