我曾经改装过一辆雪佛兰大块头——抬高底盘、压扁排气管并(当然)换掉4个博尔特电源。接着，在火花塞里注入足够的油，让它能点燃比例达到10.5:1的大缸燃油，冲击传统的点圈模式。但是，我还比较幸运，我的454是第一台带德尔科高能点火装置的车。它能产生足够的火花。
站在白板前面，我发现自己的思绪又回到了以前的日子——双手在车库里忙活着。我正计划对网络进行升级，以支持少数的超融合模块，不过我有点担心自己现有的网络是否有足够的空间。这让我想到了一个问题：到底超融合基础架构是要求完全更换网络还是只需要调整现有网络?
摸不清的动态工作负载
超融合(甚至超超融合)在本地很容易实现：将计算、网络和存储都集成在一个设备内，并且通过它由供应商预先配置好且差不多到手就可以使用。此外，它一般都声称像乐高积木一样模块化，由可调整和相对统一的模块组成，它们能稳定地绑定在一起，只需要小作调整就可以实现新功能。然而，除了常规的计算、网络和存储，还缺少的是互连网络。
当然，供应商关注超融合基础架构(HCI)的硬件，其中一些产品包含参考互连架构，并且通常在各个模块中使用白盒交换技术。由于缺少交流，有人可能认为迁移到HCI只是简单地扩大顶级机架或行间交换机的主干网为超大规模。虽然这是其中的一部分——而且你应该已经考虑了10 GbE以上规模的扩容，但是实际工作还远远不止这些。超融合基础架构从根本上改变了我们原本信赖的许多网络技术。它并不是单纯地“让所有东西提速”。
远不止一个思科UCS基架
像思科UCS这样的融合基础架构(CI)设备的一个大卖点是将计算资源捆绑到基架上，使之功能变得更加强大。原本一整个机架的专用设备和各种线缆都整合到一个可配置且密封的设备中。我们仍然要考虑这种模块间资源的逻辑配置，不过非常乐于见到物理基础架构变得精简。
然而，虽然CI的目标是增加功能和简化管理，但是HCI的目标则不仅仅是进一步融合。HCI希望交付模块化同质化计算、网络及存储资源的原因很简单：减少部件和安装步骤以削减IT人手。极其一致性的目标是大量减少人力成本，因此不要期望它一定能提供更高的灵活性。
我们肯定能够在云中看到这种现象，因为云中都是预配置的容器，所以亚马逊和微软就只是在各个数据中心安排少量IT人员来管理成千上万个同质化服务器。这种方法很适合他们，因为他们自己设计了白盒网络，也有大量的开发资源可以根据需要创建任何管理框架。但是这并不一定适合其他企业，因为HCI必须通过供应商提供的工具才能管理和监控。
安全和管理问题
如果曾经粗略看过PCI规范——我自己看过，那么你肯定知道它规定了网络分片。但是，在HCI中该如何实现网络分片呢?我们不能保证在将工作负载迁移到HCI之后现有CC处理系统的证书仍然有效。那么应该如何应用一种审计人员能理解的分片方式呢?如果所有节点都变成一样，所有的控制软件应该部署在哪里?所有的监控与管理软件又该部署在哪里?它们应该无处不在。
管理层会要求用一种统一的方法实现类似传统方式划分的网络、应用和存储监控，至少从安全角度会要求这样划分。单单软件定义网络的网络安全就已经很让人头痛了。目前零碎的企业网络并不适合用HCI完全替换机架系统;它要求我们重新思考网络。虽然CIO可能会认可灵活工作负载分配和IT人员成本削减带来的好处，但是法律部门可能不会太热心去解释融合控制与数据面板、软件定义结构和基于操作类型发现的虚拟分片。
供应商可能回避复杂性
超融合基础架构的互连复杂性还有一个令人感到意外的效果。软件定义结构在管理模块间东西向流量方面有足够的灵活性和自动化技术，但是网络基础架构复杂性的增加恰恰与超融合架构降低复杂性的目标相矛盾。至少在短期内，HCI模块所缺少的一些特殊企业网络管理功能仍然需要在核心层或融合层中重新实现。
另外，企业还需要担心的一个问题——HCI是一个容易形成东西向流量风暴的环境。在不久前，东西向的主要瓶颈是存储，但是应用管理发现固态硬盘能够缓解这个问题，然后瓶颈又转回到网络上。大多数HCI供应商都在自己的模块中解决东西向瓶颈问题，但是这并不意味着互连网络能够以相同的方式进行扩展。
中小型企业(SMB)可能会比大型企业更早使用HCI，因为他们的需求并不复杂，而且在解决方案真正有效的情况下他们通常不会介意适当的进行二次工程。目前SMB中UCS的持续应用就反映了这一点。如果企业有复杂规范要求、特殊的应用堆或者有更好的基础架构更新方法，那么HCI的应用可能不会太轻松。
供应商联合推动超融合技术的发展
站在白板前面，我发现自己的思绪又回到了以前的日子——双手在车库里忙活着。我正计划对网络进行升级，以支持少数的超融合模块，不过我有点担心自己现有的网络是否有足够的空间。这让我想到了一个问题：到底超融合基础架构是要求完全更换网络还是只需要调整现有网络?
摸不清的动态工作负载
超融合(甚至超超融合)在本地很容易实现：将计算、网络和存储都集成在一个设备内，并且通过它由供应商预先配置好且差不多到手就可以使用。此外，它一般都声称像乐高积木一样模块化，由可调整和相对统一的模块组成，它们能稳定地绑定在一起，只需要小作调整就可以实现新功能。然而，除了常规的计算、网络和存储，还缺少的是互连网络。
当然，供应商关注超融合基础架构(HCI)的硬件，其中一些产品包含参考互连架构，并且通常在各个模块中使用白盒交换技术。由于缺少交流，有人可能认为迁移到HCI只是简单地扩大顶级机架或行间交换机的主干网为超大规模。虽然这是其中的一部分——而且你应该已经考虑了10 GbE以上规模的扩容，但是实际工作还远远不止这些。超融合基础架构从根本上改变了我们原本信赖的许多网络技术。它并不是单纯地“让所有东西提速”。
远不止一个思科UCS基架
像思科UCS这样的融合基础架构(CI)设备的一个大卖点是将计算资源捆绑到基架上，使之功能变得更加强大。原本一整个机架的专用设备和各种线缆都整合到一个可配置且密封的设备中。我们仍然要考虑这种模块间资源的逻辑配置，不过非常乐于见到物理基础架构变得精简。
然而，虽然CI的目标是增加功能和简化管理，但是HCI的目标则不仅仅是进一步融合。HCI希望交付模块化同质化计算、网络及存储资源的原因很简单：减少部件和安装步骤以削减IT人手。极其一致性的目标是大量减少人力成本，因此不要期望它一定能提供更高的灵活性。
我们肯定能够在云中看到这种现象，因为云中都是预配置的容器，所以亚马逊和微软就只是在各个数据中心安排少量IT人员来管理成千上万个同质化服务器。这种方法很适合他们，因为他们自己设计了白盒网络，也有大量的开发资源可以根据需要创建任何管理框架。但是这并不一定适合其他企业，因为HCI必须通过供应商提供的工具才能管理和监控。
安全和管理问题
如果曾经粗略看过PCI规范——我自己看过，那么你肯定知道它规定了网络分片。但是，在HCI中该如何实现网络分片呢?我们不能保证在将工作负载迁移到HCI之后现有CC处理系统的证书仍然有效。那么应该如何应用一种审计人员能理解的分片方式呢?如果所有节点都变成一样，所有的控制软件应该部署在哪里?所有的监控与管理软件又该部署在哪里?它们应该无处不在。
管理层会要求用一种统一的方法实现类似传统方式划分的网络、应用和存储监控，至少从安全角度会要求这样划分。单单软件定义网络的网络安全就已经很让人头痛了。目前零碎的企业网络并不适合用HCI完全替换机架系统;它要求我们重新思考网络。虽然CIO可能会认可灵活工作负载分配和IT人员成本削减带来的好处，但是法律部门可能不会太热心去解释融合控制与数据面板、软件定义结构和基于操作类型发现的虚拟分片。
供应商可能回避复杂性
超融合基础架构的互连复杂性还有一个令人感到意外的效果。软件定义结构在管理模块间东西向流量方面有足够的灵活性和自动化技术，但是网络基础架构复杂性的增加恰恰与超融合架构降低复杂性的目标相矛盾。至少在短期内，HCI模块所缺少的一些特殊企业网络管理功能仍然需要在核心层或融合层中重新实现。
另外，企业还需要担心的一个问题——HCI是一个容易形成东西向流量风暴的环境。在不久前，东西向的主要瓶颈是存储，但是应用管理发现固态硬盘能够缓解这个问题，然后瓶颈又转回到网络上。大多数HCI供应商都在自己的模块中解决东西向瓶颈问题，但是这并不意味着互连网络能够以相同的方式进行扩展。
中小型企业(SMB)可能会比大型企业更早使用HCI，因为他们的需求并不复杂，而且在解决方案真正有效的情况下他们通常不会介意适当的进行二次工程。目前SMB中UCS的持续应用就反映了这一点。如果企业有复杂规范要求、特殊的应用堆或者有更好的基础架构更新方法，那么HCI的应用可能不会太轻松。
供应商联合推动超融合技术的发展
最终，超融合基础架构的未来将取决于供应商巨头。他们可能并不是这项技术发起者，但是他们才是将硬件投向市场的主力。思科是否会继续疯狂收购SimpliVity、Nutanix、Maxta或其他公司而变身为一站式超融合供应商呢?戴尔是否会收购EMC而推出支持超大规模模块间和模块内流量与网络服务的新产品，还是继续依靠合作伙伴的产品呢?时间会回答这些问题，我自己预期亢奋宣传周期即将过去，HCI将稳步进入生产环境应用。
原文发布时间为：2016年02月29日
本文作者：曾少宁翻译
本文来自云栖社区合作伙伴至顶网，了解相关信息可以关注至顶网。
