Released in October 2018,Redis Enterprise Kubernetes Operator 只有约一年的历史,但多个客户已使用它在生产中运行 Redis Enterprise 集群。现值 Kubernetes Operator 一周年的庆典之际,我们将另一个强大的第 2 天操作启用程序添加到其工具集中:自动集群恢复。
Kubernetes Operator 首次可以将有状态服务视为无状态服务进行管理,从而改变系统操作员和开发人员跨环境测试、部署和管理 Redis 的方式。
Redis Enterprise 集群是一个用于在多隔离租户架构中管理多种配置的多个数据库的平台。我们喜欢将其视为 Redis 数据库实例(也称为 分片)的编排平台。
可以按以下方式之一设置这些数据库
在典型部署场景中,该集群可管理数百个分片,可扩展至数十 TB 的数据,还可每秒运行数千万次操作。
Redis Enterprise 集群采用 多种机制来保证集群的可用性,即使在多个分片发生故障或节点发生故障的情况下也是如此,只要大多数集群节点保持活动状态。
在发生不可能出现的、称为“法定人数不足”的情况时(即集群的一半以上节点宕机),就会发生很多不好的事情。缓存不再存储复杂操作或返回缓存结果,从而延长应用程序响应时间。Web 会话丢失,电子商务购物车被清空。
任何此类事件都可能对组织产生深远且不利的业务后果,包括从不良客户体验到损失多笔交易,且这些影响会在繁忙时间、旺季或产品发布等其他特殊活动期间被放大。
在所有这些场景中,将集群及其数据恢复到原始的、完全可操作的状态对于业务关键型 Redis 用例至关重要,因为即使一秒钟的宕机也可能转化为数千甚至数百万次操作的损失。
除了从不常见的灾难和错误中恢复外,还有其他操作场景,其中自动集群恢复至关重要。Redis 运营人员通常将集群重新定位或复制到新环境中,以便在新区域提供服务或服务于不断扩大的人群。他们还希望以最小的生产服务影响来回收利用集群的基本基础设施,以便进行维护、修补和扩展。为了提高弹性,他们需要一个精确、可重复和快速的恢复模型来让 生产环境中的混沌工程变得更容易。
Kubernetes 从本质上协调无状态服务的生命周期,而对于有状态服务(比如我们的集群),则负责这项工作的将是系统运营人员。这就是 Redis Enterprise Kubernetes Operator 发挥作用的地方。
我们新的集群恢复机制让用户能够解决所有这些场景及更多情况,方式是在几分钟内使从整个集群故障事件中恢复成为可能。Kubernetes Operator 集群恢复执行一个完全自动化的、可预测的且一致的过程来恢复 Redis Enterprise 集群。这些操作以前可能需要几个小时才能完成,并且对人为错误的易感性增加,而现在则快速、可靠且完全自动化。
凭借管理所有主要公共云和数百个内部部署环境中超过一百万个生产用 Redis 实例的多年运营知识,我们引入了一个专用的流程来编排集群自举。在正常操作条件下,自举程序在部署实例化时创建一个新集群。当需要集群恢复时,系统运营人员可以轻松更新集群的声明性说明,以启动恢复流程。
对于自动恢复,自举程序会重新创建集群,并自动装载 以前集群的持久卷声明,其中包含持久化数据。然后,它会恢复原始集群配置,联接其余节点,并对旧集群上配置的所有数据库重新创建到新恢复的集群中。接下来,恢复会加载数据集,在集群节点之间平衡数据,并将以前用于每个数据库的端点关联起来。
在大多数场景中,集群可以在几分钟内恢复,而无需人工干预。
全新的 Kubernetes Operator 支持的恢复体验现已推出,包括我们的最新版本的 Kubernetes 部署和 Redis Enterprise 集群。
如果您想体验 Redis 运算符如何执行自动集群恢复,您可以按照我们Kubernetes 文档或GitHub上的说明,在多个 Kubernetes 发行版中的一项上、在云端的企业内部设置 Redis 企业集群。然后,访问面向 Kubernetes 的 Redis 企业集群恢复页面获取演练。