Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Storage with Ceph (OSDC 2013)
Ähnlich wie Storage with Ceph (OSDC 2013) (20)
Mehr von hastexo
Mehr von hastexo (13)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Storage with Ceph (OSDC 2013)
- 1. Storage with Ceph Scale-Out made easy Martin Gerhard Loschwitz © 2013 hastexo Professional Services GmbH. All rights reserved.
- 2. Who?
- 12. Scalable Storage
- 13. 2 types of Scalability
- 14. Scale-Up
- 15. Scale-Up before:
- 17. Scale-Up quickly comes to its limits
- 18. Scale-Out
- 21. Scale-Out is hip
- 22. Webserver
- 23. Databases
- 24. Even me!
- 25. Storage? Meh.
- 28. Blocks for distributed systems?
- 29. I don’t think so, Tim!
- 30. Object Stores
- 32. User Space Objects FS FS FS FS FS FS FS HDD HDD HDD HDD HDD HDD HDD
- 33. User Space Objects FS FS FS FS FS FS FS HDD HDD HDD HDD HDD HDD HDD
- 35. Originally a PhD thesis
- 37. Object Store
- 38. RADOS
- 40. 2 Components
- 41. OSDs
- 42. MONs
- 43. Data Placement
- 45. MONs
- 46. MONs
- 47. MONs
- 48. MONs
- 49. MONs
- 50. MONs
- 51. MONs
- 52. Parallelization
- 53. 1 2 1 2 MONs
- 54. 1 2 1 2 MONs
- 55. 1 2 1 2 1 2 1 2 MONs
- 56. MONs
- 57. CRUSH
- 59. Rack aware
- 60. Clients?
- 62. RBD (RADOS Block Device)
- 63. rbd
- 64. Qemu-RBD
- 66. ReSTful API
- 67. radosgw
- 68. Compatible with S3 and Swift
- 70. CephFS
- 71. Still Beta!
- 72. Need a special client?
- 73. librados
- 74. Use cases
- 75. Gigantic Storage
- 76. 40TB, 3 replicas = € 21.000
- 77. Virtualization
- 78. iSCSI Storage
- 79. Cloud
- 80. OpenStack
- 81. live demo
- 82. 24. May 2013 OpenStack DACH Day 2013 http://openstackdach2013.eventbrite.com
- 83. Special thanks goes to: Sage Weil (Twitter: @liewegas) & crew for Ceph Inktank (Twitter: @inktank) for the Ceph logo
- 84. 1 2 1 2 1 2 1 2 MONS goo.gl/S1sYZ (me on Google+) twitter.com/hastexo hastexo.com
Hinweis der Redaktion
- 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 ..."
- 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!
- 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!
- 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!
- 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!
- 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!
- 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!
- 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!
- 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!
- 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?
- 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
- 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
- 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 ...
- 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 ...
- I use two different slide layouts. This one you've already seen. auch.
- 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.
- 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
- 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:
- 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
- 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 ...
- 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
- 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)
- 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)
- 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.
- 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
- 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.
- I use two different slide layouts. This one you've already seen. Daraus ergibt sich, dass Blöcke für verteilte Systeme ...
- I use two different slide layouts. This one you've already seen. Ein eher unpassendes Konzept sind.
- I use two different slide layouts. This one you've already seen. Und damit sind wir beim Thema Object Stores angekommen
- 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.
- 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.
- 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.
- I use two different slide layouts. This one you've already seen. Sowas wie der aufsteigende Stern am Object-Store-Himmel ist Ceph.
- 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.
- 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
- 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
- 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
- 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)
- I use two different slide layouts. This one you've already seen. RADOS selbst besteht aus zwei Komponenten. Einerseits sind das die ...
- 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
- 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
- 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.
- 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)
- 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!
- 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.
- I use two different slide layouts. This one you've already seen. Deshalb fragt er bei einem MON nach ...
- I use two different slide layouts. This one you've already seen. und erhält die entsprechenden Details
- 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 ...
- 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
- I use two different slide layouts. This one you've already seen. Schließlich erfolgt der eigentliche Upload.
- 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
- 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.
- I use two different slide layouts. This one you've already seen. Dann erfolgt die Replikation innerhalb der OSDs
- 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
- I use two different slide layouts. This one you've already seen. Schließlich erfolgt der eigentliche Upload.
- 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
- 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)
- 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
- 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.
- 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:
- I use two different slide layouts. This one you've already seen. Das RADOS-Block-Device. RBD kommt in zwei Geschmacksrichtungen:
- 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
- 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
- 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
- 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 ...
- 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
- 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
- I use two different slide layouts. This one you've already seen. Das PR-trächtigste Front-End ist definitiv das Dateisystem. Es heisst ...
- 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
- 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
- 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.
- 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)
- 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?
- I use two different slide layouts. This one you've already seen.
- I use two different slide layouts. This one you've already seen.
- 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
- 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.
- 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
- 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
- I use two different slide layouts. This one you've already seen.
- 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
- I use two different slide layouts. This one you've already seen. Ehre, wem Ehre gebührt
- I use two different slide layouts. This one you've already seen.