北京电视台制播网数据库迁移优化项目192页（2024年修订版）.docx

北京电视台制播网数据库迁移优化项目 目录 1. 项目服务方案 4 8.1 项目背景及建设目标 4 8.1.1 项目背景 4 8.1.2 项目建设目标 4 8.2 数据库迁移（Unix到Linux） 方法 5 8.2.1 数据库迁移方法概述 5 8.2.2 数据库迁移主要任务说明 6 8.3 调研分析成果 9 8.3.1 整体架构 9 8.3.2 数据库 现状 10 8.3.2.1 数据库基本 信息 10 8.3.2.2 数据库 性能 分析 12 8.3.3 存储 现状分析 18 8.3.3.1 云平台存储系统现状 18 8.3.3.2 壳系统存储 现状 23 8.3.4 调研分析 总结 28 8.3.5 待补充调研分析内容： 29 8.4 数据库平台建设方案 31 8.4.1 建设原则 32 8.4.2 建议新平台整体系统架构 33 8.4.3 主机层方案设计 35 8.4.4 存储层方案设计 38 8.4.5 网络层方案设计 39 8.4.6 数据库层方案设计 40 8.4.6.1 Oracle RAC基本配置 40 8.4.6.2 Oracle RAC配置方案 41 8.4.7 Oracle DataGuard备库配置方案 41 8.4.8 兼容性分析 42 8.4.9 配置清单 44 8.4.10 数据库平台实施方案 45 8.5 数据库迁移方案 51 8.5.1 数据库迁移方案选择 51 8.5.2 迁移实施步骤 54 8.5.2.1 源数据库配置查询 54 8.5.2.2 源数据库 initialization parameter file 获取 55 8.5.2.3 源数据库数据导出 55 8.5.2.4 文件拷贝 56 8.5.2.5 目标数据库创建ASM Disk Group 57 8.5.2.6 目标数据库创建Initialization Par ameter File 57 8.5.2.7 创建目标数据库 58 8.5.2.8 目标数据库创建Tablespace 58 8.5.2.9 目标数据库创建Directory对象 58 8.5.2.10 目标数据库导入数据 59 8.5.3 数据库迁移验证 59 8.5.3.1 数据完整性验证 59 8.5.3.2 对外服务连接正确性验证 60 8.5.3.3 数据库性能验证 60 8.5.3.4 业务验证 63 8.5.4 风险分析与应对 63 8.5.5 应急回退预案 64 8.5.6 迁移测试与演练 64 8.5.7 业务割接方案 67 8.6 数据库优化 70 8.6.1 目标与范围 70 8.6.2 数据库优化方法 71 8.6.3 数据收集 72 8.6.4 优化分析 73 8.6.4.1 高可用性 73 8.6.4.2 可扩展性 73 8.6.4.3 高性能 74 8.6.5 优化建议与调整 75 8.6.5.1 高可用性 75 8.6.5.2 可扩展性 76 8.6.5.3 高性能 76 2. 项目实施与服务 78 9.1 系统集成实施服务 78 2.1.1. 项目管理 78 2.1.2. 项目管理目标 81 2.1.3. 项目管理内容 81 2.1.3.1. 项目定义和确定工作清单 82 2.1.3.2. 项目人员组织和分配 82 2.1.3.3. 项目进度安排和控制 84 2.1.3.4. 项目变更和风险管理 84 2.1.3.5. 项目文档管理 84 2.1.3.6. 项目文档 85 9.2 EMC实施服务体系 87 9.3 EMC服务的优势 89 9.3.1 服务团队及专业资质 89 9.3.2 经过验证的方法论 89 9.3.3 项目管理优势 90 9.3.4 技术团队支持 91 9.4 服务与管理 92 9.4.1 项目整体计划 92 9.4.2 服务方案阶段安排 93  调研分析阶段 93  规划设计阶段 93  迁移实施阶段 94  数据库优化收尾阶段 94 9.4.3 项目进度管理 94 9.4.4 交付物参考列表 95 9.4.5 项目管理组织架构和职责 96 9.4.6 实施团队主要人员简历表 98 9.4.7 项目组织和管理计划 128 9.4.8 管理内容及控制机制 128 1.1.1 129 附件 ： 投标人人力资源一览表 130 1.1 130 3. 培训计划 131 3.1. 培训目标 131 3.2. 培训地点和方式 131 3.3. 培训内容 131 4. 投标人同类业绩一览表 133 4.1. 合同 1 134 4.2. 合同2 141 4.3. 合同3 149 4.4. 合同4 156 4.5. 合同5 163 5. 中小企业声明函 173 6. 证明投标服务的合格性和符合招标文件规定的文件 174 6.1. 卓优数据公司介绍 174 6.2. 卓优数据服务体系和技术支持介绍 175 6.2.1. 卓优承诺 175 6.2.2. 卓优公司技术服务理念 176 6.2.3. 技术服务响应和流程 176 6.2.4. 故障等级和服务响应定义 177 6.2.4.1. 故障等级约定 177 6.2.4.2. 服务模式和响应机制 179 6.2.4.3. 本项目服务响应 182 6.2.5. 服务范围和服务模块 183 6.2.5.1. 服务内容和概述 184 7. 后续服务承诺 190 8. 产品性能及参数手册 191 8.1. 计算节点（DELL服务器） 191 项目服务方案 项目背景及建设目标 项目背景 北京电视台制播网数据库环境主要采用OLTP关系型数据库技术，由位于主干系统的公共数据库平台及部分业务系统内的独立数据库组成。 现有主干系统公共数据库平台主要采用传统小型机+独立存储+Oracle 10g RAC数据库集群的模式，随着制播网大规模的业务系统建设及数据库平台的扩展，逐渐形成了目前由三种型号的多台小型机组成的数据库平台对外提供数据库服务的实现方式。在系统运行初期，上述数据库部署模式提供了稳定、可靠的数据库服务能力，满足了当时节目生产业务的需要。但近两年来，随着设备的逐渐老化，数据库硬件故障频发（特别是运行时间较长的SUN E2900小型机及SUN T5440小型机），数据库服务的稳定性急剧下降，数据库架构问题凸显，数据库服务能力无法应付业务的快速增长。此外，由于小型机技术相对封闭，维护中对于服务商依赖程度较高。因此，原有数据库平台无论从自身服务能力还是从对其的运维服务能力来讲都遇到了一些问题，急需做出改变。 项目建设目标 根据标书要求，本项目将需要实现以下目标： 解决现有主干系统公共数据库平台部分数据库小型机老化严重、硬件故障频发、负载压力偏大的问题。 采用通用型架构支撑数据库服务，降低数据库维护难度及维护成本，进一步提高运维人员对数据库的整体运维能力。 提高数据库基础架构计算能力、存储性能与可靠性，减少原架构资源瓶颈。 构建基于硬件资源池的数据库服务，便于数据库服务能力的横向扩展。 计划对现有数据库版本进行升级，提高数据库的稳定性与问题支持能力；实现数据库架构的优化，在不降低安全性的基础上减少系统故障点。 通过数据库优化提升数据库服务能力及用户体验。 制定数据库平台健康基线量化指标，提高数据库管理水平。 通过本次项目，北京电视台主干系统公共数据库平台将实现 “三个转变” ： 整体架构由基于小型机的架构向基于 x86 平台的通用架构进行转变； 各数据库独立部署架构向基于硬件资源池的数据库服务架构转变，提升数据库服务横向扩展能力； IT 服务效率的转变，建立数据库平台健康基线及数据库运维管理知识库，提高数据库管理水平。 数据库迁移（Unix到Linux） 方法 北京电视台 主干系统公共数据库平台 目前正承载着台里关键业务的日常运营支撑，该系统从UNIX迁移到Linux平台不是简单的“操作系统更换，数据迁移”，而是一个复杂的系统工程，需要完善的现状调研分析及详细的规划设计，以避免迁移过程对现有业务运营带来不利影响。因此，要完成该项目需要科学的实施方法论指导，配备具有专业技能及丰富实施经验的技术专家来实施，以控制风险，顺利的实现业务平滑过渡的新的数据库系统平台。在本项目中，深圳市卓优数据科技有限公司将与具备科学、严谨的数据库迁移方法及丰富实施经验的EMC服务团队共同完成本项目工作，并按照EMC数据库迁移方法论来进行具体工作。 数据库迁移方法概述 EMC数据库迁移（Unix到Linux）方法论包括四个阶段，十六个主要步骤的工作，为U2L迁移工作提供了完整的框架指导，该方法如下图所示。 根据上图EMC数据库迁移方法，整个项目分为4个阶段： 调研分析 ：该阶段收集当前现状信息，为后续整体架构设计、详细实施方案设计提供基础依据； 规划设计 ：依据现状信息及业务发展趋势，规划整体架构，制定详细迁移计划、迁移实施方案，在方案中要同时考虑意外情况的发生，制定风险应急预案。 迁移实施 ：根据第二阶段的设计输出，进行实施操作，完成迁移实施。 迁移收尾 : 在完成迁移工作后，根据系统运行情况进行必要的优化处理操作，总结项目的经验及问题。 数据库迁移主要任务说明 调研分析阶段主要工作说明 调研分析阶段的主要目标是全面了解待迁移数据的当前现状信息，为后续整体架构设计、详细实施方案设计提供基础依据，具体任务包含： IT 基础 架构 系统调研, 包括 ： 数据库服务器当前物理资源配置调研； 数据库迁移目标云 平台 存储资源调研; 数据库备库运行 的壳系统存储平台 调研； 数据库 信息 调研 。 业务应用调研 ，包括： 业务高峰、低谷时段调研，为制定 迁移 窗口和数据库性能 分析 提供参考； 业务 重要性 调研，为 制定迁移计划 和 应急 策略提供 参考 。 应用架构及相关 信息 调研包括开发 架构、 语言， 数据库连接方式 、特殊 需求及 特征、 维护窗口 及时长、是否使用外部 数据 以及是否 有支持 人员等 。 U2L 迁移技术分析与验证 ，依据 前面调研的内容 选择数据库 迁移的 技术，包括： 可选迁移技术调研与评估； 选择数据库迁移技术； 对所选择的技术进行验证； 应用关联性分析 ，主要分析目标数据库与应用之间的相互关系，包括： 包括 应用和数据库的依赖关系； 应用之间 的依赖关系 ； 数据库和数据库之间 的 依赖 关系 。 应用关联分析是迁移 策略 和 业务恢复 方案的 基础 ，也是日后 运维 和 业务 连续性 方案的基础。 通过详细分析应用之间的关联关系，可以选择最合适的迁移方案，降低业务影响。 风险分析 ，通过对现状信息的调研分析，发现潜在的项目分析，以备提前做好风险应对方案。 规划设计阶段主要工作说明 规划设计阶段主要工作包含整体方法论中第第6到第10项，具体如下： 目标架构及部署方案 制定整体 目标架构 和 详细的 部署 方案。 部署 方案包括 能力规划(S izing) 、物理部署方案、数据库和操作 系统 参数 设定 、整体 备份方案和 数据库保护 方案 等 。 数据库的实际部署将按照该方案进行执行。 迁移实施方案详细设计 迁移实施方案 包括 详细迁移计划（批次安排及资源、时间安排）、数据迁移技术方案、迁移前技术准备方案、测试 验证 方案。其中，测试验证方案 应 包括下面内容： 数据完整性验证 性能验证 功能验证 开发 详细迁移 手册 在进行迁移实施操作时，需针对每个目标数据库开发详细 的迁移 操作 手册 ，该手册将详细定义迁移 的 每个 具体的 步骤、执行时间 和 执行人。该手册将作为实施操作的依据，同时也在项目结束后归档到知识库中，作为未来运维的参考。 应急预案 为防止不可 预知的 事件影响到 生产业务 或 数据 ，应急 预案不可或缺。 应急预案应 包括 备份与恢复方案和业务回退方案 。 其中 业务 回退 方案应详细 具体，明确回退 的 场景、 回退 时间点， 回退技术方案和回退的详细 操作 步骤 等 。 演练方案 由于数据库迁移涉及核心业务数据，迁移过程的安全可控为项目的重中之重。在正式实施操作的前的演练方案必不可少，通过演练可以让操作人员熟悉迁移操作，提前发现问题。 迁移 实施 阶段主要工作说明 迁移实施阶段主要工作包含整体方法论中第第12到第16项内容，具体如下： 迁移演练 为 确保迁移实施的顺利 ， 需要 在 测试 环境里进行 迁移 实施 方案 的演练，通过演练来验证迁移实施 方案 的步骤以及发现 和更正可能存在的问题 。在详细方案设计中，需要设计演练方案。 迁移 实施 严格按照迁移 计划和迁移 实施方案进行 迁移 技术 实施 。 测试 验证 迁移完成 后，按照 验证 方案 验证数据库和应用的各项 功能 及性能指标，确认新平台能满足业务运行要求。 系统割接 迁移实施完成、 按照 验证 方案 验证数据库性能、功能通过后，按照割接计划进行系统割接，业务访问请求将由新平台提供服务。 迁移收尾 阶段 主要工作说明： 在完成数据库由原平台向新平台的割接后，项目进入收尾阶段。项目组将通过 监控 分析新 数据库的 性能，确定新 的数据库是否需要 架构 优化 ，并在需要时对平台进行优化。同时，项目组对项目 文档 进行整理汇总、完善和 交接 ，总结项目的经验与教训， 作为用户的 知识库长期保存。这些文档也是用户 后期 的运维 和 变更 参考。 调研分析成果 依据U2L迁移方法 论 ，EMC 已经 完成调研 分析阶段的 IT 基础 架构 系统调研, 包括 ： 数据库服务器当前物理资源配置调研； 数据库迁移目标云 平台 存储资源调研; 数据库备库运行 的壳系统存储平台 调研； 数据库 信息 调研 。 整体架构 BTV 制播网SP ARC 平台 数据库 、待迁移 数据库 目标存储 云平台 和DataGuard备库 目标 存储壳系统 的 整体 架构如下 ： SPARC平台数据库每套RAC运行 在两台 SUN服务器 上，连接 两台独立 的 盘阵， 通过 卷管理软件镜像功能实现数据在两台 盘阵 上镜像保护。所有数据库通过 Golden Gate 和 部分数据库 同时也 采用了 Data Guard 保护。 数据 采用R MAN 将数据备份 到 一台NA S 设备 上。 云平台和壳系统运行的 是 虚拟化 业务系统 ，存储平台 均采用了 EMC的存储虚拟化 设备 VPLEX和 分别连接两台 EMC 盘阵，通过VPLEX的本地 镜像保护 技术实现V PLEX 连接 的两台盘阵 存储空间 的镜像保护。 数据库 现状 数据库基本 信息 北京电视台制播网大望路台址现有非新闻数据库13组，服务于13个业务子系统；其中8组集中部署于主干系统公共数据库小型机，5组分散部署于各子系统内部的X86服务器。 注：本次项目仅考虑大望路台址数据库，新闻系统数据库不在本次范围。 集中部署的8组数据库6组运行于SUN E2900或SUN T5440较老型号的小型机上，2组运行于SUN T4-2较新型号的小型机上（由于运行在SUN T4-2小型机上的数据库目前运行相对稳定、故障率相对较低，暂不考虑迁移）。概要情况由下图所示。 计划迁移数据库 不进行数据迁移需要优化评估的数据库 数据库 性能 分析 为了 评估 待迁移数据库和 DataGuard备库的 I / O负载和 评估 云平台 存储 系统、 壳系统存储系统 是否可以承载待 迁移 数据库和 DataGuard备库的 负载，EMC前期收集 了 SPAR C 平台数据库服务器 的I/O 性能数据和数据库AW R 性能 数据 并完成了 性能分析 。 EMC 专家重点分析了以下数据库性能： 数据库基本工作状况 数据库负载状况 CPU工作状况 Redo log 工作状况 Tablespace I/O 分布状况 I /O 状况 注：在项目前期过程已经投入专家资源对8套SPAR C 平台数据库进行了调研分析，本次计划迁移的6套数据库包含在8套数据库中。 具体分析结果如下： 数据库基本工作状况 ( 以媒资系统为例 ) 数据库负载状况 ( 以媒资系统为例 ) CPU 工作状况 ( 以媒资系统为例 ) Node1: Node2: Redo log 工作状况 ( 以媒资系统为例 ) Tablespace I/O 分布状况 ( 以媒资系统为例 ) I/O 性能分析 EMC收集 了 BTV制播网计划迁移数据库服务器 I/O 性能数据，并使用 EMC 专业 性能分析 工具，得出 生产数据库 I/O性能信息汇总叠加后的总的性能状况。 说明： I/O 分析结果是建设目标数据库存储系统可行性的重要依据，也是EMC专家重点分析内容之一 性能 数据 采集周期：201 6 年5月1 3 号至2016年5月20号 数据库备份产生的I/O不包含在以下 I/O 分析结果中 因为数据库备份通过 NFS 备份到外部的 NAS 文件存储设备上，数据库 迁移后备份产生 的 负载 不会落到迁移 目标存储设备上 ， 所以 下面性能数据剔除了N FS 这部分负载。 具体 I/O 性能分析结果如下： 生产数据库 I/O 性能分析 主机对磁盘操作的 IOPS ，最高峰值为3000 写I/O占 总 I/O的 百分比 平均 约为 35 % 服务器I/O性能数据分析结论 Total IOPS 峰值 :3000 读写比例平均约为： 65:35 备库 I/O 性能分析 EMC收集 了 BTV制播网备库服务器 I/O 性能数据，并使用EMC 专业 性能分析 工具，得出 生产数据库 I/O性能信息汇总叠加后的总的性能状况。 说明： 性能 数据 采集周期：201 6 年5月1 3 号至2016年5月20号。 数据库备份通过 NFS 备份到外部的 NAS 文件存储设备上，数据库 迁移后 因为 备份产生 的 负载 不会落到迁移 目标存储设备上 ， 所以 下面性能数据剔除了N FS 这部分负载。 主机对磁盘操作的 IOPS ，最高峰值为 1600 ； IOPS中写（W rite） 所占的百分比为 6 5% 性能数据分析结论 Total IOPS 峰值 :1600 读写比例平均约为： 35 :65 存储 现状分析 为了评估BTV制播网云平台存储 系统 、 壳系统存储系统 在高可用 、 容量和 性能 方面能否 承载 待迁移 数据库 和备库，EMC收集了制播网云平台 存储系统和 壳系统 存储系统 的配置 和性能数据 ， 并 使用EMC专业工具 做了分析。 云平台存储系统现状 云平台整体架构图： 云平台整体架构图 云平台是 BTV 制播网综合 管理平台 ，主要 运行的 业务包括数据库、公共服务等 系统 ，流程驱动系统和 融合资源 系统等。基础 架构 运行 在 多台X8 6 服务器 和 VMWA RE 虚拟化平台。存储系统采用一台2引擎V PLEX 和两台VNX 5400 盘阵。通过VPLE X 的本地虚拟化镜像 技术 实现两台VNX 5400 存储空间 的镜像保护 。存储网络由两台DCX-4S存储 交换 组成冗余架构，连接 服务器 、VPLEX和VNX 5400 盘阵 。 高可用配置信息 本地镜像 保护 云平台 存储系统 使用了EMC 存储虚拟化网 关设备 VPLEX，通过VPLEX的本地 镜像技术 将两台EMC VNX5400 盘阵存储空间在VPLEX上配置了 镜像 保护。通过V PLEX 镜像保护可以实现当 一台盘阵 出现 整体 故障时，服务器 仍可以 继续连接 并访问 云平台 存储系统数据。 冗余保护 V PLEX 、VNX 5400 盘阵和DCX -4S 存储 交换机 的关键 部件均采用 冗余设计。 SAN网络通过 两台 D CX-4S 交换机组成冗余 架构。 总结 云平台 存储系统 的高可用配置具备运行关键业务的能力。 容量信息 云平台 存储 空间 由两台 VNX 5400 盘阵提供，通过V PLEX 镜像 配置后 容量 信息 如下： 存储分层 RAID  类型 总可用 容量 (TB) 已分配容量 (GB) 剩余可用 (GB) 剩余总 可用容量 高性能FLASH盘 RAID5 1.4 1.28 0.12 5 .3TB 10K SAS 磁盘 RAID5 12.8 11.6 1.2 NL-SAS 磁盘 RAID6 32.2 28.2 4 目前云平台存储剩余可用的 空间为 5.3 TB ，小于待迁移 数据库 目前分配 的 12. 77TB 空间，考虑 到 数据迁移安全以及制播网业务未来的 增长 ，需要对两台VNX 5400 盘阵进行空间扩容。 性能信息 性能 数据 采集 周期 ：201 6 年5月16号至2016年5月23号 VPLEX性能信息 VPLEX前端IOPS VPLEX 前端I OPS 指来自连接服务器的I/O负载，可以反应 出 VP LEX 承载 的 I/O 负载。 前端IOPS峰值 为 12 000, 多数 时段 I OPS 低于40 00 。 VPLEX 前端 延迟 前端延迟指VP LEX 从接收 到 服务器I/O请求到 完成 该请求经历 的 时间。 读 延迟 峰值4 ms ，写延迟峰值3 .5ms 。 V PLEX 控制器bu sy D irector Busy 峰值 3 5 % ，大 部分 时间 低于2 0 % 。 VP LEX 性能评估 总结 当前VPLEX负载 不高 前端IOPS峰值 为 12 000, 多数 时段 I OPS 低于40 00 前端 延迟 低于4 ms Director busy 峰值 3 5 % ，大 部分 时间 低于2 0 % VP LEX 可以承载待迁移 数据库的 I/O负载 。 云平台当前I O P S 峰值为1 2 00 0 ，通过前期 调研 得知云平台目前还有约 一半 的业务尚未上线 和未来约20 %的 增长，云平台未来 负载 预估为1 2000*2*1.2=26400IOPS. S PARC 平台数据库I/O总负载约为3000 IOPS ，考虑到 未来 负载20 % 的增长IO PS 约为3 600 。数据库负载迁移 到 云 平台存储系统 后云平台未来 总的 IOPS负载约为3 2400 IOPS 。 在 该负载下通过EMC工具分析VP LEX 控制器 平均 利用率不超过50 % 。 VNX 5400 性能 信息 在VP LEX 本地 镜像配置 环境下 ， VPLEX连接 的两台 VNX 5400 I/O 负载相当， 下面 性能 信息 来一 台 V NX5400 盘阵。 性能 数据 采集 周期 ：201 6 年5月1 3 号至2016年5月2 0 号。 前端IOPS信息 VNX5400 前端 IOPS 峰值 约为 2 800, 大部分 时间 低于2000。 后端IO PS 后端I OPS 指VNX控制器写入物理 磁盘 产生 的 IOPS，后端口IOPS包含 了 RA ID 写 惩罚 导致增加 的 IOPS。 后端EDF闪盘IOPS峰值 约为 2 400 ，磁盘IO PS 峰值约为200 0 ，总IO PS 约为44 00 。 前端延迟 前端延迟低于1 ms. 控制器 利用率 VNX5400 控制器 利用率峰值 为约40 %, 大部分时间低于20 % 。 V NX5400 性能评估总结 VNX 5400 可以 承载 待迁移数据库I/O负载。 磁盘承载 能力 ：当前每台V NX5400 配置 的数据盘 为高性能 EFD 闪盘9块 ， SAS磁盘2 0 块，N L-SAS 大容量磁盘1 4 块。这些磁盘理论可承载IOPS可以 超过 200 00 个。待迁移 数据库 IOPS峰值 为 3000 , 在 不考虑 VPLEX和VNX 5400 缓存功能时，落在VNX 5400 磁盘 上的 最大IOPS约为500 0 个IO PS （已经考虑R aid 开销导致 的 IOPS增加）。现有磁盘 负载 440 0IOPS 加上数据库 产生的 IOP S 仍低于磁盘IOPS处理 能力 。 控制器 承载 能力： 当前 VNX5 400 控制器利用率大部分时间低于20 %, 远低于控制器平均 利用率 50 % 警戒 线 ，可以承载更多的负载。 V NX5400 全自动 分层 ( FAST) 技术可用于待迁移 数据库 上。 VNX 5400 采用了全自动分层存储（F AST ） 技术 ，热点 数据会自动 流 动 到 高性能的E FD 闪盘 上， 可以大大降低热点数据 的响应时间， 提高业务体验 。 待迁移数据库迁移 到 云 存储平台后 数据库也 同样会 受益 于 FAS T 技术带来 的 高I/O低延迟。 云平台存储性能分析总结 云平台存储系统的高可用 架构 可以满足待迁移 数据库 高可用要求 云平台存储 系统 可以承载待迁移 数据库的 负载 剩余可用 空间 不能 满足 待迁移数据库 要求， 存储系统需要扩容 壳系统存储 现状 壳系统整体 架构 壳系统整体 架构 图 壳系统平台 运行 多个业务系统 ， 其基础 架构 运行 在 多台X8 6 服务器 和 VMWA RE 虚拟化平台。存储系统采用一台2引擎V PLEX 和两台 CX4-480 盘阵。通过VPLE X 的本地虚拟化镜像 技术 实现两台 CX4-480 存储空间 的镜像保护 。壳系统存储网络和 云平台 存储系统共享两台DCX-4S存储 交换 。 高可用配置信息 本地镜像 保护 壳系统 存储系统 使用了EMC 存储虚拟化网 关设备 VPLEX，通过VPLEX的本地 镜像技术 将两台EMC CX4-480 盘阵存储空间在VPLEX上配置了 镜像 保护。通过V PLEX 镜像保护可以实现当 一台盘阵 出现 整体 故障时，服务器 仍可以 继续连接 并访问 云平台 存储系统数据。 冗余保护 V PLEX 、 CX4-480 盘阵和DCX -4S 存储 交换机 的关键 部件均采用 冗余设计。 SAN网络通过 两台 D CX-4S 交换机组成冗余 架构。 总结 壳系统 存储系统 的高可用配置具备运行关键业务的能力。 两台CX4-480盘阵 已经部署多年，原厂已经不再 提供 支持， 建议未来进行产品更新换代 。 容量信息 壳系统 存储 空间 由两台CX480 盘阵提供，通过V PLEX 镜像 配置后 容量 信息 如下： 存储分层 RAID  类型 总可用 容量 (TB) 已分配容量 (GB) 剩余可用 (GB) 剩余总 可用容量 F C RAID5 3.58 0.08 3.5TB 16.8TB FC&SATA RAID10 26.6 13.3 13.3 目前壳系统存储可以 提供的总的可用空间为16.6TB, 大于 目前生产 库分配 的 12. 77TB存储空间 ，一般备库空间需求和 生产库 相当，所以 当前 壳系统剩余 可用空间 可以满足备库需求 。 性能信息 性能 数据 采集 周期 ：201 6 年5月16号至2016年5月23号 VPLEX性能信息 VPLEX前端IOPS V PLEX 前端I OPS 峰值 20 00 0 ， 大部分时间低于 200 0 。 VPLEX 前端 延迟 前端延迟指VP LEX 从接收 到 服务器I/O请求到 完成 该请求经历 的 时间。 读 延迟 有存在短暂 峰值 达到2 0ms ， 大部分时间 不超过1 0ms ，写延迟大部分时间 低于10ms, 存在 两个 高点因 不具有代表性可以忽略 。 V PLEX 控制器bu sy Director busy% 峰值约55 %, 大部分 时间 低于30 % 。 VP LEX 性能评估 总结 VP LEX 可以承载备库 的 I/O负载 。 壳系统当前I/O负载 峰值 为20 000IOPS ， 待迁移 数据库备份负载并入 后 壳系统存储系统总的I/O负载 约为 21 600IOPS ， 考虑到未来 负载的 增长 按照20 % 的 增长 量预估，未来壳系统 存储系统 I/O总负载约2600 0IOPS ， 在 该负载下通过EMC工具分析VPLEX控制器 平均利用率 不高于50 % 。 VPLEX当前负载不高 V PLEX 前端I OPS 峰值 20 00 0 ， 大部分时间低于 200 0 。 读 延迟 有存在短暂 峰值 达到2 0ms ， 大部分时间 不超过1 0ms Director busy% 峰值约55 %, 大部分 时间 低于30 % CX480 性能 信息 在VP LEX 本地 镜像配置 环境下 ， VPLEX连接 的两台CX4-480 I/O 负载相当， 下面 性能 信息 来一 台CX4-480 盘阵。 说明 ： 性能 数据 采集 周期 201 6 年5月1 3 号至2016年5月2 0 号。 前端IOPS信息 前端IOPS是 来自 VPLEX的I/O负载。 前端IO PS 峰值约3 400 ， 大部分时间 低于1 200. 后端IOPS信息 后端I OPS 指VNX控制器写入物理 磁盘 产生 的 IOPS，后端口IOPS包含 了 RA ID 写 惩罚 导致增加 的 IOPS。 10K 转速光纤 磁盘 IOPS峰值 约为3 0 0,7K 转速SATA磁盘IOPS峰值 约为 1100。 前端 延迟 前端延迟峰值1 6ms ，大部分时段延迟低于 4ms. 控制器 利用率 控制器利用率峰值30 % CX4-480 性能评估总结 CX4-480 可以 承载 备库I/O负载。 磁盘承载 能 力：当前每台 CX4-480 配置 的数据盘 为22块光纤 磁盘 、 55 块SATA磁盘，理论 可以承载的 IOPS大约为 7000 。备库IOPS峰值为1 600, 在 不考虑 VPLEX和 CX4-480 缓存功能时，落在单台CX 4-480 磁盘 上的 IOPS约为2 360( 已经考虑R aid 开销导致 的 IOPS增加)。现有 磁盘的 负载1 400 加上待迁移 数据库 负载2 360 后仍 远小于 现有