华为云FusionInsight MRS容灾：大数据两地三中心的容灾也可以如此省心

背景介绍

随着数据湖技术从离线向实时的发展，数据湖在业务已逐渐从辅助决策向实时决策，实时干预甚至提前预防的方向发展，同时，随着国家把数据作为第五种生产要素，数据据价值在逐步提升，这样对海量数据湖的可靠性提出了新的要求。

首先，数据湖作为企业全量数据存储的地方，对数据的安全性有着至关重要的作用，如何保证湖内的数据在任何情况下，都不要出现丢失的情况，是越来越多的企业在思考的问题，同时，随着数据湖逐步补齐交互式查询，实时分析等能力，大量的分析师正逐步将日常的数据分析工作转移到数据湖中，在这种背景下，一旦出现数据湖无法对外提供服务或者是数据丢失，将会对企业产生重大影响。但另一方面，数据中心级的故障在全球不断出现，火灾、水灾等各种新闻不断涌现。同时，日常运维过程中的误操作，也是时时刻刻悬在头上的一把利剑，这种情况可能比机房起火更常见，但对数据的影响却也是致命的。

每一次有新闻报道这方面的事故时，相信很多大数据平台的运维人员都是心头一紧，如何确保数据湖系统的绝对可靠，成为越来越多企业关心的问题。

对于一个数据湖平台，常见的故障包括：

类型	故障场景
自然灾难	地震，火灾，水灾等重大灾难导致的机房级、城市级的故障，虽然出现概率低，但影响大，恢复周期长。
错误操作	运维人员无意或无意进行的某些会影响到整个局点数据安全的操作，如数据误删除，此类场景最为常见，对数据的影响也最为致命。
硬件故障	服务器、网络类的小范围故障，随着集群规模的增大，此类故障已成为常态。
数据湖一般作为大规模分布式系统，对以小范围硬件故障类一般都已在系统架构中有比较完善的考虑，本文不做详细描述。下面主要介绍的是重大灾难以及误操作场景下，MRS的高可用方案。

MRS灾备方案介绍

华为云MRS作为全球领先的数据湖平台，在可靠性方面已有比较完整的规划，为应用不同的故障场景，提供了以下三种方案：

数据备份：采用OBS或者备MRS集群来作为备份存储，将关键数据备份到OBS/HDFS中。
单集群跨AZ：采用多AZ方式建设单集群，通过副本放置策略（BPP）和YARN的任务调度机制的优化，确保单AZ故障时数据不丢失，关键业务不中断。
异地主备容灾：分别建设主、备两个MRS集群，配置主备容灾关系，主集群数据周期/实时自动同步到备集群上。主集群故障时，将业务倒换到备集群上，确保业务快速恢复。

下面将对以上三种方案进行详细描述：

MRS备份方案介绍：

备份方案，作为一种最基础的数据保护方案，具有成本低，方案简单的特点，特别是相比其它方案，在数据误删保护方面，具有独特的优势。但是，大数据业务的备份，也是十分有挑战的一项工作，主要体现在：

由于大数据平台的组件多，各类组件的备份方案也不统一，实施起来较为复杂，特别是有些场景，还要考虑组件间的数据一致性问题；
数据体量巨大，全量备份成本高，正因如此，很多大数据项目都没有采用备份方案。

华为云原生数据湖MRS，作为企业级的数据湖平台，具有简单易用的备份管理功能，支持对接多种备份存储方案。整体备份能力如下：

在组件上，支持了Manger、DBService、HDFS、YARN、HBase、Hive、ES、Redist、ClickHouse、IotDB等所有涉及数据的组件。同时MRS支持图形化的备份配置界面，用户只需要按需选择所需要备份的数据，设置好备份周期，系统将会自动周期进行备份，且会保证组件间数据关联的一致性，同时也支持手工一次性备份。

备份存储，MRS支持将数据备份到备MRS集群或OBS上，对于有条件采用OBS备份的场景，可优先采用OBS备份，对于无OBS的场景，可以采用备MRS集群进行备份，在此场景下，考虑到成本，备集群HDFS可以采用两副本。

以下是备份任务的主要管理界面：

创建备份任务时的策略选择：

备份任务管理：

总结：备份方案，由于其在应对数据丢失方面的优势，一般会作为基础的数据保护能力，特别是其全量数据的保存能力，可以应对数据误删除的场景。

MRS单集群跨AZ方案介绍

备份方案虽然可以解决数据可靠性的问题，但无法解决业务可靠性的问题，如果发生机房机的故障，虽然数据可以从备份系统中恢复，但这时的恢复周期会非常长，针对机房级的故障，如何同时解决业务和数据的可靠性，MRS提供了单集群跨AZ的方案，此方案的核心是利用大数据的分布式能力，将一个MRS集群部署到多个AZ中，对于存储层的HDFS，自动识别多AZ，并将多副本分布在多AZ中，确保任一AZ故障，都不会导致数据丢失。对于计算层，支持同一个队列跨AZ部署，并在一个AZ故障时，自动将任务在另一个AZ中重试，实现应用层无感知的AZ迁移。

MRS单集群跨AZ的部署架构如下：

如上图所示，同一个MRS集群会同时部署到3AZ中，对于存储层，通过块放置策略（BPP)对AZ的感知，将同一数据的3个副本，分别放置到3个AZ中，确保任一AZ故障，不会造成数据丢失，对于计算，通过将租户队列配置到多个AZ中，实现租户的应用，在一个AZ故障以后，仍然可以在另外一个AZ中执行。

在跨AZ的的场景下，还有一个比较大的挑战是AZ间的带宽，AZ间的带宽一般会比较有限，如何降低跨AZ部署的时候，对AZ间带宽的要求是一个不可忽视的问题，MRS的跨AZ方案中，为了降低对跨AZ带宽的诉求，MRS从以下三个方面，对跨AZ的流量进行了优化：

应用内的Shuffle流量：基于自研的Superior调度器，实现了正常场景下，计算任务不跨AZ，这样，将作务运行过程中的Shuffle流量全部控制在一个AZ内，减少了跨AZ的流量消耗。
业务数据读取流量：对于业务数据的读请求，通过基于数据本地化的调度，实现了数据从本AZ读取，将跨AZ的读流量降到接近于零。
业务数据写流量：HDFS上的写流量，会有大量的临时文件、日志类的写入流量，MRS实现了按目录配置是否需要跨AZ，实现了只针对真正的业务数据按跨AZ的策略进行副本放置。消减掉了临时文件、日志类的无用的跨AZ流量。
如下图所示，App1运行于跨AZ队列Queue1上，虽然此队列关联了AZ1和AZ2的计算资源，但MRS自研的Superior调度器通过AZ感知调度，不会将App1的计算任务同时分发到两个AZ上同时执行，而是仅在其中一个AZ上执行，

而当AZ1故障时，Superior会自动将此应用在AZ2上重跑，此时应用看到的任务状态并不会中断，也不需要进行失败重试的改造，实现了对应用的完全透明。

同时可以看出，无论App运行在哪个AZ上，对存储层的访问，都可以实现在本AZ内的闭环，并不需要跨AZ访问，保证性能的同时，也降低了对AZ间带宽的要求。

考虑到某些场景，没有足够的3AZ资源可用，MRS也支持2+1的部署模式，即：两个主AZ加一个仲裁AZ，仲裁AZ不用于实际的数据存储和业务计算，只需要几个工部署需要3AZ仲裁的组件，主要包括Zookeeper、HDFS JournalNode。

针对某此AZ间资源不均的场景，MRS也提供了灵活的配置能力，可以按需配置需要保护的业务（租户）和数据（表/目录），只要最小的AZ中的资源，满足需要跨AZ保护的业务和数据的资耗的诉求即可。不需要强制所有AZ的的资源完全一样。

MRS提供了简单易用的跨AZ部署配置界面：

集群开启跨AZ能力：

选择每个AZ的节点：

总结：

通过在计算、存储、集群管理方面的设计，业务可以方便灵活地部署出跨AZ的MRS集群，在业务看来，跨AZ的集群仍然是一个单集群，且在平台内部实现了AZ故障时的应用重试，应用层也不用进行失败重试类的改造，真正实现了对应用的完全透明的高可用能力。

MRS主备容灾方案介绍

虽然跨AZ的方案，可以解决机房级的故障，但由于单集群跨AZ方案对网络时延的要求，AZ间的距离一般只能在一个城市之内。为了应对城市级的故障场景，需要采用MRS主备容灾的方案，实现真正的高可用，这里需要说明的是，主备容灾方案，是一个端到端的方案，不是一个大数据平台层单方面能实现的，因此很多时候需要结合数据源、应用层的架构进行完整的设计，本文主要介绍大数据平台层的主备容灾方案。大数据平台层的主备复制方案如下图：