86 0 0

gPXE – eine clevere Alternative

vom gridscale Team Networking

Um was geht’s?

Vor ein paar Tagen wurde ich gefragt, ob gridscale PXE unterstützt. Die Antwort war ja. Was viele Anbieter unterbinden, ist bei gridscale erlaubt. So kann zum Beispiel mit Hilfe der Konsole im Browser zu jedem Zeitpunkt in den Bootvorgang eingegriffen werden – es kann sogar das BIOS aufgerufen werden 🙂

Spielerei, ich weiß. Worum es bei der Frage nach PXE ging war allerdings alles andere als Spielerei. Es soll eine vollständig automatisierte Umgebung entstehen. Konfiguriert werden alle Bestandteile an zentraler Stelle.

Nachdem wir ein wenig über den Usecase diskutiert haben, fanden wir irgendwie einen Standard Legacy-PXE doof und wollten etwas „cooleres“ haben. Für meine Ein-Platinen-Computer nutze ich ein ROM, dass sich beim Neustart immer das neuste OS-Image von meinem Webserver zieht und damit bootet. Dieses Prinzip haben wir seinerzeit schon auf gridscale angewandt, wenn es also unter unserer Cloud funktioniert, warum sollte es dann nicht auch in unserer Cloud funktionieren?

Was dich erwartet

Die Zutaten: Ein DHCP Server. Ein Webserver. Ein internes Netzwerk. Ein paar Cloud Server ohne Festplatten. Und ein wenig Open-Source Software.

Das Ergebnis: Ein einfach skalierbares und vor allen Dingen automatisch konfigurierendes Cloud Server Setup. Bestens geeignet um extrem schnell zu starten, Aufgaben zu erledigen und dann wieder zu stoppen. Skaliert garantiert schneller als alles was Du kennst.

Vorbereitung

Installation eines DHCP Servers

Erstelle ein privates Netzwerk für deine Server und installiere dir eine DHCP Maschine in diesem Netzwerk. Der DHCP Server hat zusätzlich einen Link ins Internet (praktische Gründe, keine Notwendigkeit).

Ich verwende meist den ISC DHCP. Eine Standardsoftware über die ich mir noch keine Gedanken gemacht habe. Wenn du bessere DHCP Server kennst, freue ich mich über einen Tipp.

Also:

 apt-get install isc-dhcp-server

In ‚/etc/dhcp/dhcpd.conf‘ liegt die Konfiguration für den DHCP Server. Dort konfigurierst du den DHCP jetzt so, dass er am internen Netzwerkinterface lauscht (eth1) und IP-Adressen für anfragende Clients verteilt. Dazu kannst du folgendes Subnetz deklarieren:

subnet 172.16.10.0 netmask 255.255.255.0 {
    range 172.16.10.50 172.16.10.100;
    option broadcast-address 172.16.10.255;
}

Damit der DHCP Server startet, muss er das richtige Netzwerkinterface identifizieren können. Diese Konfiguration kannst du in der Datei ‚/etc/default/isc-dhcp-server‘ vornehmen. Trag am Ende einfach das Interface eth1 ein.

Nun muss das Interface eth1 auch noch konfiguriert werden. Dazu editiere die Datei ‚/etc/network/interfaces‘ und ergänze am Ende folgendes:

auto eth1
iface eth1 inet static
    address 172.16.10.1
    netmask 255.255.255.0
    broadcast 172.16.10.255

Fahre das Interface eth1 nun hoch (bspw. über ‚/etc/init.d/networking restart‘) und starte anschließend den DHCP Server neu (mit ‚/etc/init.d/isc-dhcp-server restart‘).

Auslieferung von Boot-Images

Damit du ein Boot-Image pushen kannst, wird noch ein Service zur Auslieferung des Images benötigt. Früher griff man meist zu einem TFTP (z.B. tftpd-hpa) und verwendete Clientseitig normales PXE. Das war für meinen Geschmack aber immer etwas fummelig.

gPXE hat den großen Vorteil (ähnlich wie auch neuere UEFI-BIOS’e), dass ein Bootimage nun nicht mehr per tftp bereitgestellt werden muss. Stattdessen stehen höhere Protokolle wie bspw. FTP und HTTP zur Verfügung. Über einen Webserver und eine entsprechende „Asset-Verwaltung“ ist es dann ohne Probleme möglich, die Infrastruktur komplett fernzusteuern. Damit will ich nicht sagen, dass so etwas mit der Legacy-Methode nicht geht. Ganz im Gegenteil, so etwas haben wir auch schon im großen Stil gebaut. Aber es ist und bleibt einfach fummelig 🙂

Kurzer Ausflug – eine praktische Anwendung

Für große und verteilte Infrastrukturen wie gridscale ist ein solches Setup unheimlich praktisch. Wir stellen in unserer Infrastruktur signierte Boot-Images bereit. Für verschiedene Anwendungsfälle gibt es unterschiedliche Images: Management, Monitoring, Burn-In, Production, Development, Staging und kundeneigene Umgebungen. Je nachdem welche Rolle einem Server zugewiesen ist, wird das jeweils richtige Image ausgespielt.

Ein gezieltes Update eines Rechenknoten besteht z.B. nur aus zwei Schritten:

  • „Evakuieren“ des Hosts: Es dauert zwischen drei und zehn Sekunden, bis alle virtuellen Instanzen innerhalb von gridscale auf andere Hosts verschoben sind
  • Reboot des Hosts: Wir rebooten das System. Beim Boot wird dann automatisch das neuste Boot-Image geladen.

In den meisten Fällen ist aber auch das nicht notwendig. 🙂 Um Energie zu sparen, schalten wir unsere Rechenknoten aus wenn sie nicht gebraucht werden. Beim Reaktivieren steht ein Rechenknoten dann sowieso mit dem aktuellsten Boot-Image bereit.

Webserver installieren

Am einfachsten ist es, ein Image per HTTP auszuliefern. Damit hast du dann ein funktionierendes Setup und kannst weiter testen. ‚apt-get install nginx‘ erledigt alles, was für den Moment gebraucht wird. Standardmäßig läuft nginx dann auf Port 80 und hat in ‚/var/www/html/‘ sein DocRoot.

Was du jetzt zum testen brauchst sind zwei Dateien. Eine ramdisk, aus der du z.B. eine ISO starten kannst und eine ISO die du laden möchtest. Leg beides in das DocRoot des Webservers ab.

Als ISO lade dir z.B. die Netinstall von Debian herunter. Wenn du keine Lust hast eine eigene ramdisk zu erstellen, kannst du erstmal diese hier nehmen.

gPXE Loader bauen und Cloud-Server starten

Sofern du keine fertigen Images verwenden möchtest, kann ich dir rom-O-matic empfehlen. Unter Anderem wird dir da ein Rom-Builder für gPXE angeboten. Mit dem Rom-Builder kannst du z.B. direkt ein wenig Script in den Loader einbauen, s.d. sich dein System noch weiter automatisieren lässt.

Eine ganz einfache Variante sieht bspw. so aus:

#!gpxe
dhcp any
kernel http://172.16.10.1/memdisk
initrd http://172.16.10.1/debian.iso
boot

Anhand der IP siehst du schnell, dass alles sehr statisch ist. Es dient auch eher zur Veranschaulichung. Lade dir dein ROM herunter und lege es auch in das DocRoot deines Webservers. Bei mir liegt es direkt in ‚/gpxe.iso‘. Nun eine kleine Besonderheit von gridscale: Wir brauchen das gpxe.iso als CD-Laufwerk für deinen Cloud Server. Daher nutze einfach die Smart-ISO Funktion von gridscale. Trage dazu einfach die URL deines Webservers ein, unter der das erstellte Image heruntergeladen werden kann.

Smart ISO gPXE

Solltest du beim Download einen Fehler erhalten, überprüfe die Größe des ISO-Files. Wenn es kleiner als 1 MB ist, lehnen wir es ab. Im Zweifel häng einfach 10 MB aus /dev/zero an das ISO dran.

gPXE Cloud ServerDie Konfiguration im Panel kannst du dem Screenshot entnehmen. Du siehst zum Beispiel, dass der Cloud Server „gpxe 2“ nur mit dem internen Netzwerk „pxe internal network“ verbunden ist, keinen Storage angehangen hat und das zuvor erstellte ISO-Image „gpxe.iso“ in das virtuelle CD-Laufwerk des Servers eingelegt ist.

Wenn du nun den Server startest, kannst du direkt die Konsole öffnen und dem Bootvorgang zusehen. Als erstes erscheint das ISO Boot-Menü für das angebundene ISO-Image. Nach einem kurzen Augenblick startet der Cloud Server von diesem ISO-Image und lädt den von dir angegebenen Inhalt nach. Das ins CDROM-Laufwerk des Servers eingelegte ISO-Image enthält den gPXE, der mit den vier Zeilen Script-Code erweitert worden ist (siehe oben). Als Anweisung ist hinterlegt:

  • Hole dir via DHCP eine IP-Adresse (das any steht in dem Fall für alle verfügbare interfaces – es bietet sich an das zu optimieren)
  • Lade einen Kernel von http://172.16.10.1/memdisk (die Ramdisk)
  • Lade eine initrd von http://172.16.10.1/debian.iso (die Debian Netinstall ISO)
  • boote den Cloud Server

Wenn alles funktioniert, müsste deine Konsole jetzt wie folgt aussehen:

Console gPXE Cloud Server

Nach erfolgreichem Laden wirst du dann auch belohnt mit dem folgenden Bild 🙂Nach erfolgreichem Laden wirst du dann auch belohnt mit dem folgenden Bild

Glückwunsch, damit hast du ein funktionierendes Cloud Setup, das dir als Grundlage dienen kann um stark automatisierte Workloads zu skalieren.

Eine Randnotiz noch, die vielleicht einmal für dich wichtig werden kann. Unsere Infrastruktur merkt, wenn du einen Cloud Server ausschalten möchtest. Du bist also nicht wie bei anderen Anbietern gezwungen, einen API-Call abzusetzen, um einen Cloud Server auszuschalten. Sobald du uns einen PowerOff via ACPI schickst, terminieren wir deinen Prozess und schicken das zugehörige Billing-Stop-Event. Warum erwähne ich das… stell dir folgenden möglichen Workflow in deiner Infrastruktur vor:

  • Deine Anwendung erstellt einen „Rechenjob“ der an eine Worker-Node vergeben werden soll
  • Deine Anwendung startet über unsere API eine diskless Worker-Nodes mit einem gPXE
  • Die Worker-Node meldet sich nach Bootvorgang in der Zentrale und holt sich den „Rechenjob“ ab
  • Nach erfolgreicher Berechnung schickt die Worker-Node das Ergebnis zurück
  • Die Worker-Node fährt sich wieder herunter, um keine weiteren Kosten zu produzieren

So ein Setup nutzt dann die geballte Power von gridscale und arbeitet zugleich maximal kosteneffizient.

Schade, dass dir der Artikel nicht gefallen hat.
Was sollten wir deiner Meinung nach besser machen?

Vielen Dank für dein Feedback!
Wir melden uns bei dir, sobald der Artikel zu deinem Wunschthema fertig ist.

Übrigens: kennst du schon unser Tutorial zum Thema HAProxy mit SSL von Let's Encrypt?

×

Entwickler?

Melde dich bei unserem Newletter an, um regelmäßig über die neuesten Tutorials informiert zu werden.
Wir spammen nicht!