当前位置:网站首页>Astra: Apache Cassandra的未来是云原生

Astra: Apache Cassandra的未来是云原生

2020-11-08 04:23:19 DataStax

我们希望利用我们十年来构建和运营企业级Cassandra部署的经验,为Apache Cassandra构建世界一流的云原生服务。 

 

我们正在Kubernetes上构建“Cassandra即服务”,也正在积极踊跃地使C*成为世界上最好的开源、可扩展的云原生数据库。 


 

01 云原生的Apache Cassandra

我们希望Apache Cassandra成为云原生。在这个意义上,成千上万的开发者和运营商,以及从初创企业到Apple和Netflix等巨头公司,都和我们站在同一行列。

 

为了有资格表述这样一个观点,我们做了大量的工作:Astra是建立在Kubernetes、Prometheus和Envoy基础上的,而且参与GKE和EKS的本机控制和管理平面。我们也考量了其他人在这方面做的工作,特别是那些在开源Kubernetes operators方面对Cassandra做出了分享贡献的人们。 

 

为了在云上的Kubernetes大规模运行C*,我们进行了一些必要的技术工作、更改和权衡取舍。在此基础上,我们形成了对于Astra的以上观点。随着我们继续交付和改进Astra,我们的观点将随之演进。

 

我们通过对C*开源生态系统做出贡献来分享着这样的观点,特别是通过OSS项目(包括Kubernetes operators管理辅助工具指标收集器配置构建器NoSQL测试系统)。 

 

交流意见的必然结果是倾听他人的意见。在强化Cassandra的提案过程中,我们看到了一系列充满活力而来之不易的经验,这些经验为Cassandra赢来了很多Kubernetes operators

 

互相倾听将有利于大家共同思考和合作,以集体的经验来改进我们的主张,并为用户发布更好的代码。

 

02 我们的关注点

我们已经了解了Apache Cassandra与云部署相关的体系和架构,这有助于我们为社区思考做出贡献。在C* 4.0发布后,我们将必须在架构选择上做出共同的抉择。 

 

Cassandra的分支中我们已经将部分领会付诸实践,希望将来我们能与大家分享。为了让Cassandra能满足Kubernetes和云原生的特定需求,我们已经尽可能地添加了代码。

 

使用Apache Cassandra 3.11运行云原生服务需要涉及到四个工作领域:网关,操作,管理和部署。

 Astra 在 GKE/GCP 的高层架构 

 

网关(Gateway) 2-1

Astra集群通过网关接收流量。Astra使用Envoy来路由Cassandra二进制端口的请求并简化驱动程序配置。在云原生配置中,拥有单个入口IP对于管理具有弹性后端的连接性是至关重要的。这也减少了开放端口的数量,使Astra能够在云中支持CQL,同时具有弹性和安全性。

 

Astra还使用网关开放REST和GraphQL API,在与数据资产进行交互时,减轻开发者的负担。我们相信,这些将为新一代开发者在全栈应用程序开发方面提供更好的体验。

 

操作(Operations) 2-2

 

集群操作需要自动化。Astra通过一对组件来完成此任务: Cass Operator和用于Apache Cassandra的管理API(MAAC)。Cass Operator是为Apache Cassandra服务的Kubernetes operators。MAAC是Kubernetes的附属工具。

 

Cass Operator提供了一个由C*节点组成的StatefulSet,并把通常由C*管理员执行的手动任务自动化了。这包括启动集群的开始顺序、在删除节点时排干节点、以及将正确的节点放置在正确的容器中(例如防止多个节点部署到同一主机)。

 

为了能够优雅地参与Kubernetes环境,我们必须提供对集群状态的洞察力。实际上,这意味着某些以前属于数据库内部的操作(例如自动重试或建立Gossip链接以跟踪内部集群状态)现在要被提升到应用程序层了。 

 

Kubernetes可以根据整个集群的健康状况来做出决策,而不是每个C*节点自行做出独立的决策。例如,在滚动重启时,与其通过内部检查来查看节点是否正常运行,这些信号会发出给Cass Operator,由Cass Operator确保集群中的每个C*节点都能达到超过半数(quorum)要求。 

 

MAAC提供了一个JSON接口来调用nodetool命令并注入Vault机密。C*通过使用标准C*工具来保持操作一致性,感觉更像Kubernetes。该组件负责进行启动、停止、配置和检查活动性和一致性水平的操作。

 

MAAC作为辅助工具(sidecar)运行,并通过本地Unix套接字(通过mTLS作为可选项)通过CQL与C *通信。每个Sidecar进程仅负责本地C*实例。这就简化了拓扑结构,增强了Cass Operator作为集群协调系统的作用。

 

管理(Management) 2-3

指标度量对于大规模运行C*是必不可少的。Astra使用Apache Cassandra的Metrics Collector(MCAC)提供与Kubernetes和云环境集成的管理功能。 

 

MCAC简化了Cassandra用户的指标收集。C*中的传统度量标准机制是JMX,它与Kubernetes上部署的性能需求和扩展需求不匹配。我们把MCAC建立在collectd的基础上,并捆绑到Cass Operator中。它适用于2.2至4.0 beta的所有开源Apache Cassandra版本。

 

使用collectd意味着每个节点可以导出成千上万个指标系列,而对C*的性能影响最小。它与Prometheus(Kubernetes环境中用于监察的标准)保持一致,并且我们可以分析MCAC指标以及operators级别的指标,例如上下文切换、磁盘性能和网络性能。最后,MCAC写出历史日志,记载下度量指标和生命周期事件(例如落盘,压实,异常和垃圾收集)。

 

MCAC是Astra的一个关键部分,它能够使用户监测到其实例的实时运行特征。Astra可以完善地管理着下面的Cassandra节点的操作,但用户必须了解其数据模型的影响和查询对集群操作特性的影响。

 

部署(Deployment) 2-4

在Kubernetes环境中部署是连续的。通过将配置更改的控制权交给操作系统,Astra能提供更加动态且可靠的数据层。Astra使用cass-config-builder来驱动配置,并使用NoSQLBench进行环境的连续测试。

 

Cass-config-builder根据环境要求以参数方式生成cassandra.yaml文件。启动C* 容器时,它会吸收此配置。IP地址、网络信息、性能调整、安全性、磁盘优化和种子提供者都是正确运行C*的关键组件。Kubernetes控制着整个环境,同时在不断地扩大和缩小规模,对硬件故障做出反应,或更改集群范围的属性,因此C*需要采用新的配置与之适应。 

 

为了确保集群的可靠度,NoSQLBench用户能够创建任意大小的合成数据集,并根据实际应用程序的工作负载需要,运用这些数据集进行大规模负载测试。NoSQLBench适用于任何NoSQL数据库。

 

作为持续部署环境的一部分,数据库的测试自动化可以驱动数十亿次写入和读取操作,大幅减少存储量,并用实际经验展示云环境的优质性能特征。

 

03 总结

我们希望利用我们十年来构建和运营企业级Cassandra部署的经验,为Apache Cassandra构建世界一流的云原生服务。 

 

从Cassandra用户的反馈中我们看到,Kubernetes需要Cassandra,Cassandra需要Kubernetes。我们正在Kubernetes上构建“Cassandra即服务”,也正在积极踊跃地使C*成为世界上最好的开源、可扩展的云原生数据库。 

 

Cassandra正在成为云原生。很高兴大家能与我们共同走在这一征途上。

 

版权声明
本文为[DataStax]所创,转载请带上原文链接,感谢
https://www.cnblogs.com/datastax/p/13943296.html