Die Ausgaben eines Teils meines Sensorparks wird live im Internet bereitgestellt. Die Technik dahinter besteht aus einem Intel Skull, auf dem in einer VM eine „timebased“ Datenbank (Influx) und die Visualisierungssoftware Grafana laufen.

Ich möchte mit diesem Beitrag einmal etwas mehr den technischen Hintergrund beschreiben (quasi einen Blick ins „Backoffice“), aber auch darstellen, was für Probleme ich beim aktuell anstehenden Hardware-Update der Host-Maschine hatte: 

Die Hardware-Basis: Intel Skull

Die Datenbank und die Visualisierung laufen gemeinsam auf einer virtuelle Maschine (VM) unter dem VMware Hypervisor  ESXi 6.5. Die ESXi – Hardware ist ein „Intel Skull modula„, mit 8 GB RAM und 256GB + 512GB SSDs, was zusammen für meine Anwendungszwecke mehr als ausreichend Power zur Verfügung stellt, so dass ich damit auch mehr als nur eine VM betreiben kann.

Dabei ist das ESXi 6.5 auf einem 16 GB USB 2.0 -Stick installiert, um den gesamten SSD-Plattenplatz als Datastore zur Verfügung zu haben.

Die eingesetzte SSD (Intel, mitgeliefertes Produkt, im unten stehend Bild zu sehen)

zeigte jedoch von Anfang an ein etwas merkwürdiges Verhalten: Die Datenübertragungsrate brach bei intensiveren Dateioperationen (Massenkopien, Verschieben von VMs) nach kurzer Zeit (20-60sec)  dramatisch zusammen, die vom ESXi angezeigte Zugriffs-Latenz der SSD erreichte teilweise Werte > 1000ms (!), normal sind Werte < 1ms.

Als Ursache vermute ich eine zeitweise Überhitzung der SSD, so dass der SSD-Controller den Transfer abbremst (Die SSD, ein m.2 NVME-Type) ist in dem flachen Gehäuse nicht extra gekühlt und liegt ansonsten auch nur im mehr oder eher weniger existierende Kühlluftstrom (Ansaugseite) des (im Bild rechts liegenden) CPU-Lüfters.

Der Plan

Die SSD sollte also ausgetauscht werden (anderes Modell), der Speicher von 8 GB auf 16 GB erweitert und der Hypervisor von ESXi 6.5.0 auf ESXi 6.5.0a aktualisiert werden.

Gleichzeitig wollte ich von dem USB-Stick weg: Es ist zwar ganz witzig, den Hypervisor auf einem USB-Stick zu haben, ich hatte jedoch den Eindruck, dass es manchmal doch ein kleines Performanceproblem mit dem langsamen (USB 2.0) Stick gab.

1. Panne: falscher RAM-Typ

Ich hatte zwei SO-DIMM DDR3 – RAM -Module (als Pärchen á 8 GB) gekauft und musste dann beim versuchte Einbau feststellen, dass es immer besser ist, _vorher_ in die technische Spezifikationen zu sehen (Ja, ich schreibe dass bewusst, damit ihr auch mal sehen könnt, dass anderen auch Fehler unterlaufen…).

Der Intel Skull benötigt SO-DIMM DDR4 RAM-Module…(!), nun denn, die RAM-Aufrüstung ist damit zunächst beerdigt…

Plattenumbau

Der Umbau der Platte lief ohne Probleme. Zu beachten ist, dass die eingesetzte/neue SSD eine m.2 SSD vom Type M ist (das ist eine Kodierung des Kontaktkamms (rechts im Bild), speziell die Lage der Einkerbungen).

Diese Type M – SSDs sind sog. NVME SSDs, welche nur in Boards laufen, die einen entsprechenden Controller besitzen, welcher dieses Protokoll unterstützt.

Das Betriebssystem – BIOS sollte diese Festplattenschnittstelle und das Protokoll ebenfalls unterstützen (Da der Intel SKULL von Haus aus ebenfalls mit einer NVME -SSD ausgeliefert wird, ist das gegeben…)

BIOS-Update

Nach einem Blick auf die Treiber und Update – Seite zum Intel SKULL habe ich das aktuellste BIOS als Binary KY0046.BIO) herunter geladen und auf einen USB-Stick kopiert. Das Update kann damit direkt aus dem aufgerufenen Bios (Taste F2 beim booten drücken) ausgewählt und eingespielt werden.

2. Panne: Installation ESXi 6.5.0a auf die neu eingebaute SSD

Für die Installation habe ich das heruntergeladene ISO-File (MD5-Checksumme geprüft (!)) auf eine DVD-RAM gebrannt und mit dem CD-Laufwerk direkt an den Intel Skull angeschlossen. Die Boot-Optionen sind so eingestellt, dass primär von einem angeschlossenen USB-Laufwerk gebootet wird (wenn vorhanden).

Die Installation des ESXi 6.5.0a auf die frisch eingebaute SSD (Samsung 960 EVO MZ-V6E250BW) verlief auch zunächst ohne Probleme, das USB-Bootmedium wird automatisch nach der Installation ausgeworfen, der Reboot muss manuell angestoßen werden:

Beim Booten kam ein Fehler, dass eine bestimmte MD5-Prüfsummendatei nicht verfügbare wäre
(hab leider kein Bild davon).
Nach einigem herumprobieren ging es (scheinbar) plötzlich doch: Ich hatte mal versucht, auf die eben installierte Installation das gleiche Image als Update zu installieren – danach lief der Boot-Prozess komplett durch.

Allerdings war keine Anmeldung möglich: Das zuvor eingegebene Passwort für den User root wurde als ungültig abgewiesen (ja, ich habe auch berücksichtigt, dass es verschiedenen Tastenlayouts gibt und nur (neutrale) Buchstaben verwendet („asdfghjk“) ).

Letztlich half nur, den Hypervisor (ESXi) erneut auf einen USB-Stick zu installieren, was problemlos gelang.

Unklar ist mir, worin die Ursache des Problems liegt. Wenn ich dem Fehler auf die Spur gekommen bin, werde ich das hier ggf. ausführen.

Finale

Das System ist wieder „oben“ und die zuvor gesicherten VMs wieder zurückgeschoben und hochgefahren:

und auch die Datenvisualisierung läuft wieder (und ist seit heute wieder online geschaltet…) :

Wenn ihr nix verpassen wollt, abonniert einfach den Beitrags-Feed: Einfach in einen Feed-Reader eure Wahl einbinden oder in euren Mailer (sofern der das kann: Ich verwende Thunderbird bzw. den Liferea Feedreader und da geht das sehr geschmeidig).