存储虚拟化要搞好，用户其实还是得先盯着以太网这块来考虑一下

（来源：某数据中心技术讨论会上的工程师发言）

存储虚拟化要搞好，用户其实还是得先盯着以太网这块来考虑一下，这个话可能很多人一开始不理解，觉得存储虚拟化嘛，不就是把一堆硬盘池化，然后灵活分配吗？软件选好，硬件买对不就行了？但实际情况是，你底层网络要是没弄明白，上面再好的存储虚拟化系统跑起来都像是用一根细细的水管给一个巨大的游泳池同时充水和放水，肯定会出问题,而且问题会非常难受。

为什么这么说呢？你想啊，传统的存储，比如用光纤通道（FC）的那种，它是个独立的、专门为存储流量设计的网络，它就像城市里的高速路，只跑一种车，速度快，规矩严，很少堵车，但存储虚拟化之后，尤其是现在流行超融合架构，什么都跑在以太网上，存储流量、管理流量、虚拟机迁移的流量、还有业务应用的网络流量，全都在这一条以太网线上跑，这就好比把高速路、国道、省道、甚至乡间小路的车，全都赶到一条新建的八车道大马路上去，车是多了，路也宽了，但如果红绿灯设置不合理，没有交通警察，大货车、小轿车、自行车混在一起乱窜,那这条再宽的路也得堵死。

（来源：同一位工程师对具体问题的举例）

具体会碰到什么问题呢？我举几个常见的例子，第一个就是“邻居吵架”，你一台物理服务器上可能跑了十几个甚至几十个虚拟机，它们共享着服务器的物理网卡，其中一个虚拟机要是突然发疯了一样读写存储，比如做个大数据备份或者跑个报表查询，它就会把这条共享的网络通道给占满了，结果呢？其他虚拟机就惨了，它们可能连正常的应用都访问不了，感觉卡得要死，用户就会投诉说系统慢，但你查存储性能，磁盘IOPS可能还很低，根源其实在网络拥堵上,这就是没有做好网络层面的隔离和流量控制。

第二个问题是延迟抖动，存储操作，特别是对性能敏感的数据信操作，对延迟是非常敏感的，它希望每次读写的响应时间都很稳定，但在共享的以太网里，你没法保证，可能这一秒钟网络很空闲，延迟只有0.1毫秒，下一秒钟某个虚拟机开始迁移，或者有个视频会议占用了大量带宽，存储的延迟一下子就飙升到几十毫秒甚至更高，这种不稳定的延迟，对数据库来说就是灾难，会导致事务超时、应用报错，这种感觉就像是开车的时候，一会儿能飙到120公里，一会儿又得急刹车到20公里，不仅不舒服,还容易出事。

（来源：工程师关于网络基础建设的建议）

搞存储虚拟化之前，真得先把以太网这块“地基”打扎实，这不单单是买最贵的交换机就行，而是要从设计上就考虑清楚，比如说，你得做网络质量服务（QoS），这就像给不同类型的车划分车道，规定救护车、消防车有优先通行权，你要告诉网络设备，存储的流量是“VIP”，优先级最高，当网络拥堵的时候，必须优先保证存储的数据包通过，这样即使有其他大流量应用在跑,存储的响应速度也能得到基本保障。

再一个，物理链路上也要有冗余，至少要用两根网线做捆绑，这样一根线坏了，另一根还能顶上去，不会导致整个存储访问中断，虚拟化环境最怕单点故障，网络更是如此，还有，网卡的选择也很重要，现在很多服务器都有智能网卡，它能在硬件层面帮你分担一些网络负载，比如虚拟交换机的功能，这样就能减轻服务器CPU的负担，让CPU更专心地处理业务和存储计算,整体性能会好很多。

（来源：工程师最后的总结）我的观点就是，存储虚拟化听起来很美好，但它不是一个孤立的技术，它把存储的复杂性从专门的硬件里解放了出来，但也把这份复杂性转移到了通用的以太网络上，如果你忽视了网络这个承上启下的关键环节，就等于把高楼大厦建在了沙滩上，表面上看功能都实现了，但稳定性和性能都经不起考验，用户真想搞好存储虚拟化，第一步就是回过头来，老老实实地把以太网规划好、配置好、优化好，这才是最实在的，不然，后面遇到的各种稀奇古怪的问题,够你头疼的。