Balanceo de cargas entre servidores de backend

Esta página se aplica a Apigee y Apigee Hybrid.

Consulta la documentación de Apigee Edge.

Apigee mejora la disponibilidad de tus API, puesto que proporciona compatibilidad integrada para el balanceo de cargas y la conmutación por error en varias instancias del servidor de backend.

Los servidores de destino desvincula las URLs de extremo concretas de las opciones de configuración de extremo de destino. En lugar de definir una URL concreta en la configuración, puedes configurar uno o más servidores de destino con nombre. Luego, se hace referencia a cada servicio de destino por nombre en una HTTPConnection del extremo de destino.

Videos

Mira los siguientes videos para obtener más información sobre el enrutamiento de API y el balanceo de cargas mediante servidores de destino.

Información acerca de la configuración del servidor de destino

Una configuración de servidor de destino consta de un nombre, un host, un protocolo y un puerto, con un elemento adicional para indicar si el servidor de destino está habilitado o inhabilitado. Un servidor de destino también puede tener un objeto <sSLInfo> opcional.

El siguiente código proporciona un ejemplo de una configuración de servidor de destiono:

{
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true"
}

Para obtener más información sobre la API de TargetServers, consulta organizations.environments.targetservers.

Consulta el esquema de TargetServer y otras entidades en GitHub.

Crea servidores de destino

Crea servidores de destino con la IU o API de Apigee como se describe en las siguientes secciones.

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target1",
  "host": "1.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'
 

{
  "host" : "1.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
  "name": "target2",
  "host": "2.mybackendservice.com",
  "protocol": "http",
  "port": "80",
  "isEnabled": "true",
  }'

{
  "host" : "2.mybackendservice.com",
  "protocol": "http",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

curl https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers \
  -H "Authorization: Bearer $TOKEN"

[ "target2", "target1" ]

Configura un extremo de destino para el balanceo de cargas en los servidores de destino con nombre

Ahora que tienes dos servidores de destino disponibles, puedes modificar el elemento <HTTPTargetConnection> del extremo de destino para hacer referencia a esos dos servidores de destino por nombre:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configuración anterior es la configuración de balanceo de cargas más básica. El balanceador de cargas admite tres algoritmos de balanceo de cargas, Round Robin, Weighted y Least Connection. Round Robin es el algoritmo predeterminado. Debido a que no se especifica ningún algoritmo en la configuración anterior, las solicitudes salientes del proxy de API a los servidores de backend se alternarán, uno por uno, entre target1 y target2.

El elemento <Path> forma la ruta base del URI de extremo de destino para todos los servidores de destino. Solo se usa cuando se utiliza <LoadBalancer>. De lo contrario, se ignora. En el ejemplo anterior, una solicitud que llega a target1 será http://target1/test, y así para otros servidores de destino.

Configura las opciones del balanceador de cargas

Puedes ajustar la disponibilidad mediante la configuración de las opciones para balanceo de cargas y conmutación por error a nivel del balanceador de cargas y servidor de destino, como se describe en las siguientes secciones.

Algoritmo

Configura el algoritmo que usa <LoadBalancer>. Los algoritmos disponibles son RoundRobin, Weighted y LeastConnections, cada uno de los cuales se documenta a continuación.

Round robin

El algoritmo predeterminado, round robin, reenvía una solicitud a cada servidor de destino en el orden en que los servidores aparecen en la conexión HTTP del extremo de destino. Por ejemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

Peso

El algoritmo de balanceo de cargas weighted te permite configurar cargas de tráfico proporcionales para tus servidores de destino. El balanceador de cargas con el algoritmo weighted distribuye solicitudes a tus servidores de destino en proporción directa con cada ponderación del servidor de destino. Por lo tanto, el algoritmo ponderado requiere que establezcas un atributo weight para cada servidor de destino. Por ejemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

En este ejemplo, dos solicitudes se enrutarán a target2 para cada solicitud enrutada a target1.

Least Connection

Los LoadBalancers configurados para usar el algoritmo de conexión mínima enrutan las solicitudes de salida para servidor de destino con menos conexiones HTTP abiertas. Por ejemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

Cantidad máxima de fallas

La cantidad máxima de solicitudes fallidas del proxy de API a servidor de destino, que hace que la solicitud sea redirigida a otro servidor de destino.

Un error de respuesta significa que Apigee no recibe ninguna respuesta de un servidor de destino. Cuando esto sucede, el contador de fallas suma una.

Sin embargo, cuando Apigee recibe una respuesta de un destino, incluso si la respuesta es un error de HTTP (como 404 o 500), se cuenta como una respuesta de servidor de destino y el contador de fallas se restablece. Para ayudar a garantizar que las respuestas HTTP incorrectas (como 500) también aumenten el recuento del contador de fallas a fin de eliminar un servidor en mal estado de la rotación del balanceo de cargas lo antes posible, puedes agregar el elemento <ServerUnhealthyResponse> con elementos secundarios <ResponseCode> a la configuración de tu balanceador de cargas. Apigee también contará las respuestas con esos códigos como fallas.

En el siguiente ejemplo, se quitará target1 de la rotación después de cinco solicitudes fallidas, incluidas 404 y algunas respuestas 5XX del servidor de destino.

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

El valor predeterminado de MaxFailures es 0. Esto significa que Apigee siempre intenta conectarse al destino de cada solicitud y nunca quita servidor de destino de la rotación.

Lo mejor es usar MaxFailures > 0 con un monitor de estado. Si configuras MaxFailures > 0, servidor de destino se quita de la rotación cuando el destino falla la cantidad de veces que indicas. Cuando se implementa un monitor de estado, Apigee vuelve a colocar automáticamente el servidor de destino en la rotación después de que el destino vuelve a estar en ejecución, según la configuración de ese monitor de estado. Consulta Supervisión del estado para obtener más información.

Ten en cuenta que tanto las llamadas a la API normales como las que inicia un monitor de estado se tendrán en cuenta para el recuento de MaxFailures.

Además, ten en cuenta que el recuento de fallas en ejecución de cada servidor de destino se mantiene por balanceador de cargas. Por ejemplo, supongamos que un proxy tiene dos extremos de destino, cada uno con un balanceador de cargas, y ambos balanceadores de cargas están configurados para usar el mismo conjunto de servidores de destino. En ese caso, las fallas de un extremo de destino solo se registran en el balanceador de cargas correspondiente. No afectan la rotación del otro extremo de destino.

Como alternativa, si configuras MaxFailures > 0 y no configuras un monitor de estado, Apigee quitará automáticamente el servidor de destino de la rotación cuando se detecte la primera falla. Apigee verificará el estado del servidor de destino cada cinco minutos y lo devolverá a la rotación cuando responda de forma normal.

Volver a intentarlo

Si se habilita un reintento, se reintentará una solicitud cada vez que se produzca un error de respuesta (error de E/S o tiempo de espera de HTTP) o la respuesta recibida coincida con un valor establecido por <ServerUnhealthyResponse>. Consulta la sección Cantidad máxima de errores que se encuentra antes para obtener más información sobre la configuración de <ServerUnhealthyResponse>.

De forma predeterminada, <RetryEnabled> se configura como true. Configúralo como false para inhabilitar el reintento. Por ejemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Se puede establecer un servidor de destino (y solo uno) como el servidor de resguardo. El balanceador de cargas no usará el servidor de resguardo hasta que quite de la rotación todos los demás servidores de destino. Cuando esto sucede, todo el tráfico se enruta al servidor de resguardo hasta que uno de los otros servidores de destino vuelva a informar que está en buen estado y se reincorpore a la rotación. Por ejemplo:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

La configuración anterior da como resultado el balanceo de cargas round robin entre target1 y target2 hasta que target1 y target2 no estén disponibles. Cuando target1 y target2 no están disponibles, todo el tráfico se enruta a target3.

Si el servidor de resguardo no está en buen estado, Apigee no enviará tráfico a él. En su lugar, las llamadas a la API mostrarán un error 503 "Service is temporarily unavailable".

Ruta

La ruta define un fragmento de URI que se agregará a todas las solicitudes que envía el servidor de destino al servidor de backend.

Este elemento acepta una ruta de acceso de string literal o una plantilla de mensaje. Una plantilla de mensaje te permite realizar sustituciones de strings variables en el entorno de ejecución. Por ejemplo, en la siguiente definición de extremo de destino, el valor de {mypath} se usa para la ruta:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

Configura un servidor de destino para TLS/SSL

Si usas un servidor de destino a fin de definir el servicio de backend y este requiere la conexión para usar el protocolo HTTPS, debes habilitar TLS/SSL en la definición de servidor de destino. Esto es necesario porque la etiqueta host no te permite especificar el protocolo de conexión.

Configura TLS/SSL unidireccional

Usa la siguiente configuración para definir un servidor de destino con TLS/SSL unidireccional. En este ejemplo, Apigee realiza solicitudes HTTPS al servicio de backend:

{
  "name": "target1",
  "host": "mocktarget.apigee.net",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true"
  }
}

Configura la aplicación estricta de SSL

Para especificar una aplicación estricta de SSL en la definición del servidor de destino, establece enforce en true en el bloque sSLInfo, como se muestra en el siguiente ejemplo:

  {
    "name": "target1",
    "host": "mocktarget.apigee.net",
    "protocol": "http",
    "port": "443",
    "isEnabled": "true",
    "sSLInfo": {
      "enabled": "true",
      "enforce": "true"
    }
  }
  

Configura TLS/SSL bidireccional

Si el servicio de backend requiere bidireccionalidad o TLS/SSL, puedes configurar el servidor de destino con la misma configuración de TLS/SSL que los extremos de destino:

{
  "name": "TargetServer 1",
  "host": "www.example.com",
  "protocol": "http",
  "port": "443",
  "isEnabled": "true",
  "sSLInfo": {
    "enabled": "true",
    "clientAuthEnabled": "true",
    "keyStore": "keystore-name",
    "keyAlias": "keystore-alias",
    "trustStore": "truststore-name",
    "ignoreValidationErrors": "false",
    "ciphers": []
  }
}

Configura SSL estricto con la API

Para crear un servidor de destino con aplicación estricta de SSL mediante una llamada a la API, haz lo siguiente:

curl "https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/targetservers" \
  -X POST \
  -H "Content-Type:application/json"  \
  -H "Authorization: Bearer $TOKEN" \
  -d '
  {
    "name": "TargetServer 1",
    "host": "www.example.com",
    "protocol": "http",
    "port": 443,
    "isEnabled": true,
    "sSLInfo":
    {
      "enabled":true,
      "enforce":true,
      "clientAuthEnabled":true,
      "keyStore":"keystore-name",
      "keyAlias":"keystore-alias",
      "ciphers":[],
      "protocols":[],
      "clientAuthEnabled":true,
      "ignoreValidationErrors":false,
      "trustStore":"truststore-name"
    }
  }'

Supervisión del estado

El monitor de estado te permite mejorar las configuraciones de balanceo de cargas mediante un sondeo activo de las URLs del servicio de backend definidas en las configuraciones de servidor de destino. Cuando el monitor de estado está habilitada, los servidores de destino a los que no se puede acceder o que muestran una respuesta de error se marcan en mal estado. Un servidor de destino con error se vuelve a rotar automáticamente cuando el monitor de estado determina que el servidor de destino está activo. No se requieren reimplementaciones de proxy.

Un monitor de estado actúa como un cliente simple que invoca un servicio de backend a través de TCP o HTTP:

• Un cliente TCP simplemente garantiza que se pueda abrir un socket.
• Configura el cliente HTTP para que envíe una solicitud HTTP válida al servicio de backend. Puedes definir operaciones HTTP GET, PUT, POST o DELETE. La respuesta de la llamada a la supervisión de HTTP debe coincidir con la configuración establecida en el bloque <SuccessResponse>.

Éxitos y fallas

Cuando habilitas la supervisión de estado, Apigee comienza a enviar verificaciones de estado a tu servidor de destino. Una verificación de estado es una solicitud que se envía al servidor de destino y que determina si el servidor de destino está en buen estado o no.

Una verificación de estado puede tener uno de dos resultados posibles:

• Exitosa: se considera que servidor de destino está en buen estado cuando se produce una verificación de estado exitosa. Por lo general, este es el resultado de uno o más de las siguientes situaciones:
  • El servidor de destino acepta una nueva conexión al puerto especificado, responde a una solicitud en ese puerto y, luego, cierra el puerto en el plazo especificado. La respuesta del servidor de destino contiene Connection: close
  • El servidor de destino responde a una solicitud de verificación de estado con 200 (OK) o algún otro código de estado HTTP que sea aceptable.
  • El servidor de destino responde a una solicitud de verificación de estado con un cuerpo de mensaje que coincide con el cuerpo del mensaje esperado.

  Cuando Apigee determina que un servidor está en buen estado, Apigee continúa o reanuda el envío de solicitudes a este.

• Error: El servidor de destino puede fallar a una verificación de estado de diferentes maneras, según el tipo de verificación. Se puede registrar una falla cuando el servidor de destino:
  • Usa una conexión de Apigee al puerto de verificación de estado.
  • No responde a una solicitud de verificación de estado dentro un período específico.
  • Muestra un código de estado HTTP inesperado.
  • Responde con un cuerpo de mensaje que no coincide con el cuerpo del mensaje esperado.

  Cuando un servidor de destino falla en una verificación de estado, Apigee aumenta el recuento de fallas de ese servidor. Si la cantidad de fallas para ese servidor alcanza o supera un umbral predefinido (<MaxFailures>), Apigee deja de enviar solicitudes a ese servidor.

Habilita un monitor de estado

Para crear un monitor de estado para un proxy de API, agrega el elemento <HealthMonitor> a la configuración del elemento <HTTPTargetConnection del extremo de destino del proxy.

No se pueden crear monitores de estado en la IU. En su lugar, debes crear una configuración de proxy y subirla como un archivo ZIP a Apigee. Una configuración de proxy es una descripción estructurada de todos los aspectos de un proxy de API. Las configuraciones de proxy consisten en archivos XML en una estructura de directorio predefinida. Para obtener más información, consulta la Referencia de configuración de proxy de API.

Elementos de configuración de <HealthMonitor>

En la siguiente tabla, se describen los elementos de configuración de <HealthMonitor>:

Además de estos elementos, habilitar un monitor de estado requiere que establezcas el elemento <MaxFailures> en el bloque <HTTPTargetConnection> del elemento <TargetEndpoint> en un valor superior a 0. <MaxFailures> se usa para especificar la cantidad máxima de solicitudes fallidas del proxy de API al servidor de destino que pueden ocurrir antes de que la solicitud se redireccione a otro servidor de destino.

De forma predeterminada, <MaxFailures> es 0, lo que significa que Apigee no realiza ninguna medida correctiva. Cuando configures un monitor de estado, asegúrate de establecer <MaxFailures> en un valor que no sea cero.

Monitor de estado con el monitor de TCP

El monitor de estado de muestra que se describe en la siguiente configuración usa un monitor de TCP para sondear cada servidor de destino abriendo una conexión en el puerto 80 cada cinco segundos. (El puerto es opcional. Si no se especifica, el puerto TCPMonitor es el puerto de servidor de destino).

En esta configuración de ejemplo del monitor de estado, se hace lo siguiente:

• Si la conexión falla o toma más de 10 segundos en conectarse, el recuento de fallas aumenta en 1 para ese servidor de destino.
• Si la conexión se realiza correctamente, el recuento de fallas de servidor de destino se restablece a 0.

Puedes agregar un monitor de estado como elemento secundario del elemento <HTTPTargetConnection> del extremo de destino, como se muestra a continuación:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

Elementos de configuración de <TCPMonitor>

En la siguiente tabla, se describen los elementos de configuración de <TCPMonitor>:

Monitor de estado con el monitor HTTP

El monitor de estado de muestra que se describe en la siguiente configuración usa un monitor de HTTP que envía una solicitud GET al servicio de backend una vez cada cinco segundos y agrega un encabezado de autorización básica HTTP al mensaje de solicitud.

En esta configuración de ejemplo del monitor de estado, se hace lo siguiente:

• La respuesta esperada del servicio de backend es un código de respuesta HTTP 200.
• El valor esperado para el encabezado de autenticación básica HTTP personalizado ImOK es YourOK.
• El elemento <UseTargetServerSSLInfo> se establece en true para usar los parámetros de SSL del bloque <SSLInfo> del servidor de destino.

Con esta configuración, los códigos de respuesta y los valores de encabezado esperados se compararán con las respuestas reales del servicio de backend. Si la respuesta no coincide, la configuración del balanceador de cargas tratará la solicitud como una falla.

De forma predeterminada, los monitores de estado no pueden acceder a los almacenes de claves, los almacenes de confianza ni a otros parámetros de SSL desde sus servidores de destino. Para habilitar el acceso a estos parámetros para el monitor de estado y admitir TLS mutuo, por ejemplo, agrega <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo> en el bloque <Request>.

    <TargetEndpoint name="default">
      <HTTPTargetConnection>
        <LoadBalancer>
          <Algorithm>RoundRobin</Algorithm>
          <Server name="target1" />
          <Server name="target2" />
          <MaxFailures>5</MaxFailures>
        </LoadBalancer>
        <Path>/test</Path>
        <HealthMonitor>
          <IsEnabled>true</IsEnabled>
          <IntervalInSec>5</IntervalInSec>
          <HTTPMonitor>
            <Request>
              <UseTargetServerSSLInfo>true</UseTargetServerSSLInfo>
              <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
              <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
              <Port>80</Port>
              <Verb>GET</Verb>
              <Path>/healthcheck</Path>
              <Header name="Authorization">Basic 12e98yfw87etf</Header>
              <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
            </Request>
            <SuccessResponse>
              <ResponseCode>200</ResponseCode>
              <Header name="ImOK">YourOK</Header>
            </SuccessResponse>
          </HTTPMonitor>
        </HealthMonitor>
      </HTTPTargetConnection>
    </TargetEndpoint>
  

Elementos de configuración de <HTTPMonitor>

En la siguiente tabla, se describen los elementos de configuración de <HTTPMonitor> de nivel superior:

Elementos de configuración <HTTPMonitor>/<Request>

Opciones de configuración para el mensaje de solicitud saliente que envió el monitor de estado a los servidores de destino en la rotación. Ten en cuenta que <Request> es un elemento obligatorio.

Elementos de configuración <HTTPMonitor>/<SuccessResponse>

(Opcional) Opciones que coinciden con el mensaje de respuesta HTTP entrante que genera el servicio de backend sondeado. Las respuestas que no coinciden aumentan la cantidad de fallas en 1.