Idag ska jag berätta om hur idén att skapa ett nytt internt nätverk för vårt företag kom till och implementerades. Ledningens ståndpunkt är att du behöver göra samma fullfjädrade projekt för dig själv som för kunden. Om vi gör det bra för oss själva kan vi bjuda in kunden och visa hur bra det vi erbjuder honom fungerar och fungerar. Därför närmade vi oss utvecklingen av konceptet med ett nytt nätverk för Moskvakontoret mycket noggrant, med hjälp av hela produktionscykeln: analys av avdelningens behov → val av en teknisk lösning → design → implementering → testning. Så låt oss börja.
Välja en teknisk lösning: Mutant Sanctuary
Förfarandet för att arbeta på ett komplext automatiserat system beskrivs för närvarande bäst i GOST 34.601-90 "Automatiserade system. Stages of Creation”, så vi arbetade efter det. Och redan i stadierna av kravbildning och konceptutveckling stötte vi på de första svårigheterna. Organisationer med olika profiler - banker, försäkringsbolag, mjukvaruutvecklare etc. - för sina uppgifter och standarder behöver de vissa typer av nätverk, vars detaljer är tydliga och standardiserade. Detta kommer dock inte att fungera hos oss.
Varför?
Jet Infosystems är ett stort diversifierat IT-företag. Samtidigt är vår interna supportavdelning liten (men stolt), den säkerställer funktionaliteten hos bastjänster och system. Företaget innehåller många divisioner som utför olika funktioner: det är flera kraftfulla outsourcingteam, och interna utvecklare av affärssystem och informationssäkerhet, och arkitekter av datorsystem – i allmänhet, vem det än är. Följaktligen är deras uppgifter, system och säkerhetspolicyer också olika. Vilket som väntat skapade svårigheter i processen med behovsanalys och standardisering.
Här finns till exempel utvecklingsavdelningen: dess anställda skriver och testar kod för ett stort antal kunder. Ofta finns ett behov av att snabbt organisera testmiljöer och ärligt talat är det inte alltid möjligt att formulera krav för varje projekt, begära resurser och bygga en separat testmiljö i enlighet med alla interna regelverk. Detta ger upphov till nyfikna situationer: en dag tittade din ödmjuka tjänare in i utvecklarens rum och hittade under bordet ett väl fungerande Hadoop-kluster med 20 stationära datorer, som var oförklarligt kopplat till ett gemensamt nätverk. Jag tycker inte att det är värt att förtydliga att företagets IT-avdelning inte kände till dess existens. Denna omständighet, liksom många andra, var ansvarig för det faktum att under utvecklingen av projektet föddes termen "mutant reserv", som beskrev tillståndet för den lidande kontorsinfrastrukturen.
Eller här är ett annat exempel. Periodvis sätts en testbänk upp inom en avdelning. Detta var fallet med Jira och Confluence, som användes i begränsad omfattning av Software Development Center i vissa projekt. Efter en tid lärde sig andra avdelningar om dessa användbara resurser, utvärderade dem, och i slutet av 2018 flyttade Jira och Confluence från statusen "lokala programmerares leksak" till statusen "företagsresurser". Nu måste en ägare tilldelas dessa system, SLA, åtkomst-/informationssäkerhetspolicyer, säkerhetskopieringspolicyer, övervakning, regler för routingförfrågningar för att åtgärda problem måste definieras - i allmänhet måste alla attribut för ett fullfjädrat informationssystem finnas närvarande .
Var och en av våra divisioner är också en inkubator som odlar sina egna produkter. Vissa av dem dör i utvecklingsstadiet, vissa använder vi när vi jobbar med projekt, medan andra slår rot och blir replikerade lösningar som vi själva börjar använda och säljer till kunder. För varje sådant system är det önskvärt med en egen nätverksmiljö, där den kommer att utvecklas utan att störa andra system, och någon gång kan integreras i företagets infrastruktur.
Utöver utveckling har vi ett mycket stort med mer än 500 anställda, bildade i team för varje kund. De är involverade i att underhålla nätverk och andra system, fjärrövervakning, lösa anspråk och så vidare. Det vill säga, SC:s infrastruktur är i själva verket infrastrukturen för kunden som de för närvarande arbetar med. Det speciella med att arbeta med den här delen av nätverket är att deras arbetsstationer för vårt företag delvis är externa och delvis interna. Därför implementerade vi följande tillvägagångssätt för SC - företaget förser motsvarande avdelning med nätverk och andra resurser, och betraktar dessa avdelningars arbetsstationer som externa anslutningar (i analogi med filialer och fjärranvändare).
Motorvägsdesign: vi är operatören (överraskning)
Efter att ha bedömt alla fallgropar insåg vi att vi fick en teleoperatörs nätverk inom ett kontor, och vi började agera därefter.
Vi skapade ett kärnnät med hjälp av vilket alla interna, och i framtiden även externa, konsumenter förses med den tjänst som krävs: L2 VPN, L3 VPN eller vanlig L3-routing. Vissa avdelningar behöver säker internetåtkomst, medan andra behöver ren åtkomst utan brandväggar, men samtidigt skydda våra företagsresurser och kärnnätverk från deras trafik.
Vi har informellt "slutit en SLA" med varje division. I enlighet med den ska alla incidenter som uppstår elimineras inom en viss på förhand överenskommen tid. Företagets krav på sitt nätverk visade sig vara stränga. Den maximala svarstiden på en incident vid telefon- och e-postfel var 5 minuter. Tiden för att återställa nätverksfunktionalitet under typiska fel är inte mer än en minut.
Eftersom vi har ett nätverk av operatörsklass, kan du bara ansluta till det i strikt enlighet med reglerna. Serviceenheter anger policyer och tillhandahåller tjänster. De behöver inte ens information om anslutningarna till specifika servrar, virtuella maskiner och arbetsstationer. Men samtidigt behövs skyddsmekanismer, eftersom inte en enda anslutning ska inaktivera nätverket. Om en slinga skapas av misstag bör andra användare inte märka detta, det vill säga ett adekvat svar från nätverket är nödvändigt. Varje telekomoperatör löser ständigt liknande till synes komplexa problem inom sitt kärnnät. Det ger service till många kunder med olika behov och trafik. Samtidigt ska olika abonnenter inte uppleva olägenheter från andras trafik.
Hemma löste vi detta problem på följande sätt: vi byggde ett stamnät L3-nätverk med full redundans, med hjälp av IS-IS-protokollet. Ett överläggsnätverk byggdes ovanpå kärnan baserat på teknik /, med hjälp av ett routingprotokoll . För att påskynda konvergensen av routingprotokoll användes BFD-teknik.
Nätverksstruktur
I tester visade sig detta schema vara utmärkt - när någon kanal eller switch är frånkopplad är konvergenstiden inte mer än 0.1-0.2 s, ett minimum av paket går förlorade (ofta inga), TCP-sessioner slits inte, telefonsamtal inte avbryts.
Underlagslager - Fräsning
Överlagringsskikt - Routing
Huawei CE6870-switchar med VXLAN-licenser användes som distributionsswitchar. Den här enheten har ett optimalt pris/kvalitetsförhållande, vilket gör att du kan ansluta abonnenter med en hastighet av 10 Gbit/s och ansluta till stamnätet med hastigheter på 40–100 Gbit/s, beroende på vilka sändtagare som används.
Huawei CE6870 switchar
Huawei CE8850-switchar användes som kärnswitchar. Målet är att överföra trafik snabbt och tillförlitligt. Inga enheter är anslutna till dem förutom distributionsväxlar, de kan inget om VXLAN, så en modell med 32 40/100 Gbps-portar valdes, med en grundläggande licens som ger L3-routing och stöd för IS-IS och MP-BGP protokoll .
Den nedre är Huawei CE8850 kärnswitch
På designstadiet bröt en diskussion ut inom teamet om teknologier som skulle kunna användas för att implementera en feltolerant anslutning till kärnnätverksnoder. Vårt kontor i Moskva är beläget i tre byggnader, vi har 7 distributionsrum, i var och en av dem installerades två Huawei CE6870 distributionsväxlar (endast åtkomstbrytare installerades i flera distributionsrum). När nätverkskonceptet utvecklades övervägdes två redundansalternativ:
- Konsolidering av distributionsväxlar till en feltålig stapel i varje korskopplingsrum. Fördelar: enkelhet och enkel installation. Nackdelar: det finns en högre sannolikhet för fel på hela stacken när fel uppstår i firmware på nätverksenheter ("minnesläckor" och liknande).
- Använd M-LAG och Anycast gateway-tekniker för att ansluta enheter till distributionsväxlar.
Till slut bestämde vi oss för det andra alternativet. Det är något svårare att konfigurera, men har i praktiken visat sin prestanda och höga tillförlitlighet.
Låt oss först överväga att ansluta slutenheter till distributionsväxlar:
Korsa
En åtkomstswitch, server eller någon annan enhet som kräver en feltolerant anslutning ingår i två distributionsväxlar. M-LAG-teknik ger redundans på datalänksnivå. Det antas att två distributionsväxlar visas för den anslutna utrustningen som en enhet. Redundans och lastbalansering utförs med hjälp av LACP-protokollet.
Anycast gateway-teknik ger redundans på nätverksnivå. Ett ganska stort antal VRF:er är konfigurerade på var och en av distributionsväxlarna (varje VRF är avsedd för sina egna syften - separat för "vanliga" användare, separat för telefoni, separat för olika test- och utvecklingsmiljöer etc.), och i varje VRF har flera VLAN konfigurerade. I vårt nätverk är distributionsväxlar standardgateways för alla enheter som är anslutna till dem. IP-adresserna som motsvarar VLAN-gränssnitten är desamma för båda distributionsväxlarna. Trafiken leds genom närmaste växel.
Låt oss nu titta på att ansluta distributionsväxlar till kärnan:
Feltolerans tillhandahålls på nätverksnivå med hjälp av IS-IS-protokollet. Observera att det finns en separat L3-kommunikationslinje mellan switcharna, med en hastighet av 100G. Fysiskt sett är denna kommunikationslinje en direktåtkomstkabel, den kan ses till höger på bilden av Huawei CE6870-switchar.
Ett alternativ skulle vara att organisera en "ärlig" helt sammankopplad dubbelstjärnstopologi, men, som nämnts ovan, har vi 7 korsanslutna rum i tre byggnader. Följaktligen, om vi hade valt "dubbelstjärna"-topologin, skulle vi ha behövt exakt dubbelt så många "långdistans" 40G-sändtagare. Besparingarna här är mycket betydande.
Några ord måste sägas om hur VXLAN och Anycast gateway-teknologier fungerar tillsammans. VXLAN, utan att gå in på detaljer, är en tunnel för att transportera Ethernet-ramar inuti UDP-paket. Återkopplingsgränssnitten för distributionsväxlar används som destinations-IP-adress för VXLAN-tunneln. Varje korskoppling har två switchar med samma loopback-gränssnittsadresser, så ett paket kan anlända till vilken som helst av dem och en Ethernet-ram kan extraheras från den.
Om switchen känner till destinations-MAC-adressen för den hämtade ramen, kommer ramen att levereras korrekt till sin destination. För att säkerställa att båda distributionsväxlarna installerade i samma korskoppling har uppdaterad information om alla MAC-adresser som "kommer" från åtkomstswitcharna, är M-LAG-mekanismen ansvarig för att synkronisera MAC-adresstabellerna (liksom ARP) tabeller) på båda switcharnas M-LAG-par.
Trafikbalansering uppnås på grund av närvaron i underliggande nätverk av flera rutter till återkopplingsgränssnitten för distributionsväxlar.
I stället för en slutsats
Som nämnts ovan visade nätverket under testning och drift hög tillförlitlighet (återställningstiden för typiska fel är inte mer än hundratals millisekunder) och bra prestanda - varje korskoppling är ansluten till kärnan med två 40 Gbit/s-kanaler. Accessswitchar i vårt nätverk staplas och kopplas till distributionsväxlar via LACP/M-LAG med två 10 Gbit/s-kanaler. En stack innehåller vanligtvis 5 switchar med 48 portar vardera, och upp till 10 accessstackar är anslutna till distributionen i varje korskoppling. Således ger backbone cirka 30 Mbit/s per användare även vid maximal teoretisk belastning, vilket i skrivande stund räcker för alla våra praktiska tillämpningar.
Nätverket låter dig sömlöst organisera ihopparningen av godtyckligt anslutna enheter via både L2 och L3, vilket ger fullständig isolering av trafik (vilket informationssäkerhetstjänsten gillar) och feldomäner (vilket driftteamet gillar).
I nästa del kommer vi att berätta hur vi migrerade till det nya nätverket. Håll utkik!
Maxim Klochkov
Seniorkonsult i gruppen för nätverksrevision och komplexa projekt
Nätverkslösningscenter
"Jet Infosystems"
Källa: will.com