公司灾备方案
- 格式：docx
- 大小：16.81 KB
- 文档页数：10
企业灾备需求 某企业众多的业务系统中，由于前期都是分批进行搭建，每年产品选型也都有变化，业务系统的主机包括windows、linux、unix系统，存储产品也包括了IBM、EMC、HDS等，在面临众多产品及不同的生产环境时，灾备的需求需要进行细致的分析，其中包括以下几个步骤：
1、 灾备咨询 2、容灾技术选型 3、生产系统整合 4、灾备系统投产 5、演练 1.1.1 灾备咨询 建设初期需要对生产系统进行全面的调研，不仅仅包括硬件信息的收集，更包括业务风险分析，业务关联性分析等。
通过对现有系统数据的收集，充分分析现有生产系统面临的挑战，以及生产中心所处位置的地理、天气、社会环境进行充分的分析，最终对同城灾备中心及异地灾备中心的选址给出合理的咨询交付物。
业务关联性分析方面需要跟业务部门进行沟通，梳理出关联业务的数据流向和数据依赖性，用来确认容灾最终的范围及重要程度，避免因为某些特定关联业务的梳理不到位，导致核心应用因为关联性问题，容灾级别降低或灾备项目建设失败情况的发生。
1.1.2 关键技术的选型 近几年来，容灾已经成为信息数据中心建设的热门课题。很多容灾技术也快速发展起来，对用户来说也有很广阔的选择余地。由于容灾方案的技术复杂性和多样性，一般用户很难搞清其中的优劣以确定如何选择最适合自己状况的容灾解决方案。下面就容灾建设中的备份及复制技术做一个深入探讨，最终为本次容灾中的各系统选择适合的容灾方式。 容灾系统要求生产中心和灾备中心同时工作，生产中心和灾备中心之间有传输链路连接。数据自生产中心实时复制传送到灾备中心。在此基础上，可以在应用层进行集群管理，当生产中心遭受灾难出现故障时可由灾备中心接管并继续提供服务。
和数据备份相比，数据复制技术具有实时性高、数据丢失少或零丢失、容灾恢复快、投资较高等特点。
但是数据复制技术不能代替数据备份技术，因为数据复制技术保证的是两地的数据一致及完整，但是他不能避免因为人员误操作、病毒或其他方式带来的数据丢失或破坏，所以就算有了完整的数据复制技术，也不能放弃数据备份。
根据数据复制的层次，数据复制技术的实现可以分为三种：存储系统层数据复制、操作系统数据复制和数据库数据复制。
数据复制技术的比较 下面对数据复制的三种技术做一个简单比较： 复制技术 比较项目 存储系统数据复制
操作系统层数据复制 应用程序层数据复制 基于存储的
数据复制 虚拟存储技术
基本原理 数据的复制过程通过本地的存储系统和远端的存储系统之间的通信完成。 复制技术是伴随着存储局域网的出现引入的，通过构建虚拟存储上实现数据复制。 通过操作系统或者数据卷管理器来实现对数据的远程复制。 数据库的异地复制技术，通常采用日志复制功能，依靠本地和远程主机间的日志归档与传递来实现两端的数据一致。
平台要求 同构存储 与平台无关， 需要增加专有的复制服务器或带有复制功能的SAN交换机 同构主机、异构存储 与平台无关
复制性能
高 高 高 较高 资源占用 对生产系统存储性能有影响 对网络要求高 对生产系统主机性能有影响 占用部分生产系统数据库资源
技术成熟度 成熟 成熟度有待提高，非主流复制技术。 成熟 成熟
投入成本 高，需要同构存储 较高，需要专有设备 较高，需要同构主机
一般
部分软件免费，如DataGuard
复制软件
IBM PPRC EMC SRDF HP CA（Continues Access） HDS TrueCopy Brocade Tapestry DMM UIT SVM EMC VSM 原厂技术： IBM AIX LVM HP-UINX MirrorDisk
Sun Solaris SVM 专业的复制软件： Symantec SF/VVR
Oracle DataGuard Oracle GoldenGate DNT IDR DSG RealSync Quest SharePlex
操作系统数据复制选择的是系统自身的镜像复制技术，或者安装第三方软件来进行镜像复制，对于操作系统会造成比较大的影响，对IO的压力很大，所以本次项目不考虑使用此种技术。
根据用户现有设备的情况，最终选择存储复制的方式来进行本次容灾的最终关键技术，因为在核心的数据库中，访问量很大，所以在存储复制的同时，我们采用数据库复制技术，将核心数据库进行了同城的数据库复制技术，并采用数据库复制软件，完成了核心数据库的读写分离。
在网络方面，同城采用DWDM方式连接，容灾中心采用fcoip的方式进行了连接，在网络层面采用OTV的技术，使两地之间“二层”打通，为后期实现双活数据中心打下了良好的基础。
1.1.3 生产中心整合 存储系统目标架构描述： A-以核心边缘拓扑为主的双Fabric SAN架构； B-支持分层的虚拟化的存储系统，包括不同级别的磁盘系统和磁带备份设备，虚拟化设备，所有设备连接在核心交换机上；
C-服务器资源池，支持各种类型的Unix和x86服务器，通过边缘交 换机与SAN相连； D-高IO需求服务器与核心交换及直接相连，直接访问磁盘存储，例如NAS网关，备份服务器等；
E-管理服务器，提供对所有存储系统组件的统一监控和管理； F-管理网络，提供管理服务器和各种不同的存储系统组件的通讯。 SAN网络目标架构： 采用核心-边缘架构的二级部署模式，核心交换机连接存储设备，包括磁盘和磁带库设备，边缘交换机连接服务器。
分级存储系统的目标架构： 核心业务系统结构化数据部署在高端存储设备上。 重要业务系统数据部署在中低端存储池。 业务系统数据保存在磁带库环境中，包括虚拟磁带库和物理磁带库。 备份系统目标架构： 业务系统数据备份采用数据先备份到虚拟磁带库上，之后再导出/迁移到物理磁带库上作离线保存。
核心业务系统单独配置一张HBA卡，用作备份环境的链路，和生产环境的存储业务数据流量进行隔离。
对于采用LAN备份方式的业务系统，建立独立的LAN环境，避免与生产的LAN环境产生资源竞争的情况。
SAN架构采用核心-边缘架构，冗余的双Fabric网络； 从冗余性和高可用性考虑，每个边缘交换机到核心交换机之间的ISL级联至少采用两条ISL级联线；容灾中心采用ISL Trunking；根据现状考虑部署ISL Trunking(对于数据库存服务器较多，较多高带宽流量主机（例如单个主机带宽流量>200MB/s ）；
Core核心交换机的界定，所选的Core交换机端口数量不少于160口； 对于高带宽流量的主机（例如单个主机带宽流量>200MB/s ）可以直接连接到 Core交换机，其它主机通过Edge交换机接入，向目标架构演进；
对于同城容灾的SAN环境，同城生产中心和容灾中心之间 距离在10公里内，通过交换机直接ISL连接，本次SAN优化生产中心SAN网络需要与其它业务SAN实现统一，则SAN融合后整个SAN网络规模较大，中间链路波动会对生产端SAN环境有影响，建议考虑同城生产中心和同城容灾中心之间部署SAN Router，对生产和容灾中心进行隔离;
整合时需要考虑品牌，FOS及DOMAINID等。 针对SAN网络优化整合方案，其收益分析如下： 构建企业级统一的SAN网络架构，架构简单，根据业务需要灵活扩展 当前SAN网络按业务系统独立部署，存在多个SAN孤岛，不利于资源共享 满足下一步数据级容灾的要求 统一的SAN网络架构，利于后续数据级容灾工作的实施 实现FCIP设备共享，节省投资 实现集中的企业备份环境 采用基于LAN、LAN-Free的备份方式，提高备份的效率， 减轻对备份窗口紧张的压力 统一管理 建立统一的SAN基础架构进行统一监控管理 现状存在如下问题： SAN架构复杂，存在多个坚井式SAN网络孤岛 不利于资源的共享 备份效率不高 无法实现基于LAN-Free的备份 管理复杂，维护困难 多个孤立的SAN网络环境，不利于统一监控和维护 从数据库的角度看，通过前期调研显示公司共有27个物理数据库，其中除人力资源应用系统外所使用的数据库都是Oracle 10g（15个，超过95%），物理数据库所使用的操作系统绝大多数都为AIX(37个)，其余都为HP-UX操作系统(18个)和windows及linux操作系统(8个)。
从实现方式角度，当前数据库除3套采用HA方式实现，12套采用Oracle RAC，12套在单机上安装Oracle。
容灾系统的建设经过前期的咨询、现状调研分析、目标架构初步设计等阶段，在充分了解现有环境的基础上，以下述内容作为设计原则与前提条件：
§ 以业务影响分析作为容灾策略选择的重要依据； § 以应用影响分析和现状调研分析作为容灾方案的需求； § 参考国信办《信息安全技术信息系统灾难恢复规范》、《信息系统灾难恢复的规划及实施》、银行业金融机构信息系统管理指引、证券公司集中交易安全管理技术指引和人行发布的《银行业信息系统灾难恢复管理规范》--JR/T 0044-2008；
§ 综合考虑目标架构设计、容灾中心总体设计的内容作为数据级容灾方案设计的约束和输入；
基于以上多维度分析结论，综合成本（具体成本数据略）、及容灾实施对运营的影响、实施风险及未来应用级容灾的考量，确定采用数据库复制与HPXP24000存储虚拟化复制相结合的容灾复制关键技术。
系统容灾等级确定为核心A+或A的采用应用级容灾技术，其他容灾范围数据采取存储虚拟化复制技术实现数据级容灾。容灾中心同时配置HPXP24000，在生产中心中，根据现有的高端存储类型，使用现有高端存储的存储虚拟化复制技术。
1)对现有生产的影响小
