Evalueer de verbindingen in het midden van het schema. We komen hier later op terug.
Op een gegeven moment kun je geconfronteerd worden met grote complexe netwerken op basis van L2 die onherstelbaar ziek zijn. Primair zijn dit problemen met de verwerking van BUM-verkeer en met de werking van het STP-protocol. Secundair is de verouderde architectuur op zich. Dit resulteert in onaangename problemen zoals downtime en moeilijkheden bij het beheer.
We hadden twee parallelle projecten, waar de klant de voor- en nadelen van de opties realistisch inschatte en twee verschillende overlay-oplossingen koos, die wij implementeerden.
Er was de mogelijkheid om daadwerkelijk de implementatie te vergelijken. Niet de exploitatie, daarover kunnen we pas over twee of drie jaar iets zeggen.
Wat is dus een netwerkfabriek met overlay-netwerken en SDN?
Wat te doen met de hardnekkige problemen van de klassieke netwerkinfrastructuur?
Elk jaar komen er nieuwe technologieƫn en ideeƫn op. In de praktijk is de dringende noodzaak om netwerken opnieuw in te richten al een tijdlang niet aan de orde, omdat alles ook handmatig gedaan kon worden volgens de oude en vertrouwde methodes. En wat dan nog, we leven in de eenentwintigste eeuw? Uiteindelijk moet de beheerder werken, en niet alleen maar in zijn kantoor zitten.
Toen begon de boom van de bouw van grootschalige datacenters. Toen werd het duidelijk dat de ontwikkelingslimiet van de klassieke architectuur was bereikt, niet alleen op het gebied van functionaliteit, fouttolerantie en schaalbaarheid. Een van de mogelijke oplossingen voor deze problemen was het idee om overlay-netwerken bovenop een routerbare backbone te bouwen.
Bovendien, met de toenemende schaal van netwerken, kwam het probleem van het beheer van dergelijke fabrieken sterk naar voren, waardoor er oplossingen voor softwaregedefinieerde netwerken ontstonden waarmee de hele netwerkinfrastructuur als Ć©Ć©n geheel kan worden beheerd. Wanneer het netwerk vanuit Ć©Ć©n punt wordt beheerd, is het voor andere componenten van de IT-infrastructuur gemakkelijker om ermee samen te werken, en zulke interactieprocessen kunnen gemakkelijker worden geautomatiseerd.
Bijna elke grote fabrikant, niet alleen van netwerktechnologie, maar ook van virtualisatie, heeft varianten van dergelijke oplossingen in zijn portfolio.
Het blijft alleen nog te bepalen wat geschikt is voor welke behoeften. Voor bijzonder grote bedrijven met een goed team van ontwikkelaars en operations voldoen kant-en-klare oplossingen van leveranciers niet altijd aan alle behoeften, en zij gaan over tot de ontwikkeling van eigen SD (software-defined) oplossingen. Dit zijn bijvoorbeeld cloudproviders die voortdurend hun assortiment aan diensten voor hun klanten uitbreiden, en kant-en-klare oplossingen kunnen simpelweg niet bijbenen met hun behoeften.
Voor middelgrote bedrijven is de functionaliteit die door de leverancier in de vorm van een kant-en-klare oplossing wordt aangeboden in 99 procent van de gevallen voldoende.
Wat zijn overlay-netwerken?
Wat is het concept van overlay-netwerken? In feite neem je een klassieke routbare netwerkinfrastructuur en bouw je daarbovenop nog een netwerk om meer functionaliteiten te krijgen. Meestal heeft dit betrekking op een efficiƫnte belastingverdeling van apparatuur en verbindingen, een significante verhoging van de schaalbaarheid, verbeterde betrouwbaarheid en een hoop voordelen op het gebied van veiligheid (door segmentatie). Bovendien bieden SDN-oplossingen de mogelijkheid tot zeer, zeer, zeer flexibele administratie en maken ze het netwerk transparanter voor de gebruikers.
Als lokale netwerken in de jaren 2010 waren uitgevonden, zouden ze er heel anders hebben uitgezien dan wat we hebben geƫrfd van de militaire netwerken uit de jaren 1970.
Wat betreft de technologieƫn voor het bouwen van fabrieken met behulp van overlay-netwerken, zijn er momenteel veel implementaties van fabrikanten en internetprojecten RFC (EVPN+VXLAN, EVPN+MPLS, EVPN+MPLSoGRE, EVPN+Geneve en anderen). Ja, er zijn standaarden, maar de implementatie van deze standaarden door verschillende fabrikanten kan verschillen, waardoor het in de praktijk theoretisch mogelijk is om volledig van leverancierslock af te komen, maar dit blijft tot nu toe alleen op papier mogelijk.
Met SD-oplossingen is de situatie nog verwarrender; elke leverancier heeft zijn eigen visie. Er zijn volledig open oplossingen die in theorie zelf aangepast kunnen worden, en er zijn volledig gesloten oplossingen.
Cisco biedt zijn eigen SDN-oplossing voor datacenters - ACI. Dit is natuurlijk een 100% vendor-lock oplossing wat betreft de keuze van netwerk apparatuur, maar het integreert volledig met virtualisatie, containerisatie, beveiligingssystemen, orkestratie en load balancers. Toch blijft het in essentie een black box, zonder volledige toegang tot alle interne processen. Niet alle klanten staan achter zo'n oplossing, omdat je volledig afhankelijk bent van de kwaliteit van de geschreven code en de implementatie ervan. Aan de andere kant heeft de fabrikant een van de beste technische ondersteuningen ter wereld en een speciaal team dat zich uitsluitend bezighoudt met deze oplossing. Voor het eerste project werd gekozen voor Cisco ACI.
Voor het tweede project werd een oplossing van Juniper gekozen. De fabrikant heeft ook zijn SDN voor datacenters, maar de klant besloot om af te zien van de implementatie van SDN. Voor de netwerktechnologie werd gekozen voor een EVPN VXLAN-fabriek zonder gebruik te maken van gecentraliseerde controllers.
Waar is het voor nodig
Het creƫren van een fabriek maakt het mogelijk om een gemakkelijk schaalbaar, fouttolerant en betrouwbaar netwerk te bouwen. De architectuur (leaf-spine) houdt rekening met de kenmerken datacenters (traffic pathways, minimalisering van vertragingen en knelpunten in het netwerk). SD-oplossingen in datacenters maken het mogelijk om deze fabriek zeer handig, snel en flexibel te beheren en deze te integreren in het ecosysteem van het datacenter.
Beide klanten moesten reserve-datacenters opbouwen om fouttolerantie te waarborgen; daarnaast moest het verkeer tussen de datacenters worden versleuteld.
De eerste klant overwoog al oplossingen zonder fabriek als mogelijke standaard voor hun netwerken, maar zij ondervonden problemen met STP-compatibiliteit tussen verschillende hardwareleveranciers tijdens de tests. Dit leidde tot downtime, wat diensten beĆÆnvloedde. Voor de klant was dit kritiek.
Cisco was already the corporate standard for the customer; they considered ACI and other options and decided to go with this solution. They appreciated the automation of management with a single button through a unified controller. Services are set up faster and managed more quickly. They decided to ensure traffic encryption by launching MACSec between the IPN and SPINE switches. This way, they avoided a bottleneck with the crypto gateway, saved on them, and maximized bandwidth usage.
The second customer chose a controller-less solution from Juniper, as they already had a small installation with EVPN VXLAN fabric in their existing data center. However, it was not fault-tolerant (only one switch was used). They decided to expand the infrastructure of the main data center and build a fabric in the backup data center. The existing EVPN was not fully utilized: VXLAN encapsulation was not actually applied since all hosts were connected to a single switch, and all MAC addresses and /32 host addresses were local, with the switch itself serving as the gateway; there were no other devices for which VXLAN tunnels needed to be built. They decided to ensure traffic encryption using IPSEC technology between the firewalls (the MSE's performance was sufficient).
They also touched on ACI but decided that due to vendor lock-in, they would have to purchase too much hardware, including replacing recently bought equipment, which simply doesn't make economic sense. Yes, Cisco's fabric integrates with everything, but only its devices are possible within the fabric itself.
On the other hand, as mentioned earlier, you cannot simply mix an EVPN VXLAN fabric with any neighboring vendor because protocol implementations differ. It's like trying to interconnect Cisco and Huawei in one network ā technically, the standards are common, but it will require some extra effort. Since this is a bank and compatibility tests would take a very long time, they decided it was better to acquire from the same vendor now, and not get too carried away with functionalities beyond the basics.
Migratieplan
Two data centers based on ACI:
Organisatie van de interactie tussen datacenters. Er is gekozen voor een Multi-Pod-oplossing - elk datacenter is een pod. Er is rekening gehouden met de schaalvereisten voor het aantal switches en de latenties tussen de pods (RTT van minder dan 50 ms). Besloten werd om geen Multi-Site-oplossing te bouwen voor eenvoudigere beheer (voor de Multi-Pod-oplossing wordt Ć©Ć©n beheerscherm gebruikt, voor Multi-Site zouden er twee schermen nodig zijn of zou een Multi-Site Orchestrator vereist zijn), en omdat er geen geografische redundantie van de locaties nodig was.
Wat betreft de migratie van diensten vanuit het Legacy-netwerk, is de meest transparante optie gekozen, namelijk het geleidelijk verplaatsen van VLAN's die overeenkomen met bepaalde diensten.
Voor de migratie werd voor elk VLAN een overeenkomende EPG (End-point-group) op de fabriek aangemaakt. Eerst werd het netwerk uitgestrekt tussen het oude netwerk en de fabriek via L2, daarna, na de migratie van alle hosts, werd de gateway naar de fabriek verplaatst, en vond de interactie van de EPG met het bestaande netwerk plaats via L3OUT, waarbij de interactie tussen L3OUT en de EPG werd beschreven met behulp van contracten. Een schematische weergave:
Schematische structuur van de meeste ACI-fabriekspolitieken in de onderstaande afbeelding. Alle configuratie is gebaseerd op beleidsregels die in andere beleidsregels zijn genest, enzovoort. Aanvankelijk is het erg moeilijk te begrijpen, maar na verloop van tijd, zoals de praktijk aantoont, wennen netbeheerders aan deze structuur binnen ongeveer een maand, en dan komt pas het begrip van hoe handig deze structuur is.
Vergelijking
Bij de Cisco ACI-oplossing moet er meer apparatuur worden aangeschaft (aparte switches voor Inter-Pod interactie en APIC-controllers), wat het duurder maakt. De Juniper-oplossing vereiste geen aanschaf van controllers en aanvullende apparatuur; het was gedeeltelijk mogelijk om bestaande apparatuur van de klant te gebruiken.
Hier is de architectuur van de EVPN VXLAN-fabriek voor twee datacenters van het tweede project:
Met ACI krijg je een kant-en-klare oplossing ā je hoeft niet te rommelen, je hoeft niet te optimaliseren. Bij de eerste kennismaking van de klant met de fabriek zijn ontwikkelaars en ondersteunend personeel voor codering en automatisering niet nodig. Gewoon gebruik is voldoende; veel instellingen kunnen volledig via een wizard worden gedaan, wat niet altijd een pluspunt is, vooral voor mensen die gewend zijn aan de commandoregel. Hoe dan ook, je hebt tijd nodig om je geest opnieuw in te stellen op de nieuwe manier van werken, met de specifieke instelling via beleidsregels en het omgaan met veel ingesloten beleidsregels. Het is ook erg wenselijk om een duidelijke naamgevingsstructuur voor beleidsregels en objecten te hebben. Bij elke logische fout in de werking van de controller kan het probleem alleen worden opgelost via de technische ondersteuning.
In EVPN ā de console. Leef ermee of geniet ervan. Een vertrouwde interface voor de oude garde. Ja, er is een standaardconfiguratie en handleidingen. Je moet de manuals bestuderen. Verschillende constructies, alles is duidelijk en gedetailleerd.
Natuurlijk is het in beide gevallen beter om bij migratie eerst de minder kritische services te migreren, bijvoorbeeld testomgevingen, en pas daarna, na het oplossen van alle bugs, over te gaan naar de productie. En niet op vrijdagavond instellen. Vertrouw nooit de leverancier dat alles goed zal gaan; het is altijd beter om jezelf te beschermen.
Bij ACI betaal je meer, hoewel Cisco momenteel deze oplossing actief promoot en vaak goede kortingen biedt, maar je bespaart op onderhoud ā de ondersteuning. Beheer en enige automatisering van de EVPN-fabriek zonder controller vereisen investeringen en regelmatige kosten ā monitoring, automatisering, implementatie van nieuwe services. Daarbij duurt de eerste opstart bij ACI 30-40 procent langer. Dit komt omdat het langer duurt om het hele pakket benodigde profielen en beleidsregels te creĆ«ren die daarna zullen worden gebruikt. Maar naarmate het netwerk groeit, vermindert de hoeveelheid benodigde configuraties. Je gebruikt al vooraf gemaakte beleidsregels, profielen en objecten. Je kunt flexibel segmentatie en beveiliging instellen, centraal contracts beheren die verantwoordelijk zijn voor het goedkeuren van bepaalde interacties tussen EPG's ā het arbeidsvolume daalt aanzienlijk.
In EVPN moet elk apparaat in de fabriek worden geconfigureerd, wat de kans op fouten vergroot.
Als ACI trager wordt geĆÆmplementeerd, dan heeft EVPN bijna twee keer zo lang geduurd om te wordt vastgelegd. In het geval van Cisco kun je altijd een support engineer bellen om vragen te stellen over het netwerk als geheel (omdat het als een oplossing wordt gedekt), terwijl je bij Juniper Networks alleen de hardware koopt, en deze wordt gedekt. Zijn de pakketten van het apparaat vertrokken? Nou okĆ©, dat is verder jouw probleem. Maar je kunt een vraag openen over het kiezen van een oplossing of het netwerkontwerp - en dan wordt aangeraden om een professionele service aan te schaffen, tegen een extra vergoeding.
De support voor ACI is geweldig, omdat het apart is: een apart team werkt hier uitsluitend aan. Er zijn ook Russische specialisten. De gids is uitgebreid, de oplossingen zijn vooraf bepaald. Ze bekijken en adviseren. Ze valideren het ontwerp snel, wat vaak belangrijk is. Juniper Networks doet hetzelfde, maar veel langzamer (dat was onze ervaring, nu zou het volgens geruchten beter moeten zijn), wat je dwingt om alles zelf te doen waar je anders een solution engineer zou kunnen vragen.
Cisco ACI ondersteunt integratie met virtualisatie- en containerisatie systemen (VMware, Kubernetes, Hyper-V) en centraal beheer. Er zijn netwerkdiensten en beveiligingsdiensten - load balancing, firewalls, WAF, IPS en meer... Goede microsegmentatie direct uit de doos. Bij de tweede oplossing verloopt de integratie met netwerkdiensten hobbels, en het is beter om van tevoren de forums te raadplegen van degenen die het zo hebben gedaan.
Conclusie
Voor elk specifiek geval moet een oplossing worden gekozen, niet alleen op basis van de kosten van de apparatuur, maar ook rekening houdend met de verdere operationele kosten en de belangrijkste problemen waarmee de klant momenteel wordt geconfronteerd, evenals wat de plannen zijn voor de ontwikkeling van de IT-infrastructuur.
ACI is door extra apparatuur duurder geworden, maar de oplossing is kant-en-klaar zonder dat er extra aanpassingen nodig zijn, de tweede oplossing is complexer en kostbaarder qua exploitatie, maar goedkoper.
Als je wilt bespreken hoeveel de implementatie van een netwerkfabriek bij verschillende leveranciers kan kosten en welke architectuur nodig is, kunnen we een ontmoeting plannen om te praten. Tot een schets van de architectuur (waarmee je de budgetten kunt berekenen) geven we gratis advies, een gedetailleerde uitwerking is natuurlijk al betaald.
Vladimir Kleptche, bedrijfsnetwerken.
Bron: habr.com
