Configurar
Para implantar essa solução de failover automatizado, configure o balanceador de carga, configure alarmes e notificações, crie uma função e configure o OCI API Gateway.
As seguintes etapas são detalhadas abaixo:
- O processo começa com a preparação do Balanceador de Carga, que requer a definição de listeners secundários e um conjunto de regras específico para controlar o comportamento de redirecionamento.
- Depois disso, configure um alarme e uma notificação para acionar a ação quando os servidores de aplicativos estiverem todos em um status não íntegro e quando os servidores íntegros estiverem disponíveis.
- Em seguida, você ativa a automação principal implantando um fuction usando o OCI Functions, que controla programaticamente o anexo ou a desanexação do conjunto de regras do balanceador de carga com base no estado de alarme atual.
- Por fim, configure o OCI API Gateway para hospedar sua página de manutenção estática personalizada.
Cada uma dessas configurações desempenha um papel específico e integrado ao permitir o failover contínuo e automatizado para uma página de manutenção amigável.
Configurar o Balanceador de Carga
A base dessa solução está no Balanceador de Carga, que já faz a frente do aplicativo e distribui o tráfego entre seus servidores de backend. Essas etapas pressupõem que a maioria dos pré-requisitos de implantação já esteja em vigor, incluindo um listener de aplicativos (HTTP ou HTTPS), um conjunto de backend com verificações de integridade configuradas e roteamento por meio de um Gateway de Internet para que os usuários possam acessar o serviço.
Comece com um listener principal no balanceador de carga, configurado para tratar o tráfego regular para o aplicativo. Quando tudo está funcionando normalmente, esse listener roteia as solicitações de entrada para o conjunto de backend de instâncias de VM. Ele ouve portas padrão (HTTP/80 ou HTTPS/443) e as verificações de integridade garantem que apenas VMs íntegras recebam tráfego.
Para servir à página de manutenção, adicione um segundo listener no balanceador de carga. Ao contrário do listener de aplicativos, este não encaminha solicitações para os servidores de aplicativos. Em vez disso, seu conjunto de backend aponta para uma instância do OCI API Gateway, que é responsável por hospedar a página de erro estático. Essa separação garante que, mesmo que todos os servidores de aplicativos estejam inativos, o balanceador de carga ainda possa apresentar uma página de manutenção com marca e informativa por meio do Gateway de API altamente disponível. A criação do listener secundário e das etapas do gateway de API são opcionais: a página de manutenção pode ser hospedada em qualquer lugar na internet.
A transferência entre esses dois listeners é gerenciada por meio de um conjunto de regras. O conjunto de regras é anexado ao listener do aplicativo e define as condições sob as quais o tráfego deve ser redirecionado. Em circunstâncias normais, o listener envia o tráfego diretamente para os servidores de aplicativos. No entanto, quando os servidores de aplicativos falham em suas verificações de integridade, o conjunto de regras entra em ação. Ele instrui o balanceador de carga a redirecionar o tráfego para o listener de manutenção, que, por sua vez, atende à página personalizada hospedada no Gateway de API.
As etapas a seguir descrevem como criar o conjunto de regras usado para redirecionar usuários para a página de manutenção.
Sobre Alarmes
Um alarme atua como uma ponte entre detecção e ação.
O serviço OCI Monitoring ouve as métricas de integridade dos componentes da sua implantação, incluindo o balanceador de carga, incluindo o status do conjunto de backend de VMs. Quando uma condição de alarme configurada no OCI Alarms é atendida (por exemplo, todas as VMs monitoradas não íntegras por mais de um minuto), ela aciona imediatamente uma notificação. Esta notificação não é apenas para administradores humanos. Você pode roteá-lo por meio de Notificações do OCI para chamar uma função personalizada implantada com o OCI Functions. Essa função atua para alterar a configuração do balanceador de carga para mostrar a página de erro personalizada.
A mensagem de notificação enviada à função contém dimensões — pares de chave/valor que descrevem a qual recurso e a qual conjunto de backend de VMs o evento de métrica pertence.
No corpo da configuração do alarme, você incluirá o seguinte código:
{{dimensions.resourceId}},{{dimensions.backendSetName}},<name of the ruleset>
Esta tabela descreve os componentes deste corpo de alarme:
| Elemento | Descrição | Objetivo |
|---|---|---|
{{dimensions.resourceId}} |
O OCID do recurso do balanceador de carga que gerou o evento de métrica | A função usa esse OCID para identificar qual balanceador de carga precisa da atualização do conjunto de regras |
{{dimensions.backendSetName}} |
O nome do conjunto de backend que não foi íntegro | A função pode validar ou registrar qual conjunto de backend falhou; útil para ambientes dinâmicos com vários conjuntos de backend |
<name of the ruleset> |
Um valor estático (string) — o nome do conjunto de regras a ser anexado quando todos os backends não estiverem íntegros | Informe à função qual conjunto de regras aplicar quando acionado |
Esse design permite reutilizar a mesma função para tratar tarefas como configurar um balanceador de carga para exibir a página de manutenção do servidor e rotear o tráfego de volta para o aplicativo real depois que os serviços forem restaurados. Essa abordagem também pode ser aplicada para gerenciar todos os balanceadores de carga ou aplicativos em balanceadores de carga em toda a implantação da OCI.
O serviço OCI Load Balancer publica automaticamente uma métrica chamada Unhealthybackendserver no namespace oci_lbaas. Ele rastreia o número de backends não íntegros em cada conjunto de backend.
Para efeitos desta solução, os itens importantes desta métrica são:
- Descrição
- Dimensões
- Regra do acionador
- Agrupamento de mensagens
Nesta solução, o alarme deverá ser acionado quando todos os servidores de backend (VMs) se tornarem não íntegros. Isso significa que a contagem de servidores não íntegros deve ser maior ou igual ao número total de servidores de backend no conjunto.
Aqui está um exemplo de consulta de Regra de Acionador de Alarme:
UnHealthyBackendServers[1m]{lbName = <name of lb>, backendSetName = <name of the backend set>}.max() >= 1A consulta se traduz no seguinte:
- Se o número máximo de backends não íntegros for maior ou igual a um valor específico (neste exemplo, 1)
- Por um período definido de 1 minuto.
- Em seguida, o alarme faz a transição para o estado
FIRING.
No entanto, esse preenchimento dinâmico de valores só funciona quando a opção Dividir Notificação está ativada no agrupamento de mensagens. A divisão de notificações força o OCI a enviar uma notificação por valor de dimensão, em vez de agrupar tudo. Por causa disso, a notificação de alarme que atinge sua função personalizada contém o OCID exato do balanceador de carga e o nome exato do conjunto de backend em que ocorreu a falha. Como resultado, a mesma função se torna totalmente reutilizável em vários balanceadores de carga, conjuntos de backend ou ambientes, sem detalhes do balanceador de carga de codificação.
Essa configuração permite que toda a cadeia de automação funcione — o alarme publica o contexto dinâmico, a função o lê e executa o anexo correto do conjunto de regras no listener exato que está servindo o aplicativo para o usuário final.
Configurar Alarmes e Notificações
Execute a etapa a seguir para configurar o alarme e a notificação para esta solução.
Crie uma Função
No centro da automação está uma função, que é acionada sempre que o alarme detecta que todos os backends de aplicativos não são saudáveis.
A função é simples, mas poderosa: atualiza dinamicamente a configuração do Balanceador de Carga anexando ou desanexando o conjunto de regras que trata o redirecionamento do tráfego.
O código Python dentro da função segue três etapas lógicas:
- Autenticação com o OCI: A função começa estabelecendo uma sessão segura com o OCI usando o Controlador de Recursos (é assim que as funções no OCI têm permissão para chamar outros serviços do OCI sem gerenciar manualmente as chaves). Isso garante que o código possa interagir com segurança com o serviço Load Balancer. Para obter mais informações sobre a autenticação, consulte os links em Explorar Mais.
- Chamada de API para modificar o listener do balanceador de carga: Após a autenticação, o código faz uma chamada para a API do balanceador de carga.
- Se os backends estiverem com falha, a função anexará o conjunto de regras de redirecionamento ao listener do aplicativo, redirecionando os usuários para a página de erro personalizada.
- Se os backends forem recuperados, a função desanexará o conjunto de regras, restaurando o fluxo de tráfego normal para os servidores de aplicativos.
- Log e Validação: O código também inclui log simples para que os administradores possam rastrear qual ação foi tomada: por exemplo, "Conjunto de regras da Página de Manutenção Anexada ao listener-1". Isso se torna extremamente útil durante a solução de problemas ou auditorias.
Use o exemplo de código Python a seguir para criar sua função no Oracle Functions, modificando-a conforme necessário.
Function.py
import io
import json
import os
import oci
from fdk import response
import logging
def handler(ctx, data: io.BytesIO=None):
message = "start of function"
logging.getLogger().info("HTTP function start")
try:
payload_bytes = data.getvalue()
if payload_bytes == b'':
raise KeyError('No keys in payload')
body1 = json.loads(payload_bytes)
type1 = body1["type"]
query = body1["body"]
load_balancer_ocid = query.split(",")[0]
maintenance = query.split(",")[2]
signer = oci.auth.signers.get_resource_principals_signer()
load_balancer_client = oci.load_balancer.LoadBalancerClient(config={}, signer=signer)
load_balancer_client_composite_ops = oci.load_balancer.LoadBalancerClientCompositeOperations(load_balancer_client)
load_balancer_data = json.loads(str(load_balancer_client.get_load_balancer(load_balancer_ocid).data))
lb_config = load_balancer_data['listeners']
list1 = json.dumps(lb_config)
for key,value in json.loads(list1).items():
if value['default_backend_set_name'] == query.split(",")[1]:
f_list = key
rulesets = value['rule_set_names']
if type1=="OK_TO_FIRING":
message = "FIRE"
if maintenance in rulesets:
message = "Already in Maintenance Mode"
logging.getLogger().info("Already in Manintenance mode")
else:
rulesets.insert(0, maintenance)
message = "Entering Maintenance Mode"
logging.getLogger().info("Entering Main mode")
load_balancer_client_composite_ops.update_listener_and_wait_for_state(
oci.load_balancer.models.UpdateListenerDetails(
default_backend_set_name=value["default_backend_set_name"],
rule_set_names=rulesets,
port=value["port"],
protocol=value["protocol"],
ssl_configuration=value["ssl_configuration"]
),
load_balancer_ocid,
key,
wait_for_states=[oci.load_balancer.models.WorkRequest.LIFECYCLE_STATE_SUCCEEDED]
)
elif type1=="FIRING_TO_OK":
message = "OK"
if maintenance in rulesets:
message = "Entering Operation Mode"
logging.getLogger().info("Entering Operation Mode")
rulesets.remove(maintenance)
load_balancer_client_composite_ops.update_listener_and_wait_for_state(
oci.load_balancer.models.UpdateListenerDetails(
default_backend_set_name=value["default_backend_set_name"],
rule_set_names=rulesets,
port=value["port"],
protocol=value["protocol"],
ssl_configuration=value["ssl_configuration"]
),
load_balancer_ocid,
key,
wait_for_states=[oci.load_balancer.models.WorkRequest.LIFECYCLE_STATE_SUCCEEDED]
)
else:
message = "Already in operation Mode"
logging.getLogger().info("Already in Operation mode")
except (Exception) as ex:
message = "Error:" + str(ex)
return message
Configurar Gateway de API do OCI
Nesta solução, o OCI API Gateway é configurado para atender diretamente a uma página Web estática.
Observação:
O uso do OCI API Gateway é opcional: você também pode hospedar sua página de manutenção/erro fora do OCI.Diferentemente do uso típico do OCI API Gateway em que as solicitações são roteadas para backends dinâmicos, como funções ou instâncias de computação, essa abordagem aproveita a capacidade do OCI API Gateway de hospedar uma resposta estática. Esta página estática funciona como uma mensagem de manutenção amigável, informando aos usuários que o serviço está temporariamente indisponível devido a manutenção programada ou outros problemas. A página estática é totalmente gerenciada pelo OCI API Gateway, removendo a necessidade de infraestrutura adicional, como servidores Web ou armazenamento de objetos.
Quando o sistema detecta que todos os servidores de backend não estão íntegros, a função acionada pelo alarme responderá configurando o balanceador de carga para redirecionar o tráfego para o listener secundário que faz front-end da instância do OCI API Gateway, garantindo uma experiência perfeita e fácil de usar sem expor páginas de erro padrão.
Neste exemplo, você só está focado nas etapas necessárias para configurar uma resposta estática usando o OCI API Gateway. Para obter mais informações, consulte os recursos em Explore Mais.