Értékelje az összefüggéseket a diagram középső részén! Az alábbiakban még visszatérünk rájuk
Egy ponton azt tapasztalhatja, hogy a nagy, összetett L2-alapú hálózatok végzetes betegek. Mindenekelőtt a BUM forgalom feldolgozásával és az STP protokoll működésével kapcsolatos problémák. Másodszor, az architektúra általában elavult. Ez kellemetlen problémákat okoz leállások és kényelmetlen kezelés formájában.
Két párhuzamos projektünk volt, ahol a megrendelők józanul felmérték az opciók előnyeit és hátrányait, és két különböző átfedési megoldást választottak, mi pedig megvalósítottuk azokat.
Lehetőség nyílt a megvalósítás összehasonlítására. Nem kizsákmányolás, két-három év múlva beszélnünk kell róla.
Tehát mi az átfedő hálózatokkal és SDN-nel rendelkező hálózati szövet?
Mi a teendő a klasszikus hálózati architektúra sürgető problémáival?
Minden évben új technológiák és ötletek jelennek meg. A gyakorlatban sokáig nem merült fel sürgős igény a hálózatok újjáépítésére, mert a régi jó módszerekkel kézzel is meg lehet csinálni mindent. Szóval mi van, ha a huszonegyedik század? Végül is egy adminisztrátornak dolgoznia kell, nem pedig az irodájában ülni.
Ekkor kezdődött a nagyszabású adatközpontok építésének fellendülése. Aztán világossá vált, hogy a klasszikus építészet fejlődési határa elérkezett, nem csak a teljesítmény, a hibatűrés és a skálázhatóság tekintetében. A problémák megoldásának egyik lehetősége az volt, hogy átfedő hálózatokat építenek egy irányított gerinchálózatra.
Ráadásul a hálózatok méretarányának növekedésével az ilyen gyárak menedzselésének problémája is akuttá vált, aminek következtében megjelentek a szoftveresen definiált hálózati megoldások, amelyek képesek a teljes hálózati infrastruktúra egységes egészét kezelni. Ha pedig a hálózatot egyetlen pontról kezelik, akkor az IT-infrastruktúra többi eleme könnyebben kommunikálhat vele, és az ilyen interakciós folyamatok könnyebben automatizálhatók.
Szinte minden nagyobb gyártó nemcsak hálózati eszközöket, hanem virtualizációt is kínál ilyen megoldásokra a portfóliójában.
Már csak azt kell kitalálni, hogy mi a megfelelő az igényekhez. Például a különösen nagy, jó fejlesztői és üzemeltetői csapattal rendelkező cégek esetében a szállítóktól kapott csomagolt megoldások nem mindig elégítenek ki minden igényt, ezért saját SD (szoftver által definiált) megoldásokat fejlesztenek ki. Ilyenek például a felhőszolgáltatók, akik folyamatosan bővítik ügyfeleiknek nyújtott szolgáltatások körét, és a csomagolt megoldások egyszerűen nem tudnak lépést tartani az igényeikkel.
A középvállalatok számára az esetek 99 százalékában elegendő az eladó által dobozos megoldás formájában kínált funkcionalitás.
Mik azok az overlay hálózatok?
Mi az ötlet az overlay hálózatok mögött? Lényegében vegyen egy klasszikus irányított hálózatot, és építsen rá egy másik hálózatot, hogy további funkciókhoz jusson. Leggyakrabban a berendezések és kommunikációs vonalak terhelésének hatékony elosztásáról, a skálázhatósági korlát jelentős növeléséről, a megbízhatóság növeléséről és egy rakás biztonsági cuccról beszélünk (a szegmentáció miatt). Az SDN megoldások pedig ezen túlmenően lehetőséget adnak a nagyon-nagyon-nagyon kényelmes rugalmas ügyintézésre, és átláthatóbbá teszik a hálózatot fogyasztói számára.
Általánosságban elmondható, hogy ha a helyi hálózatokat a 2010-es években találták volna fel, akkor sokkal másképp néztek volna ki, mint amit a hetvenes években a katonaságtól örököltünk.
Ami az overlay hálózatokat használó szövetek építésének technológiáit illeti, jelenleg számos szállítói implementáció és internetes RFC projekt létezik (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve és mások). Igen, vannak szabványok, de ezeknek a szabványoknak a különböző gyártók általi végrehajtása eltérő lehet, így az ilyen gyárak létrehozásakor továbbra is csak elméletileg lehet teljesen elhagyni az eladói zárat.
Az SD-megoldással a dolgok még zavarosabbak: minden gyártónak megvan a maga elképzelése. Vannak teljesen nyitott megoldások, amiket elméletileg magad is ki tudod egészíteni, és vannak teljesen zártak is.
A Cisco az SDN adatközpontokhoz való verzióját kínálja – ACI. Természetesen ez egy 100%-ban gyártózárolt megoldás a hálózati eszközök kiválasztását illetően, ugyanakkor teljes mértékben integrálva van a virtualizációs rendszerekkel, konténerezéssel, biztonsággal, hangszereléssel, terheléselosztókkal stb. De lényegében mégiscsak egyfajta fekete doboz, az összes belső folyamathoz való teljes hozzáférés lehetősége nélkül. Nem minden ügyfél ért egyet ezzel a lehetőséggel, mivel Ön teljes mértékben függ a megírt megoldáskód minőségétől és annak megvalósításától, másrészt a gyártó rendelkezik a világ egyik legjobb műszaki támogatásával, és egy dedikált csapattal rendelkezik. ehhez a megoldáshoz. Az első projekt megoldásaként a Cisco ACI-t választották.
A második projekthez a Juniper megoldást választották. A gyártónak saját SDN-je is van az adatközponthoz, de az ügyfél úgy döntött, hogy nem alkalmazza az SDN-t. A hálózatépítési technológiaként egy központi vezérlők nélküli EVPN VXLAN szövetet választottak.
Mire való
A gyár létrehozása lehetővé teszi egy könnyen méretezhető, hibatűrő, megbízható hálózat kiépítését. Az architektúra (leaf-spine) figyelembe veszi az adatközpontok jellemzőit (forgalmi utak, a késések és szűk keresztmetszetek minimalizálása a hálózatban). Az adatközpontok SD-megoldásai lehetővé teszik egy ilyen gyár rendkívül kényelmes, gyors és rugalmas kezelését és az adatközponti ökoszisztémába való integrálását.
Mindkét ügyfélnek redundáns adatközpontokat kellett kiépítenie a hibatűrés biztosítása érdekében, és emellett az adatközpontok közötti forgalmat is titkosítani kellett.
Az első vásárló már a textil nélküli megoldásokat fontolgatta hálózataik lehetséges szabványaként, de a tesztek során több hardvergyártó között is problémáik akadtak az STP-kompatibilitással. Leállások voltak, amelyek miatt a szolgáltatások összeomlottak. És az ügyfél számára ez kritikus volt.
A Cisco már az ügyfél vállalati szabványa volt, megnézték az ACI és egyéb lehetőségeket, és úgy döntöttek, hogy érdemes ezt a megoldást választani. Tetszett az egy gombról egyetlen vezérlőn keresztül történő vezérlés automatizálása. A szolgáltatások gyorsabban konfigurálhatók és gyorsabban kezelhetők. Úgy döntöttünk, hogy az IPN és a SPINE kapcsolók között MACSec futtatásával biztosítjuk a forgalom titkosítását. Így sikerült elkerülnünk a szűk keresztmetszetet a crypto gateway formájában, spórolni rajtuk és a maximális sávszélességet kihasználni.
A második ügyfél a Juniper vezérlő nélküli megoldását választotta, mert a meglévő adatközpontjukban már volt egy EVPN VXLAN szövetet megvalósító kis telepítés. De ott nem volt hibatűrő (egy kapcsolót használtak). Úgy döntöttünk, hogy bővítjük a fő adatközpont infrastruktúráját, és gyárat építünk a tartalék adatközpontban. A meglévő EVPN-t nem használták ki teljesen: a VXLAN-beágyazást valójában nem használták, mivel minden host egy kapcsolóhoz csatlakozott, és minden MAC-cím és /32-es gazdagép cím helyi volt, az átjáró számukra ugyanaz a kapcsoló volt, nem volt más eszköz , ahol VXLAN alagutak építésére volt szükség. Úgy döntöttek, hogy IPSEC technológiával biztosítják a forgalom titkosítását a tűzfalak között (a tűzfal teljesítménye elegendő volt).
Kipróbálták az ACI-t is, de úgy döntöttek, hogy a gyártói zárolás miatt túl sok hardvert kell vásárolniuk, beleértve a nemrég vásárolt új berendezések cseréjét is, és ennek egyszerűen nem volt értelme gazdaságilag. Igen, a Cisco szövet mindennel integrálható, de magában a szövetben csak az eszközei lehetségesek.
Másrészt, ahogy korábban említettük, nem lehet egyszerűen keverni egy EVPN VXLAN szövetet bármelyik szomszédos szállítóval, mert a protokoll megvalósítása eltérő. Ez olyan, mintha egy hálózatban keresztezné a Ciscót és a Huaweit – úgy tűnik, a szabványok általánosak, de egy tamburával kell táncolnia. Mivel ez egy bank, és a kompatibilitási tesztek nagyon hosszúak lennének, úgy döntöttünk, hogy jobb, ha most ugyanattól a gyártótól vásárolunk, és nem ragaszkodunk túlzottan az alapfunkciókon túli funkciókhoz.
Migrációs terv
Két ACI-alapú adatközpont:
Adatközpontok közötti interakció megszervezése. A Multi-Pod megoldást választották – minden adatközpont egy pod. A kapcsolók száma és a podok közötti késleltetések (RTT kevesebb, mint 50 ms) szerinti skálázás követelményeit figyelembe veszik. Úgy döntöttek, hogy nem építünk többhelyes megoldást a könnyebb kezelhetőség érdekében (a Multi-Pod megoldás egyetlen felügyeleti felületet használ, a Multi-Site két interfésszel rendelkezik, vagy többhelyes orchestratort igényel), és mivel nincs földrajzi helyfoglalás szükséges volt.
A Legacy hálózatról történő szolgáltatások migrálása szempontjából a legátláthatóbb lehetőséget választották, fokozatosan átadva az egyes szolgáltatásoknak megfelelő VLAN-okat.
Az áttelepítéshez gyárilag minden VLAN-hoz létrejött egy megfelelő EPG (End-point-group). Először a hálózatot megfeszítették a régi hálózat és a szövet között az L2-n keresztül, majd az összes gazdagép migrációja után az átjáró átkerült a szövetbe, és az EPG interakcióba került a meglévő hálózattal az L3OUT-on keresztül, míg az L3OUT és az EPG közötti interakció. szerződések segítségével írták le. Hozzávetőleges diagram:
Az alábbi ábrán a legtöbb ACI gyári szabályzat mintaszerkezete látható. A teljes beállítás más házirendekbe ágyazott házirendeken és így tovább. Eleinte nagyon nehéz kitalálni, de fokozatosan, ahogy a gyakorlat azt mutatja, a hálózati rendszergazdák körülbelül egy hónap alatt hozzászoknak ehhez a struktúrához, és csak ezután kezdik megérteni, mennyire kényelmes.
Сравнение
A Cisco ACI megoldásban több felszerelést kell vásárolni (külön kapcsolók az Inter-Pod interakcióhoz és az APIC vezérlőkhöz), ami drágítja. A Juniper megoldásához nem kellett vezérlőt vagy kiegészítőt vásárolni; Lehetőség volt az ügyfél meglévő berendezéseinek részleges használatára.
Íme az EVPN VXLAN szövet architektúrája a második projekt két adatközpontjához:
Az ACI-vel kész megoldást kap – nem kell trükközni, nem kell optimalizálni. Az ügyfél kezdeti gyári ismerkedése során nincs szükség fejlesztőkre, nincs szükség támogató emberekre a kódhoz és az automatizáláshoz. Használata meglehetősen egyszerű; sok beállítás elvégezhető a varázslón keresztül, ami nem mindig előny, különösen a parancssorhoz szokott emberek számára. Mindenesetre időbe telik, amíg az agy új pályára épül, a beállítások sajátosságaihoz a házirendek és számos beágyazott házirend segítségével. Ezen túlmenően nagyon kívánatos egy világos struktúra a házirendek és objektumok elnevezéséhez. Ha bármilyen probléma merül fel a vezérlő logikájában, azt csak műszaki támogatással lehet megoldani.
EVPN-ben - konzol. Szenvedjen vagy örüljön. Ismerős felület a régi gárdának. Igen, van szabványos konfiguráció és útmutatók. Manát kell szívnod. Különböző tervek, minden világos és részletes.
Természetesen mindkét esetben a migráció során jobb, ha először a nem legkritikusabb szolgáltatásokat, például a tesztkörnyezeteket migrálja át, és csak azután, az összes hiba észlelése után folytatja a termelést. És ne hangolódj be péntek este. Nem szabad bízni az eladóban, hogy minden rendben lesz, mindig jobb, ha biztonságosan játszol.
Többet fizet az ACI-ért, bár a Cisco jelenleg aktívan népszerűsíti ezt a megoldást, és gyakran jó kedvezményeket ad rá, de megspórolja a karbantartást. Az EVPN-gyár vezérlő nélküli irányítása és bármilyen automatizálása befektetést és rendszeres költségeket igényel - monitorozás, automatizálás, új szolgáltatások bevezetése. Ugyanakkor az ACI-nél az első indítás 30-40 százalékkal tovább tart. Ez azért történik, mert tovább tart a szükséges profilok és házirendek teljes készletének létrehozása, amelyeket ezután használni fognak. De ahogy a hálózat növekszik, a szükséges konfigurációk száma csökken. Előre elkészített házirendeket, profilokat, objektumokat használ. Rugalmasan konfigurálhatja a szegmentálást és a biztonságot, központilag kezelheti azokat a szerződéseket, amelyek bizonyos interakciók engedélyezéséért felelősek az EPG-k között – a munka mennyisége meredeken csökken.
Az EVPN-ben minden eszközt gyárilag kell konfigurálnia, nagyobb a hibák valószínűsége.
Míg az ACI bevezetése lassabb volt, az EVPN-nek majdnem kétszer annyi ideig tartott a hibakeresés. Ha a Cisco esetében mindig fel lehet hívni egy support mérnököt és rákérdezni a hálózat egészére (mert megoldásként le van fedve), akkor a Juniper Networks-től csak hardvert veszel, és erre is van fedezet. A csomagok elhagyták a készüléket? Rendben, akkor a te problémáid. De feltehet egy kérdést a megoldás vagy a hálózattervezés kiválasztásával kapcsolatban - és akkor azt tanácsolják, hogy vásároljon professzionális szolgáltatást, felár ellenében.
Az ACI támogatás nagyon klassz, mert külön van: külön csapat ül csak erre. Vannak oroszul beszélő szakemberek is. Az útmutató részletes, a megoldások előre meghatározottak. Megnézik és tanácsot adnak. Gyorsan érvényesítik a tervezést, ami gyakran fontos. A Juniper Networks ugyanezt csinálja, csak sokkal lassabban (nekünk volt ilyen, most a pletykák szerint jobbnak kell lennie), ami arra kényszeríti az embert, hogy mindent saját maga csináljon meg, amit egy megoldásmérnök tanács tud adni.
A Cisco ACI támogatja a virtualizációs és konténerrendszerekkel (VMware, Kubernetes, Hyper-V) és a központosított felügyelettel való integrációt. Elérhető hálózati és biztonsági szolgáltatásokkal - kiegyensúlyozás, tűzfalak, WAF, IPS, stb... Jó mikroszegmentáció a dobozból. A második megoldásban a hálózati szolgáltatásokkal való integráció gyerekjáték, és érdemes előre megbeszélni a fórumokat azokkal, akik ezt megtették.
Teljes
Minden konkrét esetre ki kell választani a megoldást, nem csak a berendezés költsége alapján, hanem figyelembe kell venni a további üzemeltetési költségeket és a főbb problémákat is, amelyekkel a megrendelő jelenleg szembesül, és milyen tervei vannak. az informatikai infrastruktúra fejlesztését szolgálják.
Az ACI a kiegészítő felszerelések miatt drágább volt, de a megoldás készen van, további kikészítés nélkül, a második megoldás bonyolultabb és üzemeltetési szempontból költségesebb, de olcsóbb.
Ha meg akarja vitatni, hogy mennyibe kerülhet egy hálózati struktúra megvalósítása különböző gyártóknál, és milyen architektúrára van szükség, találkozhat és beszélgethet. Addig díjmentesen tanácsot adunk, amíg meg nem kap egy durva vázlatot az architektúráról (amivel költségvetést tud számolni), a részletes kidolgozás természetesen már fizetett.
Vladimir Klepche, vállalati hálózatok.
Forrás: will.com