Kostengünstige Virtuelle Speicher-Pools im Petabyte-Bereich mithilfe von MARS. GUUG 2017 Vortrag von Thomas Schöbel-Theuer

Transkript

1 Kostengünstige Virtuelle Speicher-Pools im Petabyte-Bereich mithilfe von MARS GUUG 2017 Vortrag von Thomas Schöbel-Theuer 1

2 Virtuelle Speicher-Pools: Agenda Skalierungs-Eigenschaften von Speicher-Architekturen Motivation: Kosten Flexibles MARS Sharding + Cluster-on-Demand Last-Balancierung mittels Hintergrund-Daten-Migration Aktueller Status / Zukunfts-Pläne

3 Schlecht skalierende Architektur: Big Cluster User 1 User 2 User 3 User 4 User 5 User 6 User 7 User 8 User 9 User 10 User 11 User 12 User 13 User User Internet O(n*k) Frontend 1 Frontend 2 Frontend 3 Frontend 4 Frontend 5 Internes Speicher (oder Dateisystem) Netzwerk Storage 1 Storage 2 Storage 3 Storage 4 Storage 5 Frontend 6 Storage Frontend 999 O(n^2) ECHTZEIT-Zugriff cross-bar Storage 999 x 2 für Georedundanz

4 Gut skalierende Architektur: Sharding User 1 User 2 User 3 User 4 User 5 User 6 User 7 User 8 User 9 User 10 User 11 User 12 User 13 User User Internet O(n*k) Storage + Frontend 1 Storage + Frontend 2 Storage + Frontend 3 Storage + Frontend 4 Storage + Frontend 5 Storage + Frontend 6 ++ lokale Skalierbarkeit: spare RAID slots,... Kleineres Replikations-Netzwerk für Batch-Migration O(n) +++ Traffic-Shaping möglich big scale out +++ Storage + Frontend 999 => Methode skaliert wirklich auf Petabytes x 2 für Georedundanz

5 Kosten (nicht-georedundante Variante) Big Cluster: Typisch RAID-10 zur Ausfall-Kompensation Platten: > 200% Zusätzliche CPUs und RAM für Storage-Knoten Zusätzlicher Strom- Verbrauch Zusätzliche HE Sharding: oft reicht lokales RAID-6 Platten: < 120% Hardware RAID Controller mit BBU-Cache auf 1 Karte Weniger Strom Weniger HE

6 Kosten (georedundant => mit Langstrecke möglich) Big Cluster: 2x RAID-10 zur Ausfall- Kompensation (kleiner geht nicht wegen längeren RZ-Ausfall-Szenarien) Platten: > 400% Zusätzliche CPUs und RAM für Storage-Knoten Zusätzlicher Strom- Sharding: 2 x lokales RAID-6 Platten: < 240% Hardware RAID Controller mit BBU-Cache Weniger Strom Weniger HE Verbrauch Zusätzliche HE

7 Flexibles MARS Sharding + Cluster-on-Demand VM1 VM2 VM3 VM4 VM5 Hypervisor ISCSI oder MARS remote device Hypervisor LV1 LV2 LV3 LV4 LV5 RAID RAID Die Hypervisoren können sowohl in Client- als auch Server-Rollen und bevorzugt auch lokal arbeiten

8 Flexible MARS Hintergrund-Migration VM1 VM2 VM3 VM4 VM5 Hypervisor ISCSI oder MARS remote device Hypervisor LV1 LV2 LV3 primary MARS Replikation LV3 secondary LV4 LV5 RAID Beliebige # Replikate k=1,2,3, dynamisch zur Laufzeit an beliebigen Orten RAID => ein Hypervisor kann gleichzeitig Quelle oder Ziel verschiedener LV-Replikationen sein

9 MARS aktueller Status MARS Sourcecode unter GPL + Docu: github.com/schoebel/mars mars manual.pdf ~ 100 Seiten mars0.1stable produktiv auf Kundendaten seit 02/2014 Rückgrat des 1&1 Geo-Redundanz Features MARS Status Feb 2017: > 2000 Server (Shared Hosting + Datenbanken) > 2x8 Petabyte brutto ~ 10 Milliarden inodes in > 3000 xfs Instanzen > 25 Millionen Betriebsstunden Neues internes Efficiency Projekt Höhere interne LXC Container Verdichtung pro 1 Hypervisor Neuer öffentlicher Branch mars0.1b mit vielen neuen Features, z.b. massen-skalierbares Clustering, Socket Bundling, Remote Device, etc mars0.1b aktuell im ALPHA-Stadium 9

10 MARS Zukunfts-Pläne Automatische Last-Balancierung TBD Separate Implementation oder libvirt / Openstack Plugins? Virtuelle LVM-artige Speicher + VM Pools Physisch ge-shardete Pools WIP 1&1 clustermanager cm3 und/oder libvirt Plugin? Erledigt: MARS anstatt DRBD Kollaboration gesucht => Gelegenheiten für andere OpenSource-Projekte! 10