Odnoklassniki est le plus grand utilisateur d'Apache Cassandra sur RuNet et l'un des plus grands au monde. Nous avons commencé à utiliser Cassandra en 2010 pour stocker les évaluations de photos, et maintenant Cassandra gère des pétaoctets de données sur des milliers de nœuds. En fait, nous avons même développé notre propre .
Le 12 septembre, dans notre bureau de Saint-Pétersbourg, nous organiserons . Le principal intervenant de l'événement sera l'ingénieur en chef d'Odnoklassniki Oleg Anastasyev. Oleg est un expert dans le domaine des systèmes distribués et tolérants aux pannes ; il travaille avec Cassandra depuis plus de 10 ans et à plusieurs reprises .
À la veille de la rencontre, nous avons discuté avec Oleg de la tolérance aux pannes des systèmes distribués avec Cassandra, lui avons demandé de quoi il parlerait lors de la rencontre et pourquoi cela valait la peine d'assister à cet événement.
Oleg a commencé sa carrière de programmeur en 1995. Il a développé des logiciels dans les domaines de la banque, des télécommunications et des transports. Il travaille en tant que développeur principal chez Odnoklassniki depuis 2007 au sein de l'équipe plateforme. Ses responsabilités incluent le développement d'architectures et de solutions pour les systèmes à forte charge, les grands entrepôts de données et la résolution des problèmes de performances et de fiabilité du portail. Il forme également des développeurs au sein de l’entreprise.
- Oleg, bonjour ! En mai a eu lieu , dédié à Apache Cassandra, les participants racontent que les discussions se sont poursuivies jusque tard dans la nuit, dites-moi, quelles sont vos impressions de la première rencontre ?
Des développeurs issus d'horizons différents et de différentes entreprises sont venus avec leurs propres difficultés, des solutions inattendues aux problèmes et des histoires étonnantes. Nous avons réussi à mener la majeure partie de la rencontre sous forme de discussion, mais il y a eu tellement de discussions que nous n'avons pu aborder qu'un tiers des sujets prévus. Nous avons prêté beaucoup d'attention à la manière et à ce que nous surveillons en prenant l'exemple de nos services de production réels.
J'étais intéressé et j'ai vraiment aimé.
- À en juger par l'annonce, sera entièrement consacré à la tolérance aux pannes, pourquoi avoir choisi ce sujet ?
Cassandra est un système distribué typique avec une énorme quantité de fonctionnalités au-delà de la réponse directe aux demandes des utilisateurs : potins, détection de pannes, propagation des modifications de schéma, expansion/réduction de cluster, anti-entropie, sauvegardes et récupération, etc. Comme dans tout système distribué, à mesure que la quantité de matériel augmente, la probabilité de panne augmente. Le fonctionnement des clusters de production Cassandra nécessite donc une compréhension approfondie de sa structure pour prédire le comportement en cas de panne et les actions de l'opérateur. Après avoir utilisé Cassandra pendant de nombreuses années, nous , que nous sommes prêts à partager, et nous souhaitons également discuter de la manière dont les collègues du magasin résolvent les problèmes typiques.
— Quand il s'agit de Cassandra, qu'entendez-vous par tolérance aux pannes ?
Tout d’abord, bien sûr, la capacité du système à survivre aux pannes matérielles typiques : perte de machines, de disques ou de connectivité réseau avec les nœuds/centres de données. Mais le sujet lui-même est beaucoup plus vaste et inclut notamment la récupération après des pannes, y compris des pannes auxquelles les gens sont rarement préparés, par exemple les erreurs des opérateurs.
— Pouvez-vous donner un exemple du cluster de données le plus chargé et le plus volumineux ?
L'un de nos plus grands clusters est le cluster cadeau : plus de 200 nœuds et des centaines de To de données. Mais ce n'est pas le plus chargé, puisqu'il est couvert par un cache distribué. Nos clusters les plus fréquentés gèrent des dizaines de milliers de RPS en écriture et des milliers de RPS en lecture.
- Ouah! À quelle fréquence quelque chose se casse-t-il ?
! Au total, nous disposons de plus de 6 99 serveurs, et chaque semaine quelques serveurs et plusieurs dizaines de disques sont remplacés (sans tenir compte des processus parallèles de mise à niveau et d'expansion du parc de machines). Pour chaque type de panne, il existe des instructions claires sur ce qu'il faut faire et dans quel ordre, tout est automatisé autant que possible, les pannes sont donc routinières et se produisent dans XNUMX % des cas inaperçues des utilisateurs.
— Comment gérez-vous de tels refus ?
Dès le début du fonctionnement de Cassandra et des premiers incidents, nous avons travaillé sur les mécanismes de sauvegarde et de récupération à partir de celles-ci, construit des procédures de déploiement qui prennent en compte l'état des clusters Cassandra et, par exemple, ne permettent pas le redémarrage des nœuds si une perte de données est possible. Nous prévoyons de parler de tout cela lors du meetup.
— Comme vous l'avez dit, il n'existe pas de systèmes absolument fiables. À quels types d’échecs vous préparez-vous et êtes-vous capable de survivre ?
Si nous parlons de nos installations de clusters Cassandra, les utilisateurs ne remarqueront rien si nous perdons plusieurs machines dans un DC ou un DC entier (cela s'est produit). Avec l'augmentation du nombre de DC, nous réfléchissons à commencer à assurer l'opérabilité en cas de panne de deux DC.
— Selon vous, qu'est-ce qui manque à Cassandra en termes de tolérance aux pannes ?
Cassandra, comme beaucoup d'autres premiers magasins NoSQL, nécessite une compréhension approfondie de sa structure interne et des processus dynamiques qui s'y déroulent. Je dirais qu’il manque de simplicité, de prévisibilité et d’observabilité. Mais il sera intéressant d'entendre les opinions des autres participants à la réunion !
Oleg, merci beaucoup d'avoir pris le temps de répondre aux questions !
Nous attendons tous ceux qui souhaitent communiquer avec des experts dans le domaine de l'exploitation d'Apache Cassandra lors de la rencontre du 12 septembre dans notre bureau de Saint-Pétersbourg.
Venez, ce sera intéressant !
Source: habr.com