思考，超融合真的完美吗？

超融合真的完美吗？
超融合架构的优势和客户价值这个已经勿容置疑，全球和国内市场都已经初步形成，HCI是未来5-10年新一代数据中心基础架构的首选方案。但是，超融合真的是完美的吗？我个人比较喜欢辩证的看问题，超融合是不是存在一些局限或问题呢？下面我们就来找找茬，同时也是选择超融合架构时需要考虑的因素。
（1）新的信息孤岛
几乎所有的超融合方案都不支持数据中心中原有的外部存储，大多数企业也不可能在短期内更换整个数据中心基础设施，结果数据中心又分裂成两个彼此独立分散的基础设施孤岛。对于大的数据中心，出于不同业务需求和平衡考量，很有可能会同时部署不同的超融合架构，不同HCI之间无法整合和互操作，结果就是又多了几个新的信息孤岛。新的信息孤岛带来了资源利用效率和统一管理的问题。

（2）性能一致性问题
数据中心中存储的性能至关重要，而且期望性能是可以预测并保持一致性的，包括延迟、IOPS和带宽，这一点尤其对核心业务系统很关键。对于超融合架构而言，这一点恰恰是很大的挑战。原因主要有两点，一是超融合架构“共享一切”。计算和存储会争抢CPU/内存/网络等物理资源，而且计算和存储又相互依赖，一旦一方资源需求骤升就是导致另一方资源枯竭，进而影响性能并在整个基础架构中产生涟漪效应。虽然可以采用cgroup或容器技术进行资源隔离限制，但和非超融合架构的效果还是不同的。二是超融合架构“一切分布式和软件定义”，集群规模较大后，网络、硬盘、服务器发生故障的概率都会增大，数据重删/压缩/加密/纠删码等功能都用软件实现，故障的自修复和数据功能实现都会消耗一定的系统资源，导致性能下降和抖动。自修复的流控，数据功能旁路到硬件模块处理，这些方法会缓解性能一致性问题，但似乎又与超融合的理念相背离。

（3）横向扩展之殃
超融合架构关键特征之一就是易于扩展，最小部署，按需扩容。超融合架构厂商宣称最大集群规模也差别很大，从数十到数千节点不等，通常从3节点起配。超融合中计算能力、存储性能和容量是同步扩容的，无法满足现实中单项能力的扩展，有些厂商还对扩容最小单元有要求，扩展灵活性会受到限制。集群达到一定规模后，系统架构复杂性就会非线性增加，集群管理变的更加困难，硬件故障和自修复发生的概率也会大大增加。因此，我们是不建议构建大集群的，如果业务允许尽量构建多个适当规模的较小集群，或者采用大集群中构建故障域或子资源池，光大是不行的。集群扩展还面临一个棘手问题，就是容量均衡。如果存储集群容量很大，均衡是一个非常漫长而痛苦的过程，同时还会对正常的业务负载产生较大的影响。

（4）系统复杂性
超融合架构简化了IT架构，极大降低了数据中心设计的复杂性，实现了快速交付，并极大简化了运维管理。不过，这都是基于用户角度的，从产品研发角度而言，超融合实际上使得内部的软件复杂性更高了。前面我们已经阐述，超融合架构需要采用CVM虚拟机控制器，并且需要将主机物理设备透传给控制虚机，增加了部署配置管理的复杂性。计算和存储对硬件平台的要求都不同，融合后也会一定程度上增加兼容性验证的复杂性。超融合架构下，管理、计算、存储、高可用通常都需要配置独立的虚拟网络，网络配置也会更加复杂。同时，共享物理资源的分配、隔离、调度，这也是额外增加的复杂性。还有一点，如果出现故障，问题的跟踪调试和分析诊断也变得更加困难。

（5）SSD分层存储
闪存SSD基本成为超融合架构中必不可少的元素，消除了计算和存储的巨大鸿沟，解决了I/O性能瓶颈问题，尤其是I/O随机读写能力。目前闪存的价格相对HDD磁盘还是要高于许多，迫于成本因素，全闪超融合方案应用仍然较少，多数应用以SSD混合存储配置为主，从而获得较高的性价比。通常情况下，我们假设热点数据占10-20%，配置相应比例的SSD存储，采用Cache加速或Tier分层模式将热点数据存储在SSD存储中，一旦热点数据超过预先设置阈值或触发迁移策略，则按相应淘汰算法将较冷数据迁移回HDD磁盘存储，从而期望在性能和容量方面达到整体平衡。看上去很完美是吧？SSD擅长的随机读写，带宽并不是它的强项，对于带宽型应用，SSD对性能并没有帮助。关于热点数据占比，这个并不好估计，如果SSD配置不足，性能会变得更差。假设应用场景合适并且SSD配置合理，情况又如何呢？SSD空间最终要被热点数据占满，就会触发数据迁移，这时HDD存储仍将成为I/O性能瓶颈，同时还要承担正常的I/O业务负载，整体性能就会出现降级和抖动。为了缓解这一问题，SSD Cache/Tier功能实现中，一方面会过滤掉顺序读写I/O，另一方面会把空间阈值设置较低，尽早进行数据迁移，同时选择系统空闲时间执行和流控。带来的负面效应是，SSD性能加速效果受限，物理设备效率发挥不充分。另外，SSD本身被写满时性能也会出现较大的波动。因此，SSD混合存储并非理想模式，实际中我们推荐根据应用场景采用全闪SSD或全磁盘HDD配置，从而获得一致性的性能表现。如果真的无法全用SSD，还有另外一种应用方式，同时创建一个全SSD和一个全HDD存储池，人为按照性能需求将虚拟机分配到不同存储池中。

（6）企业级数据功能
目前在大多数超融合系统以及SDS系统都具备了核心的企业级功能，包括数据冗余、自动精简配置、快照、克隆、SSD Cache/Tier、数据自动重建、高可用/多路径等数据功能，有些甚至还提供了重复数据删除、数据加密、数据压缩等高级数据功能。然而，相对于高端存储系统，如果超融合架构要承载核心关键应用，还有很大的差距，包括但不限于QoS控制、数据保护、数据迁移、备份容灾、一致性的高性能。核心存储系统应该遵循RAS-P原则，先做好稳定可靠性，其次是企业数据功能完备性，最后才是高性能，这个顺序不能乱，光有高性能是不行的。比如Ceph，企业级数据功能列表多而全，功能规格参数非常诱人，但真正稳定而且能够实际生产部署应用的其实不多。目前，核心关键业务系统还不太敢往超融合架构上迁移，主要还是从非核心业务开始检验，毕竟超融合出现时间还比较短，需要更多的时间和实践验证RAS-P特性。但是，未来超融合必定是核心关键业务的主流架构。

（7）物理环境应用
目前普遍公认的适合应用场景是桌面云、服务器虚拟化、OpenStack私有云、大数据分析等新型应用。理论上超融合系统可以适用于IT环境的所有应用类型，需要注意的是，超融合系统管理虚拟化环境，而更多的传统IT应用仍然运行在物理服务器和传统存储系统之上。我们可以乐观地认为没有哪一种应用程序不能被部署在超融合基础架构上，但是考虑到运行效率、硬件依赖性以及和虚拟化环境兼容性等因素，很多IT应用最好还是继续保持运行在物理硬件架构，比如数据库应用、实时控制系统以及大量遗留IT系统。

（8）异构虚拟化环境
目前超融合方案通常是仅支持一种虚拟化环境，Nutanix可以支持多种虚拟化环境，但是对于一套超融合架构部署，实际上也仅支持一种虚拟化环境。每种虚拟化环境都有各自的优势，很多企业可能需要同时运行几种虚拟化环境，比如VMware、KVM、Hyper-V、XEN，因为超融合不支持异构虚拟化环境，需要部署多套超融合架构，这就是新的信息孤岛。客户非常希望看到支持异构虚拟化环境的超融合架构方案。

（9）超融合数据共享
超融合架构采用软件定义存储替换传统的共享式存储解决了虚拟化存储问题，这里的SDS实际上主要是指ServerSAN，提供分布式块存储。然而无论是虚拟机还是物理机，实际IT应用都有着数据共享需求，需要分布式文件系统或NAS存储系统。这是目前超融合普遍缺失的，现实还是依赖外部独立部署的NAS或集群NAS存储系统，比如GlusterFS、ZFS。从技术架构和实现来说，一个SDS系统很好地统一支持Object/Block/File存储，这个非常难以实现的。比如Ceph，它的CephFS一直没有达到生产环境部署标准，更别提性能。因此，超融合架构中可以采用相同方式同时部署两套SDS存储，分别提供分布式块存储和文件系统文件共享存储，比如SSAN和GlusterFS，不必非得要求分布式统一存储。

（10）全栈超融合架构
目前很多厂商都在推超融合架构方案，其中一部分是SDS厂商，一部分是虚拟化厂商，还有更多的是集成商，像VMware/Nutanix同时做SDS和虚拟化的厂商非常少。SDS和虚拟化是两个完全迥异的领域，而且技术门槛都非常高，一个厂商同时把这两块都做到很好是非常难的。两者都想做的厂商，无非是想控制成本、自主可控、扩大市场、融资好讲故事。对于初创公司，团队和资金非常有限，打造全栈超融合架构更是困难重重。正确的姿态可能是，确定战略方向重点做好一块，然后再找另一块做得好的厂商进行战略生态合作，强强联手打造有竞争力的超融合架构方式，无论从产品技术还是市场角度都是双赢的。

5 容器要不要超融合？
容器是个神奇的东西，火热程度毫不逊色于超融合，它正在引领一场云化数据中心架构的新变革，而被革命的对象是目前还没有大行其道的超融合架构，许多企业已经或正在将应用从虚拟机迁移到容器上。那么什么是容器？简单讲容器就是主机上被隔离的进程，它运行在沙盒之中，借助CGroup/Namspace技术限定和隔离所使用的主机物理资源。为什么容器这么受热捧？虚拟机管理程序对整个设备进行抽象处理，通常对系统要求很高，而容器只是对操作系统内核进行抽象处理，使用共享的操作系统，可以更加高效地使用系统资源，相同的硬件可以创建的容器数量是虚拟机的4-6倍。这可以为数据中心节省大量的成本，同时可以快速构建随处运行的容器化应用，并简化部署和管理。“最小部署，按需扩容”，这是云计算要解决的弹性扩展问题。容器相对虚拟机非常轻量级，它能解决的根本问题就是提升效率和速度，从而实现秒级的扩展（包括缩容）。正是这些显著优势，容器非常有潜力替换虚拟机成为云计算的基础架构，这么火热自然就可以理解了。值得一提的是，并不是所有应用都要容器化，关键要看业务是否适合高度弹性计算的微服务，不能盲目推崇。

容器是用来承载应用的，其设计就是为了应用的运行环境打包，启动，迁移，弹性扩展，容器一个最重要的特性就是无状态，可以根据需要动态创建和销毁。然而，并不是所有应用都是无状态的，对于有状态的容器怎么办？容器中需要持久化的数据即状态，这是不能随便丢弃的。如何持久化保存容器的数据，这是自Docker诞生之日起就一直存在的问题。普遍的看法是不应该把数据放到容器中，最好保证所有容器都是无状态的，但还是要提供保存状态的内部机制。Docker 唯一与状态有关的概念是volume，容器访问外部应用数据接口，完全脱离Docker的管制。Volume解决了容器的数据持久化存储问题，但它仅仅是一个数据接口，容器本身并不负责持久化数据的管理。这个问题几乎被所有容器厂商忽略，主要依靠外部存储来解决，其中一种解决方案是把容器数据持久保存在可靠的分布式存储中，比如GlusterFS、Ceph，管理员不用再考虑容器数据的迁移问题。

容器里面直接跑的应用，它天生比虚拟机VM更接近应用，最能通过应用感知对存储的深层次需求，从而动态配置不同的存储策略。因此，为容器提供状态持久化的外部存储系统，应该是面向应用的存储系统，它针对不同类型应用的容器提供精细的存储策略，并进行动态智能应用感知。那么，容器计算＋应用感知存储要不要超融合？这里我们定义一下容器超融合：采用分布式存储，完全容器化，存储控制器也容器化。容器天然应该是无状态的，它的职能是实现敏捷的弹性计算，如果容器是有状态的，这个优势会被极大减弱。分布式存储都是比较重的系统，比如Ceph，GlusterFS，需要管理大量的磁盘和网络资源，本身并不适合容器化，它们更适合直接运行在原生的物理机操作系统中。分布式存储对状态要求很严格，如果把应用容器和存储控制器容器融合在一个，存储状态的变化会严重影响到应用。因此，我个人理解容器本质上是不需要做所谓的超融合，容器重点做好弹性的云计算架构，分布式存储则重点做好可容器感知的应用存储，需要有状态则由独立的外部专业存储来负责，通过容器提供的存储机制进行数据访问，如Rancher Convoy或者Flocker容器存储驱动。实际上，有状态的容器需求非常少，这也是为什么容器存储被忽视的重要原因。最后，容器与虚拟机VM最大区别就是它不是VM，容器超融合这个说法也不对。
摘自如下博文，如有侵权请通知： http://blog.csdn.net/liuaigui/article/details/51794439