MegaCLI fuer Debian?

[Knogle]

Ich gruesse euch liebe Community.

Lange Zeit habe ich unter Ubuntu fuer die Verwaltung meines RAID Controllers MegaCLI genutzt, und wuerde das nun gerne auch bei Debian machen.
Leider habe ich nun einige Stunden erfolglos nach MegaCLI fuer Debian gesucht, woran liegt das? Mache ich eventuell irgendwas falsch bei der Suche?
Ich finde es nur fuer Ubuntu CentOS und RedHat, aber nirgendwo fuer Debian

[2undvierzig]

frag den Hersteller: cisco.com
thomas Krenn hat sogar ein fertiges Debian mit integriertem MegaCLI. https://www.thomas-krenn.com/de/wiki/Me ... _verwalten

[hikaru]

Ein 3rd-Party-Repo findet sich auch recht schnell. [1] Keine Ahnung ob das empfehlenswert ist.
Auf den ersten Blick fällt auf, dass man da die DFSG nicht verstanden hat oder sich nicht darum schert. Sonst wäre das Paket dort nicht in main.

[1] https://hwraid.le-vert.net/wiki/DebianPackages

[BenutzerGa4gooPh]

frag den Hersteller: cisco.com

LSI/Broadcom.

[2undvierzig]

frag den Hersteller: cisco.com

LSI/Broadcom.

Hätt ich wohl doch nachgucken müssen.

[Knogle]

Hersteller habe ich schon gefragt Die haben nur so ein tolles VM Tool, aber weder MegaCLI oder StorCLI bieten die noch an.
Sonst nur Loesungen mit GUI, aber nichts mehr fuer Commandline :/

Schon sehr armselig fuer so einen grossen Hersteller von RAID Controllern

[r4pt0r]

Wow, das ist das erste mal, dass ich "MegaCLI" und "gerne nutzen" in einem Satz lese
Allein schon der Syntax ist eine absolute Katastrophe - diese "software" steht ganz weit oben auf der Liste der miserabelsten CLI-Tools die je geschrieben wurden... Das schlimmste/lustigste: Der "Nachfolger" StorCLI wird ganz stolz damit beworben, dass der Syntax beibehalten wurde

Ich hab den letzten dieser gammligen RAID-Controller die *nur* per megacli/megasascli verwaltet werden können vor ~1.5 Jahren entsorgt, alle anderen sind nur noch SAS2008/3008 basierte HBAs, die lassen sich auch mit anderen tools (z.b. mpsutil/mptutil) verwalten bzw laufen hier sowieso alle im IT-mode ohne jegliche RAID-funktion. HW-Raid ist IMHO ein Relikt das in die 90er gehört - ausser für Betriebssyteme die bis heute keine brauchbaren dateisysteme mit volume-management haben gibts keinen Grund noch HW-Raid zu verwenden.


Aber zum Thema: Einzige quelle für fertig paketiertes MegaCLI ist (zumindest war es das bis vor ~1.5 Jahren) das repo von hwraid.le-vert.net.
IIRC waren die Versionen immer relativ alt; aber wenn man eine "ausreichend funktionierende" Version von MegaCLI laufen hat sollte man die sowieso nicht anrühren solange man keine Probleme hat. SMART-Passthrough ist eine der Funktionen die nach Updates öfter mal kaputt waren - war immer ganz toll wenn das Monitoring nach Updates plötzlich 8 Platten "verliert"

[heisenberg]

alle anderen sind nur noch SAS2008/3008 basierte HBAs, die lassen sich auch mit anderen tools (z.b. mpsutil/mptutil) verwalten

Spontanes Googeln lässt vermuten, dass mpsutil und mptutil nur auf BSD laufende Werkzeuge sind. Laufen die auch unter Linux? Wäre schön, da ich storcli(Was neben megacli auch noch tw_cli als Vorgänger hat ) schon recht anstrengend in der Benutzung finde.

---

Ansonsten lasse ich Dir gerne die Meinung, dass HW-RAID-Controller überholt sind. Ich finde Sie bieten nach wie vor einige Vorteile, die ich so bei den Softwarevarianten nicht sehe:

• Automatisches Recovery beim Anschluss einer neuen Festplatte am gleichen Anschluss ohne explizit eine Spare konfigurieren zu müssen (=kann auch ein Ungelernter austauschen).
• Keine Zusatzkonfiguration im Betriebssystem(=einfachere Handhabung)

[habakug]

Hallo!

Hier [1] gibt es die Version 1.23.02 für Debian (storcli_1.23.02_all.deb).
Diese Version ist auch in den Tools "MegaRAID Storcli - All OS " auf Thomas-Krenn [2] enthalten (im Paket unter Ubuntu). Die Debian-Version ist älter.

Gruss, habakug

[1] http://184.154.112.130/raid/lsi/cli/
[2] https://www.thomas-krenn.com/de/downloa ... duct=12190

[r4pt0r]

alle anderen sind nur noch SAS2008/3008 basierte HBAs, die lassen sich auch mit anderen tools (z.b. mpsutil/mptutil) verwalten

Spontanes Googeln lässt vermuten, dass mpsutil und mptutil nur auf BSD laufende Werkzeuge sind. Laufen die auch unter Linux? Wäre schön, da ich storcli(Was neben megacli auch noch tw_cli als Vorgänger hat ) schon recht anstrengend in der Benutzung finde.

Sorry, hatte ich nicht beachtet. Ich hatte im Hinterkopf dass es hier bereits äquivalente tools/ports unter Linux gibt. Scheint aber wirklich noch immer nicht der Fall zu sein
Dann bleibt für die LSI/Avago/Broadcom HW-RAID Controller wohl noch immer nur MegaCLI/StorCLI.
Ich hatte mir für gängige Aufgaben, für die Mega(sas)ctl benötigt wurde (z.B. Platten ersetzen/entfernen, Platten "finden"), perl- oder shellscripte geschrieben. Der Syntax und die fehlende manpage/dokumentation hätten mich sonst ziemlich früh in den Wahnsinn getrieben...

Ansonsten lasse ich Dir gerne die Meinung, dass HW-RAID-Controller überholt sind. Ich finde Sie bieten nach wie vor einige Vorteile, die ich so bei den Softwarevarianten nicht sehe:

Das IMHO mit Abstand größte Problem der HW-Raid controller ist der 100%ige vendor- und teilweise sogar controller/chipsatzversions-lock-in. Eben die selbe praxis die in den 90ern von vielen Herstellern angestrebt wurde.
Ein guter, performanter RAID-Controller kostet ab ca 700EUR aufwärts. Da bei defekt nur ein _identischer_ controller den RAID-Verbund wieder sicher erkennen und starten kann, muss für Produktivsysteme eigentlich ein zweiter immer parat liegen. sw-raid/lvm/ZFS ist hier wesentlich "sicherer" - alle lassen sich unabhängig vom controller wieder auf neuer/anderer hardware laden.
Dazu kommt der ca jährliche Ersatz der BBU für ~100-200EUR.
Das ganze nur um Platten zu betreiben, die mittlerweile im Vergleich dazu spottbillig verramscht werden....

Datenintegrität wird mit RAID ebenfalls nicht gewährleistet - gibt eine Platte falsche Daten zurück, liefert der Controller diese einfach weiter, da er kein Konzept des Dateisystems hat. Auch die Redundanz in einem Mirror hilft hier nicht.

Ausser wenn das letzte Quäntchen performance ausgequetscht werden muss fällt mir wirklich kein Szenario ein, in dem HW-Raid noch eine wirkliche Daseinsberechtigung hätte - ausgenommen besagte Betriebssysteme die bis heute keinerlei brauchbare volume-manager (oder Dateisysteme die ein solches Konzept beinhalten) besitzen; sprich die gesamte MS Betriebssytempalette... Hier sind aber die Lizenzkosten i.d.R. der weitaus größere Faktor, da fallen die Kosten für HW-RAID dann auch nicht mehr ins Gewicht...

• Automatisches Recovery beim Anschluss einer neuen Festplatte am gleichen Anschluss ohne explizit eine Spare konfigurieren zu müssen (=kann auch ein Ungelernter austauschen).

Bei md-raid (und/oder LVM) ist der aufwand ggf wirklich höher. Mit ZFS übernimmt das aber je nach Betriebssystem der fmd (illumos), zfsd (FreeBSD) oder zed (Linux, macOS). Per default (zumindest für zfsd) wird dann bei entfernen einer Platte, eine an ihrer stelle eingesetste, unkonfigurierte Platte automatisch als Ersatz angenommen und resilvered. Problematischer beim Plattentausch durch einen "Amateur" (User) ist i.d.R. eher, die richtige Platte rauszuziehen - selbst mit eindeutigen Labels auf den Caddies und ausführlichen Anweisungen sind die überfordert. (been there, done that... )
Resilvering ist auch bedeutend effizienter als klassisches rebuild, da nur tatsächlich belegte Blöcke wiederhergestellt werden. Der HW-Controller muss i.d.r. die _komplette_ platte wiederherstellen, inkl leerer und bereits gelöschter Bereiche, da er keine Ahnung hat wo sich tatsächlich Daten befinden.
Bei heutigen Plattengrößen von mehreren TB bedeutet das einen Unterschied von mehreren Stunden bis wieder Redundanz hergestellt ist.

• Keine Zusatzkonfiguration im Betriebssystem(=einfachere Handhabung)

Konfiguration im Betriebssystem ist für beide Ansätze nicht nötig; nur die Tools und der Aufwand um letztendlich benutzbare dateisysteme zu erhalten ist deutlich unterschiedlich.
MegaCLI/StorCLI + ggf mdadm + ggf LVM + FS-spezifische tools vs zpool + zfs... Ich finde das letztere wesentlich einfacher und durchschaubarer in der handhabung, selbst bei sehr vielen devices.
Erweiterung eines ZFS-Pools ist ein einziger befehl; mit einem RAID-Controller und MegaCLI sind es wesentlich mehr schritte neue Platten aufzunehmen (so grob aus dem Gedächtnis):
- PDMkGood
- CfgForeign
- CfgLdAdd (oder SpanAdd?)
+ ggf das neue logische device in den LVM aufnehmen und/oder dateisystem erstellen.
Bei Plattenausfall muss die tote/fehlende Platte auch mit mehreren schritten aus der Konfiguration entfernt werden.
Auch das mapping der verschiedenen IDs für die Platten an den LSI-Controllern (IIR DriveID, BusID und PhysID bzw ControllerID:Device) ist mir noch als ziemlicher Krampf in Erinnerung - wenn das PdLocate nicht funktioniert (=Backplane nicht explizit vom Controller unterstützt), wird da leicht die falsche Platte aus dem Server gezogen. Ich hatte mir dafür extra mal ein perlscript gebaut um tote Platten halbwegs sicher lokalisieren und einem physischen slot zuordnen zu können...

[heisenberg]

@raptor:

Alles was ich nicht kommentiere stimmt entweder oder ich kann es nicht beurteilen

zed kannte ich noch nicht. Hört sich ja durchaus interessant an. Ansonsten ist ZFS nicht überall verfügbar(VMware, Citrix XenServer, ältere Serversysteme) bzw. ist der Einsatz nicht immer sinnvoll(z. B. wegen der RAM-Anforderungen)

Mit RAID-Controllern der 3ware Reihe hatte ich lange keine Probleme. Die waren in der Serie immer vorwärskompatibel. D. h. die neuen können alte Units erkennen und verwalten.

[heisenberg]

Problematischer beim Plattentausch durch einen "Amateur" (User) ist i.d.R. eher, die richtige Platte rauszuziehen - selbst mit eindeutigen Labels auf den Caddies und ausführlichen Anweisungen sind die überfordert.

Ich zieh immer die Platte, bei der die Aktivitäts-LED dauerhaft aus ist. Bis jetzt habe ich noch nicht daneben gegriffen. (Naja bei den wichtigen Systemen schaue ich schon mal genauer nach )

[Colttt]

zed kannte ich noch nicht. Hört sich ja durchaus interessant an. Ansonsten ist ZFS nicht überall verfügbar(VMware, Citrix XenServer, ältere Serversysteme) bzw. ist der Einsatz nicht immer sinnvoll(z. B. wegen der RAM-Anforderungen)

Nunja man hat ja das storage normalerweise nicht mit auf d Hypervisor, das bindet man ja idR per iSCSI oder NFS ein von daher ists wurst ob die das unterstützen, dein Storageserver muss das können.

[heisenberg]

@Colttt: interessantes Thema. Ich habe das mal hier fortgeführt: viewtopic.php?f=9&t=167066