Criar serviços de aplicações resilientes
Sua organização precisa que você atenda aos requisitos de recuperação, mantendo os custos e a complexidade reduzidos tanto quanto possível.
Nesta unidade, você aprende como os clusters de redundância geográfica e disponibilidade podem ajudá-lo a criar resiliência em seus aplicativos. Você aprende o que está envolvido em failovers e failbacks para seus aplicativos. Ao final desta unidade, você entenderá por que e como deve implementar uma estratégia de monitoramento e notificação.
Adicionar redundância geográfica às aplicações
Você deve ser capaz de manter seus aplicativos em execução, independentemente do que aconteça com a infraestrutura que os hospeda. Desastres naturais e outros problemas podem fazer com que toda uma área geográfica perca energia ou acesso à internet. Para responder a esses problemas graciosamente e manter seus aplicativos em execução, você deve certificar-se de que a redundância geográfica está em vigor. Mas a redundância geográfica pode ser dispendiosa se não for feita corretamente.
Pode utilizar o Azure para tornar as aplicações no local geograficamente redundantes. A vantagem de executar uma infraestrutura redundante para seus aplicativos no Azure é que você não é responsável por manter e proteger um local físico (juntamente com os custos associados).
Com o Azure, você pode adicionar redundância aos seus aplicativos com regiões que podem estar do outro lado do mundo, e não há manutenção para você lidar. Quando a manutenção é feita para si, pode obter redundância geográfica de forma mais fácil e económica.
Você pode estender a rede local para uma rede virtual que esteja executando uma réplica de sua infraestrutura em uma região diferente dentro do Azure usando uma conexão VPN site a site. O Azure Traffic Manager pode ajudá-lo a monitorar a integridade da sua rede local. Se algo acontecer com o local local, você poderá usar a infraestrutura de réplica no Azure localizada em uma região diferente.
De igual forma, pode configurar a redundância geográfica para as aplicações em execução no Azure. Por exemplo, se seus aplicativos forem executados em um grupo de máquinas virtuais do Azure em uma rede virtual, você poderá replicar a mesma configuração em outra região para redundância geográfica.
Através do peering de rede virtual, vai ligar duas redes virtuais separadas que são tratadas como uma só. O tráfego dessas duas redes não passa pela internet pública ou por um gateway. Os recursos podem se conectar diretamente a outros recursos como se estivessem na mesma rede.
Neste caso, o Gestor de Tráfego examina ambas as regiões por si ao monitorizar o estado de funcionamento de cada ponto final. Se algo acontecer com a sua região principal, o Gestor de Tráfego encaminha a procura para a sua região secundária.
Adicionar clusters de alta disponibilidade
Os clusters de alta disponibilidade ajudam a garantir que suas cargas de trabalho permaneçam disponíveis e em execução com o mínimo de tempo de inatividade. Você pode usar clusters de alta disponibilidade em qualquer um dos seguintes tipos de arquitetura:
Arquitetura ativo-ativo: você distribui e equilibra a demanda de carga entre vários nós, como duas máquinas virtuais idênticas do Azure. Pode ter estas máquinas virtuais do Azure em execução em conjunto e a partilhar a procura. Também pode distribuir a procura para estes nós com base em diferentes métodos de encaminhamento.
O diagrama a seguir é um exemplo de alto nível de um cluster ativo-ativo.
Arquitetura ativo-passivo: você executa máquinas virtuais do Azure em que um nó está ativo e em uso, e o outro nó é passivo e não está em uso. Utiliza o nó passivo apenas quando o nó ativo apresentar uma falha.
Em um cenário ativo-ativo, seus nós estão sendo executados simultaneamente. Você terá mais custos de operação no dia a dia nesse cenário, se as máquinas tiverem as mesmas especificações que as máquinas em um cluster ativo-passivo.
Os clusters ativo-passivo podem ser mais econômicos do que os clusters ativo-ativo. Como o nó passivo não está atendendo ativamente às solicitações do usuário, você pode ter custos de licenciamento de software mais baixos e custos de recursos mais baixos. No entanto, como você executa apenas o nó ativo em um cluster ativo-passivo, não é tão flexível para atender à demanda flutuante quanto em um cluster ativo-ativo.
Recursos como conjuntos de disponibilidade do Azure ajudam você a obter alta disponibilidade por meio de vários nós. Se algo afetar um computador, como falhas de hardware ou interrupções de rede, o outro computador poderá estar disponível para manter tudo em execução.
Você também pode usar os Conjuntos de Escala de Máquina Virtual do Azure para criar um cluster ativo-ativo e executar máquinas que funcionam para aumentar e diminuir a escala em resposta direta à demanda. O Azure Load Balancer, por meio de suas regras para portas de alta disponibilidade, também pode ajudá-lo a usar clusters ativo-ativo ou ativo-passivo para suas máquinas.
Ativação e reativação pós-falha das aplicações
Sua organização tem uma infraestrutura para seus aplicativos executados localmente. Você deve ajudar a garantir que sua organização atenda aos requisitos de conformidade e atinja as metas de continuidade de negócios. Usando o Azure Site Recovery e o Gerenciador de Tráfego juntos, você pode fazer failover para o Azure e, em seguida, fazer failover para manter os aplicativos em execução.
Se ocorrer uma falha, poderá redirecionar sem problemas o tráfego do cliente para uma infraestrutura criada para si no Azure. Use o Gerenciador de Tráfego para criar um perfil e definir um método de roteamento prioritário. Em seguida, crie dois pontos de extremidade: um para seu ambiente local e outro para o ambiente que você deseja configurar no Azure.
Como você normalmente executa um ambiente local e deseja que outro no Azure faça failover apenas, você pode definir as duas prioridades a seguir:
- Prioridade 1 para o ambiente local
- Prioridade 2 para o seu ambiente no Azure
Essas prioridades são como o Traffic Manager sabe como rotear o tráfego entre os dois ambientes. O Gestor de Tráfego continua a encaminhar o tráfego para o ambiente no local até observar que o ponto final já não está em bom estado de funcionamento. Se for esse o caso, o Gestor de Tráfego encaminha o tráfego para o seu segundo ambiente, no Azure.
O Azure Site Recovery começa a executar suas máquinas virtuais no Azure somente se um failover for acionado. Se ocorrer um desastre, poderá utilizar o Azure Site Recovery para iniciar uma ativação pós-falha a partir do ambiente no local para o ambiente do Azure.
O Traffic Manager permite-lhe definir a frequência de sondagem para monitorizar os seus endpoints. Você configura o Gerenciador de Tráfego para monitorar a integridade de seus pontos de extremidade a cada 30 segundos para testes regulares, até intervalos de 10 segundos para testes mais rápidos.
Após a conclusão de um failover, os clientes são direcionados de forma transparente para o novo ponto de extremidade no Azure. Depois de resolver o problema que causou o failover, você pode usar o Azure Site Recovery para fazer failover novamente em seu ambiente local. O Gestor de Tráfego continua a investigar o estado de funcionamento do ponto final no local. Quando o Gestor de Tráfego identifica que o ponto final está novamente em bom estado de funcionamento, direciona o tráfego de volta para o ambiente no local.
