it-wiki:linux:ceph
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
| it-wiki:linux:ceph [2024/07/10 04:23] – [Netzwerk] marko | it-wiki:linux:ceph [2024/07/10 06:00] (aktuell) – marko | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Hyperkonvergente Ceph-Cluster ====== | ====== Hyperkonvergente Ceph-Cluster ====== | ||
| + | * [[.ceph: | ||
| + | * [[.ceph: | ||
| + | |||
| + | ---- | ||
| Ceph ist ein verteilter Objektspeicher und Dateisystem, | Ceph ist ein verteilter Objektspeicher und Dateisystem, | ||
| Skalierbarkeit konzipiert ist. | Skalierbarkeit konzipiert ist. | ||
| Zeile 6: | Zeile 10: | ||
| * Skalierbar auf Exabyte-Ebene | * Skalierbar auf Exabyte-Ebene | ||
| * Bietet Block-, Dateisystem- und Objektspeicher | * Bietet Block-, Dateisystem- und Objektspeicher | ||
| - | * Einrichten von Pools mit unterschiedlichen Leistungs- und Redundanzmerkmalen | + | * Einrichten von [[.ceph: |
| * Daten werden repliziert, wodurch sie fehlertolerant sind | * Daten werden repliziert, wodurch sie fehlertolerant sind | ||
| * Läuft auf Standardhardware | * Läuft auf Standardhardware | ||
| Zeile 14: | Zeile 18: | ||
| Ceph besteht aus mehreren DAEMONS zur Verwendung als RBD-Speicher: | Ceph besteht aus mehreren DAEMONS zur Verwendung als RBD-Speicher: | ||
| - | * Ceph Monitor (ceph-mon, oder MON) | + | * |
| - | * Ceph Manager (ceph-mgr, oder MGS) | + | * |
| - | * Ceph Metadata Service (ceph-mds, oder MDS) | + | * |
| - | * Ceph Object Storage Daemon (ceph-osd, oder OSD) | + | * [[.ceph: |
| ===== Empfehlungen für einen gesunden Ceph-Cluster ===== | ===== Empfehlungen für einen gesunden Ceph-Cluster ===== | ||
| Zeile 26: | Zeile 30: | ||
| Ceph-Dienste können in zwei Kategorien eingeteilt werden: | Ceph-Dienste können in zwei Kategorien eingeteilt werden: | ||
| * Intensive CPU-Auslastung, | * Intensive CPU-Auslastung, | ||
| - | * **Object Storage Daemon (OSD)-Dienste** | + | * **Object Storage Daemon ([[.ceph: |
| - | * Meta Data Service (MDS), der für CephFS verwendet wird | + | * Meta Data Service (MDS), der für [[.ceph: |
| * Moderate CPU-Auslastung, | * Moderate CPU-Auslastung, | ||
| - | * Monitor (MON)-Dienste | + | * [[.ceph: |
| - | * Manager (MGR)-Dienste | + | * [[.ceph: |
| Als einfache Faustregel solltest Du jedem Ceph-Dienst mindestens einen CPU-Kern (oder Thread) zuweisen, um die Mindestressourcen bereitzustellen, | Als einfache Faustregel solltest Du jedem Ceph-Dienst mindestens einen CPU-Kern (oder Thread) zuweisen, um die Mindestressourcen bereitzustellen, | ||
| - | Wenn Du beispielsweise planst, einen Ceph-Monitor, | + | Wenn Du beispielsweise planst, einen [[.ceph: |
| - | Beachte, dass die CPU-Auslastung von OSDs hauptsächlich von der Festplattenleistung abhängt. Je höher die möglichen IOPS (IO | + | Beachte, dass die CPU-Auslastung von [[.ceph: |
| - | Operations per Second) einer Festplatte sind, desto mehr CPU kann von einem OSD-Dienst genutzt werden. Bei modernen Enterprise-SSD-Festplatten, | + | Operations per Second) einer Festplatte sind, desto mehr CPU kann von einem [[.ceph: |
| Zeile 44: | Zeile 48: | ||
| überwacht werden. | überwacht werden. | ||
| - | Als Faustregel gilt: Für etwa **1 TiB Daten wird 1 GiB Speicher** von einem OSD verwendet. Während die Nutzung | + | Als Faustregel gilt: Für etwa **1 TiB Daten wird 1 GiB Speicher** von einem [[.ceph: |
| unter normalen Bedingungen geringer sein kann, wird sie bei kritischen Vorgängen wie recovery, re-balancing | unter normalen Bedingungen geringer sein kann, wird sie bei kritischen Vorgängen wie recovery, re-balancing | ||
| oder backfilling (Auffüllen) am meisten genutzt. Das bedeutet, dass Du vermeiden solltest, Deinen verfügbaren Speicher bereits im Normalbetrieb voll auszuschöpfen, | oder backfilling (Auffüllen) am meisten genutzt. Das bedeutet, dass Du vermeiden solltest, Deinen verfügbaren Speicher bereits im Normalbetrieb voll auszuschöpfen, | ||
| - | Der OSD-Dienst selbst wird zusätzlichen Speicher verwenden. Das Ceph BlueStore-Backend des Daemons benötigt | + | Der [[.ceph: |
| standardmäßig 3-5 GiB Speicher (anpassbar). | standardmäßig 3-5 GiB Speicher (anpassbar). | ||
| Zeile 55: | Zeile 59: | ||
| [[.ceph: | [[.ceph: | ||
| - | Ich empfehle eine Netzwerkbandbreite von mindestens 10 Gbit/s oder mehr, die ausschließlich für Ceph-Verkehr verwendet wird. Ein 1-Mesh-Netzwerk-Setup ist auch eine Option für Cluster mit drei bis fünf Knoten, wenn keine Switches mit 10+ Gbit/s verfügbar sind. Um Deinen Bandbreitenbedarf abzuschätzen, | + | Ich empfehle eine Netzwerkbandbreite von mindestens 10 Gbit/s oder mehr, die ausschließlich für Ceph-Verkehr verwendet wird. Ein 1-Mesh-Netzwerk-Setup ist auch eine Option für Cluster mit drei bis fünf Knoten, wenn keine Switches mit 10+ Gbit/s verfügbar sind. Um Deinen Bandbreitenbedarf abzuschätzen, |
| Wenn Du Dir nicht sicher bist, empfehle ich die Verwendung von zwei (physischen) separaten Netzwerken für Hochleistungs-Setups: | Wenn Du Dir nicht sicher bist, empfehle ich die Verwendung von zwei (physischen) separaten Netzwerken für Hochleistungs-Setups: | ||
| Zeile 65: | Zeile 69: | ||
| Besonders bei kleinen Clustern kann die Wiederherstellung lange dauern. Es wird empfohlen, in kleinen Setups SSDs anstelle von HDDs zu verwenden, um die Wiederherstellungszeit zu verkürzen und die Wahrscheinlichkeit eines nachfolgenden Fehlerereignisses während der Wiederherstellung zu minimieren. | Besonders bei kleinen Clustern kann die Wiederherstellung lange dauern. Es wird empfohlen, in kleinen Setups SSDs anstelle von HDDs zu verwenden, um die Wiederherstellungszeit zu verkürzen und die Wahrscheinlichkeit eines nachfolgenden Fehlerereignisses während der Wiederherstellung zu minimieren. | ||
| - | Im Allgemeinen bieten SSDs mehr IOPS als rotierende Festplatten. In Anbetracht dessen kann es neben den höheren Kosten sinnvoll sein, eine klassenbasierte Trennung der Pools zu implementieren. Eine andere Möglichkeit, | + | Im Allgemeinen bieten SSDs mehr IOPS als rotierende Festplatten. In Anbetracht dessen kann es neben den höheren Kosten sinnvoll sein, eine klassenbasierte Trennung der [[.ceph: |
| Abgesehen vom Festplattentyp funktioniert Ceph am besten mit einer gleichmäßig großen und gleichmäßig verteilten Anzahl von Festplatten pro Knoten. Beispielsweise sind 4 x 500 GB-Festplatten in jedem Knoten besser als eine gemischte Konfiguration mit einer einzelnen 1 TB- und drei 250 GB-Festplatten. | Abgesehen vom Festplattentyp funktioniert Ceph am besten mit einer gleichmäßig großen und gleichmäßig verteilten Anzahl von Festplatten pro Knoten. Beispielsweise sind 4 x 500 GB-Festplatten in jedem Knoten besser als eine gemischte Konfiguration mit einer einzelnen 1 TB- und drei 250 GB-Festplatten. | ||
| - | Du musst auch die Anzahl der OSDs und die Kapazität einzelner | + | Du musst auch die Anzahl der [[.ceph: |
| === Vermeide RAID === | === Vermeide RAID === | ||
| - | Da Ceph Datenobjektredundanz und mehrere parallele Schreibvorgänge auf Festplatten (OSDs) selbst handhabt, verbessert die Verwendung eines RAID-Controllers normalerweise weder die Leistung noch die Verfügbarkeit. Im Gegenteil, Ceph ist darauf ausgelegt, ganze Festplatten allein und ohne Abstraktion dazwischen zu handhaben. RAID-Controller sind nicht für die Ceph-Arbeitslast ausgelegt und können die Dinge verkomplizieren und manchmal sogar die Leistung verringern, da ihre Schreib- und Caching-Algorithmen mit denen von Ceph in Konflikt geraten können. | + | Da Ceph Datenobjektredundanz und mehrere parallele Schreibvorgänge auf Festplatten ([[.ceph: |
it-wiki/linux/ceph.1720585390.txt.gz · Zuletzt geändert: 2024/07/10 04:23 von marko