Estudo de caso da arquitetura de solução altamente disponível do Azure HDInsight
Os mecanismos de replicação do Azure HDInsight podem ser integrados em uma arquitetura de solução altamente disponível. Neste artigo, um estudo de caso fictício para a Contoso Retail é usado para explicar possíveis abordagens de recuperação de desastres de alta disponibilidade, considerações de custo e seus designs correspondentes.
As recomendações de recuperação de desastres de alta disponibilidade podem ter muitas permutações e combinações. Estas soluções devem ser alcançadas depois de deliberados os prós e os contras de cada opção. Este artigo discute apenas uma solução possível.
Arquitetura do cliente
A imagem a seguir mostra a arquitetura principal da Contoso Retail. A arquitetura consiste em uma carga de trabalho de streaming, carga de trabalho em lote, camada de serviço, camada de consumo, camada de armazenamento e controle de versão.
Carga de trabalho de streaming
Dispositivos e sensores produzem dados para o HDInsight Kafka, que constitui a estrutura de mensagens. Um consumidor do HDInsight Spark lê os Tópicos de Kafka. O Spark transforma as mensagens de entrada e as grava em um cluster HBase HDInsight na camada de serviço.
Carga de trabalho em lote
Um cluster Hadoop HDInsight executando o Hive e o MapReduce ingere dados de sistemas transacionais locais. Os dados brutos transformados pelo Hive e pelo MapReduce são armazenados em tabelas do Hive em uma partição lógica do data lake com suporte do Azure Data Lake Storage Gen2. Os dados armazenados em tabelas do Hive também são disponibilizados para o Spark SQL, que faz transformações em lote antes de armazenar os dados selecionados no HBase para servir.
Camada de fornecimento
Um cluster HBase HDInsight com Apache Phoenix é usado para fornecer dados para aplicativos Web e painéis de visualização. Um cluster LLAP do HDInsight é usado para atender aos requisitos internos de relatórios.
Camada de consumo
Uma camada de Gerenciamento de API e Aplicativos de API do Azure reverte uma página da Web voltada para o público. Os requisitos de relatórios internos são cumpridos pelo Power BI.
Camada de armazenamento
O Azure Data Lake Storage Gen2 logicamente particionado é usado como um data lake corporativo. Os metastores do HDInsight são apoiados pelo Banco de Dados SQL do Azure.
Sistema de controlo de versão
Um sistema de controle de versão integrado a um Azure Pipelines e hospedado fora do Azure.
Requisitos de continuidade de negócios do cliente
É importante determinar a funcionalidade mínima de negócios de que você precisará se houver um desastre.
Requisitos de continuidade de negócios da Contoso Retail
- Temos de ser protegidos contra uma falha regional ou um problema de saúde dos serviços regionais.
- Meus clientes nunca devem ver um erro 404. O conteúdo público deve ser sempre veiculado. (RTO = 0)
- Durante a maior parte do ano, podemos mostrar conteúdo público que está obsoleto em 5 horas. (RPO = 5 horas)
- Durante a temporada de férias, nosso conteúdo voltado para o público deve estar sempre atualizado. (RPO = 0)
- Meus requisitos internos de relatórios não são considerados críticos para a continuidade dos negócios.
- Otimize os custos de continuidade de negócios.
Solução proposta
A imagem a seguir mostra a arquitetura de recuperação de desastres de alta disponibilidade da Contoso Retail.
Kafka usa replicação ativa – passiva para espelhar tópicos de Kafka da região primária para a região secundária. Uma alternativa à replicação de Kafka poderia ser produzir para Kafka em ambas as regiões.
O Hive e o Spark usam modelos de replicação Ative Primary – On-Demand Secondary em tempos normais. O processo de replicação do Hive é executado periodicamente e acompanha o metastore SQL do Hive Azure e a replicação da conta de armazenamento do Hive. A conta de armazenamento do Spark é replicada periodicamente usando o ADF DistCP. A natureza transitória desses clusters ajuda a otimizar custos. As replicações são agendadas a cada 4 horas para chegar a um RPO que esteja dentro do requisito de cinco horas.
A replicação do HBase usa o modelo Leader – Follower em tempos normais para garantir que os dados sejam sempre servidos, independentemente da região, e que o RPO seja muito baixo.
Se houver uma falha regional na região primária, a página da Web e o conteúdo de back-end são servidos da região secundária por 5 horas com algum grau de obsoleto. Se o painel de integridade do serviço do Azure não indicar um ETA de recuperação na janela de cinco horas, o Contoso Retail criará a camada de transformação Hive e Spark na região secundária e apontará todas as fontes de dados upstream para a região secundária. Tornar a região secundária gravável causaria um processo de failback que envolve a replicação de volta para a principal.
Durante uma alta temporada de compras, todo o pipeline secundário está sempre ativo e funcionando. Os produtores de Kafka produzem para ambas as regiões e a replicação do HBase seria alterada de Líder-Seguidor para Líder-Líder para garantir que o conteúdo voltado para o público esteja sempre atualizado.
Nenhuma solução de failover precisa ser projetada para relatórios internos, pois não é crítica para a continuidade dos negócios.
Próximos passos
Para saber mais sobre os itens discutidos neste artigo, consulte: