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 Netzwerke im Überblick #
Ceph verfügt über einige logische Netzwerke:
Ein Frontend-Netzwerk namens
öffentliches Netzwerk.Ein vertrauenswürdiges internes Netzwerk, das Back-End-Netzwerk, namens
Clusternetzwerk. Diese Einstellung ist optional.Ein oder mehrere Client-Netzwerke für Gateways. Dies ist optional und würde den Rahmen dieses Kapitels sprengen.
Das öffentliche Netzwerk ist das Netzwerk, über das Ceph-Daemons untereinander und mit ihren Clients kommunizieren. Das bedeutet, dass der gesamte Datenverkehr des Ceph-Clusters über dieses Netzwerk läuft, es sei denn, es ist ein Clusternetzwerk konfiguriert.
Das Clusternetzwerk ist das Back-End-Netzwerk zwischen den OSD-Knoten für Reproduktion, Ausgleich und Wiederherstellung. Ist dieses optionale Netzwerk konfiguriert, würde es im Idealfall die doppelte Bandbreite des öffentlichen Netzwerks mit standardmäßiger Drei-Wege-Reproduktion bieten, da das primäre OSD zwei Kopien an andere OSDs über dieses Netzwerk sendet. Das öffentliche Netzwerk befindet sich zwischen Clients und Gateways auf der einen Seite für die Kommunikation mit Monitoren, Managern, MDS-Knoten und OSD-Knoten. Monitore, Manager und MDS-Knoten nutzen es auch für die Kommunikation mit OSD-Knoten.
2.1.1 Netzwerkempfehlungen #
Wir empfehlen ein einzelnes fehlertolerantes Netzwerk mit ausreichender Bandbreite für Ihre Anforderungen. Für die öffentliche Ceph-Netzwerkumgebung empfehlen wir zwei verbundene 25-GbE-Netzwerkschnittstellen (oder schneller), die über 802.3ad (LACP) verbunden sind. Dies wird als die Mindesteinrichtung für Ceph betrachtet. Wenn Sie zusätzlich ein Clusternetzwerk verwenden, empfehlen wir vier verbundene 25-GbE-Netzwerkschnittstellen. Durch Verbinden von zwei oder mehr Netzwerkschnittstellen verbessern sich der Durchsatz durch Link-Aggregation und, bei redundanten Links und Switches, die Fehlertoleranz und Wartbarkeit.
Sie können auch VLANs erstellen, um verschiedene Arten von Datenverkehr über eine Verbindung zu isolieren. Sie können beispielsweise eine Verbindung erstellen, um zwei VLAN-Schnittstellen bereitzustellen, eine für das öffentliche Netzwerk und die zweite für das Clusternetzwerk. Beim Einrichten des Ceph-Netzwerks ist dies jedoch nicht erforderlich. Details zum Verbinden von Schnittstellen finden Sie unter https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding.
Die Fehlertoleranz kann durch Isolierung der Komponenten in Fehlerdomänen erhöht werden. Zur Erhöhung der Fehlertoleranz des Netzwerks wird durch Verbinden einer Schnittstelle von zwei separaten Netzwerkschnittstellenkarten (NIC) Schutz vor dem Ausfall einer einzelnen NIC erreicht. In ähnlicher Weise schützt das Erstellen einer Verbindung zwischen zwei Switches vor dem Ausfall eines Switches. Wir empfehlen, den Hersteller der Netzwerkgeräte zu konsultieren, um den erforderlichen Grad an Fehlertoleranz zu ermitteln.
Die Einrichtung eines zusätzlichen Verwaltungsnetzwerks, das zum Beispiel die Trennung von SSH-, Salt- oder DNS-Netzwerken ermöglicht, wurde weder getestet, noch wird sie unterstützt.
Wenn Ihre Speicherknoten ü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. Wenn dies geschieht, werden die Ceph-MONs und -OSDs nicht korrekt gestartet (das Ausführen von systemctl status ceph\* führt zur Fehlermeldung „unable to bind“ (Verbinden nicht möglich)). Zur Vermeidung dieses Problems empfehlen wir, die DHCP-Client-Zeitüberschreitung auf jedem Knoten in Ihrem Speichercluster auf mindestens 30 Sekunden zu erhöhen. Dies wird erreicht durch Ändern der folgenden Einstellungen in jedem Knoten:
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.1.1.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-Knoten über mindestens zwei Netzwerkkarten verfügen.
Sie müssen auf jeden Ceph-Knoten die folgenden Änderungen anwenden. Bei einem kleinen Cluster ist dies relativ schnell erledigt, doch bei einem Cluster mit Hunderten oder Tausenden Knoten kann dieser Vorgang sehr zeitaufwändig sein.
Legen Sie das Clusternetzwerk mit folgendem Kommando fest:
#ceph config set global cluster_network MY_NETWORKStarten Sie die OSDs neu, um das angegebene Clusternetzwerk zu binden:
#systemctl restart ceph-*@osd.*.serviceÜberprüfen Sie, ob das private Cluster-Netzwerk auf Betriebssystemebene wie erwartet funktioniert.
2.1.1.2 Überwachungsknoten in verschiedenen Teilnetzen #
Wenn sich die Überwachungsknoten in mehreren Teilnetzen befinden, beispielsweise in verschiedenen Räumen und gesteuert durch verschiedene Schalter, dann müssen Sie ihre öffentliche Netzwerkadresse in der CIDR-Schreibweise entsprechend anpassen:
cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_NBeispiel:
cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
Wenn Sie, wie in diesem Abschnitt beschrieben, mehr als ein Netzwerksegment für das öffentliche Netzwerk (oder für das Clusternetzwerk) angeben, muss jedes dieser Teilnetze zur Weiterleitung zu den anderen Teilnetzen in der Lage sein. Andernfalls können die MONs und andere Ceph-Daemons auf verschiedenen Netzwerksegmenten nicht miteinander kommunizieren, was zu einem geteilten Cluster führen würde. Wenn Sie eine Firewall verwenden, stellen Sie außerdem sicher, dass Sie jede IP-Adresse oder jedes Teilnetz in Ihre iptables einbeziehen und Ports für sie auf allen Knoten öffnen, falls erforderlich.
2.2 Konfigurationen mit mehreren Architekturen #
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.
In der gesamten Dokumentation wird SYSTEM-ARCH anstelle von x86 oder Arm verwendet.
2.3 Hardwarekonfiguration #
Für eine optimale Produkterfahrung empfehlen wir, mit der empfohlenen Cluster-Konfiguration zu beginnen. Für einen Testcluster oder einen Cluster mit geringeren Leistungsanforderungen dokumentieren wir eine minimal unterstützte Cluster-Konfiguration.
2.3.1 Mindestkonfiguration für den Cluster #
Eine Mindestkonfiguration für den Produktcluster besteht aus:
Mindestens vier physikalischen Knoten (OSD-Knoten) mit gemeinsamem Speicherort der Services
Dual-10-Gbit-Ethernet als verbundenes Netzwerk
Einem separaten Admin-Knoten (kann auf einem externen Knoten virtualisiert werden)
Eine detaillierte Konfiguration besteht aus folgenden Komponenten:
Separater Verwaltungsknoten mit 4 GB RAM, vier Cores, 1 TB Kapazität. Dies ist in der Regel der Salt-Master-Knoten. Ceph-Services und -Gateways wie Ceph Monitor, Metadata Server, Ceph OSD, Object Gateway oder NFS Ganesha werden auf dem Admin-Knoten nicht unterstützt, da er die Clusteraktualisierungs- und Upgrade-Prozesse eigenständig orchestrieren muss.
Mindestens vier physische OSD-Knoten mit jeweils acht OSD-Datenträgern. Die Anforderungen finden Sie in Abschnitt 2.4.1, „Mindestanforderungen“.
Die Gesamtkapazität des Clusters sollte so bemessen sein, dass auch bei Ausfall eines Knotens die gesamte genutzte Kapazität (einschließlich Redundanz) 80 % nicht überschreitet.
Drei Ceph Monitor-Instanzen. Monitore müssen aus Latenzgründen von SSD/NVMe-Speicher, nicht von HDDs, betrieben werden.
Monitore, Metadatenserver und Gateways können gemeinsam auf den OSD-Knoten platziert werden. Informationen über die gemeinsame Platzierung finden Sie in Abschnitt 2.12, „Ein einziger Server für OSD und Monitor“. Wenn Sie Services gemeinsam platzieren, müssen die Speicher- und CPU-Anforderungen addiert werden.
iSCSI Gateway, Object Gateway und Metadata Server benötigen mindestens inkrementelle 4 GB RAM und vier Cores.
Wenn Sie CephFS, S3/Swift, iSCSI verwenden, sind für Redundanz und Verfügbarkeit mindestens zwei Instanzen der jeweiligen Rollen (Metadata Server, Object Gateway, iSCSI) erforderlich.
Die Knoten müssen für SUSE Enterprise Storage bestimmt sein und dürfen nicht für andere physische, containerisierte oder virtualisierte Workloads verwendet werden.
Wenn eines der Gateways (iSCSI, Object Gateway, NFS Ganesha, Metadata Server usw.) innerhalb von VMs bereitgestellt wird, dürfen diese VMs nicht auf den physischen Rechnern gehostet werden, die andere Clusterrollen bedienen. (Dies ist nicht notwendig, da sie als verbundene Services unterstützt werden.)
Bei der Bereitstellung von Services als VMs auf Hypervisoren außerhalb des physischen Core-Clusters müssen Ausfalldomänen beachtet werden, um Redundanz zu gewährleisten.
Stellen Sie zum Beispiel nicht mehrere Rollen desselben Typs auf demselben Hypervisor bereit, beispielsweise mehrere MON- oder MDS-Instanzen.
Bei der Bereitstellung innerhalb von VMs ist es besonders wichtig, dass die Knoten über eine starke Netzwerkanbindung und eine gut funktionierende Zeitsynchronisierung verfügen.
Die Hypervisorknoten müssen ausreichend dimensioniert sein, um Störungen durch andere Workloads zu vermeiden, die CPU-, RAM-, Netzwerk- und Speicherressourcen verbrauchen.
2.3.2 Empfohlene Konfiguration für Produktionscluster #
Sobald Sie Ihren Cluster vergrößern, empfehlen wir, Ceph Monitors, Metadatenserver und Gateways auf separate Knoten zu verlagern, um eine bessere Fehlertoleranz zu erreichen.
Sieben Objektspeicher-Knoten
Die einzelnen Knoten dürfen nicht mehr als ca. 15 % des Gesamtspeichers ausmachen.
Die Gesamtkapazität des Clusters sollte so bemessen sein, dass auch bei Ausfall eines Knotens die gesamte genutzte Kapazität (einschließlich Redundanz) 80 % nicht überschreitet.
25 Gb Ethernet oder besser, jeweils verbunden für internes Clusternetzwerk und externes öffentliches Netzwerk.
Mindestens 56 OSDs pro Speicher-Cluster.
In Abschnitt 2.4.1, „Mindestanforderungen“ finden Sie weitere Empfehlungen.
Dedizierte physische Infrastruktur-Knoten.
Drei Ceph-Monitor-Knoten: 4 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Festplatte.
In Abschnitt 2.5, „Monitorknoten“ finden Sie weitere Empfehlungen.
Object Gateway Knoten: 32 GB RAM, 8-Core-Prozessor, RAID 1-SSDs als Festplatte.
In Abschnitt 2.6, „Object-Gateway-Knoten“ finden Sie weitere Empfehlungen.
iSCSI Gateway Knoten: 16 GB RAM, 8-Core-Prozessor, RAID 1-SSDs als Festplatte.
In Abschnitt 2.9, „iSCSI-Gateway-Knoten“ finden Sie weitere Empfehlungen.
Metadata Server Knoten (einer aktiv, einer unmittelbar betriebsbereit im Standby-Modus): 32 GB RAM, 8-Core-Prozessor, RAID 1-SSDs als Festplatte.
In Abschnitt 2.7, „Metadata Server-Knoten“ finden Sie weitere Empfehlungen.
Ein SES-Admin-Knoten: 4 GB RAM, 4-Core-Prozessor, RAID 1-SSDs als Datenträger.
2.3.3 Multipfadkonfiguration #
Wenn Sie Multipfadhardware verwenden möchten, stellen Sie sicher, dass LVM in der Konfigurationsdatei unter dem Abschnitt Geräte die Einstellung multipath_component_detection = 1 sieht. Dies wird mit dem Kommando lvm config geprüft.
Stellen Sie alternativ sicher, dass LVM die Multipfadkomponenten eines Geräts über die LVM-Filterkonfiguration filtert. Das ist hostspezifisch zu verstehen.
Es wird nicht empfohlen und sollte immer nur dann in Betracht gezogen werden, wenn multipath_component_detection = 1 nicht festgelegt werden kann.
Weitere Informationen zur Multipfadkonfiguration finden Sie unter https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.
2.4 Objektspeicherknoten #
2.4.1 Mindestanforderungen #
Die folgenden CPU-Empfehlungen berücksichtigen Geräte unabhängig von der Nutzung durch Ceph:
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 intern), erforderlich 4 × 10 GbE, empfohlen 2 × 25 GbE.
Insgesamt benötigtes RAM = Anzahl der OSDs × (1 GB +
osd_memory_target) + 16 GBWeitere Informationen zu
osd_memory_targetfinden Sie in Abschnitt 28.4.1, „Konfigurieren der automatischen 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.
Dedizierter Datenträger und SSD für das Betriebssystem, vorzugsweise in einer RAID 1-Konfiguration.
Weisen Sie mindestens 4 GB zusätzlichen Arbeitsspeicher zu, wenn dieser OSD-Host einen Teil eines Cache-Pools hostet, der für Cache-Tiering verwendet wird.
Ceph Monitors, Gateway und Metadata Server dürfen in Objektspeicher-Knoten vorhanden sein.
Aus Gründen der Festplattenleistung handelt es sich bei OSD-Knoten um Bare-Metal-Knoten. Auf einem OSD-Knoten sollten keine anderen Workloads ausgeführt werden, es sei denn, es handelt sich um eine Mindesteinrichtung von Ceph Monitors und Ceph Managers.
SSDs für Journal im Verhältnis 6:1 von SSD-Journal zu OSD.
Stellen Sie sicher, dass den OSD-Knoten keine vernetzten Blockgeräte zugeordnet sind, wie zum Beispiel iSCSI- oder RADOS-Blockgeräte-Images.
2.4.2 Mindestgröße für Datenträger #
Zwei Arten von Datenträgerspeicherplatz werden zur Ausführung auf OSD benötigt: der Speicherplatz für das WAL/DB-Gerät sowie der primäre Speicherplatz für die gespeicherten Daten. Der Mindestwert (und Standardwert) für das 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.4.3 Empfohlene Größe für das WAL- und DB-Gerät von BlueStore #
Weitere Informationen zu BlueStore finden Sie in Abschnitt 1.4, „BlueStore“.
Es wird empfohlen, 4 GB für das WAL-Gerät zu reservieren. Während die DB-Mindestgröße 64 GB für reine RBD-Workloads beträgt, wird für Object Gateway- und CephFS-Workloads eine DB-Größe empfohlen, die 2 % der Kapazität des Hauptgeräts (mindestens jedoch 196 GB) entspricht.
WichtigWir empfehlen größere DB-Volumes für Bereitstellungen mit hoher Auslastung, insbesondere bei hoher RGW- oder CephFS-Nutzung. Reservieren Sie etwas Kapazität (Slots), um bei Bedarf mehr Hardware für mehr DB-Speicherplatz zu installieren.
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 im Abschnitt 13.4.3, „Hinzufügen von OSDs mit der DriveGroups-Spezifikation“.
2.4.4 SSD für WAL/DB-Partitionen #
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 WAL/ DB auf einem SSD speichern und die Objektdaten auf einer separaten Festplatte.
Da WAL/DB-Partitionen relativ wenig Speicherplatz belegen, können Sie einen SSD-Datenträger mit mehreren WAL/DB-Partitionen freigeben. Bedenken Sie dabei jedoch, dass sich mit jeder WAL/DB-Partition die Leistung des SSD-Datenträgers verschlechtert. Wir empfehlen, maximal sechs WAL/DB-Partitionen pro SSD-Datenträger zu speichern und zwölf pro NVMe-Datenträger.
2.4.5 Maximale empfohlene Anzahl von Datenträgern #
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_targeterhä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 Knoten im Cluster kopieren, damit die Reproduktionsregeln weiterhin ausgeführt werden.
2.5 Monitorknoten #
Mindestens drei MON-Knoten sind erforderlich. Die Anzahl der Monitore 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/cephin jedem Monitor-Knoten, 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 Knoten darf nur ein Überwachungsprozess vorhanden sein.
Die Kombination von OSD-, MON- oder Object-Gateway-Knoten 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.6 Object-Gateway-Knoten #
Object-Gateway-Knoten sollten über mindestens sechs CPU-Cores und 32 GB RAM verfügen. Wenn sich noch andere Prozesse auf demselben Rechner befinden, müssen deren Anforderungen aufsummiert werden.
2.7 Metadata Server-Knoten #
Die richtige Größe der Metadata Server Knoten 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
4 GB RAM für jeden Metadatenserver-Daemon.
Gebundene Netzwerkschnittstelle.
2,5 GHz CPU mit mindestens 2 Cores.
2.8 Admin-Knoten #
Mindestens 4 GB RAM und ein CPU mit vier Cores sind erforderlich. Dies umfasst die Ausführung des Salt Masters auf dem Admin-Knoten Für große Cluster mit Hunderten von Knoten werden 6 GB RAM vorgeschlagen.
2.9 iSCSI-Gateway-Knoten #
iSCSI-Gateway-Knoten sollten über mindestens sechs CPU-Cores und 16 GB RAM verfügen.
2.10 SES und andere SUSE-Produkte #
Dieser Abschnitt enthält wichtige Informationen zur Integration von SES in andere SUSE-Produkte.
2.10.1 SUSE Manager #
SUSE Manager und SUSE Enterprise Storage sind nicht integriert. Daher kann SUSE Manager aktuell keinen SES-Cluster verwalten.
2.11 Namensbegrenzungen #
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.12 Ein einziger Server für OSD und Monitor #
Obwohl es technisch möglich ist, OSDs und MONs in Testumgebungen auf demselben Server auszuführen, empfehlen wir dringend, einen separaten Server für jeden Monitorknoten in der Produktionsumgebung einzurichten. Der hauptsächliche Grund dafür besteht in der Leistung. Je mehr OSDs der Cluster enthält, desto mehr E/A-Vorgänge müssen die MON-Knoten durchführen. Wenn ein Server von einem MON-Knoten und OSD(s) gemeinsam genutzt wird, stellen die E/A-Vorgänge des OSD eine Beschränkung für den Monitorknoten dar.
Es ist weiterhin zu überlegen, ob Festplatten von einem OSD, einem MON-Knoten 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-Knoten.
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.
Wenn es wirklich erforderlich ist, OSD- und MON-Knoten auf demselben Server auszuführen, führen Sie MON auf einem separaten Datenträger aus. Hängen Sie dazu den Datenträger im Verzeichnis /var/lib/ceph/mon ein, um die Leistung etwas zu verbessern.