Lista de verificação de resiliência para serviços específicos do Azure

  • Artigo

Resiliência é a capacidade de recuperação de falhas e continuação de funcionamento de um sistema. Cada tecnologia tem seus próprios modos de falha específicos, que você deve considerar ao projetar e implementar seu aplicativo. Use esta lista de verificação para revisar as considerações de resiliência para serviços específicos do Azure. Para obter mais informações sobre como projetar aplicativos resilientes, consulte Projetar aplicativos confiáveis do Azure.

Serviço de Aplicações

Use o nível Standard ou Premium. Essas camadas oferecem suporte a slots de preparo e backups automatizados. Para obter mais informações, consulte Visão geral detalhada dos planos do Serviço de Aplicativo do Azure

Evite aumentar ou diminuir a escala. Em vez disso, selecione uma camada e um tamanho de instância que atendam aos seus requisitos de desempenho sob carga típica e, em seguida , dimensione as instâncias para lidar com alterações no volume de tráfego. A expansão para cima e para baixo pode desencadear uma reinicialização do aplicativo.

Configuração da loja como definições da aplicação. Use as configurações do aplicativo para manter as definições de configuração como configurações do aplicativo. Defina as configurações em seus modelos do Gerenciador de Recursos ou usando o PowerShell, para que você possa aplicá-las como parte de um processo automatizado de implantação/atualização, que é mais confiável. Para obter mais informações, consulte Configurar aplicativos Web no Serviço de Aplicativo do Azure.

Crie planos separados do Serviço de Aplicativo para produção e teste. Não use slots em sua implantação de produção para testes. Todos os aplicativos dentro do mesmo plano do Serviço de Aplicativo compartilham as mesmas instâncias de VM. Se você colocar as implantações de produção e teste no mesmo plano, isso poderá afetar negativamente a implantação de produção. Por exemplo, os testes de carga podem degradar o local de produção ao vivo. Ao colocar implantações de teste em um plano separado, você as isola da versão de produção.

Separe os aplicativos Web das APIs da Web. Se sua solução tiver um front-end da Web e uma API da Web, considere decompô-los em aplicativos separados do Serviço de Aplicativo. Esse design facilita a decomposição da solução por carga de trabalho. Você pode executar o aplicativo Web e a API em planos separados do Serviço de Aplicativo, para que eles possam ser dimensionados de forma independente. Se você não precisar desse nível de escalabilidade no início, poderá implantar os aplicativos no mesmo plano e movê-los para planos separados mais tarde, se necessário.

Implante planos do Serviço de Aplicativo com redundância de zona. Em regiões com suporte, os planos do Serviço de Aplicativo podem ser implantados como zona redundante, o que significa que as instâncias são distribuídas automaticamente entre zonas de disponibilidade. O Serviço de Aplicativo distribui automaticamente o tráfego entre as zonas e lida com o failover se uma zona sofrer uma interrupção. Para obter mais informações, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.

Evite usar o recurso de backup do Serviço de Aplicativo para fazer backup de bancos de dados SQL do Azure. Em vez disso, use backups automatizados do Banco de dados SQL. O backup do Serviço de Aplicativo exporta o banco de dados para um arquivo SQL BACPAC, que custa DTUs.

Implementar num bloco de teste. Crie um slot de implantação para preparação. Implante atualizações de aplicativos no slot de preparo e verifique a implantação antes de trocá-la para a produção. Isso reduz a chance de uma atualização ruim na produção. Ele também garante que todas as instâncias sejam aquecidas antes de serem trocadas para a produção. Muitas aplicações têm um tempo significativo de aquecimento e arranque a frio. Para obter mais informações, consulte Configurar ambientes de preparo para aplicativos Web no Serviço de Aplicativo do Azure.

Crie um slot de implantação para manter a implantação LKG (Last Known-Good). Ao implantar uma atualização na produção, mova a implantação de produção anterior para o slot LKG. Isso facilita a reversão de uma implantação incorreta. Se você descobrir um problema mais tarde, você pode reverter rapidamente para a versão LKG. Para obter mais informações, consulte Aplicativo Web básico.

Habilite o log de diagnóstico, incluindo o log de aplicativos e o log do servidor Web. O registro em log é importante para monitoramento e diagnóstico. Consulte Habilitar o log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure

Registre-se no armazenamento de blob. Isso facilita a coleta e a análise dos dados.

Crie uma conta de armazenamento separada para logs. Não use a mesma conta de armazenamento para logs e dados de aplicativos. Isso ajuda a evitar que o registro em log reduza o desempenho do aplicativo.

Monitore o desempenho. Use um serviço de monitoramento de desempenho, como o New Relic ou o Application Insights , para monitorar o desempenho e o comportamento do aplicativo sob carga. O monitoramento de desempenho oferece informações em tempo real sobre o aplicativo. Ele permite diagnosticar problemas e executar a análise de causa básica de falhas.

Balanceador de Carga do Azure

Selecione SKU padrão. O Standard Load Balancer fornece uma dimensão de confiabilidade que o Basic não fornece - a de zonas de disponibilidade e resiliência de zona. Isso significa que, quando uma zona fica inativa, seu balanceador de carga padrão com redundância de zona não será afetado. Isso garante que suas implantações possam suportar falhas de zona dentro de uma região. Além disso, o Standard Load Balancer oferece suporte ao balanceamento de carga global, garantindo que seu aplicativo também não seja afetado por falhas de região.

Provisão de pelo menos duas instâncias. Implante o Azure LB com pelo menos duas instâncias no back-end. Uma única instância pode resultar em um único ponto de falha. Para criar para escala, convém emparelhar LB com Conjuntos de Dimensionamento de Máquina Virtual.

Use regras de saída. As regras de saída garantem que você não seja confrontado com falhas de conexão como resultado do esgotamento da porta SNAT. Saiba mais sobre a conectividade de saída. Embora as regras de saída ajudem a melhorar a solução para implantações de pequeno a médio porte, para cargas de trabalho de produção, recomendamos o acoplamento do Standard Load Balancer ou de qualquer implantação de sub-rede com VNet NAT.

Gateway de Aplicação

Provisão de pelo menos duas instâncias. Implante o Application Gateway com pelo menos duas instâncias. Uma única instância é um único ponto de falha. Use duas ou mais instâncias para redundância e escalabilidade. Para se qualificar para o SLA, você deve provisionar duas ou mais instâncias médias ou maiores.

BD do Cosmos para o Azure

Configure a redundância de zona. Quando você usa redundância de zona, o Azure Cosmos DB replica de forma síncrona todas as gravações em zonas de disponibilidade. Ele faz failover automaticamente no caso de uma interrupção de zona. Para obter mais informações, consulte Obter alta disponibilidade com o Azure Cosmos DB.

Replique o banco de dados entre regiões. O Azure Cosmos DB permite associar qualquer número de regiões do Azure a uma conta de banco de dados do Azure Cosmos DB. Um banco de dados do Azure Cosmos DB pode ter uma região de gravação e várias regiões de leitura. Se houver uma falha na região de gravação, você poderá ler a partir de outra réplica. O SDK do cliente lida com isso automaticamente. Você também pode fazer failover da região de gravação para outra região. Para obter mais informações, veja Como distribuir dados globalmente com o Azure Cosmos DB.

Event Hubs

Use pontos de verificação. Um consumidor de eventos deve gravar sua posição atual no armazenamento persistente em algum intervalo predefinido. Dessa forma, se o consumidor tiver uma falha (por exemplo, o consumidor trava ou o host falha), uma nova instância pode retomar a leitura do fluxo da última posição registrada. Para obter mais informações, consulte Consumidores de eventos.

Manipule mensagens duplicadas. Se um consumidor de eventos falhar, o processamento de mensagens será retomado a partir do último ponto de verificação registrado. Todas as mensagens que já foram processadas após o último ponto de verificação serão processadas novamente. Portanto, sua lógica de processamento de mensagens deve ser idempotente, ou o aplicativo deve ser capaz de desduplicar mensagens.

Lidar com exceções.. Um consumidor de eventos normalmente processa um lote de mensagens em um loop. Você deve lidar com exceções dentro desse loop de processamento para evitar a perda de um lote inteiro de mensagens se uma única mensagem causar uma exceção.

Use uma fila de mensagens mortas. Se o processamento de uma mensagem resultar em uma falha não transitória, coloque a mensagem em uma fila de mensagens mortas, para que você possa acompanhar o status. Dependendo do cenário, você pode repetir a mensagem mais tarde, aplicar uma transação de compensação ou executar alguma outra ação. Observe que os Hubs de Eventos não têm nenhuma funcionalidade interna de fila de mensagens mortas. Você pode usar o Armazenamento de Filas do Azure ou o Barramento de Serviço para implementar uma fila de mensagens mortas ou usar o Azure Functions ou algum outro mecanismo de eventos.

Configure a redundância de zona. Quando a redundância de zona está habilitada em seu namespace, os Hubs de Eventos replicam automaticamente as alterações entre várias zonas de disponibilidade. Se uma zona de disponibilidade falhar, o failover acontece automaticamente. Para obter mais informações, consulte Zonas de disponibilidade.

Implemente a recuperação de desastres fazendo failover para um namespace secundário de Hubs de Eventos. Para obter mais informações, consulte Recuperação de desastres geográficos dos Hubs de Eventos do Azure.

Cache do Azure para Redis

Configure a redundância de zona. Quando a redundância de zona está habilitada em seu cache, o Cache Redis do Azure espalha as máquinas virtuais que hospedam seu cache em várias zonas de disponibilidade. A redundância de zona oferece alta disponibilidade e tolerância a falhas no caso de uma interrupção do data center. Para obter mais informações, consulte Habilitar redundância de zona para o Cache do Azure para Redis.

Configure a replicação geográfica. A replicação geográfica fornece um mecanismo para vincular duas instâncias do Cache do Azure para Redis de camada Premium. Os dados gravados no cache primário são replicados para um cache secundário somente leitura. Para obter mais informações, consulte Como configurar a replicação geográfica para o Cache Redis do Azure

Configure a persistência de dados. A persistência de Redis permite-lhe manter os dados armazenados na cache de Redis. Você também pode tirar instantâneos e fazer backup dos dados, que podem ser carregados em caso de falha de hardware. Para obter mais informações, consulte Como configurar a persistência de dados para um Cache Redis do Azure de camada Premium

Se você estiver usando o Cache Redis do Azure como um cache de dados temporário e não como um armazenamento persistente, essas recomendações podem não se aplicar.

Provisione mais de uma réplica. Use pelo menos duas réplicas para alta disponibilidade de leitura ou três para alta disponibilidade de leitura-gravação.

Use redundância de zona. Você pode implantar réplicas da Pesquisa Cognitiva em várias zonas de disponibilidade. Essa abordagem ajuda seu serviço a permanecer operacional mesmo quando ocorrem interrupções do data center. Para obter mais informações, consulte Confiabilidade na Pesquisa Cognitiva do Azure

Configure indexadores para implantações em várias regiões. Se você tiver uma implantação em várias regiões, considere suas opções de continuidade na indexação.

  • Se a fonte de dados for replicada geograficamente, você geralmente deve apontar cada indexador de cada serviço regional de Pesquisa Cognitiva do Azure para sua réplica de fonte de dados local. No entanto, essa abordagem não é recomendada para grandes conjuntos de dados armazenados no Banco de Dados SQL do Azure. O motivo é que a Pesquisa Cognitiva do Azure não pode executar indexação incremental de réplicas secundárias do Banco de Dados SQL, somente de réplicas primárias. Em vez disso, aponte todos os indexadores para a réplica primária. Após um failover, aponte os indexadores da Pesquisa Cognitiva do Azure para a nova réplica primária.

  • Se a fonte de dados não for replicada geograficamente, aponte vários indexadores para a mesma fonte de dados, para que os serviços de Pesquisa Cognitiva do Azure em várias regiões indexem a fonte de dados de forma contínua e independente. Para obter mais informações, consulte Considerações sobre desempenho e otimização da Pesquisa do Azure.

Service Bus

Use a camada Premium para cargas de trabalho de produção. O Service Bus Premium Messaging fornece recursos de processamento dedicados e reservados e capacidade de memória para suportar desempenho e taxa de transferência previsíveis. O nível de Mensagens Premium também oferece acesso a novos recursos que estão disponíveis apenas para clientes premium no início. Você pode decidir o número de unidades de mensagens com base nas cargas de trabalho esperadas.

Manipule mensagens duplicadas. Se um editor falhar imediatamente após o envio de uma mensagem ou tiver problemas de rede ou sistema, ele pode erroneamente falhar ao registrar que a mensagem foi entregue e pode enviar a mesma mensagem para o sistema duas vezes. O Barramento de Serviço pode lidar com esse problema habilitando a deteção de duplicados. Para obter mais informações, consulte Deteção de duplicatas.

Lidar com exceções. As APIs de mensagens geram exceções quando ocorre um erro do usuário, erro de configuração ou outro erro. O código do cliente (remetentes e destinatários) deve lidar com essas exceções em seu código. Isso é especialmente importante no processamento em lote, onde o tratamento de exceções pode ser usado para evitar a perda de um lote inteiro de mensagens. Para obter mais informações, consulte Exceções de mensagens do Service Bus.

Política de novas tentativas. O Service Bus permite que você escolha a melhor política de repetição para seus aplicativos. A política padrão é permitir 9 tentativas máximas de repetição e aguardar 30 segundos, mas isso pode ser ajustado. Para obter mais informações, consulte Política de repetição – Service Bus.

Use uma fila de mensagens mortas. Se uma mensagem não puder ser processada ou entregue a qualquer destinatário após várias tentativas, ela será movida para uma fila de letra morta. Implemente um processo para ler mensagens da fila de mensagens mortas, inspecioná-las e corrigir o problema. Dependendo do cenário, você pode repetir a mensagem no estado em que se encontra, fazer alterações e repetir ou descartar a mensagem. Para obter mais informações, consulte Visão geral das filas de cartas mortas do Service Bus.

Use redundância de zona. Quando a redundância de zona está habilitada em seu namespace, o Service Bus replica automaticamente as alterações entre várias zonas de disponibilidade. Se uma zona de disponibilidade falhar, o failover acontece automaticamente. Para obter mais informações, consulte Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Service Bus.

Use o Geo-Disaster Recovery. A recuperação de desastres geográficos garante que o processamento de dados continue a operar em uma região ou datacenter diferente se uma região ou datacenter inteiro do Azure ficar indisponível devido a um desastre. Para obter mais informações, consulte Recuperação de desastres geográficos do Barramento de Serviço do Azure.

Armazenamento

Use armazenamento com redundância de zona. O armazenamento com redundância entre zonas (ZRS) copia os dados de forma síncrona entre três zonas de disponibilidade do Azure na região primária. Se uma zona de disponibilidade sofrer uma interrupção, o Armazenamento do Azure efetuará automaticamente o failover para uma zona alternativa. Para obter mais informações, veja Redundância do Armazenamento do Microsoft Azure.

Ao usar redundância geográfica, configure o acesso de leitura. Se você usar uma arquitetura de várias regiões, use uma camada de armazenamento adequada para redundância global. Com RA-GRS ou RA-GZRS, seus dados são replicados para uma região secundária. O RA-GRS usa armazenamento com redundância local (LRS) na região primária, enquanto o RA-GZRS usa armazenamento com redundância de zona (ZRS) na região primária. Ambas as configurações fornecem acesso somente leitura aos seus dados na região secundária. Se houver uma interrupção de armazenamento na região primária, o aplicativo poderá ler os dados da região secundária se você a tiver projetado para essa possibilidade. Para obter mais informações, veja Redundância do Armazenamento do Microsoft Azure.

Para discos VM, use discos gerenciados.Os discos gerenciados fornecem melhor confiabilidade para VMs em um conjunto de disponibilidade, porque os discos são suficientemente isolados uns dos outros para evitar pontos únicos de falha. Além disso, os discos gerenciados não estão sujeitos aos limites de IOPS dos VHDs criados em uma conta de armazenamento. Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais do Windows no Azure.

Para armazenamento em fila, crie uma fila de backup em outra região. Para o Armazenamento em Fila, uma réplica somente leitura tem uso limitado, porque você não pode enfileirar ou retirar itens da fila. Em vez disso, crie uma fila de backup em uma conta de armazenamento em outra região. Se houver uma interrupção do Armazenamento do Azure, o aplicativo poderá usar a fila de backup até que a região primária fique disponível novamente. Dessa forma, o aplicativo pode continuar a processar novas solicitações durante a interrupção.

Base de Dados SQL

Use o nível Standard ou Premium. Essas camadas fornecem um período de restauração point-in-time mais longo (35 dias). Para obter mais informações, consulte Opções e desempenho do Banco de dados SQL.

Habilite a auditoria do Banco de dados SQL. A auditoria pode ser usada para diagnosticar ataques maliciosos ou erros humanos. Para obter mais informações, consulte Introdução à auditoria do banco de dados SQL.

Usar a Replicação Geográfica Ativa Use a Replicação Geográfica Ativa para criar um secundário legível em uma região diferente. Se o banco de dados primário falhar ou simplesmente precisar ficar offline, execute um failover manual para o banco de dados secundário. Até o failover, o banco de dados secundário permanece somente leitura. Para obter mais informações, consulte Replicação geográfica ativa do Banco de dados SQL.

Use fragmentação. Considere o uso de fragmentação para particionar o banco de dados horizontalmente. O compartilhamento pode fornecer isolamento de falhas. Para obter mais informações, consulte Dimensionamento com o Banco de Dados SQL do Azure.

Use a restauração point-in-time para se recuperar de um erro humano. A restauração point-in-time retorna seu banco de dados para um point-in-time anterior. Para obter mais informações, consulte Recuperar um banco de dados SQL do Azure usando backups de banco de dados automatizados.

Use a restauração geográfica para se recuperar de uma interrupção de serviço. A restauração geográfica restaura um banco de dados a partir de um backup com redundância geográfica. Para obter mais informações, consulte Recuperar um banco de dados SQL do Azure usando backups de banco de dados automatizados.

Azure Synapse Analytics

Não desative o backup geográfico. Por padrão, o Synapse Analytics faz um backup completo de seus dados no SQL Pool dedicado a cada 24 horas para recuperação de desastres. Não é recomendado desativar esse recurso. Para obter mais informações, consulte Backups geográficos.

SQL Server em execução em uma VM

Faça backup do banco de dados. Se você já estiver usando o Backup do Azure para fazer backup de suas VMs, considere usar o Backup do Azure para cargas de trabalho do SQL Server usando o DPM. Com essa abordagem, há uma função de administrador de backup para a organização e um procedimento de recuperação unificado para VMs e SQL Server. Caso contrário, use o Backup Gerenciado do SQL Server para Microsoft Azure.

Gestor de Tráfego

Execute failback manual. Após um failover do Gerenciador de Tráfego, execute failback manual, em vez de failback automático. Antes de fazer failback, verifique se todos os subsistemas de aplicativos estão íntegros. Caso contrário, você pode criar uma situação em que o aplicativo alterna entre datacenters. Para obter mais informações, consulte Executar VMs em várias regiões para alta disponibilidade.

Crie um ponto de extremidade de teste de integridade. Crie um ponto de extremidade personalizado que informe sobre a integridade geral do aplicativo. Isso permite que o Gerenciador de Tráfego faça failover se algum caminho crítico falhar, não apenas o front-end. O ponto de extremidade deve retornar um código de erro HTTP se qualquer dependência crítica não estiver íntegra ou inacessível. No entanto, não reporte erros para serviços não críticos. Caso contrário, a sonda de integridade pode acionar o failover quando não for necessário, criando falsos positivos. Para obter mais informações, consulte Monitoramento e failover de pontos finais do Gerenciador de Tráfego.

Máquinas Virtuais

Evite executar uma carga de trabalho de produção em uma única VM. Uma única implantação de VM não é resiliente à manutenção planejada ou não planejada. Em vez disso, coloque várias VMs em um conjunto de disponibilidade ou escala de máquina virtual, com um balanceador de carga na frente.

Especifique um conjunto de disponibilidade ao provisionar a VM. Atualmente, não é possível adicionar uma VM a um conjunto de disponibilidade depois que a VM é provisionada. Ao adicionar uma nova VM a um conjunto de disponibilidade existente, certifique-se de criar uma NIC para a VM e adicione a NIC ao pool de endereços back-end no balanceador de carga. Caso contrário, o balanceador de carga não roteará o tráfego de rede para essa VM.

Coloque cada camada de aplicativo em um Conjunto de Disponibilidade separado. Em um aplicativo de N camadas, não coloque VMs de camadas diferentes no mesmo conjunto de disponibilidade. As VMs em um conjunto de disponibilidade são colocadas em domínios de falha (FDs) e domínios de atualização (UD). No entanto, para obter o benefício de redundância de FDs e UDs, cada VM no conjunto de disponibilidade deve ser capaz de lidar com as mesmas solicitações de cliente.

Replique VMs usando o Azure Site Recovery. Quando você replica VMs do Azure usando o Site Recovery, todos os discos de VM são replicados continuamente para a região de destino de forma assíncrona. Os pontos de recuperação são criados a cada poucos minutos. Isso fornece um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) na ordem dos minutos. Você pode realizar exercícios de recuperação de desastres quantas vezes quiser, sem afetar o aplicativo de produção ou a replicação contínua. Para obter mais informações, consulte Executar um drill de recuperação de desastres no Azure.

Escolha o tamanho certo da VM com base nos requisitos de desempenho. Ao mover uma carga de trabalho existente para o Azure, comece com o tamanho da VM mais próximo dos seus servidores locais. Em seguida, meça o desempenho da sua carga de trabalho real em relação à CPU, memória e IOPS de disco e ajuste o tamanho, se necessário. Isso ajuda a garantir que o aplicativo se comporte como esperado em um ambiente de nuvem. Além disso, se você precisar de várias NICs, esteja ciente do limite de NIC para cada tamanho.

Use discos gerenciados para VHDs.Os discos gerenciados fornecem melhor confiabilidade para VMs em um conjunto de disponibilidade, porque os discos são suficientemente isolados uns dos outros para evitar pontos únicos de falha. Além disso, os discos gerenciados não estão sujeitos aos limites de IOPS dos VHDs criados em uma conta de armazenamento. Para obter mais informações, consulte Gerenciar a disponibilidade de máquinas virtuais do Windows no Azure.

Instale aplicativos em um disco de dados, não no disco do sistema operacional. Caso contrário, você pode atingir o limite de tamanho do disco.

Use o Backup do Azure para fazer backup de VMs. Os backups protegem contra perda acidental de dados. Para obter mais informações, consulte Proteger VMs do Azure com um cofre dos Serviços de Recuperação.

Habilite os logs de diagnóstico. Inclua métricas básicas de integridade, logs de infraestrutura e diagnósticos de inicialização. O diagnóstico de inicialização pode ajudá-lo a diagnosticar uma falha de inicialização se sua VM entrar em um estado não inicializável. Para obter mais informações, consulte Visão geral dos logs de diagnóstico do Azure.

Configure Azure Monitor. Colete e analise dados de monitoramento de máquinas virtuais do Azure, incluindo o sistema operacional convidado e as cargas de trabalho executadas nele, consulte Azure Monitor and Quickstart: Azure Monitor.

Rede Virtual

Para permitir ou bloquear endereços IP públicos, adicione um grupo de segurança de rede à sub-rede. Bloqueie o acesso de usuários mal-intencionados ou permita o acesso apenas de usuários que tenham privilégio para acessar o aplicativo.

Crie uma sonda de integridade personalizada. As sondas de integridade do balanceador de carga podem testar HTTP ou TCP. Se uma VM executar um servidor HTTP, a sonda HTTP será um indicador melhor do status de integridade do que uma sonda TCP. Para uma sonda HTTP, use um ponto de extremidade personalizado que relata a integridade geral do aplicativo, incluindo todas as dependências críticas. Para obter mais informações, consulte Visão geral do Balanceador de Carga do Azure.

Não bloqueie a sonda de saúde. A sonda de integridade do balanceador de carga é enviada de um endereço IP conhecido, 168.63.129.16. Não bloqueie o tráfego de ou para este IP em quaisquer políticas de firewall ou regras de grupo de segurança de rede. Bloquear a sonda de integridade faria com que o balanceador de carga removesse a VM da rotação.

Habilite o registro em log do Load Balancer. Os logs mostram quantas VMs no back-end não estão recebendo tráfego de rede devido a respostas de teste com falha. Para obter mais informações, consulte Análise de log para o Azure Load Balancer.