DFN-Forum 2016: RZ Storage für die Virtualisierung Konrad Meier, Martin Ullrich, Dirk von Suchodoletz 31.05.2016 – Rechenzentrum Universität Rostock 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.) 04.07.16 9. DFN-Forum in Rostock 2 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 04.07.16 9. DFN-Forum in Rostock 3 Problem: Schlechte Storage Performance . 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) 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% 04.07.16 9. DFN-Forum in Rostock 4 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) 04.07.16 9. DFN-Forum in Rostock 5 Serverkonfiguration . 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 . 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 04.07.16 9. DFN-Forum in Rostock 6 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 04.07.16 9. DFN-Forum in Rostock 7 Einrichtung SSD-Cache . 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 04.07.16 9. DFN-Forum in Rostock 8 bcache Konfiguration . 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“ 04.07.16 9. DFN-Forum in Rostock 9 bcache Konfiguration cont. Weitere mögliche Performance Tweaks - writeback mode - no seq. read cutoff - no access time thresholds tee /sys/block/bcache*/bcache/cache_mode <<< writeback tee /sys/block/bcache*/bcache/sequential_cutoff <<< 0 tee /sys/fs/bcache/*/congested_read_threshold_us <<< 0 tee /sys/fs/bcache/*/congested_write_threshold_us <<< 0 04.07.16 9. DFN-Forum in Rostock 10 Bcache-Monitoring (Cache Dirty) . Via /proc Schnittstelle - Beispiel für Cache-Dirty 04.07.16 9. DFN-Forum in Rostock 11 Bcache-Monitoring (Cache Hits) . Cache-Hit Ratio - Verschiedene Einzel-Devices mit unterschiedlichen VMs 04.07.16 9. DFN-Forum in Rostock 12 Monitoring SSD-Health . Via S.M.A.R.T. Schnittstelle (Linux smartctl) - Aktualisierung via cron-job 04.07.16 9. DFN-Forum in Rostock 13 Fazit . 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 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% 04.07.16 9. DFN-Forum in Rostock 14 Einsatz bwCloud . Wegen guter Erfahrungen im ESX- Betrieb auch für andere Einsatz- bereiche mit vergleichbarem Profil getestet Mannheim . bwCloud Projekt auf Basis von Karlsruhe OpenStack - Verteilte Infrastruktur in Baden- Württemberg für Service- und Science- Cloud für Landes-Hochschulen Ulm - Mischung aus SSD und drehenden Platten scheint attraktiv Freiburg i. - Verschiedene Tests/Experimente Breisgau (bcache Untersuchungen in Ulm) 04.07.16 9. DFN-Forum in Rostock 15 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 04.07.16 9. DFN-Forum in Rostock 16 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 04.07.16 9. DFN-Forum in Rostock 17 Möglicher Einsatz HPC . 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) . 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 04.07.16 9. DFN-Forum in Rostock 18 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 04.07.16 9. DFN-Forum in Rostock 19.