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.
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.
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.
No. Las entradas de CNAME existentes seguirán funcionando según lo esperado.
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.
Los pasos 2 y 3 se retrasarán hasta que se confirme la compatibilidad con SNI.
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.