SanDisk ioDimm3 als writeback Cache

Ich habe heute alle meine virtuellen (test) Maschinen von meiner ExHana Maschine entfernt und mich mit LVM (Logical Volume Manager) beschäftigt.

Im Thomas-Krenn Wiki habe ich eine gute Anleitung gefunden, wie man SSDs als Cache in einem LVM für ein langsameres Storage verwenden kann.

Mit ein paar kleinen Anpassungen funktionieren nun meine SanDisk ioDimm3 als writeback Cache für meinen Raid-Speicher.

Die SanDisk ioDimm3 wurden in einen Raid 1 -Verbund zusammen geschaltet. Der langsamere Storage wird in meinem Setup nicht als Linux Software-Raid zur Verfügung gestellt, sondern direkt vom Smart-Array-Controller als Raid betrieben.

Alle anderen Einstellungen habe ich wie im Wiki beschrieben umgesetzt.

Jetzt geht’s an’s TESTEN.  (Natürlich auch mit LVM Snapshots)

 

Debian Mass storage controller: SanDisk ioDimm3 (rev 01)

In meiner Hana-Test-Maschine sind 2 Mass storage controller: SanDisk ioDimm3 (rev 01) verbaut.

Hier eine kurze Anleitung, wie ich diese Dinger unter Linux Debian 9 installiert habe.

Bei Sandisk registrieren und Sourcecode herunterladen, entpacken und installieren funktioniert bei mir nicht. Fehler beim Compilieren…

Aber auf  GitHub habe ich jemanden gefunden, der die Sources patcht, so dass diese auch mit  aktuellen Debian Kerneln verwendet werden können.
(getestet mit 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux)

 

git clone https://github.com/snuf/iomemory-vsl.git
(stand 1.2.2018 branch master)

cd iomemory-vsl/root/usr/src/iomemory-vsl-3.2.15

make modules

sudo make modules_install

 

Von der SanDisk – Seite im Bereich Ubuntu 16.04 folgende Pakete downloaden

fio-common_3.2.15.1700-1.0_amd64.deb
fio-preinstall_3.2.15.1700-1.0_amd64.deb
fio-sysvinit_3.2.15.1700-1.0_all.deb
fio-util_3.2.15.1700-1.0_amd64.deb
fusion_3.2.11-20150618.fff

und installieren

sudo dpkg -i fio*

sudo depmod

sudo modprobe iomemory-vsl

ls -l /dev/fio* sollte nun devices anzeigen

genau so wie lsblk

sudo update-rc.d iomemory-vsl defaults

sudo nano /etc/sysconfig/iomemory-vsl
ENABLED=1

…und schon kann man die Dinger wie Festplatten verwenden.

Im UserGuide stehen einige interessante Informationen über Performance drinnen…

So zeigt mein System im Leerlauf folgende Messwerte:

wenger@flo-hana-test:~$ for i in sda sdb fioa fiob fioc fiod ; do sudo hdparm -tT /dev/$i ; done

/dev/sda:
 Timing cached reads: 13788 MB in 1.99 seconds = 6924.94 MB/sec
 Timing buffered disk reads: 3222 MB in 3.00 seconds = 1073.57 MB/sec

/dev/sdb:
 Timing cached reads: 13628 MB in 1.99 seconds = 6844.02 MB/sec
 Timing buffered disk reads: 828 MB in 3.00 seconds = 275.87 MB/sec

/dev/fioa:
 Timing cached reads: 13664 MB in 1.99 seconds = 6862.95 MB/sec
 Timing buffered disk reads: 1472 MB in 3.00 seconds = 490.39 MB/sec

/dev/fiob:
 Timing cached reads: 13588 MB in 1.99 seconds = 6825.05 MB/sec
 Timing buffered disk reads: 1484 MB in 3.00 seconds = 494.26 MB/sec

/dev/fioc:
 Timing cached reads: 13646 MB in 1.99 seconds = 6854.43 MB/sec
 Timing buffered disk reads: 1444 MB in 3.00 seconds = 481.06 MB/sec

/dev/fiod:
 Timing cached reads: 13604 MB in 1.99 seconds = 6832.86 MB/sec
 Timing buffered disk reads: 1482 MB in 3.00 seconds = 493.53 MB/sec

und unter Last (… moment; erzeug mal auf so einer Maschine etwas Last…)

also unter Last (load1 = 55.54) ergeben sich diese Messwerte

wenger@flo-hana-test:~$ for i in sda sdb fioa fiob fioc fiod ; do sudo hdparm -tT /dev/$i ; done

/dev/sda:
 Timing cached reads: 10900 MB in 1.99 seconds = 5470.36 MB/sec
 Timing buffered disk reads: 2882 MB in 3.00 seconds = 960.07 MB/sec

/dev/sdb:
 Timing cached reads: 9990 MB in 1.99 seconds = 5013.43 MB/sec
 Timing buffered disk reads: 844 MB in 3.01 seconds = 280.47 MB/sec

/dev/fioa:
 Timing cached reads: 11134 MB in 1.99 seconds = 5586.12 MB/sec
 Timing buffered disk reads: 2420 MB in 3.00 seconds = 806.38 MB/sec

/dev/fiob:
 Timing cached reads: 10940 MB in 1.99 seconds = 5489.71 MB/sec
 Timing buffered disk reads: 2444 MB in 3.00 seconds = 814.11 MB/sec

/dev/fioc:
 Timing cached reads: 10912 MB in 1.99 seconds = 5478.23 MB/sec
 Timing buffered disk reads: 2436 MB in 3.00 seconds = 811.90 MB/sec

/dev/fiod:
 Timing cached reads: 11116 MB in 1.99 seconds = 5581.95 MB/sec
 Timing buffered disk reads: 2454 MB in 3.00 seconds = 817.45 MB/sec

Erklärung:
sda = Raid50 mit 25 Festplatten
sdb = Raid1 mit 2 Festplatten
fioa-fiob = SanDisk ioDimm

Mir ist schon klar, dass hdparm -tT nicht unbedingt ein gutes Messwerkzeug für diese Tests darstellt, aber es zeigt doch ganz deutlich was DVFS (Dynamic Voltage and Frequency Scaling) also die Energiesparfunktionen für Auswirkungen auf die Geschwindigkeit haben.

Oversized Hardware – Hardware Porn

Mein Arbeitgeber ermöglicht mir mit einer ausgediente SAP-Hana-Maschine Erfahrungen zu sammeln.
Für alle, die so etwas noch nie in den Händen hatten -> Hier etwas Hardware-Porn.

Hana Hardware|Power

Hana Hardware|Interfaces

Hana Hardware|Ram (nur ein Teil)

Hana Hardware|CPUs & RAM

Eigentlich ein geiles Teil;
Debian 9 Installation ohne Probleme (mit firmware aus non-free)

cat /proc/meminfo
MemTotal: 1056864580 kB

cat /proc/cpuinfo
… es dauert schon mal, bis die Details von 80 Kernen angezeigt werden… processor : 79
vendor_id : GenuineIntel
cpu family : 6
model : 47
model name : Intel(R) Xeon(R) CPU E7- 4870 @ 2.40GHz

Ein geiles Teil… aber was mache ich nun damit.

Vielleicht installiere ich noch einen ordentlichen Speicher dazu und dann erstelle ich meine eigene Test-Umgebung mit vielen QEMU/KVM – VMs auf diesem Server.

 

SMA-EM – Daemon Update

Ich habe das Git Repository für den SMA-EM – Daemon aktualisiert.

Neues:

  • Modularer Aufbau:
    Die eigentliche Arbeit machen nun die Plugins/Features.
    Dadurch kann der Daemon leicht angepasst und erweitert werden. User, die einzelne Features nicht benötigen, können diese einfach abschalten

Die Software kann bei Github heruntergeladen werden.

SMA-Energy-Meter Linux Daemon Update

Ich habe das Git Repository für den SMA-EM – Daemon aktualisiert.

Neuerungen:

  • Der Daemon kann nun an ein Interface bzw. an eine IP-Adresse gebunden werden, auf welchem er dann auf die Messpakete wartet.
  • Die Socket-Verbindungen werden nun nicht mehr von smaem.py hergestellt, sondern entweder vom Daemon oder von sma-em-measurement.
  • Wenn die Socket-Verbindung nicht hergestellt werden konnte, wartet der Daemon einige Sekunden und versucht es dann erneut. Systemd startet eventuell den SMAEMD bevor das Netzwerk verfügbar ist. Durch diese Änderung soll es dabei keine Probleme mehr geben
  • Der Daemon kennt nun auch die run Option, damit kann man Fehler ggf. leichter erkennen.
  • Aktualisierung der Readme und Systemd-settings

Die Software kann bei Github heruntergeladen werden.

Infos zum SMA-EM könnt Ihr hier finden.

Durch die weitere Nutzung der Seite stimmst du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen