19.03.01: Notas de la versión de Apigee Edge para nube pública

Balanceo de cargas: Más control para quitar los servidores con fallas

Cuando configuras un balanceador de cargas para un proxy de API, puedes determinar cuántas fallas de respuesta deben ocurrir antes de que se quite un servidor de la rotación del balanceo de cargas. Una falla en la respuesta significa que Apigee no recibe ninguna respuesta de un servidor de destino. Cuando esto sucede, el contador de fallas aumenta en uno. Cuando Apigee recibe una respuesta de un objetivo, incluso si la respuesta es un error de HTTP (como el 500), se cuenta como una respuesta del servidor de destino y se restablece el contador de fallas. Para garantizar que las respuestas HTTP incorrectas (como el 500) también aumenten el contador de fallas para quitar un servidor en mal estado de la rotación del balanceo de cargas lo antes posible, puedes agregar un nuevo elemento <ServerUnhealthyResponse> con elementos secundarios <ResponseCode> a la configuración del balanceador de cargas. Edge también registrará las respuestas con esos códigos como errores.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

Mejoras en la política de AccessControl

La política de AccessControl determina qué direcciones IP pueden realizar llamadas a un proxy de API. Un elemento nuevo en esa política les brinda a los desarrolladores de API más control para identificar qué direcciones IP evaluar.

<IgnoreTrueClientIPHeader>: Opcional (el valor predeterminado es falso). Cuando estableces esto como verdadero, la política ignora el encabezado True-Client-IP y evalúa las direcciones IP en el encabezado X-Forwarded-For, según el comportamiento de evaluación X-Forwarded-For que configuraste.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Para obtener más información, consulta esta publicación de Comunidad.

Hay dos elementos nuevos disponibles en la política ElevateFault para que FaultRules maneje más limpio y sea más potente.

• ShortFaultReason es un valor booleano que, cuando se establece como verdadero, coloca el nombre de la política en la variable errors.reason.
• AssignVariable, disponible en FaultResponse, te permite asignar la respuesta de falla a una variable para que la usen otras políticas en el flujo de proxy de API.

Ahora se aplican límites a los destinos alojados. Consulta Límites para obtener detalles sobre los límites.

Ahora puedes usar variables de plantilla de mensajes para configurar direcciones IP y máscaras CIDR en la política de AccessControl. Por ejemplo, si deseas almacenar una dirección IP y enmascarar un mapa de clave-valor (KVM), puedes recuperar esos valores desde una variable que establezcas en el flujo del proxy de la API. Esto te permite cambiar los valores de IP con mayor facilidad durante el tiempo de ejecución sin tener que modificar la configuración de la política.

Por ejemplo, en lugar de hacer lo siguiente:

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

Puedes configurar la política de la siguiente manera, si suponemos que los valores están almacenados en un KVM y usas la política KeyValueMapOperations para recuperar los valores y asignarlos a las variables que se muestran aquí:

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

La supervisión de API proporciona dos roles: Administrador de supervisión de API y Usuario de supervisión de API, que se describen en Supervisión de API de Access. Están disponibles en diciembre de 2018.

Edge ahora agrega el encabezado X-Apigee.Message-Timeout a cada solicitud. Este encabezado es para uso interno de Edge. No confíes en los valores de los encabezados X-Apigee.* en tus proxies de API, ya que estos encabezados no están diseñados para el uso por parte del cliente y Apigee pueden quitarlos o cambiarlos en cualquier momento.

Soluciona los errores de eliminación del almacén de claves para que la llamada a la API no falle

x-apigee.edge.execution.sense.action siempre se configura como nulo

En la política ResponseCache, NIOTheread se ejecuta sin rechazo desde el conjunto de subprocesos

Varios exportadores de registros en routers de Apigee generan un alto uso de CPU

Errores 404 intermitentes en organizaciones específicas

El flujo de uso compartido implementado no se ejecuta en algunos procesadores de mensajes

Esta corrección se incluirá en la próxima versión de Edge para la nube privada.

Esta corrección se incluirá en la próxima versión de Edge para la nube privada.

Esta corrección se incluirá en la próxima versión de Edge para la nube privada.