Editar

Partilhar via

Aplicação Web com várias camadas criada para HA/DR

Azure
Azure Arc
SQL Server
Windows

Este cenário de exemplo é aplicável a qualquer setor que precise implantar aplicativos resilientes de várias camadas criados para alta disponibilidade e recuperação de desastres. Nesse cenário, o aplicativo consiste em três camadas.

  • Camada da Web: a camada superior, incluindo a interface do usuário. Essa camada analisa as interações do usuário e passa as ações para a próxima camada para processamento.
  • Nível de negócios: processa as interações do usuário e toma decisões lógicas sobre as próximas etapas. Essa camada conecta a camada da Web e a camada de dados.
  • Camada de dados: armazena os dados do aplicativo. Um banco de dados, armazenamento de objetos ou armazenamento de arquivos é normalmente usado.

Os cenários comuns de aplicativos incluem qualquer aplicativo de missão crítica em execução no Windows ou Linux. Pode ser um aplicativo pronto para uso, como SAP e SharePoint, ou um aplicativo de linha de negócios personalizado.

Potenciais casos de utilização

Outros casos de uso relevantes incluem:

  • Implantação de aplicativos altamente resilientes, como SAP e SharePoint
  • Projetando um plano de continuidade de negócios e recuperação de desastres para aplicativos de linha de negócios
  • Configure a recuperação de desastres e execute exercícios relacionados para fins de conformidade

Arquitetura

Diagrama mostrando a visão geral da arquitetura de um aplicativo Web multicamadas altamente resiliente.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

  • Distribua as VMs em cada camada em duas zonas de disponibilidade em regiões que oferecem suporte a zonas. Em outras regiões, implante as VMs em cada camada dentro de um conjunto de disponibilidade.
  • A camada de banco de dados pode ser configurada para usar grupos de disponibilidade Always On. Com essa configuração do SQL Server, uma réplica primária de leitura/gravação dentro de um grupo de disponibilidade é configurada com até oito réplicas secundárias somente leitura. Se ocorrer um problema com a réplica primária, o grupo de disponibilidade fará o failover da atividade de leitura/gravação primária para uma das réplicas secundárias, permitindo que o aplicativo permaneça disponível. Para obter mais informações, consulte Visão geral dos grupos de disponibilidade Always On para SQL Server.
  • Para cenários de recuperação de desastres, você pode configurar a replicação nativa assíncrona Always On do SQL para a região de destino usada para recuperação de desastres. Você também pode configurar a replicação do Azure Site Recovery para a região de destino se a taxa de alteração de dados estiver dentro dos limites suportados do Azure Site Recovery.
  • Os usuários acessam o front-end ASP.NET a camada da Web por meio do endpoint do gerenciador de tráfego.
  • O gerenciador de tráfego redireciona o tráfego para o ponto de extremidade IP público primário na região de origem primária.
  • O IP público redireciona a chamada para uma das instâncias de VM da camada da Web por meio de um balanceador de carga público. Todas as instâncias de VM da camada da Web estão em uma sub-rede.
  • A partir da VM da camada da Web, cada chamada é roteada para uma das instâncias da VM na camada de negócios por meio de um balanceador de carga interno para processamento. Todas as VMs da camada de negócios estão em uma sub-rede separada.
  • A operação é processada na camada de negócios e o aplicativo ASP.NET se conecta ao cluster do Microsoft SQL Server em uma camada de back-end por meio de um balanceador de carga interno do Azure. Essas instâncias back-end do SQL Server estão em uma sub-rede separada.
  • O ponto de extremidade secundário do gerenciador de tráfego é configurado como o IP público na região de destino usada para recuperação de desastres.
  • No caso de uma interrupção da região primária, você invoca o failover do Azure Site Recovery e o aplicativo fica ativo na região de destino.
  • O ponto de extremidade do gerenciador de tráfego redireciona automaticamente o tráfego do cliente para o IP público na região de destino.

Componentes

  • Os conjuntos de disponibilidade garantem que as VMs implantadas no Azure sejam distribuídas em vários nós de hardware isolados em um cluster. Se ocorrer uma falha de hardware ou software no Azure, apenas um subconjunto das suas VMs será afetado e toda a sua solução permanecerá disponível e operacional.
  • As zonas de disponibilidade protegem seus aplicativos e dados contra falhas no datacenter. As zonas de disponibilidade são locais físicos separados dentro de uma região do Azure. Cada zona consiste em um ou mais datacenters equipados com energia, resfriamento e rede independentes.
  • O Azure Site Recovery permite replicar VMs para outra região do Azure para necessidades de continuidade de negócios e recuperação de desastres. Você pode realizar exercícios periódicos de recuperação de desastres para garantir que atenda às necessidades de conformidade. A VM será replicada com as definições especificadas para a região selecionada para que possa recuperar as suas aplicações em caso de falhas na região de origem.
  • O Azure Traffic Manager é um balanceador de carga de tráfego baseado em DNS que distribui o tráfego de forma otimizada para serviços em regiões globais do Azure, ao mesmo tempo que fornece alta disponibilidade e capacidade de resposta.
  • O Azure Load Balancer distribui o tráfego de entrada de acordo com regras definidas e testes de integridade. Um balanceador de carga fornece baixa latência e alta taxa de transferência, dimensionando até milhões de fluxos para todos os aplicativos TCP e UDP. Um balanceador de carga público é usado neste cenário para distribuir o tráfego de entrada do cliente para a camada da Web. Um balanceador de carga interno é usado neste cenário para distribuir o tráfego da camada de negócios para o cluster back-end do SQL Server.

Alternativas

  • O Windows pode ser substituído por outros sistemas operacionais porque nada na infraestrutura depende do sistema operacional.
  • O SQL Server para Linux pode substituir o armazenamento de dados back-end.
  • O banco de dados pode ser substituído por qualquer aplicativo de banco de dados padrão disponível.

Detalhes do cenário

Este cenário demonstra um aplicativo de várias camadas que usa o ASP.NET e o Microsoft SQL Server. Em regiões do Azure que dão suporte a zonas de disponibilidade, você pode implantar suas máquinas virtuais (VMs) em uma região de origem em zonas de disponibilidade e replicar as VMs para a região de destino usada para recuperação de desastres. Em regiões do Azure que não oferecem suporte a zonas de disponibilidade, você pode implantar suas VMs dentro de um conjunto de disponibilidade e replicar as VMs para a região de destino.

Para rotear o tráfego entre regiões, você precisa de um balanceador de carga global. Há duas ofertas principais do Azure:

  • Azure Front Door
  • Gestor de Tráfego do Azure

Ao escolher um balanceador de carga, considere seus requisitos e o conjunto de recursos das duas ofertas. Com que rapidez você deseja fazer failover? Você pode assumir a sobrecarga do gerenciamento de TLS? Existem restrições de custos organizacionais?

O Front Door tem recursos de Camada 7: descarregamento SSL, roteamento baseado em caminho, failover rápido, cache e outros para melhorar o desempenho e a alta disponibilidade de seus aplicativos. Você pode experimentar tempos de viagem de pacotes mais rápidos porque a infraestrutura é integrada na rede do Azure mais cedo.

Como o Front Door adiciona um novo salto, há operações de segurança adicionais. Se a arquitetura estiver em conformidade com os requisitos regulamentares, pode haver restrições sobre o ponto de terminação TLS de tráfego adicional. Os pacotes de codificação TLS selecionados pelo Front Door devem atender à barra de segurança da sua organização. Além disso, a Front Door espera que os serviços de back-end usem certificados usados pela Microsoft.

Outra consideração é o custo. A arquitetura deve aproveitar o extenso conjunto de recursos (não apenas failover) para justificar o custo adicional.

O Traffic Manager é um serviço de balanceamento de carga baseado em DNS. Ele equilibra e executa failover apenas no nível DNS. Por esse motivo, ele não pode fazer failover tão rapidamente quanto o Front Door, devido aos desafios comuns em torno do cache de DNS e sistemas que não respeitam os TTLs de DNS.

Você pode combinar ambos os balanceadores de carga, se necessário. Por exemplo, você deseja o failover baseado em DNS, mas deseja adicionar uma experiência POP na frente dessa infraestrutura gerenciada por tráfego.

Essa arquitetura usa o Gerenciador de Tráfego porque é leve. O tempo de failover é suficiente para fins ilustrativos.

Considerações

Escalabilidade

Você pode adicionar ou remover VMs em cada camada com base em seus requisitos de dimensionamento. Como esse cenário usa balanceadores de carga, você pode adicionar mais VMs a uma camada sem afetar o tempo de atividade do aplicativo.

Para outros tópicos de escalabilidade, consulte a lista de verificação de eficiência de desempenho no Centro de Arquitetura do Azure.

Segurança

Todo o tráfego de rede virtual na camada de aplicativo front-end é protegido por grupos de segurança de rede. As regras limitam o fluxo de tráfego para que apenas as instâncias de VM da camada de aplicativo front-end possam acessar a camada de banco de dados back-end. Nenhum tráfego de saída da Internet é permitido a partir da camada de negócios ou da camada de banco de dados. Para reduzir a pegada de ataque, nenhuma porta de gerenciamento remoto direto está aberta. Para obter mais informações, consulte Grupos de segurança de rede do Azure.

Para obter orientações gerais sobre como criar cenários seguros, consulte a Documentação de Segurança do Azure.

Preços

Configurar a recuperação de desastres para VMs do Azure usando o Azure Site Recovery incorrerá nos seguintes encargos continuamente.

  • Custo de licenciamento do Azure Site Recovery por VM.
  • Custos de saída de rede para replicar alterações de dados dos discos de VM de origem para outra região do Azure. O Azure Site Recovery usa compactação interna para reduzir os requisitos de transferência de dados em aproximadamente 50%.
  • Custos de armazenamento no local de recuperação. Normalmente, isso é o mesmo que o armazenamento da região de origem, além de qualquer armazenamento adicional necessário para manter os pontos de recuperação como snapshots para recuperação.

Fornecemos uma calculadora de custos de exemplo para configurar a recuperação de desastres para um aplicativo de três camadas usando seis máquinas virtuais. Todos os serviços são pré-configurados na calculadora de custos. Para ver como o preço mudaria para seu caso de uso específico, altere as variáveis apropriadas para estimar o custo.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Próximos passos

Para obter arquiteturas de referência adicionais de alta disponibilidade e recuperação de desastres, consulte: