Dual WAN mit Failover und je 1x WAN pro pfSense



  • Hi,

    ich plane derzeit eine recht spezielle DMZ Infrastruktur und weiss nicht, ob ich das so realisieren kann, wie ich mir das vorstelle.

    Am besten zeige ich hier kurz die Topologie, um mein Vorhaben zu erklären:

    
                    WAN1                    WAN2
                     :                       :
         public IP1  |                       |  public IP2
                .----+----.             .----+----.
                | pfSense +-------------+ pfSense |
                '----+----'     SYNC    '----+----'
        10.0.0.1/24  |                       |  10.0.0.2/24
                     |      .---------.      |
                     +------| Switch  |------+
                            '---------'
                                 |
                                DMZ (10.0.0.0/24)
                                 |
                           .-----+-----.
                           |    FW     | (no pfSense)
                           '-----+-----'
                                 |
                              internal
    
    

    So soll die Topologie aussehen, dazu noch folgende Ergänzung:

    • Die Zugänge für WAN1 und WAN2 liegen örtlich getrennt in unterschiedlichen Rechenzentren in verschiedenen Städten

    • Jede pfSense hat folglich nur Zugriff auf ein WAN

    • Die Verbindung der Rechenzentren untereinander ist über eine dedizierte Leitung relisiert und nicht durchdas öffentliche Netz (Internet) getunnelt (falls Security-Fragen aufkommen)

    • Die DMZ hat ein Subnetz, also die interne Adresse beider pfSense's liegt im selben Netz

    • Die Firewall zwischen DMZ und internem Netz (unten) ist nur der Vollständigeit wegen genannt und spielt keine Rolle

    Ich benötige nun eine Art Active-Standby Konfiguration mit dieser Vorgabe.
    Es wird einer der beiden WAN-Zugänge genutzt, fällt dieser aus, wird auf den anderen WAN-Zugang geschaltet.
    Kein Load-Balancing, nur Active Standby.

    Leider finde ich immer nur Aussagen und Konfigurationen mit mehreren pfSense's, welche alle Zugriff auf alle WAN haben.
    Dies habe ich aber nicht, jede pfSense hat nur Zugriff auf einen WAN-Anschluss.

    Meine Befürchtung ist nun, soweit ich das Thema bisher verstanden habe, dass das nicht geht, da sich beide pfSense mit ihren Einstellungen synchronisieren.
    Dies würde bedeuten, dass auch die WAN-Einstellungen synchronisiert werden, wodurch dann kein Zugriff mehr möglich ist.

    Und dann fällt mir noch ein, dass die interne IP der pfSense ja meine Gateway-Adresse ist und diese Adresse im Fehlerfall dann ja an die Backup-pfSense weitergegeben werden muss, damit die Rechner in der DMZ weiter auf ein Gateway zugreifen können…

    Hat jemand hier Erfahrungen oder einen Rat für mich?
    Oder ein How-to? :)

    Grüße, Morphmax


  • LAYER 8 Moderator

    Nein, das was du möchtest ist so nicht machbar.

    Erster Showstopper ist alleine bereits das WAN, da du in einem synchronisierten Setup dein NAT von intern (10.0.0.0/24) nach extern auf eine VIP oder die Interface Adresse mappen würdest. Das geht aber nicht, da du zwei getrennte WANs hast mit völlig unterschiedlichem Adressbereich. Gut, du müsstest kein CARP Interface auf das WAN legen, hättest aber trotzdem Verbindungsabbrüche, da deine externe Adresse schwenken würde und damit alle Sessions getrennt werden…
    ...was der zweite Showstopper ist: Der Sinn von CARP als Redundanzprotokoll ist ja, dass beim Ausfall kein Ausfall spürbar wird, da zu jeder Zeit die States synchronisiert werden. Diese würden zwar synchronisiert werden, wären aber ebenfalls wegen dem ersten Problem hilflos, da im State als Quelle/Interface/Ziel die WAN Adresse von WAN1 vorkommen würde. Somit würde trotz Sync ein neuer State benötigt und damit ein Verbindungsabriss erfolgen.

    Ich benötige nun eine Art Active-Standby Konfiguration mit dieser Vorgabe.
    Es wird einer der beiden WAN-Zugänge genutzt, fällt dieser aus, wird auf den anderen WAN-Zugang geschaltet.

    Weshalb überhaupt?

    Kein Load-Balancing, nur Active Standby.

    Das wäre eh nicht möglich.

    Meine Befürchtung ist nun, soweit ich das Thema bisher verstanden habe, dass das nicht geht, da sich beide pfSense mit ihren Einstellungen synchronisieren.

    Deine Befürchtung trifft zum Teil, aber nicht wegen deinem Schluß. Du kannst gewisse Dinge nicht synchronisieren und die Interface Konfiguration wird eh nicht synchronisiert. Die wird auf jedem Gerät selbst vorgenommen. Aber du kannst auch keine VIP auf WAN konfigurieren, weil das 2 getrennte Anschlüsse sind. Damit wäre ein FailOver im Fall "WAN offline" nicht möglich.

    Dies würde bedeuten, dass auch die WAN-Einstellungen synchronisiert werden, wodurch dann kein Zugriff mehr möglich ist.

    Jein, s.o. Das andere Problem ist, dass deine Einstellungen komplexer zu verwalten wären, weil du auf die unterschiedlichen Adressräume von WAN1/2 gleichzeitig abdecken müsstest.

    Und dann fällt mir noch ein, dass die interne IP der pfSense ja meine Gateway-Adresse ist und diese Adresse im Fehlerfall dann ja an die Backup-pfSense weitergegeben werden muss, damit die Rechner in der DMZ weiter auf ein Gateway zugreifen können...

    Deshalb wird bei einem HA Setup ja auch eine CARP VIP konfiguriert, die deine Gateway Adresse ist. Intern im DMZ ist das auch kein Problem, aber dir fehlt das WAN als CARP. Und damit deine eigentliche Erkennung "WAN ist down".

    Warum "patchst" du eigentlich nicht einfach das WAN2 via der RZ Verbindung rüber an Standort 1 und umgekehrt und hast damit beide WANs an beiden Standorten parat? Dann hättest du ein Multi-WAN Setup auf beiden Seiten, das man aber theoretisch als großen räumlich getrennten CARP Cluster betreiben könnte. Problem ist natürlich wenn das SYNC Interface zwischen den Kisten dann failed, welches auch über den RZ Intralink laufen müsste. Dann hätte man ruck zuck ein unschönes großes Split-Brain, was der Grund ist, warum man das über solche Links eigentlich nur ungern (oder eher gar nicht) macht.

    Gruß



  • Hi,

    erst mal danke für die Antwort. Es handelt sich um eine Projektaufgabe der Uni mit genau diesen Randdaten. Laut Prof soll es genau so mit pfSense problemlos umsetzbar sein. (Angeblich nutzt das LRZ so eine Konfig)
    Warum Active-Standby? Die Active-Leitung ist eine Leitung mit 10GbE in das Internet, die Standy-Leitung ist ein billiger 34Mbit Anschluss, welcher im Fehlerfall einen (wenn auch sehr beschränkten) Internetzugang zur Verfügung stellt.
    Die Topologie ist auch so vorgegeben und darf nicht geändert werden.

    Du sagst, es wäre ein Showstopper, dass die Verbindung beim Adresse schwenken abbricht, aber das ist doch herzlich egal?
    Nach meinem Verständnis lädt beim User dann eine Seite nicht oder ein Download oder Stream bricht ab und er lädt neu. Aber das Entscheidende, nämlich dass auf eine andere Leitung geschaltet wird und weiterhin ein Internetzugang verfügbar ist, sollte ja gegeben sein.

    Wegen dem Vorschlag, das WAN über die RZ-Verbindung an beide Standorte zu legen:
    Habe nachgefragt, darf ich nicht, sei auch nicht nötig.
    Aussage Prof: Ich soll nicht so kompliziert denken, die pfSense's sollen ihre Regeln synchronisieren, States sind uninteressant, da es ausschließlich darum geht, einen Verfügbaren Internetzugang zu haben. Verbindungsabbrüche sind irrelevant.

    Wenn ich das nun mit deiner Antwort verbinmde, dann müsste es also mit CARP funktionieren?

    Grüße!


  • LAYER 8 Moderator

    Die Topologie ist auch so vorgegeben und darf nicht geändert werden.

    Wird sie ja auch nicht, es wird lediglich der Anschluß so "verlegt" oder geroutet (in einem extra VLAN gekapselt bspw.), dass er dir an beiden Kisten zur Verfügung steht.

    Laut Prof soll es genau so mit pfSense problemlos umsetzbar sein. (Angeblich nutzt das LRZ so eine Konfig)

    Das ist ja eine nette Aussage, aber kann ich mir so ohne weiteres nicht vorstellen. Denn wenn auf dem WAN ein CARP Interface fehlt, kann kein Schwenk der Leitung durch Überwachung des Gateways stattfinden. Vor allem keine unterbrechungsfreie Weitergabe der States. Und wenn sie das tatsächlich so einsetzen, fehlt uns/mir entweder noch ein Part den ich nicht sehe in deiner Beschreibung, oder sie machen was ziemlich graues/schwarzes, was sonst keiner so konfigurieren würde.

    Du sagst, es wäre ein Showstopper, dass die Verbindung beim Adresse schwenken abbricht, aber das ist doch herzlich egal?

    Nein ist es nicht. Das ist eine der (Haupt)Aufgaben bei einem Failover, dass eben genau niemand (oder so gut wie niemand) was von einem Schwenk merkt.

    Aber das Entscheidende, nämlich dass auf eine andere Leitung geschaltet wird und weiterhin ein Internetzugang verfügbar ist, sollte ja gegeben sein.

    Wiederum nein. Der automatische Failover geschieht nur, wenn CARP einen Fehlzustand detektiert (bspw. Upstream Gateway von WAN auf FWL01 down) und dann die VIP umschwenkt. Aber da du auf beiden WANs andere Adress-Ranges hast, kannst du keine gültige VIP konfigurieren, die auf beiden Seiten vorhanden ist.

    Aussage Prof: Ich soll nicht so kompliziert denken, die pfSense's sollen ihre Regeln synchronisieren, States sind uninteressant, da es ausschließlich darum geht, einen Verfügbaren Internetzugang zu haben. Verbindungsabbrüche sind irrelevant.

    Aua. Das klingt eher nach dem was mir oben schon geschwant hat, dass da jemand CARP dazu "mißbraucht" einfach hardcore irgendwelchen Kram zu machen, den er für total sinnvoll hält, was aber eigentlich nicht der Zweck von CARP bzw. von HA ist. Sowas kenne ich aus meiner eigenen Studienzeit. Was ein Quark…

    Du solltest evtl. nochmal nachfragen, ob du dann auf beiden Seiten (WANs) einen Adressbereich hast, der gleich bleibt also ob independent IPs irgendwie geroutet werden, ich vermute aber mal nein. Und vermute weiterhin, dass hier jemand CARP als "billiges" HA Protokoll à la Keepalive mißbraucht (States sind uninteressant... -> dann kann man CARP auch bleiben lassen). Und wenn Verbindungsabbrücke irrelevant sind, muss es ja auch nicht automatisch gehen, oder? Dann kann man CARP auf dem WAN auch bleiben lassen, legt es nur auf LAN, konfiguriert die WAN Ports unabhängig und wenn WAN1 abfault, dann geht man in der UI von FWL01 eben auf CARP Switch auf Slave und schaltet manuell auf den Slave um und sobald die Leitung wieder da ist zurück.
    Ansonsten wäre CARP auf WAN nur mit einem Dummy möglich. Dann müsste man eine Adresse die nicht existiert und die keinen juckt als CARP VIP konfigurieren, die nirgends nutzen und gebrauchen und dann hätte man wahrscheinlich solch einen cruden Failover Mist gebaut.

    Wenn aber all das eh völlig egal ist drängt sich mir die Frage auf, warum man dann dafür pfSense nimmt, da die ganzen höheren Funktionen eh nicht genutzt werden. Dann kann man auch platt zwei ganz normale OpenBSD Kisten (oder Linux oder whatever) nutzen, klebt sich ein Redundanzprotokoll drauf (Corosync, Keepalive etc.) und switcht dann eben hart bei Ping Error von WAN1 auf WAN2. Wenn States etc. eh egal sind, ist ja auch ein ARP Failover auf dem LAN egal...

    geht sich jetzt den Kopf auf den Tisch hauen

    PS: (nicht auf dich bezogen morphmax - du kannst ja nichts dafür)
    Und wegen sowas hat man dann später Spezis draußen rumlaufen, die meinen, dass sowas ein total normales und gut durchdachtes Netzwerksetup ist! Danke Herr Professor! kopfschüttel
    Manchmal müsste man echt das Saufen anfangen...



  • Hallo,

    ich glaube, es liegt an "1x WAN pro PFsense". Warum nicht "2x WAN pro PFSense"?

    Die Verfügbarkeit des Internets kannst Du auch mit EINER PFSense und den beiden WANs machen. ( –>GatewayGroup)

    Wenn Du dann noch die PFSense redundant haben willst, dann zusätzliche PFSense mit CARP.

    Oder ist das jetzt "zu einfach"?

    Viele Grüße,
    Jörg


  • LAYER 8 Moderator

    Hi Jörg,

    Natürlich, eine Kiste würde genügen mit 2 WAN, deshalb ja auch die Frage, ob man die zweite Leitung nicht lokal rüberbringen kann oder umgekehrt. Das Problem wird sein, dass es sich um 2 physische Standorte handelt und wenn dann über den Interlink zwischen den beiden Standorten das WAN nicht via eigenem VLAN sauber getrennt rübergebracht werden kann, dann bekommt man das nicht wirklich hin.

    Ansonsten hast du sicher recht, dann wäre das eine Kiste mit 2x WAN und einer Gateway Gruppe. Das beschriebene Problem (von mir) liegt eher in 2 getrennten Geräten mit eigenem WAN und eigenen IP Ranges. Dann CARP auf dem externen WAN zu "verdrehen" damit es eben so halbgar einen Failover auslöst, tut mir eben technisch gesehen schon ein wenig weh. Da werden unsaubere/zusammengefrickelte Lösungen als "das geht doch toll" propagiert, die aber eben im Livebetrieb fernab von gewollt sind, sondern eher "special internal use only". Nur wenn das als "normal" propagiert wird, wird das auch weiter so gebaut und das ist eben für mich Mist. Deshalb schreib ich das auch so ;)

    Grüße



  • Hi,

    danke für die Antworten :)

    Ich kann eure Argumentation vollständig nachvollziehen und würde auch den Weg gehen, beide WANs in beiden RZ's über RZ-Verbindung zur Verfügung zu stellen.
    Aber man kennt ja Profs: Wehe die Lösung entspricht nicht seinen Vorstellungen ;)

    Folgendes habe ich mir jetzt mal frei aus den Fingern gesaugt:

    Auf der WAN-Seite benötige ich in beiden RZ's das selbe Gateway/Subnetz, korrekt?
    Also könnte ich doch folgende Topologie aufbauen, womit ich dem Prof seine Vorgabe nicht ändere.
    Grundgedanke ist, dass ich an beiden WANs einen Router/Gateway zwischen WAN und pfSense setze, welcher auf der "Außenseite" die jeweilige öffentliche IP und auf der "Innenseite" an beiden Standorten die selbe IP als Gatewayadresse hat.
    Damit haben ja beide pfSense's "das selbe Gateway" bzw. gehen sie davon aus. Jedenfalls sollte das ja einem Failover-Setup "ohne Multi-LAN" gleichkommen, oder?
    Allerdings stellt sich mir hier die Frage, was passiert, wenn eine Leitung zwischen Router und WAN ausfällt. Funktioniert da der Failover zwischen den beiden pfSense's? Bekommen die das überhaupt mit, beispielsweise weil keine Verbindungen mehr nach außen aufgebaut werden können?

    
                    WAN1                     WAN2
                     :                       :
                     :                       :
          public IP1 :                       : public IP2
                 .---+---.               .---+---.
                 |Router1|               |Router2|
                 '---+---'               '---+---'
         1.2.3.4/29  |                       |  1.2.3.4/29
                     |          VIPs         |
         1.2.3.2/29  |                       |  1.2.3.3/29
                .----+----.  1.2.3.1/29 .----+----.
                | pfSense +-------------+ pfSense |
                '----+----'     CARP    '----+----'
        10.0.0.1/24  |      10.0.0.3/24      |  10.0.0.2/24
                     |                       |
                     |      .---------.      |
                     +------| Switch  |------+
                            '---------'
                                 |
                                DMZ (10.0.0.0/24)
                                 |
                           .-----+-----.
                           |    FW     | (no pfSense)
                           '-----+-----'
                                 |
                              internal
    
    

    Grüße, Morphmax


  • LAYER 8 Moderator

    Auf der WAN-Seite benötige ich in beiden RZ's das selbe Gateway/Subnetz, korrekt?

    Nein, dort hast du die IP auf WAN Seite, die dir der Uplink zum entsprechenden WAN vorgibt. Zumindest kann ich mir das kaum anders vorstellen. Das ist ja mit der Grund warum ich schrieb, dass die Konfiguration so murks ist ;)
    Zudem brauchst du nicht die selbe Adresse, sondern die beiden Geräte müssen sich für sauberes CARP gegenseitig SEHEN können (also pingen). Sprich WAN von pf1 und pf2 müssen sich gegenseitig anpingen können, sonst gibt es instant split brain.

    Zudem ist das gleiche Netz auf einem zweiten Interface ein absolutes No-Go (1.2.3.1/29 auf Sync und 1.2.3.2/29 auf WANx)!

    Grüße



  • @JeGr:

    Nein, dort hast du die IP auf WAN Seite, die dir der Uplink zum entsprechenden WAN vorgibt. Zumindest kann ich mir das kaum anders vorstellen. Das ist ja mit der Grund warum ich schrieb, dass die Konfiguration so murks ist ;)
    Zudem brauchst du nicht die selbe Adresse, sondern die beiden Geräte müssen sich für sauberes CARP gegenseitig SEHEN können (also pingen). Sprich WAN von pf1 und pf2 müssen sich gegenseitig anpingen können, sonst gibt es instant split brain.

    Zudem ist das gleiche Netz auf einem zweiten Interface ein absolutes No-Go (1.2.3.1/29 auf Sync und 1.2.3.2/29 auf WANx)!

    Grüße

    So langsam komm ich mit der Logik nicht mehr klar. beide WANs können sich doch immer pingen (wenn sie direkt am WAN hängen). Wenn ich jetzt die WANs, wie weiter oben vorgeschlagen, über jeweils ein VLAN zum anderen Standort bringe, was passiert dann, wenn die Standortverbindung wegbricht? beide pfSense laufen, beide können sich gegenseitig pingen, nur der Sync kommt nicht mehr durch. und was passiert dann mit Paketen, bspw. SMTP (ein SMTP-Gateway in beiden RZ's), welche von extern rein kommen, welche pfSense läßt die durch? und warum? wie wissen die pfSense's das eingehende SMTP nicht mehr von dem einen, sondern vom anderen entgegengenommen werden müssen? beide sind ja weiterhin online…

    Sry, aber ich komm hier irgendwie nicht weiter. Wie lösen Firmen das Problem? Diese habe doch im Normalfall Leitungen bei mehreren Anbietern und von unterschiedlichen Standorten aus. Sitzt da dann den ganzen Tag einer im Keller und wartet darauf, dass die Internetverbindung tot ist und steckt dann den Stecker um?

    Der Letzte Vorschlag kam übrigens aus der IT-Abteilung bei mir in der Praktikumsstelle (in einem großen Konzern). Die IT'ler dort meinten auch, dass irgendwelche verlorenen States für einen Failover unwichtig sind. Wichtig ist, dass automatisch auf eine andere funktionierende Leitung geschaltet wird, so als steckt man den Stecker von der kaputten und die funktionierende Leitung. Alles andere sei nice-to-have.

    Ich sollte den Studiengang wechseln...

    Grüße!

    PS: Es soll kein gleiches Netz auf 2 Schnittstellen sein, habe es vergessen zu ändern (copy-paste aus dem sticky thread mit den Tpologiediagrammen :) )



  • Entschuldigt wenn ich hier so reingrätsche, aber was für WAN Router hast du da ?
    Soho Kisten oder was vernünftiges wie z.b. Cisco.

    Wenn du Business Router einsetzt kannst du diese schön koppeln (via VRRP oder HSRP) und somit gibt es für beide Router nur noch eine IP und mittels dynamischem Routing, würde auch das Failover WAN kein Problem mehr sein.

    Du benötigst dann nur ein größeres Transfernetz wo sich alle Geräte (Router und PFsense) darin befinden.
    Das macht die Sache für die PFsense um einiges leichter.

    Ob das mit den Wunschvorstellungen deines Profs entspricht, kann ich aber nicht sagen.


  • LAYER 8 Moderator

    @rubinho: das hat doch mit den Kisten nichts zu tun. Für VRRP oder HSRP - was das gleiche ist wie CARP - müssen die Kisten sich auch gegenseitig sehen.

    Ein Standard Failover Setup sieht man am Einfachsten unter

    https://doc.pfsense.org/index.php/Configuring_pfSense_Hardware_Redundancy_(CARP)

    Da sollte auch klar werden was gemeint ist: auf dem WAN wie auf dem LAN wird das jeweils GLEICHE Netz konfiguriert und jede Kiste bekommt eine eigene Adresse dazu gibts dann in jedem Segment noch eine VIP, die von Gerät A auf B wechselt.

    Failover-Fall wird festgestellt wenn sich auf dem konfigurierten Interface (WAN oder LAN) die Geräte nicht mehr sehen (Ping sowie Multicast). Das Sync Interface ist nur für pfSync da um States und Konfiguration abzugleichen. Bricht Sync weg, hat man einen Async Zustand was die States angeht, aber noch KEINEN Failover Fall. Erst wenn die Master Firewall ein Fail auf einem der Interfaces bemerkt und die Failover Kiste sie daher nicht mehr erreichen kann, dann schwenkt alles auf den anderen Knoten, wenn bei dem noch alles funktioniert.

    Was in deinem Fall nicht funktioniert morphmax ist genau das Setup von CARP auf dem WAN, weil deine beiden Firewalls, wenn du sie einfach nur an die WAN Uplinks dranhängst, in völlig anderen Netzen sind (nicht im gleichen Subnetz) und du darauf dann keine CARP Adresse konfigurieren kannst, da sich die Kisten per Multicast auch nicht sehen und austauschen können. Klar können die sich Pingen (externe IP1 zu 2) aber Multicast kannst du nicht über Netzgrenzen hinweg problemlos sprechen, das wird fast immer vom Provider gefiltert. Und sobald du kein CARP Interface auf dem WAN hast, kannst du kein Failover auf den Slave machen wenn WAN wegbricht. Du hättest dann nur den manuellen Weg das in der UI manuell zu machen.

    Wie lösen Firmen das Problem? Diese habe doch im Normalfall Leitungen bei mehreren Anbietern und von unterschiedlichen Standorten aus. Sitzt da dann den ganzen Tag einer im Keller und wartet darauf, dass die Internetverbindung tot ist und steckt dann den Stecker um?

    Das siehst du falsch an mehreren Punkten.

    a) Die meisten Firmen haben da einen HSRP/VRRP/CARP Cluster stehen an der Anbindung und haben 2 Leitungen vom gleichen Provider, der auf seiner Seite auch irgendeine Redundanz spricht. Also ein "H" vom Aufbau (2 Geräte Provider bringen 2 Leitungen die in 2 Geräte von dir gehen, alle Geräte untereinander als Cluster konfiguriert und mit zwei Switchen vornedran - der Querstrich - verbunden).
    b) Eine Firma betreibt ggf. mehrere Standorte, aber nutzt diese Leitungen (meistens) nicht für nen Failover von intern. Vor allem ist bei Firmen NIEMALS der State entbehrlich oder Verbindungen entbehrlich und egal. Wenn mein Kunde bspw. ein Video streamt ist der nicht begeistert wenn ihm ständig der Stream abreißt. Mehrere Standorte sind meist aus Gründen wie Geo-Location, Nähe zum Kunden wegen Latenz und Laufzeit etc. aufgesetzt und nicht als Failover für ein internes LAN.
    c) Firmen haben dann ggf. andere Verträge und routen IPs via BGP + OSPF je nach Größe. Alleine damit ergibt sich nochmals ein völlig anderes Setup und Möglichkeiten, denn dann hast du ggf. an den Standorten die gleichen IPs, die du dann rüber routen kannst.

    Zumindest habe ich im Datacenter Einsatz bislang noch kein Setup gesehen, bei dem ein Kunde FWL1 in Location 1 und FWL2 in Location 2 versucht als "Cluster" miteinander zu verbinden, schon allein weil die Laufzeiten zwischen den Standorten ggf. recht groß sind. Von dem Problem des Routings mal ganz zu schweigen :)
    Ich supporte ein ähnliches Setup, dort stehen aber JE ein Cluster in DC1 und DC2 und die sind wiederum mit einem Link zwischen den beiden DCs "verbunden", allerdings ist bei denen BGP eingerichtet: Wenn der Kunde seinen Uplink schwenken will auf DC2, dann schalten die BGP auf Cluster 1 ab und auf 2 an. Und prompt läuft alles in DC2 auf. Für sowas gibts Monitoring und semi-autonome Prozesse die das triggern, aber ein DC Failover machen die meisten nur händisch, da ggf. noch andere Dinge vorbereitet werden müssen oder Hand in Hand gehen.

    Und 2 Leitungen für ein LAN zu haben - das machen die meisten Firmen eben nicht an unterschiedlichen Standorten, sondern holen sich beides an einen Cluster/eine Firewall ran und nutzen GW Gruppen und MultiWAN.

    Grüße


Log in to reply