Les camarades de classe sont le plus grand utilisateur d'Apache Cassandra dans RuNet et l'un des plus grands au monde. Nous avons commencé à utiliser Cassandra en 2010 pour stocker des estimations de photos, et maintenant Cassandra gère des pétaoctets de données sur des milliers de nœuds, de plus, nous avons même développé notre propre
base de données transactionnelle NewSQL .
Le 12 septembre, dans notre bureau de Saint-Pétersbourg, nous tiendrons la
deuxième réunion consacrée à Apache Cassandra . Le principal orateur de l'événement sera l'ingénieur en chef Odnoklassnikov Oleg Anastasiev. 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 a
parlé à plusieurs reprises
des caractéristiques de ce produit lors de conférences .
La veille de la réunion, nous avons discuté avec Oleg de la tolérance aux pannes des systèmes distribués avec Cassandra, demandé de quoi il parlerait lors de la réunion et pourquoi cela valait la peine d'assister à cet événement.
Oleg a commencé sa carrière comme programmeur en 1995. Développement de logiciels dans le secteur bancaire, télécom, transport. Il travaille en tant que développeur principal chez Odnoklassniki depuis 2007 au sein de l'équipe de la 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, la résolution des problèmes de productivité et de fiabilité du portail. Il est également engagé dans la formation de développeurs au sein de l'entreprise.
- Oleg, bonjour! La première réunion consacrée à Apache Cassandra a eu lieu en mai, les participants disent que les discussions se sont poursuivies jusque tard dans la nuit, dites-moi, quelles sont vos impressions sur la première réunion?Des développeurs d'horizons différents de diverses sociétés sont venus avec leur douleur, des solutions inattendues aux problèmes et des histoires incroyables. Nous avons pu mener la majeure partie de la réunion sous la forme de la discussion, mais il y a eu tellement de discussions que nous n'avons pu aborder qu'un tiers des sujets qui ont été décrits. Nous avons prêté beaucoup d'attention à la façon et à ce que nous surveillons en utilisant nos services de production réels à titre d'exemple.
J'étais intéressé et j'ai vraiment apprécié.
- A en juger par l'annonce, le deuxième mitap sera entièrement consacré à la tolérance aux pannes, pourquoi avoir choisi ce sujet?Cassandra est un système distribué chargé typique avec une énorme quantité de fonctionnalités en plus de servir directement les demandes des utilisateurs: potins, détection de panne, distribution des modifications de schéma, extension / réduction du cluster, anti-entropie, sauvegardes et récupération, etc. Comme dans tout système distribué, avec une augmentation de la quantité de fer, la probabilité de pannes augmente, donc le fonctionnement de la production des clusters Cassandra nécessite une connaissance approfondie de son appareil pour prédire le comportement en cas de pannes et d'actions de l'opérateur. Dans le processus d'utilisation de Cassandra depuis de nombreuses années, nous
avons accumulé une expertise considérable , que nous sommes prêts à partager, et voulons également discuter de la façon dont nos collègues résolvent des problèmes typiques.
- En ce qui concerne Cassandra, qu'entendez-vous par tolérance aux fautes?Tout d'abord, bien sûr, la capacité du système à survivre aux défaillances 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 large et, en particulier, comprend la récupération après des pannes, y compris des pannes, pour lesquelles les gens sont rarement préparés, par exemple, les erreurs de l'opérateur.
- Pouvez-vous donner un exemple du cluster de données le plus chargé et le plus grand?L'un de nos plus grands clusters est le cluster des cadeaux: plus de 200 nœuds et des centaines de To de données. Mais ce n'est pas le plus chargé, car il est couvert par un cache distribué. Nos clusters les plus occupés contiennent des dizaines de milliers de RPS pour l'écriture et des milliers de RPS pour la lecture.
- Ouah! À quelle fréquence quelque chose se casse-t-il?Oui, constamment ! Au total, nous avons plus de 6 000 serveurs, et chaque semaine, quelques serveurs et plusieurs dizaines de disques sont remplacés (sans prendre en compte les processus de mise à niveau parallèles et l'expansion de la flotte de véhicules). Pour chaque type de panne, une instruction claire est écrite sur quoi et dans quel ordre faire, tout est automatisé si possible, donc les pannes sont une routine et dans 99% des cas elles surviennent inaperçues par les utilisateurs.
- Que luttez-vous avec de tels échecs?Dès le début de l'exploitation de Cassandra et les premiers incidents, nous avons élaboré des mécanismes de sauvegarde et de récupération à partir de ceux-ci, construit des procédures de déploiement qui prennent en compte l'état des clusters Cassandra et, par exemple, empêchent les nœuds de redémarrer si une perte de données est possible. Nous prévoyons de parler de tout cela lors de la réunion.
- Comme vous l'avez dit, il n'existe pas de systèmes absolument fiables. À quels types d'échecs vous préparez-vous et pouvez-vous 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 envisageons de commencer à assurer l'opérabilité en cas de panne de deux DC.
- Que pensez-vous que Cassandra manque en termes de tolérance aux pannes?Cassandra, comme de nombreux autres anciens référentiels NoSQL, nécessite une compréhension approfondie de sa structure interne et des processus dynamiques en cours. Je dirais qu'elle manque de simplicité, de prévisibilité et d'observabilité. Mais il sera intéressant d'entendre l'avis 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 discuter avec des experts dans le domaine de l'exploitation d'Apache Cassandra lors d'une réunion le 12 septembre à leur bureau de Saint-Pétersbourg.
Venez, ce sera intéressant!
Inscrivez-vous à l'événement.