High Availability

Hardwareredundanz

Die minimale Base Rack-Konfiguration enthält redundante Netzwerk-, Speicher- und Serverkomponenten, um sicherzustellen, dass der Ausfall eines einzelnen Elements die allgemeine Systemverfügbarkeit nicht beeinträchtigt.

Die Datenkonnektivität im gesamten System basiert auf redundanten Paaren von Leaf- und Wirbelsäulenschaltern. Die Linkaggregation wird auf allen Schnittstellen konfiguriert: Switch-Ports, Host-NICs und Uplinks. Die Leaf Switches verbinden die Rackkomponenten über Verkabelung mit redundanten Netzwerkschnittstellen in jeder Komponente. Jeder Blattschalter hat auch eine Verbindung zu jedem der Wirbelsäulenschalter, die ebenfalls miteinander verbunden sind. Die Wirbelsäulen-Switches bilden das Rückgrat des Netzwerks und ermöglichen Datenverkehr außerhalb des Racks. Ihre Uplinks zum Data Center-Netzwerk bestehen aus zwei Kabelpaaren, die mit zwei redundanten ToR-(Top-of-Rack-)Switches verbunden sind.

Das Managementcluster, in dem die Controllersoftware und Services auf Systemebene ausgeführt werden, besteht aus drei vollständig aktiven Managementknoten. Eingehende Anforderungen durchlaufen die virtuelle IP des Managementknotenclusters und werden von einem Load Balancer auf die drei Knoten verteilt. Wenn einer der Knoten nicht mehr reagiert und aus dem Cluster Zäune erstellt, sendet der Load Balancer weiterhin Traffic an die beiden verbleibenden Knoten, bis der fehlerhafte Knoten wieder fehlerfrei ist und wieder dem Cluster beitritt.

Der Speicher für das System und die Cloud-Ressourcen in der Umgebung wird von der internen ZFS Storage Appliance bereitgestellt. Die beiden Controller bilden ein aktiv-aktives Cluster, das gleichzeitig hohe Verfügbarkeit und hervorragenden Durchsatz bietet. Die ZFS-Pools basieren auf Festplatten in einer gespiegelten Konfiguration, um einen optimalen Datenschutz zu gewährleisten.

Systemverfügbarkeit

Die Software- und Serviceschicht wird auf dem Verwaltungscluster mit drei Knoten bereitgestellt und nutzt die High Availability, die dem Clusterdesign innewohnt. Die Kubernetes-Containerorchestrierungsumgebung verwendet auch Clustering sowohl für ihre eigenen Controllerknoten als auch für die darin gehosteten Servicepods. Viele Replikate der Microservices werden zu einem bestimmten Zeitpunkt ausgeführt. Knoten und Pods werden über die Managementknoten verteilt. Kubernetes stellt sicher, dass fehlerhafte Pods durch neue Instanzen ersetzt werden, damit alle Services in einem aktiven/aktiven Setup ausgeführt werden.

Alle Services und Komponenten speichern Daten in einer gemeinsamen, zentralen MySQL-Datenbank. In der MySQL-Clusterdatenbank sind Instanzen auf den drei Managementknoten bereitgestellt. Verfügbarkeit, Load Balancing, Datensynchronisierung und Clustering werden alle von internen Komponenten des MySQL-Clusters gesteuert.

Ein wesentlicher Teil des Infrastrukturnetzwerks auf Systemebene ist softwaredefiniert. Die Konfiguration virtueller Switches, Router und Gateways wird nicht von den Switches gespeichert und verwaltet, sondern über mehrere Komponenten der Netzwerkarchitektur verteilt. Der Netzwerkcontroller wird als hochverfügbarer Containerdienst bereitgestellt.

Das Upgrade-Framework nutzt die Hardwareredundanz und die geclusterten Designs, um rollierende Upgrades für alle Komponenten bereitzustellen. Beim Upgrade einer Komponenteninstanz stellen die verbleibenden Instanzen sicher, dass keine Ausfallzeit auftritt. Das Upgrade ist abgeschlossen, wenn alle Komponenteninstanzen upgegradet und in den normalen Betrieb zurückversetzt wurden.

Compute-Instanzverfügbarkeit

Bei einer Compute-Instanz bezieht sich High Availability auf das automatisierte Recovery einer Instanz, falls die zugrunde liegende Infrastruktur ausfällt. Der Status der Compute Nodes, Hypervisoren und Compute-Instanzen wird kontinuierlich überwacht. Jeder Compute Node wird mit einem Intervall von 5 Minuten abgefragt. Wenn Compute-Instanzen ausfallen, versucht das System standardmäßig, sie automatisch wiederherzustellen.

Standardmäßig versucht das System, Instanzen in der ausgewählten Faultdomain neu zu starten. Instanzen in anderen Faultdomains werden jedoch neu gestartet, wenn in der ausgewählten Faultdomain nicht genügend Ressourcen verfügbar sind. Die ausgewählte Faultdomain ist die Faultdomain, die in der Instanzkonfiguration angegeben ist.

Wenn ein Compute Node aufgrund eines ungeplanten Neustarts ausfällt und der Compute Node erfolgreich in den normalen Betrieb zurückkehrt, werden Instanzen neu gestartet. Beim nächsten Polling-Intervall wird der Startbefehl standardmäßig erneut abgesetzt, wenn Instanzen gefunden werden, die ausgeführt werden sollen, sich jedoch in einem anderen Status befinden. Wenn Instanzen gestoppt wurden und sich in diesem Status befinden, versucht der Hypervisor, sie bis zu 5 Mal neu zu starten. Instanzen, die nicht ausgeführt wurden, bevor der Compute Node nicht mehr verfügbar war, bleiben heruntergefahren, wenn der Compute Node hochgefahren ist und erneut ausgeführt wird.

Ein Compute Node gilt als nicht erfolgreich, wenn er vom Datennetzwerk getrennt wurde oder sich etwa 5 Minuten lang in einem ausgeschalteten Status befand. Dieser 5-minütige Timeout entspricht zwei nicht erfolgreichen Polling-Versuchen und ist der Schwellenwert, um den Compute Node in den Status FAIL und seinen Agent in den Status EVACUATING zu versetzen. Diese Bedingung ist erforderlich, bevor die Neustartmigration gestartet werden kann.

Bei der Neustartmigration werden alle Compute-Instanzen vom fehlerhaften Compute Node gestoppt und auf einem anderen Compute Node neu gestartet. Nach Abschluss der Migration gibt der Agent des fehlerhaften Compute Nodes an, dass Instanzen evakuiert wurden. Wenn der Compute Node schließlich erfolgreich neu gestartet wird, muss er einen Bereinigungsprozess durchlaufen, der alle veralteten Instanzkonfigurationen und zugehörigen virtuellen Datenträger entfernt. Nach der Bereinigung kann der Compute Node Compute-Instanzen erneut hosten.

Während der gesamten Neustartmigration bleiben die Instanzen im Konfigurationsstatus "Verschieben". Nach Abschluss der Migration wird der Status der Instanzkonfiguration in "Wird ausgeführt" geändert. Instanzen, die vor dem Fehler gestoppt wurden, werden nicht migriert, weil sie keinem Compute Node zugeordnet sind.

Kontinuität des Services

Compute Cloud@Customer bietet mehrere Features, die High Availability weiter verbessern. Die Gesundheitsüberwachung auf allen Ebenen des Systems ist ein Schlüsselfaktor. Diagnose- und Leistungsdaten werden aus allen Komponenten gesammelt, dann zentral gespeichert und verarbeitet und Oracle-Mitarbeitern zur Verfügung gestellt.

Um Datenverluste zu mindern und die Wiederherstellung der System- und Servicekonfiguration im Fehlerfall zu unterstützen, werden regelmäßig konsistente und vollständige Backups erstellt.

Optional können Workloads, die auf Compute Cloud@Customer bereitgestellt werden, durch die Implementierung von Disaster Recovery vor Ausfallzeiten und Datenverlust geschützt werden. Um dies zu erreichen, müssen zwei Compute Cloud@Customer-Infrastrukturen an verschiedenen Standorten eingerichtet und so konfiguriert werden, dass sie sich gegenseitig replizieren. Ressourcen, die der Disaster Recovery-Kontrolle unterliegen, werden in den ZFS Storage Appliances in jedem System separat gespeichert und zwischen den beiden Systemen repliziert. Wenn ein Vorfall an einem Standort auftritt, wird die Umgebung auf dem Replikatsystem mit minimaler Ausfallzeit aufgerufen. Wir empfehlen, dass Disaster Recovery für alle kritischen Produktionssysteme implementiert wird.