Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo descreve o suporte de fiabilidade no serviço de anonimização (pré-visualização). Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, consulte Confiabilidade do Azure.
Recuperação de desastres entre regiões
A recuperação de desastres (DR) refere-se a práticas que as organizações usam para se recuperar de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Para DR, a Microsoft usa o modelo de responsabilidade compartilhada . Neste modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam dados automaticamente nem possuem mecanismos de fallback para mudar de uma região com falha para outra região ativada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas da plataforma Azure como serviço (PaaS) fornece recursos e orientações para dar suporte à DR. Você pode usar recursos específicos do serviço para apoiar a recuperação rápida e ajudar a desenvolver o seu plano de DR.
Cada serviço de desidentificação (visualização) é implantado em uma única região do Azure. Se uma região inteira não estiver disponível ou o desempenho estiver significativamente degradado:
- A funcionalidade do plano de controle ARM é limitada a somente leitura durante a interrupção. Os metadados do serviço (como propriedades de recursos) são sempre copiados fora da região pela Microsoft. Quando a interrupção terminar, você poderá ler e gravar no plano de controle.
- Todas as solicitações do plano de dados falham durante a interrupção, como solicitações de desidentificação ou de API de tarefa. Embora nenhum dado do cliente seja perdido, existe a possibilidade de perda de metadados relacionados ao progresso do trabalho. Quando a interrupção terminar, você poderá ler e gravar no plano de dados.
Tutorial de recuperação de desastres
Se uma região inteira do Azure não estiver disponível, você ainda poderá garantir a alta disponibilidade de suas cargas de trabalho. Você pode implantar dois ou mais serviços de desidentificação em uma configuração ativa-ativa, usando o Azure Front Door para direcionar o tráfego para todas as regiões.
Com este exemplo de arquitetura:
- Serviços idênticos de desidentificação são implantados em duas regiões separadas.
- O Azure Front Door é usado para rotear o tráfego para ambas as regiões.
- Durante um desastre, uma região fica offline e o Azure Front Door encaminha o tráfego exclusivamente para a outra região. O objetivo de tempo de recuperação durante tal geo-failover é limitado ao tempo que o Azure Front Door leva para detetar que um serviço está com problemas.
RTO e RPO
Se você adotar a configuração ativo-ativo, deverá esperar um RTO (Recovery Time Objetive, objetivo de tempo de recuperação) de 5 minutos. Em qualquer configuração, você deve esperar um RPO (Recovery Point Objetive, objetivo de ponto de recuperação) de 0 minutos (nenhum dado do cliente será perdido).
Validar o plano de recuperação de desastres
Pré-requisitos
Se não tiver uma conta do Azure, crie uma conta gratuita antes de começar.
Para concluir este tutorial:
Utilize o ambiente Bash no Azure Cloud Shell. Para mais informações, veja Get started with Azure Cloud Shell.
Se preferir executar comandos de referência da CLI localmente, instale o CLI do Azure. Se estiver a usar Windows ou macOS, considere executar o Azure CLI num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.
Se você estiver usando uma instalação local, entre na CLI do Azure usando o comando az login . Para concluir o processo de autenticação, siga os passos exibidos no seu terminal. Para outras opções de entrada, consulte Autenticar no Azure usando a CLI do Azure.
Quando solicitado, instale a extensão do Azure CLI na primeira utilização. Para obter mais informações sobre extensões, consulte Usar e gerenciar extensões com a CLI do Azure.
Execute az version para descobrir a versão e as bibliotecas dependentes que estão instaladas. Para atualizar para a versão mais recente, execute az upgrade.
Criar um grupo de recursos
Você precisa de duas instâncias de um serviço de anonimização (versão de pré-visualização) em diferentes regiões do Azure para este tutorial. O tutorial usa as regiões Leste dos EUA e Oeste dos EUA 2, mas sinta-se à vontade para escolher suas próprias regiões.
Para simplificar o gerenciamento e a limpeza, use um único grupo de recursos para todos os recursos neste tutorial. Considere o uso de grupos de recursos separados para cada região/recurso para isolar ainda mais seus recursos em uma situação de recuperação de desastres.
Execute o seguinte comando para criar seu grupo de recursos.
az group create --name my-deid --location eastus
Criar serviços de desidentificação (pré-visualização)
Siga as etapas em Guia de início rápido: implante o serviço de desidentificação (visualização) para criar dois serviços separados, um no Leste dos EUA e outro no Oeste dos EUA 2.
Observe a URL de serviço de cada serviço de desidentificação para que você possa definir os endereços de back-end ao implantar a Porta da Frente do Azure na próxima etapa.
Criar uma porta de entrada do Azure
Uma implantação de várias regiões pode usar uma configuração ativa-ativa ou ativa-passiva. Uma configuração ativo-ativo distribui solicitações em várias regiões ativas. Uma configuração ativa-passiva mantém instâncias em execução na região secundária, mas não envia tráfego para lá, a menos que a região primária falhe. O Azure Front Door tem um recurso interno que permite habilitar essas configurações. Para obter mais informações sobre como projetar aplicativos para alta disponibilidade e tolerância a falhas, consulte Arquitetar aplicativos do Azure para resiliência e disponibilidade.
Criar um perfil do Azure Front Door
Agora você cria um Azure Front Door Premium para rotear o tráfego para seus serviços.
Execute az afd profile create para criar um perfil do Azure Front Door.
Observação
Se você quiser implantar o Azure Front Door Standard em vez de Premium, substitua o --sku valor do parâmetro por Standard_AzureFrontDoor. Não é possível implantar regras gerenciadas com a Política WAF se escolher a camada Padrão. Para obter uma comparação detalhada dos níveis de preços, consulte Comparação de camadas da Porta da Frente do Azure.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| Parâmetro | Valor | Descrição |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nome para o perfil da Porta da Frente do Azure, que é exclusivo dentro do grupo de recursos. |
resource-group |
my-deid |
O grupo de recursos que contém os recursos deste tutorial. |
sku |
Premium_AzureFrontDoor |
A camada de preço do perfil do Azure Front Door. |
Adicionar um ponto de extremidade do Azure Front Door
Execute az afd endpoint create para criar um ponto de extremidade em seu perfil do Azure Front Door. Este ponto de extremidade encaminha solicitações para os seus serviços. Você pode criar vários pontos de extremidade em seu perfil depois de concluir este guia.
az afd endpoint create --resource-group my-deid --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled
| Parâmetro | Valor | Descrição |
|---|---|---|
endpoint-name |
myendpoint |
Nome do ponto de extremidade sob o perfil, que é exclusivo globalmente. |
enabled-state |
Enabled |
Se esse ponto de extremidade deve ser habilitado. |
Criar um grupo de origem do Azure Front Door
Execute az afd origin-group create para criar um grupo de origem que contenha seus dois serviços de desidentificação.
az afd origin-group create --resource-group my-deid --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Https --probe-interval-in-seconds 60 --probe-path /health --sample-size 1 --successful-samples-required 1 --additional-latency-in-milliseconds 50 --enable-health-probe
| Parâmetro | Valor | Descrição |
|---|---|---|
origin-group-name |
myorigingroup |
Nome do grupo de origem. |
probe-request-type |
GET |
O tipo de solicitação de sonda de saúde que é feita. |
probe-protocol |
Https |
Protocolo a utilizar para sonda de saúde. |
probe-interval-in-seconds |
60 |
O número de segundos entre as sondas de saúde. |
probe-path |
/health |
O caminho relativo à origem que é usado para determinar a integridade da origem. |
sample-size |
1 |
O número de amostras a serem consideradas para decisões de balanceamento de carga. |
successful-samples-required |
1 |
O número de amostras dentro do período de amostragem que devem ser bem-sucedidas. |
additional-latency-in-milliseconds |
50 |
A latência extra em milissegundos para que as sondas caiam no bucket de latência mais baixa. |
enable-health-probe |
Alterne para controlar o estado da sonda de monitorização. |
Adicionar origins ao grupo de origem da Azure Front Door
Execute az afd origin create para adicionar uma origem ao seu grupo de origem. Para os parâmetros --host-name e --origin-host-header, substitua o valor do espaço reservado <service-url-east-us> pelo URL do serviço do Leste dos EUA, deixando de fora o esquema (https://). Você deve ter um valor como abcdefghijk.api.eastus.deid.azure.com.
az afd origin create --resource-group my-deid --host-name <service-url-east-us> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid1 --origin-host-header <service-url-east-us> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
| Parâmetro | Valor | Descrição |
|---|---|---|
host-name |
<service-url-east-us> |
O nome de host do serviço de anonimização primário. |
origin-name |
deid1 |
Nome da origem. |
origin-host-header |
<service-url-east-us> |
O cabeçalho do host a ser enviado para solicitações para essa origem. |
priority |
1 |
Defina esse parâmetro como 1 para direcionar todo o tráfego para o serviço de desidentificação principal. |
weight |
1000 |
Peso da origem num determinado grupo de origem para o equilíbrio da carga. Deve ter entre 1 e 1000. |
enabled-state |
Enabled |
Se essa origem deve ser habilitada. |
https-port |
443 |
A porta usada para solicitações HTTPS para a origem. |
Repita este passo para adicionar a sua segunda origem. Para os parâmetros --host-name e --origin-host-header, substitua o valor do espaço reservado <service-url-west-us-2> pelo URL do serviço West US 2, omitindo o esquema (https://).
az afd origin create --resource-group my-deid --host-name <service-url-west-us-2> --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name deid2 --origin-host-header <service-url-west-us-2> --priority 1 --weight 1000 --enabled-state Enabled --https-port 443
Preste atenção aos --priority parâmetros em ambos os comandos. Como ambas as origens estão definidas como prioridade 1, o Azure Front Door trata ambas as origens como tráfego ativo e direto para ambas as regiões. Se a prioridade para uma origem estiver definida como 2, o Azure Front Door tratará essa origem como secundária e direcionará todo o tráfego para a outra origem, a menos que ele fique inativo.
Adicionar uma rota do Azure Front Door
Execute az afd route create para mapear seu ponto de extremidade para o grupo de origem. Esta rota encaminha solicitações do endpoint para o seu grupo de origem.
az afd route create --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --origin-group myorigingroup --supported-protocols Https --link-to-default-domain Enabled
| Parâmetro | Valor | Descrição |
|---|---|---|
endpoint-name |
myendpoint |
Nome do ponto de extremidade. |
forwarding-protocol |
MatchRequest | Protocolo que esta regra usa ao encaminhar tráfego para back-ends. |
route-name |
route |
Nome da rota. |
supported-protocols |
Https |
Lista de protocolos suportados para esta rota. |
link-to-default-domain |
Enabled |
Se essa rota está vinculada ao domínio de ponto de extremidade padrão. |
Aguarde cerca de 15 minutos para que esta etapa seja concluída, pois leva algum tempo para que essa alteração se propague globalmente. Após esse período, sua porta frontal do Azure estará totalmente funcional.
Teste a porta da frente
Quando você cria o perfil Azure Front Door Standard/Premium, leva alguns minutos para que a configuração seja implantada globalmente. Uma vez concluído, você pode acessar o host frontend que você criou.
Execute az afd endpoint show para obter o nome do host do ponto de extremidade Front Door. Deve parecer abddefg.azurefd.net
az afd endpoint show --resource-group my-deid --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"
Em um navegador, vá para o nome de host do ponto de extremidade que o comando anterior retornou: <endpoint>.azurefd.net/health. Sua solicitação deve ser encaminhada automaticamente para o serviço principal de desidentificação no leste dos EUA.
Para testar o failover global instantâneo:
Abra um navegador e vá para o nome do host do ponto final:
<endpoint>.azurefd.net/health.Siga as etapas em Configurar acesso privado para desabilitar o acesso à rede pública para o serviço de desidentificação no Leste dos EUA.
Atualize o navegador. Você deve ver a mesma página de informações porque o tráfego agora é direcionado para o serviço de desidentificação no oeste dos EUA 2.
Sugestão
Talvez seja necessário atualizar a página algumas vezes para que o failover seja concluído.
Agora desative o acesso à rede pública para o serviço de desidentificação no oeste dos EUA 2.
Atualize o navegador. Desta vez, você verá uma mensagem de erro.
Reative o acesso à rede pública para um dos serviços de desidentificação. Recarregue o seu navegador e deverá ver o estado de saúde novamente.
Agora validaste que podes aceder aos teus serviços através do Azure Front Door e que o failover funciona como pretendido. Habilite o acesso à rede pública no outro serviço se tiver terminado o teste de failover.
Limpeza de recursos
Nos passos anteriores, criou os recursos do Azure num grupo de recursos. Se você não espera precisar desses recursos no futuro, exclua o grupo de recursos executando o seguinte comando:
az group delete --name my-deid
Esse comando pode levar alguns minutos para ser concluído.
Iniciar a recuperação
Para verificar o status de recuperação do seu serviço, você pode enviar solicitações para <service-url>/health.