Evalueer de verbindingen in het middelste deel van het diagram. Hieronder komen we op hen terug
Op een gegeven moment zul je merken dat grote, complexe L2-gebaseerde netwerken terminaal ziek zijn. Allereerst problemen die verband houden met het verwerken van BUM-verkeer en de werking van het STP-protocol. Ten tweede is de architectuur over het algemeen verouderd. Dit veroorzaakt onaangename problemen in de vorm van stilstand en ongemakkelijke bediening.
We hadden twee parallelle projecten, waarbij de klanten nuchter alle voor- en nadelen van de opties afgewogen hadden en twee verschillende overlay-oplossingen kozen, en die hebben we geïmplementeerd.
Er was gelegenheid om de uitvoering te vergelijken. Geen uitbuiting; we moeten er over twee of drie jaar over praten.
Wat is een netwerkstructuur met overlay-netwerken en SDN?
Wat te doen met de prangende problemen van de klassieke netwerkarchitectuur?
Elk jaar verschijnen er nieuwe technologieën en ideeën. In de praktijk heeft de dringende noodzaak om netwerken opnieuw op te bouwen zich lange tijd niet voorgedaan, omdat alles met de hand doen op de ouderwetse manier ook mogelijk is. Dus wat als het de eenentwintigste eeuw is? Een beheerder moet immers werken en niet op zijn kantoor zitten.
Toen begon een hausse in de bouw van grootschalige datacenters. Toen werd duidelijk dat de ontwikkelingslimiet van de klassieke architectuur was bereikt, niet alleen op het gebied van prestaties, fouttolerantie en schaalbaarheid. En een van de opties om deze problemen op te lossen was het idee om overlay-netwerken te bouwen bovenop een gerouteerde backbone.
Bovendien is met de toename van de schaal van netwerken het probleem van het beheer van dergelijke fabrieken acuut geworden, als gevolg waarvan softwaregedefinieerde netwerkoplossingen begonnen te verschijnen met de mogelijkheid om de gehele netwerkinfrastructuur als één geheel te beheren. En wanneer het netwerk vanuit één punt wordt beheerd, kunnen andere componenten van de IT-infrastructuur er gemakkelijker mee communiceren, en zijn dergelijke interactieprocessen gemakkelijker te automatiseren.
Bijna elke grote fabrikant van niet alleen netwerkapparatuur, maar ook van virtualisatie heeft opties voor dergelijke oplossingen in zijn portfolio.
Het enige dat overblijft is om erachter te komen wat geschikt is voor welke behoeften. Voor bijzonder grote bedrijven met een goed ontwikkelings- en exploitatieteam voldoen pakketoplossingen van leveranciers bijvoorbeeld niet altijd aan alle behoeften, en nemen zij hun toevlucht tot het ontwikkelen van hun eigen SD-oplossingen (software-gedefinieerde). Dit zijn bijvoorbeeld cloudproviders die het dienstenaanbod aan hun klanten voortdurend uitbreiden, en pakketoplossingen kunnen eenvoudigweg niet aan hun behoeften voldoen.
Voor middelgrote bedrijven is de functionaliteit die de leverancier biedt in de vorm van een boxed-oplossing in 99 procent van de gevallen voldoende.
Wat zijn overlay-netwerken?
Wat is het idee achter overlay-netwerken? In wezen neem je een klassiek gerouteerd netwerk en bouw je er nog een netwerk bovenop om meer functies te krijgen. Meestal hebben we het over het effectief verdelen van de belasting op apparatuur en communicatielijnen, het aanzienlijk verhogen van de schaalbaarheidslimiet, het vergroten van de betrouwbaarheid en een heleboel beveiligingsvoordelen (vanwege segmentatie). En daarnaast bieden SDN-oplossingen de mogelijkheid voor heel, heel, heel handig flexibel beheer en maken ze het netwerk transparanter voor zijn consumenten.
Als lokale netwerken in de jaren 2010 waren uitgevonden, zouden ze er over het algemeen heel anders hebben uitgezien dan wat we in de jaren zeventig van het leger hebben geërfd.
Op het gebied van technologieën voor het bouwen van fabrics met behulp van overlay-netwerken zijn er momenteel veel leveranciersimplementaties en internet-RFC-projecten (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve en andere). Ja, er zijn normen, maar de implementatie van deze normen door verschillende fabrikanten kan verschillen, dus bij het creëren van dergelijke fabrieken is het nog steeds mogelijk om de leveranciersvergrendeling alleen in theorie op papier volledig op te geven.
Met een SD-oplossing zijn de zaken nog verwarrender; elke leverancier heeft zijn eigen visie. Er zijn volledig open oplossingen die je in theorie zelf kunt invullen, en er zijn volledig gesloten oplossingen.
Cisco biedt zijn versie van SDN voor datacenters aan: ACI. Uiteraard is dit een 100% leveranciersafhankelijke oplossing wat betreft de keuze van netwerkapparatuur, maar tegelijkertijd is het volledig geïntegreerd met virtualisatiesystemen, containerisatie, beveiliging, orkestratie, load balancers, enz. Maar in essentie is het nog steeds een een soort black box, zonder de mogelijkheid van volledige toegang tot alle interne processen. Niet alle klanten zijn het met deze optie eens, omdat u volledig afhankelijk bent van de kwaliteit van de geschreven oplossingscode en de implementatie ervan, maar aan de andere kant heeft de fabrikant een van de beste technische ondersteuning ter wereld en heeft hij een toegewijd team dat zich uitsluitend bezighoudt met aan deze oplossing. Als oplossing voor het eerste project werd Cisco ACI gekozen.
Voor het tweede project werd gekozen voor een Juniper-oplossing. De fabrikant heeft ook een eigen SDN voor het datacenter, maar de klant heeft besloten SDN niet te implementeren. Als netwerkconstructietechnologie werd gekozen voor een EVPN VXLAN-fabric zonder het gebruik van gecentraliseerde controllers.
Waar is het voor?
Door een fabriek te creëren, kunt u een eenvoudig schaalbaar, fouttolerant en betrouwbaar netwerk bouwen. De architectuur (leaf-spine) houdt rekening met de kenmerken van datacenters (verkeerspaden, het minimaliseren van vertragingen en knelpunten in het netwerk). Met SD-oplossingen in datacenters kunt u zo’n fabriek heel handig, snel en flexibel beheren en integreren in het datacenter-ecosysteem.
Beide klanten moesten redundante datacenters bouwen om fouttolerantie te garanderen, en bovendien moest het verkeer tussen de datacenters worden gecodeerd.
De eerste klant overwoog al fabricless-oplossingen als mogelijke standaard voor hun netwerken, maar bij tests ondervonden ze problemen met de STP-compatibiliteit tussen verschillende hardwareleveranciers. Er waren downtimes waardoor services vastliepen. En voor de klant was dit cruciaal.
Cisco was al de bedrijfsstandaard van de klant, ze keken naar ACI en andere opties en besloten dat het de moeite waard was om deze oplossing te nemen. Ik vond de automatisering van de bediening vanaf één knop via één enkele controller leuk. Services worden sneller geconfigureerd en sneller beheerd. We hebben besloten om verkeersversleuteling te garanderen door MACSec uit te voeren tussen de IPN- en SPINE-switches. Zo zijn we erin geslaagd het knelpunt in de vorm van een cryptogateway te vermijden, daarop te besparen en de maximale bandbreedte te gebruiken.
De tweede klant koos voor een controllerloze oplossing van Juniper omdat hun bestaande datacenter al over een kleine installatie beschikte waarin een EVPN VXLAN-fabric was geïmplementeerd. Maar daar was het niet fouttolerant (er werd één schakelaar gebruikt). We besloten de infrastructuur van het hoofddatacenter uit te breiden en een fabriek te bouwen in het back-updatacenter. De bestaande EVPN werd niet volledig gebruikt: VXLAN-inkapseling werd niet daadwerkelijk gebruikt, aangezien alle hosts op één switch waren aangesloten en alle MAC-adressen en /32 hostadressen lokaal waren, de gateway daarvoor was dezelfde switch, er waren geen andere apparaten , waar het nodig was om VXLAN-tunnels te bouwen. Ze besloten om verkeersversleuteling te garanderen met behulp van IPSEC-technologie tussen firewalls (de prestaties van de firewall waren voldoende).
Ze probeerden ook ACI, maar kwamen tot de conclusie dat ze vanwege de leveranciersblokkering te veel hardware zouden moeten kopen, inclusief het vervangen van onlangs aangeschafte nieuwe apparatuur, en dat dit economisch simpelweg niet logisch was. Ja, de Cisco-fabric integreert met alles, maar alleen de apparaten ervan zijn mogelijk binnen de fabric zelf.
Aan de andere kant kun je, zoals we al eerder zeiden, niet zomaar een EVPN VXLAN-fabric combineren met een naburige leverancier, omdat de protocolimplementaties anders zijn. Het is alsof je Cisco en Huawei in één netwerk kruist: het lijkt alsof de standaarden gemeenschappelijk zijn, maar je zult moeten dansen met een tamboerijn. Omdat dit een bank is en de compatibiliteitstests erg lang zouden duren, hebben we besloten dat het beter was om nu bij dezelfde leverancier te kopen en ons niet te veel te laten meeslepen door functionaliteit die verder gaat dan de basisfuncties.
Migratieplan
Twee op ACI gebaseerde datacenters:
Organisatie van interactie tussen datacenters. Er werd gekozen voor de Multi-Pod-oplossing: elk datacenter is een pod. Er wordt rekening gehouden met de vereisten voor schaling met het aantal schakelaars en vertragingen tussen pods (RTT minder dan 50 ms). Er werd besloten om geen Multi-Site-oplossing te bouwen vanwege het beheergemak (een Multi-Pod-oplossing gebruikt één enkele beheerinterface, een Multi-Site zou twee interfaces hebben, of zou een Multi-Site Orchestrator vereisen), en aangezien er geen geografische reservering van locaties was vereist.
Vanuit het oogpunt van het migreren van diensten vanuit het Legacy-netwerk werd gekozen voor de meest transparante optie, waarbij VLAN's die overeenkomen met bepaalde diensten geleidelijk worden overgedragen.
Voor de migratie werd in de fabriek voor elk VLAN een overeenkomstige EPG (End-point-group) gemaakt. Eerst werd het netwerk uitgerekt tussen het oude netwerk en de fabric over L2. Nadat alle hosts waren gemigreerd, werd de gateway naar de fabric verplaatst en communiceerde de EPG met het bestaande netwerk via L3OUT, terwijl de interactie tussen L3OUT en EPG werd beschreven aan de hand van contracten. Geschat diagram:
Een voorbeeldstructuur van het meeste ACI-fabrieksbeleid wordt weergegeven in de onderstaande afbeelding. De hele opzet is gebaseerd op beleid dat is genest in ander beleid, enzovoort. In het begin is het erg moeilijk om erachter te komen, maar geleidelijk, zoals de praktijk laat zien, wennen netwerkbeheerders binnen ongeveer een maand aan deze structuur, en dan beginnen ze pas te begrijpen hoe handig het is.
Сравнение
Bij de Cisco ACI-oplossing moet je meer apparatuur kopen (afzonderlijke schakelaars voor Inter-Pod-interactie en APIC-controllers), wat het duurder maakt. Voor de oplossing van Juniper waren geen controllers of accessoires nodig; Het was mogelijk om de bestaande apparatuur van de klant gedeeltelijk te gebruiken.
Hier is de EVPN VXLAN-fabricarchitectuur voor twee datacenters van het tweede project:
Met ACI krijgt u een kant-en-klare oplossing - u hoeft niet te sleutelen, u hoeft niet te optimaliseren. Tijdens de eerste kennismaking van de klant met de fabriek zijn er geen ontwikkelaars nodig, geen ondersteunende mensen nodig voor code en automatisering. Het is vrij eenvoudig te gebruiken; veel instellingen kunnen worden gedaan via de wizard, wat niet altijd een pluspunt is, vooral voor mensen die gewend zijn aan de opdrachtregel. Hoe dan ook, het kost tijd om het brein opnieuw op te bouwen op nieuwe sporen, naar de eigenaardigheden van de instellingen, door middel van beleid en het werken met veel genest beleid. Daarnaast is het zeer wenselijk om een duidelijke structuur te hebben voor het benoemen van beleid en objecten. Als er zich een probleem voordoet in de logica van de controller, kan dit alleen worden opgelost via technische ondersteuning.
In EVPN - console. Lijd of verheug je. Een vertrouwde interface voor de oude garde. Ja, er is een standaardconfiguratie en handleidingen. Je zult mana moeten roken. Verschillende ontwerpen, alles is duidelijk en gedetailleerd.
Uiteraard is het in beide gevallen bij het migreren beter om eerst niet de meest kritische services te migreren, bijvoorbeeld testomgevingen, en pas daarna, nadat alle bugs zijn opgespoord, over te gaan tot productie. En stem niet af op vrijdagavond. Je moet de verkoper niet vertrouwen dat alles goed komt, het is altijd beter om op safe te spelen.
Je betaalt meer voor ACI, hoewel Cisco deze oplossing momenteel actief promoot en er vaak goede kortingen op geeft, maar je bespaart op onderhoud. Het beheer en de eventuele automatisering van een EVPN-fabriek zonder controller vergt investeringen en reguliere kosten: monitoring, automatisering, implementatie van nieuwe diensten. Tegelijkertijd duurt de eerste lancering bij ACI 30 tot 40 procent langer. Dit gebeurt omdat het langer duurt om de volledige set noodzakelijke profielen en beleid te maken die vervolgens zullen worden gebruikt. Maar naarmate het netwerk groeit, neemt het aantal vereiste configuraties af. U gebruikt vooraf gemaakt beleid, profielen en objecten. U kunt segmentatie en beveiliging flexibel configureren, contracten centraal beheren die verantwoordelijk zijn voor het toestaan van bepaalde interacties tussen EPG's - de hoeveelheid werk neemt sterk af.
In EVPN moet u elk apparaat in de fabriek configureren, de kans op fouten is groter.
Hoewel de implementatie van ACI langzamer verliep, duurde het debuggen van EVPN bijna twee keer zo lang. Als je in het geval van Cisco altijd een support engineer kunt bellen en vragen kunt stellen over het netwerk als geheel (omdat dit als oplossing wordt gedekt), dan koop je bij Juniper Networks alleen hardware, en dat is wat er onder de dekking valt. Hebben de pakketten het apparaat verlaten? Nou, oké, dan zijn je problemen. Maar u kunt een vraag stellen over de keuze van de oplossing of het netwerkontwerp - en dan zullen zij u adviseren om tegen een extra vergoeding een professionele dienst aan te schaffen.
ACI-ondersteuning is erg cool, omdat het gescheiden is: er zit een apart team speciaal voor. Er zijn ook Russischsprekende specialisten. De gids is gedetailleerd, de oplossingen zijn vooraf bepaald. Ze kijken en adviseren. Ze valideren het ontwerp snel, wat vaak belangrijk is. Juniper Networks doet hetzelfde, maar veel langzamer (we hadden dit, nu zou het volgens de geruchten beter moeten zijn), wat je dwingt om alles zelf te doen waar een oplossingsingenieur advies kan geven.
Cisco ACI ondersteunt integratie met virtualisatie- en containerisatiesystemen (VMware, Kubernetes, Hyper-V) en gecentraliseerd beheer. Beschikbaar met netwerk- en beveiligingsservices - balancering, firewalls, WAF, IPS, enz... Goede out-of-the-box goede microsegmentatie. Bij de tweede oplossing is de integratie met netwerkdiensten een fluitje van een cent, en is het beter om vooraf forums te bespreken met degenen die dit hebben gedaan.
Totaal
Voor elk specifiek geval is het noodzakelijk om een oplossing te selecteren, niet alleen op basis van de kosten van de apparatuur, maar ook om rekening te houden met verdere bedrijfskosten en de belangrijkste problemen waarmee de klant momenteel wordt geconfronteerd, en welke plannen daar voor zijn. zijn voor de ontwikkeling van de IT-infrastructuur.
ACI was vanwege extra apparatuur duurder, maar de oplossing is kant-en-klaar zonder de noodzaak van extra afwerking; de tweede oplossing is complexer en duurder qua bediening, maar goedkoper.
Als u wilt bespreken hoeveel het zou kunnen kosten om een netwerkstructuur op verschillende leveranciers te implementeren, en wat voor soort architectuur nodig is, kunt u elkaar ontmoeten en chatten. Wij adviseren u kosteloos totdat u een ruwe schets van de architectuur krijgt (waarmee u budgetten kunt berekenen), gedetailleerde uitwerking is uiteraard al betaald.
Vladimir Klepche, bedrijfsnetwerken.
Bron: www.habr.com