Manter uma aplicação no ar quando uma origem falha

Um time de SRE executa uma aplicação em uma origem primária e mantém uma cópia de reserva dela em um segundo data center, nuvem ou região. Os usuários precisam continuar sendo atendidos quando a primária falha, e a troca precisa acontecer do lado da Azion, sem mudança de DNS e sem lógica no cliente. Esta página agrupa as duas origens em um connector com Load Balancer, para que a origem de reserva só receba requisições quando a primária falha, e substitui a página de erro padrão da Azion pela sua quando nenhuma origem pode responder. O resultado é medido pela parcela das requisições que continuam com sucesso durante um incidente de origem e pela taxa de erro que os usuários veem enquanto o tráfego passa para a origem de reserva.

Este caso de uso não cobre a replicação de dados entre as origens nem a performance de uma única origem. Para uma única origem, consulte Acelerar sites e APIs com uma CDN.

Pré-requisitos

• Uma aplicação que serve o seu site por meio de um workload, com uma regra cujo behavior Set Connector envia as suas requisições a um connector da sua origem primária. Para criá-los, consulte Primeiros passos com Applications.
• Uma origem de reserva que guarda o mesmo conteúdo da primária e está configurada da mesma forma para a aplicação.
• Um segundo connector que serve a sua página de erro em /errors/503.html e não alcança nenhuma das origens, como um connector do tipo storage que lê um bucket do Object Storage. Para os seus campos, consulte Configurações de connector.
• Um personal token, para os passos pela API. Para criar um, consulte Gerencie personal tokens.
• Os nomes das suas origens e do seu domínio. Esta página usa app-origin para o connector da origem primária, primary.example.com para a origem primária, standby.example.com para a origem de reserva, error-pages para o connector da página de erro e www.example.com para o domínio. Cada origem adiciona um header de resposta X-Origin-Site com o valor primary ou standby, para que uma resposta nomeie a origem que respondeu. Substitua cada valor pelo seu em todos os passos.

Produtos necessários

Arquitetura de referência

Esta página constrói o Pool de origens ativo-passivo: um connector que agrupa uma origem primária e uma de reserva, com a origem de reserva atendendo só quando a primária falha.

Leia o diagrama a partir da aplicação. O Cache responde o que já guarda, e todas as outras requisições chegam a um connector, que guarda as duas origens. Dentro do connector, a função de cada endereço decide quem atende: a primária na operação normal, a de reserva só depois que a primária falha. O custom page set fica no fim do caminho de falha, para o momento em que nenhuma das origens pode responder.

Fluxo de dados

1. A requisição de um usuário chega à aplicação, e uma cópia válida que o Cache guarda a responde sem chegar a nenhuma das origens.
2. Qualquer outra requisição vai para o connector app-origin pela regra Set Connector da aplicação.
3. Load Balancer envia a requisição para primary.example.com, o único endereço Primary. A origem de reserva não recebe nada enquanto a primária responde, então só uma origem grava dados por vez.
4. Quando todos os endereços Primary falham, o que é detectado a partir de conexões que falharam ou excederam o tempo limite, Load Balancer envia a requisição para standby.example.com, o endereço Backup. A troca para a origem de reserva não precisa de mudança de DNS.
5. Quando nenhuma origem pode ser selecionada ou nenhuma responde a tempo, a Azion retorna 502, 503 ou 504, e o custom page set substitui essa resposta pela página que o connector error-pages serve, fora do pool.
6. Real-Time Metrics conta os status codes do domínio e, por requisição, a origem que respondeu, enquanto o tráfego passa para a origem de reserva e volta.

Componentes

• connector: o Platform Resource que agrupa as origens. Um connector, app-origin, guarda a primária e a de reserva, então a regra que o nomeia não precisa de mudança quando o tráfego passa de uma para a outra.
• Load Balancer: atribui a cada endereço a função Primary ou Backup. Os endereços Primary sempre têm preferência, e um endereço Backup só recebe requisições quando todos os endereços Primary falham. Max Retries, Connection Timeout e Read/Write Timeout decidem por quanto tempo uma conexão que falha segura uma requisição. O método IP Hash recusa endereços Backup.
• aplicação: o Platform Resource que roteia as requisições para app-origin com uma regra Set Connector e aplica as cache settings.
• Cache: continua respondendo o conteúdo que guarda enquanto as origens mudam. Com Stale cache ativo, ele também serve uma cópia expirada quando a origem retorna um erro 5xx ou excede o tempo limite.
• Custom Pages: o Platform Resource que substitui as respostas de erro da Azion por uma página sua. Cada página é buscada de um connector, então a página fica em error-pages, um connector que não alcança nenhuma das origens.
• Real-Time Metrics: mostra o tráfego por origem e os erros que os usuários veem, pelos status codes e pelo endereço upstream de cada requisição.

Outros designs para este caso de uso

• Pool de origens ativo-ativo entre nuvens: para times que atendem a partir de duas ou mais origens ao mesmo tempo, para distribuir a carga ou o custo. Todas as origens atendem tráfego ao vivo, então o design precisa de estado replicado ou compartilhado e de uma decisão de afinidade de sessão, e uma falha remove capacidade em vez de trocar de lado.
• Origem única com fallback para cache expirado: para aplicações com uma origem cujo conteúdo tolera ficar desatualizado por pouco tempo. Não há segunda origem, então o fluxo de falha serve conteúdo expirado em vez de trocar de origem, e só o conteúdo que já está em cache sobrevive à falha.

Configure o pool de origens

O pool de origens é o connector app-origin com Load Balancer ativo e dois endereços. A origem primária recebe a função Primary, então recebe todas as requisições enquanto responde. A origem de reserva recebe a função Backup, então fica em espera, fora do tráfego diário, e só recebe requisições quando todos os endereços Primary falham.

O pool é o procedimento que Adicione uma origem de backup a um connector descreve, executado em app-origin com estes valores:

• Addresses primary.example.com com Server Role Primary, e standby.example.com com Backup e Active ligado.
• Method Round Robin. Com um único endereço Primary, não há o que alternar, e IP Hash recusa endereços Backup com 28005.
• Max Retries 1. Uma conexão com a origem que falha é tentada de novo uma vez. O usuário espera por todas as novas tentativas antes de receber uma resposta, então uma nova tentativa limita essa espera.
• Connection Timeout 10 segundos. Uma origem que não aceita conexão em 10 segundos faz a conexão falhar, em vez de segurar o usuário pelos 60 segundos padrão da API.
• Read/Write Timeout 60 segundos, o valor que o Console preenche. Ele limita a espera por dados em uma conexão aberta com uma origem que parou de responder.

Load Balancer não tem health check: nenhuma sonda e nenhum intervalo, então nada testa nenhuma das origens entre as requisições. O padrão da API para Max Retries é 0, então um corpo de API ou de CLI define todos os valores explicitamente, como neste config:

O connector guarda a origem primária e a de reserva, e a regra que nomeia app-origin não precisa de mudança. Uma mudança de connector chega à infraestrutura distribuída da Azion ao longo de vários minutos, e os data centers a aplicam em momentos diferentes.

Os dois endereços recebem do connector o mesmo header Host, o mesmo prefixo de caminho e o mesmo protocolo. Quando a origem de reserva responde com outro nome que não o da primária, defina o Host do connector como ${host}, que envia o host que o usuário solicitou. Para as opções de conexão, consulte Configurações de connector.

Configure a página de erro quando nenhuma origem responde

Quando nenhuma origem pode responder, a Azion retorna um status code próprio: 502 quando nenhum servidor de origem pode ser selecionado ou a origem retorna uma resposta inválida, e 504 quando a origem não responde a tempo. Sem uma custom page, o usuário recebe a página intitulada Azion - Default error page. Um custom page set substitui essas respostas pela sua página.

O set desta seção liga 502, 503 e 504 a /errors/503.html no connector error-pages e responde cada um com 503. O status 503 marca uma condição temporária, que é o que uma falha de origem é. O Response TTL da página é 86400 segundos, um dia: uma página de erro é estática e raramente muda, e um TTL longo mantém as requisições longe do connector error-pages. A página vem de um connector que não alcança nenhuma das origens, porque uma página buscada do pool que falha falharia junto com ele.

O set é o que Mostre a sua própria página quando nenhuma origem responde cria e atribui, com estes valores:

O deployment do workload nomeia o set origin-down. Uma mudança de deployment leva vários minutos para chegar à infraestrutura distribuída da Azion, e as requisições podem receber a página padrão da Azion até que ela chegue.

Verifique a configuração

Cada verificação lê o header X-Origin-Site que as suas origens definem. Rode as verificações de falha em uma janela de manutenção, porque elas tiram uma origem de serviço.

• A primária atende enquanto responde. Envie várias requisições:

  curl -s -D - -o /dev/null https://www.example.com/

  Todas as respostas carregam x-origin-site: primary. Em HTTP/2, os nomes dos headers chegam em minúsculas.

• A origem de reserva assume quando a primária falha. Pare o servidor web em primary.example.com, ou bloqueie as conexões da Azion no firewall dela. Envie a requisição de novo, várias vezes. As respostas carregam x-origin-site: standby, sem mudança de DNS do seu lado.

• A primária recebe o tráfego de volta. Inicie de novo o servidor web em primary.example.com e envie a requisição várias vezes. As respostas voltam a carregar x-origin-site: primary, porque os endereços Primary sempre têm preferência sobre os endereços Backup.

• Os usuários recebem a sua página quando nenhuma origem responde. Pare as duas origens e envie a requisição. A resposta carrega o status 503 e o corpo de /errors/503.html, e não a página intitulada Azion - Default error page. Inicie as duas origens de novo.

Uma resposta de um data center que ainda não recebeu uma mudança de connector ou de deployment ainda pode mostrar o comportamento anterior. Repita a requisição até que as respostas concordem.

Medindo resultados

Boas práticas

• Teste a origem de reserva em toda janela de manutenção. Um endereço Backup não recebe tráfego enquanto a primária responde, então nada o exercita. Rode a verificação de falha desta página em cada janela de manutenção, para que uma origem de reserva que se afastou da primária seja encontrada antes de um incidente.
• Defina Max Retries e os timeouts em toda chamada de API. Um connector cuja configuração de Load Balancer é criada pela API recebe max_retries 0, connection_timeout 60 e read_write_timeout 120 para toda chave que o corpo deixa de fora. Um pool sem novas tentativas faz uma requisição falhar na primeira falha de conexão.
• Nunca coloque a página de erro atrás do pool que ela cobre. Uma custom page busca o seu conteúdo de um connector. Uma página servida por app-origin falha no mesmo incidente em que deveria aparecer.
• Deixe o Cache responder o que puder durante a troca. Uma requisição que uma cópia válida em cache responde nunca chega a nenhuma das origens. Com Stale cache ativo em uma cache setting, a Azion também serve uma cópia expirada quando a origem retorna um erro 5xx ou excede o tempo limite, por 300 segundos com Override cache behavior, e a resposta informa STALE. Para saber quando isso se aplica, consulte Expiração e atualização.
• Não use IP Hash neste pool. IP Hash mantém um cliente em um endereço e recusa endereços Backup com 28005. Um pool que precisa de afinidade de sessão entre várias origens ao vivo é o design Pool de origens ativo-ativo entre nuvens, e não este.

Guias deste caso de uso