Esta página se ha traducido con Cloud Translation API.

Balanceo de carga en 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 APIs al ofrecer compatibilidad integrada con el balanceo de carga y la conmutación por error en varias instancias de servidores backend.

Los servidores de destino desacoplan las URLs de los endpoints concretos de las configuraciones de los endpoints de destino. En lugar de definir una URL concreta en la configuración, puedes configurar uno o varios servidores de destino con nombre. A continuación, se hace referencia a cada servidor de destino por su nombre en una conexión HTTP de punto final de destino.

Vídeos

Consulta los siguientes vídeos para obtener más información sobre el enrutamiento de APIs y el balanceo de carga mediante servidores de destino

Vídeo	Descripción
Balanceo de carga con servidores de destino	Balancear la carga de las APIs en los servidores de destino.
Enrutamiento de APIs basado en el entorno mediante servidores de destino	Dirigir una API a un servidor de destino diferente en función del entorno.

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 muestra un ejemplo de configuración de un servidor de destino:

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

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

Consulta el esquema de TargetServer y otras entidades en GitHub.

Crear servidores de destino

Crea servidores de destino mediante la interfaz de usuario o la 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:

En la Google Cloud consola, ve a la página Gestión > Entornos.

Ir a Entornos
Selecciona el entorno en el que quieras definir un nuevo servidor de destino.
En la parte superior del panel, haga clic en Servidores de destino.
Haz clic en + Crear servidor de destino.
Introduce un nombre, un host, un protocolo y un puerto en los campos correspondientes. Las opciones de Protocolo son: HTTP para servidores de destino basados en REST, gRPC - Destino para servidores de destino basados en gRPC o gRPC - Llamada externa. Consulta Crear proxies de API gRPC para obtener información sobre la compatibilidad con proxies gRPC.
También puedes seleccionar Habilitar SSL. Consulta la información general sobre los certificados SSL.
Haz clic en Crear.

Apigee Classic

Para crear servidores de destino con la interfaz de usuario clásica de Apigee, sigue estos pasos:

Inicia sesión en la interfaz de usuario de Apigee.
Seleccione Administrador > Entornos > TargetServers.
En la lista desplegable Entorno, selecciona el entorno en el que quieras definir un nuevo servidor de destino.
La interfaz de usuario de Apigee muestra una lista de los servidores de destino actuales del entorno seleccionado:
Haz clic en +Servidor de destino para añadir un nuevo servidor de destino al entorno seleccionado.
Se muestra el cuadro de diálogo Añadir servidor de destino:
Haga clic en Habilitado para habilitar el nuevo servidor de destino. inmediatamente después de crearlo.
Introduce un nombre, un host, un protocolo y un puerto en los campos correspondientes. Las opciones de Protocolo son HTTP o GRPC.

También puedes seleccionar la casilla SSL. Para obtener más información sobre estos campos, consulta el vídeo TargetServers (4MV4D).
Haz clic en Añadir.
Apigee crea la nueva definición de servidor de destino.
Después de crear un nuevo servidor de destino, puedes editar tu proxy de API y cambiar el elemento <HTTPTargetConnection> para que haga referencia a la nueva definición.

API de Apigee

En las siguientes secciones se muestran ejemplos de cómo usar la API de Apigee para crear y enumerar servidores de destino.

Crear un servidor de destino en un entorno mediante la API
Listar los servidores de destino de un entorno mediante la API

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

Crear un servidor de destino en un entorno mediante la API

Para crear un servidor de destino llamado target1 que se conecte 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",
  }'

Donde $TOKEN es tu token de acceso OAuth 2.0, tal como se describe en Obtener un token de acceso OAuth 2.0. Para obtener información sobre las opciones de curl que se usan en este ejemplo, consulta Usar curl. Para ver una descripción de las variables de entorno que puedes usar, consulta Definir variables de entorno para solicitudes a la API de Apigee.

A continuación, se muestra 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. Si defines dos servidores de destino, proporcionas dos URLs que un endpoint de destino puede usar para el balanceo de carga:

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 muestra un ejemplo de la respuesta:

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

Mostrar los servidores de destino de un entorno mediante la API

Para enumerar los servidores de destino de 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 muestra un ejemplo de la respuesta:

[ "target2", "target1" ]

Ahora hay dos servidores de destino disponibles para los proxies de API desplegados en el entorno test. Para balancear la carga del tráfico entre estos servidores de destino, configura la conexión HTTP en el endpoint de destino de un proxy de API para que use los servidores de destino.

Configurar un endpoint de destino para balancear la carga entre servidores de destino con nombre

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

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

La configuración anterior es la más básica para el balanceo de carga. El balanceador de carga admite tres algoritmos de balanceo de carga: RoundRobin, Weighted y LeastConnections. Round Robin es el algoritmo predeterminado. Como no se ha especificado ningún algoritmo en la configuración anterior, las solicitudes salientes del proxy de API a los servidores backend se alternarán, una a una, entre target1 y target2.

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

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

Configurar las opciones del balanceador de carga

Puede ajustar la disponibilidad configurando las opciones de balanceo de carga y de conmutación por error a nivel de balanceador de carga y de servidor de destino, tal como se describe en las siguientes secciones.

Algoritmo

Define el algoritmo que usa <LoadBalancer>. Los algoritmos disponibles son RoundRobin, Weighted y LeastConnections. Cada uno de ellos se describe a continuación.

Orden aleatorio

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

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

Ponderado

El algoritmo de balanceo de carga ponderado te permite configurar cargas de tráfico proporcionales para tus servidores de destino. El balanceador de carga ponderado distribuye las solicitudes a los servidores de destino en proporción directa al peso de cada servidor de destino. Por lo tanto, el algoritmo ponderado requiere que defina 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, se enviarán dos solicitudes a target2 por cada solicitud que se envíe a target1.

Mínimo de conexiones

Los balanceadores de carga configurados para usar el algoritmo de menor número de conexiones dirigen las solicitudes salientes al servidor de destino con el menor número de 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>

Número máximo de errores

Número máximo de solicitudes fallidas del proxy de la API al servidor de destino que provoca que la solicitud se redirija a otro servidor de destino.

Si se produce un error en la respuesta, significa que Apigee no recibe ninguna respuesta de un servidor de destino. Cuando esto ocurre, el contador de errores aumenta en uno.

Sin embargo, cuando Apigee recibe una respuesta de un destino, aunque sea un error HTTP (como 404 o 500), se considera una respuesta del servidor de destino y se restablece el contador de errores. Para asegurarte de que las respuestas HTTP incorrectas (como 500) también aumenten el contador de errores para que un servidor en mal estado deje de participar en la rotación del balanceo de carga lo antes posible, puedes añadir el elemento <ServerUnhealthyResponse> con elementos secundarios <ResponseCode> a la configuración del balanceador de carga. Apigee también contabilizará las respuestas con esos códigos como errores.

En el siguiente ejemplo, target1 se eliminará 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 elimina el servidor de destino de la rotación.

Es mejor usar MaxFailures > 0 con un monitor de estado. Si configura MaxFailures > 0, el servidor de destino se eliminará de la rotación cuando el destino falle el número de veces que indique. Cuando hay un monitor de estado, Apigee vuelve a poner automáticamente el servidor de destino en rotación después de que el destino esté activo y en funcionamiento de nuevo, de acuerdo con la configuración de ese monitor de estado. Consulta Monitorización del estado para obtener más información.

Ten en cuenta que tanto las llamadas a la API normales como las iniciadas por un monitor de estado se contabilizarán en el número MaxFailures.

También debes tener en cuenta que el recuento de errores de ejecución de cada servidor de destino se mantiene por equilibrador de carga. Por ejemplo, supongamos que un proxy tiene dos endpoints de destino y que cada uno tiene un balanceador de carga. Además, ambos balanceadores de carga están configurados para utilizar el mismo conjunto de servidores de destino. En ese caso, los errores de un endpoint de destino solo se contabilizan en el balanceador de carga correspondiente. No afectan a la rotación del otro endpoint de destino.

De lo contrario, si configura MaxFailures > 0 y no configura un monitor de estado, Apigee retirará automáticamente el servidor de destino de la rotación cuando se detecte el primer fallo. Apigee comprobará el estado del servidor de destino cada cinco minutos y lo volverá a incluir en la rotación cuando responda con normalidad.

Reintentar

Si la opción de reintento está habilitada, se volverá a intentar una solicitud siempre que se produzca un error de respuesta (error de E/S o tiempo de espera HTTP) o que la respuesta recibida coincida con un valor definido por <ServerUnhealthyResponse>. Consulta la sección Número máximo de fallos de arriba para obtener más información sobre cómo definir <ServerUnhealthyResponse>.

De forma predeterminada, <RetryEnabled> está configurado como true. Asigna el valor false para inhabilitar los reintentos. Por ejemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Solo se puede definir un servidor de destino como servidor de respaldo. El balanceador de carga no usará el servidor de respaldo hasta que el balanceador de carga haya retirado de la rotación a todos los demás servidores de destino. Cuando esto ocurre, todo el tráfico se dirige al servidor de respaldo hasta que uno de los otros servidores de destino vuelve a estar en buen estado y se vuelve a incluir en 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 un balanceo de carga de tipo Round Robin entre target1 y target2 hasta que ambos hosts no estén disponibles.target1target2 Cuando target1 y target2 no están disponibles, todo el tráfico se dirige a target3.

Si el servidor de respaldo no está en buen estado, Apigee no enrutará el tráfico a él. En su lugar, las llamadas a la API devolverán un error 503 "El servicio no está disponible temporalmente".

Ruta

Path define un fragmento de URI que se añadirá a todas las solicitudes emitidas por el servidor de destino al servidor backend.

Este elemento acepta una ruta de cadena literal o una plantilla de mensaje. Una plantilla de mensaje te permite sustituir cadenas de variables en el tiempo de ejecución. Por ejemplo, en la siguiente definición de punto de conexión de destino, se usa el valor de {mypath} para la ruta:

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

Configurar un servidor de destino para TLS/SSL

Si usas un servidor de destino para definir el servicio de backend y este requiere que la conexión use el protocolo HTTPS, debes habilitar TLS/SSL en la definición del 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 tanto en el punto de conexión de destino como en la definición del servidor de destino, tendrá prioridad el que se encuentre en el servidor de destino.

Configurar TLS/SSL unidireccional

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

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

Configurar la aplicación estricta de SSL

Para especificar que se aplique estrictamente el protocolo SSL en la definición del servidor de destino, asigna el valor true a enforce 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"
    }
  }

Configurar TLS/SSL bidireccional

Si el servicio de backend requiere TLS/SSL bidireccional o mutuo, puede configurar el servidor de destino con los mismos ajustes de configuración de TLS/SSL que los endpoints 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": []
  }
}

Configurar SSL estricto con la API

Para crear un servidor de destino con la validación estricta de SSL mediante una llamada a la API, sigue estos pasos:

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

Monitorización de la salud

La monitorización del estado te permite mejorar las configuraciones de balanceo de carga sondeando activamente las URLs de los servicios de backend definidas en las configuraciones de los servidores de destino. Si la monitorización del estado está habilitada, los servidores de destino que no estén disponibles o devuelvan una respuesta de error se marcarán como no disponibles. Un servidor de destino que ha fallado se vuelve a poner en rotación automáticamente cuando el monitor de estado determina que está activo. No es necesario volver a implementar los proxies.

Debes asignar a <MaxFailures> un valor superior a 0 cuando utilices un monitor de estado. Si el valor de <MaxFailures> es 0, Apigee siempre intentará conectarse al destino en cada solicitud y no eliminará el servidor de destino de la rotación.

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

Un cliente TCP solo se asegura de 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 de monitor HTTP debe coincidir con los ajustes configurados en el bloque <SuccessResponse>.

Éxitos y fracasos

Cuando habilitas la monitorización del estado, Apigee empieza a enviar comprobaciones de estado a tu servidor de destino. Una comprobación de estado es una solicitud que se envía al servidor de destino para determinar si está en buen estado.

Una comprobación del estado puede dar uno de estos dos resultados:

Éxito: el servidor de destino se considera correcto cuando se realiza una comprobación del estado satisfactoria. Esto suele deberse a uno o varios de los siguientes motivos:
- El servidor de destino acepta una nueva conexión al puerto especificado, responde a una solicitud en ese puerto y, a continuación, 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 comprobación de estado con un código de estado HTTP 200 (OK) u otro que consideres aceptable.
- El servidor de destino responde a una solicitud de comprobación del estado con un cuerpo de mensaje que coincide con el cuerpo de mensaje esperado.
Cuando Apigee determina que un servidor está en buen estado, continúa o reanuda el envío de solicitudes a ese servidor.
Fallo: el servidor de destino puede fallar una comprobación del estado de diferentes formas, según el tipo de comprobación. Se puede registrar un error cuando el servidor de destino:
- Rechaza una conexión de Apigee al puerto de comprobación del estado.
- No responde a una solicitud de comprobación del estado en un periodo determinado.
- Devuelve un código de estado HTTP inesperado.
- Responde con un cuerpo de mensaje que no coincide con el cuerpo de mensaje esperado.
Cuando un servidor de destino no supera una comprobación de estado, Apigee incrementa el número de errores de ese servidor. Si el número de fallos de ese servidor alcanza o supera un umbral predefinido (<MaxFailures>), Apigee deja de enviar solicitudes a ese servidor.

Habilitar un monitor de estado

Para crear un monitor de estado de un proxy de API, añade el elemento <HealthMonitor> a la configuración del elemento <HTTPTargetConnection del endpoint de destino del proxy.

No se pueden crear monitores de estado en la interfaz de usuario. En su lugar, cree una configuración de proxy y súbala a Apigee como archivo ZIP. Una configuración de proxy es una descripción estructurada de todos los aspectos de un proxy de APIs. Las configuraciones de proxy constan de archivos XML en una estructura de directorios predefinida. Para obtener más información, consulta la referencia de configuración de proxies de APIs.

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.	falso	No
`IntervalInSec`	Intervalo de tiempo, en segundos, entre cada solicitud TCP o HTTP de sondeo.	0	Sí
`HTTPMonitor` o `TCPMonitor`	Definición del cliente TCP o HTTP que se usará para sondear el servidor de destino.	N/A	Sí

Además de estos elementos, para habilitar un monitor de estado, debe asignar al elemento <MaxFailures> del bloque <HTTPTargetConnection> del elemento <TargetEndpoint> un valor superior a 0. <MaxFailures> se usa para especificar el número máximo de solicitudes fallidas del proxy de la API al servidor de destino que pueden producirse antes de que la solicitud se redirija a otro servidor de destino.

De forma predeterminada, <MaxFailures> es 0, lo que significa que Apigee no realiza ninguna acción correctiva. Al configurar un monitor de salud, asegúrate de asignar a <MaxFailures> un valor distinto de cero.

Monitor de estado mediante monitor TCP

El monitor de estado de ejemplo que se describe en la siguiente configuración usa un monitor 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 de monitorización TCP es el puerto del servidor de destino.

En esta configuración de monitor de estado de ejemplo:

Si la conexión falla o tarda más de 10 segundos en establecerse, el contador de errores aumenta en 1 para ese servidor de destino.
Si la conexión se realiza correctamente, el recuento de errores del servidor de destino se restablece a 0.

Puedes añadir un monitor de estado como elemento secundario del elemento <HTTPTargetConnection> del endpoint de destino, tal 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`	Tiempo en el que se debe establecer la conexión con el puerto TCP para que se considere correcta. Si no se establece la conexión en el intervalo especificado, se considera un fallo, lo que incrementa el número de fallos del balanceador de carga en 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 de monitorización TCP es el puerto del servidor de destino.	0	No

Monitor de estado mediante monitor HTTP

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

En esta configuración de monitor de estado de ejemplo:

La respuesta esperada del servicio backend es un código de respuesta HTTP 200.
El valor esperado del encabezado de autorización básica HTTP personalizado ImOK es YourOK.
El elemento <UseTargetServerSSLInfo> se define como true para usar los parámetros 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 carga tratará la solicitud como un error.

De forma predeterminada, los monitores de estado no pueden acceder a almacenes de claves, almacenes de confianza u otros parámetros SSL de sus servidores de destino. Para habilitar el acceso a estos parámetros para tu monitor de salud y admitir TLS mutuo, por ejemplo, añade <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 nivel superior <HTTPMonitor>:

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`Request`	El mensaje de solicitud saliente que envía el monitor de estado a los servidores de destino en la rotación.	N/A	Sí
`SuccessResponse`	(Opcional) Opciones de coincidencia para el mensaje de respuesta HTTP entrante generado por el servicio de backend consultado.	N/A	No

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

Opciones de configuración del mensaje de solicitud saliente que envía 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 el que debe completarse la negociación de conexión TCP con el servicio HTTP para que se considere correcta. Si no se establece la conexión en el intervalo especificado, se considera un fallo, lo que incrementa el número de fallos del balanceador de carga en 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 el que se deben leer los datos del servicio HTTP para que se considere un éxito. Si no se lee en el intervalo especificado, se considera un error, lo que incrementa el número de errores de LoadBalancer del servidor de destino. Nota: Si el valor especificado es 0, Apigee usará un tiempo de espera predeterminado de 30 segundos.	0	No
`Port`	Puerto en el que se establecerá la conexión HTTP con el servicio de backend.	Puerto del servidor de destino	No
`Verb`	El verbo HTTP utilizado en cada solicitud HTTP de sondeo al servicio de backend.	N/A	No
`Path`	La ruta que se añade a la URL definida en el servidor de destino. Usa el elemento `Path` para configurar un endpoint de sondeo en tu servicio HTTP. Ten en cuenta que el elemento `Path` no admite variables.	N/A	No
`UseTargetServerSSLInfo`	Si `UseTargetServerSSLInfo` es true, las solicitudes de monitorización del estado de un servidor de destino usarán los parámetros SSL del bloque "sSLInfo" de SSLInfo del servidor de destino. De lo contrario, el monitor de estado no podrá acceder a los parámetros de SSL, como el protocolo, el almacén de claves, el almacén de confianza, etc.	falso	No
`IncludeHealthCheckIdHeader`	Te permite monitorizar las solicitudes de comprobación de estado en sistemas upstream. El `IncludeHealthCheckIdHeader` toma un valor booleano y el valor predeterminado es `false`. Si le asignas el valor `true`, habrá un `Header` llamado `X-Apigee-Healthcheck-Id` que se insertará en la solicitud de comprobación del estado. El valor del encabezado se asigna de forma dinámica y tiene el formato `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 el 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`	falso	No
`Payload`	El cuerpo HTTP generado para cada solicitud HTTP de sondeo. Ten en cuenta que este elemento no es obligatorio para las solicitudes de `GET`.	N/A	No
`Header`	Uno o varios encabezados y valores HTTP que se espera recibir del servicio backend consultado. Si algún encabezado o valor HTTP de la respuesta es diferente de los especificados, se producirá un error y el recuento del servidor de destino sondeado aumentará en 1. Puedes definir varios elementos Header.	N/A	No
`IsSSL`	Si es true, especifica que la solicitud de monitor de estado se envíe mediante HTTPS.	Falso	No
`TrustAllSSL`	Especifica si la comprobación del monitor HTTP confiará automáticamente en todos los certificados SSL.	Falso	No

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

(Opcional) Opciones de coincidencia para el mensaje de respuesta HTTP entrante generado por el servicio de backend consultado. Las respuestas que no coinciden aumentan el recuento de errores en 1.

Nombre	Descripción	Predeterminado	¿Es obligatorio?
`ResponseCode`	El código de respuesta HTTP que se espera recibir del servidor de destino sondeado. Si se introduce un código distinto al especificado, se produce un error y se incrementa el recuento del servicio backend consultado. Puedes definir varios elementos ResponseCode.	N/A	No
`Header`	Uno o varios encabezados y valores HTTP que se espera recibir del servicio backend consultado. Si algún encabezado o valor HTTP de la respuesta es diferente de los especificados, se producirá un error y el recuento del servidor de destino sondeado aumentará en 1. Puedes definir varios elementos Header.	N/A	No

Balanceo de carga en servidores de backend Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Vídeos

Acerca de la configuración del servidor de destino

Crear servidores de destino

Apigee en la consola de Cloud

Apigee Classic

API de Apigee

Crear un servidor de destino en un entorno mediante la API

Mostrar los servidores de destino de un entorno mediante la API

Configurar un endpoint de destino para balancear la carga entre servidores de destino con nombre

Configurar las opciones del balanceador de carga

Algoritmo

Orden aleatorio

Ponderado

Mínimo de conexiones

Número máximo de errores

Reintentar

IsFallback

Ruta

Configurar un servidor de destino para TLS/SSL

Configurar TLS/SSL unidireccional

Configurar la aplicación estricta de SSL

Configurar TLS/SSL bidireccional

Configurar SSL estricto con la API

Monitorización de la salud

Éxitos y fracasos

Habilitar un monitor de estado

Elementos de configuración de <HealthMonitor>

Monitor de estado mediante monitor TCP

Elementos de configuración de <TCPMonitor>

Monitor de estado mediante monitor HTTP

Elementos de configuración de <HTTPMonitor>

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

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

Balanceo de carga en servidores de backend

Elementos de configuración de `<HealthMonitor>`

Elementos de configuración de `<TCPMonitor>`

Elementos de configuración de `<HTTPMonitor>`