项目经验-汪海

项目一：单节点数据库转到oracle rac

项目简介（功能与用途）： 项目发生在04年初，由于当时采用的是基于linux的pc server，随着网站访问量的突飞猛涨，单台linux server已经基本达到了瓶颈，主机端系统load基本在10以上，由于linux server的硬件已经不能扩展，而当时的预算又不够采用小型机，所以需要有一种可扩展方案来解决。这个时候我们就想到了使用oracle 9i rac来实现数据库的横向扩展，同时对应用系统做切分，分成了3个数据库，每个库设计容量是2个节点，可以提供一天5000万次访问量的方案。   项目难点与解决方案： 在确定方案后，我们开始针对机器进行选型测试，对比hp4640和sun880单节点数据库和dell linux server跑oracle rac的性能，我们的测试团队设计了测试用例，用app集群直接跑网站真实应用去测试数据库性能，测试结果在相同访问量下dell pc server跑2个节点的rac的sql相应时间最短，所以最终选定了dell linux server＋oracle rac的方案。在存储方面我们最初是用netapp的nas存储作为数据库存储，但是在使用过程中发现netapp的nas存储在数据块频繁变化的环境下多块读的效率不是十分理想，所以决定采用emc 的CLARiiON系列存储。选型完毕后项目进入实施阶段,实施初期是搭建san存储架构，把所有emc存储通过光纤交换机和主机相连，每2台pc server拖一台存储，一共是6台pc server加3套存储。在存储架构搭建完毕后，我们开始创建oracle rac，采用2个节点的rac， 然后开始进行数据迁移方案，我们使用oracle 的materialized view来同步大表，在切换前几天基本实现新老系统的大表持续同步，在系统切换当晚我们切断老系统，刷新materialized view最后一点还没同步的数据到新系统，同时远程insert小表到新系统，总共切换时间在30分钟之内完成。系统切换后重新启动应用服务器，整个应用系统正常提供服务。   项目成功与失败的经验归纳： 在新系统上线后，主机端load下降到0.5左右，用户反映系统相应速度明显提升，app服务器的等待队列明显减少，在很长一段时间里面这套系统都表现出了相当稳定的运行状态。 这是我们第一次使用集群数据库，同时也是第一次使用san存储，整个方案完全由我们的DBA,SA,JAVA构架师，测试团队制定并实施，在当时的业界我们的做法还是比较领先的，也是oracle rac的早期用户。在一段时间的稳定期后，由于业务的飞速发展，我们的系统访问量达到了8000万次每天，在这个时候rac的一些弊端开始显示出来，由于应用没有不是针对RAC系统专门开发的，所以rac cache fusion的代价非常大，在变化频繁的系统上，rac 的一系列wait event占据了大部分的系统等待时间，系统效率开始下降。同时当一个节点发生问题时而down掉时，另一个节点要恢复坏掉的节点的数据，在这个恢复阶段所有应用将hang住直到恢复完毕，通常在这个时间段里面前台的app服务器由于请求太多不能响应而挂掉，所以基本上在繁忙的系统上rac的平滑切换将很难实现，这也决定了我们后来从RAC退回到单节点数据库。   你在项目中岗位与贡献： 负责制定产品预算 负责产品选型沟通 参与制定测试用例 参与测试 负责San网络搭建 负责系统安装调试 负责存储规划 负责数据库建立 负责数据迁移 负责系统切换 负责后期维护 负责后期应用优化 sql审核，sql培训

 

项目二：dell linux server向ibm p590系统迁移

项目简介（功能与用途）： 项目发生在05年初，距离上次系统升级一年时间，在这一年时间里，公司业务飞速发展，日访问量从2000万次增长到8000万次以上，oracle rac在这急速增长的压力下也暴露出一些问题，由于rac cache fusion的内耗越来越严重，再对rac扩展节点的方案基本被否定，同时因为rac的维护成本比单节点数据库要高很多，所以我们定下来下一步方案要采用基于UNIX小型机的单节点数据库。系统设计容量要求要能支撑2亿次每天的访问量。   项目难点与解决方法： 和上一次升级一样，我们从硬件测试选型开始，这次我们选型了hp superdome Integrity服务器和IBM P590进行对比测试。和上次系统升级一样，我们的DBA,测试团队，JAVA架构师组成了一个特别测试组去hp和ibm的测试中心进行了对比测试，用我们自己的系统跑测试，最后对比下来IBM的P590在高并发情况下机器的响应时间曲线比较平稳，同时由于AIX系统的很多自动化管理功能可以简化对主机的维护工作，我们最终选定了IBM P590做为新的数据库服务器。在存储方面，我们处于成本考虑并没有更换原先的存储，继续使用了EMC CLARiiON系列存储。由于我们在上一次系统升级后对所有rac数据库又建立了dataguard做备份数据库，这次升级我们把dataguard库的CLARiiON存储先行接到了P590上，然后在p590上建立oracle数据库，同上次系统升级一样，我们采用materialized view来同步数据，力求达到最短停机时间。同时我们调整了我们所有的监控脚本，保证了新系统的预警功能。另外我们建立了dataguard系统，保证了系统的可靠性。最终切换时间我们也控制在了每个数据库30分钟以内。   项目成功与失败的经验归纳： P590系统上线后，我们的系统load从6下降到1以下，另外我们使用了AIX的LVM来管理磁盘，降低了很多原来使用linux raw device管理上的成本。 这是我们第一次使用基于UNIX的服务器，也是国内最早一批使用P590的用户，在系统上线相当长的一段时间内都保证了业务的可持续快速发展。在系统升级的实施方面由于有了上一次的经验，这次升级做到了更加平滑的切换，所有的监控脚本都经过测试运行，保证了新系统的预警。在这套系统跑了一段时间以后，主机端依然提供了非常强劲的功能，但是由于数据库的不断扩大，越来越多的i/o等待开始暴露出来，针对这个问题我们升级了主机的内存，加大了data buffer,同时为了保证系统的可扩展性，我们最终选用了sun 9990系列存储，基本上是系统实现了线性可扩。   你在项目中岗位与贡献： 负责制定产品预算 负责产品选型沟通 参与制定测试用例 参与测试 负责San网络搭建 负责存储规划 负责系统安装调试 负责数据库建立 负责数据迁移 负责系统切换 负责监控体系建立 负责后期维护 负责后期应用优化，sql审核，sql培训

 

项目三：淘宝网远程容灾站点,建立容灾数据库

项目简介（功能与用途）： 在系统切换到了UNIX平台后，我们的关注点从性能开始转换到高可用性上，陆续建立了dataguard，hacmp，提高了系统的高可用性。这个时候我们觉得应该考虑灾备，美国的911事件导致了很多公司一夜之间所有数据都消失无踪，对于我们这种对数据库依赖性极大的公司来说，数据就是生命，我们一定要做好灾难备份。处于成本和实施难度考虑，我们提出了整个灾备的过程分3部走的想法，首先建立一个最简单的容灾站点，可以保证数据不丢失，但灾备站点不提供对外服务。第二步，实现准实时不同城市间的复制，灾备站点不对外提供服务，但是碰到主站点灾难可以切换到灾备站点进行服务。第三步，准实时的多站点复制，灾备站点同时提供服务。       项目难点与解决方法： 由于实施第一步方案受限于预算和灾备机房的线路问题，我们把灾备站点定在本城市另一端的一个机房，通过裸光纤链路和主站点相连，采用了低于主站点的服务器配置，用了一台IBM P550服务器做为3个主库的dataguard，连接一台EMC CLARiiON存储，dataguard端一直处于恢复状态，实现在灾难时最多发生20分钟的的数据丢失。           项目成功与失败的经验归纳： 项目上线后数据同步良好，基本实现系统设计目标，以最小的成本构建了一套可用的灾备系统。 项目实施成本一直是私营企业最关注的，我们的所有项目都面临着把每一分钱花在刀刃上，所有的项目方案都由公司内部人员讨论得出，显示了团队的强大的战斗力。在我们以后的项目中，我们依然会追求以最小成本获得最大收益，我相信中国绝大部分公司都是中小企业，都将会面临到和我们一样的问题，我们走过的路，做过的项目是对他们最好的指导。         你在项目中岗位与贡献： 负责制定产品预算 负责产品选型沟通 负责San网络搭建 负责系统安装调试 负责存储规划 负责数据库建立 负责监控体系建立 负责后期维护