Considérations initiales
Tenez compte des éléments suivants lorsque vous planifiez une migration de cloud à cloud.
Planifiez à l'avance car les modifications DNS ne sont pas automatiques
Si votre serveur cloud actuel, le serveur d'origine, n'est pas derrière un équilibreur de charge, l'adresse IP change. Ce changement signifie que vous devez mettre à jour le serveur de noms de domaine (DNS) pour qu'il pointe vers une nouvelle adresse IP. Vous devez vous assurer de définir l'enregistrement de durée de vie (TTL) sur 5 minutes, puis d'attendre 24 heures pour vous assurer que le changement se propage correctement. Après cela, toutes les modifications DNS que vous apportez devraient prendre effet dans les 5 minutes.
Objectif du serveur
Le serveur d'origine héberge-t-il des applications Web, des e-mails ou des bases de données ? Fait-il une chose ou gère-t-il une variété de tâches ? Une bonne évaluation initiale, effectuée à l'avance, peut vous éviter une panique de dernière minute lorsque vous basculez entre le serveur d'origine et le nouveau serveur ou serveur de destination. Assurez-vous d'identifier où vous stockez les données, les fichiers de configuration et les autres données importantes. Plus vous en saurez sur votre environnement avant la migration, plus la migration sera fluide.
Tester la migration
L'un des avantages d'une migration vers le cloud est la rapidité et la facilité avec lesquelles vous pouvez faire tourner un serveur vers le haut ou vers le bas. Nous vous encourageons vivement à éteindre le serveur d'origine après la migration plutôt que de le supprimer immédiatement. Laissez-le éteint pendant 24 heures à une semaine. Si votre site Web et vos applications fonctionnent comme prévu, votre migration s'est probablement terminée avec succès. Cependant, si la désactivation du serveur d'origine entraîne des problèmes, cela signifie que certains processus dépendent toujours de l'ancien serveur. Vous pouvez rétablir le serveur d'origine et identifier ce que vous avez manqué et le migrer correctement.
Effectuer le travail
Cette section identifie les étapes d'une migration vers le cloud.
Vérifier la taille du serveur d'origine
Pour déterminer l'espace disque minimum dont vous avez besoin sur le serveur de destination, vérifiez la quantité d'espace disque que vous utilisez actuellement.
Pour vérifier l'espace disque utilisé sous Linux®, exécutez la commande suivante :
df -h
Si vous avez besoin de plus de 160 Go (la taille de disque maximale pour une version à usage général), vous devez utiliser des volumes Cloud Block Storage sur le nouveau serveur pour accueillir toutes vos données.
Identifier les exigences du répertoire
Lorsque vous configurez des volumes Cloud Block Storage, vérifiez la taille des répertoires sur votre serveur d'origine. Ces informations vous aident à planifier l'organisation des données sur le serveur de destination, telles que les données stockées sur le disque système et les données à stocker sur les volumes supplémentaires.
Sous Linux, vous pouvez déterminer l'espace disque utilisé par les fichiers et les sous-répertoires du répertoire courant en exécutant la commande suivante :
du -hs *
Vous pouvez également spécifier un répertoire ou un nom de fichier en exécutant la commande suivante :
du -hs directoryName
Une fois que vous savez quelles données copier sur votre disque système et lesquelles copier sur un disque attaché, planifiez la taille du serveur de destination et ses volumes supplémentaires en conséquence.
Créer le serveur de destination
Lorsque vous créez le serveur de destination, tenez compte de vos besoins en stockage ainsi que des exigences en matière de mémoire, de processeur et de réseau.
Si vous avez plus de données que ne peut en contenir le disque système du serveur de destination, décidez si vous souhaitez utiliser un ou plusieurs disques de données (version E/S uniquement) ou attachez des volumes Cloud Block Storage au serveur.
Lorsque vous choisissez la taille de votre serveur de destination, tenez compte de vos besoins actuels et de toute mise à l'échelle que vous devrez peut-être effectuer à l'avenir.
Vous ne pouvez pas redimensionner les serveurs optimisés pour les E/S, mais vous pouvez ajouter ou supprimer de l'espace de stockage à l'aide de Cloud Block Storage. Les serveurs à usage général ont une taille maximale de 8 Go de RAM pour un disque dur de 160 Go et, à moins qu'ils n'utilisent le mode de virtualisation paravirtuel (PV) obsolète, vous pouvez les agrandir et non les réduire.
Pour un environnement à serveur unique, vous devez migrer vers un nouveau serveur si vos besoins en RAM ou en CPU changent.
Vous pouvez également planifier votre environnement pour utiliser une mise à l'échelle horizontale, où plusieurs serveurs exécutent votre application, avec un équilibreur de charge pour gérer le trafic vers les différents serveurs. La mise à l'échelle horizontale peut ne pas fonctionner avec toutes les applications, mais après l'avoir configurée, vous pouvez facilement ajouter ou supprimer des serveurs pour tenir compte des exigences de charge fluctuantes.
Consultez l'article sur les architectures de référence en cloud ouvert pour obtenir des exemples d'environnements.
Remarque :Si vous utilisez actuellement des serveurs Performance, les disques de données ne sont pas capturés lorsque vous créez une image. Pour sauvegarder des disques de données, vous devez vous fier à Rackspace Cloud Backup ou à une approche similaire de sauvegarde basée sur des fichiers. Si vous souhaitez que votre stockage supplémentaire soit plus portable ou que vous souhaitiez prendre des instantanés de données, envisagez d'ajouter un ou plusieurs volumes Cloud Block Storage au nouveau serveur. Consultez Créer et attacher un volume Cloud Block Storage pour en savoir plus.
Formatez et configurez tous les volumes Cloud Block Storage ou disques de donnéesAprès avoir créé votre serveur, préparez tous les disques de données ou volumes Cloud Block Storage attachés en les formatant et en configurant le système pour les utiliser.
Si vous avez associé des volumes Cloud Block Storage, consultez Préparer votre volume Cloud Block Storage pour plus d'informations.
Pour obtenir des instructions sur le formatage et le montage de disques de données sur des serveurs optimisés pour les E/S, consultez Préparer des disques de données sur des serveurs cloud Linux.
Si vous configurez des volumes attachés dans un RAID logiciel sous Linux, consultez le Linux Software-RAID HOWTO pour obtenir des instructions.
Lorsque vos disques attachés sont prêts, vous pouvez migrer vos données.
Options de migration manuelle
Vous disposez de plusieurs options pour une migration manuelle sur Linux, notamment Rackspace Cloud Backup, Rackspace Cloud Block Storage ou rsync.
Sauvegarde dans le cloud
Pour migrer des répertoires particuliers, vous pouvez utiliser Cloud Backup. Créez une sauvegarde de vos données sur le serveur d'origine, puis restaurez-la sur le serveur de destination.
Stockage de blocs cloud
Pour migrer des données spécifiques, vous pouvez utiliser Cloud Block Storage. Connectez le lecteur au serveur d'origine et copiez-y vos données. Détachez ensuite le lecteur du serveur d'origine, connectez-le au serveur de destination et copiez vos données à partir du lecteur.
Utiliser rsync pour la migration d'annuaire sur Linux
Sous Linux, vous pouvez utiliser rsync pour copier un répertoire directement sur le réseau. Par exemple, depuis le serveur d'origine, vous pouvez exécuter la commande suivante pour copier /var/lib/mysql :
rsync -e 'ssh' -avl --stats --progress /var/lib/mysql [email protected]:/var/lib/mysql
Pour plus d'informations sur rsync , consultez Sauvegarder vos fichiers avec rsync.
Important :Tant que les deux serveurs cloud se trouvent dans le même centre de données régional (DFW, ORD, IAD, LON, HKG ou SYD), vous pouvez utiliser le 10.x Adresse IP attribuée aux deux serveurs pour transférer des données. Cela signifie que vous ne serez pas facturé pour la bande passante des données entre les deux serveurs. Toutes les données transférées à l'aide d'adresses IP publiques entraîneront des coûts de bande passante potentiels.
Options spécifiques à l'application
D'autres applications peuvent avoir leurs propres moyens de faciliter la migration des données. Par exemple, pour migrer une base de données, vous pouvez faire du serveur de destination une réplique de la base de données d'origine pour répliquer automatiquement vos données sur le serveur de destination. Vous pouvez trouver des informations sur la façon de procéder à la réplication du réplica principal MySQL® ici.
Tâches post-migration
Une fois que toutes vos données se trouvent sur le serveur de destination, testez soigneusement votre application pour vous assurer qu'elle fonctionne comme prévu dans l'environnement de destination. Comme mentionné au début de cet article, nous encourageons les clients à éteindre le serveur d'origine mais à ne pas le supprimer pendant un à sept jours. Cette pratique vous donne le temps de déterminer si vous avez manqué quelque chose dans votre migration. Par exemple, qu'une adresse IP plutôt que DNS a été utilisée pour résoudre le serveur d'origine. Si après sept jours, rien ne s'est cassé et que vous n'avez remarqué aucun problème, vous devriez pouvoir supprimer le serveur d'origine en toute sécurité.
Si vous ne l'avez pas déjà fait, implémentez un plan de sauvegarde sur le serveur de destination pour éviter une perte de données importante en cas de catastrophe.