Értékelje a kapcsolódásokat a séma középső részén. Lent visszatérünk rájuk.
Egy idő után szembesülhet azzal, hogy a nagy, bonyolult L2 alapú hálózatok elkerülhetetlenül betegek. Elsősorban a BUM-forgalom kezelésével és az STP protokoll működésével kapcsolatos problémák vannak. Másodsorban az általában elavult architektúra miatt. Ez kellemetlen problémákhoz vezet, mint a leállások és a kezelhetőség nehézségei.
Két párhuzamos projektünk volt, ahol az ügyfelek reálisan értékelték az összes előnyét és hátrányát a lehetőségeknek, és két különböző overlay megoldást választottak, amelyeket mi valósítottunk meg.
Lehetőségünk volt pontosan a megvalósítást összehasonlítani. Nem a működtetést, erről két-három év múlva érdemes beszélni.
Tehát mi az a hálózati gyár overlay hálózatokkal és SDN-nel?
Mit tegyünk a klasszikus hálózati architektúra fájó problémáival?
Minden évben új technológiák és ötletek jelennek meg. A gyakorlatban a hálózatok átalakításának sürgős szükségessége nem merült fel elég sokáig, mert mindent kézzel, a régi, jól bevált módszerekkel is lehet csinálni. Hát és mi van, ha a XXI. században járunk? Végül is az adminisztrátornak dolgoznia kell, nem pedig a szobájában ülnie.
Aztán elindult a nagy adatközpontok építkezésének láza. Ekkor vált világossá, hogy a klasszikus architektúra fejlődésének határvonalát nemcsak a működőképesség, a hibakerülés és a skálázhatóság szempontjából érték el. Ezeknek a problémáknak az egyik megoldási alternatívája az volt, hogy overlay hálózatokat építünk a routolható gerinchálózat fölé.
Ezen kívül, a hálózatok méretének növekedésével égetően felmerült a problémája az ilyen gyárak kezelésének, ami miatt hálózatkezelő megoldások kezdtek megjelenni, amelyek lehetővé tették az egész hálózati infrastruktúra egy teljes egészében történő kezelését. Amikor a hálózatot egyetlen pontból kezelik, a többi IT-infrastruktúra komponensének egyszerűbb a kölcsönhatás vele, és az ilyen kölcsönhatás folyamatainak automatizálása is könnyebb.
Gyakorlatilag minden nagyobb gyártó, aki nemcsak hálózati berendezéseket, hanem virtualizációt is gyárt, rendelkezik az ilyen megoldások változataival a portfóliójában.
Csak annyit kell kideríteni, hogy milyen megoldások felelnek meg a különböző igényeknek. Például a különösen nagy cégek, amelyek jó fejlesztőcsapattal és üzemeltetéssel rendelkeznek, nem mindig elégedettek a gyártók dobozos megoldásaival, és saját SD (software defined) megoldások fejlesztéséhez folyamodnak. Ilyenek azok a felhőszolgáltatók, akik folyamatosan bővítik az ügyfeleiknek kínált szolgáltatások palettáját, és a dobozos megoldások egyszerűen nem képesek lépést tartani az igényeikkel.
Középvállalatok számára a gyártók dobozos megoldásaiban kínált funkcionalitás az esetek 99 százalékában elegendő.
Mi az az overlay hálózat?
Miben rejlik az overlay hálózatok lényege? Alapvetően egy klasszikus útválasztott hálózatot veszünk, és egy újabb hálózatot építünk rá, hogy több funkciót kapjunk. Leggyakrabban a terhelés hatékony elosztásáról, a berendezések és a kommunikációs vonalak kapacitásának jelentős növeléséről, megbízhatóság növeléséről és számos további biztonsági előnyről (szegmentálás révén) van szó. Az SDN megoldások ezen kívül lehetőséget adnak a rendkívül kényelmes és rugalmas adminisztrációra, valamint a hálózat átláthatóbbá tételére a felhasználók számára.
Ha a helyi hálózatokat a 2010-es években találták volna fel, valószínűleg nem így néznének ki, mint amit örököltünk a 1970-es évek katonai megoldásaiból.
A rétegzett hálózatokkal rendelkező gyárak építési technológiáit tekintve ma számos gyártó és internetes projekt valósítása létezik (RFC-k, mint például EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve stb.). Vannak szabványok, de ezeknek a szabványoknak a gyártók általi megvalósítása eltérhet, ezért az ilyen gyárak létrehozásakor a gyártó-specifikus megoldásoktól való teljes elfordulás egyelőre csak elméletben lehetséges.
Az SD megoldások még zavarosabbak, minden gyártónak megvan a saját víziója. Vannak teljesen nyitott megoldások, amelyeket elméletileg saját magunk is módosíthatunk, és vannak teljesen zárt megoldások.
A Cisco az adatközpontok számára kínálja SDN megoldását - ACI. Természetesen ez egy 100%-ban gyártó-specifikus megoldás a hálózati berendezések kiválasztásában, de teljes mértékben integrálódik a virtualizációs, konténerizációs, biztonsági, orchestrációs, terheléselosztó rendszerekkel és másokkal. De lényegében ez még mindig egy fekete doboz, amely nem ad teljes hozzáférést az összes belső folyamathoz. Nem minden ügyfél fogadja el ezt a megoldást, mivel teljes mértékben függ a megoldás kódjának minőségétől és annak megvalósításától, de másrészről a gyártó rendelkezik a világ egyik legjobb technikai támogatásával, és van egy dedikált csapata, amely kizárólag ezzel a megoldással foglalkozik. Az első projekt megoldásaként a Cisco ACI-t választották.
A második projekthez a Juniper megoldásait választották. A gyártónak szintén van SDN megoldása az adatközpontok számára, de az ügyfél úgy döntött, hogy nem vezeti be az SDN-t. A hálózatépítés technológiájaként az EVPN VXLAN gyárat választották központosított vezérlők használata nélkül.
Mire van szükség
A gyár létrehozása lehetővé teszi egy könnyen skálázható, hibátűrő, megbízható hálózat felépítését. Az architektúra (leaf-spine) figyelembe veszi a sajátosságokat adatközpontok (a forgalom átjárási útvonalát, késleltetés minimalizálását és a hálózatban jelentkező szűk keresztmetszeteket). Az SD megoldások az adatközpontokban nagyon kényelmes, gyors és rugalmas kezelést tesznek lehetővé egy ilyen gyár számára, integrálva azt az adatközpont ökoszisztémájába.
Mindkét ügyfélnek szüksége volt tartalék adatközpontok építésére a hibátűrés biztosítása érdekében, emellett a forgalmat az adatközpontok között titkosítani kellett.
Az első ügyfél már az adatgyár nélküli megoldásokat is lehetséges szabványként fontolgatta a hálózataiban, de a tesztelés során kompatibilitási problémák merültek fel az STP között, több gyártó berendezéseivel. Leállások történt, amelyek szolgáltatáskiesést okoztak. Az ügyfél számára ez kritikus volt.
A Cisco már a megrendelő vállalatok sztenderdje volt, alaposan megvizsgálták az ACI-t és más lehetőségeket, és úgy döntöttek, hogy ezt a megoldást választják. Az egygombos automatizált vezérlés tetszett nekik. Gyorsabban beállíthatók a szolgáltatások, gyorsabban kezelhetők. A forgalom titkosítását MACSec használatával oldották meg az IPN és SPINE switch-ek között. Így sikerült elkerülni a kriptoátjáró szűk keresztmetszetét, megtakarítani a költségeken, és maximálisan kihasználni a sávszélességet.
A második megrendelő a Juniper vezérlő nélküli megoldását választotta, mivel a meglévő adatközpontjukban már volt egy kisebb telepítés, amely az EVPN VXLAN gyárat valósította meg. Azonban ott a megoldás nem volt hibatűrő (csak egy switchet használtak). Úgy döntöttek, hogy bővítik a fő adatközpont infrastruktúráját, és egy tartalék adatközpontot építenek. A meglévő EVPN-t nem használták ki teljes mértékben: a VXLAN encapsulációt gyakorlatilag nem alkalmazták, mivel minden hoszt egy switchhez volt csatlakoztatva, és minden MAC-cím és /32 hosztcím helyi volt, a forgalom átjárója ugyanez a switch volt, nem volt más eszköz, ahová VXLAN alagutakat kellett volna építeni. A forgalom titkosítását IPSEC technológia alkalmazásával oldották meg a tűzfalak között (az MSE teljesítménye elegendő volt).
Szintén megvizsgálták az ACI-t, de úgy döntöttek, hogy a gyártói kizárás miatt túl sok hardvert kellene vásárolniuk, beleértve a nemrégiben beszerzett új eszközök cseréjét is, ami gazdaságilag nem lenne értelmes. Igen, a Cisco gyár integrálódik mindennel, de magán a gyáron belül csak a saját eszközei használhatók.
Másrészt, ahogy korábban említették, az EVPN VXLAN gyárat nem lehet csak úgy keverni bármelyik szomszédos gyártóval, mivel a protokoll megvalósítása eltérő. Olyan, mintha a Cisco-t és a Huawei-t kereszteznénk egy hálózaton belül — látszólag közösek a szabványok, de azért kell vele dolgozni. Mivel ez egy bank, és a kompatibilitás tesztjei nagyon hosszú ideig tartanának, úgy döntöttek, hogy jobban teszik, ha most ugyanattól a gyártótól vásárolnak, és nem kalandoznak túlzottan a funkcionalitás körüli bonyodalmakba.
A migrációs terv
Két adatközpont ACI alapú:
A központi adatközpontok közötti interakció szervezése. A Multi-Pod megoldás került kiválasztásra, ahol minden adatközpont egy pod. Figyelembe vették a skálázhatósági követelményeket a kapcsolók számát és a podok közötti késleltetéseket illetően (RTT kevesebb mint 50 ms). Döntés született arról, hogy nem építenek Multi-Site megoldást a kezelhetőség érdekében (a Multi-Pod megoldáshoz egyetlen kezelőfelület tartozik, míg a Multi-Site-hoz két felületre lenne szükség, vagy Multi-Site Orchestratorra), és mivel nem volt szükség geográfiai helyszínek biztonsági másolatára.
A Legacy hálózatból történő szolgáltatásmigráció szempontjából a legátláthatóbb megoldás a megfelelő VLAN-ok fokozatos átvitele lett, amelyek bizonyos szolgáltatásokhoz kapcsolódnak.
A migráció során minden VLAN-hoz létrehoztak egy megfelelő EPG-t (End-point group) a gyárban. Először a hálózat L2 szinten húzódott el a régi hálózat és a gyár között, majd miután az összes gazdagépet migrálták, a kapu a gyárra került, és az EPG és a meglévő hálózat közötti interakció L3OUT-on keresztül valósult meg, miközben a L3OUT és az EPG közötti kapcsolatokat szerződések segítségével írták le. Az ábra körülbelül így néz ki:
A Cisco ACI többségi politikáinak körvonalai a lenti ábrán láthatók. Az összes konfiguráció politikákra épül, amelyek más politikákba ágyazódnak, és így tovább. Kezdetben nagyon nehéz rájönni, de fokozatosan, ahogy a gyakorlat is mutatja, a hálózati adminisztrátorok körülbelül egy hónap alatt hozzászoknak ehhez a struktúrához, és később mindössze annyira jön el a megértés, hogy mennyire kényelmes.
Összehasonlítás
A Cisco ACI megoldásainál több berendezést kell vásárolni (külön kapcsolók az Inter-Pod interakcióhoz és APIC kontrollerek), ami miatt drágább lett. A Juniper megoldás nem igényelt kontrollereket és kiegészítő berendezéseket; részben felhasználható volt a már meglévő ügyfélberendezések.
Itt van a két adatközpont architektúrája az EVPN VXLAN gyár számára a második projekthez:
Az ACI-ban egy kész megoldást kapsz — nem kell vájkálni, nem kell optimalizálni. Az ügyfél első találkozásánál a gyárral nem szükségesek fejlesztők vagy a kód és az automatizálás támogatásával foglalkozó emberek. Elég a használat, sok beállítást a varázsló segítségével lehet elvégezni, ami nem mindig előny, különösen azok számára, akik hozzászoktak a parancssorhoz. Mindenesetre időre van szükség, hogy átálljunk az új sínekre, a beállítások politikák általi kezelésére és a sok egymásba ágyazott politika kezelésére. Nagyon kívánatos, hogy emellett világos struktúrája legyen a politikák és objektumok nevének. Ha bármilyen probléma merül fel a vezérlő logikájában, azt csak a technikai támogatás tudja megoldani.
Az EVPN — konzol. Szenvedj vagy örülj. Ismerős felület a régi gárdának. Igen, van egy szabványos konfiguráció és útmutatók. Türelmesnek kell lenned. Különböző konstrukciók vannak, minden világos és részletes.
Természetesen mindkét esetben jobb, ha a migráció során először a legkevésbé kritikus szolgáltatásokat migrálod, például a tesztelési környezeteket, és csak ezután, miután minden hibát kijavítottál, folytasd a termelést. És ne állítsd be péntek este. Ne higgy a gyártónak, hogy minden rendben lesz, mindig jobb biztosítani magad.
Az ACI-nál többet fizetsz, bár a Cisco jelenleg aktívan népszerűsíti ezt a megoldást, és gyakran jó kedvezményeket kínál rá, de spórolsz a karbantartáson — a támogatáson. Az EVPN gyár automatizálása és kezelése vezérlő nélkül költségeket és rendszeres kiadásokat igényel — monitorozás, automatizálás, új szolgáltatások bevezetése. Közben az ACI kezdeti elindítása 30–40 százalékkal tovább tart. Ez azért történik, mert lassabban készül el az összes szükséges profil és politika, amelyet később használni fognak. De ahogy nő a hálózat, a szükséges konfigurációk száma csökken. Már korábban elkészített politikákat, profilokat és objektumokat használsz. Rugalmasan beállíthatod a szegmentációt és a biztonságot, központosítva kezelheted a szerződéseket, amelyek a különböző interakciók engedélyezéséért felelnek az EPG-k között — a munka mennyisége drámaian csökken.
Az EVPN-ben minden eszközt konfigurálni kell a gyárban, a hiba valószínűsége nagyobb.
Ha az ACI lassabban valósul meg, az EVPN majdnem kétszer annyi időt vesz igénybe a hibakeresésre. Cisco esetében mindig lehet kérdezni a támogató mérnököt a hálózatról (mert az megoldásként van lefedve), míg a Juniper Networks-nél csak a hardvert vásárolja meg, és csak az van lefedve. Elmentek a csomagok az eszközről? Rendben, a továbbiak már a te problémád. De fel lehet tenni kérdéseket a megoldás vagy a hálózati design kiválasztásával kapcsolatban – és akkor ajánlják, hogy vásárolj profi szolgáltatást, extra költség ellenében.
Az ACI támogatása nagyon jó, mert külön csapat foglalkozik ezzel: egy külön csapat dolgozik csak erre. Vannak oroszul beszélő szakemberek is. A kézikönyv részletes, a megoldások előre meghatározottak. Figyelik és tanácsolnak. Gyorsan validálják a dizájnt, ami gyakran fontos. A Juniper Networks is ugyanazt csinálja, de sokkal lassabban (nálunk így volt, a hírek szerint most már jobb), ami arra kényszerít, hogy önállóan végezz mindent, ahol a megoldásmérnök javasolhatott volna.
A Cisco ACI támogatja a virtualizációs és konténerizációs rendszerekkel (VMware, Kubernetes, Hyper-V) való integrációt és a központosított kezelést. Van hálózati szolgáltatások és biztonsági szolgáltatások is — terheléselosztás, tűzfalak, WAF, IPS és egyebek… Jó mikroszegmensek dobozból. A második megoldás esetében a hálózati szolgáltatásokkal való integráció bonyolultabb, és jobb előre fórumokat nézni, akikkel ezt csinálták.
Result
Minden konkrét esethez meg kell választani a megoldást, nemcsak a hardver költsége alapján, hanem figyelembe kell venni a további üzemeltetési költségeket és az alapvető problémákat, amelyekkel az ügyfél jelenleg szembesül, valamint az IT-infrastruktúra fejlesztési terveit.
Az ACI a kiegészítő hardver miatt drágább lett, de egy kész megoldás, ami nem igényel további fejlesztést, míg a második megoldás bonyolultabb és költségesebb az üzemeltetés szempontjából, de olcsóbb.
Ha szeretnéd megbeszélni, mennyibe kerülhet a hálózati gyár megvalósítása különböző gyártóknál, és milyen architektúrára van szükség, találkozhatunk és beszélgethetünk. A vázlatos architektúra vázlata (amivel a költségeket is lehet kalkulálni) ingyenes, a részletes kidolgozás természetesen már díjköteles.
Vladimir Klepche, vállalati hálózatok.
Forrás: habr.com
