Arquiteturas de continuidade de negócios do Azure HDInsight
Este artigo fornece alguns exemplos de arquiteturas de continuidade de negócios que você pode considerar para o Azure HDInsight. A tolerância para funcionalidade reduzida durante um desastre é uma decisão de negócios que varia de um aplicativo para outro. Pode ser aceitável que algumas aplicações não estejam disponíveis ou estejam parcialmente disponíveis com funcionalidade reduzida ou processamento atrasado por um período. Para outras aplicações, qualquer funcionalidade reduzida pode ser inaceitável.
Nota
As arquiteturas apresentadas neste artigo não são de forma alguma exaustivas. Você deve projetar suas próprias arquiteturas exclusivas depois de ter feito determinações objetivas em torno da continuidade de negócios esperada, complexidade operacional e custo de propriedade.
Apache Hive e consulta interativa
A Replicação do Hive V2 é recomendada para continuidade de negócios em clusters de consulta HDInsight Hive e Interactive. As seções persistentes de um cluster Hive autônomo que precisam ser replicadas são a camada de armazenamento e o metaarmazenamento do Hive. Os clusters Hive em um cenário multiusuário com o Enterprise Security Package precisam dos Serviços de Domínio Microsoft Entra e do Ranger Metastore.
A replicação baseada em eventos do Hive é configurada entre os clusters primário e secundário. Isso consiste em duas fases distintas, bootstrapping e execuções incrementais:
O bootstrapping replica todo o armazém do Hive, incluindo as informações do metastore do Hive do primário ao secundário.
As execuções incrementais são automatizadas no cluster primário e os eventos gerados durante as execuções incrementais são reproduzidos no cluster secundário. O cluster secundário alcança os eventos gerados a partir do cluster primário, garantindo que o cluster secundário seja consistente com os eventos do cluster primário após a execução da replicação.
O cluster secundário é necessário apenas no momento da replicação para executar a cópia distribuída, DistCpmas o armazenamento e os metastores precisam ser persistentes. Você pode optar por girar um cluster secundário com script sob demanda antes da replicação, executar o script de replicação nele e desmontá-lo após a replicação bem-sucedida.
O cluster secundário é geralmente somente leitura. Você pode fazer o cluster secundário ler-gravar, mas isso adiciona complexidade adicional que envolve a replicação das alterações do cluster secundário para o cluster primário.
RPO de replicação baseada em eventos do Hive & RTO
RPO: A perda de dados é limitada ao último evento de replicação incremental bem-sucedido do primário para o secundário.
RTO: O tempo entre a falha e a retomada das transações a montante e a jusante com o secundário.
Arquiteturas Apache Hive e Interactive Query
Hive ativo primário com secundário sob demanda
Em um primário ativo com arquitetura secundária sob demanda, os aplicativos gravam na região primária ativa enquanto nenhum cluster é provisionado na região secundária durante operações normais. O SQL Metastore e o Armazenamento na região secundária são persistentes, enquanto o cluster HDInsight é roteirizado e implantado sob demanda somente antes da execução da replicação agendada do Hive.
Colmeia primária ativa com secundária em espera
Em um primário ativo com secundário em espera, os aplicativos gravam na região primária ativa, enquanto um cluster secundário em espera reduzido no modo somente leitura é executado durante operações normais. Durante operações normais, você pode optar por descarregar operações de leitura específicas da região para secundárias.
Para obter mais informações sobre a replicação do Hive e exemplos de código, consulte Replicação do Apache Hive em clusters do Azure HDInsight
Apache Spark
As cargas de trabalho do Spark podem ou não envolver um componente do Hive. Para permitir que as cargas de trabalho do Spark SQL leiam e gravem dados do Hive, os clusters do HDInsight Spark compartilham metastores personalizados do Hive de clusters de consulta do Hive/Interactive na mesma região. Nesses cenários, a replicação entre regiões de cargas de trabalho do Spark também deve acompanhar a replicação de metastores e armazenamento do Hive. Os cenários de failover nesta seção se aplicam a ambos:
- Spark SQL em tabelas ACID usando a Instalação do Hive Warehouse Connector (HWC) usando um cluster de Consulta Interativa do HDInsight.
- Estimule a carga de trabalho SQL em tabelas não ACID usando um cluster Hadoop do HDInsight.
Para cenários em que o Spark funciona no modo autônomo, os dados selecionados e os Spark Jars armazenados (para trabalhos do Livy) precisam ser replicados da região primária para a região secundária regularmente usando o .DistCP
Recomendamos que você use sistemas de controle de versão para armazenar blocos de anotações e bibliotecas do Spark onde eles possam ser facilmente implantados em clusters primários ou secundários. Certifique-se de que as soluções baseadas e não baseadas em notebook estejam preparadas para carregar as montagens de dados corretas no espaço de trabalho primário ou secundário.
Se houver bibliotecas específicas do cliente que estejam além do que o HDInsight fornece nativamente, elas deverão ser rastreadas e carregadas periodicamente no cluster secundário em espera.
RPO de replicação do Apache Spark & RTO
RPO: A perda de dados é limitada à última replicação incremental bem-sucedida (Spark e Hive) do primário para o secundário.
RTO: O tempo entre a falha e a retomada das transações a montante e a jusante com o secundário.
Arquiteturas do Apache Spark
Faísca primária ativa com secundária sob demanda
Os aplicativos leem e gravam em clusters Spark e Hive na região primária, enquanto nenhum cluster é provisionado na região secundária durante operações normais. SQL Metastore, Hive Storage e Spark Storage são persistentes na região secundária. Os clusters Spark e Hive são roteirizados e implantados sob demanda. A replicação do Hive é usada para replicar o Armazenamento do Hive e os metastores do Hive, enquanto o Azure Data Factory pode ser usado para copiar o armazenamento autônomo do DistCP Spark. Os clusters do Hive precisam ser implantados antes de cada replicação do Hive ser executada devido à computação de dependência DistCp .
Faísca primária ativa com secundária em espera
Os aplicativos leem e gravam em clusters Spark e Hive na região primária, enquanto clusters Hive e Spark em modo somente leitura em espera são executados na região secundária durante operações normais. Durante operações normais, você pode optar por descarregar operações de leitura Hive e Spark específicas da região para secundárias.
Apache HBase
A Exportação do HBase e a Replicação do HBase são formas comuns de habilitar a continuidade de negócios entre clusters HBase do HDInsight.
O HBase Export é um processo de replicação em lote que usa o HBase Export Utility para exportar tabelas do cluster HBase primário para seu armazenamento subjacente do Azure Data Lake Storage Gen 2. Os dados exportados podem então ser acessados a partir do cluster HBase secundário e importados para tabelas que devem preexistir no secundário. Embora o HBase Export ofereça granularidade no nível da tabela, em situações de atualização incremental, o mecanismo de automação de exportação controla o intervalo de linhas incrementais a serem incluídas em cada execução. Para obter mais informações, consulte Backup e replicação do HBase do HDInsight.
A replicação do HBase usa replicação quase em tempo real entre clusters do HBase de forma totalmente automatizada. A replicação é feita no nível da tabela. Todas as tabelas ou tabelas específicas podem ser direcionadas para replicação. A replicação do HBase é eventualmente consistente, o que significa que as edições recentes em uma tabela na região primária podem não estar disponíveis para todos os secundários imediatamente. É garantido que os secundários acabarão por se tornar consistentes com o primário. A replicação do HBase pode ser configurada entre dois ou mais clusters HBase HDInsight se:
- O primário e o secundário estão na mesma rede virtual.
- O primário e o secundário estão em diferentes redes virtuais emparelhadas na mesma região.
- O primário e o secundário estão em diferentes redes virtuais emparelhadas em diferentes regiões.
Para obter mais informações, consulte Configurar a replicação de cluster do Apache HBase em redes virtuais do Azure.
Existem algumas outras maneiras de executar backups de clusters do HBase, como copiar a pasta hbase, copiar tabelas e instantâneos.
HBase RPO & RTO
Exportação de HBase
- RPO: A perda de dados é limitada à última importação incremental de lote bem-sucedida pelo secundário do primário.
- RTO: O tempo entre a falha do primário e a retomada das operações de E/S no secundário.
Replicação do HBase
- RPO: A perda de dados é limitada à última remessa WalEdit recebida no secundário.
- RTO: O tempo entre a falha do primário e a retomada das operações de E/S no secundário.
Arquiteturas HBase
A replicação do HBase pode ser configurada em três modos: Líder-Seguidor, Líder-Líder e Cíclico.
HBase Replication: Líder – Modelo de seguidor
Nessa configuração entre regiões, a replicação é unidirecional da região primária para a secundária. Todas as tabelas ou tabelas específicas no primário podem ser identificadas para replicação unidirecional. Durante as operações normais, o cluster secundário pode ser usado para atender solicitações de leitura em sua própria região.
O cluster secundário opera como um cluster HBase normal que pode hospedar suas próprias tabelas e pode servir leituras e gravações de aplicativos regionais. No entanto, as tabelas replicadas ou as tabelas nativas do secundário não são replicadas de volta para o primário.
Replicação do HBase: modelo líder
Essa configuração entre regiões é muito semelhante à configuração unidirecional, exceto que a replicação acontece bidirecionalmente entre a região primária e a região secundária. Os aplicativos podem usar ambos os clusters em modos de leitura-gravação e as atualizações são trocas assíncronas entre eles.
Replicação do HBase: Multi-Região ou Cíclica
O modelo de replicação cíclica/multirregional é uma extensão da replicação do HBase e pode ser usado para criar uma arquitetura HBase globalmente redundante com vários aplicativos que leem e gravam em clusters HBase específicos da região. Os clusters podem ser configurados em várias combinações de Líder/Líder ou Líder/Seguidor, dependendo dos requisitos do negócio.
Apache Kafka
Para habilitar a disponibilidade entre regiões, o HDInsight 4.0 oferece suporte ao Kafka MirrorMaker, que pode ser usado para manter uma réplica secundária do cluster Kafka primário em uma região diferente. O MirrorMaker atua como um par consumidor-produtor de alto nível, consome de um tópico específico no cluster primário e produz para um tópico com o mesmo nome no secundário. A replicação entre clusters para recuperação de desastres de alta disponibilidade usando o MirrorMaker vem com a suposição de que produtores e consumidores precisam fazer failover para o cluster de réplica. Para obter mais informações, consulte Usar o MirrorMaker para replicar tópicos do Apache Kafka com o Kafka no HDInsight
Dependendo do tempo de vida do tópico quando a replicação foi iniciada, a replicação de tópicos do MirrorMaker pode levar a diferentes deslocamentos entre os tópicos de origem e de réplica. Os clusters Kafka do HDInsight também oferecem suporte à replicação de partições tópicas, que é um recurso de alta disponibilidade no nível de cluster individual.
Arquiteturas Apache Kafka
Replicação Kafka: Ativo – Passivo
A configuração Ativo-Passivo permite o espelhamento unidirecional assíncrono de Ativo para Passivo. Produtores e Consumidores precisam estar cientes da existência de um cluster Ativo e Passivo e devem estar prontos para fazer failover para o Passivo caso o Ativo falhe. Abaixo estão algumas vantagens e desvantagens da configuração Ativo-Passivo.
Vantagens:
- A latência da rede entre clusters não afeta o desempenho do cluster Ativo.
- Simplicidade da replicação unidirecional.
Desvantagens:
- O cluster passivo pode permanecer subutilizado.
- Complexidade de projeto na incorporação de reconhecimento de failover em produtores e consumidores de aplicativos.
- Possível perda de dados durante a falha do cluster ativo.
- Eventual consistência entre tópicos entre clusters Ativo e Passivo.
- Failbacks para Primary podem levar à inconsistência de mensagens nos tópicos.
Replicação Kafka: Ativo – Ativo
A configuração Active-Active envolve dois clusters HDInsight Kafka emparelhados regionalmente separados com replicação assíncrona bidirecional com o MirrorMaker. Neste desenho, as mensagens consumidas pelos consumidores no primário também são disponibilizadas aos consumidores no secundário e vice-versa. Abaixo estão algumas vantagens e desvantagens da configuração Active-Active.
Vantagens:
- Devido ao seu estado duplicado, failovers e failbacks são mais fáceis de executar.
Desvantagens:
- A configuração, o gerenciamento e o monitoramento são mais complexos do que o Ativo-Passivo.
- O problema da replicação circular tem de ser resolvido.
- A replicação bidirecional leva a maiores custos regionais de saída de dados.
Pacote de Segurança Empresarial do HDInsight
Essa configuração é usada para habilitar a funcionalidade multiusuário no primário e secundário, bem como conjuntos de réplicas dos Serviços de Domínio Microsoft Entra para garantir que os usuários possam se autenticar em ambos os clusters. Durante as operações normais, as políticas da Ranger precisam ser configuradas no secundário para garantir que os usuários estejam restritos às operações de leitura. A arquitetura abaixo explica como uma configuração do Hive Ative Primary – Standby Secondary habilitada para ESP pode parecer.
Replicação Ranger Metastore:
O Ranger Metastore é usado para armazenar e servir persistentemente as políticas da Ranger para controlar a autorização de dados. Recomendamos que você mantenha políticas Ranger independentes no primário e secundário e mantenha o secundário como uma réplica de leitura.
Se o requisito for manter as políticas da Ranger sincronizadas entre o primário e o secundário, use o Ranger Import/Export para fazer backup e importar periodicamente as políticas do Ranger do primário para o secundário.
A replicação de políticas Ranger entre o primário e o secundário pode fazer com que o secundário se torne habilitado para gravação, o que pode levar a gravações inadvertidas no secundário, levando a inconsistências de dados.
Próximos passos
Para saber mais sobre os itens discutidos neste artigo, consulte: