VM überwachen und im Falle eines Ausfalls Route umleiten
-
Moin,
VoIP ist mal so eine Sache, die unglaublich komplex und damit auch teuer werden kann.
Dein Konstrukt ist gut, allerdings bedeutet es auch viel aufwand:Die VMs und auch der VoIP-Cluster müssten sich immer synchronisieren - das ist ein echtes Problem.
Außerdem gibt es an jedem Standort immer eigene Konfiguartionsteile - heißt man muss im Prinzip trotzdem alles doppelt pflegen.Ich weiß ja nicht mit wie vielen Anschlüssen zurechnen ist aber man sollte mal den Aufwand (auch finanziell) ins Verhältnis zur Nutzerzahl setzen.
Der Üblichere Weg:
Warum nutzt Du nicht den Vorteil von VoIP ? Das sind IP-Ströme, die müssen nicht immer vor Ort umgesetzt werden.
Du baust ein HQ mit doppelter Anbindung nach außen, wo du für ausreichend Redundanzen sorgst und hängst dein BO per VPN (s2s) hinten dran, schön wäre ebenfalls mit 2xWAN.
Dann musst Du lediglich das HQ intensiv pflegen und die BOs belasten Dich nicht weiter.
Außerdem sparst du eine Mege Geld für Hardware die nur im HQ stehen muss und die Leitung zum BO muss keine 100MBit/s sein.gerade kleine Außenstellen lassen sich prima mit ner einfachen Fritze per VPN anklemmen - kein großer Aufwand!
Ich würde mich vielleicht noch mal ans Reißbrett setzen und das ganze überdenken.
-
Hallo und Danke für die Anregung,
aber die Vorgabe ist, dass die Konfig nur an einer Stelle gepflegt werden soll (VM1 wird zur VM2 repliziert). UND die VMs/Hardware darf nur an den Standorten stehen.
Sonst hätte ich die Anlage direkt in die Cloud ausgelagert und dann wäre es egal, wo der Rest steht.Es ist einer dieser Fälle, wo die Vorgaben die üblichen Ansätze zu Nichte machen. Was VOIP angeht, so ist Wissen im Überfluss vorhanden.
Aber vielen Dank für Deine Anregungen.
-
Hallo,
da wir auch Telefonanlage bauen und betreuen klingt das für mich nach einer Andwednung für eine Innovaphone PBX.
Hier kann man Master und Salve aufbauen und muss alles nur einmal pflegen.
Die Telefone von Innovaphone schauen ist der Master da gut gehe ich zu dem ist der nicht mehr da gehe ich zum Slave. Daher machen die Telefone die aktive Arbeit beim Ausfall.Ansonsten bastelt man sich hier nur was zusammen was im Falle eines Ausfalls dann doch nicht richtig geht.
-
Ich sehe da wie Freund Flix das Problem auch eher auf VoIP Seite gelagert, weniger auf pfSense Seiten. Das Problem für die pfSense dürfte schon der Wunsch sein, den Ausfall von VM1 zu detektieren und darauf basierend irgendwas umzurouten. Das ist nicht ihr angedachter Job - natürlich zu routen, aber nicht einen Ausfall einer spezifischen VM zu erkennen. Zudem läuft SIP Traffic ja im Normalfall UDP basierend ab, somit auch keine States oder stehende Kommunikation. Reißt also die Verbindung zu VM1 ab könnte man vielleicht auf pfSense Seiten was schnitzen, dass dann der Traffic redirected wird (interne VIP o.ä. die dann ein anderes RDR Ziel hat) aber schön ist das nicht.
Dass die Telefone das selbständig merken und von sich aus mit dem Slave kommunizieren ist da um einige Grade sinnvoller :)
-
Moin zusammen,
also unsere Innovaphone haben wir vor 10 Jahren abgelöst - mag ja sein, dass die inzwischen dazu gelernt haben.
Bin allerdings kein Freund von hot/standby - Lösungen.was das Umschwenken betrifft, so bliebe vielleicht noch das Routen mit Metriken, was eine Route präferiert und die andere sauer macht. Dazu müsste allerdings ein Interface an der PF mit der VM down gehen ;(
Evtl. sogar zu dynamischem routing zu wechseln. Habe aber noch nie OSPF auf einer PF ausprobiert - das mache ich sonst auf Ciscos.Das Problem beim Verursacher zu lösen macht aber mehr Sinn.
Die meiste Anlagen die ich kenne, die mehr als 2000 Phones schaffen, sind Cluster-Fähig.
Somit kümmern diese sich darum, dass sie für die Telefone erreichbar sind, auch wenn sie aus x-Knoten bestehen.
Solche Cluster setzen allerdings zu meist wirklich schnelle Netze (ab 10 GE voraus). Daher meist auch räumliche Nähe.Gruß
-
Hallo Zusammen,
es wäre überhaupt kein Problem hätte man dem Kunden eine größere Anlage verkauft. Die könnte direkt 2 IP-Adresskreise, Failover usw.
Und jetzt mal Hand aufs Herz: "Wer musste noch nie die Versprechungen vom Vertrieb ausbaden?" :)Für die VM-Überwachung wollte ich den LoadBalancer "missbrauchen"
https://doc.pfsense.org/index.php/Inbound_Load_Balancing#Failover_and_RecoveryÜber TCP wird geprüft, ob die Anlage erreichbar ist. WEnn das nicht der Fall ist, dann wird der komplette kommende Traffic 1:1 umgeleitet zu der anderen pfsense.
Ich habe auch Kopfschmerzen dabei, zumal der Zeitplan mehr als straff ist. Bisher bin ich erst am evaluieren, ob das überhaupt klappt mit der Umschaltung.
PS: https://www.joerg-leuschner.de/pfsense/pfsense-monitoring-von-netzwerkinterfaces/
scheint auch keine schlechte Idee zu sein.Im Endeffekt wäre die Idee 2 Gateways zu haben und je nach Verfügbarkeit der VM diese umzuschalten.
Kaffee brauch
-
Hi Leidensgenosse,
manchmal muss man den Vertriebler auch mal an seiner Krawatte zum lüften raus hängen.
Ich sollte auch mal beim Kunden am WAN-Eingang QOS machen :o - ja ne is klar, gib mir nen Proxy mit 4 TB Ram und wir reden über diesen blödsinn.
Aber mal in ernst: Wenn die eine "Falsche" Anlage verkauft haben müssen die halt mal dazu stehen.
Mit dem was Du da vor hast wirst Du vermutlich nicht glücklich und der Kunde ebenfalls nicht. Das ist für alle beteiligten nicht zielführend!Da wäre mal eine hausinterne Schulung für den Vertrieb " VoIP - so geht's richtig " angebracht.
-
Kann ich trixters nur beipflichten :) Unser (ehemaliger) Vertriebler wollte mich nicht mitnehmen zu Kunden - ich wäre zu negativ. Naja, wenn es negativ ist, dass ich dem Kunden keinen Mist verkaufe, dann wahrscheinlich schon :D Es gilt eben vielfach:
"Das kannste schon so machen, aber dann isses halt kacke!"
-
Hallo,
kleine Zwischeninfo.
Mit GW-Umschaltung funktioniert das schon mal. sogar ziemlich gut. Somit bleiben nur noch alle anderen offenen Themen :)
Und an alle Leidgenossen: wenn niemand "unmögliches" verkaufen würde, dann könnte auch keiner von uns die Geschichten erzählen "unmögliches vollbracht zu haben" :)Ich werde klar definieren, was möglich ist und was man garantiert und was dann im Desaster-Fall zu tun ist. Letztendlich muss es schon an mehreren Stellen versagen, damit es zu einem Ausfall kommt. Natürlich nicht unmöglich, aber schlimmstenfalls sind die VMs auch schnell woanders hingezogen.
ES wird viel Kaffee brauchen, aber am Ende wird man sich wieder an Toyota-Werbung erinnert fühlen. :)
-
Mit GW-Umschaltung funktioniert das schon mal. sogar ziemlich gut.
Und die hast du jetzt wie realisiert? Standen ja mehrere Varianten im Raum :)
-
http://www.mustafaulusoy.de/pfsense-loadbalancing-und-failover-einrichten/
War so frech zu googeln :)
-
Das ist ein altes (und nicht mehr ganz aktuelles) Tutorial wie man normales WAN Failover einrichtet. Ich sehe nicht, wie das in dem Fall jetzt genau angewendet werden sollte auf deinem Fall, eine VM redundant verfügbar zu machen?
