High Availabilty (Hochverfügbarkeit)

In den meisten Fällen ist ein Hardware-Fehler für den Ausfall eines Internetsicherheitssystems verantwortlich. Die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten uneingeschränkten Betrieb zu gewährleisten, wird auch Failover bzw. Hochverfügbarkeit genannt (HA, High-Availability). Sophos UTM bietet Hochverfügbarkeit, indem es ermöglicht, ein redundantes Hot-Standby-System zu konfigurieren, das im Falle eines technischen Versagens des Primärsystems dessen Aufgaben übernimmt (aktiv-passiv). Alternativ dazu können Sie Sophos UTM als Cluster konfigurieren, der speziellen Datenverkehr auf mehrere Maschinen verteilt (aktiv-aktiv), wie man es von konventionellen Lösungen zur Lastverteilung kennt. Das führt zu optimaler Ressourcenauslastung und verringert Rechenzeit.

Hinweis – Wenn Ihre Sophos UTM auf Amazon Web Services (AWS) läuft, finden Sie weitere Informationen unter Management > HA/Autoscaling.

Die Konzepte Hochverfügbarkeit und Cluster ähneln sich hinsichtlich ihrer Implementierung in Sophos UTM sehr. So kann z. B. ein hochverfügbares System als ein Zwei-Knoten-Cluster angesehen werden, was die Mindestanforderung an ein redundantes System darstellt.

Jeder Knoten innerhalb eines Clusters kann eine der folgenden Rollen annehmen:

  • Master: Das Primärsystem in einem Hot-Standby-/Cluster-Aufbau. Innerhalb eines Clusters sorgt der Master für die Synchronisierung und Verteilung der Daten.
  • Slave: Das Sekundärsystem in einem Hot-Standby-/Cluster-Aufbau, das den Betrieb sicherstellt, falls das Primärsystem ausfällt.
  • Worker: Ein einfacher Cluster-Knoten, der nur für die Datenverarbeitung zuständig ist.

Alle Knoten überwachen sich gegenseitig mit Hilfe eines sogenannten Heartbeat-Signals, ein in periodischen Abständen verschicktes Multicast-UDP-Datenpaket, um festzustellen, ob die anderen Knoten noch „am Leben“ sind (daher der Begriff Heartbeat, dt. Herzschlag). Falls aufgrund eines technischen Fehlers einer der Knoten kein Heartbeat-Signal mehr aussenden kann, wird er als tot betrachtet. Je nach der Rolle, die der ausgefallene Knoten innehatte, ändert sich die Konfiguration des Aufbaus wie folgt:

  • Falls der Master-Knoten ausfällt, übernimmt der Slave-Knoten seinen Platz und der Worker-Knoten mit der höchsten ID wird Slave.
  • Falls der Slave-Knoten ausfällt, wird der Worker-Knoten mit der höchsten ID zum Slave.
  • Falls ein Worker-Knoten ausfällt, bemerken Sie im Höchstfall Leistungseinbußen aufgrund der verringerten Rechenleistung. Die Ausfallsicherheit ist dadurch nicht beeinträchtigt.

Hinweis – Die HA-Einstellungen sind Teil der Hardware-Konfiguration und können nicht in einem Backup gespeichert werden. Das bedeutet, dass die HA-Einstellungen im Zuge einer Backup-Wiederherstellung nicht überschrieben werden.

Berichte

Alle Berichtsdaten werden auf dem Master-Knoten konsolidiert und in Abständen von fünf Minuten auf die anderen Knoten übertragen. Im Fall einer Übernahme durch das Sekundärsystem verlieren Sie daher höchstens fünf Minuten an Daten. Es gibt allerdings einen Unterschied hinsichtlich der Zusammenfassung der Daten. Die Diagramme auf den Registerkarten Protokolle & Berichte > Hardware repräsentieren lediglich die Daten des Knotens, der gerade Master ist. Netzwerkverkehrsdaten wiederum, wie sie beispielsweise auf der Seite Protokolle & Berichte > Netzwerknutzung angezeigt werden, repräsentieren Daten von allen beteiligten Knoten. So zeigt z. B. das Histogramm der heutigen CPU-Auslastung die aktuelle Prozessorauslastung des Master-Knotens. Im Fall einer Übernahme durch den Slave wären dies dann die Daten des Slave. Im Gegensatz dazu enthalten z. B. die Informationen über die häufigsten Netzwerkdienste die Daten aller Knoten, die bei der verteilten Verarbeitung des Datenverkehrs involviert waren.

Hinweise

  • Das Address Resolution Protocol (ARP) wird nur vom tatsächlichen Master benutzt, d. h. Slave- und Worker-Knoten senden und beantworten keine ARP-Anfragen.
  • Im Fall einer Übernahme führt die Einheit, die die Aufgaben übernimmt, eine ARP-Bekanntgabe (auch bekannt als gratuitous ARP) durch. Gewöhnlich dient diese ARP-Anfrage dazu, den ARP-Cache der Hosts, die diese Anfrage erhalten, zu aktualisieren. Die ARP-Bekanntgabe wird dazu benutzt, bekannt zu geben, dass die IP-Adresse des Masters auf den Slave übertragen wurde.
  • Alle Schnittstellen, die auf dem Master konfiguriert sind, müssen eine physikalische Verbindung haben, das heißt, der Port muss korrekt mit einem Netzwerkgerät verbunden sein.
In den meisten Fällen ist ein Hardware-Fehler für den Ausfall eines Internetsicherheitssystems verantwortlich. Die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten uneingeschränkten... mehr erfahren »
Fenster schließen
High Availabilty (Hochverfügbarkeit)

In den meisten Fällen ist ein Hardware-Fehler für den Ausfall eines Internetsicherheitssystems verantwortlich. Die Fähigkeit eines Systems, bei Ausfall einer seiner Komponenten uneingeschränkten Betrieb zu gewährleisten, wird auch Failover bzw. Hochverfügbarkeit genannt (HA, High-Availability). Sophos UTM bietet Hochverfügbarkeit, indem es ermöglicht, ein redundantes Hot-Standby-System zu konfigurieren, das im Falle eines technischen Versagens des Primärsystems dessen Aufgaben übernimmt (aktiv-passiv). Alternativ dazu können Sie Sophos UTM als Cluster konfigurieren, der speziellen Datenverkehr auf mehrere Maschinen verteilt (aktiv-aktiv), wie man es von konventionellen Lösungen zur Lastverteilung kennt. Das führt zu optimaler Ressourcenauslastung und verringert Rechenzeit.

Hinweis – Wenn Ihre Sophos UTM auf Amazon Web Services (AWS) läuft, finden Sie weitere Informationen unter Management > HA/Autoscaling.

Die Konzepte Hochverfügbarkeit und Cluster ähneln sich hinsichtlich ihrer Implementierung in Sophos UTM sehr. So kann z. B. ein hochverfügbares System als ein Zwei-Knoten-Cluster angesehen werden, was die Mindestanforderung an ein redundantes System darstellt.

Jeder Knoten innerhalb eines Clusters kann eine der folgenden Rollen annehmen:

  • Master: Das Primärsystem in einem Hot-Standby-/Cluster-Aufbau. Innerhalb eines Clusters sorgt der Master für die Synchronisierung und Verteilung der Daten.
  • Slave: Das Sekundärsystem in einem Hot-Standby-/Cluster-Aufbau, das den Betrieb sicherstellt, falls das Primärsystem ausfällt.
  • Worker: Ein einfacher Cluster-Knoten, der nur für die Datenverarbeitung zuständig ist.

Alle Knoten überwachen sich gegenseitig mit Hilfe eines sogenannten Heartbeat-Signals, ein in periodischen Abständen verschicktes Multicast-UDP-Datenpaket, um festzustellen, ob die anderen Knoten noch „am Leben“ sind (daher der Begriff Heartbeat, dt. Herzschlag). Falls aufgrund eines technischen Fehlers einer der Knoten kein Heartbeat-Signal mehr aussenden kann, wird er als tot betrachtet. Je nach der Rolle, die der ausgefallene Knoten innehatte, ändert sich die Konfiguration des Aufbaus wie folgt:

  • Falls der Master-Knoten ausfällt, übernimmt der Slave-Knoten seinen Platz und der Worker-Knoten mit der höchsten ID wird Slave.
  • Falls der Slave-Knoten ausfällt, wird der Worker-Knoten mit der höchsten ID zum Slave.
  • Falls ein Worker-Knoten ausfällt, bemerken Sie im Höchstfall Leistungseinbußen aufgrund der verringerten Rechenleistung. Die Ausfallsicherheit ist dadurch nicht beeinträchtigt.

Hinweis – Die HA-Einstellungen sind Teil der Hardware-Konfiguration und können nicht in einem Backup gespeichert werden. Das bedeutet, dass die HA-Einstellungen im Zuge einer Backup-Wiederherstellung nicht überschrieben werden.

Berichte

Alle Berichtsdaten werden auf dem Master-Knoten konsolidiert und in Abständen von fünf Minuten auf die anderen Knoten übertragen. Im Fall einer Übernahme durch das Sekundärsystem verlieren Sie daher höchstens fünf Minuten an Daten. Es gibt allerdings einen Unterschied hinsichtlich der Zusammenfassung der Daten. Die Diagramme auf den Registerkarten Protokolle & Berichte > Hardware repräsentieren lediglich die Daten des Knotens, der gerade Master ist. Netzwerkverkehrsdaten wiederum, wie sie beispielsweise auf der Seite Protokolle & Berichte > Netzwerknutzung angezeigt werden, repräsentieren Daten von allen beteiligten Knoten. So zeigt z. B. das Histogramm der heutigen CPU-Auslastung die aktuelle Prozessorauslastung des Master-Knotens. Im Fall einer Übernahme durch den Slave wären dies dann die Daten des Slave. Im Gegensatz dazu enthalten z. B. die Informationen über die häufigsten Netzwerkdienste die Daten aller Knoten, die bei der verteilten Verarbeitung des Datenverkehrs involviert waren.

Hinweise

  • Das Address Resolution Protocol (ARP) wird nur vom tatsächlichen Master benutzt, d. h. Slave- und Worker-Knoten senden und beantworten keine ARP-Anfragen.
  • Im Fall einer Übernahme führt die Einheit, die die Aufgaben übernimmt, eine ARP-Bekanntgabe (auch bekannt als gratuitous ARP) durch. Gewöhnlich dient diese ARP-Anfrage dazu, den ARP-Cache der Hosts, die diese Anfrage erhalten, zu aktualisieren. Die ARP-Bekanntgabe wird dazu benutzt, bekannt zu geben, dass die IP-Adresse des Masters auf den Slave übertragen wurde.
  • Alle Schnittstellen, die auf dem Master konfiguriert sind, müssen eine physikalische Verbindung haben, das heißt, der Port muss korrekt mit einem Netzwerkgerät verbunden sein.