SlideShare a Scribd company logo
1 of 84
Storage with Ceph
                      Scale-Out made easy




                          Martin Gerhard Loschwitz




© 2013 hastexo Professional Services GmbH. All rights reserved.
Who?
Scalable Storage
2 types of Scalability
Scale-Up
Scale-Up before:
Scale-Up afterwards:
Scale-Up quickly comes
      to its limits
Scale-Out
Scale-Out before:
Scale-Out afterwards:
Scale-Out is hip
Webserver
Databases
Even me!
Storage? Meh.
The Block problem
User Space




 FS
HDD
Blocks for distributed systems?
I don’t think so, Tim!
Object Stores
User Space




                  Objects

FS    FS    FS      FS      FS    FS    FS

HDD   HDD   HDD    HDD      HDD   HDD   HDD
User Space




                  Objects

FS    FS    FS      FS      FS    FS    FS

HDD   HDD   HDD    HDD      HDD   HDD   HDD
Originally a PhD thesis
Object Store
RADOS
Redundant
Autonomic
Distributed
Object
Store
2 Components
OSDs
MONs
Data Placement
MONs
MONs
MONs
MONs
MONs
MONs
MONs
Parallelization
1   2   1   2




                MONs
1   2   1   2




                MONs
1   2   1   2   1   2   1   2




                        MONs
MONs
CRUSH
Controlled
Replication
Under
Scalable
Hashing
Rack aware
Clients?
Block Device Driver
RBD (RADOS Block Device)
rbd
Qemu-RBD
ReSTful API
radosgw
Compatible with S3 and Swift
POSIX file system
CephFS
Still Beta!
Need a special client?
librados
Use cases
Gigantic Storage
40TB, 3 replicas = € 21.000
Virtualization
iSCSI Storage
Cloud
OpenStack
live demo
24. May 2013

      OpenStack DACH Day 2013

http://openstackdach2013.eventbrite.com
Special thanks goes to:

Sage Weil (Twitter: @liewegas)
      & crew for Ceph

  Inktank (Twitter: @inktank)
       for the Ceph logo
1   2      1    2      1   2   1   2




                               MONS




    goo.gl/S1sYZ (me on Google+)
         twitter.com/hastexo
               hastexo.com

More Related Content

What's hot

Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1
Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1
Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1
Andy Cobley
 
Cassandraona pi why
Cassandraona pi whyCassandraona pi why
Cassandraona pi why
Andy Cobley
 

What's hot (20)

Ceph Day KL - Bluestore
Ceph Day KL - Bluestore Ceph Day KL - Bluestore
Ceph Day KL - Bluestore
 
Stig Telfer - OpenStack and the Software-Defined SuperComputer
Stig Telfer - OpenStack and the Software-Defined SuperComputerStig Telfer - OpenStack and the Software-Defined SuperComputer
Stig Telfer - OpenStack and the Software-Defined SuperComputer
 
Beyondfs-intro
Beyondfs-introBeyondfs-intro
Beyondfs-intro
 
Ceph Day Seoul - The Anatomy of Ceph I/O
Ceph Day Seoul - The Anatomy of Ceph I/OCeph Day Seoul - The Anatomy of Ceph I/O
Ceph Day Seoul - The Anatomy of Ceph I/O
 
Practical ZFS
Practical ZFSPractical ZFS
Practical ZFS
 
The Proto-Burst Buffer: Experience with the flash-based file system on SDSC's...
The Proto-Burst Buffer: Experience with the flash-based file system on SDSC's...The Proto-Burst Buffer: Experience with the flash-based file system on SDSC's...
The Proto-Burst Buffer: Experience with the flash-based file system on SDSC's...
 
Ceph Day KL - Ceph Tiering with High Performance Archiecture
Ceph Day KL - Ceph Tiering with High Performance ArchiectureCeph Day KL - Ceph Tiering with High Performance Archiecture
Ceph Day KL - Ceph Tiering with High Performance Archiecture
 
C* Summit EU 2013: Cassandra on Flash: Performance & Efficiency Lessons Learned
C* Summit EU 2013: Cassandra on Flash: Performance & Efficiency Lessons Learned C* Summit EU 2013: Cassandra on Flash: Performance & Efficiency Lessons Learned
C* Summit EU 2013: Cassandra on Flash: Performance & Efficiency Lessons Learned
 
An Efficient Backup and Replication of Storage
An Efficient Backup and Replication of StorageAn Efficient Backup and Replication of Storage
An Efficient Backup and Replication of Storage
 
PostgreSQL + ZFS best practices
PostgreSQL + ZFS best practicesPostgreSQL + ZFS best practices
PostgreSQL + ZFS best practices
 
Tech talk Introduction to containers
Tech talk Introduction to containersTech talk Introduction to containers
Tech talk Introduction to containers
 
SUSE Enterprise Storage on ThunderX
SUSE Enterprise Storage on ThunderXSUSE Enterprise Storage on ThunderX
SUSE Enterprise Storage on ThunderX
 
Tobias Oetiker: RRDtool - how to make it sit up and beg
Tobias Oetiker: RRDtool - how to make it sit up and begTobias Oetiker: RRDtool - how to make it sit up and beg
Tobias Oetiker: RRDtool - how to make it sit up and beg
 
Tvs 473, Tvs 673, Tvs 873
Tvs 473, Tvs 673, Tvs 873 Tvs 473, Tvs 673, Tvs 873
Tvs 473, Tvs 673, Tvs 873
 
Ceph Day LA: Adventures in Ceph & ISCSI
Ceph Day LA: Adventures in Ceph & ISCSICeph Day LA: Adventures in Ceph & ISCSI
Ceph Day LA: Adventures in Ceph & ISCSI
 
Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1
Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1
Data stax cassandra_summit_2013_cassandra_raspberrypi-rc1
 
What every data programmer needs to know about disks
What every data programmer needs to know about disksWhat every data programmer needs to know about disks
What every data programmer needs to know about disks
 
Cassandraona pi why
Cassandraona pi whyCassandraona pi why
Cassandraona pi why
 
Build an affordable Cloud Stroage
Build an affordable Cloud StroageBuild an affordable Cloud Stroage
Build an affordable Cloud Stroage
 
Ceph Day KL - Ceph on All-Flash Storage
Ceph Day KL - Ceph on All-Flash Storage Ceph Day KL - Ceph on All-Flash Storage
Ceph Day KL - Ceph on All-Flash Storage
 

Similar to Storage with Ceph (OSDC 2013)

INFINISTORE(tm) - Scalable Open Source Storage Arhcitecture
INFINISTORE(tm) - Scalable Open Source Storage ArhcitectureINFINISTORE(tm) - Scalable Open Source Storage Arhcitecture
INFINISTORE(tm) - Scalable Open Source Storage Arhcitecture
Thomas Uhl
 
Turning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platformTurning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platform
OpenStack_Online
 

Similar to Storage with Ceph (OSDC 2013) (20)

What you need to know about ceph
What you need to know about cephWhat you need to know about ceph
What you need to know about ceph
 
Red Hat Storage 2014 - Product(s) Overview
Red Hat Storage 2014 - Product(s) OverviewRed Hat Storage 2014 - Product(s) Overview
Red Hat Storage 2014 - Product(s) Overview
 
Open Source Storage at Scale: Ceph @ GRNET
Open Source Storage at Scale: Ceph @ GRNETOpen Source Storage at Scale: Ceph @ GRNET
Open Source Storage at Scale: Ceph @ GRNET
 
INFINISTORE(tm) - Scalable Open Source Storage Arhcitecture
INFINISTORE(tm) - Scalable Open Source Storage ArhcitectureINFINISTORE(tm) - Scalable Open Source Storage Arhcitecture
INFINISTORE(tm) - Scalable Open Source Storage Arhcitecture
 
Ceph LISA'12 Presentation
Ceph LISA'12 PresentationCeph LISA'12 Presentation
Ceph LISA'12 Presentation
 
Webinar - Getting Started With Ceph
Webinar - Getting Started With CephWebinar - Getting Started With Ceph
Webinar - Getting Started With Ceph
 
Storage tiering and erasure coding in Ceph (SCaLE13x)
Storage tiering and erasure coding in Ceph (SCaLE13x)Storage tiering and erasure coding in Ceph (SCaLE13x)
Storage tiering and erasure coding in Ceph (SCaLE13x)
 
Block Storage For VMs With Ceph
Block Storage For VMs With CephBlock Storage For VMs With Ceph
Block Storage For VMs With Ceph
 
Ceph Introduction 2017
Ceph Introduction 2017  Ceph Introduction 2017
Ceph Introduction 2017
 
Ceph as software define storage
Ceph as software define storageCeph as software define storage
Ceph as software define storage
 
Ceph at salesforce ceph day external presentation
Ceph at salesforce   ceph day external presentationCeph at salesforce   ceph day external presentation
Ceph at salesforce ceph day external presentation
 
XenSummit - 08/28/2012
XenSummit - 08/28/2012XenSummit - 08/28/2012
XenSummit - 08/28/2012
 
Ceph Day NYC: The Future of CephFS
Ceph Day NYC: The Future of CephFSCeph Day NYC: The Future of CephFS
Ceph Day NYC: The Future of CephFS
 
ContainerDays Boston 2015: "CoreOS: Building the Layers of the Scalable Clust...
ContainerDays Boston 2015: "CoreOS: Building the Layers of the Scalable Clust...ContainerDays Boston 2015: "CoreOS: Building the Layers of the Scalable Clust...
ContainerDays Boston 2015: "CoreOS: Building the Layers of the Scalable Clust...
 
Bluestore
BluestoreBluestore
Bluestore
 
London Ceph Day: The Future of CephFS
London Ceph Day: The Future of CephFSLondon Ceph Day: The Future of CephFS
London Ceph Day: The Future of CephFS
 
Docker Introduction
Docker IntroductionDocker Introduction
Docker Introduction
 
Ceph at Spreadshirt (June 2016)
Ceph at Spreadshirt (June 2016)Ceph at Spreadshirt (June 2016)
Ceph at Spreadshirt (June 2016)
 
Turning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platformTurning OpenStack Swift into a VM storage platform
Turning OpenStack Swift into a VM storage platform
 
The Future of Cloud Software Defined Storage with Ceph: Andrew Hatfield, Red Hat
The Future of Cloud Software Defined Storage with Ceph: Andrew Hatfield, Red HatThe Future of Cloud Software Defined Storage with Ceph: Andrew Hatfield, Red Hat
The Future of Cloud Software Defined Storage with Ceph: Andrew Hatfield, Red Hat
 

More from hastexo

Storage mit ceph (glt 2013)
Storage mit ceph (glt 2013)Storage mit ceph (glt 2013)
Storage mit ceph (glt 2013)
hastexo
 
LCA 2012: High Availability Sprint
LCA 2012: High Availability SprintLCA 2012: High Availability Sprint
LCA 2012: High Availability Sprint
hastexo
 

More from hastexo (13)

Hands On Trove: Database as a Service in OpenStack
Hands On Trove: Database as a Service in OpenStack Hands On Trove: Database as a Service in OpenStack
Hands On Trove: Database as a Service in OpenStack
 
Storage mit ceph (glt 2013)
Storage mit ceph (glt 2013)Storage mit ceph (glt 2013)
Storage mit ceph (glt 2013)
 
Mit OpenStack zur eigenen Cloud (LinuxTag 2012)
Mit OpenStack zur eigenen Cloud (LinuxTag 2012)Mit OpenStack zur eigenen Cloud (LinuxTag 2012)
Mit OpenStack zur eigenen Cloud (LinuxTag 2012)
 
Mit OpenStack zur eigenen Cloud (LinuxWochen Wien, 2012)
Mit OpenStack zur eigenen Cloud (LinuxWochen Wien, 2012)Mit OpenStack zur eigenen Cloud (LinuxWochen Wien, 2012)
Mit OpenStack zur eigenen Cloud (LinuxWochen Wien, 2012)
 
Mit OpenStack zur eigenen Cloud (GLT 2012)
Mit OpenStack zur eigenen Cloud (GLT 2012)Mit OpenStack zur eigenen Cloud (GLT 2012)
Mit OpenStack zur eigenen Cloud (GLT 2012)
 
Mit OpenStack zur eigenen Cloud (OSDC 2012)
Mit OpenStack zur eigenen Cloud (OSDC 2012)Mit OpenStack zur eigenen Cloud (OSDC 2012)
Mit OpenStack zur eigenen Cloud (OSDC 2012)
 
MySQL High Availability Deep Dive
MySQL High Availability Deep DiveMySQL High Availability Deep Dive
MySQL High Availability Deep Dive
 
GlusterFS und Ceph: Skalierbares Storage ohne Wenn und Aber
GlusterFS und Ceph: Skalierbares Storage ohne Wenn und AberGlusterFS und Ceph: Skalierbares Storage ohne Wenn und Aber
GlusterFS und Ceph: Skalierbares Storage ohne Wenn und Aber
 
Mit OpenStack zur eigenen Cloud
Mit OpenStack zur eigenen CloudMit OpenStack zur eigenen Cloud
Mit OpenStack zur eigenen Cloud
 
LCA 2012: High Availability Sprint
LCA 2012: High Availability SprintLCA 2012: High Availability Sprint
LCA 2012: High Availability Sprint
 
Storage Replication in High-Performance High-Availability Environments
Storage Replication in High-Performance High-Availability EnvironmentsStorage Replication in High-Performance High-Availability Environments
Storage Replication in High-Performance High-Availability Environments
 
MySQL High Availability Sprint: Launch the Pacemaker
MySQL High Availability Sprint: Launch the PacemakerMySQL High Availability Sprint: Launch the Pacemaker
MySQL High Availability Sprint: Launch the Pacemaker
 
Fencing and Maintaining Sanity in High Availability Clusters
Fencing and Maintaining Sanity in High Availability ClustersFencing and Maintaining Sanity in High Availability Clusters
Fencing and Maintaining Sanity in High Availability Clusters
 

Recently uploaded

Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider  Progress from Awareness to Implementation.pptxTales from a Passkey Provider  Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
FIDO Alliance
 
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Victor Rentea
 

Recently uploaded (20)

Six Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal OntologySix Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal Ontology
 
2024 May Patch Tuesday
2024 May Patch Tuesday2024 May Patch Tuesday
2024 May Patch Tuesday
 
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider  Progress from Awareness to Implementation.pptxTales from a Passkey Provider  Progress from Awareness to Implementation.pptx
Tales from a Passkey Provider Progress from Awareness to Implementation.pptx
 
Navigating Identity and Access Management in the Modern Enterprise
Navigating Identity and Access Management in the Modern EnterpriseNavigating Identity and Access Management in the Modern Enterprise
Navigating Identity and Access Management in the Modern Enterprise
 
DBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor Presentation
 
JavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate GuideJavaScript Usage Statistics 2024 - The Ultimate Guide
JavaScript Usage Statistics 2024 - The Ultimate Guide
 
WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024WebRTC and SIP not just audio and video @ OpenSIPS 2024
WebRTC and SIP not just audio and video @ OpenSIPS 2024
 
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsContinuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage Intacct
 
WSO2's API Vision: Unifying Control, Empowering Developers
WSO2's API Vision: Unifying Control, Empowering DevelopersWSO2's API Vision: Unifying Control, Empowering Developers
WSO2's API Vision: Unifying Control, Empowering Developers
 
ADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptxADP Passwordless Journey Case Study.pptx
ADP Passwordless Journey Case Study.pptx
 
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
 
Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)
 
AI in Action: Real World Use Cases by Anitaraj
AI in Action: Real World Use Cases by AnitarajAI in Action: Real World Use Cases by Anitaraj
AI in Action: Real World Use Cases by Anitaraj
 
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
 
TEST BANK For Principles of Anatomy and Physiology, 16th Edition by Gerard J....
TEST BANK For Principles of Anatomy and Physiology, 16th Edition by Gerard J....TEST BANK For Principles of Anatomy and Physiology, 16th Edition by Gerard J....
TEST BANK For Principles of Anatomy and Physiology, 16th Edition by Gerard J....
 
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
Modular Monolith - a Practical Alternative to Microservices @ Devoxx UK 2024
 
CNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In PakistanCNIC Information System with Pakdata Cf In Pakistan
CNIC Information System with Pakdata Cf In Pakistan
 
Design and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data ScienceDesign and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data Science
 
Decarbonising Commercial Real Estate: The Role of Operational Performance
Decarbonising Commercial Real Estate: The Role of Operational PerformanceDecarbonising Commercial Real Estate: The Role of Operational Performance
Decarbonising Commercial Real Estate: The Role of Operational Performance
 

Storage with Ceph (OSDC 2013)

Editor's Notes

  1. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight! "Erlauben Sie mir, mich kurz vorzustellen ..."
  2. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  3. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  4. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  5. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  6. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  7. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  8. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  9. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight!
  10. Large attendee size Normally we do this for 12 people tops In 2 days Today: 20 people, 3 hours So the schedule is gonna be tight! Kurze Zwischenfrage: Wer von Ihnen betreibt einen zentralisierten Speicher? Und wer von Ihnen hatte schonmal das Problem, dass im zentralen Speicher kein Platz mehr war?
  11. I use two different slide layouts. This one you've already seen. Worum geht es heute? Der Vortragstitel verrät: Es geht um skalierbares Storage. Ich unterstelle Ihnen jetzt einfach mal ganz frech, dass Sie mit dem Begriff Storage etwas anfangen können Und vermutlich ist Ihnen auch der Begriff Skalierbarkeit bekannt. Allerdings ist es im Rahmen dieses Vortrags trotzdem sinnvoll, einen etwas genaueren Blick auf "Skalierbarkeit" an sich zu werfen
  12. I use two different slide layouts. This one you've already seen. In gegenwärtigen IT-Setups kommen typischerweise 2 Arten von Skalierbarkeit zum Einsatz
  13. I use two different slide layouts. This one you've already seen. Einerseits das Skalieren in die Höhe, auch Scale-Up genannt. Beim Scale-Up geht es im Wesentlichen darum, die Ressourcen bereits vorhandener Hardware zu vergrößern. Vulgo: Mehr CPU-Leistung, mehr RAM, mehr Plattenplatz Selbstverständlich kann "Scale-Up" auch meinen, ein System durch ein deutlich leistungsfähigeres System zu ersetzen; auch das wäre Scale-Up im klassischen Sinne. Am konkreten Beispiel bedeutet das ...
  14. I use two different slide layouts. This one you've already seen. Ein Setup, das per Scale-Up erweitert wird, sieht vor dem Upgrade so aus, und nach dem Upgrade ...
  15. I use two different slide layouts. This one you've already seen. auch.
  16. I use two different slide layouts. This one you've already seen. Das Problem von Scale-Up ist, dass das Prinzip bald an seine Grenzen stößt CPU-Power ist nicht beliebig erweiterbar RAM ist nicht beliebig erweiterbar Plattenplatz ist nicht beliebig erweiterbar.
  17. I use two different slide layouts. This one you've already seen. Als Alternative zu Scale-Up steht das Skalieren in die Breite zur Verfügung, kurz "Scale-Out". Hierbei geht es darum, ein Setup um zusätzliche Rechner zu erweitern, die dann im Verbund mit den bereits vorhandenen Systemen die eigentliche Aufgabe erledigen
  18. I use two different slide layouts. This one you've already seen. Um das Beispiel von vorhin zu bemühen, haben wir hier zunächst wieder das ursprüngliche Setup und erweitern es dann per Scale-Out, was zu diesem Effekt führt:
  19. I use two different slide layouts. This one you've already seen. Die einzelnen Rechner sind offensichtlich gar nicht so viel leistungsfähiger als das ursprüngliche System, aber bedingt durch die Tatsache, dass es jetzt 3 davon gibt, ist die Leistung des Gesamtsystems offensichtlich deutlich größer Der Vorteil von Scale-Out-Lösungen: Sie lassen sich prinzipiell beliebig erweitern
  20. I use two different slide layouts. This one you've already seen. Wenn Sie sich in der gegenwärtigen IT umschauen, werden Sie feststellen, dass Skalierbarkeit fast immer auf Scale-Out zielt und praktisch kaum mehr auf Scale-Up. Nahezu alle Kernkomponenten aktueller IT-Setups beherrschen Scale-Out Beispiele hierfür sind ...
  21. I use two different slide layouts. This one you've already seen. Webserver, die typisches Scale-Out seit Ewigkeiten unterstützen -- hier kommt einfach ein Loadbalancer-Setup zum Einsatz, das sich um beliebig viele Maschinen erweitern lässt
  22. I use two different slide layouts. This one you've already seen. Datenbanken, die Master-Slave-Replikation seit langem beherrschen und mittlerweile sogar ein neues Niveau von Scale-Out-Fähigkeiten erlangt haben, in dem sie Master-Master-Replication ermöglichen (MySQL & Galera, das der Kollege Erkan Yanar ja gestern schon vorgestellt hat)
  23. I use two different slide layouts. This one you've already seen. Datenbanken, die Master-Slave-Replikation seit langem beherrschen und mittlerweile sogar ein neues Niveau von Scale-Out-Fähigkeiten erlangt haben, in dem sie Master-Master-Replication ermöglichen (MySQL & Galera, das der Kollege Erkan Yanar ja gestern schon vorgestellt hat)
  24. I use two different slide layouts. This one you've already seen. Storage wirkt in Sachen Skalierbarkeit hingegen wie ein Relikt vergangener Tage. Ein kurzer Blick auf die Storage-Geschichte der letzten 20 Jahre offenbar das schnell.
  25. I use two different slide layouts. This one you've already seen. Dass sich das Thema Scale-Out bei Storages bisher kaum durchgesetzt hat, vor alle technische Ursachen. Scale-Out bedingt verteilte Systeme, aber Verteilung ist mit Blöcken kaum sinnvoll zu erreichen. Wenn Sie einen Datenträger kaufen, können Sie den zunächst gar nicht sinnvoll nutzen. Sie könnten darauf zwar Daten ablegen, aber Sie hätten keine Möglichkeit, diese später wieder zu finden. Deshalb brauchen wir kleine Helferlein, die uns die Nutzung von Block Storages erlauben. Wir kennen die Helferlein unter dem Namen "Dateisystem"; Dateisysteme erlauben es, Block-Devices sinnvoll zu nutzen Einzig: Sobald Dateisysteme im Spiel sind, ist das Schaffen von Distributed Systemen kaum sinnvoll möglich
  26. I use two different slide layouts. This one you've already seen. Hier wird das Problem sehr deutlich: Das Dateisystem funktioniert nur in Verbindung mit dem darunter liegenden Block-Device – es lässt sich nicht in mehrere Teile spalten, die dann innerhalb eines Rechner-Verbundes zu verteilen währen. Genau das wäre aber für Storage-Scale-Out nötig: Scale-Out bedeutet, eine verteilte Umgebung zu schaffen. Und genau dafür sind Dateisysteme sehr hinderlich.
  27. I use two different slide layouts. This one you've already seen. Daraus ergibt sich, dass Blöcke für verteilte Systeme ...
  28. I use two different slide layouts. This one you've already seen. Ein eher unpassendes Konzept sind.
  29. I use two different slide layouts. This one you've already seen. Und damit sind wir beim Thema Object Stores angekommen
  30. I use two different slide layouts. This one you've already seen. Object Stores funktionieren nach einem einfachen Prinzip: Jede in ihnen abgelegte Information wandeln sie in ein binäres Objekt um.
  31. I use two different slide layouts. This one you've already seen. Intern organisieren sich die Object Stores dann ausschließlich anhand dieser binären Objekte. Verstehen Sie mich bitte nicht falsch: Selbstverständlich nutzen auch Object Stores letztlich genauso block-basierte Speichergeräte wie jede andere Speicherlösung auch. Im Gegensatz zu Dateisystemen ist ihnen die Block-Struktur des Datenträgers aber egal. Binäre Objekte lassen sich nach Belieben zerteilen und wieder zusammensetzen Ein weiterer Vorteil ist, dass in einer solchen Konstruktion letztlich egal ist, wie das Frontend funktioniert. Im Hintergrund greift alles auf den gleichen Object Store zu. Ob das Front-End dann ein Dateisystem ist, ein Block Device oder ein anderer Dienst, ist unwichtig.
  32. I use two different slide layouts. This one you've already seen. Intern organisieren sich die Object Stores dann ausschließlich anhand dieser binären Objekte. Verstehen Sie mich bitte nicht falsch: Selbstverständlich nutzen auch Object Stores letztlich genauso block-basierte Speichergeräte wie jede andere Speicherlösung auch. Im Gegensatz zu Dateisystemen ist ihnen die Block-Struktur des Datenträgers aber egal. Binäre Objekte lassen sich nach Belieben zerteilen und wieder zusammensetzen Ein weiterer Vorteil ist, dass in einer solchen Konstruktion letztlich egal ist, wie das Frontend funktioniert. Im Hintergrund greift alles auf den gleichen Object Store zu. Ob das Front-End dann ein Dateisystem ist, ein Block Device oder ein anderer Dienst, ist unwichtig.
  33. I use two different slide layouts. This one you've already seen. Sowas wie der aufsteigende Stern am Object-Store-Himmel ist Ceph.
  34. I use two different slide layouts. This one you've already seen. Ursprünglich war Ceph eine Dissertation, verfasst von Sage A. Weil in Zusammenarbeit mit einigen Kollegen an der Universität von Santa Cruz, Kalifornien. Das Projekt ist gar nicht so neu, hatte bis dato allerdings kaum nennenswerte Publicity und geht gerade erst aktiv in die Öffentlichkeit Im Folgenden möchte ich Ihnen Ceph insgesamt gern genauer vorstellen.
  35. I use two different slide layouts. This one you've already seen. Grundsätzlich gilt: Ceph ist die Bezeichnung für ein umfassendes Storage-Konzept; ursprünglich bezeichnet der Begriff nicht ein einzelnes Stück Software Das Storage-Konzept besteht aus mehreren Komponenten, nämlich
  36. I use two different slide layouts. This one you've already seen. Der eigentliche Object Store, der sich intern gleich auch um Redundanz kümmert sowie
  37. I use two different slide layouts. This one you've already seen. Beschäftigen wir uns zunächst mit dem Object Store Die Komponente in Ceph, die den Object Store abbildet, heißt RADOS. Das steht für
  38. I use two different slide layouts. This one you've already seen. RADOS steht für ... Die Lösung speichert Daten automatisch ab, in dem es sie in binäre Dateien umwandelt und diese auf mehrere, voneinander unabhängig Hosts verteilt (automatische Replikation ist dabei übrigens enthalten)
  39. I use two different slide layouts. This one you've already seen. RADOS selbst besteht aus zwei Komponenten. Einerseits sind das die ...
  40. I use two different slide layouts. This one you've already seen. OSDs. OSD ist die Abkürzung für Object Storage Daemon. OSDs sind die eigentlichen Datenbehälter für Ceph; denn selbstverständlich braucht auch der Object Store letztlich Block-Devices, auf denen er seine Daten ablegen kann. Die grundsätzliche Annahme ist, dass jede einzelne Festplatte ein OSD ist und dass RADOS sich selbst um die Verwaltung der OSDs kümmert. Die RADOS-Entwickler gehen sogar soweit, dass sie von RAID-Konfigurationen für OSDs abraten und das Thema Redundanz von Daten ausschließlich in die Hände von Ceph geben Jedes Block-Device mit Dateisystem kann ein OSD sein, solange das Dateisystem User Extended Attributes unterstützt Die Anzahl von OSDs, die ein Ceph nutzen kann, ist praktisch unbeschränkt , hieraus ergibt sich die Skalierbarkeit in die Breite
  41. I use two different slide layouts. This one you've already seen. In addition to the OSDs, we have Monitoring Servers, usually referred to as MONs. MONs have three different tasks: Based on a PAXOS algorithm, they take care of the cluster quorum end avoid split brain scenarios. If a monitoring servers in Ceph can not see enough other Mons to know that it is in the cluster partition having the majority, it will cease service. Mons will also keep record of all existing Monitoring servers and all existing OSDs and will create documents containing exactly these information. That’s important because … Monitoring servers are the initial point of contact for Clients in Ceph. Every client that wants to talk to OSDs needs to talk to a MON first to get a list of all existing Mons and all existing OSDs and only after the client has these information, it can talk to OSDs directly
  42. I use two different slide layouts. This one you've already seen. Wie funktioniert die Daten-Ablage in Ceph? die Erklärung funktioniert am Besten anhand eines kurzen Beispiels. Wir erinnern uns an die einzelne Datei, die im Object Store abzulegen ist.
  43. I use two different slide layouts. This one you've already seen. Oben im Bild sehen Sie OSDs (in 'echten' Clustern sind das natürlich viel mehr -- zur Erinnerung: Ceph behandelt die OSDs grundsätzlich gleich, in welchem Server die stecken, ist also egal)
  44. I use two different slide layouts. This one you've already seen. Außerdem wissen wir, dass wir im RADOS-Cluster Monitoring-Server brauchen, also MONs. Bitteschön!
  45. I use two different slide layouts. This one you've already seen. Und wir haben einen Client, der eine Datei abspeichern soll Die erste Information, die der Client braucht, ist die Information über die vorhandenen MONs und OSDs.
  46. I use two different slide layouts. This one you've already seen. Deshalb fragt er bei einem MON nach ...
  47. I use two different slide layouts. This one you've already seen. und erhält die entsprechenden Details
  48. I use two different slide layouts. This one you've already seen. Dann teilt der Client die zu speichernde Datei in binäre Objekte auf ...
  49. I use two different slide layouts. This one you've already seen. und weist diese binären Objekte Gruppen zu -- die so genannten Placement Groups (PGs) und errechnet sich per Algorithmus das "Primary OSD", also das OSD, auf das der Client die Objekte einer Placement Group hochlädt
  50. I use two different slide layouts. This one you've already seen. Schließlich erfolgt der eigentliche Upload.
  51. I use two different slide layouts. This one you've already seen. Übrigens: Das Schreiben von Objekten vom Client auf die OSDs passiert parallelisiert. Der Client schreibt in der Default-Konfiguration so viel weg, wie er kann. Aus der Aufteilung in Objekte und die Verteilung auf verschiedene OSDs ergibt sich, dass ein Client zu einem Zeitpunkt X auf viel mehr Spindeln schreiben kann, als es bei konventionellen Storage-Lösungen der Fall wäre Daraus ergibt sich, dass die einzelne Festplatte, die ein OSD darstellt, gar nicht besonders schnell sein muss. Anstelle einer 300GB-SAS-Platte tut's also auch eine 3TB-SATA-Platte; in den meisten Fällen dürfte der Flaschenhals das Netzwerk sein
  52. I use two different slide layouts. This one you've already seen. Die OSDs, auf denen die Objekte landen, kümmern sich im Hintergrund automatisch um die Replikation. Schließlich gilt der Vorgang als beendet.
  53. I use two different slide layouts. This one you've already seen. Dann erfolgt die Replikation innerhalb der OSDs
  54. I use two different slide layouts. This one you've already seen. Das Tolle an diesem Vorgang ist: Wieviele OSDs da sind, ist letztlich völlig egal; je mehr OSDs zur Verfügung stehen, desto größer ist die Variabilität innerhalb des Storages
  55. I use two different slide layouts. This one you've already seen. Schließlich erfolgt der eigentliche Upload.
  56. I use two different slide layouts. This one you've already seen. Der Algorithmus, den Clients verwenden, um das primäre OSD für eine Placement Group zu errechnen und den OSDs auch für die Replikation untereinander einsetzen, heißt übrigens CRUSH-Algorithmus und ist ebenfalls eine Erfindung von Sage A. Weil. Die OSD-Zuweisung ist vollständig Algorithmus-basiert, es gibt keine Hashtabelle und auch keine Datenbank -- das verhindert Bottlenecks
  57. I use two different slide layouts. This one you've already seen. Der Algorithmus basiert auf dem Prinzip, dass er Placement-Groups grundsätzlich zufällig einzelnen OSDs zuweist, allerdings bei gleichem Input stets die gleichen OSDs ausgibt (solange die Ziel-OSDs vorhanden sind -- fällt ein OSD aus, adaptiert CRUSH das Ergebnis natürlich entsprechend)
  58. I use two different slide layouts. This one you've already seen. Der CRUSH-Algorithmus erlaubt es dem Admin übrigens auch, eigene Bedingungen für Data-Placement zu definieren; so kann der Admin über die CRUSH-Konfiguration (die "CRUSH map") festlegen, dass Replicas von Objekten in drei verschiedenen Racks vorhanden sein müssen Ceph ist also vollständig Rack aware
  59. I use two different slide layouts. This one you've already seen. Soviel zu den wesentlichen Grundzügen des RADOS-Object-Stores per se. Der Object Store ist allerdings ohne passende Clients eher nutzlos. Lassen Sie uns also einen Blick auf die Clients werfen, die für den Ceph-Object-Store zur Verfügung stehen.
  60. I use two different slide layouts. This one you've already seen. Ganz anders sieht es mit dem nächsten Front-End aus, das für RADOS zur Verfügung steht:
  61. I use two different slide layouts. This one you've already seen. Das RADOS-Block-Device. RBD kommt in zwei Geschmacksrichtungen:
  62. I use two different slide layouts. This one you've already seen. Einerseits gibt es einen eigenen RBD-Kernel-Treiber, der es ermöglicht, auf Daten in RADOS auf Block-Level-Ebene zuzugreifen. Auf dem Client gibt es dann ein /dev/rbd0, das genauso nutzbar ist wie jedes andere Block-Device auch. Bestandteil des Linux-Kernels 2.6.37 RBD-Devices sind grundsätzlich thin-provisioned
  63. I use two different slide layouts. This one you've already seen. Die zweite Variante ist die direkte Anbindung von Qemu an RBD. Qemu versteht mittlerweile (auch upstream-seitig) das RBD-Protokoll und ermöglicht es auf diese Weise, virtuelle Maschinen mit einer Festplatte zu betreiben, die direkt in RADOS liegt. Das Prinzip ermöglicht Virtualisierungs-Cluster aus zig verschiedenen Knoten, bei denen jede virtuelle Maschine auf jedem Virtualisierungshost laufen kann Auch die migration bestehender VMs von konventionellem Storage auf RADOS ist unterstützt
  64. I use two different slide layouts. This one you've already seen. Sieht konkret so aus: 8 Server, die einerseits den RADOS-Store darstellen (und entsprechend viele OSDs haben) und andererseits selbst auch virtualisieren. Jede VM kann auf jedem Host laufen, und das Setup lässt sich beliebig durch zusätzliche Server in die Breite skalieren
  65. I use two different slide layouts. This one you've already seen. Nicht unerwähnt bleiben soll die ReSTful API, die den Zugriff auf RADOS über ReST-Requests per HTTP ermöglicht. Sie heißt ...
  66. I use two different slide layouts. This one you've already seen. radosgw. Das Radosgw zielt insbesondere auf Online-Speicher-Angebote ab; denken Sie an Dropbox oder Google Drive. Wer Ceph nutzen möchte, um Benutzern den Upload von Daten per HTTP zu ermöglichen, nimmt dafür radosgw. Radosgw ist FCGI-basiert und funktioniert typischerweise mit einem Apache-Webserver (wobei auch jeder andere FCGI-fähige Webserver funktioniert) Auch wenn es auf den ersten Blick so aussieht: radosgw ist kein SPOF; wie alle anderen Komponenten lassen sich auch radosgw-Instanzen nahtlos skalieren, ggf. ist allerdings der Einsatz eines Load-Balancers notwendig
  67. I use two different slide layouts. This one you've already seen. Besonders hervorzuheben ist bei radosgw die Tatsache, dass es sowohl mit Amazons S3 wie auch mit der API von OpenStack Swift kompatibel ist Dadurch funktionieren einerseits nahezu alle S3-kompatiblen Clients und andererseits lässt sich ein Ceph mit radosgw auch ganz wunderbar in OpenStack integrieren
  68. I use two different slide layouts. This one you've already seen. Das PR-trächtigste Front-End ist definitiv das Dateisystem. Es heisst ...
  69. I use two different slide layouts. This one you've already seen. ... CephFS. CephFS ist ein vollständig mit POSIX-kompatibles Dateisystem, das im Hintergrund seine Daten in RADOS ablegt Für Metadaten gibt es in CephFS einen zusätzlichen Dienst -- MDS, also Metada Server, der die Metadaten an den Client ausliefert Vielleicht kennt der eine oder andere das MDS-Konzept von Lustre, im Gegensatz zu Lustre ist es bei CephFS allerdings so, dass der MDS selbst keine Daten anlegt oder speichert Die POSIX-Metadaten zu Dateien liegen in den Extended User Attributes der Objekte direkt auf den OSDs, der MDS dient also im Wesentlichen als großer Cache Ein MDS-Ausfall führt anders als bei Lustre nicht zu stundenlanger Downtime
  70. I use two different slide layouts. This one you've already seen. CephFS ist seit Linux 2.6.32 als Dateisystem Bestandteil des Linux-Kernels (und war bis vor Kurzem als Experimental markiert -- das wird im nächsten stabilen Linux-Kernel 3.9 nicht mehr der Fall sein, weil es die Experimental-Markierung nicht mehr gibt) Leider ist CephFS der einzige Dienst im Ceph-Stack, der offiziell noch nicht als stabil markiert ist und deshalb produktiv auch noch nicht eingesetzt werden sollte
  71. I use two different slide layouts. This one you've already seen. Wer mit keiner der gezeigten Client-Lösungen etwas anfangen kann, sich auch einfach selber welche Schreiben.
  72. I use two different slide layouts. This one you've already seen. RADOS-Zugriff lässt sich auch unmittelbar in eine Applikation einbauen. Die librados, geschrieben in C, erlaubt den unmittelbaren Zugriff auf RADOS und kommt außerdem mit Bindings für verschiedene Skriptsprachen (aus dem Kuriositätenkabinett: php-rados)
  73. I use two different slide layouts. This one you've already seen. Welche Setups lassen sich schon jetzt beispielhaft mit Ceph umsetzen? Wo liegt der Nutzen in der Praxis?
  74. I use two different slide layouts. This one you've already seen.
  75. I use two different slide layouts. This one you've already seen.
  76. I use two different slide layouts. This one you've already seen. Als Beispiel bereits erwähnt habe ich eben Virtualisierung; dank der perfekten Anbindung von Qemu an RBD und einer entsprechenden Libivrt-Integration lassen sich Mehrknoten-Virtualisierungs-Cluster mit RADOS problemlos umsetzen
  77. I use two different slide layouts. This one you've already seen. Aus einer Kombination von RBD und iSCSI lässt sich auch ein echter 1-zu-1-Ersatz für SAN-Storages bauen, die ihre Daten per iSCSI anbieten. Das erleichtert die Migration, weil vorhandene Clients nicht umkonfiguriert werden müssen.
  78. I use two different slide layouts. This one you've already seen. Ganz wichtig: Cloud! Wir allen wollen in die Cloud, wir MÜSSEN in die Cloud! Hier spielt Ceph ganz vorne mit, denn Cloud-Umgebungen haben ja in aller Regel den selbstverständlichen Anspruch nahtloser Skalierbarkeit, so dass Ceph wunderbar in das Konzept passt
  79. I use two different slide layouts. This one you've already seen. Wer einsetzt oder evaluiert, erhält mit Ceph eine wertvolle Speicherlösung, die bereits umfassend in OpenStack integriert ist. Glance kann seine Images in Ceph speichern Cinder kann Ceph als Backend für Volumes nutzen RADOS mit Radosgw funktioniert wie bereits erwähnt als nahtloser Ersatz für Swift
  80. I use two different slide layouts. This one you've already seen.
  81. I use two different slide layouts. This one you've already seen. Wer einsetzt oder evaluiert, erhält mit Ceph eine wertvolle Speicherlösung, die bereits umfassend in OpenStack integriert ist. Glance kann seine Images in Ceph speichern Cinder kann Ceph als Backend für Volumes nutzen RADOS mit Radosgw funktioniert wie bereits erwähnt als nahtloser Ersatz für Swift
  82. I use two different slide layouts. This one you've already seen. Ehre, wem Ehre gebührt
  83. I use two different slide layouts. This one you've already seen.