您的位置:首页 > 数据库

在Kubernetes集群间迁移Cassandra数据库

2020-11-29 00:19 866 查看

在本文中,我们将介绍一篇关于在不同的Kubernetes集群间迁移Cassandra数据库的文章《在不丢失数据的情况下在Kubernetes集群间迁移Cassandra数据库》。点击这里查看原文。

 

01 引言

在微服务和应用容器化的时代,如何高效管理部署和编排运行在本地、虚拟机、云上以及混合环境下的大量的应用容器,成为了开发人员必须要考虑的事项之一。

Kubernetes(简称k8s)的出现则是为了解决这一问题。

Kubernetes是一个分布式的容器编排引擎,提供了服务发现和负载均衡、存储编排、自动部署和回滚、自我修复等功能。因而,它可以高效处理容器化应用的自动化部署、 伸缩和管理等任务。

Kubernetes与Cassandra的结合无疑简化了分布式系统的生命周期管理,然而在实际应用中我们也会遇到一些挑战,比如当原文作者想要改变Cassandra部署文件中的一些参数时。

 

 

02 需求与挑战

当我们改变Cassandra节点的配置参数后,为了使新的配置生效,我们需要重启该节点。然而在实际生产环境中,对于高可用性的要求使我们不得不考虑创建新的Cassandra数据中心并进行数据迁移,从而平稳高效地解决这个问题。

对于原文作者来说,他们的实际要求包括:宕机时间限制于2-3分钟内,并且应用程序转向新k8s集群,以及两个k8s集群间的数据迁移过程要同时进行;数据迁移不能导致数据的丢失,此过程也应无需其它额外操作。

面对这样的要求,原文作者的解决思路是:在新的k8s集群中创建一个新的Cassandra数据中心,并将旧的Cassandra数据中心与新的Cassandra数据中心合并,进而进行数据迁移。在数据迁移完成之后,再将旧的Cassandra数据中心删除。

 

 

03 基础复习

在展开说明原文作者的解决思路之前,首先简单复习一下Cassandra和Kubenetes是如何在逻辑结构概念上对应统一的:

  • Cassandra Node → Kubernetes Pod
  • Cassandra Rack → Kubernetes StatefulSet
  • Cassandra Datacenter → pool of StatefulSets
  • Cassandra Cluster → Kubernetes custom resources (CRDs)

然而,光有这些是不够的。通常来说,我们还需要相应的控制器和operator来帮助我们部署和管理。

对于Cassandra以及其它数据库管理系统来说,operator通常的设计模式是:边车(sidecar) <-> 控制器(controller) <-> CRD。

 

04 解决思路

在整个迁移过程中,原文作者用到了三个Cassandra数据中心:

  • Cassandra-new——将在新的Kubernetes集群中使用的新Cassandra数据中心
  • Cassandra-current——现在正在使用的但即将废弃的Cassandra数据中心(存储在本地)
  • Cassandra-temporary——将被部署在Cassandra-current旁边为迁移过程临时之用

接下来我们总结了原文作者针对“在k8s集群间迁移Cassandra数据库”这一问题的解决思路:

  1. 在目标k8s集群中创建Cassandra-new并将其中的pod数量缩减至0
  2. 在Cassandra-temporary所在的k8s集群中挂载由PVC创建的volume
  3. 利用operator在Cassandra-current集群旁创建临时集群Cassandra-temporary,并且保证Cassandra-temporary所使用的正是新集群Cassandra-new即将使用的磁盘
  4. 更改Cassandra-temporary的配置以将其与Cassandra-current合并——最终我们得到的应该是一个Cassandra集群,其中包含了两个数据中心:Cassandra-current和Cassandra-temporary
  5. 在Cassandra-temporary和Cassandra-current间通过nodetool rebuild进行数据迁移
  6. 将Cassandra-current和Cassandra-temporary所在的两个k8s集群的资源缩减至0,此时operator依然在运行
  7. 更换磁盘,在确保磁盘连接正确的前提下运行Cassandra-new(此时Cassandra-new已经运行在新的k8s集群中),同时将应用程序转移至新的集群
  8. 通过ALTER所有的表来移除Cassandra集群里旧的数据中心,然后再移除旧的节点

通过这种方式,原文作者仅用3分钟左右的Cassandra宕机时间就完成了将Cassandra数据库在Kubernetes集群间的迁移。并且整个过程中Cassandra数据库处于功能完整可用的状态,完全没有影响应用程序的运行。

 

05 总结

本文只总结了原文作者迁移过程的核心步骤,在此过程中,原文作者还遇到诸如operators的选择比较、在Kubernetes集群间建立网络连接、硬盘和内存空间告急等实际问题,在这里可查看更多细节。

 

《Cassandra与Kubernetes》一文中,我们提到过Cassandra与Kubernetes的结合使用是非常顺理成章的,尤其在Kubernetes对于有状态应用有了更多的支持之后。

Cassandra和Kubernetes共同具有高可用性和伸缩性,所以它们的结合可以在复杂的环境下满足各种应用程序(尤其是云原生应用程序)对于性能和灵活性的要求。

为了简化Cassandra在Kubernetes环境下配置运行的流程,DataStax已经开源了DataStax Kubernetes Operator。我们希望同整个社区一起努力,使Cassandra在云原生时代成为Kubernetes环境里数据库的默认选项之一。

点击这里查看更多关于DataStax Kubernetes Operator的资源。

 

 

References:

  1. https://medium.com/flant-com/migrating-cassandra-between-kubernetes-clusters-ae4ab4ada028
  2. https://medium.com/flant-com/running-cassandra-in-kubernetes-challenges-and-solutions-9082045a7d93
  3. https://kubernetes.io/zh/docs/concepts/overview/what-is-kubernetes/
  4. https://youtu.be/h7K3RnEt0HM?t=438
  5. https://thenewstack.io/datastax-open-sources-a-kubernetes-operator-to-ease-cassandra-management/
  6. https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/configuration/configCassandra_yaml.html
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: