Schlagwort-Archive: IBM

adlerweb // BitBastelei 2024-02-14 18:45:37

100 Jahre . Zumindest der Name. Über $Jahre hatte ich diverses Equipment von denen in der Hand – sowohl Bürokram als auch PCs/Server wie z.B. die heutigen System i oder System x. Alle hatten eins gemeinsam: Schweineteuer, aber verlässlich. Vor Allem aber stand IBM zu seinen Produkten. Im Zweifel wurden Ersatzteile in <24 eingeflogen um Systeme wieder lauffähig zu bekommen. Bedauerlich, dass x86 verkauft wurde – bei Lenovo läuft man teils Wochen für Ersatzteile hinterher. Good old days.

BitNotice #123 – IBM/Lenovo Server-Firmware mit BoMC

BitNotice #123 - IBM/Lenovo Server-Firmware mit BoMC

(21 MB) 00:12:19

2017-06-23 12:00 🛈

Der Bootable Media Creator von Lenovo (ehemals IBM) erstellt Datenträger mit den aktuellsten Firmware-Updates für Serversysteme des Herstellers. Schauen wir mal, wie der BoMC bedient wird und man die Software per IMM installieren kann.

BitNotice #121 – Ungeplanter Servertausch

BitNotice #121 - Ungeplanter Servertausch

(181 MB) 00:30:51

2017-06-16 12:00 🛈

Ugh. Früh. Laut. Dank eines kaputten Elektrogerätes hat es mir den FI/RCD gekegelt, entsprechend sind nur noch die wichtigsten Geräte online. Machen wir das beste draus und tauschen gleich den Homeserver aus – zumindest so weit das mit den verfügbaren Teilen möglich ist.

BitNotice #119 – IBM 3650M2: E5530 zu L5630

BitNotice #119 - IBM 3650M2: E5530 zu L5630

(77 MB) 00:09:57

2017-06-08 12:00 🛈

Einen Nachteil haben Server der 3650M2-Generation: Der Stromverbrauch. Etwas möchte ich da doch drehen – die bisherige E5530-CPU wird gegen ein neueres Low-Power-Modell getauscht.

E5530 L5630 i3-4130
Codename Nehalem EP Westmere EP Haswell
Kerne 4 4 2
Threads 8 8 4
Grundtakt 2.40GHz 2.13GHz 3.40GHz
Turbo-Boost 2.66GHz 2.40GHz
Cache 8MB 12MB 3MB
TDP 80W 40W 54W
Lithographie 45nm 32nm 22nm

BitNotice #117 – x3650M2: RAM-Fehler, SATA-Stromanschluss nachrüsten

BitNotice #117 - x3650M2: RAM-Fehler, SATA-Stromanschluss nachrüsten

(75 MB) 00:11:27

2017-06-01 12:00 🛈

Bei einer Auktion habe ich günstig einen IBM 3650M2 geschossen. Nicht das neueste Modell, aber zuverlässig und mit den Vorteilen eines „echten“ Servers: Redundanz, ECC-RAM und quasi unkaputtbar.
Der Verkäufer sagte bereits, dass ein Fehler vorliegt – also schnell beheben und gleich noch einen „normalen“ S-ATA-Stromanschluss nachrüsten.

Links zum Thema:

BitBastelei #186 – Servernetzteil-Innenleben

BitBastelei #186 - Servernetzteil-Innenleben

(287 MB) 00:23:56

2016-02-28 11:00 🛈

Vor Kurzem ist hier mit etwas Krach ein Servernetzteil ausgefallen. Bevor dieses seinen Weg in den Elektroschrott antritt schauen wir noch, wie so ein „professionelles“ Netzteil aufgebaut und wo genau der dauerhafte Schaden aufgetreten ist.

Die Netzteile kosteten bei der Einführung 2008 ca. 200€

IBM DS32xx-Series: Logical volume vergrößern

Eigentlich eine einfache Sachlage: Eine IBM SAN mit einem einzelnen RAID-Array und 3 Volumes – seinerzeit wurde nicht der gesamte Speicherplatz zugewiesen, da die Wachstunsraten nicht absehbar waren und man sobei Bedarf dynamisch vergrößern könne. Leider ist das Vergrößern eines logischen Volumes (auf IBM-Sprache „Dynamic Logical Drive Expansion (DVE)„) offenbar eine sehr esoterische Aufgabe, daher hat IBM die Funktion auch nicht in die GUI integriert. Wir müssen also an die Konsole – meist ist hiermit die serielle Schnittstelle gemeint, da das Gerät in meinem Fall jedoch auswärts steht musste ich einen anderen Weg suchen: Auf Rechnern mit installiertem „IBM System Storage DS Storage Manager“ (aka der GUI) findet sich im Installationsordner auch einen CLI-Client. Über eine Shell kann das Programm mit folgender Syntax aufgerufen werden:

Linux
./smcli [ip] -c "befehl"
Windows
SMcli.exe [ip] -c "befehl"

Der erste Schritt besteht darin den Namen des logischen Gerätes zu finden – das geht zwar auch über die GUI, aber jetzt ist die CLI ja eh schon offen. Wichtig: Die Befehle müssen mit einem Semikolon abgeschlossen werden.

SMcli.exe -c "show logicalDrives;"

Performing syntax check...
Syntax check complete.
Executing script...
STANDARD LOGICAL DRIVES------------------------------
SUMMARY
Number of standard logical drives: 3
See other Logical Drives sub-tabs for premium feature information.
NAME STATUS CAPACITY RAID LEVEL ARRAY DRIVE TYPE
DRIVE1 Optimal 380 GB 5 1 SAS
DRIVE2 Optimal 300 GB 5 1 SAS
DRIVE3 Optimal 600 GB 5 1 SAS
DETAILS
[...]

Zur Sicherheit werfen wir auch noch einen Blick auf das zugehörige Array mit der Nummer 1 um zu bestätigen, dass wir tatsächlich noch freien Platz haben:

SMcli.exe [ip] -c "show array [1];"

[...]
ARRAY 1 (RAID 5)
Associated logical drives and free capacities:

LOGICAL DRIVE NAME CAPACITY
[...]
Free Capacity 100 GB
[...]

So weit so gut – wir haben in Drive2 zur Zeit 300GB Speicher, 100GB sind im Array noch frei. Um nun Drive2 um 50GB zu vergrößern nutzen wir folgenden Befehl – dieser kann online, also ohne Ausfall durchgeführt werden:

SMcli.exe [ip] -c "set logicalDrive["DRIVE2"] addCapacity=50GB;"

Performing syntax check...
Syntax check complete.
Executing script...
Script execution complete.
SMcli completed successfully.

Je nach Aufbau des Systems dauert die endgültige Ausführung mehrere Stunden, so ist es ggf. nötig bestehende Volumes zu Verschieben um eine Fragmentierung zu vermeidel – sowas dauert natürlich. Leider konnte ich keinen CLI-Befehl für eine Fortschrittsanzeige finden – in der GUI wird während des Vorgangs eine Notiz im Kasten „Status“ unter „Operations in Progress“ angezeigt.

Nachdem das LV vergrößert wurde muss dies auch im Betriebssystem mitgeteilt werden. Linux bekommt die Änderung meist automatisch mit, wenn nicht hilft ein SCSI-Rescan. Ext-Dateisysteme lassen sich mit resize2fs vergrößern, die meisten Anderen haben ebenfalls passende Befehle im Gepäck. Unter Windows ab Server 2008 lassen sich die Aktionen über die Datenträgerverwaltung (Unterpunkt der Computerverwaltung) durchführen, ältere Versionen beherrschen ein Online-Resize nicht, hier hilft eine passende Boot-CD.

UEFI – wir verschlimmbessern?

Was war das doch früher einfach: Ins CMOS-Setup, ein paar wenige Einstellungen anpassen und meist konnte man danach sein System starten – auch, wenn der nötige „Treiber“ erst per Option-ROM hinterher kam. Heute läuft das anders: Vor das ohnehin schon in einen Hypervisor verfrachtete OS hängt man einen weiteren Systemlayer: UEFI. Ganz toll mit ganz vielen Modulen und ganz vielen Möglichkeiten (die sicher auch Sicherheitstechnisch in Zukunft einigen Spaß machen dürften). Soweit die Theorie. Inzwischen hatte ich das große Vergnügen mehrere UEFI-Systeme vorgesetzt zu bekommen. Nummer eins war ein kleines AMD-Fusion-Board, welches recht pflegeleicht war. Das neue Setup glänzt mit Mausunsterstützung und selbsterklärender GUI, an vernünftige Einstellungen gelangt man über einen Expertenmodus. Das System startet flott und zeigt keine Fehler, zwar „no Points so far“, dann auch ältere PCs mit BIOS hatten zum Teil schon grafische Menüs, aber ich sah auch keine Nachteile für mach, also „macht wenn ihr euch besser fühlt“ – die 2TB-Grenze des alten BIOS dürfte demnächst ja erreicht sein. Die weiteren Rechner waren IBM xServer und hierzu kann ich nur eins sagen: You are doing it wrong. IBM war ja noch nie für durchdachte Menüs oder Konzepte im BIOS zu haben, aber was sie bei diesen Kisten geritten hat wissen sie wohl selbst nicht – je nach PCI-Karten benötigen die Kisten über 20 Minuten um den BIOS-Nachfolger zu durchlaufen und mit dem OS zu beginnen. Das Booten einer internen RAID-Karte wird zur Geduldsprobe: Diese versteckt sich hinter kryptischen PCI-IDs, welche erst in eine Bootwarteschlange eingefügt und in einem weiteren Schritt entsprechend priorisiert werden müssen. Selbst dann booten ältere Systeme nicht, denn ohne ein höher priorisiertes „Legacy Devices“, welches als Dummy-Boot-Device dient und beim Booten diverse Einstellungen ändert, werden nur EFI-fähige Betriebssysteme unterstützt. „Mal schnell“ etwas machen fällt hier definitiv aus. Aus den UEFI-Zielen der einfacheren Bedienbarkeit und schnelleren Bootzeiten wurde hier eher das exakte Gegenteil. Ich habe jetzt nach 2 Stunden jedenfalls das nicht (ganz planmäßig abgesägte) OS wieder am laufen – wie der letzte Nutzer es gebootet hatte wird wohl ein Geheimnis bleiben.