警务云-云数据中心运维管理解决方案

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

警务云云数据中心运维管理
解决方案
目录
1.警务云运维需求分析 (4)
1.1.警务云运维背景 (4)
1.2.警务云技术架构 (4)
1.3.运维管理需求分析 (5)
1.3.1.资源管理 (5)
1.3.2.资源监控 (5)
1.3.3.自动化管理 (5)
1.3.4.服务管理 (6)
2.警务云运维方案概述 (6)
2.1.云运维平台总体设计 (6)
2.2.云运维平台技术架构 (6)
2.3.与云平台集成方案 (8)
2.4.云资源安全管控 (9)
3.云运维平台详细技术方案 (10)
3.1.资源配置管理(CMDB) (10)
3.1.1.配置数据建模 (10)
3.1.2.配置数据采集 (11)
3.1.3.配置数据维护 (14)
3.1.4.配置数据应用 (17)
3.2.集中监控管理 (20)
3.2.1.网络监控管理 (21)
3.2.2.系统应用监控 (23)
3.2.3.用户体验监控 (29)
3.2.4.集中告警管理 (34)
3.3.运维自动化管理 (36)
3.3.1.应用持续交付 (38)
3.3.2.运维操作自动化 (41)
3.3.3.自动化作业平台 (44)
3.3.4.作业调度管理 (48)
3.4.运维管理流程 (49)
3.4.1.ITIL流程 (49)
3.4.2.云资源交付 (50)
3.4.3.工单处理 (51)
3.4.4.流程模型 (52)
3.4.5.微信门户 (53)
3.4.6.运维网站 (54)
3.5.运维数据分析 (54)
3.6.运维可视化展示 (55)
3.6.1.大屏可视化展示 (55)
3.6.2.可视化设计平台 (56)
3.7.运维管理门户 (57)
4.平台部署方案 (57)
4.1.采控代理自动化部署 (57)
4.2.运维平台部署 (58)
5.平台建设收益 (60)
1.警务云运维需求分析
1.1.警务云运维背景
近年来,全国各级公安机关大力推动信息资源汇聚共享,积极探索云计算大数据技术与公安业务的结合与应用,推动了警务工作创新发展,促进了公安信息化提质升级。

信息技术快速发展,为公安信息化发展创造了新的条件。

云计算、大数据技术的发展,为建立公安信息资源服务体系、加强公安内外部信息资源汇集整合、关联分析带来了可能。

云计算以其超级计算能力、虚拟化能力、高扩展性、按需服务、高可用性、节能减排等特性,在公安行业得了快速的发展,当前各级公安科技部门已经基本了虚拟化平台或IaaS 云计算平台,信息化水平走在前列在地区已经建设完成或正在建设PaaS、DaaS、SaaS等云计算平台,尤其是大数据、容器平台两个方面发展快速,在技术深化与实战方面取得了明显成效。

但我们也在享受云计算、大数据等先进技术带来便利的同时,我们也需要注意的到云平台的分散性、安全性、脆弱性的特性。

当前大多数云平台厂商提供的解决方案无法完全覆盖云计算的各个层次,同时各家产品均拥有自身的管理平台,在运维管理层面的能力也各不相同,这种分散性与能力的缺失使得运维管理复杂度加大。

云平台在云资源创建、调整、销毁方面灵活快速,在带来便利的同时,存在着非常大的安全隐患,如果没有相应的管控手段,这种让云平台的这个脆弱性放大,甚至影响到的整理云平台的可用性。

1.2.警务云技术架构
警务云是一个系统性工程,包括基础设施层、云架构层、应用层、管控层等多个层次,各层次相互协助整合,构成完整的警务云技术架构体系。

一、基础设施层,包括:机房环境、计算设备、存储设备及网络。

二、云架构层,包括:IaaS、PaaS、DaaS等相关的云计算、大数据、容器平台。

三、应用层,包括:数据库、中间件、标准应用等系统服务,及各类警务业务应用。

四、管控层,包括:运维管理、安全管理等云管控平台(注:本方案主要讲述运维管理),
运维管理主要包括:资源管理、监控管理、自动化管理、服务管理等。

注:基础设施层、云架构层、应用层统均为运维管理的资源对象。

附图1. 警务云技术架构图
1.3.运维管理需求分析
1.3.1.资源管理
警务云的资源管理需要同时将基础设施层、云架构层、应用层的各层次资源需要进行集中、统一纳管,才能真正到全面掌握云数据中心的资源全貌。

为了能够及时掌握云资源,运维管理平台需要与云管理平台进行集成对接,定期获得云资源的变化情况。

云的快速可变的特性,云资源很容易被创建和修改,缺乏对Openstack/VCenter/阿里云等云管理的操作管控机制,无法确认资源操作的合规性,存在明显安全隐患,需要有配套的监管手段。

1.3.
2.资源监控
随着虚拟化的快速发展,云数据中心资源规模激剧增加,同时Docker、微服务架构的快速发展,使得云资源规模快速增加,资源数量级达到数十万级别甚至更高,对云资源监控的要求越来越高,开源软件和传统商业监控工具已经无法满足云数据中心监控管理的需要。

1.3.3.自动化管理
资源规模巨大的云数据中心仅仅依靠传统的人工运维操作已经无法满足当前的运维需求,需要更高层次的自动化管理能力。

规范操作,知识的沉淀,降低对技术高手的依赖;提
高效率、降低风险,提升运维应急应急保障能力。

1.3.4.服务管理
基于ITIL标准实现对日常维护、故障处置、变更上线等运维过程需要规范化、流程化管理,确保脆弱的云环境安全可靠,同时通过自动化工具降低运维过程中的安全风险。

基于服务门户、服务目录与服务流程对提供便捷的运维服务,并通过自动化工具,在安全合规的前提下服务快速交付。

2.警务云运维方案概述
2.1.云运维平台总体设计
考虑到警务云平台的技术多样性、平台分散性、脆弱性等特点,警务云运维管理平台的建设应当遵守以下原则:
一、集中化管理
避免多个入口、分散管理,将各类云资源管理权限回收,由运维管理平台作为云资源配置管理、资源监控的集中化管理平台,确保云资源管理安全合规;
二、自动化管理
通过自动化工具提供运维效率、降低风险、规范操作,实现知识精确沉淀,提升应急保障能力。

三、规范化管理
基于ITIL标准建立符合警务云运维实际需求的运维服务流程,通过流程化工具对运维过程进行规范化、合规化管理;
四、可视化管理
通过可视化云数据中心资源、监控、作业执行、工单流程、运行态势,提高运维决策的可视化水平。

2.2.云运维平台技术架构
优云运维管理平台采用微服务、大数据等互联网技术架构,统一平台PaaS层,产品采用平台+APP模式,平台提供统一采集操作层和资源库,应用APP基于平台服务和组件规范,
可不断丰富扩展。

平台提供服务门户作为统一的运维入口,实现各类运维管理场景。

附图2. 平台架构设计
⏹配置管理库(CMDB)
CMDB实现对数据中心所有IT资源的配置信息管理,保证数据中心中配置项的完整性和精准性,构建运维管理元数据,并为监控、运维流程提供资源数据。

⏹集中监控管理
系统提供云数据中心基础资源、业务应用、用户体验全方位监控,同时提供集中的监控告警管理及监控性能数据展示。

⏹运维自动化管理
系统提供自动化操作与应用持续交付管理能力,实现运维自动化管理,提升运维操作效率、降低人工操作风险。

⏹运维管理流程
系统提供基于ITIL的规范化运维管理流程,建立基于服务目录的对外服务交付过程,同时支持面向于云资源自动化交付管理。

⏹可视化展示与分析
系统提供美观形象的可视化展示平台,帮忙运维管理人员准确掌握IT运行态势与运维
服务水平。

运维管理门户
提供了运维管理门户网站、个人工作台等形式的面向外部最终用户自服务及内部人员人性化的运维界面。

此外,平台还预留多种标准接口及开放的接口体系,实现和第三方系统的功能或数据集成对接,包括云管理平台、PKI认证、短信系统、邮件系统等。

2.3.与云平台集成方案
系统支持通过与云管理平台进行对接,包括:VMWare、Openstack(华为云、浪潮云、曙光云等)、阿里云等云平台,实现与IaaS、PaaS、DaaS等层次的集成对接,实现统一配置管理、全方位监控、操作自动化、服务流程及可视化展示。

附图3. 运维平台与云平台集成方案
运维管理平台与云平台的集成对接方案如下:
2.4.云资源安全管控
云的快速可变的特性,云资源很容易被创建和修改,缺乏对Openstack/VCenter/阿里云等云管理的操作管控机制,无法确认资源操作的合规性,存在明显安全隐患,需要有配套的监管手段。

1)禁止在非必要的情况(如平台级的资源池、镜像、安全策略的配置管理操作等)使用云管理平台对云资源进行操作,如:云资源创建、调整与销毁,避免出现人为的非法操作与非授权的资源使用。

2)日常周期性的维护操作需要使用自动化平台进行自动完成。

3)日常资源申请与变更必须通过运维流程进行服务申请,在审批通过后调用自动化运维工具进行资源的操作,减少人工操作。

4)通过配置管理库(CMDB)的全网扫描与自动化发现能力对云资源进行管理,及时发现非法的资源变更的情况,确保云环境的安全管控。

3.云运维平台详细技术方案
3.1.资源配置管理(CMDB)
需实现对数据中心的物理资源、虚拟资源、软件资源及应用系统等对象的配置信息,包括配置模型的管理、配置信息的发现、配置关系的梳理、配置数据的管控,形成数据中心的配置管理库CMDB,提供统一、可信的配置数据应用支撑。

3.1.1.配置数据建模
配置管理库(CMDB)系统应当建立覆盖数据中心所有的IT资源的配置管理模型,易于理解和使用,并支持用户进行快速扩展,建立契合实际需求的配置模型。

配置模型应当能够覆盖现有网络与安全设备、服务器、存储等硬件设备,及数据库、中间件、应用软件及业务系统等软件设施,至少包括以下配置项类型:
1)机房设施,包括:机柜、UPS、精密空调、配电柜、视频摄像头、传感器等。

2)网络与安全设备,包括:防火墙、路由器、交换机、IDS/IPS、负载均衡器、安全网关等;
3)服务器,包括:小型机、刀片服务器、PC服务器等;
4)存储设备,包括:存储整列、光纤交换机、磁带机、
5)操作系统,包括:Windows、AIX、HP-UNIX、各类Linux等;
6)数据库,包括:DB2、Sybase、Informix、Oracle、Mysql、MongoDB、Cassandra等;
7)中间件,包括:Weblogic、Websphere、TUXEDO、MQ、CICIS、Apache等;
8)虚拟化,包括:VMWARE、华为、H3C、阿里云等;
9)应用软件,包括:FTP、LDAP、AD、Email Server等
10)业务系统,主要包括:警务综合系统、PGIS、打防控、视频监控等
配置库应支持灵活的动态建模能力,可根据IT架构分层,自由、灵活的定义和调整配置模型,支持配置项类型、配置关系、配置表单的建模能力,所有设计与调整都基于可视化界面。

附图4. CMDB数据建模
配置建模能力包括资产配置项建模、关系建模以及字典目录管理和配置表单管理。

3.1.2.配置数据采集
系统支持多种资产配置信息的发现和收集手段,包括:全网扫描、配置发现、批量导入、第三方系统的集成接口等。

3.1.2.1.全网资源扫描
系统应当提供网络扫描工具,发现网络当中的所有IP资源,并将发现的资源标识为服务器或网络设备,发现结果进入IP地址库。

应当同时扫描任务的定期执行,及时发现网络当中的IP黑户。

3.1.2.2.配置采集发现
系统应当提供配置深度发现工具,发现对象包括网络设备、服务器、操作系统、数据库、中间件、虚拟化等,并支持配置项关系的发现。

配置数据收集维护利用了多种技术手段来保证各个来源的数据准确性和完整性,系统支持向导式发现配置功能,支持ICMP、TCP、SNMP、WMI、Telnet、SSH、CCLI、Http、DNS、JDBC、JMX、VMWare、libvirt、XenAPI等多种协议来实现配置信息的自动发现,用户可以通过发现配置向导来实现发现范围、发现参数的设置,构建合理的配置发现策略,同时支持将发现结果导入到配置管理库中。

附图5. 自动发现配置
对于发现结果支持导出,能够通过EXECL导出并保存。

3.1.2.3.配置项批量导入
为了方便使用和维护,系统支持配置项信息的EXECL格式导入和导出功能,可以根据管理需要,选定所需的配置项进行导出;同时也可以将编辑好的EXECL文件直接导入到系统中,实现配置信息的批量导入。

附图6. 数据批量导入
3.1.2.
4.云平台资源采集
系统支持通过与第三方系统集成实现配置数据的导入。

如与华为云平台进行集成获取云资源的配置信息。

附图7. 与第三方系统集成获取配置数据
3.1.2.5.配置数据调和
从不同采集源获取到相同的资源数据时,系统能够识别并合并,并与配置库中标准数据进行比对,判断是否产生变化,如果产生变化则产生差异报告,并发出通知告知管理员进行变更审核,避免出现重复或不一致的配置信息。

附图8. 配置调和
3.1.3.配置数据维护
数据维护主要针对采集入库的数据进行综合管理,包括数据调和、分区管理、审核管理以及权限管理。

3.1.3.1.配置分区管理
系统支持数据分区管理,能够按照用户的地域、组织机构分布等因素对配置项进行分区,建立不同的管理域,各机构分别管理自己管辖范围内的配置。

系统采用建立配置维护圈、社交协作化的思路,通过文化引导和规范约束结合的方法,促进配置维护圈的活跃、保证配置准确率,激发用户内在动力来做好配置维护。

主要有圈子管理、人工配置维护、仓库数据的认领、配置评论、配置审核以及配置的动态展示等。

1、支持按数据维护职责建立独立的数据维护工作区,各工作区对各自团队负责管理
的资源进行认领并负责对该数据的维护管理。

附图9. CMDB维护圈创建
2、支持数据维护者根据自身维护需要创建过滤标签,快速查阅自身所关心的配置数
据;
3、支持对配置数据开放式的评论、点赞,提升数据维护的积极性与团队协作。

附图10. 数据开放式的评论、点赞
3.1.3.2.配置审核管理
配置数据的变更生效由工作区负责人审核决定,确保变更的快捷有效。

变更审核时支持查看配置数据变化报告。

附图11. 配置数据变更审核
支持对工作区内所有资源的数据变化时,可实时通知数据的订阅者或第三方系统,并告知变化内容。

3.1.3.3.配置变更跟踪
系统支持实时数据跟踪功能,能够跟踪配置和资产的当前状态信息,针对配置管理,系统能够支持配置项的版本跟踪和维护,当配置项产生新的版本时,系统能够自动跟踪、记录、
更新并保存原始版本记录,对于存在多个版本的配置信息,系统还支持版本之间的比较。

附图12. 配置数据变更动态
3.1.3.
4.配置权限管理
数据维护工作区拥有独立的团队成员管理权限,支持成员增加、删除;
3.1.
4.配置数据应用
3.1.
4.1.配置应用场景管理
支持按应用场景建立配置数据应用区,支持从统一配置库当中选择所需的配置数据,并支持基于配置数据标签进行数据的批量导入。

数据应用区中,不仅能查看配置项数据,还能根据管理创建所需要的配置关系,同时也查看到其他团队所创建的配置关系。

附图13. 配置关系展示
数据应用区可以被监控系统、运维流程等模块进行调用,用于各类配置数据应用场景分析。

3.1.
4.2.配置数据查询
系统提供了全文检索的能力,能够对所有配置信息通过全文检索的方式进行数据查询。

全文检索支持对配置信息的附件信息进行检索,同时系统还提供了最近搜索记录功能,能将最近、常用的搜索的关键字进行记录,通过点击快速进行检索。

附图14. 数据全文检索能力
3.1.
4.3.配置与流程关系管理
系统支持和流程进行关联,一方面可以直接从配置项发起相关流程工单,如事件、变更等;另一方面由变更流程引起的配置项变化,再变更流程工单完成时自动进行变更审核;对于和配置项相关的工单,在浏览配置项时均可查看其所关联的工单信息,如该配置项发生过哪些事件工单、有哪些变更等。

用户还可以通过在配置管理界面直接发起运维工单,就该配置项开启流程运转。

附图15. 配置项与工单关联
3.1.
4.4.配置关系管理
系统支持配置关系管理,提供直观的关系列表和可视化视图,通过配置关系管理,可以帮助管理人员快速了解该配置项与其他配置项之间的关联关系,从而帮助管理人员快速评判该配置项的重要程度和依赖关系。

附图16. 配置关系展示
当该配置项出现故障能够快速评判其影响范围及影响程度。

3.2.集中监控管理
要求能够实现对现有的网络设备、主机/虚拟机、数据库、中间件、存储、业务应用等各类云资源的监控管理,提供面向业务应用用户体验监测能力,并提供故障告警、性能数据、监控展示的集中化管理。

附图17. 全方位监控工具体系

附图18. 集中监控管理
3.2.1.网络监控管理
网络监控工具面向网络运维人员,为其提供相应的技术工具,实现网络拓扑结构、网络故障、网络性能、网络配置的实时监控,及时发现网络故障、流量异常,提高网络管理效率,确保网络的安全性和可靠性。

系统支持大规模、分布式管理需求,能够适合大规模、分域、分级等管理特点。

支持多层级联部署,满足网络隔离以及单向通信的需要,以及满足大规模部署的要求。

3.2.1.1.网络拓扑发现
系统支持自动网络发现能力,能够实现对华为、华三、锐捷、神码、中兴、CISCO等主流品牌设备自动发现,支持局部发现某个设备的邻居设备,并支持自动网络拓扑构建。

系统支持全局网络拓扑与分层网络拓扑,全局拓扑显示所有的网络设备及关系。

分层网络拓扑支持通过拓扑逐层建立组合的方式,支持构建骨干网拓扑展示,也可以根据业务管理场景进行拓扑构建。

附图19. 网络拓扑管理
网络拓扑支持良好的拓扑交互,通过高亮显示指定设备及相关设备,能快速分析设备间的关系;也支持放大、缩小等地图式操作功能。

支持在在拓扑上显示设备与链路的性能负荷。

支持通过IP、设备名等关键字快速搜索与定位设备。

3.2.1.2.网络设备监控
系统支持发现与监测主流厂商的网络设备,设备性能监控指标包括:在线状态、Ping延时、CPU、RAM、端口状态、端口速率、端口包速、端口丢包率、端口错包率等。

3.2.1.3.网络链路监测
系统支持对网络链路的发现与监测,能够自动发现二层、三层网络链路,并支持对网络链路可用状态、丢包率、包延时的监测。

3.2.1.
4.网络事件管理
系统支持网络设备发出的SNMP Trap与Syslog告警事件,并对进行告警事件进行事件关联压缩,能将对称的事件或重复的事件压缩,在界面上只显示事件的最新信息,并能点击查询事件的相关信息
系统应支持事件的关联分析,并提供实时事件浏览界面,以对实时关注当前系统中发生的各类事件,以便对故障采取快速响应行动。

3.2.2.系统应用监控
系统支持数据中心计算、存储、网络等基础资源以及对运行于基础资源上的数据库、中间件等平台环境的监测。

系统应具备大规模、分布式管理能力,能够适应大规模资源管理要求,系统的部署不会对现有环境产生影响。

3.2.2.1.服务器硬件监控
系统对IBM、DELL、HP、华为、浪潮、联想等国内外主流品牌的服务器硬件监控,支持通过IPMI协议实现监测,监控指标包括:服务器电流、传感器风扇、传感器状态、传感器温度、服务器电流、服务器电源功率等。

附图20. 服务器硬件监控
3.2.2.2.存储监控监控
系统支持对主流存储设备的监控,包括:HP、IBM、EMC、华为、HDS、Netapp等,技术手段包括:SMI-S、SNMP。

监控指标包括:存储阵列、物理磁盘、存储池、控制器、存储卷、存储卷组等。

附图21. 存储设备监控
若设备支持,支持监控设备环境参数,如温度、风扇、电源电压等。

并能支持基于SNMP Trap、Syslog方式接收存储设备主动告警。

3.2.2.3.虚拟化监控
系统支持对VMWare虚拟化平台的监控管理,监控指标包括:虚拟机集群、物理机CPU、物理机内存、物理机磁盘、虚拟机CPU、虚拟机内存、虚拟机磁盘等。

附图22. 虚拟化监控
3.2.2.
4.I aaS云管理平台监控
系统支持通过与IaaS云管理平台进行对接实现云资源监控,支持Openstack(华为云、浪潮云、曙光云等)、阿里云等云平台监控。

附图23. 云平台监控
3.2.2.5.D ocker虚拟化监控
除虚拟化及IaaS云平台监控之外,同时支持对新兴的Docker监控。

附图24. Docker监控
3.2.2.6.操作系统监控
可监测众多的服务器操作系统,包括:Windows、Debian、Ubuntu、CentOS、Redhat、Mac OSX、Fedora、CoreOS、AIX、HP-UNIX。

支持通过SNMP、CLI、WMI、代理Agent方式监控服务器,Linux/Unix系统的CLI监控方式应当同时支持SSH及Telnet两种方式。

a)可自动监测服务器的各类性能指标,包括:CPU、RAM、磁盘、负载、文件系统、
网络、监测、服务等指标;
附图25. 操作系统监测
b)可自动监测服务器重要事件,包括:Windows Event、Syslog;
c)可监测一些常见的系统服务,包括:HTTP、DNS、TCP、SSH、SNMP、WMI;
3.2.2.7.中间件监控
系统支持对各类中间件进行监控:
a)Web服务中间件,包括:Apache、Tomcat、IIS、Nginx、JBoss、Lighttpd、Weblogic、
Websphere;
附图26. 中间件监测
b)缓存中间件,包括:Redis、Memcached;
c)消息中间件,包括:ActiveMQ、RabbitMQ、Kafka;
d)大数据中间件,包括:etcd、HAProxy、Elasticsearch、Hadoop(HDFS、MapReduce、
Zookeeper);
3.2.2.8.数据库监控
系统支持传统关系型数据库与NoSQL数据库的监控:
a)可监测各类传统关系数据库,包括:MySQL、PostgreSQL、SQLServer、DB2、Oracle、
Sysbase、Informix
附图27. Mysql监测
b)可监测各类NoSQL数据库,包括:Cassandra、MongoDB
附图28. Cassandra 数据库监控
附图29. MongoDB 数据库监控
3.2.2.9.大数据架构监控
当前云数据中心在大数据方面发展势头明显,大数据云成为云数据中心的主要研究方向之一,同时也是云数据中心与实战结合的关键点。

在大数据云的建设方面Hadoop技术占据的重要角色,运维系统支持面向Hadoop核心组件(HDFS、MapReduce、Yarn、Zookeeper)及内部消息中间件(RibbitMQ)的监控。

附图30. Hadoop 2的监控支持情况
以HDFS为例,监控指标包括:监控指标应当包括:总容量、损坏块、数据节点(DataNode)相关指标、HDFS空闲空间、HDFS使用磁盘空间、HDFS使用空间总数、丢失磁盘块数量、主节点(NameNode)相关指标、复制的磁盘块总数。

附图31. 大数据监控架构
3.2.3.用户体验监控
用户体验监测要求实现对业务系统的应用前端(WEB\APP)的运行性能、故障、用户操作体验、及用户行为的监控分析,为应用前端性能优化、故障处理、用户体验优化、应用评估提供数据支撑。

监控数据方式应当采用对应用尽量小的方式,应采用轻量级的插件,不应对应用业务逻辑进行改造。

系统应具有良好的水平扩展能力,能够支持未来增加被监控业务系统的性能要求。

3.2.3.1.应用总体分析
系统应当支持前端应用运行分析,展示应用总体访问情况,支持按访问用户数、操作数、错误数进行排序,方便领导和管理人员了解某项应用系统的访问分布情况,对应用的关心程度和使用情况等进行全面的分析, 掌握热点应用、僵尸应用。

相关文档
最新文档