4.1-数据迁移方案-完整版

BBACNetApp办公存储升级项目存储数据迁移方案北汽蓝谷&NetApp20190723项目会议议题2总体架构介绍实施计划邮件系统迁移-SAN其他SAN数据迁移NAS数据迁移风险评估和建议决策项目汇总总体架构介绍老架构4新架构5HPUXVMwareExchangeFileServicesFAS9000MC集中控制和管理HPUXVMwareWindowsFileServicesDC2数据中心DC1数据中心利旧FAS6280,FAS3210,FAS3210备份存储ISL新生产存储新生产存储迁移方法、工具介绍6迁移方法介绍：1.vmware的storagevmotion：在新存储创建新LUN映射给vmware后，通过vmware成熟的svmotion功能在线平滑的将所有老vmware数据（位于老存储）迁移至新存储2.7mtt工具：此工具由netapp提供，实现存储到存储间的数据卷镜像1:1迁移。迁移的单位是volume卷。迁移组织结构是：project，每个Project可以包含一个或多个卷，每个Project是一个独立的割接组，及每次割接的最新单位是一个project（即此project内包含的所有卷一起割接）；3.邮件迁移：邮件数据迁移通过7MTT工具完成，通过exchange的DAGHA切换功能实现不停机操作。4.其他系统迁移：通过7MTT工具完成，割接时需要停机，前端需要重新挂载访问新存储LUN/volume。迁移系统迁移方法是否停机备注虚拟化vmware的storagevmotion在线由vmware保障虚拟化（带裸设备映射）7mtt工具停机邮件系统7mtt工具在线由exchange保障数据库等其他LUN7mtt工具停机NAS类（文件共享）7mtt工具停机裸容量对比—老存储-裸容量690T7裸容量对比—新存储-裸容量404T8待迁移数据量汇总-卷裸容量349T9实施计划总体项目计划11总体项目计划（续）12数据迁移总体计划13数据迁移总体进度简述14原邮件，虚拟化裸磁盘映射等LUN磁盘全部关闭并清除，计划变更为分多个Project组迁移邮件组单独创建Project迁移组，未开启迁移，未割接虚拟化裸设备映射单独创建Project迁移组，未开启迁移，未割接NAS部分根据6个老存储分别创建6个Project迁移组，目前大部分已经完成迁移，未割接虚拟化的LUN磁盘部分由vmwarevmotion执行前端迁移，目前大部分已经完成迁移并割接数据库单独创建Project迁移组，已经完成迁移，未割接数据迁移完成（基线传输）预估15业务系统协议剩余待迁移数据量完成时间预估迁移策略邮件FC54T11天60M/s，全天候数据库及虚拟化裸设备FC8T2天NASCIFS,NFS6T2天建议割接次序16邮件组在线依次割接（分2-4次）虚拟化裸设备映射，和数据库等其他LUN一批割接全部NAS共享一批割接割接具体方式和批次依最终业务方意见和停机窗口决定邮件系统迁移-SAN分批迁移18利用Exchange的failover功能分批进行迁移，此方案优势在于可以不停机迁移MD01MD02MD03MD04FAS6280FAS9000邮件服务器迁移阶段一191阶段一日期和时间耗时Owner备注开始MB-04服务器中所挂载卷的数据基线复制（共176个卷）？？2-4天NetAppExchange工程师将MB-04服务器修改为非活动状态？？30分钟Exchange工程师在7MTT软件中做最后一次基线复制？？10分钟NetApp将MB-04的FC线连接到新交换机？？30分钟NetAppExchange工程师将MB-04服务器修改为活动状态？？1小时Exchange工程师业务验证（邮件收发测试）？？10分钟用户邮件服务器迁移阶段二201阶段二日期和时间耗时Owner备注开始MB-03服务器中所挂载卷的数据基线复制？？2-4天NetAppExchange工程师将MB-03服务器修改为非活动状态？？30分钟Exchange工程师在7MTT软件中做最后一次基线复制？？10分钟NetApp将MB-03的FC线连接到新交换机？？30分钟NetAppExchange工程师将MB-03服务器修改为活动状态？？1小时Exchange工程师业务验证（邮件收发测试）？？10分钟用户邮件服务器迁移阶段三211阶段三日期和时间耗时Owner备注开始MB-02服务器中所挂载卷的数据基线复制？？2-4天NetAppExchange工程师将MB-02服务器修改为非活动状态？？30分钟Exchange工程师在7MTT软件中做最后一次基线复制？？10分钟NetApp将MB-02的FC线连接到新交换机？？30分钟NetAppExchange工程师将MB-02服务器修改为活动状态？？1小时Exchange工程师业务验证（邮件收发测试）？？10分钟用户邮件服务器迁移四221阶段四日期和时间耗时Owner备注开始MB-01服务器中所挂载卷的数据基线复制？？2-4天NetAppExchange工程师将MB-01服务器修改为非活动状态？？30分钟Exchange工程师在7MTT软件中做最后一次基线复制？？10分钟NetApp将MB-01的FC线连接到新交换机？？30分钟NetAppExchange工程师将MB-01服务器修改为活动状态？？1小时Exchange工程师业务验证（邮件收发测试）？？10分钟用户待迁移数据清单-54T实际数据23待迁移数据清单24待迁移数据清单25待迁移数据清单26待迁移数据清单27待迁移数据清单28待迁移数据清单29迁移工具展示30迁移工具展示31迁移工具展示32迁移工具展示33迁移工具展示34迁移工具展示35迁移工具展示36迁移工具展示37目前迁移进度38全部未开启，等待审批其他SAN数据迁移40迁移和割接架构407MTT整体将所有LUN迁移至新存储后，Oracle等系统重新指向磁盘路径到新存储SBDC2D026SBDC2D027虚拟化（裸盘映射）其他LUN系统FAS6280FAS900041数据库服务器等LUN迁移和割接1阶段一日期和时间耗时Owner备注开始SBDC2D026,SBDC2D0267，虚拟化裸盘映射等带LUN服务器中所挂载11个卷数据基线复制？？10天NetAppOracle工程师将服务器停机？？30分钟Oracle工程师在7MTT软件中做最后一次基线复制？？30分钟NetApp将物理服务器的FC线连接到新交换机？？30分钟NetAppOracle工程师将服务器开机？？1小时Oracle工程师业务验证？？10分钟用户待迁移数据清单-8T实际数据42迁移工具展示43迁移工具展示44迁移工具展示45目前迁移进度46数据库迁移完成虚拟化裸设备映射全部未开启，等待审批NAS数据迁移48迁移和割接示意图487MTT整体将所有NAS卷迁移至新存储后，主机系统重新指向磁盘路径到新存储文件共享文件共享门户网盘FAS6280FAS900049NAS服务器和客户端卷迁移和割接1阶段一日期和时间耗时Owner备注开始文件共享，门户等NAS服务器中所挂载83个卷数据基线复制？？10天NetAppNAS服务器停机？？30分钟NAS客户端在7MTT软件中做最后一次基线复制？？30分钟NetApp将新存储配置老NASIP并加入AD域？？30分钟NetAppNAS服务器开机？？1小时NAS客户端业务验证？？10分钟用户待迁移数据清单-60T实际数据50待迁移数据清单51待迁移数据清单52待迁移数据清单53迁移工具展示54迁移工具展示55迁移工具展示56迁移工具展示57迁移工具展示58迁移工具展示59目前迁移进度60Sf002,Sf003,Sf005迁移未完成Sf001,Sf004,Sf006迁移基本完成目前迁移进度-迁移中s00261目前迁移进度-迁移中s00362目前迁移进度-迁移中s00563风险评估和建议风险评估概览65容量爆满风险（特别是LUN）：Netapp存储的层级是aggregate---volume---lun，volume空间预留不足情况下，存在lunoffline风险，导致前端主机无法识别到LUN磁盘，进而影响相应业务。容量矛盾点：当前老存储待迁移卷裸容量达349T，但新存储空间为404T，迁移后目的端使用率达86%，间接制约了源端空间的扩容幅度，即源端容量的扩容极限空间为55T。7MTT工具迁移依赖存储底层卷的快照snapshot技术，卷做了snapshot后，任何数据变化（增删改）都回额外占用卷空间，同时每次做增量传输时比对源端和目的端差异会临时占用额外空间为了避免出现lunoffline情况，强烈建议：volumelevel预留10%剩余空间（如果卷启用了重删压缩功能，则需要预留14%的剩余空间），aggregatelevel预留5%注意：预留10%空间仅适用于绝大部分场景，实际环境中不用类型业务有不同特点，及一定不可控空间增长因素，需要存储管理员加强空间监控的同时，还需要对业务空间有一定的管控和预测，尽量避免短期大量数据变动。同时缩短7mtt的增量更新周期，尽早完成割接操作。数据漏迁移，数据不一致7MTT迁移工具自身官方设计可以保障数据一致性，但由于数据owner众多，需要用户加强内部卷统计梳理，相应owner确认，提前通知owner做割接及数据验证。数据迁移过程中对业务性能影响迁移过程中占用存储的磁盘IO资源，存储网络接口，及交换机网络产生一定压力，当前迁移计划为20:00-5:00区间60M每秒的速度迁移，建议调整为全天候60M每秒速度迁移（每天可迁移5T数据），同时监控业务压力适当实时调整.服务器硬件故障风险迁移，特别是割接过程中，涉及到服务器重启，线缆插拔，有一定的硬件故障风险。风险点详情-磁盘爆满风险-高风险66以下卷使用率均超过95%，需要扩容，降低使用率至90%以下，特别是FC协议的卷（含LUN的卷）风险点详情-磁盘爆满风险-中等风险67以下卷使用率均超过90%，建议扩容或密切关注容量变化，保持使用率90%以下，特别是FC协议的卷风险点详情-磁盘爆满风险-中等风险68以下卷使用率均超过90%，建议扩容或密切关注容量变化，保持使用率90%以下，特别是FC协议的卷风险点详情-磁盘爆满风险-中等风险69以下卷使用率均超过90%，建议扩容或密切关注容量变化，保持使用率90%以下，特别是FC协议的卷风险点详情-磁盘爆满风险-中等风险70以下卷使用率均超过90%，建议扩容或密切关注容量变化，保持使用率90%以下，特别是FC协议的卷风险点详情-磁盘爆满风险-中等风险71以下卷使用率均超过90%，建议扩容或密切关注容量变化，保持使用率90%以下，特别是FC协议的卷风险点应对方案-磁盘爆满风险-172通过分析数据可知：空间使用率较高的应用主要是邮件系统；相应的AGGR为s600f001的aggr_450g_01,aggr_900g_01和s600f001的aggr_900g_01虚拟化已经通过vmwaresmotion功能完成数据迁移和割接：共197T（卷裸容量），其中LUN裸容量168T.此类卷可以删除来释放老存储空间，用于扩容卷使用率超过90%的卷。割接完成后，根据需要重新调整卷空间容量。可以删除的卷信息如下：FilerAGGRAGGR总容量AGGR使用率s688f001aggr_450_015473687aggr_900_017570396aggr_450_root36672s688f002aggr_450_013820586aggr_900_017566689aggr_450_root36672风险点应对方案-磁盘爆满风险-273新存储总空间配置约404T，老存储总数据量（卷总裸容量）约349T，迁移后目的端使用率达86%，间接制约了源端空间的扩容幅度，即源端容量的扩容极限空间为55T。为此建议源端存储空间加强空间监控，在55T（建议50T）以内完成扩容操作。风险点详情及应对方案-数据迁移过程中对业务性