【案例分享】正在面临的架构调整困难

去年,处于对整体财务系统的数据库安全考虑。提出了集中存储的架构,

       原本的数据结构是。由4台win2003或2008系统的服务器运行MS SQL2000数据库,独立运行。每台服务器数据库数量越100个。数据库容量则大小不等。总容量每台约200G-300G左右,其中正式库,测试库,历史数据库混杂在一起。由于各种历史问题。公司在早起信息化发展的时候就没有做好长远规划,导致了现在的这种结构。这种结构每台服务器都存在严重的单点故障,数据备份耗时,维护繁琐。后来提出了整体的虚拟化架构。采用V7000作为集中存储。由若干台服务器组成虚拟化集群来替代原本的数据库服务器,分离正式数据和非正式数据。单独准备一台超大容量,性能一般的虚拟机用来做非正式数据的连接。V7000与另外一台V5000做镜像同步,保证数据的实时同步。一旦V7000故障。可以使用V5000替代。

其实缘由的数据库结构很简单,没有双机。mssql2000数据库也相对简单。

       但到目前位置,我只做出非正式库,并且只协同软件运维人员分离了很少一部分非正式库,原因是,由于整套系统运维,发展时间过长原有数据库中太多的存储过程,管理用户,而且其中很多是否在启用。密码。连接到那些业务数据库都没有详细的记录。少了详细的基础运维资料。导致分离正式数据库的方案基本废弃。恐怕最后我只能考虑整体的数据库迁移,保持原有数据库的状态进行P2V。

工作中其实这样的例子太多了。特别是工业信息化中。很多系统上线没有专门的信息化部门去跟踪运维。慢慢的几年以后。所有系统细节没有人了解。最后要升级或者迁移的时候。就如同一刻定时炸弹。

5回答

duansqduansq  技术经理 , 华夏人寿
目前类似问题在各个小公司都存在,很多项目为了赶时间上线,文档都不完善,有的甚至边上线边修改,凑合着上了。开发运维一组人马,系统压力较小时,什么问题也不显露,过了两年,换了一批人,系统突然压力大了,原本觉得没问题的系统突然问题一堆。想起去调整时,发现什么文档都没有,运维的人不...显示全部

目前类似问题在各个小公司都存在,很多项目为了赶时间上线,文档都不完善,有的甚至边上线边修改,凑合着上了。开发运维一组人马,系统压力较小时,什么问题也不显露,过了两年,换了一批人,系统突然压力大了,原本觉得没问题的系统突然问题一堆。想起去调整时,发现什么文档都没有,运维的人不敢动,底层系统或数据库的也不敢动,就如个定时炸弹。

收起
 2017-03-24
浏览650
王巧雷王巧雷  系统工程师 , sino-bridge
这个事从根本来讲就不是技术的问题,乱成一团,没有人主动去往前推。但出了问题肯定是运维的先背锅,背锅的人想推的人又没那么大权限。所以我觉得从存储层来做反而是最值得推荐的。历史遗留的混乱问题不是你能解决的,但是最起码存储的高可用、数据安全问题还是可以解决的啊。通...显示全部

这个事从根本来讲就不是技术的问题,乱成一团,没有人主动去往前推。但出了问题肯定是运维的先背锅,背锅的人想推的人又没那么大权限。


所以我觉得从存储层来做反而是最值得推荐的。历史遗留的混乱问题不是你能解决的,但是最起码存储的高可用、数据安全问题还是可以解决的啊。通过v7000和v5000的镜像方案先从底层解决了数据安全问题。剩下的历史遗留问题就又大把的时间去慢慢梳理了。

至于v5000拉低性能的问题,看怎么做了,如果同步复制的确实有点,如果vdm的话,写操作会略有拉低,读操作选择v7000就行。再说了看看原来那些设备,一团糟,就算被5000拉低一下,估计也比原来快。

收起
 2017-03-24
浏览671
  • 是啊。基本上从我的角度来说。也就是这样了。我无力协调其他部门。也不想去惹这烂摊子。维持现有的运维工作。不出事故。仅此而已了。
    2017-03-24
yujin2010goodyujin2010good  系统工程师 , 大型零售巨头
mssql相对简单啊,密码问题随意改就行了啊。走存储层做本来就是成本问题。为什么不主机层面做?显示全部

mssql相对简单啊,密码问题随意改就行了啊。

走存储层做本来就是成本问题。为什么不主机层面做?

收起
 2017-03-20
浏览676
  • 库太多了。正式,非正式的混杂在一起,每台服务器上大约都有200-300G的数据。约150个库左右。其中正式在运行的大概有三分之一,由于业务混杂,磁盘空间不足,应用系统软件严重老化,BUG多。经常某个库影响了整个系统。都不知道是哪个业务库出的问题。所以才打算分离出来,
    2017-03-20
你们单位的架构 包括数据库 都是你负责吗?这件事情应该由专门DBA去考虑,先写个评估报告,对数据方面的事情做整体评估,并写明需要这么做的必要性,再往下落实到具体每套业务系统的负责人,不然大家肯定不愿意去动现有的数据!...显示全部

你们单位的架构 包括数据库 都是你负责吗?这件事情应该由专门DBA去考虑,先写个评估报告,对数据方面的事情做整体评估,并写明需要这么做的必要性,再往下落实到具体每套业务系统的负责人,不然大家肯定不愿意去动现有的数据!

收起
 2017-03-20
浏览674
  • 我们没有DBA,现有的信息化的管理部门是一些不太动信息化的人,他们的作用基本上就是上传下达,我作为系统管理员基本上要一直延续到数据库上,和软件的人员直接对接,方案我们自己定,自己报,然后石沉大海。
    2017-03-20
提出一点疑问,用V7000与V5000做存储级别的同步,岂不是拉低V7000的性能嘛?另外数据库的分离与整合肯定要花费大量的时间!显示全部

提出一点疑问,用V7000与V5000做存储级别的同步,岂不是拉低V7000的性能嘛?

另外数据库的分离与整合肯定要花费大量的时间!

收起
 2017-03-20
浏览690
  • 1,上面运行的业务受软件限制,还停留在mssql2000的版本上。对存储的性能要求还没有那么高。每天的数据更新也没有那么大。V7000和v5000之间只做数据同步,性能的消耗还没有严重到影响业务的程度。 2,我原来的打算是把所有的非正式库分离。这些库是可以在工作时间操作的,这样把原本的数据库整理到只有正式库后进行P2V。 无奈软件运维的人员一是不愿意做,二是有很多数据历史遗留。什么人用。干什么的。没有个详细的统计。谁也不敢动。也不想担责任。
    2017-03-20
  • 这个历史遗留问题你要上报你的领导,从上往下执行才好往前推进!
    2017-03-20
  • 唉,一言难尽,只能说信息化部门不受重视,管理存在严重的问题。这个方案我是报给我们经理的,设备采购也都没问题。但是具体到数据部分。涉及到多个部门特别是使用部门。谁也不愿意对数据承担责任。都采取保持现状的态度。
    2017-03-20

提问者

潘延晟系统工程师, 第十区。散人

问题状态

  • 发布时间:2017-03-17
  • 关注会员:5 人
  • 问题浏览:4006
  • 最近回答:2017-03-24
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30