Odnoklassniki é o maior usuário do Apache Cassandra no RuNet e um dos maiores do mundo. Começamos a usar o Cassandra em 2010 para armazenar classificações de fotos e agora o Cassandra gerencia petabytes de dados em milhares de nós. .
No dia 12 de setembro, em nosso escritório em São Petersburgo, realizaremos . O principal orador do evento será o engenheiro-chefe da Odnoklassniki Oleg Anastasyev. Oleg é um especialista na área de sistemas distribuídos e tolerantes a falhas; ele trabalha com Cassandra há mais de 10 anos e repetidamente .
Na véspera do encontro, conversamos com Oleg sobre tolerância a falhas de sistemas distribuídos com Cassandra, perguntamos sobre o que ele falaria no encontro e por que valeria a pena participar deste evento.
Oleg começou sua carreira de programador em 1995. Ele desenvolveu software para bancos, telecomunicações e transportes. Ele trabalha como desenvolvedor líder na Odnoklassniki desde 2007 na equipe da plataforma. Suas responsabilidades incluem o desenvolvimento de arquiteturas e soluções para sistemas de alta carga, grandes data warehouses e a solução de problemas de desempenho e confiabilidade de portais. Ele também treina desenvolvedores dentro da empresa.
- Oleg, olá! Em maio ocorreu , dedicado a Apache Cassandra, os participantes contam que as discussões duraram até tarde da noite, por favor me digam, quais foram suas impressões sobre o primeiro encontro?
Desenvolvedores com experiências diferentes e de empresas diferentes vieram com suas próprias dores, soluções inesperadas para problemas e histórias incríveis. Conseguimos conduzir a maior parte do encontro em formato de discussão, mas foram tantas as discussões que só conseguimos abordar um terço dos temas planejados. Prestamos muita atenção em como e o que monitoramos usando o exemplo de nossos serviços reais de produção.
Fiquei interessado e gostei muito.
- A julgar pelo anúncio, será inteiramente dedicado à tolerância a falhas, por que você escolheu este tópico?
Cassandra é um típico sistema distribuído ocupado com uma enorme quantidade de funcionalidades além de atender diretamente às solicitações do usuário: fofoca, detecção de falhas, propagação de alterações de esquema, expansão/redução de cluster, antientropia, backups e recuperação, etc. Como em qualquer sistema distribuído, à medida que a quantidade de hardware aumenta, a probabilidade de falhas aumenta, por isso a operação dos clusters de produção Cassandra requer um conhecimento profundo de sua estrutura para prever o comportamento em caso de falhas e ações do operador. Depois de usar Cassandra por muitos anos, nós , que estamos prontos para compartilhar, e também queremos discutir como os colegas da oficina resolvem problemas típicos.
— Quando se trata de Cassandra, o que você quer dizer com tolerância a falhas?
Em primeiro lugar, é claro, a capacidade do sistema de sobreviver a falhas típicas de hardware: perda de máquinas, discos ou conectividade de rede com nós/data centers. Mas o tópico em si é muito mais amplo e inclui, em particular, a recuperação de falhas, incluindo falhas para as quais as pessoas raramente estão preparadas, por exemplo, erros do operador.
— Você pode dar um exemplo do maior e mais carregado cluster de dados?
Um dos nossos maiores clusters é o gift cluster: mais de 200 nós e centenas de TB de dados. Mas não é o mais carregado, pois é coberto por um cache distribuído. Nossos clusters mais movimentados lidam com dezenas de milhares de RPS para gravação e milhares de RPS para leitura.
- Uau! Com que frequência algo quebra?
! No total, temos mais de 6 mil servidores, e todas as semanas são substituídos alguns servidores e várias dezenas de discos (sem levar em conta os processos paralelos de atualização e expansão da frota de máquinas). Para cada tipo de falha existem instruções claras sobre o que fazer e em que ordem, tudo é automatizado sempre que possível, por isso as falhas são rotineiras e em 99% dos casos ocorrem despercebidas pelos usuários.
— Como você lida com essas recusas?
Desde o início da operação do Cassandra e dos primeiros incidentes, trabalhamos nos mecanismos de backup e recuperação deles, construímos procedimentos de implantação que levam em consideração o estado dos clusters do Cassandra e, por exemplo, não permitem que os nós sejam reiniciados se a perda de dados for possível. Planejamos falar sobre tudo isso no encontro.
— Como você disse, não existem sistemas absolutamente confiáveis. Para quais tipos de falhas você se prepara e é capaz de sobreviver?
Se falarmos sobre nossas instalações de clusters Cassandra, os usuários não perceberão nada se perdermos várias máquinas em um DC ou um DC inteiro (isso aconteceu). Com o aumento do número de CDs, pensamos em começar a garantir a operacionalidade em caso de falha de dois CDs.
— O que você acha que falta em Cassandra em termos de tolerância a falhas?
Cassandra, como muitos outros armazenamentos NoSQL antigos, requer um conhecimento profundo de sua estrutura interna e dos processos dinâmicos que ocorrem. Eu diria que falta simplicidade, previsibilidade e observabilidade. Mas será interessante ouvir a opinião de outros participantes do encontro!
Oleg, muito obrigado por dedicar seu tempo para responder às perguntas!
Estamos aguardando todos que desejam se comunicar com especialistas na área de operação do Apache Cassandra no encontro do dia 12 de setembro em nosso escritório em São Petersburgo.
Venha, será interessante!
Fonte: habr.com