财务公司灾备项目常见问题解答.docVIP

财务公司灾备项目常见问题解答 马丁 西先生 X 关注成功！ 加关注后您将方便地在 我的关注中得到本文献的被引频次变化的通知！ 新浪微博 腾讯微博 人人网 开心网 豆瓣网 网易微博 作者简介：马丁 来自火星, 爱学习, 爱钻研技术。懂数据, 懂灾备。很直接, 不绕圈子, 很正经, 偶尔逗逼。目标是数据永存, 业务永续。我就是二次元小王子 作者简介：西先生 某财务公司CIO西先生。 西先生:要上灾备项目了, 可是关于灾备还是有好多不懂, 要是马丁在就好了…… 马丁:我来咯~ 西先生:亲爱的马丁, 我们公司要上灾备项目, 可有些问题还是一头雾水啊!首先想知道, 灾备系统的建设通常是指哪些?灾备管理指的又是什么? 马丁:灾备系统, 指的是建设物理 (硬件) 的设备和基础设施, 比如说灾备系统、两地三中心等。 灾备管理包括了容灾管理平台、企业的容灾管理规范 (比如应急响应机制等) , 是“软件平台+管理策略”的组合。 西先生:哦, 这样啊……那灾备系统所面临的核心问题是什么呢? 马丁:如果灾备系统的容灾管理复杂、低效、依赖人工干预, 当灾备系统最需要发挥作用的时候, 无论是业务团队还是IT团队, 在操作上都会蹑手蹑脚, 生怕在接管的流程中会出现问题、纰漏, 或其他意想不到的状况。 最终的结果, 就是谁都“心里没底”, 谁都“手上没准”。于是, 谁也不敢做出决定 (或者说谁也不敢担负未知的风险) , 原本可能是有效的灾备系统也就此变成了一个无效的摆设。 西先生:嗯太对了!我应该怎样避免发生这种情况呢? 马丁:第一, 设计理念。应该应用针对生产系统及数据保护的统一技术方案, 而不应选择仅对数据做保护, 或通过多种技术搭配实现对生产系统的保护, 这将大大增加系统的不确定性。 第二, 灾备设备选择。经过多年的市场宣传, 很多人认为生产系统与灾备系统选择同品牌的产品才是最好的。但事实证明, 只有选择专业厂商的产品才是正确的。生产设备选用高性能的存储系统, 灾备系统则应该选择专业的、具有快速写入能力, 空间大、性价比高的设备, 从而提高灾备整体方案的持续扩展性价比。 西先生:好嘞, 这两点我一定注意……另外, 很多存储厂商都会推荐使用存储复制或双活的解决方案, 我感觉也挺不错。 马丁:存储复制技术或存储双活技术主要解决的问题是存储层的HA功能, 即保证在主设备故障时, 副设备能够立即或微延迟地进行数据接管, 从而保证业务系统的持续运行。但该技术存在一定的风险, 即主存储数据故障时, 由于数据的同步机制, 副存储的数据也很可能是无效的, 这样一来就会发生整个业务系统包括灾备系统同时失效的情况。 西先生:额, 原来这样啊……那存储也可以通过快照机制来避免这种情况的发生吧? 马丁:生产级的存储设备会将性能尽可能投入在I/O请求的处理上, 在开启快照功能后, 不但要占用较多宝贵的存储空间, 同时还会严重影响存储性能。并且, 生产存储对于快照的持能则较为有限, 通常仅支持250-1 024个磁盘快照, 且最小间隔会在分钟级, 甚至是小时级, 可能性有限。 针对这种情况, 选用在灾备存储上实现永久保存的快照, 以及I/O级的数据保护机制可能会更有效。 西先生:看来还不是完美方案哦……那针对数据库系统很多人推荐我使用日志级复制技术, 这种技术有什么优缺点吗? 马丁:数据库日志级复制技术, 最有名的要算是Oracle的Dataguard, 其采用的是将数据库落盘的日志内容异步复制到灾备服务器中, 进行数据再写入的方式, 实现两端数据的一致性。 我相信会有人来质疑我说的异步问题, 他们会认为数据库日志级复制是同步完成的。但对于数据库, 数据落盘的同时会完成数据的写入操作, 再将落盘的日志内容加载至内存, 然后通过网络发送至灾备端, 灾备端接收后, 日志先落盘进行数据校对, 再将日志加载至内存, 再写入数据库中。而这一套操作完成后, 数据就已经落后生产系统一大段时间了。 如果一定要采用同步写入的方式, 有两种可行性:一是灾备系统与生产系统在同一个非常近的距离内, 保证网络时延绝对低, 但这会失去灾备的意义;二是能够忍受等待灾备端数据写入完成的确认信息, 这将严重影响生产系统的性能。 西先生:明白了。那最近很火的文件级CDP技术, 它有什么优势吗? 马丁:文件级CDP技术与数据库日志级同步有很多类似的地方, 即通过OS的API接口对写入的数据进行获取, 并且同样会在生产端留有缓冲区 (日志区) 以暂存变化的数据记录。 文件级CDP的同步过程也会经过“数据的抓取→记录日志落盘→发送至灾备端→灾备端数据再写入”的过程, 这同样是一个异步同步的机制。在应急情况下的数据一致性相对难保障。 另一个风险是在网络中断的情况下, 由于前段数据抓取的过程不会停止, 当记