DFN-Forum 2016: RZ Storage für die Virtualisierung- OSD auf bcache: 240MB/s - Kleinere Aussetzer...

DFN-Forum 2016:RZ Storage für die Virtualisierung

Konrad Meier, Martin Ullrich, Dirk von Suchodoletz

31.05.2016 – Rechenzentrum Universität Rostock

04.07.16 9. DFN-Forum in Rostock 2

Ausgangslage

Praktiker-Beitrag, deshalb Fokus auf Problemlage und Ergebnisse / Erkenntnisse- Beschaffung neuen Speichersystems bereits in Ausschreibung

- Übergangslösung für Problem für ca. halbes Jahr gesucht

- Abt. eScience für Strat.entwicklung, bwCloud, HPC

- Interessanter „Case“ im RZ-Geschäft, da Storage inzwischen sehr zentral

- Storage im Übergang zu SSD/Flash aber All-Flash noch nicht bezahlbar

- Flash attraktiver Beschleuniger/Cache

- Bisher keine Erfahrung (wenig explizite Erfolgsberichte, jedoch viele Hinweise auf deutliche Verbesserungen), Probleme jedoch so groß, dass Risiko eines Scheiterns akzeptabel (Abschätzung Umbauaufwand etc.)


Damalige Ausgangssituation

Zwei ESX-Cluster im Einsatz- Virtualisierung 1 Altsystem,

klassiches FC-Setup

- Virtualisierung 2 modernes System hoher Performance als zukünftiges Modell

Storage: Klass. Massen-speicher (nicht virt.-optimiert)

Für einfache Migration der VMs Einsatz von NFSv3

Realisiert über Linux-Fileserver- Fibrechannel-Infrastruktur

- LUNs mit Multipath-Anbindung als Blockdevices mit ext4


Mehrfache Ausfälle des NFS-Kopfes mit unklaren Ursachen- Hohe Latenzen seit einigen Wochen

- Last sollte aufgrund Semesterpause eher gering sein

- Keine bekannten Veränderungen im Lastprofil der vorhandenen VMs

Aufschaukeleffekte- NFS „staut“ lange Queues auf (async Konfiguration)

- Bei Crashes, je nach Gast-OS ziemlich kaputte FS

- Linux-Gäste setzen bei langen Latenzen (virt.) Blockdevice ro, NTFS toleranter

- Ungeschickte Konfigurationen in VMs verschlimmern Zustand

Ergebnisse von fio (iotop, htop ebenso betrachtet)

Problem: Schlechte Storage Performance

lat(usec): 250=26.96%, 500=72.49%, 750=0.29%, 1000=0.07%lat(msec): 2=0.09%, 4=0.08%, 10=0.01%, 20=0.01%, 50=0.01%lat(msec): 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 2000=0.01%lat(msec): >=2000=0.01%


Auswahl des Caching-Ansatzes

Technologische Basis: Linux-Kernel

Betrachtete Alternativen- FlashCache (Facebook)

- EnhanceIO (STEC)

- dm-cache (Kernel-Modul)

- bcache (Kernel-Modul seit 3.11 ...)

Kein Tiering, sondern Caching (heiße Daten doppelt)

Alle können Write-Caching

Sollten als Kernelmodul enthalten sein („Qualitätsindex“, da schon FibreChannel Multipathing mit Device-Mapper, dm-cache ausgeschlossen)


Umsetzung von zwei Performance-Boostern: RAM für Read-Cache auf OS-Ebene, bcache für Serialisierung/Write

Überlegungen zur SSD-Konfiguration: RAID 10 für Ausfallsicherheit und Geschwindigkeit

Sehr großzügige Abschätzung der TBW nach oben

Serverkonfiguration

Sizing der Cache-Größe und Geschwindigkeit (SATA-IF limitierender Faktor, kein PCIe-Device, da sehr teuer und flexible Nachnutzung geplant)

Einbau der Cache-Platten direkt im Server


Einrichtung SSD-Cache

Da keine Erfahrung vorhanden Zwei-Server-Lösung gewählt- High-IO VMs auf eigenes

System zur Entlastung des Gesamt-Storage

- Rest incl. NFS-File-IO auf bcache Server

Planung des Ablaufs mit Downtime erforderlich- Kopierzeit und Platz für

Zwischenlager einkalkulieren

- Verschärft durch teilweise laufenden Betrieb


Keine Lösung erlaubt einfaches „Davorhängen“- Konsequenz: Daten müssen immer komplett umkopiert werden

- Qualität der Anleitungen leider gemischt, Best-Practice Guides zur Konfiguration teilweise widersprüchlich

Insgesamt 10 Cache Devices angelegt- bcache Tools müssen installiert sein

- Kein Verschnitt, da dynamisch verwaltet

- Ergebnis: 10 Dateisysteme; 10 NFS Exports (Zahl der NFS-Server in diesem Zuge deutlich erhöht)

- Sicherheitsmaßnahme um ein großes Dateisystem zu vermeiden

- Umstieg von XFS auf EXT4 aufgrund von Problemen im Vorgängersystem

- Auf jedem NFS Export liegen mehrere VMs

Einrichtung SSD-Cache


Einrichtung eines speziellen, neuen Blockdevices aus Caching und Backing Storage- Vorteil SSDs können ausfallen, ohne komplette Rekonfiguration der

Maschine zu triggern

Wissenschaft für sich, sehr viele Optionen via /proc Interface zugänglich

Write Back als zentrales Feature- Daten werden immer auf die SSDs geschrieben

- Kein Sequential Cut-Off eingestellt: Auch sequenzielle Schreiboperationen werden in den Cache geschrieben

Festlegung der möglichen Menge von „Cache dirty“

bcache Konfiguration


Weitere mögliche Performance Tweaks- writeback mode

- no seq. read cutoff

- no access time thresholds

bcache Konfiguration cont.

tee /sys/block/bcache*/bcache/cache_mode <<< writebacktee /sys/block/bcache*/bcache/sequential_cutoff <<< 0tee /sys/fs/bcache/*/congested_read_threshold_us <<< 0tee /sys/fs/bcache/*/congested_write_threshold_us <<< 0


Via /proc Schnittstelle- Beispiel für Cache-Dirty

Bcache-Monitoring (Cache Dirty)


Cache-Hit Ratio- Verschiedene Einzel-Devices mit unterschiedlichen VMs

Bcache-Monitoring (Cache Hits)


Via S.M.A.R.T. Schnittstelle (Linux smartctl)- Aktualisierung via cron-job

Monitoring SSD-Health


Mut zu schnellen Entscheidungen nach Analyse und Abwägung Alternativen ausgezahlt- Gute VM Performance (deutlich verbesserte Latenz)

- bcache lief bis zum Ende ohne Probleme, keine Ausfälle

- Web-Monitoring

- TBW-“Verbrauch“ deutlich niedriger als kalkuliert

Hat „Halbwertszeit“ des alten Setups deutlich verlängert (trotzdem will keiner die neuen Systeme missen)

„Richtige“ Mitarbeiter zur Stelle

Fazit

lat(usec): 250=99.89%, 500=0.08%, 750=0.01%, 1000=0.01%lat(msec): 2=0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=0.01%lat(msec): 100=0.01%


Einsatz bwCloud

Wegen guter Erfahrungen im ESX-Betrieb auch für andere Einsatz-bereiche mit vergleichbarem Profil getestet

bwCloud Projekt auf Basis von OpenStack- Verteilte Infrastruktur in Baden-

Württemberg für Service- und Science-Cloud für Landes-Hochschulen

- Mischung aus SSD und drehenden Platten scheint attraktiv

- Verschiedene Tests/Experimente (bcache Untersuchungen in Ulm)

Freiburg i. Breisgau

Ulm

Karlsruhe

Mannheim


Einsatz bwCloud

2 SSDs (je 480GB) und 6 HDDs (je 1TB) im Ceph- OSD läuft auf bcache Device

- Ceph aus VM Sicht von Performance her vergleichbar/teils sogar besser als einzelne lokale SSD (solange die aggregierte Last nicht zu hoch)

bcache Ansatz schneller, Performance aus Sicht von Ceph- OSD auf HDD: ~35MB/s

- Journal auf SSD: ~70MB/s

- OSD auf bcache: 240MB/s

- Kleinere Aussetzer sowohl bei Journal als auch bcache Setup (Zuordnung des Fehlers jedoch nicht klar, selten)

Aktuell ein Hit Ratio von ca. 60% bis 80% (bei Reads, die nicht aus dem RAM beantwortet werden)- Vergleichbar mit Werten im referierten ESX-Usecase


Einsatz bwLehrpool

bwLehrpool – Projekt zur Desktop-Virtualisierung, vorgestellt auf letztem DFN-Forum in Lübeck- Speicherung größerer

Mengen/Umfang von VM-Abbildern in Delivery-Server und Proxies

- Subset vorhandener Abbilder benötigt


Papers legen Einsatz für HPC nahe (Usecase aus dem Bereich der Physik)

Evaluation für bwForCluster NEMO in Freiburg bei Erweiterung, falls Bedarf entsteht (größere Setup-Herausforderungen zur Beschleunigung des BeeGFS wegen hoher Bandbreiten auf RAID-Controller)

Möglicher Einsatz HPC

Experimente der Kollegen in Ulm mit bwForCluster JUSTUS- Chemie-Usecase: Sehr schlechte Hit

Ratio wegen langer sequenzieller Writes und Verdrängung

Usecases und Tweaks mit signifikantem Einfluss auf Ergebnis


Weitere Informationen

bwCloud – bw-cloud.org (Dank an die Kollegen in Ulm und Mannheim)

Konrad Meier

Martin Ullrich

Dirk von Suchodoletz

{vorname.nachname}@rz.uni-freiburg.de

DFN-Forum 2016: RZ Storage für die Virtualisierung- OSD auf bcache: 240MB/s - Kleinere Aussetzer...

Documents

Transcript of DFN-Forum 2016: RZ Storage für die Virtualisierung- OSD auf bcache: 240MB/s - Kleinere Aussetzer...