10
Datacenter Routing VRRP Design Best-Practice
Hallo zusammen,
ich habe mir zu diesem Thema schon über längerem Zeitraum immer mal wieder Fachberichte angesehen und Gedanken gemacht. Jetzt hatte ich mit einem Kollegen auch mal wieder eine Diskussion darüber: Im Kern geht es darum wie man im Bereich Firewall, Hochverfügbarkeit und Routing bestimmte Services in einem zentralen RZ bereitstellt und welche Struktur dafür am besten geeignet ist. Es geht um zentrales VPN, Webservices und Appliances die zentral untergebracht sind. Diese sollen von einem Unternehmen das mehrere Standorte hat verwendet werden. Es geht nicht um Massen-Hosting alla Hetzner, sondern eher in Richtung zentrales Unternehmens-RZ.
Ich persönlich bin der Meinung das es eigentlich nur zwei Varianten gibt, die sich mir persönlich in den letzten Jahren herauskristallisiert haben:
1. Klassisches Edge mit VRRP
Physische Firewall-Appliance im Active/Backup. Webservices werden per Portforward und Loadbalancer bereitgestellt. Doppeltes NAT. Dahinter ein Layer3-Switch mit MLAG oder wahlweise als Stack, der Ports bereitstellt. VPN der Standorte terminiert auf der physischen VPN-Router, geroutet wird mit OSPF oder BGP. Webservices und Branchen-Software virtualisiert auf einem entsprechenden Cluster.
2. Cloud
Zentraler Layer3-Switch mit MLAG oder als Stack. Trennung durch VLANs. Webservices werden entweder direkt per VLAN-Tagging durchgereicht an das öffentliche Netz und per integrierter Firewall abgesichert oder hinter Loadbalancing (Debian,Haproxy,nftables oder virtualisierte OPNsense/pfSense/whatever) und Routing per SDN. Unterschied besteht also darin das es keinen physischen VPN-Router gibt.
Hintergrund ist der: Unser eigenes RZ wurde vor einigen Jahren nach einem Klassischen VRRP designed. Mein Kollege fing dann irgendwann mal an, den Backup-Router ebenfalls in die Lage zu versetzen das dieser ebenfalls verwendet wird. Es wurde ein Verkapptes Active/Active daraus. Es funktioniert nicht richtig und führt zu vielen Problemen im Alltag. Antrieb war wohl das die Ressourcen sonst brach liegen. Aber das geht am eigentlichen Sinn von VRRP vorbei. Er ist der Meinung das muss in einem modernen RZ möglich sein.
Nun ist mir leider keine andere Technik bekannt, außer propietäre Systeme von z.B. Arista (VARP), die ein Active/Active im VRRP zulassen.
Mich würde an dieser Stelle Lektüre oder eigene Erfahrungen interessieren. Wie sollte sowas im besten Fall modern umgesetzt werden? Wie sollte ein RZ aussehen? Eventuell hat jemand brauchbare Fallbeispiele.
Durch reine Internetrecherche findet man viel Unsinn. Teilweise werden Begriffe zusammengeworfen, umgedeutet oder haben plötzlich einen völlig anderen Kontext. Mich würde da eher eure Erfahrungen interessieren.
Grüße
ich habe mir zu diesem Thema schon über längerem Zeitraum immer mal wieder Fachberichte angesehen und Gedanken gemacht. Jetzt hatte ich mit einem Kollegen auch mal wieder eine Diskussion darüber: Im Kern geht es darum wie man im Bereich Firewall, Hochverfügbarkeit und Routing bestimmte Services in einem zentralen RZ bereitstellt und welche Struktur dafür am besten geeignet ist. Es geht um zentrales VPN, Webservices und Appliances die zentral untergebracht sind. Diese sollen von einem Unternehmen das mehrere Standorte hat verwendet werden. Es geht nicht um Massen-Hosting alla Hetzner, sondern eher in Richtung zentrales Unternehmens-RZ.
Ich persönlich bin der Meinung das es eigentlich nur zwei Varianten gibt, die sich mir persönlich in den letzten Jahren herauskristallisiert haben:
1. Klassisches Edge mit VRRP
Physische Firewall-Appliance im Active/Backup. Webservices werden per Portforward und Loadbalancer bereitgestellt. Doppeltes NAT. Dahinter ein Layer3-Switch mit MLAG oder wahlweise als Stack, der Ports bereitstellt. VPN der Standorte terminiert auf der physischen VPN-Router, geroutet wird mit OSPF oder BGP. Webservices und Branchen-Software virtualisiert auf einem entsprechenden Cluster.
2. Cloud
Zentraler Layer3-Switch mit MLAG oder als Stack. Trennung durch VLANs. Webservices werden entweder direkt per VLAN-Tagging durchgereicht an das öffentliche Netz und per integrierter Firewall abgesichert oder hinter Loadbalancing (Debian,Haproxy,nftables oder virtualisierte OPNsense/pfSense/whatever) und Routing per SDN. Unterschied besteht also darin das es keinen physischen VPN-Router gibt.
Hintergrund ist der: Unser eigenes RZ wurde vor einigen Jahren nach einem Klassischen VRRP designed. Mein Kollege fing dann irgendwann mal an, den Backup-Router ebenfalls in die Lage zu versetzen das dieser ebenfalls verwendet wird. Es wurde ein Verkapptes Active/Active daraus. Es funktioniert nicht richtig und führt zu vielen Problemen im Alltag. Antrieb war wohl das die Ressourcen sonst brach liegen. Aber das geht am eigentlichen Sinn von VRRP vorbei. Er ist der Meinung das muss in einem modernen RZ möglich sein.
Nun ist mir leider keine andere Technik bekannt, außer propietäre Systeme von z.B. Arista (VARP), die ein Active/Active im VRRP zulassen.
Mich würde an dieser Stelle Lektüre oder eigene Erfahrungen interessieren. Wie sollte sowas im besten Fall modern umgesetzt werden? Wie sollte ein RZ aussehen? Eventuell hat jemand brauchbare Fallbeispiele.
Durch reine Internetrecherche findet man viel Unsinn. Teilweise werden Begriffe zusammengeworfen, umgedeutet oder haben plötzlich einen völlig anderen Kontext. Mich würde da eher eure Erfahrungen interessieren.
Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 668990
Url: https://administrator.de/forum/datacenter-routing-vrrp-design-best-practice-668990.html
Ausgedruckt am: 21.12.2024 um 16:12 Uhr
10 Kommentare
Neuester Kommentar
Moin,
ich würde gar kein VRRP nutzen sollten.
Ich nutze dafür mehrere Firewall Cluster im active/passive.
Der Schwenk läuft zumindest bei den Fortinets so ziemlich nahtlos. Da kommt VRRP nicht ran.
Außerdem hast du mit einer Firewall als Gateway wesentlich mehr Kontrolle. Klar kostet der Durchsatz mehr als zwei simple Core Switche.
Gruß
Spirit
ich würde gar kein VRRP nutzen sollten.
Ich nutze dafür mehrere Firewall Cluster im active/passive.
Der Schwenk läuft zumindest bei den Fortinets so ziemlich nahtlos. Da kommt VRRP nicht ran.
Außerdem hast du mit einer Firewall als Gateway wesentlich mehr Kontrolle. Klar kostet der Durchsatz mehr als zwei simple Core Switche.
Gruß
Spirit
Ich nutze dafür mehrere Firewall Cluster im active/passive.
Der Schwenk läuft zumindest bei den Fortinets so ziemlich nahtlos. Da kommt VRRP nicht ran.
Der Schwenk läuft zumindest bei den Fortinets so ziemlich nahtlos. Da kommt VRRP nicht ran.
Aber das wäre dann eher eine proprietäre Lösung eines Hersteller. Also nicht standardisiert. Was würde da im OpenSource-Bereich rankommen? CARP?
Prinzipiell Ja, es wäre eine Lösung. Setzt aber voraus das man entweder umstellt, was mit Kosten verbunden ist, oder man deren Systeme bereits verwendet. Wenn das der Fall ist, ist man letztendlich auch von diesem Hersteller und seiner Lösung abhängig.
die ein Active/Active im VRRP zulassen.
Deine verwendeten ICX Switches supporten doch alle VRRP-E und damit local Forwarding auf jedem Node so das es keinen Standby Switch im Sinne von Passive mehr gibt sondern jeder VRRP-E Member L3 forwardet. VRRP-E supporten die Teile schon seit Jahren und es wäre sehr verwunderlich wenn ihr es nicht im DC Umfeld aktiviert habt sondern nur das uralte Standard VRRP was diese überholten Rollen von Active und Standby hat die so gut wie keiner mehr nutzt.(Zitat aus dem Deployment Guide: "In VRRP-E server virtualization, multiple VRRP standby devices are supported, and each device can be configured to route to an upstream Layer 3 network. This provides efficient deployment for both Layer 2 and Layer 3 networks.")
Das gilt ebenso für Fabric Switches mit SPB oder Trill oder moderneren IP Fabric Setups.
In der Beziehung hat der Kollege also Recht das Active/Active eher "state of the art" ist! Das gilt heute auch für Firewall Cluster die meist Active/Active laufen. In Full Stack Designs stellt sich die Frage prinzipbedingt gar nicht erst.
Aber das wäre dann eher eine proprietäre Lösung eines Hersteller.
Und?Wenn es doch stabil Funktioniert soll es mir ja egal sein. Wird irgendwann der Hersteller gewechselt, nutzt der andere/ eigene Protokolle... für die Clients doch Wurscht, was da passiert.
Wenn das Routing auf den Switchen passiert, muss natürlich geprüft werden, wass ihr alles haben wollt/ braucht.
Ein Switch kann nunmal kein IDS, was eine NextGen-FW könnte. Auch kann ein Switch nicht mit dem Client kommunizieren, um im Falle eines kompromittierten Clients den Traffic in andere (V)LANs zu unterbinden.
Das wiederum wäre möglich, wenn ich Sophos' Endpoint-Protection und eine Fortinet/ Sophos-Firewall einsetze (andere, Kompatible Produkte sind ebenso möglich): https://docs.sophos.com/central/customer/help/de-de/ManageYourProducts/T ...
Moin, irgendwo habe ich gelesen, daß Active/Active-Designs komplexer sind und bergen das Risiko von asymmetrischem Routing und Instabilitäten.
Zitat von @aqui:
die ein Active/Active im VRRP zulassen.
Deine verwendeten ICX Switches supporten doch alle VRRP-E und damit local Forwarding auf jedem Node so das es keinen Standby Switch im Sinne von Passive mehr gibt sondern jeder VRRP-E Member L3 forwardet. VRRP-E supporten die Teile schon seit Jahren und es wäre sehr verwunderlich wenn ihr es nicht im DC Umfeld aktiviert habt sondern nur das uralte Standard VRRP was diese überholten Rollen von Active und Standby hat die so gut wie keiner mehr nutzt.Tatsächlich verwenden wir das derzeit nicht. Wir haben noch aus historischen Gründen und wie @Spirit-of-Eli es ausgedrückt hat - "um mehr Kontrolle zu haben" - noch zwei physische Edge-Router mit VPN und Firewall im Einsatz die sich vor dem Layer3-Switch befinden hierarchisch. Das sind eigentlich einfach nur zwei Debian-Büchsen mit nftables und Wireguard. Damit die "Ausfallsicher" sind, gibt es in der Linux-Welt zwei Möglichkeiten (zumindest die ich kenne): Keepalived (VRRP) und UCARP (CARP).
Letzteres ist halt patentfrei und in Teilen etwas moderner. Aber weil Keepalived einfacher war damals, wurde sich dafür entschieden. Zusammen mit conntrackd ist das schon nicht schlecht in Sachen Performance.
Wenn man die ICX-Switches mit VRRP-E betreibt, was beim mir die zweite beschriebene Variante "Cloud" (so nenne ich das mal) darstellt, dann wäre diese beiden Debian-Büchsen komplett obsolet. Das ist richtig.
Moin,
Gruß,
Dani
Moin, irgendwo habe ich gelesen, daß Active/Active-Designs komplexer sind und bergen das Risiko von asymmetrischem Routing und Instabilitäten.
Warum soll Active/Active Instabilität mit sich bringen? Es werden bestehende Ressourcen effektiver genutzt als bei Active/Passive. Auch ist asymmetrischem Routing ja "gewollt". Aber man muss wissen was man tut und vor allem im Fehlerfall. Gerade letzteres wird von vielen unterschätzt oder sogar vergessen.Zentraler Layer3-Switch mit MLAG oder als Stack. Trennung durch VLANs. Webservices werden entweder direkt per VLAN-Tagging durchgereicht an das öffentliche Netz und per integrierter Firewall abgesichert oder hinter Loadbalancing
Ein Layer 3 Switch hat als "Firewall" eben ACLs - nicht mehr, nicht weniger. Das würde ich auf keinen Fall mit einer klassischen Firewall vergleichen wollen. Das sind Äpfel und Birnen.hinter Loadbalancing (Debian,Haproxy,nftables oder virtualisierte OPNsense/pfSense/whatever)
Was hat ein Loadbalancer mit der Sicherheitsarchitektur zu tun?!Gruß,
Dani
1
Wenn es das denn nun war bitte deinen Thread hier dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Wird denn eigentlich in solch einem Szenario überhaupt noch VRRP verwendet? Wäre ja dank Failover-Architektur in virtualisierten Umgebungen völlig obsolet. Mal beispielsweise ich betreibe eine virtualisierte pfSense auf einem Proxmox-Cluster. Letzteres unterstützt Live Migration und HA Fencing. Dann würde in der Theorie eigentlich nur eine virtuelle Maschine gebraucht. Gut, es würde in einem Hardware-Fehlerfall die Session oder Layer3 unter Umständen abreißen, je nachdem wie schnell ein zweiter Host die VM wieder angestartet bekommt.
Layer2 wäre ja durch Mlag oder Stack vor Ausfall gesichert.
Layer2 wäre ja durch Mlag oder Stack vor Ausfall gesichert.
Warum soll Active/Active Instabilität mit sich bringen? Es werden bestehende Ressourcen effektiver genutzt als bei Active/Passive. Auch ist asymmetrischem Routing ja "gewollt". Aber man muss wissen was man tut und vor allem im Fehlerfall. Gerade letzteres wird von vielen unterschätzt oder sogar vergessen.
Quelle: KI
Vielen Dank für das Feedback!
Zu den Punkten:
1. Active/Active vs. Active/Passive Setup: Active/Active kann in bestimmten Szenarien effizienter sein, erfordert jedoch eine sorgfältige Abstimmung, um asymmetrisches Routing zu verhindern. Falls die Umgebung es erlaubt, bleibt ein klassisches Active/Passive mit VRRP oft stabiler, da es klar geregelte Übergänge hat und einfacher zu kontrollieren ist, gerade in Netzwerken mit empfindlichen Anforderungen.
2. Alternative Technologien: Technologien wie EVPN oder SDN sind nicht immer eine direkte Alternative zu VRRP, sondern eher für dynamischere Netzwerke oder Datacenter geeignet, die flexiblere Layer-2-übergreifende Lösungen benötigen. Wenn VRRP allein nicht die gewünschte Redundanz oder Lastverteilung bringt, könnten diese Technologien helfen.
3. Failover-Timings: Ein weiterer Punkt ist die Optimierung der VRRP-Timings, um Failover-Zeiten zu minimieren. Hier helfen angepasste Advertisement-Intervalle und Preemption-Einstellungen, um das Verhalten beim Ausfall eines Routers feinzutunen.
Ich hoffe, diese Ergänzungen klären die offenen Punkte!
Zu den Punkten:
1. Active/Active vs. Active/Passive Setup: Active/Active kann in bestimmten Szenarien effizienter sein, erfordert jedoch eine sorgfältige Abstimmung, um asymmetrisches Routing zu verhindern. Falls die Umgebung es erlaubt, bleibt ein klassisches Active/Passive mit VRRP oft stabiler, da es klar geregelte Übergänge hat und einfacher zu kontrollieren ist, gerade in Netzwerken mit empfindlichen Anforderungen.
2. Alternative Technologien: Technologien wie EVPN oder SDN sind nicht immer eine direkte Alternative zu VRRP, sondern eher für dynamischere Netzwerke oder Datacenter geeignet, die flexiblere Layer-2-übergreifende Lösungen benötigen. Wenn VRRP allein nicht die gewünschte Redundanz oder Lastverteilung bringt, könnten diese Technologien helfen.
3. Failover-Timings: Ein weiterer Punkt ist die Optimierung der VRRP-Timings, um Failover-Zeiten zu minimieren. Hier helfen angepasste Advertisement-Intervalle und Preemption-Einstellungen, um das Verhalten beim Ausfall eines Routers feinzutunen.
Ich hoffe, diese Ergänzungen klären die offenen Punkte!
