Hodiaŭ mi rakontos al vi pri kiel la ideo krei novan internan reton por nia kompanio aperis kaj estis efektivigita. La pozicio de administrado estas, ke vi devas fari la saman plenkreskan projekton por vi mem kiel por la kliento. Se ni faras ĝin bone por ni mem, ni povas inviti la klienton kaj montri kiom bone tio, kion ni proponas al li, funkcias kaj funkcias. Sekve, ni tre ĝisfunde alproksimiĝis al la disvolviĝo de la koncepto de nova reto por la Moskva oficejo, uzante la plenan produktan ciklon: analizo de fakaj bezonoj → elekto de teknika solvo → dezajno → efektivigo → testado. Do ni komencu.
Elektante Teknikan Solvon: Mutant Sanctuary
La proceduro por labori en kompleksa aŭtomatigita sistemo estas nuntempe plej bone priskribita en GOST 34.601-90 "Aŭtomatigitaj sistemoj. Etapoj de Kreado”, do ni laboris laŭ ĝi. Kaj jam en la stadioj de postformado kaj koncepto-disvolviĝo, ni renkontis la unuajn malfacilaĵojn. Organizoj de diversaj profiloj - bankoj, asekurentreprenoj, programistoj, ktp. - por siaj taskoj kaj normoj, ili bezonas iujn specojn de retoj, kies specifaĵoj estas klaraj kaj normigitaj. Tamen ĉi tio ne funkcios kun ni.
Kial?
Jet Infosystems estas granda diversigita IT-kompanio. Samtempe, nia interna subtena fako estas malgranda (sed fiera), ĝi certigas la funkciecon de bazaj servoj kaj sistemoj. La firmao enhavas multajn dividojn kiuj plenumas malsamajn funkciojn: ĉi tiuj estas pluraj potencaj subkontraktaj teamoj, kaj endomaj programistoj de komercaj sistemoj, kaj informa sekureco, kaj arkitektoj de komputikaj sistemoj - ĝenerale, kiu ajn ĝi estas. Sekve, iliaj taskoj, sistemoj kaj sekurecaj politikoj ankaŭ estas malsamaj. Kiu, kiel atendite, kreis malfacilaĵojn en la procezo de bezonanalizo kaj normigado.
Jen, ekzemple, la disvolva fako: ĝiaj dungitoj skribas kaj testas kodon por granda nombro da klientoj. Ofte necesas rapide organizi testajn mediojn, kaj sincere, ne ĉiam eblas formuli postulojn por ĉiu projekto, peti rimedojn kaj konstrui apartan testan medion konforme al ĉiuj internaj regularoj. Ĉi tio estigas kuriozajn situaciojn: unu tagon via humila servisto rigardis en la ĉambron de programistoj kaj trovis sub la tablo taŭge funkcianta Hadoop-grupo de 20 labortabloj, kiu estis neklarigeble konektita al komuna reto. Mi pensas, ke ne indas klarigi, ke la IT-sekcio de la kompanio ne sciis pri ĝia ekzisto. Ĉi tiu cirkonstanco, kiel multaj aliaj, respondecis pri la fakto, ke dum la disvolviĝo de la projekto naskiĝis la termino "mutaciulo-rezervo", priskribante la staton de la long-suferanta oficeja infrastrukturo.
Aŭ jen alia ekzemplo. Periode, testbenko estas starigita ene de fako. Tio estis la kazo kun Jira kaj Confluence, kiuj estis uzitaj laŭ limigita mezuro fare de la Programaro-Evoluo-Centro en kelkaj projektoj. Post iom da tempo, aliaj fakoj eksciis pri ĉi tiuj utilaj rimedoj, taksis ilin, kaj fine de 2018, Jira kaj Confluence transiris de la statuso de "ludilo de lokaj programistoj" al la statuso de "firmaaj rimedoj". Nun posedanto devas esti asignita al ĉi tiuj sistemoj, SLAoj, politikoj pri aliro/informsekureco, sekurecpolitikoj, monitorado, reguloj por direkti petojn por ripari problemojn devas esti difinitaj - ĝenerale, ĉiuj atributoj de plenrajta informsistemo devas esti ĉeestantaj. .
Ĉiu el niaj dividoj ankaŭ estas inkubatoro, kiu kultivas siajn proprajn produktojn. Iuj el ili mortas en la evolufazo, iujn ni uzas dum ili laboras pri projektoj, dum aliaj enradikiĝas kaj fariĝas reproduktitaj solvoj, kiujn ni mem komencas uzi kaj vendi al klientoj. Por ĉiu tia sistemo, estas dezirinde havi sian propran retan medion, kie ĝi disvolviĝos sen enmiksiĝi kun aliaj sistemoj, kaj iam povas esti integrita en la infrastrukturon de la kompanio.
Krom disvolviĝo, ni havas tre granda kun pli ol 500 dungitoj, formitaj en teamoj por ĉiu kliento. Ili okupiĝas pri konservado de retoj kaj aliaj sistemoj, fora monitorado, solvado de asertoj, ktp. Tio estas, la infrastrukturo de la SC estas, fakte, la infrastrukturo de la kliento kun kiu ili nuntempe laboras. La propreco labori kun ĉi tiu sekcio de la reto estas, ke iliaj laborstacioj por nia kompanio estas parte eksteraj, kaj parte internaj. Sekve, por la SC ni efektivigis la sekvan aliron - la firmao provizas la respondan fakon per reto kaj aliaj rimedoj, konsiderante la laborstaciojn de ĉi tiuj fakoj kiel eksterajn rilatojn (analogie kun branĉoj kaj foraj uzantoj).
Aŭtovoja dezajno: ni estas la funkciigisto (surprizo)
Post taksado de ĉiuj malfacilaĵoj, ni rimarkis, ke ni ricevas reton de telekomunikado ene de unu oficejo, kaj ni komencis agi laŭe.
Ni kreis kernan reton per kiu iu interna, kaj estonte ankaŭ ekstera, konsumanto estas provizita per la bezonata servo: L2 VPN, L3 VPN aŭ regula L3-vojigo. Iuj fakoj bezonas sekuran aliron al Interreto, dum aliaj bezonas puran aliron sen fajroŝirmiloj, sed samtempe protektante niajn kompaniajn rimedojn kaj kernan reton kontraŭ ilia trafiko.
Ni neformale "konkludis SLA" kun ĉiu divido. Konforme al ĝi, ĉiuj okazantaj okazaĵoj devas esti eliminitaj en certa, antaŭinterkonsentita tempodaŭro. La postuloj de la firmao por ĝia reto montriĝis striktaj. La maksimuma responda tempo al okazaĵo okaze de telefonaj kaj retpoŝtaj misfunkciadoj estis 5 minutoj. La tempo por restarigi retan funkciecon dum tipaj misfunkciadoj ne estas pli ol minuto.
Ĉar ni havas portantan-nivelan reton, vi povas konekti al ĝi nur strikte konforme al la reguloj. Servaj unuoj starigas politikojn kaj provizas servojn. Ili eĉ ne bezonas informojn pri la konektoj de specifaj serviloj, virtualaj maŝinoj kaj laborstacioj. Sed samtempe necesas protektaj mekanismoj, ĉar eĉ ne unu konekto devas malŝalti la reton. Se buklo estas hazarde kreita, aliaj uzantoj ne rimarku tion, tio estas, taŭga respondo de la reto estas necesa. Ajna teleentreprenisto konstante solvas similajn ŝajne kompleksajn problemojn ene de sia kerna reto. Ĝi provizas servon al multaj klientoj kun malsamaj bezonoj kaj trafiko. Samtempe, malsamaj abonantoj ne devus sperti ĝenon de la trafiko de aliaj.
Hejme, ni solvis ĉi tiun problemon jene: ni konstruis spinan reton L3 kun plena redundo, uzante la IS-IS-protokolon. Supermeta reto estis konstruita sur la kerno bazita sur teknologio /, uzante vojprotokolon . Por akceli la konverĝon de vojprotokoloj, BFD-teknologio estis uzita.
Reta strukturo
En provoj, ĉi tiu skemo montris sin bonega - kiam iu kanalo aŭ ŝaltilo estas malkonektita, la konverĝa tempo ne estas pli ol 0.1-0.2 s, minimumo da pakaĵoj estas perditaj (ofte neniu), TCP-sesioj ne estas disŝiritaj, telefonaj konversacioj. ne estas interrompitaj.
Subtavolo - Vojaĝado
Overlay Tavolo - Voting
Huawei CE6870-ŝaltiloj kun VXLAN-licencoj estis utiligitaj kiel distribuŝaltiloj. Ĉi tiu aparato havas optimuman prezon/kvalitan rilatumon, permesante al vi konekti abonantojn kun rapideco de 10 Gbit/s, kaj konekti al la spino je rapidoj de 40–100 Gbit/s, depende de la uzataj transriceviloj.
Huawei CE6870-ŝaltiloj
Huawei CE8850-ŝaltiloj estis utiligitaj kiel kernŝaltiloj. La celo estas transdoni trafikon rapide kaj fidinde. Neniuj aparatoj estas konektitaj al ili krom distribuŝaltiloj, ili scias nenion pri VXLAN, do estis elektita modelo kun 32 40/100 Gbps-havenoj, kun baza licenco, kiu provizas L3-vojigon kaj subtenon por la IS-IS kaj MP-BGP. protokoloj.
La malsupra estas la kernŝaltilo Huawei CE8850
En la dezajnostadio, diskuto eksplodis ene de la teamo pri teknologioj, kiuj povus esti uzataj por efektivigi mistoleran konekton al kernaj retaj nodoj. Nia Moskva oficejo situas en tri konstruaĵoj, ni havas 7 distribuĉambrojn, en ĉiu el kiuj estis instalitaj du distribuaj ŝaltiloj Huawei CE6870 (nur alirŝaltiloj estis instalitaj en pluraj distribuĉambroj). Dum evoluigado de la retokoncepto, du redundaj elektoj estis pripensitaj:
- Firmiĝo de distribuoŝanĝoj en mistolereman stakon en ĉiu kruckonektĉambro. Avantaĝoj: simpleco kaj facileco de aranĝo. Malavantaĝoj: ekzistas pli alta probablo de fiasko de la tuta stako kiam eraroj okazas en la firmvaro de retaj aparatoj ("memorfuĝoj" kaj similaj).
- Apliku M-LAG kaj Anycast-enirejteknologiojn por konekti aparatojn al distribuaj ŝaltiloj.
En la fino, ni decidis por la dua opcio. Ĝi estas iom pli malfacila agordi, sed montris praktike sian rendimenton kaj altan fidindecon.
Ni unue konsideru konekti finajn aparatojn al distribuaj ŝaltiloj:
Kruco
Alirŝaltilo, servilo, aŭ ajna alia aparato kiu postulas mistolereman konekton estas inkluzivita en du distribuŝaltiloj. M-LAG-teknologio disponigas redundon sur la datenlignivelo. Oni supozas, ke du distribuaj ŝaltiloj aperas al la ligita ekipaĵo kiel unu aparato. Redundo kaj ŝarĝbalancado estas aranĝitaj uzante la LACP-protokolon.
Anycast-enirejteknologio disponigas redundon ĉe la retonivelo. Sufiĉe granda nombro da VRF-oj estas agordita sur ĉiu el la distribuŝaltiloj (ĉiu VRF estas destinita por siaj propraj celoj - aparte por "regulaj" uzantoj, aparte por telefonio, aparte por diversaj testaj kaj evoluaj medioj, ktp.), kaj en ĉiu VRF havas plurajn VLANojn agordis. En nia reto, distribuaj ŝaltiloj estas la defaŭltaj enirejoj por ĉiuj aparatoj konektitaj al ili. La IP-adresoj respondaj al la VLAN-interfacoj estas la samaj por ambaŭ distribuaj ŝaltiloj. Trafiko estas direktita tra la plej proksima ŝaltilo.
Nun ni rigardu konekti distribuajn ŝaltilojn al la kerno:
Faŭltoleremo estas disponigita sur la retonivelo uzante la IS-IS-protokolon. Bonvolu noti, ke aparta komunika linio L3 estas disponigita inter la ŝaltiloj, kun rapideco de 100G. Fizike, ĉi tiu komunika linio estas kablo de Rekta Aliro, ĝi videblas dekstre en la foto de Huawei CE6870-ŝaltiloj.
Alternativo estus organizi "honestan" plene ligitan duoblan steltopologion, sed, kiel menciite supre, ni havas 7 kruckonektajn ĉambrojn en tri konstruaĵoj. Sekve, se ni elektus la topologion "duobla stelo", ni bezonus ekzakte duoble pli multajn "longdistancaj" 40G-ricevilojn. La ŝparaĵoj ĉi tie estas tre signifaj.
Kelkaj vortoj devas esti diritaj pri kiel VXLAN kaj Anycast-enirejteknologioj funkcias kune. VXLAN, sen eniri detalojn, estas tunelo por transporti Eterretajn kadrojn ene de UDP-pakaĵoj. La loopback interfacoj de distribuŝaltiloj estas utiligitaj kiel la celloka IP-adreso de la VXLAN-tunelo. Ĉiu interkruciĝo havas du ŝaltilojn kun la samaj loopback interfacadresoj, tiel ke pakaĵeto povas alveni ĉe iu el ili, kaj Ethernet-kadro povas esti eltirita de ĝi.
Se la ŝaltilo scias pri la celo MAC-adreso de la prenita kadro, la kadro estos ĝuste liverita al sia celloko. Por certigi, ke ambaŭ distribuoŝaltiloj instalitaj en la sama kruckonekto havas ĝisdatigitajn informojn pri ĉiuj MAC-adresoj "alvenantaj" de la alirŝaltiloj, la M-LAG-mekanismo respondecas pri sinkronigado de la MAC-adrestabeloj (same kiel ARP). tabloj) sur ambaŭ ŝaltiloj M-LAG-paroj.
Trafikbalancado estas atingita pro la ĉeesto en la submeta reto de pluraj itineroj al la loopback interfacoj de distribuŝaltiloj.
Anstataŭ konkludo
Kiel menciite supre, dum testado kaj funkciado la reto montris altan fidindecon (reakiro por tipaj misfunkciadoj ne estas pli ol centoj da milisekundoj) kaj bonan rendimenton - ĉiu kruckonekto estas konektita al la kerno per du 40 Gbit/s kanaloj. Alirŝaltiloj en nia reto estas stakigitaj kaj konektitaj al distribuaj ŝaltiloj per LACP/M-LAG kun du kanaloj de 10 Gbit/s. Stako kutime enhavas 5 ŝaltilojn kun 48 havenoj ĉiu, kaj ĝis 10 alirstakoj estas konektitaj al la distribuo en ĉiu kruckonekto. Tiel, la spino provizas ĉirkaŭ 30 Mbit/s por uzanto eĉ ĉe la maksimuma teoria ŝarĝo, kiu en la momento de la skribado sufiĉas por ĉiuj niaj praktikaj aplikoj.
La reto ebligas al vi perfekte organizi la parigon de ajnaj arbitraj konektitaj aparatoj per kaj L2 kaj L3, provizante kompletan izolitecon de trafiko (kiun la informa sekurecservo ŝatas) kaj misfunkciajn domajnojn (kiujn la operacia teamo ŝatas).
En la sekva parto ni rakontos al vi kiel ni migris al la nova reto. Restu agordita!
Maksim Kloĉkov
Ĉefkonsultisto de la reto-revizio kaj kompleksaj projektogrupo
Centro de Retaj Solvoj
"Jetaj Infosistemoj"
fonto: www.habr.com