aix的存储高可用和容灾解决方案实现.docVIP

AIX 的存储高可用和容灾解决方案实现 本文介绍如何结合使用 AIX LVM Mirror 和 DS8000 Metro Mirror 技术，在存储架构层面实现存储高可用的同时满足企业同城容灾需求。本文同时就该方法最受人关注的容灾切换部分，分别就计划内和计划外两种场景进行详细讨论，并结合实验，充分论证了该方案的可行性。 基本技术介绍 AIX LVM Mirror 本地存储高可用解决方案介绍 Logical Volume Manager(LVM)是 AIX 上用于逻辑卷管理的软件。LVM 本身提供 Logical Volume (LV)数据在多个 Physical Volume (PV)之间做数据镜像的功能，以达到存储的本地高可用性。在 LVM Mirror 方案中写 I/O 与底层设备交互如下图所示。 图 1. LVM Mirror 方案架构 当服务器发出写 I/O 时，该 I/O 在 Parallel 模式下会同时并行发送到两台存储设备上。如上图中 Step 1, Step 2 和 Step 1’, Step 2’。只有当 Step 2 和 Step 2’都完成时，一个写 I/O 才会被服务器认为完成。 在该解决方案中，当底层任一存储，即 PV，出现故障时，LVM 会自动将停止该 PV 上所有的 I/O 活动，并将相应读写切换到剩下的正常 PV 上。整个切换过程在 LVM 层完成，所有 LV 在故障切换过程中状态保持在线，对应用层透明。切换时间最低在 15 秒左右，甚至更短。 同城容灾解决方案介绍 DS8000 Metro Mirror (MM)技术是一种满足 Recovery Point Object (RPO)为 0 的存储级同城容灾解决方案。该方案中，数据通过存储底层的 I/O 同步复制到容灾站点来达到相应的容灾目的。在 DS8000 MM 方案中写 I/O 与不同站点间 DS8000 存储交互如下图所示。 图 2. DS8000 MM 方案架构 当服务器发出写 I/O 时，首先该写 I/O 首先放往在生产站点主存储设备上；其次该写 I/O 由生产站点主存储发往灾备站点备存储；接着备存储发回写 I/O 完成信息；最后主存储向服务端发送写 I/O 完成信息。整个过程中，每个写 I/O 保证会在生产和容灾站点间同步完成。 在该解决方案中，当生产站点发生灾难时，会触发站点切换场景，即生产站点所有设备宕机，灾备站点服务器和存储在容灾端被启用并提供服务。由于容灾端存储的数据是通过同步复制技术产生，数据与生产保持一致，从而保证了 RPO 为 0。值得注意的时 DS8000 MM 该方案本身不提供生产站点的本地存储高可用保证。当本地存储发生故障且无法恢复时，最终需要将生产切换到容灾站点。整个过程一般为几个小时或更高。 AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案介绍 AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案是一种融合两种方案优点的存储高可用加容灾解决方案。该解决方案的基本架构图如下图所示。 图 3. AIX LVM Mirror 结合 DS8000 Metro Mirror 架构 AIX LVM Mirror 结合 DS8000 Metro Mirror 解决方案其优点是显而易见的：其为企业基础架构提供本地存储高可用保护的同时，也提供了存储级同城容灾的能力。 但是在本方案中，由于生产端服务器的 AIX LVM 的 LV Copy 存在两份，而容灾端只有一份，因此在容灾端的单份 Copy 对容灾切换的影响成为客户主要关注点，主要有以下几点： 容灾切换时影响：容灾端应用在单份 Copy 情况下其 LVM VG 和应用是否能正常拉起，以及相应 RTO 影响。 生产回切时影响：生产端 LVM Mirror 能否正常重新同步，及其对生产的性能影响。 整个操作流程复杂度：复杂度是否可控，是否会对运维团队带来额外负担。 对于以上问题我们将分计划内和计划外两种切换场景在第二章节进行详细讨论。 AIX LVM Mirror 结合 DS8000 Metro Mirror 容灾切换和恢复步骤 一般容灾切换场景可分为计划内和计划外两种，以下章节分别就该两种场景进行讨论。所有讨论均基于实际测试结果，测试环境如下: 硬件为 Power 570，4 核 CPU，16G 内存。 操作系统 AIX 6100-05 + PowerHA 6.1.0.9，双机配置为 Active-Standby 方式。 应用为 Oracle 10g。（这里以 Oracle 应用为例，本方案也适用于其他应用场景。） 整个测试数据容量大小约为 1 TB。 计划内切换和恢复步骤 计划内切换特点在于容灾站点切换以