Recuperação de desastre para a API do Azure para FHIR

A API do Azure para FHIR é um serviço totalmente gerenciado, baseado em FHIR® (Fast Healthcare Interoperability Resources). Para atender aos requisitos de negócios e conformidade, você pode usar o recurso dr (recuperação de desastre) para a API do Azure para FHIR.

O recurso de DR fornece um RPO (Objetivo de Ponto de Recuperação) de 15 minutos e um RTO (Objetivo de Tempo de Recuperação) de 60 minutos.

Como habilitar a DR

Para habilitar o recurso de DR, crie um tíquete de suporte único. Você pode escolher uma região emparelhada do Azure ou outra região em que há suporte para a API do Azure para FHIR. A equipe de suporte da Microsoft habilitará o recurso de DR com base na prioridade de suporte.

Como funciona o processo de DR

O processo de DR envolve as seguintes etapas:

• Replicação de dados
• failover automático
• Recuperação de região afetada
• Failback manual

Replicação de dados na região secundária

Por padrão, a API do Azure para FHIR oferece proteção de dados por meio de backup e restauração. Quando o recurso de recuperação de desastre está habilitado, a replicação de dados começa. Um réplica de dados é criado e sincronizado automaticamente na região secundária do Azure. A replicação de dados inicial pode levar alguns minutos a algumas horas, ou mais, dependendo da quantidade de dados. O réplica de dados secundários é uma replicação dos dados primários. Ele é usado diretamente para recuperar o serviço e ajuda a acelerar o processo de recuperação.

Vale a pena observar que as RU/s de taxa de transferência devem ter os mesmos valores nas regiões primária e secundária.

failover automático

Durante uma interrupção de região primária, a API do Azure para FHIR faz failover automaticamente para a região secundária e o mesmo ponto de extremidade de serviço é usado. Espera-se que o serviço seja retomado em uma hora ou menos, e a possível perda de dados é de até 15 minutos de dados. Outras alterações de configuração podem ser necessárias. Para obter mais informações, consulte Alterações de configuração na DR.

Recuperação de região afetada

Depois que a região afetada for recuperada, ela estará disponível automaticamente como uma região secundária e a replicação de dados será reiniciada. Você pode iniciar o processo de recuperação de dados ou aguardar até que a etapa de failback seja concluída.

Quando a computação tiver falhado de volta para a região recuperada e os dados não tiverem, poderá haver possíveis latências de rede. O main motivo é que a computação e os dados estão em duas regiões diferentes. As latências de rede devem desaparecer automaticamente assim que os dados falharem de volta para a região recuperada por meio de um gatilho manual.

Failback manual

A computação faz failback automaticamente para a região recuperada. Os dados são alternados manualmente para a região recuperada pela equipe de suporte da Microsoft usando o script.

Alterações de configuração na DR

Outras alterações de configuração podem ser necessárias quando Link Privado, CMK (Chave Gerenciada pelo Cliente), Conector FHIR IoMT (Internet das Coisas Médicas) e $export são usados.

Link privado

Você pode habilitar o recurso de link privado antes ou depois que a API do Azure para FHIR tiver sido provisionada. Você também pode provisionar o link privado antes ou depois que o recurso de DR tiver sido habilitado. Consulte a lista abaixo quando estiver pronto para configurar Link Privado para DR.

• Configure Link Privado do Azure na região primária. Esta etapa não é necessária na região secundária. Para obter mais informações, consulte Configurar link privado

• Crie uma VNet do Azure na região primária e outra VNet na região secundária. Para obter informações, consulte Criar uma rede virtual usando o portal do Azure.

• Na região primária, a VNet cria um emparelhamento VNet para a VNet da região secundária. Para obter mais informações, consulte Emparelhamento de rede virtual do Azure.

• Use as configurações padrão ou você pode adaptar a configuração conforme necessário. A importância é que o tráfego possa fluir entre as duas redes virtuais.

• Quando o DNS privado é configurado, a VNet na região secundária precisa ser configurada manualmente como um "Links de rede virtual". A VNet primária já deveria ter sido adicionada como parte do fluxo de criação do ponto de extremidade Link Privado. Para obter mais informações, consulte Links de rede virtual.

• Opcionalmente, configure uma VM na VNet da região primária e outra na VNet da região secundária. Você pode acessar a API do Azure para FHIR de ambas as VMs.

O recurso de link privado deve continuar funcionando durante uma interrupção regional e após a conclusão do failback. Para obter mais informações, consulte Configurar link privado.

Observação

Configurar redes virtuais e emparelhamento VNet não afeta a replicação de dados.

CMK

Seu acesso à API do Azure para FHIR será mantido se o cofre de chaves que hospeda a chave gerenciada em sua assinatura estiver acessível. Há um possível tempo de inatividade temporário, pois Key Vault pode levar até 20 minutos para restabelecer sua conexão. Para obter mais informações, confira Disponibilidade e redundância do Azure Key Vault.

$export

O trabalho de exportação será coletado de outra região após 10 minutos sem uma atualização para o trabalho status. Siga as diretrizes para o armazenamento do Azure para recuperar sua conta de armazenamento em caso de interrupção regional. Para saber mais, confira Recuperação de desastre e failover da conta de armazenamento.

Certifique-se de conceder as mesmas permissões à identidade do sistema da API do Azure para FHIR. Além disso, se a conta de armazenamento estiver configurada com redes selecionadas, consulte Como exportar dados FHIR.

Como testar a DR

Embora não seja necessário, você pode testar o recurso de DR em um ambiente de não produção. Para o teste de DR, somente os dados serão incluídos e a computação não será incluída.

Considere as etapas a seguir para o teste de DR.

• Preparar um ambiente de teste com dados de teste. É recomendável que você use uma instância de serviço com pequenas quantidades de dados para reduzir o tempo para replicar os dados.

• Crie um tíquete de suporte e forneça sua assinatura do Azure, a região preferencial do Azure para o failover e o nome do serviço para a API do Azure para FHIR para seu ambiente de teste.

• Crie um plano de teste, como faria com qualquer teste de dr.

• A equipe de suporte da Microsoft habilita o recurso de recuperação de desastre e confirma que a região de failover preferencial pelo cliente foi adicionada

• Realize o teste de DR e registre os resultados do teste, que devem incluir problemas de perda de dados e latência de rede.

• Para failback, notifique a equipe de suporte da Microsoft para concluir a etapa de failback.

• (Opcional) Compartilhe qualquer comentário com a equipe de suporte da Microsoft.

Observação

O teste de DR dobrará o custo do ambiente de teste durante o teste. Nenhum custo adicional incorrerá depois que o teste de DR for concluído e o recurso de recuperação de desastre estiver desabilitado.

Custo da recuperação de desastre

O recurso de recuperação de desastre gera custos extras porque os dados da computação e dos dados réplica em execução no ambiente na região secundária. Para obter mais detalhes sobre preços, consulte a página da Web de preços da API do Azure para FHIR .

Observação

A oferta de DR está sujeita ao SLA para a API do Azure para FHIR, 1.0.

Próximas etapas

Neste artigo, você aprendeu como funciona a DR para a API do Azure para FHIR e como habilitá-la. Para saber mais sobre a API do Azure para outros recursos com suporte do FHIR, confira

Recursos com suporte do FHIR

FHIR® é uma marca registrada da HL7 e é usado com a permissão da HL7.