Arvioi kytkennät kaavion keskiosassa. Palaamme niihin alla
Jossain vaiheessa saatat huomata, että suuret, monimutkaiset L2-pohjaiset verkot ovat parantumattomasti sairaita. Ensinnäkin BUM-liikenteen käsittelyyn ja STP-protokollan toimintaan liittyvät ongelmat. Toiseksi arkkitehtuuri on yleensä vanhentunut. Tämä aiheuttaa epämiellyttäviä ongelmia seisokkien ja epämukavan käsittelyn muodossa.
Meillä oli kaksi rinnakkaista projektia, joissa asiakkaat arvioivat raittiisti vaihtoehtojen plussat ja miinukset ja valitsivat kaksi erilaista peittoratkaisua ja toteutimme ne.
Siellä oli mahdollisuus vertailla toteutusta. Ei hyväksikäyttöä, meidän pitäisi puhua siitä kahden tai kolmen vuoden kuluttua.
Joten mikä on verkkorakenne, jossa on peittoverkot ja SDN?
Mitä tehdä klassisen verkkoarkkitehtuurin kiireellisille ongelmille?
Joka vuosi ilmaantuu uusia tekniikoita ja ideoita. Käytännössä verkostojen uudelleenrakentamisen kiireellinen tarve ei noussut esiin kovin pitkään, koska myös kaiken tekeminen käsin vanhoilla hyvillä menetelmillä on mahdollista. Entä jos on XNUMX-luku? Loppujen lopuksi järjestelmänvalvojan pitäisi työskennellä eikä istua toimistossaan.
Sitten alkoi suurten palvelinkeskusten rakentamisen puomi. Sitten kävi selväksi, että klassisen arkkitehtuurin kehitysraja oli saavutettu, ei vain suorituskyvyn, vikasietoisuuden ja skaalautuvuuden suhteen. Ja yksi vaihtoehdoista näiden ongelmien ratkaisemiseksi oli ajatus peittoverkkojen rakentamisesta reititetyn runkoverkon päälle.
Lisäksi verkkojen laajenemisen myötä tällaisten tehtaiden hallinnan ongelma on tullut akuutiksi, minkä seurauksena alkoi ilmestyä ohjelmistopohjaisia verkkoratkaisuja, jotka pystyvät hallitsemaan koko verkkoinfrastruktuuria yhtenä kokonaisuutena. Ja kun verkkoa hallitaan yhdestä pisteestä, IT-infrastruktuurin muiden komponenttien on helpompi olla vuorovaikutuksessa sen kanssa ja tällaiset vuorovaikutusprosessit on helpompi automatisoida.
Lähes jokaisella suurella verkkolaitteiden, mutta myös virtualisoinnin, valmistajalla on portfoliossaan vaihtoehtoja tällaisiin ratkaisuihin.
Jäljelle jää vain selvittää, mikä sopii mihinkin tarpeisiin. Esimerkiksi erityisen suurilla yrityksillä, joilla on hyvä kehitys- ja toimintatiimi, toimittajien paketoidut ratkaisut eivät aina täytä kaikkia tarpeita, vaan ne turvautuvat omien SD-ratkaisujen (softwaredefined) kehittämiseen. Nämä ovat esimerkiksi pilvipalveluntarjoajia, jotka laajentavat jatkuvasti asiakkailleen tarjottavia palveluja, eivätkä paketoidut ratkaisut yksinkertaisesti pysty pysymään heidän tarpeidensa perässä.
Keskisuurille yrityksille toimittajan tarjoama toiminnallisuus laatikkoratkaisuna riittää 99 prosentissa tapauksista.
Mitä peittoverkot ovat?
Mikä on peittoverkkojen idea? Käytännössä otat perinteisen reititetyn verkon ja rakennat sen päälle toisen verkon saadaksesi lisää ominaisuuksia. Useimmiten puhumme laitteiden ja tietoliikennelinjojen kuormituksen tehokkaasta jakamisesta, skaalautuvuusrajan merkittävästä lisäämisestä, luotettavuuden lisäämisestä ja joukosta turvallisuushyötyjä (segmentoinnin vuoksi). Ja SDN-ratkaisut tarjoavat tämän lisäksi mahdollisuuden erittäin, erittäin, erittäin kätevään joustavaan hallintoon ja tekevät verkosta läpinäkyvämmän kuluttajille.
Yleisesti ottaen, jos paikalliset verkot olisi keksitty 2010-luvulla, ne olisivat näyttäneet paljon erilaisilta kuin mitä saimme armeijasta 1970-luvulla.
Peittoverkkoja käyttävien kankaiden rakentamiseen liittyvien teknologioiden osalta tällä hetkellä on olemassa monia toimittajatoteutuksia ja Internet RFC -projekteja (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve ja muut). Kyllä, standardeja on, mutta näiden standardien täytäntöönpano eri valmistajien toimesta voi vaihdella, joten tällaisia tehtaita luotaessa on edelleen mahdollista luopua kokonaan myyjän lukosta vain teoriassa paperilla.
SD-ratkaisulla asiat ovat vieläkin hämmentävämpiä: jokaisella toimittajalla on oma näkemyksensä. On täysin avoimia ratkaisuja, jotka voit teoriassa täydentää itse, ja on täysin suljettuja.
Cisco tarjoaa SDN-versionsa datakeskuksille - ACI. Luonnollisesti tämä on 100-prosenttisesti toimittajan lukittu ratkaisu verkkolaitteiden valinnassa, mutta samalla se on täysin integroitu virtualisointijärjestelmiin, konteihin, turvallisuuteen, orkestrointiin, kuormituksen tasapainottajiin jne. Mutta pohjimmiltaan se on silti eräänlainen musta laatikko ilman mahdollisuutta päästä täysimääräisesti kaikkiin sisäisiin prosesseihin. Kaikki asiakkaat eivät hyväksy tätä vaihtoehtoa, koska olet täysin riippuvainen kirjoitetun ratkaisukoodin ja sen toteutuksen laadusta, mutta toisaalta valmistajalla on yksi maailman parhaista teknisistä tukipalveluista ja sillä on vain omistautunut tiimi. tähän ratkaisuun. Ensimmäisen projektin ratkaisuksi valittiin Cisco ACI.
Toiseen projektiin valittiin Juniper-ratkaisu. Valmistajalla on myös oma SDN konesalille, mutta asiakas päätti olla toteuttamatta SDN:ää. Verkon rakentamistekniikaksi valittiin EVPN VXLAN -kangas ilman keskitettyjä ohjaimia.
Mitä varten se on
Tehtaan luominen mahdollistaa helposti skaalautuvan, vikasietoisen ja luotettavan verkon rakentamisen. Arkkitehtuuri (leaf-spine) ottaa huomioon datakeskusten ominaisuudet (liikennereitit, viiveiden ja pullonkaulojen minimoiminen verkossa). Palvelinkeskusten SD-ratkaisut mahdollistavat tällaisen tehtaan hallinnan ja integroinnin konesaliekosysteemiin erittäin kätevästi, nopeasti ja joustavasti.
Molempien asiakkaiden oli rakennettava redundantteja konesaleja vikasietoisuuden varmistamiseksi, ja lisäksi konesalien välinen liikenne piti salata.
Ensimmäinen asiakas harkitsi jo kankaattomia ratkaisuja mahdollisena standardina verkkoihinsa, mutta testeissä heillä oli ongelmia STP-yhteensopivuuden kanssa useiden laitevalmistajien välillä. Oli seisokkeja, jotka aiheuttivat palvelujen kaatumisen. Ja asiakkaalle tämä oli kriittistä.
Cisco oli jo asiakkaan yritysstandardi, he katsoivat ACI:tä ja muita vaihtoehtoja ja päättivät, että tämä ratkaisu kannattaa. Pidin ohjauksen automatisoinnista yhdestä painikkeesta yhden ohjaimen kautta. Palvelut määritetään nopeammin ja niitä hallitaan nopeammin. Päätimme varmistaa liikenteen salauksen ajamalla MACSec IPN- ja SPINE-kytkimien välillä. Siten onnistuimme välttämään kryptoyhdyskäytävän muodossa olevan pullonkaulan, säästämään niissä ja käyttämään maksimikaistanleveyttä.
Toinen asiakas valitsi Juniperin ohjaimettoman ratkaisun, koska heidän nykyisessä konesalissaan oli jo pieni EVPN VXLAN -kangasta toteuttava asennus. Mutta siellä se ei ollut vikasietoinen (yksi kytkin käytettiin). Päätimme laajentaa pääpalvelinkeskuksen infrastruktuuria ja rakentaa tehtaan varapalvelinkeskukseen. Olemassa olevaa EVPN:ää ei käytetty täysin: VXLAN-kapselointia ei varsinaisesti käytetty, koska kaikki isännät oli kytketty yhteen kytkimeen ja kaikki MAC-osoitteet ja /32 isäntäosoitteet olivat paikallisia, yhdyskäytävä niille oli sama kytkin, muita laitteita ei ollut. , jossa oli tarpeen rakentaa VXLAN-tunneleita. He päättivät varmistaa liikenteen salauksen IPSEC-tekniikalla palomuurien välillä (palomuurin suorituskyky oli riittävä).
He kokeilivat myös ACI:tä, mutta päättivät, että myyjälukon vuoksi heidän olisi ostettava liikaa laitteistoa, mukaan lukien äskettäin ostetut uudet laitteet, eikä siinä yksinkertaisesti ollut taloudellista järkeä. Kyllä, Cisco-kangas integroituu kaikkeen, mutta vain sen laitteet ovat mahdollisia itse kankaassa.
Toisaalta, kuten sanoimme aiemmin, et voi vain sekoittaa EVPN VXLAN -kangasta minkään naapuritoimittajan kanssa, koska protokollien toteutukset ovat erilaisia. Se on kuin risteyttäisi Cisco ja Huawei samassa verkossa – standardit näyttävät olevan yleisiä, mutta joudut tanssimaan tamburiinilla. Koska kyseessä on pankki ja yhteensopivuustestit olisivat hyvin pitkiä, päätimme, että on parempi ostaa nyt samalta toimittajalta, emmekä hurahdu liikaa perustoimintojen lisäksi.
Muuttosuunnitelma
Kaksi ACI-pohjaista datakeskusta:
Vuorovaikutuksen järjestäminen datakeskusten välillä. Multi-Pod-ratkaisu valittiin - jokainen konesali on pod. Skaalausvaatimukset kytkinten lukumäärän ja podien välisten viiveiden mukaan (RTT alle 50 ms) otetaan huomioon. Päätettiin olla rakentamatta Multi-Site-ratkaisua hallinnan helpottamiseksi (Multi-Pod-ratkaisu käyttää yhtä hallintaliittymää, Multi-Site-ratkaisulla olisi kaksi rajapintaa tai se vaatisi Multi-Site Orchestratorin), ja koska ei maantieteellistä paikkavaraus vaadittiin.
Legacy-verkosta palveluiden siirtämisen kannalta valittiin läpinäkyvin vaihtoehto siirtämällä asteittain tiettyjä palveluita vastaavia VLAN-verkkoja.
Siirtoa varten kullekin VLAN:lle luotiin vastaava EPG (End-point-group) tehtaalla. Ensin verkkoa venytettiin vanhan verkon ja kankaan välillä L2:n yli, sitten kun kaikki isännät oli siirretty, yhdyskäytävä siirrettiin kankaaseen ja EPG oli vuorovaikutuksessa olemassa olevan verkon kanssa L3OUT:n kautta samalla kun L3OUT:n ja EPG:n välinen vuorovaikutus. kuvattiin sopimusten avulla. Likimääräinen kaavio:
Esimerkkirakenne useimmista ACI-tehdaskäytännöistä on esitetty alla olevassa kuvassa. Koko kokoonpano perustuu muihin käytäntöihin sisältyviin käytäntöihin ja niin edelleen. Aluksi sitä on erittäin vaikea selvittää, mutta vähitellen, kuten käytäntö osoittaa, verkonvalvojat tottuvat tähän rakenteeseen noin kuukaudessa, ja sitten he alkavat ymmärtää, kuinka kätevä se on.
vertailu
Cisco ACI -ratkaisussa sinun on ostettava lisää laitteita (erilliset kytkimet Inter-Pod-vuorovaikutusta ja APIC-ohjaimia varten), mikä tekee siitä kalliimman. Juniperin ratkaisu ei vaatinut ohjaimien tai lisävarusteiden hankintaa; Asiakkaan olemassa olevia laitteita oli mahdollista käyttää osittain.
Tässä on EVPN VXLAN -kangasarkkitehtuuri kahdelle toisen projektin datakeskukselle:
ACI:n avulla saat valmiin ratkaisun – ei tarvitse puuhailla, ei tarvitse optimoida. Asiakkaan alustavan tutustumisen aikana tehtaaseen ei tarvita kehittäjiä, koodiin ja automaatioon ei tarvita tukihenkilöitä. Se on melko helppokäyttöinen; monet asetukset voidaan tehdä ohjatun toiminnon kautta, mikä ei ole aina plussaa, etenkään komentoriville tottuneille. Joka tapauksessa vie aikaa rakentaa aivot uudelleen uusille raiteille, asetusten erityispiirteisiin käytäntöjen ja monien sisäkkäisten käytäntöjen avulla toimimisen kautta. Tämän lisäksi on erittäin toivottavaa, että käytäntöjen ja objektien nimeämiselle on selkeä rakenne. Jos ohjaimen logiikassa ilmenee ongelmia, se voidaan ratkaista vain teknisen tuen avulla.
EVPN:ssä - konsolissa. Kärsi tai iloitse. Vanhalle vartijalle tuttu käyttöliittymä. Kyllä, siellä on vakiokokoonpano ja oppaat. Sinun täytyy polttaa manaa. Erilaisia malleja, kaikki on selkeää ja yksityiskohtaista.
Luonnollisesti molemmissa tapauksissa siirrettäessä on parempi siirtää ensin ei kriittisimmät palvelut, esimerkiksi testiympäristöt, ja vasta sitten, kun kaikki viat on havaittu, siirrytään tuotantoon. Ja älä viritä perjantai-iltana. Sinun ei pitäisi luottaa myyjään, että kaikki on hyvin, on aina parempi pelata varman päälle.
Maksat enemmän ACI:stä, vaikka Cisco mainostaa tällä hetkellä aktiivisesti tätä ratkaisua ja antaa siitä usein hyviä alennuksia, mutta säästät ylläpidossa. EVPN-tehtaan hallinta ja mahdollinen automatisointi ilman ohjainta vaatii investointeja ja säännöllisiä kustannuksia - seurantaa, automatisointia, uusien palveluiden käyttöönottoa. Samaan aikaan ensimmäinen käynnistys ACI:lla kestää 30–40 prosenttia kauemmin. Tämä johtuu siitä, että tarvittavien profiilien ja käytäntöjen koko joukon luominen, joita sitten käytetään, kestää kauemmin. Mutta verkon kasvaessa tarvittavien kokoonpanojen määrä vähenee. Käytät valmiiksi luotuja käytäntöjä, profiileja, objekteja. Voit määrittää segmentoinnin ja suojauksen joustavasti, hallita keskitetysti sopimuksia, jotka ovat vastuussa tietyn vuorovaikutuksen sallimisesta EPG:iden välillä - työn määrä laskee jyrkästi.
EVPN:ssä sinun on määritettävä jokainen laite tehtaalla, virheiden todennäköisyys on suurempi.
Vaikka ACI:n käyttöönotto oli hitaampaa, EVPN:n virheenkorjaus kesti melkein kaksi kertaa kauemmin. Jos Ciscon tapauksessa voit aina soittaa tukiinsinöörille ja kysyä verkosta kokonaisuutena (koska se on katettu ratkaisuna), niin Juniper Networksista ostetaan vain laitteisto, ja se on se katettu. Ovatko paketit lähteneet laitteesta? No okei, sitten sinun ongelmasi. Mutta voit avata kysymyksen ratkaisun tai verkkosuunnittelun valinnasta - ja sitten he neuvovat sinua ostamaan ammattimaisen palvelun lisämaksusta.
ACI-tuki on erittäin siistiä, koska se on erillinen: erillinen tiimi istuu vain tätä varten. Siellä on myös venäjänkielisiä asiantuntijoita. Opas on yksityiskohtainen, ratkaisut ovat ennalta määrättyjä. He katsovat ja neuvovat. He vahvistavat suunnittelun nopeasti, mikä on usein tärkeää. Juniper Networks tekee saman, mutta paljon hitaammin (meillä oli tämä, nyt pitäisi huhujen mukaan olla parempi), mikä pakottaa tekemään kaiken itse, mitä ratkaisuinsinööri osaa neuvoa.
Cisco ACI tukee integraatiota virtualisointi- ja konttijärjestelmiin (VMware, Kubernetes, Hyper-V) ja keskitettyyn hallintaan. Saatavana verkko- ja tietoturvapalveluilla - tasapainotus, palomuurit, WAF, IPS jne... Hyvä mikrosegmentointi pakkauksesta. Toisessa ratkaisussa integrointi verkkopalveluihin on helppoa, ja foorumeista kannattaa keskustella etukäteen niiden kanssa, jotka ovat tehneet tämän.
Koko
Jokaista tapausta varten on tarpeen valita ratkaisu, ei pelkästään laitteiston kustannusten perusteella, vaan on myös otettava huomioon muut käyttökustannukset ja tärkeimmät asiakkaan tällä hetkellä kohtaamat ongelmat ja suunnitelmat. ovat IT-infrastruktuurin kehittämiseen.
ACI oli lisälaitteiden vuoksi kalliimpi, mutta ratkaisu on valmis ilman lisäviimeistelyä, toinen ratkaisu on monimutkaisempi ja toiminnan kannalta kalliimpi, mutta halvempi.
Jos haluat keskustella siitä, kuinka paljon verkkokankaan käyttöönotto eri toimittajilla saattaa maksaa ja millaista arkkitehtuuria tarvitaan, voit tavata ja keskustella. Neuvomme sinua maksutta, kunnes saat karkean luonnoksen arkkitehtuurista (jolla voit laskea budjetteja), yksityiskohtainen suunnittelu on tietysti jo maksettu.
Vladimir Klepche, yritysverkot.
Lähde: will.com