Odnoklassniki es el mayor usuario de Apache Cassandra en RuNet y uno de los más grandes del mundo. Comenzamos a usar Cassandra en 2010 para almacenar calificaciones de fotografías y ahora Cassandra administra petabytes de datos en miles de nodos; de hecho, incluso desarrollamos el nuestro propio. .
El 12 de septiembre en nuestra oficina de San Petersburgo celebraremos . El orador principal del evento será el ingeniero jefe de Odnoklassniki Oleg Anastasyev. 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 repetidamente .
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. Desarrolló software en banca, telecomunicaciones y transporte. Desde 2007 trabaja como desarrollador líder en Odnoklassniki en el equipo de la plataforma. Sus responsabilidades incluyen el desarrollo de arquitecturas y soluciones para sistemas de alta carga, grandes almacenes de datos y la resolución de problemas de rendimiento y confiabilidad del portal. También forma a desarrolladores dentro de la empresa.
- ¡Oleg, hola! En mayo tuvo lugar , dedicado a Apache Cassandra, los participantes dicen que las discusiones se prolongaron hasta altas horas de la noche, por favor cuéntame, ¿cuáles son tus impresiones del primer encuentro?
Desarrolladores con diferentes orígenes y diferentes empresas vinieron con sus propios problemas, soluciones inesperadas a problemas e historias sorprendentes. Logramos llevar a cabo la mayor parte de la reunión en formato de discusión, pero hubo tantas discusiones que solo pudimos tocar un tercio de los temas planificados. Hemos prestado mucha atención a cómo y qué monitoreamos utilizando el ejemplo de nuestros servicios de producción reales.
Me interesó y me gustó mucho.
- A juzgar por el anuncio, Estará completamente dedicado a la tolerancia a fallas, ¿por qué elegiste este tema?
Cassandra es un típico sistema distribuido ocupado con una gran cantidad de funcionalidades más allá de atender directamente las solicitudes de los usuarios: chismes, detección de fallas, propagación de cambios de esquema, expansión/reducción de clústeres, antientropía, copias de seguridad y recuperación, etc. Como en cualquier sistema distribuido, a medida que aumenta la cantidad de hardware, aumenta la probabilidad de fallas, por lo que el funcionamiento de los clústeres de producción de Cassandra requiere un conocimiento profundo de su estructura para predecir el comportamiento en caso de fallas y las acciones del operador. Después de usar Cassandra durante muchos años, , que estamos dispuestos a compartir, y también queremos discutir cómo los compañeros del taller resuelven problemas típicos.
— Cuando se trata de Cassandra, ¿a qué te refieres con tolerancia a fallos?
En primer lugar, por supuesto, la capacidad del sistema para sobrevivir a fallos típicos de hardware: 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 darnos un ejemplo del grupo de datos más grande y más cargado?
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, ya que está cubierto por una caché distribuida. Nuestros clústeres más ocupados manejan decenas de miles de RPS para escritura y miles de RPS para lectura.
- ¡Guau! ¿Con qué frecuencia se rompe algo?
! En total contamos con más de 6 mil servidores, y cada semana se reemplazan un par de servidores y varias decenas de discos (sin tener en cuenta los procesos paralelos de actualización y ampliación del parque de máquinas). Para cada tipo de fallo hay instrucciones claras sobre qué hacer y en qué orden, todo está automatizado siempre que es posible, por lo que los fallos son rutinarios y en el 99% de los casos pasan desapercibidos para los usuarios.
— ¿Cómo afronta usted esas negativas?
Desde el comienzo de la operación de Cassandra y los primeros incidentes, trabajamos en los mecanismos para realizar copias de seguridad y recuperación de ellos, creamos procedimientos de implementación que tienen en cuenta el estado de los clústeres de Cassandra y, por ejemplo, no permiten que los nodos se reinicien. si es posible la pérdida de datos. Planeamos hablar de todo esto en la reunión.
— Como usted ha dicho, no existen sistemas absolutamente fiables. ¿Para qué tipos de fracasos se prepara y es capaz de manejar?
Si hablamos de nuestras instalaciones de clusters de Cassandra, los usuarios no notaremos nada si perdemos varias máquinas en un DC o en un DC completo (esto ha sucedido). Con el aumento del número de CD, estamos pensando en comenzar a garantizar la operatividad en caso de falla de dos CD.
— ¿Qué crees que le falta a Cassandra en términos de tolerancia a fallos?
Cassandra, como muchas otras tiendas NoSQL tempranas, requiere una comprensión profunda de su estructura interna y los procesos dinámicos que ocurren. Yo diría que carece de simplicidad, previsibilidad y observabilidad. ¡Pero será interesante escuchar las opiniones 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 comunicarse con expertos en el campo del funcionamiento de Apache Cassandra en la reunión del 12 de septiembre en nuestra oficina de San Petersburgo.
¡Ven, será interesante!
Fuente: habr.com