Migración a routers y balanceadores de cargas NGINX

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X.
Información

Durante agosto y septiembre de 2015, migraremos nuestros Cloud Routers y balanceadores de cargas de Apigee Edge a NGINX (que se pronuncia “Motor X”). NGINX, un servidor web de código abierto, proporciona un rendimiento incluso mejor y una simultaneidad más alta que nuestros balanceadores de cargas y routers existentes.

Qué significa esto para nuestros clientes de la nube

La conclusión es que este cambio debe ser transparente para ti y no requiere ninguna acción de tu parte que no sea verificar que los sistemas funcionan como se espera. A continuación, se describen los pasos que seguiremos, junto con las respuestas a algunas preguntas frecuentes.

Paso 1: Actualización de software

Actualizaremos todos los routers al nuevo router basado en NGINX y aprovecharemos nuestro modelo de implementación por fases para garantizar que los servicios no se vean afectados como resultado de esta actividad.

Paso 2: Quita el nivel de balanceador de cargas en los entornos que no son de producción

Comenzaremos el proceso de quitar el nivel de balanceador de cargas existente en los entornos que no son de producción con el nuevo router NGINX que controla la funcionalidad del balanceo de cargas. Los balanceadores de cargas de producción permanecerán intactos y sin cambios durante este paso. Antes de quitar los balanceadores de cargas existentes, adoptaremos un enfoque exhaustivo para garantizar que el tráfico funcione según lo esperado. No es necesario que realices ninguna acción para completar este paso. Sin embargo, debes informar cualquier problema a Apigee, y trabajaremos contigo para resolverlos antes de continuar con el paso 3.

Paso 3: Quita el nivel de balanceador de cargas en los entornos de producción

Una vez que se complete el paso 2 de forma correcta, determinaremos un conjunto de períodos de mantenimiento para quitar el nivel de balanceador de cargas en los entornos de producción mediante el mismo enfoque mencionado en el Paso 2 a fin de garantizar que el tráfico de la API del entorno de ejecución siga funcionando como se espera.

Cambios en la funcionalidad del producto

Estos son algunos cambios en la funcionalidad del producto con el cambio a NGINX.

Funciones obsoletas

Las siguientes propiedades ya no se admiten en ProxyEndpoints:

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

Para evitar esta baja, consulte el siguiente artículo de la comunidad: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html.

Preguntas frecuentes

A continuación, se proporcionan las respuestas a algunas preguntas frecuentes sobre la migración a NGINX.

¿Esto podría cambiar las IP públicas? Algunos de nuestros comercios permiten específicamente el acceso desde direcciones IP conocidas y cuando cambian las interrupciones del flujo de tráfico de los comercios.
Durante el paso 1, la respuesta es “No”, ya que no modificaremos los balanceadores de cargas existentes, lo cual no cambiará directamente ninguna de las IP que entregan tráfico. Sin embargo, debido a la naturaleza del servicio de balanceo de cargas de Amazon Web Services (AWS), se aplican reglas de escalamiento normales, lo que significa que las IP pueden cambiar como parte de su lógica de escalamiento (funcionalidad existente). Por este motivo, no recomendamos implementar los parámetros de configuración de la lista de entidades permitidas del norte con el paquete de productos de Apigee Edge. Durante los pasos 2 y 3, la eliminación del balanceador de cargas y sus direcciones IP asociadas conlleva consecuencias en la lista de entidades permitidas. Por lo tanto, coordinaremos estrechamente contigo durante estos pasos para garantizar una transición sin problemas y proporcionaremos un nuevo conjunto de direcciones IP para las cuales permitir el acceso.
¿Afectará esto las restricciones de IP que implementamos en nuestros servidores de origen?
No se requieren cambios, siempre que los servidores de origen sean los de extremos de destino (servidores que se llaman desde el paquete de proxy). Este cambio se realiza en el lado norte de Apigee o en el punto de entrada a Apigee.
¿Nuestro CNAME existente requerirá cambios?
No. Las entradas de CNAME existentes seguirán funcionando según lo esperado.
La migración de certificados SSL puede ser complicada. ¿Cómo vas a abordar esto?
Si usas SSL, el paso inicial no afectará la configuración de SSL existente. Sin embargo, tendremos que coordinar estrechamente contigo para asegurarnos de que SSL esté configurado correctamente en el router nuevo antes de continuar con los pasos 2 y 3.
¿Qué sucede si mi app o cliente no admite SNI?
Los pasos 2 y 3 se retrasarán hasta que se confirme la compatibilidad con SNI.
¿Habrá tiempo de inactividad?
No prevemos que haya tiempo de inactividad. Los cambios se implementarán con el modelo de implementación estándar durante los períodos de actualización existentes.