Perspetiva do Well-Architected Framework no gestor de tráfego do Azure
O Azure Traffic Manager é um balanceador de carga global que pode distribuir o tráfego entre várias regiões do Azure, zonas dentro de uma região ou datacenters dentro dessas zonas. Ele usa o protocolo DNS (Sistema de Nomes de Domínio) para estabelecer um caminho de comunicação entre um cliente e os pontos de extremidade da sua carga de trabalho. Depois que a conexão é estabelecida, os clientes podem se conectar diretamente ao ponto de extremidade sem a ajuda do Gerenciador de Tráfego.
Este artigo pressupõe que, como arquiteto, você tenha revisado as opções de balanceamento de carga no Azure e escolhido o Gerenciador de Tráfego do Azure para sua carga de trabalho, que é implantada em várias regiões em um modelo ativo-ativo ou ativo-passivo. As orientações neste artigo fornecem recomendações de arquitetura mapeadas de acordo com os princípios dos pilares do Well-Architected Framework.
Importante
Como usar este guia
Cada seção tem uma lista de verificação de projeto que apresenta áreas arquitetônicas de preocupação, juntamente com estratégias de design localizadas para o escopo da tecnologia.
Também estão incluídas recomendações para os recursos tecnológicos que podem ajudar a materializar essas estratégias. As recomendações não representam uma lista exaustiva de todas as configurações disponíveis para o Gerenciador de Tráfego e suas dependências. Em vez disso, listam as recomendações-chave relacionadas às perspetivas de design. Use as recomendações para criar sua prova de conceito ou para otimizar seus ambientes existentes.
Arquitetura fundamental que demonstra as principais recomendações: balanceamento de carga multirregião com o Gerenciador de Tráfego, o Firewall do Azure e o Application Gateway.
Âmbito da tecnologia
Esta análise concentra-se nas decisões inter-relacionadas para o seguinte recurso do Azure:
- Gestor de Tráfego
Observação
Para cargas de trabalho que hospedam aplicativos HTTP, o Azure Front Door é uma escolha natural devido aos seus recursos, como uma rede de entrega de conteúdo, terminação TLS (Transport Layer Security) e um firewall integrado.
Em comparação com o Azure Front Door, o Traffic Manager é mais fácil de configurar, configurar e manter. O Gestor de Tráfego não tem um ponto de extremidade que você possa controlar diretamente. Ao contrário do Front Door, que lida com solicitações de clientes, o Traffic Manager conecta apenas clientes ao ponto de extremidade de uma carga de trabalho.
Mas essa simplicidade vem com compensações que podem introduzir complexidades em uma arquitetura. Por exemplo, talvez seja necessário implementar medidas de segurança adicionais para bloquear tipos de ataque do Open Worldwide Application Security Project (OWASP). Um Firewall de Aplicativo Web (WAF) no Azure Front Door ou no Azure Application Gateway fornece esse recurso. Ou você pode adicionar um cache, que pode acelerar a entrega de conteúdo, mas adiciona complexidade porque você deve gerenciar um armazenamento de dados.
Para obter mais informações, consulte Well-Architected Visão do framework sobre o Azure Front Door.
Fiabilidade
O objetivo do pilar Confiabilidade é fornecer funcionalidade contínua, criando resiliência suficiente e a capacidade de se recuperar rapidamente de falhas.
Os princípios de design de fiabilidade fornecem uma estratégia de design de alto nível aplicada a componentes individuais, aos fluxos do sistema e ao sistema como um todo.
Lista de verificação de design
Inicie sua estratégia de design com base na lista de verificação de revisão de projeto para Confiabilidade. Determine sua relevância para seus requisitos de negócios, tendo em mente a natureza de seu aplicativo e a criticidade de seus componentes. Alargar a estratégia de modo a incluir mais abordagens, conforme necessário.
Contabilize possíveis falhas. O Gestor de Tráfego foi concebido para ser resiliente. Mas ainda pode ser um único ponto de falha para sua carga de trabalho. Para reduzir esse risco, defina um caminho secundário para um serviço alternativo que se torne ativo se o Gerenciador de Tráfego não estiver disponível. Para evitar problemas de roteamento, não use o Gerenciador de Tráfego e o serviço alternativo juntos.
Ter um bom entendimento da cobertura do contrato de nível de serviço (SLA). Ao avaliar os SLAs do Gestor de Tráfego , compreenda a cobertura relacionada com o percentil publicado. Por exemplo, suas pesquisas de DNS podem falhar várias vezes. Essas falhas não são consideradas tempo de inatividade até que ocorra um minuto completo de falhas contínuas de pesquisa de DNS.
Incorpore redundância em sua arquitetura de carga de trabalho. Se o seu serviço estiver exposto através de um endereço IP público, utilize o Gestor de Tráfego para implementar redundância em regiões do Azure, no local e noutras nuvens. Por exemplo, você pode ter um aplicativo local que tenha uma instância secundária na nuvem. Se o sistema local falhar, a instância de nuvem pode ficar ativa, o que ajuda a garantir a continuidade.
Use uma arquitetura de implantação confiável para oferecer suporte à redundância. Como balanceador de carga, o Gerenciador de Tráfego distribui o tráfego entre pontos de extremidade de carga de trabalho com base em como você configura seu método de roteamento. Você define essa configuração em um perfil do Gerenciador de Tráfego. O perfil é um componente central da sua estratégia de implantação. Você pode usar a configuração de perfil apropriada para implementar um modelo ativo-ativo ou um modelo ativo-passivo que tenha uma reserva pronta.
Cada perfil especifica um único método de roteamento de tráfego. Alguns cenários exigem roteamento de tráfego mais sofisticado. Você pode combinar perfis do Gerenciador de Tráfego para aproveitar mais de um método de roteamento de tráfego.
Para obter mais informações, consulte métodos de roteamento do Gerenciador de Tráfego.
Avalie a duração do cache das respostas DNS. A configuração TTL (time-to-live) para pesquisas de DNS no Gerenciador de Tráfego determina por quanto tempo os resolvedores DNS downstream armazenam em cache as respostas DNS. O TTL padrão pode resultar em tempos de cache mais longos do que o necessário, o que pode causar interrupção se um ponto de extremidade falhar. Reduza o TTL para aumentar a frequência das atualizações de cache. Esse método pode ajudar a reduzir o tempo de inatividade, mas aumenta a frequência das pesquisas de DNS.
Evite enviar tráfego para instâncias instáveis ou comprometidas. Revise as funcionalidades de verificação de integridade incorporadas no Gestor de Tráfego.
Para aplicativos HTTPS e HTTP, implemente o padrão Health Endpoint Monitoring para fornecer uma página personalizada em seu aplicativo. Com base em verificações específicas, a página retorna um código de status HTTPS apropriado. Além da disponibilidade do ponto de extremidade, sua verificação de integridade deve monitorar todas as dependências do seu aplicativo.
Para outros aplicativos, o Gerenciador de Tráfego usa o protocolo TCP (Transmission Control Protocol) para determinar a disponibilidade do ponto de extremidade.
Para obter mais informações, consulte Health Endpoint Monitoring pattern e Compreender as sondas do Traffic Manager.
Determine sua tolerância a interrupções. Se um back-end ficar indisponível, pode passar algum tempo antes que o Traffic Manager reconheça a falha e pare de direcionar o tráfego para o ponto de extremidade indisponível. Há um período de tempo em que as solicitações dos clientes não podem ser atendidas. Use essa tolerância para definir as configurações de teste, que determinam a rapidez com que você deseja iniciar suas operações de continuidade de negócios.
Inclua os pontos de extremidade como parte integrante do seu teste de resiliência. Simule endpoints indisponíveis para ver como o Traffic Manager lida com falhas. Suponha que sua carga de trabalho use um balanceador de carga como o Application Gateway em uma rede virtual privada. Pode usar regras do grupo de segurança de rede (NSG) no Azure Chaos Studio para simular falhas no endpoint. Você pode bloquear o acesso à sub-rede onde o Application Gateway reside.
Recomendações
| Recomendação | Benefício |
|---|---|
| Implante vários pontos de extremidade nos perfis do Gestor de Tráfego e ativa-os. Se um endpoint não estiver ativado, ele não será testado para análises de saúde ou incluído na rotação de roteamento de tráfego. Coloque esses pontos de extremidade em regiões diferentes. | As instâncias redundantes contribuem para garantir a disponibilidade caso um ponto de extremidade falhe. |
| Avalie os vários métodos de roteamento de tráfego . Configure um ou uma combinação de métodos para alinhar com sua estratégia de implantação. O Gerenciador de Tráfego aplica o método escolhido a cada consulta DNS e usa o método para determinar qual ponto de extremidade é retornado na resposta DNS. - O método ponderado distribui o tráfego com base no coeficiente de peso configurado. Este método suporta modelos ativo-ativo. - O método baseado em prioridade configura a região primária para receber tráfego e enviá-lo para a região secundária como um backup. Este método suporta modelos ativo-passivo. - O método geográfico roteia o tráfego com base na origem geográfica da consulta DNS. Para cobrir todas as regiões, configure pelo menos um ponto de extremidade com a propriedade All (World). |
Um método de roteamento otimizado ajuda a garantir que você distribua o tráfego de forma eficiente entre seus endpoints. Você pode dar suporte às metas do modelo de implantação ativo-ativo ou ativo-passivo. Um método de roteamento eficiente ajuda a garantir que as regiões secundárias possam lidar com o tráfego ou atuar como backup. O roteamento geográfico ajuda a direcionar os usuários para o ponto de extremidade mais próximo com base em sua localização. Ele ajuda a garantir que o tráfego seja gerenciado de forma eficiente e não seja perdido. |
| Defina o intervalo TTL DNS duração para um valor baixo, de preferência inferior a 60 segundos. Para otimizar o desempenho, ajuste a temporização da sonda de integridade e o TTL do registo DNS. | Uma baixa duração do TTL ajuda a garantir atualizações de cache do resolvedor de DNS downstream mais frequentes e failover mais rápido. Ele também minimiza o tempo de inatividade e melhora a capacidade de resposta geral do seu aplicativo. |
| Configurar testes de integridade para monitorizar o ponto de extremidade. - Não habilite AlwaysServe, que desativa o monitoramento de endpoint e envia solicitações para o endpoint, independentemente de seu estado de integridade. - Defina o valor probing interval. Considere a compensação entre a rapidez com que consegue detetar falhas e o número de solicitações para o endpoint. O número de solicitações pode ser substancial porque o Gerenciador de Tráfego é um serviço global que faz ping simultaneamente de vários locais. - Defina o valor probe timeout. Considere quanto tempo esperar antes de declarar o endpoint não funcional. Inclua os falsos positivos no número de falhas. |
As sondas de integridade garantem que apenas instâncias saudáveis consigam responder às solicitações do usuário. Eles também ajudam a determinar se as falhas não são transitórias e com que rapidez as operações de failover devem ocorrer. |
Segurança
O objetivo do pilar Segurança é fornecer confidencialidade, integridade e disponibilidade garantias para a carga de trabalho.
Os princípios de conceção de segurança fornecem uma estratégia de conceção de alto nível para alcançar esses objetivos, aplicando abordagens ao projeto técnico do Gestor de Tráfego.
Lista de verificação de design
Revisão dos padrões de segurança. Para melhorar sua postura de segurança, revise a linha de base de segurança do Gerenciador de Tráfego.
Impedir a modificação não autorizada do roteamento de tráfego. Trate os perfis do Gerenciador de Tráfego como recursos críticos de carga de trabalho porque eles contêm as definições de configuração para rotear o tráfego. Apenas identidades autorizadas devem ter acesso a esses perfis. Implemente controle de acesso baseado em função (RBAC) no plano de controle para restringir tarefas como criar, excluir ou modificar recursos. Somente identidades autorizadas devem ter autoridade para habilitar ou desabilitar terminais. O acesso não autorizado pode resultar em alterações de configuração e potencialmente redirecionar o tráfego para implementações maliciosas.
Proteja os aplicativos contra ameaças na borda da rede. O Gestor de Tráfego não fornece funcionalidades de segurança incorporadas, como um WAF. Para ajudar a proteger aplicações HTTP, deve implementar a inspeção de tráfego ao nível do ponto final.
Uma arquitetura típica pode incluir o Gestor de Tráfego e vários endpoints. Para cada ponto de extremidade, um gateway de aplicações que trata da terminação TLS e de outras funções de segurança fornece proteção. Para obter uma arquitetura de referência que demonstre esse padrão, consulte balanceamento de carga multirregião com o Gerenciador de Tráfego, o Firewall do Azure e o Gateway de Aplicativo.
Proteja as entradas DNS. O Gerenciador de Tráfego pode ser suscetível a ataques que manipulam dados DNS, o que pode redirecionar o tráfego para sites mal-intencionados e causar problemas de segurança. Uma ameaça comum é uma aquisição de subdomínio, na qual um registro DNS aponta para um recurso do Azure desprovisionado. Para evitar aquisições de subdomínios, use registros de alias DNS do Azure e associe o ciclo de vida de um registro DNS a um recurso do Azure.
Para obter mais informações, consulte Impedir entradas DNS pendentes.
Recomendações
| Recomendação | Benefício |
|---|---|
|
Adicione gateways de aplicação aos terminais de carga de trabalho. Para implementar a inspeção de segurança com um firewall para aplicações HTTP, adicione gateways de aplicações aos endpoints de workloads. |
Você pode inspecionar o tráfego HTTP de entrada para ajudar a proteger o aplicativo contra ataques comuns. |
| Crie um de registro de alias no DNS do Azure para o nome de domínio do ápice da sua carga de trabalho para fazer referência a um perfil do Gerenciador de Tráfego. | Os registros de alias associam firmemente o ciclo de vida de um registro DNS a um recurso do Azure. Essa configuração ajuda a evitar referências pendentes se a carga de trabalho for descomissionada. Se o perfil do Gerenciador de Tráfego for excluído, o registro de alias DNS se tornará um conjunto de registros vazio. Ele não faz mais referência ao recurso excluído. |
Otimização de Custos
A Otimização de Custos concentra-se em detetar padrões de gastos, priorizar investimentos em áreas críticas e otimizar em outras para atender ao orçamento da organização enquanto atende aos requisitos de negócios.
Os princípios de design para Otimização de Custos fornecem uma estratégia de design de alto nível para alcançar esses objetivos e efetuar compromissos conforme necessário no design técnico relacionado ao Gestor de Tráfego e ao seu ambiente.
Lista de verificação de design
Inicie sua estratégia de design com base na lista de verificação de revisão de projeto para Otimização de Custos para investimentos. Ajuste o design para que a carga de trabalho esteja alinhada com o orçamento alocado para a carga de trabalho. Seu design deve usar os recursos certos do Azure, monitorar investimentos e encontrar oportunidades para otimizar ao longo do tempo.
Avalie o custo das funcionalidades. O recurso de painel de exibição de tráfego mostra de onde seus clientes se conectam e a latência associada. Essas informações ajudam a otimizar o desempenho e refinar seu projeto, o que contribui para a excelência operacional e a eficiência do sistema. No entanto, implica custos adicionais. Para obter mais informações, consulte a seção de faturamento da Visualização de tráfego.
Considere também o custo associado às sondas de saúde. O Gestor de Tráfego efetua pings nos seus pontos finais definidos a partir de várias localizações para verificar a sua disponibilidade. Você pode escolher pings lentos e pings rápidos. Os pings rápidos detetam falhas mais rapidamente, mas incorrem em custos mais elevados. Eles também adicionam mais carga à carga de trabalho porque as verificações de integridade são mais frequentes.
Avalie o custo da sua estratégia de roteamento. Por exemplo, se a maioria dos clientes acessar seu ponto de extremidade de uma região de alta latência, você poderá criar outro ponto de extremidade mais próximo desses usuários e ajustar o método de roteamento no Gerenciador de Tráfego. Essa prática reduz a latência para que você possa processar mais solicitações com menos capacidade, o que leva a economias de custos.
Recomendações
Excelência Operacional
A Excelência Operacional concentra-se principalmente em procedimentos para práticas de desenvolvimento de , observabilidade e gerenciamento de releases.
Os princípios de design Excelência Operacional fornecer uma estratégia de design de alto nível para alcançar essas metas para os requisitos operacionais da carga de trabalho.
Lista de verificação de design
Colete e analise dados operacionais como parte do monitoramento de sua carga de trabalho. Capture logs e métricas relevantes do Gerenciador de Tráfego. Use esses dados para solucionar problemas, entender os comportamentos do tráfego e ajustar a lógica de roteamento.
Ver dados de tráfego para perfis. Esses dados ajudam a identificar áreas para melhorias, como expandir sua presença do Azure em regiões de alta latência. Ele também destaca padrões de tráfego em diferentes regiões para ajudá-lo a determinar onde aumentar ou diminuir o investimento.
Implementar operações de recuperação de desastres. Sua implementação de recuperação de desastres pode ser projetada para redirecionar o tráfego de rede/web do site principal para um site de backup. Esse método de recuperação de desastres pode ser implementado usando o DNS do Azure e o Gerenciador de Tráfego do Azure (DNS). Em caso de desastre, se o ponto de extremidade primário ficar degradado, o Gerenciador de Tráfego redirecionará o tráfego para um ponto de extremidade secundário íntegro. Por padrão, o Gestor de Tráfego dá prioridade ao ponto de extremidade principal, mas também pode ser configurado com pontos de extremidade de redundância adicionais ou balanceadores de carga para distribuir a carga de tráfego. Para obter mais informações, consulte Configurar a recuperação de desastres e a deteção de interrupções.
Evite operações de failback automático. Ao fazer um failback, não use o failback automático, que volta imediatamente para o ponto de extremidade original no primário quando estiver disponível. Em vez disso, desative o ponto de extremidade original e use o ponto de extremidade secundário até desejar alternar. Esta abordagem proporciona tempo para a estabilização. O failback imediato pode criar carga extra e atrasos.
Para obter mais informações, consulte a arquitetura de referência de balanceamento de carga multirregião .
Teste as definições de configuração. Erros de configuração podem afetar todos os aspetos da carga de trabalho, especialmente a confiabilidade. Teste as configurações com vários clientes em vários locais. Para obter mais informações, consulte Verificar as configurações do Gerenciador de Tráfego.
Recomendações
| Recomendação | Benefício |
|---|---|
|
Habilitar logs de diagnóstico para um perfil do Gestor de Tráfego. Utilize ferramentas para reproduzir registos e analisar os dados de verificação de integridade. |
Os logs de diagnóstico fornecem informações sobre o comportamento do perfil do Gerenciador de Tráfego. Por exemplo, você pode identificar os motivos para tempos limite de teste individuais em relação a um ponto de extremidade. |
| Habilite o painel de exibição de tráfego . Obtenha informações sobre de onde seus clientes se conectam e a latência associada. | Essas informações ajudam a otimizar o desempenho e o custo, pois você pode refinar seu projeto. |
| Aproveite o Heat Map REST API, que fornece dados sobre locais e latência do cliente. | Essa abordagem oferece flexibilidade, como a definição de um período de tempo específico. Você pode adicionar dados a ferramentas ou painéis personalizados. Você também pode usar essa API para integrar com ferramentas externas. |
| Desativar os endpoints para atividades operacionais. Por exemplo, você pode desabilitar o failback após um failover para fazer manutenção ou teste. | Desativar o ponto de extremidade do balanceador de carga é benéfico para tarefas operacionais porque não se pode parar o tráfego em tempo real. Durante a manutenção, as instâncias não recebem tráfego se desativares o endpoint. Essa abordagem evita o failback automático. |
Eficiência de desempenho
A Eficiência de Desempenho tem a ver manter a experiência do usuário, mesmo quando há um aumento na de carga por meio do gerenciamento de capacidade. A estratégia inclui dimensionar recursos, identificar e otimizar potenciais gargalos e otimizar para obter o máximo desempenho.
Os princípios de design de Eficiência de Desempenho fornecem uma estratégia de design de alto nível para atingir essas metas de capacidade de acordo com o uso esperado.
Lista de verificação de design
Inicie sua estratégia de design com base na lista de verificação de revisão de projeto para Eficiência de desempenho. Defina uma linha de base baseada em indicadores-chave de desempenho para o Traffic Manager.
Meça o impacto no desempenho da sua configuração. O Traffic Manager não interfere na conexão direta entre o cliente e seu endpoint. O principal impacto no desempenho é a pesquisa inicial de DNS. A configuração TTL afeta a frequência com que essa pesquisa ocorre. Um TTL mais baixo significa resoluções de DNS mais frequentes, o que pode afetar ligeiramente o desempenho. Se definir o TTL como zero, cada solicitação exigirá uma pesquisa de DNS, o que adiciona um pequeno atraso antes de aceder ao endpoint.
Como o Gerenciador de Tráfego opera no nível DNS, ele não oferece suporte à afinidade de sessão. O Traffic Manager pode direcionar os usuários para pontos de extremidade diferentes para cada chamada. Se precisar de afinidade de sessão, deve-se guardar o estado num repositório de dados separado.
Para obter mais informações, consulte Considerações de desempenho para o Gerenciador de Tráfego.
Ajuste o comportamento de roteamento de tráfego para otimizar o desempenho. Um único perfil pode ter vários pontos de extremidade, mas você pode aplicar apenas um método de roteamento de cada vez.
Para cenários mais complexos, considere a criação de uma hierarquia de perfis para combinar diferentes métodos de roteamento. Por exemplo, você pode priorizar regiões e, em seguida, usar o roteamento baseado no desempenho dentro das regiões.
Recomendações
| Recomendação | Benefício |
|---|---|
| Use o método de roteamento de desempenho quando tiver pontos de extremidade em locais geográficos diferentes. | Esse método prioriza o envio de tráfego para o ponto de extremidade que tem a menor latência. Esse método ajuda a garantir um serviço rápido para os usuários. |
| Use ferramentas especializadas para otimizar o desempenho. Meça o desempenho das suas pesquisas de DNS. Para analisar o desempenho do tráfego, use o painel de exibição de tráfego ou a API REST do Heat Map. | As ferramentas de medição de latência DNS executam uma pesquisa completa de DNS e fornecem dados de desempenho. Você pode usar esses dados para definir a duração do TTL e otimizar o desempenho. |
| Combine métodos de tráfego com perfis aninhados para obter um desempenho ideal, conforme os seus requisitos de carga de trabalho. | Um método de roteamento otimizado ajuda a garantir que o tráfego seja direcionado para os pontos de extremidade mais responsivos e mais próximos. Essa abordagem ajuda a melhorar o desempenho do aplicativo e a experiência do usuário. |
| Use o recurso de medições reais do usuário para exibir medições de latência de rede para regiões do Azure. Esta funcionalidade está disponível sem custos adicionais. | Você pode tomar decisões de roteamento orientadas por dados para direcionar consultas para a região do Azure que fornece a menor latência. |
| Defina o intervalo TTL de DNS para um valor mais alto. | Os clientes podem armazenar os resultados em cache por um longo período de tempo, o que reduz a necessidade de resolver o DNS a cada vez. |
Políticas do Azure
O Azure fornece um extenso conjunto de políticas internas relacionadas ao Gerenciador de Tráfego e suas dependências. Algumas das recomendações anteriores podem ser auditadas por meio da Política do Azure. Por exemplo, pode verificar se:
- Os logs de recursos são ativados para acompanhar atividades.
- Os logs para perfis do Gerenciador de Tráfego são enviados para os Hubs de Eventos do Azure.
Para obter uma governança abrangente, revise as definições internas da Política do Azure para os serviços de rede do Azure.
Recomendações do Azure Advisor
Azure Advisor é um consultor de nuvem personalizado que ajuda você a seguir as práticas recomendadas para otimizar suas implantações do Azure. Aqui estão algumas recomendações que podem ajudá-lo a melhorar a confiabilidade, a segurança, a relação custo-benefício, o desempenho e a excelência operacional de suas instâncias de aplicativos Web.
Trocas
Pode ser necessário fazer concessões de design se usar as abordagens das listas de verificação dos pilares. Aqui estão alguns exemplos de vantagens e desvantagens.
Confiabilidade e Eficiência de Desempenho
A configuração TTL para pesquisas de DNS. A configuração TTL padrão pode resultar em tempos de cache mais longos. Longos tempos de cache podem causar tempo de paragem se um ponto de extremidade falhar, porque a aplicação continua a tentar uma conexão com o ponto de extremidade falhado durante a duração do TTL.
Reduza o TTL para ajudar a mitigar esse problema. Um TTL mais baixo tem atualizações mais frequentes e transição automática mais rápida, mas aumenta a frequência de consultas DNS. Essa abordagem pode afetar o desempenho e aumentar a carga nos servidores DNS.
Fiabilidade e Otimização de Custos
- Sondas de saúde. O Traffic Manager usa sondas de integridade para executar ping em seus endpoints de vários locais para verificar sua disponibilidade. Você pode escolher pings lentos ou pings rápidos. Os pings rápidos detetam falhas mais rapidamente, mas aumentam o custo. Os pings lentos levam mais tempo para detetar falhas, mas custam menos. Equilibre a velocidade de deteção e recuperação de falhas com os custos associados.
Próximo passo
Considere os seguintes recursos que demonstram as recomendações neste artigo.
Use a seguinte arquitetura de referência como exemplo de como aplicar as diretrizes deste artigo a uma carga de trabalho:
Use a seguinte documentação do produto para melhorar sua experiência em implementação: