融合基础架构如何处理存储服务和数据传播

　　如果可预测的性能是我们所关注的，那么IT规划人员应该寻找那些可以建立专门的存储层，也可以建立融合存储层的解决方案。

　　存储服务是所有任何基础设施的重要组成部分，尤其是对融合架构。很多打包式解决方案都会用到传统的共享存储系统作为架构中存储部分的实现。这要求一个存储网络加入进来，但由于供应商的预集成工作，存储网络的复杂性会大大降低。

　　大多数集成方案和所有的纯软件融合系统都把存储服务作为计算层的一部分。存储软件在每个节点汇集存储容量，这一实现的优点是能够消除增加额外存储控制器的成本和复杂性。并且这些系统可以使用服务器级别的存储介质，而不是企业级硬盘和闪存存储。这两个功能相结合极大地降低了成本。

　　当存储服务在计算层内运行时，有一些问题需要注意。这些服务通常运行在虚拟机（VM）上，这意味着虚拟机的活动水平可能会对群集中的其他虚拟机产生不利影响。例如，当一个虚拟化的SQL Server应用程序中的I/O需求激增，可能引起运行存储软件的虚拟机工作负荷增加，这可能导致I/O总线竞争。由于每个节点分担存储，计算和存储I/O，一些I/O问题会得到减轻，但要达到可预测的性能依然会有合理的担心。

　　这种担忧会因现实而加剧，因为大多数集成方案或纯软件融合系统根本不能有效利用共享存储。换句话说，对于缺乏可预测性如此关注的数据中心其实是缺乏一种能力，即通过建立一个专门的融合存储库来解决这一问题。如果可预测的性能是您关注的问题，那么我奉劝IT规划人员去寻找既可以建立专门的存储层，也可建立融合存储层的解决方案。

　　为实现共享和RAID保护，数据是如何进行分散的？

　　为支持实时迁移这样的功能，虚拟机需要多台主机可以访问相同的虚拟磁盘。并且，当然，虚拟机必须免受驱动器故障的影响。

　　同样，由于大多数打包式解决方案使用传统共享阵列，对数据保护少有关注。方案中集成的通常是企业级阵列，是基于RAID的数据保护。

　　打包和集成的解决方案往往会采取不同的方法。他们会为存储软件作一些调整，而此时的存储通常是以横向扩展的方式跨越整个计算层。它可以采取以下两种形式，第一种是复制模型，即每个虚拟机都会被实时复制到一个或两个其它节点上。大多数IT规划者倾向于选择三路复制，使它们在发生单点故障的时候仍处于受保护状态。

　　虽然复制是一种简单而有效的技术，IT规划人员必须认识到，这种模式下存储容量的消耗是三倍增加的。每次写操作也被三倍放大了，所以对这些节点间的网络互连进行高度调优就变得非常关键了。

　　另一种方式是采用像纠删码这样的技术来保护数据。纠删码对存储容量的开销优于复制，一般为30%和3倍的比例关系。而且由于I/O的需求是如此之小，当进行写数据，或者在重建状态时也会有更好的表现。当然它也有缺点，通常每个节点都需要参与每一个I/O操作，无论读还是写。

　　最后要考虑的是融合架构是如何保障性能的。对于打包式方法，性能是通过共享存储设备获得，所以确保存储网络配置正确和适当调优就成为了关键。

　　集成方案或基于软件的融合基础架构在性能方面应该是有优势的。由于这些系统在计算层上运行存储软件，存储I/O访问——特别是读操作——应当会有很大提高。但如何在现实中达到，在很大程度上取决于软件架构。如果需要在放置数据之后再动动脑子，那么该软件可以设计为每个虚拟机都具有其数据的本地副本。对于使用复制作为数据保护的，这一点尤其容易，而对于使用纠删码的系统则几乎无法实现。