|
征文:运营支撑数据存储系统的整合分析某大型电信运营支撑系统经过多年的建设后,各个功能子系统已经初具雏形。但是由于在建设初期,缺乏对整个业务系统各种应用的整体规划,因此在各个子系统各自建设成型后,形成了多个独立的SAN孤岛,为此,该大型电信运营商计划把多个独立的功能系统整合起来,形成统一管理的数据中心。 该大型电信运营商的已有网络环境包括如下几个功能: BOSS存储系统由 EMC/HDS/IBM等主流厂商的高端存储系统构成如:DMX1000,Symm8830, Symm8530 、SHARK等系统组成。完成采集计费和交费的基本功能。 CRM 由EMC DMX1000,CX300等中高端存储系统组成,完成客服,客户管理的功能。 BI系统由IBM SHARK800高端存储系统组成,实现报表和主题分析等决策支持的功能。 ONDEMAND由FAST500中端存储系统组成,实现详单查询。 上述各个功能都采用DWDM光纤交换机形成各自的存储区域网(SAN孤岛),在统一系统内通过SAN实现块数据的快速流动和访问。 大致的业务流程是BOSS系统生成原始的客户信息和话单详单, BOSS系统通过连续卷复制功能(BCV,SRDF)实现基于指针的块数据复制,不仅供BOSS系统内部进行备份、测试、报表使用,同时也必须向BI、ONDEMAND提供,装载后生成统计和分析结构。系统的数据流动会随业务量的增加快速增长。 目前,该系统存在的问题是:各个系统的存储资源互相独立,磁盘的使用不能统一规划,造成使用率的不均衡。各个功能系统间的数据流流动也只能通过IP/TCP协议,不能实现数据块级的高效数据共享。 此外,由于数据源是数据库的内部数据,因此局限于应用层数据存储格式的限制,只能在应用层进行数据的传输,如BOSS数据库中的营帐数据。效率最低,灵活性较差,且接口不规范,如上边 BI同步营帐数据BCV. 各个系统功能系统之间,则通过标准的IP/TCP协议,既FTP方式。在操作系统层进行数据的传输。如BOSS的话单数据。效率一般,比较灵活,且执行标准传输协议。 同时,由于整个系统中拥有来自多家供应商的多种存储系统,甚至拥有来自同一供应商的不同种类的系统。每个存储孤岛都有自己的管理器和自己的一套工具,以及自己的一套策略和一套过程。这种状况不仅造成了效率很低,而且需要很高的成本,也增加了出现宕机错误的可能性。 为此,构建一个统一的数据存储平台是该电信运营商的当务之急。 网络改造方案 多个光纤交换机构建而成的SAN孤岛,不符合系统整合的总体建设思路,如何整合现有存储网络,构建更大规模、更灵活、更简化的网络支撑平台,首先面临的问题在于,在存储网络层面解决各个SAN孤岛通信的问题。可以通过两种思路来解决: 经过分析,这两种连通SAN孤岛的方式各有利弊。第一种方案使用更大规模的导向器构建一个整合的大的SAN存储网络,能大幅度提高整体存储网络利用率,更有效的分配和管理现有存储资源,更灵活的进行存储资源扩展与应用扩展,大幅度降低整体存储网络的管理复杂度和成本。仅从技术上考虑,是最为优化的整合存储网络架构。 但是该方案的最大缺陷在于,在整合过程中,需要对原有业务系统做较大的改动,因而会造成较长的业务停机时间,且在改动过程中,数据迁移会面临较大的风险。在现实存储整合的过程中,这种较为彻底的整合方式往往更加合适一些在业务连续性方面并没有太高要求的中小型企业采用。考虑到该电信企业本身对业务连续性有较高要求,且数据丢失风险控制方面也提出了较高要求,因此,我们推荐采用第二种SAN整合方式:使用SAN路由连接各个SAN孤岛。 如上图,使用SAN路由连接各个SAN孤岛实际上是指在各个SAN孤岛之间,增加一个SAN路由,各个SAN孤岛与路由器相连接。这样原有的各个SAN系统结构依然不变,原有各个SAN孤岛中的交换机配置也不需要做太多改变。通过中间的SAN路由器控制各个存储子网络之间的数据流传输。 该方案并非一个彻底的改造方案,更多意义上是在原有系统的基础上加以整合。相比第一个方案,该方案在日后的管理上面临了更高的复杂性和成本问题,但是该方案的突出优势在于对现有系统的冲击最小,系统改造面临的风险最小,因而我们建议该移动运营公司采用该系统。 责编: 微信扫一扫实时了解行业动态 微信扫一扫分享本文给好友 著作权声明:畅享网文章著作权分属畅享网、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
|
最新专题 |
|