小金融对双活要求不高，可否采用超融合架构替代存储架构？

我觉得是没有问题的。超融合有着很多优越性。而且也特别中小企业，当然也包括小金融。具体的搭配要看实际环境的业务量，对故障的容忍度等等。总体来说。需求不算苛刻的情况下可以用超融合架构代替传统的存储架构，可以适当增加一些备份容灾手段来提高可靠性。

要考虑稳定性的问题，如果系统对稳定性要求不是非常极致，超融合完全没问题。

要考虑稳定性的问题，如果系统对稳定性要求不是非常极致，超融合完全没问题。部分数据库一体机就是虚拟机上运行的RAC。

小金融在选择基础架构平台时一般会有如下需求：

1. 架构简捷，开放，无需复杂规划；
2. 最小化部署，提升资源利用率，尽可能降低空间及运维人员压力；
3. 弹性伸缩，易于扩展，满足资源池化以及共享的需求；
4. 按需购买，避免一次性高额投入，缓解预算紧张的状况；
5. 性能及可靠性高，为关键业务提供保障；
6. 快速实现资源分配，支持业务系统快速迭代与上线。

而超融合基于X86架构，利用虚拟化、分布式存储等技术实现计算、存储以及网络资源一站式管理，可以有效地满足以上需求。
同城主数据中心与备数据中心可以采用双活的方案设计时，可以实现RPO=0的数据保护。
构建双活数据中心时需满足数据中心间的距离、网络链路质量等要求，这些要求与金融机构的大小无关，属于架构要求。
SmartX 双活数据中心（拉伸集群），数据实时同步，需要满足网络带宽和延时要求，数据采用3副本，在主站点（优先可用域）存放2个副本，次集可用域存放1个副本，如出现站点故障，业务可直接进行站点切换，RPO=0

超融合架构能够为型企业提供高效的存储和计算能力，同时还能够节省维护和管理成本。而且，超融合架构具有很好的可扩展性，能够满足企业未来业务扩展的需求金融行业采用超融合架构替代传统存储架构的案例已经比较多，同时需要考虑的是超融合架构虽然已经比较成熟，但产品实现和服务的情况各厂商差别其实很大，一定要选在超融合产品上真正有竞争力的专业产品型厂商，例如国外主要是Nutanix，和VMware，国内的主要是SmartX，国外的产品品牌肯定更强，但价格比较高，本地服务响应速度可能会不够及时等问题。从不同的金融行业客户来看，作为中国超融合软件金融行业市场份额的 No.1，SmartX 长期深耕金融行业，已服务证券、期货、银行、保险、基金等多个细分领域的客户。

超融合除了支持在应用层面上，应用级别双活部署相同的应用程序，这些应用程序能够同时处理数据，以保证在其中一个地点发生故障时，另一个地点可以继续提供服务。常见的双活应用包括网站和数据库。超融合构架本身也可以做到跨数据中心的双活架构模式通过集群拉伸到两个位置，数据是强一制性的，以SmartX产品为例，集群间可实现数据的实时同步、应用服务在数据中心之间自动容灾切换。当开启双活的功能，数据副本将自动变成三副本保护，即优先可用域存储两份副本，次级可用域存储一份副本，如何结合的灵活适配双活方案需要综合去看，业务场景和物理条件是否与双活技术适配。

对于大型金融企业，超融合的双活构架是一种理想的解决方案，因为这些企业的系统往往需要支持高度并发的交易、处理大量数据以及实时监控。这些任务对系统的可靠性和可用性提出了很高的要求，因此需要一个具有高度集成性的解决方案来确保系统的稳定性。超融合的双活构架可以在数据中心之间提供实时同步，以确保数据的一致性和可靠性，并且可以在一个节点故障时自动切换到另一个节点以确保系统的高可用性。

对于小型金融企业，超融合的双活构架同样是一种有用的解决方案。虽然这些企业的规模较小，但是它们也需要支持一定的交易量和数据处理能力，同时需要确保系统的可靠性和可用性。超融合的双活构架可以通过其高度集成的特性，使得小型企业可以轻松管理和维护其系统。此外，超融合的双活构架还可以在发生故障时自动切换节点，确保系统的高可用性，从而避免业务中断和损失。

    对于小金融公司来说是可以替代的，业务量级不大的时候，可以应用全部部署到超融合上，数据库依据业务要求、架构、量级等因素，选择部分部署到超融合虚拟化上。
    数据同步选择应用层的同步机制或者第三方同步工具，安全产品采用虚拟化的增强组件产品，容灾选择虚拟化的多站点保护机制。

这样的优势是维护简单，超融合产品优秀，厂商支持到位的话，系统抗故障能力也很优秀。

    首先明确一个要求，小金融对双活要求不高，并不代表可以不做双活，只是做的级别和程度要求相对较低。
    按照国家银监会的要求，银行等金融机构在成立一年内就需要实现双活或数据备份等容灾手段保护数据安全和业务安全。按照国家容灾等级建设制度要求，双活属于6级最高级，小金融可以根据自身情况做5级或以下容灾级别，但是不可以不做。
     超融合架构做数据中心双活架构，需要依赖的网络和技术的条件比较多，严格意义上讲不是特别合适，但是如果做本地级别的双活或者网络条件允许下的双中心级别的双活容灾还可以考虑，主要有以下两种方案：
1，如果两个数据中心距离不是很远，或者只做本地数据中心的双活或主备架构，在网络条件比较好的情况下(光纤或万兆网络链接)可以实现。如果是本地数据中心双活，直接使用超融合架构组建一个或多个超融合群集，部署在群集内的金融应用可以实现高可用性。如果是两个数据中心直接，可以将超融合的群集服务器在物理上分开部署，将群集内的服务器分别部署在两个数据中心，但是逻辑上还是一个群集，这样两个数据中心共享一套群集，部署在群集内的应用同样享受高可用特性。
2，如果两个数据中心距离较远，或者本地数据中心要求不高，小金融不做双活，只做数据备份或者数据复制，那么可以通过超融合架构的分布式存储数据复制功能实现。首先一定是两套超融合群集，一主一备，不管是分别部署在两个数据中心还是全部本地化部署，平时都是只启用主群集，备群集只做数据同步和备份，在主群集有故障时再启用备群集接管。这种架构好处是随时实现不了双活级别，但是对网络要求比较低，可以实现并满足银监会的要求。
    另外，超融合架构本身就是分布式存储+虚拟化系统的架构，从技术上来讲是可以替换小金融的存储架构的。但是建议是只替换小金融的分布式存储架构，对于数据一致性要求比较高的集中式存储，能否替代还需要多做测试。因为超融合的存储架构毕竟是分布式的，存储文件和数据没有问题，但是对于oracle rac这类对数据有强一致性要求的业务，需要慎重选择，并不一定能支持的很好，而且不管大小金融数据库类业务比较多，还需要谨慎选择。

小金融合大金融对安全以及监管的要求是一样的，小金融和大金融最大的区别就是规模，再就是需要考虑其业务对底层存储的要求，如果是集中式存储那就不能通过超融合架构替代，如果是分布式的这个可以考虑通过超融合架构替代。超融合最大的特点是算存、管控、安全一体化，涉及的不仅仅是存储的问题，还有计算与安全的，所以这个问题需要更进一步细致的分开讨论，不能仅仅是存储层面。

超融合架构的核心技术是服务器虚拟化+分布式存储，只是计算和存储运行在同一软件堆栈上。
优点：方案集成度高，部署便捷，可横向扩容；
缺点：虚拟化方案可选，但存储方案是封闭的，易形成资源孤岛；整体架构扩展性不足，不管是横向还是纵向扩容；系统内部复杂性高。
超融合架构有其固有缺陷，并不适合通用的存储场景。但如果合理规划，确实能替代很多存储使用场景。需要注意的有：要控制住超融合集群的规模，应用可在多个集群中部署，适合一般的虚拟化场景（ 计算与存储配比稳定）

这个是完全可行的，对应轻量化的应用是完全合适的；相比银行保险那些要求较高的性能还估计比那些强，完全可行！
第二超融合存储部署也比较方便，功能也很全，对数据库rac也是完全支持的！

1、若对建设和运维成本敏感、系统对扩展性要求不高，请酌情考虑。
2、若系统架构比较稳定，对性能要较高要求，比较推荐。