Hohe Verfügbarkeit

Jedes IT-System dient einem Zweck. Um diesen Zweck zu erfüllen, muss es für seine Verwendung verfügbar sein. Einige IT-Systeme sind für ein Unternehmen von entscheidender Bedeutung und müssen daher hoch verfügbar sein. Das heißt, es darf keine oder nur minimale Zeiträume geben, in denen sie teilweise oder vollständig nicht verfügbar sind. Andere Systeme sind weniger wichtig. Bei ihnen ist eine gewisse Anzahl geplanter oder ungeplanter Ausfallzeiten akzeptabel, wenn beispielsweise auf alternative Workflows zurückgegriffen oder einfach gewartet werden kann, bis das System wieder verfügbar ist. Viele Systeme liegen irgendwo in der Mitte zwischen diesen beiden Extremen.

Definieren und Verstehen der Verfügbarkeit

Hohe Verfügbarkeit (High Availability, HA) ist ein Entwurfsansatz, der es einem System ermöglicht, über einen bestimmten Zeitraum ein vorher festgelegtes Niveau der Betriebsleistung zu erreichen. Hochverfügbare Systeme bieten Kunden ein System und eine Umgebung mit der erforderlichen Zuverlässigkeit, um ihre Geschäftsanforderungen an die Servicebereitstellung zu erfüllen oder zu übertreffen und auf einem erwarteten Qualitätsniveau zu arbeiten.

Ein weiterer häufig verwendeter Begriff in diesem Bereich ist geographische Redundanz. Dieser Begriff bezieht sich im Allgemeinen auf das Entwurfsziel einer Anwendung bzw. eines Systems, das einen vollständigen Ausfall des Rechenzentrums überstehen kann, indem zusätzliche Systeme oder ein Ausweich- oder Sicherungssystem an einem anderen geographischen Standort verfügbar sind. Dieser Ansatz kann zum Schutz vor Naturkatastrophen, Stromausfällen oder anderen Unterbrechungen der Verfügbarkeit von Rechenzentren beitragen.

Viele Architekten verwenden einen Satz allgemeiner Begriffe, um auf einen Ansatz auf System- oder Komponentenebene für Hochverfügbarkeit zu verweisen und ihn detailliert zu beschreiben. Zu den gebräuchlichsten Begriffen, die in diesem Bereich verwendet werden, gehören:

• Aktiv/Aktiv: Dies ist ein Fehlertoleranzmuster, das darauf beruht, dass zwei oder mehr Systeme aktiv Anforderungen empfangen und verarbeiten. In einem Aktiv/Aktiv-System ist jeder Knoten, der eine Anforderung empfängt, den anderen gleich, und Anforderungen werden in der Regel so verteilt, dass sie in etwa zu gleichem Anteil an jeden Backend-Knoten gesendet werden.
• Aktiv/Passiv: Bei diesem auch als Primär-/Standby bezeichneten Fehlertoleranzmuster fließen die Benutzeranforderungen vollständig an ein System, während ein zweites System auf ein Szenario wartet, in dem es benötigt wird. Ein solches Szenario wäre entweder ein Ausfall des primären Systems (bei dem das aktive System die Verarbeitung von Anforderungen einstellt) oder ein geplanter Wechsel, was in beiden Fällen dazu führt, dass der Benutzerdatenverkehr an das passive System, das nun als aktives System gilt, gesendet wird.
• Failover-Systeme sind so konzipiert, dass sie vollständig mit einem aktiven System synchronisiert werden, aber bereit sind, Datenverkehr zu empfangen, diesen Datenverkehr aber nur dann empfangen, wenn das primäre System aus irgendeinem Grund ausgefallen ist. Ein Failover-System ähnelt einer Aktiv/Passiv-Konfiguration, kann jedoch unterschiedliche Workflows besitzen, die mit dem “Failover” (also der Funktionsübertragung nach einem Ausfall) an dieses System verbunden sind.

Verfügbarkeitsziele

Ein Kennwert, mit dem die Verfügbarkeit gemessen werden kann, ist die Betriebszeit, die im Allgemeinen als Prozentsatz der Zeit, in der ein System in einem bestimmten Zeitraum “verfügbar” war, gemessen wird. Die Definition des Begriffs verfügbar ist subjektiv und sollte früh im Systementwurfsprozess festgelegt werden, damit eine gemeinsame Einigung über dieses Ziel erzielt werden kann. Eine gewünschte Verfügbarkeitsebene wird häufig als angestrebte Betriebszeit definiert, die oft in Neunen ihren Ausdruck findet. Beispiel:

• 99 % (zwei Neunen) - entspricht 3,65 Tagen zulässiger Ausfallzeit pro Jahr
• 99,9 % (drei Neunen) - entspricht 8,77 Stunden zulässiger Ausfallzeit pro Jahr

Verfügbarkeitsziele können in Form eines Service-Level-Agreements (SLA) zwischen den Benutzern eines Systems und der Organisation, die dieses System betreibt, formalisiert werden. Häufig enthalten SLAs andere leistungsbezogene Kennwerte, die über die reinen Verfügbarkeitsziele hinausgehen, wie z. B. erwartete Reaktionszeiten, und Definitionen der Strafen für das Erreichen dieser Ziele, wenn eine Lieferanten- und Kundenbeziehung besteht. Interne SLAs sind ebenso wichtig, obwohl sie in der Regel nicht die Anforderungen eines kundenorientierten SLA in Bezug auf Strafen und Berichterstattung enthalten.

Kritikalitätsebenen

Ein weiterer Ansatz, den Unternehmen in Bezug auf die Verfügbarkeit verfolgen, besteht darin, Kritikalitätsebenen für die von ihnen verwendeten Systeme festzulegen, die je nach den Auswirkungen, die ein Ausfall auf eine Organisation haben kann, von nicht unbedingt erforderlich bis grundlegend reichen. Zu den Überlegungen können Benutzererfahrung, Finanzen, Reputation und regulatorische Auswirkungen gehören, und jede Kritikalitätsebene kann eine andere SLA-Zieldefinition haben. Einige Organisationen bezeichnen ein bestimmtes System als “Ebene 1” oder “Geschäftskritisch”, andere Systeme dagegen als “Ebene 2” oder weniger geschäftskritisch mit deshalb weniger Einschränkungen oder anderen Konfigurationen.

Das Entwerfen und Erstellen eines Systems, das eine vordefinierte Verfügbarkeit erfüllt, erfordert einen ganzheitlichen Ansatz, der viele verschiedene Aspekte oder Themenbereiche berücksichtigt, wie zum Beispiel:

• Sorgfältige Auswahl hochwertigerer Software- und Hardwarekomponenten, die im Gegensatz zu Standardkomponenten speziell dafür entwickelt wurden, die mittlere Zeit zwischen Ausfällen (Mean Time between Failures, MTBF) zu reduzieren.
• Beseitigung aller Single Points of Failure (SPOF) im System durch Herstellung von Redundanz aller Komponenten. Ein Single Point of Failure ist ein Teil einer Software oder Hardware, das bei einem Ausfall dazu führt, dass das gesamte System nicht mehr verfügbar ist. Mit einem Single Point of Failure kann ein System den Ausfall einer Komponente tolerieren, ohne die Verfügbarkeit merklich zu beeinträchtigen.
• Erstellung von Plänen für die Wiederherstellung der Verfügbarkeit eines Systems, falls es tatsächlich nicht mehr verfügbar sein sollte, und Testung dieser Pläne. Dazu kann die Definition von Zielen für die akzeptable Zeit, die benötigt wird, um das System wieder verfügbar zu machen, und für den maximal zulässigen Datenverlust, gehören.
• Durchsetzung von Richtlinien und Verfahren mit Schwerpunkt auf dem Änderungsmanagement, um die Wahrscheinlichkeit versehentlicher oder unbeabsichtigter Unterbrechungen, z. B. aufgrund menschlicher Fehler, zu minimieren.

Der Aufbau eines Systems, das höhere Anforderungen an die Betriebszeit erfüllt, erfordert in der Regel eine erhebliche Vorabinvestition und die kontinuierliche Investition von Zeit und Ressourcen im Vergleich zu einem Referenzsystem, das nur eine Standardverfügbarkeitsebene erfüllt.Bei hoher Verfügbarkeit geht es jedoch nicht um alles oder nichts. Oft ist es sinnvoll zu überlegen, ob es Subsysteme gibt, für die Verfügbarkeitsziele gelockert werden können, ohne den Geschäftswert eines IT-Systems wesentlich zu beeinträchtigen.

Überlegungen zum Entwurf

Der Prozess des Entwerfens eines hoch verfügbaren Systems beginnt nicht mit einer leeren Leinwand. In den meisten Fällen bestimmen die vorhandene IT-Infrastruktur, die Richtlinien, das Fachwissen und die Präferenzen einer Organisation den Gesamtrahmen, den ein Enterprise-GIS-System berücksichtigen muss. Dazu gehören die auf Betriebszeit oder Verfügbarkeit gerichteten Erwartungen der unterstützenden Systeme und die IT-Komponenten, die zur Verfügung stehen, um eine hohe Verfügbarkeit zu erreichen. Berücksichtigen Sie die gegenseitigen Abhängigkeiten zwischen Entscheidungen, bei denen eine Entwurfsentscheidung oft eine andere hervorbringt. Viele dieser Details können als Entwurfseinschränkungen betrachtet werden, die dazu beitragen, einen Entwurfsprozess in Richtung eines für beide Seiten akzeptablen Ziels zu lenken, bei dem das System die Gesamtanforderungen erfüllt und sich gleichzeitig an den bereits von der Organisation festgelegten Standards orientiert und Kosten, Verwaltbarkeit und andere Faktoren in Einklang bringt.

Häufig gehören Entwurfseinschränkungen zu den folgenden Kategorien:

• Geschäftsanforderungen: Die Geschäftsanforderungen einer Organisation bestimmen, welche Ausfallzeit akzeptabel ist. Die akzeptablen Ausfallzeiten reichen von null bis hin zu Stunden oder Tagen, bevor das System wiederhergestellt wird. Dies wird als Recovery Time Objective (RTO, Zielsetzung für Wiederherstellungszeit) bezeichnet. Die Geschäftsanforderungen sind auch ein Hinweis darauf, wie viel Datenverlust, ausgedrückt als Zeitangabe, im Falle eines Ausfalls toleriert werden kann. Dies wird als Recover Point Objective (RPO, Zielsetzung für Wiederherstellungspunkt) bezeichnet und liegt als Wert des Datenverlusts in der Regel zwischen null Sekunden und einer Woche.
• Bereitstellungsmuster: Die Auswahl eines bestimmten Bereitstellungsmusters bestimmt häufig im Voraus, inwieweit Verfügbarkeitsüberlegungen in detaillierte Entwurfsentscheidungen einbezogen werden müssen. Mit anderen Worten: Beim Aufbau eines Systems rund um SaaS- oder PaaS-Angebote wurden viele dieser Entscheidungen bereits von der Organisation getroffen, die das Angebot hostet. Auf der anderen Seite bietet die Bereitstellung von GIS-Serversoftware in einem Rechenzentrum, das Ihre Organisation besitzt und verwaltet, ein Höchstmaß an Flexibilität in Bezug auf die Erfüllung Ihrer genauen Verfügbarkeitsanforderungen, ist aber auch mit den meisten Verantwortlichkeiten verbunden.
• Infrastruktur: In den meisten Fällen müssen sich IT-Experten, die GIS-Systeme für die Bereitstellung in Rechenzentren entwerfen, die in Ihrer Organisation betrieben werden, nicht um grundlegende physische Infrastrukturen wie Hosting-Einrichtungen, Stromversorgung, Kühlung und Netzwerk kümmern, da diese bereits eingerichtet sind und in der Regel ein hohes Maß an Verfügbarkeit dieser grundlegenden Ressourcen bieten.
• Wartung: Bei einigen Systemen ist die Möglichkeit, Systeme ohne Ausfallzeiten zu patchen oder zu aktualisieren, von entscheidender Bedeutung, um sicherzustellen, dass die Benutzer nicht beeinträchtigt werden oder andere Systeme kontinuierlich funktionieren können. In diesen Fällen kann das Patchen auf fortlaufender Basis oder die Verwendung einer Blau/Grün- oder Primär-/Standby-Umgebung mit diesen Zielen vereinbar sein, aber die potenziellen Auswirkungen der gewünschten Wartungsmaßnahmen und der Wartungsrhythmus sind wichtige Faktoren, die bei jedem Systementwurf berücksichtigt werden müssen.

In ähnlicher Weise können IT-Organisationen die Auswahl an Infrastrukturen weiter einschränken, z. B. auf bestimmte Marken und Modelle für physische Hardware, Virtualisierungsschichten, Speichersysteme, Load Balancer, Reverseproxys usw.

Die Nutzung kommerzieller Cloud-basierter Infrastructure-as-a-Service (IaaS), seien es virtuelle Maschinen oder Kubernetes-Cluster, schränkt Ihre Optionen ebenfalls ein.

• Software: Die Ebenen, bis zu denen Softwarekomponenten, aus denen sich ein System zusammensetzt, höhere Verfügbarkeitsgrade unterstützen, variieren und reichen von keiner ausgewiesenen Unterstützung bis hin zu vollständig unterstützten und dokumentierten Konfigurationen mit hoher Verfügbarkeit. Sie unterscheiden sich auch im Grad: Nicht alle Verfügbarkeitsebenen können mit einer bestimmten Software erreicht werden, was dann das erreichbare SLA, RPO oder RTO einschränkt.
• Menschen und Prozesse: Es ist oft vorzuziehen, etablierte Prozesse und Verfahren für den Aufbau und die Verwaltung hoch verfügbarer Systeme, die Ihre Organisation bereits eingerichtet hat, zu nutzen, um von vorhandenem Fachwissen zu profitieren.

Muster für hohe Verfügbarkeit

In Bezug auf ArcGIS Enterprise bezieht sich hohe Verfügbarkeit auf Maßnahmen, die die Verfügbarkeit einer einzelnen Bereitstellung von ArcGIS Enterprise erhöhen. Replizierte Bereitstellungen, die normalerweise geographisch in einem anderen Rechenzentrum oder in einer anderen Cloud-Region verteilt sind, bieten eine Möglichkeit der Notfallwiederherstellung. Weitere Informationen über Hohe Verfügbarkeit in ArcGIS Enterprise.

ArcGIS Enterprise bietet durch die Kombination mehrerer Computer in unterschiedlichen Konfigurationen ein höheres Maß an Verfügbarkeit. Die Komponenten von ArcGIS Enterprise verwenden unterschiedliche Ansätze, um hohe Verfügbarkeit zu erreichen:

Portal for ArcGIS

Eine Portal-Site mit hoher Verfügbarkeit besteht aus zwei Servern, die miteinander verbunden sind, um die HA-Site zu erstellen. Sie sind jeweils vollständig redundant. Das System verwaltet aber einen Computer als primären Knoten, während der andere Computer der Standby-Knoten ist. Wenn der primäre Computer ausfällt, erkennt der Standby-Computer den Fehler und wird selbst zum primären Computer.

Auf Webserver-Ebene ist das System Aktiv/Aktiv, da jeder Portal-Knoten in der Lage ist, eingehende Anforderungen zu verarbeiten, und die Suchindizes über beide Systeme hinweg synchron gehalten werden. Zustandsänderungen, bei denen Bearbeitungen, Einladungen von Mitgliedern und Konfigurationen in der Portal-Datenbank gespeichert werden, werden jedoch nur von einem Knoten verarbeitet. Deshalb wird das Gesamtsystem als Aktiv/Passiv betrachtet.

Ein hoch verfügbares Portal erfordert auch einen Load Balancer, um Anforderungen zwischen den beiden Knoten zu verteilen, in der Regel mit einer Round-Robin-Methode. Der primäre und der Standby-Knoten informieren sich durch die Kommunikation zwischen den Computern über Ports und Datenbanksynchronisierung gegenseitig über den Zustand, verlassen sich aber auch auf den gemeinsamen Dateispeicher für das Inhaltsverzeichnis des Portals, bei dem es sich um eine NFS-Dateifreigabe, eine UNC-Dateifreigabe oder einen Cloud-nativen Objektspeicher handeln kann.

Weitere Informationen zum Konfigurieren einer Portal for ArcGIS-Bereitstellung mit hoher Verfügbarkeit.

GIS-Server

Eine hoch verfügbare GIS-Server-Site besteht aus zwei oder mehr vollständig redundanten Computern, die zu einer ArcGIS Server-“Site” in Form einer Aktiv/Aktiv-Konfiguration verbunden sind, in der die Workloads auf alle Knoten verteilt werden. Ein hoch verfügbarer GIS-Server erfordert auch einen Load Balancer, um Anforderungen, in der Regel mit einem Round-Robin-Ansatz, an die Mitgliedscomputer weiterzuleiten, obwohl der Webdatenverkehr auch im primären Standby-Modus weitergeleitet werden kann.

Über den Zustand informieren sich die Computer in einer Site gegenseitig in erster Linie über einen gemeinsamen Speicherort für die Serververzeichnisse und den Konfigurationsspeicher, in der Regel eine NFS- oder UNC-Dateifreigabe. Für Cloud-Systeme sind auch Cloud-native Optionen für den Konfigurationsspeicher verfügbar, z. B. DynamoDB- und S3-Speicher in AWS oder Azure Files-Speicher in Microsoft Azure.

Weitere Informationen zum Erreichen einer Bereitstellung von ArcGIS Server mit hoher Verfügbarkeit finden Sie unter Konfigurieren einer Site mit mehreren Computern. Ressourcen für Bereitstellungen mit hoher Verfügbarkeit auf einem einzelnen Computer sind ebenfalls verfügbar.

Web Adaptor

Web Adaptor kann redundant auf zwei oder mehr Computern bereitgestellt werden, wobei jede Instanz in einer Aktiv/Aktiv-Konfiguration vollständig redundant ist. Für diese Konfiguration ist ein Front-End-Load Balancer erforderlich, an den Clients ihre Anforderungen senden und der die Anforderungen auf beide Web Adaptor-Hosts verteilt. Weitere Ressourcen finden Sie in der Dokumentation.

ArcGIS Data Store

Data Store vom Typ “relational”: Ein hoch verfügbarer Data Store vom Typ “relational” besteht aus genau zwei vollständig redundanten Instanzen in einer Aktiv/Aktiv-Clusterkonfiguration. Wenn der primäre Data-Store-Computer ausfällt, erkennt der Standby-Computer den Fehler und wird selbst zum primären Computer. Clients können dann gehostete Feature-Services weiter ohne Unterbrechung verwenden.

Graph Data Store: Ein hoch verfügbarer Graph Store besteht aus genau drei vollständig redundanten Instanzen in einer Aktiv-Aktiv-Clusterkonfiguration.

Objektspeicher: Die hohe Verfügbarkeit für den Objektspeicher wird im Cluster-Modus unterstützt, wobei für diese Architektur mindestens drei Computer erforderlich sind. Da im Cluster-Modus die Daten auf diesen drei Computern repliziert werden, bleibt der Data Store beim Ausfall eines einzelnen Computers verfügbar.

Big Data Store vom Typ “spatiotemporal”: Data Stores dieses Typs unterstützen auch den Cluster-Modus. Cluster sollten eine ungerade Anzahl an Computern (was für die Konsensfindung unter den Mitgliedern erforderlich ist) sowie mindestens drei Computer enthalten. Alle diese Konfigurationen sind Aktiv/Aktiv-Konfigurationen mit hoher Verfügbarkeit.

Das Dokumentationsthema Konfigurieren von verwalteten Data Stores mit hoher Verfügbarkeit enthält zusätzliche Anleitungen, Schritte und Empfehlungen.

Relationale Datenbanken

Die Verfügbarkeit von Datenbankressourcen ist ein spezieller Bereich der Architektur mit vielen anbieterspezifischen Optionen für jedes einzelne Datenbankangebot, zu denen auch Aktiv/Aktiv- und Aktiv-Passiv/Muster gehören. Im Allgemeinen kann ArcGIS eine Verbindung zu diesen Konfigurationen herstellen, wenn bei der Datenregistrierung, über die auf Services zugegriffen oder Services veröffentlicht werden, ein DNS-Alias oder eine flexible IP-Adresse verwendet wird, auf die immer von ArcGIS aus zugegriffen wird, die aber bei einem Ausfall des primären Systems auf eine andere Backend-Datenbank verweisen kann. In diesem Szenario bemerken die ArcGIS-Komponenten die Änderung in der Backend-Datenbank nicht und funktionieren weiterhin erwartungsgemäß, vorausgesetzt, dass dieselben Anmeldeinformationen, dasselbe Schema und dieselben Zeilen verfügbar sind.

Empfehlungen zum Entwurf

Wenn Sie fundierte und effektive Entscheidungen im Zusammenhang mit hoher Verfügbarkeit treffen möchten, dann sollten Sie die folgenden Entwurfsempfehlungen berücksichtigen:

• Sicherungen: Das Erstellen von Sicherungen Ihrer ArcGIS-Bereitstellung ist die einfachste Möglichkeit, Datenverluste zu vermeiden und Ausfallzeiten zu reduzieren. Damit können Sie Elemente wiederherstellen, die zum Zeitpunkt der Erstellung der Sicherung vorhanden waren, und die Zeit bis zur Betriebsaufnahme wird erheblich verkürzt.
• Verwalten von schreibgeschützten und nicht schreibgeschützten Systemen: Wenn es sich bei Ihrer Anwendung oder Ihrem System um ein schreibgeschütztes System handelt, bei dem Benutzer hauptsächlich Daten anzeigen, die an anderer Stelle verwaltet werden, ist das Erreichen einer Konfiguration mit hoher Verfügbarkeit einfacher, da eine Aktiv-Aktiv-Konfiguration verwendet werden kann. Wenn Änderungen von Benutzern erstellt werden, gibt es in einem nicht schreibgeschützten System in der Regel eine Mischung aus Aktiv/Aktiv- und Aktiv/Passiv-Ebenen der Architektur, was die Verwaltung einer primären, aktiven Kerndatenbank ermöglicht und auch dafür sorgt, dass das passive, Standby- oder Failover-System im Falle eines Ausfalls für den Empfang von Datenverkehr bereit ist.
• Duplizierung und Redundanz: Implementieren Sie mehrere Instanzen bestimmter Systemkomponenten, möglicherweise mit geographischer Redundanz, um Single Points of Failure zu reduzieren. Berücksichtigen Sie die Fähigkeiten, die für die Wartung des Systems erforderlich sind. Bedenken Sie, dass eine Person genauso gut ein Single Point of Failure sein kann.
• Testpläne und Systemüberwachung: Bewerten Sie die Fähigkeit des Systems, den erforderlichen Servicelevel zu erfüllen, indem Sie die Belastung, die Leistung und die Failover-Funktionen testen. Alle Testpläne und die damit verbundenen Aktivitäten sollten Teil Ihrer gesamten System-Governance sein. Überwachen Sie das System kontinuierlich, um Probleme zu beheben, bevor sie einen großflächigen oder nicht behebbaren Ausfall verursachen.
• Zu den weiteren Empfehlungen zur hohen Verfügbarkeit gehören Automatisierung, Zusammenarbeit, Load-Balancing und Arbeitslasttrennung.