SmartCollect SC² für hohe Verfügbarkeit einrichten

Die Einrichtung von SmartCollect SC² für hohe Verfügbarkeit ist ziemlich einfach. Sie benötigen nur eine gemeinsame Datenbank zum Speichern von Dashboard, Benutzern, und andere dauerhafte Daten. Die standardmäßig eingebettete SQLite-Datenbank wird also nicht funktionieren, Sie müssen zu MySQL oder Postgres wechseln.

Zuerst müssen Sie MySQL oder Postgres auf einem anderen Server einrichten und SmartCollect SC² für die Verwendung dieser Datenbank konfigurieren. Sie finden die Konfiguration dafür im [[Datenbank]]-Abschnitt (/administration/configuration/#database) in der SmartCollect SC²-Konfiguration. SmartCollect SC² wird nun alle Langzeitdaten in der Datenbank aufrechterhalten. Wie Sie die Datenbank für Hochverfügbarkeit konfigurieren, sprengt den Rahmen dieser Anleitung. Wir empfehlen, einen Experten für die von Ihnen verwendete Datenbank zu finden.

Derzeit unterstützt die Alarmierung eine begrenzte Form der Hochverfügbarkeit. Seit v4.2.0 werden Alarmbenachrichtigungen beim Betrieb mehrerer Server dedupliziert. Das bedeutet, dass alle Alerts auf jedem Server ausgeführt werden, aber die Alert-Benachrichtigungen werden nur einmal pro Alert gesendet. SmartCollect SC² unterstützt keine Lastverteilung zwischen Servern.

Nach SmartCollect SC² 6.2 brauchen Sie den Sitzungsspeicher nicht mehr zu konfigurieren, da die Datenbank standardmäßig verwendet wird. Wenn Sie die Anmeldesitzungsdaten von der Datenbank auslagern möchten, können Sie remote_cache konfigurieren.

Der zweite Punkt, den Sie berücksichtigen müssen, ist, wie Sie mit Benutzersitzungen umgehen und wie Sie Ihren Load Balancer vor SmartCollect SC² konfigurieren. SmartCollect SC² unterstützt zwei Arten der Speicherung von Sitzungsdaten: lokal auf der Festplatte oder in einer Datenbank/Cache-Server. Wenn Sie Sitzungen auf der Festplatte speichern möchten, können Sie sticky sessions in Ihrem Load Balancer verwenden. Wenn Sie es vorziehen, Sitzungsdaten in einer Datenbank/einem Cache-Server zu speichern können Sie jede zustandslose Routing-Strategie in Ihrem Load Balancer verwenden (z. B. Round Robin oder Least Connections).

Bei der Verwendung von Sticky Sessions wird der gesamte Datenverkehr für einen Benutzer immer an denselben Server gesendet. Das bedeutet, dass sitzungsbezogene Daten auf der Festplatte und nicht in einer gemeinsamen Datenbank gespeichert werden. Dies ist das Standardverhalten für SmartCollect SC² und wenn Sie nur mehrere Server für Failover wollen, ist dies eine gute Lösung, da sie den geringsten Arbeitsaufwand erfordert.

Sie können auch wählen, Sitzungsdaten in einem Redis/Memcache/Postgres/MySQL zu speichern, was bedeutet, dass der Load Balancer einen Benutzer zu jedem SmartCollect SC²-Server schicken kann, ohne sich auf jedem Server anmelden zu müssen. Dies erfordert ein wenig mehr Arbeit vom Betreiber, ermöglicht es Ihnen aber, SmartCollect-Server zu entfernen/hinzufügen, ohne die Benutzererfahrung zu beeinträchtigen. Wenn Sie MySQL/Postgres für die Sitzungsspeicherung verwenden, benötigen Sie zunächst eine Tabelle, in der die Sitzungsdaten gespeichert werden. Mehr Details dazu in [sessions]

Für SmartCollect SC² selbst spielt es keine Rolle, ob Sie die Sitzungsdaten auf der Festplatte oder in einer Datenbank/Redis/Memcache speichern. Wir empfehlen jedoch die Verwendung von Datenbank/Redis/Memcache, da dies die Verwaltung der SmartCollect-Server erleichtert.