Vandag sal ek jou vertel hoe die idee om 'n nuwe interne netwerk vir ons maatskappy te skep ontstaan en geïmplementeer is. Bestuur se standpunt is dat jy dieselfde volwaardige projek vir jouself moet doen as vir die kliënt. As ons dit goed vir onsself doen, kan ons die kliënt nooi en wys hoe goed wat ons hom bied werk en werk. Daarom het ons die ontwikkeling van die konsep van 'n nuwe netwerk vir die Moskou-kantoor baie deeglik benader, met behulp van die volle produksiesiklus: ontleding van departementele behoeftes → keuse van 'n tegniese oplossing → ontwerp → implementering → toetsing. So kom ons begin.
Die keuse van 'n tegniese oplossing: Mutant Sanctuary
Die prosedure om aan 'n komplekse outomatiese stelsel te werk, word tans die beste beskryf in GOST 34.601-90 "Outomatiese stelsels. Stages of Creation”, so ons het daarvolgens gewerk. En reeds in die stadiums van vereistesvorming en konsepontwikkeling het ons die eerste probleme ondervind. Organisasies met verskillende profiele - banke, versekeringsmaatskappye, sagteware-ontwikkelaars, ens. - vir hul take en standaarde benodig hulle sekere soorte netwerke, waarvan die besonderhede duidelik en gestandaardiseer is. Dit sal egter nie by ons werk nie.
Hoekom?
Jet Infosystems is 'n groot gediversifiseerde IT-maatskappy. Terselfdertyd is ons interne ondersteuningsafdeling klein (maar trots), dit verseker die funksionaliteit van basiese dienste en stelsels. Die maatskappy bevat baie afdelings wat verskillende funksies verrig: dit is verskeie kragtige uitkontrakteringspanne, en interne ontwikkelaars van besigheidstelsels, en inligtingsekuriteit, en argitekte van rekenaarstelsels – in die algemeen, wie dit ook al is. Gevolglik verskil hul take, stelsels en sekuriteitsbeleide ook. Wat, soos verwag, probleme geskep het in die proses van behoefte-analise en standaardisering.
Hier is byvoorbeeld die ontwikkelingsafdeling: sy werknemers skryf en toets kode vir 'n groot aantal kliënte. Dikwels is daar 'n behoefte om vinnig toetsomgewings te organiseer, en eerlik gesproke is dit nie altyd moontlik om vereistes vir elke projek te formuleer, hulpbronne aan te vra en 'n aparte toetsomgewing in ooreenstemming met alle interne regulasies te bou nie. Dit gee aanleiding tot nuuskierige situasies: eendag het jou nederige bediende in die ontwikkelaars se kamer gekyk en onder die tafel 'n behoorlik werkende Hadoop-groep van 20 lessenaars gevind, wat onverklaarbaar aan 'n gemeenskaplike netwerk gekoppel was. Ek dink nie dit is die moeite werd om te verduidelik dat die maatskappy se IT-afdeling nie geweet het van sy bestaan nie. Hierdie omstandigheid, soos baie ander, was verantwoordelik vir die feit dat tydens die ontwikkeling van die projek die term "mutante reservaat" gebore is, wat die toestand van die lankmoedige kantoorinfrastruktuur beskryf.
Of hier is nog 'n voorbeeld. Periodiek word 'n toetsbank binne 'n departement opgestel. Dit was die geval met Jira en Confluence, wat in 'n beperkte mate deur die sagteware-ontwikkelingsentrum in sommige projekte gebruik is. Na 'n geruime tyd het ander departemente van hierdie nuttige hulpbronne geleer, dit geëvalueer, en aan die einde van 2018 het Jira en Confluence van die status van "plaaslike programmeerders se speelgoed" na die status van "maatskappyhulpbronne" verskuif. Nou moet 'n eienaar aan hierdie stelsels toegewys word, SLA's, toegang-/inligtingsekuriteitsbeleide, rugsteunbeleide, monitering, reëls vir die roetering van versoeke om probleme op te los moet gedefinieer word - in die algemeen moet al die eienskappe van 'n volwaardige inligtingstelsel teenwoordig wees .
Elkeen van ons afdelings is ook 'n broeikas wat sy eie produkte kweek. Sommige van hulle sterf in die ontwikkelingstadium, sommige gebruik ons terwyl ons aan projekte werk, terwyl ander wortel skiet en gerepliseerde oplossings word wat ons self begin gebruik en aan kliënte verkoop. Vir elke so 'n stelsel is dit wenslik om sy eie netwerkomgewing te hê, waar dit sal ontwikkel sonder om met ander stelsels in te meng, en op 'n sekere punt in die maatskappy se infrastruktuur geïntegreer kan word.
Benewens ontwikkeling, het ons 'n baie groot met meer as 500 werknemers, gevorm in spanne vir elke kliënt. Hulle is betrokke by die instandhouding van netwerke en ander stelsels, afstandmonitering, die oplossing van eise, ensovoorts. Dit wil sê, die infrastruktuur van die SC is in werklikheid die infrastruktuur van die kliënt met wie hulle tans werk. Die eienaardigheid daarvan om met hierdie afdeling van die netwerk te werk, is dat hul werkstasies vir ons maatskappy deels ekstern en deels intern is. Daarom het ons vir die SC die volgende benadering geïmplementeer - die maatskappy voorsien die ooreenstemmende departement van netwerk- en ander hulpbronne, en beskou die werkstasies van hierdie departemente as eksterne verbindings (naar analogie met takke en afgeleë gebruikers).
Snelwegontwerp: ons is die operateur (verrassing)
Nadat ons al die slaggate beoordeel het, het ons besef dat ons 'n telekommunikasie-operateur se netwerk binne een kantoor kry, en ons het dienooreenkomstig begin optree.
Ons het 'n kernnetwerk geskep met behulp waarvan enige interne, en in die toekoms ook eksterne, verbruiker van die vereiste diens voorsien word: L2 VPN, L3 VPN of gereelde L3-roetering. Sommige departemente het veilige internettoegang nodig, terwyl ander skoon toegang sonder brandmure nodig het, maar terselfdertyd ons korporatiewe hulpbronne en kernnetwerk teen hul verkeer moet beskerm.
Ons het informeel "'n SLA gesluit" met elke afdeling. Daarvolgens moet alle voorvalle wat ontstaan binne 'n sekere vooraf ooreengekome tydperk uitgeskakel word. Die maatskappy se vereistes vir sy netwerk blyk streng te wees. Die maksimum reaksietyd op 'n voorval in die geval van telefoon- en e-pos mislukkings was 5 minute. Die tyd om netwerkfunksionaliteit te herstel tydens tipiese mislukkings is nie meer as 'n minuut nie.
Aangesien ons 'n draergraad-netwerk het, kan u slegs streng in ooreenstemming met die reëls daaraan koppel. Dienseenhede stel beleide op en verskaf dienste. Hulle het nie eens inligting nodig oor die verbindings van spesifieke bedieners, virtuele masjiene en werkstasies nie. Maar terselfdertyd is beskermingsmeganismes nodig, want nie 'n enkele verbinding behoort die netwerk te deaktiveer nie. As 'n lus per ongeluk geskep word, moet ander gebruikers dit nie agterkom nie, dit wil sê, 'n voldoende reaksie van die netwerk is nodig. Enige telekommunikasie-operateur los voortdurend soortgelyke oënskynlik komplekse probleme binne sy kernnetwerk op. Dit verskaf diens aan baie kliënte met verskillende behoeftes en verkeer. Terselfdertyd moet verskillende intekenare nie ongerief ervaar as gevolg van die verkeer van ander nie.
By die huis het ons hierdie probleem op die volgende manier opgelos: ons het 'n ruggraat L3-netwerk met volle oortolligheid gebou, met behulp van die IS-IS-protokol. 'n Oorlegnetwerk is bo-op die kern gebou, gebaseer op tegnologie /, met behulp van 'n roeteprotokol . Om die konvergensie van roeteringsprotokolle te bespoedig, is BFD-tegnologie gebruik.
Netwerkstruktuur
In toetse het hierdie skema getoon dat dit uitstekend is - wanneer enige kanaal of skakelaar ontkoppel word, is die konvergensietyd nie meer as 0.1-0.2 s nie, 'n minimum van pakkies gaan verlore (dikwels geen), TCP-sessies word nie geskeur nie, telefoongesprekke word nie onderbreek nie.
Onderlaaglaag - Roetering
Oorleglaag - Roetering
Huawei CE6870-skakelaars met VXLAN-lisensies is as verspreidingskakelaars gebruik. Hierdie toestel het 'n optimale prys/gehalte-verhouding, wat jou toelaat om intekenare teen 'n spoed van 10 Gbit/s te koppel, en teen 'n spoed van 40–100 Gbit/s aan die ruggraat te koppel, afhangend van die transceivers wat gebruik word.
Huawei CE6870 skakelaars
Huawei CE8850-skakelaars is as kernskakelaars gebruik. Die doel is om verkeer vinnig en betroubaar oor te dra. Geen toestelle is aan hulle gekoppel nie, behalwe verspreidingskakelaars, hulle weet niks van VXLAN nie, daarom is 'n model met 32 40/100 Gbps-poorte gekies, met 'n basiese lisensie wat L3-roetering en ondersteuning bied vir die IS-IS en MP-BGP protokolle.
Die onderste een is die Huawei CE8850 kernskakelaar
Op die ontwerpstadium het 'n bespreking binne die span uitgebreek oor tegnologieë wat gebruik kan word om 'n foutverdraagsame verbinding met kernnetwerknodusse te implementeer. Ons Moskou-kantoor is in drie geboue geleë, ons het 7 verspreidingskamers, in elkeen waarvan twee Huawei CE6870-verspreidingskakelaars geïnstalleer is (slegs toegangskakelaars is in verskeie verspreidingskamers geïnstalleer). By die ontwikkeling van die netwerkkonsep is twee oortolligheidsopsies oorweeg:
- Konsolidasie van verspreiding skakel in 'n foutverdraagsame stapel in elke kruisverbindingskamer. Voordele: eenvoud en gemak van opstelling. Nadele: daar is 'n groter waarskynlikheid van mislukking van die hele stapel wanneer foute voorkom in die firmware van netwerktoestelle ("geheuelekkasies" en dies meer).
- Pas M-LAG- en Anycast-poorttegnologieë toe om toestelle aan verspreidingskakelaars te koppel.
Uiteindelik het ons op die tweede opsie besluit. Dit is ietwat moeiliker om te konfigureer, maar het in die praktyk sy werkverrigting en hoë betroubaarheid getoon.
Kom ons oorweeg eers om eindtoestelle aan verspreidingskakelaars te koppel:
Kwaad
'n Toegangskakelaar, bediener of enige ander toestel wat 'n foutverdraagsame verbinding vereis, is by twee verspreidingskakelaars ingesluit. M-LAG-tegnologie verskaf oortolligheid op die dataskakelvlak. Daar word aanvaar dat twee verspreidingskakelaars na die gekoppelde toerusting as een toestel verskyn. Oortolligheid en lasbalansering word uitgevoer met behulp van die LACP-protokol.
Anycast gateway-tegnologie verskaf oortolligheid op netwerkvlak. 'n Redelike groot aantal VRF's is op elk van die verspreidingskakelaars gekonfigureer (elke VRF is vir sy eie doeleindes bedoel - afsonderlik vir "gewone" gebruikers, afsonderlik vir telefonie, afsonderlik vir verskeie toets- en ontwikkelingsomgewings, ens.), en in elkeen VRF het verskeie VLAN's opgestel. In ons netwerk is verspreidingskakelaars die verstekpoorte vir alle toestelle wat daaraan gekoppel is. Die IP-adresse wat ooreenstem met die VLAN-koppelvlakke is dieselfde vir beide verspreidingskakelaars. Verkeer word deur die naaste skakelaar gelei.
Kom ons kyk nou na die koppeling van verspreidingskakelaars aan die kern:
Foutverdraagsaamheid word op netwerkvlak verskaf deur die IS-IS-protokol te gebruik. Neem asseblief kennis dat 'n aparte L3-kommunikasielyn tussen die skakelaars voorsien word, teen 'n spoed van 100G. Fisies is hierdie kommunikasielyn 'n Direct Access-kabel dit kan aan die regterkant in die foto van Huawei CE6870-skakelaars gesien word.
'n Alternatief sou wees om 'n "eerlike" volledig gekoppelde dubbelstertopologie te organiseer, maar, soos hierbo genoem, het ons 7 kruisverbindingskamers in drie geboue. Gevolglik, as ons die "dubbelster"-topologie gekies het, sou ons presies twee keer soveel "langafstand" 40G-ontvangers nodig gehad het. Die besparings hier is baie aansienlik.
'n Paar woorde moet gesê word oor hoe VXLAN- en Anycast-gateway-tegnologieë saamwerk. VXLAN, sonder om in besonderhede in te gaan, is 'n tonnel vir die vervoer van Ethernet-rame binne UDP-pakkies. Die teruglus-koppelvlakke van verspreidingskakelaars word as die bestemmings-IP-adres van die VXLAN-tonnel gebruik. Elke kruisverbinding het twee skakelaars met dieselfde teruglus-koppelvlakadresse, so 'n pakkie kan by enige van hulle aankom, en 'n Ethernet-raam kan daaruit onttrek word.
As die skakelaar weet van die bestemming MAC-adres van die opgespoorde raam, sal die raam korrek by sy bestemming afgelewer word. Om te verseker dat beide verspreidingskakelaars wat in dieselfde kruisverbinding geïnstalleer is, bygewerkte inligting het oor alle MAC-adresse wat vanaf die toegangskakelaars "aankom", is die M-LAG-meganisme verantwoordelik vir die sinchronisering van die MAC-adrestabelle (asook ARP) tabelle) op beide skakelaars M-LAG pare.
Verkeersbalansering word bereik as gevolg van die teenwoordigheid in die onderlaagnetwerk van verskeie roetes na die teruglus-koppelvlakke van verspreidingskakelaars.
In plaas daarvan om 'n gevolgtrekking
Soos hierbo genoem, het die netwerk tydens toetsing en werking hoë betroubaarheid getoon (hersteltyd vir tipiese foute is nie meer as honderde millisekondes nie) en goeie werkverrigting - elke kruisverbinding is met twee 40 Gbit/s-kanale aan die kern gekoppel. Toegangskakelaars in ons netwerk word gestapel en gekoppel aan verspreidingskakelaars via LACP/M-LAG met twee 10 Gbit/s-kanale. 'n Stapel bevat gewoonlik 5 skakelaars met 48 poorte elk, en tot 10 toegangstapels is gekoppel aan die verspreiding in elke kruisverbinding. Die ruggraat verskaf dus ongeveer 30 Mbit/s per gebruiker selfs by die maksimum teoretiese las, wat ten tyde van die skryf daarvan voldoende is vir al ons praktiese toepassings.
Die netwerk laat jou toe om die paring van enige arbitrêre gekoppelde toestelle deur beide L2 en L3 naatloos te organiseer, wat volledige isolasie van verkeer (waarvan die inligtingsekuriteitsdiens hou) en foutdomeine (waarvan die bedryfspan hou) bied.
In die volgende deel sal ons jou vertel hoe ons na die nuwe netwerk gemigreer het. Bly ingeskakel!
Maxim Klochkov
Senior konsultant, netwerkoudit en komplekse projektegroep
Netwerkoplossingsentrum
"Jet Infosystems"
Bron: will.com