VENTAS: 1-800-867-1389

Información general sobre el ciclo de vida de la migración de Azure

Actualizado: abril de 2014

El ciclo de vida de la migración es una metodología estándar que proporciona las instrucciones paso a paso para migrar aplicaciones y datos a . Los pasos principales de la migración son la Fase de análisis, Fase de migración de aplicaciones, Fase de migración de datos, Fase de pruebas y optimización, y Fase de operación y administración, como se muestra en el diagrama siguiente.

En este tema se explica detalladamente cada fase y se incluyen vínculos a información adicional.

también admite Oracle en Máquinas virtuales de . Para obtener más información, vea Imágenes de máquinas virtuales de Oracle para Azure.

Autores: Kun Cheng, Selcin Turkarslan, Norberto Garcia
Revisores: Paolo Salvatori, Steve Howard, Stuart Ozer

El objetivo de esta fase es entender las necesidades empresariales que requieren la solución de . Una vez identificados los objetivos empresariales, examine la arquitectura de las aplicaciones existente para identificar las principales diferencias entre las soluciones de y locales, y determine si necesita cambiar el diseño de la aplicación local existente para satisfacer las necesidades empresariales de una solución de . Las tareas y preguntas siguientes le ayudarán a crear un plan de migración:

  • Definir los requisitos empresariales: los escenarios empresariales pueden plantear muchas preguntas posibles cuando una aplicación se ejecuta en :

    • ¿La solución de implementación de está dirigida a nuevos clientes y usuarios?

    • ¿Necesitaría ser multiempresa para admitir varios clientes?

    • ¿Satisface la aplicación la normativa de cumplimiento cuando los datos se hospedan en los centros de datos de Microsoft en lugar de estar en sitios de los clientes?

    • ¿Qué aplicaciones son más indicadas para la nube desde el punto de vista arquitectónico y estratégico?

    • Qué tipo de migración es idónea para mi aplicación: migrar toda una aplicación y todas las dependencias a ; o migrar una parte de la aplicación a la nube y dejar algunos recursos de forma local; o migrar una aplicación a roles web o de trabajo con dependencias que funcionan mejor en una Máquina virtual de .

    Las respuestas a estas preguntas afectan al comportamiento de una aplicación en la plataforma para el que está diseñada.

  • Determinar las discrepancias entre características: ¿puede ejecutar la aplicación existente en sin realizar ningún cambio? Por ejemplo, Base de datos SQL de (Base de datos SQL) no admite todas las características que admite SQL Server local. Si desea mover una aplicación local que usa CLR (Common Language Runtime) a Base de datos SQL, necesita cambiar el diseño de la aplicación moviendo lógica de CLR de SQL Server al nivel de aplicación o volviendo a escribir la lógica de CLR mediante instrucciones Transact-SQL admitidas por Base de datos SQL. Tenga en cuenta que Base de datos SQL no admite actualmente CLR de SQL.

    A partir de la versión 2012, se han agregado nuevas capacidades de Máquina virtual a . Con Máquinas virtuales de , puede migrar aplicaciones existentes de SQL Server compiladas en la plataforma Windows Server a la plataforma con unos cambios mínimos en el código o incluso ningún cambio. Con SQL Server en Máquina virtual de , los administradores y desarrolladores pueden seguir usando las mismas herramientas de desarrollo y administración que usan de forma local. El rendimiento de una base de datos relacional en Máquina virtual depende de muchos factores, entre los cuales se incluye el tamaño de máquina virtual, el número y la configuración de los discos, la red, la configuración del software de base de datos y la carga de trabajo de la aplicación. Se recomienda que los desarrolladores realicen pruebas comparativas de su aplicación en varios tamaños de máquina virtual y con distintas configuraciones de almacenamiento para seleccionar la más adecuada. Para obtener más información, vea Migrar a SQL Server en una máquina virtual de Azure.

  • Preparar un plan para lograr rendimiento y escalabilidad: muchas aplicaciones heredadas se diseñaron para integrarse estrechamente entre la lógica de la aplicación y los componentes de acceso a datos. En el caso de aplicaciones heredadas, tiene sentido desacoplar componentes de la aplicación para mejorar su funcionamiento y escalado en . Si la aplicación es demasiado locuaz o realiza excesivas consultas de datos, use el Servicio Caching de Azure o implemente su propio mecanismo de almacenamiento en memoria caché para crear lotes de consultas de acceso a datos y reducir los viajes de ida y vuelta entre la aplicación y los datos. Si la aplicación que se va a migrar tratan con bases de datos grandes o con grandes volúmenes de transacciones, es probable que la migración a Base de datos SQL necesite un cambio de diseño del modelo de base de datos. Esto se debe a que una única instancia de Base de datos SQL puede controlar un número limitado de transacciones por segundo y tener un tamaño de base de datos limitado. Cuando tenga bases de datos grandes o un volumen elevado de transacciones, considere la posibilidad de implementar una arquitectura de escalado horizontal que use varias bases de datos en Base de datos SQL o empiece a usar métodos de escalado horizontal en lugar de costosos sistemas locales de escalado vertical. La implementación de OLTP en memoria o la durabilidad diferida para las tablas que tienen volúmenes de transacciones elevados debe considerarse también una forma de mejorar el rendimiento. Para obtener más información sobre OLTP en memoria, vea OLTP en memoria (optimización en memoria). Para obtener más información sobre la durabilidad diferida, vea Cómo controlar la durabilidad de las transacciones.

    Para obtener más información sobre las consideraciones de rendimiento cuando se usa SQL Server en una máquina virtual, vea Consideraciones de rendimiento para SQL Server en Máquinas virtuales de Azure y las notas del producto Guía de rendimiento para SQL Server en Máquinas virtuales de Azure.

    Base de datos SQL de ha publicado una versión de vista previa Premium limitada de Base de datos SQL. Al reservar una cantidad fija de capacidad para Base de datos SQL y sus réplicas secundarias, el servicio Premium ofrecerá un rendimiento más predecible para las aplicaciones en la nube, en relación con las ediciones existentes de Base de datos SQL Web y Business . Para obtener más información sobre las cuentas Premium de Base de datos SQL, vea Administrar una base de datos Premium y Instrucciones sobre la vista previa Premium de Base de datos SQL.

  • Preparar un plan para la administración del ciclo de vida de la aplicación: es importante tener en cuenta los escenarios de control de versiones y actualización de aplicaciones en . Según cómo sea su Contrato de nivel de servicio, quizás tenga que mantener varias versiones de la aplicación para atender a los distintos niveles de clientes. Puede que también desee minimizar el tiempo improductivo mientras actualiza una aplicación en . Se recomienda que realice un mantenimiento exhaustivo del entorno de ensayo y del entorno de producción en . Asegúrese de que puede revertir actualizaciones en caso de que surjan problemas de compatibilidad. El plan de reversión de actualizaciones debe cubrir en primer lugar la aplicación y, después, la base de datos.

Después de esta fase, se recomienda que elabore un proyecto piloto, ya que esto ofrece una visión clara de los servicios y las herramientas de la plataforma .

Una vez que decida migrar la aplicación a , empiece con una versión piloto de la aplicación con datos mínimos para elaborar una prueba de concepto. En primer lugar, implemente los cambios de código necesarios en la aplicación para satisfacer los objetivos de implementación de en cuanto a requisitos empresariales y técnicos. Después, compile e implemente el código de la aplicación en los roles apropiados de .

En general, la mayoría de las aplicaciones locales existentes pueden ejecutarse en los Servicios en la nube de con unos cambios mínimos o sin ningún cambio, pero esto puede crear varios problemas de rendimiento, escalabilidad y seguridad. Para optimizar el rendimiento y permitir la escalabilidad futura, se recomienda volver a diseñar la aplicación usando varios roles antes de migrar a los Servicios en la nube de . Para obtener más información, vea Consideraciones sobre el desarrollo para los Servicios en la nube de Azure. Es conveniente que mueva primero toda la aplicación a los Servicios en la nube de y que mueva después los datos. Debido a motivos de seguridad, rendimiento o de otro tipo, puede que algunas partes de la aplicación necesiten estar activas de forma local. Esto puede hacer necesario el uso de soluciones híbridas. Para obtener más información, vea Compilación de soluciones híbridas con Azure.

Si decide usar SQL Server en una Máquina virtual (VM) de , modifique las aplicaciones existentes de SQL Server para conectarse a la base de datos de SQL Server en la Máquina virtual de . Además, siga uno de estos enfoques de migración:

  • Quizás ya tenga una aplicación funcionando en una máquina virtual existente. Puede migrar esta máquina virtual a . En este caso, la aplicación, sus valores de configuración y sus datos ya están en esta máquina virtual. Pero quizás sea necesario cargar un archivo .vhd grande en . Además, puede haber algunos controladores y dependencias de hardware en esta máquina virtual existente que no estén disponibles en .

  • Puede crear una máquina virtual en . Para ello, pude iniciar una máquina virtual desde la Galería de imágenes, que ya contiene SQL Server. A continuación, instale la aplicación en esta máquina virtual. Esto reduce el tiempo de carga y quita las dependencias de controladores y de hardware, pero requiere la instalación de datos de la aplicación y de carga.

Para obtener más información sobre cómo migrar las bases de datos de SQL Server existentes a un servidor SQL Server en Máquina virtual de , vea el tema Migrar a SQL Server en una máquina virtual de Azure.

Si usa Servicios en la nube de , mueva los datos relacionales de SQL Server local a Base de datos SQL y mueva los datos no estructurados al almacenamiento de como Blob, Tabla o Unidades de . Para obtener más información, vea Migrar datos a Tablas y Blobs de Windows Azure y Migrar bases de datos de SQL Server a Base de datos SQL de Azure.

Si decide usar SQL Server en Máquinas virtuales de , puede seguir uno de estos dos métodos de migración:

  • Quizás tenga datos en una máquina virtual existente. Puede cargar esta máquina virtual existente en un archivo .vhd en .

  • Puede crear una máquina virtual en . Después, puede cargar datos en un archivo .vhd en . A continuación, puede adjuntar este archivo .vhd cargado o un disco vacío a la máquina virtual como un disco de datos. Puede usar los discos de datos para almacenar los registros y los archivos de datos de SQL Server. Además, puede usar las herramientas y las técnicas que se describen en el tema Migrar a SQL Server en una máquina virtual de Azure para migrar las bases de datos existentes de SQL Server a SQL Server en una máquina virtual de .

Después de migrar la aplicación y los datos a , realice pruebas funcionales y de rendimiento. En esta fase, pruebe la aplicación en la nube y confirme que funciona de la manera esperada. Después, compare los resultados de rendimiento entre la instalación local y . A continuación, resuelva cualquier problema de características, funcionalidad, rendimiento o escalabilidad de la aplicación en la nube. Para obtener más información, vea Implementar el plan de migración de Azure.

Después de la fase de pruebas y optimización, configure e implemente la supervisión y el seguimiento de la aplicación con Diagnósticos de . Diagnósticos de le permite recopilar datos de diagnóstico de una aplicación que se ejecuta en . Puede usar los datos de diagnósticos para depuración y solución de problemas, medida del rendimiento, supervisión del uso de recursos, análisis del tráfico y planeación de la capacidad, y auditoría. Para obtener más información, vea Diagnósticos y depuración de Azure en MSDN Library.

Si necesita sincronizar datos entre la instalación local y Base de datos SQL o entre distintos servidores de Base de datos SQL, instale y configure el servicio SQL Data Sync (Vista previa). Además, se recomienda que instale y configure un plan de recuperación de datos por si se producen errores de usuario o desastres naturales. Para obtener más información, vea Consideraciones sobre alta disponibilidad y recuperación ante desastres con Base de datos SQL de Azure.

Vea también

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