2、同城,用于关键系统的双活,应对盘机故障以及机房级故障。
3、异地一般不会做双活,可以用改技术来做灾备。
2、其次要梳理实施双活的应用范围,双活可以带来业务连续性的保障,但同时也增加了架构的复杂度和运维的复杂性,不是所以的业务系统都需要做到双活。
3、第三,对需要做双活的业务系统进行架构分析,BS还是CS,有无负载均衡,使用什么数据库等等,分析的结果是要决定在双活架构中如何把这些因素都考虑进去。
4、双活的运维架构,如自动化切换系统,人工触发还是告警系统自动触发?两边的系统如何一体化监控?等等
5、组织架构或管理流程也要同步考虑,双活的两个站点必须要能一体化管理。
考虑到双活涉及到应用、网络、数据等多个维度,网络和数据方面容易解决一些,应用上如果是比较老的系统有些不支持分布式部署或域名访问的,所以,整体考虑,核心系统更换或改造时比较适合同步建设同城双活,这样,在前期从应用出发按照双活架构来进行规划设计,后面只需要按规划分阶段实施。
注意事项有以下几点:
1、应用必须支持分布式部署架构,并支持使用域名访问数据库。
2、生产机房和同城灾备机房链路质量要有一定保障。
3、根据监管要求,按照业务等级来规划方案,不同的等级采用不同的保护策略。
1、存储双活对应用层没有要求,存储双活从层次上来讲,有几种实现方式。
一:存储层(SAN存储或NAS存储)自身,体现为免网关双活的存储设备;
二:SAN网络层,存储网关,代表性的:VPLEX,SVC等;
三:卷管理软件层,代表性的LVM,Veritas的SF(现在不叫这个名字了)等,其实广义上,我认为可以将ASM也可以划分为第三种方式,只是这种只适用于有限Oracle DB的场景
2、真正的双活应该是多层次的,分别对应的是容灾的6个级别(中国标准),国际标准是7个级别的,存储双活只是最底层的,其他的还包括传输层、网络层(含负载均衡)、计算层、应用层、数据库层、安全层等。
2、本地高可用和同城双活在技术上还是有较大差别,需要重新设计方案的,比如本地HA机制一般需要心跳线来保障,而心跳机制是有网络延时限制的,也就是说有距离的限制,不能适用于同城这样的距离上。
3、应用系统的同城架构建好后,各自承担多少负载要看所建设的双活模式。如果是AS模式,那么同城机房是不承担业务量的。如果是AQ模式,可以把一些纯查询或报表类业务放在同城机房。如果是AA模式,理论上每个机房是可以承担50%的业务量的,当然要看两个机房资源配置是否对等了
双活部署在同城跨双中心模式时,中间传输链路故障的发生,是不可避免的事情。
唯一能做的就是,确保仲裁在第3站点是独立部署,确保在脑裂时候,可以正确的选择出其中一个站点存活。
一种比较简单的方式按区域分片,比如南方片的用户流量导入A中心,北方片的用户流量导入B中心,各自访问自己的记录,这样可以减少一部分数据冲突,但不彻底。
比较好的做法则是需要应用侧精心设计,同一应用在不同中心实际上业务类型不完全一致,比如一个购物系统,商品页面流量全部导入A中心,购物车流量全部导入B中心,访问的是不同表,zhe yang可以最大限度减少数据冲突。
1、Oracle dataguard,带宽根据数据量大小可选择2MB-20MB专线。
2、第三方备份软件,如veritas NBU的AIR技术可将数据复制到异地机房,带宽根据数据量大小可选择2MB-20MB专线。
3、在生产机房将数据备份到NAS存储介质上,借助NAS存储设备的复制功能将数据同步到异地NAS存储设备上,带宽根据数据量大小可选择2MB-20MB专线。
以上,可根据场景和需求选择相应的解决方案。
双活模式下,也要加强数据备份的管理工作,最好有统一的备份系统,平时做好恢复演练。
2、重点关注的还是类似数据库这样的非负载均衡数据库,切换时要综合考虑,比如从主站点切换到备站点时,要考虑应用服务器连接到数据库服务器的配置变化。
3、CS模式和BS模式切换时会有所不同,BS应用一般采用域名访问,但CS应用一般配置IP地址,在发生切换时要特殊进行处理。
4、此外要注意,切换的方案中真正的故障切换和切换演练会是两套方案。
联系客服