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.
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 et les dépôts vers le même disque.
-
Actuellement, seuls MySQL et référentiels peuvent être migrés vers des disques supplémentaires.
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.
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
-
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. -
Une fois
/data/userconfiguré, ajoutez des périphériques de stockage de blocs supplémentaires à l’instance.Actuellement,
ghe-storage-findchoisit le premier stockage de blocs pour la configuration/data/useren 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. -
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.serviceremontera automatiquement les disques de données existants aux chemins appropriés.Shell /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme2n1 db
/usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme2n1 dbShell /usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme3n1 git
/usr/local/share/enterprise/ghe-storage-multi-disk init /dev/nvme3n1 git
Notez que /dev/nvme2n1 et /dev/nvme3n1 sont uniquement des chemins d'accès d'exemple. Ils peuvent ne pas correspondre aux chemins d’accès de votre système. De même, db et git sont des exemples. Vous pouvez choisir des noms différents.
-
Basculez vers le mode maintenance.
Shell gh es maintenance set --enabled true
gh es maintenance set --enabled true -
Migrez vos chemins de données souhaités.
Pour migrer MySQL :
Shell /usr/local/share/enterprise/ghe-storage-migrate-mysql db
/usr/local/share/enterprise/ghe-storage-migrate-mysql dbPour migrer des référentiels :
Shell /usr/local/share/enterprise/ghe-storage-migrate-repositories git
/usr/local/share/enterprise/ghe-storage-migrate-repositories git -
Quittez le mode maintenance.
Shell gh es maintenance set --enabled false
gh es maintenance set --enabled false -
Testez l’instance pendant une période de temps pour vous assurer que tout fonctionne comme prévu.
-
**Seulement après un test suffisant**, supprimez `/data/user/mysql-backup` et `/data/user/repositories-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.
-
Configurez un nouveau réplica HA avec de meilleurs disques.
Pour planifier la migration des données, utilisez
du -sh /data/user/mysqletdu -sh /data/user/repositoriessur le serveur principal pour calculer les besoins en espace disque pour le nouveau réplica. -
Configurez des disques multiples sur le nouveau réplica HA.
-
Autorisez le serveur principal HA à répliquer vers le réplica.
-
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 migré vers /data/multi-disk/db/mysql, et /data/user/repositories est migré vers /data/multi-disk/git/repositories.
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-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:~$ ghe-maintenance -u
admin@ghe-test-primary:~$ /usr/local/share/enterprise/ghe-storage-multi-disk status
Checking system status...
/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.
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"
MYSQL_MIGRATION_PATH="/data/multi-disk/db/mysql"
REPOSITORIES_MIGRATION_PATH="/data/multi-disk/git/repositories"
admin@ghe-test-primary:~$ ls /var/log/multi-disk/
ghe-storage-init-db.log ghe-storage-init-git.log ghe-storage-migrate-mysql.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"
MYSQL_MIGRATION_PATH="/data/multi-disk/db/mysql"
REPOSITORIES_MIGRATION_PATH="/data/multi-disk/git/repositories"
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 56
-rw-r--r-- 1 root root 2398 Mar 3 13:22 ghe-storage-init-db.log
-rw-r--r-- 1 root root 2497 Mar 3 13:23 ghe-storage-init-git.log
-rw-r--r-- 1 root root 2201 Mar 3 13:28 ghe-storage-migrate-mysql.log
-rw-r--r-- 1 root root 37296 Mar 3 13:30 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
statusinitinfomountstart-services(recommandé uniquement pour le débogage)stop-services(recommandé uniquement pour le débogage)
- ghe-storage-migrate-repositories
/data/user/repositoriesmigre vers n'importe quel chemin de disque créé à l'aide deghe-storage-multi-disk init.
- ghe-storage-migrate-mysql
/data/user/mysqlmigre vers n'importe quel chemin de disque créé à l'aide deghe-storage-multi-disk init.