中国移动网络代维管理系统技术规范总册V
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
中国移动通信企业标准
中国移动网络代维管理系统技术规范
总册
版本号:1.1.0
2012-9-1 发布2012-9-1 实施
中国移动通信集团公司
目录
1 范围 (2)
2 规范性引用文件 (2)
3 术语、定义和缩略语 (2)
4 总体方案 (3)
4.1 建设目标 (3)
4.2 指导思想 (3)
4.3 服务对象 (4)
4.4 管理范围 (4)
5 系统架构 (5)
5.1 功能架构 (5)
5.2 软件架构 (5)
5.3 组网原则 (7)
6 运行环境要求 (7)
6.1 运行环境和系统要求 (7)
6.2 主机及网络设备系统要求 (8)
6.2.1 主机设备要求 (8)
6.2.2 网络设备要求 (9)
6.2.3 存储设备要求 (10)
6.3 软件技术要求 (10)
6.3.1 操作系统 (10)
6.3.2 数据库管理系统 (11)
6.3.3 电子地图技术要求 (11)
7 系统技术要求 (12)
7.1 功能性 (12)
7.2 性能要求 (12)
7.3 软件设计要求 (13)
7.4 可靠性 (13)
7.5 安全性 (14)
7.6 可维护性 (14)
8 编制历史 (14)
前言
《中国移动网络代维管理系统技术规范》规定了中国移动网络代维管理系统的建设目标、建设原则、体系结构、功能结构、接口要求、技术要求,供中国移动内部和系统开发、集成厂商共同使用;是中国移动网络代维管理系统建设所依据的技术规范,用于指导全网代维管理IT化手段建设、开发与应用。
本分册是《中国移动网络代维管理系统技术规范》系列分册之一。
《中国移动网络代维管理系统技术规范》系列分册的结构、名称如下:
本规范由中国移动通信集团公司网络部制订,由集团公司网络部归口和解释。
本规范起草单位:中国移动通信集团公司网络部。
本规范主要起草人:王晓琦、石晓萍、王烨、周林、夏凡超、王鹏、徐智岳、杜传业、马松、吴丹、贺军、云雅琼、杜珍祥、童克波、吕晓敏、周云斌、陈为国、陆旻、许贤、周敏、郭艺娴、赵珺、陈宏宇、于洪亮、吕敏、徐铁瑛、诸圣勇、谭凌凯、文晓林、唐继志、霍廷瑞、杨竹。
1 范围
本规范规定了中国移动网络代维管理系统的建设目标、建设原则、体系结构、功能结构、接口要求、技术要求,供中国移动内部和系统开发、集成厂商共同使用。
2 规范性引用文件
下列文件中的条款通过本规范的引用而成为本规范的条款。
凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本规范,凡是不注日期的引用文件,其最新版本适用于本规范。
3 术语、定义和缩略语
下列术语、定义和缩略语适用于本规范:
4 总体方案
4.1 建设目标
按照集团公司对代维工作五统一(统一标准、统一招标、统一认证、统一考核、统一IT化手段建设)的要求,代维管理系统是作为提升代维管理能力和效率,促进代维工作低成本高效运营的重要措施。
系统建设目标概括如下:
➢建设统一的代维管理IT化支撑系统,支撑代维管理、考核等各项工作,实现对代维工作的规范化、标准化和精细化管控;
➢结合电子地图和定位技术实现对代维人员的实时位置查询、历史轨迹查询,以及巡检、盯防、通信保障、故障处理、隐患处理、资源管理等工作的现场管理,提高对代维生产现场的管控能力;
➢加强维护资源的统一管理和调度,强化对代维工作的过程管理和结果控制。
4.2 指导思想
➢公司战略定位
本方案的制定遵循中国移动公司战略的要求,符合“CMOSS2.0”在公司战略定位:
◆遵循“成为卓越品质的创造者”的公司愿景。
◆立足于“一个中国移动”卓越网络工程。
◆打造“做世界一流企业,成为移动信息专家”的新跨越战略。
◆是“打造卓越的运营体系”的重要组成部分。
➢网管规划指导
本方案参考中国移动网管规划工作组CMOSS2.0规划成果,遵循CMOSS2.0规划总体思路,并参考借鉴了规划成果中的功能框架和技术框架作为系统架构原型。
结合规划成果所指明的方向和定
位,在功能架构和技术架构上进一步深入分析并细化落地。
➢国际先进标准规范
本方案力求和国际标准规范接轨,引入TMF中“精益运营”的理念,以提高运营效率、提升整体效能、发挥最大效益,从而获取竞争优势、打造世界级运营服务能力,使得网管支撑系统不断朝以下几个方面发展:
◆综合化:支持多专业网络代维管理,支持多种业务的网络代维流程。
◆集中化:集中化的运营维护可以降低成本、加快业务部署开展、提高企业收益。
◆模块化:电信企业的运营面临着很大的不确定性,新业务层出不穷,必须具备迅速推
出新服务和提供整体解决方案的能力,功能模块化是必备的前提。
◆流程化:通过EAI与工作流技术,将优化的业务与管理流程进行固化,确保流程管理
的标准化与可控性,以支持企业流程的设计、执行、监控与评估。
◆标准化:采用标准化的技术体系,降低运营支撑系统的集成成本,易于扩展和升级。
◆面向客户化:面向电信企业的外部和内部客户,全面支撑企业生产活动、经营活动和
管理活动。
4.3 服务对象
网络代维管理系统服务对象包括系统使用人员和系统建设过程中的技术相关人员,具体如下:移动公司代维管理人员:负责协调管理整个代维工作,是网络代维管理系统的使用人员;在网络代维管理系统建设过程中负责参与制定功能需求。
代维公司管理人员:负责协调移动公司代维管理人员与代维人员之间的工作,是网络代维管理系统的使用人员,在网络代维管理系统建设过程中配合移动公司代维管理人员反馈功能需求的建议,同时收集、汇总代维人员使用情况,提出系统改进的建议。
代维人员:具体实施代维工作,是网络代维管理系统的使用人员。
项目管理人员:在网络代维管理系统建设过程中负责产品选型、技术管理和项目管理的人员。
软件开发人员:在网络代维管理系统建设过程中负责系统分析、设计、实现的人员。
技术支持人员:在网络代维管理系统建设过程中参与方案规划和系统技术支持的人员,并负责在系统使用过程中对使用人员遇到的各项问题进行技术支持。
4.4 管理范围
管理的专业:基站设备及配套、传输线路、直放站室分及WLAN、铁塔及天馈、集客家客专业。
管理的信息:合作伙伴的资质信息、代维资源信息、代维任务执行信息、代维考核数据信息、代维费用信息等。
5 系统架构
5.1 功能架构
中国移动网络代维管理系统的功能架构示意图如下:
5.2 软件架构
中国移动网络代维管理系统应采用分层的软件结构,软件从下至上分为采集层、数据服务层和应用展现层,每层只需要关心本层的数据、业务逻辑和业务实现,层与层之间通过标准接口进行交互,能更好的实现系统的可扩展性。
中国移动综合代维系统技术架构示意图如下:
数据层:
数据层是网络代维管理系统完成接入、数据采集、控制、协议转换的功能,经过归一和转换后通过统一的通信协议和信息模型向其它层提供数据。
数据层主要是对网络代维管理系统的数据模型进行维护、数据的自动采集以及数据的导入导出。
服务层:
服务层在网络代维管理系统的三层结构中位于应用层之下,采集层之上。
围绕着上层的应用,服务层完成系统的核心业务功能,为上层程序提供基于业务的操作管理功能,主要实现各类基础信息管理,工作流程的运转,数据的整合分析等功能。
应用展现层:
应用展现层为系统用户直接提供B/S架构的展现界面,为系统使用者提供丰富灵活、友好的人机界面。
应用展现层为生产性工作服务,提供日常的操作和运行维护功能,对数据的准确性、及时性、直观性有明确的要求,目的在于快速发现问题,快速解决问题。
其主要功能包括:首页管理、业务联系函管理、资源管理、资质管理、工单管理、巡检管理、终端管理、费用分析、考核统计查询等。
5.3 组网原则
代维管理系统基本配置要求为:
➢数据库服务器一台,主要用于运行数据库服务;
➢应用服务器一台,主要用于WEB服务(包括主应用服务、报表服务和接口服务);
➢地图服务器一台,主要满足应代维管理对地图服务的需求,如路径分析、网络资源、代维人员、任务地点的定位展现等。
应用集群根据具体情况,既可以采用操作系统自身的集群、双机软件,也可以采用第三方的系统管理软件来实现。
网络建设方案:通过网络交换机搭建局域网,为保证系统CMNET网络的接入,提供防火墙实现OA网、互联网的安全访问控制。
网络部署示意图如图所示:
网络代维管理平台网络部署示意
6 运行环境要求
6.1 运行环境和系统要求
软件具有可移植性,可在多种硬件平台、网络和操作系统环境下工作,可以支持主流的操作系统(Windows、Solaris、HP UX、AIX),移动终端应该支持主流的智能操作系统(Android、iOS、Symbian、Windows Phone等)。
6.2 主机及网络设备系统要求
应用软件满足平滑移植,即应用软件与硬件平台相对分离,应用软件可以自由运行在主流硬件平台的主流操作系统上。
不同时期提供的同类软、硬件能够兼容。
6.2.1 主机设备要求
主机运行的可用性
➢主机系统应具有以7×24×52的方式工作的能力,即每周7 天,每天24小时,每年52星期连续不间断,从而使得整个系统的可用性达到99.8%。
➢主机系统采用服务器集群技术(CLUSTER)。
当一台主机出现故障时,其它主机能够自动接替工作。
➢各应用系统可根据实际的负载情况,在群集内各主机间灵活迁移,从而使整个群集内各应用系统性能达到最优。
➢主机的处理能力要求满足所有业务的应用和一定客户规模的需求,而且需考虑全部系统的开销及应用切换时性能余量。
系统设计时应考虑30%的性能冗余;
掉电保护
➢计算机电源出现故障时,系统利用自身的后备电源把内存中的所有数据(即工作现场)保留到硬盘的相应部分,当电源修复之后,系统在启动过程中,首先确定是否需要执行掉电恢复程序,以恢复掉电现场或重新启动主机系统,从而保证应用程序不会因掉电而中断,也不会丢失数据。
➢在计算机硬件、操作系统、存储系统及应用系统业务进程出现故障时,能迅速响应并自动进行应用的切换;集群系统中,某一台计算机出现故障时,应不影响系统的应用及响应能力;
开放性、兼容性和可互联性
主机系统的各种设计规范,技术指标及产品均符合国际和工业标准,并可提供多厂家产品的支持能力。
系统要满足相关的国际标准和国家标准,是开放的可兼容系统,能与不同厂牌的产品兼容,可以有效保护投资。
扩充性
主机系统应该具有良好的扩充性能,包括:
➢良好的CPU扩充能力,主机性能能够随着CPU的增加线性增长;
➢良好的内存扩充能力,可以方便地增加内存;
➢良好的节点扩充能力,可以方便的在集群中添加新的节点,并显著提升系统的性能;
➢良好的I/O扩充能力,可以方便地扩充与外存储器的I/O通道,提升系统的I/O性能;
➢主机系统设备应具有适当的扩充能力,包括节点的扩充、CPU的扩充、内存容量的扩充及I/O能力的扩充等;并可支持CPU模块的升级;
➢支持电源、I/O 设备、存储设备的热插拔。
高可管理性
在分布式环境中,高可管理性已成为系统能否成功的关键,主机系统应能够集中统一的管理方案,降低维护成本。
机房空间要求
对于主机系统,在选型时需要注意考虑其对机房空间资源的需求,一般需要考虑下述因素:➢空间位置需求:主机设备的高、宽、深尺寸是否符合机房的要求;是否是标准机架;
➢电源需求:需要注意使用的直流电或交流电的不同;电源的路数要求;电源的功率要求;
➢空调制冷需求:需要注意机房的空调制冷系统能否满足设备散热要求;
➢走线方式要求:大部分标准机房要求上走线、下送风制冷,需要注意所选择的主机设备是否满足此要求。
6.2.2 网络设备要求
核心网络设备应满足下述要求:
网络采用TCP/IP协议,主干网络采用高速网络;
路由器产品必须符合通用的国际工业化标准,支持TCP/IP等标准协议及X.25等远程通信标准,支持OSPF、IS-IS、RIP或静态路由等路由协议;
核心交换机采用热旁路路由器协议HSRP协议,实现双机互为备份;
核心交换机提供三层交换能力,同时提供等路径路由,实现负载均衡;
接入交换机采用STP协议,同时连接到两台核心交换机上,避免单点失败;
核心局域网划分VLAN,由核心交换机实现网段间路由;
核心交换机及中心路由应采用高可靠的设备,具备背板冗余功能,系统板、关键I/O板、电源、风扇等考虑冗余,并可热插拔;省中心节点、地市节点要求双路由器配置,并保证路由器的互相热切换备份;
主干网络设备的配置端口总数应能满足应用和用户规模的要求,并保留约20%的余量,同时应保证适当的扩展能力;
主干网络设备要求平均无故障时间应大于26280小时,可用性不小于99.8%。
6.2.3 存储设备要求
存储设备主要指磁盘阵列,实现系统数据的联机存储,存储设备应满足下述要求:
磁盘阵列平均无故障连续工作时间(MTBF)应该大于1 万小时,可用性不小于99.8%;系统故障平均恢复时间(MTTR)小于1 小时。
磁盘阵列不能存在单点故障;
磁盘阵列设备必须能和主流厂家的主机系统相连;
磁盘阵列必须满足多机高可用群集系统的需要;
磁盘阵列应该支持FC-AL接口或FCSW接口,建议使用主流的接口标准,必须支持RAID1+0,RAID5,可以支持RAID0、RAID1、RAID0+1、RAID3 等。
应该提供多通道、双电源及冗余风扇,无单点隐患;
磁盘阵列应该支持电源、磁盘等的热拔插要求;
磁盘阵列磁盘的转速应大于10000RPM;
磁盘阵列设备必须具有较强的平滑扩充能力,包括系统存储容量的扩充及I/O能力的扩充等;
磁盘阵列应该支持存储区域网(SAN)等存储、备份方式;
磁盘阵列必须具备完善的存储系统管理软件,同时该软件应该能与主流的通用网管软件进行集成;
磁盘阵列的缓存可以按照1TB磁盘容量配置1GB以上缓存进行配置;
磁盘阵列的WIO应低于5%。
6.3 软件技术要求
6.3.1 操作系统
操作系统支持虚拟内存管理,支持多用户、多任务、多进程和多线程;
支持完全对称多处理器(SMP);
支持群集(cluster);
操作系统应至少达到C2级的安全标准;
操作系统应遵循X/open XPG4, POSIX 1003.1等国际或工业标准;
操作系统应提供图形化的系统管理工具;
支持在线诊断和软硬件的自动错误记录,在电源故障或其他紧急情况可提供自保护和自恢复。
6.3.2 数据库管理系统
数据库系统的基本技术要求如下:
支持ANSI/ISO SQL-89、ANSI/ISO SQL-92标准;
支持中文汉字内码,符合双字节编码;
支持主流厂商的硬件平台及操作系统平台;
数据库系统应具有良好的伸缩性;
支持主流的网络协议(如:TCP/IP、IPX/SPX、NETBIOS及混合协议);
具有良好的开放性,支持异种数据库的互访:
实现对文件数据和桌面数据库数据的访问;
实现对大型异种数据库的访问;
能够将原有异种数据库向本数据库无损失移植;
实现和高级语言互联的能力;
支持XA、ODBC 3.0、X/OpenCLI、JDBC等标准;
支持分布式事务及两阶段提交功能。
具有支持并行操作所需的技术(如:多服务器协同技术、事务处理的完整性控制技术等);
支持网络上同构或异构数据库之间数据的冗余性复制;具有多种复制功能模块(如:实时复制、定时复制、双向复制、多点方式下的N向复制、复制转发,复制范围可整表复制或表中部分行复制或修改单元复制);
支持联机事务处理(OLTP);支持决策支持的建立,要求能够实现数据的快速装载、高效的并发处理和交互式查询;
支持C2或以上级安全标准、多级安全控制;
支持数据库存储加密及相应冗余控制;
提供Web服务接口模块,对客户端输出协议支持HTTP2.0、SSL等;
支持联机存储和备份功能(如:磁带方式、光盘方式);
应具有强的容错能力、错误恢复能力、错误记录及预警能力;
数据库、表大小等技术参数可灵活设置,支持对多媒体数据及大数据量处理的技术需求;
应避免数据库死锁的出现,一旦死锁能够自动解锁。
6.3.3 电子地图技术要求
网络代维管理系统的电子地图技术要求参照《中国移动网管系统GIS平台技术规范》对电子地图的标准实施。
7 系统技术要求
7.1 功能性
⏹软件的主要功能是经过检验的。
⏹具有在不中断服务的情况下,完成功能升级能力;在增加新的关联规则时,系统不必中断
服务。
⏹软件应具有良好的人机界面。
软件可选择支持客户机/服务器结构;或浏览器/服务器结构。
⏹用户界面采用中文界面,提示信息通俗易懂,操作及选择键(热键、菜单选择等)的功能
定义在全系统保持一致。
应提供在线帮助信息。
⏹支持请求处理能力的扩展。
⏹具有丰富而实用的代维管理功能集,通常能够覆盖网络代维过程中所必须的功能,功能的
细节设计能够充分考虑到操作人员的直观和便捷操作。
⏹具有流程管控和长事务处理机制,从而支持资源的分布式协作管理。
⏹能够支持各种主流的通信网络技术,如:PSTN、GSM、SDH、xDSL、3G、IP等。
⏹能够通过建模和功能扩展,实现对新技术的支持。
⏹采取多层技术架构,集中数据存储,使用集群或负载均衡技术,从而具有良好的运行性能,
能够管理海量的资源数据。
⏹客户端与服务器端的通信带宽要求,一般瘦客户端上下行需128K,胖客户端上下行需512K。
⏹附带高素质、经验丰富、业务娴熟的专家服务队伍。
7.2 性能要求
⏹在硬件配置足够的情况下,不采用分布式结构容量上应可以支持百万级对象数。
⏹对数据进行新增、修改、删除、查询等操作时的平均响应时间应该在2到3秒之间。
以确
保系统有较高的可用性。
⏹以数据管理层性能要求为例
在TPCC42000(CPU[个数]:MEM[容量:GB]为1:3)的同等机器配置情况下,数据管理层组件产品对应用功能层访问性能的支持应在数据量小于1000万条、并发访问用户数小于50个、后台没有运行大型应用软件(例如数据库等)、对象的平均属性数不超过50个、关系数少于3000万的情况下,达到如下性能指标:
◆单个对象的增加、删除、修改响应时间平均小于0.5秒。
◆批量增加对象的响应时间平均应小于1分钟/千个对象。
◆批量删除对象的响应时间平均应小于30秒/千个对象,如果级联删除,则算作多个对
象删除。
◆单个对象查询(根据唯一标识获取)的平均响应时间小于0.1秒。
◆批量查询数据的平均响应时间小于2秒(数据量为1000万条时,平均响应时间应小
于5秒)。
◆事件(告警、性能、通知等)平均转发时间应小于2秒。
7.3 软件设计要求
⏹软件在设计、开发中要遵循易操作性、健壮性、实用性、高效性和安全性的原则。
⏹软件要求为模块化结构,保证安全可靠,具有容错能力,采用开放的接口,有二次开发能
力,并且便于扩容。
⏹软件必须采用主流的开发平台,具有良好的开放性。
⏹软件必须支持跨平台部署,必须支持主流的操作系统:如HP_UNIX,Tru64,Solaris、AIX
和WINDOWS等。
⏹支持Oracle、Informix、Sybase、DB2等主流数据库。
⏹支持WebLogic、WebSphere、TomCat等主流应用服务器。
⏹系统数据管理层支持分布式体系结构。
⏹软件设计应有防护性能,某一软件模块内的软件错误应限制在本模块内,而不应造成其他
软件模块的错误。
允许操作人员有限范围的误操作。
7.4 可靠性
⏹在不发生硬件故障和操作系统故障下,软件应有容错能力,一般小的软件故障不应引起系
统重启动;在故障情况下,任何数据不得无故丢失。
⏹系统的年可靠性应大于99.8%。
⏹系统支持7×24小时持续运行。
7.5 安全性
⏹终端程序能够穿过防火墙设置了IP映射。
⏹通过缴费管理接入的终端与通过前台缴费接入的终端有不同的安全级别。
⏹登录数据的口令要求加密。
⏹数据能定期归档和备份,采用双机热备策略进行备份恢复,保证3小时之内恢复所有数据。
⏹保证所有数据库操作的事务完整性。
⏹系统帐号管理遵循《中国移动4A安全技术规范》。
7.6 可维护性
⏹提供系统操作日志,需要支持日志分级,按照配置的级别生成不同详细程度的日志。
⏹可以配置某个运行实例是否进入测试状态,来决定该程序是否输出测试记录的日志。
⏹记录系统处理的请求包、返回结果包;提供查看请求包、返回结果包的工具。
8 编制历史
. .
.。