《互联网时代的自动化运维.pdf》由会员分享,可在线阅读,更多相关《互联网时代的自动化运维.pdf(26页珍藏版)》请在三一文库上搜索。
1、互联网时代的自动化 Syupei 运维 的变迁运维 运维的核心目标:保证服务的可靠及可持续运行 在计算机应用的发展历史中, 运维工作一直是必不可缺的重要环节, 无论在什么年代、什么场景, 保证服务的可靠、可持续运行,一直都是运维的最终目标。 但是在不同的时期,其实施的手段、关注的重点却是在发生变化的 的变迁运维 单机时代局域网时代互联网时代 整个计算机的发展历史,可以简单的归纳为上面三个时代, 既从单机时期,到八九十年代的局域网络时期. 再到现在的互联网时期, 期间无论是业务模型还是技术都发生了很大的变化. 的变迁运维 在早期, 单机时代时,计算机仍是一台昂贵的电子设备, 应用场景远没有今天这
2、样广泛,网络体系也没有今天这样复杂和敏感 电子技术也不如今天成熟。 这个时期的运维,关注的重点通常是以硬件为主,(而且那个时期的运维估计门槛会非常高,应该都 是些科学家干的事.) 那个时期, 不止计算机本身的硬件,与之相关的电力及其它配套也在范畴之内。 的变迁运维 到了中期,计算机由大、中型转向微型化,在八九十年代, 局域网络发展迅猛,金融、航空 、电力、通讯、等各类商用民用场 景快速跟进,不但使得计算机的总体量级大增,单个范围内需要管理的计算机规模也在不断加大和复杂化。 在这个过程中,形成了 以设备管理(包括网络设备/系统管理/硬件管理)、数据存储与容灾、目录与内容管理、资产管理、信息安 全
3、管理为主的传统运维体系。 的变迁运维 运维管理 设备管理 数据 存储与容灾 管理 目录与内 容管理 信息安全 管理 资产管理 的变迁运维 到了现在, 互联网模式占据了主流位置且至今未衰, 科技和业务模式带来的变化,也不停的推动着整个运维体系的转变。 比如, IDC取代了自建的局域网机房, 通讯主干虽然仍然关注但也不用再直接维护、而安全的挑战越来越严重。 运维管理 设备管理 数据 存储与容灾 管理 目录与内 容管理 信息安全 管理 资产管理 的变迁运维 早期那种大包干、一体化、定义宏大的运维体系,逐渐被更加明确与细致的分工所拆散。 的变迁运维 运维管理 设备管理 数据 存储与容灾 管理 目录与内
4、 容管理 信息安全 管理 资产管理 业务维护 运维开始更多的关注业务(早期在金融/电力领域,运维可能不直接关注业务, 而关注设备等. 但是到了现在,运维必须去了解业务) 业务管理所占的比重越来越大. 另外“运维管理”中各个子项的权重开始产生倾斜, 我简单的把它分为两个部份. 的变迁运维 1 10 100 1000 100200300400500600700800900100011001200 规模增长 复杂度1复杂度2 数 据安 全 业 务 设 备 内 容 资 产 为什么要这样划分的, 主要是源于复杂度的变化. 有一些维度是随着规模的增长而小量增长, 而另一些维度则随着规模的增长而变得迅速复杂
5、. 这种复杂度不一致突现,使得运维工作演生出更明确的分工,逐项剥离。 系统、硬件、网络一层开始出现专职的SYS(系统管 理员职位),安全也开从运维中独立出来,成为重要的一环。 资产管理、设备维护、自动装机等工作,不再是运维工程师关注 的重点, 相反,与业务可用性紧密相关的调度、监控、关系管理变得更加上层。而互联网时期的运维,尤其是自动化运维,其 主要关心的正是在这一层。 不同规模下的自动化构建 刚才从历史的角度梳理运维工作关注重点的迁移, 我们再来看看,即使同在互联网时期,不同规模下的自动化体系建设,又分别有哪些特性,可以采用哪些手段呢? 工具构建 单项化或批量工具化 PSSH OmniTTY
6、 PhpMyadmin Shell脚本 最初的自动化萌芽, 自然就是工具化的构建. 很多中小公司,几台到数十台的规模,最常用运维手段就是利用各种小脚本、小工具(切)。 相对于这个规模来说,这种方式虽然简单, 但也的确是一种低成本下可灵活实施且有效的手法。 但仅仅凭工具显示是不够的, 很多中小公司, 使用工具进行运维, 最集中的问题包括以下几个方面 问题 救火队员 缺乏运维指标 缺乏运维预案 缺乏知识库 救火队员:往往在出了故障以后才开始介入。 缺乏运维指标:甚至可能没有专职的运维人员,有些就是RD各自维护各自的系统。有没有问题全凭人的经验检查为主。 没有设立详细的运维指标。 缺乏运维预案:故障
7、解决基本是case by case的形式,很少去做运维的预案,发生什么事情时该如何解决。 缺乏知识库:不太会系统的总结/以及有一套完备的问题或知识库。 领域系统构建 部署监控数据 Puppet chef . Nagios Cacti . 当规模聚集到一定程度时,依赖工具化而本质仍是手工管理的运维自然无力应对。 许多中等互联网公司早已跨入千台的行列。 在这种规模下,各种针对特定领域的专有系统如雨后春笋般出现。 Nagios Nagios做为一款开源的监控系统,能有效的对各类平台的运行情况进行监控。使得在服务异常时发出邮件或短信的报警。 并且其体系非常开放,通过简单的插件编写可以使用户方便的扩展针
8、对自身服务的特定监控。甚至可以定义一些处理程度, 使得在服务或主机发生故障时起到一定程度的介入功能。 puppet 传统模型:做某种过程性的动作 puppet模型:通过定义角色应该有的状 态,使每个客户端知道自身“是什么”, 然后来决定做什么以“达到该有的状态” 而Puppet则是大规模集群管理的新秀. 其本身是用ruby开发,基于典型的C/S架构. 通过一种特定的配置描述语言来维护集群中机器的状态. 在传统的模型中,通常会用一些小工具,小软件来做一些过程性的动作。比如小脚本批量上线。 而Puppet通过抽象资源的方式,使得每台机器能够清楚其自身”应该是什么”,而不仅仅是像以前那样 一次性的做
9、什么. 各机器上的客户端根据这个描述,决定自身应该做怎么样的动作,并将自己的状态进行回报. 实现了高度灵活的自动化管理. 领域系统构建 运维的核心目标:保证服务的可靠及可持续运行 自动化运维:完全保证运维核心目标的前提下,尽可 能的将人工干预自动化 这类针对特定领域的管理系统,极大的减轻了运维人员在重复性、批量化操作方面的负担。 能够非常有效的在其领域内完成既定的运维子目标。 但其缺陷在于这些系统,通常只能针对一个领域进行处理,而对其间的关联性难以保证。或者 说打通的成本其实也很高 我们回顾一下运维的本质:。 监控是我们的目标吗? 部署是我们的目标吗? 这两个都是手段。 如果我们要搭建自动化,
10、其真正的目标应该是:完全保证运维核心目标的前提下,尽可能的将需要人后置干涉的部份处理掉。 平台构建 对于规模已经上万台、甚至十万台以上规模的各互联网巨头来说,其业务交织纵横、子系统间关系非常复杂。 传统的开源软件比较难以覆盖到这样场景下的运维需求。 在这个阶段,除了各服务自身的监控信息、部署信息需要运维外,服务与服务间的关系管理、上下游变更所带来的影响、 业务的串联也显得尤为重要。经常是牵一发而动全身。 各互联网巨头都在根据自身的业务特点、以及自身所采用的基础平台特性,自行的研发整体的自动化平台。 平台构建 资源 services ip port hostname url password 下
11、面介绍另一种的自动化运维体系模型: 先来做一个抽象: 我们把运维调度的最小单位, 抽象为一个资源: 比如一个服务的请求地址/一个端口/一个IP地址 无论是做一个监控/做一次部署,其实都是对这些最小资源做操作. 平台构建 资源状态资源定义资源位置 资源 services ip port hostname url password 控制策略 对于已被抽象了的资源,运维的核心关注就是三大块: 既: 资源应该是什么样, 资源现在是什么样, 资源在哪里。 根据它现在的样子,应该是什么样子,在哪里, 可以衍生出许多的动作. 举例:监控是一种动作, 部署是一种动作. 常见的运维手法都满足上面的表述. 对于这
12、三个方面, 又可抽象出具体的工程模型, 即: 需要一个容器来存放资源定义的元信息, 需要一个名字服务来表示资源的位置,这个名字服务可被下游订阅,当资源位置发生变化时能够主动通知到下游. 需要一个状态池来存放资源现在的状态信息, 运维衍生的各种工具可以根据这个池中的状态做出不同的业务动作. 工程模型 Naming Register Agent Service Meta Service Meta Machine Pool SET Service Service status status state pool Naming Sync URL MonitorRuleOpenApi Master st
13、ate pool 于是, 这类平台构建, 则可以根据所提及的对资源的三种模型, 映射到工程实践,从而引申出这样一张图表: 最左边的SET域: 用来对业务服务进行抽象, 一个服务,需要的元信息, 比如什么模块版本/安装在哪里.以及需要的资源. 建立一个Master, 读取这些Meta描述,以及状态池中实际情况,决定从机器池中选择相应的机器资源. 并将元信息发送到选定机器的客户端. 客户端收到Meta信息后,与本机的state pool进行对比, 根据差异决定启停的服务. 服务启动时,从URL中取出自身所需的资源信息, 而启动后, 需要主动到资源注册中注册自身信息,以供下游服务使用. 并在启动后,
14、将自身状态信息通过agent汇报给全局状态池. 应用可根据其状态决定各自的使用方式. 工程样例 Naming Register Agent Module:N? ? ? ? ? ? ? ? Host1 Host2 Host3 . Nginx Nginx status state pool Naming Sync URL MonitorRule OpenApi Master state pool LoadBalancer Cpu 90 ? 这个模型如果以一个运维实例举例的话: 我们可以定义一个叫 web/static的名字,做为网站的静态资源访问服务器, 这个服务器需要2台2G内存的nginx的机
15、器. master根据这个信息从机器池中选择符合条件的机器,下发meta信息, agent根据meta信息进行安装部署. 在启动后主动将已启动的nginx服务资源注册到 web/static名字中. 负载均衡的设备订阅这个名字,一但名字发生变化, 则能收到通知做相应的reload动作. 同时监控应用监控着相关服务的状态池, 当状态池中的状态到达一定阈值时,执行相应的报警,甚至干脆调用接口修改元信息,再多 部署几台机器以实现自动缩扩容. 基础架构与运维关系 OPS Applications Develop Machines (原来) 随着运维技术的进步,以及运维体系的完善,自动化运维做为一个既不
16、算新,又充满活力的方向,也随着规模、场景的变化迎 来新的挑战。 运维的活动空间,将不再像原来那样:既开发人员开发应用,不关注运维, 而运维人员主要盯着机器或单一服 务,的事后处理,无法从前面一开始介入、影响开发。在自动化运维发展的后期, OPS ApplicationsDevelop 基础架构与运维关系 Infrastructure Operation Platform machine1 machine2 machine3 (现在) 运维,将更多的介于硬件与操作系统之上、应用之下, 与基础架构相辅相成,交替推动。 故而自动化运维平台的根本,不是说仅仅把操作界面化,做成一个OA一样的办公系统,让
17、人点点鼠标来操作。 而是能够在底层的基础架构与上层的业务系统之间搭建一个良好的桥梁,使得业务系统能够充分、稳定 ,却又不过度关注 底层架构特性。这个时期的运维,已经不再是打扫设备、收发报警的后置服务,而是在业务开发时期介入,伴随整个业务 共同运行的一种特殊服务。 时代的变迁与挑战 开发关注运维运维影响开发 在可预见的未来方向上,运维的角色重要性将越来越提升,这种提升的关键在于运维在整个技术体系中的参与度及所处位置发生 的变化。自动化运维的兴起,将传统意义上处于后置服务的运维人员带到了服务前沿,以往简单的追查故障、保障服务虽然仍占 据运维工作的一部份,但随着自动化运维技术的发展,运维人员有更多的精力、条件,投入到整个服务架构的梳理、设计中,甚 至以提供基础组件的方式参与到研发过程,使得产品天生具有较高的可运维性。 研发要关注运维、运维有能力介入研发,具有对等能力的角色配合,各自负责不同的领域方向,这是技术发展大体系下的必然分 工,也是运维摆脱苦力劳作,继续往更深技术发展的必然之路。 QA Syupei
链接地址:https://www.31doc.com/p-3332016.html