Editar

Compartilhar via


Alta disponibilidade na MEC pública do Azure

Gerenciador de Tráfego do Azure
Azure Load Balancer
Conjuntos de Dimensionamento de Máquinas Virtuais do Azure

A computação de borda de acesso múltiplo (MEC) pública do Azure é uma ótima plataforma para hospedar aplicativos na borda e pode torná-los mais responsivos, mas atualmente não oferece suporte a recursos de alta disponibilidade. Este artigo descreve como implantar cargas de trabalho no modo ativo/em espera para obter alta disponibilidade e recuperação de desastres.

Apache®, Apache Ignite, Ignite e o logotipo de chamas são marcas registradas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou em outros países. O uso desta marca não implica aprovação por parte da Apache Software Foundation.

Arquitetura

Diagrama que mostra uma arquitetura para a implementação de cargas de trabalho em modo ativo/em espera para obter alta disponibilidade e recuperação de desastres.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

  • Gerenciador de Tráfego do Microsoft Azure. Configure o Gerenciador de Tráfego para usar o roteamento de prioridade. Defina o endereço IP do Load Balancer na MEC pública do Azure (principal) como Prioridade 1. Defina o da região secundária como Prioridade 2. Essa configuração envia todo o tráfego no caso de não failover para a MEC pública do Azure.

    Observação

    No momento, o Gerenciador de Tráfego para a MEC pública do Azure não oferece suporte ao roteamento de desempenho, que pode determinar dinamicamente o roteamento descrito anteriormente com base na menor latência para o ponto de extremidade.

    Nessa arquitetura, o failback é obtido automaticamente depois que as máquinas virtuais (VMs) e/ou o load balancer padrão estão online novamente. O Gerenciador de Tráfego determina que as cargas de trabalho estão ativas e redireciona o tráfego de volta para a região principal do MEC pública do Azure.

  • Balanceador de carga público. Esse load balancer faz frente à camada de aplicativo e equilibra o tráfego para o pool de VMs no conjunto de dimensionamento de máquina virtual.

  • Balanceador de carga interno. Esse load balancer é usado para acessar a camada de banco de dados. Dependendo do tipo de banco de dados usado para seu aplicativo, talvez você não precise de um load balancer aqui, supondo que outros serviços de plataforma como serviço (PaaS) tenham seu próprio load balancer.

  • Conjuntos de Dimensionamento de Máquinas Virtuais do Azure. A maioria das implantações de produção usa Conjuntos de Dimensionamento de Máquina Virtual para dimensionar dinamicamente suas cargas de trabalho com base na carga de tráfego. O MEC público do Azure também oferece suporte para o Serviço de Kubernetes do Azure para aplicativos nativos da nuvem e baseados em contêiner.

  • Camada de banco de dados. Atualmente, a MEC pública do Azure não oferece suporte a serviços de PaaS do banco de dados SQL, como o SQL Server em Máquinas Virtuais do Azure e a Instância Gerenciada de SQL do Azure. Atualmente, ele também não oferece suporte a serviços de PaaS NoSQL, como o Azure Cosmos DB e a Instância Gerenciada do Azure para Apache Cassandra. Você pode implantar soluções de terceiros que oferecem suporte a serviços SQL ou NoSQL e replicação de dados em seus clusters distribuídos geograficamente.

Componentes

Alternativas

Backup e recuperação de desastres do Azure, que fornece recursos de backup e recuperação de site do Azure:

  • Replica ativamente VMs da MEC pública do Azure para a região pai e as disponibiliza para failover e failback em caso de interrupção.
  • Faz backup de VMs para evitar corrupção ou perda de dados.

Essa abordagem custa menos do que a descrita anteriormente porque não há recursos ociosos. Essa alternativa é adequada apenas para aplicações que permitem RTOs mais altos.

Observação

O backup e a recuperação de desastres do Azure para o MEC público do Azure atualmente oferecem suporte apenas a máquinas virtuais.

Detalhes do cenário

Possíveis casos de uso

Use essa arquitetura quando quiser implantar cargas de trabalho no modo ativo/em espera para obter alta disponibilidade e recuperação de desastres. Este cenário é ideal para o setor de telecomunicações.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Contrato de Nível de Serviço

A Microsoft oferece suporte a contratos de nível de serviço (SLAs) para infraestrutura de tamanho maior, como regiões do Azure e do Azure. O MEC público do Azure é uma extensão de área de cobertura menor do Azure e, portanto, não tem suporte a SLA.

Desempenho

A MEC pública do Azure foi projetado para hospedar aplicativos críticos de latência. Como o failover para uma região secundária aumenta a latência das cargas de trabalho, ele pode não fornecer o mesmo nível de desempenho. Dependendo do aplicativo e de sua sensibilidade a essa latência aumentada, você precisa decidir qual dos serviços, se houver, deve fazer failover para a região.

Bancos de dados

A replicação e o backup de dados são importantes quando você depende de failovers de banco de dados. A maioria dos serviços de PaaS do Azure tem suporte interno para replicação geográfica e criação de réplicas de leitura entre regiões e regiões geográficas.

Observação

Atualmente, o MEC público do Azure não oferece suporte a serviços de PaaS, como Instância Gerenciada do SQL, SQL Server em Máquinas Virtuais do Azure, Banco de Dados do Azure para MySQL ou Banco de Dados do Azure para PostgreSQL. Ofertas de terceiros como Couchbase, MongoDB e Apache Cassandra podem fornecer serviços de infraestrutura como serviço (IaaS) que oferecem suporte à replicação geográfica.

Gerenciador de Tráfego

Opções de failover

O Gerenciador de Tráfego oferece suporte a vários métodos de roteamento: desempenho, geográfico, prioridade e muito mais. Para oferecer melhor suporte a aplicativos de baixa latência, envie dados dinamicamente para a região / MEC público do Azure mais próxima do usuário. No momento, o roteamento de desempenho não tem suporte no MEC público do Azure. A próxima melhor opção é priorizar estaticamente o melhor local para um aplicativo.

Para um aplicativo distribuído globalmente que tenha cargas de trabalho distribuídas em várias regiões e MECs públicas do Azure, use um método de roteamento aninhado. Use o roteamento geográfico para dividir o tráfego para a região correta e, em seguida, use o roteamento prioritário para dividir ainda mais o tráfego.

Failback

Depois que as cargas de trabalho na MEC pública do Azure são refeitas, os testes do Gerenciador de Tráfego detectam que ele pode receber solicitações e redirecionar automaticamente o tráfego de volta para a MEC pública do Azure.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

A MEC pública do Azure é usada principalmente para cenários de computação de baixa latência e em tempo real. Os dados são processados pelas instâncias de computação executadas no MEC público do Azure. Essa arquitetura usa ativo/standby com um hot standby. Ou seja, as cargas de trabalho na região secundária não são usadas, a menos que haja um failover.

Essa abordagem para implantar cargas de trabalho como um modo de espera incorre em custos de implantação do Azure, mesmo que as cargas de trabalho não sejam usadas.

Para mais informações sobre preços:

Para obter informações sobre como criar uma carga de trabalho econômica, consulte Visão geral do pilar de otimização de custos na documentação do Azure Well-Architected Framework.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Próximas etapas