Failover auf zweiten Server mit gleichen IP Adressen
Hallo zusammen,
wir haben eine Anforderung eine IP Intercom Server (Sprachkommunikation) mit einem zweiten der genau
wie der erste konfiguriert ist (gleiche IP Adressen), redundant/ausfallsicher zu machen. Der zweite Server ist natürlich auch eingeschaltet.
Der Server ist ein proprietäres System auf eigener Hardware. Darauf gibt es dann als Software die "Zentrale" mit IP Adresse
und "Teilnehmerkarten" mit eigener IP Adresse pro Teilnehmerkarte. An jede Teilnehmerkarte können sich 8 Endgeräte anmelden.
Die Endgeräte haben als Ziel die IP Adresse der entsprechenden Teilnehmerkarte eingetragen, auf der sie konfiguriert sind.
Auf der Zentrale, den Teilnehmerkarten und Endgeräten lässt sich auch ein Router/Gateway eintragen.
Im Fehlerfall des ersten Servers, z.B. wenn die IP der Zentrale nicht erreichbar ist, soll dann automatisch ein Failover auf den zweiten
Server erfolgen. Es wird kein Load Balancing benötigt. Ist der Fehler vom ersten Server behoben, kann die Verbindung ruhig weiterhin
über den zweiten Server laufen.
Alle Komponenten sind im lokalen Netzwerk. Es ist keine Kommunikation des Intercom Netzwerkes ins Internet notwendig.
Die Hardware ist in diesem Fall im gleichen Rack eingebaut.
Zusätzlich soll es nach Möglichkeit eine Benachrichtigung eines Ausfalls von einem Intercom Servers geben (z.B. Mail, SNMP).
Bin vor kurzem auf MikroTik gestoßen und hab mir einen kleinen zum lernen geholt. Die Kisten können ja "alles" für eine super Preis.
IP´s überwachen und Mails versenden können die auch schon selber.
Wenn es auch eine Möglichkeit gibt, das mit MikroTik zu realisieren, würde ich das Favorisieren.
Lässt sich das realisieren ?
Gruß
wir haben eine Anforderung eine IP Intercom Server (Sprachkommunikation) mit einem zweiten der genau
wie der erste konfiguriert ist (gleiche IP Adressen), redundant/ausfallsicher zu machen. Der zweite Server ist natürlich auch eingeschaltet.
Der Server ist ein proprietäres System auf eigener Hardware. Darauf gibt es dann als Software die "Zentrale" mit IP Adresse
und "Teilnehmerkarten" mit eigener IP Adresse pro Teilnehmerkarte. An jede Teilnehmerkarte können sich 8 Endgeräte anmelden.
Die Endgeräte haben als Ziel die IP Adresse der entsprechenden Teilnehmerkarte eingetragen, auf der sie konfiguriert sind.
Auf der Zentrale, den Teilnehmerkarten und Endgeräten lässt sich auch ein Router/Gateway eintragen.
Im Fehlerfall des ersten Servers, z.B. wenn die IP der Zentrale nicht erreichbar ist, soll dann automatisch ein Failover auf den zweiten
Server erfolgen. Es wird kein Load Balancing benötigt. Ist der Fehler vom ersten Server behoben, kann die Verbindung ruhig weiterhin
über den zweiten Server laufen.
Alle Komponenten sind im lokalen Netzwerk. Es ist keine Kommunikation des Intercom Netzwerkes ins Internet notwendig.
Die Hardware ist in diesem Fall im gleichen Rack eingebaut.
Zusätzlich soll es nach Möglichkeit eine Benachrichtigung eines Ausfalls von einem Intercom Servers geben (z.B. Mail, SNMP).
Bin vor kurzem auf MikroTik gestoßen und hab mir einen kleinen zum lernen geholt. Die Kisten können ja "alles" für eine super Preis.
IP´s überwachen und Mails versenden können die auch schon selber.
Wenn es auch eine Möglichkeit gibt, das mit MikroTik zu realisieren, würde ich das Favorisieren.
Lässt sich das realisieren ?
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 620581
Url: https://administrator.de/contentid/620581
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
26 Kommentare
Neuester Kommentar
Hallo,
Nein, so nicht. Wenn Server 2 mit den gleichen IPs betrieben werden soll, darf der nicht eingeschaltet oder im Netzwerk Erreichbar sein. IP Grundlagen mal ansehene und lernen.
Gruß,
Peter
Nein, so nicht. Wenn Server 2 mit den gleichen IPs betrieben werden soll, darf der nicht eingeschaltet oder im Netzwerk Erreichbar sein. IP Grundlagen mal ansehene und lernen.
Gruß,
Peter
Denkbar wäre es mit Anycast zu lösen: https://de.wikipedia.org/wiki/Anycast
Das erfordert aber ein entsprechendes Netzwerk Design.
Das erfordert aber ein entsprechendes Netzwerk Design.
Das ist super-simples Anycast und lässt sich mit jedem Router lösen.
Das Netzwerklayout sieht so aus, dass jeder Server zunächst seine eigene eindeutige Unicast-IP aus dem jeweiligen Subnetz bekommt. Klassisches Netzwerkdesign.
Auf jeden Server, der am Anycast teilnehmen soll, wird dann zusätzlich ein virtuelles Netzwerkinterface ("Bridge") konfiguriert, welches nur diese eine Anycast-Adresse als /32 IPv4 bzw. /128 IPv6 konfiguriert bekommt (ohne weitere Konfiguration wie DNS oder Gateway).
Die Anycast-IP wird dann vom Router auf die Unicast-IP des Servers geroutet, der jetzt aktuell per Anycast den Dienst bereitstellen soll.
Um den automatischen Failover zu erhalten, musst du mehrere Routen mit unterschiedlicher Priorität anlegen - jeweils eine für jeden teilnehmenden Server.
Du solltest sehr kurze ARP-/NDP-Timeouts auf dem Router verwenden (so 20-30 Sekunden). Sobald die Unicast-IP des aktuell aktiven Servers nicht mehr für den Router erreichbar ist, wird die zugehörige Route invalidiert und es greift die mit der nächstbesten Priorität.
Der Failover greift dann aber nur automatisch, wenn wirklich der zugehörige Server im Netzwerk unerreichbar wird. Wenn nur der Dienst nicht mehr funktioniert, der Server an sich aber noch läuft, nützt dier das so erstmal nicht.
Für den Fall des Failovers bei Dienstausfall müsstest du entsprechende Protokolle verwenden - unter Linux beliebt z.B. Corosync und Pacemaker.
Diese können dann, auch ohne Anycast-Setup, einfach die IP-Adressen umbinden und dies auch automatisch tun, sobald der Dienst ausfällt.
Das allerdings nur, wenn der Dienst vom entsprechenden HA-Protokoll unterstützt wird. Hier solltest du mal schauen, ob es da bereits von der Software Schnittstellen für solche Protokolle gibt. Letzteres wäre zu bevorzugen, weil dabei ggf. auch laufende Sessions übernommen werden können.
Das Netzwerklayout sieht so aus, dass jeder Server zunächst seine eigene eindeutige Unicast-IP aus dem jeweiligen Subnetz bekommt. Klassisches Netzwerkdesign.
Auf jeden Server, der am Anycast teilnehmen soll, wird dann zusätzlich ein virtuelles Netzwerkinterface ("Bridge") konfiguriert, welches nur diese eine Anycast-Adresse als /32 IPv4 bzw. /128 IPv6 konfiguriert bekommt (ohne weitere Konfiguration wie DNS oder Gateway).
Die Anycast-IP wird dann vom Router auf die Unicast-IP des Servers geroutet, der jetzt aktuell per Anycast den Dienst bereitstellen soll.
Um den automatischen Failover zu erhalten, musst du mehrere Routen mit unterschiedlicher Priorität anlegen - jeweils eine für jeden teilnehmenden Server.
Du solltest sehr kurze ARP-/NDP-Timeouts auf dem Router verwenden (so 20-30 Sekunden). Sobald die Unicast-IP des aktuell aktiven Servers nicht mehr für den Router erreichbar ist, wird die zugehörige Route invalidiert und es greift die mit der nächstbesten Priorität.
Der Failover greift dann aber nur automatisch, wenn wirklich der zugehörige Server im Netzwerk unerreichbar wird. Wenn nur der Dienst nicht mehr funktioniert, der Server an sich aber noch läuft, nützt dier das so erstmal nicht.
Für den Fall des Failovers bei Dienstausfall müsstest du entsprechende Protokolle verwenden - unter Linux beliebt z.B. Corosync und Pacemaker.
Diese können dann, auch ohne Anycast-Setup, einfach die IP-Adressen umbinden und dies auch automatisch tun, sobald der Dienst ausfällt.
Das allerdings nur, wenn der Dienst vom entsprechenden HA-Protokoll unterstützt wird. Hier solltest du mal schauen, ob es da bereits von der Software Schnittstellen für solche Protokolle gibt. Letzteres wäre zu bevorzugen, weil dabei ggf. auch laufende Sessions übernommen werden können.
Moin,
ansonsten wäre vielleicht CARP noch eine Option: https://blog.no42.org/article/ucarp-high-availability/
VG
ansonsten wäre vielleicht CARP noch eine Option: https://blog.no42.org/article/ucarp-high-availability/
VG
Da gibt es einige Möglichkeiten.
Irgendwie machst Du auf mich nicht den Eindruck, das Thema nur ansatzweise zu beherrschen.
Eine Netzwerkkonfiguration dieser Art, sollte nur von Leuten, die wenigstens etwas Ahnung haben umgesetzt werden.
Hole dir bitte Hilfe ins Haus, wenn dein Netzwerk dir wichtig ist.
Irgendwie machst Du auf mich nicht den Eindruck, das Thema nur ansatzweise zu beherrschen.
Eine Netzwerkkonfiguration dieser Art, sollte nur von Leuten, die wenigstens etwas Ahnung haben umgesetzt werden.
Hole dir bitte Hilfe ins Haus, wenn dein Netzwerk dir wichtig ist.
Auf welche Ausfälle soll überwacht werden?
Wenn das System selbst keine HA-Möglichkeiten erlaubt, muss man etwas in der Physik rumbasteln. Eine Möglichkeit wäre, wie gesagt den Kisten die selbe IP zu geben und über ein vier bzw. acht poliges Umschaltrelais den Netzwerkanschluss umzuschalten.
Bei Linux, BSD und Windows wäre es kein Problem, ich hätte sogar ne Idee, wie man dein Szenario evtl. über einen LANCOM-Router redundant anbinden kann, aber eigentlich sollte, wenn das System als betriebskritisch eingestuft wird, was entsprechendes bereits vorhanden sein bzw. beim Hersteller angefordert werden können.
Wenn das System selbst keine HA-Möglichkeiten erlaubt, muss man etwas in der Physik rumbasteln. Eine Möglichkeit wäre, wie gesagt den Kisten die selbe IP zu geben und über ein vier bzw. acht poliges Umschaltrelais den Netzwerkanschluss umzuschalten.
Bei Linux, BSD und Windows wäre es kein Problem, ich hätte sogar ne Idee, wie man dein Szenario evtl. über einen LANCOM-Router redundant anbinden kann, aber eigentlich sollte, wenn das System als betriebskritisch eingestuft wird, was entsprechendes bereits vorhanden sein bzw. beim Hersteller angefordert werden können.
Zitat von @tikayevent:
Eine Möglichkeit wäre, wie gesagt den Kisten die selbe IP zu geben und über ein vier bzw. acht poliges Umschaltrelais den Netzwerkanschluss umzuschalten.
Eine Möglichkeit wäre, wie gesagt den Kisten die selbe IP zu geben und über ein vier bzw. acht poliges Umschaltrelais den Netzwerkanschluss umzuschalten.
Das ist nicht, wie Anycast funktioniert o_O
Und für den Fall dass du das wirklich ernst meinst: Dass man Switchports am Switch ein- und ausschalten kann, wäre ein zu einfacher weg?
wie gesagt den Kisten die selbe IP zu geben und über ein vier bzw. acht poliges Umschaltrelais den Netzwerkanschluss umzuschalten.
Warum solche gruselige Frickelei wenn man es mit Anycast und 3 Mausklicks auf jedem Baumarkt Router ganz einfach gelöst bekommt. Siehe oben...!Fehlendes Feedback des TO zeigt das er vermutlich eh das Interesse an einer zielführenden Lösung verloren hat.
Ich weiß was Anycast ist und ich habe es explizit nicht darauf abgesehen, weil der TO ja von propriäterer Technik schrieb. Das System muss hier ja schon etwas mitspielen, weil das System müsste dann ja zwei IP-Adressen für die Verwaltung und die Bereitstellung des Dienstes haben und muss die IP-Adresse des Dienstes propagieren können. Um es jetzt mal stumpf runterzubrechen: Mir ist noch keine HW-Telefonanlage (was auch immer der TO mit Intercom-System meint) begegnet, die ein dynamisches Routingprotokoll und mehr als eine IP pro Schnittstelle beherrscht hat.
Ja, man könnte auch den Switchport deaktivieren und aktivieren, aber dafür müsste erstmal der passende Switch da sein und man muss ihn ansprechen können.
Meine Idee kann man auch fertig kaufen. Nennt sich Ethernet Bypass. Insbesondere in der Industrie- und Automationstechnik weit verbreitet.
Ja, man könnte auch den Switchport deaktivieren und aktivieren, aber dafür müsste erstmal der passende Switch da sein und man muss ihn ansprechen können.
Meine Idee kann man auch fertig kaufen. Nennt sich Ethernet Bypass. Insbesondere in der Industrie- und Automationstechnik weit verbreitet.
Als VM und diese auf HA trimmen geht nicht?
Ohne eure Hardware zu kennen und eure Virtualisierungsmöglichkeiten, könnte man das Probleme so sehr elegant in Minuten lösen.
Ja, und die beiden autonom laufenden Intercom bekommen dann eine gemeinsame Datenbank oder Freigabe oder täglich ein Backup eingespielt oder wie soll das laufen?
Es gibt ja wie der TO oben selber erklärt eine feste statische Zuweisung von Clients zum Server und die Applikation ist fest ohne Datenbank oder solche Dinge. Alles statisch also wenn man es recht versteht. Jede Teilnehmerkarte und ihre IP ist also vollkommen autonom.
Da wir alle (inkl. der TO) nicht sicher wissen was technisch auf diesen Teilnehmerkarten überhaupt möglich ist, müssen wir, wie der TO, erstmal davon ausgehen das übliche Redundanzprotokolle, virtuelle IPs usw. usw. auf diesen Karten gar nicht möglich sind. Wie auch wenn die Server/Teilnehmerkarten IP immer zwingend statisch durch den Client vorgegeben ist und Server Zugriff (Root) durch den Anwender nicht möglich ist. Folglich würden dann OS spezifische Redundanzmechanismen der Netzinterfaces damit per se ausscheiden.
Dies vorausgesetzt, würde es eine Anycast Lösung sinnvoller erscheinen lassen, da sie wie bereits gesagt, vollkommen unabhängig von irgendwelcher Hardware, OS oder Applikation umsetzbar ist.
Da wir alle (inkl. der TO) nicht sicher wissen was technisch auf diesen Teilnehmerkarten überhaupt möglich ist, müssen wir, wie der TO, erstmal davon ausgehen das übliche Redundanzprotokolle, virtuelle IPs usw. usw. auf diesen Karten gar nicht möglich sind. Wie auch wenn die Server/Teilnehmerkarten IP immer zwingend statisch durch den Client vorgegeben ist und Server Zugriff (Root) durch den Anwender nicht möglich ist. Folglich würden dann OS spezifische Redundanzmechanismen der Netzinterfaces damit per se ausscheiden.
Dies vorausgesetzt, würde es eine Anycast Lösung sinnvoller erscheinen lassen, da sie wie bereits gesagt, vollkommen unabhängig von irgendwelcher Hardware, OS oder Applikation umsetzbar ist.
Offsichtlich hast du keine Ahnung, was das Produkt Schneider Interkom für einen Inhalt hat.
Zitat von @lanazy:
Wie aqui richtig schreibt, gibt es keine Datenbank, Dateien etc, die zwischen den beiden Servern synchronisiert werden müssen.
Die Konfiguration wird per Software gemacht. Damit lässt sich ein Backup machen und auf andere Server innerhalb Sekunden wieder einspielen.
Ist die Konfiguration gemacht, ändert sich in der Regel nichts mehr.
Die Anycast Lösung erscheint am sinnvollsten, da ja unabhängig von der eingesetzten Systeme.
Damit lassen sich ja quasi auch andere Systeme redundant auslegen.
Wie aqui richtig schreibt, gibt es keine Datenbank, Dateien etc, die zwischen den beiden Servern synchronisiert werden müssen.
Die Konfiguration wird per Software gemacht. Damit lässt sich ein Backup machen und auf andere Server innerhalb Sekunden wieder einspielen.
Ist die Konfiguration gemacht, ändert sich in der Regel nichts mehr.
Die Anycast Lösung erscheint am sinnvollsten, da ja unabhängig von der eingesetzten Systeme.
Damit lassen sich ja quasi auch andere Systeme redundant auslegen.
Was meinst du warum Schneider für eine Sicherheitslösung sich für dieses Design entscheiden hat? Krankenhäuser, Museen, Gefängnisse arbeiten damit und es ist noch niemand auf die Idee gekommen, dass eine Anycast-Verteilung die Redundanz ermöglicht?
Stell dir mal vor, Du musst das System bedienen und VERANTWORTEN in deiner Schicht und im Hintergrund gab es einen Schwenk und du kannst auf Daten des Secondary nicht zugreifen, der bis vor Minuten für Jahre der Primary war? Du bekommst auch gar nicht mit im Frontend dass das Backend geschwenkt hat. Lass mich raten, du machst dann ein Helpdeskticket auf?
Heute ist wohl Freitag.
Zitat von @142583:
Stell dir mal vor, Du musst das System bedienen und VERANTWORTEN in deiner Schicht und im Hintergrund gab es einen Schwenk und du kannst auf Daten des Secondary nicht zugreifen, der bis vor Minuten für Jahre der Primary war? Du bekommst auch gar nicht mit im Frontend dass das Backend geschwenkt hat. Lass mich raten, du machst dann ein Helpdeskticket auf?
Stell dir mal vor, Du musst das System bedienen und VERANTWORTEN in deiner Schicht und im Hintergrund gab es einen Schwenk und du kannst auf Daten des Secondary nicht zugreifen, der bis vor Minuten für Jahre der Primary war? Du bekommst auch gar nicht mit im Frontend dass das Backend geschwenkt hat. Lass mich raten, du machst dann ein Helpdeskticket auf?
Du hast noch nie mit Anycast gearbeitet?
Die nicht-eindeutige Anycast-IP wird nur für den Zugriff auf den bereitgestellten Dienst genutzt. Administration, Backups, Monitoring u.s.w. wird über die Unicast-IP gemacht, die bei jedem Anycast-Teilnehmer eindeutig ist.
Es ist also für die Administration völlig egal, wo die IP gerade hin geroutet wird.
Das funktioniert bei den Root-Nameservern, die allesamt Anycasted sind, auch und skaliert weltweit.
Heute ist wohl Freitag.
Ja, ganz offensichtlich.Als Anmerkung dazu noch einmal: Die Nutzung von Anycast setzt voraus, dass man jeweils zwei IP-Adressen auf den Systemen konfigurieren kann. Da ist ja bisher fraglich, ob das so vom Hersteller unterstützt wird.
Allerdings sehe ich gerade beim schnellen Durchklicken, dass dieses System ("virtuosis"?) IPv6-Unterstützung hat.
Hier hast du den bei IPv6 prinzipbedingten Vorteil, dass a) zusätzlich zur "richtigen" Adresse immer auch die sehr eindeutige Link-Local-Adresse auf dem Interface vorhanden sein muss und damit als Routing-Ziel verwendet werden kann.
Und dass b) IPv6-Adressen beim Eintragen (sofern nicht vom Hersteller kastriert) als Anycast-Adresse definiert werden können und damit keine Probleme mit DAD im Netzwerk verursachen können.
Wenn ich mir allerdings das Lizenzierungsmodell des Herstellers ansehe, kommen mir Zweifel, ob das vom Hersteller so unterstützt ist.
Das solltest du mal mit dem klären um herauszufinden, ob simples Anycast funktioniert.
Ja, ich kenne Anycast und betreibe auf h diverse Konfigs.
Schneider sieht kein Anycast vor und es es sogar mit Verlust der Support-Vereinbarung zu rechnen.
Wenn man nur VoIPen will und muss, dann ist es sicherlich unkritisch. Geht es um Sicherheit und Manipulationsschutz, dafür ist die Lösung bekannt, dann wäre es zumindest eine Frage der Pflichtendelegation zu klären, ob man auf eigene Faust eine solche Konstruktion bauen kann, nur weil sie funktioniert.
Passiert etwas, ein Bediener z. B. Ein Pförtner kann nicht nachweisen welche Tür er geöffnet hat... Und warum... Und das besonders kurzfristig, weil vielleicht der Chef neben ihm steht oder die Polizei... Gibt es riesen Ärger.
Schneider sieht kein Anycast vor und es es sogar mit Verlust der Support-Vereinbarung zu rechnen.
Wenn man nur VoIPen will und muss, dann ist es sicherlich unkritisch. Geht es um Sicherheit und Manipulationsschutz, dafür ist die Lösung bekannt, dann wäre es zumindest eine Frage der Pflichtendelegation zu klären, ob man auf eigene Faust eine solche Konstruktion bauen kann, nur weil sie funktioniert.
Passiert etwas, ein Bediener z. B. Ein Pförtner kann nicht nachweisen welche Tür er geöffnet hat... Und warum... Und das besonders kurzfristig, weil vielleicht der Chef neben ihm steht oder die Polizei... Gibt es riesen Ärger.