脑科医院系统建议方案.doc

1 脑科医院电子病历硬件平台解决方案 南京东软系统集成有限公司 2010 3 31 2 目 录 1 1医院信息系统概述医院信息系统概述 3 3 2 2方案设计方案设计 4 4 2 1 电子病历系统平台设计 4 2 2 系统设计总体拓扑图 5 2 3 服务器系统设计 5 2 3 1 设计原则 5 2 3 2 设计架构 6 2 3 3 业务量估算 8 2 3 4 数据库服务器设计 10 2 4 存储系统设计 12 2 4 1 存储系统设计原则 12 2 4 2 基于 SAN 架构的设计思想 13 2 4 3 存储量估算 14 2 4 4 存储系统设计 15 2 5 电子病历交换机 17 2 6 其它设计 17 2 7 配置清单 17 3 3备份系统建议 未来二期 备份系统建议 未来二期 1919 3 1 应急灾难恢复策略 25 3 1 1 医院信息系统概述医院信息系统概述 脑科医院为了实现医院管理的科学化 现代化 数字化 提高医院管理效 率与服务质量 增强竞争力 按照总体规划 逐步实施的原则全面建设医院信 息系统 此次建设主要是关于脑科医院电子病历系统建设 能够明显改善医疗 质量至少是医疗文书质量 还可以提高效率 规范医疗行为 减少人为差错 改善科研环境 这不仅具有积极的社会效益 也有明显的经济效益 脑科医院管理电子病历系统不但要满足全院日常医疗服务需要 还需要能 够为全院的现代企业模式管理提供准确及时的决策支持数据 全院满负荷运转 时 目前有五个科室使用 下面结合医院的具体需求 同时考虑到医院电子病 历系统的建设进行状况 充分结合现有设备环境对系统平台的建设提出科学合 理的建议 4 2 方案设计方案设计 2 12 1 电子病历系统平台设计电子病历系统平台设计 脑科医院为了实现医院管理的科学化 现代化 数字化 提高医院服务质 量 增强竞争力 按照总体规划 逐步实施的原则全面建设医院信息系统 电 子病历是医疗健康信息个性化发展的趋势 也是信息化应用向临床发展的迫切 需求 病历作为患者信息的载体 集中反映了患者的诊断治疗过程 电子病历 是数字信息化的病历 它的内容包括纸张病历的所有信息 电子病历不仅指静 态病历信息 还包括提供的相关服务 它能实现患者信息的采集 加工 存储 传输和服务 医院院满负荷运转时 日门诊量人次 则信息系统平台系统建设规模不同 结合医院的具体需求 同时考虑到医院信息系统的建设进行状况 同时充分考 虑结合现有设备环境对系统平台 包括服务器 网络 存储及系统软件的建设 提出科学合理的建议 5 2 22 2 系统设计总体拓扑图系统设计总体拓扑图 系统拓扑图系统拓扑图 2 32 3 服务器系统设计服务器系统设计 2 3 12 3 1设计原则设计原则 医院电子病历系统主机担负着信息的加工 处理 提炼 查询等工作 是 信息汇集 保存 处理的中心 要求高度的安全性 可靠性 稳定性和高性能 因此在主机系统的设计方面我们充分考虑以上要求 遵循如下原则 1 1 硬件平台 硬件平台 1 系统要有足够的联机事务处理 OLTP 6 2 系统要有足够的 I O 速度 3 系统要有足够的内存及外存 4 系统要易于扩展 包括 CPU 数 I O 接口卡 内存 硬盘 5 系统要有充分的冗余 支持高可靠性 2 2 操作系统 操作系统 1 操作系统符合开放标准 具有一定的先进性 兼容性良好 2 适应系统的多样性 3 操作系统比较成熟 能提供高度的可靠性和安全机制 4 操作系统要易于升级 5 提供丰富的系统管理软件和良好的用户界面 提供 CPU 资源 内存 资源 外设以及文件系统的管理 6 提供丰富的开发工具 7 支持开放的网络协议 3 3 其它 其它 1 较好的性能价格比 2 较好的售后服务 包括安装 调试 培训以及软硬件的维修 升级 服务 2 3 22 3 2设计架构设计架构 医院信息系统要求可提供不间断的 高速率的数据传输服务 可靠性 可 用性 可维护性 RAS 是系统必不可少的 RAS 技术保护数据和设备的投资 帮助用户保持高效稳定的计算系统 医院的服务器的特性应包含以下几个方面 1 1 可靠性可靠性 服务器系统设备是提供存储 检索 提供信息的关键资源 要求有较高的 7 可靠性 可支持不影响应用程序正常运行的系统硬件和软件的升级和维护 支 持保证硬盘可靠性的 RAID 技术 2 2 可用性可用性 CPU 内存板冗余 服务器可配置冗余的 CPU 内存板 在每个 CPU 内存 板上还可以配置冗余的 CPU 来提高系统的可用性 外部系统备份 通过外部系统备份方案降低系统风险 比如采用双机热 备技术 冗余电源和冷却系统 服务器需具备有冗余电源 这样 即使有一个电 源 冷却模块失效 系统仍能够正常运行 另外冷却系统可避免服务器 因环境失调引起的故障 3 3 可维护性可维护性 热插拔硬件 热插拔硬件可缩短服务器脱机进行升级的时间 并能方便 而迅速地更换硬件 具有更好的可用时间可维护性 系统监视 服务器需具备系统监视管理软件包 进行远程监视和硬件故 障预测 7 24 小时关键任务服务 服务器可提供 7x24 小时关键任务服务 最大 限度地维护用户服务器系统的正常运行 保证可能出现的问题在第一时 间得到解决 4 4 可缩放能力可缩放能力 服务器应具有较强的缩放性 良好的性价比 可在多个方向上进行扩展 使得网络管理人员最终能根据应用需要对服务器的 CPU 内存和 I O 装置进行 优化和配置 以满足日益增长的需求 5 5 可升级能力可升级能力 服务器在升级时 用户在所有软件 培训 应用和外设等系统基础设施方 面得到最大限度的保护 部件都可用继续延用 用户的应用可以运行在新系统 8 上 同时性能大大提高 可以根据实际需要增加 CPU 的数目 扩充内存和硬盘的容量以及增加 I O 通道的数目达到增强性能的目的 6 6 超强的存储能力超强的存储能力 目前 由于医院将要开展的电子病历业务要求对信息的采集 加工 存储 传输和服务 因此 系统中应具有大容量的存储设备 以满足现有数据信息的 存储要求 同时 还要保证数据访问的快速高效 并采用 RAID 技术确保数据 安全 2 3 32 3 3业务量估算业务量估算 根据医院的日门诊量的规模不同 根据我们长期从事医院管理信息系统建 设的经验并结合医院的实际情况 我们通过对业务系统的分析 推算出主机系 统性能 针对系统中心端数据库服务器部分性能需求进行分析 1 1 TPC CTPC C 及及 TPMCTPMC TPC TransactionProcessingPerformanceCouncil 事务处理性能委员会 是由数十家会员公司创建的非盈利组织 它的功能是制定商务应用基准程序 Benchmark 的标准规范 性能和价格度量 并管理测试结果的发布 TPC 已经推出了四套基准程序 被称为 TPC A TPC B TPC C 和 TPC D 其中 A 和 B 已经过时 不再使用了 TPC C 是在线事务处理 OLTP 的 基准程序 TPC D 是决策支持 DecisionSupport 的基准程序 TPC 即将推出 TPC E 作为大型企业 Enterprise 信息服务的基准程序 TPC C 使用三种性能和价格度量 其中性能由 TPC C 吞吐率衡量 单位 是 tpmC tpm 是 transactionsperminute 的简称 C 指 TPC 中的 C 基准程序 它的定义是每分钟内系统处理的新订单个数 价格是指系统的总价格 单位是 美元 而价格性能比则定义为总价格 性能 单位是 tpmC 9 2 2 交易量分析交易量分析 关于 每笔实际交易对应多少个 TPC C 值 这个问题 其数值是随着业务性 质的不同而不同的 对此数值最科学的解释 应该来自应用系统本身 当应用 系统跑起来以后 可以通过对系统运行效率的科学评测和分析 来获取 也可 以根据类似应用的经验值来参考 不同厂家的机器 对应值也不完全一样 一般来说我们需要保证 30 M1 的主机 CPU 处理余量 用于操作系统 数 据库 工具软件 监控软件或其它应用系统的使用 从医院的情况分析 电子病历系统数据库服务器系统的联机事务处理主要 来自医院内部终端所产生的联机事务处理请求 目前 医院业务终端数量包括 住院系统医生 护士工作站 检验等职能科室工作等等 从脑科医院具体的情况分析 同时考虑到系统未来的扩展需求 我们考虑 100 个信息终端 分别运行包括电子病历信息系统的全部业务 在峰值情况下 的一分钟之内全部对数据库服务器发起连接请求 即可得到系统的联机事务处 理请求的峰值约为 100 当然 这是以假设状态下的最大峰值进行估计 因此 联机事务处理交易的峰值为 100 60 6000 笔 分 考虑到系统 3 到 5 年后的 业务扩展 按照 35 的比例增长 这样得出联机事务处理请求的峰值为 6000 1 35 8100 笔 分 根据计算公式 TpmC TPS 峰值 M2 1 M1 一般来说每一笔 M2 联机事务处理所对应的 TPC 值 的值都根据具体的业 务处理情况不同 一般好的系统的 M2 的值应该在 5 30 范围内 我们在此不 可能将每一笔值进行精确的估算 只能够对这些所有的联机事务处理做一个平 均值估算 因此总体来看 我们按照 M2 15 来进行估算是一个比较合理的数 10 值 这样我们就可以将这些值计算出来 TPM 16200 8 1 30 173571TpmC 因此 我们建议脑科医院管理信息系统数据库服务器的因此 我们建议脑科医院管理信息系统数据库服务器的 TPMTPM 值最少应该达值最少应该达 到到 173571TpmCTpmC 3 3 内存容量大小内存容量大小 关于内存的配置 我们是这样进行估算的 我们认为内存的消耗主要包括 有如下几个部分 主机系统正常运行所需消耗 主要指操作系统消耗 数据库运行所需开销 数据库 SGA 运行所需正常开销 联机事务处理消耗 因此从上边我们可以看到主机系统所需内存大小由四大部分组成 根 据我们以前的经验 发现每一笔交易占用的内存为 1M 到 3M 之间 我们的 经验公式是 内存 操作系统 数据库管理系统 数据库 SGA 运行 并发连接 数 2M 通常情况下操作系统占用 128MB 内存 数据库管理系统约占用 512MB 数据库 SGA 分配为 512MB 内存运行的最佳冗余空间比为 60 根 据上面的估算 并且保证高性能的原则 保证 CPU MEM 的配置比例最少应 该保持在 1 4 以上 能够保证 CPU 访问内存的速度 这样我们就可以得到 系统所需内存容量 11 2 3 42 3 4数据库服务器设计数据库服务器设计 目前 有两种典型的服务器配置平台可供选择 小型机 采用 Unix 操作 系统 和微机服务器 采用 Windows 操作系统 它们在性能 价格方面分别 具有自己的优势和特点 在硬件方面 小型机采用精减指令集计算 RISC 处理器 具有处理速度 快 吞吐能力强特点 同时结合 Unix 操作系统的安全 稳定性能 可使小型 机适用于各种应用环境 专业小型机生产厂商一般具有长期的硬件研发历史 在人才 技术 经验 管理等方面具有丰富的积累 各类专业化的设计以及新 技术的应用更使小型机在稳定性 可用性 可管理性及可扩展性等方面不断的 提高 而微机服务器采用 Intel 处理器 相对而言 微机服务器的维护和使用较 为方便 性能价格比较好 目前 微机服务器的应用也越来越广泛 一些大型 的服务器厂商 投入大量的人力物力到微机服务器产品的研发项目中 并将一 些小型机的技术运用到微机服务器产品中 使得该领域中的产品性能不断提高 有些机型的速度及可靠性等方面已逼近 甚至超过低端小型机产品 目前 各 厂商不断推出新型的企业级微机服务器 为各类中小型企业的关键应用提供了 丰富的解决方案 对于数据库服务器的选型 根据业务量的估算和脑科医院电子病历系统规 模确定 同时建议部署 2 台 PC 服务器组成双机热备系统 提高系统的可靠性 和高性能 PCPC ServerServer 方案方案 建议配置 2 台高端 PC Server 做为电子病历核心数据库服务器 两台服务 器建议分别配置 2 2 路路 IntelIntel XeonXeon 四核四核 2 662 66 GHzGHz CPUCPU 16GB16GB 内存内存 保证 CUP Mem 1 4 配置了 2 块 300GB 热插拔 SAS 硬盘 用来装载 12 Windows2008 Server 企业版操作系统 数据库软件 这 2 块内置硬盘采用硬 盘镜像软件进行硬盘镜像保护 保障启动盘的可靠性 在服务器的通信方面 2 台服务器分别配置 4 块千兆网卡用于数据通信并 实现双机系统 当运行网卡出现故障时 备用网卡将接替它运行 这个接替 过程是非常快速的 并且对应用系统及用户没有任何服务的中断和影响 提 供网卡的双重保护 每台服务器将配置 2 块 HBA 光纤通道卡 用于连接外置光纤磁盘阵列 并 配置了负载均衡和故障切换软件 以确保系统 I O 的高性能和高可靠性 每台服务器配置了一个 DVD 光驱 提供常用的软件安装及数据装载 每台服务器配置了热插拔冗余电源和热插拔冗余风扇 PCPC ServerServer 建议配置 建议配置 数据库服务器 数量 2 台 配置 2 E5540 2 53GHz 四核 CPU 16G 内存 2 块 300G 硬盘 配置 RAID 卡 可做 RAID1 4 块千兆以太网卡 2 块 HBA 卡 1 个 DVD ROM 3 个 PCI E 插槽 最大 6 个可用的 PCI E 热插拔冗余电源和热插拔冗余风扇 Windows 操作系统 13 2 42 4 存储系统设计存储系统设计 2 4 12 4 1存储系统设计原则存储系统设计原则 存储系统必须具有高安全可靠性以保证整个医院系统顺利运行 磁盘系统 重点保证 7 24 小时不间断运行 磁带系统重点保证备份的可靠性 存储系统具有较强的扩展能力和连接能力以保证用户投资 存储系统具有高性能 高效传输 存储系统具有使数据安全可靠存储的解决方案 保证在线系统数据不丢失 存储系统必须操作简易 使用灵活 存储系统必须具有本地备份保护措施 2 4 22 4 2基于基于 SANSAN 架构的设计思想架构的设计思想 SAN 为医院信息系统带来的好处 1 资源最大限度汇集 在 SAN 未出现以前 在计算中心的公用区域内将设备进行物理汇集通常是 不可能的 若有可能的话 却又要求昂贵的费用和专有的扩展技术 通过在存 储资源和服务器之间引入网络 这一难题解决了 所有服务器和存储设备之间 的硬件互连已经是很平常的事情了 2 开放性强 扩容方便 存储区域网络 SAN 是集中化管理的调整存储网络 其中可以包含来自多 个厂商的存储服务器 存储管理软件 应用服务器和网络硬件设备 若所有的 设备都与 SAN 相连 那么为一个或多个服务器增加存储容量就变得非常简单 根据 SAN 配置和服务器操作系统的不同 有可能做到服务器不用停机或重新启 动就可以增加或移走存储设备 14 3 真正的数据共享 在数据共享中 数据的相同拷贝同时被多台服务器访问 这样就节省了大 量存储空间 同时在此基础上可以对存储进行整合 有不同层次上的数据共享 包括 序列化逐次或一次一个式的访问 这是一种数据的串行再利用方式 相 同的数据首先分配给不同服务器的第一个应用 然后到第二个 依此类推 多个应用同时进行读访问 在这种模式下 一个或多个服务器中的多个应 用程序可以同时读取数据 但只有一个应用程序能对数据进行更新 因此 不 会出现数据完整性问题 多个应用同时进行读取访问 这有点类似上一种模式的情况 不同的是所 有主机都能修改数据 在这种模式下 也分两种不同的情况 一个是所有的应 用程序都在相同的平台上 同构 另一种情况是应用程序在不同的平台上 异构 4 数据移动方便 数据移动解决方案可以将数据在类似或不同的存储设备间来回移动 目前 数据的移动或复制靠服务器或多个服务器来完成 服务器从源设备中读取数据 然后通过 LAN 或 WAN 传送给其它的服务器 最后数据写入目标设备 整个过程 要占用服务器处理器的操作周期 而且在 SAN 上数据要传送两次 一次是从源 设备到服务器 一次是从服务器到目标设备 SAN 数据移动解决方案的目标是不使用服务器 无服务器 不使用 LAN 或 WAN 无 LAN 来进行数据拷贝 这样就释放了服务器处理器的操作周期 同时也释放了 LAN 或 WAN 的带宽 目前 这种数据复制是靠在 SAN 内使用支持 第三方 SCSI 3 拷贝命令的智能网络来完成 第三方拷贝也可以看作是外部数 据移动或拷贝 正是因为以上的优势 才使 SAN 成为自从网络计算时代以来 IT 产业所取 15 得的最重要成就之一 所以 在医院信息系统中存储系统设计方案采用了 SAN 架构进行设计 2 4 32 4 3存储量估算存储量估算 存储数据量主要包括两大部分 第一部分包括主机系统内置硬盘大小 第 二部分包括磁盘阵列容量大小 其中主机系统内置硬盘主要存储的内容包括操 作系统 数据库系统 磁盘阵列存储的内容根据医院的要求 主要是全院信息 系统 3 5 年时间产生的所有数据及其原始数据 从上边的分析我们可以看到实际上系统对内置硬盘的大小要求不是很高 根据我们的经验 我们可以得出这个结论即 内置硬盘大小为 操作系统 数 据库 应用软件 整个容量不超过 18GB 左右 但是考虑到数据库软件随着运行 时间的不断增长 其所要求的存储容量也会相应增加 并且考虑采用镜像的方 式保证系统文件的安全 因此我们配置的内置硬盘大小为 300GB 300GB 2 对于磁盘阵列的大小 我们根据医院的实际情况进行估算 预计 3 5 年后全院满负荷运转时 根据以往对医院电子病历系统建设和实 施的经验 我们认为医院电子病历系统数据量的组成主要包括以下几个方面 基础信息数据 患者信息数据 住院系统信息数据 其他系统信息数据 通过以上对系统产生数据量的估算可见 系统的初始基础数据约为 1GB 相对于系统 3 5 年的数据量来说可以忽略不记 满负荷运转时 每天 产生的数据容量约为几个主要数据信息增长量之和 同时 为了保证数据的安全性和可靠性 我们建议采用 RAID1 0 或 RAID5 16 技术 这样 就可得出电子病历系统所需合理的磁盘存储容量为这样 就可得出电子病历系统所需合理的磁盘存储容量为 3T3T 裸容量 裸容量 2 4 42 4 4存储系统设计存储系统设计 存储系统主要用于支持数据库服务器系统 满足医院电子病历业务的存储 处理 由于电子病历应用系统是大型的 OLTP 数据库系统 所以要求存储系统 能满足大量数据存储和交易快速响应的需要 还要保障数据的安全性和一致性 根据前面的分析服务系统采用 SAN 存储架构进行设计 根据上面的设计方案在医院信息系统 SAN 存储中实际的配置方案主要包括 以下几部分 ServerServer 服务器 服务器 服务器基础结构是 SAN 解决方案的基础 连入 SAN 中的服务器为数据库服 务器系统双机系统 StorageStorage 存储设备 存储设备 本地的数据存储设备 采用 1 台中端存储服务器 结合 Server 方案 我们用 SAN 架构磁盘阵列作为电子病历系统一级在线 存储 主要存储电子病历系统数据 系统近 3 5 年数据 提供快速的查询以保 证系统的高效性 方案考虑到光纤通道集群方案分三大部分 主机服务器 共享存储系统和 主机与共享存储的连接三部分 其中 集群的主机服务器部分采用二台高性能 高可用性和高可靠性的 PC 服务器 进一步满足高可用性 高性能的需求 主 机与共享存储柜之间的连接部分通过在服务器各配置二块光纤通道主机控制器 分别连接光缆到光纤交换机上 再连接到集群存储柜 以构成光纤通道集群方 案的硬件环境 磁盘阵列 17 数量 1 台 配置 2 个 FC 控制器 每个控制器有 2 GB 缓存 4GB Cache 4 个 4GB FC 端口 3TB 硬盘容量 10 300GB 硬盘最大扩展 96 块 多链路软件 冗余电源 存储管理软件 SANSAN fabricfabric 连接设备 连接设备 配置 2 台 24 口 8 口激活 光纤交换机做为 SAN 连接设备 构架成数据中 心存储区域网 配置 8 个 SFP 光纤模块及相应的光纤跳线 SoftwareSoftware 管理软件 管理软件 SAN 的管理包括存储系统的管理 存储网络的管理和系统级管理 SAN 存 储级管理由不同的存储设备组成 如磁盘 磁盘阵列 磁带 磁带库等 SAN 存储网络的管理由可以提供连通性的所有各类逐渐组成 如 SAN 线缆 SAN 交 换机以及主机总线适配器等 对于 SAN 存储级管理软件 本方案根据配置的存储设备配置了不同的管理 软件 2 52 5 电子病历交换机电子病历交换机 主要用于电子病历与核心交换机相连接 我公司在这里考虑采用一台 24 口 10 100 1000 自适应交换机 2 62 6 其它设计其它设计 为了保证各部门很好处理日常事务 我公司在这个项目中配置了中高端 35 台 PC 台式机和 20 台打印机 18 2 72 7 配置清单配置清单 项目项目数量数量规格规格 核心服务 器 2 台台2 CPU 16G 内存 2 块 300G 硬盘 4 个千兆 以太网卡 2 块 HBA 卡 1 个 DVD ROM 热插拔 冗余电源和热插拔冗余风扇 Windows 企业 版 操作系统 核心存储1 台台双控 缓存 4G 提供 4 个 4Gb FC 接口 配置 10 块 300GB 15000 转光纤磁盘 提供磁盘 阵列管理软件 提供多通道链路管理软件 实现链路负载均衡 支持操作系统 AIX HP UX Solaris Windows Server Linux 冗余及热插拔电源 SAN 交换 机 2 台台24 口 4GB 光纤通道交换机 8 口激活并配 置相同数量的 SFP 和光纤线 交换机1 台台24 口 10 100 1000 自适应交换机 PC 台式机 35 台台 打印机20 台台 19 3 3 备份系统建议 未来二期 备份系统建议 未来二期 随着医院信息化建设的逐步发展 业务系统的数据处理量和数据存储量越 来越大 数据存储系统是医院信息系统的核心组成部分 担负着业务处理等极 其重要的工作 而系统中的数据 更是核心中的核心 数据的安全性关系到整 个系统能否正常的运行 最终关系到能否提供正常的服务 所以对数据做好数 据保护是至关重要的 是保证提供正常服务的最后一道防线 备份备份技术的选择技术的选择 对医院系统数据库建立一个集中管理的 自动化的 高速有效的备份手段 可以考虑和利用在线备份软件 完善整个备份系统 实现全自动在线备份 磁带库选型磁带库选型 1 1 磁带机的速度磁带机的速度 目前 主流的成熟磁带机技术主要有几大类 LTO 4 120M 字节 秒 LTO 3 80M 字节 秒 2 2 备份的速度备份的速度 但若在备份的数据链路上没有瓶颈时 备份的速度直接取决于磁带机的速 度 因为目前的 VERITAS 的备份软件都持通过并发的数据流使多个磁带驱动器 同时工作 所以 备份的理论速度 磁带机的速度 带库中磁带机的数量 若以 1 个 LTO4 驱动器计算 该磁带库的理论备份速度为 120 1 120M 字节 20 秒 若以 2 个 LTO4 驱动器计算 该磁带库的理论备份速度为 120 2 240M 字节 秒 当然 实际的备份速度要慢一些 因为在整个备份过程中 并不是所有的 磁带机都同时结束工作 3 3 所需磁带机数量的计算所需磁带机数量的计算 但备份数据流链路上不存在瓶颈时 所需的磁带机数量的计算方法为 备份的数据量 备份的时间窗口 磁带机的速度 例如 医院系统初始备份的数据量为 0 5T 使用的是 LTO4 的磁带机 希 望能在 4 小时内结束全备份 则 所需的磁带机数量为 0 5T 524 288M 4 小时 4 3600 14400 秒 LTO4 磁带机的速度为 120M 字节 秒 524288 14400 120 0 3 将该计算结果向上取整 1 个磁带机驱动器 若再适当考虑通过硬件 冗余来实现高可靠 配置 2 个 LTO 4 磁带机就更稳妥 4 4 所需磁带库内槽位的计算所需磁带库内槽位的计算 常规的备份策略是全备份与增量备份相结合 而一个备份周期包括全备份 其后的增量备份 因为在恢复时要将全备份和增量备份结合使用才能有效地 将数据恢复至最后一次备份或发生数据灾难的时刻 如果我们将所有要备份的数据量 这也是一次全备份的数据量 称之为一 份存储 那么 一个备份周期中的数据量肯定大于一份存储 因为还要包括全 备份之后的所有增量备份 在此 我们暂且认为是两份存储 21 作为在备份中必须遵循的一个基本原则 在最新的全备份尚未成功结束时 上一个备份周期中的所有磁带介质都不能破坏 否则 万一在这次全备份的过 程中发生数据灾难 系统将没有可用的备份用来进行系统恢复 所以 将这个 最新的全备份考虑在内 就又增加了一份存储 共计三份 作为在备份中需要考虑的另一个基本原则 对数据只做一个备份是不可靠 的 因为磁带在理论上也有可能出现意外的物理损坏 这就导致在需要时无法 有效的恢复数据 所以 在企业级的备份中 应该在正常的备份结束后再复制 一份磁带 复制后的磁带应该异地保存以增加数据容灾的能力 但这份存储在 复制结束前也是在磁带库中的 所以将其考虑在内 就又增加了一份存储 共 计四份 作为在备份中需要考虑的另一个实际情况是 在磁带库中的磁带并不一定 都是 100 的利用率 这其中的原因有多方面 有可能是由于对磁带分组管理的 需要 有些磁带是做文件系统备份的 另一些是做数据库备份的 不能混合使 用 所以利用率达不到 100 也有可能是出于对恢复时性能的考虑 若一个 备份的 IMAGE 不是从磁带头开始 在恢复时先需要进行定位 这需要时间 在 一定程度上也影响恢复的性能 有意的没有 100 的利用磁带 所以 将这些 因素考虑在内 就又需要增加一到两份的存储 至此 已需要 5 6 份存储 在企业环境中 可能会有要求要将某些数据能回溯到以前某个历史时刻 对这些数据 就要保留多个备份周期 所以 由于这样的原因也需要一些额外 的存储 将这个因素考虑在内 就又需要增加一到两份的存储 结合上文 至 此 共需要 6 8 份存储 因此 正常情况下 磁带库的容量应达到所备份数据量的因此 正常情况下 磁带库的容量应达到所备份数据量的 7 7 倍 倍 7 7 份存储 份存储 以上 以上 若数据量为 0 5TB 使用的是 LTO4 磁带机 每盒 LTO 磁带在非压缩格式下 容量为 800GB 为完成该环境的备份 所需要的磁带库槽位应为 22 0 5T 512GB 512 7 800 5 槽 由于目前的备份性能的瓶颈在于百兆网络 由于目前的备份性能的瓶颈在于百兆网络 网络传输的速度达不到一个磁 网络传输的速度达不到一个磁 带机的速度 带机的速度 因此 只需要配置一个 因此 只需要配置一个 LTO4LTO4 磁带机 磁带机 8 8 个槽位即可 个槽位即可 但考虑到技术的先进型 可扩展性 再结合对硬件冗余的考虑 则目前选但考虑到技术的先进型 可扩展性 再结合对硬件冗余的考虑 则目前选 配的磁带库应支持扩展到配的磁带库应支持扩展到 1 1 个个 LTO4LTO4 磁带机 磁带机 备份软件的选择备份软件的选择 备份软件备份系统能够顺利实施的关键 好的备份软件可以具有非常强大 的功能 帮助用户顺利实施备份系统 对重要数据进行快速 安全 可靠的备 份 并当由于任何原因发生数据丢失时 能迅速通过备份系统对数据进行恢复 所以 对一个备份软件的要求就是对备份和恢复的要求 备份软件的选择 建议满足以下需求 扩展性 支持所有主流的操作系统和数据库 支持所有主流的磁带 机和磁带库设备 数据备份要能在线完成 在备份过程中不影响业务系统的正常运行 要求能够支持在一个 CLIENT 端上启动并发数据流 加速备份过程 充分利用多磁带机的磁带库设备 要求能够支持在一盘磁带上由多数据流交叉写入 以解决慢客户端 的问题 提高磁带机性能的利用率 对于多磁带机的带库设备 要求能够支持对磁带在线实现 RAID1 以 便能同时生成两份备份 提升备份介质的可靠性 要求能实现全图形化管理 可对设备 作业进行监控 有多种 23 wizards 提供备份策略 备份设备配置等 wizard 帮助 在 SAN 结构下 允许不同操作系统共享磁带库设备 并且同一磁带 驱动器可被同一或不同操作系统的主机动态共享 支持远程分发式的 CLIENT 端软件安装 除文件系统外 可对裸设备进行备份 对大量的小文件备份时可通 过磁盘物理数据块进行 以提高性能 但要求能恢复单个文件 图形化管理所有备份设备 备份策略及备份作业的监控 日志 可 远程集中化管理多个备份环境 备份策略的选择备份策略的选择 备份策略的定义备份策略的定义 搭建好备份系统平台以后 我们必须根据实际需要配置备份策略 定义备 份策略 涉及到以下内容 在什么时间 备份时间 如下午 6 00 将什么数据 备份内容 如主数据库数据 以什么方式 备份方式 如全备份或增量备份 通过哪组磁带驱动器 备份通道 如 磁带驱动器 备份到哪一个磁带组 备份目的地 如 Volume Pool for 主数据库 在我们对每一组数据 数据库都根据需要定义好备份策略后 系统就会自 动的按照我们定义的时间 方式 将需要备份的数据备份到我们指定的带库中 去 而备份的方式可以分为三种 全备份 增量备份 累计增量备份 1 全备份 24 每次备份定义的所有数据 优点是恢复快 缺点是备份数据量大 数据多 时可能做一次全备份需很长时间 2 增量备份 备份自上一次备份以来更新的所有数据 其优点是每次备份的数据量少 缺点是恢复时需要全备份及多份增量备份 3 差分备份 备份自上一次全备份以来更新的所有数据 备份策略的应用备份策略的应用 在备份策略选择时 一般的规则是 1 对于操作系统和应用程序代码 可在每次系统更新或安装新软件时做一 次全备份 2 对于一些日常数据更新量大 但总体数据量不是非常大的关键应用数据 可每天在用户使用量较小的时候安排全备份 3 对于日常更新量相对于总体数据量较小 而总体数据量非常大的关键应 用数据 可每隔一个月或一周安排一次全备份 再此基础上 每隔一个较短的 时间间隔做增量备份 我们可以结合这三种方式 灵活应用 比如 1 数据量少时 我们可以每次都用全备份备份数据 这样 恢复时 只需 要指定一个数据源即可 2 数据量大时 如果每天作全备份 效率会很低 我们可以结合全备份和 增量备份方式 比如每星期作一次全备份 如星期天 其它时间 每天作一 个增量备份 如 星期一到星期六 恢复时 只要依次恢复最多七个备份介质 即可 如 上周日 星期一 星期二 直到出事前一天的数据 25 3 数据量特别大时 每星期作全备份对系统的压力也会很大 这时 我们 可以结合全备份 累计增量备份 增量备份三种方式 提供相对效率高 恢复 有快的备份手段 比如每个月作一次全备份 如每月初 然后每星期日作一 次累计增量备份 其它时间 每天作一次增量备份 恢复时 先恢复月初的全 备份 再恢复上周日的累计增量备份 在依次恢复以后每一天的增量备份 如 星期一 星期二 直到出事前一天的数据 最多恢复 8 份数据 相对的 如果不采用累计增量备份方式 恢复时最多可能需要恢复 31 份数据 恢复速 度和复杂程度都会不理想 3 13 1 应急灾难恢复策略应急灾难恢复策略 一个应用系统运行时可能会发生各种意外情况 影响整个应用系统的正常 工作 因此我们必需预先考虑到