Infomaniak bemüht sich seit jeher, seinen ökologischen Fussabdruck im Alltag zu minimieren und seine Ressourcen bestmöglich auszuschöpfen. Für einen Hosting-Anbieter, der ausschliesslich auf erneuerbare Energien setzt, besteht die umweltschädlichste Aktivität im Kauf neuer Server. In dieser Hinsicht sind wir bemüht, das Leben der Server so weit wie möglich zu verlängern und technisch veralteten Geräten ein zweites Leben zu ermöglichen.

Letztere verwenden wir weiterhin für interne Zwecke wie Vorproduktion, Schulung und Demonstration. Dieses «Schicksal» ereilt beispielsweise unsere guten alten DELL R410-Server! Damit wir die Maschinen dennoch unter akzeptablen Rahmenbedingungen verwenden können, verpassen wir ihnen eine Verjüngungskur. Genau darum geht es in diesem Artikel.

Autor dieses Beitrags ist Mickael Asseline (alias PAPAMICA), Systemingenieur bei Infomaniak. Der IT-Freak teilt seine Erkenntnisse in einschlägigen Foren sowie über Discord, Wiki-Tech.io und Tech2Tech. Wann immer es seine Zeit zulässt, entspannt er sich bei einer Partie CS.

Stichwort DELL R410-Server

Bevor ich zum eigentlichen Thema komme, muss ich einige Jahre zurückgehen, und zwar bis 2009! Tatsächlich stammen die DELL R410-Server im 1U-Format vom Ende der 2000er-Jahre, unterstützten bis zu zwei CPUs und bis zu 64 GB RAM – bei nur vier Steckplätzen für SAS- oder SATA-Festplatten (2″5 oder 3″5).

Auf ins zweite Leben!

Prozessor

Unsere alten Server wurden bis dato mit einer 4-Kern-CPU betrieben. Das war früher ausreichend, doch heutzutage wollen wir Leistung. Folglich nutzen wir beide CPU-Sockel und platzieren dort CPUs mit sechs Kernen. Ergebnis: zwei kernige Xeon L5640-Prozessoren!

Arbeitsspeicher

Uns stehen acht Steckplätze für DDR3-RAM-Module zur Verfügung. Da der Server nur 64 GB unterstützt, entschieden wir uns für acht Module mit 8 GB ECC DDR3 mit einer Taktrate von 1333 MHz. Damit haben wir die Möglichkeiten in diesem Bereich leider ausgereizt.

Netzwerk

Wir benötigen eine Netzwerkkarte, die den Betrieb des Servers nicht verlangsamt, und unsere 40 Gbps-Infrastruktur bestmöglich ausschöpfen. Letztlich entschieden wir uns für eine Karte mit 25 Gbps. Hierzu mussten wir den PCIe-Slot des Servers freimachen und uns von der PERC H700-RAID-Karte trennen.

Speicher

Jetzt wird es spannend!

Diese Server habe nur vier 3″5-Steckplätze für Festplatten und begrenzen folglich die Möglichkeiten, einen System- und einen Datenabschnitt einzurichten (ohne Raid, beispielsweise für ELK oder Swift). Wir entschieden uns für eine Modifizierung des Servers und fügten zwei SSD für das System hinzu. Dabei war etwas Einfallsreichtum gefragt, denn bei 1U-Servern war der Platz äusserst knapp.

Beginnen wir mit dem einfachen Teil: Zunächst packten wir in die vier freien Steckplätze vier SAS-Festplatten mit 12 TB und 3.5 Zoll.

Für die zusätzliche SSD-Platte nutzten wir den Steckplatz für das CD-Laufwerk mit einem Adapter von einem CD- zu einem SATA 2″5-Laufwerk. Das sieht dann in etwa so aus:

Doch wie bereits gesagt, wollten wir zwei SSDs, um das System mit RAID zu betreiben. Also fügten wir mit diesem Adapter einen weiteren Adapter hinzu: 2 x M.2 zu 2″5 SATA.

So konnten wir unsere beiden Extra-SSDs unterkriegen! Wenngleich bei dieser Konfiguration ein Hardware-RAID ausgeschlossen ist, bleibt uns so noch die
Hot-Plug-Funktion, um im Notfall ohne Systemunterbrechung eine Festplatte auszutauschen (nicht möglich bei SSD M2).

Mit dem M.2-Adapter lässt sich mithilfe von Jumpern auf der Platine ein Hardware-RAID realisieren. Da wir aber keine Möglichkeit haben, dieses RAID-System fernzuüberwachen, entschieden wir uns dagegen. Die vier SAS-Platten sowie die beiden SSD M.2 werden vom System als JBOD betrachtet. Folglich können wir dies mit einem Software-RAID nutzen.

Ergebnis

Unsere R410-Server sind mit zwei zusätzlichen SSDs ausgestattet:

 

 

Die beiden System-SSDs M.2 120G und die vier HDDs mit 12TB sind an der Frontseite unseres R410 klar zu erkennen:

root@17S025J>_ ~ # dmidecode -t 1 | grep PowerEdge
Product Name: PowerEdge R410
root@17S025J>_ ~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 289.2M 1 loop /lib/live/mount/rootfs/filesystem.squashfs
sda 8:0 0 111.8G 0 disk
sdb 8:16 0 111.8G 0 disk
sdc 8:32 0 10.9T 0 disk
sdd 8:48 0 10.9T 0 disk
sde 8:64 0 10.9T 0 disk
sdf 8:80 0 10.9T 0 disk

Damit stehen unseren Servern noch einige Dienstjahre in unseren verschiedenen Labs bevor 😎