Esta página foi traduzida pela API Cloud Translation.

Antipadrão: balanceamento de carga com apenas um servidor de destino com MaxFailures definido como um valor diferente de zero

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

A configuração do TargetEndpoint define a maneira como o Apigee Edge se conecta a um serviço de back-end ou API. Ele envia as solicitações e recebe as respostas para/do serviço de back-end. O serviço de back-end pode ser um servidor HTTP/HTTPS, NodeJS ou destino hospedado.

O serviço de back-end no TargetEndpoint pode ser invocado de uma das seguintes maneiras:

URL direto para um servidor HTTP ou HTTPS
ScriptTarget para um script Node.js hospedado na borda
HostedTarget para NodeJS implantado no ambiente de destino hospedado
Configuração do TargetServer

Da mesma forma, a política de chamadas de serviço pode ser usada para fazer uma chamada para qualquer serviço externo do fluxo do proxy da API. Essa política é compatível com a definição de URLs de destino HTTP/HTTPS diretamente na própria política ou usando uma configuração de TargetServer.

Configuração do TargetServer

A configuração TargetServer separa os URLs de endpoint concretos das configurações de TargetEndpoint ou das políticas de Service Callout. Um TargetServer é referenciado por um nome em vez do URL no TargetEndpoint. A configuração do TargetServer terá o nome do host do serviço de back-end, o número da porta e outros detalhes.

Veja um exemplo de configuração de TargetServer:

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

O TargetServer permite que você tenha configurações diferentes para cada ambiente. Uma política de TargetEndpoint/Service Callout pode ser configurada com um ou mais TargetServers nomeados usando um LoadBalancer. O suporte integrado para o balanceamento de carga melhora a disponibilidade das APIs e do failover entre as instâncias configuradas do servidor de back-end.

Veja um exemplo de configuração de TargetEndpoint usando TargetServers:

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

MaxFailures

A configuração MaxFailures especifica o número máximo de falhas de solicitação para o servidor de destino. Após esse período, o servidor de destino será marcado como inativo e removido da rotação para todas as solicitações subsequentes.

Um exemplo de configuração com MaxFailures especificado:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
       <Server name="target2"/>
       <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

No exemplo acima, se cinco solicitações consecutivas falharem para "target1", ele será removido da rotação e todas as solicitações subsequentes serão enviadas apenas para target2.

Antipadrão

Ter apenas um TargetServer em uma configuração LoadBalancer da política TargetEndpoint ou Service Callout com MaxFailures definido como um valor diferente de zero não é recomendado, porque pode ter implicações adversas.

Considere o seguinte exemplo de configuração que tem um único TargetServer chamado "target1" com MaxFailures definido como 5 (valor diferente de zero):

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

Se as solicitações para o TargetServer "target1" falharem cinco vezes, número especificado em MaxFailures, o TargetServer será removido da rotação. Como não há outros TargetServers para falhar, todas as solicitações subsequentes para o API Proxy com essa configuração apresentarão falha com o erro 503 Service Unavailable.

Mesmo que o "target1" do TargetServer volte ao estado normal e seja capaz de enviar respostas, as solicitações ao proxy da API continuarão retornando erros 503. Isso ocorre porque o Edge não coloca automaticamente o TargetServer de volta em rotação, mesmo depois que o destino está funcionando novamente. Para resolver esse problema, o proxy de API precisa ser reimplantado para que o Edge coloque o TargetServer novamente em rotação.

Se a mesma configuração for usada na política de Service Callout, as solicitações da API receberão o erro 500 depois que as solicitações para o "target1" do TargetServer falharem cinco vezes.

Impacto

O uso de apenas um TargetServer em uma configuração LoadBalancer da política TargetEndpoint ou Service Callout com MaxFailures definido como um valor diferente de zero gera os seguintes problemas:

As solicitações da API falharão com erros 503/500 de forma contínua, depois que as solicitações falham por um número máximo de vezes, até que o proxy de API seja reimplantado.
A interrupção é mais longa porque pode levar mais tempo para diagnosticar a causa do problema, sem conhecimento prévio sobre este antipadrão.

Prática recomendada

Tenha mais de um TargetServer na configuração do LoadBalancer para maior disponibilidade.
Sempre defina um monitor de integridade quando MaxFailures estiver definido como um valor diferente de zero. Um servidor de destino será removido da rotação quando o número de falhas atingir o número especificado em MaxFailures. Ter um HealthMonitor garante que o TargetServer seja colocado de volta na rotação assim que o servidor de destino ficar disponível novamente. Ou seja, não é necessário reimplantar o proxy.

Para garantir que a verificação de integridade seja realizada no mesmo número da porta que o Edge usa para se conectar aos servidores de destino, a Apigee recomenda omitir o elemento filho <Port> em <TCPMonitor>, a menos que ele seja diferente da porta TargetServer. Por padrão, <Port> é igual à porta TargetServer.

Exemplo de configuração com o HealthMonitor:
```
<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>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>
```
Se houver alguma restrição de forma que apenas um TargetServer e o HealthMonitor não sejam usados, não especifique MaxFailures na configuração de LoadBalancer.

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