Einheit 3.5: Hochverfügbarkeit am Netzwerkrand

Einführung

Ein öffentlicher Endpunkt ist nur so verfügbar, wie die einzelne Netzwerkschnittstelle, die derzeit für ihn antwortet. Wenn diese Schnittstelle zu einem Server gehört und der Server ausfällt, hört die Adresse auf zu antworten, und jeder Client, der sie zwischengespeichert hat, bleibt hängen, bis die Adresse an einen anderen Ort verschoben wird. Die architektonische Frage an der Netzwerkkante lautet daher nicht „Wie mache ich einen Server zuverlässig?“, sondern „Wie halte ich eine stabile öffentliche Adresse antwortend, wenn sich das dahinterliegende Element ändert?“. IONOS CLOUD bietet dafür ein spezifisches Primitiv, IP Failover, mit einem präzisen und engen Anwendungsbereich. Diese Einheit behandelt Edge-HA als eine Designentscheidung: was IP Failover garantiert, was es bewusst nicht tut und wie es in das umfassendere Resilienz-Bild einpasst, das Modul 7 vervollständigt.

1. IP Failover: Eine gemeinsame Adresse über redundante NICs

IP Failover ist der Mechanismus der Plattform für einen Active-Passive-Edge. Die Funktion Cloud IP-Failover provisioniert dieselbe IP-Adresse für mehrere Netzwerkinterfaces, die zu verschiedenen virtuellen Servern im selben LAN gehören. Eine NIC wird als Master festgelegt und hält die Adresse als ihre primäre IP; die anderen NICs in der Gruppe sind Replikate, die bereitstehen, dieselbe Adresse zu übernehmen. Wenn der Master-Server ausfällt, kann die Adresse zu einer Replikat-NIC wechseln, sodass der öffentliche Endpunkt weiterhin antwortet, ohne dass der Client eine neue Adresse erfahren muss.

Dass dies als stabiler Endpunkt funktioniert, liegt daran, dass die Adresse eine reservierte öffentliche IP sein muss. Per DHCP generierte Adressen können in einer Failover-Gruppe nicht verwendet werden. Dies ist dieselbe Reservierungsdisziplin, die Sie bei der Erstellung der Topologie mit drei LANs in Einheit 3.1 angewendet haben: Die reservierte IPv4-Adresse ist an eine Region gebunden und besteht unabhängig von einem einzelnen Server, was genau die Eigenschaft ist, die ein HA-Endpunkt benötigt. Die Failover-Gruppe bindet diese persistente Adresse einfach an einen Satz von Kandidaten-NICs und verfolgt, welche davon sie aktuell besitzt.

Die wichtigste Eigenschaft, die verinnerlicht werden muss, ist die Grenze der Garantie. IP Failover stellt die Provisionierung derselben IP für mehrere Interfaces bereit. Er überwacht nicht die Verfügbarkeit des Dienstes, der über diese IP erreicht wird. Die Plattform verschiebt eine Adresse zwischen NICs; sie führt keine Health-Probe gegen Ihre Anwendung aus, entscheidet nicht, dass Ihr Webserver Fehler zurückgibt, und löst keinen Wechsel in Ihrem Namen aus. Die Erkennungs- und Entscheidungslogik, die ein Replikat zum Master befördert, befindet sich in Ihrem Gast-Betriebssystem. Das etablierte Muster ist eine Software-HA-Schicht, die auf den Servern selbst ausgeführt wird, beispielsweise keepalived, das VRRP steuert, oder der eigene HA-Mechanismus eines Vendor-Geräts, das entscheidet, wann die gemeinsame Adresse beansprucht wird, und dann den Wechsel steuert. Die Plattform liefert das Primitive der gemeinsamen Adresse; Sie liefern die Intelligenz, die entscheidet, wann ein Failover erfolgen soll. Dies ist die wiederkehrende Arbeitsteilung, die die Plattform auf Infrastrukturebene im Gegensatz zur Anwendungsebene zieht, und am Edge ist sie ungewöhnlich scharf.

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

• Das LAN muss öffentlich sein (mit dem Internet verbunden) und darf keinen Load Balancer enthalten. IP Failover und ein Managed Load Balancer sind alternative Edge-Muster, keine geschichteten: Wo bereits ein Managed Application Load Balancer oder Network Load Balancer die Ebene absichert, ist dieser Balancer das Verfügbarkeitskonstrukt, und IP Failover gilt nicht im selben LAN.
• Virtuelle MAC-Adressen werden nicht unterstützt. Ein Failover-Design kann nicht von einer portablen Layer-2-Identität ausgehen, die mit der Adresse wandert; der Wechsel erfolgt auf der IP-Ebene, und das Replikat antwortet mit seiner eigenen MAC, sobald es die Adresse besitzt. Planen Sie das ARP/Neighbour-Verhalten und eventuelle Erwartungen an gratuitous ARP entsprechend, da die Gast-HA-Software den Wechsel ankündigt.

IP Failover muss für alle solchen HA-Setups konfiguriert werden; es ist das native Konstrukt für ein selbst verwaltetes Active-Passive-Paar hinter einer öffentlichen Adresse, und die Plattform dokumentiert keine Alternative für diese spezifische Form.

2. Wann IP-Failover das richtige Werkzeug ist

IP-Failover hat seinen Platz in einem engen Spektrum von Designs, und die Erkennung dieses Spektrums verhindert seine falsche Anwendung. Die folgende Tabelle stellt die Optionen für Edge-Verfügbarkeit gegenüber, die Sie in diesem Modul nun haben.

Die entscheidende Frage ist, ob das, was Sie schützen, seine eigene Verfügbarkeit verwaltet und eine einzelne klebrige öffentliche Adresse benötigt, oder ob es eine horizontal skalierbare Ebene ist, auf die ein verwalteter Balancer den Verkehr verteilen sollte. Ein selbstverwaltetes Netzwerk-Virtualgerät, eine Software-Firewall oder ein clustrierter Dienst, der erwartet, einen schwebenden VIP zu besitzen, ist der klassische Kandidat für IP-Failover: Es führt bereits keepalived oder ein Äquivalent aus und benötigt nur, dass die Plattform zwei seiner NICs eine reservierte Adresse teilen lässt. Eine zustandslose Web- oder API-Ebene ist das nicht; diese gehört hinter einen verwalteten Load Balancer, wo Gesundheitsprüfung und Backend-Verteilung für Sie übernommen werden.

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

3. Edge-HA durch mehrzonalen Aufbau und DNS-Failover

Kein einzelnes Konstrukt liefert Resilienz von Ende zu Ende, und so zu gestalten, als würde es, ist der häufigste Fehler am Edge. Die robuste Auslegung ist geschichtet, wobei jeder Mechanismus den Fehlerbereich abdeckt, den der darunterliegende nicht abdecken kann.

Am untersten Ende verteilt mehrzonaler Aufbau die redundanten Mitglieder eines Paares über Verfügbarkeitszonen, sodass ein zonaler Fehler beide Hälften nicht gleichzeitig ausfällt. Dies ist eine Platzierungsentscheidung, die bei der Bereitstellung getroffen wird, und sie wirkt sich direkt auf Edge-HA aus: Ein IP-Failover-Paar, dessen Master und Replikat in derselben Zone liegen, gewinnt nichts, wenn diese Zone verloren geht. Platzieren Sie die Mitglieder in verschiedenen Zonen und treffen Sie dies bewusst, anstatt eine automatische Platzierung zu akzeptieren, die sie möglicherweise zusammen anordnet. (Compute bietet die Zonen 1, 2 und Auto an; „Auto" ist bequem, ist aber genau die Einstellung, die ein redundantes Paar stillschweigend zusammenbringen kann. Benennen Sie die Zonen daher für jedes HA-Paar explizit. Modul 7 kehrt in diesem Resilienz-Kontext auf diese Auto-Zonen-Falle zurück.)

Über der Platzierung liegt DNS-Failover, der die Fehlerbereiche abdeckt, die eine einzelne IP nicht überbrücken kann. Eine reservierte IP und ihre Failover-Gruppe sind an eine Region und ein LAN gebunden; sie können einen Endpunkt nicht an einen zweiten Standort oder eine zweite Region verlegen. Wenn der Fehlerbereich, dem Sie standhalten müssen, größer als ein LAN ist, verschiebt sich die Steuerung auf den Namen. Wie in Einheit 3.7 dargelegt, ist dies ein vom Kunden gebautes Muster und kein natives Produkt: Ihre eigene Gesundheitsprüfung (ein externer Monitor oder ein Signal aus der Zielgesundheit eines Load Balancers) erkennt einen ausgefallenen Endpunkt und ruft die Cloud DNS API auf, um einen Datensatz mit niedriger TTL auf einen gesunden Endpunkt umzuleiten. Cloud DNS selbst ist nicht gesundheitsbewusst; es liefert den Datensatz, den Sie festgelegt haben, und ändert eine Antwort nie von selbst. So erhalten Sie automatisiertes Failover über Zonen und Standorte hinweg, da kein verwaltetes Failover-Produkt existiert. DNS-Failover steuert nur neue Verbindungen, daher müssen die von ihm bedienten Ebenen zustandslos sein, damit das Muster sicher ist.

Gemeinsam gelesen bilden die drei Ebenen eine klare Hierarchie: IP-Failover sorgt dafür, dass eine einzelne öffentliche Adresse antwortet, wenn ein Server in einem LAN ausfällt; mehrzonaler Aufbau stellt sicher, dass die redundanten Mitglieder kein zonal gemeinsames Schicksal teilen; und DNS-Failover leitet Clients um, wenn ein gesamter Endpunkt, eine Zone oder ein Standort verloren ist. Jede Ebene ist notwendig, keine ist allein ausreichend, und das Edge-Design besteht darin zu entscheiden, welche Ebenen ein gegebener Endpunkt tatsächlich benötigt.

FinCorp am Edge

Die regulierten Workloads von FinCorp liegen hinter einer selbst verwalteten Netzwerk-Firewall-Appliance, die das Sicherheitsteam aus Gründen der Richtlinien und Prüfung selbst betreiben muss. Diese Appliance ist der Lehrbuchfall für IP-Failover: zwei Firewall-Instanzen im öffentlichen LAN, Master und Replikat, die eine reservierte öffentliche IPv4-Adresse teilen, wobei der eigene HA-Prozess der Appliances entscheidet, wann das Replikat die Adresse übernimmt. FinCorp platziert die beiden Firewall-Instanzen in verschiedenen Verfügbarkeitszonen, damit ein Zonenfehler beide nicht fallen lässt, und akzeptiert, dass die Plattform den Firewall-Dienst nicht für sie prüft; diese Überwachung ist Aufgabe der Appliance. Für die zustandslose, öffentlich zugängliche Web-Ebene hinter dieser Firewall verwendet FinCorp überhaupt kein IP-Failover; es nutzt den Managed Application Load Balancer aus Einheit 3.3, da diese Ebene horizontal skaliert und von einer gesundheitsgeprüften Verteilung profitiert. Die Frage des Standortübergreifenden Betriebs, nämlich das Überstehen des vollständigen Verlusts der primären Region, wird auf das DNS-Failover-Design in Einheit 3.7 und den Kontinuitätsplan in Modul 7 verschoben, da keine Edge-IP diese Anforderung erfüllen kann. Die Entscheidung summiert sich: eine reservierte IP und ein IP-Failover-Paar für die selbst verwaltete Appliance, verwaltete Lastverteilung für die elastischen Ebenen und DNS als steuerebene für den standortübergreifenden Betrieb.

Zusammenfassung der Entscheidung

Die Auswahlregel: Schützen Sie ein selbst verwaltetes, einadressiges Paar mit IP-Failover; schützen Sie eine elastische Ebene mit einem verwalteten Load Balancer; schützen Sie sich vor dem Verlust einer Zone durch explizite Mehrzonenplatzierung; und schützen Sie sich vor dem Verlust eines gesamten Endpunkts oder einer Site mit DNS-Failover. Die Mechanismen schichten sich; sie ersetzen einander nicht.

Zusammenfassung

Die Hochverfügbarkeit am Netzwerkrand von IONOS CLOUD wird durch Komposition aufgebaut, nicht durch eine einzelne Funktion. IP Failover versieht ein selbst verwaltetes Active-Passive-Paar mit einer stabilen reservierten öffentlichen IP, die zwischen redundanten NICs im selben öffentlichen LAN verschoben werden kann. Es stoppt jedoch bewusst bei der Bereitstellung der gemeinsamen Adresse: Die Erkennung des Gesundheitszustands und die Entscheidung für einen Failover liegen in Ihrer Gastumgebung. Das Konstrukt kann kein loadbalanciertes LAN überspannen, keine DHCP-Adresse verwenden und keine virtuelle MAC-Adresse nutzen. Um dieses Grundelement herum werden explizite Multi-Zone-Platzierungen geschichtet, um zonenweite Ausfälle zu überwinden, sowie DNS-Failover, um Clients umzuleiten, wenn ein gesamter Endpunkt oder eine gesamte Site ausgefallen ist. Dies ist die Antwort der Plattform auf das Fehlen eines verwalteten Failover-Produkts.

Wichtige Punkte:

• IP Failover bereitstelt eine reservierte öffentliche IP über mehrere NICs auf verschiedenen Servern im selben öffentlichen LAN; der Master hält sie, Replikate können sie übernehmen.
• Die Plattform überwacht keine Dienstgesundheit für Failover. Erkennung und Beförderung sind die Verantwortung des Kunden, typischerweise eine Gast-HA-Ebene wie keepalived/VRRP oder die eigene HA einer Vendor-Appliance.
• IP Failover erfordert eine reservierte öffentliche IP (kein DHCP), ein öffentliches LAN ohne Load Balancer und unterstützt keine virtuellen MAC-Adressen.
• IP Failover ist für selbst verwaltete Ein-Adress-Paare gedacht; elastische zustandslose Ebenen gehören stattdessen hinter einen verwalteten Load Balancer.
• Edge-HA wird mit Multi-Zone-Platzierung kombiniert (Überwindung von Zonenausfällen; Zonen explizit festlegen, niemals Auto für ein redundantes Paar) und DNS-Failover (Überwindung von Endpunkt-, Zonen- oder Site-Ausfall), wobei jede Komponente einen Fehlerbereich abdeckt, den die andere nicht kann.

Wichtige Begriffe:

• IP-Failover-Gruppe: Eine Gruppe von NICs auf verschiedenen Servern in einem öffentlichen LAN, die eine einzelne reservierte öffentliche IP teilen, mit einem festgelegten Master, die Active-Passive-Failover der Adresse ermöglicht.
• Master- / Replikat-NIC: Innerhalb einer Failover-Gruppe besitzt der Master die gemeinsame Adresse derzeit als seine primäre IP; Replikate sind berechtigt, sie zu übernehmen.
• Active-Passive-HA: Ein Redundanzmodell, bei dem ein Knoten den Verkehr bedient und ein Standby-Knoten bei einem Ausfall übernimmt, im Gegensatz zu Active-Active-Lastverteilung.

Weitere Lektüre

• Einheit 3.3, Lastverteilung - Layer 7 (Anwendung), und Einheit 3.4, Lastverteilung - Layer 4 (Netzwerk), für die Alternative am Edge mit verwaltetem Load Balancer.
• Einheit 3.7, DNS und Failover-Routing, für die Steuerung von Failover über Zonen und Standorte hinweg.
• Modul 7, Betrieb, Resilienz und Leistung, für die Platzierung in mehreren Zonen, die Auto-Zone-Falle und das Gesamtbild der Geschäftskontinuität.