Fiabilidade no serviço de desidentificação dos Serviços de Dados de Saúde do Azure (pré-visualização)
Este artigo descreve o suporte à confiabilidade no serviço de desidentificação (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) consiste na recuperação 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 pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.
Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. 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 de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver 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 de plano de dados falham durante a interrupção, como solicitações de desidentificação ou API de trabalho. Nenhum dado do cliente é perdido, mas há o potencial de perda de metadados de 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, com a porta frontal do Azure usada para rotear o tráfego para ambas 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 esse failover geográfico é limitado ao tempo que o Azure Front Door leva para detetar que um serviço não está íntegro.
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 subscrição do Azure, crie uma conta gratuita do Azure antes de começar.
Para concluir este tutorial:
Use o ambiente Bash no Azure Cloud Shell. Para obter mais informações, consulte Guia de início rápido para Bash no Azure Cloud Shell.
Se preferir executar comandos de referência da CLI localmente, instale a CLI do Azure. Se estiver a utilizar o Windows ou macOS, considere executar a CLI do Azure num contentor Docker. Para obter mais informações, consulte Como executar a CLI do Azure em um contêiner do Docker.
Se estiver a utilizar uma instalação local, inicie sessão no CLI do Azure ao utilizar o comando az login. Para concluir o processo de autenticação, siga os passos apresentados no seu terminal. Para outras opções de entrada, consulte Entrar com a CLI do Azure.
Quando solicitado, instale a extensão da CLI do Azure na primeira utilização. Para obter mais informações sobre as extensões, veja Utilizar extensões com o CLI do Azure.
Execute o comando az version para localizar a versão e as bibliotecas dependentes instaladas. Para atualizar para a versão mais recente, execute o comando az upgrade.
Criar um grupo de recursos
Você precisa de duas instâncias de um serviço de desidentificação (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 (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.
Nota
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 | Description |
|---|---|---|
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 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 | Description |
|---|---|---|
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 | Description |
|---|---|---|
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 status da sonda de integridade. |
Adicionar origens ao grupo de origem da Porta da Frente do Azure
Execute az afd origin create para adicionar uma origem ao seu grupo de origem. Para os parâmetros e , substitua --host-name o valor <service-url-east-us> do espaço reservado pelo URL de serviço do Leste dos EUA, deixando de fora o esquema (https://).--origin-host-header 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 | Description |
|---|---|---|
host-name |
<service-url-east-us> |
O nome do host do serviço de desidentificaçã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 e , substitua --host-name o valor <service-url-west-us-2> do espaço reservado pelo URL do serviço West US 2, deixando de fora o esquema (https://).--origin-host-header
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. Essa rota encaminha solicitações do ponto de extremidade para 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 | Description |
|---|---|---|
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 seu browser. 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.
Gorjeta
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 seu browser. Desta vez, você verá uma mensagem de erro.
Reative o acesso à rede pública para um dos serviços de desidentificação. Atualize seu navegador e você verá o status de integridade novamente.
Agora você validou que pode acessar seus serviços por meio 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.
Clean up resources (Limpar 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.