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.

Video	Descripción
Balanceo de cargas con servidores de destino	API de balanceo de cargas en servidores de destino
Enrutamiento de API según el entorno mediante servidores de destino	Enruta una API a un servidor de destino diferente según el entorno.

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.

Apigee en la consola de Cloud

Para crear servidores de destino con Apigee en la consola de Cloud, sigue estos pasos:

Accede a la IU de Apigee en la consola de Cloud.
Selecciona Administración > Entornos.
Selecciona el entorno en el que deseas definir un servidor de destino nuevo.
Haz clic en Servidores de destino en la parte superior del panel.
Haz clic en + Crear servidor de destino.
Ingresa un nombre, un host, un protocolo y un puerto en los campos proporcionados. Las opciones para Protocolo son: HTTP para los servidores de destino basados en REST, gRPC: Destino para los servidores de destino basados en gRPC o gRPC: Callout externo. Consulta Crea proxies de API de gRPC para obtener más información sobre la compatibilidad con el proxy de gRPC.
De manera opcional, puedes seleccionar Habilitar SSL. Consulta Descripción general de certificados SSL.
Haz clic en Crear.

Apigee clásico

Para crear servidores de destino con la IU clásica de Apigee, haz lo siguiente:

Accede a la IU de Apigee.
Selecciona Administrador > Entornos > TargetServers.
En la lista desplegable Entorno, selecciona el entorno para el que deseas definir un servidor de destino nuevo.
La IU de Apigee muestra una lista de servidores de destino actuales en el entorno seleccionado:
Haz clic en +Servidor de destino para agregar un servidor de destino nuevo al entorno seleccionado.
Aparecerá el cuadro de diálogo Agregar servidor de destino:
Haz clic en Habilitado para habilitar la nueva definición de servidor de destino. inmediatamente después de crearlo.
Ingresa un nombre, un host, un protocolo y un puerto en los campos proporcionados. Las opciones para Protocolo son HTTP o GRPC.

De manera opcional, puedes seleccionar la casilla de verificación SSL. Para obtener más información sobre estos campos, consulta TargetServers (video 4MV4D).
Haz clic en Agregar.
Apigee crea la nueva definición de servidor de destino.
Después de crear un nuevo servidor de destino, puedes editar el proxy de API y cambiar el elemento <HTTPTargetConnection> para hacer referencia a la nueva definición.

API de Apigee

En las siguientes secciones, se proporcionan ejemplos sobre el uso de la API de Apigee para crear y enumerar servidores de destino.

Crea un servidor de destino en un entorno mediante la API
Enumera los servidores de destino en un entorno con la API

Para obtener más información, consulta la API de TargetServers.

Crea un servidor de destino en un entorno mediante la API

Para crear un servidor de destino llamado target1 que se conecta a 1.mybackendservice.com en el puerto 80, usa la siguiente llamada a la API:

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",
  }'

En el ejemplo anterior, $TOKEN está configurado como tu token de acceso de OAuth 2.0, como se describe en Obtén un token de acceso de OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usa curl. Para obtener una descripción de las variables de entorno utilizadas, consulta Configura variables de entorno para solicitudes a la API de Apigee.

A continuación, se proporciona un ejemplo de la respuesta.

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

Crea un segundo servidor de destino con la siguiente llamada a la API. Cuando defines dos servidores de destino, proporcionas dos URLs que un extremo de destino puede usar para el balanceo de cargas:

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",
  }'

A continuación, se proporciona un ejemplo de la respuesta.

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

Enumera los servidores de destino en un entorno con la API

Para enumerar los servidores de destino en un entorno, usa la siguiente llamada a la API:

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

A continuación, se proporciona un ejemplo de la respuesta.

[ "target2", "target1" ]

Ahora hay dos servidores de destino disponibles para que los usen los proxies de API implementados en el entorno de test. Para balancear las cargas de tráfico en estos servidores de destino, configura la conexión HTTP en el extremo de destino de un proxy de API para usar los servidores de destino.

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.

Para obtener más información, consulta TargetEndpoint.

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.

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.

Reintento

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 servidor de destino de reserva no se incluye en las rutinas de balanceo de cargas hasta que el balanceador de cargas identifique todos los demás servidores de destino. Cuando el balanceador de cargas determina que no está disponible ningún servidor de destino que no sea de resguardo, todo el tráfico se enruta al servidor de resguardo. 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.

Nota: Si defines el bloque sSLInfo en la definición extremo de destino y servidor de destino, la definición en servidor de destino tiene prioridad.

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.

Debes establecer <MaxFailures> mayor que 0 cuando uses un monitor de estado. Si el valor de <MaxFailures> se establece en 0, Apigee siempre intentará conectarse al destino de cada solicitud y no quitará el servidor de destino de la rotación.

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>:

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`IsEnabled`	Un valor booleano que habilita o inhabilita el monitor de estado.	false	No
`IntervalInSec`	El intervalo de tiempo, en segundos, entre cada solicitud de sondeo TCP o HTTP.	0	Sí
`HTTPMonitor` o `TCPMonitor`	Es una definición del cliente TCP o HTTP que se usará para sondear el servidor de destino.	N/A	Sí

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>:

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`ConnectTimeoutInSec`	El tiempo en que la conexión al puerto TCP se debe establecer para que se considere correcta. Si no se puede establecer la conexión en el intervalo especificado, se considera una falla y se incrementa el recuento de fallas del balanceador de cargas para el servidor de destino.	0	Sí
`Port`	Opcional. El puerto en el que se establecerá la conexión TCP. Si no se especifica, el puerto TCPMonitor es el puerto de servidor de destino.	0	No

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:

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`Request`	Es el mensaje de solicitud saliente que envió el monitor de estado a los servidores de destino en la rotación.	N/A	Sí
`SuccessResponse`	(Opcional) Opciones que coinciden con el mensaje de respuesta HTTP entrante que genera el servicio de backend sondeado.	N/A	No

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.

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`ConnectTimeoutInSec`	Tiempo, en segundos, en que el protocolo de enlace de conexión TCP al servicio HTTP debe completarse para que se considere correcto. Si no se puede establecer la conexión en el intervalo especificado, se considera una falla y se incrementa el recuento de fallas del balanceador de cargas para el servidor de destino. Nota: Si el valor especificado es 0, Apigee usará un tiempo de espera predeterminado de 30 segundos.	0	No
`SocketReadTimeoutInSec`	Tiempo, en segundos, en que los datos se deben leer desde el servicio HTTP para que se considere un resultado correcto. Si no se lee el intervalo especificado, se producirá una falla, lo que aumenta el recuento de fallas del LoadBalancer para el servidor de destino. Nota: Si el valor especificado es 0, Apigee usará un tiempo de espera predeterminado de 30 segundos.	0	No
`Port`	El puerto en el que se establecerá la conexión HTTP al servicio de backend.	Puerto del servidor de destino	No
`Verb`	El verbo HTTP que se usa para cada solicitud HTTP de sondeo al servicio de backend.	N/A	No
`Path`	La ruta de acceso adjunta a la URL definida en el servidor de destino. Usa el elemento `Path` para configurar un "extremo de sondeo" en tu servicio HTTP. Ten en cuenta que el elemento `Path` no admite variables.	N/A	No
`UseTargetServerSSLInfo`	Cuando `UseTargetServerSSLInfo` sea verdadero, las solicitudes del monitor de estado a un servidor de destino usarán los parámetros de SSL del bloque SSLInfo ("sSLInfo") del servidor de destino. De lo contrario, los parámetros de SSL, como el protocolo, el almacén de claves, el almacén de certificados de confianza, etcétera, no estarán disponibles para el monitor de estado.	false	No
`IncludeHealthCheckIdHeader`	Te permite hacer un seguimiento de las solicitudes de verificación de estado en sistemas ascendentes. `IncludeHealthCheckIdHeader` toma un valor booleano y su valor predeterminado es `false`. Si lo configuras como `true`, hay una `Header` llamada `X-Apigee-Healthcheck-Id` que se inserta en la solicitud de verificación de estado. El valor del encabezado se asigna de forma dinámica y toma la forma siguiente: `ORG/ENV/SERVER_UUID/N`, donde`ORG` es el nombre de la organización, `ENV` es el nombre del entorno, `SERVER_UUID` es un ID único que identifica al MP y `N` es el número de milisegundos transcurridos desde el 1 de enero de 1970. Ejemplo de encabezado de solicitud resultante: `X-Apigee-Healthcheck-Id: orgname/envname/E8C4D2EE-3A69-428A-8616-030ABDE864E0/1586802968123`	false	No
`Payload`	El cuerpo HTTP generado para cada solicitud HTTP de sondeo. Ten en cuenta que este elemento no es obligatorio para las solicitudes `GET`.	N/A	No
`Header`	Uno o más encabezados y valores HTTP que se espera que se reciban del servicio de backend sondeado. Cualquier encabezado o valor HTTP de la respuesta que sea diferente de los especificados genera un error y el recuento para el servidor de destino sondeado se incrementa en 1. Puedes definir varios elementos del encabezado.	N/A	No
`IsSSL`	Si es verdadero, especifica que la solicitud del monitor de estado se envíe a través de HTTPS.	Falso	No
`TrustAllSSL`	Especifica si la verificación del monitor HTTP confiará automáticamente en todos los certificados SSL.	Falso	No

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.

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`ResponseCode`	El código de respuesta HTTP que se espera recibir del servidor de destino sondeado. Un código distinto del código especificado genera un error y el recuento se incrementa para el servicio de backend sondeado. Puedes definir varios elementos ResponseCode.	N/A	No
`Header`	Uno o más encabezados y valores HTTP que se espera que se reciban del servicio de backend sondeado. Cualquier encabezado o valor HTTP de la respuesta que sea diferente de los especificados genera un error y el recuento para el servidor de destino sondeado se incrementa en 1. Puedes definir varios elementos del encabezado.	N/A	No

Balanceo de cargas entre servidores de backend

Videos

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

Crea servidores de destino

Apigee en la consola de Cloud

Apigee clásico

API de Apigee

Crea un servidor de destino en un entorno mediante la API

Enumera los servidores de destino en un entorno con la API

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

Configura las opciones del balanceador de cargas

Algoritmo

Round robin

Peso

Least Connection

Cantidad máxima de fallas

Reintento

IsFallback

Ruta

Configura un servidor de destino para TLS/SSL

Configura TLS/SSL unidireccional

Configura la aplicación estricta de SSL

Configura TLS/SSL bidireccional

Configura SSL estricto con la API

Supervisión del estado

Éxitos y fallas

Habilita un monitor de estado

Elementos de configuración de <HealthMonitor>

Monitor de estado con el monitor de TCP

Elementos de configuración de <TCPMonitor>

Monitor de estado con el monitor HTTP

Elementos de configuración de <HTTPMonitor>

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

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

Elementos de configuración de `<HealthMonitor>`

Elementos de configuración de `<TCPMonitor>`

Elementos de configuración de `<HTTPMonitor>`