Kubernetes 容灾解决方案的关键能力

Kubernetes 容灾解决方案关键能力

我们面临着不断地需要实施和部署新的软件应用、发展新的商业模式、以及吸引新的客户。通过Kubernetes,我们可以采用云原生方式来进行软件的开发、部署和运维。

基于Kubernetes开发和运行的应用,对于我们实现我们的商业目标,非常重要。但新技术的导入,也会要求我们考虑更多:新的开发方法、新的团队、新的工程师、新的技术、新的合作伙伴、新的供应商、新的挑战。

对CIO们来说,将关键应用转移到Kubernetes上的最大挑战之一,就是容灾恢复能力。

在投入大量资金开发了Kubernetes上的应用后,我们最担心的就是:一旦出现我们无法控制的意外事件,我们的应用变得无法访问。如:云供应商服务意外停止、数据中心电力中断、云服务中断、网络连接中断等。导致用户无法访问应用后,用户满意度大幅下降。

根据著名研究机构Uptime Institute的报告,通常发生服务中断,一般我们会归因到第三方服务上,如托管服务供应商或云服务供应商。31%的服务中断是由由我们无法控制的因素导致的,如:网络错误(30%),IT/软件错误(28%)。对于Kubernetes上的应用,我们需要一个可靠的容灾恢复方案。

根据451 Research的报告,对于关键性应用来说,57%的应用要求RPO<1小时,48%要求RTO<1小时。即使是非关键应用,也有容灾恢复的需求。这对已经满负荷工作的IT团队来说都是较大的压力。

在这样的情况下,企业的IT团队,需要为诸多企业级应用交付强健的容灾恢复方案。

要点小结

Portworx解决了云原生Kubernetes应用企业级容灾的三个关键难点。

基于Kubernetes底层原生开发的PX-DR:

  • 以Kubernetes原生方式进行保护和恢复:容器颗粒度的保护、命名空间可感知。
  • 可应用感知的整体企业级解决方案、而不是多种方法的应用复合。
  • 操作简单,可实现零数据损失的跨云自动化快速恢复。

Kubernetes容灾解决方案,不仅需要操作简单方便,而且需要对容器化应用的技术细节进行有效感知。因此,一个为Kubernetes原生构建的、简单、易用、方便的容灾恢复方案变得更加重要。

Kubernetes应用保护的主要难点

容器的基本结构原理与虚拟机有着根本的不同

容器化应用与虚拟机中的应用有很大不同。为了有效的保护和恢复容器化应用,我们需要在分布式系统中编排执行一系列复杂的操作。这是因为应用是同时运行在多个容器里的,并且这些容器存在于Kubernetes集群里的不同的节点之上。

相对于在过去15年里我们常见的基于虚拟机的单体应用来说,这是架构上的很大不同。

传统的备份和恢复方案对于虚拟机的应用来说已足够。但是对于Kubernetes和容器来说,就不再适合。使用传统的基于VM的备份方案,不仅会让你失去对系统安全的控制,甚至会在关键时候导致应用不可用或者数据丢失,这是存在较大风险的。

容器应用需要智能化的自动恢复

在出现灾难事件后,恢复一个Kubernetes应用,并不是仅在另一个区域重新启动一个新容器那么简单。简单的快照无法有效确保数据的一致性。

容器应用的组件都是单独部署和单独扩展的,每个容器都有自己的容器镜像、部署配置、状态规则、外部配置、运维周期、依赖关系和数据。配置数据和应用的商业逻辑通常是作为元数据进行存储,保存在Kubernetes集群上,并且需要被保护和恢复,以确保应用能够正常的工作。

今天的容器化应用不再仅仅是一个只包括容器镜像和数据的单体。处于微服务架构下的应用,包括前端服务和中间件层。中间件层包括大量的正在运行商业逻辑的中间件,并且它们都连接到了持久数据服务上。这个完整的堆栈都需要被作为一个整体来进行备份和恢复。

一些流行的数据服务,如Kafka、Cassandra、Elastic、MySQL、MongoDB,是由不同的社区来创建的,每一个的运维管理和要求的技能都很不一样。

分布式数据服务的广泛采用,要求我们重新思考我们的数据保护机制,需要同时考虑数据、以及运维中的元数据。

零数据损失情况下的跨云快速恢复

备份和数据保护是非常重要的。在零数据损失的情况下,及时的恢复应用是容灾恢复最重要的目标。

超过53%的组织认为,对于关键应用来说,RTO(恢复时间目标)应该小于1个小时,但实际上,超过50%的应用需要1~4小时来恢复。因此为了达到理想的可用性目标,我们还有一定的差距。

对于商业组织来说,拥有有效的应用保护和恢复能力,正在变得越来越重要。超过65%的大型组织,已经实施部署了混合云/多云的策略。而其中的31%,正在同时使用超过2个以上的公有云服务。企业不可能从每一个单独的基础设施服务商,或者云服务商那里分别采购它们自行定制的解决方案。

Portworx为Kubernetes提供数据保护

Portworx是基于Kubernetes和容器的原生方式构建的。我们创建了一系列的存储和数据管理解决方案,专门来解决企业在现代化IT架构中面临的挑战。

Portworx PX-DR产品的定位,是为了保护Kubernetes应用,以达到零数据损失的快速恢复,并且赋能团队可以快速的掌握使用,不需要过多深入到每一个容器化应用的技术细节。

为Kubernetes原生设计

容器化应用通常跨多个主机,运行在多个容器里。通过Pods和命名空间来运行。Portworx PX-DR按照原生Pods和命名空间构建的方式来运行,从而让我们可以在容器颗粒度和命名空间层面上来对应用进行保护。

通过保护Pod和整个命名空间,不论应用如何配置或者应用如何在集群上跨主机来运行,我们都可以容易的选择应用并进行保护。

虽然应用是复杂的,我们采用快照操作,就可以对应用进行保护。Portworx的数据保护解决方案,让我们可以在另一个Kubernetes集群上快速的恢复和重启应用,不论集群是位于什么样/什么位置的云服务之上。

通过保护应用、应用的配置、以及应用的数据,Portworx提供了真正的Kubernetes原生容灾恢复解决方案。

应用可感知

今天的容器化应用变的越来越复杂:展现技术、消息流、分析、数据存储,每种技术都由不同的社区来构建,并且需要不同的运维方法。

为了达到应用的扩展性和数据保护,我们要么严格限制我们所采用的技术的来源数量,这会降低我们的灵活性。或者我们采用有效的解决方案来原生化的处理各种复杂性问题,从而更快的推动数字化。

这意味着我们可以持续性的创新和部署新的应用,而不需要对每一个技术都有深入的了解。Portworx会帮助我们完成底层的集成。我们只需要制定我们的应用保护时间计划,来满足可用性需要。

跨多云/混合云环境下的一致性的、可靠的容灾恢复 

我们的应用并不是处于单一控制的环境中。即便我们仅仅使用单一的云服务提供商,我们也会跨区域来部署应用。当我们使用混合云/多云环境时,复杂度就进一步提升。

Portworx PX-DR是按Kubernetes原生的分布式方式构建的。能够交付零数据损失(零RPO)和快速恢复时间(低RTO)是保持系统稳健的重要能力。

当应用被部署在彼此高速连接的云平台上时,例如,由专线连接的不同区域的云服务,Portworx可以帮助我们达到零RPO和零RTO。这意味着不会有数据损失,并且在发生问题时,可以即时恢复。

如果应用部署采用传统配置方式,如跨不同地理位置的数据中心的部署,通过Portworx,我们可以在几秒至几分钟的时间内恢复应用,并且不会有数据损失。

大多数企业的数据保护目标是1小时内恢复应用11,使用Portworx PX-DR数据保护,可以让我们达到更加快速的恢复。

如果当我们正在使用的某个云服务发生错误后,而我们的应用依然在运行,我们的客户满意度会更高。

加拿大皇家银行RBC的成功案例

加拿大皇家银行RBC正在通过Red Hat OpenShift使用Kubernetes,但是无法达到可用性的要求。通过Portworx企业级数据管理平台和PX-DR,RBC达到了零RPO、以及小于2分钟的RPO指标。这意味着RBC可以在2分钟内在另一个数据中心恢复应用,而没有数据损失。

结论

我们的商业环境在快速演进,我们的竞争对手在快速追赶。在互联网时代,客户的体验是成功的关键,我们无法允许让客户不快的事情的发生。

错误时常会出现,服务中断时常会发生,云服务时常会宕机。我们需要一个强健、灵活和快速的恢复解决方案,来保证我们的应用能够持续性的满足客户的需要。

我们在Kubernetes上部署的容器化应用是我们的增长引擎,但是容器化应用与传统应用有很大的不同。需要有针对性的通过Kubernetes和容器的方式来对应用进行保护。而不是传统的数据保护方式。

为了让DevOps能够充分的发挥效能,如果每一个技术都需要专业的工程师来应对,会极大的增加我们的投入。我们的容灾恢复方案需要与这些技术事先集成,可感知应用,这样通用型的运维工程师就可以很好的处理问题。

混合云/多云架构变得普遍,我们不能允许云服务提供商的任何错误对我们的应用造成影响。不论我们选择什么样的基础架构服务商,都应确保我们应用的可用性。

下一步

Portworx已服务全球2000强企业超过5年。我们理解您的目标、您的难点。我们愿竭诚帮助您。

这里是PX-DR的介绍视频,欢迎观看。

https://v.qq.com/x/page/m30648ptszh.html

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址