Balanceamento de carga entre servidores de back-end

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

O Apigee Edge aumenta a disponibilidade da API oferecendo suporte integrado para carga e failover em várias instâncias do servidor de back-end.

As configurações do TargetServer dissociam URLs de endpoint concretos do TargetEndpoint personalizadas. Cada TargetServer é referenciado pelo nome em um TargetEndpoint HTTPConnection. Em vez de definir um URL concreto na configuração, você pode configurar um ou mais TargetServers nomeados, conforme descrito na seção TargetEndpoint (em inglês).

Uma definição TargetServer consiste em um nome, um host e uma porta, com um elemento adicional para indicam se o TargetServer está ativado ou desativado.

Vídeos

Assista os vídeos a seguir para saber mais sobre roteamento de API e balanceamento de carga usando servidores de destino

Exemplo de configuração do TargetServer

O código a seguir define um servidor de destino:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

Elementos de configuração do TargetServer

A tabela a seguir descreve os elementos usados para criar e configurar um TargetServer:

Gerenciar servidores de destino usando a interface

Gerencie os servidores de destino, conforme descrito abaixo.

Como gerenciar servidores de destino usando a API

Use a API Edge para criar, excluir, atualizar, acessar e listar servidores de destino. Para Para mais informações, consulte TargetServers.

Use a seguinte chamada de API para criar um servidor de destino:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Exemplo de resposta:

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

Depois de criar o primeiro TargetServer, use a seguinte chamada de API para criar um segundo TargetServer. Ao definir dois TargetServers, você fornece dois URLs que um TargetEndpoint pode usar para o balanceamento de carga:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Exemplo de resposta:

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

Use a seguinte chamada de API para recuperar uma lista de TargetServers em um ambiente:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

Exemplo de resposta:

[ "target2", "target1" ]

Agora há dois TargetServers disponíveis para uso por proxies de API implantados no teste de nuvem. Para balancear a carga do tráfego nesses TargetServers, configure a conexão HTTP no endpoint de destino de um proxy de API para usar os TargetServers.

Há um limite de 500 TargetServers por ambiente. documentados no tópico Limites.

Como configurar um TargetEndpoint para balancear a carga em TargetServers nomeados

Agora que há dois TargetServers disponíveis, é possível modificar a configuração de conexão HTTP TargetEndpoint para fazer referência a esses dois TargetServers por nome:

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

A configuração acima é a mais básica possível de balanceamento de carga. O balanceador de carga aceita três algoritmos de balanceamento de carga: round-robin, ponderado e dinâmico. Round-robin é o algoritmo padrão. Como nenhum algoritmo foi especificado na configuração acima, as solicitações de saída do proxy de API para os servidores de back-end se alternarão, um para um, entre target1 e target 2.

O elemento <Path> forma o caminho de base do URI do TargetEndpoint todos os servidores de destino. Ele só é usada quando <LoadBalancer> é usado. Caso contrário, será ignorado. No exemplo acima, uma solicitação que chega a "target1" será http://target1/test e assim por outros servidores de destino.

Como definir opções do balanceador de carga

É possível ajustar a disponibilidade usando opções de balanceamento de carga e failover no serviço do balanceador de carga e do servidor de destino. Esta seção descreve essas opções.

Algoritmo

Define o algoritmo usado por <LoadBalancer>. Os algoritmos disponíveis são RoundRobin, Weighted e LeastConnections, cada um deles documentado abaixo.

Round robin

O algoritmo padrão, round-robin, encaminha uma solicitação para cada TargetServer na ordem em que os servidores estão listados na conexão HTTP do endpoint de destino. Exemplo:

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

Ponderado

O algoritmo de balanceamento de carga ponderado permite configurar cargas de tráfego proporcionais para os TargetServers. O balanceador de carga ponderado distribui a solicitação para seus TargetServers diretamente proporção ao peso de cada TargetServer. Portanto, o algoritmo ponderado requer que você defina um atributo weight para cada TargetServer. Por exemplo:

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

Neste exemplo, duas solicitações serão roteadas para target2 para cada solicitação encaminhada para target1.

Escalonamento dinâmico

LoadBalancers configurados para usar o algoritmo de escalonamento dinâmico roteiam solicitações de saída para o TargetServer com menos conexões HTTP abertas. Exemplo:

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

Máximo de falhas

O número máximo de solicitações com falha do proxy de API para o TargetServer que fazem com que a solicitação seja redirecionada para outro TargetServer.

Uma falha na resposta significa que a Apigee não recebe resposta de um servidor de destino. Quando isso acontece, o contador de falhas é incrementado em um.

No entanto, quando a Apigee recebe uma resposta de um destino, mesmo que a resposta seja um erro HTTP (como 500), isso conta como uma resposta do no servidor de destino, e o contador de falhas será redefinido. Para ajudar a garantir que respostas HTTP inválidas (como 500) também incrementa o contador de falhas para remover um servidor não íntegro. da rotação do balanceamento de carga o mais rápido possível, é possível adicionar o Elemento <ServerUnhealthyResponse> com <ResponseCode> elementos filhos à configuração do balanceador de carga. O Edge também contará as respostas com essas e códigos como falhas.

No exemplo a seguir, a target1 será removida da rotação após as cinco solicitações com falha, incluindo algumas respostas do 5XX do servidor de destino.

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

O padrão MaxFailures é 0. Isso significa que o Edge sempre tenta conectar à meta para cada solicitação e nunca remove o servidor de destino da rotação.

É melhor usar MaxFailures > 0 com um HealthMonitor. Se você configurar MaxFailures > 0, o TargetServer é removido da rotação quando o destino falhar o número de vezes que você indicar. Quando um HealthMonitor em vigor, a Apigee coloca automaticamente a o TargetServer volta a girar depois que o alvo voltasse a funcionar, de acordo com a desse HealthMonitor. Consulte Monitoramento de integridade para mais informações.

Como alternativa, se você configurar MaxFailures > 0 e não configurar um HealthMonitor, a Apigee não incluirá novamente o TargetServer na rotação automaticamente depois que a Apigee detectar uma falha. Nesse caso, é necessário reimplantar o proxy de API antes que a Apigee coloque o TargetServer novamente na rotação. Consulte Como implantar um proxy de API.

Tentar novamente

Se a nova tentativa for ativada, uma solicitação será repetida sempre que ocorrer uma falha de resposta (erro de E/S ou de tempo limite HTTP) ou a resposta recebida corresponder a um valor definido por <ServerUnhealthyResponse>. Consulte Máximo de falhas acima para mais informações sobre a configuração de <ServerUnhealthyResponse>.

Por padrão, <RetryEnabled> é definido como true. Defina como false para desativar a nova tentativa. Exemplo:

<RetryEnabled>false</RetryEnabled>

IsFallback

Um (e apenas um) TargetServer pode ser definido como o servidor substituto. O TargetServer substituto não será incluído nas rotinas de balanceamento de carga até que todos os outros TargetServers sejam identificados como indisponíveis pelo balanceador de carga. Quando o balanceador de carga determina que todos os TargetServers estão indisponíveis, todo o tráfego é roteado para o servidor substituto. Por exemplo:

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

A configuração acima resulta em um balanceamento de carga round-robin entre os destinos 1 e 2 até que nenhum dos dois esteja disponível. Quando os destinos 1 e 2 não estão disponíveis, todo o tráfego é roteado para o destino 3.

Caminho

O caminho define um fragmento de URI que será anexado a todas as solicitações emitidas pelo TargetServer para o servidor de back-end.

Esse elemento aceita um caminho de string literal ou um modelo de mensagem. Um modelo de mensagem permite fazer substituição de strings variáveis no tempo de execução. Por exemplo, na definição do endpoint de destino a seguir, o valor de {mypath} é usado para o caminho:

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

Configurar um servidor de destino para TLS/SSL

Se você estiver usando um TargetServer para definir o serviço de back-end e esse serviço exigir a conexão para usar o protocolo HTTPS, será necessário ativar o TLS/SSL na definição do TargetServer. Isso é necessário porque a tag <Host> não permite que você especifique o protocolo de conexão. Veja abaixo a definição do TargetServer para unidirecional TLS/SSL em que o Edge faz solicitações HTTPS para o serviço de back-end:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

Se o serviço de back-end exigir o recurso TLS/SSL de duas vias ou mutuo, configure o TargetServer usando as mesmas definições de configuração do TLS/SSL que o TargetEndpoints:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

Para informações sobre as propriedades <SSLInfo>, como <Ciphers> e <ClientAuthEnabled>, consulte a informações sobre como definir essas propriedades para um host virtual em Como configurar o acesso TLS a uma API para a nuvem privada.

Para instruções completas sobre a configuração do TLS/SSL de saída, consulte Como configurar o TLS da borda para o back-end (nuvem e nuvem privada).

Esquema do TargetServer

Consulte o esquema do TargetServer e de outras entidades no GitHub.

Monitoramento de integridade

O monitoramento de integridade permite aprimorar as configurações de balanceamento de carga pesquisando ativamente os URLs de serviço de back-end definidos nas configurações do TargetServer. Com o monitoramento de integridade ativado, um TargetServer com falha é colocado automaticamente de volta na rotação quando o HealthMonitor determina que o TargetServer está ativo.

O monitoramento de integridade funciona com <MaxFailures>. Sem o monitoramento de integridade ativado, <MaxFailures> especifica o número máximo de solicitações com falha do proxy de API para o TargetServer que faz com que a solicitação seja redirecionada para outro TargetServer. O TargetServer com falha é retirado da rotação até você reimplantar o proxy.

Com o monitoramento de integridade ativado, um TargetServer com falha é colocado automaticamente de volta na rotação e não são necessárias reimplantações de proxy.

O HealthMonitor atua como um cliente simples que invoca um serviço de back-end por TCP ou HTTP:

• Um cliente TCP simplesmente garante que um soquete possa ser aberto.
• Você configura o cliente HTTP para enviar uma solicitação HTTP válida ao serviço de back-end. É possível definir operações HTTP GET, PUT, POST ou DELETE. A resposta da chamada do monitor HTTP precisa corresponder às definições definidas no bloco <SuccessResponse>.

Sucessos e falhas

Quando você ativa o monitoramento de integridade, o Edge começa a enviar verificações de integridade para o destino. servidor. Uma verificação de integridade é uma solicitação enviada ao servidor de destino que determina se o ou não.

Uma verificação de integridade pode ter um destes dois resultados:

• Sucesso: o servidor de destino é considerado íntegro quando ocorre uma verificação de integridade bem-sucedida. Isso normalmente é resultado de um ou mais dos seguintes procedimentos:
  • O servidor de destino aceita uma nova conexão com a porta especificada, responde a uma solicitação nessa porta e a fecha no prazo determinado. A resposta do servidor de destino contém “Connection: close”
  • O servidor de destino responde a uma solicitação de verificação de integridade com um código de status HTTP 200 (OK) ou outro que você determinar aceitável.
  • O servidor de destino responde a uma solicitação de verificação de integridade com um corpo de mensagem que corresponde ao corpo esperado.

  Quando o Edge determina que um servidor está íntegro, ele continua ou retoma o envio de solicitações para ele.

• Falha: o servidor de destino pode falhar em uma verificação de integridade de maneiras diferentes, dependendo do tipo de verificação. Uma falha pode ser registrada quando o servidor de destino:
  • Recusa uma conexão do Edge com a porta de verificação de integridade.
  • não responde a solicitações de verificação de integridade dentro de um período especificado;
  • retorna um código de status HTTP inesperado;
  • responde com um corpo de mensagem que não corresponde ao corpo esperado da mensagem.

  Quando um servidor de destino falha em uma verificação de integridade, o Edge aumenta a contagem de falhas desse servidor. Se o número de falhas desse servidor atinge ou excede um limite predefinido (<MaxFailures>), o Edge para de enviar solicitações para esse servidor.

Como ativar um HealthMonitor

Para criar um HealthMonitor, adicione o elemento <HealthMonitor> à configuração HTTPConnection do TargetEndpoint para um proxy. Não é possível fazer isso na IU. Em vez disso, você cria uma configuração de proxy fazer upload dele no Edge como um arquivo ZIP. Uma configuração de proxy é uma descrição estruturada de todos os aspectos de um proxy de API. As configurações de proxy consistem em arquivos XML em uma estrutura de diretórios predefinida. Para mais informações, consulte a Referência de configuração do proxy da API.

Um HealthMonitor simples define um IntervalInSec combinado com um TCPMonitor ou um HTTPMonitor. O elemento <MaxFailures> especifica o número máximo de solicitações com falha do proxy de API para o TargetServer que faz com que a solicitação seja redirecionada para outro TargetServer. Por padrão, <MaxFailures> é 0, o que significa que O Edge não realiza ações corretivas. Ao configurar um monitor de integridade, configure <MaxFailures> na tag <HTTPTargetConnection> da tag <TargetEndpoint> como um valor diferente de zero.

TCPMonitor

A configuração abaixo define um HealthMonitor que pesquisa cada TargetServer abrindo uma conexão na porta 80 a cada cinco segundos. A porta é opcional. Se não for especificada, a porta TCPMonitor será a TargetServer.

• Se a conexão falhar ou levar mais de 10 segundos para se conectar, a contagem de falhas aumentará em 1 para esse TargetServer.
• Se a conexão for bem-sucedida, a contagem de falhas para TargetServer será redefinida como 0.

É possível adicionar um HealthMonitor como um elemento filho do elemento HTTPTargetConnetion do TargetEndpoint, como mostrado abaixo:

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

HealthMonitor com elementos de configuração TCPMonitor

A tabela a seguir descreve os elementos de configuração do TCPMonitor:

HTTPMonitor

Uma amostra do HealthMonitor que usa um HTTPMonitor enviará uma solicitação GET para o serviço de back-end uma vez a cada cinco segundos. O exemplo abaixo adiciona um cabeçalho de autorização básica HTTP à mensagem de solicitação. A configuração de resposta define configurações que serão comparadas com a resposta real do serviço de back-end. No exemplo abaixo, a resposta esperada é um código de resposta HTTP 200 e um cabeçalho HTTP personalizado ImOK, com valor YourOK. Se a resposta não for correspondente, a solicitação será tratada como uma falha pela configuração do balanceador de carga.

O HTTPMonitor é compatível com serviços de back-end configurados para usar protocolos HTTP e HTTPS unidirecionais. No entanto, ele não é compatível com o seguinte:

• HTTPS bidirecional (também chamado de TLS/SSL bidirecional)
• certificados autoassinados

Observe que todas as configurações de Solicitação e Resposta em um monitor HTTP serão específicas para o serviço de back-end que precisa ser invocado.

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <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>
    

HealthMonitor com elementos de configuração HTTPMonitor

A tabela a seguir descreve os elementos de configuração do HTTPMonitor: