自动化运维管理中的灾备方案.docx

自动化运维管理中的灾备方案.docx

《自动化运维管理中的灾备方案.docx》由会员分享，可在线阅读，更多相关《自动化运维管理中的灾备方案.docx（8页珍藏版）》请在冰豆网上搜索。

自动化运维管理中的灾备方案

自动化运维管理中的灾备方案

运维路漫漫，风险千千万，任何系统故障或是硬件故障都有可能导致系统不可用、数据丢失、数据恶意篡改等风险。

风险一旦发生，会对企业造成巨大乃至无法挽回的影响。

所以设计一套良好的企业IT灾备方案，是保障企业IT系统可用性和数据安全必不可少的重要途径。

良好的灾备方案和有效的实施会将企业因IT故障导致的损失降至最低。

那么该如何设计企业灾备方案呢？

这还是要综合考虑企业的IT规模，成本和人力三个基本要素，结合企业自身情况，进行有重点的方案设计和实施。

一、灾备平台总体架构

相对比较合理完整的灾备平台大概架构如下：

灾备平台在条件允许的情况下，可以采取两地三中心+云端的方式。

公司所在地同城自建或是租赁两个机房，这两个机房之间的数据或是文件以实时同步的方式实现两个机房的实时热备。

在另一个城市租赁或是自建机房，一般两城市间距离最少300公里。

异地机房跟同城的两个机房采用延迟同步或是手动同步的方式存储IT系统、文件和数据等。

一般异地机房是用作同城机房的系统冷备和备份集存储，尽量不要做与同城机房数据实时同步：

避免同城机房数据、文件删除或是恶意篡改，导致异地机房实时同步数据也不可用。

比较经济的方案是可以在异地机房租赁服务器，存储同城机房的备份集和核心系统的冷备。

另外根据公司数据的保密程度有选择的采用云端服务器进行备份集存储或是系统冷热备。

灾备平台建设总的指导思想是：

高可用+备份。

高可用可以是热备（即只有一台服务器提供服务，另外服务器静默，出现故障后自动切换到静默服务器）也可以是集群方式（集群中的服务器全部对外提供服务）。

总之避免单点故障，出现问题后自动切换至正常的设备或是系统上。

二、高可用—机房、网络和硬件

建立灾备平台首先是机房、网络和硬件的高可用。

总体架构中的多机房+云端可以实现机房的高可用。

网络和硬件的高可用具体如下：

1、双电源，多链路

机房除了必备的UPS备用电源之外，还必须实现接入硬件设备如：

交换机、物理机等设备的双电源。

这样可以避免掉电引起的故障。

另外接入的双电源需要插在不同的插排，避免插排故障。

多链路是指机房接入多种供应商的网络，避免光缆挖断或是供应商网络故障引起的大面积网络故障。

另外不同链路的网络接入进来也可以提高系统对外在不同网络环境下的访问速度。

2、防火墙

防火墙一般采用不同厂商的至少2套组成防火墙的高可用，避免防火墙的单点故障，导致外网不能成功接入内网。

3、存储、服务器

一般大的存储厂商都有成熟的数据同步和灾备管理的方案，所以存储一定要选择大的厂商，如EMC、惠普等。

另外存储一般情况下尽量避免选择多厂商。

因为不同厂商之间的存储产品不太好实现存储级别的数据同步和镜像灾备等。

关于服务器这里推荐企业实现虚拟化，通过虚拟化软件，实现服务器的高可用。

虽然不同的服务器和操作系统厂商提供了各种各样的集群方案如RHCS、windows的WSFC等，但是实施起来比较复杂且增加IT成本。

采用虚拟化既可以节省资源，也可以实现只采用虚拟化的集群解决方案就可以避免服务器的单点故障。

例如采用vSphere的HA，可以实现一台物理机宕机，该物理机上的虚拟机实现自动切换到另外正常的物理机上。

4、备件库

备件库在灾备平台建设中往往是最容易忽略的一个重要因素。

随着使用时间的增长，机房中的硬件会有这样或那样的故障，如果没有替换件及时更换硬件故障的话，从供应商的备件库提货到现场，会导致大大增加IT故障时间。

备件库涵盖机房中的所有部件的方方面面，包括电源、服务器内存、CPU、HUB、路由、交换机等等，也包括网线、电话线和插排等部件。

机房管理，灾备管理中一定要清点清楚备件库的物资，出现紧缺，一定要及时补充完毕。

避免硬件故障增加额外的IT故障时间。

机房、网络和硬件的高可用和备件是灾备方案的基石，一定要根据企业自身的情况和IT投入成本进行规划和设计，避免大范围和长时间的硬件故障。

三、高可用—应用、DB、文件

机房、网络和硬件属于硬层面，接下来分享一下软层面的一些高可用的方式，主要包括应用、数据库和文件服务器。

应用、数据库和文件总体来说采用集群或是主备方式部署，避免单点故障。

另外负载均衡和反向代理的使用也可以减轻单节点的访问压力和提高内网服务器的安全。

1、应用高可用

很多企业可能直接把应用服务器如Tomcat、Weblogic等直接映射到外网IP，这样如果需要部署多台的话，需要做多个公网IP的映射，并且难以实现访问的负载均衡，由于出现故障需要手动切换，故不能算是实现了高可用。

采用反向代理服务器的方式如Nginx、Haproxy既可以实现反向代理，也可以实现负载均衡，并且可以节省公司的公网IP资源。

每一组应用至少部署两台不同的虚拟机上，避免应用的单点故障。

资源比较紧张的情况下，可以实现交叉部署，例如应用A1和应用A2部署在虚拟机VM1和VM2上，应用B2和应用B1也部署在与A1，A2相同的虚拟机上，统一虚拟机多应用，每个应用又在其它虚拟机有部署，避免单点故障还节省资源。

但是要注意，一般业务量比较均衡的不同应用可以交叉部署，业务量比较大且核心系统还是要分开部署的。

2、数据库高可用

不管是Oracle、还是MySQL或是SQLServer都有较多且已在不同公司的生产正常运行的高可用和集群方案，这里简单介绍一下Oracle、MySQL和Redis。

Oracle高可用

Oracle比较常见的高可用方案主要是RAC+DG。

其中RAC可以实现负载均衡和单点故障。

一般部署方式RAC的两个节点挂载同一存储，存储方面存在单点故障的可能。

由于RAC主要是做负载均衡，不太好实现读写分离。

可以采用搭建RAC的DataGuard实现RAC的数据实时同步到standby数据库中。

另外standby可以对外提供只读操作，实现读写分离，减少主库RAC的压力。

另外OGG即OracleGoldenGate是Oracle做数据同步的另一主要解决方案。

OGG也可以实现异构跨平台的数据同步。

MySQL高可用

MySQL的高可用方案也比较多，比较常见的有主从复制、MHA、MMM等。

另外不同的MySQL厂商也提供了不同的基于MySQL的集群Cluster方案且都有生产实施案例，如GaleraCluster、Percona的PXC和MySQL官方的Cluster等，都可以实现MySQL的高可用集群和读写分离。

另外MySQL也有众多的中间件如MyCat、OneProxy等可以很容易地实现读写分离和分库分表、分布式等方案。

Redis高可用

一般IT系统架构使用Redis主要两大用途：

共享Session存储和缓存数据。

Redis的高可用架构一般主要两种：

哨兵模式的主从和Cluster集群。

上图为Redis的哨兵模式，通过哨兵监控，实现故障后自动推举master。

Redis Cluster是Redis3.0以后推出的，截止目前生产应用的也已经比较多。

3、文件高可用

在系统架构中，一般文件服务器作为单独的服务进行部署，主要存放文件、图片、App应用上传的附件等。

有的时候也把静态资源放到文件服务器中。

有的公司会选择自建文件服务器，也有的会选择云服务，如阿里云的OSS等。

我所在的公司主要考虑到数据和文件的保密性，采取了自建文件服务器的方式，主要采用了FastDFS这一开源框架进行搭建。

采用三台服务器交叉部署三组Tracker+Storage，为公司所有IT系统提供静态资源（主要包括文件、图片）读写服务。

上面主要介绍的软硬方面的高可用和硬件备件库等，接下来介绍灾备平台的另一个重要的组成部分——备份策略。

系统只实现高可用还是不够的，尤其是灾难性故障的时候，包括数据被篡改，只有高可用，没有备份集也是无济于事。

一些核心系统如果没有有效的备份，那么在灾难性故障面前将真的是灾难性。

四、备份策略

备份策略总的大概分为：

备份周期、存储位置、恢复策略、验证策略四大部分。

1、备份对象

备份策略首选要确定备份对象，并且根据优先级逐步实施。

备份对象涵盖IT系统的方方面面，从前端应用到后端数据库，从系统层面的虚拟机备份到服务器上的具体某一个文件，都是我们备份的对象。

一般来说备份虚拟机和备份应用是有重复的地方，但是多管齐下，做到最可靠，这样的代价就是由于重复备份集存储，提高了IT的存储成本。

2、备份周期

备份周期一般以周为单位，周三和周天全备，其它时间增量备份。

全备+增量备份可以节省一部分资源，也提高了恢复的速度。

虚拟机层面一般采用虚拟机全备的方式。

另外将备份删除策略定在备份周期里。

根据系统的重要性和要求，定期删除一些过期的备份集，释放存储资源。

3、存储位置

备份集的存放本着多处存放的原则。

一般在本地服务器存放一份，机房内备份服务器或是NAS存放一份，异地机房存放一份，根据备份集对象数据的保密性，有选择的在云端存放一份。

多地存放，降低了备份集丢失的可能性。

4、恢复策略

恢复策略包括恢复方案和恢复脚本。

二者结合，要求准确有效的说明备份集的恢复方法和方式，并且需要记录恢复的大概时间。

5、验证策略

有备份，就一定要验证，而且要定期验证备份集中的每一个备份的可用性。

制定并实施持续完整的备份验证策略，是保证备份集可用的最佳途径。

在验证备份集的时候，要根据恢复策略的脚本和方案进行恢复验证，并且记录验证时间。

做到故障后心中有数。

五、应急演练

应急演练作为灾备平台的一部分，主要模拟一些灾难性故障的响应措施。

例如服务器宕机，该如何通知汇报，如何进行排故恢复等规章流程和制度的演练。

验证策略以时间为标准验证每一个备份集的准确可用性。

应急演练时根据系统的优先程度，对重要的核心系统进行应急演练，避免出现故障手忙脚乱。

灾备平台的建立和实施是一个漫长持久的过程，可以先从最简单的备份开始。

手中有备份，一起故障皆可从容面对。