Os colegas de classe são 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 estimativas de fotos e agora o Cassandra gerencia petabytes de dados em milhares de nós; além disso, desenvolvemos nosso próprio
banco de dados transacional NewSQL .
No dia 12 de setembro, em nosso escritório em São Petersburgo, realizaremos a
segunda reunião dedicada a Apache Cassandra . O principal orador do evento será o engenheiro-chefe Odnoklassnikov Oleg Anastasiev. Oleg é um especialista na área de sistemas distribuídos e tolerantes a falhas, trabalha com Cassandra há mais de 10 anos e tem
falado repetidamente
sobre os recursos deste produto em conferências .
Na véspera da reunião, conversamos com Oleg sobre a tolerância a falhas de sistemas distribuídos com Cassandra, perguntamos sobre o que ele falaria na reunião e por que valia a pena participar desse evento.
Oleg começou sua carreira como programador em 1995. Desenvolvimento de software no setor bancário, telecomunicações, transporte. Ele trabalha como desenvolvedor líder em Odnoklassniki desde 2007 como membro da equipe da plataforma. Suas responsabilidades incluem o desenvolvimento de arquiteturas e soluções para sistemas de alta carga, grandes data warehouses, resolvendo os problemas de produtividade e confiabilidade do portal. Ele também está envolvido no treinamento de desenvolvedores dentro da empresa.
- Oleg, olá! Em maio, ocorreu o primeiro encontro dedicado ao Apache Cassandra, os participantes dizem que as discussões foram até tarde da noite, por favor, diga-me, quais são suas impressões sobre o primeiro encontro?Desenvolvedores com diferentes origens de várias empresas vieram com sua dor, soluções inesperadas para problemas e histórias surpreendentes. Conseguimos conduzir a maior parte da reunião no formato da discussão, mas houve tantas discussões que pudemos abordar apenas um terço dos tópicos descritos. Prestamos muita atenção em como e o que monitoramos usando nossos serviços de produção reais como exemplo.
Eu estava interessado e realmente gostei.
- A julgar pelo anúncio, o segundo mitap será inteiramente dedicado à tolerância a falhas. Por que você escolheu este tópico?O Cassandra é um sistema distribuído carregado típico com uma enorme quantidade de funcionalidade, além de atender diretamente às solicitações do usuário: fofocas, detecção de falhas, distribuição de alterações de esquema, expansão / redução do cluster, anti-entropia, backups e recuperação, etc. Como em qualquer sistema distribuído, com um aumento na quantidade de ferro, a probabilidade de falhas aumenta; portanto, a operação dos clusters de produção Cassandra requer um entendimento profundo de seu dispositivo para prever o comportamento em caso de falhas e ações do operador. No processo de uso do Cassandra por muitos anos,
acumulamos uma experiência significativa , que estamos prontos para compartilhar, e também queremos discutir como nossos colegas resolvem problemas típicos.
- Quando se trata de Cassandra, o que você quer dizer com tolerância a falhas?Antes de tudo, é 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, em particular, inclui recuperação de falhas, incluindo falhas, para as quais as pessoas raramente são preparadas, por exemplo, erros do operador.
- Você pode dar um exemplo do cluster de dados mais carregado e maior?Um de nossos maiores clusters é o cluster de presentes: mais de 200 nós e centenas de TB de dados. Mas não é o mais carregado, porque é coberto por um cache distribuído. Nossos clusters mais ocupados possuem dezenas de milhares de RPS para gravação e milhares de RPS para leitura.
Uau! Quantas vezes algo quebra?Sim constantemente ! No total, temos mais de 6 mil servidores, e toda semana são substituídos alguns servidores e várias dezenas de discos (sem levar em conta os processos de atualização paralela e a expansão da frota de veículos). Para cada tipo de falha, uma instrução clara é escrita sobre o que e em que ordem fazer, tudo é automatizado na medida do possível; portanto, as falhas são rotineiras e, em 99% dos casos, passam despercebidas pelos usuários.
- O que você está lutando com essas falhas?Desde o início da operação do Cassandra e os primeiros incidentes, desenvolvemos mecanismos de backup e recuperação a partir deles, criamos procedimentos de implantação que levam em consideração o estado dos clusters do Cassandra e, por exemplo, impedem que os nós sejam reiniciados se a perda de dados for possível. Planejamos conversar sobre tudo isso na reunião.
- Como você disse, sistemas absolutamente confiáveis não existem. Que tipos de falhas você está preparando e capaz de sobreviver?Se falarmos sobre nossas instalações de clusters Cassandra, os usuários não notarão nada se perdermos várias máquinas em um CD ou em um CD inteiro (isso aconteceu). Com o aumento do número de CDs, estamos pensando em começar a garantir a operacionalidade no caso de uma falha de dois CDs.
- O que você acha que Cassandra não tem em termos de tolerância a falhas?Cassandra, como muitos outros repositórios NoSQL, requer um entendimento profundo de sua estrutura interna e dos processos dinâmicos em andamento. Eu diria que ela carece de simplicidade, previsibilidade e observabilidade. Mas será interessante ouvir a opinião de outros participantes da reunião!
Oleg, muito obrigado por reservar um tempo para responder às perguntas!
Aguardamos todos que quiserem conversar com especialistas na área de operação do Apache Cassandra em uma reunião realizada em 12 de setembro no escritório de São Petersburgo.
Venha, vai ser interessante!
Inscreva-se no evento.