Wie funktioniert eine Rescue Console?

[federschuh]

Hi,
bei den meisten Providern kann man ja über eine RescueConsole auf den dedizierten Server gelangen. In der Praxis läuft es ja so ab, dass das OS der Maschine runtergefahren wird, und die Maschine neu gestartet wird und die Kontrolle nach dem Neustart an das RescueSystem übergeben wird. Man muss sich an der RescueConsole einloggen (mit temp. Credentials, ssh usw), wonach man dann die Platte des des Rechners ins RescueSystem mounten kann...

Ich frage mich wie das technisch denn realisiert ist.
Da muss doch ein entspr. Zusatz(-karte?) am Rechner eingebaut sein, oder?

Kann man den heimischen Rechner auch so ausstatten? Kosta Quanta?, ProduktLinks?

 

[Lord Gurke]

Es gibt mindestens vier verschiedene Möglichkeiten, einen nicht mehr funktionierenden Server aus der Ferne zu bedienen - alle unterschiedlich effektiv und teuer...

1)
Das Rescue-Betriebssystem über Netboot:
Der Server bootet standardmäßig übers Netzwerk und bekommt (wenn du es eingestellt hast) vom zentralen DHCP-Server ein Boot-Image angeboten, welches das Rescue-Betriebssystem beinhaltet.
Anstatt wie sonst üblich von der Festplatte zu starten, bootet der Server nun übers Netzwerk und lädt das Rettungssystem, welches meist per Kernelparameter oder Webrequest beim Starten ein Root-Passwort setzt, welches dir angezeigt wird.
Vermutlich ist das jenes Verfahren welches du beschreibst und auch am günstigsten umzusetzen ist, denn du brauchst keine zusätzliche spezielle Hardware (unter der Prämisse, dass du einen DHCP- und TFTP-Server im Netzwerk hast).
Um einen ausgeschalteten Server wieder zu starten gibt es dann auch einige Möglichkeiten:
Entweder das profane "Wake on LAN", wo du einfach ein Wakeup-Paket an die MAC-Adresse der Netzwerkkarte schickst, die dann den Rechner einschaltet.

Als "zweinull-Feature":
Eine PDU, die für ein paar Sekunden den Strom aus- und wieder einschaltet. I.d.R. sind die Server so konfiguriert, dass sie sofort einschalten, sobald Strom da ist, womit du dann damit wirklich jeden Server wieder hochgefahren bekommst.
Hetzner benutzt meines Wissens die Telejet Webresetter, damit kannst du dann aus der Ferne sogar über den PS/2-Port die STRG+ALT+ENTF-Sequenz schicken oder den Reset-Knopf betätigen.

2)
Die serielle Konsole:
Hilft dir weiter, wenn du über das Netzwerk nicht mehr auf den Server zugreifen kannst. Dazu benötigst du ein serielles Kabel ("Nullmodemkabel") welches am Server angeschlossen wird und eine kleine zweite Maschine, an der du das andere Ende anschließt.
Mit ein paar Kernelparametern kannst du Linux und inzwischen auch Windows mitteilen, dass es doch bitte an der seriellen Konsole ein Terminal bereitstellt, über das du wie über SSH/Telnet arbeiten kannst.

3)
Der IP-KVM:
Ein kleines Kästchen, welches Anschlüsse für Monitor, Tastatur, Maus und Netzwerk hat.
Du verbindest den KVM über normale Standardkabel mit dem Server und kannst über die IP-Adresse des IP-KVM auf die Maschine zugreifen, als wenn du direkt mit Monitor und Tastatur davorsitzt. Klingt spannend, hat aber leider auch einen spannenden Preis...

4)
Die IPMI-Karte:
Du steckst eine IPMI-Karte in den Server (unterstützt nicht jede Hardware). Diese Karte hat eine eigene Netzwerkschnittstelle und funktioniert unabhängig von der Hardware in der sie verbaut ist - natürlich nur solange sie irgendwie Strom bekommt.
Übers Netzwerk kannst du auf diese Karte zugreifen und alles mit dem Server anstellen, was du willst.
Per VNC bekommst du die Ausgabe der Grafikkarte zu dir umgeleitet, kannst natürlich darüber auch Tastatur und Maus bedienen, CD-Images hochladen (und damit aus hunderten Kilometern Entfernung eine Installations-CD "einlegen"), kannst auf Reset drücken oder den Power-Button betätigen etc...
Solange die Hardware des Servers nicht explodiert ist, kannst du ihn irgendwie noch fernsteuern.
Leider passen die Karten nicht in jedes Mainboard resp. unterstützen nicht jedes BIOS - meistens nur die Servermainboards...

 

[Mr.Check]

Sehr gute Übersicht Lord Gurke, ich denke damit ist ein nützlicher Überblick für jeden Interessierten geschaffen

Eine sinnvolle Ergänzung ist vielleicht noch der Hinweis, dass z.B. bei einigen SuperMicro-Mainboards ein solches IPMI-Interface bereits integriert ist. Die IP-Adresse dieses Interfaces wird einmalig im BIOS konfiguriert und schon hat man die selbe Funktionalität wie bei einer IPMI-Karte. Der Server lässt sich hierüber ein- und ausschalten, via Konsole fernsteuern, wichtige Parameter (Lüfterzustand, Temperatur etc.) lassen sich darin überwachen und nicht zuletzt kann man auch hier eine ISO-Datei, die sich z.B. auf dem heimischen PC befindet, in seinen Server im RZ "einlegen" und ein neues OS installieren. Bei einer Neuanschaffung eines Servers macht es also ggf. Sinn, auf Mainboards mit IPMI-Funktionalität zu setzen.

 

[federschuh]

Hi Lord Gurke
vielen Dank für die ausführlichen Infos.

Wenn man selber 2+ Dedicated Server bei einem Provider mietet,
dann müsste man doch so eine NetBoot-Lösung selber einrichten können
um eine eigene RescueConsole für die eigenen MietServer zu realisieren, oder?

Hmmm. der Netboot-Server könnte doch theoretisch eigentlich überall stehen, oder?
Denn TFTP benutzt doch das TCP-Protokoll, ohne Broadcast-Zeugs, oder?

 

[Mr.Check]

Hmmm. der Netboot-Server könnte doch theoretisch eigentlich überall stehen, oder?
Denn TFTP benutzt doch das TCP-Protokoll, ohne Broadcast-Zeugs, oder?

So einfach geht das leider nicht.

Wie Lord Gurke schon sagte, wird das Boot-Image (oder die Fundstelle des Boot-Images) vom DHCP-Server bereitgestellt - und dieser muss natürlich im gleichen Netz sein wie der Server, da er mittels Broadcast angesprochen wird.


Übrigens benutzt TFTP das UDP-Protokoll, aber darum gehts ja nicht

 

[Lord Gurke]

Wenn man selber 2+ Dedicated Server bei einem Provider mietet,
dann müsste man doch so eine NetBoot-Lösung selber einrichten können
um eine eigene RescueConsole für die eigenen MietServer zu realisieren, oder?

Wenn der Provider sein Netzwerk im Griff hat, funktioniert das nicht
Was meinst du was da los wäre, wenn jeder seinen eigenen DHCP-Server betreiben würde...
Ohne Sonderlösung für dich dürften DHCP-Antworten am Switchport direkt verworfen werden.

Hmmm. der Netboot-Server könnte doch theoretisch eigentlich überall stehen, oder?
Denn TFTP benutzt doch das TCP-Protokoll, ohne Broadcast-Zeugs, oder?

TFTP benutzt normalerweise Unicast-UDP, also kann der Server irgendwo stehen.
In der DHCP-Antwort wird direkt die IP-Adresse des TFTP-Servers und ein Dateiname mitgegeben und solange der Client ins Internet kann, darf der Server stehen wo er will.


EDIT: Mist, nur Sekunden zu langsam

 

[federschuh]

Wenn der Provider sein Netzwerk im Griff hat, funktioniert das nicht
Was meinst du was da los wäre, wenn jeder seinen eigenen DHCP-Server betreiben würde...
Ohne Sonderlösung für dich dürften DHCP-Antworten am Switchport direkt verworfen werden.

TFTP benutzt normalerweise Unicast-UDP, also kann der Server irgendwo stehen.
In der DHCP-Antwort wird direkt die IP-Adresse des TFTP-Servers und ein Dateiname mitgegeben und solange der Client ins Internet kann, darf der Server stehen wo er will.

Ich hab mal eben im Web etwas danach geguckt, z.B. hier:
http://wiki.debian.org/DebianInstaller/BootpTFTP
D.h. in der DHCP-Konfiguration kann man die Einträge auch individuell setzen.
D.h. wenn der Hoster für den Kunden individuelle Einträge in seine DHCP-Konfig erlaubt für den Netboot, dann könnte der Kunde seinen (irgendwo stehenden) TFTP-Server benutzen zum booten...
Die Hoster sollten diesen (neuen Service auch anbieten... ist bestimmt 'ne Marktlücke...

 

[Mr.Check]

Die Hoster sollten diesen (neuen Service auch anbieten... ist bestimmt 'ne Marktlücke...

Naja, letztendlich hast du ja drei Szenarien, die abgedeckt werden können/sollten:

1. Firewall falsch konfiguriert bzw. sonstiger Fehler in der Netzwerk-Konfiguration: Hier hilft dir am besten das IPMI-Interface bzw. KVM over IP, da du hiermit sehr einfach direkt über der Konsole deine Konfiguration anpassen kannst. Wenn z.B. versehentlich nur SSH gesperrt wurde, ist das sicherlich eleganter als das komplette System im Rescue-Modus zu booten.

2. Systemfehler, der das System evtl. nicht mehr booten lässt: Dafür stellen einige Provider fertige Rescue-Systeme zur Verfügung, die i.d.R. über NetBoot gestartet werden. Alternativ könntest du mit einem IPMI-Interface deine eigene LiveCD starten.

3. Neuinstallation des System: Hierfür stellen die meisten Provider fertige Images zur Verfügung, womit sich die gängigsten Systeme mit wenigen Klicks installieren lassen. Auch hier würde IPMI helfen, indem man einfach ein Image seiner Wahl bootet.

Meine Meinung dazu: IPMI ist die eierlegende Wollmilchsau für alles, was du für Installation / Fehlerbehebung an deinem Server brauchst. Wer es einmal hatte, will bestimmt nicht mehr darauf verzichten. Bei HostEurope z.B. hat das jeder Root-Server serienmäßig dabei.

Welchen Vorteil würde denn ein individuelles NetBoot-System bringen? Sowohl der Rescue-Modus als auch die Installation der meisten Systeme wird doch angeboten von den meisten größeren Providern.

 

[Firewire2002]

Die Hoster sollten diesen (neuen Service auch anbieten... ist bestimmt 'ne Marktlücke...

Ich würde mal vermuten, die Leute die sowas brauchen lassen sich an einer Hand abzählen. Einfacher wäre es, das Image das gebootet werden soll dem Hoster zur Verfügung zu stellen oder dem Hoster einfach zu sagen, was man für Sonderwünsche hat.
Bei kleineren Hostern sind da durch aus Individualisierungen möglich. Bei größeren Massenhostern solltest du ein paar mehr Kunden animieren, dass gleiche zu fordern. Ansonsten lohnt es sich für diese Hoster nicht, das zu implementieren.

 

[Lord Gurke]

@Mr. Check:
Der einzige gute Grund ein eigenes Netboot-Image zu benötigen wäre, wenn man ein Betriebssystem installieren will, welches der Hoster nicht anbietet.
Und da kann man sich gut behelfen, wenn der Provider einen IP-KVM zur Verfügung stellt, ein DVD-Laufwerk anschließt, das ISO vom Kunden brennt und einlegt.
Der Kunde installiert ja nicht täglich das Betriebssystem neu (und falls doch sollte man sich fragen, ob ein Server wirklich das Richtige für den Kunden ist), von daher ist das vermutlich deutlich weniger Aufwand, das so manuell auf Anfrage zu handhaben.

 

[Mr.Check]

Ja ich denke auch, dass es für diesen speziellen Fall andere Lösungen gibt, die nicht zuletzt für den Provider einfacher sind, als einen DHCP-Dienst für jeden Kunden individuell zu konfigurieren

Und der Regel braucht der Kunde ja dieses (spezielle) Betriebssystem von Anfang an, also wird er sich ja gar nicht erst einen Server bei einem Provider mieten, der weder IPMI im Server hat noch das gewünschte OS als Image zur Verfügung stellt.