Einheit 3.5: Hochverfügbarkeit am Netzwerkrand

Einführung

Ein öffentlicher Endpunkt ist nur so verfügbar wie das einzelne Netzwerkinterface, das derzeit darauf antwortet. Wenn dieses Interface zu einem Server gehört und der Server verloren geht, hört die Adresse auf zu antworten, und jeder Client, der sie zwischengespeichert hat, bleibt bis etwas die Adresse an einen anderen Ort verschiebt, gestrandet. Die architektonische Frage am Netzwerkrand ist daher nicht "Wie mache ich einen Server zuverlässig", sondern "Wie halte ich eine stabile öffentliche Adresse ansprechbar, wenn sich das dahinterliegende Objekt ändert". IONOS bietet Ihnen ein spezifisches Primitiv dafür, IP-Failover, mit einem präzisen und engen Anwendungsbereich. Diese Einheit behandelt die Hochverfügbarkeit am Rand als Designentscheidung: was IP-Failover garantiert, was es bewusst nicht tut, und wie es in das umfassendere Bild der Widerstandsfähigkeit passt, das Modul 7 vervollständigt.

1. IP-Failover: Eine gemeinsame Adresse über redundante Netzwerkkarten

IP-Failover ist der Mechanismus der Plattform für eine aktive-passive Kante. Die Cloud-IP-Failover-Funktion bereitstellt die gleiche IP-Adresse für mehrere Netzwerkschnittstellen, die verschiedenen virtuellen Servern auf dem gleichen LAN gehören. Eine Netzwerkkarte wird als Master bezeichnet und hält die Adresse als ihre primäre IP-Adresse; die anderen Netzwerkkarten in der Gruppe sind Replikate, die bereit sind, die gleiche Adresse zu übernehmen. Wenn der Master-Server ausfällt, kann die Adresse zu einer Replikat-Netzwerkkarte wechseln, sodass der öffentliche Endpunkt weiterhin antwortet, ohne dass der Client jemals eine neue Adresse erlernen muss.

Was diese Funktion als stabilen Endpunkt ermöglicht, ist, dass die Adresse eine reservierte öffentliche IP-Adresse sein muss. DHCP-generierte Adressen können nicht in einer Failover-Gruppe verwendet werden. Dies ist die gleiche Reservierungsdisziplin, die Sie beim Aufbau der drei-LAN-Topologie in Einheit 3.1 angewendet haben: die reservierte IPv4-Adresse ist regionsspezifisch und besteht unabhängig von einem einzelnen Server, was genau die Eigenschaft ist, die ein Hochverfügbarkeits-Endpunkt benötigt. Die Failover-Gruppe bindet einfach diese persistente Adresse an eine Reihe von Kandidaten-Netzwerkkarten und verfolgt, welche davon derzeit die Adresse besitzt.

Die wichtigste Eigenschaft, die internalisiert werden muss, ist die Grenze der Garantie. IP-Failover ermöglicht die Bereitstellung der gleichen IP-Adresse für mehrere Schnittstellen. Es überwacht jedoch nicht die Verfügbarkeit des Dienstes, der über diese IP-Adresse erreicht wird. Die Plattform verschiebt eine Adresse zwischen Netzwerkkarten; sie führt jedoch keinen Gesundheitstest gegen Ihre Anwendung durch, entscheidet, dass Ihr Webserver Fehler zurückgibt, und löst einen Wechsel auf Ihre Seite aus. Die Erkennungs- und Entscheidungslogik, die ein Replikat zum Master befördert, lebt in Ihrem Gast-Betriebssystem. Das etablierte Muster ist eine Software-Hochverfügbarkeitsschicht, die auf den Servern selbst läuft, beispielsweise keepalived, das VRRP antreibt, oder ein HA-Mechanismus eines Herstellers, der entscheidet, wann die gemeinsame Adresse beansprucht und dann den Wechsel antreibt. Die Plattform liefert das gemeinsame-Adresse-Primitiv; Sie liefern die Intelligenz, die entscheidet, wann ein Failover durchgeführt wird. Dies ist die wiederkehrende Aufteilung der Arbeit, die die Plattform auf der Infrastrukturbene versus der Anwendungsebene zieht, und am Rand ist sie ungewöhnlich scharf.

Zwei weitere Einschränkungen prägen jedes Design, das IP-Failover verwendet:

• Der LAN muss öffentlich (mit dem Internet verbunden) sein und darf keinen Load Balancer enthalten. IP-Failover und ein gemanagter Load Balancer sind alternative Kantenmuster, nicht geschichtete: Wenn ein Managed Application Load Balancer oder ein Netzwerk-Load Balancer bereits die Ebene vorne hat, ist dieser Lastenausgleich die Verfügbarkeitskonstruktion und IP-Failover gilt nicht für den gleichen LAN.
• Virtuelle MAC-Adressen werden nicht unterstützt. Ein Failover-Design kann nicht davon ausgehen, dass eine portable Schicht-2-Identität mit der Adresse reist; der Wechsel erfolgt auf der IP-Ebene, und das Replikat antwortet mit seiner eigenen MAC-Adresse, sobald es die Adresse besitzt. Planen Sie das ARP/Nachbarnverhalten und alle Erwartungen an die gratuitous-ARP entsprechend, da die Gast-HA-Software die Bewegung ankündigt.

IP-Failover muss für alle solchen HA-Setups konfiguriert werden; es ist die native Konstruktion für ein selbstverwaltetes aktives-passives Paar hinter einer öffentlichen Adresse, und die Plattform dokumentiert keine Alternative für diese spezifische Form.

2. Wenn Edge IP-Failover das richtige Werkzeug ist

IP-Failover verdient seinen Platz in einem engen Band von Designs, und das Erkennen dieses Bandes hält Sie davon ab, es falsch anzuwenden. Die folgende Tabelle vergleicht die Optionen für die Verfügbarkeit am Rand, die Sie jetzt über dieses Modul verfügen.

Die entscheidende Frage ist, ob das Ding, das Sie schützen, seine eigene Verfügbarkeit verwaltet und eine einzelne öffentliche Adresse benötigt, oder ob es eine horizontal skalierbare Tier ist, die ein gemanagter Lastenausgleich verteilen sollte. Ein selbstverwaltetes Netzwerk-Virtual-Appliance, ein Software-Firewall oder ein clusterfähiger Dienst, der erwartet, eine schwimmende VIP zu besitzen, ist der klassische IP-Failover-Kandidat: es läuft bereits Keepalived oder ein Äquivalent und benötigt nur, dass die Plattform zwei seiner NICs eine reservierte Adresse teilen lässt. Eine zustandslose Web- oder API-Tier ist nicht; das gehört hinter einem gemanagten Load Balancer, wo Gesundheitsprüfung und Backend-Verteilung für Sie gehandhabt werden.

IP-Failover ist auch durch den Fehlerbereich begrenzt. Da die Failover-Gruppe auf einem einzelnen LAN lebt, schützt sie gegen den Verlust eines Servers, nicht gegen den Verlust einer Verfügbarkeitszone oder einer Region. Das ist die Nahtstelle, an der die nächsten beiden Mechanismen übernehmen.

3. Erstellung von Edge-HA mit Multi-Zone-Platzierung und DNS-Failover

Kein einzelnes Konstrukt bietet eine umfassende Ausfallsicherheit, und die Planung, als ob eines vorhanden wäre, ist der häufigste Fehler am Rand. Die robuste Haltung ist schichtweise, wobei jedes Mechanismus den Fehlerbereich abdeckt, den der darunterliegende nicht abdecken kann.

Unten wird die Multi-Zone-Platzierung die redundanten Mitglieder jedes Paares über Verfügbarkeitszonen verteilt, sodass ein Fehler auf Zonenebene nicht beide Hälften auf einmal beeinträchtigen kann. Dies ist eine Platzierungsentscheidung, die bei der Bereitstellung getroffen wird, und sie interagiert direkt mit Edge-HA: Ein IP-Failover-Paar, dessen Master und Replikat in der gleichen Zone sitzen, gewinnt nichts, wenn diese Zone verloren geht. Platzieren Sie die Mitglieder in verschiedenen Zonen und seien Sie dabei bewusst, anstatt eine automatische Platzierung zu akzeptieren, die sie möglicherweise zusammenlegen könnte. (Compute bietet Zonen 1, 2 und Auto; "Auto" ist bequem, aber genau diese Einstellung kann ein redundantes Paar stillschweigend zusammenlegen, also nennen Sie die Zonen explizit für jedes HA-Paar. Modul 7 kehrt in dem Zusammenhang der Ausfallsicherheit zu dieser Auto-Zonen-Falle zurück.)

Über der Platzierung hinweg deckt das DNS-Failover die Fehlerbereiche ab, die kein einzelnes IP abdecken kann. Ein reservierter IP und seine Failover-Gruppe sind an eine Region und einen LAN gebunden; sie können keinen Endpunkt zu einem zweiten Standort oder einer zweiten Region verschieben. Wenn der Fehlerbereich, den Sie überleben müssen, größer ist als ein LAN, bewegt sich die Steuerung nach oben zur Namensebene. Wie in Einheit 3.7 entwickelt wird, ist dies ein kundenspezifisches Muster und kein natives Produkt: Ihre eigene Gesundheitsprüfung (ein externer Monitor oder ein Signal von einem Load Balancer-Zielzustand) erkennt einen toten Endpunkt und ruft den Cloud DNS API auf, um einen low-TTL-Eintrag auf einen gesunden Endpunkt umzuleiten. Cloud DNS selbst ist nicht gesundheitsbewusst; es dient dem Eintrag, den Sie festlegen, und ändert nie eine Antwort von selbst. So erhalten Sie automatisches Failover über Zonen und Standorte, obwohl es kein gemanagtes Failover-Produkt gibt. Das DNS-Failover steuert nur neue Verbindungen, sodass die Ebenen, die es vorne hat, zustandslos sein müssen, damit das Muster sicher ist.

Wenn man die drei Schichten zusammen liest, bilden sie eine klare Hierarchie: Das IP-Failover stellt sicher, dass eine einzelne öffentliche Adresse auch dann noch antwortet, wenn ein Server auf einem LAN stirbt; die Multi-Zone-Platzierung stellt sicher, dass die redundanten Mitglieder nicht den gleichen Zonenfehler teilen; und das DNS-Failover leitet Clients um, wenn ein gesamter Endpunkt, eine Zone oder ein Standort weg ist. Jedes ist notwendig, keines ist allein ausreichend, und das Edge-Design ist die Handlung, die auswählt, welche Schichten ein bestimmter Endpunkt tatsächlich benötigt.

FinCorp am Rand

FinCorps regulierte Workloads sitzen hinter einem selbstverwalteten Netzwerk-Firewall-Gerät, das das Sicherheitsteam aus Gründen der Richtlinie und des Audits selbst betreiben möchte. Dieses Gerät ist der klassische Fall für ein IP-Failover: Zwei Firewall-Instanzen auf dem öffentlichen LAN, Master und Replikat, teilen sich eine reservierte öffentliche IPv4-Adresse, wobei der HA-Prozess der Geräte entscheidet, wann das Replikat die Adresse beansprucht. FinCorp platziert die beiden Firewall-Instanzen in verschiedenen Verfügbarkeitszonen, sodass ein Zonenfehler nicht beide beeinträchtigen kann, und akzeptiert, dass die Plattform den Firewall-Dienst nicht für sie überwacht; diese Überwachung ist die Aufgabe des Geräts. Für die öffentlich zugängliche zustandslose Web-Ebene, die hinter diesem Firewall sitzt, verwendet FinCorp kein IP-Failover; es verwendet das Managed Application Load Balancer aus Einheit 3.3, weil diese Ebene horizontal skaliert und von einer gesundheitsgeprüften Verteilung profitiert. Die Frage des Überlebens des Verlusts der primären Region als Ganzes wird auf das DNS-Failover-Design in Einheit 3.7 und den Kontinuitätsplan in Modul 7 verschoben, weil kein Edge-IP diese Anforderung erfüllen kann. Die Entscheidung kumuliert: Ein reservierter IP und ein IP-Failover-Paar für das selbstverwaltete Gerät, gemanagtes Lastenausgleich für die elastischen Ebenen und DNS als die schichtübergreifende Steuerungsebene.

Entscheidungszusammenfassung

Die Auswahlregel: Schützen Sie ein selbstverwaltetes, einzelnes Adressenpaar mit IP-Failover; schützen Sie eine elastische Tier mit einem gemanagten Load Balancer; schützen Sie gegen Zonenverlust mit expliziter Multi-Zonen-Platzierung; und schützen Sie gegen den Verlust eines gesamten Endpunkts oder Standorts mit DNS-Failover. Die Mechanismen schichten sich; sie ersetzen sich nicht gegenseitig.

Zusammenfassung

Die Hochverfügbarkeit am IONOS-Netzwerkrand wird durch Zusammensetzung und nicht durch ein einzelnes Feature erreicht. Der IP-Failover bietet ein selbstverwaltetes aktives-passives Paar eine stabile reservierte öffentliche IP-Adresse, die zwischen redundanten Netzwerkkarten (NICs) auf dem gleichen öffentlichen LAN verschoben werden kann, aber absichtlich beim Bereitstellen der gemeinsamen Adresse stoppt: Die Gesundheitserkennung und die Entscheidung zum Failover liegen in Ihrem Gastsystem, und der Aufbau kann nicht über eine lastverteilte LAN, eine DHCP-Adresse oder eine virtuelle MAC-Adresse verfügen. Um diesen primitiven Mechanismus herum schichten Sie eine explizite Multi-Zonen-Platzierung, um Fehler auf Zonenebene zu überwinden, und DNS-Failover, um Clients umzuleiten, wenn ein gesamter Endpunkt oder eine gesamte Website nicht mehr verfügbar ist, was die Plattform als Antwort auf das Fehlen eines verwalteten Failover-Produkts bietet.

Wichtige Punkte:

• Der IP-Failover bereitstellt eine reservierte öffentliche IP-Adresse über mehrere NICs auf verschiedenen Servern auf dem gleichen öffentlichen LAN; der Master hält sie, Replikate können sie übernehmen.
• Die Plattform überwacht die Dienstgesundheit nicht für das Failover. Die Erkennung und die Beförderung sind die Verantwortung des Kunden, typischerweise eine Gast-HA-Ebene wie keepalived/VRRP oder ein HA-Produkt eines Anbieters.
• Der IP-Failover erfordert eine reservierte öffentliche IP-Adresse (keine DHCP), ein öffentliches LAN ohne Load Balancer und unterstützt keine virtuellen MAC-Adressen.
• Der IP-Failover ist für selbstverwaltete Einzeladressenpaare; elastische Zustandslose-Ebenen gehören hinter einem verwalteten Load Balancer.
• Die Edge-HA komponiert mit Multi-Zonen-Platzierung (Überwindung von Zonenfehlern; Zonen explizit festlegen, nie Auto für ein redundantes Paar) und DNS-Failover (Überwindung von Endpunkt-/Zonen-/Seitenverlust), wobei jeder eine Fehlerdomäne abdeckt, die der andere nicht abdecken kann.

Wichtige Begriffe:

• IP-Failover-Gruppe: Eine Menge von NICs auf verschiedenen Servern auf einem öffentlichen LAN, die eine einzelne reservierte öffentliche IP-Adresse teilen, mit einem bestimmten Master, der das aktive-passive Failover der Adresse ermöglicht.
• Master-/Replik-NIC: Innerhalb einer Failover-Gruppe ist der Master derzeit der Besitzer der gemeinsamen Adresse als seine primäre IP-Adresse; Replikate sind berechtigt, sie zu übernehmen.
• Aktiv-passive HA: Ein Redundanzmodell, bei dem ein Node den Datenverkehr bedient und ein Standby bei einem Ausfall übernimmt, im Gegensatz zum aktiven-aktiven Lastenausgleich.

Weitere Lektüre

• Einheit 3.3, Lastverteilung - Layer 7 (Anwendung), und Einheit 3.4, Lastverteilung - Layer 4 (Netzwerk), für die Alternative des gemanagten Lastenausgleichs.
• Einheit 3.7, DNS und Failover-Routing, für die cross-zone- und cross-site-Failover-Steuerung.
• Modul 7, Betrieb, Widerstandsfähigkeit und Leistung, für die multi-zone-Platzierung, die Auto-Zone-Falle und das vollständige Bild der Geschäftskontinuität.