前言
九月的北京,天空是那么的蓝,凉爽的秋风虽然略带了一点细砂,但还是从中能嗅到秋天的芬香,也足已可以把大家憋了一夏天的苦闷一下子释放出来了。
九月的Ontario lake ,是那么的美丽,碧水蓝天,让人心旷神怡;
九月的Rochester,是那么天高云淡,令人向往。
在这绝美的季节,Oct Release 项目也到了最后的关键的冲刺阶段。自从公司以“炸弹性”新闻收购美国某公司以来,就开始了国际化征程:大规模的ERP 项目在国内已经开展了一年,国内系统已经进行的差不多了,于是在这金秋季节,开始进军美利坚,作为是Oct Release中第一批在美国的正式系统。暂且不说技术上的难度,但对于公司的正在大踏步的国际化征途,对于公司Global IT 部门在祖国之外分公司,尤其是在号称遍地都是“高科技”的美国,实施归属中国总部管理的系统,意义的重大可想而知。
根据项目的安排,带着北京凉爽的秋风,我和老王、老程等一行三人坐上了飞往美利坚的飞机,经过长途跋涉,几次的展转换机。根据地图导向终于到了Rochester,由于那地方只是要安装系统的服务器托管在IBM的IDC 中,在那里并没有公司的分公司,因此,自然没有公司的人来迎接。IBM的人更不会那么无私的提供帮助了。于是一切都是靠自己找宾馆,找饭馆(其实,后来的项目实施异常的困难,也没机会和心情去吃吃美国的著名的烤牛排。。呵呵)。这个环节一切还算顺利,住的地方很easy解决了,吃饭的饭馆也看了几个,挺不错的。这些都安顿后,于是就真正开始了为期一周的美国Oracle EBS 系统搭建任务。
虽然美国和中国之间的MPLS已开通,但网络环境十分不理想,公司还没有真正在美国安装实施过production系统。而一周的时间对于需要安装多AP 、多节点RAC Database 的生产系统而言是紧张的,对于倒时差而言是辛苦的,并且只有一周的时间。
系统架构
此次系统的整体架构如下:
简单说明:
- Hardware: 全部是IBM P系列Server 和IBM 8100 存储
- 为达到Applications 的Load Balance 和Fail Over 的效果,采用2个AP Server
- 为达到database Load Balance 和Fail Over 的效果,采用双节点的ORACLE RAC 方式
- 所有服务器的操作系统均为64 bit AIX5L
- Cluster Software 采用IBM 的HACMP
前期准备
其实,在还没有到Rochester之前,已经在国内做了很周密的规划,虽然这样的配置已经在北京完成,并且运行的很成功,但对于到异国他乡的硬件环境以及操作系统完全有美国的IBM 工程师完成,还是有点不太放心,所以做了更多的技术上以及思想的准备,另外在公司的相关部门配合下了与IBM Rochester维护团队的进行了紧张沟通。因为之前我们和IBM的这个团队没有任何的合作,同时我和IBM还未建立起统一的文档沟通机制。尽管我们提供了系统的要求的很详细规划文档,给了IBM ROCHESTER 维护团队,但我们的文档的任何一条需求后面都可能存在理解上差异。 准备已经似乎很完备了,也似乎应该会很顺利按时完成的。但,事情的发展并非想象的那样。。。。。
架构历程:
第一天
和IBM ROCHESTER 维护团队负责人联系后,拿到了系统的IP以及用户密码等信息,总算可以登陆到服务器上了,但进去检查后,最大的发现操作系统中安装的HACMP 并没有安装需求完成。安装需求上要求是必须安装HACMP5.3 版本,而他们却安装了最新的版本HACMP5.4,而HACMP5.4 并不是ORACLE 验证过的,并且还没有听说有人在这样的版本中安装成功过。虽然在做了大量的沟通之后,但无奈美国人的做事方式,终于在一个工作日后拿到了似乎已经满足ORACLE EBS 搭建需求的系统。其实,同样的工作如果和中国的IBM朋友,可能也就3~4个小时就能完全完成,无奈可能是美国的做事方式,或者其他,协调、协调、再协调了整整1个工作日。这时虽然此次任务还没有正式开始,但总算可以稍微轻松喘口气了,但时间已经白白的过了1天了,此时时间已经到了美国时间的20:00。
为了夺会损失的时间,于是泡上从祖国带来的“康师傅”牌方便面,闻着方便面的香味,嚼着“张铁林他爷爷的爷爷的”榨菜,连夜开始了复杂的ORACLE EBS 系统的搭建。
根据ORACLE 的官方要求,对AIX 和HA进行了全面的检查,并准备了安装需要的用户环境以及编译工具,一切都准备了,于是就开始了正式的安装。开始的安装一切还算顺利,期间虽然出现了一些小的错误,但根据以前的经验都很简单的解决掉了。但安装到最后 出现ORA-03113 +ORA-07445 的错误,造成了节点2上创建数据库失败,虽然节点1上数据库安装成功了,但这是RAC 数据库啊,怎么着也就是整体安装失败。
此时的时间已经到没了美国时间的第二天中午。
第二天
虽然这样的系统已经搭建多次,但现在怀疑时候安装过程哪个地方出现了纰漏。于是,重新完全卸掉,并把第1次安装的东西完全删掉。于是有全神贯注的对6个SERVER 的环境进行全面的检查,更加仔细的进行正规的安装….等快结束的已经又12个小时过去了…..但最后还是同样的错误,节点2 上ORA-03113 +ORA-07445,创建数据库失败。并且ORACLE 并没有其他特殊的错误,期间打了无数的电话,问了认识的所有的朋友,都没有遇到这样的问题。
此时,大家都很累了,由于时差的原因,也分太清楚是白天还是晚上,差不多近3天3夜没睡觉(晕,到了美利坚,也不至于兴奋到这个地步呀。)
怀疑是不是ORACLE 的BUG,在METALINK 的搜索了大量的资料,也没发现相关的信息。
实在没办法了,只有 向ORACLE 发布最高级别的TAR 了,不亏是一级TAR ,ORACLE 很快给了响应,根据他们的要求,提供安装日志,提供ALERT 日志……….由于是印度的工程师负责,自己的英语口语也就“HELLO”,“THANKS”这样的水平,再加上那印度口音的英语,实在没办法有电话沟通了,只能在METALINK上交流.
他们把信息收集后,说要分析。。。。于是,一边趁机迷瞪会,一边等ORACLE 的分析结果,时间已经过去了8个小时了,ORACLE 还在分析,也没有给予明确的答复………
第三天
其实,天已经很亮了,新的一天又开始了,而我们的时间又要白白浪费了一天.
根据以前的经验,并且北京的系统也是同样的环境,并能正常安装成功和运行的很好。基本可以否定ORACLE 的BUG. 时间紧迫啊,等ORACLE 的给结果还不知道猴年马月呢,于是决定不再指望ORACLE 的技术支持,决定自己去判定可能的造成的原因
以前,一直特相信美国人的技术很专业,近乎有点迷信的程度了,所以,一直没敢怀疑是不是美国IBM 工程师安装的AIX 是否有问题。虽然安ORACLE 的安装需求是完全满足的。但现在的确没辙了,不怀疑真的过不去了,于是为了测试出现问题的节点2 服务器的操作系统是否真有问题,不安装了RAC 数据库 ,而是直接安装一个单点的ORACLE 数据库。但到最后,在要创建数据库的时候,同样的问题,同样错误出现了….同样是ORACLE 的进程起来后,一会就会自动断掉,出现ORA-03113 +ORA-07445的错误。
哈哈,现在,完全可以断定操作系统肯定有问题了。此时已经是第三天美国时间下午1点多了。
发现的这个特别严重的问题,于是想美方IBM提出协调,而美方以已完成了我们所提出的所有需求为理由,不再提供进一步的Support。这或许就是美国人的做事方式。协调、协调、再协调,这次怎么也没协调成功。就这样一个下午又白白过去了。
既然美国IBM 不给support,只有自己想办法了,于是向中国的朋友求援.虽然,现在的时间是北京的凌晨了,但中国的朋友还是很热情的给予援助。通过IBM的朋友很专业的分析和对比:
发现这台服务器是曾经打过ML06的补丁,但又删掉了,却没有完全删掉了,有一部分文件处在ML06,但大部分文件却是ML05的完整文件,并且经过对关键包的对比,这台服务器和另外一台做双机的机器有很大差异,这样文件不一致,存在BUG 的可能性很大。 决定把补丁升级到ML06的全补丁。他们开始下载ML06的补丁包,2G大小的包,通过internet 下载然后传到服务器上,再解开,怎么也需要半天的时间。此时没有我的事了,也帮不了什么了,于是再吃点方便面、迷迷糊糊睡一会。
第四天
迷迷忽忽睡了一觉,IBM 工程师把补丁总算打完了。
为了测试系统的可用性,减少出现错误再重来的时间,决定在有问题的机器上先安装一个单纯的单点ORACLE 数据库,一切顺利,创建数据库成功。
第四天美国时间 20点又开始 ORACLE EBS 安装。
第五天
经过大概12小时的正常安装,成功!!!
此时离出发去机场还有2个小时……………….
此时幸福是什么? 睡觉、睡觉、再睡觉。
几个小时侯后,坐上了回祖国的飞机。
后续
回国后,和美国那边再次沟通,美方在事实面前也不得不承认,是他们的疏忽所造成。
总结
在这7天的时间里,由于倒时差和无尽的加班,老程睡眠不到40小时,老王睡眠不超过25小时,我连20小时都不到。这次美国之行没有时间去领略五大湖的宜人景色,也没有时间去领略美国的风土人情;但领略到了国际化道路的不易,领略到了中美团队之间对工作方式和态度的差异,更看到了中国团队的勤奋和无限的生气……