12
Software Defined Storage
Hallo Leute,
ich wende mich heute mit einer für mich sehr interessanten und wichtigen Frage an euch. Bei uns steht eine komplette Modernisierung unseres Rechenzentrums an, da wir bei der Leistung und der Datenkapazität an unseren Grenzen sind. Nun bin ich dabei mehrere Möglichkeiten für einen Neuaufbau durch zu denken. Alle gängigen Storage Varianten habe ich mit meinem Partner schon durchgekaut und bin nun bei meinen Nachforschungen auf das Thema SDS (Software Defined Storage'") gestoßen. Nach vielem Nachlesen finde ich da Thema immer spannender. SDS sticht ja durch Skalierbarkeit und vor allem durch die Möglichkeit hervor sehr heterogene System (bei Hersteller und Hardware) zu ermöglichen. Ich wollte jetzt nur mal fragen, ob jemand Erfahrungen in der Nutzung, Einrichtung und Konfiguration von SDS hat und diese gerne teilen möchte. Open Source oder Enterprise Lösung? Welche Hardware Konstellationen? Ich wäre dankbar, wenn sich viele hier beteiligen würden und Erfahrungen tauschen, da ich denke, ich bin nicht der Einzige, für den dieses Thema jetzt interessant ist bzw. in naher Zukunft interessant werden wird. Ich sage jetzt schon mal Danke für eure Unterstützung.
VLG
Andreas
ich wende mich heute mit einer für mich sehr interessanten und wichtigen Frage an euch. Bei uns steht eine komplette Modernisierung unseres Rechenzentrums an, da wir bei der Leistung und der Datenkapazität an unseren Grenzen sind. Nun bin ich dabei mehrere Möglichkeiten für einen Neuaufbau durch zu denken. Alle gängigen Storage Varianten habe ich mit meinem Partner schon durchgekaut und bin nun bei meinen Nachforschungen auf das Thema SDS (Software Defined Storage'") gestoßen. Nach vielem Nachlesen finde ich da Thema immer spannender. SDS sticht ja durch Skalierbarkeit und vor allem durch die Möglichkeit hervor sehr heterogene System (bei Hersteller und Hardware) zu ermöglichen. Ich wollte jetzt nur mal fragen, ob jemand Erfahrungen in der Nutzung, Einrichtung und Konfiguration von SDS hat und diese gerne teilen möchte. Open Source oder Enterprise Lösung? Welche Hardware Konstellationen? Ich wäre dankbar, wenn sich viele hier beteiligen würden und Erfahrungen tauschen, da ich denke, ich bin nicht der Einzige, für den dieses Thema jetzt interessant ist bzw. in naher Zukunft interessant werden wird. Ich sage jetzt schon mal Danke für eure Unterstützung.
VLG
Andreas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 327278
Url: https://administrator.de/contentid/327278
Printed on: April 19, 2024 at 11:04 o'clock
12 Comments
Latest comment
Wir haben momentan etwas um die 270 TB Storage, basierend auf Ceph in Betrieb.
Das ist in der Grundkonfiguration schon Rock Solid, wenn man die Redundanz der Daten erhöht wird es noch solider und beim Lesen auch schneller.
Du kannst mit Ceph auch relativ gut eine Verteilung der Daten über mehrere Standorte realisieren, zudem ist es selbstheilend - will heißen, wenn ein Ceph-Server für längere Zeit aus dem Verbund fällt, werden die Daten automatisch so umverteilt dass wieder das vorgegebene Redundanzlevel erreicht wird.
Das ist in der Grundkonfiguration schon Rock Solid, wenn man die Redundanz der Daten erhöht wird es noch solider und beim Lesen auch schneller.
Du kannst mit Ceph auch relativ gut eine Verteilung der Daten über mehrere Standorte realisieren, zudem ist es selbstheilend - will heißen, wenn ein Ceph-Server für längere Zeit aus dem Verbund fällt, werden die Daten automatisch so umverteilt dass wieder das vorgegebene Redundanzlevel erreicht wird.
Hi,
danke für deinen Beitrag. Wie sieht denn da deine Hardwarezusammenstellung aus? Möchte gerne ein wenig Ideen und Anregungen sammeln, um dann ein Konzept für uns zu erstellen.
VLG
danke für deinen Beitrag. Wie sieht denn da deine Hardwarezusammenstellung aus? Möchte gerne ein wenig Ideen und Anregungen sammeln, um dann ein Konzept für uns zu erstellen.
VLG
Das sind bei uns 3HE-Gehäuse mit je 24 HDD-Bays, Intel Xeon und mindestens 64 GB RAM, redundantes Netzteil.
Derzeit wird Netzwerk über 4x 1 GbE per LAG geführt, da wird aber langsam die Grenze sichtbar.
Wichtig ist, dass du bei den Festplatten wirklich die RAID-Editions der jeweiligen Hersteller nimmst. Bei derartigen Mengen Festplatten pro Gehäuse (und Rack) gehen normale Desktop- oder NAS-Platten innerhalb kürzester Zeit kaputt.
Derzeit wird Netzwerk über 4x 1 GbE per LAG geführt, da wird aber langsam die Grenze sichtbar.
Wichtig ist, dass du bei den Festplatten wirklich die RAID-Editions der jeweiligen Hersteller nimmst. Bei derartigen Mengen Festplatten pro Gehäuse (und Rack) gehen normale Desktop- oder NAS-Platten innerhalb kürzester Zeit kaputt.
Hallo,
danke für die schnelle Antwort. Ich benötige ca. 50 TB Speicher. Daher dachte ich mir, ich nehme 5 Server mit Raidcontroller, packe in jeden ein paar Platten rein, so dass ich ca. 10-15 TB im Raid5 auf jedem Server habe. Diese dann als clustered Filesystem, z.B. mit Ceph zu verbinden. Sind die Monitoringtools, Replikationstools und Verwaltungstools auf allen Servern installiert? Wie muss ich mir das vorstellen?
VLG
danke für die schnelle Antwort. Ich benötige ca. 50 TB Speicher. Daher dachte ich mir, ich nehme 5 Server mit Raidcontroller, packe in jeden ein paar Platten rein, so dass ich ca. 10-15 TB im Raid5 auf jedem Server habe. Diese dann als clustered Filesystem, z.B. mit Ceph zu verbinden. Sind die Monitoringtools, Replikationstools und Verwaltungstools auf allen Servern installiert? Wie muss ich mir das vorstellen?
VLG
Bei Ceph wird normalerweise kein RAID im Unterbau genutzt sondern möglichst viele einzelne Festplatten.
Das erhöht insgesamt die Performance und auch ein wenig die Stabilität, weil Ceph beim Ausfall einer Festplatte ("OSD") direkt anfangen kann die Daten zu reorganisieren um die Redundanz zu erhalten.
Zusätzlich erhältst du den Komfort, jederzeit ein paar Festplatten nachstecken zu können und damit die verfügbare Kapazität im laufenden Betrieb erweitern zu können. Und wenn alle Bays belegt sind stellst du halt den nächsten Server daneben. Sobald der Server für Ceph konfiguriert ist, wird automatisch die verfügbare Kapazität erweitert und die vorhandenen Daten auf den neuen Server mitverteilt. Das erhöht dann auch kurzfristig die Performance, da dann insgesamt mehr Festplatten zum Lesen und Schreiben verfügbar sind.
Ceph ist so aufgebaut, dass du "Object Storage Daemons" (OSDs) hast, welche jeweils eine einzelne verbaute Festplatte im Server repräsentieren. Jeder OSD kann einzeln von den "Ceph-Monitors" angesteuert werden - das sind die, die letztlich die Schnittstelle zwischen deinen Festplatten und deinem Netzwerk darstellen. Damit die Monitors wissen, wo welche Datenfragmente zu finden sind, brauchst du die "Ceph Metadata Daemons" die eine Datenbank führen auf welchen OSDs welche Datenfragmente gespeichert sind und diese nötigenfalls reorganisieren.
Die Live-Metadaten darfst du niemals verlieren, denn sonst hast du nur noch nicht mehr zu rekonstruierenden Datenmüll - die sollten also schon alleine deshalb so redundant wie möglich ausgelegt werden.
Das können alles getrennte Server sein, es kann aber auch alles auf dem selben Server laufen.
Wichtig ist, dass die Dienste so verteilt sind, dass du niemals Gefahr läufst dass keine Instanz des Dienstes mehr erreichbar ist und dass sie mit zunehmender Anzahl OSDs notfalls mitskaliert werden müssen.
Aus dem restlichen Netzwerk erreichbar sein müssen nur die Ceph-Monitors - das Ceph-Interne Netzwerk zur Reorganisation und Synchronisation sollte optimalerweise abgeschottet sein.
Ceph selbst bringt auch eigene Tools zur Gesundheitsüberwachung der Systeme mit, repariert die meisten auftretenden Fehler (defekte Festplatten, Totalausfall eines Servers...) aber vollautomatisch von selbst.
Es gibt verschiedene Möglichkeiten, Daten innerhalb von Ceph abzulegen - entweder über CephFS (da habe ich aber keine Erfahrung mit, kann also auch nichts zur Stabilität sagen), oder als nacktes Blockdevice wie man es von ISCSI kennt oder als Object Storage wie bei Amazon S3.
Das Einbinden des Dateisystems funktioniert dann so, wie man es von ISCSI mit Multipath kennt - einfach die Adressen der vorhandenen Ceph-Monitore angeben und dann das Dateisystem resp. das Blockdevice einhängen
Das erhöht insgesamt die Performance und auch ein wenig die Stabilität, weil Ceph beim Ausfall einer Festplatte ("OSD") direkt anfangen kann die Daten zu reorganisieren um die Redundanz zu erhalten.
Zusätzlich erhältst du den Komfort, jederzeit ein paar Festplatten nachstecken zu können und damit die verfügbare Kapazität im laufenden Betrieb erweitern zu können. Und wenn alle Bays belegt sind stellst du halt den nächsten Server daneben. Sobald der Server für Ceph konfiguriert ist, wird automatisch die verfügbare Kapazität erweitert und die vorhandenen Daten auf den neuen Server mitverteilt. Das erhöht dann auch kurzfristig die Performance, da dann insgesamt mehr Festplatten zum Lesen und Schreiben verfügbar sind.
Ceph ist so aufgebaut, dass du "Object Storage Daemons" (OSDs) hast, welche jeweils eine einzelne verbaute Festplatte im Server repräsentieren. Jeder OSD kann einzeln von den "Ceph-Monitors" angesteuert werden - das sind die, die letztlich die Schnittstelle zwischen deinen Festplatten und deinem Netzwerk darstellen. Damit die Monitors wissen, wo welche Datenfragmente zu finden sind, brauchst du die "Ceph Metadata Daemons" die eine Datenbank führen auf welchen OSDs welche Datenfragmente gespeichert sind und diese nötigenfalls reorganisieren.
Die Live-Metadaten darfst du niemals verlieren, denn sonst hast du nur noch nicht mehr zu rekonstruierenden Datenmüll - die sollten also schon alleine deshalb so redundant wie möglich ausgelegt werden.
Das können alles getrennte Server sein, es kann aber auch alles auf dem selben Server laufen.
Wichtig ist, dass die Dienste so verteilt sind, dass du niemals Gefahr läufst dass keine Instanz des Dienstes mehr erreichbar ist und dass sie mit zunehmender Anzahl OSDs notfalls mitskaliert werden müssen.
Aus dem restlichen Netzwerk erreichbar sein müssen nur die Ceph-Monitors - das Ceph-Interne Netzwerk zur Reorganisation und Synchronisation sollte optimalerweise abgeschottet sein.
Ceph selbst bringt auch eigene Tools zur Gesundheitsüberwachung der Systeme mit, repariert die meisten auftretenden Fehler (defekte Festplatten, Totalausfall eines Servers...) aber vollautomatisch von selbst.
Es gibt verschiedene Möglichkeiten, Daten innerhalb von Ceph abzulegen - entweder über CephFS (da habe ich aber keine Erfahrung mit, kann also auch nichts zur Stabilität sagen), oder als nacktes Blockdevice wie man es von ISCSI kennt oder als Object Storage wie bei Amazon S3.
Das Einbinden des Dateisystems funktioniert dann so, wie man es von ISCSI mit Multipath kennt - einfach die Adressen der vorhandenen Ceph-Monitore angeben und dann das Dateisystem resp. das Blockdevice einhängen
Hi,
danke für die super Erklärung. In der Praxis heisst das für mich dann, dass ich z. B. 5-10 Server nehme und in jeden Server z. B. 5 Platten reinmache, die nicht im Raid laufen sondern einzeln. Dann die Installation von Ceph und Ceph verteilt dann die Daten redundant über alle Platte auf allen Servern? Gibt es dazu ein Diagramm oder ein vernünftiges Tutorial? Wenn ich das richtig verstehe: Ich setze Hot-Swap Platten ein. Wenn in irgendeinem Server eine Platte defekt ist, nehm ich sie raus und ersetz durch eine neue Platte. Das System heilöt sich von selbst. Was passiert wenn ein ganzer Server ausfällt?
VLG
danke für die super Erklärung. In der Praxis heisst das für mich dann, dass ich z. B. 5-10 Server nehme und in jeden Server z. B. 5 Platten reinmache, die nicht im Raid laufen sondern einzeln. Dann die Installation von Ceph und Ceph verteilt dann die Daten redundant über alle Platte auf allen Servern? Gibt es dazu ein Diagramm oder ein vernünftiges Tutorial? Wenn ich das richtig verstehe: Ich setze Hot-Swap Platten ein. Wenn in irgendeinem Server eine Platte defekt ist, nehm ich sie raus und ersetz durch eine neue Platte. Das System heilöt sich von selbst. Was passiert wenn ein ganzer Server ausfällt?
VLG
Was bei einem Ausfall einzelner OSDs oder ganzer Server passieren soll, kann man in Grenzen konfigurieren.
Normalerweise beginnt die Reorganisation sofort bei Ausfällen, man kann aber konfigurieren dass ein gewisses Timeout verstreichen soll bis eine Reorganisation beginnt.
Aber in der Tat: Sollte ein ganzer Server ausfallen, beginnt eine automatische Reorganisation der Daten um die Redundanz zu erhalten.
Normalerweise beginnt die Reorganisation sofort bei Ausfällen, man kann aber konfigurieren dass ein gewisses Timeout verstreichen soll bis eine Reorganisation beginnt.
Aber in der Tat: Sollte ein ganzer Server ausfallen, beginnt eine automatische Reorganisation der Daten um die Redundanz zu erhalten.
Super,
jetzt nur noch eine Frage. Wie sollte die Hardwarekonfiguration der Server aussehen.
Braucht man Raid-Controller oder kann man die weglassen. Packt man einfach Festplatten rein und das System verteilt die Daten über alle Festplaten? Wie muss ich mir das vorstellen?
VLG
jetzt nur noch eine Frage. Wie sollte die Hardwarekonfiguration der Server aussehen.
Braucht man Raid-Controller oder kann man die weglassen. Packt man einfach Festplatten rein und das System verteilt die Daten über alle Festplaten? Wie muss ich mir das vorstellen?
VLG
RAID-Controller braucht man nicht. Wenn du die Festplatten alle angeschlossen bekommst und die Geschwindigkeit OK ist, reicht der OnBoard-Controller problemlos aus.
Wir haben einen Adaptec-Controller in unseren Systemen, der aber kein RAID konfiguriert hat sondern die Festplatten 1:1 durchrieicht - einfach, weil wir sonst keine 24 Festplatten pro Server hätten ansteuern können
Die Daten werden wie gesagt vom Metadata Daemon verteilt und die Tabelle verwaltet wo was liegt. Das ganze wird als "Sharding" bezeichnet.
Wir haben einen Adaptec-Controller in unseren Systemen, der aber kein RAID konfiguriert hat sondern die Festplatten 1:1 durchrieicht - einfach, weil wir sonst keine 24 Festplatten pro Server hätten ansteuern können
Die Daten werden wie gesagt vom Metadata Daemon verteilt und die Tabelle verwaltet wo was liegt. Das ganze wird als "Sharding" bezeichnet.
Und was machst du wenn ein ganzer Server ausfällt? Bei einer Festplatte denke ich ist das kein Problem. Aber ein ganzer Server?
Die Daten sind ja redundant über verschiedene Server gespeichert.
Im Normalbetrieb sind alle Daten doppelt auf zwei verschiedenen Servern gespeichert. Wenn einer ausfällt hast du weiterhin eine Kopie auf einemen anderen Server.
Um die Redundanz zu erhalten, werden die Daten nach einer gewissen Downtime wieder auf die verbliebenen Server kopiert um die Daten wieder redundant zu haben.
Im Normalbetrieb sind alle Daten doppelt auf zwei verschiedenen Servern gespeichert. Wenn einer ausfällt hast du weiterhin eine Kopie auf einemen anderen Server.
Um die Redundanz zu erhalten, werden die Daten nach einer gewissen Downtime wieder auf die verbliebenen Server kopiert um die Daten wieder redundant zu haben.
D.h. wenn ich 5 Server habe und in jedem Server 5-10 Platten, reicht das für Ausfallsicherheit, viel Platz und gute Performance. Kann man die Monitoring und Crush Datenbanken so verteilen, dass diese auch auf mehreren Servern liegen? Gibts zum Thema Ceph gute Literatur. Woher kann ich mir die Kenntnisse holen? Kannst du mir da nen Tipp geben?
