ntpd
zu chronyd
policy.cfg
und Deploy Ceph Dashboard mit DeepSeaIn diesem Kapitel finden Sie die Schritte zum Aufrüsten von SUSE Enterprise Storage 5.5 auf Version 6. Version 5.5 entspricht im Grunde der Version 5, auf die alle aktuellen Patches angewendet wurden.
Das Upgrade von SUSE Enterprise Storage-Versionen vor 5.5 wird nicht unterstützt. Sie müssen zunächst auf die aktuelle Version von SUSE Enterprise Storage 5.5 aufrüsten und dann die Schritte in diesem Kapitel ausführen.
In den Versionshinweisen finden Sie zusätzliche Informationen zu den Änderungen, die seit der vorigen Version von SUSE Enterprise Storage vorgenommen wurden. Informieren Sie sich in den Versionshinweisen über Folgendes:
Sind bei der Hardware besondere Überlegungen zu beachten?
Wurden erhebliche Änderungen an den verwendeten Software-Paketen vorgenommen?
Gelten besondere Vorsichtsmaßnahmen für die vorliegende Installation?
In den Versionshinweisen finden Sie auch Informationen, die erst nach der Fertigstellung des Handbuchs bekannt wurden. Auch bekannte Probleme werden beschrieben.
Nach Installation des Pakets release-notes-sesfinden Sie die Versionshinweise lokal im Verzeichnis /usr/share/doc/release-notes
oder online unter https://www.suse.com/releasenotes/.
Falls Sie zuvor Version 4 aufgerüstet haben, prüfen Sie, ob das Upgrade auf Version 5 erfolgreich abgeschlossen wurde:
Prüfen Sie, ob folgende Datei vorhanden ist:
/srv/salt/ceph/configuration/files/ceph.conf.import
Die Datei wird beim Importprozess während des Upgrades von SES 4 auf 5 erstellt. Außerdem wird die Option configuration_init: default-import
in folgender Datei festgelegt:
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Wenn configuration_init
noch auf default-import
eingestellt ist, greift der Cluster auf ceph.conf.import
als Konfigurationsdatei zurück, nicht auf die Standarddatei ceph.conf
von DeepSea, die aus Dateien in folgendem Verzeichnis kompiliert wird:
/srv/salt/ceph/configuration/files/ceph.conf.d/
Sie müssen daher ceph.conf.import
auf benutzerdefinierte Konfigurationen prüfen und diese Konfigurationen ggf. in eine der Dateien in folgendem Verzeichnis verschieben:
/srv/salt/ceph/configuration/files/ceph.conf.d/
Entfernen Sie anschließend die Zeile configuration_init: default-import
aus
/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml
Wenn Sie nicht die Konfiguration aus ceph.conf.import
zusammenführen und die Option configuration_init: default-import
entfernen, werden alle standardmäßigen Konfigurationseinstellungen von DeepSea (in /srv/salt/ceph/configuration/files/ceph.conf.j2
gespeichert) nicht auf den Cluster angewendet.
Prüfen Sie, ob der Cluster den neuen Bucket-Typ „straw2“ nutzt:
cephadm@adm >
ceph osd crush dump | grep straw
Prüfen Sie, ob das Ceph Profil „jewel“ verwendet wird:
cephadm@adm >
ceph osd crush dump | grep profile
Werden ältere RBD-Kernel-Clients (vor SUSE Linux Enterprise Server 12 SP3) verwendet, beachten Sie Abschnitt 12.9, „RBD-Zuordnung mit älteren Kernel-Clients“. Es wird empfohlen, ältere RBD-Kernel-Clients nach Möglichkeit aufzurüsten.
Wenn sich openATTIC auf dem Admin Node befindet, ist es nach dem Aufrüsten des Knotens nicht mehr verfügbar. Das neue Ceph Dashboard ist dann verfügbar, wenn Sie es mit DeepSea implementiert haben.
Das Cluster-Upgrade kann lange dauern, nämlich in etwa so lange, wie es dauert, ein Upgrade eines Computers multipliziert mit der Anzahl der Cluster Nodes durchzuführen.
Ein einzelner Knoten kann nicht aufgerüstet werden, wenn darauf noch die vorherige SUSE Linux Enterprise Server-Version ausgeführt wird, sondern muss mit dem Installationsprogramm der neuen Version neu gestartet werden. Die Services, die dieser Knoten anbietet, stehen daher eine gewisse Zeit lang nicht zur Verfügung. Die wesentlichen Cluster-Services sind weiterhin verfügbar – ist beispielsweise ein MON während des Upgrades inaktiv, gibt es dennoch mindestens zwei aktive MONs. Services, für die nur eine einzelne Instanz vorliegt, z. B. ein einzelnes iSCSI-Gateway, stehen leider nicht zur Verfügung.
Bestimmte Arten von Daemons hängen von anderen ab. Beispielsweise hängen Object Gateways von Ceph MON und Ceph OSD Daemons ab. Wir empfehlen für das Upgrade die folgende Reihenfolge:
Admin Node
Ceph Monitors/Ceph Managers
Metadata Server
Ceph OSDs
Object Gateways
iSCSI Gateways
NFS Ganesha
Samba Gateways
Wenn Sie AppArmor im Modus „complain“ oder „enforce“ ausgeführt hatten, müssen Sie vor dem Upgrade eine Salt-Pillar-Variable festlegen. SUSE Linux Enterprise Server 15 SP1 umfasst standardmäßig AppArmor, weshalb die AppArmor-Verwaltung in die DeepSea-Phase 0 integriert wurde. Laut dem Standardverhalten in SUSE Enterprise Storage 6 werden AppArmor und die zugehörigen Profile entfernt. Soll das in SUSE Enterprise Storage 5.5 konfigurierte Verhalten beibehalten werden, prüfen Sie, ob die Datei /srv/pillar/ceph/stack/global.yml
eine der folgenden Zeilen enthält, bevor Sie das Upgrade starten:
apparmor_init: default-enforce
oder
apparmor_init: default-complain
Ab SUSE Enterprise Storage 6 sind MDS-Namen, die mit einer Ziffer beginnen, nicht mehr zulässig und MDS-Daemons werden nicht gestartet. Sie können prüfen, ob Ihre Daemons solche Namen aufweisen. Führen Sie hierzu entweder das Kommando ceph fs status
aus oder starten Sie einen MDS neu und prüfen Sie, ob dessen Protokolle die folgende Meldung enthalten:
deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in a future version. MDS names may not start with a numeric digit.
Wird die obige Meldung angezeigt, müssen die MDS-Namen migriert werden, bevor Sie auf SUSE Enterprise Storage 6 aufrüsten können. DeepSea umfasst eine Orchestrierung, mit der diese Migration automatisiert wird. Den MDS-Namen, die mit einer Ziffer beginnen, wird „mds“ vorangestellt.:
root@master #
salt-run state.orch ceph.mds.migrate-numerical-names
Wenn bestimmte Konfigurationseinstellungen an MDS-Namen gebunden sind und die Namen Ihrer MDS-Daemons mit einer Ziffer beginnen, prüfen Sie, ob Ihre Konfigurationseinstellungen auch für die neuen Namen angewendet werden (mit dem Präfix „mds“). Betrachten Sie den folgenden Beispielabschnitt in der Datei /etc/ceph/ceph.conf
:
[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digit mds cache memory limit = 1073741824 mds standby for name = 456-another-mds
Der Orchestrator ceph.mds.migrate-numerical-names
ersetzt den MDS-Daemon-Namen „123-my-mds“ durch „mds.123-my-mds“. Sie müssen die Konfiguration gemäß dem neuen Namen anpassen:
[mds.mds,123-my-mds] # config setting specific to MDS name with the new name mds cache memory limit = 1073741824 mds standby for name = mds.456-another-mds
Damit werden MDS-Daemons mit den neuen Namen eingefügt, bevor die bisherigen MDS-Daemons entfernt werden. Die Anzahl der MDS-Daemons verdoppelt sich für kurze Zeit. Die Clients können erst nach einer kurzen Pause für das Failover auf CephFS zugreifen. Planen Sie die Migration daher für einen Zeitraum, in dem Sie nur eine geringe oder gar keine CephFS-Auslastung erwarten.
Die Sicherung der Konfiguration und Daten eines Clusters ist nicht obligatorisch. Es wird jedoch dringend empfohlen, wichtige Konfigurationsdateien und Clusterdaten zu sichern. Weitere Informationen finden Sie in Kapitel 3, Sichern der Cluster-Konfiguration und -Daten.
ntpd
zu chronyd
#
SUSE Linux Enterprise Server 15 SP1 synchronisiert die Uhrzeit des lokalen Hosts nicht mehr über ntpd
. Stattdessen wird chronyd
verwendet. Sie müssen den Zeitsynchronisierungs-Daemon auf jedem Cluster Node migrieren. Sie können wahlweise vor dem Cluster-Upgrade zu chronyd
migrieren oder zunächst den Cluster aufrüsten und die Migration zu chronyd
danach durchführen.
chronyd
vor dem Cluster-Upgrade #Installieren Sie das Paket chrony :
root@minion >
zypper install chrony
Bearbeiten Sie die chronyd
-Konfigurationsdatei /etc/chrony.conf
und fügen Sie NTP-Quellen aus der aktuellen ntpd
-Konfiguration in /etc/ntp.conf
ein.
chronyd
-Konfiguration
In https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html finden Sie weitere Anweisungen, wie Sie Zeitquellen in die chronyd
-Konfiguration einfügen.
Deaktivieren und stoppen Sie den ntpd
-Service:
root@minion >
systemctl disable ntpd.service && systemctl stop ntpd.service
Starten und aktivieren Sie den chronyd
-Service:
root@minion >
systemctl start chronyd.service && systemctl enable chronyd.service
Überprüfen Sie den Status von „chrony“:
root@minion >
chronyc tracking
chronyd
nach dem Cluster-Upgrade #Fügen Sie während des Cluster-Upgrades die folgenden Software-Repositorys ein:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
Rüsten Sie den Cluster auf Version 6 auf.
Bearbeiten Sie die chronyd
-Konfigurationsdatei /etc/chrony.conf
und fügen Sie NTP-Quellen aus der aktuellen ntpd
-Konfiguration in /etc/ntp.conf
ein.
chronyd
-Konfiguration
In https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-ntp.html finden Sie weitere Anweisungen, wie Sie Zeitquellen in die chronyd
-Konfiguration einfügen.
Deaktivieren und stoppen Sie den ntpd
-Service:
root@minion >
systemctl disable ntpd.service && systemctl stop ntpd.service
Starten und aktivieren Sie den chronyd
-Service:
root@minion >
systemctl start chronyd.service && systemctl enable chronyd.service
Migrieren Sie von ntpd
zu chronyd
.
Überprüfen Sie den Status von „chrony“:
root@minion >
chronyc tracking
Entfernen Sie die eingefügten Legacy-Software-Repositorys, mit denen ntpd
während des Upgrade-Prozesses im System beibehalten wurde.
Wenden Sie die aktuellen Patches vor dem Upgrade auf alle Cluster Nodes an.
Prüfen Sie, ob die erforderlichen Repositorys auf den einzelnen Knoten konfiguriert sind. Mit folgendem Kommando rufen Sie eine Liste aller verfügbaren Repositorys ab:
root@minion >
zypper lr
Für SUSE Enterprise Storage 5.5 erforderlich:
SLES12-SP3-Installer-Updates
SLES12-SP3-Pool
SLES12-SP3-Updates
SUSE-Enterprise-Storage-5-Pool
SUSE-Enterprise-Storage-5-Updates
Für NFS/SMB Gateway auf SLE-HA unter SUSE Linux Enterprise Server 12 SP3 erforderlich:
SLE-HA12-SP3-Pool
SLE-HA12-SP3-Updates
Wenn Sie mit einem Repository-Staging-System arbeiten (SMT, RMT oder SUSE Manager), erstellen Sie eine neue, eingefrorene Patchstufe für die aktuelle und die neue SUSE Enterprise Storage-Version.
Weitere Informationen finden Sie in:
Wenden Sie die aktuellen Patches für SUSE Enterprise Storage 5.5 und SUSE Linux Enterprise Server 12 SP3 auf jeden Ceph Cluster Node an. Prüfen Sie, ob die richtigen Software-Repositorys mit den einzelnen Cluster Nodes verbunden sind (siehe Abschnitt 6.4.1, „Erforderliche Software-Repositorys“) und führen Sie die DeepSea-Phase 0 aus:
root@master #
salt-run state.orch ceph.stage.0
Prüfen Sie nach Abschluss der Phase 0, ob der Status der einzelnen Cluster „HEALTH_OK“ umfasst. Falls nicht, beheben Sie das Problem, bevor Sie etwaige Neustarts in nachfolgenden Schritten vornehmen.
Prüfen Sie mit zypper ps
, ob Prozesse vorliegen, die mit veralteten Bibliotheken oder Binärdateien ausgeführt werden, und starten Sie die betreffenden Prozesse neu.
Prüfen Sie, ob der ausgeführte Kernel die aktuell verfügbare Version aufweist, und starten Sie ihn neu, wenn dies nicht der Fall ist. Prüfen Sie die Ausgabe der folgenden Kommandos:
cephadm@adm >
uname -acephadm@adm >
rpm -qa kernel-default
Prüfen Sie, ob das Paket ceph in Version 12.2.12 (oder höher) vorliegt. Prüfen Sie, ob das Paket deepsea in Version 0.8.9 (oder höher) vorliegt.
Wenn Sie bislang mit Einstellungen für bluestore_cache
gearbeitet haben, sind diese Einstellungen ab ceph
Version 12.2.10 nicht mehr in Kraft. Die neue Einstellung bluestore_cache_autotune
, die standardmäßig auf „true“ eingestellt ist, deaktiviert die manuelle Festlegung der Cache-Größe. Soll das bisherige Verhalten wieder aktiviert werden, legen Sie bluestore_cache_autotune=false
fest. Weitere Informationen finden Sie unter Abschnitt 16.2.1, „Automatische Festlegung der Cache-Größe“.
Wenn offensichtliche Probleme im System vorliegen, beheben Sie sie, bevor Sie das Upgrade starten. Allein durch das Upgrade werden bestehende Systemprobleme unter keinen Umständen behoben.
Prüfen Sie die Cluster-Leistung. Wählen Sie hierzu unter Kommandos wie rados bench
, ceph tell osd.* bench
oder iperf3
.
Prüfen Sie den Zugriff auf Gateways (z. B. iSCSI-Gateway oder Object Gateway) und auf RADOS Block Device.
Dokumentspezifische Teile der Systemeinrichtung, z. B. Details zur Netzwerkeinrichtung, Partitionierung oder Installation.
Stellen Sie wichtige Systeminformationen mit supportconfig
zusammen und speichern Sie sie außerhalb der Cluster Nodes. Weitere Informationen finden Sie in https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_admsupport_supportconfig.html.
Prüfen Sie, ob ausreichend freier Speicherplatz auf jedem Cluster Node bereitsteht. Prüfen Sie den freien Speicherplatz mit df -h
. Bei Bedarf geben Sie Speicherplatz frei: Entfernen Sie nicht mehr benötigte Dateien/Verzeichnisse oder veraltete OS-Snapshots. Falls der Speicherplatz nicht ausreicht, setzen Sie das Upgrade erst dann fort, wenn Sie genügend Speicherplatz freigegeben haben.
Führen Sie das Kommando cluster health
aus, bevor Sie den Upgrade-Vorgang starten. Starten Sie das Upgrade erst dann, wenn jeder Cluster Node „HEALTH_OK“ meldet.
Prüfen Sie, ob alle Services ausgeführt werden:
Salt Master und Salt Master Daemons.
Ceph Monitor und Ceph Manager Daemons.
Metadatenserver Daemons.
Ceph OSD Daemons.
Object Gateway-Daemons.
iSCSI-Gateway-Daemons.
Die folgenden Kommandos geben Details zum Cluster-Status und zur jeweiligen Konfiguration zurück:
ceph -s
Gibt eine kurze Zusammenfassung des Ceph Cluster-Zustands, der ausgeführten Services, der Datenauslastung und der E/A-Statistik zurück. Prüfen Sie, ob die Meldung „HEALTH_OK“ vorliegt, bevor Sie das Upgrade starten.
ceph health detail
Gibt Details zurück, wenn der Ceph Cluster-Zustand nicht in Ordnung ist.
ceph versions
Gibt die Versionen der ausgeführten Ceph Daemons zurück.
ceph df
Gibt den gesamten und den freien Speicherplatz auf dem Cluster zurück. Starten Sie das Upgrade nur dann, wenn der freie Speicherplatz im Cluster bei mindestens 25 % des gesamten Speicherplatzes liegt.
salt '*' cephprocesses.check results=true
Gibt die ausgeführten Ceph-Prozesse und ihre PIDs zurück, sortiert nach den Salt Minions.
ceph osd dump | grep ^flags
Prüfen Sie, ob die Flaggen „recovery_deletes“ und „purged_snapdirs“ vorhanden sind. Falls nicht, können Sie mit folgendem Kommando ein Scrubbing für alle Platzierungsgruppen erzwingen: Beachten Sie, dass dieses erzwungene Scrubbing die Leistung Ihrer Ceph Clients unter Umständen negativ beeinflusst.
cephadm@adm >
ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub
CTDB umfasst eine geclusterte Datenbank, die von Samba Gateways herangezogen wird. Das CTDB-Protokoll ist sehr einfach und unterstützt keine Cluster mit Knoten, die mit anderen Protokollversionen kommunizieren. CTDB-Knoten müssen daher vor einem Upgrade offline geschaltet werden.
Damit die wesentlichen Cluster-Services auch während des Upgrades verfügbar sind, müssen Sie die Cluster Nodes einzeln nacheinander aufrüsten. Für das Upgrade eines Knotens stehen zwei Möglichkeiten zur Auswahl: entweder mit der Installationsprogramm-DVD oder mit dem Distribution Migration System.
Nach dem Aufrüsten der einzelnen Knoten wird empfohlen, mit rpmconfigcheck
nach aktualisierten Konfigurationsdateien zu suchen, die lokal bearbeitet wurden. Wenn das Kommando eine Liste von Dateinamen mit dem Suffix .rpmnew
, .rpmorig
oder .rpmsave
zurückgibt, vergleichen Sie diese Dateien mit den aktuellen Konfigurationsdateien, damit gewährleistet ist, dass keine lokalen Änderungen verloren gehen. Aktualisieren Sie ggf. die betroffenen Dateien. Weitere Informationen zur Verwendung von .rpmnew
-, .rpmorig
- und .rpmsave
-Dateien finden Sie in https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-sw-cl.html#sec-rpm-packages-manage.
Nach dem Aufrüsten eines Knotens sind einige Pakete „bezuglos“, besitzen also kein übergeordnetes Repository mehr. Dieser Fall tritt ein, da python2-Pakete nicht automatisch veraltet sind, wenn python3-spezifische Pakete vorliegen.
Weitere Informationen zum Abrufen bezugloser Pakete finden Sie in https://www.suse.com/documentation/sles-15/book_sle_admin/data/sec_zypper.html#sec_zypper_softup_orphaned.
Starten Sie den Knoten von der Installationsprogramm-DVD/dem Image mit Linux Enterprise Server 15 SP1 neu.
Wählen Sie im Boot-Menü die Option
.Prüfen Sie im Bildschirm
(Migrationsziel auswählen), ob „SUSE Linux Enterprise Server 15 SP1“ ausgewählt ist, und aktivieren Sie das Kontrollkästchen (Repositorys für Migration manuell anpassen).Wählen Sie die folgenden Module zur Installation aus:
SUSE Enterprise Storage 6 x86_64
Basesystem Module 15 SP1 x86_64
Desktop Applications Module 15 SP1 x86_64
Legacy Module 15 SP1 x86_64
Server Applications Module 15 SP1 x86_64
Prüfen Sie im Bildschirm
(Bisher verwendete Repositorys), ob die richtigen Repositorys ausgewählt sind. Falls das System nicht bei SCC/SMT registriert ist, müssen Sie die Repositorys manuell einfügen.Für SUSE Enterprise Storage 6 erforderlich:
SLE-Module-Basesystem15-SP1-Pool
SLE-Module-Basesystem15-SP1-Updates
SLE-Module-Server-Applications15-SP1-Pool
SLE-Module-Server-Applications15-SP1-Updates
SLE-Module-Desktop-Applications15-SP1-Pool
SLE-Module-Desktop-Applications15-SP1-Updates
SLE-Product-SLES15-SP1-Pool
SLE-Product-SLES15-SP1-Updates
SLE15-SP1-Installer-Updates
SUSE-Enterprise-Storage-6-Pool
SUSE-Enterprise-Storage-6-Updates
Wenn ntpd
nach der SES-Migration zu chronyd
migriert werden soll (siehe Abschnitt 6.3, „Migration von ntpd
zu chronyd
“), fügen Sie die folgenden Repositorys ein:
SLE-Module-Legacy15-SP1-Pool
SLE-Module-Legacy15-SP1-Updates
Für NFS/SMB Gateway auf SLE-HA unter SUSE Linux Enterprise Server 15 SP1 erforderlich:
SLE-Product-HA15-SP1-Pool
SLE-Product-HA15-SP1-Updates
Prüfen Sie die
(Installationseinstellungen) und starten Sie den Installationsvorgang mit (Aktualisieren).Das Distribution Migration System (DMS) bietet einen Pfad für das Upgrade eines installierten SUSE Linux Enterprise-Systems von einer Hauptversion auf eine andere Hauptversion. Im nachfolgenden Verfahren wird SUSE Enterprise Storage 5.5 mit DMS auf Version 6 aufgerüstet, wobei auch die zugrunde liegende Migration von SUSE Linux Enterprise Server 12 SP3 auf SUSE Linux Enterprise Server 15 SP1 durchgeführt wird.
Allgemeine und ausführliche Informationen zu DMS finden Sie in https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/.
Installieren Sie die RPM-Pakete für die Migration. Damit wird der GRUB-Bootloader so angepasst, dass das Upgrade beim nächsten Neustart automatisch ausgelöst wird. Installieren Sie das Paket SLES15-SES-Migration und suse-migration-sle15-activation :
root@minion >
zypper install SLES15-SES-Migration suse-migration-sle15-activation
Ist der aufzurüstende Knoten bei einem Repository-Staging-System wie SCC, SMT, RMT oder SUSE Manager registriert, erstellen Sie /etc/sle-migration-service.yml
mit folgendem Inhalt:
use_zypper_migration: true preserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
Ist der aufzurüstende Knoten nicht bei einem Repository-Staging-System wie SCC, SMT, RMT oder SUSE Manager registriert, nehmen Sie die folgenden Änderungen vor:
Erstellen Sie /etc/sle-migration-service.yml
mit folgendem Inhalt:
use_zypper_migration: false preserve: rules: - /etc/udev/rules.d/70-persistent-net.rules
Deaktivieren oder entfernen Sie die Repositorys für SLE 12 SP3 und SES 5 und fügen Sie die Repositorys für SLE 15 SP1 und SES 6 ein. Eine Liste der zugehörigen Repositorys finden Sie in Abschnitt 6.4.1, „Erforderliche Software-Repositorys“.
Führen Sie einen Neustart durch, sodass das Upgrade gestartet wird. Während des laufenden Upgrades können Sie sich vom Hostsystem aus über ssh
mit dem vorhandenen SSH-Schlüssel als Migrationsbenutzer anmelden (siehe https://documentation.suse.com/suse-distribution-migration-system/1.0/single-html/distribution-migration-system/). Wenn Sie bei SUSE Enterprise Storage den physischen Zugriff oder den direkten Konsolenzugriff auf den Computer besitzen, können Sie sich auch an der Systemkonsole als root
mit dem Passwort sesupgrade
anmelden. Der Knoten wird nach dem Upgrade automatisch neu gestartet.
Wenn das Upgrade fehlschlägt, prüfen Sie /var/log/distro_migration.log
. Beheben Sie das Problem, installieren Sie die RPM-Pakete für die Migration erneut und starten Sie den Knoten neu.
Die folgenden Kommandos sind weiterhin funktionsfähig, auch wenn auf den Salt Minions veraltete Versionen von Ceph und Salt ausgeführt werden: salt '*' test.ping
und ceph status
Nach dem Upgrade des Admin Node ist openATTIC nicht mehr installiert.
Wenn SMT auf dem Admin Node gehostet wurde, führen Sie dessen Migration zu RMT durch (siehe https://www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html).
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
Nach dem Upgrade des Admin Node können Sie mit dem Kommando salt-run upgrade.status
nützliche Informationen zu den Cluster Nodes abrufen. Mit diesem Kommando werden die Ceph- und OS-Versionen aller Knoten aufgelistet und Sie erhalten eine Empfehlung für die Reihenfolge, in der die Knoten aufgerüstet werden sollten, auf denen noch ältere Versionen ausgeführt werden.
root@master #
salt-run upgrade.status
The newest installed software versions are:
ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable)
os: SUSE Linux Enterprise Server 15 SP1
Nodes running these software versions:
admin.ceph (assigned roles: master)
mon2.ceph (assigned roles: admin, mon, mgr)
Nodes running older software versions must be upgraded in the following order:
1: mon1.ceph (assigned roles: admin, mon, mgr)
2: mon3.ceph (assigned roles: admin, mon, mgr)
3: data1.ceph (assigned roles: storage)
[...]
Wenn Ihr Cluster keine MDS-Rollen nutzt, rüsten Sie die MON/MGR Nodes einzeln nacheinander auf.
Wenn der Cluster MDS-Rollen nutzt und sich die MON/MGR- und MDS-Rollen auf demselben Rechner befinden, müssen Sie den MDS Cluster verkleinern und dann die auf demselben Rechner befindlichen Knoten aufrüsten. Weitere Informationen finden Sie in Abschnitt 6.11, „Upgrade von Metadatenservern“.
Wenn Ihr Cluster MDS-Rollen nutzt und diese Rollen auf dedizierten Servern ausgeführt werden, rüsten Sie alle MON/MGR Nodes einzeln nacheinander auf; verkleinern Sie dann den MDS Cluster und rüsten Sie ihn auf. Weitere Informationen finden Sie in Abschnitt 6.11, „Upgrade von Metadatenservern“.
Aufgrund einer Einschränkung im Ceph Monitor-Design gilt Folgendes: Sobald zwei MONs auf SUSE Enterprise Storage 6 aufgerüstet wurden und ein Quorum gebildet haben, wird der dritte MON (auf dem weiterhin SUSE Enterprise Storage 5.5 ausgeführt wird) nicht wieder in den MON-Cluster aufgenommen, wenn er neu gestartet wurde (z. B. nach dem Neustart eines Knotens). Wenn zwei MONs aufgerüstet wurden, sollten die restlichen MONs daher so rasch wie möglich ebenfalls aufrüstet werden.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
Sie müssen den Metadatenserver (MDS)-Cluster verkleinern. Aufgrund einer Inkompatibilität bestimmter Funktionen in den SUSE Enterprise Storage-Versionen 5.5 und 6 werden die älteren MDS-Daemons heruntergefahren, sobald ein einzelner MDS mit SES 6 in den Cluster eingefügt wird. Für die Dauer des Upgrades der MDS Nodes muss der MDS-Cluster daher auf einen einzelnen aktiven MDS (ohne Standbys) verkleinert werden. Sobald der zweite Knoten aufgerüstet wurde, können Sie den MDS-Cluster wieder erweitern.
Auf einem stark ausgelasteten MDS-Cluster müssen Sie die Auslastung ggf. vermindern (z. B. Clients anhalten), sodass ein einzelner MDS den gesamten Workload tragen kann.
Beachten Sie den aktuellen Wert der Option max_mds
:
cephadm@adm >
ceph fs get cephfs | grep max_mds
Verkleinern Sie den MDS-Cluster, wenn mehrere aktive MDS-Daemons vorliegen, also wenn max_mds
> 1 ist. Mit folgendem Kommando verkleinern Sie den MDS-Cluster:
cephadm@adm >
ceph fs set FS_NAME max_mds 1
FS_NAME bezeichnet hierbei den Namen der CephFS-Instanz (standardmäßig „cephfs“).
Ermitteln Sie den Knoten, auf dem einer der Standby-MDS-Daemons ausgeführt wird. Betrachten Sie die Ausgabe des Kommandos ceph fs status
und starten Sie das Upgrade des MDS-Clusters auf diesem Knoten.
cephadm@adm >
ceph fs status
cephfs - 2 clients
======
+------+--------+--------+---------------+-------+-------+
| Rank | State | MDS | Activity | dns | inos |
+------+--------+--------+---------------+-------+-------+
| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |
+------+--------+--------+---------------+-------+-------+
+-----------------+----------+-------+-------+
| Pool | type | used | avail |
+-----------------+----------+-------+-------+
| cephfs_metadata | metadata | 2688k | 96.8G |
| cephfs_data | data | 0 | 96.8G |
+-----------------+----------+-------+-------+
+-------------+
| Standby MDS |
+-------------+
| mon3-6 |
| mon2-6 |
+-------------+
In diesem Beispiel müssen Sie den Upgrade-Vorgang entweder auf dem Knoten „mon3-6“ oder auf dem Knoten „mon2-6“ starten.
Rüsten Sie den Knoten mit dem Standby-MDS-Daemon auf. Sobald der aufgerüstete MDS-Knoten startet, werden die veralteten MDS-Daemons automatisch heruntergefahren. Zu diesem Zeitpunkt kann der CephFS-Service für die Clients kurzzeitig ausfallen.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
Rüsten Sie die verbleibenden MDS-Knoten auf.
Setzen Sie max_mds
auf die gewünschte Konfiguration zurück:
cephadm@adm >
ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT
Führen Sie die folgenden Schritte auf jedem Speicher-Node aus:
Ermitteln Sie die OSD-Daemons, die auf einem bestimmten Knoten ausgeführt werden:
cephadm@osd >
ceph osd tree
Legen Sie die Flagge „noout“ für jeden OSD Daemon auf dem aufzurüstenden Knoten fest:
cephadm@osd >
ceph osd add-noout osd.OSD_ID
Beispiel:
cephadm@osd >
for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done
Prüfen Sie mit:
cephadm@osd >
ceph health detail | grep noout
oder
cephadm@osd >
ceph –s
cluster:
id: 44442296-033b-3275-a803-345337dc53da
health: HEALTH_WARN
6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set
Erstellen Sie /etc/ceph/osd/*.json
-Dateien für alle vorhandenen OSDs. Führen Sie hierzu das folgende Kommando auf dem aufzurüstenden Knoten aus:
cephadm@osd >
ceph-volume simple scan --force
Rüsten Sie den OSD Node auf. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
Aktivieren Sie alle im System aufgefundenen OSDs:
cephadm@osd >
;ceph-volume simple activate --all
Sollen die Datenpartitionen einzeln aktiviert werden, müssen Sie das entsprechende Kommando ceph-volume
für die jeweilige Partitionen ermitteln. Ersetzen Sie X1 durch den richtigen Buchstaben/die richtige Zahl der Partition:
cephadm@osd >
ceph-volume simple scan /dev/sdX1
Beispiel:
cephadm@osd >
ceph-volume simple scan /dev/vdb1
[...]
--> OSD 8 got scanned and metadata persisted to file:
/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json
--> To take over management of this scanned OSD, and disable ceph-disk
and udev, run:
--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
Die letzte Zeile der Ausgabe enthält das Kommando, mit dem Sie die Partition aktivieren:
cephadm@osd >
ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290
[...]
--> All ceph-disk systemd units have been disabled to prevent OSDs
getting triggered by UDEV events
[...]
Running command: /bin/systemctl start ceph-osd@8
--> Successfully activated OSD 8 with FSID
d7bd2685-5b92-4074-8161-30d146cd0290
Prüfen Sie, ob der OSD Node nach dem Neustart ordnungsgemäß gestartet wird.
Reagieren Sie auf die Meldung „Legacy BlueStore stats reporting detected on XX OSD(s)“ (Gemeldete Legacy-BlueStore-Statistik auf XX OSD(s) erkannt):
cephadm@osd >
ceph –s
cluster:
id: 44442296-033b-3275-a803-345337dc53da
health: HEALTH_WARN
Legacy BlueStore stats reporting detected on 6 OSD(s)
Diese Warnmeldung ist beim Upgrade von Ceph auf Version 14.2.2 normal. Mit folgender Einstellung können Sie sie deaktivieren:
bluestore_warn_on_legacy_statfs = false
Zur Problembehebung führen Sie das folgende Kommando auf allen OSDs aus, während sie gestoppt sind:
cephadm@osd >
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX
Das folgende Helper-Skript führt ceph-bluestore-tool repair
für alle OSDs auf dem Knoten NODE_NAME aus:
OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done
Heben Sie die Flagge „noout“ für jeden OSD Daemon auf dem aufzurüstenden Knoten auf:
cephadm@osd >
ceph osd rm-noout osd.OSD_ID
Beispiel:
cephadm@osd >
for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done
Prüfen Sie mit:
cephadm@osd >
ceph health detail | grep noout
Hinweis:
cephadm@osd >
ceph –s
cluster:
id: 44442296-033b-3275-a803-345337dc53da
health: HEALTH_WARN
Legacy BlueStore stats reporting detected on 6 OSD(s)
Prüfen Sie den Cluster-Status. Die Ausgabe ähnelt der folgenden:
cephadm@osd >
ceph status
cluster:
id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12
health: HEALTH_WARN
3 monitors have not enabled msgr2
services:
mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
mgr: mon2(active, since 22m), standbys: mon1, mon3
osd: 30 osds: 30 up, 30 in
data:
pools: 1 pools, 1024 pgs
objects: 0 objects, 0 B
usage: 31 GiB used, 566 GiB / 597 GiB avail
pgs: 1024 active+clean
Prüfen Sie, ob alle OSD Nodes neu gestartet und ob die OSDs nach dem Neustart automatisch gestartet wurden.
OSD BlueStore ist ein neues Back-End für die OSD Daemons. Ab SUSE Enterprise Storage 5 ist dies die Standardoption. Verglichen mit FileStore, das Objekte als Dateien in einem XFS-Dateisystem speichert, kann BlueStore eine höhere Leistung bereitstellen, weil es Objekte direkt auf dem zugrundeliegenden Blockgerät speichert. BlueStore ermöglicht außerdem weitere Funktionen, wie integrierte Komprimierung und EC-Überschreibungen, die bei FileStore nicht zur Verfügung stehen.
Für BlueStore spezifisch umfasst ein OSD ein „wal“ (Write Ahead-Protokoll)-Gerät und ein „db“ (RocksDB-Datenbank)-Gerät. Die RocksDB-Datenbank enthält die Metadaten für einen BlueStore OSD. Diese beiden Geräte befinden sich standardmäßig auf demselben Gerät wie ein OSD, doch jedes der beiden kann auf andere (z. B. schnellere) Medien platziert werden.
In SUSE Enterprise Storage 5 werden sowohl FileStore als auch BlueStore unterstützt und FileStore und BlueStore OSDs können gemeinsam in einem einzelnen Cluster vorhanden sein. Während des Upgrade-Vorgangs für SUSE Enterprise Storage werden FileStore OSDs nicht automatisch zu BlueStore konvertiert. Beachten Sie, dass die BlueStore-spezifischen Funktionen nicht auf OSDs verfügbar sind, die nicht zu BlueStore migriert wurden.
Vor der Konvertierung zu BlueStore müssen die OSDs SUSE Enterprise Storage 5 ausführen. Der Konvertierungsvorgang ist langsam, weil alle Daten zweimal umgeschrieben werden. Obwohl der Migrationsvorgang möglicherweise lange dauert, fällt der Cluster nicht aus und alle Clients können währenddessen weiterhin auf den Cluster zugreifen. Rechnen Sie für die Dauer der Migration jedoch mit einer geringeren Leistung. Der Grund dafür besteht in einem Ausgleich und Abgleich der Cluster-Daten.
Gehen Sie bei der Migration von FileStore OSDs zu BlueStore folgendermaßen vor:
Salt-Kommandos, die zur Ausführung der Migration erforderlich sind, werden durch Sicherheitsmaßnahmen blockiert. Führen Sie folgendes Kommando aus, um diese Vorsichtsmaßnahmen auszuschalten:
root@master #
salt-run disengage.safety
Bauen Sie die Knoten vor dem Fortsetzen des Vorgangs neu auf:
root@master #
salt-run rebuild.node TARGET
Sie können die Knoten auch einzeln neu aufbauen. Beispiel:
root@master #
salt-run rebuild.node data1.ceph
Mit rebuild.node
werden stets alle OSDs im Knoten entfernt und neu erstellt.
Wenn ein OSD nicht konvertiert werden kann, zerstört die erneute Ausführung des Aufbaus die bereits konvertierten BlueStore OSDs. Anstatt den Aufbau neu auszuführen, können Sie Folgendes ausführen:
root@master #
salt-run disks.deploy TARGET
Nach der Migration zu BlueStore bleibt die Anzahl der Objekte gleich und die Datenträgerauslastung ist nahezu dieselbe.
Rüsten Sie die Anwendungsknoten in der folgenden Reihenfolge auf:
Object Gateways
Wenn sich ein Lastausgleich vor Object Gateways befindet, sollte ein Upgrade der Object Gateways bei laufendem Betrieb ohne Ausfall möglich sein.
Prüfen Sie nach jedem Upgrade, ob die Object Gateway-Daemons ausgeführt werden, und testen Sie mit einem S3/Swift-Client.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
iSCSI Gateways
Wenn iSCSI Initiatoren mit Multipath konfiguriert sind, sollte ein Upgrade der iSCSI-Gateways bei laufendem Betrieb ohne Ausfall möglich sein.
Prüfen Sie nach jedem Upgrade, ob der lrbd
-Daemon ausgeführt wird, und testen Sie mit einem Initiator.
Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
NFS Ganesha. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
Samba Gateways. Befolgen Sie die Anweisungen in Abschnitt 6.8, „Upgrade Knoten für Knoten – Grundverfahren“.
policy.cfg
und Deploy Ceph Dashboard mit DeepSea #
Bearbeiten Sie /srv/pillar/ceph/proposals/policy.cfg
auf dem Admin Node und wenden Sie die folgenden Änderungen an:
Nehmen Sie während des Cluster-Upgrades keine neuen Services in die Datei policy.cfg
auf. Ändern Sie die Cluster-Architektur erst dann, wenn das Upgrade abgeschlossen ist.
Entfernen Sie role-openattic
.
Fügen Sie role-prometheus
und role-grafana
in den Knoten ein, auf dem Prometheus und Grafana installiert waren (in der Regel der Admin Node).
Die Rolle profile-PROFILE_NAME
wird nunmehr ignoriert. Fügen Sie die neue Rolle in der Zeile role-storage
ein. Für die vorhandene Rolle
profile-default/cluster/*.sls
fügen Sie beispielsweise Folgendes ein:
role-storage/cluster/*.sls
Synchronisieren Sie alle Salt-Module:
root@master #
salt '*' saltutil.sync_all
Aktualisieren Sie den Salt-Pillar mit DeepSea-Phase 1 und Phase 2:
root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2
Bereinigen Sie openATTIC:
root@master #
salt OA_MINION state.apply ceph.rescind.openatticroot@master #
salt OA_MINION state.apply ceph.remove.openattic
Heben Sie das Grain „restart_igw“ auf, sodass Phase 0 nicht das iSCSI-Gateway neu startet, das bislang noch nicht installiert wurde:
Salt mastersalt '*' grains.delkey restart_igw
Führen Sie abschließend die DeepSea-Phasen 0–4 aus:
root@master #
salt-run state.orch ceph.stage.0root@master #
salt-run state.orch ceph.stage.1root@master #
salt-run state.orch ceph.stage.2root@master #
salt-run state.orch ceph.stage.3root@master #
salt-run state.orch ceph.stage.4
Unter Umständen schlägt die DeepSea-Phase 3 mit diesem Fehler fehl:
subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \ '/var/lib/ceph subvolume missing on 4510-1', \ [...] 'See /srv/salt/ceph/subvolume/README.md']
In diesem Fall müssen Sie /srv/pillar/ceph/stack/global.yml
bearbeiten und die folgende Zeile einfügen:
subvolume_init: disabled
Aktualisieren Sie dann den Salt-Pillar und führen Sie die DeepSea-Phase 3 erneut aus:
root@master #
salt '*' saltutil.refresh_pillarroot@master #
salt-run state.orch ceph.stage.3
Sobald die DeepSea-Phase 3 erfolgreich beendet wurde, wird das Ceph Dashboard ausgeführt. Eine ausführliche Übersicht der Ceph Dashboard-Funktionen finden Sie in Kapitel 22, Ceph Dashboard.
Mit folgendem Kommando rufen Sie eine Liste der Knoten ab, auf denen das Dashboard ausgeführt wird:
cephadm@adm >
ceph mgr services | grep dashboard
Mit folgendem Kommando rufen Sie eine Liste der Admin-Berechtigungsnachweise ab:
root@master #
salt-call grains.get dashboard_creds
Starten Sie die Object Gateway-Services einzeln nacheinander, sodass sie den „beast“-Webserver anstelle des veralteten „civetweb“ nutzen:
root@master #
salt-run state.orch ceph.restart.rgw.force
Bevor Sie den Vorgang fortsetzen, wird dringend empfohlen, das Ceph-Telemetriemodul zu aktivieren. Weitere Informationen und Anweisungen finden Sie in Abschnitt 10.2, „Telemetriemodul“.
In SUSE Enterprise Storage 5.5 wurde das Layout Ihrer OSDs mit sogenannten „Profilen“ in DeepSea beschrieben. Mit SUSE Enterprise Storage 6 wurde auf eine andere Vorgehensweise umgestellt, auf die sogenannten DriveGroups (weitere Informationen siehe Abschnitt 5.5.2, „DriveGroups“).
Die Migration auf die neue Vorgehensweise ist nicht sofort obligatorisch. Destruktive Operationen wie salt-run osd.remove
, salt-run osd.replace
oder salt-run osd.purge
sind nach wie vor verfügbar. Sollen neue OSDs eingefügt werden, ist jedoch Ihre Mithilfe gefordert.
Angesichts der unterschiedlichen Vorgehensweise dieser Implementierungen bieten wir keinen automatisierten Migrationspfad an. Wir bieten jedoch verschiedene Werkzeuge (Salt-Ausführungsprogramme) an, die die Migration so weit wie möglich erleichtern sollen.
Mit folgendem Kommando rufen Sie Informationen zu den derzeit implementierten OSDs ab:
root@master #
salt-run disks.discover
Alternativ können Sie den Inhalt der Dateien in den Verzeichnissen /srv/pillar/ceph/proposals/profile-*/
prüfen. Ihre Struktur sieht in etwa wie folgt aus:
ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore
Weitere detaillierte Informationen zur DriveGroups-Spezifikation finden Sie in Abschnitt 5.5.2.1, „Spezifikation“.
Der Unterschied zwischen einer frischen Implementierung und einem Upgrade-Szenario liegt darin, dass die zu migrierenden Laufwerke bereits „genutzt“ werden. Da
root@master #
salt-run disks.list
nur nach nicht genutzten Datenträgern sucht, verwenden Sie
root@master #
salt-run disks.list include_unavailable=True
Passen Sie die DriveGroups gemäß Ihrer aktuellen Einrichtung an. Mit folgendem Kommando erhalten Sie eine eher bildliche Darstellung der Abläufe. Beachten Sie, dass dieses Kommando nichts zurückgibt, wenn keine freien Datenträger vorliegen:
root@master #
salt-run disks.report bypass_pillar=True
Wenn Sie die ordnungsgemäße Konfiguration Ihrer DriveGroups geprüft haben und nun die neue Vorgehensweise anwenden möchten, entfernen Sie die Dateien aus dem Verzeichnis /srv/pillar/ceph/proposals/profile-PROFILE_NAME/
, entfernen Sie die entsprechenden Zeilen für profile-PROFILE_NAME/cluster/*.sls
aus der Datei /srv/pillar/ceph/proposals/policy.cfg
und führen Sie die DeepSea-Phase 2 aus, sodass der Salt-Pillar aktualisiert wird.
root@master #
salt-run state.orch ceph.stage.2
Prüfen Sie das Ergebnis mit folgenden Kommandos:
root@master #
salt target_node pillar.get ceph:storageroot@master #
salt-run disks.report
Wenn Ihre DriveGroups nicht ordnungsgemäß konfiguriert sind und Ihre Einrichtung Ersatz-Datenträger umfasst, werden diese Datenträger so implementiert, wie Sie dies angegeben haben. Wir empfehlen, Folgendes auszuführen:
root@master #
salt-run disks.report
In einfachen Fällen wie Stand-Alone-OSDs erfolgt die Migration im Lauf der Zeit. Immer wenn Sie einen OSD im Cluster entfernen oder ersetzen, wird er durch einen neuen, LVM-basierten OSD ersetzt.
Immer wenn ein einzelner „Legacy“-OSD in einem Knoten ersetzt werden muss, müssen auch alle OSDs, die bestimmte Geräte gemeinsam mit diesem OSD nutzen, zum LVM-basierten Format migriert werden.
Aus Gründen der Vollständigkeit sollten Sie die OSDs im gesamten Knoten migrieren.
Bei einer differenzierteren Einrichtung, die über Stand-Alone-OSDs hinausgeht (z. B. dedizierte WAL/DBs oder verschlüsselte OSDs), kann die Migration nur dann durchgeführt werden, wenn alle dem betreffenden WAL/DB-Gerät zugeordneten OSDs entfernt wurden. Dies ergibt sich aus dem Kommando ceph-volume
, mit dem logische Volumes auf Datenträgern vor der Implementierung erstellt werden. So wird verhindert, dass der Benutzer partitionsbasierte Implementierungen mit LV-basierten Implementierungen vermischt. In diesen Fällen ist es am besten, alle einem WAL/DB-Gerät zugeordneten OSDs manuell zu entfernen und mit dem DriveGroups-Verfahren neu zu implementieren.