- 1、本文档共21页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
?
?
保险行业长期数据保存技术方案
?
?
数据作为保险企业最核心的资产需要长期有效的保存,保险行业集中交易等核心数据更需要得到长期的保存,以便后期审计和溯源。目前,各家保险行业的集中交易等核心数据主要保存在高端集中存储阵列,格式化数据存放于SAN存储,日志数据主要存放于NAS存储中,超过10年的日志数据归档于磁带或者磁盘中。随着数据量越来越大,非结构化数据呈现爆发式增长,现有技术方案和架构出现了一些痛点:非结构化数据存放于传统集中式存储会造成一部分性能的浪费;数据量爆发式增长后扩展困难;数据未分级管理容易造成数据混乱……针对以上痛点,保险企业需要尝试用新技术、新架构解决当前的问题。技术路线选型多样化:NAS文件、对象、分布式、光盘、磁盘等等多条路线,需要根据数据类型进行选择,以及在追求数据存储性价比的同时,保证数据的长久安全存储,能进行数据的分级管理,在线数据、近线数据、离线数据分开管理,能最大程度的发挥存储的性能。社区上个星期组织了线上交流,围绕“保险行业核心数据长期保存技术方案应该如何选择”,特别邀请保险行业专家和戴尔科技的专家和众多保险行业同行一同参与,本文是本次活动中大家分享的精华内容梳理总结,包括四个方面:保险行业分布式存储选型与容量规划、如何实现保险行业的数据长期保存,如何实现保险业务数据分级存储与灾备,以及活动达成的共识,希望给保险同行实现长期数据保存技术的过程带来帮助。
通过本场交流活动达成了一些交流共识如下,仅供参考:
1)?保险行业存储产品的选择要围绕业务需求来规划,从业务入手,综合考虑数据的类型、负载压力、数据量、对数据访问时延要求、成本等等综合考虑。
2)长期保存的数据使用频率最多的那一少部分数据存储在高端集中式闪存阵列、本地NVMe磁盘等;中频访问的数据放到HDD存储或SSD+HDD混合存储上;低频离线数据放到磁盘、光盘或是磁带存储。
3)?保险业务在线数据为高频访问,或者对数据的消费存在极短的响应时间要求的;近线可存在一定的时间容忍度,为非实时交易;离线数据访问频率极低,通常用于数据备份、或长期极低频访问场景,如备份数据。
4)根据保险监管要求,重要客户数据都必须异地灾备,客户影像资料文件也属于需异地灾备数据。
一、保险行业分布式存储选型与容量规划
保险行业存储产品的选择要围绕业务需求来规划,从业务入手,综合考虑数据的类型、负载压力、数据量、对数据访问时延要求、成本等等综合考虑。
1、分布式存储建设中的问题,硬件兼容性,同一集群扩容中的硬件兼容性?
【问题描述】分布式存储建设中的扩容遇到的问题:因为时间不同硬件设备发展的不同,因此扩容时就经常遇到原来的硬件已经升级了,而硬件升级后就有了对兼容性的要求,固件、操作系统版本、内核都有了区别,对于分布式存储的建设就带来了挑战,因此有没有什么好的办法或者厂商能解决这个实实在在存在的问题。同一分布式存储集群中能否兼容较新的硬件,对分布式存储运行稳定都是一个挑战,现实中已经遇到过类似问题。
@zhangleo某大型保险集团高级工程师:
1)现在分布式存储基本都支持不同配置的设备组成一个资源池;
2)也是组建不同的硬件资源池进行统一命名。
@bai030805戴尔科技?高级系统工程师:
在对象存储方面,Dell的ECS产品的软件是可以兼容不同代的硬件的,可以允许不同代的硬件在一个存储池中。
@asuro太平洋保险?系统架构师:
硬件伴随着摩尔定律快速更新和迭代,将不同时期的硬件混建在一个资源池内会导致木桶效应,不能充分发挥新硬件的性能和特性,也会引发兼容性问题。所以,通常情况下会将不同的硬件组成不同SLA的资源池,按需进行分配和数据迁移。
2、分布式存储、对象存储的容量管理?
【问题描述】对于对象存储、分布式存储的容量,如果有效地管理容量、预估容量,多副本、纠删码等等细节的管理,以上相关的参考、规范及经验,以及相关指导。
@qixiaoding戴尔科技?架构师:
选好基础架构,一些技术限制无法避免,就要先有预期。
比如,hadoop选了3副本,再通过应用做了容灾。实际至少要有6副本保证这个数据合规。
但是,厂商的技术和开源的技术是不一样的,商业化产品有自己的纠删和副本选择,兼听则明。
容量管理有几条水线,自己要提前设置好。
我们通常建议将90%设为红色告警线,即容量严重不足,无法应对突发场景,必须马上扩容,这里说的是马上,而不是按传统的半年为周期的采购流程。
还有,我们一般也不建议设置硬的容量使用限制,如果设置了,可能带来不必要的维护工作。
3、对于分布式存储的选型,有什么标准、建议以及避坑经验分享?
【问题描述】要进行分布式存储的选型,在项目初始界面,有什么标准、建议以及避坑经验分享?
@amanyzes系统架构师:
存
文档评论(0)