Hochverfügbarkeit bezieht sich auf eine Entwicklungsmethode, die ein System so verfügbar halten soll, wie es praktisch umsetzbar ist. Es wird beabsichtigt, die Gründe für Ausfallzeiten wie Systemfehler und Wartungstätigkeiten zu minimieren. Außerdem soll die Zeit verkürzt werden, die zur Erkennung von und Wiederherstellung nach auftretenden Ausfallereignissen benötigt wird. In der Praxis werden automatische Methoden der Erkennung von und Wiederherstellung nach Ausfallereignissen schnell erforderlich, weil höhere Verfügbarkeitsgrade errreicht werden müssen.
Sentinel ist eine komplexe, mehrschichtige Anwendung, die von einer großen Vielzahl von Diensten abhängt und diese bereitstellt. Außerdem kann es in mehrere Systeme von Drittanbietern zur Datenerfassung, Datenfreigabe und Vorfallbehebung integriert werden. Die meisten Hochverfügbarkeitslösungen ermöglichen es den Anwendern, Abhängigkeiten zwischen den Diensten, die hochverfügbar sein sollten, und den abhängigen Diensten zu definieren, doch dies trifft nur auf Dienste zu, die im Knoten selbst ausgeführt werden. Sentinel-externe Systeme wie Ereignisquellen müssen separat konfiguriert werden, um so verfügbar zu sein, wie es im Unternehmen erforderlich ist. Diese müssen auch konfiguriert werden, um Situationen ordnungsgemäß verarbeiten zu können, in denen Sentinel für eine bestimmte Zeit nicht verfügbar ist, wie zum Beispiel bei Failover-Ereignissen. Wenn die Zugriffsrechte stark eingeschränkt sind, zum Beispiel wenn authentifizierte Sitzungen zum Senden/Empfangen von Daten zwischen dem Drittanbietersystem und Sentinel verwendet werden, muss das Drittanbietersystem so konfiguriert werden, dass es Sitzungen von beliebigen Clusterknoten akzeptiert oder dort initiiert (Sentinel sollte zu diesem Zweck mit einer virtuellen IP-Adresse konfiguriert werden). NetIQ kann keinen bestimmten Grad an Hochverfügbarkeit zwischen unserem Produkt und Drittanbietersystemen garantieren, die außerhalb unserer Kontrolle liegen.
Alle Hochverfügbarkeits-Cluster erfordern irgendeine Form von freigegebenem Speicher, sodass diese Anwendungsdaten schnell von einem Clusterknoten in ein anderen verschoben werden können, falls im ursprünglichen Knoten ein Fehler auftritt. Der Speicher selbst sollte hochverfügbar sein. Dies wird normalerweise durch die Verbindung der SAN-Technologie (Storage Area Network, SAN) mit den Clusterknoten über ein FibreChannel-Netzwerk erreicht. Andere Systeme verwenden NAS (Network Attached Storage), iSCSI oder andere Technologien, die ein Ferneinhängen eines freigegebenen Speichers zulassen. Die grundlegenden Anforderungen des freigegebenen Speichers bestehen darin, dass der Cluster den Speicher sauber von einem fehlerhaften Clusterknoten an einen neuen Clusterknoten verschieben kann.
HINWEIS:Für iSCSI sollten Sie die größte von der verwendeten Hardware unterstützte MTU (Message Transfer Unit) verwenden. Größere MTUs verbessern die Speicherleistung. In Sentinel können Probleme auftreten, wenn die Latenz bzw. Bandweite zum Speicher nicht den Mindestempfehlungen entspricht.
Es gibt zwei grundlegende Vorgehensweisen, die Sentinel für den freigegebenen Speicher verwenden kann. Bei der ersten werden alle Komponenten (Anwendungs-Binärdateien, Konfiguration und Ereignisdaten) im freigegebenen Speicher gesucht. Bei einem Failover wird der Speicher am primären Knoten ausgehängt und in den Sicherungsknoten verschoben. Dadurch wird die gesamte Anwendung und Konfiguration des freigegebenen Speichers geladen. Bei der zweiten Vorgehensweise werden die Ereignisdaten im freigegebenen Speicher gespeichert, doch die Anwendungs-Binärdateien und die Konfiguration bleiben auf jedem Clusterknoten. Bei einem Failover werden nur die Ereignisdaten in den Sicherungsknoten verschoben.
Jede Vorgehensweise hat Vorteile und Nachteile, doch bei der zweiten Vorgehensweise kann die Sentinel-Installation die FHS-konformen Standardinstallationspfade verwenden. Außerdem ermöglicht sie die Überprüfung der RPM-Softwarepaketerstellung und auch die Anwendung von Patches und die Neukonfiguration bei laufendem Betrieb, um die Ausfallzeit zu minimieren.
Diese Lösung führt Sie durch ein Beispiel einer Installation in einem Cluster, der den freigegebenen iSCSI-Speicher verwendet und die Anwendungsbinärdateien/-konfiguration auf jedem Clusterknoten sucht.
Eine entscheidende Komponente in jeder hochverfügbaren Umgebung ist eine zuverlässige, konsistente Methode zur Überwachung der Ressourcen, die hochverfügbar sein sollten, und der Ressourcen, von denen diese abhängen. Die SLE HAE verwendet zur Durchführung dieser Überwachung eine Komponente namens Resource Agent. Deren Aufgabe besteht darin, den Status der einzelnen Ressourcen anzugeben und diese Ressource (auf Anfrage) zu starten oder zu stoppen.
Resource Agent muss einen zuverlässigen Status für die überwachten Ressourcen angeben, um unnötige Ausfallzeiten zu verhindern. Ein falscher Positiv-Status (wenn eine Ressource als fehlerhaft gilt, doch den Fehler selbst wieder beheben könnte) kann zur Dienstmigration (und damit verbundenen Ausfallzeit) führen, obwohl dies überhaupt nicht notwendig wäre. Ein falscher Negativ-Status (wenn der Resource Agent meldet, dass eine Ressource funktioniert, obwohl sie dies nicht ordnungsgemäß tut) kann die ordnungsgemäße Verwendung des Diensts verhindern. Andererseits kann die externe Überwachung eines Diensts recht schwierig sein. Ein Webdienst-Port zum Beispiel könnte zwar auf ein einfaches Ping reagieren, liefert jedoch keine korrekten Daten, wenn eine echte Anfrage ausgestellt wird. In vielen Fällen muss in den Dienst die Funktion zur Selbstdiagnose integriert sein, um eine wirklich präzise Messung durchführen zu können.
Diese Lösung bietet die Basisversion des OCF Resource Agent für Sentinel, der das System auf größere Fehler in der Hardware, im Betriebssystem oder im Sentinel-System überwachen kann. Zu diesem Zeitpunkt basieren die Fähigkeiten zur externen Überwachung von Sentinel auf IP-Port-Tests und es besteht durchaus die Gefahr für die Ablesung eines falschen Positiv- und falschen Negativ-Status. Wir planen, sowohl Sentinel als auch den Resource Agent langfristig zu verbessern, um die Genauigkeit dieser Komponente zu erhöhen.
In einem HA-Cluster werden kritische Dienste ständig überwacht und automatisch in anderen Knoten neu gestartet, falls sie fehlerhaft sind. Diese Automatisierung kann jedoch Probleme mit sich bringen, wenn im primären Knoten Kommunikationsprobleme auftreten. Obwohl der in diesem Knoten ausgeführte Dienst anscheinend ausgefallen ist, wird er in Wahrheit weiter ausgeführt und schreibt weiterhin Daten in den freigegebenen Speicher. In diesem Fall kann der Start einer Reihe von Diensten auf einem Sicherungsknoten leicht zu Datenbeschädigung führen.
Cluster verwenden eine Vielzahl an Methoden (wie zum Beispiel Split Brain Detection (SBD) und Shoot The Other Node In The Head (STONITH)), um dies zu verhindern. Diese werden kollektiv als Fencing bezeichnet. Primäres Ziel ist es, die Beschädigung der Daten im freigegebenen Speicher zu verhindern.