Bei meinem aktuellen Arbeitgeber steht die Migration in zwei neue Rechenzentren an. Eines der Ziele dieser Migration ist die Erhöhung der Ausfallsicherheit. Dies habe ich zum Anlass genommen mir den PRTG Failover Cluster mit einem vorgeschalteten Citrix ADC einmal anzuschauen.

Die Installation und Konfiguration ist eigentlich recht einfach und das Vorgehen möchte ich in diesem Artikel nochmals erläutern.

PRTG Failover Cluster konfigurieren

Um den Core-Server von PRTG als Failover-Cluster zu konfigurieren gibt es seitens PAESSLER zwei gute Artikel:
– Failover Cluster Configuration
– Failover Cluster Step by Step

Wenn man sich an diese hält, läuft der Cluster in kürzester Zeit. Was gibt es zu beachten?

• Der zweite Cluster-Node ist immer Read-Only, d.h. selbst bei einem Ausfall des Master-Servers kann auf dem Failover-Server nur überwacht, jedoch nicht konfiguriert werden.
• Remote Probes müssen so (um-)konfiguriert werden, dass sie ihre Daten an alle Cluster Nodes senden und nicht nur dem Master.
• Die Remote Probes werden vom PRTG Cluster selbst konfiguriert. Eine allfällige Registry Anpassung (manuell oder via GPP) wird wieder überschrieben.
• Remote Probes müssen jeden Cluster Node einzeln erreichen können. Bei einer NAT Konfiguration bedeutet dies ein eigener FQDN und NAT Zugang pro Core Server.
• Der erste Administrator (prtgadmin) ist autonom pro Node. Um spätere Probleme zu vermeiden sollte das Passwort auf beiden Servern identisch gesetzt und mit der AD Authentifizierung gearbeitet werden.
• Nur der Master-Server sieht sich selbst noch als „Local Probe“. Auf den Failover-Servern ist nur der „Cluster Probe“ und alle anderen Remote Probe Server ersichtlich.
• Die Probe Dienste der PRTG Core Server senden ihre Daten nur lokal (127.0.0.1).

In den Cluster Einstellungen sollte man die „Node Namen“ passend setzen und die IP Adressen durch FQDN ersetzen.
Dies macht es einerseits übersichtlicher für alle PRTG Benutzer und andererseits ist man unabhängiger bei einer allfälligen Änderung der IP Adressierung.

Hinweise:
– Man kann zwar im GUI dem Master Server einen DNS Alias setzen, die Remote Probes erhalten jedoch immer den originalen Hostname übermittelt.
– Die Änderung wird sofort an die Remote Probes übermittelt.

Bei einer frischen Installation kann nun die Konfiguration direkt in der Cluster Probe gestartet werden. Wurde ein Solo PRTG Core Server in einen Cluster umgewandelt, so müssen die konfigurierten Gruppen, Geräte und Sensoren vomr „Local Probe“ in den „Cluster Probe“ verschoben werden:

Konfiguration Citrix ADC

Nachdem nun der PRTG Failover Cluster soweit konfiguriert ist, bauen wir nun den Zugriff auf diesen. Ohne ADC würde man nun entweder mittels DNS Round-Robin einen FQDN konfigurieren, wobei man hier nicht steuern kann auf welchem Node man landet, oder man arbeitet mit zwei verschiedenen FQDN, was wiederum nicht Anwenderfreundlich ist.

In diesem Abschnitt wird die Konfiguration eines LB vServer mit Failover Funktion erläutert.

Hierzu werden alle (normalerweise zwei) Cluster Nodes im ADC erfasst:

add server prtgserver1 prtgserver1.domain.pit
add server prtgserver2 prtgserver2.domain.pit

Für jeden Server erstellen wir einen Service. Nach best practice sind die PRTG Server SSL verschlüsselt, somit bauen wir passende Services dazu:

add service svc-https-prtgserver1 prtgserver1 SSL 443
add service svc-https-prtgserver2 prtgserver2 SSL 443

Im Gegensatz zu einem normalen Loadbalancing wird im Failover nicht ein einzelner sondern zwei vServer benötigt, um den zweiten als Backup zu konfigurieren. Dem vServer mit einer IP wird der Service des PRTG Master Servers angefügt. Der zweite vServer (ohne Adressierung) steuert den PRTG Failover Server an. Beide LB vServer benötigen auch das dazu passende SSL Zertifikat:

add lb vserver lb-vsrv-prtg.domain.pit SSL 192.168.200.222 443
add lb vserver lb-vsrv-prtg-backup.domain.pit SSL 0.0.0.0 0
 
bind lb vserver lb-vsrv-prtg.domain.pit svc-https-prtgserver1
bind lb vserver lb-vsrv-prtg-backup.domain.pit svc-https-prtgserver2

bind ssl vserver lb-vsrv-prtg.domain.pit -certkeyName wildcard.domain.pit
bind ssl vserver lb-vsrv-prtg-backup.domain.pit -certkeyName wildcard.domain.pit

set lb vserver lb-vsrv-prtg.domain.pit -backupVServer lb-vsrv-prtg-backup.domain.pit

Dem Service Monitoring habe ich am meisten Zeit gewidmet. Die PRTG Server bieten eine Status-Seite (/api/public/testlogin.htm), welche jedoch bereits bei einem Problem mit dem Mailserver ein „NOTOK“ zurück meldet.
Nur diese Status-Seite alleine konnte ich also nicht nutzen. Daher baute ich ein Monitoring basierend auf dieser plus zusätzlichen zwei Standard-Monitoren (TCP und HTTP). Da sich der TCP-Default Monitor nicht anfügen lässt wenn bereits ein anderer Monitor in Benutzung ist, habe ich einen eigenen erstellt.
Wegen der Benutzung von HTTPS muss dem HTTP Monitor der Response Code 302 hinzugefügt werden.

add lb monitor mon-prtg-TCP TCP
add lb monitor mon-prtg-http HTTP -respCode 200 302 -httpRequest "HEAD /" -secure YES

Das Monitoring der Status-Seite bat mir ein erstes Mal die Nutzung des „Reverse“ Monitorings. Würde man nämlich nur die Antwort „OK“ prüfen, so wäre der Monitor auch bei einem „NOTOK“ zufrieden, da „OK“ ein Bestandteil der Antwort ist. Daher prüfen wir auf ein „NOTOK“ und geben mit dem Monitor grünes Licht, falls diese Antwort nicht vorhanden ist – Reverse eben. ;-)

add lb monitor MON-PRTG-Core-Status HTTP-ECV -send "GET /api/public/testlogin.htm" -recv NOTOK -reverse YES -secure YES

Zu guter Letzt müssen die neu gebauten Monitore in den Services konfiguriert werden. Dazu fügen wir pro Service die drei hinzu und definieren den Monitoring Schwellwert 2. So bleibt der Service verfügbar, solange zwei Monitore grünes Licht geben:

bind service svc-https-prtgserver1 -monitorName mon-prtg-http
bind service svc-https-prtgserver1 -monitorName mon-prtg-TCP
bind service svc-https-prtgserver1 -monitorName mon-prtg-Core-Status
bind service svc-https-prtgserver2 -monitorName mon-prtg-http
bind service svc-https-prtgserver2 -monitorName mon-prtg-TCP
bind service svc-https-prtgserver2 -monitorName mon-prtg-Core-Status

set service svc-https-prtgserver1 -monThreshold 2
set service svc-https-prtgserver2 -monThreshold 2

Mit dieser Konfiguration kann nun ein Benutzer über eine FQDN (z.B. prtgcluster.domain.pit) auf die PRTG Oberfläche zugreifen. Der LB vServer vom ADC schaltet erst auf den Failover Server um, sobald der Master Server nicht mehr verfügbar ist (z.B. Neustart). Ist der Master Server wieder online, schaltet der ADC wieder auf diesen zurück.

Viel Spass beim Nachbauen. :-)

Citrix bietet zur Überwachung und Konfiguration von Citrix ADC (ehem. NetScaler) das Citrix Application Delivery Management (ehem. NetScaler MAS). Wie kann man nun aber die ADC Appliances im PRTG überwachen? Diese Frage haben sich schon einige gestellt und nebst kostenpflichtigen Plugins von www.prtgplugins.com gibt es weitere Open Source Optionen.

Eine mögliche Lösung habe ich bei Jason McKenry gefunden. Er hat basierend auf dem NetScaler PowerShell Modul passende Skripte erstellt, mit welchen aktuell folgendes überwacht werden kann:

• Appliance Performance (CPU, PE CPU, Disk, RAM und Durchsatz)
• Status aller vServer (LB, AAA, VPN und CS)
• Status aller LB vServer
• Ablaufdaten aller Zertifikate
• ungespeicherte Konfigurationen

Sein Blog-Artikel erklärt die komplette Konfiguration in Englisch. Ich möchte in diesem Artikel einerseits die Vorgehensweise auf Deutsch erläutern und andererseits noch ein paar Ergänzungen anbringen.

Als Basis dient nun jedoch der Blog-Artikel von Jason:

Quelle: https://itrandomness.com/2018/01/monitoring-netscaler-with-prtg/

Als erstes lädt man die passenden Skripte herunter. Dieser sind entweder auf GitHub (manchmal aktualisiert) oder am Ende des Artikels zu finden.

Nun muss das NetScaler Module installiert werden. Hierbei gibt es folgendes zu beachten:

• Ein aktuelles Windows Management Framework sollte installiert sein (muss manuell gemacht werden, nicht über die Microsoft Updates).
• PRTG arbeitet mit der 32-bit Version von PowerShell. Somit müssen alle Befehle in der (x86) Version ausgeführt werden.
• Das NetScaler Module muss auf allen Probe Server installiert werden, welche den Custom Sensor ausführen sollen.

Wenn alles rund läuft reichen folgende Befehle:

Set-ExecutionPolicy Unrestricted
Install-Module -Name NetScaler -scope AllUsers

Ich hatte auf meinem System das Problem, dass kein passender Provider gefunden wurde. Bei der Fehleranalyse stellte ich fest, dass im System kein Paket-Provider registriert war. Mit folgenden Befehlen kann dies korrigiert werden:

Install-PackageProvider Nuget –Force
Install-Module –Name PowerShellGet –Force

Damit wir die Appliances abfragen können, benötigen wir einen lokalen Benutzer auf jeder Appliance. Dieser benötigt nur Read-Only Rechte:

add system user svcprtg PASSWORD -externalAuth DISABLED
bind system user svcprtg read-only 100

Nun müssen die Sensor Dateien in die entsprechenden Ordner kopiert werden.

Die .ps1 Dateien kommen in den Ordner „Custom SensorsEXEXML“ (Standard: %programfiles(x86)%PRTG Network MonitorCustom SensorsEXEXML).

Die .ovl Dateien kommen in den Ordner „lookupscustom“ (Standard: %programfiles(x86)%PRTG Network Monitorlookupscustom).

Anschliessend müssen die Dateien (lookups) im PRTG neu geladen werden. Der Menüpunkt ist unter PRTG > Setup > Administrative Tools zu finden:

Bevor die Sensoren eingerichtet werden können, muss der neu erstellte Benutzer konfiguriert werden. Entweder gilt dieser nur für die ADC Appliances oder es ist eine Überlegung wert, den Benutzer für alle Linux/UNIX Server zu verwenden:

Nun können die fünf Sensoren (einer pro PowerShell Skript) eingerichtet werden. Diese werden als EXE/Script Advanced hinzugefügt. Der Name kann frei vergeben werden. Folgende Parameter müssen mitgegeben werden:

%host %linuxuser %linuxpassword

Hier ein paar Beispiele:

Falls seitens ADC vServer hinzugefügt oder entfernt werden, so muss der Sensor neu eingerichtet werden. Die Channels können dies nicht automatisch abgleichen.

Viel Spass beim Nachbauen. :-)

Bei meinem aktuellen Brötchengeber pflegen wir eine grössere Infrastruktur, welche auch nicht mehr mit nur einem PRTG Server auskommt. Aktuell Überwachen wir rund 800 Devices mit ca. 11’000 Sensoren – Tendenz steigend – mit Probe Server an verschiedenen Standorten.

Jeder PRTG Administrator mit ähnlichen Voraussetzungen kennt das Problem wenn nicht nur mit den standardmässig mitgelieferten Sensoren gearbeitet wird: ein neuer Custom Sensor muss an jeden Probe Server verteilt werden falls das Device einmal innerhalb der Konfiguration verschoben wird.

Um diesen simplen Kopiervorgang ein wenig zu automatisieren habe ich ein kleines Batch-Skript geschrieben, welches am Ende des Artikels heruntergeladen werden kann.

Da mit Schleifen gearbeitet wird, muss zuerst das Timeout zur Auflösung der Variablen erhöht werden:

Setlocal EnableDelayedExpansion

Quelle: https://ss64.com/nt/delayedexpansion.html

Das Skript besteht aus fixen Variablen wie dem PRTG Core-Server sowie dem Pfad der Sensoren sowie anschliessend aus wechselnden Variablen, den PRTG Probe-Servern. Als erstes setzen wir jedoch die fixen:

SET SensorPath=C$Program Files (x86)PRTG Network MonitorCustom Sensors
SET PRTGServer=prtgcore.domain.pit

Im nächsten Schritt wird das Array für die verschiedenen Probe-Server erstellt. Jeder zusätzliche Server benötigt eine eigene Zeile, in welcher die Zahl in den eckigen Klammern erhöht werden muss. Die letzte Zeile dient als Start für die Kalkulation der Anzahl Probes:

SET PRTGProbe[0]=prtgprobe1.domain.pit
SET PRTGProbe[1]=prtgprobe2.domain.pit
SET PRTGProbe[2]=prtgprobe3.domain.pit
SET PRTGProbes=0

Nach dem Erstellen des Arrays muss die Anzahl für die folgende Schlaufe ermittelt werden. In meinen ersten Testläufen wurde die Schlaufe dann jeweils einmal zu viel abgearbeitet, weshalb ich das Resultat der Kalkulation um 1 reduziere. Falls hier jemand eine bessere Idee hat, dann darf gern das Kommentarfeld benutzt werden:

IF defined PRTGProbe[%PRTGProbes%] (
     SET /a "PRTGProbes+=1"
     GOTO PRTGCount
)
 
SET /a PRTGProbes=%PRTGProbes%-1

Abschliessend wird mittels Schlaufe ein Robocopy Befehl für jeden Probe-Server abgesetzt, welcher den Inhalt des Ordners „Custom Sensors“ verteilt:

FOR /l %%n in (0,1,%PRTGProbes%) do (
    ROBOCOPY "%PRTGServer%%SensorPath%" "!PRTGProbe[%%n]!%SensorPath%" /E /R:1 /W:1 /COPYALL
)

Viel Spass beim Nachbauen.

Immer wieder wurde ich von meinen Kursteilnehmern gefragt, welche Monitoring-Lösung ich verwenden würde. Bisher waren mir Produkte wie SCOM, Nagios etc. bekannt. Seit meinem Arbeitgeberwechsel durfte ich ein neues Produkt kennenlernen.

PRTG von Paessler ist ein intuitives Monitoring-Programm, welches schnell zu erlernen ist. Gerne werde ich in Zukunft auch öfter über Konfigurationen hier schreiben.

Nachdem ich das Produkt das erste Mal gesehen habe, wollte ich es ausprobieren. Auf der Homepage der Nürnberger Softwarefirma findet man relativ schnell eine vollwertige Trial-Version, welche nach Ablauf der Testphase zu einer auf 100 Sensoren limitierte wird –> Homepage

Die Installation war ohne weitere Probleme durchgeführt. PRTG kommt ohne SQL Datenbank aus, so dass man auch hier auf weitere Lizenzen verzichten kann. Nach dieser startet das Auto Discovery und das Grundsetup ist abgeschlossen.

Für ein effizienteres Monitoring empfiehlt es sich SNMP auf den Servern und Geräten zu konfigurieren. Hierzu später mehr…

Die Geräte und Sensoren können nach Belieben sortiert werden:

Für einen ersten Überblick oder für verschiedene Helpdesk können mit sogenannten Maps die Daten bedarfsgerecht aufbereitet und dargestellt werden:

Preislich ist PRTG sicherlich teurer wie eine reine Opensource Lösung, dafür muss man weniger „basteln“ wie bei manch einem anderen Produkt. Es gibt in der Funktion keine Differenzierung der Editionen, sondern es werden die Anzahl Sensoren (Messpunkte) lizenziert. Die Preise sind meiner Meinung nach gerechtfertigt und das Preis-/Leistungsverhältnis nahezu perfekt.

Viel Spass beim Ausprobieren :-)