Tänään kerron, kuinka ajatus uuden sisäisen verkoston luomisesta yrityksellemme syntyi ja toteutui. Johdon kanta on, että sinun tulee tehdä sama täysi projekti itsellesi kuin asiakkaalle. Jos teemme sen itsellemme hyvin, voimme kutsua asiakkaan ja näyttää kuinka hyvin se mitä tarjoamme hänelle toimii ja toimii. Siksi lähestyimme Moskovan toimiston uuden verkon konseptin kehittämistä erittäin perusteellisesti ja koko tuotantosykliä hyödyntäen: osaston tarpeiden analysointi → teknisen ratkaisun valinta → suunnittelu → toteutus → testaus. Joten aloitetaan.
Teknisen ratkaisun valitseminen: Mutant Sanctuary
Monimutkaisen automatisoidun järjestelmän työskentelymenettely kuvataan tällä hetkellä parhaiten GOST 34.601-90 "Automaattiset järjestelmät. Stages of Creation”, joten työskentelimme sen mukaan. Ja jo vaatimusten muodostuksen ja konseptien kehittämisen vaiheissa kohtasimme ensimmäiset vaikeudet. Eriprofiiliset organisaatiot - pankit, vakuutusyhtiöt, ohjelmistokehittäjät jne. - tarvitsevat tehtäviään ja standardejaan varten tietyntyyppisiä verkkoja, joiden erityispiirteet ovat selkeät ja standardoituja. Tämä ei kuitenkaan toimi meillä.
Miksi?
Jet Infosystems on suuri monipuolinen IT-yritys. Samalla sisäinen tukiosastomme on pieni (mutta ylpeä), se varmistaa peruspalvelujen ja -järjestelmien toimivuuden. Yrityksessä on monia eri tehtäviä suorittavia divisioonaa: nämä ovat useita tehokkaita ulkoistustiimejä ja sisäisiä yritysjärjestelmien ja tietoturvan kehittäjiä ja laskentajärjestelmien arkkitehteja - yleensä, kuka tahansa. Vastaavasti niiden tehtävät, järjestelmät ja turvallisuuspolitiikka ovat myös erilaisia. Mikä odotetusti aiheutti vaikeuksia tarveanalyysi- ja standardointiprosessissa.
Tässä on esimerkiksi kehitysosasto: sen työntekijät kirjoittavat ja testaavat koodia suurelle määrälle asiakkaita. Usein testiympäristöt on järjestettävä nopeasti, eikä rehellisesti sanottuna aina ole mahdollista muotoilla jokaiselle projektille vaatimuksia, pyytää resursseja ja rakentaa erillistä testiympäristöä kaikkien sisäisten määräysten mukaisesti. Tästä syntyy outoja tilanteita: eräänä päivänä nöyrä palvelijasi katsoi kehittäjien huoneeseen ja löysi pöydän alta kunnolla toimivan 20 pöytäkoneen Hadoop-klusterin, joka oli selittämättömällä tavalla yhdistetty yhteiseen verkkoon. Mielestäni ei ole syytä selventää, ettei yrityksen IT-osasto tiennyt sen olemassaolosta. Tämä seikka, kuten monet muut, oli vastuussa siitä, että projektin kehittämisen aikana syntyi termi "mutanttireservi", joka kuvaa pitkään kärsineen toimistoinfrastruktuurin tilaa.
Tai tässä toinen esimerkki. Ajoittain osastolle perustetaan testipenkki. Näin tapahtui Jiran ja Confluencen kohdalla, joita Software Development Center käytti rajoitetusti joissakin projekteissa. Jonkin ajan kuluttua muut osastot oppivat näistä hyödyllisistä resursseista, arvioivat ne, ja vuoden 2018 lopussa Jira ja Confluence siirtyivät "paikallisten ohjelmoijien lelujen" tilasta "yrityksen resurssien" tilaan. Nyt näille järjestelmille on määritettävä omistaja, SLA:t, pääsy/tietoturvakäytännöt, varmuuskopiointikäytännöt, valvonta, säännöt reitityspyyntöille ongelmien korjaamiseksi on määriteltävä - yleensä kaikkien täysimittaisen tietojärjestelmän attribuuttien on oltava olemassa. .
Jokainen toimialamme on myös hautomo, joka kasvattaa omia tuotteitaan. Osa niistä kuolee kehitysvaiheessa, osa käytämme projektityöskentelyn aikana, kun taas toiset juurtuvat ja niistä tulee kopioituja ratkaisuja, joita alamme käyttää itse ja myydä asiakkaille. Jokaiselle tällaiselle järjestelmälle on toivottavaa olla oma verkkoympäristö, jossa se kehittyy häiritsemättä muita järjestelmiä ja jossain vaiheessa voidaan integroida yrityksen infrastruktuuriin.
Kehityksen lisäksi meillä on erittäin suuri yli 500 työntekijää, jotka on muodostettu ryhmiksi jokaiselle asiakkaalle. He osallistuvat verkkojen ja muiden järjestelmien ylläpitoon, etävalvontaan, vaatimusten ratkaisemiseen ja niin edelleen. Toisin sanoen SC:n infrastruktuuri on itse asiassa sen asiakkaan infrastruktuuri, jonka kanssa he työskentelevät parhaillaan. Tämän verkoston osan kanssa työskentelyn erikoisuus on, että heidän työasemansa yrityksellemme ovat osittain ulkoisia ja osittain sisäisiä. Siksi SC:lle otimme käyttöön seuraavan lähestymistavan - yritys tarjoaa vastaavalle osastolle verkko- ja muita resursseja, pitäen näiden osastojen työasemat ulkoisina yhteyksinä (analogisesti konttoreiden ja etäkäyttäjien kanssa).
Moottoritien suunnittelu: olemme operaattori (yllätys)
Arvioituamme kaikki sudenkuopat totesimme, että saimme teleoperaattorin verkon yhden toimiston sisään ja aloimme toimia sen mukaisesti.
Loimme runkoverkon, jonka avulla jokaiselle sisäiselle ja tulevaisuudessa myös ulkoiselle kuluttajalle tarjotaan tarvittava palvelu: L2 VPN, L3 VPN tai tavallinen L3 reititys. Jotkut osastot tarvitsevat suojatun Internet-yhteyden, kun taas toiset tarvitsevat puhtaan pääsyn ilman palomuuria, mutta samalla suojaavat yrityksemme resursseja ja ydinverkkoa liikenteeltä.
Teimme epävirallisesti "SLA-sopimuksen" jokaisen divisioonan kanssa. Sen mukaan kaikki ilmenevät tapahtumat on poistettava tietyn, ennalta sovitun ajan kuluessa. Yrityksen vaatimukset verkostolleen osoittautuivat tiukiksi. Suurin vastausaika tapaukseen puhelin- ja sähköpostihäiriötapauksissa oli 5 minuuttia. Aika verkon toiminnan palauttamiseen tyypillisten vikojen aikana on enintään minuutti.
Koska meillä on operaattoritason verkko, voit muodostaa yhteyden siihen vain tiukasti sääntöjen mukaisesti. Palveluyksiköt asettavat käytäntöjä ja tarjoavat palveluita. He eivät edes tarvitse tietoja tiettyjen palvelimien, virtuaalikoneiden ja työasemien yhteyksistä. Mutta samaan aikaan tarvitaan suojamekanismeja, koska yhden yhteyden ei pitäisi poistaa verkkoa käytöstä. Jos silmukka luodaan vahingossa, muiden käyttäjien ei pitäisi huomata tätä, eli verkon riittävä vastaus on tarpeen. Jokainen teleoperaattori ratkaisee jatkuvasti samanlaisia näennäisesti monimutkaisia ongelmia ydinverkossaan. Se palvelee monia asiakkaita, joilla on erilaiset tarpeet ja liikenne. Samanaikaisesti eri tilaajat eivät saisi kokea haittaa muiden liikenteestä.
Kotona ratkaisimme tämän ongelman seuraavasti: rakensimme runkoverkon L3-verkon täydellä redundanssilla IS-IS-protokollaa käyttäen. Ytimen päälle rakennettiin teknologiaan perustuva peittoverkko /, käyttämällä reititysprotokollaa . Reititysprotokollien lähentymisen nopeuttamiseksi käytettiin BFD-tekniikkaa.
Verkon rakenne
Testeissä tämä malli osoitti olevansa erinomainen - kun mikä tahansa kanava tai kytkin irrotetaan, konvergenssiaika on enintään 0.1-0.2 s, vähintään paketteja menetetään (usein ei yhtään), TCP-istunnot eivät katkea, puhelinkeskustelut eivät keskeydy.
Alustakerros - reititys
Overlay Layer - Reititys
Jakelukytkiminä käytettiin Huawei CE6870 -kytkimiä VXLAN-lisenssillä. Tällä laitteella on optimaalinen hinta/laatusuhde, jonka avulla voit liittää tilaajia 10 Gbit/s nopeudella ja runkoverkkoon 40–100 Gbit/s nopeudella käytetyistä lähetin-vastaanottimista riippuen.
Huawei CE6870 kytkimet
Ydinkytkiminä käytettiin Huawei CE8850 -kytkimiä. Tavoitteena on välittää liikennettä nopeasti ja luotettavasti. Niihin ei ole kytketty muita laitteita paitsi jakelukytkimet, ne eivät tiedä mitään VXLANista, joten valittiin malli, jossa on 32 40/100 Gbps porttia, peruslisenssillä joka tarjoaa L3 reitityksen ja tuen IS-IS:lle ja MP-BGP:lle. protokollat.
Alin on Huawei CE8850 -ydinkytkin
Suunnitteluvaiheessa ryhmän sisällä syntyi keskustelu teknologioista, joilla voitaisiin toteuttaa vikasietoinen yhteys runkoverkon solmuihin. Moskovan toimistomme sijaitsee kolmessa rakennuksessa, meillä on 7 jakeluhuonetta, joista jokaiseen asennettiin kaksi Huawei CE6870 -jakelukytkintä (vain pääsykytkimet asennettiin useisiin jakeluhuoneisiin). Verkkokonseptia kehitettäessä harkittiin kahta redundanssivaihtoehtoa:
- Jakokytkimien yhdistäminen vikasietoiseksi pinoksi jokaisessa ristikytkentähuoneessa. Plussat: yksinkertaisuus ja helppokäyttöisyys. Haitat: koko pinon epäonnistumisen todennäköisyys on suurempi, kun verkkolaitteiden laiteohjelmistossa tapahtuu virheitä ("muistivuotoja" ja vastaavia).
- Käytä M-LAG- ja Anycast-yhdyskäytävätekniikoita laitteiden yhdistämiseen jakelukytkimiin.
Lopulta päädyimme toiseen vaihtoehtoon. Se on hieman vaikeampi konfiguroida, mutta se on osoittanut käytännössä suorituskykynsä ja korkean luotettavuutensa.
Harkitse ensin päätelaitteiden liittämistä jakelukytkimiin:
Ylittää
Pääsykytkin, palvelin tai mikä tahansa laite, joka vaatii vikasietoisen yhteyden, sisältyy kahteen jakelukytkimeen. M-LAG-tekniikka tarjoaa redundanssin datalinkkitasolla. Oletetaan, että kaksi jakelukytkintä näkyy liitetylle laitteelle yhtenä laitteena. Redundanssi ja kuormituksen tasapainotus suoritetaan LACP-protokollalla.
Anycast-yhdyskäytävätekniikka tarjoaa redundanssin verkkotasolla. Kuhunkin jakelukytkimeen on konfiguroitu melko suuri määrä VRF:itä (jokainen VRF on tarkoitettu omiin tarkoituksiinsa - erikseen "tavallisille" käyttäjille, erikseen puheluille, erikseen erilaisiin testi- ja kehitysympäristöihin jne.) ja jokaisessa. VRF:lle on määritetty useita VLAN-verkkoja. Verkkossamme jakelukytkimet ovat oletusyhdyskäytäviä kaikille niihin liitettyille laitteille. VLAN-liitäntöjä vastaavat IP-osoitteet ovat samat molemmilla jakelukytkimillä. Liikenne ohjataan lähimmän vaihteen kautta.
Katsotaanpa nyt jakelukytkimien yhdistämistä ytimeen:
Vikasietoisuus tarjotaan verkkotasolla IS-IS-protokollan avulla. Huomaa, että kytkimien välillä on erillinen L3-tietoliikennelinja, jonka nopeus on 100G. Fyysisesti tämä tietoliikennelinja on suorapääsykaapeli; se näkyy oikealla Huawei CE6870 -kytkimien kuvassa.
Vaihtoehtona olisi järjestää "rehellinen" täysin yhdistetty kaksoistähtitopologia, mutta kuten edellä mainittiin, meillä on 7 ristiin yhdistettyä huonetta kolmessa rakennuksessa. Vastaavasti, jos olisimme valinneet "kaksoistähti"-topologian, olisimme tarvinneet täsmälleen kaksi kertaa enemmän "pitkän kantaman" 40G-lähetin-vastaanottimia. Säästöt ovat täällä erittäin merkittäviä.
Muutama sana on sanottava siitä, kuinka VXLAN- ja Anycast-yhdyskäytäväteknologiat toimivat yhdessä. VXLAN, yksityiskohtiin menemättä, on tunneli Ethernet-kehysten kuljettamiseen UDP-pakettien sisällä. Jakelukytkimien silmukkaliitäntöjä käytetään VXLAN-tunnelin kohde-IP-osoitteena. Jokaisessa risteyksessä on kaksi kytkintä, joilla on sama loopback-liitäntäosoite, joten paketti voi saapua mihin tahansa niistä ja siitä voidaan poimia Ethernet-kehys.
Jos kytkin tietää haetun kehyksen MAC-osoitteen, kehys toimitetaan oikein määränpäähänsä. M-LAG-mekanismi vastaa MAC-osoitetaulukoiden (sekä ARP:n) synkronoinnista varmistaakseen, että molemmilla samaan ristikytkentään asennetuilla jakelukytkimillä on ajantasaiset tiedot kaikista pääsykytkimistä "saapuvista" MAC-osoitteista. taulukot) molemmissa kytkimissä M-LAG-pareissa.
Liikenteen tasapainotus saavutetaan, koska alusverkossa on useita reittejä jakeluvaihteiden takaisinkytkentärajapintoihin.
Sen sijaan johtopäätös
Kuten yllä mainittiin, verkko osoitti testauksen ja käytön aikana korkeaa luotettavuutta (tyypillisten vikojen palautumisaika on enintään satoja millisekunteja) ja hyvää suorituskykyä - jokainen ristikytkentä on yhdistetty ytimeen kahdella 40 Gbit/s kanavalla. Verkkomme pääsykytkimet on pinottu ja kytketty jakelukytkimiin LACP/M-LAG:n kautta kahdella 10 Gbit/s kanavalla. Pinossa on yleensä 5 kytkintä, joissa kussakin on 48 porttia, ja jopa 10 pääsypinoa on kytketty jakeluun kussakin ristikytkennässä. Siten runko tarjoaa noin 30 Mbit/s käyttäjää kohden jopa teoreettisella maksimikuormalla, mikä riittää kirjoitettaessa kaikkiin käytännön sovelluksiimme.
Verkon avulla voit järjestää saumattomasti minkä tahansa mielivaltaisten kytkettyjen laitteiden pariliitoksen sekä L2:n että L3:n kautta, mikä tarjoaa täydellisen liikenteen (josta tietoturvapalvelu pitää) ja vikaalueet (joista käyttötiimi pitää) eristämisen.
Seuraavassa osassa kerromme, kuinka siirryimme uuteen verkkoon. Pysy kanavalla!
Maxim Klochkov
Verkoston auditointi- ja monimutkaisten projektien ryhmän vanhempi konsultti
Verkkoratkaisukeskus
"Jet Infosystems"
Lähde: will.com