Odnoklassniki è il più grande utente di Apache Cassandra su RuNet e uno dei più grandi al mondo. Abbiamo iniziato a utilizzare Cassandra nel 2010 per archiviare le valutazioni delle foto e ora Cassandra gestisce petabyte di dati su migliaia di nodi, infatti abbiamo persino sviluppato il nostro .
Il 12 settembre si terrà nel nostro ufficio di San Pietroburgo . Il relatore principale dell'evento sarà l'ingegnere capo della Odnoklassniki Oleg Anastasyev. Oleg è un esperto nel campo dei sistemi distribuiti e tolleranti ai guasti; collabora con Cassandra da più di 10 anni e più volte .
Alla vigilia dell'incontro, abbiamo parlato con Oleg della tolleranza agli errori dei sistemi distribuiti con Cassandra, gli abbiamo chiesto di cosa avrebbe parlato all'incontro e perché valeva la pena partecipare a questo evento.
Oleg ha iniziato la sua carriera di programmatore nel 1995. Ha sviluppato software nel settore bancario, delle telecomunicazioni e dei trasporti. Dal 2007 lavora come sviluppatore leader presso Odnoklassniki nel team della piattaforma. Le sue responsabilità includono lo sviluppo di architetture e soluzioni per sistemi ad alto carico, grandi data warehouse e la risoluzione di problemi di prestazioni e affidabilità del portale. Inoltre forma gli sviluppatori all'interno dell'azienda.
- Oleg, ciao! A maggio ha avuto luogo , dedicato ad Apache Cassandra, i partecipanti raccontano che le discussioni sono andate avanti fino a tarda notte, ditemi, quali sono le vostre impressioni sul primo incontro?
Sviluppatori con background diversi e provenienti da aziende diverse sono arrivati con il proprio dolore, soluzioni inaspettate ai problemi e storie straordinarie. Siamo riusciti a condurre la maggior parte dell'incontro in formato discussione, ma ci sono state così tante discussioni che siamo riusciti a toccare solo un terzo degli argomenti pianificati. Abbiamo prestato molta attenzione a come e cosa monitoriamo utilizzando l'esempio dei nostri servizi di produzione reali.
Mi ha interessato e mi è piaciuto molto.
- A giudicare dall'annuncio, sarà interamente dedicato alla tolleranza agli errori, perché hai scelto questo argomento?
Cassandra è un tipico sistema distribuito occupato con un'enorme quantità di funzionalità oltre al servizio diretto delle richieste degli utenti: gossip, rilevamento di errori, propagazione di modifiche allo schema, espansione/riduzione del cluster, anti-entropia, backup e ripristino, ecc. Come in ogni sistema distribuito, all'aumentare della quantità di hardware, aumenta la probabilità di guasti, quindi il funzionamento dei cluster di produzione Cassandra richiede una profonda comprensione della sua struttura per prevedere il comportamento in caso di guasti e le azioni dell'operatore. Dopo aver utilizzato Cassandra per molti anni, noi , che siamo pronti a condividere, e vogliamo anche discutere su come i colleghi in negozio risolvono i problemi tipici.
— Quando si parla di Cassandra, cosa intendi per tolleranza agli errori?
Prima di tutto, ovviamente, la capacità del sistema di sopravvivere ai tipici guasti hardware: perdita di macchine, dischi o connettività di rete con nodi/data center. Ma l'argomento in sé è molto più ampio e comprende in particolare il recupero da guasti, compresi guasti per i quali le persone sono raramente preparate, ad esempio errori dell'operatore.
— Puoi fornire un esempio del cluster di dati più carico e più grande?
Uno dei nostri cluster più grandi è il cluster regalo: più di 200 nodi e centinaia di TB di dati. Ma non è il più caricato, visto che è coperto da una cache distribuita. I nostri cluster più attivi gestiscono decine di migliaia di RPS in scrittura e migliaia di RPS in lettura.
- Oh! Quanto spesso si rompe qualcosa?
! In totale abbiamo più di 6mila server e ogni settimana vengono sostituiti un paio di server e diverse dozzine di dischi (senza tener conto dei processi paralleli di aggiornamento ed espansione del parco macchine). Per ogni tipo di guasto ci sono istruzioni chiare su cosa fare e in quale ordine, tutto è automatizzato quando possibile, quindi i guasti sono di routine e nel 99% dei casi si verificano senza che gli utenti se ne accorgano.
— Come gestite tali rifiuti?
Fin dall'inizio del funzionamento di Cassandra e dai primi incidenti, abbiamo lavorato sui meccanismi di backup e ripristino da essi, creato procedure di distribuzione che tengano conto dello stato dei cluster Cassandra e, ad esempio, non consentano il riavvio dei nodi se la perdita di dati è possibile. Di tutto questo parleremo durante il meetup.
— Come hai detto, non esistono sistemi assolutamente affidabili. Per quali tipi di fallimenti ti prepari e sei in grado di gestire?
Se parliamo delle nostre installazioni di cluster Cassandra, gli utenti non noteranno nulla se perdiamo più macchine in un DC o in un intero DC (questo è successo). Con l'aumento del numero dei DC si sta pensando di iniziare a garantire l'operatività in caso di guasto di due DC.
— Cosa pensi che manchi a Cassandra in termini di tolleranza agli errori?
Cassandra, come molti altri primi negozi NoSQL, richiede una profonda comprensione della sua struttura interna e dei processi dinamici che si verificano. Direi che manca di semplicità, prevedibilità e osservabilità. Ma sarà interessante sentire le opinioni degli altri partecipanti al meeting!
Oleg, grazie mille per aver dedicato del tempo per rispondere alle domande!
Aspettiamo tutti coloro che desiderano comunicare con gli esperti nel campo del funzionamento di Apache Cassandra all'incontro del 12 settembre nel nostro ufficio di San Pietroburgo.
Vieni, sarà interessante!
Fonte: habr.com