存储双活保险业双活架构设计

保险行业存储双活架构设计及技术路线选择

保险行业存储双活架构设计及技术路线选择

活动简介

保险是金融系统领域的重要分支,保险公司的健康运营是对社会、国家的承诺,是对亿万被保险人的责任!因此在做好保险产品的同时,险企更要注重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服务器之间构建同一对象的多个副本,实际上也是一种多活。这种分布式架构天然的双活显然比传统高大上的集中式存储双活来的便捷、来的实惠。

在本次的存储双活在保险业交流活动中,我们想广招同行和各行业的伙伴们共同探讨企业存储架构的设计路线。希望大家可以擦出火花,以下问题可以作为引子,激发大家的智慧:

1. 大家都谈谈自己公司目前存储的架构现状,停留在x.0时代以及未来的存储架构演进roadmap?

2. 存储双活在你们那儿是怎么做的?日常运维中是否有很多坑儿等着你去跳?

3. 分布式架构和软件定义显然已经成为大势所趋,如何做好技术的推演和平滑过渡?

4. 随着保监会“双录”发令枪的打响,对象存储近来在保险行业貌似要呈现“井喷”式的增长,面对如此热潮,你们做了哪些准备?

主题资料

全闪存阵列助阵保险新系统建设

张万雷张万雷系统工程师, 高伟达软件股份有限公司
全闪存阵列助阵保险新系统建设为了提高数据中心资源的利用和管理效率,在进行基础设施选型和方案设计的时候,就要求我们为客户设计更加高效、可靠、稳定的基础架构平台。本次活动我们便以某保险公司借助IBM FlashSystem所设计的存储系统架构方案为案例与大家进行分享。

嘉宾

ibmfuqiang
系统架构师IBM
擅长领域: 存储灾备分布式架构
发布67
回答59
zp_ccc
zp_ccc1615
高级技术主管国内某金融科技公司
擅长领域: 存储灾备服务器
发布3275
回答1593
jxnxsdengyu
系统工程师江西农信
擅长领域: 存储灾备双活
发布1447
回答1020
qq373793057
系统工程师某银行
擅长领域: 存储灾备分布式系统
发布314
回答179
goodbyezwl
系统工程师高伟达软件股份有限公司
擅长领域: 存储安全闪存
发布59
回答46
lzg21st
lzg21st41437
存储工程师brcb
擅长领域: 存储灾备分布式架构
发布420
回答290

活跃参与会员

  • longlw
  • liutaozhen
  • ce97
  • s20040521
  • fendou92
  • xtfw7945
  • 张全
  • ibmfuqiang
  • wangshuai_go
  • Super_Liu
  • 老赵
  • engliah12
  • amolexcompany
  • clclifu
  • sunyan19880523
  • jialiuele
  • mxin
  • zwz99999
  • zp_ccc
  • pysx0503
  • baochengchen
  • 少东家
  • nkj827
  • niechun
  • aix7
  • wangmj
  • wuwenpin
  • jxnxsdengyu
  • loverandom
  • lzg21st
  • ttkanni
  • skyping
  • sxtycxx
  • zhutu
  • cft18
  • 唐唐大人
  • 洋芋2333
  • 长诗佐酒
  • michaellhb
  • Garyy
  • Qiangz
  • 程老师
  • aixchina
  • 晓黎
  • saudi
  • gz_kevin
  • hbm8888
  • penguin23
  • quansheng
  • sony389
  • tcq0086
  • study123
  • my979899
  • yulu4314
  • zrosiness
  • tyrande
  • qingyun1208
  • weiliang1216
  • weiruan85
  • briankle
  • xzbd000
  • liguaren
  • hudingi256
  • jiaxu2000
  • yritech
  • sakidodo
  • jy00810061
  • UNOX
  • ct_hg_cool
  • faye
  • 行成
  • power8
  • mzjmzjmzj333
  • aigoppb
  • QaSanil
  • hebingbingsx
  • mycortex
  • aixkevin
  • ds8K
  • qysong
  • xukaishi
  • wjs_luna
  • 彬彬
  • xijiehaiqing
  • EndlessRain
  • yinxin
  • 大大觉迷
  • micalafei
  • cnboom
  • 798683133yj
  • iciest
  • mornsky
  • bingwangzi2500
  • lc905
  • gpfs
  • 梵人
  • vamenyi
  • wzpystcdc
  • chenmingfu
  • ynkmtang
  • aelous
  • wsbj123
  • 韩斐
  • 小魔神
  • oldpear419
  • 吉祥嘻嘻
  • SkyWalkerDy
  • dx_958
  • w1042802321
  • gaopin
  • linux_zcy
  • 金椋
  • anonimous
  • 刘刚
  • bryan_zhy
  • foxsilver
  • aircox
  • Roy
  • gpfs1
  • haonan
  • katong
  • ethany_ang
  • JAGXU
  • abczycx
  • lifans
  • nikkordong
  • wangyeye
  • dhjt
  • skms
  • khms
  • user1
  • doc
  • zf110
  • 夏卫东
  • wangyunjin
  • h382410221
  • lwto
  • bankinfo
  • wisdomone1
  • lktianxia
  • jad
  • haijiang
  • blgyes
  • luxiaojun
  • AIX萌新
  • gjlsam
  • huaweitac
  • boy_hxm
  • qikui1250
  • datou1984923
  • 蒋啸
  • shenjie001
  • jaden_1989
  • Vi
  • zhanglj
  • ouou1000
  • hhucwhy
  • libai21
  • clock0120_cn
  • QUACHESS
  • alpha17
  • 王立新
  • kernelry
  • cpc1989
  • guoxilin
  • 旺旺811003
  • 孟威
  • everboy99
  • lostbacker
  • sunday7411
  • qlinfo
  • conu
  • lihuizhi
  • shendaoshu
  • fengyun1
  • congui
  • 去世的闲人
  • dnyu2017
  • yangzhihuai
  • baimmi
  • pysx05031
  • 邱倪慧珠
  • youyouwoxin888
  • 智诩
  • 王磊磊
  • 时东南
  • Sangfor
  • 黄呆毛
  • airstuky
  • James_Liu
  • zhuhaiqiang
  • itjava
  • yi1982523
  • 挚爱咖啡
  • 邓凡心
  • 罗右阳
  • 谢霆锋爸爸
  • gossipyboy
  • sukie
  • seaman_bin
  • 甘草片
  • a414356153
  • vivilion
  • twt_1706
  • 建奎生
  • hansxq
  • law12
  • zhangyj_bj
  • YTXYGG
  • Vicente
  • merming
  • mileskuo
  • telepathiq
  • 冯磊
  • yummy0409
  • skywq516
  • shipeng
  • dgl_2005
  • Houbaofei
  • twt_jad
  • cppcc
  • jiaomc
  • styongge
  • kashin9
  • linterminal
  • boriswang
  • 刘悦炀
  • 匿名
  • 邢万里
  • fhff23
  • sunlightrain
  • hottpost
  • wangheqiao
  • gary007
  • litdong
  • zhangpeng张
  • qingjingmilk
  • zxycs888
  • 叶落在盛唐
  • skyhualu
  • AidenC
  • 网络小白
  • lihongtao_Z
  • xrestart
  • hs1199
  • zmmoszs
  • 小喵喵200812
  • teesp
  • 分享艰难
  • jianfeizhang
  • wangyunpu
  • hfboss
  • Charlesyan
  • 沈刚
  • zhuangxinkai
  • maxsong
  • zswqyz
  • good_Knight
  • Newbieofit
  • cllin_kiki
  • Tianxiayu
  • 益峰
  • Hitman
  • lsh_twt
  • 虚空神主
  • Shawn严肖
  • 顾黄亮
  • xiaosko
  • 非强力MT
  • NSTcisco
  • comme2010
  • guoyajing
  • boney89
  • liuhuowu
  • 李静12138
  • XSKY星辰天合
  • chpps2000
  • mllteal
  • funy
  • jz
  • Julien
  • djl2020
  • Alicehu
  • 落花有意流水
  • 樹想
  • 网上邻居
  • 凡舒
  • Eleven11馨
  • wsjiejun
  • M3T
  • goober
  • XX_20220103
  • rootk
  • X社区推广