SVC究竟用于什么场合才是较佳的选择？

问题一：

a. 在缓存上：

SVC在MM或者Local Hyper Swap架构中写缓存同步，而读缓存非同步。

由于同步复制是MM的R2端的数据是不可访问的，因此没有读的意义，而写缓存必须同步，否则数据就丢失（这里的缓存是指同步卷所使用的缓存部分）

而在Local Hyper Swap架构中，读缓存是根据站点属性分配的，即采用本地读的功能，如果本地有数据，就从本地的后端存储上读取，自然读缓存不一样。

在拉伸式集群中，读写缓存都是一致的，本质上可以理解为一台设备的两个控制器。

对于VPLEX来说，VPLEX只开放读缓存，因此从切换上说，VPLEX并不存在切换的问题，通信机制只要保证控制信息的同步就可以了。其缓存遵循全局缓存的特性。

从这个模型上可以知道，SVC和VPLEX考虑的点是不同的，并非SVC是所谓的冷切换

b. 性能上

SVC的性能本身是非常不错的，上一代SVC在8节点的情况下可以实现52万的IOPS（SPC-1，传统磁盘），而这一代IBM也通过SVC技术+FLASHSYSTEM技术组建了V9000的产品。相当于两个节点的SVC可以实现50万以上的IOPS。

而由于写CACHE的存在，在进行虚拟化的时候，SVC可以帮助老旧的存储提高部分的性能，相当于为老旧存储扩大了其CACHE空间。

而VPLEX的模式中，VPLEX使用了透写模式，在写压力巨大的时候，VPLEX是完全将压力转移到其后端存储上的，而VPLEX仅分担读压力。

当然如果将SVC对于某个卷的写CACHE关闭，可以实现类似于VPLEX的效果（有时IBM会在后端是FLASH的情况下这样做，取决于具体情况）

因此由于实现机制的不同，其性能评估要看具体场景，适合的产品用于适合的场景才是王道

c. 虚拟化和集中管理

这点上只说2点，一是SVC的诞生最初的目的就是为了实现虚拟化。二是SVC是目前市面上兼容其它厂家存储做多的存储虚拟化产品，没有之一。

SVC究竟用什么什么场合才是最佳的选择？

从以下三个方面来看SVC适不适合应用到这些场合。

1. 跨数据中心高可用

当存储正真发生故障的时候，暂且不讨论存储复制的逻辑校验问题。

就拿切换时间本身来讲，存储间的数据复制可以通过metro mirror来实现，但是SVC节点之间的缓存并没有同步过去。

所以这种切换相当是一种冷切换。如果这个时刻数据读写量非常大，那么出来的高可用数据就完全不是实验室里面出来的那个值了。

如果拿SVC来跟VPLEX比一下，那么VPLEX看似更高级一些，因为VPLEX会有缓存同步，是一个类似与ORACLE extend RAC的一种机制。

但实际上这种跨中心的缓存实时同步实时竞争带来的是另外一种安全上的风险，恐怕更要命。

所以SVC在RTO上会差一些，但是在保障系统性能及安全上能高一筹。

VPLEX在RTO上会更好一些，但是同时也带来了性能及安全上的风险。

2. 从性能上来讲

SVC是可以扩展节点，也可以增强节点自身的配置。

但是SVC的分裂集群机制，只能保证一个IO GROUP中的一个主节点为一个VDISK服务，其他IO GROUP无法实现自动接管，更别说负载均衡了。

那么我们就拿一个单一存储设备和一个SVC的节点比较，假设我的性能要求非常高，如果我用单一的存储设备，我可以实现存储设备多控的负载均衡，

而SVC的一个节点的性能相对一个高端存储来讲，那会差很多。

所以就单一业务来讲，SVC能实现的性能最大值恐怕要弱于存储设备本身。

3. 从存储自动化集中管理来讲

SVC对存储设备的兼容性要优于其他产品，SVC附带了很多高端存储具备的一些功能，比如说闪存的加入，自动分层等，可以实现整体业务性能的均衡。

比如一些备份、迁移上的功能很容易帮我们实现存储的统一管理并且提高存储管理的自动化水平。在这一点上，VPLEX等其他产品跟他无法比拟。

综合来看，我觉得把SVC应用到需要集中化管理存储实现整体性能平衡以及提高系统管理自动化水平的场合比较合适。

第一个，对于：“跨中心的缓存实时同步实时竞争带来的是另外一种安全上的风险”这句话含糊不清，到底会有哪种风险？

第二个，Vplex缓存一致性同步不仅仅是为了保障可用性，而是能够让每个节点都能并行处理IO，这也是VPLEX核心优势。

第三个，对于：“一些备份、迁移上的功能很容易帮我们实现存储的统一管理并且提高存储管理的自动化水平。在这一点上，VPLEX等其他产品跟他无法比拟” ——我坚信阁下对VPLEX这套产品了解非常之浅。

IBM SVC 主要用与异构存储的整体整合，统一存储资源池。提供同城、异地的灾备环境。

1.SVC不管是普通模式，还是拉伸集群模式，都会确保写入的数据在两个节点间同步，否则不会返回I/O完成的命令给主机。在拉伸集群中，如果中间链路故障，那么正在传输中，未收到对端返回的写I/O，将会hold住，直到两个站点通过第三仲裁选举出最终存活的站点，然后由这个站点提供服务。此时，之前发生失败的写I/O会直接写入到后端存储中，保证数据的一致性。在这些基本原理上，各厂商实现的方法略有不同，但目的肯定是确保数据的安全和完整性。SVC在这里和VPLEX没有多大的差别，不能因为VPLEX看上去比较吓唬人的分布式缓存架构，就认为VPLEX会更高级一些。由于VPLEX采用分布式缓存架构，且没有写缓存，那么每次需要形成一个写一致性组是，需要两个集群做通信，然后再传输一致性组过去。一个一致性组不是一个I/O，是一组I/O，那么中间链路故障，仍然会等待选举，或者直接指向winner策略宣布某个站点存活，然后再把传输实现的一致性组的数据进行recover，写入到后端存储。VPLEX的每一个一致性组传输所需要的来回确认导致I/O路径长，引起性能问题，才是做双活时需要重点关注的问题。

至于SVC的RTO比VPLEX的RTO差一些，则完全没有道理。RTO说的是recover所需要的时间。SVC的prefered owner架构特点，只需要在脑裂场景判断完成后，把存活站点的I/O写入后端，接管对端的卷，就可以提供服务了。VPLEX需要在内部看未传输完成的一致性组和本地正在形成的一致性组数据，哪些需要recover，然后写到后端去。这些都是很快速的完成，从哪可以判断出谁比谁的RTO更差呢？

2.SVC的拉伸集群，支持本地读本地写。在每个站点，每个节点都可以支持接受I/O，哪怕这个卷的属主属于对端节点。在这个模式中，I/O可以并发发给两个站点的多个节点，同时进行处理，形成Active-Active架构。在这个架构中，写也有锁的概念，也会在两个站点的控制器间快速实现锁排斥机制，确保数据block不会被两边同时写入导致脏数据。机制类似VPLEX，但不需要实现的那么复杂，导致很多长I/O路径。

单论SVC的节点性能，在前两代的CF8节点上做过SPC-1测试，16个V7000在8个CF8节点管理下，SPC-1性能达到50多万IOPS。现在最新的DH8节点，性能是CF8的3-4倍，那么性能可达到150-200万IOPS，每个I/O Group可达到50万IOPS。我们已经给很多客户展示过一对DH8节点挂闪存，可以跑出60-70万8K IOPS的随机混合读写（70:30）性能，侧面证明SVC端是可以支撑传统高端存储，不会出现性能瓶颈的。现在传统磁盘的存储，即使是高端的DS8870/VSP或G1000，都很难有单个存储超50万IOPS的情况。当然，现在进入闪存时代，存储网关受限与节点的接口速度和CPU核数，已经很难说一个集群可以管理很多太全闪存阵列。在闪存时代，传统高端存储的控制器都无法发挥出全闪存的性能，更何况存储网关了。至于VPLEX，没有看到公布SPC-1的值，不方便做评论。

1. hyperswap方面，我觉得是对原来要求DS8800苛刻条件的一个福音。

2. 存储双活，虚拟化，这些就不用说了。