Nach Hersteller
Dell PowerEdge HPE ProLiant Lenovo ThinkSystem Fujitsu Primergy Supermicro IBM System x / Power Acer AltosEinsatz & Alleinstellungsmerkmale
Rechenzentren Lombardei Aruba Ponte San Pietro Jenseits des HerstellersupportsOS-Stabilität: Treiber, Kernel und Firmware auf eine Linie bringen.
Scheinbar zufällige Abstürze, sporadische Kernel Panics, Hypervisor, die VMs ohne erkennbaren Grund killen: Häufig ist das Symptom hardwarenah, die eigentliche Ursache liegt aber im Mismatch zwischen Hersteller-Firmware, Treibern des Betriebssystems, Power-Management-Konfiguration und realem Workload. Die systemische Diagnose ist unser Handwerk — noch vor dem Austausch von Hardware.
Wiederkehrende Instabilitätsmuster.
- Windows-BSOD wiederkehrend mit konstantem Stop Code (z. B.
DPC_WATCHDOG_VIOLATION,SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) — meist ein Netzwerk- oder Storage-Treiber, der nicht zur Firmware passt. - Linux Kernel Panic mit Stack Trace, der immer auf denselben Treiber zeigt — der In-Tree-Treiber muss aktualisiert oder durch den Hersteller-Treiber ersetzt werden.
- ESXi PSOD (Purple Screen of Death) mit Verweis auf Netzwerk-, Storage- oder RAID-Treiber — Abgleich der Kompatibilitätsmatrix VMware/Hersteller.
- VM killed by hypervisor ohne Fault des Knotens: oft aggressives Power Management, das CPU/Cache während I/O-Latenzen in den Deep Sleep schickt.
Diagnose, bevor Hardware angefasst wird.
- Abgleich Firmware ↔ Treiber: Kompatibilitätsmatrix des Herstellers, RAID-Controller, NIC, HBA, BMC.
- Power-Management-Konfiguration: im BIOS (C-States, P-States, Turbo) und im Betriebssystem. Transaktionale Server brauchen die Power Policy „Performance“; bei überwiegend im Leerlauf laufenden Servern kann das Gegenteil sinnvoll sein.
- Prüfung der Zertifizierungen: VMware HCL, Microsoft WHQL, Red Hat HCL für die Kombinationen, die der Kunde tatsächlich einsetzt.
- Analyse von Crash Dumps (Windows) oder Kernel-Logs (Linux), um die exakt ausfallende Komponente zu identifizieren.
Die Fragen, die uns am häufigsten gestellt werden.
Bei Servern mit Softwareproblemen: übernehmen Sie das oder ist AssistenzaServer.eu zuständig?
Das hängt von der Root Cause ab. Zeigt die Diagnose, dass das Symptom hardwarenah ist (nicht abgestimmter Hersteller-Treiber, zu aktualisierende Firmware, Power Management im BIOS), übernehmen wir: Diese Grenzzone zwischen Hardware und Software ist genau unser Feld. Liegt die Ursache rein in der Systemadministration (Applikationskonfiguration, OS-Patches, Software-Networking, Security), ist die Schwesterseite AssistenzaServer.eu der richtige Ansprechpartner.
Löst ein Treiber-Update immer das Problem?
Nein, in manchen Fällen haben gerade die neuesten Treiber Bugs — vor allem bei EOL-Hardware, bei der der Hersteller die älteren Kombinationen nicht mehr testet. Auf diesen Systemen ist die stabile, zertifizierte Version häufig N-1 oder N-2 gegenüber dem Latest. Wir prüfen die Herstellermatrix im Einzelfall.
Windows Crash Dump oder Linux Kernel-Log: fordern Sie die immer an?
Ja, sie sind die wichtigste Grundlage für die Diagnose. Unter Windows: Minidump in C:\Windows\Minidump (standardmäßig konfiguriert). Unter Linux: /var/log/kern.log, journalctl -k, gegebenenfalls kdump-Crashes in /var/crash. Unter ESXi: vmkernel.log, vm-support-Bundle. Ohne diese Daten ist die Diagnose langsamer und ungenauer.