Múltiples bastidores son geniales, pero no son suficientes.
No es una suposición ficticia asumir que todo un centro de datos podría quedar fuera de línea. Ocurrió en el pasado para las empresas más grandes y los proveedores de nubes. Es cuestión de tiempo antes de que suceda de nuevo. Si le preocupan sus datos y que sus usuarios permanezcan en línea en tales circunstancias, sea responsable y asegúrese de que su clúster se despliegue (adecuadamente) en varios centros de datos.
Hacerlo con Cassandra no sólo es posible, sino que es bastante sencillo de configurar.
Lo que ha aprendido hasta ahora le servirá bien. Ya sabes que tienes que distribuir tus datos de manera uniforme en todo tu grupo. Y entiendes que esto se hará mayormente eligiendo un divisor adecuado. He recomendado el particionador Murmur3.
También comprendió que es importante que su grupo conozca la topología de la red en la que reside, utilizando el soplón NetworkTopologyStrategy.
En Cassandra, el factor de replicación se define por espacio clave y centro de datos .
Eso significa que podemos (y normalmente lo haremos) definir un factor de replicación diferente para cada centro de datos.
A efectos de la recuperación de desastres, es muy común tener un centro de datos dedicado con el propósito de replicar datos «en línea» y «esperando» a que ocurra una catástrofe.
En tal caso, este centro de datos «asumirá» y servirá a los usuarios existentes.
Hay varias prácticas cuando se trata de múltiples centros de datos.
Algunos prefieren ubicar diferentes centros de datos en diferentes zonas geográficas, haciendo que cada nodo del centro de datos sirva a los usuarios «locales» mientras replican sus datos a los nodos remotos.
Otros, prefieren que todos los nodos sirvan a todos los usuarios, dejando que Cassandra decida qué nodo sirve a qué usuario.
Estas prácticas están relacionadas en su mayoría con asuntos de rendimiento y podría tocarlas en un futuro artículo, según su solicitud.
Mi recomendación personal, y algunas personas tienen una opinión diferente, es no tratar un centro de datos como un centro de datos «principal» y el otro como un centro de datos de «recuperación de desastres», y asignar a cada uno diferentes recursos. Intente escalarlos de forma similar y replique sus datos con el mismo factor de replicación en cada uno.
Esto tendrá una mayor sobrecarga de nodos y almacenamiento – y es su decisión cómo equilibrar el costo de la sobrecarga con el posible costo de la pérdida de datos.