Ausgangslage: Wir haben einen älteren HP ML-350 Gen. 9-Server den wir gerne als Ersatz-Server konfigurieren würden.
Nun ist es so, dass für diesen aber sämtliche Service-Verträge und Abonnements seitens HPE ausgelaufen und und seitens Geschäftsleitung es auch nicht geplant ist weitere Support-/-Service-Verträge abzuschliessen. (Also gibt's keinen kostenlosen Support seitens HPE [oder einer Firma, welche HPE-Partner ist] und auch gewisse BIOS-Updates können nicht mehr kostenlos bezogen werden. Habe mal hier im Forum nachgefragt jemand wüsste wie man trotzdem dazu kommt was dann geschlossen wurde weil's zivilrechtlich heikel ist -> viewtopic.php?t=182860 )
Ein Thema ist auch das iLO-Feature (der Rechner hat einen "kleinen Computer" drin, der völlig unabhängig vom OS oder irgendwelchen Soft-Reboots fungiert, das nennt sich iLO. Hat auch einen eigenen Ethernet-Anschluss welcher die IP dieses "kleinen Computers" zur Verfügung stelle damit man remote auf sein Web-GUI zugreifen kann)
Nun ist es z.B. so, dass bei diesem ILO auch kein Feature lizenziert (gekauft, das kostet halt) werden will welches OS-unabhängig Benachrichtigungen zum Hardware-RAID-Array (welches insgesamt 7 2.5"-HDs oder SSD beinhalten kann, aktuell haben wir 7x WD Red NAS-HDDs drin) per SMTP versenden kann. Das HW-RAID ist aktuell mit allen 7 Platten als RAID5 mit 1 Spare-Disk konfiguriert
Leider scheint es für den HW-RAID-Controller irgendwie keine OS-Software zu geben welche die hinter dem HW-RAID-Array "versteckten" Platten (trotz für das OS nur 1 sichbarer [virtueller] RAID-Festplatte) einzeln zum OS durchreichen kann (Weder für Window$ *, noch für Linux) - konkret für SMART-/RAID-Benachrichtigungen.
* Bei Window$ müsste man den Eventlog auf Treiber-Nachrichten parsen (per Taskplaner auf bestimmte Strings) und dann, bei einem RAID-/SMART-Problem über den eingerichteten Task und ein Skript, welches per Mail ein SMTP-Server aufruft (zwecks Mailversand), ein Mail versenden. Also ziemlich kompliziert.
-> Aus diesem Grund hätten wir vor, in Zukunft auf HW-RAID zu verzichten. Dann wird auch die Cache-Batterie überflüssig. (Wir hatten mal den Fall, dass diese leer war. Eine MariaDB-Stored Procedure auf einer Linux VM hatte dann statt ein paar Millisekunden ca. 30 Sekunden um vollständig abgearbeitet zu werden - na ja..
)Nun stellt sich beim SW-RAID die Frage betr. des Boot-Vorgangs. Ab einem SW-RAID-Array zu booten ist wohl die grösste Bastelei ever. (Linux kann das zumindest "irgendwie" bei RAID1, wobei das RAID1 dann nicht mehr 1:1 gespiegelt ist weil ich auf einer der beiden Platten in Boot-Sektor befindet. -> Der Bootloader des BIOS kann ja das SW-RAID nicht vor dem Boot-Vorgang aufbauen. Hatte mal so ein Billig-Nas von Iomega, welches ebenfalls ausgebaut war - nix gut, nene!!)
Was wäre da eine gute (oder zumindest "halbwegs passable"
) Idee?- 1 SSD (oder HD) als Bootplatte (schnell, aber nicht redundant) und dann die restlichen 6 Platten als SW-RAID-Array aufbauen? (Die Frage ist eher unabhängig davon, ob als OS nun Linux oder Window$ verwendet wird)
- 2 SSD (oder HD) TROTZDEM (!) als HW-RAID-Array zusammenfassen und das OS ab diesen booten (ILO-Benachrichtigungen hin oder her - halt einfach ab und zu
manuell ins Treiber-Event-Log schauen ob keine der beiden Platten Stress macht?)
-> Ne USV haben wir natürlich und SW-RAID wäre selbst bei einem Stromausfall relativ stabil und hat sich bis jetzt immer regeneriert (egal ob bei Window$ oder Linux), aber PURES HW-RAID sollte m.E. immer ne Cache-Speicher-Batterie haben - auch bei red. Stromversorgung. Gerade LSI-Controller ohne Speicherbatterie (z.B. günstigere wie der LSI 9212-4i4e mit Anschlüssen welche mechanisch eher SATA- als SAS-mässig sind) machen bei HW-RAID und einem Stromausfall massive Probleme. Da kann es vorkommen, dass ein Dateisystemfehler (nicht zwangsläufig defekte Sektoren) auftritt welcher sich dann "kreut und quer" immer und immer wieder über das RAID-Array "synchronisiert"... hatte mal so einen Fall, wo es nur noch half alle Platten auszubauen und zu Wipen (z.B. um zu schauen ob der Wipe-Vorgang bis 100% durchläuft was darauf hinweist dass es KEINE defekten Sektoren hat) und anschliessend alles wieder zusammenzusetzen. -> Hat mich mehr als ein Wochenende gekostet, all die Terabyte-grossen Platten durchzuwipen
P.S.: Zuhause habe ich einen kleinen Fujitsu-Server, dessen Boot-Platte eine einzeln SSD ist. An einem LSI-Controller hängen 4 HDDs (Segate Video-Platten, die sind stabil und werden nicht allzu heiss - lieber stabil als rasend schnell -> SSDs werden übrigens auch ziemlich heiss, die einzelne (mit genug Luft drum herum) SSD-Boot-Platte wurde gemäss "HDD Sentinel" ca. 10 Grad heisser als es die 4 2.5" Seagate Video HDDs jemals wurden) Die 4 RAID-Platten sind über 2x2 HW-RAID0 ("RAID" - eher in Anführungszeichen bei RAID0!
) zu 2 virt. Platten zusammengefasst welche im OS wiederum zu RAID1 zusammengefasst werden - also RAID 10 als Mischung von HW-RAID0 und SW-RAID1... ne "interessante" Kombination, läuft aber relativ gut!! 
-> Aber zuhause ist halt nicht das Selbe wie im Geschäft... wenn zuhause was passiert kommt's rein auf mich persönlich zurück. Im Geschäft auch, aber NICHT nur... sondern auch auf dem Chef und unsere Kunden und das Firmen-Image wenn was passiert.
Bin gerade ein wenig verwirrt - evtl. kann mir jemand ein wenig auf den Sprung helfen...?
(Ist ein bisschen viel Text, ich weiss, aber ich hoffe zumindest dass ich damit alle notwendigen Infos geliefert habe...)
Für den einen oder anderen Tipp wäre ich sehr dankbar...
(-> "Last Power State" im BIOS aktiviert, wie normal bei Servern)
Linux SW RAID scheint wirklich super stabil zu sein. Dank dem SW-RAID konnte ich auch die Cache-Batterie aus dem Server nehmen - völlig überflüssig in diesem Fall.