你和云的距离只缺数据库服务器的一场大火

{"value":"### **前言**\n【一切都会运行在云端】云时代早已来临，现在越来越多的企业从自己维护基础设施转移到公有（或者私有）云上， 带来的好处也是无需赘述的，极大降低了 IaaS 层的运维成本，对于数据库层面来说的，以往需要很强的 DBA 背景才能搞定弹性扩容高可用什么的高级动作，现在大多数云服务基本都或多或少提供了类似的服务。但是，这个但是就重要了，谁也不知道“意外”哪一天会到来，本地服务器做的再好的架构也抗不住一场“大火”，让我们看看Amazon 是怎么通过一代代的最佳实践，将自己的容灾备份能力变的越来越可靠；\n### **为什么我们要做“防火”**\n企业的数据库就好比人的大脑的记忆系统，没有了数据库就没有了记忆系统。但是数据的安全性不是万无一失的，随着企业信息化的发展，对于核心数据的安全需求也就越来越大，数据容灾备份就是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。\n### **MySQ L如何实现 Crash Recoverable Transaction**\n对于一个简单的数据库模型，数据库运行在单个服务器上，在硬盘上存储了数据的记录，或许是以 B-Tree 方式构建的索引。所以有一些 data page 用来存放数据库的数据，其中一个存放了X的记录，另一个存放了Y的记录。每一个 data page 通常会存储大量的记录，而 X 和 Y 的记录是page 中的一些 bit 位。在硬盘中，除了有数据之外，还有一个预写式日志（Write-Ahead Log，简称为 WAL）。预写式日志对于系统的容错性至关重要。在服务器内部，有数据库软件，通常数据库会对最近从磁盘读取的 page 有缓存。 \n当你在执行一个事务内的各个操作时，例如执行 X=X+10 的操作时，数据库会从硬盘中读取持有X的记录，给数据加10。但是在事务提交之前，数据的修改还只在本地的缓存中，并没有写入到硬盘。我们现在还不想向硬盘写入数据，因为这样可能会暴露一个不完整的事务。\n为了让数据库在故障恢复之后，还能够提供同样的数据，在允许数据库软件修改硬盘中真实的 data page 之前，数据库软件需要先在 WAL 中添加 Log 条目来描述事务。所以在提交事务之前，数据库需要先在 WAL 中写入完整的 Log 条目，来描述所有有关数据库的修改，并且这些 Log 是写入磁盘的。\n如果数据库成功的将事务对应的操作和 commit 日志写入到磁盘中，数据库可以回复给客户端说，事务已经提交了。而这时，客户端也可以确认事务是永久可见的。\n接下来有两种情况。\n如果数据库没有崩溃，最终数据库会将 cache 中的数值写入到磁盘对应的位置。所以数据库写磁盘是一个 lazy 操作，它会对更新进行累积，每一次写磁盘可能包含了很多个更新操作。这种累积更新可以提升操作的速度。\n如果数据库在将 cache 中的数值写入到磁盘之前就崩溃了，这样磁盘中的 page 仍然是旧的数值。当数据库重启时，恢复软件会扫描 WAL 日志，发现对应事务的 Log，并发现事务的 commit 记录，那么恢复软件会将新的数值写入到磁盘中。这被称为 redo，它会重新执行事务中的写操作。\n这就是事务型数据库的工作原理的简单描述，同时这也是一个极度精简的 MySQL 数据库工作方式的介绍，MySQL 基本以这种方式实现了故障可恢复事务;\n### **关系型数据库（[Amazon RDS](https://aws.amazon.com/cn/rds/?trk=cndc-detail)）的容灾备份** \n在 MySQL 基础上，结合 Amazon 自己的基础设施，Amazon 为其云用户开发了改进版的数据库，叫做 RDS（Relational Database Service）。RDS 是第一次尝试将数据库在多个 AZ 之间做复制，这样就算整个数据中心挂了，你还是可以从另一个 AZ 重新获得数据而不丢失任何写操作。\n对于 RDS 来说，有且仅有一个E C2实例作为数据库。这个数据库将它的 data page 和 WAL Log 存储在 EBS，而不是对应服务器的本地硬盘。当数据库执行了写 Log 或者写 page 操作时，这些写请求实际上通过网络发送到了 EBS 服务器。所有这些服务器都在一个AZ中。\n每一次数据库软件执行一个写操作，Amazon 会自动的，对数据库无感知的，将写操作拷贝发送到另一个数据中心的 AZ 中,\n在 RDS 的架构中，每一次写操作，例如数据库追加日志或者写磁盘的 page，数据除了发送给 AZ1的两个 EBS 副本之外，还需要通过网络发送到位于 AZ2的副数据库。副数据库接下来会将数据再发送给 AZ2的两个独立的 EBS 副本。之后，AZ2的副数据库会将写入成功的回复返回给 AZ1的主数据库，主数据库看到这个回复之后，才会认为写操作完成了。\nRDS 这种架构提供了更好的容错性。因为现在在一个其他的 AZ中，有了数据库的一份完整的实时的拷贝。这个拷贝可以看到所有最新的写请求。即使 AZ1发生火灾都烧掉了，你可以在 AZ2的一个新的实例中继续运行数据库，而不丢失任何数据。\n### **Aurora 数据分片（Protection Group）** \n为了能支持超过10TB 数据的大型数据库。Amazon 的做法是将数据库的数据，分割存储到多组存储服务器上，每一组都是6个副本，分割出来的每一份数据是10GB。所以，如果一个数据库需要20GB的数据，那么这个数据库会使用2个PG（Protection Group），其中一半的10GB数据在一个PG中，包含了6个存储服务器作为副本，另一半的10GB数据存储在另一个PG中，这个PG可能包含了不同的6个存储服务器作为副本。\n因为 Amazon 运行了大量的存储服务器，这些服务器一起被所有的 Aurora 用户所使用。两组 PG 可能使用相同的6个存储服务器，但是通常来说是完全不同的两组存储服务器。随着数据库变大，我们可以有更多的 Protection Group。这里有一件有意思的事情，你可以将磁盘中的 data page 分割到多个独立的PG中，比如说奇数号的 page 存在 PG1，偶数号的 page 存在PG2。如果可以根据 data page 做 sharding，那是极好的。\nSharding 之后，Log 该如何处理就不是那么直观了。如果有多个 Protection Group，该如何分割 Log 呢？答案是，当 Aurora 需要发送一个 Log 条目时，它会查看 Log 所修改的数据，并找到存储了这个数据的 Protection Group，并把 Log 条目只发送给这个 Protection Group 对应的6个存储服务器。这意味着，每个 Protection Group 只存储了部分 data page 和所有与这些 data page 关联的 Log 条目。所以每个 Protection Group 存储了所有 data pag 的一个子集，以及这些 data page 相关的 Log 条目。\n如果其中一个存储服务器挂了，我们期望尽可能快的用一个新的副本替代它。因为如果4个副本挂了，我们将不再拥有 Read Quorum，我们也因此不能创建一个新的副本。所以我们想要在一个副本挂了以后，尽可能快的生成一个新的副本。表面上看，每个存储服务器存放了某个数据库的某个某个 Protection Group 对应的10GB数据，但实际上每个存储服务器可能有1-2块几TB的磁盘，上面存储了属于数百个 Aurora 实例的10GB数据块。所以在存储服务器上，可能总共会有10TB的数据，当它故障时，它带走的不仅是一个数据库的10GB数据，同时也带走了其他数百个数据库的10GB数据。所以生成的新副本，不是仅仅要恢复一个数据库的10GB数据，而是要恢复存储在原来服务器上的整个10TB的数据。我们来做一个算术，如果网卡是10Gb/S，通过网络传输10TB的数据需要8000秒。这个时间太长了，我们不想只是坐在那里等着传输。所以我们不想要有这样一种重建副本的策略：找到另一台存储服务器，通过网络拷贝上面所有的内容到新的副本中。我们需要的是一种快的多的策略。\nAurora 实际使用的策略是，对于一个特定的存储服务器，它存储了许多 Protection Group 对应的10GB的数据块。对于 Protection Group A，它的其他副本是5个服务器。或许这个存储服务器还为 Protection Group B 保存了数据，但是B的其他副本存在于与A没有交集的其他5个服务器中，\n假设有足够多的服务器，这里的服务器大概率不会有重合，同时假设我们有足够的带宽，现在我们可以以100的并发，并行的拷贝1TB 的数据，这只需要10秒左右。如果只在两个服务器之间拷贝，正常拷贝1TB 数据需要1000秒左右。\n这就是 Aurora 使用的副本恢复策略，它意味着，如果一个服务器挂了，它可以并行的，快速的在数百台服务器上恢复。如果大量的服务器挂了，可能不能正常工作，但是如果只有一个服务器挂了，Aurora 可以非常快的重新生成副本。\n### **总结**\n#### **传统企业上云，灾备先行**\n数据显示，目前已有超过千万个数据库迁移到各大云平台上。到2023年，全球3/4的数据库都将运行在云上。传统企业上云已势不可挡，有数据显示，中国企业的上云意愿高达84%。曾经在很长一段时间内，企业上云最主要的障碍就是安全性。安全涉及的范围非常广泛，灾备就是其中重要的一环。\n#### **云灾备的特点**\n结合云计算、云存储的特性，云灾备具备多方面的优势∶\nA.节约-投入低\n无须一次性采购高额的硬件投入，也无须面对因为采购硬件所带来的设备寿命、利旧、再采购等硬件生命周期管理问题。\nB.高效-资源服务化\n结合了云计算的特点提供了多租户平台、弹性扩容的功能，实现了云灾备资源的服务化。\nC.部署灵活-敏捷运维\n部署简单、运维方便、随时演练，运维人员可专注于整个IT系统的分层灾备的设计和规划上，并利用弹性的云灾备资源进行分层、分阶段部署。\nD.多系统-适应混合IT架构\n对于物理机、虚拟机、云主机，本地数据库、云数据库，长期并存的混合IT架构，可以通过云灾备进行集中管理，全面保护。\nE.安全-继承传统灾备技术优势\n部分云灾备解决方案继承了传统灾备解决方案在数据一致性、业务连续性和数据安全性方面的特点。\n#### **中国在灾备市场发展趋势预测**\nA.云灾备将成为主流\n云存储的发展将进一步刺激云灾备的发展。有预测显示，目前全球数据量以每两年翻一番的速度增长，到2023年全世界需要管理的数据将达到1000ZB（1ZB约为1000亿TB）。\n云计算、大数据等新技术和应用为该领域提供了新的发展机遇，云计算的核心思想是将大量资源统一管理和调度，向用户提供按需服务。基于云计算技术，灾难恢复系统成本更低，恢复速度也更快。\nB.灾备将成为信息安全工作的重中之重\n信息安全是国家安全的重要组成部分，已经上升到政治安全、经济安全、领土安全等并驾齐驱的战略高度，金融、能源、电力、通信、交通等各关键领域、关键部门的关键信息基础设施是经济社会运行的神经中枢，是信息安全的重中之重，也是可能遭到重点攻击的目标，因此相关的灾备系统一定要尽快落实到位，作为数据安全的最后一道防线，灾备工作需要肩负的责任重大。云安全方面，需要不断提升对云计算核心软硬件的自主研发能力;提高企业自身信息安全防护意识，灾难恢复是信息安全保障的最后一道防线，当数据丧失可用性和可控性时，仍可通过灾难恢复技术挽救回来。\nC.灾备不再是一个业务而是一个生态\n以往单一的灾备技术已经发展成一个集信息存储、信息传输、数据安全等多个方面于一体的综合性IT技术，同时，不同的灾备技术也必须依赖更高维度的生态系统管理予以有效整合。\n灾备安全生态（DR Total Solution Ecological，DR-TSE）理念是以更高的维度建立一个完善的灾备体系，以生态的角度去看待原本点状的灾备部署，充分发挥每一个模块的效用，使任何一种灾备方式都不仅仅是针对某一个数据、某一个应用进行的，而是涵盖在整个业务逻辑中进行，从而实现线上、线下的使用快速方便，软件、硬件、SaaS的交付模式齐全完备，容错、容灾、备份灵活共存，共享、迁移和演练随时随地进行，本地、异地、云端灾备式任意构建，数据库、文件、流媒体全面支持，各类国产、进口、云上、云下单操作系统无缝兼容，由此形成合力，真正做到灾备及高效的业务连续性管理。全生态灾备技术将大受欢迎!","render":"<h3><a id=\\"_0\\"></a><strong>前言</strong></h3>\\n<p>【一切都会运行在云端】云时代早已来临，现在越来越多的企业从自己维护基础设施转移到公有（或者私有）云上， 带来的好处也是无需赘述的，极大降低了 IaaS 层的运维成本，对于数据库层面来说的，以往需要很强的 DBA 背景才能搞定弹性扩容高可用什么的高级动作，现在大多数云服务基本都或多或少提供了类似的服务。但是，这个但是就重要了，谁也不知道“意外”哪一天会到来，本地服务器做的再好的架构也抗不住一场“大火”，让我们看看Amazon 是怎么通过一代代的最佳实践，将自己的容灾备份能力变的越来越可靠；</p>\n<h3><a id=\\"_2\\"></a><strong>为什么我们要做“防火”</strong></h3>\\n<p>企业的数据库就好比人的大脑的记忆系统，没有了数据库就没有了记忆系统。但是数据的安全性不是万无一失的，随着企业信息化的发展，对于核心数据的安全需求也就越来越大，数据容灾备份就是为了在遭遇灾害时能保证信息系统能正常运行，帮助企业实现业务连续性的目标，备份是为了应对灾难来临时造成的数据丢失问题。</p>\n<h3><a id=\\"MySQ_L_Crash_Recoverable_Transaction_4\\"></a><strong>MySQ L如何实现 Crash Recoverable Transaction</strong></h3>\\n<p>对于一个简单的数据库模型，数据库运行在单个服务器上，在硬盘上存储了数据的记录，或许是以 B-Tree 方式构建的索引。所以有一些 data page 用来存放数据库的数据，其中一个存放了X的记录，另一个存放了Y的记录。每一个 data page 通常会存储大量的记录，而 X 和 Y 的记录是page 中的一些 bit 位。在硬盘中，除了有数据之外，还有一个预写式日志（Write-Ahead Log，简称为 WAL）。预写式日志对于系统的容错性至关重要。在服务器内部，有数据库软件，通常数据库会对最近从磁盘读取的 page 有缓存。<br />\\n当你在执行一个事务内的各个操作时，例如执行 X=X+10 的操作时，数据库会从硬盘中读取持有X的记录，给数据加10。但是在事务提交之前，数据的修改还只在本地的缓存中，并没有写入到硬盘。我们现在还不想向硬盘写入数据，因为这样可能会暴露一个不完整的事务。<br />\\n为了让数据库在故障恢复之后，还能够提供同样的数据，在允许数据库软件修改硬盘中真实的 data page 之前，数据库软件需要先在 WAL 中添加 Log 条目来描述事务。所以在提交事务之前，数据库需要先在 WAL 中写入完整的 Log 条目，来描述所有有关数据库的修改，并且这些 Log 是写入磁盘的。<br />\\n如果数据库成功的将事务对应的操作和 commit 日志写入到磁盘中，数据库可以回复给客户端说，事务已经提交了。而这时，客户端也可以确认事务是永久可见的。<br />\\n接下来有两种情况。<br />\\n如果数据库没有崩溃，最终数据库会将 cache 中的数值写入到磁盘对应的位置。所以数据库写磁盘是一个 lazy 操作，它会对更新进行累积，每一次写磁盘可能包含了很多个更新操作。这种累积更新可以提升操作的速度。<br />\\n如果数据库在将 cache 中的数值写入到磁盘之前就崩溃了，这样磁盘中的 page 仍然是旧的数值。当数据库重启时，恢复软件会扫描 WAL 日志，发现对应事务的 Log，并发现事务的 commit 记录，那么恢复软件会将新的数值写入到磁盘中。这被称为 redo，它会重新执行事务中的写操作。<br />\\n这就是事务型数据库的工作原理的简单描述，同时这也是一个极度精简的 MySQL 数据库工作方式的介绍，MySQL 基本以这种方式实现了故障可恢复事务;</p>\n<h3><a id=\\"Amazon_RDS_13\\"></a><strong>关系型数据库（Amazon RDS）的容灾备份</strong></h3>\\n<p>在 MySQL 基础上，结合 Amazon 自己的基础设施，Amazon 为其云用户开发了改进版的数据库，叫做 RDS（Relational Database Service）。RDS 是第一次尝试将数据库在多个 AZ 之间做复制，这样就算整个数据中心挂了，你还是可以从另一个 AZ 重新获得数据而不丢失任何写操作。<br />\\n对于 RDS 来说，有且仅有一个E C2实例作为数据库。这个数据库将它的 data page 和 WAL Log 存储在 EBS，而不是对应服务器的本地硬盘。当数据库执行了写 Log 或者写 page 操作时，这些写请求实际上通过网络发送到了 EBS 服务器。所有这些服务器都在一个AZ中。<br />\\n每一次数据库软件执行一个写操作，Amazon 会自动的，对数据库无感知的，将写操作拷贝发送到另一个数据中心的 AZ 中,<br />\\n在 RDS 的架构中，每一次写操作，例如数据库追加日志或者写磁盘的 page，数据除了发送给 AZ1的两个 EBS 副本之外，还需要通过网络发送到位于 AZ2的副数据库。副数据库接下来会将数据再发送给 AZ2的两个独立的 EBS 副本。之后，AZ2的副数据库会将写入成功的回复返回给 AZ1的主数据库，主数据库看到这个回复之后，才会认为写操作完成了。<br />\\nRDS 这种架构提供了更好的容错性。因为现在在一个其他的 AZ中，有了数据库的一份完整的实时的拷贝。这个拷贝可以看到所有最新的写请求。即使 AZ1发生火灾都烧掉了，你可以在 AZ2的一个新的实例中继续运行数据库，而不丢失任何数据。</p>\n<h3><a id=\\"Aurora_Protection_Group_19\\"></a><strong>Aurora 数据分片（Protection Group）</strong></h3>\\n<p>为了能支持超过10TB 数据的大型数据库。Amazon 的做法是将数据库的数据，分割存储到多组存储服务器上，每一组都是6个副本，分割出来的每一份数据是10GB。所以，如果一个数据库需要20GB的数据，那么这个数据库会使用2个PG（Protection Group），其中一半的10GB数据在一个PG中，包含了6个存储服务器作为副本，另一半的10GB数据存储在另一个PG中，这个PG可能包含了不同的6个存储服务器作为副本。<br />\\n因为 Amazon 运行了大量的存储服务器，这些服务器一起被所有的 Aurora 用户所使用。两组 PG 可能使用相同的6个存储服务器，但是通常来说是完全不同的两组存储服务器。随着数据库变大，我们可以有更多的 Protection Group。这里有一件有意思的事情，你可以将磁盘中的 data page 分割到多个独立的PG中，比如说奇数号的 page 存在 PG1，偶数号的 page 存在PG2。如果可以根据 data page 做 sharding，那是极好的。<br />\\nSharding 之后，Log 该如何处理就不是那么直观了。如果有多个 Protection Group，该如何分割 Log 呢？答案是，当 Aurora 需要发送一个 Log 条目时，它会查看 Log 所修改的数据，并找到存储了这个数据的 Protection Group，并把 Log 条目只发送给这个 Protection Group 对应的6个存储服务器。这意味着，每个 Protection Group 只存储了部分 data page 和所有与这些 data page 关联的 Log 条目。所以每个 Protection Group 存储了所有 data pag 的一个子集，以及这些 data page 相关的 Log 条目。<br />\\n如果其中一个存储服务器挂了，我们期望尽可能快的用一个新的副本替代它。因为如果4个副本挂了，我们将不再拥有 Read Quorum，我们也因此不能创建一个新的副本。所以我们想要在一个副本挂了以后，尽可能快的生成一个新的副本。表面上看，每个存储服务器存放了某个数据库的某个某个 Protection Group 对应的10GB数据，但实际上每个存储服务器可能有1-2块几TB的磁盘，上面存储了属于数百个 Aurora 实例的10GB数据块。所以在存储服务器上，可能总共会有10TB的数据，当它故障时，它带走的不仅是一个数据库的10GB数据，同时也带走了其他数百个数据库的10GB数据。所以生成的新副本，不是仅仅要恢复一个数据库的10GB数据，而是要恢复存储在原来服务器上的整个10TB的数据。我们来做一个算术，如果网卡是10Gb/S，通过网络传输10TB的数据需要8000秒。这个时间太长了，我们不想只是坐在那里等着传输。所以我们不想要有这样一种重建副本的策略：找到另一台存储服务器，通过网络拷贝上面所有的内容到新的副本中。我们需要的是一种快的多的策略。<br />\\nAurora 实际使用的策略是，对于一个特定的存储服务器，它存储了许多 Protection Group 对应的10GB的数据块。对于 Protection Group A，它的其他副本是5个服务器。或许这个存储服务器还为 Protection Group B 保存了数据，但是B的其他副本存在于与A没有交集的其他5个服务器中，<br />\\n假设有足够多的服务器，这里的服务器大概率不会有重合，同时假设我们有足够的带宽，现在我们可以以100的并发，并行的拷贝1TB 的数据，这只需要10秒左右。如果只在两个服务器之间拷贝，正常拷贝1TB 数据需要1000秒左右。<br />\\n这就是 Aurora 使用的副本恢复策略，它意味着，如果一个服务器挂了，它可以并行的，快速的在数百台服务器上恢复。如果大量的服务器挂了，可能不能正常工作，但是如果只有一个服务器挂了，Aurora 可以非常快的重新生成副本。</p>\n<h3><a id=\\"_27\\"></a><strong>总结</strong></h3>\\n<h4><a id=\\"_28\\"></a><strong>传统企业上云，灾备先行</strong></h4>\\n<p>数据显示，目前已有超过千万个数据库迁移到各大云平台上。到2023年，全球3/4的数据库都将运行在云上。传统企业上云已势不可挡，有数据显示，中国企业的上云意愿高达84%。曾经在很长一段时间内，企业上云最主要的障碍就是安全性。安全涉及的范围非常广泛，灾备就是其中重要的一环。</p>\n<h4><a id=\\"_30\\"></a><strong>云灾备的特点</strong></h4>\\n<p>结合云计算、云存储的特性，云灾备具备多方面的优势∶<br />\\nA.节约-投入低<br />\\n无须一次性采购高额的硬件投入，也无须面对因为采购硬件所带来的设备寿命、利旧、再采购等硬件生命周期管理问题。<br />\\nB.高效-资源服务化<br />\\n结合了云计算的特点提供了多租户平台、弹性扩容的功能，实现了云灾备资源的服务化。<br />\\nC.部署灵活-敏捷运维<br />\\n部署简单、运维方便、随时演练，运维人员可专注于整个IT系统的分层灾备的设计和规划上，并利用弹性的云灾备资源进行分层、分阶段部署。<br />\\nD.多系统-适应混合IT架构<br />\\n对于物理机、虚拟机、云主机，本地数据库、云数据库，长期并存的混合IT架构，可以通过云灾备进行集中管理，全面保护。<br />\\nE.安全-继承传统灾备技术优势<br />\\n部分云灾备解决方案继承了传统灾备解决方案在数据一致性、业务连续性和数据安全性方面的特点。</p>\n<h4><a id=\\"_42\\"></a><strong>中国在灾备市场发展趋势预测</strong></h4>\\n<p>A.云灾备将成为主流<br />\\n云存储的发展将进一步刺激云灾备的发展。有预测显示，目前全球数据量以每两年翻一番的速度增长，到2023年全世界需要管理的数据将达到1000ZB（1ZB约为1000亿TB）。<br />\\n云计算、大数据等新技术和应用为该领域提供了新的发展机遇，云计算的核心思想是将大量资源统一管理和调度，向用户提供按需服务。基于云计算技术，灾难恢复系统成本更低，恢复速度也更快。<br />\\nB.灾备将成为信息安全工作的重中之重<br />\\n信息安全是国家安全的重要组成部分，已经上升到政治安全、经济安全、领土安全等并驾齐驱的战略高度，金融、能源、电力、通信、交通等各关键领域、关键部门的关键信息基础设施是经济社会运行的神经中枢，是信息安全的重中之重，也是可能遭到重点攻击的目标，因此相关的灾备系统一定要尽快落实到位，作为数据安全的最后一道防线，灾备工作需要肩负的责任重大。云安全方面，需要不断提升对云计算核心软硬件的自主研发能力;提高企业自身信息安全防护意识，灾难恢复是信息安全保障的最后一道防线，当数据丧失可用性和可控性时，仍可通过灾难恢复技术挽救回来。<br />\\nC.灾备不再是一个业务而是一个生态<br />\\n以往单一的灾备技术已经发展成一个集信息存储、信息传输、数据安全等多个方面于一体的综合性IT技术，同时，不同的灾备技术也必须依赖更高维度的生态系统管理予以有效整合。<br />\\n灾备安全生态（DR Total Solution Ecological，DR-TSE）理念是以更高的维度建立一个完善的灾备体系，以生态的角度去看待原本点状的灾备部署，充分发挥每一个模块的效用，使任何一种灾备方式都不仅仅是针对某一个数据、某一个应用进行的，而是涵盖在整个业务逻辑中进行，从而实现线上、线下的使用快速方便，软件、硬件、SaaS的交付模式齐全完备，容错、容灾、备份灵活共存，共享、迁移和演练随时随地进行，本地、异地、云端灾备式任意构建，数据库、文件、流媒体全面支持，各类国产、进口、云上、云下单操作系统无缝兼容，由此形成合力，真正做到灾备及高效的业务连续性管理。全生态灾备技术将大受欢迎!</p>\n"}