Considérations initiales
Problèmes à prendre en compte avant la migration :
DNS-changes-are-not-automatic, so you-need-to-have-a -planifier !
Si votre serveur cloud n'est pas derrière un équilibreur de charge, il y aura un changement d'adresse IP. Cela signifie que vous devrez modifier vos entrées DNS sur la nouvelle adresse IP. Nous vous recommandons de vérifier le TTL ("time to live") pour vous assurer qu'il a une valeur faible (300 secondes / 5 minutes) et d'attendre au moins 24 heures pour que le changement prenne effet. Ce changement garantit que toutes les modifications que vous apportez à votre DNS sont propagées dans le système en 5 minutes ou moins.
Quel est le but de ce serveur ?
Il est important de prendre le temps de déterminer le rôle joué par le serveur. Est-ce uniquement pour les applications Web ? Hébergez-vous des e-mails ? Existe-t-il des bases de données ? Une bonne évaluation initiale peut faire gagner beaucoup de temps et éviter la panique de dernière minute lorsque vous passez de l'ancien serveur au nouveau. Il est important d'identifier où se trouvent vos données, fichiers de configuration, etc. Avoir une bonne compréhension de votre environnement vous aidera à réussir votre migration.
Essayez la migration avec un tampon !
L'un des avantages de la migration vers le cloud est la rapidité et la facilité avec laquelle il est possible de créer ou de supprimer un serveur. Nous vous recommandons, une fois que vous vous considérez prêt à basculer entre l'ancien et le nouveau serveur, d'arrêter uniquement l'ancien serveur, sans le supprimer pour le moment. Laissez-le dans cet état entre 24 heures et une semaine. Si vous constatez que votre site Web ou une autre application fonctionne correctement, il est probable que vous puissiez considérer la migration comme terminée. Si vous remarquez des problèmes lors de l'arrêt de l'ancien serveur, vous n'avez peut-être pas migré tout ce qui devait être migré. Vous avez toujours l'ancien serveur, vous pouvez donc le réactiver (sélectionnez l'option "redémarrer" dans le portail)
Faire le travail
Vérifier la taille de l'ancien serveur
Pour déterminer l'espace disque minimum nécessaire sur votre nouveau serveur, vous devez connaître l'occupation de votre ancien serveur.
Vous pouvez utiliser la commande suivante pour surveiller l'utilisation du disque de votre ancien serveur :
df -h
Si vous avez besoin de plus de 160 Go (la taille de disque maximale pour un serveur "à usage général"), vous devez utiliser des volumes de stockage Cloud Block sur le nouveau serveur pour stocker toutes vos données.
Identifier les exigences du répertoire
Lorsque vous configurez des volumes Cloud Block Storage, il est bon de vérifier la taille des répertoires sur votre serveur d'origine. Ces informations vous aideront à planifier l'organisation des informations sur le nouveau serveur, en détaillant quelles informations seront stockées sur le disque système et quelles autres informations seront stockées sur des volumes supplémentaires.
Sous Linux, vous pouvez déterminer l'espace utilisé par les fichiers et les répertoires avec la commande suivante :
du -hs *
Vous pouvez également spécifier le nom du répertoire ou du fichier avec la commande suivante :
du -hs NombredeDirectorio
Une fois que vous savez quelles informations vous allez copier sur le disque système et quelles informations vous allez copier sur le disque supplémentaire, vous pouvez planifier la taille du nouveau serveur et ses volumes supplémentaires.
Créer un serveur cible
Lors de la création du serveur de destination, il est important de prendre en compte les exigences de stockage sur disque, ainsi que la mémoire, le processeur et la mise en réseau.
Si la taille de vos données dépasse la taille du disque système du serveur, vous devrez décider si vous souhaitez utiliser un ou plusieurs disques supplémentaires (serveurs de type I/O uniquement) ou utiliser un volume Cloud Block Storage. tenez compte des exigences actuelles, ainsi que des exigences futures.
Les serveurs optimisés pour les E/S ne peuvent pas être redimensionnés une fois créés. Les seules modifications que vous pouvez apporter consistent donc à ajouter ou à supprimer de l'espace disque à l'aide de Cloud Block Storage. Les serveurs de type « General Purpose » ont une taille maximale de 8 Go de RAM/160 Go sur disque. Seuls les serveurs de type « General Purpose » qui n'utilisent pas le mode de virtualisation de precate paravirtual (PV) peuvent modifier leur taille.
Dans un environnement à serveur unique, pour changer les ressources RAM ou CPU, il sera nécessaire de migrer vers un nouveau serveur.
Si vous prévoyez qu'il sera nécessaire d'augmenter ou de diminuer les ressources de votre environnement, vous pouvez concevoir votre solution pour tirer parti de la mise à l'échelle horizontale. À l'aide d'un équilibreur de charge, vous pouvez avoir plusieurs nœuds exécutant votre application et vous pouvez ajouter ou supprimer des nœuds en tant que la charge change. Il convient de noter que la mise à l'échelle horizontale n'est pas nécessairement la bonne pour toutes les applications.
L'article sur l'architecture de référence du cloud ouvert illustre quelques exemples de différents environnements cloud.
Remarque : Si vous utilisez des serveurs de type Performance, il est important de noter que les disques de données ne sont pas inclus lorsque vous générez une image.Pour sauvegarder des disques de données, il est nécessaire d'utiliser le service RackspaceCloud Backup ou une autre solution similaire. Si vous avez besoin que votre stockage soit portable ou que vous ayez besoin de prendre des instantanés, nous vous recommandons d'utiliser des volumes Cloud Block Storage.
Préparer des volumes ou des disques de données Cloud Block Storage
Une fois le nouveau serveur créé, il est nécessaire de préparer les disques de données ou Cloud Block Storage en formatant le disque et en configurant le système d'exploitation pour les utiliser.
Pour préparer Cloud Block Storage, vous pouvez voir Préparer votre volume Cloud Block Storage.
Pour préparer des disques de données sur des serveurs de type optimisé pour les E/S, vous pouvez consulter Préparer des disques de données sur des serveurs cloud Linux.
Si vous souhaitez utiliser les disques supplémentaires dans la configuration RAID sous Linux, vous pouvez consulter Linux Software-RAID HOWTO.
Options de migration manuelle
Il existe 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 spécifiques, vous pouvez utiliser Cloud Backup. Vous pouvez créer une sauvegarde de vos données sur le serveur source et la restaurer sur le serveur de destination.
### Stockage de blocs dans le cloud
Pour migrer des données spécifiques, vous pouvez utiliser Cloud Block Storage. Vous ajoutez le disque à votre serveur d'origine et copiez les données. Ensuite, vous le démontez du serveur source, le montez sur le serveur de destination et copiez les données.
rsync sur Linux pour la migration d'annuaire
Sous Linux, vous pouvez utiliser rsync pour copier directement un répertoire sur le réseau. Par exemple, depuis le serveur source, 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
Important : Si les deux serveurs cloud se trouvent dans le même centre de données régional (DFW, ORD, IAD, LON, HKG, SYD), vous pouvez utiliser l'adresse IP 10.x attribuée aux deux serveurs pour transférer vos données. En utilisant ce réseau, vous ne serez pas facturé pour l'utilisation de la bande passante entre les serveurs. Si vous transférez les données via l'adresse IP publique, des frais d'utilisation de la bande passante vous seront facturés.
Pour plus d'informations sur rsync, vous pouvez consulter Sauvegarder vos fichiers avec rsync.
Options spécifiques à l'application
D'autres applications peuvent avoir leurs propres moyens pour faciliter la migration des données. Par exemple, pour migrer une base de données, vous pouvez créer une instance esclave sur le serveur de destination et répliquer automatiquement les données du serveur source. Pour plus d'informations sur la création d'une réplication maître-esclave, voir ici.
Tâches post-migration
Une fois que toutes vos données se trouvent sur le serveur de destination, nous vous recommandons de tester soigneusement votre application pour vous assurer qu'elle fonctionne comme prévu. Comme nous l'avons mentionné au début de cet article, nous vous recommandons d'arrêter le serveur d'origine, mais de ne pas le supprimer. Attendez 1 à 7 jours pour avoir une chance de déterminer s'il manquait quelque chose dans la migration qui utilisait l'ancienne adresse IP. Si après 7 jours tout semble être en ordre, il est généralement prudent de procéder à la suppression du serveur d'origine.
Si ce n'est pas le cas, le moment est venu de mettre en œuvre un plan de sauvegarde sur le serveur cible.
