Recuperação após desastre da API do Azure para FHIR
A API do Azure para FHIR é um serviço totalmente gerido, baseado em Fast Healthcare Interoperability Resources (FHIR®). Para cumprir os requisitos empresariais e de conformidade, pode utilizar a funcionalidade de recuperação após desastre (DR) da API do Azure para FHIR.
A funcionalidade DE DR fornece um Objetivo de Ponto de Recuperação (RPO) de 15 minutos e um Objetivo de Tempo de Recuperação (RTO) de 60 minutos.
Como ativar a DR
Para ativar a funcionalidade DR, crie um pedido de suporte único. Pode escolher uma região emparelhada do Azure ou outra região onde a API do Azure para FHIR seja suportada. A equipa de suporte da Microsoft ativará a funcionalidade de DR com base na prioridade de suporte.
Como funciona o processo de DR
O processo de DR envolve os seguintes passos:
- Replicação de dados
- Ativação pós-falha automática
- Recuperação da região afetada
- Reativação pós-falha manual
Replicação de dados na região secundária
Por predefinição, a API do Azure para FHIR oferece proteção de dados através da cópia de segurança e restauro. Quando a funcionalidade de recuperação após desastre está ativada, começa a replicação de dados. Uma réplica de dados é criada e sincronizada automaticamente na região secundária do Azure. A replicação de dados inicial pode demorar alguns minutos a algumas horas, ou mais, dependendo da quantidade de dados. A réplica de dados secundária é uma replicação dos dados primários. É utilizado diretamente para recuperar o serviço e ajuda a acelerar o processo de recuperação.
Vale a pena notar que as RU/s de débito têm de ter os mesmos valores nas regiões primária e secundária.
Ativação pós-falha automática
Durante uma falha na região primária, a API do Azure para FHIR efetua automaticamente a ativação pós-falha para a região secundária e é utilizado o mesmo ponto final de serviço. Espera-se que o serviço seja retomado dentro de uma hora ou menos e que a potencial perda de dados seja de até 15 minutos de dados. Podem ser necessárias outras alterações de configuração. Para obter mais informações, veja Alterações de configuração na DR.
Recuperação da região afetada
Após a recuperação da região afetada, esta fica automaticamente disponível como uma região secundária e a replicação de dados é reiniciada. Pode iniciar o processo de recuperação de dados ou aguardar até que o passo de reativação pós-falha seja concluído.
Quando a computação tiver efetuado a reativação pós-falha para a região recuperada e os dados não forem recuperados, poderão existir potenciais latências de rede. A principal razão é 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 voltarem à região recuperada através de um acionador manual.
Reativação pós-falha manual
A computação efetua a reativação pós-falha automaticamente para a região recuperada. Os dados são mudados manualmente para a região recuperada pela equipa de suporte da Microsoft através do script.
Alterações de configuração na DR
Podem ser necessárias outras alterações de configuração quando são utilizadas Private Link, Chave Gerida pelo Cliente (CMK), Conector IoMT FHIR (Internet das Coisas Médicas) e $export.
Ligação privada
Pode ativar a funcionalidade de ligação privada antes ou depois de a API do Azure para FHIR ter sido aprovisionada. Também pode aprovisionar uma ligação privada antes ou depois de a funcionalidade DR ter sido ativada. Veja a lista abaixo quando estiver pronto para configurar Private Link para DR.
Configure Azure Private Link na região primária. Este passo não é necessário na região secundária. Para obter mais informações, veja Configurar a ligação privada
Crie uma VNet do Azure na região primária e outra VNet na região secundária. Para obter informações, veja Criar uma rede virtual com o portal do Azure.
Na região primária, a VNet cria um VNet peering para a VNet da região secundária. Para obter mais informações, veja Peering de rede virtual.
Utilize as predefinições ou pode personalizar a configuração conforme necessário. A importância é que o tráfego possa fluir entre as duas redes virtuais.
Quando o DNS privado está configurado, a VNet na região secundária tem de ser configurada manualmente como uma "Ligações de rede virtual". A VNet principal já deveria ter sido adicionada como parte do fluxo de criação do ponto final Private Link. Para obter mais informações, veja Ligações de rede virtual.
Opcionalmente, configure uma VM na VNet da região primária e outra na VNet da região secundária. Pode aceder à API do Azure para FHIR a partir de ambas as VMs.
A funcionalidade de ligação privada deve continuar a funcionar durante uma indisponibilidade regional e após a conclusão da reativação pós-falha. Para obter mais informações, veja Configurar a ligação privada.
Nota
A configuração de redes virtuais e do VNet Peering não afeta a replicação de dados.
CMK
O seu acesso à API do Azure para FHIR será mantido se o cofre de chaves que aloja a chave gerida na sua subscrição estiver acessível. Existe um possível período de indisponibilidade temporário, uma vez que Key Vault podem demorar até 20 minutos a restabelecer a ligação. Para obter mais informações, veja Disponibilidade e redundância do Azure Key Vault.
$export
A tarefa de exportação será recolhida de outra região após 10 minutos sem uma atualização do estado da tarefa. Siga as orientações para o armazenamento do Azure para recuperar a sua conta de armazenamento em caso de indisponibilidade regional. Para obter mais informações, veja Recuperação após desastre e ativação pós-falha da conta de armazenamento.
Confirme que concede 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, veja Como exportar dados FHIR.
Como testar a DR
Embora não seja necessário, pode testar a funcionalidade de DR num ambiente de não produção. Para o teste de DR, apenas os dados serão incluídos e a computação não será incluída.
Considere os seguintes passos para o teste de DR.
Preparar um ambiente de teste com dados de teste. Recomenda-se que utilize uma instância de serviço com pequenas quantidades de dados para reduzir o tempo de replicação dos dados.
Crie um pedido de suporte e forneça a sua subscrição do Azure, a região preferencial do Azure para a ativação pós-falha e o nome do serviço da API do Azure para FHIR para o seu ambiente de teste.
Crie um plano de teste, como faria com qualquer teste de DR.
A equipa de suporte da Microsoft ativa a funcionalidade de DR e confirma que a região de ativação pós-falha preferencial pelo cliente foi adicionada
Realize o teste de DR e registe os resultados dos testes, que devem incluir quaisquer problemas de perda de dados e latência de rede.
Para reativação pós-falha, notifique a equipa de suporte da Microsoft para concluir o passo de reativação pós-falha.
(Opcional) Partilhe comentários com a equipa de suporte da Microsoft.
Nota
O teste de DR duplicará o custo do seu ambiente de teste durante o teste. Não haverá custos adicionais após a conclusão do teste de DR e a funcionalidade de DR ser desativada.
Custo da recuperação após desastre
A funcionalidade de recuperação após desastre implica custos adicionais porque os dados da réplica de computação e de dados em execução no ambiente na região secundária. Para obter mais detalhes sobre preços, veja a página Web de preços da API do Azure para FHIR .
Nota
A oferta de DR está sujeita ao SLA da API do Azure para FHIR, 1.0.
Passos seguintes
Neste artigo, aprendeu como funciona a DR para a API do Azure para FHIR e como a ativar. Para saber mais sobre a API do Azure para outras funcionalidades suportadas do FHIR, veja
FHIR® é uma marca registada do HL7 e é utilizada com a permissão de HL7.