VENTAS: 1-800-867-1389

Implementar el plan de migración de Azure

Actualizado: abril de 2014

Azure es una plataforma informática y de servicios en Internet hospedada en centros de datos de Microsoft. Con Azure, los desarrolladores y los administradores no necesitan implementar la infraestructura de software y hardware subyacente, ya que Microsoft se encarga del sistema operativo, el hardware, la red, los recursos de almacenamiento y las actualizaciones de la plataforma subyacentes automáticamente.

Se recomienda encarecidamente que después de migrar una aplicación a la nube ejecute las pruebas funcionales y de rendimiento en la aplicación como si se tratara de cualquier aplicación recién implementada. Puesto que Azure es diferente de su plataforma local, debe tener en cuenta los siguientes aspectos importantes al implementar la migración:

Tenga en cuenta que este tema se centra principalmente en los Servicios en la nube de Azure. Si desea instrucciones preliminares sobre la migración de SQL Server en Máquinas virtuales de Azure, vea Migrar con Máquinas virtuales de Windows Azure.

Autores: Kun Cheng, Steve Howard
Colaboradores: Selcin Turkarslan

Al migrar aplicaciones a la nube, debe saber cómo probar y depurar la aplicación para poder asegurarse de que en la nube funcionará de la manera esperada. A continuación se muestra una lista de enfoques que puede usar para probar la aplicación:

  • Azure Tools para Microsoft Visual Studio: puede compilar la aplicación y, después, ejecutarla y depurarla localmente mediante emuladores de proceso y de almacenamiento incluidos como parte de Azure Tools. Esto le permite desarrollar su aplicación localmente antes de publicarla en Azure. Azure Tools para Microsoft Visual Studio extiende Visual Studio 2010 y le permite probar la aplicación mediante emuladores de proceso y de almacenamiento que proporcionan la mayoría de las funciones de Azure. Se recomienda que realice este tipo de prueba en las etapas iniciales de las pruebas funcionales. Para obtener más información, vea Azure Tools para Microsoft Visual Studio.

  • SQL Server Data Tools: SQL Server Data Tools (SSDT) ofrece un entorno integrado dentro de Visual Studio 2010 que sirve para diseñar bases de datos, crear o editar objetos y datos de base de datos, o ejecutar consultas para todas las plataformas SQL admitidas, incluida Base de datos SQL de Azure remoto y Microsoft SQL Server 2012 local. Permite probar soluciones de proyecto de base de datos usando la base de datos predeterminada local o Base de datos SQL de Azure examinando la parte de acceso a datos relacionales de la aplicación. Para obtener más información, vea SQL Server Data Tools. Nota:: tanto Azure Tools para Microsoft Visual Studio como SSDT le permiten realizar las pruebas básicas de funcionalidad y compatibilidad en su aplicación con orígenes de datos sin conexión y en línea. Para probar todos los aspectos de una aplicación en la nube real en cuanto a funcionalidad, rendimiento y escalabilidad, necesita realizar una prueba de simulación en Azure donde se implementará y ejecutará la aplicación.

  • Marco de pruebas automatizadas: muchas aplicaciones existentes ya cuentan con un marco de pruebas automatizadas que se puede usar para asegurarse de que todos los componentes o las funciones de la aplicación funcionan de la manera esperada. Cuando una aplicación se ejecuta en Azure, puede que el marco de pruebas automatizadas funcione o no, según cómo esté diseñado. Si el marco de pruebas automatizadas debe ejecutarse localmente pero puede conectarse a una aplicación en Azure usando los extremos definidos, puede funcionar. De lo contrario, se recomienda que hospede en Azure tanto el marco de pruebas automatizadas como la aplicación para mitigar posibles problemas de latencia y pérdida de conexiones.

  • Prueba de carga de Visual Studio: si una aplicación no dispone de un marco de pruebas automatizadas, se recomienda crear uno nuevo y usar Prueba de carga de Visual Studio para realizar una prueba de simulación con varios usuarios simultáneos.

Entre las pruebas, el almacenamiento provisional y la producción, debe intentar minimizar el tiempo de implantación real en la medida de lo posible. Se puede tardar varias horas o varios días en copiar una base de datos grande local a Azure. Además, no es probable que desee que la aplicación esté inactiva todo el tiempo que se tarda en migrar totalmente los datos existentes. Por eso debe tener un plan para minimizar el tiempo improductivo debido al cambio de sistema. Tenga en cuenta que el cambio de sistema se refiere al tiempo necesario para realizar el traslado final a Azure. Antes del cambio de sistema, examine las tablas y decida cuáles contienen datos estadísticos y cuáles contienen datos que podrían cambiar durante el proceso de cambio de sistema. En el caso de datos estáticos, no es necesario mover ningún dato en el momento de la implantación final. Sin embargo, si hay alguna duda sobre si los datos de una tabla determinada pueden cambiar durante el proceso, debe incluir en el sistema lógica para migrar todos los cambios más adelante. También se recomienda examinar si es necesario migrar a la nube todos los datos de los sistemas locales antes que la aplicación esté activa en Azure. Si la aplicación puede estar activa y permite poner al día los datos más adelante, puede eliminar el tiempo improductivo.

Sin embargo, si los datos de Azure deben ser coherentes con los datos locales antes del funcionamiento en Azure, considere la posibilidad de minimizar la cantidad de datos que se deben migrar en el momento del cambio de sistema, ya que esto ayuda a minimizar el tiempo improductivo necesario para realizar el cambio de sistema real. En algunos casos, puede ser adecuado mover algunos datos antes del cambio y mover los datos restantes después del cambio real. En esos casos, el plan de migración debe identificar claramente los datos que hay que migrar primero y los datos restantes que se pueden migrar más adelante. Esto permite que la aplicación esté activa en Azure con menos tiempo improductivo, ya que puede estar en producción mientras migra los datos restantes. Puede emplear los siguientes métodos de sincronización de datos para realizar la migración de datos antes del cambio al nuevo sistema:

El servicio SQL Data Sync (Vista previa) de proporciona funciones de sincronización de datos para bases de datos de SQL: SQL Server y Base de datos SQL. El servicio tiene dos funciones principales en este momento:

  • La sincronización de datos entre bases de datos locales de SQL Server e instancias de de Base de datos SQL, que permite a las aplicaciones locales y basadas en la nube usar datos idénticos.

  • La sincronización de datos entre dos o más instancias de de Base de datos SQL; las instancias pueden estar en el mismo centro de datos, en centros de datos diferentes o en regiones distintas.

SQL Data Sync (Vista previa) de es una buena opción para sincronizar bases de datos locales e instancias de Base de datos SQL de en las situaciones siguientes:

  • Necesita realizar pruebas de aplicaciones en paralelo.

  • Necesita ejecutar su aplicación en paralelo antes del traslado final de todas las operaciones de datos locales a .

  • Durante la migración a , necesita ejecutar la aplicación de forma local y es necesario mantener un tiempo improductivo mínimo.

  • Necesita realizar una sincronización de datos continua como parte de una solución híbrida entre la aplicación local y de .

Tenga en cuenta que para hacer un seguimiento de los cambios de datos incrementales, cuando se configura el grupo de sincronización SQL Data Sync (Vista previa) agrega una tabla de seguimiento de cambios para cada tabla que se va a sincronizar. Cuando utilice SQL Data Sync (Vista previa), asegúrese de que los planes de espacio tienen en cuenta las tablas de seguimiento de cambios. Además, una vez configurada la sincronización no debe realizar cambios en las estructuras de tabla ni en las claves principales de las tablas que se van a sincronizar a menos que reinicialice el grupo de sincronización. SQL Data Sync (Vista previa) no es adecuado en aquellas situaciones en las que se necesite una sincronización de datos intermedia o continuada.

Advertencia: SQL Data Sync (Vista previa) solo está disponible actualmente como versión de vista previa y solo está pensado como origen de comentarios sobre el producto para las versiones futuras; no debe usarse en entornos de producción.

Para obtener más información acerca de SQL Data Sync (Vista previa), vea SQL Data Sync (Vista previa).

Puede usar replicación, creación de reflejo o trasvase de registros para mover datos de SQL Server local a otro SQL Server local o a una instancia de SQL Server que se ejecuta en una Máquina virtual de Azure. Sin embargo, no puede usarlos para mover datos hacia o desde Base de datos SQL de Azure. Para obtener más información, vea Trasvase de registros y replicación y Crear reflejo de la base de datos y trasvase de registros.

Con el fin de minimizar el tiempo necesario para transferir datos en la implantación final, debe mover antes todos los datos posibles a la plataforma Azure. Puede crear un trabajo ETL personalizado para mover los datos modificados del sistema local al entorno Azure. Al realizar la migración desde SQL Server 2008 o posterior local, se recomienda usar Captura de datos modificados o Seguimiento de los datos modificados para asegurarse de que todos los datos modificados, y solo ellos, se mueven realmente desde la base de datos local a la instancia de Base de datos SQL de Azure. Para obtener más información sobre estas dos características, vea Seguimiento de cambios de datos en los Libros en pantalla de SQL Server. En el caso de bases de datos que no usen Captura de datos modificados o Seguimiento de los datos modificados, es necesario crear un sistema de seguimiento de los datos y los datos que se han migrado. En todos los casos, la clave para minimizar el tiempo improductivo necesario para el cambio real es tener que mover la mínima cantidad de datos posibles en el momento de la implantación real.

Mediante DAC, puede exportar datos de una instancia de SQL Server y ponerlos en el almacenamiento de Blob de Azure, desde donde pueden importarse a una Base de datos SQL de Azure. Con DAC, puede configurar filtros sobre qué tablas se deben importar o exportar. Sin embargo, no puede configurar filtros de nivel de fila. Esta es la razón por la que conviene usar DAC cuando tablas enteras caben dentro de una sola base de datos, pero no funciona bien para bases de datos con escalado horizontal. DAC no es adecuado para migrar aplicaciones en las que se necesite una sincronización de datos continuada. Para obtener más información, vea Exportar una aplicación de capa de datos en los Libros en pantalla de SQL Server.

El propósito de crear copias de seguridad de una base de datos es permitir la recuperación ante pérdidas de datos debidas a errores administrativos, errores de la aplicación o la pérdida total de un centro de datos. La copia de seguridad y la restauración de datos es diferente en Base de datos SQL de Azure que en un servidor SQL Server local, y deben funcionar con los recursos y las herramientas disponibles. Por tanto, un uso confiable del proceso de copia de seguridad y restauración para la recuperación de datos requiere una estrategia de copia de seguridad y restauración de Base de datos SQL de Azure. Hay tres categorías generales de problemas de las que quizás haya que recuperar una instancia de Base de datos SQL de Azure:

  • Errores de infraestructura o de hardware: dentro de un centro de datos pueden producirse errores de hardware. Por ejemplo, el nodo físico que ejecuta la instancia de Base de datos SQL de Azure puede bloquearse.

  • Problemas o errores de aplicaciones o generados por los usuarios: los usuarios o las aplicaciones pueden realizar cambios no deseados en los datos. Por ello, puede ser necesaria una operación de reversión. Por ejemplo, un usuario podría modificar algunos datos que pertenezcan al cliente equivocado y otros.

  • Pérdida de las instalaciones de un centro de datos: el contrato de nivel de servicio actual de Base de datos SQL de Azure tiene una excepción para factores ajenos al control razonable de Microsoft, como desastres. En caso de que se produzca un desastre, el centro de datos puede resultar dañado de tal forma que las bases de datos no se puedan recuperar a partir de las réplicas o las copias de seguridad locales.

Necesita decidir en última instancia qué nivel de riesgo desea tolerar con respecto a los datos almacenados dentro de centros de datos de Base de datos SQL de Azure. Para obtener información detallada sobre las herramientas de copia de seguridad y restauración disponibles y cómo elaborar estrategias de recuperación ante desastres alrededor de ellas, vea el artículo Continuidad de negocio de Base de datos SQL de Azure en MSDN Library.

Cuando realice la migración real de la aplicación a Azure, puede tomar los siguientes enfoques:

  • Ejecución en paralelo: con este método, la aplicación se puede ejecutar en paralelo tanto de forma local como en Azure. Esto permite realizar pruebas en directo de la aplicación en Azure antes de que la aplicación sea totalmente dependiente de la nube. Las pruebas deben incluir lo siguiente, sin limitarse a ello: pruebas funcionales, pruebas de rendimiento y pruebas de escalabilidad. Una vez que termine de probar totalmente el nuevo sistema en Azure, realice la migración de datos final y cierre el sistema local.

  • Pausa y cambio definitivo: este método es adecuado cuando hay que sincronizar todos los datos antes de que la aplicación esté totalmente operativa en Azure. Con este método, todas las pruebas funcionales y de rendimiento se deben completar primero en Azure. Después, configure el sistema para replicar datos en el entorno de Azure mediante uno de los métodos de sincronización de datos especificados anteriormente. Se recomienda que mantenga los datos lo más sincronizados posible minimizando el período de tiempo necesario para la última sincronización o la última operación ETL antes del cambio definitivo. Cuando llegue el momento de cambiar a Azure, cierre el sistema local, realice la última sincronización de datos y active la aplicación en Azure.

Vea también

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft