Vandaag vertel ik je hoe het idee om een nieuw intern netwerk voor ons bedrijf te creëren ontstond en werd geïmplementeerd. Het standpunt van het management is dat je voor jezelf hetzelfde volwaardige project moet doen als voor de klant. Als we het zelf goed doen, kunnen we de klant uitnodigen en laten zien hoe goed wat we hem aanbieden werkt en werkt. Daarom hebben we de ontwikkeling van het concept van een nieuw netwerk voor het kantoor in Moskou zeer grondig benaderd, waarbij we de volledige productiecyclus gebruikten: analyse van de afdelingsbehoeften → selectie van een technische oplossing → ontwerp → implementatie → testen. Dus laten we beginnen.
Een technische oplossing selecteren: Mutant Sanctuary
De procedure voor het werken aan een complex geautomatiseerd systeem kan momenteel het beste worden beschreven in GOST 34.601-90 “Geautomatiseerde systemen. Fasen van de Schepping”, dus werkten we daarnaar. En al in de stadia van eisenvorming en conceptontwikkeling kwamen we de eerste moeilijkheden tegen. Organisaties met verschillende profielen - banken, verzekeringsmaatschappijen, softwareontwikkelaars, enz. - hebben voor hun taken en standaarden bepaalde soorten netwerken nodig, waarvan de details duidelijk en gestandaardiseerd zijn. Bij ons zal dit echter niet lukken.
Waarom?
Jet Infosystems is een groot gediversifieerd IT-bedrijf. Tegelijkertijd is onze interne supportafdeling klein (maar trots), zij zorgt voor de functionaliteit van basisdiensten en systemen. Het bedrijf bevat veel divisies die verschillende functies vervullen: dit zijn verschillende krachtige outsourcingteams en interne ontwikkelaars van bedrijfssystemen en informatiebeveiliging, en architecten van computersystemen - in het algemeen, wie het ook is. Dienovereenkomstig zijn hun taken, systemen en beveiligingsbeleid ook verschillend. Dat zorgde, zoals verwacht, voor problemen in het proces van behoeftenanalyse en standaardisatie.
Hier bevindt zich bijvoorbeeld de ontwikkelafdeling: haar medewerkers schrijven en testen code voor een groot aantal klanten. Vaak is er behoefte om snel testomgevingen in te richten, en eerlijk gezegd is het niet altijd mogelijk om per project eisen te formuleren, middelen aan te vragen en een aparte testomgeving te bouwen conform alle interne regelgeving. Dit levert merkwaardige situaties op: op een dag keek je nederige bediende de ontwikkelaarsruimte binnen en vond onder de tafel een goed werkend Hadoop-cluster van twintig desktops, dat op onverklaarbare wijze was verbonden met een gemeenschappelijk netwerk. Ik denk niet dat het de moeite waard is om te verduidelijken dat de IT-afdeling van het bedrijf niet van het bestaan ervan op de hoogte was. Deze omstandigheid was, net als vele andere, verantwoordelijk voor het feit dat tijdens de ontwikkeling van het project de term 'mutantreserve' werd geboren, die de toestand van de lang lijdende kantoorinfrastructuur beschrijft.
Of hier is nog een voorbeeld. Periodiek wordt binnen een afdeling een proefbank ingericht. Dit was het geval bij Jira en Confluence, die bij sommige projecten in beperkte mate door het Software Development Center werden gebruikt. Na enige tijd leerden andere afdelingen over deze nuttige bronnen, evalueerden ze, en eind 2018 gingen Jira en Confluence over van de status van ‘speelgoed voor lokale programmeurs’ naar de status van ‘bedrijfsmiddelen’. Nu moet er een eigenaar aan deze systemen worden toegewezen, moeten SLA's, toegangs-/informatiebeveiligingsbeleid, back-upbeleid, monitoring en regels voor het routeren van verzoeken om problemen op te lossen worden gedefinieerd - in het algemeen moeten alle kenmerken van een volwaardig informatiesysteem aanwezig zijn .
Elk van onze divisies is ook een incubator die zijn eigen producten teelt. Sommigen van hen sterven in de ontwikkelingsfase, sommige gebruiken we tijdens het werken aan projecten, terwijl andere wortel schieten en gerepliceerde oplossingen worden die we zelf gaan gebruiken en aan klanten verkopen. Voor elk dergelijk systeem is het wenselijk om een eigen netwerkomgeving te hebben, waar het zich zal ontwikkelen zonder andere systemen te verstoren, en op een gegeven moment kan worden geïntegreerd in de infrastructuur van het bedrijf.
Naast ontwikkeling hebben we een zeer grote met ruim 500 medewerkers, voor elke klant in teams gevormd. Ze zijn betrokken bij het onderhouden van netwerken en andere systemen, het op afstand monitoren, het oplossen van claims, enzovoort. Dat wil zeggen dat de infrastructuur van de SC in feite de infrastructuur is van de klant met wie ze momenteel werken. Het bijzondere van het werken met dit deel van het netwerk is dat hun werkstations voor ons bedrijf deels extern en deels intern zijn. Daarom hebben we voor de SC de volgende aanpak geïmplementeerd: het bedrijf voorziet de overeenkomstige afdeling van netwerk- en andere bronnen, waarbij de werkstations van deze afdelingen worden beschouwd als externe verbindingen (naar analogie met filialen en externe gebruikers).
Snelwegontwerp: wij zijn de exploitant (verrassing)
Nadat we alle valkuilen hadden beoordeeld, realiseerden we ons dat we het netwerk van een telecommunicatie-operator binnen één kantoor kregen, en we begonnen dienovereenkomstig te handelen.
We creëerden een kernnetwerk waarmee iedere interne, en in de toekomst ook externe, consument wordt voorzien van de benodigde service: L2 VPN, L3 VPN of reguliere L3 routing. Sommige afdelingen hebben veilige internettoegang nodig, terwijl andere schone toegang nodig hebben zonder firewalls, maar tegelijkertijd onze bedrijfsbronnen en het kernnetwerk moeten beschermen tegen hun verkeer.
Met iedere divisie hebben we informeel ‘een SLA afgesloten’. In overeenstemming hiermee moeten alle incidenten die zich voordoen binnen een bepaalde, vooraf afgesproken periode worden geëlimineerd. De eisen die het bedrijf aan zijn netwerk stelde, waren streng. De maximale responstijd bij een incident bij telefoon- en e-mailstoringen bedroeg 5 minuten. De tijd om de netwerkfunctionaliteit te herstellen tijdens typische storingen bedraagt niet meer dan een minuut.
Omdat wij over een carrier-grade netwerk beschikken, kunt u hier alleen verbinding mee maken als u zich strikt aan de regels houdt. Service-eenheden bepalen het beleid en leveren diensten. Ze hebben niet eens informatie nodig over de verbindingen van specifieke servers, virtuele machines en werkstations. Maar tegelijkertijd zijn er beschermingsmechanismen nodig, omdat geen enkele verbinding het netwerk mag uitschakelen. Als er per ongeluk een lus ontstaat, mogen andere gebruikers dit niet merken, dat wil zeggen dat een adequate reactie van het netwerk noodzakelijk is. Elke telecomoperator lost voortdurend soortgelijke ogenschijnlijk complexe problemen op binnen zijn kernnetwerk. Het biedt service aan veel klanten met verschillende behoeften en verkeer. Tegelijkertijd mogen verschillende abonnees geen hinder ondervinden van het verkeer van anderen.
Thuis hebben we dit probleem op de volgende manier opgelost: we hebben een backbone L3-netwerk gebouwd met volledige redundantie, gebruikmakend van het IS-IS-protocol. Op basis van technologie werd bovenop de kern een overlay-netwerk gebouwd /, met behulp van een routeringsprotocol . Om de convergentie van routeringsprotocollen te versnellen, werd BFD-technologie gebruikt.
Netwerk structuur
In tests bleek dit schema uitstekend te zijn: wanneer een kanaal of schakelaar wordt losgekoppeld, is de convergentietijd niet meer dan 0.1-0.2 s, gaat een minimum aan pakketten verloren (vaak geen), worden TCP-sessies niet gescheurd, telefoongesprekken worden niet onderbroken.
Onderlaag - Routering
Overlaylaag - Routering
Huawei CE6870-switches met VXLAN-licenties werden gebruikt als distributieswitches. Dit apparaat heeft een optimale prijs-kwaliteitverhouding, waardoor u abonnees kunt aansluiten met een snelheid van 10 Gbit/s en verbinding kunt maken met de backbone met snelheden van 40-100 Gbit/s, afhankelijk van de gebruikte transceivers.
Huawei CE6870-schakelaars
Huawei CE8850-schakelaars werden gebruikt als kernschakelaars. Het doel is om verkeer snel en betrouwbaar te verzenden. Er zijn geen apparaten op aangesloten behalve distributieschakelaars, ze weten niets van VXLAN, dus werd gekozen voor een model met 32 40/100 Gbps-poorten, met een basislicentie die L3-routering en ondersteuning biedt voor de IS-IS en MP-BGP protocollen.
De onderste is de Huawei CE8850-kernschakelaar
In de ontwerpfase brak binnen het team een discussie uit over technologieën die gebruikt konden worden om een fouttolerante verbinding met kernnetwerkknooppunten te implementeren. Ons kantoor in Moskou is gevestigd in drie gebouwen, we hebben 7 distributieruimtes, in elk waarvan twee Huawei CE6870 distributieschakelaars zijn geïnstalleerd (in verschillende distributieruimtes zijn alleen toegangsschakelaars geïnstalleerd). Bij de ontwikkeling van het netwerkconcept zijn twee redundantieopties overwogen:
- Consolidatie van distributieschakelaars in een fouttolerante stapel in elke cross-connectieruimte. Voordelen: eenvoud en installatiegemak. Nadelen: er is een grotere kans op uitval van de gehele stack wanneer er fouten optreden in de firmware van netwerkapparaten (“geheugenlekken” en dergelijke).
- Pas M-LAG- en Anycast-gatewaytechnologieën toe om apparaten met distributieschakelaars te verbinden.
Uiteindelijk zijn we voor de tweede optie gegaan. Het is iets moeilijker te configureren, maar heeft in de praktijk zijn prestaties en hoge betrouwbaarheid bewezen.
Laten we eerst overwegen om eindapparaten aan te sluiten op distributieschakelaars:
Kruis
Een toegangsschakelaar, server of ander apparaat dat een fouttolerante verbinding vereist, is opgenomen in twee distributieschakelaars. M-LAG-technologie biedt redundantie op datalinkniveau. Er wordt aangenomen dat twee verdeelschakelaars voor de aangesloten apparatuur als één apparaat verschijnen. Redundantie en taakverdeling worden uitgevoerd met behulp van het LACP-protocol.
Anycast-gatewaytechnologie biedt redundantie op netwerkniveau. Op elk van de distributieschakelaars is een vrij groot aantal VRF's geconfigureerd (elke VRF is bedoeld voor zijn eigen doeleinden - afzonderlijk voor "gewone" gebruikers, afzonderlijk voor telefonie, afzonderlijk voor verschillende test- en ontwikkelomgevingen, enz.), en in elke VRF heeft verschillende VLAN's geconfigureerd. In ons netwerk zijn distributieschakelaars de standaardgateways voor alle apparaten die erop zijn aangesloten. De IP-adressen die overeenkomen met de VLAN-interfaces zijn voor beide distributieschakelaars hetzelfde. Het verkeer wordt via het dichtstbijzijnde wissel geleid.
Laten we nu eens kijken naar het verbinden van distributieschakelaars met de kernel:
Fouttolerantie wordt op netwerkniveau geboden met behulp van het IS-IS-protocol. Houd er rekening mee dat er tussen de schakelaars een aparte L3-communicatielijn is voorzien, met een snelheid van 100G. Fysiek is deze communicatielijn een Direct Access-kabel; deze is rechts te zien op de foto van Huawei CE6870-switches.
Een alternatief zou zijn om een “eerlijke” volledig verbonden dubbelstertopologie te organiseren, maar zoals hierboven vermeld hebben we zeven onderling verbonden kamers in drie gebouwen. Als we dus voor de ‘dubbele ster’-topologie hadden gekozen, zouden we precies twee keer zoveel ‘langeafstands’ 7G-transceivers nodig hebben gehad. De besparingen zijn hier zeer aanzienlijk.
Er moeten een paar woorden worden gezegd over hoe VXLAN- en Anycast-gatewaytechnologieën samenwerken. VXLAN is, zonder in details te treden, een tunnel voor het transporteren van Ethernet-frames binnen UDP-pakketten. De loopback-interfaces van distributieschakelaars worden gebruikt als het bestemmings-IP-adres van de VXLAN-tunnel. Elke crossover heeft twee switches met dezelfde loopback-interfaceadressen, zodat een pakket bij elk van deze switches kan aankomen en er een Ethernet-frame uit kan worden gehaald.
Als de switch het bestemmings-MAC-adres van het opgehaalde frame kent, wordt het frame correct op de bestemming afgeleverd. Om ervoor te zorgen dat beide distributieschakelaars die in dezelfde cross-connect zijn geïnstalleerd, actuele informatie hebben over alle MAC-adressen die “binnenkomen” van de toegangsschakelaars, is het M-LAG-mechanisme verantwoordelijk voor het synchroniseren van de MAC-adrestabellen (evenals ARP tabellen) op beide schakelaars M-LAG-paren.
Verkeersbalancering wordt bereikt door de aanwezigheid in het onderliggende netwerk van verschillende routes naar de loopback-interfaces van distributieschakelaars.
In plaats Output
Zoals hierboven vermeld, vertoonde het netwerk tijdens het testen en gebruik een hoge betrouwbaarheid (hersteltijd voor typische storingen bedraagt niet meer dan honderden milliseconden) en goede prestaties - elke cross-connect is verbonden met de kern via twee 40 Gbit/s-kanalen. Toegangsschakelaars in ons netwerk zijn gestapeld en verbonden met distributieschakelaars via LACP/M-LAG met twee 10 Gbit/s-kanalen. Een stapel bevat gewoonlijk 5 switches met elk 48 poorten, en in elke cross-connect zijn maximaal 10 toegangsstacks verbonden met de distributie. De backbone levert dus zelfs bij de maximale theoretische belasting ongeveer 30 Mbit/s per gebruiker, wat op het moment van schrijven voldoende is voor al onze praktische toepassingen.
Met het netwerk kunt u naadloos de koppeling van willekeurig aangesloten apparaten via zowel L2 als L3 organiseren, waardoor volledige isolatie van verkeer (wat de informatiebeveiligingsdienst leuk vindt) en foutdomeinen (wat het operationele team leuk vindt) wordt geboden.
In het volgende deel vertellen we u hoe we naar het nieuwe netwerk zijn gemigreerd. Blijf kijken!
Maxim Klochkov
Senior consultant van de groep netwerkaudit en complexe projecten
Netwerkoplossingencentrum
"Jet-infosystemen"
Bron: www.habr.com