智能化IT运维管理平台方案建议书_第1页
智能化IT运维管理平台方案建议书_第2页
智能化IT运维管理平台方案建议书_第3页
智能化IT运维管理平台方案建议书_第4页
智能化IT运维管理平台方案建议书_第5页
已阅读5页,还剩13页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、智能化IT运维治理平台方案建议书1 .企业运维现状与开展趋势随着企业信息化的不断开展,运维人员需要面对越来越复杂的业务和越来越多样化的用户需求,不断扩展的应用需要越来越合理的模式来保证运维效劳能灵活便捷、平安稳定地持续.某企业从初期的几台效劳器开展到庞大的数据中央,单靠人工已经无法满足在技术、业务、治理等方面的要求,那么标准化、自动化、架构优化、过程优化等降低运维效劳本钱的因素越来越被人们所重视.其中,自动化开始代替人工操作在企业的运维过程中逐渐表达出来了强大的优势.运维随着企业业务的开展,自动化作为其重要属性之一已经不仅仅只是代替人工操作,更重要的是深层探知和全局分析,关注的是在当前条件下如

2、何实现性能与效劳最优化,同时保证投资收益最大化.通过自动化运维能最大限度地在更少的维修时间内实现运维目标,提升运维效劳质量.因此,对于越来越复杂的运维来说,将人工操作逐渐改变为自动化治理是一个重要开展趋势.2 .企业运维存在的问题与需求某企业初期只有文件共享和邮件效劳等几台效劳器,运维工作完全由人工操作,随着企业的开展,新业务系统不断上线企业、建设了中央机房,运维工作还是以人工为主,但是这一阶段增加了网络治理系统和环境监控系统,这两个系统在一定程度上减轻了运维的工作量,根本上实现了运维的半自动化.企业在开展,运维工作量在不断的增加,企业的运维工作面临以下的问题及需要解决:2.1 运维人员的工作

3、效率与工作主动性需要提升在企业运维过程中,只有当故障已经发生并且造成业务影响时才能发现和着手处理,这种被动救火不但使运维人员终日忙碌,也使运维本身质量很难提升,导致IT部门和业务部门对运维效劳满意度都不图.运维人员日常大局部时间和精力是处理一些简单重复的问题,而且由于故障预警机制不完善,往往是故障发生后或报警后才会进行处理,使得运维人员的工作经常是处于被动的状态,怎样才能在故障发生前及时发现并把故障处理掉,使运维工作变被动为主动2.2 需要建立一套高效的运维机制企业在运维治理过程中缺少自动化的运维治理模式,没有明确的运维人员角色定义和责任划分,使到问题出现后很难快速、准确地找到根本原因,无法及

4、时地找到相应的人员进行修复和处理.或者是在问题找到后缺乏流程化的故障处理机制,而在处理问题时不但欠缺标准化的解决方案,也缺乏全面的跟踪记录,企业需要建立一套高效的运维治理制度为运维工作提供方向和依据.2.3 缺乏高效的运维技术工具随着信息化建设的深入,企业业务系统日趋复杂,各种各样的网络设备、效劳器、存储设备、业务系统等让运维人员难以沉着应对,即使加班加点地维护、部署、治理也经常会因设备出现故障而导致业务的中断,严重影响企业的正常运转.出现这些问题局部原因是企业缺乏事件监控和诊断工具等运维技术工具,由于在没有高效的技术工具的支持下故障事件很难得到主动、快速处理.3 .业务流程标准化与健全运维治

5、理制度3.1 实现业务流程标准化,为自动化运维打好根底标准化是自动化运维的根底,想要实现标准化,首先识别各个运维对象,然后我们日常做的所有运维工作都应该是针对这些对象的运维.如果运维操作脱离了对象,那就没有任何意义.同样,没有理清楚对象,运维自然不得章法.例如扩容,首先确定是效劳器的扩容,还是应用的扩容,还是其它对象的扩容.你会发现,对象不同,扩容这个场景所实施的动作是完全不一样的.如果把效劳器的扩容套用到应用的扩容上去,必然会导致流程错乱.同时对于对象理解上的不一致,也会增加无谓的沟通本钱,造成运维效率低下.这种情况下的自动化运维不但不能提升效率,还会越自动越混乱.实现标准化的第一步是物理根

6、底设施的标准化,例如,识别物理对像效劳器、交换机、机柜等硬件;识别这些物理对像的属性,效劳器的序列号、ip地址、厂商等信息;识别这些对像之间的关系,效劳器所在的机柜、接入哪个交换机的哪个接口了等信息.效劳器物理根底设施的标准化如下列图其它设备的标准化以此类推:第二步是应用的标准化,应用效劳、中间件,数据库等;例如,数据库的表、视图、存储过程的标准化,表的字段名、值,索引等,表和视图之间的关联关系等.第三步是流程标准化,如备份、软件升级、杀毒,新业务上线等流程的标准化,下列图是现在的运维流程:前端运维人员权嵬升锻升级运行同川根底设施手工操作诊断&修复手工操作诊断&修复手豫知至文3

7、脚本彳操作学件限制住监控瑞、据行杳阅手工开启,更新工单4件告警脚本自动化运维是基于流程化的框架,将事件与IT流程相关联,一旦被监控系统发现性能超标,超过预先配置的阀值或宕机,就会触发相关事件以及事先定义好的流程,可自动启动故障响应和恢复机制.自动化工作平台还可帮助运维人员完成日常的重复性工作,提升运维效率,下列图是实现自动化运维的流程图:,指导性流程运维的自动化能够预测故障、在故障发生前能够报警,让运维人员把故障消除在发生前,将所产生损失减到最低.由过去的手工执行转为自动化操作,从而减少乃至消除运维中的延迟,实现零延时的运维.3.2 建立完整、全面的运维治理制度,为自动化运维的实现保驾护航运维

8、制度的建立包括环境治理、资产治理、介质治理、设备治理、监控治理、治理、系统平安治理、恶意代码防范治理、密码治理、变更治理、备份与恢复治理、平安事件处置,应急预案治理等制度.1 .运维治理制度是衡量运维工作的一把尺子,完善的治理制度能有效的提升运维工作效率,日常工作以治理制度为依据,按规定的要求和规定的流程操作既快速又准确;2 .全面的运维治理制度能在问题和故障还没有出现,没有造成损失前就被及时的发现,从而问题得到有效的处理,业务连续性得到了保证;3 .运维治理制度为运维工作提供了标准化的解决方案,使运维人员在处理问题时有章可循快速找到问题的根本原因,把问题对业务造成的损失降到最低;4 .运维治

9、理制度是为业务效劳的,业务是不断开展的,运维治理制度要跟得上业务的不断开展实现治理制度的创新.5 .自动化运维技术路线选型5.1 自动化运维概述自动化运维范围包括安装自动化、部署自动化、监控自动化、发布自动化、升级自动化、平安管控自动化、优化自动化、数据备份自动化等.自动化运维系统包括商用自动化运维系统、开源自动化运维系统,自建研发自动化运维系统.商业的运维系统在功能上要全面一些,效劳支持上能好一些,更新与升级有保证,采购本钱较高,对运维人员的技术要求相对较低.开源运维系统更灵活一些,效劳支持需要运维人员自身多投入一些时间和精力,更新与升级更个性化一些,相对本钱较低.自建自动化运维系统对人员的

10、技术要求最高,本钱也不低,但是当企业开展到一定规模后自建的运维系统才能更适合企业对于自动化运维的要求.5.2 开源运维工具的应用场景与优势1) Puppet是一个开源的软件自动化配置和部署工具,它使用简单且功能强大,很多大型IT公司均在使用puppet对集群中的软件进行治理和部署.优缺点分析:优点是Web界面生成处理报表、资源清单、实时节点治理,push命令可即刻触发变更;缺点是相对其他工具较复杂、需学习Puppet的DSL或Ruby,安装过程缺少错误校验和生成错误报表.2) SaltStack是一种全新的根底设施治理方式,部署轻松,在几分钟内可以运行起来,扩展性好,很容易治理上万台效劳器,速

11、度够快,效劳器之间秒级通讯.优缺点分析:优点是可以使用简单的配置模块或复杂的脚本,Web界面可以看到运行和监控的工作状态、事件日志,扩展水平极强;缺点是缺少生成深度报告的水平.3) Ansible是新出现的运维工具是基于Python研发的综合了众多老牌运维工具的优点实现了批量操作系统配置、批量程序的部署、批量运行命令等功能.在进行大规模部署时,手工配置效劳器环境是不现实的,这时必须借助于自动化部署工具.优缺点分析:优点是模块可以用任何语言开发、备管节点不需要安装代理软件、有Web治理界面、安装运行简单;缺点是对windows备管节点需要增强、执行效率相对较低.下列图是Puppet、Saltst

12、ackAnsible这三款运维工具处理水平与处理效率的比照:各种运维工具只是用于帮助人员进行运维的,每种工具都有其使用的优势领域,Puppet适用于软件自动化配置和部署;SaltStack适用于根底设施治理,在几分钟内可运行起来,很容易治理上万台效劳器,速度够快;Ansible适用于批量操作系统配置、批量程序的部署、批量运行命令等;下面是两个常用的开源监控系统:1)Nagios是一款免费的开源IT根底设施监控系统,其功能强大,灵活性强,能有效监控Windows、Linux、VMware和Unix主机状态,交换机、路由器等网络设备的网络设置等.一旦主机或效劳状态出现异常时,会发出邮件或报警第一时

13、间通知IT运维人员,在状态恢复后发出正常的邮件或短信通知.优缺点分析:优点是配置灵活、监控工程很多、自动日志滚动、支持冗余方式主机监控、报警设置多样性.缺点是事件限制台功能较弱、无法查看历史数据、插件易用性不好.2)Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案.用于监控网络上的效劳器或效劳以及其他网络设备状态的网络治理系统,后台基于C,前台由PHP编写,可与多种数据库搭配使用,提供各种实时报警机制.优缺点分析:优点是企业级开源、功能强大、入门容易、数据可以图形的方式呈现、提供多种API接口,可定制化开发.缺点是深层次需求开发难度较大、报警设置复杂、

14、缺少数据汇总功能、数据报表需要二次开发.Nagios适用于IT根底设施的监控系统,其功能强大,灵活性强,能有效监控各种操作系统的主机、交换路由设备等;Zabbix提供分布式系统监视以及网络监视功能,用于监控网络上的效劳器,效劳以及其他网络设备状态的网络治理系统.以上这五种工具都是开源的,运维人员可以根据企业的规模、业务需要、所要实现的运维功能等要求使用多种工具组合,发挥运维与监控工具各自的优势.工具的使用需要人工的干预和决策,工具不能完全代替全部运维工作.还需要结合实际业务逻辑和业务场景,把工具与业务融合到一起.例如,按业务要求对工具进行二次开发,更好的发挥运维与监控工具的优势,提升运维人员工

15、作效率.4.3Saltstack实现效劳器部署的自动化Saltstack在企业中实现效劳器部署的自动化运维,saltstack是基于python开发的一套C/S架构配置治理工具,它的底层使用zeroMQpub/sub方式通信,使用SSL证书签发的方式进行认证治理.salt我们选择了0.16.0版,该版中参加了multi-masterr特性,在这种架构下所有的minion将连接到所有配置的master上去.当一个master出现故障可以使用其余的master继续提供效劳,不会影响我们的正常使用,saltstack架构如下列图:Saltstack在企业中的部署步骤:1、确定saltstack软件依

16、赖关系是否满足要求:saltstack要求python的版本大于2.6或小于3.0,还需要检查以下的库,包括msgpack-pythorryaml、jinja2、markupsafe,apache-libcloud、requests等.2、安装master和minions:我这里效劳器的操作系统是centos的,安装命令如下:Wget:/pub/epel/6/i386/epel-release-6-8.noarch.rpmyuminstallsalt-masteryuminstallsalt-minion注:安装成功,显示Complete.3

17、、创立一个master效劳的备份节点并复制主master节点的key到备节点:Master:-saltmaster1.cccxht-saltmaster2.cccxht默认的master的privatekey是在目录:/etc/salt/pki/master.将该目录下的master.pem拷贝到备master节点的同一位置,对master的publickey文件master.pub做同样的操作,启用备master节点,在备节点接受key.4、重启minions:配置完成后,minion将会对主master和备master进行核对,并且两个master都对minion有操作权限.注:minio

18、n可以自动检测失败的master,并且尝试重连到一个更快的master,将minion端的参数master_alive_interval设置为true,即可开启该功能.5、saltstack状态文件的编写,saltstack上线后,运维工作从复杂的重复的效劳器部署和配置工作转移到saltstack状态文件的编写和维护,状态文件的编写要考虑模块化和通用性,在大批量部署之前要经过测试,没有问题后再部署,以下是一些经常用到的测试命令:(1)查询网络连接情况一是否能连接到客户端rootcentossalt#salt'*'test.pinglocalhost:Trueserver.ccc

19、xht:True(2)查询网卡iprootcentos/#salt'localhost'erfaceslocalhost:eth0:hwaddr:08:00:27:59:a9:8dinet:-address:02-broadcast:55-label:eth0-netmask:(3)查询磁盘空间rootcentostmp#salt'localhost'disk.usagelocalhost:/:1K-blocks:28423128available:2157223

20、6capacity:25%filesystem:/dev/mapper/vg_centos-lv_rootused:5406132还有很多经常用到的命令在此就不一一列举了,Saltstack可以实现云计算与数据中央架构编排,Saltstack可以由zabbix监控事件调用.通过Saltstack的salt-cloud实现对docker和openstack等云平台的支持,配合saltstack的mine实时发现功能就可以实现各种云平台业务自动扩展;Saltstack可以与CMDB相结合实现运维平台化、自动化和智能化.5 .自动化运维方案设计5.1 自动化运维规划图提到自动化运维就不能不说ITIL

21、,ITIL即信息技术根底架构库(InformationTechnologyInfrastructureLibrary),主要适用于IT月艮务管理(ITSM).ITIL为企业的IT效劳治理实践提供了一个客观、严谨、可量化的标准和标准.ITIL已经成为了IT效劳治理的国际标准,而CMDB配置治理数据库ConfigurationManagementDatabase那么是实现ITIL最重要的内容.随着企业的开展,对于运维要求越来越高,使用现有的开源工具已经不能满足企业对于运维的要求,根据企业业务的开展与对运维的要求建设统一的运维治理平台成为了企业迫切的需求.自动化运维平台的建设以ITIL标准为依据,根

22、据先底层后高层的原那么先建设效劳工具区域的各个运维子系统,各个运维子系统通过API的方式对上层提供效劳,最后不同的业务平台去调用这些效劳接口即可,运维平台的各个层面建设要全面符合治理制度的要求.5.2 自动化运维平台模块设计自动化运维平台以ITIL标准为依据在此标准上开发的,第一阶段已经做到了业务流程的标准化,现阶段从事件治理子系统开始逐渐完善各个子系统,把各种配置当作效劳来看待.CMDB也可以理解成统一的元数据库,比方说机房信息、效劳器信息、人员信息、效劳信息、业务信息以及他们之间的物理和业务拓扑关系等.上层的所有系统都应该关联到CMDB,以CMDB为中央,变更后的数据信息必须实时反应到CM

23、DB中,各个运维子系统才能看到最新的数据信息,保证其他系统能同步这份变更,以到达统一同步的目的.因此把CMDB系统当作运维的核心系统来对待,有利于后续各个系统之间的互通.以下是局部模块的设计要求:事件治理:负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止.事件治理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到SLA效劳级别协议(Service-LevelAgreement)所定义的效劳级别;问题与日志治理:通过调查和分析IT根底架构的薄弱环节、查明事故产生的原因,并制定解决事故的方案和预防事故再次发生的措施,将由于问题和事故对业务产生的负面影响减小到最

24、低的效劳治理流程.在问题治理这局部要做好问题处理过程的日志的功能,对于问题的处理提供查询的功能,可以追踪问题以预防类似问题再次发生.变更治理:在最短的时间窗口内完成根底架构或效劳的变更而对其进行限制的效劳治理流程变更治理的目标是保证在变更实施过程中使用标准的方法和步骤,尽快地实施变更,以将由变更所导致的业务中断对业务的影响减小到最低.可行性治理:通过分析用户和业务系统的可行性需求并据以优化和设计IT根底架构的可行性,从而保证以合理的本钱满足不断增长的可行性需求的治理流程.可行性治理是一个前瞻性的治理流程,它通过对业务和用户可行性需求的定位,使得IT效劳的设计建立在真实需求的根底上,从而预防IT效劳运作中采用了过度的可行性级别,节约了IT效劳的

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论