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 funcionando pelo menos 99,9% do 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 os 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 desastres 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, os Aplicativos Azure Spring 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 seu 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 distribuirá automaticamente suas instâncias de serviço de aplicativo por 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 é encaminhado para todos os seus recursos de conexão disponíveis. Quando uma zona fica inativa, a plataforma deteta as instâncias perdidas, tenta encontrar automaticamente novas instâncias de substituição e distribui o tráfego conforme necessário.
Nota
Para criar, atualizar, validar e listar conexões de serviço, o Service Connector chama APIs de um serviço de computação e de 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 zone-down podem não ter êxito se o serviço de destino não puder ser alcançado. Esta limitação aplica-se ao Serviço de Aplicações, às Aplicações de Contentor do Azure e às Aplicações Azure Spring.
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 do Azure Container Apps.
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.
Crie um plano do Serviço de Aplicativo e inclua um
--zone-redundantparâmetro. Opcionalmente, inclua o parâmetro para especificar a--number-of-workerscapacidade. Saiba mais detalhes em 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 6Crie um aplicativo no Serviço de Aplicativo e uma conexão com sua conta de Armazenamento de Blob 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
Como você habilitou a redundância de zona para seu Serviço de Aplicativo, a conexão de serviço também é redundante de zona.
Gorjeta
É recomendável habilitar a redundância de zona para o serviço de destino. Em um cenário de zone-down, o tráfego para sua conexão será automaticamente espalhado 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.
Compreender a recuperação de desastres e a resiliência no Service Connector
A recuperação de desastres é o processo de restauração da funcionalidade do aplicativo após uma perda catastrófica.
Na nuvem, reconhecemos antecipadamente que falhas certamente acontecerão. Em vez de tentar evitar simplesmente as falhas, o objetivo é minimizar os efeitos da falha de um único componente. Se houver um desastre, o Service Connector fará failover para a região emparelhada. Os clientes não precisam fazer nada se a interrupção for decidida/declarada pela equipe do Service Connector.
Usaremos os termos RTO (Recovery Time Objetive) para indicar o tempo entre o início de uma interrupção que afeta o Service Connector e a recuperação até a disponibilidade total. Usaremos RPO (Recovery Point Objetive, objetivo de ponto de recuperação) para indicar o tempo entre a última operação restaurada corretamente e o tempo do início da interrupção que afeta o Service Connector. O RPO esperado e máximo é de 24 horas e o RTO é de 24 horas.
As operações no Service Connector podem falhar durante o período de desastre, antes que o failover aconteça. Quando o failover for concluído, os dados serão restaurados e o cliente não precisará tomar nenhuma ação.
O conector de serviço lida com a continuidade de negócios e a recuperação de desastres (BCRD) 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 sobre a latência no caso de um desastre – o que significa que, se uma região ficar inativa, 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 lida com o remapeamento de DNS para as regiões disponíveis. Todos os dados e ações da visão do cliente servem como de costume após o failover. O Service Connector mudará seu DNS em cerca de uma hora. Executar um failover manual levaria mais tempo. Como o Service Connector é um provedor de recursos criado sobre outros serviços do Azure, o tempo real depende do tempo de failover dos serviços subjacentes.
Suporte à região de recuperação de desastres
Atualmente, o Service Connector suporta os seguintes pares de regiões. No caso de uma interrupção da região primária, o failover para a região secundária é iniciado automaticamente.
| Primário | Secundária |
|---|---|
| E.U.A. Leste 2 - EUAP | E.U.A. Leste |
| E.U.A. Centro-Oeste | Centro-Oeste dos EUA 2 |
| Europa Ocidental | Europa do Norte |
| Europa do Norte | Europa Ocidental |
| E.U.A. Leste | E.U.A. Oeste 2 |
| E.U.A. Oeste 2 | E.U.A. Leste |
Failover entre regiões
A Microsoft é responsável por lidar com failovers entre regiões. O Service Connector executa verificações de integridade a cada 10 minutos e failovers regionais são detetados e manipulados no back-end do Service Connector. O processo de failover não requer nenhuma alteração nos aplicativos ou configurações de serviço de computação do cliente. 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 todas as funcionalidades 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 suportados pelo 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
- Os clientes relatam uma interrupção de região
As solicitações para conexões de serviço são afetadas durante um failover. Quando o failover estiver concluído, os dados da 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óximos passos
Consulte o artigo de conceito abaixo para saber mais sobre o Service Connector.