Odnoklassniki è il più grande utilizzatore di Apache Cassandra in Runet e uno dei più grandi al mondo. Abbiamo iniziato a utilizzare Cassandra nel 2010 per memorizzare le valutazioni delle foto e ora gestiamo petabyte di dati su migliaia di nodi. Inoltre, abbiamo persino sviluppato la nostra versione. .
Il 12 settembre nel nostro ufficio di San Pietroburgo si terrà Il relatore principale dell'evento sarà il chief engineer di Odnoklassniki, Oleg Anastasiev. Oleg è un esperto in sistemi distribuiti e ad alta disponibilità, lavora con Cassandra da oltre 10 anni e ha più volte .
In preparazione al meetup, abbiamo parlato con Oleg della resilienza dei sistemi distribuiti con Cassandra, chiedendogli di cosa parlerà al meetup e perché dovresti partecipare a questo evento.
Oleg ha iniziato la sua carriera come programmatore nel lontano 1995. Ha sviluppato software nei settori bancario, telecomunicazioni e trasporti. Lavora come sviluppatore senior su Odnoklassniki dal 2007, all'interno del team della piattaforma. Le sue responsabilità includono la progettazione di architetture e soluzioni per sistemi ad alta intensità di carico, grandi database, nonché la risoluzione di problemi di performance e affidabilità del portale. Si occupa anche di formare sviluppatori all'interno dell'azienda.
— Ciao Oleg! A maggio si è svolto , dedicato ad Apache Cassandra, i partecipanti dicono che le discussioni sono andate avanti fino a tardi nella notte, per favore, quali sono state le tue impressioni dal primo meetup?
Sono venuti sviluppatori con background diversi da diverse aziende con i loro problemi, soluzioni inaspettate e storie sorprendenti. Siamo riusciti a svolgere gran parte del meetup in formato di discussione, ma c'erano così tante discussioni che siamo riusciti a toccare solo un terzo degli argomenti previsti. Abbiamo prestato molta attenzione a come e cosa monitoriamo prendendo come esempio i nostri reali servizi in produzione.
Mi è stato interessante e mi è piaciuto molto.
— A giudicare dall'annuncio, sarà completamente dedicato alla tolleranza ai guasti, perché abbiamo scelto proprio questo argomento?
Cassandra è un tipico sistema distribuito ad alta disponibilità con un'enorme quantità di funzionalità oltre al semplice servizio delle richieste degli utenti: gossip, rilevamento dei guasti, diffusione delle modifiche allo schema, espansione/riduzione del cluster, anti-entropy, backup e ripristino, ecc. Come in qualsiasi sistema distribuito, con l'aumento della quantità di hardware cresce la probabilità di guasti; pertanto, la gestione dei cluster Cassandra in produzione richiede una profonda comprensione del suo funzionamento per prevedere il comportamento in caso di guasti e le azioni dell'operatore. Durante anni di utilizzo di Cassandra, abbiamo , che siamo pronti a condividere, e vogliamo anche discutere di come i colleghi nel settore affrontano problemi comuni.
— Quando si parla di Cassandra, cosa intendi per tolleranza ai guasti?
In primo luogo, ovviamente, la capacità del sistema di gestire i guasti hardware tipici: la perdita di macchine, dischi o connettività di rete con nodi/data center. Ma l'argomento è molto più ampio e include in particolare il ripristino dopo guasti, compresi quelli per cui le persone sono raramente pronte, come gli errori dell'operatore.
— Puoi fare un esempio del cluster di dati più carico e grande?
Uno dei nostri cluster più grandi è il cluster dei regali: più di 200 nodi e centinaia di TB di dati. Ma non è il più sovraccarico, poiché supportato da una cache distribuita. I nostri cluster più carichi gestiscono decine di migliaia di RPS in scrittura e migliaia di RPS in lettura.
— Wow! Con quale frequenza si rompe qualcosa?
! Abbiamo oltre 6.000 server, e ogni settimana un paio di server e diverse decine di dischi vengono sostituiti (escludendo i processi paralleli di aggiornamento ed espansione della flotta di macchine). Per ogni tipo di guasto è disponibile un'istruzione chiara su cosa e in quale ordine fare, il tutto è automatizzato il più possibile, quindi i guasti sono routine e nel 99% dei casi avvengono senza essere notati dagli utenti.
— Come affrontate tali guasti?
Fin dall'inizio dell'esercizio di Cassandra e dai primi incidenti, abbiamo sviluppato meccanismi di backup e ripristino, costruito procedure di deploy che tengono conto dello stato dei cluster Cassandra e, ad esempio, non permettono il riavvio dei nodi se c'è il rischio di perdita di dati. Di tutto questo intendiamo discutere al meetup.
— Come hai detto, non esistono sistemi completamente affidabili. Quali tipi di guasti state preparando e siete in grado di affrontare?
Se parliamo delle nostre installazioni dei cluster Cassandra, gli utenti non noteranno alcuna differenza se perdiamo alcune macchine in un data center o un intero data center (è già successo). Con la crescita del numero di data center, stiamo pensando di iniziare a garantire la continuità in caso di guasto di due data center.
— Cosa manca a tuo avviso a Cassandra in termini di resilienza?
Cassandra, come molti altri primi sistemi di archiviazione NoSQL, richiede una profonda comprensione della sua struttura interna e dei processi dinamici che avvengono. Direi che le mancano semplicità, prevedibilità e osservabilità. Ma sono curioso di sentire anche le opinioni degli altri partecipanti al meetup!
Oleg, grazie mille per aver trovato il tempo di rispondere alle domande!
Aspettiamo tutti coloro che vogliono confrontarsi con esperti nel campo dell'operatività di Apache Cassandra al meetup il 12 settembre nel nostro ufficio di San Pietroburgo.
Venite, sarà interessante!
Fonte: habr.com
