保险企业集中式的SAN和NAS存储系统如何转型升级？

保险是金融系统领域的重要分支，保险公司的健康运营是对社会、国家的承诺，是对亿万被保险人的责任！因此在做好保险产品的同时，险企更要注重IT系统的建设，核心的信息系统要经过严格审慎的架构设计、运营和不断优化，从而给客户提供优质的服务，同时增强客户对险企的信心。

作为传统行业，保险公司的存储系统普遍采用集中式的SAN和NAS存储，业务系统数据库主要部署在SAN存储上，而云桌面和文件型应用则采用NAS存储。这种传统、稳定的存储架构承载了核心业务系统的生产、容灾和研发测试需求。对于传统的存储架构，普遍采用了高度冗余的硬件架构设计以规避单点故障，从而实现存储系统的高可用和高可靠。另外，通过采用高吞吐、低延迟的高端存储设备保证底层存储的高性能。在SAN组网规划和实施中，按照前端主机类型以及业务种类将存储设备和SAN网络逻辑上划分出多个区域，使得各区域的业务不会产生资源争抢，确保了业务系统的高性能和故障隔离。同时每个区域充分考虑冗余性设计，确保没有单点故障。

显然，这种存储架构模式是很多公司的存储1.0时代，在这个时期，存储系统架构简单，拓扑清晰，是从前端应用到后端存储的直线型端到端的设计思路。在这种模式下，业务系统的IO性能和扩展能力有限、可预测性强，因为后端连接存储的性能便是提供给业务的性能边界。此外，由于拓扑清晰，给故障处理也带来了很大的便利性。但是，这种“竖井式”的架构，显然降低了存储系统之间的数据流动性，不同存储之间的利用率难以实现平衡，单台存储的独立运行也成了一个宏观的单点故障。

随着软件定义大潮的出现，数据中心的存储架构迎来了2.0时代，软件定义存储从数据平面和控制平面给存储架构注入了新鲜的血液。在软件定义中，存储系统之间增强了沟通，池化的概念将异构的存储紧密联系在一起，数据可以在不同的存储系统之间肆意流动。前端业务想要的性能可以量化，不同业务系统可以定制自己的IO属性，包括延迟、IOPS和带宽，也可以定制期望的冗余性：比如镜像、多副本等。此外，软件定义也给存储的配置带来了自动化，极大地减轻了存储运维人员的工作负担和压力。然而，如同世间没有完美的事物，存储架构也没有完美的一招鲜，一切美好的背后肯定有他的“阴暗”一面。比如，和1.0时代清晰、简单架构相比，2.0的存储架构在简单中也存在着复杂，如果前端业务系统出现了IO故障或性能问题，那么排障和调优将会是个大的挑战，虚拟化掩盖了硬件实体的边界。

可以说大多数的险企，正在从稳健的存储1.0时代走向或者说去尝试和探索存储2.0时代。在这期间，有个很重要的话题，就是存储的双活实现方式，在1.0时代，存储之间的数据复制往往是同构存储之间的基于FC或者IP的直连，每个存储厂商通过自己的数据复制软件实现存储之间的数据同步或者异步复制。在2.0时代出现了存储虚拟化，如SVC、VPlex，这种存储网关形态的产品，模糊了后端存储的异构特性，实现了不同厂牌存储产品之间的数据复制。谈到存储双活，实际上大多数的险企并未实施，或者说至少没有在跨地域上做双活实施。很显然，需求是驱动架构演进的源动力。对于来自外部监管方保监会的要求，在《保险业信息系统灾难恢复管理指引》一文中明确规定对于“信息系统短时间中断会造成重大社会影响；或影响保险机构关键业务功能，并造成重大经济损失”这样的第一类要求最为严苛的信息系统，要求达到的RTO<=36小时，RPO<=8小时，可见这个离双活架构之下的RTO和RPO为0的差距还是很大的。另外如果从内部的架构设计来讲，部署异地的存储双活，那么数据中心之间的数据链路显然要有高质量，以免高IO RTT和链路抖动影响业务系统性能和稳定性。虽然说没人迫使我们做双活，但是无论什么时候，数据之于企业来讲始终是最重要的资产，所以综合考量这些因素，我们更多的做法是数据中心间做存储的异步复制，同机房存储之间构建双活。

不过，这里讲的更多的还是传统集中式存储构建双活的方式，在2.0时代，软件定义也带来了分布式架构。如Openstack框架下后端存储解决方案中最为流行的Ceph，Ceph在多台x86服务器之间构建同一对象的多个副本，实际上也是一种多活。这种分布式架构天然的双活显然比传统高大上的集中式存储双活来的便捷、来的实惠。