Compartilhar via


Alta disponibilidade para o Service Connector

O Service Connector dá suporte a zonas de disponibilidade do Azure para ajudá-lo a obter resiliência e confiabilidade para suas cargas de trabalho críticas para os negócios. O objetivo da arquitetura de alta disponibilidade no Service Connector é garantir que suas conexões de serviço estejam ativas e executando pelo menos 99,9% de tempo, para que você não precise se preocupar com os efeitos de possíveis operações de manutenção e interrupções. O Service Connector foi projetado para fornecer suporte de alta disponibilidade para todos os tipos de aplicativos que você está executando no Azure.

Os usuários podem distribuir serviços de computação do Azure entre zonas de disponibilidade em muitas regiões. O Service Connector é um provedor de recursos de extensão para esses serviços de computação. Quando você cria uma conexão de serviço em um serviço de computação com zonas de disponibilidade habilitadas, o Azure também configurará automaticamente a zona de disponibilidade de conexão de serviço correspondente para sua conexão de serviço. A Microsoft é responsável por configurar zonas de disponibilidade e recuperação de desastre para suas conexões de serviço.

Redundância de zona no Service Connector

O Service Connector é um provedor de recursos de extensão do Azure. Ele estende o Serviço de Aplicativo do Azure, o Azure Spring Apps e os Aplicativos de Contêiner do Azure. Quando você cria uma nova conexão de serviço em um desses serviços de computação com o Service Connector, um recurso de conexão é provisionado como parte do serviço de computação pai de nível superior.

Para habilitar a redundância de zona para sua conexão, você deve habilitar a redundância de zona para seu serviço de computação. Depois que o serviço de computação tiver sido configurado com redundância de zona, suas conexões de serviço também se tornarão automaticamente redundantes de zona. Por exemplo, se você tiver um serviço de aplicativo com redundância de zona habilitada, a plataforma espalhará automaticamente as instâncias do serviço de aplicativo em três zonas na região selecionada. Quando você cria uma conexão de serviço neste serviço de aplicativo com o Service Connector, o recurso de conexão de serviço também é criado automaticamente nas três zonas correspondentes na região selecionada. O tráfego é roteado para todos os recursos de conexão disponíveis. Quando uma zona fica inoperante, a plataforma detecta as instâncias perdidas, tenta encontrar automaticamente novas instâncias de substituição e espalha o tráfego conforme necessário.

Observação

Para criar, atualizar, validar e listar conexões de serviço, o Service Connector chama APIs de um serviço de computação e um serviço de destino. Como o Service Connector depende das respostas do serviço de computação e do serviço de destino, as solicitações ao Service Connector em um cenário de zona suspensa podem não ter êxito se o serviço de destino não puder ser atingido. Essa limitação se aplica ao Serviço de Aplicativo, aos Aplicativos de Contêiner do Azure e ao Azure Spring Apps.

Como criar uma conexão de serviço com redundância de zona com o Service Connector

Siga as instruções abaixo para criar uma conexão de serviço com redundância de zona no Serviço de Aplicativo usando a CLI do Azure ou o portal do Azure. O mesmo processo pode ser usado para criar uma conexão com redundância de zona para os serviços de computação do Azure Spring Apps e dos Aplicativos de Contêiner do Azure.

Para habilitar a redundância de zona para uma conexão de serviço usando a CLI do Azure, comece criando um Serviço de Aplicativo com redundância de zona.

  1. Crie um plano do Serviço de Aplicativo e inclua um --zone-redundant parâmetro. Opcionalmente, inclua o --number-of-workers parâmetro para especificar a capacidade. Saiba mais detalhes sobre como implantar um Serviço de Aplicativo com redundância de zona.

    az appservice plan create --resource-group MyResourceGroup --name MyPlan --zone-redundant --number-of-workers 6
    
  2. Crie um aplicativo no Serviço de Aplicativo e uma conexão com sua conta de Armazenamento de Blobs ou outro serviço de destino de sua escolha.

    az webapp create --name MyApp --plan MyPlan resource-group MyResourceGroup
    az webapp connection create storage-blob 
    

À medida que você habilitou a redundância de zona para o Serviço de Aplicativo, a conexão de serviço também é redundante por zona.

Dica

É recomendável habilitar a redundância de zona para seu serviço de destino. Em um cenário de zona para baixo, o tráfego para sua conexão será distribuído automaticamente para outras zonas. No entanto, a criação, validação e atualização de conexões dependem de APIs de gerenciamento do serviço de destino. Se um serviço de destino não oferecer suporte à redundância de zona ou não tiver a redundância de zona habilitada, essas operações falharão.

Entender a recuperação e a resiliência de desastres no Service Connector

A recuperação de desastre é o processo de restauração da funcionalidade do aplicativo após uma perda catastrófica.

Na nuvem, reconhecemos antecipadamente que falhas certamente ocorrerão. Em vez de tentar evitar falhas completamente, o objetivo é minimizar os efeitos de um único componente com falha. Se houver um desastre, o Service Connector fará failover para a região emparelhada. Os clientes não precisarão fazer nada se a interrupção for decidida/declarada pela equipe do Service Connector.

Usaremos os termos RTO (Objetivo de Tempo de Recuperação) para indicar o tempo entre o início de uma interrupção que afeta o Conector de Serviço e a recuperação à disponibilidade total. Usaremos o RPO (Objetivo de Ponto de Recuperação) para indicar a hora entre a última operação restaurada corretamente e a hora do início da interrupção que afeta o Conector de Serviço. O RPO esperado e máximo é de 24 horas e o RTO é de 24 horas.

As operações no Conector de Serviço podem falhar durante o tempo de desastre, antes que o failover ocorra. Depois que o failover for concluído, os dados serão restaurados e o cliente não precisará executar nenhuma ação.

O conector de serviço manipula a BCRD (continuidade dos negócios e recuperação de desastre) para armazenamento e computação. A plataforma se esforça para ter o mínimo de impacto possível em caso de problemas de armazenamento/computação, em qualquer região. O design da camada de dados prioriza a disponibilidade em relação à latência em caso de desastre, o que significa que, se uma região falhar, o Service Connector tentará atender à solicitação do usuário final de sua região emparelhada.

Durante a ação de failover, o Service Connector manipula o remapeamento de DNS para as regiões disponíveis. Todos os dados e ações do modo de exibição do cliente servem como de costume após o failover. O Conector de Serviço alterará seu DNS em cerca de uma hora. Executar um failover manual levaria mais tempo. Como o Service Connector é um provedor de recursos criado com base em outros serviços do Azure, o tempo real depende do tempo de failover dos serviços subjacentes.

Suporte à região de recuperação de desastre

Atualmente, o Service Connector dá suporte aos seguintes pares de região. No caso de uma interrupção de região primária, o failover para a região secundária é iniciado automaticamente.

Primário Secundário
Leste dos EUA 2 EUAP Leste dos EUA
Centro-oeste dos EUA Centro-Oeste dos EUA 2
Oeste da Europa Europa Setentrional
Europa Setentrional Oeste da Europa
Leste dos EUA Oeste dos EUA 2
Oeste dos EUA 2 Leste dos EUA

Failover entre regiões

A Microsoft é responsável por lidar com failovers entre regiões. O Conector de Serviço executa verificações de integridade a cada 10 minutos e failovers regionais são detectados e tratados no back-end do Service Connector. O processo de failover não requer alterações nos aplicativos do cliente ou nas configurações do serviço de computação. O Service Connector usa uma configuração de cluster ativo-passivo com failover automático. Após uma recuperação de desastre, os clientes podem usar as funcionalidades completas fornecidas pelo Service Connector.

A verificação de integridade executada a cada 10 minutos simula o comportamento do usuário criando, validando e atualizando conexões para serviços de destino em cada um dos serviços de computação compatíveis com o Service Connector. A Microsoft começará a analisar e iniciar um failover do Service Connector se atendermos a qualquer uma das seguintes condições:

  • A verificação de integridade do serviço falha três vezes seguidas
  • Os serviços dependentes do Service Connector declaram uma interrupção
  • Clientes relatam uma interrupção na região

As solicitações para conexões de serviço são afetadas durante um failover. Depois que o failover for concluído, os dados de conexão de serviço serão restaurados. Você pode verificar a página de status do Azure para verificar o status de todos os serviços do Azure.

Próximas etapas

Acesse o artigo de conceito abaixo para saber mais sobre o Service Connector.