Compartir a través de

Migración de una instancia de API Management insertada en la red virtual hospedada en la plataforma stv1 a stv2

  • Artículo

SE APLICA A: Desarrollador | Premium

En este artículo se proporcionan pasos para migrar una instancia de API Management hospedada en la plataforma de proceso stv1 en contexto a la plataforma de stv2 cuando se inserta (implementa) la instancia en una externa o red virtual interna. Averigüe si necesita hacerlo.

Nota:

Novedad de agosto de 2024: para ayudarle a migrar la instancia insertada en la red virtual, hemos mejorado las opciones de migración en el portal. Ahora puede migrar la instancia local y mantener la misma subred y dirección IP.

Para una instancia de inserción de red virtual, tiene las siguientes opciones de migración:

  • Opción 1: mantenga la misma subred: migre la instancia en contexto y mantenga la configuración de subred existente de las instancias. Puede elegir si se conserva (recomendado) la dirección VIP original de la instancia de API Management o si se generará una nueva dirección VIP.

  • Opción 2: cambie a una nueva subred: migre la instancia especificando una subred diferente en la misma red virtual o en otra. Después de la migración, opcionalmente, vuelva a migrar a la subred original de la instancia. El proceso de migración cambia las direcciones VIP de la instancia. Después de la migración, debe actualizar las dependencias de red, como DNS, reglas de firewall y redes virtuales para usar las nuevas direcciones VIP.

Si necesita migrar una instancia de API Management no insertada con red virtual hospedada en la stv1 plataforma, consulte Migración de una instancia de API Management no insertada con red virtual a la plataforma stv2.

Importante

Se está retirando la compatibilidad con las instancias de API Management hospedadas en la plataforma stv1. En Azure global, la fecha de retirada es el 31 de agosto de 2024. En Azure Government y en Azure operado por 21Vianet (Azure en China), la fecha de retirada es el 24 de febrero de 2025. Si tiene instancias hospedadas en la plataforma stv1, mígrelas a la plataforma stv2 antes de la fecha de retirada para evitar interrupciones del servicio.

Precaución

  • La migración de la instancia de API Management a una stv2 plataforma es una operación de larga duración.
  • La migración a stv2 no es reversible.

¿Qué ocurre durante la migración?

La migración de la plataforma de API Management desde stv1 a stv2 implica actualizar solo el proceso subyacente y no tiene ningún impacto en la configuración del servicio o api persistente en la capa de almacenamiento.

  • El proceso de actualización implica la creación de un nuevo proceso en paralelo al proceso anterior, que puede tardar hasta 45 minutos. Planee tiempos más largos para implementaciones de varias regiones y en escenarios que implican cambiar la subred más de una vez.
  • El estado de API Management en el Azure Portal será Actualizado.
  • Para determinadas opciones de migración, puede optar por conservar la dirección VIP o se generará una nueva VIP pública.
  • Para escenarios de migración cuando se genera una nueva dirección VIP:
    • Azure administra la migración.
    • El DNS de puerta de enlace sigue apuntando al proceso anterior si se usa un dominio personalizado.
    • Si el DNS personalizado no está en uso, el DNS de puerta de enlace y de portal apunta al nuevo proceso inmediatamente.
    • En el caso de una instancia en modo de red virtual interna, el cliente administra el DNS, por lo que las entradas DNS continúan apuntando al proceso antiguo hasta que el cliente lo actualice.
    • Es el DNS que apunta al proceso nuevo o antiguo y, por tanto, no hay tiempo de inactividad de las API.
    • Los cambios son necesarios para las reglas de firewall, si los hay, para permitir que la nueva subred de proceso llegue a los back-end.
    • Después de una migración correcta, el proceso anterior se retira automáticamente después de un breve período. Al cambiar a una nueva subred utilizando la hoja de migración de la plataforma en el portal, puede activar una configuración de migración para conservar la antigua puerta de enlace durante 48 horas. La opción de retraso de 48 horas solo está disponible para los servicios insertados en la red virtual.

Requisitos previos

Otros requisitos previos son específicos de las opciones de migración en las secciones siguientes.

Opción 1: Migrar y mantener la misma subred

Puede migrar la instancia de API Management a la plataforma stv2 manteniendo la configuración de subred existente, lo que simplifica la migración. Puede migrar utilizando la hoja de migración de la plataforma en Azure Portal o la API de REST Migrate to Stv2.

Requisitos previos

  • Se debe asociar un grupo de seguridad de red a cada subred y se deben configurar las reglas NSG para la API Management en la plataforma stv2. A continuación se muestran las opciones de conectividad mínimas:

    • Salida a Azure Storage a través del puerto 443
    • Salida a Azure SQL a través del puerto 1433
    • Salida a Azure Key Vault a través del puerto 443
    • Entrada desde Azure Load Balancer a través del puerto 6390
    • Entrada desde la etiqueta de servicio ApiManagement a través del puerto 3443
    • Entrada a través del puerto 80/443 para clientes que llaman al servicio API Management
    • La subred debe tener habilitados los puntos de conexión de servicio para Azure Storage, Azure SQL y Azure Key Vault.

  • El espacio de direcciones de cada subred existente debe ser lo suficientemente grande como para hospedar una copia del servicio existente en paralelo con el servicio existente durante la migración.

  • Otras consideraciones de red:

    • Desactive las reglas de escalado automático configuradas para las instancias de API Management implementadas en la subred. Las reglas de escalado automático pueden interferir con el proceso de migración.
    • Si tiene varias instancias de API Management en la misma subred, migre cada instancia en secuencia. Se recomienda migrar rápidamente todas las instancias de la subred para evitar posibles problemas con las instancias hospedadas en distintas plataformas de la misma subred.

Opciones de dirección IP pública: migración de la misma subred

Puede elegir si se conserva (recomendado) la dirección VIP original de la instancia de API Management o si se generará una nueva dirección VIP.

  • Conservar la dirección IP virtual: si conserva la dirección VIP en una red virtual en modo externo, las solicitudes de API pueden seguir respondiendo durante la migración (consulte tiempo de inactividad esperado); para una red virtual en modo interno, se espera un tiempo de inactividad temporal. La configuración de infraestructura (como dominios personalizados, ubicaciones y certificados de CA) se bloqueará durante 45 minutos. No se requiere ninguna otra configuración después de la migración.

    Con esta opción, el proceso de stv1 se elimina permanentemente una vez completada la migración. No hay ninguna opción para conservarla temporalmente.

    La siguiente imagen muestra un resumen de alto nivel de lo que ocurre cuando se conserva la dirección IP.

    Diagrama de la migración local a la misma subred y conservación de la dirección IP.

  • Nueva dirección IP virtual: si elige esta opción, API Management genera una nueva dirección VIP para la instancia. Sin embargo, las solicitudes de API siguen respondiendo durante la migración. La configuración de infraestructura (como dominios personalizados, ubicaciones y certificados de CA) se bloqueará durante 30 minutos. Después de la migración, deberá actualizar las dependencias de red, como DNS, reglas de firewall y redes virtuales para usar la nueva dirección IP virtual.

    Con esta opción, el proceso stv1 se mantiene durante un breve periodo de tiempo por defecto una vez finalizada la migración para que pueda validar la instancia migrada y confirmar la configuración de red y DNS.

    La siguiente imagen muestra un resumen de alto nivel de lo que ocurre cuando se genera una nueva dirección IP.

    Diagrama de migración local a la misma subred y generación de una nueva dirección IP.

Dirección IP precreada para la migración

En el caso de las instancias de API Management a las que se puede acceder mediante una dirección IP pública, API Management crea previamente una dirección IP pública para el proceso de migración. Busque la dirección IP precreada en la salida JSON de las propiedades de la instancia de API Management. En customProperties, la dirección IP precreada es el valor de la propiedad Microsoft.WindowsAzure.ApiManagement.Stv2MigrationPreCreatedIps. Para una implementación de varias regiones, el valor es una lista separada por comas de direcciones IP precreadas.

Use la dirección IP precreada (o direcciones) para ayudarle a administrar el proceso de migración:

  • Al migrar y conservar la dirección VIP, la dirección IP precreada se asigna temporalmente a la nueva implementación de stv2, antes de asignar la dirección IP original a la implementación de stv2. Si tiene reglas de firewall que limitan el acceso a la instancia de API Management, por ejemplo, puede agregar la dirección IP precreada a la lista de permitidos para conservar la continuidad del acceso de cliente durante la migración. Una vez completada la migración, puede quitar la dirección IP precreada de la lista de permitidos.
  • Al migrar y generar una nueva dirección VIP, la dirección IP precreada se asigna a la nueva implementación de stv2 durante la migración y se conserva una vez completada la migración. Use la dirección IP precreada para actualizar las dependencias de red, como DNS y reglas de firewall, para apuntar a la nueva dirección IP.

Tiempo de inactividad esperado y retención de proceso

Al migrar una instancia insertada con red virtual y mantener la misma configuración de subred, se espera un tiempo de inactividad mínimo o ningún tiempo de inactividad para la puerta de enlace de API. En la tabla siguiente se resumen el tiempo de inactividad esperado y la retención de proceso stv1 para cada escenario de migración al mantener la misma subred:

Modo de red virtual Opción de dirección IP pública Tiempo de inactividad esperado Retención de proceso stv1
Externos Conservar VIP Sin tiempo de inactividad; el tráfico se sirve en una dirección IP temporal durante un máximo de 20 minutos durante la migración a la nueva implementación de stv2 Sin retención
Externos Nueva VIP sin tiempo de inactividad Se conserva de forma predeterminada durante 15 minutos para permitirle actualizar las dependencias de red.
Interno Conservar VIP Tiempo de inactividad durante aproximadamente 20 minutos durante la migración mientras la dirección IP existente se asigna a la nueva implementación de stv2. Sin retención
Interno Nueva VIP sin tiempo de inactividad Se conserva de forma predeterminada durante 15 minutos para permitirle actualizar las dependencias de red; se puede extender a 48 horas cuando se usa el portal

Pasos de migración: mantener la misma subred

  1. Vaya a la instancia de API Management en Azure Portal.
  2. En el menú izquierdo, en Configuración, seleccione Migración de plataforma.
  3. En Seleccionar una opción de migración, seleccione Mantener la misma subred.
  4. En Elegir una opción de dirección IP, seleccione una de las dos opciones de dirección IP.

    Nota:

    Si su red virtual está en modo externo, tome nota de la dirección IP pública creada previamente para el proceso de migración. Use esta dirección para configurar la conectividad de red para la instancia migrada.

  5. (Para instancias inyectadas en modo interno y que migran a una nueva VIP) En Elija el escenario que se alinee con sus requisitos, elija una de las dos opciones, dependiendo de si desea mantener el proceso original stv1 durante un periodo tras la migración.
  6. Seleccione Comprobar para ejecutar comprobaciones automatizadas en la subred. Si se detectan problemas, ajuste la configuración de la subred y vuelva a ejecutar comprobaciones. Para otras dependencias de red, como DNS y reglas de firewall, compruebe manualmente.
  7. Confirme que desea migrar y seleccione Iniciar migración. El estado de la instancia de API Management cambia a Actualizando. El proceso de migración tarda aproximadamente 45 minutos en completarse. Cuando el estado cambia a En línea, se completa la migración.

Opción 2: Migración y cambio a una nueva subred

Con Azure Portal, puede migrar la instancia especificando una subred diferente en la misma red virtual o en otra. Después de la migración, opcionalmente, vuelva a migrar a la subred original de la instancia.

En la imagen siguiente se muestra información general de alto nivel sobre lo que sucede durante la migración en paralelo.

Diagrama de migración local a una nueva subred.

Requisitos previos

  • Una nueva subred de la red virtual actual, en cada región donde se implementa la instancia de API Management. (Como alternativa, configure una subred en una red virtual diferente en las mismas regiones y suscripción que la instancia de API Management). Se debe asociar un grupo de seguridad de red a cada subred y se deben configurar las reglas NSG para la API Management en la plataforma stv2.

  • (Opcional) Un nuevo recurso de dirección IPv4 pública SKU Estándar en las mismas regiones y suscripción que su instancia de API Management. Para más información, consulte Requisitos previos para las conexiones de red.

Importante

  • A partir de mayo de 2024, un recurso de dirección IP pública ya no es necesario al implementar (insertar) una instancia de API Management en una red virtual en modo interno o migrar la configuración de red virtual interna a una nueva subred. En el modo de red virtual externa, especificar una dirección IP pública es opcional; si no proporciona una, se configura automáticamente una dirección IP pública administrada por Azure y se usa para el tráfico de API en tiempo de ejecución. Proporcione solo la dirección IP pública si desea poseer y controlar la dirección IP pública que se usa para la comunicación entrante o saliente a Internet.
  • Actualmente, si habilita la redundancia de zona para una instancia de API Management en una red virtual en modo interno o en modo externo, debe especificar una nueva dirección IP pública.

Pasos de migración: cambio a una nueva subred

  1. Vaya a la instancia de API Management en Azure Portal.

  2. En el menú izquierdo, en Configuración, seleccione Migración de plataforma.

  3. En Seleccionar una opción de migración, seleccione Cambiar a una nueva subred.

  4. En Elija el escenario que se alinee con sus requisitos, elija una de las dos opciones, dependiendo de si desea mantener el proceso original stv1 durante un tiempo después de la migración.

    Captura de pantalla de las opciones para conservar el proceso de stv1 en el portal.

  5. En Definir la configuración de migración para cada ubicación:

    1. Seleccione una ubicación para migrar.
    2. Seleccione la Red virtual, Subred y, opcionalmente, la Dirección IP pública a la que quiere migrar.

    Captura de pantalla de la selección de la configuración de migración de red en el portal.

  6. En Comprobar que la subred cumple los requisitos de migración, seleccione Comprobar para ejecutar comprobaciones automatizadas en la subred. Si se detectan problemas, ajuste la configuración de la subred y vuelva a ejecutar comprobaciones. Para otras dependencias de red, como DNS y reglas de firewall, compruebe manualmente.

  7. Confirme que desea migrar y seleccione Migrar. El estado de la instancia de API Management cambia a Actualizando. El proceso de migración tarda aproximadamente 45 minutos en completarse. Cuando el estado cambia a En línea, se completa la migración.

Si la instancia de API Management se implementa en varias regiones, repita los pasos anteriores para continuar con la migración de la configuración de red virtual para las ubicaciones restantes de la instancia.

(Opcional) Migración a la subred original

Si ha migrado y cambiado a una nueva subred, opcionalmente vuelva a migrar a la subred original que usó en cada región. Para ello, vuelva a actualizar la configuración de la red virtual, esta vez especificando la red virtual y la subred originales en cada región. Como en la migración anterior, espere una operación de larga duración y espere que la dirección VIP cambie.

En la imagen siguiente se muestra información general de alto nivel sobre lo que sucede durante la migración en paralelo.

Diagrama de la migración local a la subred original.

Importante

Si la red virtual y la subred están bloqueadas (ya que otras stv1 instancias de API Management basadas en la plataforma se implementan allí) o el grupo de recursos donde se implementa la red virtual original tiene un bloqueo de recursos, asegúrese de quitar el bloqueo antes de volver a migrar a la subred original. Espere a que se complete la eliminación del bloqueo antes de intentar la migración a la subred original. Más información.

Requisitos previos adicionales

  • Subred original desbloqueada, en cada región donde se implementa la instancia de API Management. Se debe asociar un grupo de seguridad de red a la subred y se deben configurar reglas de grupo de seguridad de red para API Management.

  • (Opcional) Un nuevo recurso de dirección IPv4 pública SKU Estándar en las mismas regiones y suscripción que su instancia de API Management.

    Importante

    • A partir de mayo de 2024, un recurso de dirección IP pública ya no es necesario al implementar (insertar) una instancia de API Management en una red virtual en modo interno o migrar la configuración de red virtual interna a una nueva subred. En el modo de red virtual externa, especificar una dirección IP pública es opcional; si no proporciona una, se configura automáticamente una dirección IP pública administrada por Azure y se usa para el tráfico de API en tiempo de ejecución. Proporcione solo la dirección IP pública si desea poseer y controlar la dirección IP pública que se usa para la comunicación entrante o saliente a Internet.
    • Actualmente, si habilita la redundancia de zona para una instancia de API Management en una red virtual en modo interno o en modo externo, debe especificar una nueva dirección IP pública.

Actualización de la configuración de red virtual

  1. En el portal, vaya a la red virtual original.
  2. En el menú de la izquierda, seleccione Subredes y, a continuación, la subred original.
  3. Compruebe que API Management publicó las direcciones IP originales. En Direcciones IP disponibles, anote el número de direcciones IP disponibles en la subred. Todas las direcciones (excepto las direcciones reservadas de Azure) deben estar disponibles. Si es necesario, espere a que se libere la dirección IP.
  4. Navegue hasta su instancia de API Management.
  5. En el menú izquierdo, en Red, seleccione Red virtual.
  6. Seleccione la conexión de red en la ubicación que quiera actualizar.
  7. Seleccione la red y la subred originales de la red virtual. Opcionalmente, seleccione una nueva dirección IP pública. Seleccione Aplicar.
  8. Si la instancia de API Management se implementa en varias regiones, siga configurando la configuración de red virtual para las ubicaciones restantes de la instancia.
  9. En la barra de navegación superior, seleccione Guardar.

Después de actualizar la configuración de la red virtual, el estado de la instancia de API Management cambia a Actualización . El proceso de migración tarda aproximadamente 45 minutos en completarse. Cuando el estado cambia a En línea, se completa la migración.

Comprobación de la migración

Para comprobar que la migración se realizó correctamente, cuando el estado cambie a En línea, compruebe la versión de la plataforma de la instancia de API Management. Después de una migración correcta, el valor es stv2 o stv2.1.

Confirmación de la configuración antes de purgar la puerta de enlace anterior

En escenarios en los que la puerta de enlace antigua se conserva temporalmente después de la migración, el proceso antiguo y el nuevo creado durante la migración coexisten durante un breve período de tiempo, aproximadamente 15 minutos, que puede usar para validar la implementación y que las aplicaciones funcionan según lo previsto. En determinados escenarios, opcionalmente puede extender el período de retención a 48 horas a través de una configuración del portal.

  • Durante esta ventana, las puertas de enlace antiguas y nuevas son tanto en línea como en servicio del tráfico. No se le factura durante este tiempo.
  • Use esta ventana para actualizar las dependencias de red, como DNS, reglas de firewall y redes virtuales, para usar la nueva dirección VIP y el espacio de direcciones de subred.
  • Además, compruebe el estado de red de la instancia actualizada para garantizar la conectividad de la instancia a sus dependencias. En el portal, en el menú izquierdo, en Implementación e infraestructura, seleccione Red>Estado de red. Si es necesario, actualice la configuración, como las reglas UDR y NSG.
  • Después de la ventana, se retira la puerta de enlace antigua y la nueva puerta de enlace es la única que atiende el tráfico.

Reversión automática si se produce un error en la migración

Si se produce un error durante el proceso de migración, la instancia revertirá automáticamente a la plataforma stv1. Si la migración se completa correctamente (la versión de la plataforma de la instancia se muestra como stv2 o stv2.1 y el estado como En línea), no se puede revertir a la stv1 plataforma.

Para obtener ayuda si se produce un error en la migración, póngase en contacto con Soporte técnico de Azure.

Si necesita la capacidad de revertir manualmente, la recomendación es implementar una nueva stv2 instancia en paralelo con la instancia original de API Management.

Ayuda y soporte técnico

Estamos aquí para ayudarle a migrar a la stv2 plataforma con interrupciones mínimas en los servicios.

Si tiene alguna pregunta, obtenga respuestas de expertos de la comunidad en Microsoft Q&A. Si tiene un plan de soporte técnico y necesita ayuda técnica, cree una solicitud de soporte técnico.

  1. En Resumen, escriba una descripción del problema, por ejemplo, "retirada de stv1".
  2. En Tipo de problema, seleccione Técnico.
  3. En Suscripción, seleccione la suscripción.
  4. En Servicio, seleccione Mis servicios y, a continuación, seleccione Servicio API Management.
  5. En Recurso, seleccione el recurso de Azure para el que va a crear una solicitud de soporte técnico.
  6. En Tipo de problema, seleccione Administración y supervisión.
  7. En Subtipo de problema, seleccione Actualizar, escalar o cambios de SKU.

Preguntas más frecuentes

  • ¿Qué información necesitamos para elegir una ruta de migración?

    • ¿Cuál es el modo de red de la instancia de API Management?
    • ¿Están configurados los dominios personalizados?
    • ¿Está implicado un firewall?
    • ¿Hay dependencias conocidas tomadas por ascendentes o descendentes en las direcciones IP implicadas?
    • ¿Es una implementación de varias regiones?
    • ¿Se puede modificar la instancia existente o se requiere una configuración paralela?
    • ¿Puede haber tiempo de inactividad?
    • ¿Se puede realizar la migración en horas no comerciales?

  • ¿Cuáles son los requisitos previos para la migración?

    Para las instancias insertadas en la red virtual, consulte los requisitos previos para las opciones para migrar y mantener la misma subred o para migrar y cambiar a una nueva subred.

  • ¿La migración provocará tiempo de inactividad?

    Al migrar una instancia insertada con red virtual y mantener la misma configuración de subred, se espera un tiempo de inactividad mínimo o ningún tiempo de inactividad para la puerta de enlace de API. Consulte la tabla de resumen en tiempo de inactividad esperado.

    Al migrar y cambiar a una nueva dirección VIP, no debería haber ningún tiempo de inactividad si los nombres de host predeterminados están en uso. Es fundamental que todas las dependencias de red se ocupen por adelantado de las API afectadas para que sean funcionales. Sin embargo, si los dominios personalizados están en uso, apuntarán al proceso purgado hasta que se actualicen, lo que puede provocar un tiempo de inactividad. Como alternativa, para determinadas opciones de migración, habilite una configuración de migración para conservar la puerta de enlace antigua durante 48 horas. Hacer que el proceso antiguo y el nuevo coexistan facilitará la validación y, luego, podrá actualizar las entradas DNS personalizadas a voluntad.

  • Mi tráfico está forzado a tunelizar a través de un firewall. ¿Qué cambios son necesarios?

    • En primer lugar, asegúrese de que las subredes que use para la migración conserven la siguiente configuración (ya deben estar configuradas si va a migrar y mantener la subred actual):
      • Habilitación de puntos de conexión de servicio como se describe aquí
      • La UDR (ruta definida por el usuario) tiene el salto de la etiqueta del servicio ApiManagement establecida en "Internet" y no solo en la dirección del firewall.
    • Los requisitos de configuración de NSG para stv2 siguen siendo los mismos tanto si tiene firewall como si no; asegúrese de que la nueva subred la tenga.
    • Las reglas de firewall que hacen referencia al intervalo de direcciones IP actual de la instancia de API Management deben actualizarse para usar el intervalo de direcciones IP de la nueva subred.

  • ¿Puede que se produzcan pérdidas de datos o de configuración durante la migración?

    stv1 para la migración de stv2 implica actualizar la plataforma de proceso solo y no se cambia la capa de almacenamiento interna. Por lo tanto, toda la configuración es segura durante el proceso de migración. Esto incluye la identidad administrada asignada por el sistema, que si está habilitada, se conserva.

  • Cómo confirmar que la migración se ha completado y realizado correctamente

    La migración se considerará finalizada y con éxito cuando el estado en la página Información general sea En línea y la versión de la plataforma sea stv2 o stv2.1. Compruebe también que el estado de la red en la hoja Red muestra el color verde para toda la conectividad necesaria.

  • ¿Puedo realizar la migración mediante el portal?

    Sí, las instancias insertadas en red virtual se pueden migrar mediante la hoja Migración de plataforma.

  • ¿Puedo conservar la dirección IP de la instancia?

    Sí, la hoja Migración de plataforma en el portal y la API de REST tienen opciones para conservar la dirección IP.

  • ¿Hay una ruta de migración sin modificar la instancia existente?

    Sí, necesita una migración en paralelo. Esto significa crear una nueva instancia de API Management en paralelo con la instancia actual y copiar la configuración en la nueva instancia.

  • ¿Qué ocurre si la migración falla?

    Si la instancia de API Management no muestra la versión de la plataforma como stv2 o stv2.1 y el estado como En línea después de iniciar la migración, es probable que se produzca un error. El servicio se revierte automáticamente a la instancia anterior y no se realizan cambios.

  • ¿Qué funcionalidad no está disponible durante la migración?

    Sin embargo, las solicitudes de API siguen respondiendo durante la migración. La configuración de infraestructura (como dominios personalizados, ubicaciones y certificados de CA) se bloquea durante 30 minutos.

  • ¿Cuánto tiempo durará la migración?

    La duración esperada de una migración a una nueva configuración de red virtual es de aproximadamente 45 minutos. El indicador para comprobar si la migración ya se ha realizado es comprobar si el estado de la instancia vuelve a En línea y no a Actualizando. Planee tiempos más largos para implementaciones de varias regiones y en escenarios que implican cambiar la subred más de una vez.

  • ¿Hay alguna manera de validar la configuración de la red virtual antes de intentar la migración?

    Si planea cambiar la subred durante la migración, puede implementar una nueva instancia de API Management con el recurso de dirección IP de red virtual, subred y (opcional) que usará para la migración real. Vaya a la página Estado de red una vez completada la implementación y compruebe si cada estado de conectividad del punto de conexión es verde. Si es así, puede quitar esta nueva instancia de API Management y continuar con la migración real con el servicio hospedado stv1 original.

  • ¿Puedo revertir la migración si es necesario?

    Si se produce un error durante el proceso de migración, la instancia se revertirá automáticamente a la plataforma stv1. Sin embargo, después de que el servicio se migre correctamente, no se puede revertir a la stv1 plataforma.

  • ¿Se requiere algún cambio en las zonas DNS privadas o de dominio personalizados?

    Con las instancias insertadas con red virtual en modo interno y cambiando a una nueva VIP, deberá actualizar las zonas DNS privadas a la nueva dirección IP de red virtual adquirida después de la migración. Preste atención a la actualización de zonas DNS que no son de Azure (por ejemplo, los servidores DNS locales que apuntan a la dirección IP privada de API Management). Sin embargo, en modo externo, el proceso de migración actualizará automáticamente los dominios predeterminados si están en uso.

  • Mi instancia de stv1 se implementa en varias regiones de Azure (varias regiones). ¿Cómo puedo actualizar a stv2?

    Las implementaciones en varias regiones incluyen más puertas de enlace administradas implementadas en otras ubicaciones. Al migrar mediante la hoja Migración de plataforma en el portal, se migra cada ubicación por separado. La API de REST Migrar a Stv2 migra todas las ubicaciones en una sola llamada. La instancia se considera migrada a la nueva plataforma solo cuando se migran todas las ubicaciones. Todas puertas de enlace siguen funcionando normalmente a lo largo del proceso de migración.

  • ¿Puedo actualizar mi instancia de stv1 a la misma subred?

    Sí, use la hoja de Migración de plataforma en el portal, o use la API de REST Migrar a stv2.

  • ¿Puedo probar la nueva puerta de enlace en una nueva subred antes de cambiar el tráfico activo?

    • Cuando se migra a una nueva subred, de forma predeterminada las puertas de enlace administradas antigua y nueva coexisten durante 15 minutos, que es una pequeña ventana de tiempo para validar la implementación. Puede habilitar una configuración de migración para conservar la puerta de enlace antigua durante 48 horas. Este cambio mantiene activas las puertas de enlace administradas antiguas y nuevas para recibir tráfico y facilitar la validación.
    • El proceso de migración actualiza automáticamente los nombres de dominio predeterminados y, si se usa, el tráfico se enruta inmediatamente a las nuevas puertas de enlace.
    • Si los nombres de dominio personalizados están en uso, es posible que deban actualizarse los registros DNS correspondientes con la nueva dirección IP si no se usa CNAME. Los clientes pueden actualizar su archivo de hosts a la nueva dirección IP de API Management y validar la instancia antes de realizar el cambio. Durante este proceso de validación, la puerta de enlace antigua sigue sirviendo el tráfico activo.

  • ¿Hay alguna consideración al usar el nombre de dominio predeterminado en una nueva subred?

    Las instancias que usan el nombre DNS predeterminado en modo externo tienen el DNS actualizado automáticamente por el proceso de migración. Además, el proceso de migración actualiza automáticamente el punto de conexión de administración, que siempre usa el nombre de dominio predeterminado. Dado que el conmutador se produce inmediatamente en una migración correcta, la nueva instancia comienza a recibir tráfico inmediatamente y es fundamental que las restricciones o dependencias de red se ocupen de antemano para evitar que las API afectadas no estén disponibles.

  • ¿Qué debemos tener en cuenta para las puertas de enlace auto hospedadas?

    No es necesario hacer nada en las puertas de enlace autohospedadas. Solo tiene que migrar las instancias de API Management que se ejecutan en Azure que se ven afectadas por la retirada de la plataforma stv1. Tenga en cuenta que podría haber una nueva dirección IP para el punto de conexión de configuración de la instancia de API Management y se deben actualizar las restricciones de red ancladas a la dirección IP.

  • ¿Cómo se ve afectado el portal para desarrolladores por la migración?

    No hay ningún impacto en el portal para desarrolladores. Si se usan dominios personalizados, el registro DNS debe actualizarse con la dirección IP efectiva, después de la migración. Sin embargo, si los dominios predeterminados están en uso, se actualizan automáticamente en la migración correcta. No hay tiempo de inactividad para el portal para desarrolladores durante la migración.

  • ¿Hay algún impacto en el costo una vez que migramos a stv2?

    El modelo de facturación sigue siendo el mismo para stv2 y no se incurrirá en ningún costo más después de la migración.

  • ¿Qué permisos de RBAC son necesarios para la migración de stv1 a stv2?

    El usuario o proceso que realiza la migración necesitaría acceso de escritura a la instancia de API Management. Además, se requieren los dos permisos siguientes:

    • Microsoft.Network/virtualNetworks/subnets/join/action
    • Microsoft.Network/publicIPAddresses/join/action

Contenido relacionado