Best Practices

Stellen Sie sicher, dass Ihr Cluster Kubernetes v1.21 oder höher ausführt, bevor Sie SUSE Storage aktualisieren.

Wir empfehlen, Ihren Kubernetes-Cluster auf einer der folgenden Versionen auszuführen. Diese Versionen sind die aktiven unterstützten Versionen vor der SUSE Storage-Version und wurden mit SUSE Storage v1.11.2 getestet.

Verweist auf https://endoflife.date/kubernetes.

Stellen Sie sicher, dass CoreDNS mit mindestens zwei Replikaten läuft, um eine hohe Verfügbarkeit aufrechtzuerhalten. Dieses Setup minimiert Unterbrechungen bei der DNS-Auflösung, wenn ein CoreDNS-Pod eine vorübergehende Störung erfährt.

Es wird empfohlen, eine Festplatte für die Speicherung von SUSE Storage für die Produktion zu widmen, anstatt die Root-Festplatte zu verwenden.

Wenn Sie die Root-Festplatte verwenden müssen, verwenden Sie das Standard-Setup von minimal available storage percentage, das 25 % beträgt, und setzen Sie overprovisioning percentage auf 100 %, um die Wahrscheinlichkeit von DiskPressure zu minimieren.

Wenn Sie eine dedizierte Festplatte für SUSE Storage verwenden, können Sie die Einstellung minimal available storage percentage auf 10 % senken.

Der Überprovisionierungsprozentsatz hängt davon ab, wie viel Speicherplatz Ihr Volume im Durchschnitt nutzt. Wenn Ihre Arbeitslast beispielsweise nur die Hälfte der verfügbaren Volumengröße nutzt, können Sie den Überprovisionierungsprozentsatz auf 200 setzen, was bedeutet, dass SUSE Storage die Festplatte als doppelt so groß betrachtet, wie ihre volle Größe minus den reservierten Speicherplatz.

Da SUSE Storage derzeit keine Sharding zwischen den verschiedenen Festplatten unterstützt, empfehlen wir die Verwendung von LVM, um alle Festplatten für SUSE Storage in einer einzigen Partition zu aggregieren, damit sie in Zukunft leicht erweitert werden kann.

Alle zusätzlichen Festplatten müssen in der /etc/fstab-Datei eingetragen werden, um eine automatische Montage nach dem Neustart der Maschine zu ermöglichen.

Verwenden Sie keinen symbolischen Link für die zusätzlichen Festplatten. Verwenden Sie mount --bind anstelle von ln -s und stellen Sie sicher, dass es sich in der fstab-Datei befindet. Für Details siehe den Abschnitt über die Unterstützung mehrerer Festplatten.

Um ein anderes Verzeichnis als das Standardverzeichnis /var/lib/longhorn für die Speicherung zu verwenden, kann die Einstellung Default Data Path vor der Installation des Systems geändert werden. Für Details zur Änderung der Voreinstellungen vor der Installation siehe diesen Abschnitt.

Die Standard-Knoten-/Festplattenkonfiguration Funktion kann verwendet werden, um die Standardfestplatte nach der Installation anzupassen. Die Anpassung der Standardkonfigurationen für Festplatten und Knoten ist nützlich für die Skalierung des Clusters, da sie die Notwendigkeit beseitigt, SUSE Storage manuell für jeden neuen Knoten zu konfigurieren, wenn der Knoten mehr als eine Festplatte enthält oder wenn die Festplattenkonfiguration für neue Knoten unterschiedlich ist. Denken Sie daran, Create default disk only on labeled node zu aktivieren, falls zutreffend.

Wir empfehlen, die CPU-Anforderung für SUSE Storage Instanzmanager-Pods festzulegen.

Die Guaranteed Instance Manager CPU Einstellung ermöglicht es Ihnen, einen Prozentsatz der insgesamt zuweisbaren CPU-Ressourcen auf jedem Knoten für jeden Instanzmanager-Pod zu reservieren, wenn die V1 Daten-Engine aktiviert ist. Der Standardwert ist 12.

Legen Sie einen bestimmten Milli-CPU-Wert für die Instanzmanager-Pods auf einem bestimmten Knoten fest, indem Sie das Feld für die CPU-Anforderung des Instanzmanagers für diesen Knoten aktualisieren.

Verweisen Sie auf Garantierter Instanzmanager-CPU für weitere Details.

Die Guaranteed Instance Manager CPU for V2 Data Engine Einstellung ermöglicht es Ihnen, eine bestimmte Anzahl von Milli-CPUs auf jedem Knoten für jeden Instanzmanager-Pod zu reservieren, wenn die V2 Daten-Engine aktiviert ist. Standardmäßig verwendet der Storage Performance Development Kit (SPDK) Ziel-Daemon innerhalb jedes Instanz-Manager-Pods 1 CPU-Kernel. Die Konfiguration eines minimalen CPU-Nutzungswerts ist entscheidend für die Aufrechterhaltung der Stabilität von Engine und Replikaten, insbesondere während Zeiten hoher Knotenlast. Der Standardwert ist 1250.

Empfehlung: false

Diese Einstellung sollte in der Produktionsumgebung auf false gesetzt werden, um die beste Verfügbarkeit des Volumens sicherzustellen. Andernfalls kann ein Ausfallereignis eines Knotens mehr als ein Replikat eines Volumens zum Absturz bringen.

Empfehlung: false

Deaktivieren Sie diese Einstellung (false) in Produktionsumgebungen, um die maximale Verfügbarkeit des Volumens bei der Erstellung sicherzustellen. Wenn aktiviert (true), gelingt die Erstellung des Volumens, selbst wenn das System nur ein Replikat planen kann. Dies schafft ein Risiko, dass der Cluster ohne sofortige Benachrichtigung des Benutzers keinen Speicherplatz mehr hat.

Empfehlung: least-effort

Für Produktionsumgebungen empfehlen wir, die Replica Auto Balance auf least-effort einzustellen. Diese Einstellung stellt sicher, dass mindestens eine Replica auf einem anderen Knoten in jeder Zone platziert wird, was eine hohe Verfügbarkeit (HA) bietet.

In bestimmten Grenzfällen könnten Sie in Erwägung ziehen, die best-effort zu verwenden, die kontinuierlich versucht, die Replikate gleichmäßig über Knoten und Zonen zu verteilen. Diese Einstellung kann jedoch zu häufigen Wiederaufbauten führen, wenn der Cluster instabil ist.

Für die meisten Benutzer ist es ausreichend, mehrere Replikate ohne die Einstellung Replica Auto Balance zu haben, um eine grundlegende HA zu erreichen, insbesondere wenn Sie übermäßige Wiederaufbauten und Ressourcenverbrauch vermeiden möchten.