Der Storage-Controller ist der am meisten unterschätzte Flaschenhals im Server. Der Wechsel von einem acht Jahre alten MegaRAID mit 512 MB Cache auf einen PERC H755 oder Smart Array P816i-a mit 4 GB Write-Back-Cache kann den sequenziellen Durchsatz verdoppeln und die Random-IOPS vervierfachen. Bei virtualisierten Workloads ist der Unterschied fast immer spürbar.
SQL Server, PostgreSQL, MySQL auf einem PERC H730 mit 1 GB Cache, alle Workloads stauen sich zur Tagesmitte: der Umstieg auf H755 mit 4 GB Cache und Write-Back mit BBU senkt die Latenz häufig von mehreren Dutzend Millisekunden auf einstellige Werte.
Hardware-RAID soll erhalten bleiben, für Datenbanken und Logs wird aber NVMe-Performance gefordert. Lösung: tri-mode Controller (PERC H755N, Smart Array MR416i-p) mit kompatiblem backplane.
Die Migration auf software-defined storage setzt HBA passthrough voraus. Der vorhandene RAID-Controller muss durch einen reinen HBA ersetzt werden (PERC HBA350, Smart Array E208i-a), damit die Laufwerke einzeln durchgereicht werden.
Integrierte Enterprise-Controller (PERC bei Dell, integriertes Smart Array bei HPE, RAID 940 bei Lenovo) sind oft „vendor-locked“: der PERC H755 passt physisch in viele Server, ist offiziell aber nur für bestimmte Modelle freigegeben. Bei Supermicro gibt es mehr Spielraum (Broadcom MegaRAID als Standard). Wir prüfen vorab die HCL.
Ein neuer Controller kann eine andere SAS-Verkabelung erfordern (SAS3 vs. SAS4, mini-SAS HD vs. SlimSAS) sowie ein backplane mit tri-mode Fähigkeit (für NVMe). Bei Upgrades über Baureihen hinweg müssen häufig auch die Kabel und mitunter das backplane getauscht werden.
Write-Back-Controller arbeiten mit BBU (wiederaufladbarer Akku) oder Supercap (Kondensator). Eine BBU hält im Mittel 3-5 Jahre, ein Supercap deutlich länger. Beim vorhandenen Controller prüfen wir das Alter der BBU: ist sie nahe am Lebensende, nehmen wir den Tausch in den Einsatz mit auf.
Controller, Server-BIOS, Betriebssystem und Treiber müssen zueinander passen. Bei Dell steuert der Lifecycle Controller die Matrix, bei HPE das SPP (Service Pack for ProLiant). Das Update vor dem physischen Tausch ist Pflicht.
Beim Wechsel innerhalb derselben Familie (z. B. LSI auf LSI) wird die foreign config auf dem neuen Controller importiert, das Array wird erkannt und online genommen. Bei unterschiedlichen Familien (LSI auf HPE Smart Array) sind die On-Disk-Metadaten inkompatibel: das Array muss neu angelegt werden — Backup vorher zwingend.
Bei PERC erfordern einige erweiterte Funktionen (RAID 6, Write-Back-Cache, FastPath) ein license unlock. Bei HPE Smart Array gilt dasselbe (Lizenz über SPP). Wir prüfen, ob der Ziel-Controller die benötigten Funktionen freigeschaltet hat oder freischalten kann.
Snapshot des Controller-Zustands (RAID level, Laufwerksreihenfolge, strip size, cache policy, write policy, aktive Lizenzen). Komplettes Datenbackup oder konsistenter Snapshot. Kein Eingriff ohne verifiziertes Backup.
Update des Server-BIOS, Firmware-Vorbereitung des Ziel-Controllers, gegebenenfalls vorkonfiguriertes license unlock. Prüfung der erforderlichen SAS-Verkabelung (teils zu ersetzen), gegebenenfalls backplane-Upgrade für tri-mode.
Server heruntergefahren, vorhandenen Controller ausbauen, neuen einbauen, bei Bedarf neu verkabeln, BBU/Supercap positionieren, wieder anschließen.
Boot ins Controller-Setup, Prüfung der erkannten Laufwerke, Import der foreign config (bei kompatibler Familie). Cache-Einstellungen werden entsprechend der Ausgangskonfiguration wiederhergestellt. Start des Betriebssystems, Prüfung, dass das Array online ist.
I/O-Benchmark vorher/nachher (fio oder iometer), Prüfung auf SMART-Fehler der Laufwerke, schriftlich dokumentierte Performance-Baseline. Applikative Validierung mit dem Kunden vor der Übergabe.
Mittelständischer Kunde in der Provinz Monza, Server PowerEdge R740 mit SQL Server Standard, produktive ERP-Datenbank mit 1,2 TB, konstanter transaktionaler Traffic. Controller PERC H730 mit 1 GB Write-Back-Cache, 8 SAS-Laufwerke 10K à 1,8 TB im RAID 10. Latenzspitzen beim Schreiben während der Batch-Läufe (Tagesabschlüsse, Monatsendfakturierung): von 5 ms im Leerlauf auf 60-90 ms im Batch.
Diagnose: Controller-Cache beim Schreiben gesättigt. Der physische Storage (SAS 10K) kann mehr leisten, wenn der Controller nicht drosselt. Lösung: Upgrade auf PERC H755 mit 8 GB Cache, bei gleichen Laufwerken und unverändertem RAID 10. Identische LSI-basierte Familie: direkter foreign-config-Import.
Durchführung: Komplettbackup der SQL-Datenbank (full + log) vor dem Eingriff. Nachtfenster von 3 Stunden. Server heruntergefahren, Controller getauscht, PERC-Firmware aktualisiert, Boot, Import der foreign config (5 Minuten), Systemstart, SQL-Integritätsprüfung (DBCC CHECKDB), synthetischer Batch-Test, Rückgabe in die Produktion.
Ergebnis: Batch-Latenz unter 15 ms, sequenzieller Schreibdurchsatz +120 %. Kein Datenverlust. Der Kunde arbeitet unverändert auf denselben Laufwerken weiter.
Drei Szenarien: 1) Virtualisierter Workload mit hohem Random-I/O auf einem alten Controller mit kleinem Cache — der Umstieg auf 2-4 GB Write-Back-Cache bringt spürbaren Nutzen. 2) NVMe wird als geschütztes Ziel benötigt (RAID): der alte Controller unterstützt NVMe nicht über tri-mode, der neue schon. 3) Wechsel von HBA passthrough auf einen Controller mit BBU für Datenbank-Workloads, die write durability auch bei Stromausfall garantiert brauchen.
Ja, in vielen Fällen. Das Standardvorgehen: Snapshot der aktuellen Konfiguration (Laufwerksreihenfolge, RAID level, strip size, write policy), physischer Tausch des Controllers gegen ein kompatibles Modell, Import der foreign config auf dem neuen Controller. Sind die Modelle aus derselben Familie (z. B. PERC H730 → H755), verläuft das nahezu nahtlos. Zwischen unterschiedlichen Familien (LSI MegaRAID auf HPE Smart Array) sind die On-Disk-Metadaten nicht kompatibel: es braucht Backup + Neuanlage des Arrays.
Ein HBA (Host Bus Adapter) reicht die Laufwerke einzeln an das Betriebssystem durch: ideal für software-defined Lösungen (Storage Spaces Direct, vSAN, Ceph, ZFS), die Schutz und Cache auf OS-Ebene übernehmen. Ein RAID-Controller erledigt Schutz und Cache in Hardware und präsentiert dem OS virtuelle Volumes: ideal für klassische Server, deren OS diese Komplexität nicht verwalten soll. Die Wahl hängt vom Storage-Stack des Kunden ab.
Er erlaubt dem Controller, einen Write bereits als „abgeschlossen“ zu quittieren, sobald er im Cache liegt — auch wenn das Laufwerk noch hinterherhinkt. Das bringt einen enormen Schub bei der Schreibleistung. Fällt der Strom aus, halten BBU (Akku) oder Supercap (Kondensator) den Cache am Leben, bis er nach Rückkehr der Spannung auf die Laufwerke geschrieben wird. Ohne BBU/Supercap schaltet der Controller auf write-through und verliert deutlich an Leistung. Der Tausch einer defekten BBU/Supercap ist eine wiederkehrende Wartungsaufgabe, die wir übernehmen.
Eine hohe queue depth (256+ pro Port) erlaubt dem Controller, viele I/O-Kommandos in der Warteschlange zu halten, ohne zu sättigen. Bei moderner Virtualisierung mit Dutzenden VMs, die in Summe Tausende IOPS erzeugen, führt ein Controller mit niedriger queue depth (32-64) zu Staus, Latenz und gedeckeltem Durchsatz. Moderne Enterprise-Controller (PERC H755, Smart Array P816i-a, Broadcom 9560) sind für diese Dichten ausgelegt.
Ja, auf tri-mode Controllern der jüngsten Generation (PERC H755N/H965i, Smart Array MR416i-p, Broadcom 9560). Tri-mode erlaubt den Mischbetrieb von SAS, SATA und NVMe am selben Controller. Die NVMe-Performance über tri-mode erreicht kein direkt angebundenes NVMe über PCIe, bietet aber RAID-/Cache-Schutz bei weiterhin sehr hohen IOPS — der sweet spot für viele Mid-Market-Workloads.
Schicken Sie uns Hersteller, Modell (Service Tag / Seriennummer / part number der motherboard) und den Ziel-Workload. Innerhalb eines Arbeitstages erhalten Sie eine Antwort zur technischen Machbarkeit, zu den erkannten Randbedingungen und eine ehrliche Einschätzung.