Menü Schließen

Proxmox 4 – EXT4 – VIRTIO – SCSI – RAW – QCOW2 Performance Vergleich

Proxmox VE Logo

Proxmox als Lösung für LXE und KVM Virtualisierung bietet eine Vielzahl von Einstellungsmöglichkeiten. Darunter auch verschiedene Optionen für virtuelle Festplatten. In diesem Zusammenhang interressiert mich die Wahl des Bus (VirtIO bzw. SCSI) und des Formates der virtuellen Festplatte (raw, qcow2, vmdk), sowie deren Cache-Optionen (kein Cache, Direct sync, Write Through, Write back, Write back (unsicher) ). Weiterhin werde ich kurz die Vor- und Nachteile des Formates sowie deren Cache-Optionen aufzählen

Testhardware

Für den Test stand mir ein HP Elitebook 8460p mit folgender Ausstattung zur Verfügung:

  • Intel i5 2520M 2Core CPU
  • 16GB DDR3 RAM
  • OS Disk = OSC Vertex 2 mit 120GB
  • VM Disk = Intel 320 SSD mit 320GB

Debian Jessie kam als Betriebssystem auf dem Host zum Einsatz. Proxmox wurde in der aktuellen PVE-Version 4.4-12, mit Kernel 4.4.35-2-pve und KVM Qemu 2.7.0, nachinstalliert (non-subscription).

Jede virtuelle Maschine ist vom Typ KVM und ebenfalls mit Debian Jessie als geführte Intallation frisch installiert. Ext4 wurde als Dateisystem verwendet. Das Testgerät führt keine weiteren Dienste aus die den Test hätten beeinflussen können. Die SSD für die virtuellen Maschinene ist wie folgt eingebunden:

# ext4 noatime,nodiratime,errors=remount-ro 0 2

Diskformat RAW

Bei der Verwendung des RAW-Formates  werden die Daten als Plain Binary Image abgelegt. Sie entsprechen denen der tatsächlichen der virtuellen Festplatte. Somit ist ein Image im RAW-Format immer so groß wie der gesamten Speicher für die virtuelle Festplatte konfiguriert wurde. Das Format ist sehr portabel und kann auch in anderen Systemen wie Virtualbox eingebunden werden. Es bestitzt im Gegensatz zu QCOW (2) keinen Overhead.

Diskformat QCOW2

QCOW2 präsentiert die 2. Generation das Dateiformates für Diskimages. Verwaltet wird es vom virtuellen Machine Monitor, QEMU. Das Copy-On-Write Format besitzt eine Vielzahl an speziellen Funktionen. Diese sind unter anderen:

  • Multiple-Snapshotfunktion im laufenden Betrieb
  • Diskgröße wächst mit steigender Anzahl an zu speichernden Daten
    • Überprovisionierung möglich
  • AES Verschlüsselung
  • ZLIB Kompression
  • kein direkter Mount wie bei RAW möglich
  • leichter Overhead durch Zusatzfunktionen im Vergleich zu RAW

KVM Cache Optionen

KVM (Kernel-based Virtual Machine) bietet diverse Optionen zur Verwendung eines Caches für virtuelle Maschinen. Nachfolgend die Möglichkeiten und deren Bedeutet.

KVM Cache – none

Mit dieser Option ist der meiste Page Cache deaktiviert und der Write Cache für die Festplatte der VM aktiviert. Damit ist die Performance für Anwendungen in der VM gut, aber die Daten sind im Falle eines Powerfehlers nicht geschützt. Diese Option ist für temporäre Daten, bei denen ein Verlust nicht so schlimm ist, zu empfehlen.

KVM Cache – writethrough

MIt dieser Option ist der Cache des Hosts aktiviert, aber der Diskcache der VM deaktiviert. Dadurch werden die Daten direkt an den Host gesendet, der diese vor dem Schreiben zwischenspeichert. Dieser Mode sichert die Datenintegrität, wodurch die Read-Performance generell besser als die Write-Performance ist.

KVM Cache – writeback

Mit dieser Option ist sowohl der Host Cache als auch der Disk Write Cache der VM aktiviert. Damit sit die I/O Performance gut, aber die Daten sind nicht gegen einen Powerfehler gesichert, da sie erst in den „Zwischenspeicher“ geschrieben werden, bevor sie auf das Blockdevice abgespeichert werden.

KVM Cache – directsync

Mit dieser Optione werden die Schreiboperationen in der VM an den Host gesendet und erst wenn sie erfolgreich geschrieben wurden zurück gemeldet. Diese Option ist ähnlich der writehrough Option, jedoch ohne die Nutzung des Host Cache.

KVM Cache – unsafe

Mit dieser Option werden Cache-Transfer-Operationen komplett ignoriert. Sie ist ähnlich der writeback Option. Auch diese Option ist nur für temporäre oder nicht wichtige Daten geeignet, wie z.B. Gastinstallationen.

Testablauf

Die virtuellen Maschinen sind alle grundlegend wie folgt konfiguriert:

  • Bustyp = SCSI (VirtIO SCSI)
  • 32GB  HDD
  • 1 CPU 1 Core KVM Standard
  • 1024 GB RAM

Je Test wurde eine 32GB große virtuelle Maschine mit Debian und ext4 erstellt. Als Kernel kam der dato aktuelle von Jessie in Version 3.16.0-4-amd64 zum Einsatz. Es gab keine besonderen Tuningmaßnahmen (Dateisystem, Kernel etc.). Insgesamt wurden 10 virtuelle Testmaschinen erstellt auf denen jeweils 9 Performancetests ausgeführt wurden.

  1. raw (Bus: VirtIO SCSI und VirtIO)
    1. Standardeinstellung (kein Cache)
    2. direct sync
    3. write through
    4. write back
    5. write back (unsicher)
  2. qcow2 (Bus: VirtIO SCSI und VirtIO)
    1. Standardeinstellung (kein Cache)
    2. direct sync
    3. write through
    4. write back
    5. write back (unsicher)

Nach jedem Einzeltest wurde die fio Testdatei gelöscht. Nach jedem Wechsel des Disktyp wurde die alte virtuelle Maschine gelöscht und die neue mit Debian neuinstalliert. Die Test wurden mit dem Tool fio und ioping ausgeführt. Aus zeitlichen Gründen wurde jeder Test nur einmal durchlaufen.

FIO und IOPing Tests

1. fio Random Write Test der IOP/s – viele kleine Dateien

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=256 –size=4G —readwrite=randwrite

IOPSBW in KB/sCPU User in %CPU System in %Runtime in ms0100000200000300000400000500000600000

1.1 fio Random write Test der IOP/s - viele kleine Dateien (SCSI)

IOPSBW in KB/sCPU User in %CPU System in %Runtime in ms050000100000150000200000

1.2 fio Random write Test der IOP/s - viele kleine Dateien (VIRTIO)

2. fio Random Read Test der IOP/s – viele kleine Dateien

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=256 –size=4G —readwrite=randread

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0100000200000300000400000

2.1 fio Random Read Test der IOP/s - viele kleine Dateien (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0200000400000600000

2.2 fio Random Read Test der IOP/s - viele kleine Dateien (VIRTIO)

3. fio Sequential Write Test der IOP/s – eine große Datei

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=256 –size=4G —readwrite=write

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms050000100000150000200000250000300000

3.1 fio Sequential write Test der IOP/s - eine große Datei (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0200000400000600000

3.2 fio Sequential write Test der IOP/s - eine große Datei (VIRTIO)

4. fio Sequential Read Test der IOP/s – eine große Datei

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4k –iodepth=256 –size=4G —readwrite=read

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0100000200000300000400000500000

4.1 fio Sequential Read Test der IOP/s - eine große Datei (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms02000004000006000008000001000000

4.2 fio Sequential Read Test der IOP/s - eine große Datei (VIRTIO)

5. fio Random Write Test des Throughput – viele kleine Dateien

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4M –iodepth=256 –size=10G —readwrite=randwrite

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms050000100000150000200000250000

5.1 fio Random Write Test des Throughput - viele kleine Dateien (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms050000100000150000200000250000300000

5.2 fio Random Write Test des Throughput - viele kleine Dateien (SCSI)

6. fio Random Read Test des Throughput

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4M –iodepth=256 –size=10G —readwrite=randread

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0100000200000300000400000500000

6.1 fio Random Read Test des Throughput (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0100000200000300000400000500000

6.2 fio Random Read Test des Throughput (VIRTIO)

7. fio Sequential Write Test des Throughput – eine große Datei

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4M –iodepth=256 –size=10G —readwrite=write

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms050000100000150000200000250000

7.1 fio Sequential Write Test des Throughput - eine große Datei (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms050000100000150000200000250000

7.2 fio Sequential Write Test des Throughput - eine große Datei (VIRTIO)

8. fio Sequential Read Test des Throughput – eine große Datei

# fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=test –bs=4M –iodepth=256 –size=10G —readwrite=read

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0100000200000300000400000500000

8.1 fio Sequential Read Test des Throughput - eine große Datei (SCSI)

IOPSBW in KB/sCPU UserCPU SystemRuntime in ms0100000200000300000400000500000

8.2 fio Sequential Read Test des Throughput - eine große Datei (VIRTIO)

9. IOPing Latenztest

# ioping -c 10 .

9.1 IOPing -Latenztest (SCSI)

9.2 IOPing -Latenztest (VIRTIO)

Anmerkungen

IO-Thread

Proxmox 4 Disk IO-Thread
Proxmox 4 Disk IO-Thread

Unter Proxmox 4.x kann für die virtuelle Festplatte zusätzlich die Option IO-Thread aktiviert werden. Ein paar Punkte dazu:

  • in QEMU =1 IO-Thread je Diskcontroller
  • in VirtIO-blk gibt es 1 Controller je Disk
  • in VirtIO-SCSI by default ist 1 Controller für X Disk, IO-Thread wird somit zwischen den Disks geteilt
  • unter VirtIO-SCSI-Single ist 1 VirtIO-SCSI Controller für 1 Disk zuständig

ToDo

  • Auswertung formulieren
  • weitere Test mit z.B. XFS als Dateisystem
  • weitere Test mit IO-Thread aktiviert

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert