Alta disponibilidade para o Service Connector
O Service Connector dá suporte às zonas de disponibilidade do Azure para ajudar você a ter resiliência e confiabilidade para suas cargas de trabalho comercialmente críticas. A meta da arquitetura de alta disponibilidade no Service Connector é garantir que suas conexões de serviço estejam ativas e em execução 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 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 ficarão automaticamente com redundância 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 nesse 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 recursos de conexão disponíveis. Quando uma zona falha, a plataforma detecta as instâncias perdidas, tenta automaticamente localizar 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 baixa podem não ser bem-sucedidas se o serviço de destino não puder ser alcançado. Essa limitação se aplica ao Serviço de Aplicativo, aos Aplicativos de Contêiner do Azure e aos Aplicativos de Primavera do Azure.
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 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 parâmetro
--zone-redundant. Opcionalmente inclua o parâmetro--number-of-workerspara especificar a capacidade. 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 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
Como você habilitou a redundância de zona para o Serviço de Aplicativo, a conexão de serviço também é com redundância de zona.
Dica
É recomendável habilitar a redundância de zona para o seu serviço de destino. Em um cenário de zona inativa, o tráfego para sua conexão será espalhado automaticamente para outras zonas. No entanto, criar, validar e atualizar conexões depende 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 resiliência e recuperação de desastre no Service Connector
Recuperação de desastre é o processo de restaurar a funcionalidade do aplicativo após uma perda catastrófica.
Na nuvem, reconhecemos antecipadamente que, certamente, ocorrerão falhas. Em vez de tentar evitar completamente a falha, a meta é minimizar os efeitos de uma falha em um componente individual. 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 (Recovery Time Objective) para indicar o tempo entre o início de uma interrupção que afeta o Service Connector e a recuperação para disponibilidade total. Usaremos o RPO (Recovery Point Objective, objetivo do 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. 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 possível de impacto 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 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 manipula o remapeamento 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 Service Connector 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 pares de região a seguir. No caso de uma interrupção da região primária, o failover para a região secundária começa automaticamente.
| Primária | Secundário |
|---|---|
| Leste dos EUA 2 EUAP | Leste dos EUA |
| Centro-Oeste dos EUA | Centro-Oeste dos EUA 2 |
| Europa Ocidental | Norte da Europa |
| Norte da Europa | Europa Ocidental |
| 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 Service Connector executa verificações de integridade a cada 10 minutos e os failovers regionais são detectados e tratados no back-end do Service Connector. O processo de failover não requer nenhuma alteração nos aplicativos do cliente ou 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 que é 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 com suporte do 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 de 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.