Zum Inhalt springen

Beurteilung eines Ceph Konzepts


carstenj

Empfohlene Beiträge

Hi,

wir haben hier in unserer Firma folgende Situation:

  • Zahlreiche Server mit eingebauten Festplatten (1 TB)
  • Auf diesen Servern läuft jeweils XEN und darauf VMs
  • Jede der auf den Servern befindlichen Festplatten ist im Cephcluster registriert

Das hat nun zur Folge, dass jedes Ausschalten eines Servers die komplette Ceph Infrastruktur beeinträchtigt, weil dann natürlich auch mal eben 4TB aus dem Cluster entfernt werden.

Meine Zweifel an diesem Konzept sind natürlich, ob das nicht ein eher suboptimaler weg ist. Ich hätte jetzt vermutlich eher ein eigenens System nur für Ceph eingerichtet, welches natürlich völlig unabhängig von den einzelnen Servern agiert. Oder verstehe ich Ceph nur falsch?

 

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Server sind eigentlich dafür da, dass sie permanent laufen sollen...

Das Ceph-Konzept plant, dass, wenn ein Server ausfällt, sich die Last auf andere Server verteilt und alles, wie gewohnt, weiter laufen kann.

Falls Du Server immer wieder ausschalten können willst, ist das eher ein ungeeignetes Konzept. Das wird hauptsächlich von Firmen verwendet, die HA erfolgreich umsetzen wollen.

Ich sehe Ceph als Nachfolger von heartbeat und pacemaker mit DRBD.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Die Grundidee hinter Ceph ist, dass du ein verteiltes Storage hast, dass unabhängig der Geräte und der Festplattengröße skalieren kann. Das Gegenteil einer solche Lösung wäre ein zentraler Datenspeicher, z. B. ein SAN. Aufgrund fest eingerichter RAIDs ist ein SAN nur schwer skalierbar. Du kannst an ein SAN natürlich eine Erweiterung hängen, musst dann aber das SAN reorganisieren oder ein weiteres RAID einrichten. Mal eben alle 2 TB Platten gegen 4 TB Platten tauschen ist bei einem SAN mit einem festen RAID (z. B. 5 oder 6) nicht möglich. Auch kannst du keinen Mix aus verschiedenen Festplattengrößen im RAID laufen lassen, ohne erheblichen Speicherpatzverlust einzubüßen (RAID-0 mal außer acht gelassen). Ein Ceph Storage ist hier bei weitem flexibler.

Natürlich fehlen 4 TB im Ceph Storage, wenn der Datenspeicher Offline geht. Aufgrund des Designs von Ceph sollte dadurch aber keine echte Downtime der Infrastruktur (VM's) entstehen, da die Last schnell von den übrigen System aufgefangen werden kann. Ich kenne das auch nur aus der Theorie, wir selbst haben nur SAN's im Einsatz. Wahrscheinlich werden die Daten im gewisser Weise redundant über die Infrastruktur verteilt - wie das Technische im Detail abläuft - keine Ahnung, es wird aber irgendwo der Fall sein, weil sonst so eine Infrastruktur nicht hochverfügbar wäre (Ceph bewirbt ja aber genau das).

Beide Systeme haben sicherlich ihre Vor- und Nachteile. Ceph auf einem zentralen Datenspeicher in Betrieb zu nehmen macht hingegen keinen Sinn. Ceph fungiert hier wie eine Art "virtuelles Dateisystem". Dann kann man sich Ceph sparen und direkt auf dem Datenspeicher als organisierten RAID-Verbund operieren und alle XEN-Hosts daran anbinden.

Bearbeitet von halcyon
Link zu diesem Kommentar
Auf anderen Seiten teilen

Quote

Oder verstehe ich Ceph nur falsch?

Nein Du hast nur einen der vielen Nachteile eines verteilten Speichersystems aus erster Hand erfahren (bei allen hier unerwaehnten Vorteilen, die sie durchaus eine gute Loesung fuer viele denkbare Szenarien sein lassen)... warte einfach bis Dir der gesamte Cluster wegen einem Husten von einer total unbekannten Node um die Ohren fliegt und die Platzreduzierung ist Dein geringstes Problem :)

PS: Brutto und Nettokapazitaet in verteilten System mit Uptime SLA berechnen ist teilweise ne Wissenschaft fuer sich ... Plan Deine Kapazitaet wie Du sie Brutto brauchst, schau was Du an netto fuer interne Redundanzen dafuer benoetigst und dann fueg mindestens 1 baugleiche Node von der Kapazitaet hinzu als Daumenregel. Verteilten Storage bauen der nur Kapazitaet hat wenn alle Nodes verfuegbar sind ist sehr kontraproduktiv :)

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 4 Monate später...

Google: noout oder/und out time 

Sag dem Ceph einfach, was Du vorhast, dann nimmt es den Host nicht gleich fuer tot.

Und sorg dafuer, dass es generell die Replikationslast fuer einen Rechner samt OSDs vertraegt.

Es muss performancemaessig so eingestellt und ausgelegt sein, dass eine Replikation noch ertragbar ist. Wie halt nen Rebuild bei nem Raid, ggf. auch einfach ein wenig bremsen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...