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

去年,处于对整体财务系统的数据库安全考虑。提出了集中存储的架构,       原本的数据结构是。由4台win2003或2008系统的服务器运行MS SQL2000数据库,独立运行。每台服务器数据库数量越100个。数据库容量则大小不等。总容量每台约200G-300G左右,其中正式...显示全部

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

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

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

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

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

收起
参与25

查看其它 4 个回答yujin2010good的回答

yujin2010goodyujin2010good  系统工程师 , 大型零售巨头

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

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

互联网服务 · 2017-03-20
浏览2170
  • 库太多了。正式,非正式的混杂在一起,每台服务器上大约都有200-300G的数据。约150个库左右。其中正式在运行的大概有三分之一,由于业务混杂,磁盘空间不足,应用系统软件严重老化,BUG多。经常某个库影响了整个系统。都不知道是哪个业务库出的问题。所以才打算分离出来,
    2017-03-20

回答者

yujin2010good
系统工程师大型零售巨头
擅长领域: 云计算服务器存储

yujin2010good 最近回答过的问题

回答状态

  • 发布时间:2017-03-20
  • 关注会员:5 人
  • 回答浏览:2170
  • X社区推广