Consideraciones iniciales
Considere los siguientes elementos cuando planifique una migración de nube a nube.
Planifique con anticipación porque los cambios de DNS no son automáticos
Si su servidor en la nube actual, el servidor de origen, no está detrás de un balanceador de carga, la dirección IP cambia. Este cambio significa que debe actualizar el servidor de nombres de dominio (DNS) para que apunte a una nueva IP. Debe asegurarse de establecer el registro de tiempo de vida (TTL) en 5 minutos y luego esperar 24 horas para asegurarse de que el cambio se propague correctamente. Después de eso, cualquier cambio de DNS que realice debería surtir efecto en 5 minutos.
Propósito del servidor
¿El servidor de origen aloja aplicaciones web, correo electrónico o bases de datos? ¿Hace una cosa o maneja una variedad de tareas? Una buena evaluación inicial, realizada con anticipación, puede ahorrarle un pánico de último minuto cuando cambia el interruptor entre el servidor de origen y el servidor nuevo o de destino. Asegúrese de identificar dónde almacena los datos, los archivos de configuración y otros datos importantes. Cuanto más sepa sobre su entorno de cara a la migración, la migración será más fluida.
Probar la migración
Una ventaja de realizar una migración a la nube es la rapidez y facilidad con la que puede activar o desactivar un servidor. Le recomendamos encarecidamente que apague el servidor de origen después de la migración en lugar de eliminarlo de inmediato. Déjalo apagado durante 24 horas a una semana. Si su sitio web y sus aplicaciones se ejecutan como se esperaba, es probable que su migración se haya completado con éxito. Sin embargo, si apagar el servidor de origen genera problemas, significa que algunos procesos aún dependen del servidor anterior. Puede recuperar el servidor de origen e identificar lo que se perdió y migrarlo correctamente.
Realizar el trabajo
Esta sección identifica los pasos para una migración a la nube.
Verificar el tamaño del servidor original
Para determinar el espacio mínimo en disco que necesita en el servidor de destino, verifique cuánto espacio en disco está usando actualmente.
Para comprobar el espacio en disco utilizado en Linux®, ejecute el siguiente comando:
df -h
Si necesita más de 160 GB (el tamaño máximo de disco para un tipo de uso general), debe usar volúmenes de Cloud Block Storage en el nuevo servidor para acomodar todos sus datos.
Identificar los requisitos del directorio
Cuando esté configurando volúmenes de Cloud Block Storage, verifique los tamaños de los directorios en su servidor de origen. Esta información lo ayuda a planificar la organización de los datos en el servidor de destino, como qué datos van al disco del sistema y qué datos debe almacenar en los volúmenes adicionales.
En Linux, puede determinar el espacio en disco que usan los archivos y los subdirectorios en el directorio actual ejecutando el siguiente comando:
du -hs *
También puede especificar un directorio o nombre de archivo ejecutando el siguiente comando:
du -hs directoryName
Una vez que sepa qué datos copiar en el disco de su sistema y cuáles copiar en un disco adjunto, planifique el tamaño del servidor de destino y sus volúmenes adicionales en consecuencia.
Crea el servidor de destino
Cuando cree el servidor de destino, tenga en cuenta sus requisitos de almacenamiento, así como los requisitos de memoria, CPU y red.
Si tiene más datos de los que caben en el disco del sistema del servidor de destino, decida si desea usar uno o más discos de datos (solo tipo de E/S) o adjuntar volúmenes de Cloud Block Storage al servidor.
Al elegir el tamaño de su servidor de destino, considere sus necesidades actuales y cualquier escalamiento que pueda necesitar hacer en el futuro.
No puede cambiar el tamaño de los servidores optimizados para E/S, pero puede agregar o quitar espacio de almacenamiento mediante Cloud Block Storage. Los servidores de propósito general tienen un tamaño máximo de 8 GB de RAM a 160 GB de disco duro y, a menos que usen el modo de virtualización paravirtual (PV) obsoleto, solo puede hacerlos más grandes y no más pequeños.
Para un entorno de un solo servidor, debe migrar a un nuevo servidor si cambian sus requisitos de RAM o CPU.
Como alternativa, puede planificar su entorno para usar el escalado horizontal, donde más de un servidor ejecuta su aplicación, con un balanceador de carga para administrar el tráfico a los diferentes servidores. Es posible que el escalado horizontal no funcione con todas las aplicaciones, pero después de configurarlo, puede agregar o quitar servidores fácilmente para tener en cuenta los requisitos de carga fluctuantes.
Consulte el artículo sobre arquitecturas de referencia de nube abierta para ver algunos entornos de ejemplo.
Nota :si actualmente utiliza servidores de rendimiento, los discos de datos no se capturan cuando crea una imagen. Para hacer una copia de seguridad de los discos de datos, debe confiar en Rackspace Cloud Backup o en un enfoque de copia de seguridad basado en archivos similar. Si desea que su almacenamiento adicional sea más portátil o desea tomar instantáneas de datos, considere agregar uno o más volúmenes de Cloud Block Storage al nuevo servidor. Consulte Crear y adjuntar un volumen de Cloud Block Storage para obtener más información.
Formatee y configure cualquier volumen o disco de datos de Cloud Block Storage Después de crear su servidor, prepare cualquier disco de datos adjunto o volumen de Cloud Block Storage formateándolos y configurando el sistema para usarlos.
Si adjuntó volúmenes de Cloud Block Storage, consulte Preparar su volumen de Cloud Block Storage para obtener más información.
Para obtener instrucciones sobre cómo formatear y montar discos de datos en servidores optimizados para E/S, consulte Preparar discos de datos en servidores en la nube de Linux.
Si está configurando volúmenes adjuntos en un RAID de software en Linux, consulte el CÓMO RAID de software de Linux para obtener instrucciones.
Cuando sus discos adjuntos estén listos, puede migrar sus datos.
Opciones de migración manual
Tiene varias opciones para una migración manual en Linux, incluidos Rackspace Cloud Backup, Rackspace Cloud Block Storage o rsync.
Copia de seguridad en la nube
Para migrar directorios particulares, puede usar Cloud Backup. Cree una copia de seguridad de sus datos en el servidor de origen y luego restáurela en el servidor de destino.
Almacenamiento en bloque en la nube
Para migrar datos específicos, puede usar Cloud Block Storage. Conecte la unidad al servidor de origen y copie sus datos en él. Luego desconecte la unidad del servidor de origen, conéctela al servidor de destino y copie sus datos de la unidad.
Utilice rsync para la migración de directorios en Linux
En Linux, puede usar rsync para copiar un directorio a través de la red directamente. Por ejemplo, desde el servidor de origen puede ejecutar el siguiente comando para copiar /var/lib/mysql :
rsync -e 'ssh' -avl --stats --progress /var/lib/mysql [email protected]:/var/lib/mysql
Para más información sobre rsync , consulte Hacer una copia de seguridad de sus archivos con rsync.
Importante :siempre que los dos servidores en la nube estén en el mismo centro de datos regional (DFW, ORD, IAD, LON, HKG o SYD), puede utilizar 10.x Dirección IP asignada a los dos servidores para transferir cualquier dato. Esto significa que no se le cobrará por el ancho de banda de los datos entre los dos servidores. Todos los datos transferidos mediante direcciones IP públicas generarán posibles costos de ancho de banda.
Opciones específicas de la aplicación
Otras aplicaciones pueden tener sus propios medios para facilitar la migración de datos. Por ejemplo, para migrar una base de datos, puede hacer que el servidor de destino sea una réplica de la base de datos de origen para replicar automáticamente sus datos en el servidor de destino. Puede encontrar información sobre cómo realizar la replicación principal de MySQL® aquí.
Tareas posteriores a la migración
Una vez que todos sus datos estén en el servidor de destino, pruebe su aplicación minuciosamente para asegurarse de que funciona como se espera en el entorno de destino. Como se mencionó al comienzo de este artículo, recomendamos a los clientes que apaguen el servidor de origen pero que no lo eliminen durante uno a siete días. Esta práctica le da tiempo para determinar si se ha perdido algo en su migración. Por ejemplo, que se utilizó una dirección IP en lugar de DNS para resolver el servidor de origen. Si después de siete días, nada se ha roto y no ha notado ningún problema, debería ser seguro eliminar el servidor de origen.
Si aún no lo ha hecho, implemente un plan de copia de seguridad en el servidor de destino para evitar una pérdida significativa de datos en caso de una catástrofe.