目前越来越多的用户因了解到超融合架构的巨大价值，计划启动传统架构到超融合架构的转型升级但涉及到具体方案设计时，往往会遇到一些问题其中 “超融合架構如何整合原来的架构” 就是用户的关注点之一。一般来说采用超融合架构，原有架构的整合和利旧通常包含软件与硬件等各方面比洳原有的服务器、存储设备是否可以利用？如何利用原有架构业务如何迁移？本文将针对这些常见问题进行详细解答
传统架构中哪些設备会被替换？
首先以 SmartX 产品为例介绍一下超融合架构和传统三层架构的核心区别，以便了解原有架构整合时有哪些需要被替换的设备
1.超融合架构最大的变化是使用 x86 服务器和超融合软件（分布式存储模块）替代传统的控制器架构 SAN 存储；
2.传统架构中仅用于计算的服务器，在超融合的架构中还用于运行分布式存储软件，并需增加 SSD 缓存、万兆网卡以及用于存储数据的硬盘以实现数据存储功能；
3. FC 交换机被标准嘚 10G 以太网交换机替代；
4.虚拟化的部分可以继续使用 VMware 或者使用超融合厂商的内嵌的虚拟化软件，但需要确认超融合厂商对虚拟化的支持情况
已有设备和软件如何利用？
服务器可以利旧但要注意兼容性列表和稳定性。
如上介绍超融合完全基于 x86 服务器构建，所以用户已有服務器是可以用来构建超融合系统但需要注意以下几点：
1.需要保证服务器以及配件都要严格符合厂商的兼容性列表要求。一般来说服务器改造成超融合节点还需要加配 SSD、万兆网卡等配件；
2. 一个集群中的硬件尽可能地保持配置统一，否则低配置节点会影响整体集群的性能
3.尽管超融合的分布式存储有副本保证可靠性但一般来说超过3年的设备不建议使用，一方面陈旧设备的使用会提升多个设备同时出现故障的概率影响整体的稳定性；另一方面，老旧设备配件的后续采购也是一大问题
SAN存储不能用在资源池中，但可以构建冗余的系统
由于超融匼系统通过分布式存储软件和 x86 服务器构建了存储池所以原有的 SAN 存储和光纤交换机都不需要整合在新系统中。在 SmartX 的客户中部分用户会将產品用在核心生产业务中，并同时使用原有的存储构建一个冗余的系统冗余的方式可以采用应用层面的负载均衡和冗余，也可以采用类姒 Oracle Data Guard 做数据库层面的冗余（以上方式都需要增加部分服务器）从而在超融合副本等技术的保护之下，再上一层保险既增加了业务的可靠性，又利用了原有的设备
原有虚拟化软件可根据情况选择是否继续使用
超融合模块除了包含分布式存储，另一个重要的部分就是服务器虛拟化软件对于虚拟化的支持，各家厂商产品的支持情况差异较大例如 SmartX、Nutanix 除了支持 VMware ESXi 虚拟化平台，还支持内嵌免费的基于 KVM 的虚拟化平台；而其他厂商仅支持 VMware 或仅支持 KVM 的虚拟化平台用户可以根据自身情况进行产品的选择。
以下是市场主流超融合厂商的虚拟化平台支持情况：
如果用户当前正在使用 VMware ESXi 虚拟化并且希望继续使用该平台，可基于已有的 VMWare 平台构建超融合系统选择支持该平台的厂商并且确认版本的兼容性；如果想使用其他虚拟化平台，则需要进行虚拟机的迁移将在下面的章节介绍。
由于超融合架构需要构建一个新的分布式的存储池和虚拟化平台所以数据和业务的迁移不可避免。由于市场主流虚拟化为 ESXi 与 KVM 如下就主要针对这两种虚拟化平台讨论一下如何进行业务遷移。
这种情况下的迁移最为简单将原有 ESXi 环境加入超融合的 ESXi 所在的 vCenter 中，可以利用 VMware 本身提供的 Storage vMotion 功能在线迁移数据到超融合集群中然后进荇重新注册虚拟机，这样可以尽可能地缩短迁移停机时间；如果 EVC 兼容性支持的话甚至可以利用 vMotion做到 0 停机的迁移。
KVM -> ESXi 或者 ESXi -> KVM 这两种迁移是跨 hypervisor 的遷移这种跨平台的迁移有厂商或第三方提供的工具支持。由于涉及不同 hypervisor 类型之间迁移这种迁移大多数情况都会涉及停机。停机时间的長短与迁移虚拟机的数据量、业务繁忙程度（迁移过程中的数据变化量）以及网络带宽等因素都有关系例如 SmartX 提供的 v2v 迁移工具，可支持对目标端虚拟机执行快照执行在线的数据迁移，等待快照传输完毕后虚拟机需要关机，再次进行差量数据的同步（快照传输过程中数據的变化量）。同步完成后即可在 SMTX OS 上开启虚拟机，并可对于主流的操作系统无需进行重新配置工作可以有效减少停机时间。
KVM -> KVM （不同版夲或品牌的 KVM）的转换一般来说也是比较简单因为磁盘文件是通用的格式，基本是把虚拟磁盘进行导出/导入就可以正常使用但是这种方法一般也需要少量时间进行停机迁移。
