Ma arról mesélek, hogyan született meg és valósult meg az ötlet, hogy cégünk számára új belső hálózatot hozzunk létre. A vezetőség álláspontja az, hogy ugyanazt a teljes értékű projektet kell megvalósítania magának, mint az ügyfélnek. Ha jól csináljuk magunknak, meg tudjuk hívni az ügyfelet, és megmutatjuk, mennyire működik és működik, amit kínálunk neki. Ezért nagyon alaposan, a teljes gyártási ciklust felhasználva közelítettük meg a moszkvai iroda új hálózatának koncepciójának kidolgozását: osztályigények elemzése → műszaki megoldás kiválasztása → tervezés → megvalósítás → tesztelés. Tehát kezdjük.
Technikai megoldás kiválasztása: Mutant Sanctuary
Az összetett automatizált rendszeren végzett munka folyamatát jelenleg a legjobban a GOST 34.601-90 „Automatizált rendszerek” írja le. A Teremtés szakaszai”, így ennek megfelelően dolgoztunk. És már a követelmények kialakításának és a koncepció kidolgozásának szakaszában találkoztunk az első nehézségekkel. Különböző profilú szervezetek - bankok, biztosítók, szoftverfejlesztők stb. - feladataikhoz, szabványaikhoz bizonyos típusú hálózatokra van szükségük, amelyek sajátosságai világosak és szabványosak. Ez azonban nálunk nem fog működni.
Miért?
A Jet Infosystems egy nagy, szerteágazó informatikai vállalat. Belső támogatási részlegünk ugyanakkor kicsi (de büszke), az alapszolgáltatások, rendszerek működőképességét biztosítja. A cég számos részleggel rendelkezik, amelyek különböző funkciókat látnak el: ezek több nagy teljesítményű outsourcing csapat, valamint az üzleti rendszerek és az információbiztonság házon belüli fejlesztői, valamint a számítástechnikai rendszerek építészei - általában, bárki is legyen az. Ennek megfelelően feladataik, rendszereik és biztonsági politikáik is eltérőek. Ami a várakozásoknak megfelelően nehézségeket okozott az igényfelmérés és a szabványosítás folyamatában.
Itt van például a fejlesztési részleg: alkalmazottai nagyszámú ügyfél számára írnak és tesztelnek kódot. Gyakran szükség van a tesztkörnyezetek gyors megszervezésére, és őszintén szólva nem mindig lehet minden projektre vonatkozóan követelményeket megfogalmazni, erőforrásokat igényelni és külön tesztkörnyezetet felépíteni minden belső szabályozásnak megfelelően. Ez furcsa helyzetekre ad okot: egy nap szerény szolgád benézett a fejlesztők szobájába, és az asztal alatt egy 20 asztali számítógépből álló, megfelelően működő Hadoop-fürtöt talált, amely megmagyarázhatatlan módon egy közös hálózathoz csatlakozott. Szerintem nem érdemes tisztázni, hogy a cég informatikai osztálya nem tudott a létezéséről. Ez a körülmény – sok máshoz hasonlóan – felelős azért, hogy a projekt kidolgozása során megszületett a „mutáns tartalék” kifejezés, amely a régóta szenvedő irodai infrastruktúra állapotát írja le.
Vagy itt van egy másik példa. Időnként egy osztályon belül próbapadot állítanak fel. Ez volt a helyzet a Jira és a Confluence esetében, amelyeket a Szoftverfejlesztési Központ korlátozott mértékben használt egyes projektekben. Egy idő után más osztályok értesültek ezekről a hasznos erőforrásokról, értékelték őket, és 2018 végén a Jira és a Confluence a „helyi programozók játékszere” státuszból a „vállalati erőforrások” státuszba került. Most ezekhez a rendszerekhez tulajdonost kell rendelni, SLA-kat, hozzáférési/információs biztonsági házirendeket, biztonsági mentési házirendeket, megfigyelést, a problémák megoldására irányuló kérések útválasztási szabályait meg kell határozni - általában egy teljes értékű információs rendszer minden attribútuma jelen kell legyen. .
Minden részlegünk egy inkubátor is, amely saját termékeit termeszti. Némelyikük a fejlesztési szakaszban elhal, néhányat a projektek során használunk, míg mások gyökeret eresztenek, és replikált megoldásokká válnak, amelyeket mi magunk kezdünk el használni, és eladunk ügyfeleinknek. Minden ilyen rendszerhez kívánatos, hogy rendelkezzen saját hálózati környezettel, ahol a többi rendszer zavarása nélkül fejlődik, és egy bizonyos ponton integrálható a vállalat infrastruktúrájába.
Amellett, hogy a fejlesztés, van egy nagyon nagy több mint 500 alkalmazottal, minden ügyfél számára csapatokká alakulva. Részt vesznek a hálózatok és egyéb rendszerek karbantartásában, a távfelügyeletben, a panaszok megoldásában stb. Vagyis az SC infrastruktúrája valójában annak az ügyfélnek az infrastruktúrája, akivel jelenleg is dolgoznak. A hálózat ezen szakaszával való munkavégzés sajátossága, hogy cégünk számára a munkaállomások részben külső, részben belsőek. Ezért az SC esetében a következő megközelítést alkalmaztuk - a vállalat hálózati és egyéb erőforrásokkal látja el a megfelelő részleget, külső kapcsolatnak tekintve ezen osztályok munkaállomásait (a fióktelepek és távoli felhasználók analógiájára).
Autópálya tervezés: mi vagyunk az üzemeltető (meglepetés)
Miután felmértük az összes buktatót, rájöttünk, hogy egy távközlési szolgáltató hálózatát kapjuk egy irodán belül, és ennek megfelelően kezdtünk el cselekedni.
Létrehoztunk egy törzshálózatot, melynek segítségével bármely belső, és a jövőben külső fogyasztó számára biztosított a szükséges szolgáltatás: L2 VPN, L3 VPN vagy normál L3 routing. Egyes részlegeknek biztonságos internet-hozzáférésre van szükségük, míg másoknak tiszta hozzáférésre van szükségük tűzfalak nélkül, ugyanakkor meg kell védeni vállalati erőforrásainkat és törzshálózatunkat a forgalomtól.
Minden részleggel informálisan „SLA-t kötöttünk”. Ennek értelmében minden felmerülő incidenst meghatározott, előre egyeztetett időn belül meg kell szüntetni. A cég hálózatával szemben támasztott követelmények szigorúnak bizonyultak. Telefon- és e-mail-hiba esetén a maximális válaszidő egy incidensre 5 perc volt. Tipikus meghibásodások esetén a hálózati funkcionalitás visszaállításának ideje nem több, mint egy perc.
Mivel szolgáltató szintű hálózattal rendelkezünk, csak szigorú szabályok betartásával lehet rá csatlakozni. A szolgáltatási egységek házirendeket határoznak meg és szolgáltatásokat nyújtanak. Még az egyes szerverek, virtuális gépek és munkaállomások kapcsolatairól sincs szükségük információra. Ugyanakkor védelmi mechanizmusokra van szükség, mert egyetlen kapcsolat sem tilthatja le a hálózatot. Ha véletlenül hurok jön létre, akkor ezt a többi felhasználó ne vegye észre, vagyis a hálózat megfelelő válasza szükséges. Bármely távközlési szolgáltató folyamatosan megold hasonló bonyolultnak tűnő problémákat a törzshálózatán belül. Számos, eltérő igényű és forgalmú ügyfélnek nyújt szolgáltatást. Ugyanakkor a különböző előfizetők nem tapasztalhatnak kényelmetlenséget mások forgalmából.
Itthon ezt a problémát a következőképpen oldottuk meg: IS-IS protokollt használva építettünk egy gerinc L3 hálózatot teljes redundanciával. A mag tetejére technológián alapuló overlay hálózat épült /, útválasztási protokoll használatával . Az útválasztási protokollok konvergenciájának felgyorsítására BFD technológiát alkalmaztak.
Hálózati struktúra
A tesztek során ez a séma kiválónak bizonyult - ha bármelyik csatorna vagy kapcsoló le van választva, a konvergencia ideje nem haladja meg a 0.1-0.2 s-ot, minimális csomagok vesznek el (gyakran egy sem), a TCP-munkamenetek nem szakadnak meg, a telefonbeszélgetések nem szakadnak meg.
Underlay Layer - Routing
Overlay Layer – Útválasztás
Elosztási kapcsolóként a Huawei CE6870 kapcsolóit VXLAN-licenccel használták. Ez az eszköz optimális ár/minőség aránnyal rendelkezik, ami lehetővé teszi az előfizetők csatlakoztatását 10 Gbit/s sebességgel, a gerinchálózathoz pedig 40-100 Gbit/s sebességgel, a használt adó-vevőktől függően.
Huawei CE6870 kapcsolók
A Huawei CE8850 kapcsolóit alapkapcsolóként használták. A cél a forgalom gyors és megbízható továbbítása. Az elosztó kapcsolókon kívül semmilyen eszköz nem csatlakozik hozzájuk, nem tudnak semmit a VXLAN-ról, ezért egy 32 db 40/100 Gbps porttal rendelkező modellt választottak, alaplicenccel, amely L3 útválasztást és támogatást biztosít az IS-IS és MP-BGP számára. protokollok .
Az alsó a Huawei CE8850 magkapcsolója
A tervezési szakaszban vita robbant ki a csapaton belül azokról a technológiákról, amelyek segítségével hibatűrő kapcsolatot lehet megvalósítani a maghálózati csomópontokkal. Moszkvai irodánk három épületben található, 7 elosztóhelyiséggel rendelkezünk, melyek mindegyikébe két-két Huawei CE6870 elosztó kapcsoló került beépítésre (több elosztóhelyiségbe csak beléptető kapcsoló került beépítésre). A hálózati koncepció kidolgozásakor két redundancia-lehetőséget vettek figyelembe:
- Az elosztó kapcsolók összevonása hibatűrő kötegbe minden keresztkapcsolati helyiségben. Előnyök: egyszerűség és könnyű beállítás. Hátrányok: nagyobb a valószínűsége a teljes verem meghibásodásának, ha hibák lépnek fel a hálózati eszközök firmware-ében ("memóriaszivárgás" és hasonlók).
- Alkalmazza az M-LAG és az Anycast gateway technológiákat az eszközök elosztási kapcsolókhoz való csatlakoztatásához.
Végül a második lehetőség mellett döntöttünk. Valamivel nehezebb konfigurálni, de a gyakorlatban megmutatta teljesítményét és nagy megbízhatóságát.
Először vegyük fontolóra a végberendezések elosztókapcsolókhoz való csatlakoztatását:
Kereszt
Hozzáférési kapcsoló, szerver vagy bármely más, hibatűrő kapcsolatot igénylő eszköz két elosztókapcsolóban található. Az M-LAG technológia adatkapcsolati szinten redundanciát biztosít. Feltételezzük, hogy két elosztókapcsoló egy eszközként jelenik meg a csatlakoztatott berendezés számára. A redundancia és a terheléselosztás az LACP protokoll segítségével történik.
Az Anycast gateway technológia hálózati szinten redundanciát biztosít. Meglehetősen nagy számú VRF van konfigurálva mindegyik elosztó kapcsolón (mindegyik VRF saját célra készült - külön a „szokásos” felhasználók számára, külön a telefonáláshoz, külön a különböző teszt- és fejlesztési környezetekhez stb.), és mindegyikben. A VRF-ben több VLAN van beállítva. Hálózatunkban az elosztókapcsolók az alapértelmezett átjárók az összes hozzájuk csatlakoztatott eszköz számára. A VLAN interfészeknek megfelelő IP-címek mindkét elosztó kapcsolónál megegyeznek. A forgalom a legközelebbi váltón keresztül történik.
Most nézzük meg a terjesztési kapcsolók kernelhez való csatlakoztatását:
A hibatűrés hálózati szinten az IS-IS protokoll használatával biztosított. Felhívjuk figyelmét, hogy a kapcsolók között külön L3-as kommunikációs vonal van, 100G sebességgel. Fizikailag ez a kommunikációs vonal egy Direct Access kábel, amely a jobb oldalon látható a Huawei CE6870 kapcsolók fotóján.
Alternatív megoldás egy „becsületes” teljesen összekapcsolt kettős csillag topológia megszervezése, de, mint fentebb említettük, három épületben 7 keresztkapcsolatos helyiségünk van. Ennek megfelelően, ha a „kétcsillagos” topológiát választottuk volna, akkor pontosan kétszer annyi „nagy hatótávolságú” 40G adó-vevőre lett volna szükségünk. A megtakarítás itt nagyon jelentős.
Néhány szót kell ejteni a VXLAN és az Anycast gateway technológiák együttműködéséről. A VXLAN, anélkül, hogy belemennénk a részletekbe, egy alagút az Ethernet keretek UDP-csomagokon belüli szállítására. Az elosztó kapcsolók loopback interfészei a VXLAN alagút cél IP-címeként szolgálnak. Minden crossoverhez két, azonos loopback interfész címmel rendelkező kapcsoló tartozik, így bármelyikre érkezhet egy csomag, amelyből Ethernet keretet lehet kinyerni.
Ha a kapcsoló ismeri a visszakeresett keret MAC-címét, akkor a keretet megfelelően kézbesíti a célállomásra. Annak biztosítása érdekében, hogy mindkét elosztó kapcsoló ugyanabban a keresztkapcsolatban legyen naprakész információval rendelkezik a hozzáférési kapcsolókról „érkező” MAC-címekről, az M-LAG mechanizmus felelős a MAC-címtáblázatok (valamint az ARP) szinkronizálásáért. táblázatok) mindkét kapcsolón M-LAG pár.
A forgalom kiegyenlítése annak köszönhető, hogy az alátéthálózatban több útvonal is található az elosztó kapcsolók visszahurkolási interfészeihez.
Ahelyett, hogy egy következtetés
Mint fentebb említettük, a tesztelés és az üzemeltetés során a hálózat nagy megbízhatóságot (a tipikus hibák helyreállítási ideje nem több száz milliszekundumnál) és jó teljesítményt mutatott - minden keresztcsatlakozás két 40 Gbit/s-os csatornával kapcsolódik a maghoz. Hálózatunk hozzáférési kapcsolói egymásra vannak rakva, és LACP/M-LAG-n keresztül két 10 Gbit/s-os csatornával csatlakoznak az elosztó kapcsolókhoz. Egy verem általában 5 kapcsolót tartalmaz, mindegyik 48 porttal, és minden keresztkapcsolatban legfeljebb 10 hozzáférési verem csatlakozik az elosztáshoz. Így a gerinchálózat a maximális elméleti terhelés mellett is körülbelül 30 Mbit/s-ot biztosít felhasználónként, ami az írás pillanatában minden gyakorlati alkalmazásunkhoz elegendő.
A hálózat lehetővé teszi bármely tetszőleges csatlakoztatott eszköz párosításának zökkenőmentes megszervezését mind az L2-n, mind az L3-on keresztül, biztosítva a forgalom (amelyet az információbiztonsági szolgáltatás kedveli) és a hibatartományok (amit az üzemeltetési csapat szeret) teljes elkülönítését.
A következő részben elmondjuk, hogyan költöztünk át az új hálózatra. Maradjon velünk!
Maxim Klochkov
A hálózati audit és komplex projektek csoport vezető tanácsadója
Hálózati megoldások központja
"Jet Inforendszerek"
Forrás: will.com