Was Sie wissen müssen, wenn Sie in Google Cloud mehr als eine Netzwerkschnittstelle nutzen
Der Load Balancer von Google Cloud mit einer einzigen globalen IP und einer ganzen Reihe von Backend-Diensten (VMs, K8s-Pods, Cloud-Functions-Instanzen usw.) ist heute der gängigste Weg, eine Anwendung im World Wide Web bereitzustellen. Vor allem dann, wenn Sie nicht mehr brauchen als das gute alte HTTP(S). Eine einzige IP-Adresse, die alles regelt, reicht in der Regel völlig aus.
Hin und wieder gibt es jedoch ein spezielles – oder nennen wir es traditionelles – Setup, bei dem eine VM Traffic über mehrere IPs annehmen soll. Meistens läuft das über TCP, doch auch das klassische IP-basierte HTTP Virtual Hosting kommt einem sofort in den Sinn.
Im Kern läuft das Ganze auf die Frage hinaus: "Wie bekomme ich eine GCP-VM mit mehreren IPs?" Eine Websuche führt Sie höchstwahrscheinlich zu "GCP-VM mit mehreren Netzwerkschnittstellen". Dieser Ansatz funktioniert wie hier beschrieben – jeder Network Interface Card (NIC) der VM wird eine externe IP zugewiesen. Es gibt jedoch einige Einschränkungen, die Sie kennen sollten:
- Jede Network Interface Card (NIC) braucht ein eigenes VPC-Netzwerk. An sich kein Problem, aber durchaus mit DevOps-Aufwand verbunden – Sie müssen nicht nur ein VPC anlegen und dessen IP-Bereiche überschneidungsfrei definieren, sondern auch für jedes VPC eigene Firewall-Regeln einrichten.
- Sie können maximal 8 NICs pro VM haben. Das mag für Ihre Zwecke reichen – oder eben nicht.
- Die Anzahl der NICs einer VM lässt sich nach deren Erstellung NICHT mehr ändern. Wenn Sie mit 5 IPs starten und später eine weitere hinzufügen wollen, müssen Sie die VM neu erstellen.
- Die Anzahl der vCPUs einer VM muss mindestens der Anzahl der NICs entsprechen. Hier kann es schnell teuer werden. 1–2 vCPUs reichen für Ihren gesamten Traffic vielleicht völlig aus, doch wenn Sie 8 IPs wollen, zahlen Sie trotzdem für eine Maschine mit 8 vCPUs.
Es gibt einen Trick, den ich mit Ihnen teilen kann: Erstellen Sie eine VM mit 8 vCPUs und 8 NICs, stoppen Sie sie, skalieren Sie den Maschinentyp herunter und starten Sie sie wieder. Vorsicht – GCP kann diese Lücke jederzeit schließen.
Forwarding Rules
Der günstigere und unkompliziertere Weg sind Forwarding Rules. Das gesamte Networking in GCP ist Software-defined, sodass Ihre VM nicht einfach IPs übernehmen und sie per ARP-Antwort ankündigen kann – ARP findet hier praktisch nicht statt. Es gibt nur localhost oder das Default-Gateway für alles andere. Selbst Traffic zur "Nachbar"-VM im selben VPC läuft über das Default-Gateway.
me@my-vm:~$ ip route showdefault via 10.128.0.1 dev ens410.128.0.1 dev ens4 scope linkWir müssen GCP also "erklären", dass wir weitere IPs für eingehenden Traffic wollen – und das geschieht über Forwarding Rules.
Eine Forwarding Rule in GCP ist sehr flexibel. Sie kann auf beliebige Kombinationen aus IP, Ports, Protokollen, HTTP-Hosts und -Pfaden lauschen und passenden Traffic an ein Ziel weiterleiten – das kann eine VM, ein VM-Pool, ein Cloud-Storage-Bucket, eine Cloud Function, ein K8s-Service usw. sein.
Forwarding Rules kosten Geld. Dazu später mehr.
In unserem Fall brauchen wir nur die einfachste Form – auf tcp:address:port lauschen und allen Traffic an eine einzelne Zielinstanz weiterleiten.
Forwarding Rules in ihrer einfachsten Form
Die GCP-Dokumentation hat einen sehr guten und sehr langen Artikel dazu, wie man das einrichtet. Google nennt diesen Ansatz Protocol Forwarding. In der GCP-UI-Konsole gibt es dafür praktisch keine Unterstützung. Wenn Sie das in einer anderen als der Standardregion einrichten wollen, müssen Sie penibel auf die richtigen Regions und Zones bei jedem Befehl achten (lassen Sie es mich in den Kommentaren wissen, falls Sie hierzu mehr Details wünschen).
Zum Glück geht es in der UI auch einfacher.
Reservieren wir zunächst einige IPs:
HINWEIS: Achten Sie darauf, dass Ihre IPs regional sind und in derselben Region liegen wie Ihre Ziel-VM.
Die UI weist Sie darauf hin, dass ungenutzte statische externe IPs ein höheres Pricing haben als genutzte – das beheben wir gleich.
Erstellen Sie als Nächstes eine VM – nennen wir sie "au-vm" in der Region australia-southeast1. Klicken Sie unbedingt auf "Allow HTTP traffic" oder konfigurieren Sie die Firewall-Regeln so, dass der entsprechende Port über TCP zugelassen wird.
Nun zu den Forwarding Rules. Wählen Sie im Menü "Network Services" den Punkt "Load Balancing" und starten Sie die Konfiguration für einen neuen TCP-Load-Balancer. Die Standardwerte "From Internet to my VMs", "Single region only" und "Target Pool or Target Instance" sind genau das, was wir brauchen.
Geben Sie Ihrem Load Balancer einen Namen und wählen Sie dann im Bereich "Backend configuration" Ihre vorhandene au-vm-Instanz aus.
Damit ist der Zielteil erledigt. Klicken Sie nun auf "Frontend configuration", um den "Listening"-Teil zu konfigurieren, und fügen Sie alle reservierten IPs hinzu.
Hier habe ich alle zuvor reservierten IPs hinzugefügt, damit sie auf Port 80 lauschen
Klicken Sie auf "Create" – fertig! Geben Sie dem Ganzen ein paar Minuten Zeit, dann kann Ihre VM ab sofort Traffic von allen drei oben genannten IPs annehmen. Falls es nicht klappt, prüfen Sie, ob die Firewall-Regeln die erforderlichen Ports zulassen.
Sie können Ihren Load Balancer jederzeit bearbeiten und IPs hinzufügen oder entfernen.
Prozesse auf Ihrer VM können sich sogar an die gewünschte Ziel-IP binden, obwohl diese Adresse auf keinem Linux-Netzwerkinterface konfiguriert zu sein scheint (laut ip address show). In diesem Beispiel funktioniert Folgendes:
nc -s 34.87.204.138 -l -p 80Das Geheimnis dahinter: GCP-Daemons laufen auf Ihrer Maschine und konfigurieren die Linux-Routen so, dass Pakete für die fraglichen Zieladressen akzeptiert werden:
me@au-vm:~$ ip route show table all...local 34.87.204.138 dev ens4 table local proto 66 scope hostlocal 34.87.228.28 dev ens4 table local proto 66 scope hostlocal 34.116.108.163 dev ens4 table local proto 66 scope host...Reden wir über Geld
Forwarding Rules funktionieren hervorragend und wirken wie die natürliche Antwort auf diese Aufgabe. Kostenlos sind sie allerdings nicht.
Google berechnet Ihnen eine Pauschale von 0,025 $/Stunde für die ersten fünf Regeln – Sie zahlen also dieselben 0,025 $/Stunde, egal ob Sie 1 oder 5 Regeln haben. Für jede weitere Forwarding Rule kommen 0,01 $/Stunde dazu. 10 IPs für eine VM einen ganzen Monat lang vorzuhalten, kostet Sie damit 55 $/Monat – nur für die Forwarding Rules.
Damit nicht genug. Vor nicht allzu langer Zeit hat GCP angefangen, auch externe IPs zu berechnen, sogar die genutzten (und zwar unabhängig davon, ob die IPs von VMs oder Forwarding Rules verwendet werden). Der Preis von 0,004 $/h pro IP wirkt vielleicht vernachlässigbar, summiert sich aber auf 0,004 $*730 h = 2,92 $/Monat – mal 10 IPs in unserem Fall ergibt das Gesamtkosten für 10 zur VM geroutete IPs von:
55 $ + 29,20 $ ≈ 85 $/Monat – nur für IPs, bevor wir die VM überhaupt bezahlen
Ob das nun teuer ist oder nicht, überlasse ich Ihrem Urteil :-)
Vielen Dank fürs Lesen! Bleiben Sie mit uns in Kontakt – folgen Sie uns im DoiT Engineering Blog, auf dem DoiT LinkedIn-Kanal und dem DoiT Twitter-Kanal. Karrieremöglichkeiten finden Sie unter https://careers.doit.com.