Danas ću vam reći kako je nastala i implementirana ideja o stvaranju nove interne mreže za našu kompaniju. Stav menadžmenta je da morate da uradite isti kompletan projekat za sebe kao i za klijenta. Ako to radimo dobro za sebe, možemo pozvati kupca i pokazati koliko dobro funkcionira i funkcionira ono što mu nudimo. Stoga smo razvoju koncepta nove mreže za moskovsku kancelariju pristupili vrlo temeljito, koristeći cijeli proizvodni ciklus: analiza potreba odjela → odabir tehničkog rješenja → dizajn → implementacija → testiranje. Pa počnimo.
Odabir tehničkog rješenja: Utočište mutanta
Procedura za rad na složenom automatizovanom sistemu trenutno je najbolje opisana u GOST 34.601-90 „Automatizovani sistemi. Faze stvaranja”, pa smo i radili po tome. I već u fazama formiranja zahtjeva i razvoja koncepta naišli smo na prve poteškoće. Organizacije različitih profila - banke, osiguravajuća društva, programeri softvera itd. - za svoje zadatke i standarde trebaju određene vrste mreža čije su specifičnosti jasne i standardizovane. Međutim, kod nas to neće funkcionirati.
Zašto?
Jet Infosystems je velika raznolika IT kompanija. Istovremeno, naš interni odjel podrške je mali (ali ponosan), osigurava funkcionalnost osnovnih servisa i sistema. Kompanija sadrži mnoge divizije koje obavljaju različite funkcije: to je nekoliko moćnih outsourcing timova, i interni programeri poslovnih sistema, i informacione sigurnosti, i arhitekti računarskih sistema - općenito, ko god da je. U skladu s tim, njihovi zadaci, sistemi i sigurnosne politike su također različiti. Što je, očekivano, stvorilo poteškoće u procesu analize potreba i standardizacije.
Evo, na primjer, odjela za razvoj: njegovi zaposlenici pišu i testiraju kod za veliki broj kupaca. Često postoji potreba da se brzo organizuju testna okruženja, a iskreno rečeno, nije uvek moguće formulisati zahteve za svaki projekat, zatražiti resurse i izgraditi posebno testno okruženje u skladu sa svim internim propisima. Ovo dovodi do zanimljivih situacija: jednog dana vaš ponizni sluga je pogledao u sobu za programere i ispod stola pronašao ispravno funkcionalan Hadoop klaster od 20 desktopa, koji je neobjašnjivo bio povezan sa zajedničkom mrežom. Mislim da nije vrijedno pojašnjavati da IT odjel kompanije nije znao za njeno postojanje. Ova okolnost, kao i mnoge druge, bila je odgovorna za to što se tokom razvoja projekta rodio pojam „rezerva mutanta“, koji opisuje stanje napaćene kancelarijske infrastrukture.
Ili evo još jednog primjera. Periodično se u okviru odjeljenja uspostavlja ispitna stanica. To je bio slučaj sa Jira i Confluenceom, koje je Centar za razvoj softvera koristio u ograničenoj mjeri u nekim projektima. Nakon nekog vremena, druga odjeljenja su saznala za ove korisne resurse, procijenila ih i krajem 2018. godine Jira i Confluence prešli su sa statusa „igračke lokalnih programera“ u status „resursa kompanije“. Sada se ovim sistemima mora dodijeliti vlasnik, moraju se definirati SLA, politike sigurnosti pristupa/informacija, politike sigurnosnog kopiranja, nadzor, pravila za usmjeravanje zahtjeva za rješavanje problema - općenito, svi atributi punopravnog informacionog sistema moraju biti prisutni .
Svaki od naših odjela je i inkubator koji uzgaja vlastite proizvode. Neki od njih umiru u fazi razvoja, neke koristimo dok radimo na projektima, dok se drugi ukorijene i postanu replicirana rješenja koja sami počinjemo koristiti i prodavati klijentima. Za svaki takav sistem poželjno je imati svoje mrežno okruženje, u kojem će se razvijati bez ometanja drugih sistema, a u jednom trenutku može biti integrisano u infrastrukturu kompanije.
Pored razvoja, imamo veoma veliki sa više od 500 zaposlenih, formiranih u timove za svakog kupca. Oni su uključeni u održavanje mreža i drugih sistema, daljinsko praćenje, rješavanje zahtjeva itd. Odnosno, infrastruktura SC je, u stvari, infrastruktura korisnika sa kojim trenutno rade. Posebnost rada sa ovim dijelom mreže je da su njihove radne stanice za našu kompaniju dijelom eksterne, a dijelom interne. Stoga smo za SC implementirali sledeći pristup – kompanija obezbeđuje odgovarajućem odeljenju mrežne i druge resurse, smatrajući radne stanice ovih odeljenja kao eksterne veze (po analogiji sa filijalama i udaljenim korisnicima).
Projektovanje autoputa: mi smo operater (iznenađenje)
Nakon što smo procijenili sve zamke, shvatili smo da dobijamo mrežu telekomunikacionog operatera u okviru jedne kancelarije i počeli smo da se ponašamo u skladu sa tim.
Napravili smo jezgro mreže uz pomoć koje se svakom internom, a u budućnosti i eksternom potrošaču pruža potrebna usluga: L2 VPN, L3 VPN ili redovno L3 rutiranje. Nekim odjelima je potreban siguran pristup Internetu, dok je drugima potreban čist pristup bez zaštitnih zidova, ali istovremeno štiteći naše korporativne resurse i osnovnu mrežu od njihovog prometa.
Neformalno smo “zaključili SLA” sa svakom divizijom. U skladu sa njim, svi incidenti koji se pojave moraju biti otklonjeni u određenom, unapred dogovorenom roku. Ispostavilo se da su zahtjevi kompanije za svoju mrežu strogi. Maksimalno vrijeme odgovora na incident u slučaju kvara telefona i e-pošte bilo je 5 minuta. Vrijeme za vraćanje mrežne funkcionalnosti tokom tipičnih kvarova nije više od jedne minute.
Budući da imamo mrežu za operatere, na nju se možete povezati samo u skladu s pravilima. Servisne jedinice postavljaju politike i pružaju usluge. Ne trebaju im čak ni informacije o konekcijama određenih servera, virtuelnih mašina i radnih stanica. Ali u isto vrijeme, potrebni su mehanizmi zaštite, jer niti jedna veza ne bi trebala onemogućiti mrežu. Ako se petlja slučajno stvori, drugi korisnici to ne bi trebali primijetiti, odnosno neophodan je adekvatan odgovor mreže. Svaki telekom operater konstantno rješava slične naizgled složene probleme unutar svoje osnovne mreže. Pruža usluge mnogim klijentima sa različitim potrebama i prometom. Istovremeno, različiti pretplatnici ne bi trebali imati neugodnosti od prometa drugih.
Kod kuće smo ovaj problem riješili na sljedeći način: izgradili smo okosnu L3 mrežu sa punom redundantnošću, koristeći IS-IS protokol. Mreža preklapanja je izgrađena na vrhu jezgre zasnovana na tehnologiji /, koristeći protokol rutiranja . Da bi se ubrzala konvergencija protokola rutiranja, korištena je BFD tehnologija.
Struktura mreže
U testovima se ova šema pokazala odličnom - kada je bilo koji kanal ili prekidač isključen, vrijeme konvergencije nije više od 0.1-0.2 s, gubi se minimum paketa (često nijedan), TCP sesije se ne kidaju, telefonski razgovori nisu prekinuti.
Podložni sloj - Routing
Overlay Layer - Routing
Huawei CE6870 svičevi sa VXLAN licencama korišteni su kao distributivni prekidači. Ovaj uređaj ima optimalan odnos cene i kvaliteta, omogućavajući vam da povežete pretplatnike brzinom od 10 Gbit/s, i povežete se na okosnicu brzinom od 40–100 Gbit/s, u zavisnosti od primopredajnika koji se koriste.
Huawei CE6870 prekidači
Huawei CE8850 prekidači su korišteni kao prekidači za jezgro. Cilj je brzo i pouzdano prenijeti promet. Na njih nisu priključeni uređaji osim distributivnih prekidača, ne znaju ništa o VXLAN-u, pa je odabran model sa 32 40/100 Gbps porta, sa osnovnom licencom koja obezbjeđuje L3 rutiranje i podršku za IS-IS i MP-BGP protokoli .
Donji je Huawei CE8850 prekidač jezgre
U fazi dizajna, unutar tima je izbila diskusija o tehnologijama koje bi se mogle koristiti za implementaciju veze otporne na greške na čvorove jezgre mreže. Naša moskovska kancelarija se nalazi u tri zgrade, imamo 7 distributivnih prostorija, od kojih su u svakoj postavljena dva Huawei CE6870 razvodna prekidača (samo pristupni prekidači su instalirani u nekoliko distributivnih prostorija). Prilikom razvoja koncepta mreže razmatrane su dvije opcije redundantnosti:
- Konsolidacija distributivnih prekidača u stek otporan na greške u svakoj prostoriji za unakrsno povezivanje. Prednosti: jednostavnost i lakoća podešavanja. Nedostaci: veća je vjerovatnoća kvara cijelog steka kada se pojave greške u firmveru mrežnih uređaja („memory leaks“ i sl.).
- Primijenite M-LAG i Anycast gateway tehnologije za povezivanje uređaja sa distributivnim prekidačima.
Na kraju smo se odlučili na drugu opciju. Nešto ga je teže konfigurirati, ali je u praksi pokazao svoje performanse i visoku pouzdanost.
Razmotrimo prvo povezivanje krajnjih uređaja sa distributivnim prekidačima:
Cross
Pristupni prekidač, server ili bilo koji drugi uređaj koji zahtijeva vezu otpornu na greške uključeni su u dva distribucijska prekidača. M-LAG tehnologija obezbeđuje redundantnost na nivou veze podataka. Pretpostavlja se da se dva distributivna prekidača pojavljuju na priključenoj opremi kao jedan uređaj. Redundancija i balansiranje opterećenja se izvode pomoću LACP protokola.
Anycast gateway tehnologija pruža redundantnost na nivou mreže. Prilično veliki broj VRF-ova je konfigurisan na svakom od distributivnih prekidača (svaki VRF je namenjen za svoje potrebe - posebno za "obične" korisnike, posebno za telefoniju, posebno za različita testna i razvojna okruženja, itd.), i u svakom VRF ima nekoliko konfiguriranih VLAN-ova. U našoj mreži, distributivni prekidači su podrazumevani gateway za sve uređaje koji su na njih povezani. IP adrese koje odgovaraju VLAN interfejsima su iste za oba distribuciona prekidača. Saobraćaj se odvija preko najbliže skretnice.
Sada pogledajmo povezivanje prekidača distribucije na kernel:
Tolerancija grešaka je obezbeđena na nivou mreže korišćenjem IS-IS protokola. Imajte na umu da je odvojena L3 komunikaciona linija između prekidača, pri brzini od 100G. Fizički, ova komunikaciona linija je kabl za direktni pristup može se videti na desnoj strani na fotografiji Huawei CE6870 prekidača.
Alternativa bi bila organiziranje “poštene” potpuno povezane topologije dvostruke zvijezde, ali, kao što je gore spomenuto, imamo 7 unakrsnih soba u tri zgrade. U skladu s tim, da smo odabrali topologiju “dvostruke zvijezde”, bilo bi nam potrebno točno dvostruko više “dugometnih” 40G primopredajnika. Uštede su ovde veoma značajne.
Treba reći nekoliko riječi o tome kako VXLAN i Anycast gateway tehnologije rade zajedno. VXLAN, bez ulaženja u detalje, je tunel za transport Ethernet okvira unutar UDP paketa. Interfejsi loopback distribucijskih prekidača se koriste kao odredišna IP adresa VXLAN tunela. Svaka unakrsna veza ima dva prekidača sa istim adresama loopback interfejsa, tako da paket može stići na bilo koji od njih, a iz njega se može izdvojiti Ethernet okvir.
Ako komutator zna za odredišnu MAC adresu preuzetog okvira, okvir će biti ispravno dostavljen na svoje odredište. Kako bi se osiguralo da oba distributivna prekidača instalirana u istoj unakrsnoj vezi imaju ažurne informacije o svim MAC adresama koje "stižu" sa pristupnih prekidača, M-LAG mehanizam je odgovoran za sinhronizaciju tablica MAC adresa (kao i ARP tablice) na oba prekidača M-LAG para.
Balansiranje saobraćaja se postiže zbog prisustva u osnovnoj mreži nekoliko ruta do sučelja loopback distributivnih prekidača.
Umjesto zaključka
Kao što je već spomenuto, tokom testiranja i rada mreža je pokazala visoku pouzdanost (vrijeme oporavka kod tipičnih kvarova nije više od stotina milisekundi) i dobre performanse - svaka unakrsna veza je povezana sa jezgrom preko dva kanala od 40 Gbit/s. Pristupni prekidači u našoj mreži su složeni i povezani sa distributivnim prekidačima preko LACP/M-LAG sa dva kanala od 10 Gbit/s. Stack obično sadrži 5 prekidača sa po 48 portova, a do 10 pristupnih stekova je povezano na distribuciju u svakoj unakrsnoj vezi. Dakle, okosnica pruža oko 30 Mbit/s po korisniku čak i pri maksimalnom teoretskom opterećenju, što je u trenutku pisanja dovoljno za sve naše praktične primjene.
Mreža vam omogućava da neprimetno organizujete uparivanje bilo kojeg proizvoljnog povezanog uređaja i preko L2 i L3, obezbeđujući potpunu izolaciju saobraćaja (što voli služba za bezbednost informacija) i domena grešaka (što voli operativni tim).
U sljedećem dijelu ćemo vam reći kako smo migrirali na novu mrežu. Stay tuned!
Maxim Klochkov
Viši konsultant, Grupa za reviziju mreže i složene projekte
Centar za mrežna rješenja
"Jet Infosystems"
izvor: www.habr.com