Oleg Anastasyev 迷你访谈:Apache Cassandra 中的容错能力

Oleg Anastasyev 迷你访谈:Apache Cassandra 中的容错能力

Odnoklassniki 是 RuNet 上最大的 Apache Cassandra 用户,也是世界上最大的用户之一。 我们从 2010 年开始使用 Cassandra 来存储照片评级,现在 Cassandra 管理着数千个节点上的 PB 级数据,事实上,我们甚至开发了自己的 NewSQL 事务数据库.
12 月 XNUMX 日,我们将在圣彼得堡办事处举办 第二次专门讨论 Apache Cassandra 的聚会。 本次活动的主要发言人将是 Odnoklassniki Oleg Anastasyev 的总工程师。 Oleg 是分布式和容错系统领域的专家;他与 Cassandra 合作已有 10 多年,并多次 在会议上谈到使用该产品的功能.

在聚会前夕,我们与 Oleg 讨论了 Cassandra 分布式系统的容错性,询问他会在聚会上谈论什么以及为什么值得参加这个活动。

Oleg 于 1995 年开始了他的编程生涯。 他开发了银行、电信和运输领域的软件。 自 2007 年以来,他一直在 Odnoklassniki 平台团队担任首席开发人员。 他的职责包括开发高负载系统、大型数据仓库的架构和解决方案,以及解决门户性能和可靠性问题。 他还在公司内部培训开发人员。

- 奥列格,你好! XNUMX月份发生了 第一次聚会,献给Apache Cassandra,与会者表示讨论一直持续到深夜,请告诉我,您对第一次聚会的印象如何?

来自不同公司、不同背景的开发者带着自己的痛苦、意想不到的问题解决方案和精彩的故事来到这里。 我们设法以讨论的形式进行了大部分聚会,但讨论太多,我们只能触及计划主题的三分之一。 我们非常关注如何使用真实生产服务的示例来监控我们的监控方式和内容。

我很感兴趣并且非常喜欢它。

- 从公告来看, 第二次聚会 将完全致力于容错,为什么选择这个主题?

Cassandra 是一个典型的繁忙分布式系统,除了直接服务用户请求之外,还具有大量功能:八卦、故障检测、模式更改传播、集群扩展/收缩、反熵、备份和恢复等。 与任何分布式系统一样,随着硬件数量的增加,发生故障的可能性也会增加,因此 Cassandra 生产集群的运行需要深入了解其结构,以预测发生故障和操作员操作时的行为。 使用 Cassandra 多年后,我们 积累了丰富的专业知识,我们准备分享,也想讨论店里的同事如何解决典型问题。

— 说到 Cassandra,容错是什么意思?

首先,当然是系统承受典型硬件故障的能力:机器、磁盘或与节点/数据中心的网络连接丢失。 但这个主题本身要广泛得多,特别包括从故障中恢复,包括人们很少准备好的故障,例如操作员错误。

— 你能举一个负载最多、最大的数据集群的例子吗?

我们最大的集群之一是 Gift 集群:超过 200 个节点和数百 TB 数据。 但它并不是负载最多的,因为它被分布式缓存覆盖。 我们最繁忙的集群可处理数万个 RPS 写入和数千个 RPS 读取。

- 哇! 东西多久会坏一次?

一直是! 我们总共拥有 6 多台服务器,每周都会更换几台服务器和几十块磁盘(不考虑机器群升级和扩展的并行过程)。 对于每种类型的故障,都有明确的指示说明要做什么以及按什么顺序进行,一切都会尽可能自动化,因此故障是例行公事,并且在 99% 的情况下发生时不会被用户注意到。

——你如何应对这样的拒绝?

从 Cassandra 运行之初和第一起事件开始,我们就研究了备份和恢复机制,构建了考虑到 Cassandra 集群状态的部署程序,例如不允许重新启动节点如果数据可能丢失。 我们计划在聚会上讨论这一切。

——正如你所说,不存在绝对可靠的系统。 您准备并能够处理哪些类型的故障?

如果我们谈论 Cassandra 集群的安装,如果我们在一个 DC 或整个 DC 中丢失多台机器(这种情况已经发生),用户将不会注意到任何事情。 随着DC数量的增加,我们正在考虑开始在两个DC出现故障的情况下保证可操作性。

— 您认为 Cassandra 在容错性方面缺乏什么?

Cassandra 与许多其他早期 NoSQL 存储一样,需要深入了解其内部结构和发生的动态过程。 我想说它缺乏简单性、可预测性和可观察性。 但听到其他会议参与者的意见会很有趣!

奥列格,非常感谢您抽出时间回答问题!

我们正在等待每一位想要在 12 月 XNUMX 日在我们圣彼得堡办公室举行的聚会上与 Apache Cassandra 操作领域的专家进行交流的人。

来吧,会很有趣的!

报名参加活动。

来源: habr.com

添加评论