超融合架构下如何实现双活建设？建设过程中需要注意的问题？

超融合问世之初目的是面向运维能力一般用户提供开箱即用的便捷交付。随着使用深入，可用性问题开始考虑。

目前，双活方案中延伸集群较多，但存在很多局限性，因此影响实施效果。题主提到的资源容量问题，在任何高可用架构下都是存在。

说到延伸集群，重点其实是网络延时，比站点间的RTT不能超过5ms，站点到仲裁站点之间的RTT不超过200ms等。同时，注意脑裂问题，不同负载业务串扰问题、组网问题等

其实，基础架构资源层做好稳定服务，可用性从应用层实现也是个好方法。没必要在选择困难或技术程度不足时硬上。

  同城双活的超融合方案，确实很多厂商做的并不好。很多超融合产品数据的副本流动只在一个故障域（或者一个集群），在架构设计之初并未考虑到拉伸集群之类的多故障域双活应用。虽然从逻辑架构上来看，拉伸集群仅仅是把同一个集群中的节点分布在不同的物理地域，但由于有多个故障域的存在，对数据同步的设计其实是有很高要求的。受限于网络链路的影响， 当前常见的双活都是同城这类短距离双活，这是因为当距离拉开过远时，链路的RTT时延无法保证数据在两个数据中心间的同步返回要求。所以我们一般建议同城双活的两个数据中心物理距离不超过50KM，最好能使用裸纤直连。同时尽量选择国际大厂的成熟方案，并且进行基于实际业务的Poc测试，尽量降低试错成本。

是否可以从系统、数据库层面上来实现所谓的双活，即通过高速网络打通同城双数据中心，然后应用两地部署、数据库两地同步，应用用到的文件及附件服务采用分布式文件架构实现两地实时同步，这样既实现了系统的扩容增加并发又实现双活应用，会不好好一点？