Als Intel Gold Partner sind wir stets auf dem Neusten Stand bei neuen Entwicklungen und Trends der Firma Intel. Eine neue Entwicklung von Intel ist die Softwarelösung Intel Cache Acceleration Software. Diese Software ermöglicht es bei einem bestehenden Serversystem mit normalen Festplatten im Nachhinein SSDs zu installieren und diese als schnellen SSD Cache zu verwenden um die I/O Performance des Festplatten-Arrays zu verbessern. Vorsicht – es gilt der Hinweis: Die Intel Cache Acceleration Software kann nicht auf die Systempartition eingesetzt werden. Man kann es daher nur auf eine gemountete Partition anwenden oder, wenn man einen Virtualisierungslayer verwendet, auf die z.B. LVM Partition der virtuellen Maschine. Zur Aktivierung ist es aber notwendig, den Mountpoint kurzzeitig zu unmounten bzw. die virtuelle Maschine zu stoppen. – Intel verspricht dabei:
- 2x schnelleren Datendurchsatz
- 75 % weniger Latenz
- 70 % weniger Wiederherstellungszeit
Und das Ganze ohne Datenmigration und ohne Änderungen am bestehenden System. Das Einzige was notwendig ist, ist die Installation einer oder mehrerer SSDs und die Installation der Cache Acceleration Software auf dem Serversystem. Dafür gibt es einen Windows Software Client und einen Linux Software Client. Als kleinen Bonus bietet Intel eine kostenfreie 120 Tage Testlizenz über die Webseite an. Möchte man direkt die Lizenz kaufen, so wird zwischen einer Lizenz bis 200 GB SSD Space und einer unlimited Lizenz unterschieden. Die Unlimited GB Lizenz inklusive Standard Support liegt aktuell bei 51,00 $. Im Vergleich zu einer xCacheCade 2.0 Lizenz zu LSI RAID Controllern die bei über 200,00 € liegt ist das ein wahres Schnäppchen, wenn es hält, was es verspricht.
Wir haben uns einen unserer Restpostenserver geschnappt und das Ganze einmal getestet. Als Basis für das Grundsystem haben wir folgende Hardware verwendet:
- Intel Core i7-4790T
- 32 GB DDR3 RAM
- 2x 2 TB WD Red Festplatten – WD20EFRX-68EUZN0
Installiert wurde das System anschließend mit Debian 8 im Software RAID 1 mit einem zusätzlichen Software RAID mount auf das Verzeichnis /var/www. Mit Sicherheit könnte man auch /var/lib/mysql als Mount einsetzen um zum Beispiel die Datenbank Performance zu erhöhen.
Diese Art von Server kommt bei uns sehr häufig zum Einsatz und bildet daher eine sehr gute Referenz für einen Performance Test. Das Debian nutzt den aktuellen Standard Kernel 3.16.0-4-amd64. Man kann auch einen individuellen Kernel von uns nutzen, allerdings ist dabei für die Installation des Intel Cache Acceleration weiterführendes Fachwissen im Kernel Bereich erforderlich, da zusätzliche Header und Kernel Module installiert werden müssen.
Cache Typen die bei Intel Cache Acceleration zum Einsatz kommen
Bevor man mit der Einrichtung der Intel Cache Acceleration beginnt, sollte man sich über die verschiedenen Cache Typen klar sein, die zur Auswahl stehen. Die Intel Cache Acceleration bietet dabei Drei Varianten:
write-around – Eine Caching Variante bei denen einige Schreiboperationen nicht cached werden. Schreiboperationen für Datenblöcke die nicht im Cache existieren werden direkt auf das Core Device geschrieben und der Cache nur als bypass verwenden. Wenn die Schreiboperation einen Fehler verursacht zum Beispiel durch defekte Sektoren, ist diese zusätzlich im Cache vorhanden. Diese Variante wird empfohlen bei weniger Schreibprozessen im Vergleich zu Leseprozessen wie zum Beispiel bei Datenbanksystemen.
write-back – Bei dieser Caching Methode werden alle Daten zuerst auf die SSD geschrieben. Wenn das HDD Array ausreichend Ressourcen wieder zur Verfügung hat, wird der Write Cache auf die HDD geschrieben. Wichtiger Hinweis: Diese Cache Variante sollte man nur verwenden, wenn man mehrere SSDs in einem RAID Verbund als Cache verwendet. Wenn hier die SSD im laufenden Betrieb einen Defekt aufweis kommt es zu Datenverlust.
write-through – Bei dieser Caching Methode werden alle Schreiboperationen zum Cache und synchron zur Festplatte gesendet.
Je nach Anwendungsfall kann daher eine der Drei möglichen Cachingvarianten verwendet werden. Wenn nur eine SSD zum Einsatz kommt, sollte man von Variante write-back absehen.
Installation von Intel Cache Acceleration – normales System ohne Virtualisierungslayer
Die Installation ist denkbar einfach. Man lädt von der Webseite http://www.intel.com/content/www/us/en/software/intel-cache-acceleration-software-performance.html die aktuelle Version der Software herunter, in unserem Fall installer-Intel-CAS-03.01.01.10140400-trial.run und lädt diese anschließend auf den Server hoch.
Der Installer benötigt noch ein paar Debian Pakete um ausgeführt werden zu können:
apt-get install gcc make linux-headers-3.16.0-4-all-amd64
Anschließend kann man die Installation durch Ausführen der .run Datei starten.
chmod u+x installer-Intel-CAS-03.01.01.10140400-trial.run
./installer-Intel-CAS-03.01.01.10140400-trial.run
Dabei wird ein Kernel Modul gebaut. Ein reboot ist nicht erforderlich.
Jetzt muss der Intel Cache Accelerator noch konfiguriert werden. Zuvor haben wir eine 256 GB Kingston KC400 Business SSD im Server installiert.
Cache im write-back mode auf die neu hinzugefügte SSD setzen – da es sich nur um ein Testsystem handelt, haben wir ausnahmsweise die bei einer SSD nicht empfohlene write-back Methode gewählt. Die Vor- und Nachteile können in der Intel Dokumentation nachgelesen werden. Nach Quick Guide wird der write-back mode empfohlen.
casadm –start-cache –cache-device /dev/sda –force –cache-mode wb
Jetzt das Cache Device dem entsprechenden Software RAID Array zuschlüsseln – das funktioniert in der Form aber nur auf Devices, die nicht in Nutzung sind, daher vorher das Device unmounten – in unserem Fall /var/www:
umount /var/www
casadm –add-core –cache-id 1 –core-device /dev/md2
mount -a
Nachdem das Cache Device eingerichtet wurde ändert sich die Bezeichnung des Devices von md2 auf /dev/intelcas1-1. Dazu ein Screenshot aus der Dokumentation von Intel:
Das Ganze sieht dann quasi so aus:
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/md1 92G 1,3G 86G 2% /
udev 10M 0 10M 0% /dev
tmpfs 6,3G 8,6M 6,3G 1% /run
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/md0 922M 32M 827M 4% /boot
/dev/intelcas1-1 46G 52M 44G 1% /var/www
Wichtiger Hinweis: Bei einem Neustart des Servers startet das Cache Device nicht automatisch mit. Man muss dieses daher immer neu hinzufügen. Etwas umständlich aber leider notwendig.
nano /etc/init.d/cas
Dort folgendes eintragen:
#!/bin/sh
casadm -S -i 1 -d /dev/sda -r
casadm -S -i 1 -d /dev/sda -c wb
casadm -A -i 1 -d /dev/md2
mount /dev/md2 /var/www
Hinweis: Beim Betrieb des Cache Arrays im write-back Modus kann es sein, dass wenn der Server einfach ausgeschalten oder neugestartet wird, nicht alle Daten aus dem Cache auf die HDD geschrieben wurden. Daher muss vor erneutem Einbinden des Caches zunächst ein Recovery ausgeführt werden. Dieser bewirkt, dass die noch nicht aus dem Cache geschriebenen Daten auf die Festplatte geschrieben werden.
Anschließend die Schreibrechte setzen und das Script im Autostart hinzufügen.
chmod u+x /etc/init.d/cas
ln /etc/init.d/cas /etc/rc2.d/S99cas
Damit ist die Einrichtung abgeschlossen.
Installation von Intel Cache Acceleration – KVM/LXC Virtualisierung mit Proxmox
Als Basis haben wir eine Standard Proxmox Installation herangezogen mit Software RAID 1 – so wie wir diese über unseren auto Installer im Dedicated Server Administrationspanel anbieten.
Leider ist es so, dass es ab Kernel 4.3 umfassende Änderungen gab. Beim Bauen des entsprechenden Kernel Moduls über den Installer kommt es daher zu den Fehler „error: too many arguments to function ‚bio_endio‘„. Abhilfe schafft hier leider nur ein Kernel Downgrade auf 4.2. Intel wird das sicher noch patchen in einer der nächsten Versionen.
apt-get remove pve-kernel-4.4.40-1-pve
apt-get install pve-kernel-4.2.8-1-pve pve-headers-4.2.8-1-pve
reboot
Anschließend kann man die Installation durch Ausführen der .run Datei starten.
chmod u+x installer-Intel-CAS-03.01.01.10140400-trial.run
./installer-Intel-CAS-03.01.01.10140400-trial.run
Dabei wird ein Kernel Modul gebaut. Ein reboot ist nicht erforderlich.
Jetzt muss der Intel Cache Accelerator noch konfiguriert werden. Zur sauberen Installation von Proxmox im Software RAID 1 haben wir die SSD wieder abgezogen, diese wird jetzt natürlich wieder angeschlossen.
Cache im write-back mode auf die neu hinzugefügte SSD setzen – da es sich nur um ein Testsystem handelt, haben wir ausnahmsweise die bei einer SSD nicht empfohlene write-back Methode gewählt.
casadm –start-cache –cache-device /dev/sda –force –cache-mode wb
Jetzt müssen wir das Cache Device noch dem Proxmox LVM zuweisen. Dazu zuerst alle VMs stoppen und anschließend das /var/lib/vz Verzeichnis unmounten. Dann muss der Mountpoint in der /etc/fstab noch auf das neue Cache Device angepasst werden.
umount /var/lib/vz
casadm –add-core –cache-id 1 –core-device /dev/pve/data
nano /etc/fstab
Den mount Eintrag /dev/mapper/pve-data auskommentieren.
mount /dev/intelcas1-1 /var/lib/vz
Nachdem das Cache Device eingerichtet wurde ändert sich die Bezeichnung des Devices von /dev/mapper/pve-data auf /dev/intelcas1-1.
Wichtiger Hinweis: Bei einem Neustart des Servers startet das Cache Device nicht automatisch mit. Man muss dieses daher immer neu hinzufügen. Etwas umständlich aber leider notwendig.
nano /etc/init.d/cas
Dort folgendes eintragen:
#!/bin/sh
casadm -S -i 1 -d /dev/sda -r
casadm -S -i 1 -d /dev/sda -c wb
casadm -A -i 1 -d /dev/pve/data
mount /dev/intelcas1-1 /var/lib/vz
Hinweis: Beim Betrieb des Cache Arrays im write-back Modus kann es sein, dass wenn der Server einfach ausgeschalten oder neugestartet wird, nicht alle Daten aus dem Cache auf die HDD geschrieben wurden. Daher muss vor erneutem Einbinden des Caches zunächst ein Recovery ausgeführt werden. Dieser bewirkt, dass die noch nicht aus dem Cache geschriebenen Daten auf die Festplatte geschrieben werden.
Anschließend die Schreibrechte setzen und das Script im Autostart hinzufügen.
chmod u+x /etc/init.d/cas
ln /etc/init.d/cas /etc/rc2.d/S99cas
Damit der Autostart der Proxmox VMs auch weiterhin funktioniert, muss Proxmox warten, bis der Mount erfolgreich mit dem Cache initialisiert wurde. Dazu unter
nano /usr/bin/pvesh
die Zeile
sleep(20);
unter optmacht ergänzen. Das Ganze sieht dann in etwa so aus:
my $optmatch;
do {
$optmatch = 0;
if ($cmd) {
if ($cmd eq ‚–noproxy‘) {
$cmd = shift;
$disable_proxy = 1;
$optmatch = 1;
} elsif ($cmd eq ‚–nooutput‘) {
# we use this when starting task in CLI (suppress printing upid)
# for example ‚pvesh –nooutput create /nodes/localhost/stopall‘
$cmd = shift;
$opt_nooutput = 1;
$optmatch = 1;
sleep(20);
}
}
} while ($optmatch);
Performance Testlauf
Getestet haben wir das System mit nachfolgenden Referenzbefehlen:
Festplatte
sysbench –test=fileio –file-total-size=5G prepare
sysbench –num-threads=1 –test=fileio –file-total-size=6G –file-test-mode=rndrw –max-time=300 –max-requests=0 –file-extra-flags=direct run
Ohne CAS: 0.2722 Sekunden
Mit CAS – normale Partition: 0.0039 Sekunden
Ohne CAS – KVM virtuelle Maschine: 0.1313 Sekunden
Mit CAS – KVM virtuelle Maschine unter 256 GB: 0.1231 Sekunden
Mit CAS – KVM virtuele Maschine über 256 GB: 0.0138 Sekunden
Ohne CAS – LXC virtuelle Maschine: 0.0008 Sekunden
Mit CAS – LXC virtuelle Maschine: 0.0062 Sekunden
Festplatte fsync
sysbench –num-threads=1 –test=fileio –file-fsync-freq=1 –file-num=1 –file-total-size=16384 –file-test-mode=rndwr run
Ohne CAS: 556.0433 Sekunden
Mit CAS – normale Partition: 35.9658 Sekunden
Ohne CAS – KVM virtuelle Maschine: 360.5552 Sekunden
Mit CAS – KVM virtuelle Maschine unter 256 GB: 47.9616 Sekunden
Mit CAS – KVM virtuele Maschine über 256 GB: 48.0677 Sekunden
Ohne CAS – LXC virtuelle Maschine: 1244.2452 Sekunden
Mit CAS – LXC virtuelle Maschine: 70.4643 Sekunden
Festplatte write
dd if=/dev/zero of=./test.file bs=1M count=1000 oflag=direct
Ohne CAS: 141 MB/s
Mit CAS – normale Partition: 258 MB/s
Ohne CAS – KVM virtuelle Maschine: 2.0 GB/s
Mit CAS – KVM virtuelle Maschine unter 256 GB: 241 MB/s
Mit CAS – KVM virtuele Maschine über 256 GB: 1.2 GB/s
Ohne CAS – LXC virtuelle Maschine: 109 MB/s
Mit CAS – LXC virtuelle Maschine: 3.0 GB/s
dd if=/dev/zero of=/root/testfile bs=512 count=4000 oflag=direct
Ohne CAS: 5,6 MB/s
Mit CAS – normale Partition: 20,0 MB/s
Ohne CAS – KVM virtuelle Maschine: 3.4 MB/s
Mit CAS – KVM virtuelle Maschine unter 256 GB: 4.4 MB/s
Mit CAS – KVM virtuele Maschine über 256 GB: 4.4 MB/s
Ohne CAS – LXC virtuelle Maschine: 2,6 MB/s
Mit CAS – LXC virtuelle Maschine: 22.6 MB/s
dd if=/dev/zero of=fileio bs=1M count=1000 oflag=direct
Ohne CAS: 129 MB/s
Mit CAS – normale Partition: 250 MB/s
Ohne CAS – KVM virtuelle Maschine: 610 MB/s
Mit CAS – KVM virtuelle Maschine unter 256 GB: 433 MB/s
Mit CAS – KVM virtuele Maschine über 256 GB: 6.8 GB/s
Ohne CAS – LXC virtuelle Maschine: 3.6 GB/s
Mit CAS – LXC virtuelle Maschine: 3.0 GB/s
Festplatte read
dd if=fileio of=/dev/null bs=1M count=1000
Ohne CAS: 142 MB/s
Mit CAS – normale Partition: 555 MB/s
Ohne CAS – KVM virtuelle Maschine: 394 MB/s
Mit CAS – KVM virtuelle Maschine unter 256 GB: 2.3 GB/s
Mit CAS – KVM virtuele Maschine über 256 GB: 2.4 GB/s
Ohne CAS – LXC virtuelle Maschine: 5.8 GB/s
Mit CAS – LXC virtuelle Maschine: 4.3 GB/s
Festplatten read mit hdparm
hdparm -tT –direct /dev/md1
Ohne CAS: cached reads: 256.06 MB/s – disk reads: 127.78 MB/s
Mit CAS – normale Partition: cached reads: 320.07 MB/s – disk reads: 276.52 MB/s
Ohne CAS – KVM virtuelle Maschine: cached reads: 1067.56 MB/s – disk reads: 1137.53 MB/s
Mit CAS – KVM virtuelle Maschine unter 256 GB: cached reads: 962.23 MB/s – disk reads: 5446.52 MB/s
Mit CAS – KVM virtuele Maschine über 256 GB: cached reads: 1005.93 MB/s – disk reads: 5707.55 MB/s
Ohne CAS – LXC virtuelle Maschine: leider nicht anwendbar in LXC
Mit CAS – LXC virtuelle Maschine: leider nicht anwendbar in LXC
Festplatten I/O mit ioping
ioping /dev/md1
Ohne CAS: 10 requests completed in 9.53 s, 56 iops, 227.3 KiB/s | min/avg/max/mdev = 4.38 ms / 17.6 ms / 47.9 ms / 11.3 ms
Mit CAS – normale Partition: 10 requests completed in 9.25 s, 95 iops, 383.1 KiB/s | min/avg/max/mdev = 852 us / 10.4 ms / 21.6 ms / 5.82 ms
Ohne CAS – KVM virtuelle Maschine: 10 requests completed in 9.45 s, 94 iops, 376.8 KiB/s | min/avg/max/mdev = 150 us / 10.6 ms / 78.5 ms / 23.2 ms
Mit CAS – KVM virtuelle Maschine unter 256 GB: 10 requests completed in 9.32 s, 2.88 k iops, 11.2 MiB/s | min/avg/max/mdev = 167 us / 347 us / 1.27 ms / 336 us
Mit CAS – KVM virtuele Maschine über 256 GB: 10 requests completed in 9.40 s, 2.44 k iops, 9.52 MiB/s | min/avg/max/mdev = 154 us / 410 us / 1.40 ms / 480 us
Ohne CAS – LXC virtuelle Maschine: leider nicht anwendbar in LXC
Mit CAS – LXC virtuelle Maschine: leider nicht anwendbar in LXC
Leider ist es so, dass sobald ein Virtualisierungslayer dazwischen ist wie z.B. KVM oder LXC man sieht, dass bei gleichen Files die geschrieben oder gelesen werden trotz des direct flags ein zusätzlicher Cache zwischengeschaltet wird. Bei ioping werden die IO-Anfragen natürlich nicht cached, daher bekommt man hier schon deutlich zuverlässigere Werte. Man sieht, dass der Cache sich offensichtlich die Daten direkt über den Systemkernel abholt mit Hilfe des entsprechenden Kernel Modules. Daher gibt es kaum einen Unterschied bei IO-Ping zwischen einer VM deren Container kleiner als die SSD Größe ist im Vergleich zu einer VM deren Containerfile größer als die SSD Größe ist. Das ist sehr gut, denn so ist es nicht erforderlich die SSD Größe darauf auszulegen wie groß die größte KVM VM ist. Insgesamt ist es aber wohl abhängig von der Systemumgebung ob die Performancesteigerung die von Intel als Referenz angeführt wird auch wirklich erreicht wird. Besonders interessant kann dies aber für die Beschleunigung von I/O Anfragen sein um die Basis-Storage signifikant zu entlasten.
Nett ist zudem die Auswertung mit dem Command casadm –stats -i 1 – diese liefert umfangreiche Details zur Cache Nutzung.
Fazit
Schade, dass man den SSD Cache nur auf einem Festplatten Mount bzw. weiterführenden Festplatten Arrays anwenden kann. Damit ist es leider nicht möglich ein direkt auf die Festplatten installiertes Betriebssystem nachträglich auf die Intel Cache Acceleration umzurüsten. Sehr schön hingegen ist, dass man ohne großen Administrativen Aufwand einen SSD Cache in einem virtualisierten System integrieren kann ohne eine Neuinstallation durchführen zu müssen. Zudem kann man, wenn man pro VM ein LVM Volumen verwendet, den SSD Cache sehr gut steuern und nur für bestimmte virtuelle Maschinen freigeben. Die Software ist zudem sehr gut dokumentiert und bietet neben den in unseren Testlauf eingesetzten Caching Varianten noch eine Vielzahl anderer Möglichkeiten zum Beispiel nur eine Partition einer SSD als Cache zu verwendet. Man kann so zum Beispiel ein großes SSD Array als HDD Beschleuniger und zusätzlich durch entsprechende Partitionierung zum Beispiel als Systempartition verwenden.
Die Software scheint schon sehr ausgereift zu sein und ist mit 51 $ für den Funktionsumfang ein Schnäppchen. Zudem kann man sehr einfach den Cache nach Bedarf auch wieder deaktivieren. Anschauen und testen lohnt sich hier sicherlich, es wird aber nicht auf jeden Anwendungsfall passen.
