Wer Amazon FSx for OpenZFS einsetzen möchte, sollte die Deployment-Typen kennen und verstehen, wie sie unter der Haube funktionieren. Aktuell werden drei Deployment-Typen unterstützt: Single-AZ (non-HA), Single-AZ (HA) und Multi-AZ (HA).
Beim Anlegen eines neuen Dateisystems stehen Ihnen zwei Methoden zur Auswahl: Quick Create und Standard Create. Quick Create bietet einen schlanken Setup-Prozess, während Standard Create deutlich umfangreichere Konfigurationsmöglichkeiten eröffnet.
Standard Create ist dabei nicht nur empfehlenswert – für zwei der drei Deployment-Typen ist es sogar zwingend erforderlich. Damit ist Standard Create für die meisten Implementierungen die erste Wahl, denn Sie haben von Anfang an mehr Kontrolle über die Konfiguration Ihres Dateisystems.
Deployment-Typ Single-AZ (non-HA)
Für Single-AZ (non-HA) müssen Sie Standard Create verwenden, da dieser Deployment-Typ in Quick Create nicht zur Auswahl steht (siehe Abbildung 1). Sie erhalten ein einzelnes Dateisystem, das sich im Fehlerfall durch den Austausch der defekten Infrastrukturkomponente automatisch wiederherstellen sollte. Während des Ausfalls kommt es jedoch zu Downtime und Datenverlust. In seltenen Fällen lässt sich das Dateisystem nicht wiederherstellen, und alle nicht gesicherten Daten gehen verloren.
Achten Sie darauf, die richtige Security Group zuzuweisen und passende Security-Group-Regeln anzulegen, damit der Datenverkehr zugelassen wird (bei Quick Create wird standardmäßig die Default-Security-Group der VPC zugewiesen). Das gilt für alle Deployment-Typen.
Abbildung 1 – die FSx-Erstellungs-UI für Quick Create.
Deployment-Typ Single-AZ (HA)
Bei Single-AZ (HA) können Sie zwischen Quick Create und Standard Create wählen. Standard Create ist jedoch zu bevorzugen, da Sie damit gezielt das gewünschte Subnetz und die Security Group festlegen können.
Dieser Deployment-Typ legt zwei Dateisysteme innerhalb desselben Subnetzes sowie eine Endpoint-IP-Adresse an (auf die wir beim Multi-AZ-Setup noch genauer eingehen). Über diese Endpoint-IP-Adresse wickelt FSx das Failover bei diesem Deployment-Typ ab. FSx hat einen DNS-Namen, der auf die Endpoint-IP-Adresse verweist, und diese Endpoint-IP-Adresse ist als sekundäre IP-Adresse an die ENI des aktuell aktiven Dateisystems gebunden. Bei einem Failover wird die Endpoint-IP-Adresse von der ENI des aktiven Dateisystems gelöst und an die ENI des Standby-Dateisystems gebunden. Der DNS-Eintrag verweist weiterhin auf dieselbe IP, die nun aber an der Standby-ENI hängt – bis das Hauptdateisystem vollständig wiederhergestellt ist.
Bei beiden bisher genannten Deployment-Typen lässt sich Ihr Dateisystem mit minimalem Aufwand auf Ihren EC2-Instanzen mounten. Beim Multi-AZ-Deployment ist dagegen ein zusätzlicher Schritt nötig.
Multi-AZ Deployment-Typ
Beim Multi-AZ Deployment-Typ sollten Sie unbedingt Standard Create statt Quick Create wählen, denn bei Quick Create lassen sich weder Subnetze auswählen noch Routing-Tabellen zuordnen. Die Zuordnung von Routing-Tabellen zu einem FSx-Dateisystem ist ausschließlich beim Multi-AZ-Setup verfügbar.
Ein per Quick Create erstelltes Multi-AZ-Setup verknüpft ausschließlich die Default-Routing-Tabelle, während Ihre Subnetze in der Regel eigene Routing-Tabellen verwenden. Warum ist das wichtig? Wenn Sie das Setup so anlegen, haben Sie out of the box keine Netzwerkkonnektivität, und Ihre Verbindung läuft in einen Timeout. Genau das ist einem meiner Kunden passiert, der Quick Create ausprobiert hat – und so kamen wir dazu, die Hintergründe genauer zu untersuchen.
Man könnte annehmen, dass Ressourcen innerhalb derselben VPC automatisch über die "local"-Route eine Verbindung zu Ihrem FSx-Dateisystem aufbauen – schließlich erreichen Sie auf diesem Weg auch andere AWS-Dienste wie RDS, ElastiCache und EC2-Instanzen in Ihrer VPC, und sogar Single-AZ-FSx-Dateisysteme sind so erreichbar. Doch hier kommt der Haken: In diesem Fall trifft die Annahme nicht zu. Die "local"-Route allein reicht unter diesen Bedingungen nicht aus, um Konnektivität zu Ihrem FSx-Dateisystem herzustellen.
Wie stellen Sie also Konnektivität her? Die kurze Antwort: Sie müssen die Routing-Tabellen der Subnetze, in denen Ihre EC2-Instanzen liegen, mit dem FSx-Dateisystem verknüpfen. Dazu klicken Sie neben "Route Tables" auf "Manage" und ordnen Routing-Tabellen zu oder heben die Zuordnung auf (siehe Abbildung 2).
Abbildung 2 – Änderung der Routing-Tabellen-Zuordnung bei FSx.
Sobald die Konnektivität aktiviert ist, sehen Sie in Ihrer Routing-Tabelle einen Eintrag mit einer ENI (siehe Abbildung 3). Diese ENI-Route ist der Weg von Ihrer Instanz zum FSx-Dateisystem. Der Eintrag besteht aus einer Endpoint-IP-Adresse und der ENI des aktuell aktiven Dateisystems.
Abbildung 3 – ENI-Eintrag in Ihren zugeordneten Routing-Tabellen.
Diese Konfiguration ist notwendig, damit das Failover funktioniert. Wie bei Single-AZ (HA) kommt auch hier eine Endpoint-IP-Adresse zum Einsatz – allerdings lässt sie sich nicht zwischen ENIs verschieben, wenn diese in unterschiedlichen AZs liegen. Hinzu kommt: Bei Single-AZ (HA) wird die Endpoint-IP-Adresse innerhalb eines bestehenden Subnetzes erstellt – beim Multi-AZ-Deployment ist das nicht der Fall.
Multi-AZ-Setup
Wenn Sie FSx im Multi-AZ-Modus einrichten, werden für die Redundanz zwei separate Dateisysteme in zwei Subnetzen in unterschiedlichen AZs angelegt. Jedes Dateisystem verfügt über eine eigene Elastic Network Interface (ENI). Beim Setup benötigt FSx eine spezielle IP-Adresse (eine "Floating"-IP), die für das Failover genutzt wird. Diese IP-Adresse ist eine einzelne Adresse (/32).
Den IP-Adressbereich können Sie entweder selbst über den Parameter "EndpointIpAddressRange" angeben oder FSx automatisch einen ungenutzten /28-CIDR-Bereich aus Ihrer VPC wählen lassen.
Ein wichtiges Detail zu dieser Floating-IP: Sie liegt zwar innerhalb des IP-Bereichs Ihrer VPC, ist aber bewusst außerhalb aller bestehenden Subnetzbereiche platziert. Aus Sicht des Amazon-EC2-Netzwerks ist diese IP-Adresse damit keiner konkreten Netzwerkressource und keinem Subnetz zugeordnet.
Ihre Dateisysteme und deren ENIs befinden sich weiterhin innerhalb Ihrer Subnetze; die Endpoint-IP-Adresse – also die Floating-IP – liegt jedoch in keinem Subnetz-CIDR Ihrer VPC. Der Eintrag in der Routing-Tabelle ist erforderlich, um Datenverkehr für die Floating-IP an die korrekte ENI des aktuell aktiven Dateisystems zu leiten. Ohne diese Route wird der Verkehr verworfen, da die Floating-IP zu keinem Subnetz gehört (siehe Abbildung 4).
Hintergrund dieser Konfiguration: FSx setzt kein DNS-basiertes Failover ein, da der NFS-Client beim Failover an Grenzen stößt. DNS-Lookups erfolgen nur einmal beim Mount-Vorgang. Daher muss FSx einen anderen Failover-Mechanismus nutzen als andere AWS-Multi-AZ-Dienste wie etwa RDS – andernfalls müssten NFS-Clients nach jedem Failover neu gemountet werden.
Damit das Failover zwischen Multi-AZ-Primary und Standby-Dateisystem nahtlos funktioniert, brauchen Sie also den ENI-Eintrag in den Routing-Tabellen der Subnetze, in denen Ihre Clients laufen. Bei einem Failover-Ereignis aktualisiert FSx alle damit verknüpften Kunden-Routing-Tabellen so, dass die Floating-IP (Destination) gleich bleibt, das Target im Failover-Fall aber auf das Standby-Dateisystem zeigt.
Abbildung 4 – FSx-Setup.
Fazit
Dieser Blogpost hat die Implementierung von Amazon FSx for OpenZFS beleuchtet: die Erstellungsoptionen, das Networking im Hintergrund und warum sich die Deployment-Typen technisch so unterschiedlich verhalten.
Fragen zum Einsatz von FSx for OpenZFS in Ihrem Unternehmen?
Wenn Sie noch überlegen, wie Sie ein OpenZFS-Multi-AZ-Setup – oder eine andere GCP- oder AWS-Infrastrukturlösung – erfolgreich in Ihrem Unternehmen umsetzen, unterstützen wir Sie gerne.
Bei DoiT International besteht unser Team ausschließlich aus erfahrenen Senior Engineers. Wir sind spezialisiert auf anspruchsvolles Cloud-Consulting, Architekturdesign und Debugging-Services. Ob Sie Ihre ersten Schritte mit verteilten Datenbanken planen, ein bestehendes System optimieren oder komplexe Probleme analysieren möchten – wir liefern maßgeschneiderte Expertenberatung, die genau zu Ihren Anforderungen passt.
Sprechen Sie uns an und holen Sie das volle Potenzial aus Ihrer Cloud-Infrastruktur heraus.