在Kubernetes集群间迁移Cassandra数据库

在本文中，我们将介绍一篇关于在不同的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:

posted @ 2020-11-29 00:19  DataStax  阅读(375)  评论(0)  编辑  收藏  举报