Sai's questions

Temos um cluster Cassandra em execução no GKE com um pool de nós de 32 CPUs e discos SSD. O tamanho atual do cluster é de quase 1 PB, com cada nó utilizando uma média de 5 TB em discos SSD alocados de 10 TB. O cluster é composto por 200 nós, cada um com discos de 10 TB, totalizando 2 PB de tamanho total alocado.

Dado o tamanho deste cluster, os custos de manutenção são substanciais. Como podemos conseguir uma recuperação de desastres de baixo custo para um cluster tão grande?

Uma opção que estou considerando é criar um novo data center em uma região diferente com fator de replicação 1 (RF1). Embora isso não seja recomendado, reduziria pelo menos o tamanho do cluster por um fator de três.

Qualquer sugestão seria muito apreciada.

Detalhes do ENV:

1. GKE (cluster do Google Kubernetes)
2. Delator da nuvem do Google. https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/architecture/archSnitchGoogle.html
3. 140 nós com 4 RACKs (4 statefulsets em 4 AZs em uma região)
4. Cada tamanho de nó é 5 TB e o tamanho do cluster é 700 TB.

Procedimento seguido para restaurar o banco de dados: restaurei um tamanho de banco de dados de 450 TB no cassandra K8s da origem ao destino usando a atualização do nodetool copiando sstables. Cada nó possui cerca de 5 a 6 TB de dados. A abordagem que tomei:

1. Crie um novo cluster com o mesmo número de nós, como 140 nós de origem.
2. Criou novos discos a partir de instantâneos de disco de origem (nuvem) e anexou esses discos a novos nós.
3. Tabelas de sistema limpas.
4. C* iniciado como um cluster de destino.
5. Tabelas criadas manualmente que correspondem ao cluster de origem
6. Estábulos copiados de tabelas antigas para tabelas recém-criadas (UUID). 7 Executei a atualização do nodetool

Observação: status do Nodetool mostrando o mesmo tamanho da origem para cada nó, cfstats também correspondendo ao tamanho das tabelas no destino e na origem.

Problema pós-migração:

1. Para reduzir o tamanho do cluster, comecei a descomissionar um dos nós e ele foi concluído em 10 minutos. Esperando ver pelo menos 8 horas com base na manutenção anterior do cluster de origem.

2. Como não se esperava que a desativação fosse executada apenas por 10 minutos, tentei adicionar um novo nó ao cluster, que deveria copiar dados de aproximadamente 5 a 6 TB, mas copiou apenas 2 TB.

3. Como outra verificação, tentei "limpeza do Nodetool" em outro nó que faz parte do cluster de destino e reduziu os dados de 6 TB para 2 TB. A mesma limpeza não reduz quaisquer dados no nó de origem.

4. Após a restauração, todo o cluster é reparado no destino usando a ferramenta Reaper e não há problemas com o reparo, mas o problema é a desativação, a limpeza e a inicialização.