Odnoklassniki é o maior usuario de Apache Cassandra en RuNet e un dos maiores do mundo. Comezamos a usar Cassandra en 2010 para almacenar clasificacións de fotos, e agora Cassandra xestiona petabytes de datos en miles de nodos, de feito, incluso desenvolvemos o noso propio .
O 12 de setembro celebraremos na nosa oficina de San Petersburgo . O orador principal do evento será o enxeñeiro xefe de Odnoklassniki Oleg Anastasyev. Oleg é un experto no campo dos sistemas distribuídos e tolerantes a fallos; leva máis de 10 anos traballando con Cassandra e repetidamente. .
Na véspera da reunión, falamos con Oleg sobre a tolerancia a fallos dos sistemas distribuídos con Cassandra, preguntámoslle de que falaría na reunión e por que pagaba a pena asistir a este evento.
Oleg comezou a súa carreira de programador en 1995. Desenvolveu software en banca, telecomunicacións e transporte. Leva traballando como desenvolvedor líder en Odnoklassniki desde 2007 no equipo da plataforma. As súas responsabilidades inclúen o desenvolvemento de arquitecturas e solucións para sistemas de alta carga, grandes almacéns de datos e a resolución de problemas de rendemento e fiabilidade do portal. Tamén forma desenvolvedores dentro da empresa.
- Oleg, ola! En maio tivo lugar , dedicado a Apache Cassandra, os participantes din que as discusións se prolongaron ata ben entrada a noite, por favor, dime, cales son as túas impresións da primeira reunión?
Os desenvolvedores con diferentes formacións de diferentes empresas viñeron coa súa propia dor, solucións inesperadas a problemas e historias sorprendentes. Conseguimos levar a cabo a maior parte da reunión nun formato de discusión, pero houbo tantas discusións que só puidemos tocar un terzo dos temas previstos. Fixemos moita atención en como e que monitorizamos usando o exemplo dos nosos servizos de produción reais.
Interesoume e gustoume moito.
- A xulgar polo anuncio, dedicarase enteiramente á tolerancia a fallas, por que escolleches este tema?
Cassandra é un típico sistema distribuído ocupado cunha gran cantidade de funcionalidades máis alá de atender directamente as solicitudes dos usuarios: fofocas, detección de fallos, propagación de cambios de esquema, expansión/redución de clústeres, anti-entropía, copias de seguridade e recuperación, etc. Como en calquera sistema distribuído, a medida que aumenta a cantidade de hardware, aumenta a probabilidade de fallos, polo que o funcionamento dos clústeres de produción de Cassandra require unha profunda comprensión da súa estrutura para predicir o comportamento en caso de fallos e accións do operador. Despois de usar Cassandra durante moitos anos, nós , que estamos dispostos a compartir, e tamén queremos falar de como os compañeiros da tenda resolven problemas típicos.
— Cando se trata de Cassandra, que entendes por tolerancia ás culpas?
En primeiro lugar, por suposto, a capacidade do sistema para sobrevivir a fallos típicos de hardware: perda de máquinas, discos ou conectividade de rede con nodos/centros de datos. Pero o tema en si é moito máis amplo e inclúe en particular a recuperación de fallos, incluíndo fallos para os que a xente raramente está preparada, por exemplo, os erros do operador.
— Podes poñer un exemplo do clúster de datos máis cargado e máis grande?
Un dos nosos clústeres máis grandes é o clúster de agasallos: máis de 200 nodos e centos de TB de datos. Pero non é o máis cargado, xa que está cuberto por unha caché distribuída. Os nosos clústeres máis ocupados manexan decenas de miles de RPS para escribir e miles de RPS para ler.
- Vaia! Cantas veces se rompe algo?
! En total, temos máis de 6 mil servidores, e cada semana substitúense un par de servidores e varias ducias de discos (sen ter en conta os procesos paralelos de actualización e ampliación do parque de máquinas). Para cada tipo de avaría, hai instrucións claras sobre que facer e en que orde, todo está automatizado sempre que sexa posible, polo que os fallos son habituais e no 99% dos casos pasan desapercibidos para os usuarios.
—¿Como afronta este tipo de negativas?
Dende o inicio do funcionamento de Cassandra e das primeiras incidencias, traballamos nos mecanismos de copia de seguridade e recuperación dos mesmos, construímos procedementos de implantación que teñan en conta o estado dos clústeres de Cassandra e, por exemplo, non permitan o reinicio dos nodos. se é posible a perda de datos. Pensamos falar de todo isto na reunión.
— Como dixeches, non hai sistemas absolutamente fiables. Para que tipos de fracasos te preparas e podes sobrevivir?
Se falamos das nosas instalacións de clústeres Cassandra, os usuarios non notarán nada se perdemos varias máquinas nun DC ou nun DC enteiro (isto pasou). Co aumento do número de DC, estamos pensando en comezar a garantir a operatividade en caso de falla de dous DC.
—¿Que cres que lle falta a Cassandra en canto a tolerancia ás culpas?
Cassandra, como moitas outras primeiras tendas NoSQL, require unha comprensión profunda da súa estrutura interna e dos procesos dinámicos que se producen. Eu diría que carece de sinxeleza, previsibilidade e observabilidade. Pero será interesante escoitar as opinións doutros participantes da reunión!
Oleg, moitas grazas por dedicar o tempo a responder as preguntas!
Agardamos a todos os que queiran comunicarse con expertos no campo da operación de Apache Cassandra na reunión do 12 de setembro na nosa oficina de San Petersburgo.
Veña, vai ser interesante!
Fonte: www.habr.com