软件定义存储，当下存储行业最火热的话题，没有之一。从最开始的软件定义数据中心，到软件定义网络与网络功能虚拟化(SDN和NFV)，这场浪潮最终烧到了数据中心最核心也是最复杂的组成部分——存储。于是，软件定义存储的理念随之而来。
在这一理念下，软件应当在企业存储系统中发挥重要的作用，它可以建立、管理、控制和协调存储资源，而不仅仅是存储系统的附属品或是边缘。
与此同时，有一个经久不衰的话题持续存在，那就是“双活”。作为保障业务连续性最坚实的基础，越来越多的企业开始付诸行动，正如某业内媒体所撰写的那样：“2014年，一个最显著的变化是，双活数据中心跨越了概念炒作的阶段，被很多企业用户所接受。”
存储系统的双活解决方案长期以来就是数据中心双活架构中的重点，这其中的原因不仅是因为存储系统中存储了企业最核心的生产数据，是“万万马虎不得”的核心系统，更因为与服务器(主机端)双活、应用程序双活(如Oracle RAC)相比，存储系统的双活不仅架构复杂、实施复杂，而且往往存在这样或那样的问题，
在“临门一脚”的时候，往往“活不过来”。
但即便是这样，存储系统的双活解决方案仍然在企业客户的数据中心遍地开花，可是，许多企业客户发现，在软件定义存储的大思路之下，数据中心内的存储双活方案，却成了软件定义存储的拦路虎、挡路石。
“嗨!我们还能不能好好的在一起玩耍了?”软件定义存储对存储双活说到。
存储双活 阻碍软件定义存储的发展?
软件定义存储和存储双活，看起来是八竿子打不着的事情，这两者之间怎么就产生了互相影响?凭什么说“(某些)存储双活解决方案，阻碍了软件定义存储的发展”?这事儿还要从业界主流的几种存储双活架构说起。
存储双活的架构设计，从不同的供应商的产品特点出发，大致可以归纳为几类：主机卷镜像、虚拟化存储网关、外置双活存储网关和存储内嵌双活+CDP等几种架构，其中绝大多数存储双活选择，由于其架构设计，在实现存储双活后，主机端与存储(功能)端被人为的分割开来，从而无法利用阵列本身软件，软件定义存储也就无从谈起了。
为什么会发生这样的事情呢?还要从其中几种架构的设计思路说起。
主机卷镜像的方式是早期存储双活方案选择较多的方式，企业客户通过采购主机卷镜像软件，保证数据从主存储镜像到备存储，这一方案不依赖于具体的存储品牌，支持存储双活，但由于卷镜像软件只将存储系统作为一个“硬盘池”来使用，无法利用存储阵列本身的软件。
除此以外，这一方案还存在额外采购镜像软件安装在所有主机端所造成的成本和消耗主机资源、存储系统/主机操作系统/虚拟化平台多平台兼容性等问题。
更进一步，业内一些存储厂商提出了虚拟化网关的存储双活解决方案，这一方案利用两层SAN交换机内的存储网关，将后端存储进行虚拟化，变成虚拟化资源池来使用其容量，将主机端的IO通过SAN交换机分发给两套存储系统，从而达到存储“双活”的目的——在这一架构中，存储系统只是被虚拟化的资源池，同样无法利用阵列本身的软件。
但更为关键的是，在付出了额外购买存储网关的成本、接受了新增网关层可能存在的性能瓶颈问题以及网关往往不能跨代混用等问题之后，虚拟化存储网关的存储双活却并不能够真正支持存储双活——以x86服务器为基础的虚拟化存储网关双活控制器集群，双活的只是网关内的控制器，而不是虚拟化存储网关。
基于对虚拟化存储网关进一步优化，外置双活存储网关架构被设计出来，它采用外置双活存储网关，在采购至少两对(四个)网关的前提下，这一方案确实可以提供行业内可靠性几近最佳的存储双活支持，但是，由于存储系统仍然是依靠存储网关实现数据的分配和系统的利用，它仍然无法利用阵列本身的软件。
在这一方案中，决不可忽略的是成本问题。相对于之前谈到的两个方案，由于架构设计的问题，每对网关对应一套存储系统，这意味着必须采购两对也就是四个外置存储网关，“四引擎，八个控制器”的采购成本，几乎是此前两个方案的两倍之多。
传统的三种双活方式，不仅存在架构复杂、阵列软件不能复用等问题，且只对物理故障有效。
那么，有没有什么办法，既能够保证存储双活，又能够利用阵列本身软件，不破坏“软件定义存储的良好愿景”呢?
当然有了!你把存储网关取消掉，让主机端直接连接存储系统不就得了?!
存储内嵌双活+CDP：这才是软件定义存储的思路
让存储双活回到软件定义存储的思路上来，其实并不像想象中的那么难，一方面，存储双活与软件定义存储不是对立的，即便是刚才谈到的几种解决方案，都是以软件为核心的，软件怎么会“为难”软件呢?另一方面，之前几种方案之所以无法释放阵列的软件能力，核心原因在于其只是将存储作为容量池使用，而是将复杂的软件功能交付给了存储网关或是主机端，从这个角度来说，“直连”不就得了?
但主机端直接连接存储，实现存储双活是有条件的，这个条件就是：存储系统必须要内嵌双活，也就是将原本存储网关干的事情纳入到存储系统中去，这就是我们在前文中提到的“存储内嵌双活+CDP”的模式——咦?为什么要CDP?这件事情我们暂时按下不表，先把话题集中到双活架构上来。
戴尔Live Volume的“存储内嵌双活+CDP”架构
在戴尔Compellent存储系统中，有一项内嵌技术叫做LV，这不是LOUIS VUITTON，而是Live Volume，以这一技术为核心的双活解决方案是“比纯粹数据复制更高级的数据中心级别的双活保护方案”：Live Volume以流动、虚拟化的方式，维持戴尔Compellent SC系列存储系统之间的数据关系，数据卷可以在系统之间以非中断方式在线数据迁移，或者说叫“漂移”。
在双活架构中，主存储的每一次IO操作，都通过FC或iSCSI链路以同步(远程站点可以选择异步)复制的方式，投射到备(从)存储上，使两边的数据保持高度的一致性。
当主存储站点或是通向其的路径发生故障，主机端的IO无法到达主存储时，戴尔Compellent SC存储系统会感知到来自主机端IO的下降甚至是丢失，在满足一定的条件时，即完成从动态的交换路径到自动进行动态角色交换等一系列动作，也就是说，原有的主存储和备(从)存储之间交换了身份。
Live Volume的站点交换过程，可以完全保证数据的同步。
这一“交换身份”的过程，对主机来说就像是让卷动态漂移到了新的主存储(也就是原来的备份(从)存储)那里，其技术实现和应用体验就像是VMware上实时在线迁移一台虚拟机——Live Volume就像是在主存储/备(从)存储系统中创造一个类似VMware的Hypervisor虚拟化层的存储抽象层——让卷可以就像是VMotion一样，自由的在存储系统之间漂移。
在这样的架构下，主机端所分配的卷，就像是在两套存储系统之间“漂移”，对主机端来说，主卷永远存储在主存储上，从未改变。哪怕主存储和备(从)存储之间的角色在1分钟前刚刚发生了改变，这正是作为“存储Hypervisor”的Live Volume的核心技术优势之一。
虚拟化环境中，戴尔Compellent SC系列存储系统基于其应用和数据流量感知技术，可以感知虚拟机的在线迁移，在虚拟机迁移之后，主机端IO出现变化时，“以最靠近的一套存储自动进行动态角色交换”，让虚拟机永远连接的都是“主存储系统”。
更进一步：两地三中心和逻辑故障的双活
说到数据中心的故障，IDC有一个大致的统计数字，逻辑故障占53%，硬件故障占47%，这也就意味着，大多数情况下存储双活面对的问题，不是系统宕机或是站点损毁，而是数据压根儿就是错的——这往往是逻辑故障所造成的。
对于高端存储应用来说，传统的备份技术已经不能满足实时恢复逻辑故障的需求，因此，CDP技术应运而生，成为企业客户避免存储系统逻辑故障的重要解决方案：CDP技术通过对数据进行大量的、高频率的“拍照”，让管理员可以选择将数据恢复到任意时间点(往往是分钟级)。
这就是戴尔Compellent SC存储的“LV”之所以被称为“存储内嵌双活+CDP”存储双活技术的原因，通过在Live Volume中内嵌CDP技术，一旦发生存储双活系统的逻辑故障，管理员可以从内嵌的CDP“设备(空间)”将数据恢复到主存储并快速同步到备(从)存储——与外置CDP不同，这是在存储系统内部进行复制，传输速度、延迟和可恢复性的水平更高。
基于戴尔Live Volume的两地三中心解决方案示意图。
两地三中心解决方案是存储双活解决方案的扩展，通过在远程站点增加一套存储系统，极大的提高了地域接近(大部分情况下就是在同一个数据中心)的双活存储在应对灾难灾害时的应对能力，Live Volume的两地三中心方案，可以简单的通过级联(近线DR站点异步复制连接远程DR站点)和混合(主站点与近线DR站点同步复制，与远程DR站点异步复制)两种模式建立，完全不需要调整原有的双活架构，只需要为主存储增加一个远程连接的外部站点即可。
这就是以Live Volume为基础的戴尔Compellent SC系列存储所构建的支持硬件故障和逻辑故障的高可用性存储双活和两地三中心灾难恢复功能的组合，作为一款可以感知主机端IO和虚拟机位置变化的解决方案，它可以支持动态性能调整、零停机存储维护、跨数据中心数据迁移以及虚拟机(微软、VMware或是其他Hypervisor)动态迁移等多种对存储系统颇有点考验的需求。
原生存储双活：架构简单 功能强大
戴尔Live Volume为企业客户实现存储双活及两地三中心高可用性，提供了一整套完整的解决方案，满足了企业客户在逻辑故障和物理故障两个层面对存储系统高可用性的需求，但在企业级IT市场，最终实现的结果只占企业客户实际意义的百分之五十，另有百分之五十在意的，是实现的过程——是否简单?是否风险小?是否具有良好的延续性?
这正是戴尔Live Volume技术广泛受到戴尔Compellent系列存储用户欢迎的原因，在全球主流存储厂商中第一个将存储双活高可用性技术加入到存储系统的软件平台中，戴尔必然是经过深思熟虑的(在被Dell收购以前，live volume就是Compellent流动数据跨越多套存储构建存储云的核心技术)。
一方面，在前面我们就提到过，作为“存储内嵌双活+CDP”，戴尔Live Volume既不需要从外部设备恢复数据，也不需要经由复杂的路径进行数据复制和恢复，这意味着更好的效率，更快的传输速度和更低的恢复风险。
另一方面，在一个经典的计算、存储、网络三层模型中，戴尔Live Volume “原生双活”的实现架构中避免了增加外置虚拟化网关或其他IT设备，避免了对数据中心存储架构的后天改造，更降低了方案的复杂性——既然存储系统自带“原生双活”，为什么还要去选择复杂的非原生方案?
第三，戴尔Live Volume的双活解决方案具有极高的灵活性和经济性，在链路选择方面，企业客户可以选择FC或是IP路径连接，复用裸光纤iSCSI远程复制这样的架构“容忍度”，可以帮助企业客户节省昂贵的FC直连费用;另一方面，无论是本地站点还是远程站点，戴尔的方案都支持同步或异步两种方式，且支持动态调整，在链路状况不稳定(这种事情在中国非常常见)的情况下，企业客户可以选择不同的复制方式。
第四，也是最重要的，Live Volume不是以“屏蔽”存储阵列自身的软件为条件的双活甚至多活方案，丰富的存储软件功能是戴尔存储在市场上的核心竞争力之一，如果为了增加一项功能而放弃整个“森林”，不仅企业客户不会答应，对于将数据中心业务重点放在存储上的戴尔公司来说，也是一个绝对不能够承受的损失。
试想，如果未来真的实现了“控制平面与数据平面分离”的软件定义存储，控制平面具有极强的存储软件甚至是多融合平台软件能力(这从当前新的企业级高端存储特性就能看出)，难道就要如此白白放弃这部分昂贵的价值么?
做云时代的存储双活
在本文最后的这一部分，我们终于涉及到讨论存储双活话题时经常会提到的一个概念：“(第三站点)仲裁”，在部分供应商的解决方案中，“(第三站点)仲裁”作为一个判定双活切换的“裁判”角色，得到了非常重要的位置。
但是，这样一个“裁判”真的必不可少，或者是，必须要以一个站点的形式存在么?
一方面，以中国企业客户的实际情况来看，独立的第三方仲裁(站点)几乎不可能，在一个双活数据中心(构建存储双活)之外，建立独立的数据中心站点容纳仲裁端，绝大多数企业都是承受不起的，而如果将“裁判”置于任何一方(站点)，在发生数据中心链路或其他物理故障时，不过是徒劳无用。
另一方面，随着云计算技术的普及，存储双活站点判定正常状态的“Pulse(心跳)”，完全可以脱离开实际的物理站点，进入到一个可靠、可信、具备高速链路的云平台上——位于云的仲裁站点通过判断来自不同存储系统的“Pulse”信号——以更具有经济性和可靠性的方式，保障存储双活站点的高可用性。
软件定义的甚至是云定义的“(第三方站点)仲裁”才是企业客户最需要的，传统的基于物理设备的存储双活判断方式，是无法满足企业客户的需要的，它不仅昂贵，而且受限于物理空间的限制，而以存储系统软件功能形态存在的戴尔Live Volume则完全不存在于任何的限制——让数据最终流动到云端，正是戴尔存储业已成型的流动数据架构的价值。
另外，除了支持不同型号Compellent存储系统的双活解决方案，还有支持跨越不同的网络接口协议来实现的双活切换，小编先埋个伏笔，很快就会有后续文章详细介绍哦!
