Confiabilidade no serviço de desidentificação do Serviços de Dados de Saúde do Azure (versão prévia)
Este artigo descreve o suporte à confiabilidade no serviço de desidentificação (versão prévia). Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.
Recuperação de desastre entre regiões
A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.
Quando o assunto é 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 de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em 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 PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.
Cada serviço de desidentificação (versão prévia) é 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 painel de controle do ARM é limitada a somente leitura durante a interrupção. A Microsoft sempre faz backup fora da região dos metadados de serviço (como as propriedades do recurso). Assim que a interrupção terminar, você poderá ler e gravar no painel de controle.
- Todas as solicitações do plano de dados falham durante a interrupção, como solicitações da API de desidentificação ou de trabalho. Nenhum dado do cliente é perdido, mas há o potencial para que metadados de progresso do trabalho sejam perdidos. Depois que a interrupção terminar, você poderá ler e gravar no plano de dados.
Tutorial de recuperação de desastre
Se uma região inteira do Azure não estiver disponível, você ainda poderá garantir 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 o Azure Front Door usado para rotear o tráfego para as duas regiões.
Com este exemplo de arquitetura:
- Serviços de desidentificação idênticos são implantados em duas regiões separadas.
- O Azure Front Door é usado para rotear o tráfego para as duas regiões.
- Durante um desastre, uma região fica offline e o Azure Front Door roteia 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 detectar que um serviço está não íntegro.
RTO e RPO
Se adotar a configuração ativa-ativa, você deverá esperar um RTO (Objetivo de tempo de recuperação) de 5 minutos. Em toda configuração, você deve esperar um RPO (objetivo de ponto de recuperação) de 0 minutos (nenhum dado do cliente será perdido).
Validar plano de recuperação de desastre
Pré-requisitos
Caso você não tenha uma assinatura 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, confira Início Rápido para Bash no Azure Cloud Shell.
Se preferir executar os comandos de referência da CLI localmente, instale a CLI do Azure. Para execuções no Windows ou no macOS, considere executar a CLI do Azure em um contêiner do Docker. Para obter mais informações, confira Como executar a CLI do Azure em um contêiner do Docker.
Se estiver usando uma instalação local, entre com a CLI do Azure usando o comando az login. Para concluir o processo de autenticação, siga as etapas exibidas no terminal. Para ver outras opções de entrada, confira Conectar-se com a CLI do Azure.
Quando solicitado, instale a extensão da CLI do Azure no primeiro uso. Para obter mais informações sobre extensões, confira Usar extensões com a CLI do Azure.
Execute az version para localizar a versão e as bibliotecas dependentes que estão instaladas. Para fazer a atualização 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 desidentificação (versão prévia) em regiões diferentes do Azure para este tutorial. O tutorial usa as regiões Leste dos EUA e Oeste dos EUA 2, mas fique à 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 usar grupos de recursos separados para cada região/recurso para isolar ainda mais seus recursos em uma situação de recuperação de desastre.
Execute o comando a seguir para criar um grupo de recursos.
az group create --name my-deid --location eastus
Criar serviços de desidentificação (versão prévia)
Siga as etapas no Início Rápido: implante o serviço de desidentificação (versão prévia) para criar dois serviços separados, um no Leste dos EUA e outro no Oeste dos EUA 2.
Anote 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 o Azure Front Door na próxima etapa.
Criar um Azure Front Door
Uma implantação de várias regiões pode usar uma configuração ativa-ativa ou ativa-passiva. A configuração ativa-ativa distribui as solicitações entre várias regiões ativas. A configuração ativa-passiva continua executando instâncias 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 integrado que permite habilitar essas configurações. Para obter mais informações sobre como criar aplicativos para alta disponibilidade e tolerância a falhas, consulte Arquitetar aplicativos do Azure para proporcionar resiliência e disponibilidade.
Criar um perfil do Azure Front Door
Agora, crie um Azure Front Door Premium, para rotear o tráfego para os 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 valor do parâmetro --sku por Standard_AzureFrontDoor. Não é possível implantar regras gerenciadas com a Política do WAF se escolher a camada Standard. Para obter uma comparação detalhada dos tipos de preço, confira Comparação de camadas do Azure Front Door.
az afd profile create --profile-name myfrontdoorprofile --resource-group my-deid --sku Premium_AzureFrontDoor
| Parâmetro | Valor | Descrição |
|---|---|---|
profile-name |
myfrontdoorprofile |
Nome do perfil do Azure Front Door, 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 |
O tipo 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. Esse ponto de extremidade roteia 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 | Descrição |
|---|---|---|
endpoint-name |
myendpoint |
Nome do ponto de extremidade no perfil, que é globalmente exclusivo. |
enabled-state |
Enabled |
Decisão de habilitar (ou não) esse ponto de extremidade. |
Criar um grupo de origem do Azure Front Door
Execute az afd origin-group create para criar um grupo de origem contendo 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 investigação de integridade que é feita. |
probe-protocol |
Https |
Protocolo a ser usado na investigação de integridade. |
probe-interval-in-seconds |
60 |
O número de segundos entre as investigações de integridade. |
probe-path |
/health |
O caminho relativo à origem usada 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 amostras que devem ser bem-sucedidas. |
additional-latency-in-milliseconds |
50 |
A latência extra em milissegundos para que as investigações se enquadrem no bucket de latência mais baixa. |
enable-health-probe |
Alternância para controlar o status da investigação de integridade. |
Adicionar origens ao grupo de origem do Azure Front Door
Execute az afd origin create para adicionar uma origem ao grupo de origem. Para os parâmetros --host-name e --origin-host-header, substitua o valor do espaço reservado <service-url-east-us> pela URL de 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 do host do serviço de desidentificação primário. |
origin-name |
deid1 |
Nome de origem. |
origin-host-header |
<service-url-east-us> |
O cabeçalho do host a ser enviado nas 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 primário. |
weight |
1000 |
Peso da origem em um determinado grupo de origem para balanceamento de carga. Precisa estar entre 1 e 1000. |
enabled-state |
Enabled |
Decisão de habilitar (ou não) essa origem. |
https-port |
443 |
A porta usada nas solicitações HTTP para a origem. |
Repita essa etapa e adicione 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> pela URL de serviço do Oeste dos EUA 2, deixando de fora 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 parâmetros --priority nos dois comandos. Como as duas origens são definidas como prioridade 1, o Azure Front Door trata as duas origens como tráfego ativo e direto para as duas regiões. Se a prioridade de 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 ela falte.
Adicionar uma rota do Azure Front Door
Execute az afd route create para mapear o ponto de extremidade para o grupo de origem. Essa rota encaminha solicitações do ponto de extremidade 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 | O protocolo que essa regra usa ao encaminhar o tráfego aos back-ends. |
route-name |
route |
O nome da rota. |
supported-protocols |
Https |
Lista de protocolos com suporte para essa rota. |
link-to-default-domain |
Enabled |
Se esta rota está vinculada ao domínio do ponto de extremidade padrão ou não. |
Aguarde cerca de 15 minutos para que essa etapa seja concluída, pois leva algum tempo para que essa alteração se propague de maneira global. Após esse período, o Azure Front Door estará totalmente funcional.
Testar o Front Door
Quando você cria o perfil do Azure Front Door Standard/Premium, a configuração leva alguns minutos para ser implantada globalmente. Após a conclusão, você pode acessar o host de front-end que criou.
Execute az afd endpoint show para obter o nome do host do ponto de extremidade do Front Door. Sua aparência deve ser parecida com 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 do host do ponto de extremidade que o comando anterior retornou: <endpoint>.azurefd.net/health. Sua solicitação deve ser roteada automaticamente para o serviço de desidentificação primário no Leste dos EUA.
Para testar o failover global instantâneo:
Abra o navegador e vá para o nome do host do ponto de extremidade:
<endpoint>.azurefd.net/health.Siga as etapas em Configurar o acesso privado para desabilitar o acesso à rede pública para o serviço de desidentificação no Leste dos EUA.
Atualize seu navegador. Você deverá 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.
Dica
Talvez seja necessário atualizar a página algumas vezes para que o failover seja concluído.
Agora desabilite o acesso à rede pública para o serviço de desabilitação no Oeste dos EUA 2.
Atualize seu navegador. Desta vez, você deverá ver uma mensagem de erro.
Habilite novamente o acesso à rede pública para um dos serviços de desidentificação. Atualize o navegador e você verá o status da integridade novamente.
Agora você validou que pode acessar seus serviços por meio do Azure Front Door e que o failover funciona conforme o esperado. Habilite o acesso à rede pública no outro serviço se terminar o teste de failover.
Limpar os recursos
Nas etapas anteriores, você criou os recursos do Azure em um grupo de recursos. Se você achar que não 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 recuperação
Para verificar o status de recuperação do serviço, você pode enviar solicitações para <service-url>/health.