Este cenário de exemplo é aplicável a qualquer setor que precise implantar aplicativos multicamadas resilientes criados para alta disponibilidade e recuperação de desastre. Nesse cenário, o aplicativo é formado por 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.
- Camada de negócios: processa as interações do usuário e toma decisões lógicas sobre as próximas etapas. Essa camada se conecta à camada da Web e à camada de dados.
- Camada de dados: armazena os dados do aplicativo. Um banco de dados, o armazenamento de objetos ou o armazenamento de arquivos normalmente é usado.
Cenários de aplicativo comuns incluem qualquer aplicativo de missão crítica em execução no Windows ou Linux. Isso pode ser um aplicativo pronto para uso, como SAP e SharePoint, ou um aplicativo de linha de negócios personalizado.
Possíveis casos de uso
Outros casos de uso relevantes incluem:
- Implantar aplicativos altamente resilientes, como SAP e SharePoint
- Projetar um plano de continuidade de negócios e recuperação de desastres para aplicativos de linha de negócios
- Configurar a recuperação de desastres e executar treinamentos relacionados para fins de conformidade
Arquitetura
Baixe um Arquivo Visio dessa arquitetura.
Workflow
- Distribua as VMs em cada camada em duas zonas de disponibilidade em regiões que oferecem suporte às zonas. Em outras regiões, implante as VMs em cada camada em 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 em 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á 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 saber mais informações, confira 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 do SQL Always On para a região de destino usada na recuperação de desastre. 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 compatíveis com o Azure Site Recovery.
- Os usuários acessam a camada da Web do ASP.NET front-end através do ponto de extremidade do gerenciador de tráfego.
- O gerenciador de tráfego redireciona o tráfego para o ponto de extremidade do 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 de camada da Web através 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 de VM na camada de negócios através 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 conecta-se 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 do SQL Server de back-end 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 na recuperação de desastre.
- No caso de uma interrupção da região primária, invoque o failover do Azure Site Recovery e o aplicativo ficará 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 entre vários nós de hardware isolados em um cluster. Se ocorrer uma falha de hardware ou software no Azure, somente um subconjunto de suas VMs será afetado e toda sua solução permanecerá disponível e operacional.
- As zonas de disponibilidade ajudam a proteger os aplicativos e os dados contra falhas no datacenter. As zonas de disponibilidade são locais físicos separados em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes.
- O Azure Site Recovery permite replicar VMs em outra região do Azure, para necessidades de continuidade dos negócios e recuperação de desastres. Você pode realizar análises periódicas de recuperação de desastres para garantir que atende às necessidades de conformidade. A máquina virtual será replicada com as configurações especificadas para a região selecionada para que você possa recuperar seus aplicativos em caso de interrupções na região de origem.
- O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que distribui o tráfego de maneira ideal para serviços em todas as regiões globais do Azure, fornecendo alta disponibilidade e capacidade de resposta.
- O Azure Load Balancer distribui o tráfego de entrada de acordo com as regras e investigações de integridade. O balanceador de carga fornece baixa latência e alta taxa de transferência e pode ser escalado verticalmente em milhões de fluxos para aplicativos TCP e UDP. Um balanceador de carga público é usado neste cenário para distribuir o tráfego de clientes 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 do SQL Server de back-end.
Alternativas
- O Windows pode ser substituído por outros sistemas operacionais já que nada na infraestrutura depende do sistema operacional.
- SQL Server para Linux pode substituir o armazenamento de dados de 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 apresenta um aplicativo de várias camadas que usa o ASP.NET e o Microsoft SQL Server. Em regiões do Azure que oferecem suporte a zonas de disponibilidade, é possível implantar suas máquinas virtuais (VMs) em uma região de origem nas zonas de disponibilidade e replicar as VMs na região de destino usadas para recuperação de desastres. Em regiões do Azure que não oferecem suporte a zonas de disponibilidade, é possível implantar suas VMs (máquinas virtuais) em um conjunto de disponibilidade e replicar as VMs na região de destino.
Para rotear o tráfego entre regiões, é necessário um balanceador de carga global. O Azure tem duas ofertas principais:
- Porta da frente do Azure
- Gerenciador de Tráfego do Azure
Ao escolher um balanceador de carga, considere seus requisitos e o conjunto de recursos de ambas. Qual rapidez de failover você deseja? Você pode assumir a sobrecarga do gerenciamento de TLS? Há alguma restrição de custo organizacional?
O Front Door oferece recursos de Camada 7: descarregamento de SSL, roteamento com base em caminho, failover rápido, cache etc., para aprimorar o desempenho e a disponibilidade dos seus aplicativos. Você pode experimentar menores tempos de percurso de pacote, pois a infraestrutura é precocemente integrada à rede do Azure.
Como o Front Door adiciona um novo salto, há operações de segurança adicionadas. Se a arquitetura estiver em conformidade com os requisitos regulatórios, poderá haver restrições sobre o ponto de terminação TLS para tráfego adicional. Os pacotes de criptografias TLS selecionados pelo Front Door devem observar a barra de segurança da sua organização. Além disso, o Front Door espera que os serviços de back-end usem certificados usados pela Microsoft.
Outra consideração é a segurança. A arquitetura deve aproveitar o amplo conjunto de recursos (não apenas o failover) para justificar o custo adicionado.
O Gerenciador de Tráfego é um serviço de balanceamento de carga com base em DNS. Ele é faz o balanceamento e o failover somente no nível de DNS. Por esse motivo, ele não pode fazer failover tão rapidamente quanto o Azure Front Door, devido a desafios comuns relacionados ao cache do DNS e sistemas que não respeitam os TTLs do DNS.
Se preciso, é possível combinar os dois balanceadores de carga. Por exemplo, você deseja o failover com base em DNS, mas quer adicionar uma experiência POP na frente dessa infraestrutura gerenciada por tráfego.
Essa arquitetura usa o Gerenciador de Tráfego devido à sua leveza. O tempo de failover é suficiente para fins ilustrativos.
Considerações
Escalabilidade
Você pode adicionar ou remover as VMs em cada camada com base em seus requisitos de escala. 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 informar-se sobre outros tópicos de escalabilidade, confira a lista de verificação de eficiência de desempenho disponível no Centro de Arquitetura do Azure.
Segurança
Todo o tráfego de rede virtual para a camada de aplicativo front-end é protegido por grupos de segurança de rede. As regras limitam o fluxo de tráfego para que somente as instâncias de VM da camada de aplicativo front-end possam acessar a camada de banco de dados de back-end. Nenhum tráfego de Internet de saída é permitido da camada de banco de dados ou de negócios. Para reduzir a superfície de ataque, nenhuma porta de gerenciamento remoto direto fica aberta. Para saber mais, confira Grupos de segurança de rede do Azure.
Para obter orientação geral sobre como criar soluções seguras, confira a Documentação de segurança do Azure.
Preços
A configuração da recuperação de desastre para VMs do Azure que usam o Azure Site Recovery incorrerá nas seguintes cobranças de maneira contínua.
- O custo do licenciamento da Recuperação de Site do Azure por VM.
- Os custos de saída de rede para replicar alterações de dados dos discos da VM de origem para outra região do Azure. O Azure Site Recovery usa a compactação interna para reduzir os requisitos de transferência de dados em cerca de 50%.
- Custos de armazenamento no site de recuperação. Isso geralmente equivale ao armazenamento da região de origem mais qualquer armazenamento adicional necessário para manter os pontos de recuperação como instantâneos para recuperação.
Fornecemos uma calculadora de custos de exemplo para configurar a recuperação de desastre 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 seria alterado para seu uso específico, altere as variáveis apropriadas para estimar o custo.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Sujay Talasila | Principal Líder de Produto
Próximas etapas
Recursos relacionados
Para informar-se sobre arquiteturas adicionais de referência para alta disponibilidade e recuperação de desastre, consulte: