Configuration de plusieurs disques de données

Vous pouvez configurer des disques de données supplémentaires et les utiliser pour héberger des données de différents services.

Qui peut utiliser cette fonctionnalité ?

GitHub Enterprise Server

Dans cet article

Remarque

La possibilité de configurer et d’utiliser plusieurs disques de données se trouve dans préversion publique et peut être modifiée. Nous aimerions recevoir vos commentaires sur l'aperçu. Vous pouvez le partager avec votre équipe de réussite client ou laisser un commentaire dans le billet de discussion de la communauté. Notre option préférée consiste à partager vos commentaires avec votre équipe de réussite client.

Pourquoi introduire davantage de disques dans l’instance GHES ?

  • Distribution améliorée des ressources :

    • Différents services ont des exigences de disque uniques.
    • MySQL est principalement sensible à la latence et aux IOPS.
    • Certaines ressources (telles que les référentiels) ne bénéficient pas autant de l'utilisation d'un stockage sur blocs coûteux.

  • Limites maximisées de machines virtuelles :

    • Un seul disque n’est souvent pas en mesure de limiter les limitations d’une instance.
    • Du point de vue des coûts, il n’est généralement pas possible ou utile d’exécuter tout sur le stockage le plus coûteux ou le plus rapide.

  • Séparation plus claire entre l’allocation de ressources et les services :

    • Les ressources peuvent être allouées de manière ciblée, ce qui empêche les services critiques d’être affamés.

  • Échelle:

    • Les clients utilisant aussi bien des topologies autonomes que des topologies à haute disponibilité peuvent effectuer un scale-out en fonction de leurs besoins.

  • Résilience:

    • L’isolation des journaux d’activité du disque racine renforce la résilience en évitant que le volume des journaux d’activité ne sature le disque racine.

Constraints

  • Les disques multi-données sont pris en charge uniquement sur les topologies autonomes et haute disponibilité (HA).

  • Une fois que plusieurs disques de données sont configurés dans un déploiement, cette modification ne peut pas être annulée pour ce déploiement.

  • La configuration de disques multi-données et la migration des données nécessitent généralement un temps d’arrêt.

    • Vous pouvez réduire cela en configurant un réplica avec des disques de données multiples, en répliquant les données à partir du serveur principal, puis en basculant vers le réplica.
    • Si vous ajoutez des disques multi-données directement au serveur principal, attendez-vous à un temps d’arrêt beaucoup plus long.

  • Pendant la préversion publique, les disques multi-données doivent être utilisés uniquement dans les environnements hors production.

  • Il n’est pas recommandé de migrer MySQL, les dépôts, les journaux système ou les journaux GitHub vers le même disque. Chaque disque supplémentaire ne doit contenir qu’une seule migration.

  • Actuellement, seuls les journaux MySQL, référentiels, journaux système et GitHub peuvent être migrés vers des disques supplémentaires.

  • Le redémarrage du nœud GitHub Enterprise Server est nécessaire après la migration des journaux système pour s'assurer qu'il fonctionne à l'échelle du système. Il faudra un certain temps, car l'application de la configuration a lieu également pendant le démarrage du nœud.

Recommandations sur la ressource

Si vous ajoutez des disques aussi rapides ou plus rapides que vos disques actuels, vous devriez voir des performances améliorées. Les périphériques de stockage sont généralement mesurés par IOPS (opérations d’entrée/sortie par seconde), le débit et la latence. Pour MySQL, nous vous recommandons d’utiliser un disque avec une latence inférieure et des IOPS plus élevées que votre disque de données existant. Pour les dépôts, choisissez un disque avec des E/S par seconde et un débit plus élevés que votre disque de données actuel. Pour les journaux, nous vous recommandons d’utiliser un disque avec des E/S par seconde et un débit supérieurs à ceux de votre disque de données existant pour gérer les opérations d’écriture continue à partir des activités de journalisation.

Dans les configurations à haute disponibilité, il est préférable d’utiliser des disques de données multiples à la fois sur le serveur principal et sur tous les réplicas. Il n’est pas recommandé de mélanger les configurations où le serveur principal utilise des disques de données multiples, tandis que le réplica n’en utilise pas.

Configuration de plusieurs disques de données et chemins d’accès aux données

Prerequisites

  • Nous vous recommandons de procéder à une sauvegarde récente de vos données avant de commencer.
  • Créez un environnement de test pour essayer la fonctionnalité.
    • Pendant la préversion publique, nous vous recommandons uniquement d’utiliser la fonctionnalité dans un environnement de test.
    • Une fois la fonctionnalité généralement disponible, nous vous recommandons de tester la fonctionnalité dans un environnement hors production avant de l’utiliser en production.

Instructions

  1. Vous pouvez effectuer une nouvelle installation de GHES ou utiliser une instance GHES existante. Le disque de données doit être configuré à l’adresse /data/user.

  2. Une fois /data/user configuré, ajoutez des périphériques de stockage de blocs supplémentaires à l’instance.

    Actuellement, ghe-storage-find choisit le premier stockage de blocs pour la configuration /data/user en fonction de l’ordre alphabétique du chemin de stockage de bloc. Cela se produit lors du premier démarrage de l’appliance GHES.

    Pour avoir plus de contrôle sur le disque utilisé pour /data/user, il est préférable d'effectuer le processus d'initialisation avec un seul disque attaché au départ.

  3. Initialisez la configuration multi-disque en utilisant les nouveaux dispositifs de stockage en bloc. Pour initialiser la prise en charge de plusieurs disques, exécutez ghe-storage-multi-disk init. Lors de chaque redémarrage, ghe-multi-disk.service remontera automatiquement les disques de données existants aux chemins appropriés.

    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

Notez que /dev/nvme2n1, /dev/nvme3n1, /dev/nvme4n1et /dev/nvme5n1 sont des exemples de chemins uniquement. Ils peuvent ne pas correspondre aux chemins d’accès de votre système. De même, , db, git``systemlogs, et githublogs sont des exemples. Vous pouvez choisir des noms différents.

  1. Basculez vers le mode maintenance.

    Shell
    gh es maintenance set --enabled true

  2. Migrez vos chemins de données souhaités.

    Pour migrer MySQL :

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

    Pour migrer des référentiels :

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

    Pour effectuer la migration des journaux d’activité système :

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

    Après avoir migré les journaux système, redémarrez l’instance :

    Shell
    sudo reboot

    Pour effectuer la migration des journaux d’activité GitHub :

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

  3. Quittez le mode maintenance.

    Shell
    gh es maintenance set --enabled false

  4. Testez l’instance pendant une période de temps pour vous assurer que tout fonctionne comme prévu.

  5.        **Seulement après un test suffisant**, supprimez`/data/user/mysql-backup`, , `/data/user/repositories-backup``/var/log-backup`, `/data/github/current/log-backup`et `/data/github/shared/log-backup`.

    La conservation de ces répertoires pendant les tests vous permet de revenir en arrière en cas d'urgence. Une fois les tests suffisants, vous devez supprimer ces dossiers de sauvegarde pour libérer de l’espace.

Conseils pour les configurations de haute disponibilité

Les conseils suivants permettent de réduire les temps d’arrêt dans les topologies haute disponibilité (HA). Si vous utilisez une topologie autonome, nous n’avons pas de conseils supplémentaires similaires pour l’instant.

Pour les topologies de haute disponibilité, la meilleure approche consiste à mettre en place un nouveau réplica avec plusieurs disques de données configurés, à répliquer les données depuis le primaire, puis à promouvoir le réplica au statut de primaire. La migration de données vers des disques supplémentaires sur le serveur principal actuel n’est pas recommandée, car ce processus peut entraîner un temps d’arrêt important.

  1. Configurez un nouveau réplica HA avec de meilleurs disques.

Pour planifier la migration des données, utilisez du -sh /data/user/mysql, du -sh /data/user/repositories, du -sh /var/log, du -sh /data/github/current/log et du -sh /data/github/shared/log sur le serveur maître pour calculer les besoins en espace disque pour le nouveau réplica.

  1. Configurez des disques multiples sur le nouveau réplica HA.
  2. Autorisez le serveur principal HA à répliquer vers le réplica.
  3. Suivez la séquence de basculement comme documentée dans Lancement d’un basculement vers votre appliance réplica.

Bien que le processus de réplication puisse prendre beaucoup de temps, l’avantage est qu’il s’exécute en arrière-plan, de sorte que l’interruption réelle du mode de maintenance est considérablement réduite.

Exemple : configuration de disques supplémentaires

Cet exemple illustre les commandes et sorties requises pour l’initialisation de disque et la migration des données. Plus précisément, /data/user/mysql est déplacé vers /data/multi-disk/db/mysql, et /data/user/repositories est déplacé vers /data/multi-disk/git/repositories. En outre, les journaux système sont déplacés vers /data/multi-disk/systemlogs/log, et les journaux GitHub sont déplacés vers /data/multi-disk/githublogs.

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

Contrôles d’hygiène

Les /usr/local/share/enterprise/ghe-storage-multi-disk status et /usr/local/share/enterprise/ghe-storage-multi-disk info sont tous deux utiles pour vérifier votre configuration.

Pour afficher la configuration multi-disque actuelle, utilisez :

$ 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

Pour passer en revue les journaux multi-disques, notamment les événements d’initialisation et de migration de disque, exécutez :

$ 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

Commandes pour la gestion de plusieurs disques

Ces commandes permettent d’ajouter plusieurs disques et de migrer des services ou des chemins de dossier spécifiques vers ces disques. Les chemins d’accès au dossier d’origine sont conservés et restent inchangés. D’autres services ne savent pas que tout a changé. Les chemins d’accès au dossier statique sont liés symboliquement aux chemins nouvellement migrés.

Les commandes sont les suivantes :

  • ghe-storage-multi-disk

    • status
    • init
    • info
    • mount
    • start-services (recommandé uniquement pour le débogage)
    • stop-services (recommandé uniquement pour le débogage)

  • ghe-storage-migrate-repositories

    • /data/user/repositories migre vers n'importe quel chemin de disque créé à l'aide de ghe-storage-multi-disk init.

  • ghe-storage-migrate-mysql

    • /data/user/mysql migre vers n'importe quel chemin de disque créé à l'aide de ghe-storage-multi-disk init.

  • ghe-storage-migrate-logs

    • /var/log migre vers n'importe quel chemin de disque créé à l'aide de ghe-storage-multi-disk init.

  • ghe-storage-migrate-github-logs

    • Migre /data/github/current/log et /data/github/shared/log vers n’importe quel chemin de disque créé à l’aide de ghe-storage-multi-disk init.