基础架构升级的典型问题与案例Word文档格式.docx

基础架构升级的典型问题与案例Word文档格式.docx

《基础架构升级的典型问题与案例Word文档格式.docx》由会员分享，可在线阅读，更多相关《基础架构升级的典型问题与案例Word文档格式.docx（9页珍藏版）》请在冰豆网上搜索。

F.待LV同步完成并确认无误后，删除原存储的镜像。

G.将原存储的lun从操作系统的vg中删除，并删除设备。

H.原存储设备下线，完成迁移。

这种迁移方式的优点是，在线迁移，不需要停机窗口，而且直接使用系统内置的lvm功能即可，不需要额外的license费用，。

缺点是受限于操作系统特性，如果操作系统不支持LVM特性，就无法采用了。

补充：

如果存储层面采用了类似的第三方存储软件产品，如VxVM、GPFS等产品，也可以支持这种迁移方案。

（2）.基于虚拟化平台的角度。

以VMware为例。

C.新存储划分同规格LUN给到集群中所有ESXI上。

D.利用Vmotion和storageVmotion执行虚拟机和存储的迁移。

E.待全部迁移完毕，并且稳定一段时间后，拆除旧存储LUN。

这种迁移方式直接通过vmware来实现，迁移之前需要查询官方文档，检查迁移的限制及版本之间的兼容性，并做好相关测试。

这里仅讨论vmware平台，PowerVM平台的vios本质上就是aix，可以基于lvm来做。

（3）.基于应用软件本身特性来做。

这里以oracle和db2为例

Oracle-ASM方式：

配置ASM冗余策略，利用ASM将新LUN加入到磁盘组的冗余组当中。

待数据同步完毕，并且稳定一段时间后，拆除旧存储。

重新配置ASM冗余策略。

D.服务器识别存储端的lun，并配置为asmdisk或raw设备

E.将新的磁盘加入asmdiskgroup，再删除原有的磁盘成员。

F.asm会自动同步，通过查看v$asm_operation可监控进度。

G.同步完成后即可将设备删除，下线。

优点：

可以在线做，不停止业务。

缺点：

自动平衡，无法控制进度，一旦出现问题不好解决。

oracle暂不支持asm冗余类型的转换，所以原生为external模式的asm磁盘组不能使用镜像的方式来做。

Oracle-other：

-可以使用backupascopy的方式替换存储，停机时间较短。

-可以采用dg物理备库的方式做。

在线。

-可以采用oraclegoldengate的方式来做。

-备份恢复或数据泵导入导出。

停机时间长，取决于数据量。

DB2-storagegroup方式：

D.服务器识别存储端的lun，配置对应的文件系统系统。

E.通过storagegroup增加删除path的方式替换存储。

或者在新存储的文件系统上创建新的storagegroup，通过更好storagegroup的方式更换存储。

F.同步完成后即可将设备删除，下线。

在线迁移。

db2存储组要求10.1或更高，需要设计好重平衡的时间。

可以使用其他复制方案在线做，比如ogg、cdc、q复制等。

也可以选择db2move或者重定向恢复等方式，停机时间依据数据量大小而定。

（4）.基于存储本身的角度来做。

现在很多主流厂商的存储设备都自带存储虚拟化网关功能，或者提供迁移向导。

可以在线的将原有存储数据迁移到新存储，以ibmv7000举例，执行如下步骤即可。

A.新的v7000设备安装上架加电测试

B.将v7000加入san环境中，重新设计zone信息，原有的存储和v7000做存储zone，v7000和主机做hostzone

C.原存储的lun映射给v7000，v7000以image模式识别。

D.V7000将数据迁移到自身存储。

E.迁移完毕后，取消原存储的映射，原存储下线即可。

停机时间极短，更改zone映射等。

对应用透明，上层改动小

需要存储支持，需额外的license。

综上，迁移的方法有很多，但对于用户来说，具体情况具体分析。

要选择最适合自己的方式，而不是片面的追求新技术。

另外，所有的实施操作之前一定要做好备份，做好备份，做好备份，重要的事情说三遍。

2.新购买的存储无法兼容前端老旧系统，系统升级及迁移该如何设计规划？

又一个典型的场景，明明设计好的数据迁移，结果因为兼容性又带来了升级问题。

一般情况下，在进行设备更换类型的数据迁移时，需要提前对新设备的兼容性做好确认工作，以免遇到兼容性问题导致迁移失败。

一般的兼容性问题包含两个方面：

（1）.主机设备无法兼容新存储，比如新采购的v7000存储，主机还是最古老的rs6000小机。

就有可能遇到兼容性问题，或者虽然可以凑合使用，但是无法充分的发挥新设备的性能。

这种情况其实还是建议升级前端主机的。

（2）.主机设备上的操作系统无法兼容存储，比如新存储的多路径或存储代理等软件需要较高的操作系统版本支持。

这时就需要规划操作系统的升级，以更好的满足存储的兼容要求。

但是操作系统的升级又可能涉及到应用软件的兼容性。

需要做好通盘规划。

以免升级后，存储可以使用了，应用出现了异常。

除此之外还有一些特殊情况，比如应用软件已停止更新多年，只支持非常古老的系统，但更新的硬件设备又无法安装老系统。

这时可以考虑通过虚拟化的方式实现。

对于x86环境，可以使用vmware虚拟化，并做p2v迁移。

对于Power平台，aix7.1支持versionedwpar功能，支持将5.2的aix迁移到7.1的wpar里面。

这样就可以解决旧版操作系统和新设备之间的兼容性问题了。

3.上层应用升级更新后，新版应用不支持原来版本的数据库，如何规划升级？

一般整个业务系统的构成包含很多层面，从底层的存储系统、san网络、上层的主机、数据库、中间件等等都又涉及。

有的时候看似简单的上层应用升级，却可以牵涉出大量的兼容性问题。

比如新版本的应用对jdk的版本有要求，现有的applicationserver又不支持新版的jdk。

升级了新版中间件后呢，发现中间件和数据库的兼容性又有待确认。

这种升级场景实际上就是由上层应用倒逼的被动式升级了，已经到了不得不做的地步了。

这种类型的升级还是建议按照传统模式的来，涉及应用的兼容性，其他需要做好测试和规划，一般包含如下步骤：

（1）在新的设备搭建一套新的环境，包括数据库、应用服务器。

（2）在新的环境中导入测试数据，前端从业务层进行相关可用性验证

（3）进行数据被备份迁入到测试环境的相关数据迁移时间实测评估

（4）进行数据库系统的升级测试，测试后再次进行应用验证

（5）停止生产系统的应用系统进行数据库升级，一般选择的停止窗口在业务低峰期，由于前期准备活动充分，基本系统停机时间约等于数据库升级时间。

（6）升级完成后进行应用层面的验证。

需要注意的是，升级之前一定做好数据备份并验证。

准备好回退机制。

4.采购的新服务器设备不支持旧版操作系统，但因为停止更新的应用仅支持旧版os，应用迁移如何规划？

硬件产品对软件的支持都有兼容性要求，尤其是服务器产品。

比如新采购的x86服务器，想再安装windows2003或者windows2000就比较困难了。

但是因为应用的限制，又不能支持新版的操作系统。

目前，虚拟化的架构应该是解决这种问题的一个很好的手段，而且技术成熟。

维护简便，风险小。

通过虚拟化平台的p2v迁移功能，可以将整个应用系统连同操作系统一起迁移到虚拟化平台上。

对于x86平台来说，vmware占据了大部分的企业级虚拟化市场份额。

vmware虚拟化环境支持大多数主流操作系统，通过实施基于vmware的p2v迁移，我们可以原来的应用和操作系统一起迁移到虚拟化平台。

并通过虚拟化平台做虚拟机级别的保护，使得应用同时得到性能和稳定性的收益。

至于Power平台，对于早期旧版本的aix系统，通过使用aix7.1内置的versionedwpar功能，可以将aix5.2/5.3版本的aix迁移到最新的Power8处理器平台，被迁移的aix版本最早支持到aix5.2sp8。

但从长远来看，这终究这是一种治标不治本的手段。

随着后续硬件的发展更新，将会拖着虚拟化的平台一起升级。

最终可能还是会出现兼容的问题。

根本的解决办法，还是在信息化上持续的投入，即使不保持实时系统最新，也尽量不要让软件和应用的的版本太落后。

总的来说，升级是大势所趋。

无论当下有怎样的困难，拖到最后也难免升级的命运。

5.原有的备份软件Network备份在带库的数据，如何迁移到新的、其他备份软件中，如TSM？

这种情况因为涉及到两种备份架构的变更，所以还是比较麻烦的，一般来讲有如下两种实现方式：

（1）.直接部署tsm环境，备份数据到新tsm系统。

同时老的networker环境也不要删除，同时共存，只是将networker的备份调度都停了。

等老network环境里的数据过期后，老磁带可以直接拿到新tsm环境中打标重用。

（2）.利用IBMButterfly软件，直接迁移数据到新环境中。

这个是ibm的一个服务，感兴趣可以找ibm咨询下。

6.单台存储设备有必要升级为双活吗？

升级之后会不会影响到读写性能呢？

目前是单台V7000设备，出于安全考虑有了增加一台V7000做成双活的想法，请问升级之后会不会影响到读写性能。

关于是否要升级为双存储，主要是看自己的实际情况，如果对可用性有严苛的要求，肯定需要从架构上补齐短板，双存储确是可用增加可靠性。

具体到存储高可用如何做呢，有两种实现方式：

（1）.可以基于主机做，如lvmmirror，基于主机lvm做的话还是需要调整一些东西的。

以aix接双存储为例：

a.创建vg的时候quorum应该为no

b.硬盘hdisk的rw_timeout（每个读写操作超时的时长）和（发现丢包后多长时间通知主机的时长）参数的调整。

c.fscsix光纤卡设备的fc_err_recov参数，建议改为fast_fail默认为delay_fail,故障时，可减少重路由时间

d.lv的读写策略，建议为chlv-dpsxxxlv即写所有，从主读取，保证读取速度

（2）.可以基于存储做，如vdm，在使用中实际是单读双写，性能会略有一点延迟，但不会太大。

可以用工具压一下对比看看，如iorate工具，或者是oracle的orion工具。

二、升级和迁移案例分享

案例一：

一次失败的aix系统升级以及挽救过程

原本是特别简单的一个case，数据库出现故障，经过数据库工程师分析是ibmaix的一个系统bug，需要升级aix补丁。

原计划的操作流程如下：

1.rootvg拆镜像

2.磁盘克隆（备份用，想着如果出了问题可以回退）

3.升级aix，重启

4.数据库启动并验证。

实际执行过程如下：

1.rootvg拆镜像，成