我们面临着不断地需要实施和部署新的软件应用、发展新的商业模式、以及吸引新的客户。通过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的介绍视频，欢迎观看。
