26
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ß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 620581
Url: https://administrator.de/contentid/620581
Printed on: July 27, 2024 at 01:07 o'clock
26 Comments
Latest comment
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.
Hallo,
was du beschreibst ist ein simples Active/Passive Clustering. Nur: Das muss die Applikation unterstützen. Im Voice-Bereich ist Hochverfügbarkeit glaube ich ein gängies Feature - hast du schonmal geschaut, was der Hersteller der Software für ein Modell vorschlägt?
Grüße
Filipp
was du beschreibst ist ein simples Active/Passive Clustering. Nur: Das muss die Applikation unterstützen. Im Voice-Bereich ist Hochverfügbarkeit glaube ich ein gängies Feature - hast du schonmal geschaut, was der Hersteller der Software für ein Modell vorschlägt?
Grüße
Filipp
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?
1wie 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.
Hallo zusammen,
sorry für die späte Antwort.
Ganz Ahnungslos bin ich jetzt nicht, aber ja, was Routing-, Redundanz-Protokolle etc. angeht, kenne ich mich tatsächlich nicht aus. So ein Szenario habe ich bis jetzt auch noch nicht benötigt. Deshalb frage ich euch Profis, um mögliche Lösungen zu erhalten und mir das Wissen anzueignen.
Danke euch für die Vorschläge.
Werde mir das mit Anycast auf jeden Fall angucken. Das mit dem Relais würde ich lieber vermeiden.
Der Intercom Server (ganz einfach ausgedrückt, IP Sprechanlage) basiert zwar auf Debian, ist aber vom Hersteller eingeschränkt. Root Zugriff haben wir nicht.
Der Hersteller bietet zu Zeit keine Redundanz an. Vielleicht kommt diese Möglichkeit ja eines Tages.
Gehen wir zum jetzigen Stand davon aus, dass am Server keine Konfigurationen möglich sind. Deshalb möchten wir das mit Netzwerkmitteln unabhängig von den Servern lösen.
Aber ich werde versuchen mehr Infos, bzw. was zum testen zu bekommen um heraus zu finden was eventuell doch auf dem Server machbar ist.
Es würde reichen, die "Zentralen" IP zu überwachen. Richtig ist auch, dass pro virtueller Komponente (Zentrale, Teilnehmerkarte) nur eine IP eingestellt werden kann.
Wer noch mögliche Lösungen hat, gerne posten.
sorry für die späte Antwort.
Ganz Ahnungslos bin ich jetzt nicht, aber ja, was Routing-, Redundanz-Protokolle etc. angeht, kenne ich mich tatsächlich nicht aus. So ein Szenario habe ich bis jetzt auch noch nicht benötigt. Deshalb frage ich euch Profis, um mögliche Lösungen zu erhalten und mir das Wissen anzueignen.
Danke euch für die Vorschläge.
Werde mir das mit Anycast auf jeden Fall angucken. Das mit dem Relais würde ich lieber vermeiden.
Der Intercom Server (ganz einfach ausgedrückt, IP Sprechanlage) basiert zwar auf Debian, ist aber vom Hersteller eingeschränkt. Root Zugriff haben wir nicht.
Der Hersteller bietet zu Zeit keine Redundanz an. Vielleicht kommt diese Möglichkeit ja eines Tages.
Gehen wir zum jetzigen Stand davon aus, dass am Server keine Konfigurationen möglich sind. Deshalb möchten wir das mit Netzwerkmitteln unabhängig von den Servern lösen.
Aber ich werde versuchen mehr Infos, bzw. was zum testen zu bekommen um heraus zu finden was eventuell doch auf dem Server machbar ist.
Es würde reichen, die "Zentralen" IP zu überwachen. Richtig ist auch, dass pro virtueller Komponente (Zentrale, Teilnehmerkarte) nur eine IP eingestellt werden kann.
Wer noch mögliche Lösungen hat, gerne posten.
Als VM und diese auf HA trimmen geht nicht?
Werde ich morgen mal versuchen zu klären.
Ohne eure Hardware zu kennen und eure Virtualisierungsmöglichkeiten, könnte man das Probleme so sehr elegant in Minuten lösen.
Mit Anycast ebenso, denn das ist völlig unabhängig von irgendwelcher Hardware, OS oder Applikation !
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 @142583:
Offsichtlich hast du keine Ahnung, was das Produkt Schneider Interkom für einen Inhalt hat.
Woher weißt du jetzt, dass es sich genau um dieses Produkt handelt?Offsichtlich hast du keine Ahnung, was das Produkt Schneider Interkom für einen Inhalt hat.
Ich habe nur etwas von Intercom gelesen. „Schneider“ ist mir hier nicht untergekommen oder ich habe etwas arg übersehen.
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.
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.
Ja, es handelt sich um das Produkt von Schneider Intercom.
Aber wie gesagt, da von Herstellerseite z.Z. keine Redundanz möglich ist, suchen wir eine unabhängige Lösung.
Aber wie gesagt, da von Herstellerseite z.Z. keine Redundanz möglich ist, suchen wir eine unabhängige Lösung.
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.
es ist noch niemand auf die Idee gekommen, dass eine Anycast-Verteilung die Redundanz ermöglicht?
Offensichtlich nicht.Es sind ja auch nicht immer Sicherheitsrelevante Anlagen. Es kann auch ganz einfache Tür-, Tor- oder interne Bürokommunikation sein.
In diesem Fall möchte mal wohl den Ausfall gering halten.
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.
Wie gesagt, es muss auf keine Daten des anderen Servers zugegriffen werden. Es geht um Gespräche von A nach B.Im besten Fall merkt der Benutzer nicht, dass die Endgeräte sich auf den anderen Server angemeldet haben. Wenn´s blöd läuft, ist das Gespräch weg und der Benutzer muss es neu aufbauen.
Das solltest du mal mit dem klären um herauszufinden, ob simples Anycast funktioniert.
Werden wir machen.Es ist möglich das System VirtuoSIS auf VMware oder Hyper-V zu installieren, ist aber in diesem Fall eine kleine Hardwarevariante geworden.
Wie immer ist es auch eine Preisfrage.
Da man sich hier für die kleine Hardwareversion entschieden hat, ist es anscheinend eine kleine Anlage.
Habe gerade erfahren, dass IPv6 nicht möglich ist.
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.