Usando Espelhamento em um Cenário de Exemplo de Recuperação de Desastre
Esse cenário de recuperação de desastre de ponta a ponta demonstra como usar o espelhamento para fornecer maior disponibilidade e manter os aplicativos funcionando caso um incidente grave afete uma região completa do IBM Cloud...
Dois clusters foram provisionados em regiões diferentes e configurados para espelhamento (seguindo as informações em Como ativar o espelhamento) usando A e B como aliases de cluster.Um
produtor publica registros em um tópico chamado accounting.invoices e um consumidor lê as mensagens desse tópico no cluster A.
O cluster de origem fica indisponível
Vamos considerar o que acontece se ocorrer um desastre na região do cluster de origem.
É responsabilidade do proprietário da instância Event Streams determinar se o impacto do evento é suficiente para declarar um desastre. O proprietário da instância de serviço deve coordenar o failover de aplicativos, incluindo a sua reconfiguração, reimplementação e reinicialização, quando necessário.
Efetuando failover de produtores
Execute os seguintes passos para falhar sobre:
- Pare os produtores que estavam apontando para o cluster A.
- Se o cluster A e o link de A para o cluster B ainda estiverem operacionais, certifique-se de que o máximo possível de dados seja espelhado, verificando se o atraso desses tópicos no cluster B é zero.
- Reinicie os produtores para apontar para os pontos de extremidade do cluster B.
- Desative qualquer espelhamento que ainda esteja ativado nos tópicos do cluster A para o cluster B. Isso pode ser feito usando os Controles do usuário.
O produtor agora é alternado para o cluster B e envia mensagens para um novo tópico local com o mesmo nome do original.
Efetuando failover de consumidores
Execute os seguintes passos para falhar sobre:
- Se o cluster A e o link de A para o cluster B ainda estiverem operacionais, permita que os consumidores leiam todos os dados da mensagem nos tópicos no cluster A e confirmem seus deslocamentos no final do tópico
- Pare os consumidores que estavam apontando para o cluster A.
- Reinicie os consumidores para que apontem para os pontos de extremidade do cluster B.
O consumidor agora pode continuar a consumir as mensagens existentes do tópico accounting.invoices.A do cluster B enquanto novas mensagens vêm de accounting.invoices.
Se o aplicativo exigir uma ordem rigorosa, os tópicos remotos deverão ser totalmente consumidos primeiro, antes de iniciar o consumo dos tópicos locais. Dessa forma, as mensagens são processadas na ordem em que foram produzidas.
Reconfigurando um ambiente de espelhamento
O proprietário da instância de serviço Event Streams é responsável por decidir o que acontece quando o cluster A é recuperado.
No caso de o cluster A não ser recuperável, o proprietário da instância de serviço do Event Streams será responsável por ativar o espelhamento entre o cluster B e uma instância recém-provisionada. Para ativar o espelhamento para uma nova ocorrência, conclua as seguintes etapas:
- Falha sobre os produtores e consumidores de A a B conforme descrito anteriormente.
- Desativar o espelhamento atual do cluster A para o cluster B. Para obter mais informações, consulte Desativando espelhamento.
- Após o espelhamento ser desativado, ative o espelhamento entre o cluster B (agora a origem) para o cluster recém-provisionado (o destino). Para obter mais informações, consulte Ativando o espelhamento.
Como alternativa, se o cluster A tiver se recuperado, normalmente um usuário retorna as operações para o cluster A. Conclua as etapas a seguir para retornar operações primárias para o cluster A.
Antes de fazer a reversão, o espelhamento deve ser ativado na direção oposta:
- Assegure-se de que o cluster A esteja totalmente operacional.
- Desativar o espelhamento atual do cluster A para o cluster B. Para obter mais informações, consulte Desativando espelhamento.
- Após o espelhamento ter sido desativado, ative o espelhamento entre o cluster B (agora a origem) e o cluster A (agora o destino). Para obter mais informações, consulte Ativando o espelhamento.
- O cluster de origem A agora torna-se o cluster de destino.
- O cluster de destino B torna-se o novo cluster de origem.
- Ative quaisquer tópicos a serem espelhados do cluster B para o cluster A. É possível fazer isso usando os Controles do usuário
Em seguida, assegure-se de que os dados estão sendo replicados para o cluster A, verificando se os tópicos do cluster B estão aparecendo no cluster A. Esses tópicos têm o sufixo do novo cluster de origem, B.
Não espelhe novamente o tópico de destino original no cluster B, pois isso causaria um efeito cíclico indesejável. Conforme mostrado no diagrama, espelhamos accounting.invoices do cluster B para o cluster A, não accounting.invoices.A.
Failback
A decisão de efetuar failback é novamente pertencente ao proprietário da instância do Event Streams. O proprietário da instância de serviço deve coordenar o failback de aplicativos, incluindo a sua reconfiguração, reimplementação e reinicialização, quando necessário.
Diferentemente do caso de failover, nesse caso não houve desastre no cluster B. Portanto, o failback é uma operação controlada e pode ser alcançado com perda mínima de dados ou reprocessamento de dados.
Por fim, mude o espelhamento de volta para a configuração original, o que significa que o cluster A é novamente a origem e o cluster B volta a ser o destino.
- Assegure que o cluster A e o cluster B estejam totalmente operacionais.
- Desativar o espelhamento atual do cluster B para o cluster A. Para obter mais informações, consulte Desativando espelhamento.
- Após o espelhamento ter sido desativado, ative o espelhamento entre o cluster A (agora a origem) e o cluster B (agora o destino). Para obter mais informações, consulte Ativando o espelhamento.