在信息化不断革新的新时代,企业 面对新的业务场景需求,容灾备份技术也需要有 新 的思考。 互联网元素不断融入传统IT,企业不断引入属于自己的 大数据 平台,公有云逐渐开始走进企业的某些业务场景。简言之系列的信息化变革导致了企业数据在数目量级、结构形态、流动轨迹等各个方面的质变。 面对这样的场景,本次活动围绕企业新场景下的容灾备份需求,探讨项目建设的必要性方面以及项目建设过程当中的技术架构及策略运用方面的关键问题。 总结如下:
一、 面对大数据的海量数据,如何考虑备份系统的规划建设?
有人从整体策略提出问题,例如“ 大数据平台有什么好的备份策略? ”;有人从数据量与成本的平衡角度提出问题,例如“ 数据备份成本过高,这种类型系统该是否该备份,如何备份? ”;有人从微观技术细节提出问题,例如“ 大数据平台当中的碎小并且海量的非结构化数据,如何考虑备份? ”
梳理各方观点汇总如下:
首先,大数据业务的引入,导致数据发生了以下几个变化:
正是因为以上这几个特点并存,很难有一个万能的备份平台来完成对大数据平台内所有数据的备份恢复工作。所以对于大数据平台内的数据 备份 ,需要明确 几 个问题:
其次,针对具体的细节技术问题“ 碎小并且海量的非结构化数据备份 ”。
从备份技术本身考虑, 海量小文件的备份之所以成为难题就是普通的复制方式的备份,在备份之前需要扫描所有的文件头信息,一旦这个量达到一定级别,这个扫描就花费了很多很多的开销,导致备份无法进行。通常解决方法:基于NDMP技术的备份工具。 其原理就是靠着镜像、快照的方式在较短时间内备份大量文件。为目标文件系统创建一个固定的快照。在备份期间就直接备份这个快照。例如: 应用IBM V7K、INSPUR AS5600G2、IBM SVC等硬件实现Metro Mirror同步卷复制。
从备份规划处理角度考虑, 我们可以从业务层对这些海量的小文件的分类和归属进行良好的规划。比如可以按照日期、应用分类、地域属性等等,这样就把这些海量的小文件切分成若干部分,分而治之。调整文件生成策略,达限压缩,也可外挂程序处理压缩;调整备份策略,先压缩后备份,这条在时间开销上应该效果不明显,多次读写会比较明显;生成即备份,应用OS的卷镜像,无法使用磁带备份,甚至都不需要备份软件,缺点是如果用低端存储,可能会形成短板影响整体的运行效率。
二、灾备架构下,如何考虑容灾备份建设的关键问题?
有人从备份原点及数据流向角度提出问题,例如“ 直接对灾备系统进行备份,还是把生产系统的备份数据传输到灾备中心? ”;有人从管理角度提出问题,例如“ 部属在“多地多中心”的系统是一个管理员横向运维,还是由分布在多地的不同人员分别维护? ”;有人从必要性角度提出“ 双活容灾架构下的备份还有没有必要? ”。
梳理各方观点汇总如下:
首先,从必要性上来讲,双活是容灾的概念,解决的是物理层面的错误。比如设备故障、链路中断、水灾火灾等等。备份主要是解决逻辑层面的错误,比如说认为的误操作导致的数据丢失或者错误。我们可以通过备份将数据回退到某个时间点。就像Oracle 虽然有 RAC 的集群架构来解决高可用的问题,但是它还是要设计闪回的功能来解决数据回退的问题。因此,备份和容灾缺一不可。
其次,从备份的原点和数据的流向上来看,至于如何定义,要从架构上来讲。 如果是同城双活架构,理论上两边都一样,但是实际使用的时候,总会有主有次,主的多一些写,次的多一些读,因此建议在次端进行数据备份,然后回传主数据中心。因为数据都是实时同步的,从数据有效性完整性来讲,都是一样的。但是为什么建议次端备份呢,因为备份会影响正常读写业务的性能。如果是主备架构,那么两边是不一样的,数据是异步复制的。灾备端备份的数据一定不是最新的数据。因此为了保障数据的实时性,建议从主中心备份,然后传输到备中心。如果互为主备的架构,也可以搞一套跨数据中心的备份体系,将备份压力分散在不同的数据中心。
然后,从管理角度来讲,多数认为无论是双活数据中心还是两地三中心,控制应该是集中的,但是运维管理应该是分区的。也就是说,横向不同数据中心区域都应该有局部的运维管理,但是所有的横向局部管理又要受主中心的集中控制。
三、 混合云架构下的容灾备份建设,因该如何考虑?
有人从安全性角度提出问题,例如“ 公用云方案的安全合规风险? ”;有人从传统和云架构的对比角度提出问题,例如“ 传统架构和混合云架构下,容灾、备份的对比? ”;有人从不同行业建设角度提出“ 保险行业的混合云架构下的灾备? ”“ 在分布式多云化、容器化的大背景下什么才是金融行业的IT灾备最佳实践? ”。有人从管理角度提出“ 在多云环境的备份和容灾,如何更好的实现统一管理? ”
梳理各方观点汇总如下:
从数据的安全合规性角度来看,金融行业还是要看监管要求,如果符合监管的要求,同时企业自身又充分评估了风险。那么就可以尝试公有云资源的利用。例如:保险行业采用混合云架构的相对多一些,银行业就很少。究其根本原因还是行业监管要求以及数据本身对安全合规的具体要求不同。但是利用公有云的价值不在于灾备,之所以有很多企业要把私有云和公有云打通,搞一个混合云的架构主要是看中了公有云的灵活性和扩展性,以及对公有云数据的价值挖掘。所以单独为了灾备搞一个混合云架构,个人觉得意义不是很大。
从容灾备份架构的对比区别角度来看,没有具体案例的情况下,只能泛泛而谈。混合云架构下,对于可以在私有云和公有云之间漂移的应用,那么它们的容灾和备份更多的是依赖公有云。应用请求从互联网进入,公有云与私有云之间的路由切换和数据同步是关键,规划设计之初更多的是依照共有云的容灾服务标准和接口来对接私有云的接口设计。备份可能更多的会放在公有云侧。传统架构下,容灾主要考虑自有的两个或者三个数据中心之间的网络路由、应用切换、数据同步、仲裁判断等系列问题的设计。从各个层面都需要选择相应的技术去完成相应的切换和恢复功能,同时需要考虑上下层之间的联动问题。备份自然是以一个数据中心为备份点,其他数据中心异步传输副本的方式了。
从金融行业的容灾备份建设角度来看,首先,金融行业的IT灾备架构,在不同细分的行业当中有不同的特点。比如银行还是以两地三中心为主,保险在传统架构的基础之上在探讨混合云的架构,其互联网元素更多一些。有一些纯粹的互联网金融企业,其架构那就是纯粹的互联网基因了。因此,探讨金融行业的IT灾备架构,还是要进行行业细分。其次,从大的方面来看,IT架构无非就是传统架构和互联网架构两大块。论证其容灾架构的时候,从网络、应用、数据等各个层面来看,都要将其分为两个大的框架范畴。先把数据中心边界的轮廓勾勒出来,然后需要根据不同的业务系统分别去分析其容灾架构如何嵌套在大的轮廓当中。对于保险公司来讲,一部分应用系统属于传统的业务,并且一直会延续它的运营模式。这部分业务还是要将数据保留在自己的私有云当中,按照传统的灾备架构去规划建设。还有一部分业务是需要利用到公有云途径获取到的海量数据进行客户分析,以实现其精算和精准营销。这部分业务系统是需要混合云的架构,那么这部分业务系统的灾备就要依赖于混合云架构下的多云做灾备了。 应用请求从互联网进入,公有云与私有云之间的路由切换和数据同步是关键,规划设计之初更多的是依照共有云的容灾服务标准和接口来对接私有云的接口设计。备份可能更多的会放在公有云侧。
从容灾备份的统一管理角度来看,首先,需要整合近线数据备份、远程数据复制系统的各类信息,以应用为视角,展现数据保护架构,实时监控数据复制作业,严审数据副本。其次,备份系统集中监控分析,针对近线备份系统,实现备份设备(TL/VTL)、备份网络(SAN网络)和备份系统(NBU、TSM等)的集中监控(硬件监控、网络监控、备份任务监控)和分析(健康度分析、容量分析、流量分析)功能。然后,备份系统与云平台对接,现有的云平台在给客户提供资源服务时,需要同时为客户提供备份服务,而传统备份系统并不具备这种接口。例如,OneSRM DPM通过自动部署备份任务的方式,实现传统备份系统与云平台对接。
四、 容灾备份规划建设过程的一些关键问题?
有人从备份数据的有效性提出问题,例如“ 如何开展备份有效性检查工作? ”;有人从建设思路上提出“ 现代信息化的数据备份和容灾是作为信息化的安全保障还是应该成为一个独立的系统? ”
针对备份数据的有效性问题,梳理如下:
总体认为,恢复是检验备份的标准,恢复包括本机恢复和异机恢复,本机恢复不可以做,但是异机恢复可以经常做,从而可以检测我们备份过程是否有效。延伸来看,需要做好以下几项工作:
1、定时做好备份数据验证与演练计划安排。
2、备份介质冗余最好规划为多副本与多冗余机制有机结合。
3、备份软件方面能做到备份策略所备份数据的介质是否有效性,可用性。
针对容灾备份的独立性问题,梳理如下:
整体而言,从前的数据备份数据备份和容灾系统基本作为基本作为单独的个体个体,随着业务连续性和监管要求和越来越来越严格,备份和和容灾容灾在在建设建设项目初期就要考虑到到,所以作为一个整体来进行进行规划。
就备份而言,它已经不再是一个孤立存在的系统了。备份系统不再是简单的数据或者关键配置的备份了,而是已经纳入集团级的信息安全平台,并入数据安全板块,进行集团级的平台化管理和运维。主旨思想就是提供备份中台的概念,任何分支想备份数据均要通过总部的平台进行登记、下发策略、备份数据。但是为保障数据的安全性,我们实现了异地数据存储,管理统一集权。实现了一个备份池的概念,任何系统有备份需求只需要安装相关的备份终端即可,不用关心数据的存储物理位置及空间等信息。随着数据安全法的落地,作为企业数据的最后一道生命线,备份系统至关重要,算是信息安全中数据安全的模块。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论0 条评论