大家觉得存储虚拟化技术足够成熟了没，遇到客户使用的案例多不？

deadwind

这里说的存储虚拟化主要指例如IBM/SVC(v7000)、HDS/USP-V、EMC/vPlex等等这样的带内虚拟化技术

1.大家觉得技术足够成熟可靠了么？比如SVC也发展N年了
2.大家看到客户使用的多不多？
3.用在生产环境的多不多？

当管理一二十台存储，且每台存储设备上都接了30+以上的主机(业务)时，面对存储调整、firmware升级时，没有这种存储虚拟化技术时，还有什么好方法？

milujite

我发现的就有几个问题：
1、虚拟化一般都是老的那些存储使用规划过，才介入进来。小存储和高端存储不同，小存储一般是边规划边使用，而高端存储一般先划分大量等大的LUN，然后根据需要做组合。如HDS之类的厂家会把RAID划分成100-200G的LUN，然后如果需要大LUN时，使用LUSE来组合。而这些小存储被虚拟化后，由于还有很多空间未划分LUN，因此在后期如果对小存储划分LUN，又得去操作虚拟化，管理成本其实没低。如果因为容灾数据集中需求，那也只能这样了。

2、实施起来相对比较麻烦，在AIX下，存储虚拟化得exportvg然后再import，在HP上操作就比AIX复杂得多。

3、存储调整和FIRMWARE升级问题虚拟化没法解决吧？被虚拟化的存储还是之前怎么，被虚拟化后还是怎么升级。

deadwind

milujite 发表于 2012-02-09 10:45
我发现的就有几个问题：
1、虚拟化一般都是老的那些存储使用规划过，才介入进来。小存储和高端存储不同，小 ...

嗯

1.一般都是这么用的，LUSE、MetaLun等等，各家存储都有这种方式；
2.如果把现有生产业务应用上的存储变成虚拟化后的存储，必须协调停机时间捣腾一遍，代价不小，如果是完整的全新规划倒没有这个问题；
3.是这样的，比如SVC，SVC接管下面多个存储(假定有存储A和存储B)的LUN，然后SVC打包这个LUN从SVC提供给主机，那么这个LUN对主机是透明的，主机不知道该LUN在A或B上，当存储A需要升级firmware或调整必须停机时，上面的多套业务可停机的就停机，不可停机的全部在SVC上迁移到存储B，不影响主机(多少会有性能波动但可控制)，然后存储A停机完成维护，启动后再次被SVC接管，原有临时迁移到存储B上的lun再回迁到存储A

这在技术上是可行的，问题是存储虚拟化虽然有了好几年的发展，但感觉用的还是很少(从论坛很少讨论可知)，也有厂商讲了些案例，了解到的大多是用来整合老弱病残异的存储而用，但随着虚拟化、私有云、已经大量存储的管理情况下，越来越没有好的手段来应对了，我觉得存储虚拟化来让数据流动是个好的方向，但还是对这种技术的可靠性不太放心

这里还没提到存储虚拟化厂商和存储厂商不是一家情况下带来的踢皮球问题

milujite

恩，厂家皮球也是问题～更多的是虚拟化压根没办法减少维护工作量和复杂性。

michael1983

存储虚拟化的前提是你的存储得足够多，否则就是浪费钱。
另外，虚拟化之后，人力精力照样无法节省。
存储这东西，咋稳定咋来，没必要费那劳什子的力气去整合它。

milujite

michael1983 发表于 2012-02-22 09:51
存储虚拟化的前提是你的存储得足够多，否则就是浪费钱。
另外，虚拟化之后，人力精力照样无法节省。
存储 ...

恩，有些环境很麻烦，如需要对数据做SAN复制之类的。确实需要整合。不过我觉得如果是虚拟化还不如直接迁数据～当然，最终决定权只有领导

michael1983

milujite 发表于 2012-02-22 14:21
恩，有些环境很麻烦，如需要对数据做SAN复制之类的。确实需要整合。不过我觉得如果是虚拟化还不如直接迁 ...

再复杂的环境，都有技术方案可以解决数据复制问题，你敢冒风险用存储虚拟化的技术尝试吗？
退一万步说，出了问题，到底是底层存储的问题，还是虚拟化设备的问题，会不会存在各自推诿的状况呢？
异构设备的firmware版本等不匹配导致的各种异常，会让你后悔的。
不过赞同兄弟的一句话，决定权还是在领导。
其他一切都是浮云。

*Daemon*

技术很成熟
案例非常多
生产环境案例也不少
我所知道HDS的VM和VSP可以在线升固件，至于被虚拟化的原有存储维护方式照旧。

至于是否需要虚拟化、整合，不同用户不同需求。