Migración a App Service Environment v3 mediante la característica de migración en paralelo

Nota:

La característica de migración que se describe en este artículo se usa para la migración automatizada en paralelo (en una subred diferente) de la versión 2 de App Service Environment a la versión 3. Si no ha solicitado un período de gracia de 30 días, revise la información general del período de gracia y después solicite un período de gracia; para ello, vaya a Azure Portal y visite la hoja Migración para cada uno de los entornos de App Service.

Si busca información sobre la característica de migración local, consulte Migración a App Service Environment v3 mediante la característica de migración local. Si busca información sobre las opciones de migración manual, consulte Opciones de migración manual. Para obtener ayuda para decidir qué opción de migración es adecuada para usted, consulte Árbol de decisión ruta de migración. Para obtener más información sobre App Service Environment v3, consulte Introducción a App Service Environment v3.

La migración en paralelo incluye desafíos adicionales en comparación con la migración local. Para los clientes que necesitan decidir entre las dos opciones, la recomendación es usar la migración local, ya que hay menos pasos y menos complejidad. Si decide usar la migración en paralelo, revise la sección de orígenes comunes de problemas al migrar mediante la característica de migración en paralelo para evitar problemas comunes.

App Service puede automatizar la migración de un entorno de App Service Environment v1 y v2 a un entorno de App Service Environment v3. Hay diferentes opciones de migración. Revise el árbol de decisión de ruta de migración para decidir qué opción es mejor para su caso de uso. App Service Environment v3 proporciona ventajas y diferencias en las características con respecto a versiones anteriores. Asegúrese de revisar las características compatibles de App Service Environment v3 antes de migrar para reducir el riesgo de un problema inesperado en la aplicación.

La característica de migración en paralelo automatiza la migración a App Service Environment v3. La característica de migración en paralelo crea una instancia de App Service Environment v3 con todas las aplicaciones en una subred diferente. La instancia de App Service Environment existente no se elimina hasta que inicie su eliminación al final del proceso de migración. Esta opción de migración es mejor para los clientes que quieran migrar a App Service Environment v3 sin tiempo de inactividad y pueden admitir el uso de una subred diferente para su nuevo entorno. Si necesita usar la misma subred y puede admitir aproximadamente una hora de tiempo de inactividad de la aplicación, consulte la característica de migración local. Para obtener opciones de migración manual que le permiten migrar a su propio ritmo, consulte Opciones de migración manual.

Importante

Si no completa todos los pasos descritos en este tutorial, experimentará un tiempo de inactividad. Por ejemplo, si no actualiza todos los recursos dependientes con las nuevas direcciones IP o no permite el acceso a o desde la nueva subred, como el caso del almacén de claves de sufijo de dominio personalizado, experimentará tiempo de inactividad hasta que se solucione ese problema.

Se recomienda utilizar esta función primero para entornos de desarrollo antes de migrar cualquier entorno de producción para ensayar el proceso y garantizar que no haya problemas inesperados. Proporcione comentarios relacionados con este artículo o la característica mediante los botones que se encuentran en la parte inferior de la página.

Escenarios admitidos

En este momento, la característica de migración en paralelo no admite migraciones a App Service Environment v3 en las regiones siguientes:

Azure Public

• Centro de Emiratos Árabes Unidos

Azure Government

• US DoD (centro)
• US DoD (este)
• US Gov: Arizona
• US Gov Texas
• US Gov - Virginia

Microsoft Azure operado por 21Vianet

• Este de China 2
• Norte de China 2

Las siguientes configuraciones de App Service Environment se pueden migrar mediante la característica de migración en paralelo. En la tabla se proporciona la configuración de App Service Environment v3 al usar la característica de migración en paralelo en función de la instancia de App Service Environment existente.

Configuración	Configuración de App Service Environment v3
App Service Environment v2 de equilibrador de carga interno (ILB)	App Service Environment v3 de ILB
Externo (ELB/Internet con dirección IP pública) App Service Environment v2	App Service Environment v3 de ELB
App Service Environment v2 de ILB con un sufijo de dominio personalizado	App Service Environment v3 de ILB con un sufijo de dominio personalizado

App Service Environment v3 se puede implementar como redundante de zona. La redundancia de zona se puede habilitar siempre que App Service Environment v3 esté en una región que admita la redundancia de zona.

Si quiere que el nuevo entorno de App Service Environment v3 use un sufijo de dominio personalizado y no está usando uno actualmente, dicho sufijo de dominio personalizado se puede configurar en cualquier momento una vez se complete la migración. Para obtener más información, consulte Configuración del sufijo de dominio personalizado para App Service Environment. Si el entorno existente tiene un sufijo de dominio personalizado y ya no quiere usarlo, debe configurar un sufijo de dominio personalizado para la migración. Puede quitar el sufijo de dominio personalizado una vez completada la migración.

Limitaciones de la característica de migración en paralelo

A continuación se muestran algunas limitaciones cuando se usa la característica de migración en paralelo:

• La nueva instancia de App Service Environment v3 está en una subred diferente, pero en la misma red virtual que el entorno.
• No se puede cambiar la región en la que se encuentra App Service Environment.
• Los entornos de App Service Environment de ELB no se pueden migrar a App Service Environment v3 de ILB y viceversa.
• Si el entorno existente de App Service Environment usa un sufijo de dominio personalizado, debe configurar uno para el entorno de App Service Environment v3 durante el proceso de migración.
  • Si ya no quiere usar un sufijo de dominio personalizado, puede quitarlo una vez se complete la migración.
• La característica de migración en paralelo solo está disponible mediante la CLI o la API REST. La característica no está disponible en Azure Portal.

App Service Environment v3 no admite las características siguientes que es posible que use con la instancia actual de App Service Environment v2 o v2.

• Configuración de un enlace TLS/SSL basado en IP con las aplicaciones.
• App Service Environment v3 no vuelve a Azure DNS si los servidores DNS personalizados configurados de la red virtual no pueden resolver un nombre determinado. Si este comportamiento es necesario, asegúrese de que tiene un reenviador a un DNS público o de incluir Azure DNS en la lista de servidores DNS personalizados.

La característica de migración en paralelo no admite los siguientes escenarios. Consulte las opciones de migración manual si el entorno de App Service Environment se incluye en una de estas categoría.

• App Service Environment v1
  • Para encontrar la versión de App Service Environment, vaya al entorno de App Service Environment en Azure Portal y seleccione la opción Configuración en Configuración en el lado izquierdo. También puede usar Azure Resource Explorer y revisar el valor de la propiedad kind para su entorno de App Service Environment.
  • Si tiene una instancia de App Service Environment v1, puede migrar mediante la característica de migración local o una de las opciones de migración manual.
• App Service Environment v2 de ELB con direcciones SSL de IP
• App Service Environment v2 anclado a una zona
• App Service Environment con un nombre que no cumple los límites de caracteres. El nombre completo, incluido el sufijo de dominio, debe tener 64 caracteres o menos. Por ejemplo: my-ase-name.appserviceenvironment.net para ILB y my-ase-name.p.azurewebsites.net para ELB deben tener 64 caracteres o menos. Si no cumple el límite de caracteres, debe migrar manualmente. Los límites de caracteres específicos para el nombre de App Service Environment son los siguientes:
  • Límite de caracteres de nombre de App Service Environment de ILB: 36 caracteres
  • Límite de caracteres de nombre de App Service Environment de ELB: 42 caracteres

La plataforma App Service revisa la instancia de App Service Environment para confirmar la compatibilidad con la migración en paralelo. Si el escenario no pasa todas las comprobaciones de validación, no podrá migrar en este momento mediante la característica de migración en paralelo. Si el entorno está en un estado incorrecto o suspendido, no podrá migrar hasta que realice las actualizaciones necesarias.

Nota

App Service Environment v3 no admite SSL de IP. Si usa SSL de IP, deberá quitar todos los enlaces SSL de IP antes de migrar a App Service Environment v3. La característica de migración admitirá el entorno una vez que se quiten todos los enlaces SSL de IP.

Solución de problemas

Si App Service Environment no supera las comprobaciones de validación o intenta realizar un paso de migración en el orden incorrecto, verá uno de los siguientes mensajes de error:

Mensaje de error	Descripción	Recomendación
Solo se puede llamar a la migración en un ASE en una red virtual de ARM y si dicho ASE está en la red virtual clásica.	Las instancias de App Service Environment en redes virtuales clásicas no se pueden migrar mediante la característica de migración en paralelo.	Migrar mediante una de las opciones de migración manual.
La migración de ASEv3 aún no está lista.	La infraestructura subyacente no está lista para admitir App Service Environment v3.	Migre con una de las opciones de migración manual si desea migrar inmediatamente. De lo contrario, espere a que la característica de migración en paralelo esté disponible en su región.
No se puede habilitar la redundancia de zona para este ASE.	La región en la que se encuentra App Service Environment no admite redundancia de zona.	Si necesita habilitar la redundancia de zona, use una de las opciones de migración manual para migrar a una región que admita la redundancia de zona.
La migración no se puede realizar en este sufijo DNS personalizado ASE en este momento.	Se bloquea la migración del sufijo de dominio personalizado.	Abra un caso de soporte técnico para comunicarse con el soporte técnico para resolver el problema.
No se puede realizar la migración de ASE con redundancia de zona en este momento.	Se bloquea la migración de App Service Environment con redundancia de zona.	Abra un caso de soporte técnico para comunicarse con el soporte técnico para resolver el problema.
No se puede realizar la migración en ASEv2 anclado a una zona.	La instancia de App Service Environment v2 que está anclada por zona no se puede migrar mediante la característica de migración en paralelo en este momento.	Migre con una de las opciones de migración manual si desea migrar inmediatamente.
La operación de reversión de migración existente está en curso, inténtelo de nuevo más tarde.	Se revierte un intento de migración anterior.	Espere hasta que se complete la reversión en curso antes de intentar volver a iniciar la migración.
Properties.VirtualNetwork.Id debe contener el id. de recurso de subred.	El error aparece si intenta migrar sin proporcionar una nueva subred para la colocación de App Service Environment v3.	Asegúrese de seguir las instrucciones y completar el paso para identificar la subred que usará para App Service Environment v3.
No se puede pasar a <requested phase> desde la fase <previous phase> actual de la migración sin tiempo de inactividad.	Este error aparece si intenta realizar un paso de migración en el orden incorrecto.	Asegúrese de seguir los pasos de migración en orden.
Error al iniciar la operación de reversión en ASE en estado híbrido, inténtelo de nuevo más tarde.	Este error aparece si intenta revertir la migración, pero algo va mal. Este error no afecta ni a su entorno antiguo ni al nuevo.	Abra un caso de soporte técnico para comunicarse con el soporte técnico para resolver el problema.
Este ASE no se puede migrar sin tiempo de inactividad.	Este error aparece si intenta usar la característica de migración en paralelo en una instancia de App Service Environment v1.	La característica de migración en paralelo no admite App Service Environment v1. Migre mediante la característica de migración local o una de las opciones de migración manual.
La migración no está disponible para esta suscripción.	Tiene que contar con la ayuda del soporte técnico para migrar este entorno de App Service Environment.	Abra un caso de soporte técnico para comunicarse con el soporte técnico para resolver el problema.
No se puede realizar la migración con redundancia de zona, ya que las direcciones IP creadas durante la migración previa no son redundantes de zona.	Este error aparece si intenta realizar una migración con redundancia de zona, pero las direcciones IP generadas durante el paso de generación de IP no se crearon como redundantes de zona. La plataforma intenta hacer que todas las direcciones IP sean redundantes en la zona para garantizar la resistencia del back-end.	Abra un caso de soporte técnico para interactuar con el soporte técnico si necesita habilitar la redundancia de zona. Los ingenieros revertirán la migración y permitirán otro intento de crear las direcciones IP. Si no, puede migrar sin habilitar la redundancia de zona.
No se puede llamar a la migración si la opción SSL de IP está habilitada en alguno de los sitios.	Las instancias de App Service Environment que tienen sitios con la opción SSL de IP habilitada no se pueden migrar mediante la característica de migración en paralelo.	Quite el SSL de IP de todas las aplicaciones de App Service Environment para habilitar la característica de migración.
No se puede migrar dentro de la misma subred.	El error aparece si especifica la misma subred en la que se encuentra el entorno actual para la colocación de App Service Environment v3.	Debe especificar una subred diferente para App Service Environment v3. Si necesita usar la misma subred, migre mediante la característica de migración local.
La suscripción tiene demasiados entornos de App Service Environment. Quite algunos entornos antes de intentar crear más.	Se cumple la cuota de App Service Environment para la de suscripción.	Elimine entornos innecesarios o póngase en contacto con el soporte técnico para revisar las opciones.
No se puede llamar a la migración en este ASE hasta que finalice la actualización activa.	Las instancias de App Service Environment no se pueden migrar durante las actualizaciones de la plataforma. Puede establecer las preferencias de actualización en Azure Portal. Las actualizaciones tardan entre 8 y 12 horas o más en función del tamaño (número de instancias o núcleos) de App Service Environment.	Espere hasta que finalice la actualización y, a continuación, migre.
La operación de administración de App Service Environment está en curso.	App Service Environment está realizando una operación de administración. Entre estas operaciones se pueden incluir actividades como implementaciones o actualizaciones. La migración se bloquea hasta que se completan estas operaciones.	Puede migrar una vez completadas estas operaciones.
El InteralLoadBalancingMode no se admite actualmente.	Los entornos de App Service Environment que tienen InternalLoadBalancingMode establecido en determinados valores no se pueden migrar mediante la característica de migración en este momento. El equipo de Microsoft debe cambiar manualmente InternalLoadBalancingMode.	Abra un caso de soporte técnico para comunicarse con el soporte técnico para resolver el problema. Solicite una actualización a InternalLoadBalancingMode.
No se puede llamar a la migración completa antes de que se generen direcciones IP.	Este error aparece si intenta migrar antes de finalizar los pasos de premigración.	Asegúrese de completar todos los pasos previos a la migración antes de intentar migrar. Consulte la guía paso a paso para la migración.
No se puede llamar a la migración completa en ASE con el sufijo DNS personalizado establecido, pero sin una configuración de sufijo DNS personalizado de ASE V3 configurada.	El entorno de App Service Environment existente usa un sufijo de dominio personalizado. Debe configurar un sufijo de dominio personalizado para App Service Environment v3 durante el proceso de migración.	Configure un sufijo de dominio personalizado. Si ya no quiere usar un sufijo de dominio personalizado, puede quitarlo una vez se complete la migración.

Información general sobre el proceso de migración mediante la característica de migración en paralelo

La migración en paralelo consta de una serie de pasos que se deben seguir en orden. Aquí se indican los puntos clave para un subconjunto de los pasos. Es importante comprender lo que ocurre durante estos pasos y cómo se verán afectados el entorno y las aplicaciones. Después de revisar la información siguiente y cuando esté a punto para migrar, siga la guía paso a paso.

Comprobar que se admita la migración mediante la característica de migración en paralelo para el entorno de App Service Environment

La plataforma valida si el entorno de App Service Environment se puede migrar mediante la característica de migración en paralelo. Si el entorno de App Service Environment no supera todas las comprobaciones de validación, no se puede migrar en este momento mediante la característica de migración en paralelo. Consulte la sección solución de problemas para obtener más información sobre las posibles causas de error de validación. Si el entorno está en un estado incorrecto o suspendido, no podrá migrar hasta que realice las actualizaciones necesarias. Si no puede realizar la migración mediante la característica de migración en paralelo, consulte las opciones de migración manual.

La validación también comprueba si App Service Environment está en la compilación mínima necesaria para la migración. Esta compilación puede ser más reciente que la compilación estándar que se implementa con el ciclo de actualización y mantenimiento rutinarios de la plataforma. La compilación mínima se actualiza periódicamente para asegurarse de que hay disponibles las últimas correcciones de errores y mejoras. Si App Service Environment no está en la compilación mínima, debe iniciar la actualización usted mismo. Esta actualización es un proceso estándar en el que App Service Environment no se ve afectado, pero no puede escalar ni realizar cambios en app Service Environment mientras la actualización está en curso. No se puede migrar hasta que finalice la actualización. Las actualizaciones pueden tardar entre 8 y 12 horas en completarse o más en función del tamaño de su entorno. Si planea un período de tiempo específico para la migración, debe ejecutar la comprobación de validación 24-48 horas antes del tiempo de migración planeado para asegurarse de que tiene tiempo para una actualización si es necesario.

Selección y preparación de la subred para la nueva instancia de App Service Environment v3

La plataforma crea la nueva instancia de App Service Environment v3 en una subred diferente a la de App Service Environment existente. Debe seleccionar una subred que cumpla los siguientes requisitos:

• La subred debe estar en la misma red virtual y, por tanto, región, que la instancia de App Service Environment existente.
  • Si la red virtual no tiene una subred disponible, debe crear una. Es posible que tenga que aumentar el espacio de direcciones de la red virtual para crear una nueva subred. Para obtener más información, consulte Creación de una red virtual.
• La subred debe poder comunicarse en las dos direcciones con la subred en la que se encuentra la instancia de App Service Environment existente. Asegúrese de que no haya grupos de seguridad de red u otras configuraciones de red que impidan la comunicación entre las subredes.
• La subred debe tener una sola delegación de Microsoft.Web/hostingEnvironments.
• La subred debe tener suficientes direcciones IP disponibles para admitir la nueva instancia de App Service Environment v3. El número de direcciones IP necesarias depende del número de instancias que quiera usar para la nueva instancia de App Service Environment v3. Para obtener más información, vea Redes de App Service Environment v3.
• La subred no debe tener ningún bloqueo aplicado. Si hay bloqueos, deben quitarse antes de la migración. Los bloqueos se pueden volver a añadir si hace falta una vez completada la migración. Para más información sobre los bloqueos y la herencia de bloqueos, consulte Bloqueo de los recursos para proteger la infraestructura.
• No debe haber ninguna directiva de Azure que bloquee la migración ni las acciones relacionadas. Si hay directivas que bloquean la creación de instancias de App Service Environment o la modificación de subredes, deben quitarse antes de la migración. Las directivas se pueden leer si es necesario una vez completada la migración. Para más información sobre Azure Policy, consulte información general de Azure Policy.

Generación de direcciones IP salientes para la nueva instancia de App Service Environment v3

La plataforma crea las nuevas direcciones IP de salida. Mientras se crean estas IP, la actividad con el entorno de App Service Environment existente no se interrumpe, pero no podrá escalar ni realizar cambios en este entorno. Este proceso tarda unos 15 minutos en completarse.

Cuando haya finalizado, se crean las nuevas direcciones IP salientes que usará la futura instancia de App Service Environment v3. Estas nuevas IP no afectan de ninguna manera en el entorno existente.

Recibirá la nueva dirección IP de entrada una vez completada la migración, pero antes de realizar el cambio de DNS para redirigir el tráfico del cliente a la nueva instancia de App Service Environment v3. No obtiene la dirección IP de entrada en este momento del proceso porque hay dependencias en los recursos de App Service Environment v3 que se crean durante el paso de migración. Tiene la oportunidad de actualizar los recursos que dependen de la nueva dirección IP de entrada antes de redirigir el tráfico a la nueva instancia de App Service Environment v3.

Actualización de recursos dependientes con nuevas direcciones IP salientes

Las nuevas direcciones IP salientes se crean y se le proporcionan antes de iniciar la migración real. La nueva salida predeterminada a las direcciones públicas de Internet se ofrece para que pueda ajustar los firewalls externos, el enrutamiento DNS, los grupos de seguridad de red y cualquier otro recurso que dependa de estas direcciones IP antes de completar la migración. Es responsabilidad suya actualizar todos los recursos que se verán afectados por el cambio de dirección IP asociado al nuevo entorno de App Service Environment v3. No avance al paso siguiente hasta que haya realizado todas las actualizaciones necesarias. Es posible que experimente tiempo de inactividad durante y después del paso de migración si tiene dependencias en las direcciones IP de salida y no puede realizar todas las actualizaciones necesarias. Esto se debe a que, una vez iniciada la migración, aunque el tráfico siga dirigiéndose a sus front-ends de App Service Environment v2, el equipo informático subyacente es su nuevo App Service Environment v3 en la nueva subred.

Este paso también es un buen momento para revisar los cambios en las dependencias de red entrantes y salientes al pasar a App Service Environment v3, incluido el cambio de puerto para el sondeo de estado de Azure Load Balancer, que ahora usa el puerto 80.

Delegación de la subred de App Service Environment

En App Service Environment v3 es necesario que la subred en la que se encuentra tenga una sola delegación de Microsoft.Web/hostingEnvironments. La migración no se puede realizar correctamente si la subred de App Service Environment no está delegada o la delega en un recurso diferente. Asegúrese de que la subred que seleccione para la nueva instancia de App Service Environment v3 tenga una única delegación de Microsoft.Web/hostingEnvironments.

Confirmación de cambios de tamaño de instancia

Los planes de App Service se crean con la SKU Aislado v2 correspondiente como parte de la migración. Por ejemplo, los planes I2 corresponden a I2v2. Es posible que las aplicaciones se aprovisionen en exceso después de la migración, ya que el nivel Aislado v2 tiene más memoria y CPU por tamaño de instancia correspondiente. Tiene la oportunidad de escalar el entorno según sea necesario una vez completada la migración. Para obtener más información, revise los detalles de la SKU.

Asegúrese de que no haya bloqueos en los recursos

Los bloqueos de la red virtual bloquean las operaciones de la plataforma durante la migración. Si la red virtual tiene bloqueos, debe quitarlos antes de migrar. Los bloqueos se pueden volver a añadir si hace falta una vez completada la migración. Los bloqueos pueden existir en tres ámbitos diferentes: suscripción, grupo de recursos y recurso. Cuando se aplica un bloqueo en un ámbito primario, todos los recursos heredan el mismo bloqueo. Si tiene bloqueos aplicados en el ámbito de suscripción, grupo de recursos o recurso, debe quitarlos antes de llevar a cabo la migración. Para más información sobre los bloqueos y la herencia de bloqueos, consulte Bloqueo de los recursos para proteger la infraestructura.

Asegúrese de que no hay ninguna migración de bloqueo de directivas de Azure

Azure Policy se puede usar para denegar la creación y modificación de recursos a determinadas entidades de seguridad. Si tiene una directiva que bloquea la creación de entornos de App Service o la modificación de subredes, debe quitarla antes de migrar. La directiva se puede leer si es necesario una vez completada la migración. Para más información sobre Azure Policy, consulte información general de Azure Policy.

Agregar un sufijo de dominio personalizado (opcional)

Si el entorno de App Service Environment existente usa un sufijo de dominio personalizado, debe configurar un sufijo de dominio personalizado para el nuevo entorno de App Service Environment v3. El sufijo de dominio personalizado en App Service Environment v3 se implementa de forma diferente que en App Service Environment v2. Debe proporcionar el nombre de dominio personalizado, la identidad administrada y el certificado, que se deben almacenar en Azure Key Vault. Para obtener más información sobre App Service Environment sufijo de dominio personalizado v3, incluidos los requisitos, las instrucciones paso a paso y los procedimientos recomendados, consulte Configuración del sufijo de dominio personalizado para App Service Environment. Si el entorno de App Service Environment v2 tiene un sufijo de dominio personalizado, debe configurar un sufijo de dominio personalizado para el nuevo entorno aunque ya no quiera usarlo. Una vez se complete la migración, puede quitar la configuración del sufijo de dominio personalizado si es necesario.

Si la migración incluye un sufijo de dominio personalizado, en el caso de App Service Environment v3, el dominio personalizado no se muestra en la sección Essentials de la página Información general del portal, ya que es para App Service Environment v1 o v2. En lugar de esto, en el caso de App Service Environment v3, vaya a la página Sufijo de dominio personalizado, donde podrá confirmar que el sufijo de dominio personalizado está configurado correctamente. Además, en App Service Environment v2, si tiene un sufijo de dominio personalizado, el nombre de host predeterminado incluye el sufijo de dominio personalizado y tiene el formato APP-NAME.internal.contoso.com. En App Service Environment v3, el nombre de host predeterminado siempre usa el sufijo de dominio predeterminado y tiene el formato APP-NAME.ASE-NAME.appserviceenvironment.net. Esta diferencia se debe a que App Service Environment v3 mantiene el sufijo de dominio predeterminado al agregar un sufijo de dominio personalizado. Con App Service Environment v2, solo hay un sufijo de dominio único.

Migración a App Service Environment v3

Después de completar los pasos anteriores, debe continuar con la migración lo antes posible.

No hay tiempo de inactividad de la aplicación durante la migración, pero al igual que en el paso de generación de IP, no se puede escalar, modificar la instancia de App Service Environment existente ni implementar aplicaciones en él durante este proceso.

Importante

Dado que el escalado se bloquea durante la migración, debe escalar el entorno al tamaño deseado antes de iniciar la migración. Si tiene habilitado el escalado automático, y se produce un evento de escalado antes de que se inicie la migración, tendrá que esperar hasta que se complete el evento de escalado antes de iniciar la migración. Debe deshabilitar el escalado automático antes de iniciar la migración para evitar este problema. Si necesita escalar el entorno después de la migración, puede hacerlo una vez completada la migración.

Este paso también es donde decide si desea habilitar la redundancia de zona para la nueva instancia de App Service Environment v3. La redundancia de zona se puede habilitar siempre que App Service Environment v3 esté en una región que admita la redundancia de zona.

Para la migración en paralelo se necesita una ventana de servicio de tres a seis horas para las migraciones de instancias de App Service Environment v2 a v3. Durante la migración, se bloquean las configuraciones de escalado y entorno, y se producen los siguientes eventos:

• La nueva instancia de App Service Environment v3 se crea en la subred seleccionada.
• Los nuevos planes de App Service se crean en la nueva instancia de App Service Environment v3 con el nivel Aislado v2 correspondiente.
• Las aplicaciones se crean en la nueva instancia de App Service Environment v3.
• Los equipos o trabajadores subyacentes de sus aplicaciones se trasladan al nuevo App Service Environment v3, lo que significa que sus aplicaciones se ejecutan ahora en su App Service Environment v3. Sin embargo, sus front-ends de App Service Environment v2 siguen funcionando de manera predeterminada y sirviendo tráfico. Su antigua dirección IP de entrada sigue en uso, pero sus nuevas IP de salida están usándose. Además, los front-ends de su nuevo App Service Environment v3 están creados y listos para servir tráfico.
  • En el caso de los entornos de App Service Environment de ILB, los front-end de App Service Environment v3 no se usan hasta que actualice las zonas DNS privadas con la nueva dirección IP de entrada.
  • En el caso de las instancias de App Service Environment de ELB, el proceso de migración no redirecciona el tráfico a los servidores front-end de la versión 3 de App Service Environment  hasta completar el paso final de la migración.

Cuando se completa este paso, el tráfico de la aplicación seguirá dirigiéndose en los servidores front-end antiguos de la versión 2 de App Service Environment y en la IP de entrada que se le asignó. Sin embargo, sus aplicaciones se ejecutan en realidad en trabajos en su nuevo App Service Environment v3.

Nota:

Debido a un error conocido, es posible que los trabajos web no se inicien durante el paso de implementación híbrida. Si usa trabajos web, este error puede provocar problemas o tiempo de inactividad de la aplicación. Abra un caso de soporte técnico si tiene alguna pregunta o duda sobre este problema.

Obtener la dirección IP de entrada para la nueva instancia de App Service Environment v3 y actualizar los recursos dependientes

La nueva dirección IP de entrada se proporciona para que se puedan configurar nuevos puntos de conexión con servicios como Traffic Manager o Azure Front Door y actualizar cualquiera de las zonas DNS privadas. No avance al paso siguiente hasta que realice estos cambios. Hay tiempo de inactividad si no actualiza los recursos dependientes con la nueva dirección IP de entrada. Es responsabilidad suya actualizar todos los recursos que se vean afectados por el cambio de dirección IP asociado a la nueva instancia de App Service Environment v3. No avance al paso siguiente hasta que haya realizado todas las actualizaciones necesarias.

Redirigir el tráfico de cliente, validar la versión del entorno de App Service Environment v3 y completar la migración

El último paso consiste en redirigir el tráfico a los front-ends de su nuevo App Service Environment v3 y finalizar la migración. Antes de realizar este paso, debe revisar la nueva instancia de App Service Environment v3 y realizar las pruebas necesarias para validar que funciona según lo previsto. De forma predeterminada, el tráfico va a los servidores front-end de App Service Environment v2. Si usa un entorno de la versión 3 de App Service Environment de ILB, puede probar los servidores front-end de la versión 3 de App Service Environment, para lo que debe actualizar su zona DNS privada con la nueva dirección IP de entrada. Si usa una instancia de App Service Environment v3 de ELB, el proceso de prueba depende de la configuración de red específica. Un método sencillo para probar los entornos de ELB es actualizar el archivo de hosts para usar la nueva dirección IP de entrada de App Service Environment, versión 3. Si tiene dominios personalizados asignados a las aplicaciones individuales, también puede actualizar su DNS para que apunte a la nueva IP de entrada. Probar este cambio le permite validar completamente el entorno de App Service Environment v3 antes de iniciar el paso final de la migración, en el que se elimina el antiguo entorno de App Service Environment.

Una vez que esté listo para redirigir el tráfico, puede completar el paso final de la migración. Este paso actualiza los registros DNS internos o de plataforma para que apunten a la dirección IP del equilibrador de carga de su nuevo App Service Environment v3 y a los front-ends que se crearon durante la migración. Los cambios son efectivos en un par de minutos. Es su responsabilidad actualizar sus registros DNS para que apunten a la nueva dirección IP de entrada. Si tiene problemas o la aplicación está inactiva, establezca la configuración de caché y TTL. Este paso también cierra el entorno antiguo de App Service y lo elimina. La nueva instancia de App Service Environment v3 es ahora su entorno de producción.

Importante

La plataforma garantiza una experiencia de migración sin tiempo de inactividad. Sin embargo, la configuración de DNS puede provocar tiempo de inactividad durante el paso de cambio de DNS. Esto puede deberse a problemas relacionados con la configuración de TTL y caché, ya que el tráfico podría seguir dirigiéndose a su antiguo App Service Environment tras el cambio de DNS. Debe revisar la configuración de DNS y asegurarse de que tiene un TTL bajo y de que el proveedor de DNS admite la propagación rápida. Si tiene un TTL alto, podría experimentar tiempo de inactividad durante el paso de cambio de DNS.

Nota:

Es importante completar este paso lo antes posible. Cuando App Service Environment está en estado híbrido, no puede recibir actualizaciones de plataforma ni revisiones de seguridad, lo que hace que sea más vulnerable a la inestabilidad y a las amenazas de seguridad.

Tiene 14 días para completar este paso. Después de 14 días, la plataforma completará de manera automática la migración y eliminará el entorno anterior. Si necesita más tiempo, puede abrir un caso de soporte técnico para analizar las opciones.

Si detecta algún problema con la nueva instancia de App Service Environment v3, no ejecute el comando para redirigir el tráfico del cliente. Este comando también inicia la eliminación de App Service Environment v2. Si encuentra un problema, póngase en contacto con el soporte técnico.

Uso de la característica de migración en paralelo

Requisitos previos

Asegúrese de que comprende cómo afecta la migración a App Service Environment v3 a las aplicaciones. Revise el proceso de migración en su totalidad para comprender la escala de tiempo del proceso y dónde y cuándo debe implicarse. Revise también las preguntas más frecuentes, que pueden responder a algunas de sus preguntas.

Asegúrese de que no haya bloqueos en la red virtual, los grupos de recursos, los recursos o la suscripción. Los bloqueos bloquean las operaciones de plataforma durante la migración.

Asegúrese de que no haya directivas de Azure que bloqueen las acciones necesarias para la migración, incluidas las modificaciones de subred y las creaciones de recursos de Azure App Service. Las directivas que bloquean las modificaciones y las creaciones de recursos pueden provocar que la migración se bloquee o produzca un error.

Dado que App Service Environment v3 está en una subred diferente de la red virtual, debe asegurarse de que tiene una subred disponible en la red virtual que cumple los requisitos de subred de App Service Environment v3. La subred que seleccione también debe poder comunicarse con la subred en la que se encuentra la instancia de App Service Environment existente. Asegúrese de que no haya nada que bloquee la comunicación entre las dos subredes. Si no tiene una subred disponible, debe crear una antes de migrar. La creación de una nueva subred puede implicar aumentar el espacio de direcciones de la red virtual. Para obtener más información, consulte Creación de una red virtual y una subred.

Dado que el escalado se bloquea durante la migración, debe escalar el entorno al tamaño deseado antes de iniciar la migración. Si necesita escalar el entorno después de la migración, puede hacerlo una vez completada la migración. Si tiene habilitado el escalado automático, y se produce un evento de escalado antes de que se inicie la migración, esta se bloqueará hasta que se complete el evento de escalado. Debe deshabilitar el escalado automático antes de iniciar la migración para evitar este problema.

Siga los pasos que se describen aquí en orden y como se escriben, ya que está realizando llamadas a la API de REST de Azure. Se recomienda usar la CLI de Azure para realizar estas llamadas de API. Para obtener información acerca de otros métodos, consulte Referencia de API de REST de Azure.

Para esta guía, instale la CLI de Azure o use Azure Cloud Shell y utilice un shell de Bash.

Nota:

Se recomienda usar un shell de Bash para ejecutar los comandos proporcionados en esta guía. Es posible que los comandos no sean compatibles con las convenciones de PowerShell y los caracteres de escape.

Importante

Durante la migración, Azure Portal podría mostrar información incorrecta sobre App Service Environment y sus aplicaciones. No vaya a la experiencia de migración en Azure Portal, ya que la característica de migración en paralelo no está disponible allí. Se recomienda usar la CLI de Azure para comprobar el estado de la migración. Si tiene alguna pregunta sobre el estado de la migración o las aplicaciones, póngase en contacto con el soporte técnico.

1. Selección de la subred para la nueva instancia de App Service Environment v3

Seleccione una subred en App Service Environment v3 que cumpla los requisitos de subred de App Service Environment v3. Anote el nombre de la subred que seleccione. Esta subred debe ser diferente de la subred en la que se encuentra su instancia de App Service Environment existente.

2. Obtención del identificador de App Service Environment

Ejecute los comandos siguientes para obtener el identificador de App Service Environment y almacenarlo como una variable de entorno. Reemplace los marcadores de posición del nombre y los grupos de recursos por los valores de App Service Environment que quiera migrar. ASE_RG y VNET_RG son los mismos si la red virtual y App Service Environment están en el mismo grupo de recursos.

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

3. Validación de la compatibilidad de la migración

El comando siguiente comprueba si la instancia de App Service Environment es compatible con la migración. Este comando también valida que App Service Environment está en la versión de compilación admitida para la migración. Si App Service Environment no está en la versión de compilación admitido, debe iniciar la actualización usted mismo. Para obtener más información sobre la actualización de la migración previa, consulte Validación de que la migración se admite mediante la característica de migración en paralelo para App Service Environment.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

Si no hay errores, se admite la migración y puede continuar con el paso siguiente.

Si necesita iniciar una actualización para actualizar App Service Environment a la versión de compilación compatible, lo cual puede tardar entre 8 y 12 horas o más en función del tamaño del entorno, ejecute el siguiente comando. Ejecute este comando solo si produce un error en el paso de validación y se le indica que actualice App Service Environment.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

4. Generación de direcciones IP salientes para la nueva instancia de App Service Environment v3

Ejecute el comando siguiente para crear nuevas direcciones IP salientes. Este paso tarda unos 15 minutos en completarse. No modifique la escala ni realice cambios en la instancia existen de App Service Environment durante este tiempo.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01"

Ejecute el comando siguiente para comprobar el estado de este paso:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status

Si el paso está en curso, obtiene el estado Migrating. Una vez que obtenga el estado de Ready, ejecute el comando siguiente para ver las nuevas direcciones IP salientes. Si no ve las nuevas direcciones IP inmediatamente, espere unos minutos e inténtelo de nuevo.

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5. Actualización de recursos dependientes con nuevas direcciones IP salientes

Usando las nuevas IP de salida, actualice cualquiera de sus recursos o componentes de red para asegurarse de que su nuevo entorno funciona según lo previsto una vez iniciada la migración. Es responsable de realizar las actualizaciones necesarias. Las nuevas IP de salida se usan una vez que se crea el entorno de App Service v3 durante el paso de migración. Por ejemplo, si tiene un sufijo de dominio personalizado y Azure Key Vault y administra restricciones de acceso con un firewall, debe actualizar el firewall de Azure Key Vault para permitir solo las nuevas direcciones IP salientes o toda la nueva subred.

6. Delegación de la subred de App Service Environment

En App Service Environment v3 es necesario que la subred en la que se encuentra tenga una sola delegación de Microsoft.Web/hostingEnvironments. En las versiones anteriores no es necesaria esta delegación. Tiene que confirmar que la subred se ha delegado correctamente y actualizar la delegación (si es necesario) antes de migrar. Puede actualizar la delegación si ejecuta el comando siguiente o si va hasta la subred en Azure Portal.

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

7. Confirmación de que no haya bloqueos en la red virtual

Los bloqueos de la red virtual bloquean las operaciones de la plataforma durante la migración. Si la red virtual tiene bloqueos, debe quitarlos antes de migrar. Si es necesario, puede volver a agregar los bloqueos una vez completada la migración.

Use el siguiente comando para comprobar si la red virtual tiene bloqueos:

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Elimine los bloqueos existentes con el siguiente comando:

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Para ver los comandos relacionados para comprobar si la suscripción o el grupo de recursos tiene bloqueos, consulte la Referencia de la CLI de Azure para bloqueos.

8. Preparación de las configuraciones

Si el App Service Environment existente usa un sufijo de dominio personalizado, debe configurar uno para el nuevo recurso App Service Environment v3 durante el proceso de migración. Se produce un error en la migración si no configura un sufijo de dominio personalizado y usa uno actualmente. Para obtener más información sobre el sufijos de dominio personalizado de App Service Environment v3, incluidos los requisitos, las instrucciones paso a paso y los procedimientos recomendados, consulte Sufijo de dominio personalizado para App Service Environment.

Nota:

Si va a configurar un sufijo de dominio personalizado, al agregar los permisos de red en el almacén de claves de Azure, asegúrese de que el almacén de claves permite el acceso desde la nueva subred de App Service Environment v3. Si accede al almacén de claves mediante un punto de conexión privado, asegúrese de que ha configurado el acceso privado correctamente con la nueva subred. Si no puede establecer correctamente este acceso antes de la migración, experimentará un tiempo de inactividad.

Puede hacer que el nuevo App Service Environment zona v3 sea redundante si el entorno existente está en una región que admita la redundancia de zona. La redundancia de zona se puede configurar estableciendo la propiedad zoneRedundant en true. La redundancia de zona es una configuración opcional. Esta configuración solo se puede establecer durante la creación de la nueva App Service Environment v3 y no se puede quitar más adelante.

Para establecer estas configuraciones, incluida la identificación de la subred seleccionada anteriormente, cree un archivo denominado parameters.json con los detalles siguientes en función de su escenario. Asegúrese de usar la nueva subred seleccionada para la nueva instancia de App Service Environment v3. No incluya las propiedades para un sufijo de dominio personalizado si esta característica no se aplica a la migración. Preste atención al valor de la propiedad zoneRedundant y establézcalo según sus necesidades de resistencia.

Si va a migrar sin un sufijo de dominio personalizado, use este código:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

Si usa una identidad administrada asignada por el usuario para la configuración del sufijo de dominio personalizado, use este código:

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

Si usa una identidad administrada asignada por el sistema para la configuración del sufijo de dominio personalizado, use este código:

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

9. Migración manual a App Service Environment v3 y comprobación del estado

Una vez completados todos los pasos anteriores, puede iniciar la migración. Asegúrese de comprender las implicaciones de la migración.

Este paso tarda entre tres y seis horas en completarse. Durante ese tiempo, no hay tiempo de inactividad de la aplicación si ha seguido los pasos anteriores. El escalado, la implementación y las modificaciones en la instancia existente de App Service Environment se bloquean durante este paso.

Nota:

Debido a un error conocido, es posible que los trabajos web no se inicien durante el paso de implementación híbrida. Si usa trabajos web, este error puede provocar problemas o tiempo de inactividad de la aplicación. Abra un caso de soporte técnico si tiene alguna pregunta o duda sobre este problema.

Ejecute el siguiente comando para iniciar la migración:

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

Ejecute el siguiente comando para comprobar el estado de la migración:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Una vez que obtenga el estado MigrationPendingDnsChange, la migración habrá terminado y tendrá un recurso App Service Environment v3. Las aplicaciones ahora se ejecutan en el nuevo entorno y en el entorno anterior.

Ejecute el siguiente comando para obtener los detalles del nuevo entorno:

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Importante

Durante la migración, así como durante el paso MigrationPendingDnsChange, Azure Portal muestra información incorrecta sobre la aplicación Service Environment y sus aplicaciones. Use la CLI de Azure para comprobar el estado de la migración. Si tiene alguna pregunta sobre el estado de la migración o las aplicaciones, póngase en contacto con el soporte técnico.

Nota:

Si la migración incluye un sufijo de dominio personalizado, su configuración podría mostrarse como degradada una vez completada la migración debido a un error conocido. App Service Environment debería seguir funcionando con normalidad. El estado degradado se debería resolver automáticamente en un plazo de 6 a 8 horas. Si la configuración sigue degradada después de 8 horas o si el sufijo del dominio personalizado no funciona, póngase en contacto con el soporte técnico.

10. Obtenga las direcciones IP de entrada para la nueva instancia de App Service Environment v3 y actualice los recursos dependientes

En esta fase del proceso de migración tiene dos conjuntos de front-ends de App Service Environment y ambos conjuntos son capaces de servir tráfico de aplicaciones. Sus DNS no se han cambiado, por lo que, de manera predeterminada, el tráfico se envía a los front-ends del antiguo App Service Environment. Debe actualizar los recursos dependientes para usar la nueva dirección IP entrante para la nueva instancia de App Service Environment v3. Para instancias de App Service Environment orientadas internamente (ILB), debe actualizar las zonas DNS privadas para que apunten a la nueva dirección IP de entrada.

Para obtener la nueva dirección IP de entrada para la nueva instancia de App Service Environment v3, ejecute el siguiente comando que corresponde al tipo de equilibrador de carga de App Service Environment. Es responsable de realizar las actualizaciones necesarias.

Para entornos de App Service con ILB, ejecute el comando siguiente para obtener la dirección IP de entrada privada:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

Para entornos de App Service de ELB, ejecute el comando siguiente para obtener la dirección IP de entrada pública:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

Importante

Si la migración incluye un sufijo de dominio personalizado, el comportamiento de nombre de host predeterminado para App Service Environment v3 es diferente al de App Service Environment v2. En el caso de App Service Environment v3, el nombre de host predeterminado siempre usa el sufijo de dominio predeterminado y tiene el formato APP-NAME.ASE-NAME.appserviceenvironment.net. Revise todos los recursos dependientes, como App Gateway, que usan los nombres de host de las aplicaciones para asegurarse de que estén actualizados para tener en cuenta este comportamiento. Para más información sobre las diferencias de características de App Service Environment entre las distintas versiones, consulte Comparación de versiones de App Service Environment.

Redirigir el tráfico de cliente, validar la versión del entorno de App Service Environment v3 y completar la migración

Este paso es la oportunidad de probar y validar la nueva instancia de App Service Environment v3.

Importante

Tiene 14 días para completar este paso. Después de 14 días, la plataforma completará de manera automática la migración y eliminará el entorno anterior. Si necesita más tiempo, puede abrir un caso de soporte técnico para analizar las opciones.

Una vez que confirme que sus aplicaciones funcionan como se espera, puede finalizar la migración ejecutando el siguiente comando. Este comando también elimina el entorno anterior.

Si encuentra algún problema o decide en este momento que ya no desea continuar con la migración, póngase en contacto con el soporte técnico para analizar las opciones. No ejecute el comando de cambio de DNS, ya que ese comando completa la migración.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

Ejecute el comando siguiente para comprobar el estado de este paso:

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Durante este paso, obtendrá un estado de CompletingMigration. Cuando se obtiene un estado de MigrationCompleted, se realiza el paso de redirección del tráfico y se completa la migración.

Causas frecuentes de problemas al migrar mediante la característica de migración en paralelo

A continuación se muestran ejemplos de causas frecuentes de problemas que encuentran los clientes al migrar mediante la característica de migración en paralelo. Debe revisar estas áreas para asegurarse de que no experimenta tiempos de inactividad ni interrupciones del servicio durante el proceso de migración o después.

• Azure Key Vault debe permitir el tráfico desde las nuevas direcciones IP o subred de salida.
• Las dos subredes deben poder comunicarse entre sí en ambas direcciones. Normalmente, los clientes permiten el tráfico de la antigua a la nueva subred, pero se olvidan de permitir el tráfico de la nueva a la anterior.
• App Gateway debe actualizarse con las nuevas direcciones IP.
• Los registros DNS debe actualizarse con las nuevas direcciones IP.
• Si ha codificado las direcciones IP de forma codificada en las aplicaciones, debe actualizarlas con las nuevas direcciones IP.
• Las tablas de rutas deben actualizarse con todas las nuevas rutas.

Precios

La migración del entorno de App Service Environment no conlleva ningún costo. Sin embargo, se le facturará tanto por su App Service Environment v2 como por su nuevo App Service Environment v3 una vez que inicie el proceso de migración. Dejará de cobrársele por su antiguo App Service Environment v2 cuando finalice el último paso de la migración, en el que se eliminará el antiguo entorno. Debe completar la validación lo antes posible para evitar que se acumulan cargos excesivos. Para obtener más información sobre los precios de App Service Environment v3, vea los detalles sobre precios.

Al migrar al entorno de App Service Environment v3 de versiones anteriores, hay escenarios que debe tener en cuenta que pueden reducir el costo mensual. Considere reservas y planes de ahorro para reducir aún más los costos. Para obtener información sobre las oportunidades de ahorro de costos, consulte Oportunidades de ahorro de costos después de actualizar a App Service Environment v3.

Nota:

Debido a las diferencias entre los planes de tarifa de Aislado a Aislado v2, es posible que las aplicaciones se aprovisionen en exceso después de la migración, ya que el nivel Aislado v2 tiene más memoria y CPU por tamaño de instancia correspondiente. Tendrá la oportunidad de escalar el entorno según sea necesario una vez completada la migración. Para obtener más información, revise los detalles de la SKU.

Reducción vertical de los planes de App Service

Las SKU del plan de App Service disponibles para el entorno de App Service Environment v3 se ejecutan en el nivel Aislado v2 (Iv2). El número de núcleos y la cantidad de RAM se duplican eficazmente por nivel correspondiente en comparación con el nivel Aislado. Al migrar, los planes de App Service se convierten en el nivel correspondiente. Por ejemplo, las instancias de I2 se convierten en I2v2. Aunque I2 tiene dos núcleos y 7 GB de RAM, I2v2 tiene cuatro núcleos y 16 GB de RAM. Si espera que los requisitos de capacidad permanezcan iguales, está sobreaprovisionando y paga por proceso y memoria que no está usando. En este escenario, puede reducir verticalmente la instancia de I2v2 a I1v2 y terminar con un número similar de núcleos y RAM al que tenía anteriormente.

Preguntas más frecuentes

• ¿Qué ocurre si la migración de mi entorno de App Service Environment no es compatible actualmente?
  No puede realizar la migración en paralelo mediante la característica de migración en este momento. Si tiene un entorno no compatible y quiere migrar inmediatamente, consulte las opciones de migración manual.
• ¿Cómo puedo elegir qué opción de migración es adecuada para mí?
  Revise el árbol de decisión de ruta de migración para decidir qué opción es mejor para su caso de uso.
• ¿Cómo sé si debo usar la característica de migración en paralelo?
  La característica de migración en paralelo es mejor para los clientes que quieran migrar a App Service Environment v3, pero no pueden admitir el tiempo de inactividad de la aplicación. Dado que se usa una nueva subred para el nuevo entorno, hay consideraciones de red que se deben tener en cuenta, incluidas las nuevas direcciones IP. Si puede admitir el tiempo de inactividad, consulte la característica de migración local, lo que produce cambios mínimos de configuración, o las opciones de migración manual. La característica de migración local crea la instancia de App Service Environment v3 en la misma subred que el entorno existente y usa la misma infraestructura de red.
• ¿Experimentaré tiempo de inactividad durante la migración?
  La plataforma garantiza que no haya tiempo de inactividad durante el proceso de migración paralelo. Sin embargo, la configuración de DNS puede provocar tiempo de inactividad durante el paso de cambio de DNS. Esto puede deberse a problemas relacionados con la configuración de TTL y caché, ya que el tráfico podría seguir dirigiéndose a su antiguo App Service Environment tras el cambio de DNS. Debe revisar la configuración de DNS y asegurarse de que tiene un TTL bajo y de que el proveedor de DNS admite la propagación rápida.
• ¿Tendré que hacer algo con mis aplicaciones después de la migración para que se ejecuten en el entorno nuevo de App Service Environment?
  No, todas las aplicaciones que se ejecutan en el entorno anterior se migrarán automáticamente al nuevo entorno y se ejecutarán igual que antes. No se necesita ninguna entrada de usuario.
• ¿Qué ocurre si mi entorno de App Service Environment tiene un sufijo de dominio personalizado?
  La característica de migración en paralelo admite este escenario de migración.
• ¿Qué ocurre si mi entorno de App Service Environment está anclado a una zona?
  La característica de migración en paralelo no admite este escenario de migración en este momento. Si tiene una instancia de App Service Environment anclada por zona y quiere migrar inmediatamente, consulte las opciones de migración manual.
• ¿Qué ocurre si mi App Service Environment tiene direcciones SSL de IP?
  SSL de IP no se admite en App Service Environment v3. Es necesario quitar todos los enlaces SSL de IP antes de migrar mediante la característica de migración o una de las opciones manuales. Si piensa usar la característica de migración en paralelo, una vez que quite todos los enlaces SSL de IP, superará esa comprobación de validación y podrá continuar con la migración automatizada.
• ¿Qué propiedades de mi entorno de App Service Environment cambiarán?
  Está en un entorno de App Service Environment v3, por lo que debe asegurarse de revisar las características y diferencias en las características en comparación con las versiones anteriores. Las direcciones IP de entrada y salida cambian al usar la característica de migración en paralelo. Tenga en cuenta que, para App Service Environment de ELB, accesible desde Internet, anteriormente había una única IP tanto de entrada como de salida. En el caso de App Service Environment v3 estas son independientes. Para obtener más información, vea Redes de App Service Environment v3. Para obtener una comparación completa de las versiones de App Service Environment, consulte comparación de versiones de App Service Environment.
• ¿Qué ocurre si se produce un error en la migración o hay un problema inesperado durante esta?
  Si hay un problema inesperado, los equipos de soporte técnico estarán a su disposición. Se recomienda migrar entornos de desarrollo antes de tocar cualquier entorno de producción para obtener información sobre el proceso de migración y ver cómo afecta a las cargas de trabajo.
• ¿Qué ocurre con mi entorno antiguo de App Service Environment?
  Si decide migrar una instancia de App Service Environment mediante la característica de migración en paralelo, el entorno anterior se usará hasta el último paso del proceso de migración. Una vez completado el último paso, el entorno antiguo y todas las aplicaciones hospedadas en él se cerrarán y eliminarán. El entorno antiguo ya no es accesible. No se puede revertir al entorno antiguo en este momento.
• ¿Qué ocurrirá con mis recursos App Service Environment v1/v2 después del 31 de agosto de 2024?
  Después del 31 de agosto de 2024, si no migra a App Service Environment v3, sus App Service Environment v1/v2s y las aplicaciones implementadas en ellas ya no estarán disponibles. App Service Environment v1/v2 se hospeda en unidades de escalado de App Service que se ejecutan en una arquitectura de Cloud Services (clásica) que se retirará el 31 de agosto de 2024. Por este problema, App Service Environment v1/v2 ya no estará disponible después de esa fecha. Migre a App Service Environment v3 para mantener las aplicaciones en ejecución, o guarde o realice una copia de seguridad de los recursos o datos que necesite mantener.

Pasos siguientes

Redes de App Service Environment v3

Uso de un entorno de App Service Environment v3

Sufijo de dominio personalizado