Für manchen etwas gewöhnungsbedürftig gestaltet sich ja das Desaster Recovery von Compute Nodes bei Triton. Denn hier bildet quasi das ZFS die letzte Verteidigungslinie - solange alle Platten intakt sind, sollte man den Compute Node in einem anderen Chassis oder nach einem Tausch des Motherboards einfach wieder in Betrieb nehmen können. (Nicht nur) deshalb sollte in so einem Setup auf proprietäre RAID-Controller verzichtet werden. Die könnten z. B. Probleme bei der Plattenerkennung machen.
Gerade kürzlich war bei einem Compute Node das Motherboard ausgefallen - und tatsächlich hat die obige Anleitung
- betroffenen Compute Node im Admin-Portal oder über CNAPI löschen
- (Reparierten) Compute Node booten
- ggfs. erzeugen der
manta0VNIC mit Hilfe der Manta Network Configuration (ist idempotent und kann deshalb mehrfach laufen) - ggfs. setzen des "external" NIC-Tag
gut funktioniert. Der "neue" Compute Node taucht in der Serverliste jetzt mit seinem synthetisch (auf Basis der MAC-Adresse) generierten Namen auf. Leider war mir aber keine Möglichkeit bekannt, den alten Alias-Namen des Compute Nodes wieder zu setzen (das ist eigentlich nur per sdcadm server setup möglich - das kann aber nur für eine Neuinstallation benutzt werden). Auf sdc-discuss wurde aber noch eine andere Möglichkeit gezeigt:
# Login to the moray instance on your headnode
# get the moray instance up
MORAY_IP=$(ifconfig net0 | grep inet | awk '{print $2}')
# use the updatemany command to set it directly in moray
updatemany -h "$MORAY_IP" -d '{ "hostname": "YOURNEWHOSTNAMEHERE" }' cnapi_servers "(uuid=SERVERUUIDHERE)"
Danach ist noch ein Reboot des Compute Nodes fällig, damit dieser den neuen Namen auch an der Konsole anzeigt (da der Name als dhcp-Parameter mitgegeben wird).
updatemany gehört zu den Moray Client Tools, die dazu dienen, mit diesem "json-based key-value store" zu interagieren.