基于喜欢的DB、Kubernetes操作器和容器存储运行自己的DBaaS

作者：Evan Powell

为什么要这么做？

几乎每天我都听人说到想把越来越多的工作转移到Kubernetes上。这可能有道理，因为上面来自StackOverflow的数据表明，Kubernetes已经真正起飞了。

而早在2017年，我主要被问到的是 - 如何运行自己的Kubernetes，通过OpenShift，Rancher或Kubespray，或从源码开始，相对于从三大云服务商直接购买使用 - 而最近在MayaData以及OpenEBS社区，我们常常被要求建议的是，运行自己的Redis，Cassandra或MongoDB。这些用户所需比较的是来自相同的三大云服务商的DBaaS，甚至是DB供应商本身提供的服务。

第一个问题是 - 为什么？你为什么要承担自己做这件事的责任？我不想离题太远，因为我想更多地谈谈“如何而不是为什么” — 我将简单地把答案总结为：“出于我们运行Kubernetes相同的原因。从广义上讲，用户想要运行Kubernetes，要么是为了更快地运行，要么是为了省钱 - 或者两者兼而有之。他们想要做的是尽可能少的头痛和风险 - 他们想要所有的东西都是Kubernetes原生，并且是顺利工作。

当然，涉及到数据时，安全性也是最重要的。许多企业，如金融服务和医疗服务供应商，或那些担心AWS作为竞争对手的企业，选择在自己的环境中运行自己的Kubernetes，部分原因是担心数据被云供应商，或某些外部攻击者查看。是的，我们看到许多OpenEBS用户使用本地加密，这似乎验证了这一趋势。

DBaaS的替代品

在每家云供应商，你都可以购买多种风格的DBaaS。你选择哪一个取决于你的技术需求，当然也取决于你与这些云供应商的关系。一般来说，你将使用一个高质量的解决方案，一个最小化停机时间，并以最少的麻烦，为你的工程师提供他们基本所需的解决方案。

查看DB选择的一种常见方法是检查CAP定理和应用程序需要什么。通常的经验法则是你从三种选择中选出两种。有许多关于选择数据库的博客和讨论 - 基本的一点是，有越来越多的DB，其中有一部分是由第一线云供应商作为服务提供。

数据库的不同口味

有大量的DB解决方案 - 其中许多都没有什么共同点，除了它们的主要任务是对数据进行排序，以便更快地存储或访问特定用例。至少有八种主要类型：

• 键值存储 - 例如Kubernetes内部的ETCD
• 列存储 - 例如Amazon的Redshift — 通常作为分析最有效 — SAP Hana是内存数据库中一个著名的专有数据库，通常被归类为列存储
• 文档存储 - 比如MongoDB
• 图形数据库 - 比如Neo4J
• 行存储 - Cassandra实际上就是其中之一，尽管有时被称为列存储 — 通常面向行的DB更擅长写
• 内存数据库 - 如Redis
• 综合的“Synthetic”，如CockroachDB、NuoDB和TiDB - 它们能够在水平缩放读写时保持一致性，因此可以说是在拉伸，甚至使上面突出显示的ACP变得毫无意义
• 时间序列数据库，如InfluxDB，通常运行在Kubernetes上最常见的有状态工作负载下 - Prometheus，默认的监控解决方案；如果你对2018年10月的这个博客感兴趣，你可以阅读更多关于Prometheus下使用OpenEBS的信息：https://blog.openebs.io/using-openebs-as-the-tsdb-for-prometheus-fac3744d5507

相对旧的和众所周知的SQL的解决方案似乎仍是非常普遍，这里有各种各样的原因，比如微服务的起飞减少了工作负载的大小。架构越来越多使用消息系统像Kafka，以及服务网格来回传递相关信息 - 数据的收发 - 而不是一切到放到共享的NoSQL平台。这可能是我们看到大量PostgreSQL和MySQL运行在OpenEBS之上的原因之一。还有一些分布式SQL系统可以向外扩展，但仍然保留SQL语义 - 值得注意的例子包括TiDB和Couchase，其中每个系统都有按底层数据结构排序的键值存储，以及基于分布式内存缓存的NuoDB。介于两者之间的是像Vitess这样的解决方案，它采用MySQL或类似的方法，管理分片和一些横向扩展MySQL所需的自动化操作。

你可以从云供应商中获得这些变体的子集作为服务。那么，为什么用户越来越多地运行自己的DBaaS呢？除了上面非常明显的一点 - 更多的控制，包括运行特定的DB - 以及更少的开销和更少的安全顾虑（无论它们是否有良好的基础）之外，用户为什么可能选择构建和运行自己的DBaaS？

构建一个更好地服务于数据库的堆栈

DB本身由一些软件组成，这些软件具有不同的需求，此外，你还可以选择对每个数据库使用哪些底层存储引擎，以及如何配置这些存储引擎。例如，根据使用的版本和底层存储引擎，MongoDB有一个日志、各种数据目录和一个复制日志。Cassandra有commit_logs、data_files和saved_cache。类似地，PostgreSQL也有一个WAL director和数据目录。今天有了容器附加存储系统（container attached storage system）和Kubernetes中的存储类构造，你可以轻松地将DB的每个组件匹配到一个非常合适，且经过调优的底层存储组件。

另外，如果你想了解关于数据库的BTree和LSM方法、它们的底层存储引擎以及与底层计算机科学相关的概念，你将会从Damian Gryski去年的演讲中受益：

https://youtu.be/wxcCHvQeZ-U

尽管DB的组合几乎是无穷无尽的，许多类型的DB的示例都可以不同地配置，但是你可以借助像OpenEBS一样的解决方案，在任何底层物理磁盘或云卷上的公共存储层上使用它们，通常会为每个组合自动定制。

你可以在有关多种类型的DB的文档中，了解关于DB的每个组件对存储的更多信息；例如，MongoDB文档声明：

同样值得注意的是，为了处理磁盘或SSD故障，MongoDB文档还建议使用RAID 10。

更容易地集成不同的数据源

就像Unix - 我们看到DB单做一件事，而且很好地完成。这种面向DB的微服务方法，依赖于Kafka这样的系统来跨数据库和其他数据源集成和流，而不是使用一个外部存储系统来提供所有数据的集成，以及可能带来的问题和困难。现在，在ETL过程之后，大部分数据可能最终都会出现在Snowflake或一些内部部署中。具有讽刺意味的是，如果已知这些DB只做一件事，并且在你的环境中做得很好，那么集成所有这些数据源有时会更容易。

DevOps的自主权

DevOps的一个基本原则，是让小团队选择他们自己的工具。让每个团队选择自己喜欢的DB符合这种模式，而拥有一个大型DBaaS解决方案通常不符合这种模式。

问题在哪里？操作

虽然我们MayaData非常相信Kubernetes作为更自动化操作基础的强大功能，但我们也看到在构建和运行有状态工作负载的方法上有相当多的变化或多样性。

目前，似乎每种DB和有状态工作负载都至少有一个Kubernetes操作器（Operator）。虽然这很棒，但也有点令人担忧。作为事件驱动自动化的领导者 - StackStorm - 的联合创始人，我花了数年的时间来处理这项day two的业务，嗯，这很难。在我看来，我们需要在某些工作接受采用工作流，无论是Argo，现在集成到Kubeflow，或StackStorm，它的核心是一个新的容器友好和非常强大的工作流引擎Orquesta；顺便说一句，Orquesta可以很容易地嵌入到其它项目中，我期待并希望在2019年晚些时候发生。我这里所说的工作流是指使用一个引擎，它可以显式地显示常见的流程事件，比如fork、join、条件暂停等等，并且可以让人们更好地了解和共享这些模式。

回到2015年10月，时间过得真快！我帮助写了一个关于Netflix和其他公司如何使用StackStorm进行Cassandra操作的博客。

https://stackstorm.com/2015/10/02/tutorial-of-the-week-cassandra-auto-remediation/

如果你对工作流程操作感兴趣，顺便说一下，你可能对StackStorm的共同创始人Dmitri Zimine的对谈感兴趣，谈论三大云供应商的产品定位，指出工作流引擎让serverless产品功能联系在一起：

https://thenewstack.io/serverless-and-workflows-the-present-and-the-future/

那么，存储在哪里的位置是？

无论你选择对操作器使用可泛化的方法，还是使用Kubernetes社区中出现的众多一次性方法之一，你都可以通过使用容器附加存储作为泛化的方法。虽然存储和相关功能不会十分在乎你的有状态工作负载是什么 - 但是它可以提供一些每个数据库都需要的公共服务，从而使工程师能够专注于每个数据库中需要他们关注的特定方面。

我将一些常见的需求放到这个表中，因为我们经常会从社区（以及投资者、客户和新团队成员）那里得到一些问题，这些问题表明，数十家争夺关注的DB与底层容器存储之间的界线，有时似乎在所有的喧嚣中迷失了。例如，你是否知道DB的存储引擎不是“真正的存储”？欢迎在下方发表评论，或者更好地 - 在StackOverflow或者我们的Slack社区本身提问：

https://slack.openebs.io

例如，我们最近完成了测试，并创建了一些推荐的存储类，这些存储类是最大的NoSQL社区项目之一。你可以在OpenEBS.ci看到提交到OpenEBS Master的各种常见数据进行的测试。如果你感兴趣，还可以获取进行此测试的系统的存储类和配置。

总结

本博客旨在概述运行你自己的DBaaS时需要考虑的一些事情。总的来说，我建议你这样做 - 不过，我也建议你仔细考虑一下操作自动化，当然还有底层数据的弹性。

我们在MayaData正积极致力于企业的许多DBaaS实现，我们也很乐意通过Slack等的讨论来分享最佳实践。请务必保持联系。在DBaaS部署的帮助下，我们共同实现数据敏捷性的巨大提升。无论你对DB或其他有状态工作负载进行何种组合，我们都尽自己的一份力量帮助你实现真正的数据敏捷性。