Tach Zusammen!
Um das Thema Skalierung abzuschließen stelle ich jetzt einmal das Sahnehäubchen vor – Orion Hochverfügbarkeit.
Es war einmal…bis Ende 2016 hinein gab es ein schreckliches Produkt bei uns. Ja, ich gebe zu, es war schrecklich: Die Failover Engine, oder auch FOE.
Hat jemand von euch einmal damit gearbeitet? Seid ihr immer noch Mitglied in der Selbsthilfegruppe?
Okay das ist Vergangenheit.
Letztes Jahr wurde FOE durch Orion HA Version 1 abgelöst und seit ein paar Monaten ist Version 2 verfügbar.
Orion HA erstellt im Prinzip eine Kopie des primären Orion Servers und funktioniert durch active/passive, liegt also solange im Hintergrund bis etwas passiert. Der Installationsprozess ist einfach, die notwendigen Anpassungen an die Infrastruktur gering.
Version 1 hatte leider eine Beschränkung: Beide Maschinen mussten im gleichen Subnetz sein.
Bei kleineren Umgebungen ist das kein Thema, aber bei mehreren Standorten muss man hier unter Umständen mit Technologien wie OTV tricksen um das VLAN zu strecken und Datenzentren verbinden.
Die Kommunikation beider Maschinen wird in dem Fall über eine virtuelle IP gelöst.
In Version 2 kam dann richtiges Desaster Recovery und erlaubt den Einsatz über Subnetze hinaus. Die Kommunikation läuft nun über einen virtuellen Hostnamen anstatt einer IP.
Soweit die Zusammenfassung und hier die komplette Dokumentation:
http://www.solarwinds.com/documentation/en/flarehelp/sam/content/ha_what_is_high_availability.htm
Aber ich führe euch einmal durch den Prozess!
Zum Verständnis:
Auf meinem Host sitzt sowohl der Orion Server (ORION) und die Datenbank (MSSQL) in einem 10.0.0.0/24 das auch nach draussen geht. Ich habe mir ein 10.0.1.0/24 erstellt das aber nur auf dem Host in einem eigenen vswitch existiert. Dazwischen sitzt eine freundliche VYOS Instanz welche die beiden Subnetze routed.
Im zweiten Subnetz habe ich eine VM ORIONHA erstellt und bisher nur in die Domain aufgenommen.
Zuerst teste ich die Namensauflösung. Es sind drei Tests notwendig; IP, FQDN, Shortname:
Das Ganze muss natürlich auf beiden Maschinen funktionieren!
Bevor ihr loslegt schlage ich vor alle Module auf den aktuellsten Stand zu bringen um Zeit zu sparen.
Öffnet auf der HA Box einen Browser, logged in Orion ein und geht zu Settings à Product… und wählt High Availablahblah:
Das sieht noch nackt aus und ich klicke auf Set Up:
Viel Auswahl gibt es hier nicht:
Ich evaluiere:
Dann lade ich den Installer herunter:
Der Installer startet, haltet euch fest…einen Installationsprozess. Und den kennen wir schon.
Ich schlage vor, das Fenster unten zum letzten Test für die DNS Auflösung zu nutzen und nur den einfachen Hostnamen einzugeben:
Anstatt APE/AWS wie beim letzten Mal wählen wir nun HA:
Oh was ist das da ganz oben?
Es gibt HA für den primären Poller, was ich gerade vorhabe, aber auch HA für zusätzliche Poller.
Das ist bei mir ausgegraut weil keine mehr vorhanden. Also weiter und der richtige Installer startet.
Nur ein Screenshot hier weil wir den schon des Öfteren gesehen haben.
Danach startet der Configuration Wizard. Den haben wir auch schon ungefähr so oft gesehen wie James Bond Goldfinger.
Sobald alles durchgelaufen ist wird automatisch die Seite High Availability Deployment Summary aufgerufen und wir sollten beide Maschinen sehen:
Und jetzt wird es endlich interessant. Wir brauchen einen Namen für den Pool sowie den virtuellen Host – ORIONPOOL in meinem Beispiel:
Jetzt wird der virtuelle Hostname angelegt:
Wir bekommen eine Zusammenfassung und klicken auf das blaue Knöpfchen:
Das war es! Naja fast.
In einer Produktivumgebung kommt jetzt natürlich noch ein Schritt der leider etwas Zeitraubend sein kann:
Ich würde an dieser Stelle NCM empfehlen um den Syslog Receiver/Netflow umzuändern.
Mir ist das furchtbar egal, ich ignoriere die Meldung und freue mich über das hier:
Ein kurzer Test:
Klasse:
Wer meinen Blog verfolgt weiss, dass ich stark abhängig bin – von Kaffee. Von daher ist jetzt Zeit für eine weitere Tasse da wir gerade einen Milestone erreicht haben.
Im DNS sieht es übrigens so aus:
Perfekt!
Kurz etwas für diejenigen von euch die wie ich unter OCD leiden:
- Ich nehme die ORIONHA Maschine als Node ins Monitoring
Wenn ich das Orion SAM Template auf der HA Maschine nutze sehe ich „Probleme“:
- Ignorieren soweit möglich…schaltet Alarme hierfür aus.
JETZT KOMMT DER ERNSTFALL!
Hat jemand von euch einen Kollegen namens Ernst? Passt gut auf ihn auf. 
Ich gehe zu meiner Orion Maschine und klaue das Netzwerk:
Teste die alte URL:
Mein Beileid:
Aber unter dem virtuellen Hostnamen:
Alles gut:
Cross-check! Die Dienste laufen nun wie erwartet auf der HA Maschine:
Und der Pool sagt „mir geht’s nicht gut, aber irgendwie geht’s trotzdem weiter“ – das sage ich übrigens auch wenn ich zum Mittagessen beim goldenen M war:
War das kompliziert?
Es waren ein paar Schritte sicherlich, aber wir haben gerade die Ausfallsicherheit für unser Orion innerhalb von wenigen Minuten realisiert. Das ist schon eine interessante Sache.
Ein paar Dinge noch hinterhergeworfen:
Windowsupdates sollten hier ähnlich behandelt werden wir ihr es bei einem Cluster erledigt, also schön nacheinander.
Orion Updates muss man planen. Wenn auf der primären Maschine Updates eingespielt worden sind, deaktiviert dies den Pool! Hier die Schritte:
http://www.solarwinds.com/documentation/en/flarehelp/sam/content/ha_upgrade_pool_members.htm
Es gibt HA für den Anwendungsserver, HA für die Polling Engines sowie HA für zusätzliche Webserver (wobei das vermutlich zu vernachlässigen ist).
Wir kümmern uns nicht um HA für die Datenbank – das ist eure Angelegenheit – nutzt AlwaysOn oder was auch immer am besten passt:
https://logicalread.com/sql-server-availability-technology/
Viel Spass mit dem Herumspielen!