Konfigurieren mehrerer Datenträger

Warum werden weitere Datenträger für die GHES-Instanz eingeführt?

• Verbesserte Ressourcenverteilung:

  • Unterschiedliche Dienste weisen eindeutige Datenträgeranforderungen auf.
  • MySQL ist vor allem empfindlich gegenüber Latenz und IOPS.
  • Einige Ressourcen (z. B. Repositorys) profitieren nicht so viel von teurem Blockspeicher.

• Maximierte VM-Grenzwerte:

  • Ein einzelner Datenträger kann häufig die Einschränkungen einer Instanz nicht ausschöpfen.
  • Aus Kostenperspektive ist es in der Regel nicht machbar oder lohnenswert, alles auf den teuersten oder schnellsten Speicher auszuführen.

• Klarere Trennung zwischen Ressourcenzuordnung und Diensten:

  • Ressourcen können gezielt zugeordnet werden, um Ressourcenknappheit bei kritischen Diensten zu verhindern.

• Skalierung:

  • Kunden in eigenständigen und hochverfügbaren Topologien können bei Bedarf skalieren.

• Ausfallsicherheit:

  • Durch das Isolieren von Protokollen vom Stammdatenträger wird die Resilienz verbessert, indem verhindert wird, dass das Volume der Protokolle den Stammdatenträger überflutet.

Constraints

• Multidaten-Datenträger werden nur in eigenständigen und hochverfügbaren Topologien (High Availability, HA) unterstützt.

• Sobald mehrere Datenträger in einer Bereitstellung konfiguriert sind, kann diese Änderung für diese Bereitstellung nicht rückgängig gemacht werden.

• Das Einrichten von Datenträgern mit mehreren Daten und das Migrieren von Daten erfordert in der Regel einige Ausfallzeiten.

  • Sie können dies minimieren, indem Sie ein Replikat mit mehreren Datenlaufwerken konfigurieren, Daten vom Primärsystem replizieren und dann auf das Replikat umschalten.
  • Wenn Sie mehrere Datenträger direkt zum Primärsystem hinzufügen, sollten Sie mit einer deutlich längeren Ausfallzeit rechnen.

• Während der öffentlichen Vorschau sollten Datenträger mit mehreren Daten nur in Nichtproduktionsumgebungen verwendet werden.

• Es wird nicht empfohlen, MySQL,Repositorys, Systemprotokolle oder GitHub Protokolle auf denselben Datenträger zu migrieren. Jeder zusätzliche Datenträger sollte nur eine Migration enthalten.

• Derzeit können nur MySQL-, Repositorys- und Systemprotokolle und GitHub Protokolle zu zusätzlichen Datenträgern migriert werden.

• Ein Neustart des GitHub Enterprise Server-Knotens ist nach der Migration der Systemprotokolle erforderlich, um die Funktionsfähigkeit auf Systemebene sicherzustellen. Es wird einige Zeit in Anspruch nehmen, da die Konfiguration auch während des Startvorgangs des Knotens ausgeführt wird.

Ressourcenempfehlungen

Wenn Sie Datenträger hinzufügen, die so schnell oder schneller sind als Ihre aktuellen, sollten Sie eine verbesserte Leistung sehen. Speichergeräte werden in der Regel durch IOPS (Eingabe-/Ausgabevorgänge pro Sekunde), Durchsatz und Latenz gemessen. Für MySQL empfehlen wir die Verwendung eines Datenträgers mit geringerer Latenz und höherer IOPS als Der vorhandene Datenträger. Wählen Sie für Repositories einen Datenträger mit höherem iops und Durchsatz als der aktuelle Datenträger aus. Für Protokolle empfehlen wir die Verwendung eines Datenträgers mit höherem iops und Durchsatz als der vorhandene Datenträger, um fortlaufende Schreibvorgänge aus Protokollierungsaktivitäten zu verarbeiten.

Bei Setups mit hoher Verfügbarkeit empfiehlt es sich, Multidatenträger sowohl auf den primären als auch auf allen Replikaten zu verwenden. Das Mischen von Konfigurationen, bei denen der primäre Datenträger mehrere Daten aufweist, das Replikat jedoch nicht, wird nicht empfohlen.

Einrichten mehrerer Datenträger und Datenpfade

Voraussetzungen

• Es wird empfohlen, vor den ersten Schritten eine aktuelle Sicherung Ihrer Daten zu erstellen.
• Erstellen Sie eine Testumgebung, um das Feature zu testen.
  • Während der öffentlichen Vorschau empfehlen wir nur die Verwendung des Features in einer Testumgebung.
  • Sobald das Feature allgemein verfügbar ist, empfehlen wir, das Feature in einer Nicht-Produktionsumgebung zu testen, bevor es in der Produktion verwendet wird.

Anweisungen

1. Sie können eine Neuinstallation von GHES durchführen oder eine vorhandene GHES-Instanz verwenden. Der Datenträger sollte auf /data/user konfiguriert sein.

2. Fügen Sie der Instanz zusätzliche Blockspeichergeräte hinzu, nachdem die Einrichtung von /data/user abgeschlossen ist.

          `ghe-storage-find` Wählt derzeit den ersten Blockspeicher für die Einrichtung `/data/user` basierend auf der alphabetischen Reihenfolge des Blockspeicherpfads aus. Dies geschieht beim ersten Start der GHES-Appliance.
   

   Um mehr Kontrolle darüber zu haben, welcher Datenträger für /data/user verwendet wird, ist es besser, den Initialisierungsprozess mit nur einem zunächst angefügten Datenträger abzuschließen.

3. Initialisieren Sie das Setup mit mehreren Datenträgern mithilfe der neuen Blockspeichergeräte. Führen Sie zum Initialisieren der Unterstützung für mehrere Datenträger die Ausführung aus ghe-storage-multi-disk init. Bei jedem Neustart hängt ghe-multi-disk.service die vorhandenen Datenträger automatisch an den richtigen Pfaden neu ein.

   Shell

   /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme2n1 db
   

   Shell

   /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme3n1 git
   

   Shell

   /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme4n1 systemlogs
   

   Shell

   /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme5n1 githublogs
   

Bitte beachten Sie, dass /dev/nvme2n1, /dev/nvme3n1, /dev/nvme4n1 und /dev/nvme5n1 nur Beispielpfade sind. Möglicherweise stimmen sie nicht mit den Pfaden in Ihrem System überein. Ebenso sind db, git, systemlogs, und githublogs Beispiele. Sie können verschiedene Namen auswählen.

1. Wechseln Sie zum Wartungsmodus.

   Shell

   gh es maintenance set --enabled true
   

2. Migrieren Sie Die gewünschten Datenpfade.

   So migrieren Sie MySQL:

   Shell

   /usr/local/share/enterprise/ghe-storage-migrate-mysql db
   

   So migrieren Sie Repositorys:

   Shell

   /usr/local/share/enterprise/ghe-storage-migrate-repositories git
   

   So migrieren Sie Systemprotokolle:

   Shell

   /usr/local/share/enterprise/ghe-storage-migrate-logs systemlogs
   

   Starten Sie nach der Migration von Systemprotokollen die Instanz neu:

   Shell

   sudo reboot
   

   So migrieren Sie GitHub Protokolle:

   Shell

   /usr/local/share/enterprise/ghe-storage-migrate-github-logs githublogs
   

3. Beenden Sie den Wartungsmodus.

   Shell

   gh es maintenance set --enabled false
   

4. Testen Sie die Instanz für einen bestimmten Zeitraum, um sicherzustellen, dass alles wie erwartet funktioniert.

5.        **Erst nach ausreichenden Tests**, entfernen `/data/user/mysql-backup`, `/data/user/repositories-backup`, `/var/log-backup`, `/data/github/current/log-backup`, und `/data/github/shared/log-backup`.
   

   Wenn Sie diese Ordner während des Tests beibehalten, können Sie einen Rollback in einem Notfall durchführen. Nach ausreichenden Tests sollten Sie diese Sicherungsordner entfernen, um Speicherplatz freizugeben.

Leitfaden für Konfigurationen mit hoher Verfügbarkeit

Die folgenden Anleitungen tragen dazu bei, Ausfallzeiten bei Topologien mit hoher Verfügbarkeit (HA) zu reduzieren. Wenn Sie eine eigenständige Topologie verwenden, haben wir derzeit keine ähnlichen zusätzlichen Anleitungen.

Bei HA-Topologien besteht der beste Ansatz darin, ein neues Replikat zu erstellen, das mit mehreren Datenträgern konfiguriert ist, Daten vom Primärsystem zu replizieren und dann das Replikat zum Primärsystem zu befördern. Das Migrieren von Daten zu zusätzlichen Datenträgern auf der aktuellen Primären wird nicht empfohlen, da dieser Prozess zu erheblichen Ausfallzeiten führen kann.

1. Richten Sie ein neues HA-Replikat mit besseren Datenträgern ein.

Um die Datenmigration zu planen, verwende du -sh /data/user/mysql, du -sh /data/user/repositories, du -sh /var/log, du -sh /data/github/current/log und du -sh /data/github/shared/log auf dem primären Datenträger, um den Speicherplatzbedarf für die neue Replik zu berechnen.

1. Richte auf dem neuen HA-Replikat mehrere Datenträger ein.
2. Biete die Möglichkeit, dass der primäre HA-Rechner auf den Replikator repliziert.
3. Folgen Sie der Failoversequenz, wie in Initiieren eines Failovers zu deiner Replikat-Appliance dokumentiert.

Während der Replikationsprozess lange dauern kann, ist der Vorteil, dass er im Hintergrund ausgeführt wird, sodass die tatsächliche Unterbrechung des Wartungsmodus erheblich reduziert wird.

Beispiel: Konfigurieren zusätzlicher Datenträger

Dieses Beispiel veranschaulicht die erforderlichen Befehle und Ausgaben für die Initialisierung der Datenträger und die Datenmigration. Im Einzelnen wird /data/user/mysql nach /data/multi-disk/db/mysql und /data/user/repositories nach /data/multi-disk/git/repositories migriert. Außerdem werden die Systemprotokolle nach /data/multi-disk/systemlogs/log und die GitHub Protokolle nach /data/multi-disk/githublogs migriert.

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk status
Checking system status...

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk info
Dumping disk status and information...

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme2n1 db
Starting initialization sequence for /dev/nvme2n1 at /data/multi-disk/db...

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme3n1 git
Starting initialization sequence for /dev/nvme3n1 at /data/multi-disk/git...

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme4n1 systemlogs
Starting initialization sequence for /dev/nvme4n1 at /data/multi-disk/systemlogs...

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme5n1 githublogs
Starting initialization sequence for /dev/nvme5n1 at /data/multi-disk/githublogs...

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-mysql db
Start MySQL migration to /data/multi-disk/db...
Running checks..
Error: maintenance mode must be enabled before being able to proceed.
ERROR: Last Command: return 1 LINE: 36 ghe-storage-migrate-mysql
Script exited with exit code: 1

admin@ghe-test-primary:~$ ghe-maintenance -s

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-mysql db
Start MySQL migration to /data/multi-disk/db...
Success: /data/user/mysql moved to /data/multi-disk/db/mysql
Script exited with exit code: 0

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-repositories git
Start repository migration to /data/multi-disk/git...
Success: /data/user/repositories moved to /data/multi-disk/git
Script exited with exit code: 0

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-logs systemlogs
Start log migration to /data/multi-disk/systemlogs...
Success: /var/log moved to /data/multi-disk/systemlogs/log
Please restart the GitHub Enterprise instance to apply the changes.
Script exited with exit code: 0

admin@ghe-test-primary:~$ sudo reboot

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-github-logs githublogs
Error: Config apply currently in progress. Please wait for it to finish...

# Wait for config apply to finish

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-migrate-github-logs githublogs
Start github log migration to /data/multi-disk/githublogs...
Success:  moved to /data/multi-disk/githublogs
Script exited with exit code: 0

admin@ghe-test-primary:~$ ghe-maintenance -u

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk status
Checking system status...
Multi disk setup is enabled...
Potential disks are automatically mounted on startup...
# Disk check
Detected multi disk path at /data/multi-disk/db...
/data/multi-disk/db is set up correctly for multi disk use.
Detected multi disk path at /data/multi-disk/git...
/data/multi-disk/git is set up correctly for multi disk use.
Detected multi disk path at /data/multi-disk/githublogs...
/data/multi-disk/githublogs is set up correctly for multi disk use.
Detected multi disk path at /data/multi-disk/systemlogs...
/data/multi-disk/systemlogs is set up correctly for multi disk use.
# Service migration check
MySQL migration was detected...
/data/user/mysql -> /data/multi-disk/db/mysql is correctly symlinked.
Repositories migration was detected...
/data/user/repositories -> /data/multi-disk/git/repositories is correctly symlinked.
GitHub current log migration was detected...
/data/github/current/log -> /data/multi-disk/githublogs/github-current-log is correctly symlinked.
GitHub shared log migration was detected...
/data/github/shared/log -> /data/multi-disk/githublogs/github-shared-log is correctly symlinked.
Logs migration was detected...
/var/log -> /data/multi-disk/systemlogs/log is correctly symlinked.

admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk info
Dumping disk status and information...
# Multi disk configuration /data/user/multi-disk-config:
DISK_DB="lvm"
DISK_GIT="lvm"
DISK_SYSTEMLOGS="lvm"
DISK_GITHUBLOGS="lvm"
MYSQL_MIGRATION_PATH="/data/multi-disk/db/mysql"
REPOSITORIES_MIGRATION_PATH="/data/multi-disk/git/repositories"
# Multi-disk logs path is stored in /etc/multi-disk/ghe-multi-disk-logs-mount
GHCURRENT_LOG_MIGRATION_PATH="/data/multi-disk/githublogs/github-current-log"
GHSHARED_LOG_MIGRATION_PATH="/data/multi-disk/githublogs/github-shared-log"
ENABLE_MULTI_DISK_LOGS_MOUNT=true

LOGS_MIGRATION_PATH=/data/multi-disk/systemlogs/log

admin@ghe-test-primary:~$ ls /var/log/multi-disk/
ghe-storage-init-db.log   ghe-storage-init-git.log    ghe-storage-migrate-github-logs.log   ghe-storage-migrate-mysql.log   ghe-storage-init-githublogs.log   ghe-storage-init-systemlogs.log   ghe-storage-migrate-logs.log    ghe-storage-migrate-repositories.log

Hygienekontrollen

Sowohl /usr/local/share/enterprise/ghe-storage-multi-disk status als auch /usr/local/share/enterprise/ghe-storage-multi-disk info sind hilfreich, um Ihre Einrichtung zu überprüfen.

Verwenden Sie Folgendes, um die aktuelle Konfiguration für mehrere Datenträger anzuzeigen:

$ cat /data/user/multi-disk-config
DISK_DB="lvm"
DISK_GIT="lvm"
DISK_SYSTEMLOGS="lvm"
DISK_GITHUBLOGS="lvm"
MYSQL_MIGRATION_PATH="/data/multi-disk/db/mysql"
REPOSITORIES_MIGRATION_PATH="/data/multi-disk/git/repositories"
# Multi-disk logs path is stored in /etc/multi-disk/ghe-multi-disk-logs-mount
GHCURRENT_LOG_MIGRATION_PATH="/data/multi-disk/githublogs/github-current-log"
GHSHARED_LOG_MIGRATION_PATH="/data/multi-disk/githublogs/github-shared-log"

$ cat /etc/multi-disk/ghe-multi-disk-logs-mount
ENABLE_MULTI_DISK_LOGS_MOUNT=true

LOGS_MIGRATION_PATH=/data/multi-disk/systemlogs/log

Führen Sie Folgendes aus, um Protokolle mit mehreren Datenträgern zu überprüfen, einschließlich Datenträgerinitialisierungs- und Migrationsereignissen:

$ ls -l /var/log/multi-disk/
total 64
-rw-r--r-- 1 root root  2115 Feb 13 16:32 ghe-storage-init-db.log
-rw-r--r-- 1 root root  2478 Feb 13 16:36 ghe-storage-init-githublogs.log
-rw-r--r-- 1 root root  2114 Feb 13 16:36 ghe-storage-init-git.log
-rw-r--r-- 1 root root  2378 Feb 13 16:36 ghe-storage-init-systemlogs.log
-rw-r--r-- 1 root root 20450 Feb 13 17:27 ghe-storage-migrate-github-logs.log
-rw-r--r-- 1 root root  1053 Feb 13 17:15 ghe-storage-migrate-logs.log
-rw-r--r-- 1 root root  2460 Feb 13 16:38 ghe-storage-migrate-mysql.log
-rw-r--r-- 1 root root 19011 Feb 13 16:42 ghe-storage-migrate-repositories.log

Befehle zum Verwalten mehrerer Datenträger

Diese Befehle ermöglichen das Hinzufügen mehrerer Datenträger und das Migrieren bestimmter Dienste oder Ordnerpfade zu diesen Datenträgern. Die ursprünglichen Ordnerpfade werden beibehalten und statisch gehalten. Andere Dienste wissen nicht, dass sich etwas geändert hat. Die Pfade für statische Ordner werden mit den neu migrierten Pfaden verknüpft.

Zu den Befehlen gehören:

• ghe-storage-multi-disk

  • status
  • init
  • info
  • mount
  • start-services (nur für das Debuggen empfohlen)
  • stop-services (nur für das Debuggen empfohlen)

• ghe-storage-migrate-repositories

  • Migriert /data/user/repositories zu einem beliebigen Datenträgerpfad, der mit ghe-storage-multi-disk init erstellt wurde.

• ghe-storage-migrate-mysql

  • Migriert /data/user/mysql zu einem beliebigen Datenträgerpfad, der mit ghe-storage-multi-disk init erstellt wurde.

• ghe-storage-migrate-logs

  • Migriert /var/log zu einem beliebigen Datenträgerpfad, der mit ghe-storage-multi-disk init erstellt wurde.

• ghe-storage-migrate-github-logs

  • Migriert /data/github/current/log und /data/github/shared/log zu einem beliebigen Datenträgerpfad, der mit ghe-storage-multi-disk init erstellt wurde.