Load Balancing
Nutzen Sie den Load Balancer, um ihren Datenverkehr auf mehrere Server zu verteilen und die Performance zu optimieren.
Last updated
Nutzen Sie den Load Balancer, um ihren Datenverkehr auf mehrere Server zu verteilen und die Performance zu optimieren.
Last updated
Der Load Balancer nimmt die Anfragen der Clients entgegen und leitet diese an den am besten geeigneten Server weiter. Somit stellen Sie sicher, dass Enginsight auch bei einer Vielzahl eingehender Anfragen optimal läuft.
Wir empfehlen die Nutzung des Load Balancers spätestens ab 500 zu betreuenden Hosts.
Zur Nutzung des Load Balancing müssen 3 zusätzliche virtuelle Maschinen bereitgestellt werden:
VM für den Load Balancer
VM für die Services
VM für den 2. App-Server
Für einen flüssigen Betrieb empfehlen wir Ihnen Nginx als Reverse Proxys zu nutzen.
Bereiten Sie im ersten Schritt die VM für den Load Balancer vor. Dieser dient der Zertifikatsbehandlung und Weiterleitung Ihrer Anfragen.
Es gilt zu beachten, dass auf der VM, auf der der Nginx läuft kein Docker installiert wird. Nur so können Sie einen reibungslosen Ablauf sicherstellen.
Stellen Sie eine VM für den Load Balancer bereit.
Installieren Sie den Nginx mittels sudo apt install nginx
. Übernehmen Sie hierfür ganz einfach die Konfiguration und passen Sie diese entsprechend an.
Fügen Sie nun die Zertifikate hinzu und passen Sie die Pfade entsprechend in der Konfiguration an. Bsp.:
Ablageort der Zertifikate: /etc/nginx/ssl
Anpassung in der Konfiguration:
ssl_certificate /etc/nginx/ssl/fullchain.pem;
und
ssl_certificate_key /etc/nginx/privkey.pem;
Sollten Sie Ihre Zertifikate auf IP Adressen ausgestellt haben, stellen Sie sicher, dass die jeweiligen Zertifikate auch auf die korrekten IP-Adressen ausgestellt sind.
Diese VM ist ausschließlich für die Ausführung der folgenden Services bereit zustellen:
Beachten Sie unbedingt, dass die Services nun auf einer separaten VM ausgeführt werden und berücksichtigen Sie dies bei der Konfiguration Ihrer App Server.
Installieren Sie Docker und laden Sie das Enginsight Repo auf Ihre Services VM (Installation Appserver Schritt 1-4).
Passen Sie nun die docker-compose.yml
unter /opt/enginsight/enterprise
gemäß den Anweisungen an.
Stellen Sie sicher, dass immer die aktuellen Versionsendungen genutzt werden.
Hinterlegen Sie eine Mail-Server-Konfiguration und stellen Sie sicher, dass die Mail-Server-Konfiguration identisch mit jener auf den App-Servern ist.
Sichern Sie Ihre Datenbank mit iptables
ab.
Passen Sie die iptables
so an, dass jegliche Verbindungen von außerhalb zur Datenbank blockiert werden. Dieser Schritt führt dazu, dass nur die Applikation auf die MongoDB zugreifen kann und unberechtigte Zugriffe verhindert werden.
Fügen Sie neue Regeln für den 2. App Server sowie den Server hinzu, auf dem die Services ausgeführt werden. Rufen Sie hierfür die iptables
auf.
Ersetzen Sie <APP IP>
durch die von der Datenbank erreichbare IP des Applikationsservers. Ersetzen Sie <DB IP>
durch die von der Applikation erreichbare IP des Datenbankservers und fügen Sie, wie unten abgebildet, Regeln für den Redis hinzu.
Sobald alle Änderungen vorgenommen sind speichern Sie Ihre Einstellungen persistent.
Fügen Sie nun Redis hinzu, indem Sie den Redis-Server installieren.
Passen Sie die Konfiguration an.
Speichern und starten Sie die Anwendung anschließend neu.
Bereiten Sie zwei Virtuelle Machinen für die App-Server vor. Diese VMs gewährleistet, dass die Benutzeroberfläche von allen Servern aus erreichbar ist und die Services parallel ausgeführt werden können.
Falls Sie Enginsight zuvor ohne Load Balancer genutzt haben, können Sie den bisher genutzten App-Server als eine der 2 benötigten App-Server VMs verwenden!
Dies erleichtert die Einrichtung des Load Balancers erheblich und ermöglicht es Ihnen, schnell mit der Implementierung fortzufahren.
Installieren Sie Docker und laden Sie das Enginsight Repo auf Ihre Services VM (Installation Appserver Schritt 1-4).
Um Zeit und Mühe zu sparen, empfehlen wir Ihnen, entweder unsere ISO-Datei zu nutzen oder den ersten App-Server zu klonen, um die zweite VM für den App-Server zu erstellen.
Passen Sie die docker-compose.yml , wie nachfolgend angegeben an.
Beachten Sie auch hier, dass am Ende stets die aktuellen Versionen stehen. Passen Sie hierfür entweder die .xml an und löschen Sie alle nicht benötigten Einträge oder passen Sie die Versionen selbstständig an.
Hinterlegen Sie, falls noch nicht vorhanden, die Mail-Server-Konfiguration und stellen Sie sicher, dass die Mail-Server-Konfiguration identisch mit jener auf der Services-VM ist.
Sollten Sie den App Server geklont haben, so deaktivieren Sie den nginx auf beiden App Servern mit dem Befehl: systemctl stopp nginx
und systemctl disable nginx
Kopieren Sie den Inhalt der Datei DEFAULT_JWT_SECRET.conf
unter /opt/enginsight/enterprise/conf
und fügen Sie diese auf dem 2. App Server in die selbe Datei ein. So stellen Sie sicher, dass beide Dateien identisch auf beiden Servern hinterlegt sind.
Prüfen Sie nun die Connection zu Redis. Loggen Sie sich hierfür in den Container ein und stellen Sie eine Verbindung her:
Redis Connection prüfen
docker ps
docker exec -it <ID von server-m2> /bin/sh
redis-cli -h <IPDB>
Überprüfen Sie nun anhand der Docker Logs von server m-2, ob eine Connection von der Datenbank zu Redis besteht.
Ändern Sie den DNS Eintrag.
Beachten Sie hierbei, dass die URL der APP und der API auf den Loadbalancer ausgerichtet sind und nicht mehr auf den APP Server.
Sobald Sie alle VMs vorbereitet haben, können Sie die setup.sh
ausführen.
Beachten Sie, dass die Redis URL in redis://<IPDB>:6379
abgeändert werden muss
Jetzt ist es an der Zeit zu überprüfen, ob Ihre Anwendung auch im Falle eines einzelnen Serverausfalls weiterhin problemlos funktioniert.
Führen Sie hierfür docker-compose down
auf dem APP Server 1 aus und überprüfen Sie, ob der APP Server 2 weiterhin Daten empfängt und alle Hosts weiterhin aktiv sind.
Fahren Sie alle Docker Container mit docker-compose up -d
wieder hoch
Führen Sie die Unterpunkte 1 und 2 nocheinmal für App Server 2 durch.
Beachten Sie, dass das Update-Script nun immer auf allen drei Servern ausgeführt werden muss, um sicherzustellen, dass alle Server auf dem neuesten Stand sind und keine Inkompatibilitäten auftreten.
Service | Funktion |
---|---|
sentinel-m3
Regelt Alarme und verwaltet zugeordnete Benachrichtigungen.
reporter-m4
Versorgt die Enginsight-Plattform mit aktuellen Vulnerabilitätsdaten (CVEs) und verteilt sie an die Module.
profiler-m22
Sorgt für die Berechnung des Normalverlaufs der Machine Learning Metriken.
anomalies-m28
Gleicht Normalverlauf der Machine Learning Metriken mit den gemessenen Daten ab, um Anomalien zu erkennen.
scheduler-m29
Löst geplante, automatisierte Aktionen aus, zum Beispiel Plugins oder Audits.
updater-m34
Managed und aktualisiert die Konfigurationschecklisten.
generator-m35
Erzeugt PDF-Berichte, z.B. für Hosts, Endpunkte und Penetrationstests.
historian-m38
Fasst gemessene Daten zusammen, um sie im zeitlichen Verlauf darzustellen.
themis-m43
Fungiert als Integritäts-Manager und überprüft Daten auf Korrektheit sowie Aktualität.