Taksi la ligojn en la meza parto de la diagramo. Ni revenos al ili sube.
En iu momento, vi eble trovos, ke grandaj, kompleksaj L2-bazitaj retoj estas fine malsanaj. Antaŭ ĉio, problemoj asociitaj kun prilaborado de BUM-trafiko kaj la funkciado de la STP-protokolo. Due, la arkitekturo estas ĝenerale malnoviĝinta. Ĉi tio kaŭzas malagrablajn problemojn en formo de malfunkcioj kaj maloportuna uzado.
Ni havis du paralelajn projektojn, kie la klientoj sobre taksis ĉiujn avantaĝojn kaj malavantaĝojn de la elektoj kaj elektis du malsamajn superkovrajn solvojn, kaj ni efektivigis ilin.
Estis ŝanco kompari la efektivigon. Ne ekspluatado; ni parolu pri ĝi post du aŭ tri jaroj.
Do, kio estas reto-ŝtofo kun overlay retoj kaj SDN?
Kion fari kun la urĝaj problemoj de klasika reto-arkitekturo?
Ĉiujare aperas novaj teknologioj kaj ideoj. En la praktiko, la urĝa bezono rekonstrui retojn ne aperis dum sufiĉe longa tempo, ĉar fari ĉion mane uzante la bonajn malnovmodajn metodojn ankaŭ eblas. Kio do se ĝi estas la dudekunua jarcento? Post ĉio, administranto devus labori, kaj ne sidi en sia oficejo.
Tiam ekprospero en la konstruado de grandskalaj datumcentroj komenciĝis. Tiam evidentiĝis, ke la evolulimo de klasika arkitekturo estis atingita, ne nur laŭ efikeco, faŭltoleremo kaj skaleblo. Kaj unu el la ebloj por solvi ĉi tiujn problemojn estis la ideo konstrui superkovrajn retojn supre de venkita spino.
Krome, kun la pliiĝo de la skalo de retoj, la problemo pri administrado de tiaj fabrikoj akriĝis, rezulte de kiu komencis aperi retaj solvoj difinitaj programaro kun la kapablo administri la tutan retan infrastrukturon kiel unu tuton. Kaj kiam la reto estas administrita de ununura punkto, estas pli facile por aliaj komponentoj de la IT-infrastrukturo interagi kun ĝi, kaj tiaj interagaj procezoj estas pli facile aŭtomatigeblaj.
Preskaŭ ĉiu grava fabrikanto de ne nur retaj ekipaĵoj, sed ankaŭ de virtualigo, havas eblojn por tiaj solvoj en sia biletujo.
Restas nur eltrovi, kio taŭgas por kio bezonas. Ekzemple, por precipe grandaj kompanioj kun bona evoluiga kaj operacia teamo, pakitaj solvoj de vendistoj ne ĉiam kontentigas ĉiujn bezonojn, kaj ili recurre al evoluigado de siaj propraj SD (programaro difinita) solvoj. Ekzemple, ĉi tiuj estas nubaj provizantoj, kiuj konstante vastigas la gamon de servoj provizitaj al siaj klientoj, kaj pakitaj solvoj simple ne kapablas daŭrigi siajn bezonojn.
Por mezgrandaj kompanioj, la funkcieco ofertita de la vendisto en formo de boksita solvo sufiĉas en 99 procentoj de kazoj.
Kio estas overlay retoj?
Kio estas la ideo malantaŭ supermetitaj retoj? Esence, vi prenas klasikan reton kaj konstruas alian reton sur ĝi por akiri pli da funkcioj. Plej ofte, ni parolas pri efike distribuado de la ŝarĝo sur ekipaĵo kaj komunikadlinioj, signife pliigante la skaleblan limon, pliigante fidindecon kaj amason da sekurecaj bonaĵoj (pro segmentado). Kaj SDN-solvoj, krom ĉi tio, donas la ŝancon por tre, tre, tre oportuna fleksebla administrado kaj faras la reton pli travidebla por siaj konsumantoj.
Ĝenerale, se lokaj retoj estus inventitaj en la 2010-aj jaroj, ili aspektus multe malsamaj ol tio, kion ni heredis de la militistaro en la 1970-aj jaroj.
Koncerne teknologiojn por konstruado de ŝtofoj uzantaj superkovrajn retojn, ekzistas nuntempe multaj vendistaj efektivigoj kaj Interretaj RFC-projektoj (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve kaj aliaj). Jes, ekzistas normoj, sed la efektivigo de ĉi tiuj normoj de malsamaj fabrikantoj povas malsami, do kreante tiajn fabrikojn, ankoraŭ eblas tute forlasi la vendistan seruron nur teorie sur papero.
Kun SD-solvo, aferoj estas eĉ pli konfuzaj; ĉiu vendisto havas sian propran vizion. Estas tute malfermitaj solvoj, kiujn teorie vi povas kompletigi mem, kaj estas tute fermitaj.
Cisco ofertas sian version de SDN por datumcentroj - ACI. Kompreneble, ĉi tio estas 100% vendisto-ŝlosita solvo laŭ elekto de retaj ekipaĵoj, sed samtempe ĝi estas plene integrita kun virtualigsistemoj, kontenerigo, sekureco, orkestrado, ŝarĝbalanciloj ktp. Sed esence, ĝi ankoraŭ estas. speco de nigra skatolo, sen la ebleco de plena aliro al ĉiuj internaj procezoj. Ne ĉiuj klientoj konsentas pri ĉi tiu opcio, ĉar vi tute dependas de la kvalito de la skribita solvkodo kaj ĝia efektivigo, sed aliflanke, la fabrikanto havas unu el la plej bonaj teknikaj subtenoj en la mondo kaj havas dediĉitan teamon dediĉitan nur. al ĉi tiu solvo. Cisco ACI estis elektita kiel la solvo por la unua projekto.
Por la dua projekto, Juniper-solvo estis elektita. La fabrikanto ankaŭ havas sian propran SDN por la datumcentro, sed la kliento decidis ne efektivigi SDN. EVPN VXLAN-ŝtofo sen la uzo de alcentrigitaj regiloj estis elektita kiel la retokonstruteknologio.
Por kio ĝi estas
Krei fabrikon ebligas al vi konstrui facile skaleblan, mistolerantan, fidindan reton. La arkitekturo (folio-spino) konsideras la karakterizaĵojn de datumcentroj (trafikaj vojoj, minimumigante malfruojn kaj botelojn en la reto). SD-solvoj en datumcentroj permesas vin tre konvene, rapide kaj flekseble administri tian fabrikon kaj integri ĝin en la datumcentran ekosistemon.
Ambaŭ klientoj devis konstrui redundajn datumcentrojn por certigi misfunkciadon, kaj krome, trafiko inter la datumcentroj devis esti ĉifrita.
La unua kliento jam konsideris senŝtofajn solvojn kiel ebla normo por siaj retoj, sed en testoj ili havis problemojn kun STP-kongruo inter pluraj hardvarvendistoj. Ekzistis malfunkcioj kiuj kaŭzis servojn kraŝi. Kaj por la kliento tio estis kritika.
Cisco jam estis la kompania normo de la kliento, ili rigardis ACI kaj aliajn eblojn kaj decidis, ke indas preni ĉi tiun solvon. Mi ŝatis la aŭtomatigon de kontrolo de unu butono tra ununura regilo. Servoj estas agorditaj pli rapide kaj administritaj pli rapide. Ni decidis certigi trafikan ĉifradon per funkciado de MACSec inter la IPN kaj SPINE-ŝaltiloj. Tiel, ni sukcesis eviti la botelon en formo de kripta enirejo, ŝpari sur ili kaj uzi la maksimuman larĝan bandon.
La dua kliento elektis senregilan solvon de Juniper ĉar ilia ekzistanta datumcentro jam havis malgrandan instalaĵon efektivigantan ŝtofon EVPN VXLAN. Sed tie ĝi ne estis tolerema al misfunkciadoj (oni uzis unu ŝaltilon). Ni decidis vastigi la infrastrukturon de la ĉefa datumcentro kaj konstrui fabrikon en la rezerva datumcentro. La ekzistanta EVPN ne estis plene uzita: VXLAN-enkapsuligo ne estis fakte uzita, ĉar ĉiuj gastigantoj estis ligitaj al unu ŝaltilo, kaj ĉiuj MAC-adresoj kaj /32-mastro-adresoj estis lokaj, la enirejo por ili estis la sama ŝaltilo, ekzistis neniuj aliaj aparatoj. , kie estis necese konstrui VXLAN-tunelojn. Ili decidis certigi trafikan ĉifradon uzante IPSEC-teknologion inter fajroŝirmiloj (la agado de la fajroŝirmilo estis sufiĉa).
Ili ankaŭ provis ACI, sed decidis ke pro la vendistoseruro, ili devos aĉeti tro da aparataro, inkluzive de anstataŭigo de ĵus aĉetita nova ekipaĵo, kaj ĝi simple ne havis ekonomian sencon. Jes, la Cisco-ŝtofo integras kun ĉio, sed nur ĝiaj aparatoj estas eblaj ene de la ŝtofo mem.
Aliflanke, kiel ni diris antaŭe, vi ne povas simple miksi ŝtofon EVPN VXLAN kun iu ajn najbara vendisto, ĉar la protokolaj efektivigoj estas malsamaj. Estas kiel kruci Cisco kaj Huawei en unu reto - ŝajnas, ke la normoj estas oftaj, sed vi devos danci per tamburino. Ĉar ĉi tio estas banko, kaj kongruaj testoj estus tre longaj, ni decidis, ke estas pli bone aĉeti de la sama vendisto nun, kaj ne tro forpreni funkciecon preter la bazaj.
Plano de migrado
Du ACI-bazitaj datencentroj:
Organizo de interago inter datumcentroj. La solvo Multi-Pod estis elektita - ĉiu datumcentro estas pod. La postuloj por grimpi laŭ la nombro da ŝaltiloj kaj prokrastoj inter balgoj (RTT malpli ol 50 ms) estas enkalkulitaj. Estis decidite ne konstrui Multi-Site-solvon por facileco de administrado (Multi-Pod-solvo uzas ununuran administradinterfacon, Multi-Site havus du interfacojn, aŭ postulus Multi-Site Orchestrator), kaj ĉar neniu geografia rezervo de retejoj estis postulata.
El la vidpunkto de migrado de servoj de la Legacy-reto, la plej travidebla opcio estis elektita, iom post iom transigante VLAN-ojn respondajn al certaj servoj.
Por migrado, ekvivalenta EPG (Finpunkto-grupo) estis kreita por ĉiu VLAN en la fabriko. Unue, la reto estis etendita inter la malnova reto kaj la ŝtofo super L2, tiam post kiam ĉiuj gastigantoj estis migritaj, la enirejo estis proponita al la ŝtofo, kaj la EPG interagis kun la ekzistanta reto tra L3OUT, dum la interagado inter L3OUT kaj EPG. estis priskribita uzante kontraktojn. Proksimuma diagramo:
Specimena strukturo de la plej multaj ACI-fabrikpolitikoj estas montrita en la figuro malsupre. La tuta aranĝo baziĝas sur politikoj nestitaj ene de aliaj politikoj ktp. Komence estas tre malfacile eltrovi ĝin, sed iom post iom, kiel praktiko montras, retaj administrantoj alkutimiĝas al ĉi tiu strukturo en ĉirkaŭ unu monato, kaj poste ili nur komencas kompreni kiom oportuna ĝi estas.
Komparo
En la Cisco ACI-solvo, vi devas aĉeti pli da ekipaĵo (apartaj ŝaltiloj por Inter-Pod-interago kaj APIC-regiloj), kio faras ĝin pli multekosta. La solvo de Juniper ne postulis la aĉeton de regiloj aŭ akcesoraĵoj; Eblis parte uzi la ekzistantan ekipaĵon de la kliento.
Jen la ŝtofa arkitekturo EVPN VXLAN por du datumcentroj de la dua projekto:
Kun ACI vi ricevas pretan solvon - ne necesas ruĉi, ne bezonas optimumigi. Dum la komenca konatiĝo de la kliento kun la fabriko, neniuj programistoj estas bezonataj, neniuj subtenaj homoj estas bezonataj por kodo kaj aŭtomatigo. Ĝi estas sufiĉe facila por uzi; multaj agordoj povas esti faritaj per la sorĉisto, kio ne ĉiam estas pluso, precipe por homoj alkutimiĝintaj al la komandlinio. Ĉiukaze, necesas tempo por rekonstrui la cerbon sur novaj vojoj, al la proprecoj de agordoj per politikoj kaj funkciado kun multaj nestitaj politikoj. Aldone al tio, estas tre dezirinde havi klaran strukturon por nomi politikojn kaj objektojn. Se iu problemo aperas en la logiko de la regilo, ĝi povas esti solvita nur per teknika subteno.
En EVPN - konzolo. Suferu aŭ ĝoju. Konata interfaco por la maljuna gvardio. Jes, ekzistas norma agordo kaj gvidiloj. Vi devos fumi manaon. Malsamaj dezajnoj, ĉio estas klara kaj detala.
Kompreneble, en ambaŭ kazoj, dum migrado, estas pli bone migri unue ne la plej kritikajn servojn, ekzemple, testajn mediojn, kaj nur tiam, kaptinte ĉiujn cimojn, procedi al produktado. Kaj ne agordu vendrede vespere. Vi ne devus fidi la vendiston, ke ĉio estos en ordo, ĉiam estas pli bone ludi ĝin sekure.
Vi pagas pli por ACI, kvankam Cisco nuntempe aktive reklamas ĉi tiun solvon kaj ofte donas bonajn rabatojn pri ĝi, sed vi ŝparas pri bontenado. Administrado kaj ajna aŭtomatigo de EVPN-fabriko sen regilo postulas investojn kaj regulajn kostojn - monitorado, aŭtomatigo, efektivigo de novaj servoj. En la sama tempo, la komenca lanĉo ĉe ACI daŭras 30-40 procentojn pli longe. Ĉi tio okazas ĉar necesas pli longe krei la tutan aron de necesaj profiloj kaj politikoj, kiuj tiam estos uzataj. Sed kiam la reto kreskas, la nombro da bezonataj agordoj malpliiĝas. Vi uzas antaŭkreitajn politikojn, profilojn, objektojn. Vi povas flekseble agordi segmentadon kaj sekurecon, centre administri kontraktojn, kiuj respondecas pri permesi iujn interagojn inter EPGoj - la kvanto de laboro malpliiĝas akre.
En EVPN, vi devas agordi ĉiun aparaton en la fabriko, la verŝajneco de eraroj estas pli granda.
Dum ACI estis pli malrapida efektivigi, EVPN daŭris preskaŭ duoble pli longe por sencimigi. Se en la kazo de Cisco vi ĉiam povas voki subtenan inĝenieron kaj demandi pri la reto entute (ĉar ĝi estas kovrita kiel solvo), tiam de Juniper Networks vi nur aĉetas aparataron, kaj tio estas kovrita. Ĉu la pakaĵoj forlasis la aparaton? Nu, bone, tiam viaj problemoj. Sed vi povas malfermi demandon pri la elekto de solvo aŭ reto-dezajno - kaj tiam ili konsilos vin aĉeti profesian servon, kontraŭ plia kotizo.
ACI-subteno estas tre bonega, ĉar ĝi estas aparta: aparta teamo sidas nur por tio. Estas ankaŭ ruslingvaj specialistoj. La gvidilo estas detala, la solvoj estas antaŭdeterminitaj. Ili rigardas kaj konsilas. Ili rapide validas la dezajnon, kiu ofte gravas. Juniper Networks faras la samon, sed multe pli malrapide (ni havis ĉi tion, nun ĝi devus esti pli bona laŭ onidiroj), kio devigas vin fari ĉion mem, kie solvo-inĝeniero povus konsili.
Cisco ACI subtenas integriĝon kun virtualigo kaj kontenerigaj sistemoj (VMware, Kubernetes, Hyper-V) kaj centralizita administrado. Havebla kun retaj kaj sekurecaj servoj - ekvilibro, fajroŝirmiloj, WAF, IPS, ktp... Bona mikro-segmentado el la skatolo. En la dua solvo, integriĝo kun retaj servoj estas facila, kaj estas pli bone diskuti forumojn anticipe kun tiuj, kiuj faris tion.
La rezulto
Por ĉiu specifa kazo, necesas elekti solvon, ne nur bazitan sur la kosto de la ekipaĵo, sed ankaŭ necesas konsideri pliajn operaciajn kostojn kaj la ĉefajn problemojn, kiujn la kliento nuntempe alfrontas, kaj kiajn planas tie. estas por la evoluo de la IT-infrastrukturo.
ACI, pro kroma ekipaĵo, estis pli multekosta, sed la solvo estas preta sen la bezono de plia finaĵo; la dua solvo estas pli kompleksa kaj multekosta rilate funkciadon, sed pli malmultekosta.
Se vi volas diskuti kiom eble kostos efektivigi retan ŝtofon ĉe malsamaj vendistoj, kaj kia arkitekturo necesas, vi povas renkontiĝi kaj babili. Ni konsilos vin senpage ĝis vi ricevos malglatan skizon de la arkitekturo (per kiu vi povas kalkuli buĝetojn), detala ellaborado, kompreneble, jam estas pagita.
Vladimir Klepche, kompaniaj retoj.
fonto: www.habr.com