对于业务偏向互联网，应用系统较多采用分布式架构的民营银行，如何进行合理的超融合架构规划？

对于业务偏向互联网，应用系统较多采用分布式架构的民营银行，这样银行的渠道服务、服务支撑、办公管理类这些业务系统更适用于先迁到超融合平台上来，超融合架构最初以业务不敏感的系统中使用，在非数据库模块中先行推广，不断积累大规模使用超融合架构的经验，确保超融合架构稳步推进。

采用超融合产品的出发点我认为有三个是比较关键的，结合自身使用超融合的经验，我简单描述一下。
一、稳定性。这是一个很难量化的一个概念，影响稳定性的因素也有很多，既跟厂商的技术和架构有关，也和自身维护能力有关。选择一个靠谱的厂商很重要，产品、服务两手都要抓；另外运维团队的技术能力专业程度也会影响超融合使用的状态，
二、维护性。一些IT规模比较小的公司可能需要外部技术团队的支持，采购的超融合产品市场占有率也是一个需要考虑的点，毕竟小众的产品所对应的市场上的技术人才也会少很多。而且对于工程师自身而言，考一些大厂的认证证书适用性、含金量也更高一些。
三、成本因素。往往大家预算都不太够，一体机形式的产品又往往比较贵，我们采用的是服务器、NVMe、超融合软件分开采购的形式，把各种部件都变成标准化的采购，能在一定程度上减少投入，相应的对运维团队的技术能力要求就会更高一些，在具体的产品搭配、产品设计以及后续维护都要求有相关的专业知识。
另外传统的超融合还是以虚拟化为主，这就造成了某些业务场景不适用的情况，面对这种情况，我们需要做一下架构上的改造，比如容器化、数据库一体机、软件定义存储等。

    从形态上来看，超融合仍然脱离不了虚拟化主机的范畴，在对这类民营银行的架构规划时，仍然适用于虚拟化主机的规划方法。根据不同的应用类型，不同的应用等级，划分为不同的资源池。计算部分相对简单。但超融合需要额外考虑的是存储部分。和传统集中式存储不同，超融合采用数据副本的方式来保证数据的安全性。在提升数据安全性的同时，副本的损耗不能忽略不计。例如采用2副本时，由于所有数据是双写，规划容量就应该至少是需求容量的2倍。 3副本时，规划容量就至少是需求容量的3倍。