Evalueer die skakels in die middelste deel van die stroombaan. Ons sal hieronder na hulle terugkeer.
Op 'n sekere punt kan jy vind dat groot komplekse netwerke gebaseer op L2 terminaal siek is. Eerstens, probleme wat verband hou met die verwerking van BUM-verkeer en die werking van die STP-protokol. In die tweede - in die algemeen, moreel verouderde argitektuur. Dit veroorsaak onaangename probleme in die vorm van stilstand en ongerief van hantering.
Ons het twee parallelle projekte gehad, waar kliënte nugter al die voor- en nadele van die opsies beoordeel het en twee verskillende oorlegoplossings gekies het, en ons het dit geïmplementeer.
Dit was moontlik om die implementering te vergelyk. Nie operasie nie, dit is die moeite werd om oor twee of drie jaar daaroor te praat.
So, wat is 'n netwerkmateriaal met oorlegnetwerke en SDN?
Wat om te doen met die seer probleme van klassieke netwerkargitektuur?
Nuwe tegnologieë en idees verskyn elke jaar. In die praktyk het die dringende behoefte om die netwerke te herbou nie lank ontstaan nie, want jy kan ook alles met die hand doen deur die goeie ou oupa-metodes te gebruik. So wat, wat is die een-en-twintigste eeu in die tuin? Op die ou end moet die administrateur werk, en nie in sy kantoor sit nie.
Toe het 'n oplewing in die bou van grootskaalse datasentrums begin. Toe het dit duidelik geword dat die grens van die ontwikkeling van klassieke argitektuur bereik is, nie net wat prestasie, fouttoleransie, skaalbaarheid betref nie. En een van die opsies om hierdie probleme op te los, was die idee om oorlegnetwerke bo-op 'n roeteerbare ruggraat te bou.
Daarbenewens, met die toename in die skaal van netwerke, het die probleem om sulke fabrieke te bestuur akuut geword, as gevolg waarvan sagteware-gedefinieerde netwerkoplossings begin verskyn het met die vermoë om die hele netwerkinfrastruktuur as 'n geheel te bestuur. En wanneer die netwerk vanaf 'n enkele punt bestuur word, is dit makliker vir ander komponente van die IT-infrastruktuur om daarmee te kommunikeer, en sulke interaksieprosesse is makliker om te outomatiseer.
Byna elke groot vervaardiger van nie net netwerktoerusting nie, maar ook virtualisering, het opsies vir sulke oplossings in sy portefeulje.
Dit bly net om uit te vind wat geskik is vir watter behoeftes. Byvoorbeeld, vir veral groot maatskappye met 'n goeie ontwikkeling- en bedryfspan, voldoen verkopers se out-of-the-box-oplossings nie altyd aan alle behoeftes nie, en hulle wend hulle tot die ontwikkeling van hul eie SD (sagteware-gedefinieerde) oplossings. Dit is byvoorbeeld wolkverskaffers wat voortdurend die reeks dienste wat aan hul kliënte verskaf word, uitbrei, en boksoplossings kan eenvoudig nie tred hou met hul behoeftes nie.
Vir mediumgrootte ondernemings is die funksionaliteit wat deur die verkoper in die vorm van 'n boksoplossing aangebied word, genoeg in 99 persent van die gevalle.
Wat is oorlegnetwerke
Wat is die idee van oorlegnetwerke. Basies neem jy 'n klassieke roetenetwerk en bou 'n ander netwerk bo-op dit om meer funksies te kry. Meestal praat ons oor die effektiewe verspreiding van die las op toerusting en kommunikasielyne, 'n aansienlike toename in die skaalbaarheidslimiet, verhoogde betroubaarheid en 'n klomp sekuriteitsgoedjies (as gevolg van segmentering). En SDN-oplossings, benewens hierdie, maak baie, baie, baie gerieflike buigsame administrasie moontlik en maak die netwerk meer deursigtig vir sy verbruikers.
Oor die algemeen, as plaaslike netwerke in die jare van die 2010's uitgevind is, sou hulle ver lyk van wat ons van die weermag van die 1970's geërf het.
Wat tegnologieë betref vir die bou van fabrieke deur oorlegnetwerke te gebruik, is daar tans baie implementerings van vervaardigers en Internet RFC-projekte (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve en ander). Ja, daar is standaarde, maar die implementering van hierdie standaarde deur verskillende vervaardigers kan verskil, so wanneer sulke fabrieke geskep word, is dit steeds moontlik om die verkoperslot heeltemal te laat vaar, slegs in teorie op papier.
Met die SD-oplossing is dinge selfs meer ingewikkeld, elke verkoper het sy eie visie. Daar is heeltemal oop oplossings wat jy in teorie op jou eie kan voltooi, daar is heeltemal geslote.
Cisco bied sy eie weergawe van SDN vir datasentrums - ACI. Natuurlik is dit 'n 100% verskaffer-geslote oplossing in terme van die keuse van netwerktoerusting, maar dit is terselfdertyd ten volle geïntegreer met virtualisering, houerisering, sekuriteit, orkestrasie, lasbalanseerders, ens. Maar in werklikheid is dit steeds 'n soort van swart boks, sonder die moontlikheid van volle toegang tot alle interne prosesse. Nie alle kliënte stem in tot hierdie opsie nie, aangesien jy heeltemal afhanklik is van die kwaliteit van die geskrewe oplossingskode en die implementering daarvan, maar aan die ander kant het die vervaardiger een van die beste tegniese ondersteuning ter wêreld en het 'n toegewyde span wat handel dryf slegs met hierdie oplossing. Cisco ACI is gekies as die oplossing vir die eerste projek.
Vir die tweede projek is 'n Juniper-oplossing gekies. Die vervaardiger het ook sy eie SDN vir die datasentrum, maar die kliënt het besluit om nie SDN te implementeer nie. Die EVPN VXLAN-fabriek is gekies as die tegnologie vir die bou van die netwerk sonder die gebruik van gesentraliseerde beheerders.
Waarvoor is dit
Deur 'n fabriek te skep, kan jy 'n maklik skaalbare, foutverdraagsame, betroubare netwerk bou. Die argitektuur (blaar-ruggraat) neem die kenmerke van datasentrums (verkeerspaaie, minimalisering van vertragings en knelpunte in die netwerk) in ag. SD-oplossings in datasentrums maak dit baie gerieflik, vinnig, buigsaam om so 'n fabriek te bestuur, dit in die datasentrum-ekosisteem te integreer.
Beide kliënte moes oortollige datasentrums bou om foutverdraagsaamheid te verseker, daarbenewens moes verkeer tussen datasentrums geïnkripteer word.
Die eerste kliënt het reeds stoflose oplossings as 'n moontlike standaard vir hul netwerke oorweeg, maar in toetse het hulle probleme gehad met STP-versoenbaarheid tussen verskeie hardewareverkopers. Daar was stilstand wat diensdalings veroorsaak het. En vir die kliënt was dit krities.
Cisco was reeds die kliënt se ondernemingstandaard, hulle het na ACI en ander opsies gekyk en besluit dat dit die moeite werd is om hierdie spesifieke oplossing te neem. Ek het gehou van die outomatisering van beheer vanaf een knoppie deur 'n enkele kontroleerder. Dienste word vinniger opgestel, vinniger bestuur. Ons het besluit om verkeerskodering te verskaf deur MACSec tussen die IPN- en SPINE-skakelaars uit te voer. Dit was dus moontlik om 'n bottelnek in die vorm van 'n kripto-poort te vermy, op hulle te bespaar en die bandwydte tot die maksimum te gebruik.
Die tweede kliënt het Juniper se beheerlose oplossing gekies omdat hul bestaande datasentrum reeds 'n klein installasie met 'n EVPN VXLAN-stofimplementering gehad het. Maar daar was dit nie foutverdraagsaam nie (een skakelaar is gebruik). Ons het besluit om die infrastruktuur van die hoofdatasentrum uit te brei en 'n fabriek in die rugsteundatasentrum te bou. Die bestaande EVPN is nie ten volle benut nie: VXLAN-inkapseling is nie eintlik gebruik nie, aangesien alle gashere aan dieselfde skakelaar gekoppel was, en alle MAC-adresse en /32-gasheeradresse plaaslik was, was dieselfde skakelaar die poort vir hulle, daar was geen ander toestelle, waar dit nodig was om VXLAN-tonnels te bou. Hulle het besluit om verkeerskodering te verskaf met behulp van IPSEC-tegnologie tussen brandmure (ITU-werkverrigting was voldoende).
Hulle het ook ACI probeer, maar het besluit dat hulle weens die verkoperslot te veel hardeware sal moet koop, insluitend die vervanging van onlangs aangekoopte nuwe toerusting, en dit maak eenvoudig nie ekonomies sin nie. Ja, die Cisco-stof integreer met alles, maar slegs sy toestelle is moontlik binne die stof self.
Aan die ander kant, soos vroeër genoem, kan u nie net 'n EVPN VXLAN-fabriek met enige naburige verkoper meng nie, want die protokolimplementerings verskil. Dit is soos om Cisco en Huawei in dieselfde netwerk te kruis – dit blyk dat die standaarde algemeen is, net jy moet met 'n tamboeryn dans. Aangesien dit 'n bank is, en versoenbaarheidstoetse baie lank sou wees, het ons besluit dat dit beter is om nou by dieselfde verkoper te koop, en nie regtig meegevoer te raak met funksionaliteit verder as die basis een nie.
Migrasieplan
Twee datasentrums gebaseer op ACI:
Organisasie van interaksie tussen datasentrums. 'n Multi-Pod-oplossing is gekies - elke datasentrum is 'n peul. Die vereistes vir skaal volgens die aantal skakelaars en vertragings tussen peule (RTT minder as 50 ms) word in ag geneem. Daar is besluit om nie 'n Multi-Site-oplossing te bou vir gemak van bestuur nie ('n enkele bestuurskoppelvlak word gebruik vir 'n Multi-Pod-oplossing, vir Multi-Site sal daar twee koppelvlakke wees, of 'n Multi-Site Orchestrator sal vereis word), en aangesien geen geografiese bespreking van terreine nodig was nie.
Uit die oogpunt van migrasie van dienste vanaf die Legacy-netwerk, is die mees deursigtige opsie gekies, geleidelik oordra VLAN's wat ooreenstem met sekere dienste.
Vir migrasie is 'n ooreenstemmende EPG (Eindpunt-groep) vir elke VLAN by die fabriek geskep. Eerstens is die netwerk tussen die ou netwerk en die fabriek langs L2 gespan, dan na die migrasie van alle gashere, is die poort na die fabriek oorgeplaas, en die EPG het deur L3OUT met die bestaande netwerk in wisselwerking gekom, terwyl die interaksie tussen L3OUT en EPG is beskryf deur gebruik te maak van kontrakte. Geskatte skema:
Die benaderde struktuur van die meeste ACI-fabriekspolisse word in die onderstaande figuur getoon. Die hele instelling is gebaseer op beleide wat in ander beleide geneste is, ensovoorts. Aanvanklik is dit baie moeilik om dit uit te vind, maar geleidelik, soos die praktyk toon, raak netwerkadministrateurs binne ongeveer 'n maand gewoond aan so 'n struktuur, en dan kom eers die begrip van hoe gerieflik dit is.
vergelyking
In die Cisco ACI-oplossing moet jy meer toerusting koop (aparte skakelaars vir Inter-Pod-interaksie en APIC-beheerders), waardeur dit duurder geblyk het te wees. Juniper se oplossing het nie die aankoop van beheerders en bykomstighede vereis nie; dit het geblyk die reeds bestaande toerusting van die kliënt gedeeltelik te gebruik.
Hier is die EVPN VXLAN-stofargitektuur vir die twee datasentrums van die tweede projek:
In ACI kry jy 'n klaargemaakte oplossing - nie nodig om te kies nie, nie nodig om te optimaliseer nie. By die aanvanklike kennismaking van die kliënt met die fabriek is ontwikkelaars nie nodig nie, ondersteunende mense is nie nodig vir kode en outomatisering nie. Eenvoudige bewerking is genoeg, baie instellings kan oor die algemeen deur 'n towenaar gedoen word, wat nie altyd 'n pluspunt is nie, veral vir mense wat gewoond is aan die opdragreël. Dit neem in elk geval tyd om die brein op nuwe spore te herbou, op die eienaardighede van instellings deur middel van beleide en werk op 'n menigte geneste beleide. Dit is hoogs wenslik, benewens dit, om 'n duidelike struktuur te hê vir die benoeming van beleide en voorwerpe. As daar enige probleem in die logika van die beheerder is, kan dit slegs deur tegniese ondersteuning opgelos word.
In EVPN, die konsole. Ly of wees bly. Bekende koppelvlak vir die ou garde. Ja, daar is 'n tipiese opset en gidse. Jy moet mana rook. Verskillende ontwerpe, alles is duidelik en gedetailleerd.
Natuurlik, in beide gevalle, is dit beter om nie eers die mees kritieke dienste te migreer nie, byvoorbeeld toetsomgewings, en eers dan, nadat al die foute opgespoor is, voort te gaan na produksie. En moenie Vrydagaand inskakel nie. Jy moet nie die verkoper vertrou dat alles in orde sal wees nie, dit is altyd beter om veilig te speel.
Jy betaal meer op ACI, hoewel Cisco tans hierdie oplossing aktief bevorder en dikwels goeie afslag daarvoor gee, maar jy bespaar op onderhoud. Bestuur en enige soort outomatisering van 'n EVPN-fabriek sonder 'n beheerder vereis beleggings en gereelde koste - monitering, outomatisering, implementering van nuwe dienste. Terselfdertyd neem die aanvanklike bekendstelling van ACI 30–40 persent langer. Dit is omdat dit langer neem om die hele stel nodige profiele en beleide te skep, wat dan gebruik sal word. Maar soos die netwerk groei, neem die aantal konfigurasies wat nodig is af. Jy gebruik reeds vooraf-geskepte beleide, profiele, voorwerpe. Jy kan segmentering en sekuriteit buigsaam opstel, kontrakte sentraal bestuur wat verantwoordelik is vir die oplossing van sekere interaksies tussen EPG - die hoeveelheid werk daal skerp.
In EVPN moet u elke toestel in die fabriek konfigureer, die waarskynlikheid van foute is groter.
As ACI stadiger is om te implementeer, het EVPN amper twee keer so lank geneem om te ontfout. As jy in die geval van Cisco altyd 'n ondersteuningsingenieur kan bel en vra oor die netwerk as 'n geheel (omdat dit as 'n oplossing gedek word), dan koop jy net hardeware by Juniper Networks, en dit is wat gedek word. Pakkies het die toestel verlaat? Goed, dan jou probleme. Maar jy kan 'n vraag oopmaak oor die keuse van 'n oplossing of netwerkontwerp - en dan sal hulle jou aanraai om 'n professionele diens te koop, teen 'n bykomende fooi.
ACI-ondersteuning is baie gaaf, want dit is apart: 'n aparte span sit net hiervoor. Daar is, insluitend Russiessprekende spesialiste. Die gids is gedetailleerd, die besluite is vooraf bepaal. Kyk en gee raad. Hulle bevestig vinnig die ontwerp, wat dikwels belangrik is. Juniper Networks doen dieselfde ding, maar soms stadiger (ons het dit vroeër gedoen, nou behoort dit volgens gerugte beter te wees), wat jou dwing om alles self te doen waar 'n oplossingsingenieur kan adviseer.
Cisco ACI ondersteun integrasie met virtualisering en houerstelsels (VMware, Kubernetes, Hyper-V) en gesentraliseerde bestuur. Daar is netwerk- en sekuriteitsdienste - balansering, brandmure, WAF, IPS, ens. Goeie mikro-segmentering uit die boks. In die tweede oplossing word integrasie met netwerkdienste met 'n tamboeryn gedoen, en dit is beter om forums te rook met diegene wat dit vooraf gedoen het.
Totale
Vir elke spesifieke geval is dit nodig om 'n oplossing te kies, nie net gebaseer op die koste van toerusting nie, maar dit is ook nodig om verdere bedryfskoste en die hoofprobleme wat die kliënt nou in die gesig staar in ag te neem, en wat is die planne vir die ontwikkeling van IT-infrastruktuur.
ACI as gevolg van bykomende toerusting het duurder uitgekom, maar die oplossing is gereed sonder die behoefte aan bykomende saag, die tweede oplossing is meer ingewikkeld en duur in terme van werking, maar goedkoper.
As jy wil bespreek hoeveel dit kan kos om 'n netwerkfabriek op verskillende verskaffers te implementeer, en watter soort argitektuur nodig is, kan jy ontmoet en gesels. Voor die rowwe skets van die argitektuur (waarmee jy die begrotings kan bereken), sal ons jou 'n gratis wenk gee, 'n gedetailleerde studie is natuurlik reeds betaal.
Vladimir Klepche, korporatiewe netwerke.
Bron: will.com