Migration de l'ensemble de la plateforme
La migration de la plateforme consiste essentiellement en une migration de base de données et une migration des services. Dans ce cas, vous devez installer tous les logiciels annexes sur le nouveau serveur, puis déplacer la base de données et copier les services.
Les étapes décrites ci‑dessous s'appliquent aussi bien aux installations Linux qu'à celles sous Windows. De plus, elles peuvent être utilisées pour une migration de Windows vers Linux, ou inversement.
Étape 1 - prérequis
Tout d'abord, vous devez préparer le(s) serveur(s) pour exécuter la plateforme. En général, la capacité de production ne doit pas être inférieure à l'existante, c'est‑à‑dire que vous devez vous assurer que le serveur dispose du même nombre ou d'un nombre supérieur de cœurs CPU, de RAM et d'espace disque. L'infrastructure réseau doit offrir une bande passante Internet suffisante, et les mêmes ports doivent être ouverts pour que la plateforme fonctionne comme sur le serveur précédent.
En règle générale, lors du calcul des paramètres du nouveau serveur, vous pouvez vous appuyer sur le exigences matérielles indiqué dans la section correspondante de notre site web.
Du point de vue logiciel, le même logiciel tiers doit être installé que sur le serveur source. Cela inclut :
Java SE Development Kit (JDK) 17
MySQL Server 8.0
NGINX 1.2 ou version ultérieure
Seules les versions majeures importent ici, et la différence de versions mineures n'affectera pas la fonctionnalité.
Étape 2 - migration de la base de données
C'est l'étape la plus longue et la plus gourmande en ressources car la base de données croît au fil du temps et peut atteindre une taille importante.
La stratégie de base consiste à effectuer une sauvegarde de la base de données existante, puis à la transférer sur le nouveau serveur et à restaurer la base de données à partir de la sauvegarde. C'est une méthode simple, fiable et éprouvée, mais l'inconvénient est le temps d'arrêt prolongé, qui s'allonge encore davantage avec la taille de la base de données.
Si vous disposez d'un disque séparé sur votre ancien serveur hébergeant la base de données, vous pouvez simplement le démonter puis le monter sur le nouveau serveur. De cette façon, la base de données sera transférée presque instantanément. Malheureusement, cette méthode ne fonctionne que lors d'une virtualisation au sein du même centre de données ou du même fournisseur cloud (AWS, Azure, etc.). Si vous changez de centre de données, cette méthode n'est pas applicable.
Pour les grandes bases de données et dans les cas où minimiser le temps d'arrêt est crucial, une méthode avancée connue sous le nom de réplication de base de données doit être utilisée. Dans ce cas, une réplique de la base de données est créée sur le serveur cible, elle est progressivement remplie de données et fonctionne en tant qu'esclave. Cette procédure est lente, mais permet à la base de données maître de continuer à fonctionner normalement sans interruption. Lorsque l'esclave rattrape la population du maître, il ne reste plus qu'à inverser maître/esclave, et ainsi la base de données sera complètement migrée vers le nouveau serveur avec toutes les données actuelles.
La réplication n'est pas une fonctionnalité standard de MySQL, elle nécessite donc l'utilisation d'un logiciel tiers à cet effet. Il existe différentes solutions et chaque administrateur système a ses propres préférences en matière d'outils. Notre outil préféré est XtraBackup application de Percona qui permet d'effectuer des sauvegardes à chaud et la réplication d'une base de données en fonctionnement.
Lors de la copie de la base de données, la clé de licence est corrompue car elle n'est utilisable que sur un seul serveur. Vous devrez peut‑être sauvegarder la clé de licence séparément avant de basculer vers la base de données du nouveau serveur. Il s'agit de la chaîne de symboles dans la ligne fingerprint de la google.variables table. Vous devez enregistrer cette valeur et la substituer au même endroit avant de démarrer la nouvelle base de données. Si la clé n'a pas été sauvegardée et a été corrompue, le support technique Navixy la réémettra gratuitement.
Étape 3 - migration des services
Le seul élément de la plateforme qui change constamment est la base de données. En même temps, les services de la plateforme et le site web restent statiques, et les modifications n'interviennent que lors des mises à jour de la plateforme. Il suffit donc de copier les répertoires nécessaires, y compris leur contenu, aux mêmes chemins.
Sur Linux, ce sont :
/home/java/
/var/www
/etc/nginx/ (toutes les configurations et certificats SSL)
Sur Windows, ce sont :
C:\java
C:\nginx
Après cela, vous devez configurer les services Navixy pour qu'ils s'exécutent. Sur Linux, cela se fait avec systemd, sur Windows avec Java Wrapper. Les configurations sur l'ancien et le nouveau serveur doivent être identiques. Si vous ne savez pas comment configurer ces services, contactez le support technique Navixy.
Étape 4 - changement d'adresse IP
Une fois que vous avez déplacé la base de données et tous les services vers le nouveau serveur, vous devez rendre ce serveur principal et accessible aux clients et à leurs appareils de suivi.
Pour ce faire, vous devez transférer l'adresse IP publique de l'ancien serveur vers le nouveau.
Si le transfert de l'adresse IP est impossible (ce qui peut être le cas lors d'un changement de centre de données), vous devez modifier la configuration DNS en liant votre domaine à la nouvelle adresse IP publique du serveur.
Étapes finales
Après le changement d'adresse IP, vous devez arrêter les services java en cours d'exécution sur l'ancien serveur.
Ensuite, vous pouvez démarrer tous les services sur le nouveau serveur. Cela termine la migration et vous pouvez vérifier la disponibilité de la plateforme migrée.
Si vous rencontrez des problèmes pendant ou après la migration, vous pouvez contacter le support technique Navixy à [email protected] pour une consultation complémentaire.
Mis à jour
Ce contenu vous a-t-il été utile ?