Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Enterprise Storage 6

2 Hardwareanforderungen und Empfehlungen Edit source

Die Hardwareanforderungen für Ceph hängen stark vom E/A-Workload ab. Die folgenden Hardwareanforderungen und Empfehlungen sollten als Ausgangspunkt für die detaillierte Planung betrachtet werden.

Im Allgemeinen sind die Empfehlungen in diesem Abschnitt auf jeweils einen Prozess ausgelegt. Wenn auf dem selben Rechner mehrere Prozesse ablaufen, müssen die CPU-, RAM-, Festplatten- und Netzwerkanforderungen entsprechend erhöht werden.

2.1 Konfigurationen mit mehreren Architekturen Edit source

SUSE Enterprise Storage unterstützt sowohl x86- als auch Arm-Architekturen. Bei der Erwägung der einzelnen Architekturen ist zu beachten, dass es bei den Cores pro OSD, der Frequenz und dem RAM keine gravierenden Unterschiede zwischen den CPU-Architekturen gibt, die sich auf die Größenfestlegung auswirken würden.

Wie bei kleineren x86-Prozessoren (keine Server) bieten weniger leistungsstarke Arm-basierte Cores unter Umständen keine optimalen Arbeitsbedingungen, insbesondere wenn sie für Pools mit Löschcodierung eingesetzt werden.

2.2 Mindestkonfiguration für den Cluster Edit source

  • Es sind mindestens vier OSD Nodes mit jeweils acht OSD-Festplatten erforderlich.

  • Drei Ceph Monitor Nodes (SSD für dediziertes Betriebssystemlaufwerk erforderlich).

  • iSCSI-Gateways, Object Gateways und Metadatenserver benötigen inkrementell 4 GB RAM und vier Cores.

  • Für Ceph Monitors, Object Gateways und Metadatenserver Nodes ist eine redundante Bereitstellung erforderlich.

  • Separater Verwaltungs-Node mit 4 GB RAM, vier Cores, 1 TB Kapazität. Dies ist in der Regel der Salt Master Node. Ceph Services und Gateways, z. B. Ceph Monitor, Ceph Manager, Metadatenserver, Ceph OSD, Object Gateway oder NFS Ganesha, werden auf dem Admin Node nicht unterstützt.

2.3 Objektspeicher-Nodes Edit source

2.3.1 Mindestanforderungen Edit source

  • CPU-Empfehlungen:

    • Ein 2-GHz-CPU-Thread pro rotierendem Datenträger

    • Zwei 2-GHz-CPU-Threads pro SSD

    • Vier 2-GHz-CPU-Threads pro NVMe

  • Separate 10-GbE-Netzwerke (öffentlich/Client und Back-End), erforderlich 4 × 10 GbE, empfohlen 2 × 25 GbE.

  • Insgesamt benötigtes RAM = Anzahl der OSDs × (1 GB + osd_memory_target) + 16 GB

    Weitere Informationen zu osd_memory_target finden Sie in Abschnitt 16.2.1, „Automatische Festlegung der Cache-Größe“.

  • OSD-Datenträger in JBOD-Konfigurationen oder individuelle RAID-0-Konfigurationen.

  • OSD-Journal darf sich auf der OSD-Festplatte befinden.

  • OSD-Festplatten sollten exklusiv von SUSE Enterprise Storage verwendet werden.

  • Dedizierte Festplatte/SSD für das Betriebssystem, vorzugsweise in einer RAID 1-Konfiguration.

  • Wenn dieser OSD-Host einen Teil eines Cache Pools hostet, der für ein Cache Tiering verwendet wird, müssen Sie mindestens weitere 4 GB RAM zuordnen.

  • Ceph Monitors, Gateway und Metadata Server dürfen in Objektspeicher-Nodes vorhanden sein.

  • Aus Gründen der Datenträgerleistung wird Bare Metal-Hardware für OSD Nodes empfohlen (keine virtuellen Maschinen).

2.3.2 Mindestfestplattengröße Edit source

Zwei Arten von Festplattenspeicherplatz werden zur Ausführung auf OSD benötigt: der Speicherplatz für das Festplattenjournal (für FileStore) oder WAL/DB-Gerät (für BlueStore) sowie der primäre Speicherplatz für die gespeicherten Daten. Der Mindestwert (und Standardwert) für Journal/WAL/DB beträgt 6 GB. Der Mindestspeicherplatz für Daten beträgt 5 GB, da Partitionen, die kleiner als 5 GB sind, das Gewicht 0 zugewiesen wird.

Auch wenn nun der Mindestspeicherplatz für ein OSD 11 GB beträgt, empfehlen wir mindestens 20 GB pro Festplatte, sogar für Testzwecke.

2.3.3 Empfohlene Größe für das WAL- und DB-Gerät von BlueStore Edit source

Tipp
Tipp: Weitere Informationen

Weitere Informationen zu BlueStore finden Sie in Abschnitt 1.4, „BlueStore“.

  • Es wird empfohlen, 4 GB für das WAL-Gerät zu reservieren. Die empfohlene Größe für DB liegt bei den meisten Workloads bei 64 GB.

  • Falls Sie beabsichtigen, das WAL- und DB-Gerät auf dieselbe Festplatte zu stellen, dann empfehlen wir eine einzelne Partition für beide Geräte statt eine eigene Partition pro Gerät. Dadurch kann Ceph das DB-Gerät auch für WAL-Operationen verwenden. Die Verwaltung des Festplattenspeicherplatzes ist daher effizienter, weil Ceph die DB-Partition für WAL nur dann verwendet, wenn es unbedingt erforderlich ist. Ein weiterer Vorteil besteht darin, dass eine volle Auslastung der WAL-Partition sehr unwahrscheinlich ist und kein Speicherplatz verschwendet wird, da er gegebenenfalls auch für DB-Operationen verwendet werden kann.

    Um das DB-Gerät für WAL freizugeben, geben Sie nicht das WAL-Gerät an, sondern nur das DB-Gerät.

    Weitere Informationen zum Festlegen eines OSD-Layouts finden Sie in Abschnitt 5.5.2, „DriveGroups“.

2.3.4 Verwenden von SSD für OSD-Journale Edit source

Solid-State- oder Festkörperlaufwerke (SSD) haben keine beweglichen Teile. Dadurch wird die Zeit für den zufälligen Zugriff und die Leselatenz reduziert und der Datendurchsatz beschleunigt. Da der Preis pro 1 MB für SSDs erheblich höher ist als der Preis für sich drehende Festplatten, eignen sich SSDs nur für kleinere Speicher.

Die Leistung von OSDs wird möglicherweise erheblich verbessert, wenn Sie deren Journal auf einem SSD speichern und die Objektdaten auf einer separaten Festplatte.

Tipp
Tipp: Gemeinsame Nutzung eines SSD für mehrere Journale

Da Journaldaten relativ wenig Speicherplatz belegen, können Sie mehrere Journalverzeichnisse auf einer einzigen SSD-Festplatte einhängen. Bedenken Sie dabei jedoch, dass sich mit jedem freigegebenen Journal die Leistung der SSD-Festplatte verschlechtert. Wir empfehlen, maximal sechs Journale pro SSD-Festplatte zu speichern und zwölf pro NVMe-Festplatte.

2.3.5 Maximale empfohlene Anzahl von Festplatten Edit source

Jeder Server kann so viele Festplatten enthalten wie für ihn zulässig sind. Bei der Planung der Anzahl von Festplatten pro Server gibt es einiges zu bedenken:

  • Netzwerk-Bandbreite. Je mehr Festplatten ein Server enthält, desto mehr Daten müssen für die Schreiboperationen der Festplatte über die Netzwerkkarte(n) übertragen werden.

  • Arbeitsspeicher. RAM ab 2 GB wird für den BlueStore-Cache herangezogen. Mit dem Standardwert von 4 GB für osd_memory_target erhält das System eine angemessene Cache-Anfangsgröße für rotierende Datenträger. Bei SSD oder NVME sollten Sie die Cache-Größe und die RAM-Zuordnung pro OSD erhöhen, damit die höchstmögliche Leistung erzielt wird.

  • Fehlertoleranz. Wenn der Server komplett ausfällt, verliert der Cluster temporär so viele OSDs wie er Festplatten hat. Darüberhinaus müssen Sie alle Daten des ausgefallenen Servers auf die anderen Nodes im Cluster kopieren, damit die Reproduktionsregeln weiterhin ausgeführt werden.

2.4 Monitor Nodes Edit source

  • Mindestens drei Ceph Monitor Nodes sind erforderlich. Die Anzahl der Monitors sollte immer ungerade sein (1+2n).

  • 4 GB RAM.

  • Prozessor mit vier logischen Cores.

  • Ein SSD oder ein anderer ausreichend schneller Speichertyp ist für Monitors sehr zu empfehlen, insbesondere für den Pfad /var/lib/ceph in jedem Monitor Node, da das Quorum bei hohen Festplattenlatenzen möglicherweise instabil ist. Zwei Festplatten in der RAID 1-Konfiguration werden aus Redundanzgründen empfohlen. Es wird empfohlen, dass separate Festplatten oder mindestens separate Festplattenpartitionen für die Überwachungsprozesse zur Verfügung stehen, um den verfügbaren Festplattenspeicherplatz des Monitors vor Ereignissen wie schleichender Protokolldateiausweitung zu schützen.

  • Pro Node darf nur ein Überwachungsprozess vorhanden sein.

  • Die Kombination von OSD, Monitor oder Object Gateway Nodes wird nur unterstützt, wenn ausreichend Hardwareressourcen verfügbar sind. Dies bedeutet, dass die Anforderungen für alle Services aufsummiert werden müssen.

  • Zwei Netzwerkschnittstellen verbunden mit mehreren Schaltern.

2.5 Object Gateway Nodes Edit source

Object Gateway Nodes sollten sechs bis acht CPU Cores und 32 GB RAM haben (64 GB empfohlen). Wenn sich noch andere Prozesse auf demselben Rechner befinden, müssen deren Anforderungen aufsummiert werden.

2.6 Metadata Server Nodes Edit source

Die richtige Größe der Metadata Server Nodes hängt vom spezifischen Anwendungsfall ab. Generell gilt, je mehr offene Dateien der Metadata Server verarbeiten muss, desto mehr CPU und RAM benötigt er. Nachfolgend finden Sie die Mindestanforderungen an die

  • 3 GB RAM für jeden Metadatenserver-Daemon.

  • Gebundene Netzwerkschnittstelle.

  • 2,5 GHz CPU mit mindestens 2 Cores.

2.7 Salt Master Edit source

Mindestens 4 GB RAM und ein CPU mit vier Cores sind erforderlich. Dies umfasst die Ausführung des Ceph Dashboards auf dem Admin Node. Für große Cluster mit Hunderten von Nodes werden 6 GB RAM vorgeschlagen.

2.8 iSCSI Nodes Edit source

iSCSI Nodes sollten sechs bis acht CPU-Cores und 16 GB RAM haben.

2.9 Netzwerkempfehlungen Edit source

Die Netzwerkumgebung, in der Sie Ceph ausführen möchten, sollte idealerweise eine gebundene Gruppe von mindestens zwei Netzwerkschnittstellen sein, die logisch aufgeteilt ist in einen öffentlichen Teil und einen verbürgten internen Teil über VLANs. Der empfohlene Bindungsmodus ist 802.3ad, falls möglich, um maximale Bandbreite und Stabilität zur Verfügung zu stellen.

Das öffentliche VLAN dient dazu, den Service für Kunden bereitzustellen. Der interne Teil sorgt für die authentifizierte Ceph Netzwerkkommunikation. Der Hauptgrund dafür besteht darin, dass die Nachrichten zum Konfigurieren geheimer Schlüssel möglicherweise öffentlich übertragen werden und daher eine Schwachstelle darstellen, denn Ceph bietet Authentifizierung und Schutz vor Angriffen erst, nachdem diese geheimen Schlüssel hinzugefügt wurden.

Tipp
Tipp: Über DHCP konfigurierte Nodes

Wenn Ihre Speicher-Nodes über DHCP konfiguriert werden, reichen die standardmäßigen Zeitüberschreitungen möglicherweise nicht für eine korrekte Konfiguration des Netzwerks aus, bevor die Ceph Daemons starten. In diesem Fall starten die Ceph MONs und OSDs nicht korrekt (die Ausführung von systemctl status ceph\* führt zu „unable to bind“-Fehlern). Wir empfehlen, die Zeitüberschreitung des DHCP-Clients in jedem Node in Ihrem Speicher-Cluster auf mindestens 30 Sekunden zu erhöhen. Dies wird erreicht durch Ändern der folgenden Einstellungen in jedem Node:

Legen Sie in /etc/sysconfig/network/dhcp Folgendes fest:

DHCLIENT_WAIT_AT_BOOT="30"

Legen Sie in /etc/sysconfig/network/config Folgendes fest:

WAIT_FOR_INTERFACES="60"

2.9.1 Hinzufügen eines privaten Netzwerks zu einem aktiven Cluster Edit source

Wenn Sie bei der Ceph-Bereitstellung kein Cluster-Netzwerk angeben, dann wird eine einzelne öffentliche Netzwerkumgebung angenommen. Auch wenn Ceph in einem öffentlichen Netzwerk gut funktioniert, wird seine Leistung und Sicherheit durch Festlegen eines zweiten privaten Cluster-Netzwerks erhöht. Zur Unterstützung von zwei Netzwerken muss jeder Ceph Node über mindestens zwei Netzwerkkarten verfügen.

Sie müssen auf jeden Ceph Node die folgenden Änderungen anwenden. Bei einem kleinen Cluster ist dies relativ schnell erledigt, doch bei einem Cluster mit Hunderten oder Tausenden Nodes kann dieser Vorgang sehr zeitaufwändig sein.

  1. Halten Sie die auf Ceph bezogenen Services in jedem Cluster Node an.

    Fügen Sie eine Zeile zu /etc/ceph/ceph.conf hinzu, um das Cluster-Netzwerk zu definieren. Beispiel:

    cluster network = 10.0.0.0/24

    Wenn Sie eigens statische IP-Adressen zuweisen oder die cluster network-Einstellungen außer Kraft setzen müssen, können Sie dies mit der optionalen Einstellung cluster addr erledigen.

  2. Überprüfen Sie, ob das private Cluster-Netzwerk auf Betriebssystemebene wie erwartet funktioniert.

  3. Starten Sie die auf Ceph bezogenen Services in jedem Cluster Node.

    root # systemctl start ceph.target

2.9.2 Monitor Nodes in verschiedenen Teilnetzen Edit source

Wenn sich die Monitor Nodes in mehreren Teilnetzen befinden, beispielsweise in verschiedenen Räumen und durch verschiedene Schalter gesteuert, dann müssen Sie die Datei ceph.conf entsprechend anpassen. Wenn beispielsweise die Nodes die IP-Adressen 192.168.123.12, 1.2.3.4 und 242.12.33.12 aufweisen, fügen Sie die folgenden Zeilen zum Abschnitt global hinzu:

[global]
[...]
mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12
mon initial members = MON1, MON2, MON3
[...]

Müssen Sie eine öffentliche Adresse oder ein öffentliches Netzwerk pro Monitor angeben, dann müssen Sie außerdem einen Abschnitt [mon.X] für jeden Monitor hinzufügen:

[mon.MON1]
public network = 192.168.123.0/24

[mon.MON2]
public network = 1.2.3.0/24

[mon.MON3]
public network = 242.12.33.12/0

2.10 Benennungseinschränkungen Edit source

Ceph unterstützt nicht generell Nicht-ASCII-Zeichen in Konfigurationsdateien, Pool-Namen, Benutzernamen und so weiter. Wir empfehlen, beim Konfigurieren eines Ceph Clusters in allen Ceph-Objekt- bzw. Konfigurationsnamen nur einfache alphanumerische Zeichen (A-Z, a-z, 0-9) und wenige Satzzeichen ('.', '-', '_') zu verwenden.

2.11 Ein einziger Server für OSD und Monitor Edit source

Obwohl es technisch möglich ist, Ceph OSDs und Monitors in Testumgebungen auf demselben Server auszuführen, empfehlen wir dringend, einen separaten Server für jeden Monitor Node in der Produktionsumgebung einzurichten. Der hauptsächliche Grund dafür ist die Leistung. Je mehr OSDs der Cluster enthält, desto mehr E/A-Operationen müssen die Monitor Nodes durchführen. Wenn ein Server von einem Monitor Node und OSD(s) gemeinsam genutzt wird, stellen die E/A-Operationen des OSD eine Beschränkung für den Monitor Node dar.

Es ist weiterhin zu überlegen, ob Festplatten von einem OSD, einem Monitor Node und dem Betriebssystem auf dem Server gemeinsam genutzt werden sollen. Die Antwort ist einfach: wenn möglich, stellen Sie eine separate Festplatte für den OSD bereit und einen separaten Server für einen Monitor Node.

Obwohl Ceph verzeichnisbasierte OSDs unterstützt, sollte für einen OSD immer eine eigene Festplatte vorhanden sein und nicht die des Betriebssystems dafür genutzt werden.

Tipp
Tipp

Wenn es wirklich erforderlich ist, OSD und Monitor Node auf demselben Server auszuführen, führen Sie den Monitor auf einer separaten Festplatte aus. Hängen Sie dazu die Festplatte im Verzeichnis /var/lib/ceph/mon ein, um die Leistung etwas zu verbessern.

2.12 Empfohlene Konfiguration für Produktions-Cluster Edit source

  • Sieben Objektspeicher-Nodes

    • Die einzelnen Nodes dürfen nicht mehr als ca. 15 % des Gesamtspeichers ausmachen

    • 10 GB Ethernet (vier physische Netzwerke gebunden an mehrere Schalter)

    • Mindestens 56 OSDs pro Speicher-Cluster

    • RAID 1-Betriebssystemfestplatte für jeden OSD-Speicher-Node

    • SSDs für Journal im Verhältnis 6:1 von SSD-Journal zu OSD

    • 1,5 GB RAM pro TB der OSD-Basiskapazität für jeden Objektspeicher-Node

    • 2 GHz pro OSD für jeden Objektspeicher-Node

  • Dedizierte physische Infrastruktur-Nodes

    • Drei Ceph Monitor Nodes: 4 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte

    • Ein SES-Verwaltungs-Node: 4 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte

    • Redundante physische Bereitstellung von Gateway oder Metadata Server Nodes:

      • Object Gateway Nodes: 32 GB RAM, 8-Core-Prozessor, RAID 1-SSDs als Festplatte

      • iSCSI Gateway Nodes: 16 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte

      • Metadata Server Nodes (einer aktiv, einer unmittelbar betriebsbereit im Standby-Modus): 32 GB RAM, 8-Core-Prozessor, RAID 1-SSDs als Festplatte

2.13 SUSE Enterprise Storage 6 und andere SUSE-Produkte Edit source

Dieser Abschnitt enthält wichtige Informationen zur Integration von SUSE Enterprise Storage 6 in andere SUSE-Produkte.

2.13.1 SUSE Manager Edit source

SUSE Manager und SUSE Enterprise Storage sind nicht integriert. Daher kann SUSE Manager aktuell keinen SUSE Enterprise Storage Cluster verwalten.