主流存储双活架构设计读写性能对比分析.docx

? ? ? ? ? ? ? 主流存储双活架构设计读写性能对比分析 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?  目 录 TOC \o 1-3 \h \z \u 主流存储双活架构设计读写性能对比分析 1 一、华为 HyperMetro 3 二、 EMC VPLEX 8 三、 IBM SVC 10 四、 HDS GAD 16 五、 NetApp MetroCluster 20  【摘要】对华为 HyperMetro 、 EMC Vplex 、 IBM SVC 、 HDS GAD 和 NetApp MetroCluster 等五个厂商存储双活方案的特点、仲裁需求、仲裁机制和两地三中心扩展方案进行了详细的解析。在本篇文章中，作者将从另一个角度，也是存储双活方案的另一大关键点 读写性能入手，剖析这五种存储跨中心双活方案的 I/O 读写流程和对业务主机带来的性能影响。 性能影响问题是存储双活方案的突出问题，因为双活系统在写入数据时，会写两次数据，尤其是通过复制功能写到远端存储的过程，传输链路的性能也会影响整体性能。因此，存储双活不可避免要遇到性能问题，这也是各大厂商存储双活方案标明最大支持 RTT 或者站点间距的原因之一。相比单存储直接提供读写来说，存储双活一定会增加读写响应时间，更别说存储还是跨两个不同数据中心的，随着距离的增加，理论上每增加 100KM ，会增加 1MS 的 RTT （往返延迟时间），通常单个 I/O 总耗时在 1-3MS 左右，就会认为单个存储 I/O 时延处于比较高性能的模式（最大支持的 IOPS 也是存储选型的重要考虑因素），如果加上其他因素，如“数据头处理”和“并发”， 1MS 的“理论”时延增加的影响会成倍增加，将原本处于高性能模式的 I/O 响应时间拉高，对应用或者数据库来说，“变慢”了。所以存储双活的初衷是只是为了高可用性和提高总体并发、吞吐量，并不是为了降低读写响应时间。然而，我们在选型存储双活方案时，依旧需要考虑如何尽量降低双活的存储所带来的性能降低影响，哪种方案会带来较小的性能影响。因此，笔者现就目前国内主流的五种存储双活方案在双活性能上的特点进行解析。 一、华为 HyperMetro 1 、读 I/O ：针对数据读场景， 华为 HyperMetro 方案架构下， 双活数据中心的业务主机只需要读本数据中心对应的双活存储阵列即可，如下图所示，这样可以有效避免主机跨数据中心读取数据，提升整体读 I/O 访问性能。 2 、写 I/O ：针对数据写场景，业务主机直接写本数据中心对应的双活存储阵列，避免主机跨数据中心转发数据（在转发写模式下，区分主从 LUN ，从 LUN 的写 I/O 将被控制器转发到主 LUN 的控制器处理写 I/O ，并将数据回同步至从 LUN ），充分利用 HyperMetro AA 双活能力，如下图左所示， AA 集群的每个控制器都能够接收写 I/O ，由本地控制器处理本地主机的写 I/O 请求，减少跨数据中心的转发次数，提升方案整体性能。数据写 I/O 过程如下图右所示： 假如数据中心 A 的存储阵列收到写 I/O ，写 I/O 处理流程如下： （ 1 ）申请写权限和记录写日志：数据中心 A 存储阵列收到主机写请求，先申请双活 Pair 的写权限。获得写权限后，双活 Pair 将该请求记录写日志（保证断点续传）。日志中只记录地址信息，不记录具体的写数据内容。该日志采用具有掉电保护能力的内存空间记录以获得良好的性能。 （ 2 ）执行双写：将该请求拷贝两份分别写入本地 LUN 和远端 LUN 的 Cache 。 （ 3 ）双写结果处理：等待两端 LUN 的写处理结果都返回。 （ 4 ）响应主机：双活 Pair 返回主机写 I/O 操作完成，完成一次写 I/O 周期。 从整个写 I/O 流程可以看出， HyperMetro 为了保证两个数据中心存储的数据实时一致，写操作都需要等待两端存储写成功之后再返回主机“写成功”。双活 I/O 性能因为实时双写导致了一定的时延增加，该写 I/O 流程相较于本地写 I/O 而言，额外增加了以下四个时延点。 （1） 写权限申请时，等待分布式锁产生的时延； （2） DCL 机制（数据变化记录）产生的时延； （ 3 ）跨站点将写 I/O 拷贝至远端 LUN Cache ； （ 4 ）远端 LUN Cache 收到写 I/O 后，将处理结果返回至本地。 这四个时延点中最主要的还是 3 和 4 中组成的 1 倍跨站点往返时延（ RTT ），此外，华为 HyperMetro 设计了一系列 I/O 性能优化方案，以减小对写时延的影响，提升整体双活的业务性能。 （ 1 ）数据零拷贝：在双活