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

2 Hardwareanforderungen und Empfehlungen

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 Objektspeicher-Nodes

2.1.1 Mindestanforderungen

  • Es sind mindestens 4 OSD-Nodes mit jeweils 8 OSD-Festplatten erforderlich.

  • Bei OSDs, die BlueStore nicht verwenden, ist mindestens 1 GB RAM pro Terabyte OSD-Basiskapazität für jeden OSD-Speicher-Node erforderlich. 1,5 GB RAM pro Terabyte OSD-Basiskapazität wird empfohlen. Bei der Wiederherstellung sind möglicherweise 2 GB RAM pro Terabyte OSD-Basiskapazität optimal.

    Bei OSDs, die BlueStore verwenden, müssen Sie zunächst die RAM-Größe berechnen, die für OSDs ohne BlueStore empfohlen wird. Danach berechnen Sie 2 GB plus die Größe des BlueStore Cache von RAM, der für jeden OSD-Prozess empfohlen wird und wählen Sie den höheren RAM-Wert der beiden Ergebnisse. Beachten Sie, dass der BlueStore-Standardcache standardmäßig 1 GB für HDD- und 3 GB für SSD-Laufwerke benötigt. Wählen Sie zusammenfassend den höheren Wert von:

    [1GB * OSD count * OSD size]

    oder

    [(2 + BS cache) * OSD count]
  • 1,5 GHz eines logischen CPU Core pro OSD ist mindestens erforderlich für jeden OSD Daemon-Prozess. 2 GHz pro OSD Daemon-Prozess werden empfohlen. Beachten Sie, dass Ceph einen OSD Daemon-Prozess pro Speicherfestplatte ausführt. Zählen Sie nicht die Festplatten, die allein zur Verwendung als OSD-Journale, WAL-Journale, omap-Metadaten oder eine beliebige Kombination dieser drei Fälle reserviert sind.

  • 10 GB Ethernet (zwei Netzwerkschnittstellen verbunden mit mehreren Schaltern).

  • OSD-Festplatten in JBOD-Konfigurationen

  • 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.

  • OSD-Nodes sollten aus Gründen der Festplattenleistung Bare Metal-Geräte sein, nicht virtualisiert.

2.1.2 Mindestfestplattengröße

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.1.3 Empfohlene Größe für das WAL- und DB-Gerät von BlueStore

Tipp
Tipp: Weitere Informationen

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

Im Folgenden erhalten Sie einige Regeln zur Berechnung der Größe für WAL/DB-Geräte. Wenn Sie DeepSea zum Bereitstellen von OSDs mit BlueStore verwenden, werden die empfohlenen Regeln automatisch angewendet und der Administrator wird entsprechend informiert.

  • 10 GB des DB-Geräts für jedes Terabyte der OSD-Kapazität (ein Hunderstel des OSD).

  • Zwischen 500 MB und 2 GB für das WAL-Gerät. Die WAL-Größe hängt vom Datenverkehr und Workload ab, nicht von der OSD-Größe. Wenn Sie wissen, dass ein OSD physisch dazu in der Lage ist, kleine Schreib- und Überschreibvorgänge bei einem sehr hohen Durchsatz zu verarbeiten, sollten Sie eher mehr als weniger Speicherplatz für WAL veranschlagen. Ein IGB WAL-Gerät ist ein guter Kompromiss, der die meisten Bereitstellungen abdeckt.

  • 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:

    bluestore_block_db_path = "/path/to/db/device"
    bluestore_block_db_size = 10737418240
    bluestore_block_wal_path = ""
    bluestore_block_wal_size = 0
  • Alternativ können Sie das WAL auf ein eigenes separates Gerät stellen. In diesem Fall empfehlen wir das schnellste Gerät für die WAL-Operation.

2.1.4 Verwenden von SSD für OSD-Journale

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.1.5 Maximale empfohlene Anzahl von Festplatten

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. Reservieren Sie für optimale Leistung mindestens 2 GB RAM pro Terabyte installierten Festplattenspeicherplatz.

  • Fehlertoleranz. Wenn der Server komplett ausfällt, verliert der Cluster temporär so viele ODSs 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.2 Monitor Nodes

  • 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.3 Object Gateway Nodes

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.4 Metadata Server Nodes

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 sind die Mindestanforderungen aufgeführt:

  • 3 GB RAM pro Metadata Server Daemon.

  • Gebundene Netzwerkschnittstelle.

  • 2,5 GHz CPU mit mindestens 2 Cores.

2.5 Salt Master

Mindestens 4 GB RAM und ein CPU mit vier Cores sind erforderlich. Die Ausführung von openATTIC am Salt Master ist darin enthalten. Für große Cluster mit Hunderten von Nodes werden 6 GB RAM vorgeschlagen.

2.6 iSCSI Nodes

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

2.7 Netzwerkempfehlungen

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.7.1 Hinzufügen eines privaten Netzwerks zu einem aktiven Cluster

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.

    sudo systemctl start ceph.target

2.7.2 Monitor Nodes in verschiedenen Teilnetzen

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 globalen Abschnitt 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] pro 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.8 Benennungseinschränkungen

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.9 Ein einziger Server für OSD und Monitor

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.10 Mindestkonfiguration für den Cluster

  • Vier Objektspeicher-Nodes

    • 10 GB Ethernet (zwei Netzwerke verbunden mit mehreren Schaltern)

    • 32 OSDs pro Speicher-Cluster

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

    • Dedizierte Betriebssystemfestplatte für jeden Objektspeicher-Node

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

    • 1,5 GHz pro OSD für jeden Objektspeicher-Node

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

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

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

      • iSCSI Gateways, Object Gateways und Metadata Server benötigen inkrementell 4 GB RAM und vier Cores

  • Separater Verwaltungs-Node mit 4 GB RAM, vier Cores, 1 TB Kapazität

2.11 Empfohlene Konfiguration für Produktions-Cluster

  • 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.12 SUSE Enterprise Storage und andere SUSE Produkte

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

2.12.1 SUSE Manager

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