Non, nous n'avons pas de solution automatique pour migrer un serveur virtuel entre centres de données à cause de limitations techniques (l'adresse IP par exemple).

Vous devrez alors créer un nouveau serveur sur l'interface d'administration.

Il vous faudra ensuite transférer les données de l'ancien serveur vers le nouveau.

En Gandi AI, il vous faudra sauvegarder les fichiers sources de votre site web et exporter les bases de données depuis Phpmyadmin par exemple, puis les importer sur le nouveau serveur.

En mode expert, un transfert par SSH est possible directement.

Une seconde méthode en mode expert consisterait à créer un serveur avec un disque de données sur le second centre de données, puis de transférer les données depuis le disque système de l'ancien serveur vers le disque de données du nouveau serveur (par dd par exemple, notez que cela peut prendre du temps). Enfin, vous pourrez modifier le type du disque de données en disque système sur l'interface d'administration dans les paramètres avancés du disque, puis démarrez sur celui-ci.

Voici quelques commandes pour cette méthode :

• Avec dd/gzip :

  dd iflag=direct bs=8k if=/dev/xvdYX | gzip -9 | ssh baltimore-server "gzip -d | dd bs=8k of=/dev/xvdYX"

• Avec mbuffer :

1. on démarre le destinataire à Baltimore :

   mbuffer -q -s 128k -m 8M -I <baltimore_server>:<port> | gzip -d | dd bs=8k of=/dev/xvdYX

2. on démarre l'expéditeur à Paris :

   dd iflag=direct bs=8k if=/dev/xvdYX | gzip -9 | mbuffer -q -s 128k -m 2M -O <baltimore_server>:<port>

• Avec rsync, copiez seulement ce dont vous avez besoin :

rsync -arvz src baltimore_server:/dst

Non, les allocations d'adresses IP et le système d'approvisionnement des serveurs des deux centres de données sont indépendants.

Non, pour les mêmes raisons que la migration d'un serveur entre centres de données, les deux plateformes FR et US sont indépendantes.

Non, les serveurs DNS anycast donnent simplement la présence physiques des serveurs DNS Gandi dans de multiples endroits pour que les requêtes DNS soient servies par le service le plus proche.

Non, les plateformes sont indépendantes l'une de l'autre et utilisent des allocations d'adresses IP séparées.

Il est possible de le faire sous certaines conditions. Nous avons testé ce type de solution mais c'est du sur-mesure, il y a toujours des limitations concernant l'utilisation de nos propres adresses IP sur vos serveurs. Vous aurez besoin de vous entretenir avec notre équipe technique à propos de vos pré-requis pour voir si nous pouvons effectuer cette configuration.

La latence est définie comme le délai de la route aller entre deux points sur un réseau. Ce que vous voyez sur le traceroute est le délai d'aller-retour pour le saut en question (avec une exception pour les sauts contenus dans une route MPLS?). La latence transatlantique plus les distances des câbles entre Paris et Baltimore occasionnent un retard dans un seul sens de l'ordre de 45ms (plus ou moins un couple ?) Cela se traduit par un retard aller-retour d'au moins 90ms, ce qui est normal. Notez que cette explication est simplifiée et que d'autres facteurs déterminent la latence réelle.

Ce comportement est dû à la taille du tampon matériel sur les interfaces Ethernet physiques qui doivent être remplis avant de pouvoir publier les données sur la connexion Ethernet. Si le trafic est petit ou nul, les petits paquets seront «stockés» dans les tampons jusqu'à ce qu'il y ait suffisamment de données à transmettre. Cela se traduira par un faux retard sur la route aller-retour et la variance (jitter readings?). Avec une utilisation de données normale, ce phénomène sera moins évident. Cependant, ce comportement est tout à fait normal pour n'importe quel périphérique réseau ou un serveur.

Nous travaillons actuellement sur une solution de réseaux privés virtuels que nous déploierons dans le courant 2011 dans le même centre de données. Nous regardons actuellement ce qu'il est possible de mettre en place pour des centres de données différents en terme de VLAN.