Los compañeros de clase son los usuarios más grandes de Apache Cassandra en RuNet y uno de los más grandes del mundo. Comenzamos a usar Cassandra en 2010 para almacenar estimaciones de fotos, y ahora Cassandra administra petabytes de datos en miles de nodos, además, incluso desarrollamos nuestra propia
base de datos transaccional NewSQL .
El 12 de septiembre, en nuestra oficina de San Petersburgo, celebraremos la
segunda reunión dedicada a Apache Cassandra . El orador principal del evento será el ingeniero jefe Odnoklassnikov Oleg Anastasiev. Oleg es un experto en el campo de los sistemas distribuidos y tolerantes a fallas, ha estado trabajando con Cassandra durante más de 10 años y ha
hablado repetidamente
sobre las características de este producto en conferencias .
En la víspera de la reunión, hablamos con Oleg sobre la tolerancia a fallas de los sistemas distribuidos con Cassandra, le preguntamos de qué hablaría en la reunión y por qué valía la pena asistir a este evento.
Oleg comenzó su carrera como programador en 1995. Desarrollo de software en el sector bancario, telecomunicaciones, transporte. Ha trabajado como desarrollador líder en Odnoklassniki desde 2007 como miembro del equipo de la plataforma. Sus responsabilidades incluyen el desarrollo de arquitecturas y soluciones para sistemas de alta carga, grandes almacenes de datos, resolviendo los problemas de productividad y confiabilidad del portal. También se dedica a la formación de desarrolladores dentro de la empresa.
- Oleg, hola! La primera reunión dedicada a Apache Cassandra tuvo lugar en mayo, los participantes dicen que las discusiones continuaron hasta altas horas de la noche, por favor díganme, ¿cuáles son sus impresiones de la primera reunión?Los desarrolladores con diferentes antecedentes de varias compañías llegaron con su dolor, soluciones inesperadas a problemas e historias sorprendentes. Pudimos llevar a cabo la mayor parte de la reunión en el formato de la discusión, pero hubo tantas discusiones que pudimos tocar solo un tercio de los temas que se describieron. Prestamos mucha atención a cómo y qué monitoreamos usando nuestros servicios de producción reales como ejemplo.
Estaba interesado y realmente lo disfruté.
- A juzgar por el anuncio, el segundo mitap estará completamente dedicado a la tolerancia a fallas, ¿por qué elegiste este tema?Cassandra es un sistema distribuido cargado típico con una gran cantidad de funcionalidad además de atender directamente las solicitudes de los usuarios: chismes, detección de fallas, distribución de cambios de esquema, expansión / reducción del clúster, anti-entropía, copias de seguridad y recuperación, etc. Como en cualquier sistema distribuido, con un aumento en la cantidad de hierro, aumenta la probabilidad de fallas, por lo que la operación de producción de los grupos de Cassandra requiere una comprensión profunda de su dispositivo para predecir el comportamiento en caso de fallas y acciones del operador. En el proceso de uso de Cassandra durante muchos años, hemos
acumulado una experiencia significativa , que estamos listos para compartir, y también queremos discutir cómo nuestros colegas resuelven problemas típicos.
- Cuando se trata de Cassandra, ¿qué quieres decir con tolerancia a fallas?En primer lugar, por supuesto, la capacidad del sistema para sobrevivir fallas de hardware típicas: pérdida de máquinas, discos o conectividad de red con nodos / centros de datos. Pero el tema en sí es mucho más amplio y, en particular, incluye la recuperación de fallas, incluidas fallas, para las cuales las personas rara vez están preparadas, por ejemplo, errores del operador.
- ¿Puede dar un ejemplo del clúster de datos más cargado y más grande?Uno de nuestros grupos más grandes es el grupo de regalos: más de 200 nodos y cientos de TB de datos. Pero no es el más cargado, porque está cubierto por un caché distribuido. Nuestros grupos más ocupados tienen decenas de miles de RPS para escribir y miles de RPS para leer.
- Wow! ¿Con qué frecuencia se rompe algo?Si, constantemente ! En total, tenemos más de 6 mil servidores, y cada semana se reemplazan un par de servidores y varias docenas de discos (excluyendo procesos de actualización paralelos y expandiendo la flota). Para cada tipo de falla, se escribe una instrucción clara sobre qué y en qué orden hacer, todo se automatiza si es posible, por lo tanto, las fallas son una rutina y en el 99% de los casos pasan desapercibidas para los usuarios.
- ¿Qué estás luchando con tales fracasos?Desde el comienzo de la operación de Cassandra y los primeros incidentes, desarrollamos mecanismos de respaldo y recuperación a partir de ellos, construimos procedimientos de implementación que tienen en cuenta el estado de los clústeres de Cassandra y, por ejemplo, evitamos que los nodos se reinicien si es posible la pérdida de datos. Planeamos hablar de todo esto en la reunión.
- Como dijiste, no existen sistemas absolutamente confiables. ¿Para qué tipos de fallas te estás preparando y eres capaz de sobrevivir?Si hablamos de nuestras instalaciones de clústeres Cassandra, los usuarios no notarán nada si perdemos varias máquinas en una DC o en una DC completa (esto sucedió). Con el aumento en el número de DC, estamos pensando en comenzar a garantizar la operatividad en caso de falla de dos DC.
- ¿Qué crees que le falta a Cassandra en términos de tolerancia a fallas?Cassandra, como muchos otros repositorios NoSQL tempranos, requiere una comprensión profunda de su estructura interna y los procesos dinámicos en curso. Yo diría que carece de simplicidad, previsibilidad y observabilidad. ¡Pero será interesante escuchar la opinión de otros participantes de la reunión!
Oleg, muchas gracias por tomarte el tiempo de responder las preguntas.
Estamos esperando a todos los que quieran hablar con expertos en el campo de la operación de Apache Cassandra en una reunión el 12 de septiembre en su oficina de San Petersburgo.
Ven, será interesante!
Registrarse para el evento.