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 multiacesso (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 implantar cargas de trabalho no 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 balanceador de carga no MEC público 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 o MEC público do Azure.

    Observação

    No momento, o Gerenciador de Tráfego para o MEC público 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 balanceador de carga 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 balanceador de carga 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 balanceador de carga é 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 balanceador de carga aqui, supondo que outros serviços de plataforma como serviço (PaaS) tenham seu próprio balanceador de carga.

  • 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 ao Serviço de Kubernetes do Azure para aplicativos nativos da nuvem e baseados em contêiner.

  • Camada de banco de dados. Atualmente, o MEC público 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 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

  • O MEC público do Azure é uma solução de computação de borda que reúne um portfólio de serviços de computação, rede e aplicativos da Microsoft gerenciados a partir da nuvem.
  • O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS. Você pode usá-lo para direcionar solicitações DNS de entrada com base em um método de roteamento escolhido.
  • O Azure Load Balancer fornece alta disponibilidade e alto desempenho para seus aplicativos.
  • Os Conjuntos de Dimensionamento de Máquina Virtual do Azure permitem que você gerencie e escale até milhares de VMs.

Alternativas

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

  • Replica ativamente VMs do MEC público 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. Esse cenário é ideal para o setor de telecomunicações.

Considerações

Essas 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, confira Microsoft Azure Well-Architected Framework.

SLA

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

O MEC público 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 no MEC público 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 o MEC público 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.

O MEC público do Azure é usado 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 obter 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