精华内容
下载资源
问答
  • 如果没有清晰的云运维规划和手段,云数据中心将难以高效的运转起来,所以云运维对于云建设者来说是至关重要的一环。那么云数据中心与传统的数据中心运维有什么共同点和差别?做好云运维应该关注什么?该如何选择一个...

    随着工业4.0的兴起,云计算已经从实验阶段转化为具体实施阶段。除了部署相应的软件、硬件和虚拟化资源,还有一个问题摆在我们面前,如何运维云?如果没有清晰的云运维规划和手段,云数据中心将难以高效的运转起来,所以云运维对于云建设者来说是至关重要的一环。那么云数据中心与传统的数据中心运维有什么共同点和差别?做好云运维应该关注什么?该如何选择一个合适的云运维工具?上述问题都是应该是云运维过程中会遇到的。下文会针对这些问题展开详细论述

    一、云运维与传统数据中心运维比较

    “云是数据中心的新IT形态”,云与传统数据中心的建设目标是一致的,都是为企业提供IT服务。运维人员的职责都是保障IT服务的质量,围绕服务等级协议SLA展开各种运维活动。然而在运维技术、管理模式、财务流程、服务分级、业务要求、运维职责划分等方面两者又有所不同。

    · 相对于传统的数据中心,云数据中心的服务特征更加明显,云数据中心将基础设施(IaaS)、平台(PaaS)、软件(SaaS)以服务的形式提供给最终用户,它利用虚拟化、SDN等技术将网络、计算、存储以及应用等资源池化,通过自动化技术按需为用户分配IT资源。因此在云运维中IT请求交付(Request Fulfillment)流程的地位不断突出,也使得云运维显示出明显的运营性质。

    · 云也改变了传统数据中心的财务管理模式和采购模式,传统数据中心原来的采购流程变为了服务审批流程。要申请云数据中心资源,面向云业务的计费系统也应运而生。云计费除了用于真正的收费场景外,更多的时候应用于企业内部,通过内部核算,也就是经济杠杆去有效约束IT资源需求,形成在服务质量和IT资源间的平衡,有效提升IT资源利用率。

    · 云数据中心对IT服务交付速度提出了更高的要求,然而云数据中心的基础结构却比传统数据中心更加复杂,手工交付难以满足云服务交付的速度要求,更容易发生故障,自动化交付就成为了云服务交付的必要手段。

    在传统数据中心,运维人员需要关注基础设施的维护,而在在混合云和公有云应用场景中,应用管理的地位更加突出。运维人员不必关心部署在公有云上的业务所依赖的基础设施,而业务监控的职责也转移给公有云提供商。公有云提供商不但要保障IT基础设施本身,还要更加关注承载业务的运行状态。

    二、云数据中心运维简介

    在云数据中心维护过程中,云服务请求交付系统、计费组件以及自动化部署组件已经从云运维系统中剥离出来,形成相对独立的运营平台—云平台。云平台提供了服务目录、自助服务台、云服务自动部署、以及一体化的计费和核算功能,因此云平台对云数据中心的正常运转至关重要。

    而传统的网络监控、服务器监控、机房监控、业务监控、事态管理、变更管理、问题管理、配置管理对云数据中心而言依然不可或缺。

    云平台是云数据中心的对外服务和展示窗口,是云租户对云数据中心的直观体验。云数据中心运维是云服务水平的后台保障,二者就像客机上的空乘和地勤一样,在云数据中心缺一不可。

    1、云运维过程中需要关注哪些问题?

    在云运维过程中主要需要关注如下几个问题:

    • 选择开放架构

    云虽然已经到达了可实际部署阶段,但是云平台架构、计算虚拟化技术、网络虚拟化技术、云与大数据的配合等技术依然发展迅速。为保障云运维的持续发展,应该优先选择正在不断演进的开放平台作为基础架构。

    •  CMDB作用愈加明显

    在私有云和混合云应用场景中,高度集中的业务、高度集中的设施、广泛应用的虚拟化技术、众多的云设施和软件供应商、多样的云服务消费者,以上这些因素组合在一起,使云运维的复杂度成指数级增长。云数据中心的设备信息、应用信息、策略信息、维保信息、组织信息、负责人等各维度的信息交织成复杂的关系网,实际运维时如果能从这张关系网中将所关注的信息抽丝拨茧,将大幅提升云运维的效率。反之如果没有有效手段管理这些关系,云运维可能会变得混乱和无序,运维效率低下,使云服务体验大打折扣。设计合理的CMDB(配置管理数据库)恰恰是解决这个问题的最佳途径。CMDB自动同步配置项信息,将割裂的各维度信息关联在一起,帮助云运维人员全面、准确和及时地了解业务相关的组织、资源、环境和服务等不同维度信息,使运维人员快速准确地了解事件影响范围,作出正确的决策。

    • ·使用必要手段全局监控业务质量

    在混合云应用场景中,部分开放的业务会部署到公有云上,企业运维人员无法有效的监控到公有云的基础设施,在这种情况下,公有云的服务等级SLA就成了一个黑盒,无从监控。所以必须要有有效的手段全局监控业务质量,从而间接评价公有云服务等级SLA。

    • 明确云架构下各机构的责任主体

    由于企业组织架构是按照传统的网络、应用、计算来划分的,而在混合云场景中,云服务商与企业运维人员也不属于同一组织机构,所以当部署在云上的业务出现故障时,容易出现组织间的推卸责任的问题,从而延长了问题的定位和解决周期。因此企业运维人员要有手段基于业务按照网络、计算、应用等不同维度的出具资源健康度报告,明确问题责任主体。

    • 云场景下如何有效控制开销

    云应用场景中还有另外一个问题,就是如何使用最小的开销(公有云资源),最大限度地保障业务的质量。为了保障业务的稳定运行,企业运维人员通常为每个业务申请一定的资源余量,然而过多的余量会增加财务成本,如何确定这个量,就成企业运维人员关注的问题。一份能将业务运行时所需要的CPU、内存、磁盘等历史信息进行有效分析的可度量的业务容量分析报告,将对企业运维人员非常有用。如果在资源不足发生前,有工具能够提前预警,给企业运维人员充分时间调整资源分配策略,将有效节省公有云开销。

    • 使用可控的自动化手段提升管理效率

    云数据中心的资源规模、业务规模、组织规模远远超过传统数据中心。新设备的快速部署、快速上线、纳管监控、资源编排、定期巡检、升级和配置变更这些原本就颇为复杂的工作在规模和速度的双重压力下都变得更加艰巨。传统的手工方式效率低下,出错风险高,自动化手段逐步成为云运维的首选。随着虚拟化、PXE、SDN、Overlay、服务链等技术不断广泛应用,自动部署、自动编排、自动巡检、自动升级等自动化手段越来越多应用于云运维。然而自动化仍然要在可控、可跟踪、可审计、可回退的前提下进行,避免单个错误的扩大化。虽然自动化还存在一定风险,云运维的自动化趋势已经不可逆转。

    2、如何选择有效运维工具

    运维工具产品种类繁多,每种运维工具都有自己适合的应用场景。云数据中心架构复杂,业务集中,应该如何选择适合云运维工具产品呢,下面将展开详尽的分析。

    大集中的云数据中心降低了IT整体维护成本,也增加了业务风险。精密空调故障、UPS故障、火灾、漏水任一风险如果不能及时处置都可能给整个云数据中心造成无法修复的大面积损坏。这种损害影响程度远远大于单设备的故障。所以实时的机房监控工具对于云数据中心运维依然非常重要。

    对于云运维而言,如果仍然按照传统的网络、计算、存储、虚拟化、应用去分别管理,对云运维人员讲,不但头绪繁多、而且效率低下。最好能选择一套工具,能够将应用、网络、计算、存储、虚拟化等IT资源的性能及告警信息综合分析,通过简洁易懂的界面,直观呈现业务健康水平。当出现故障时,能够先从全部业务的宏观视角,确定关联和影响,再通过智能钻取和故障定位技术,缩小故障定位范围是在计算、应用还是网络,从而明确问题职责,帮助IT管理员准确定位业务故障位置。

    选择合适的数据中心容量管理对数据中心运维也非常重要,容量管理工具要能从业务、集群、机房等多个角度分析数据中心容量趋势,预测容量风险,指导资源优化,为IT投资提供量化依据。业务容量管理要能根据业务负载及资源消耗趋势,预测系统资源瓶颈,为管理者提供容量预警和扩容建议。集群容量管理应该全面监控集群内物理和虚拟化资源,智能分析资源超配比例,指导资源配置。

    选择合适的CMDB工具会给云运维带来事半功倍的效果。CMDB工具让云运维人员全面、准确和及时地了解业务相关的环境、资源、组织、服务信息,有效帮助云运维机构消除信息孤岛,提升信息关联性和透明度。

    云运维监控工具除了上述特性方面的考虑外,还需要注意工具的广泛的资源监控能力。只有具备监控各种应用、多个厂家的网络设备、不同服务器款型、不同虚拟化产品等IT资源的能力,才能进一步作到融合分析和统一运维。如果没有广泛的适配能力,云运维工具就成了中看不中用的花架子,难以产生真正的价值。

    运维工具在选择时还要注意一点,不能将运维工具想象成万能的,所有问题都依赖工具解决。运维工具是配合云运维规划、企业组织架构和企业管理制度一起来保障云服务质量的,它仅仅是云运维的一个组成部分。云运维仍然需要遵从PDCA(计划、执行、检查、行动)的规律不断改进和优化。随企业的业务要求变化、管理体质调整和技术发展,运维工具也需要不断演进、不断优化,所以云运维工具的选择也应循序渐进,不能一口吃个胖子。

    结束语

    云运维是个复杂的系统工程,选择好的云运维工具无疑会使云运维变得轻松,高效。然而选择这样的工具前,首先需要考虑云运维的组织应该如何更好的为云服务,清晰的组织划分,明确的责任定位,完善的流程规划,能够帮助确定云运维工具的软件定位,从而使快速找到合适的运维工具事半功倍。云运维工具仍然依托于传统的IT设施监控和应用监控,没有这个基础云运维将变成空中楼阁。在此基础上,云运维工具更加重视系统级的业务监控,更加重视业务、资源、服务和人之间的关联性,更加重视智能排障能力,更加重视容量管理,更加重视自动化能力。有了合适的运维工具软件,云运维自然变得简单。


    本文作者:佚名

    来源:51CTO

    展开全文
  • 平安云运维解密

    2017-06-12 09:02:56
    作者简介:周锋、丘子隽,平安平台事业部云网络服务组技术专家 本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请[订阅《程序员》] 导读:本文将介绍平安的日常运维管理,工具研发与最佳实践,希望...

    作者简介:周锋、丘子隽,平安云平台事业部云网络服务组技术专家
    本文为《程序员》原创文章,未经允许不得转载,更多精彩文章请[订阅《程序员》]

    导读:本文将介绍平安云的日常运维管理,工具研发与最佳实践,希望对从事云计算服务的读者有借鉴意义。

    平安云简介

    平安云隶属于中国平安保险(集团)股份有限公司,依托平安集团构建的金融及健康IT生态圈,为银行,证券,保险,互联网金融及医疗健康类机构提供按需付费,高可用,高弹性,安全合规的云计算服务。结合金融及健康业务在系统,合规以及数据方面的特性,平安云除为客户提供开发,测试,生产,容灾在内的全套基础设施服务外,还提供定制化金融IT解决方案。

    从13年底立项以来,平安金融云一直尽可能走开源和自研结合的路线,自主研发了IaaS层的全套产品线,为金融行业客户提供可靠、弹性、高效、集约的基础架构层服务。

    日常运维管理

    基于ITIL的流程管理

    图片描述

    图1 平安云的运维管理流程体系

    多数企业的日常系统运维都是遵守ITIL体系。云计算改变了资源交付与运维资源的方式,云平台本身也是新的运维对象,需要控制风险,解决事件,跟进问题,管理平台资源池的容量。

    平安云承担了一部分企业基础架构的角色。如图1,为了满足金融企业的高合规特征,平安云的运维严格遵守ITIL流程,按照平安科技的制度规范要求实施变更,事件,问题,业务持续计划以及容量管理。

    包括已经通过工具自动化的操作,所有的生产区变更都需要经过每周两次的内部变更评审会议授权后才可以触发工具实施。对于网络等全局性的变更更是需要提交到重大变更评审系列会议获得高级主管审批后方可授权执行。

    同时,由于业务的快速转型需求,运维对象与运维内容的变化也越来越快,因此在传统的ITIL风险控制流程之上,我们借助开源或自研开发了很多运维辅助工具。另一方面,在业内去IOE、分布式系统的背景下,大量采用了供应商竞争激烈、通用的Server,通用Server的单机可靠性要比以往的专用小型机等服务器有所下降,但业务通过分布式部署后反而提升了整个应用的可靠性。,因此单一的物理资源可靠性指标的集合并不能有效地衡量IT服务可靠性,而需要从上层服务的整体可用指标来实施创新与衡量服务可靠性,这个转变对金融技术转型来说尤为重要。

    平安云引入了SRE运维云平台系统,总结来说中心思想有两点:1.从软件或架构层面分析问题解决问题,避免引入人的工作或影响,2. 所有必需的操作都要有工具支撑,避免随着底层操作对象资源的增加而增加工作人力。这个思想并没有违背ITIL理念,从我们的实践经验分析,SRE可以作为ITIL新时代的工具,良好地融合后可以有效地支持金融业务在云上的可靠性。

    门户自助资源交付与责任共担体系

    平安云作为平安集团基础架构的延伸,首先希望能够实现下面的目标:

    1. 运营或业务用户可以直接自助申请资源,分钟级交付。并进一步实现快速扩容能力。
    2. 各个应用专机专用,消灭应用间的交叉影响。
    3. 在云门户上实现权限控制,各应用的所有者对自己的主机有完全的管理权,在拥有root权限之上更能自主poweroff/poweron主机。

    在传统的大物理机环境下,会出现多个业务应用共享一台高性能主机。在这种环境下,应用所有者很难单独为自己的应用在操作系统层调优,安装软件或自助的启停主机,必须通过冗长的申请流程要求主机管理员实施。通过云计算,应用所有者完全独享自己的云主机,并可以根据业务需求自由的设置各种操作系统参数或者安装软件。

    在传统的虚拟机环境下,由于VCenter等统一管理平台的集中权限管理,业务应用虽然可以拥有自己独立的OS,但是当OS需要冷启动或需要进行配置伸缩时,必须走流程通过虚拟环境管理员帮助操作,在时效上与效率上都不能满足创新业务的快速需求。

    平安云自主研发了一套云门户系统,用户可以通过门户自主的管理自己的云主机,包括主机的启停,配置修改以及类似带外管理的local console等功能。同时,由于有严格的基于租户与资源组的视图隔离与权限控制,可以确保每个应用资源组管理员只能够看到自己系统的主机,保证了资源组管理员操作应用主机合规,安全。
    图片描述

    图2 IaaS模式下的责任共担体系

    如图2,通过云门户隔离OS的视图与操作权限,将独享主机操作所有权与管理责任上浮,分布到不同的应用资源组,提供给应用资源组管理员更加自由的灵活度与更安全的应用之间的隔离,原有的基础架构运维人员可以集中精力处理平台层的优化与运维,从而提高运维效率与系统稳定性。

    私有云 vs 公有云

    在一开始平安云是以公有云的标准来规划和运维平安自己的私有云平台产品的,但是经过两年多的运维和越来越多的生产应用上云,我们对私有云的定位和运维方式也在不断思考和改进。主要有下面三点:

    1. 私有云相当于企业中基础架构的地位,因此第一价值导向为服务业务应用,保障应用可用性。这与公有云单纯追求单机可用率是不同的,私有云不但要提供可以接受的底层资源可用率,同时也要有手段分散风险影响面,避免异常集中在同一个时间点。我们在后续的架构改造中,牺牲了一定的共享资源灵活性,而转为优先保障底层资源隔离,避免由于底层共享资源异常而引起的大面积故障风险。
    2. 私有云与上层应用关联紧密,应用团队与云平台团队之间的沟通频繁。云平台可以对应用部署方式提出规范,亦需要有手段与运营团队一同巡检应用的部署方式是否符合规范。因此云上应用对云平台团队来说不是黑盒,而是灰盒甚至是白盒。
    3. 业务应用有编排搭建,快速扩容,容灾同步,数据备份等需求,这些都需要云平台产品针对具体的业务场景开发解决方案。因此在后期平安云的产品建设更多的以实际业务需求为导向,开发了标准应用系统编排搭建,本地盘方案,云主机复制,文件同步,按需自动开通防火墙等产品与功能。

    为了保障应用可用性,我们提供了如下手段:

    1. 双AZ部署

    每个区域(Region)均提供了两个可用区(Available Zone),可用区之间在计算网络存储三个层面物理隔离,要求应用必须分散部署在两个可用区,通过ELB服务分散流量到两个可用区的云主机上。即使一个可用区由于物理故障全down,另一个可用区也可以正常提供服务。

    1. 关联性组

    顾名思义,就是将一个应用集群中的云主机都放到同一个关联性组内打上标签,在云主机启动时后台会分散同一个关联性组的主机到不同的底层物理服务器上,确保单台物理服务器的硬件故障只会影响到一个应用集群中的一台主机实例。应用前端如果有使用ELB服务的话,应用可用性不会受到影响,而只会减小应用的最大服务容量。

    1. 超融合架构

    平安云提供使用超融合存储的云主机。使用计算单元物理机的内置大容量磁盘提供三副本分布式存储,消除了iops集中在某一台存储设备或存储路径上的情况。同时控制一个存储集群上的云主机数量,避免由于底层资源故障导致的大面积故障。

    工具研发

    Argus监控

    监控是系统管理的基石。如果监控失效,则我们无从得知系统状况如何,甚至是否运转正常,所以监控系统需要具备极高的可用性。在早期,我们选择基于zabbix进行二次开发,但随着平安云规模超过万台主机以后,zabbix达到了性能瓶颈,无法跟上业务发展的脚步。于是,在调研之后,我们选择了二次开发open-falcon 来重新构建整个监控系统。它具有高可用、易扩展、易维护的特性,支持第三方告警接入。

    open-falcon的告警对接到平安自研的端到端监控平台,并在告警展现上做优化、分析与收敛,方便运维人员快速判断异常来源以及原因。同时通过open-falcon的api,接入ELK日志分析与自研的VMWare myclient监控告警,可以从日志与集群角度实施监控。

    目前我们也在尝试智能的数据分析与自动恢复等策略,出于谨慎考虑我们对自动恢复还是比较保守,加入了人工触发的步骤。

    图片描述

    图3 Argus平台架构

    AlphaOPS

    平安云给自己的运维自动化平台和运维体系起了个名字叫AlphaOps,寓意是希望能够达到智能运维的目标。

    图片描述

    图4 AlphaOps平台架构

    如图4,在定义AlphaOps运维自动化的时候,我们定义了三种AlphaOps的开发模式:集中管理平台模式,脚本自动化模式,产品自带运维模式。这三种自动化模式也可以诠释AlphaOps开发中的工作内容。

    集中管理平台模式

    AlphaOps有专职的运维开发成员,他们主要负责梳理云平台各层组件之间的关系,对接已有的核心应用CMDB与资源管理CMDB,针对高频或强烈需求的运维场景开发集中管理平台,展现资源之间的关联关系与平台容量的趋势,批量展示或操作海量资源,以及实现云内管理平台基础资源的自动交付能力。

    AlphaOps平台基于keystone框架实现了精确到实名账号的鉴权机制,对运维人员最小授权与留存所有操作日志。再配合基于FreeIPA,Tacacs+,guacamole开发的智能终端登录平台,运维人员可以在一次AlphaOps登陆验证身份后,免密登陆授权给自己的堡垒机与终端实施操作,减少了花费在设备之间跳转上的工作量,也减少了特权账户密码泄漏的风险。设备的admin账号根据需求授权到个人账号,三个月自动更改一次,自动进入后台teampass数据库,运维人员不需要知道密码即可管理相应基础资源。

    脚本自动化模式

    集中管理平台有一定的规划和设计,能够实现较完整的功能,但无法满足运维场景的多样化与个性化需求,因此AlphaOps平台打通了各个计算,存储,网络产品之间的连接后,既提供了集中式运维管理平台供运维人员在上面实施一键式操作,又提供了方便的web service接口供运维人员能够依据各种个性或突发运维场景在AlphaOps的工具Terminal上方便地编写运维脚本,实现对海量规模对象的高效管理。

    为了确保运维脚本的一致性与可维护性,我们也要求所有的脚本都要遵循开发过程规范,所有版本修改必须由需求引发,版本入库管理,代码评审,并且需要遵守一些共通的日志,权限等规范要求。

    另外,由于平安云的运维人员都具有开发能力,我们也要求运维人员积极参与到产品的早期开发建设与架构评审中,在产品开发阶段即引入运维参与,确保产品的可靠性与可运维性。

    产品自带运维模式

    基于开源软件做二次开发实现产品化是很多云平台建设的选择,平安云也不例外。为了确保这些产品的可靠性与可运维性,我们对产品开发提出了3条要求:

    1. 不低于99.95%的可用性。
    2. 在设计和开发过程中考虑可运维性,提供RESTful的CRUD以及启停等运维API接口。
    3. 在产品发生异常时的快速恢复三板斧(重启/切换/回滚)需要验证有效,提供POC环境和测试环境的验证结果。

    基于上述要求开发出来的产品天然具有可运维性,后续AlphaOps只需要梳理环境后,调用产品自身的API即开即用,并且组织到各个运维场景中。

    CMDB

    目前平安云的CMDB主要分为两个部分,向应用方向的核心配置管理与向基础资源方向的基础资源配置管理。

    平安云的门户通过租户与资源组的两级管理实现了各个BU以及各个应用系统到云上交付物的映射管理,再加上平安科技原有的集群资源管理系统,AlphaOps对这些信息做了聚合,实现了从上之下与从下至上的应用与底层资源的关联关系管理。运维人员能够快速的在应用信息到所有关联的底层资源之间进行相互查询。

    对于基础资源的配置管理,主要管理两类信息:

    1. 基础资源的属性管理。如物理机,交换机等的配置,物理位置等信息。这部分信息大部分也与资产管理相关,在几乎所有的CMDB中都会涉及到。
    2. 基础资源之间的关联关系管理。这部分信息由于错综复杂,信息量大,几乎不可能手工录入。目前平安云采用的是使用agent自动采集的方式来管理和录入系统。

    另外,针对各个设备与主机自身参数设置的动态采集与基线管理也在平安云CMDB的开发计划中。

    NSP

    NSP全称是网络服务平台(Network Service Platform),作为平安云网络的核心组件,实现异构厂商设备的统一管理,网络功能虚拟化,抽象出通用易懂的网络功能模型,为云门户和其他系统提供网络服务。通过NSP自动化的对接平安内部的审批系统,统一的配置设计和检查,达到提高网络配置效率和减少人工错误的事件。NSP提供的服务归纳为以下四种:
    图片描述

    图5 NSP功能架构

    1. 基础网络自动化配置:NSP提供API接口,实现虚拟网络和物理网络的自动化配置,为租户提供L2/L3层网络弹性扩展能力;
    2. 网络编排服务:租户VPC的网络编排,NFV设备的编排管理,SDN能力集成等。
    3. 高级网络服务管理:提供防火墙、负载均衡、VPN等高级网络服务的配置和管理;
    4. 网络增值服务:接入第三方网络服务,将其他公司提供的增值网络服务接入云平台,比如网络探测服务、CDN、DDoS服务等。

    VMWare myclient

    平安云的传统金融分区部分底层使用了VMWare作为虚拟化技术,平安云团队自研了一套myclient接口,实现了三个方面的能力:

    1. 从hypervisor层采集监控信息,能够从全局把控虚拟化集群的健康状况与告警。
    2. 作为cloudstack的补充,实现了直接管理VMWare的能力,在一些应急预案、大规模迁移、以及参数设置的场景中能够高效完成自动化操作。
    3. 平安集团的传统环节还有很多存量的生产虚拟机。通过myclient与ESXi对接,将这些虚拟机接入到平安云门户,再梳理应用所有者权限后,能够达到与80%与云主机相同的效果。

    Lesson Learn/最佳实践

    在平安云的建设与生产使用过程中,我们经历了主机从零到百,从百到千,从千到万的过程,收获最宝贵的是架构治理,业务入云和海量运维的经验,这种不断提高的过程是平安云能够在过去2年中迅速成长的关键。其中针对海量业务中主要有下面三条心得。

    共享资源粒度

    由于云计算最早是从虚拟化起步,而虚拟化的一个重要标志是使用底层共享存储实现秒迁移能力,因此在前期平安云也是采用了共享存储做为底层存储。在过去2年的使用中发现共享存储有如下两个问题:

    1. 定时任务共振
      云主机都是由标准化的OS模板生成,这些模板中通常都内置了一些定时任务。当云主机数量上了5000之后,每一次几千几百个定时任务的同时调用对于底层存储来说都会是一次iops风暴,必须通过对cron job或者被调用脚本的random启动处理来分散io压力到不同的时间点。
    2. 共享存储异常时的影响面
      当同一个共享存储异常时,基本上会影响到其上所有的物理机与云主机。另一方面,尽管对云主机的io有iops限速,由于金融行业特性,大部分业务发生在工作时间内比较集中的时间段内,当一套存储上的云主机过多,且业务繁忙时期,一片面积的主机都达到iops上限时,对于共享存储的性能来说是一个很大的挑战。

    因此,从分散风险的角度需要控制一个可用区内单个存储设备上的云主机个数。

    黑天鹅思维

    量变引起质变是所有事物的共通规律。当IT环境到达一个规模后,所有看起来是低概率的事件都一定会先后发生,肯定会发生。因此不能因为一个异常看起来发生的概率很低或感觉不会发生就忽视它们。

    在经历了1,2次黑天鹅概率级别的故障之后,平安云加强了针对应急预案建设的人力投入,并且确定了下面的验证应急预案的原则:

    1. 所有的关联组件都有可能出问题,并且有些关联组件有可能短时间内恢复不了,此时恢复预案是否有效。
    2. 所有涉及自动化处理的代码逻辑都有可能会出问题,出问题后人工介入是否有效。
    3. 针对各种组件,都需要有有效的关联关系管理的CMDB。所有的组件都必须有重启/切换预案,且必须要定期验证其有效性。

    各项服务指标的全局把握

    云平台本身的可用性与性能指标并不是一直不变的,随着底层资源容量的变化与规模的增大,可用性和性能很有可能在某一天会发生突然的变化,在这之前都会有一些征兆产生。

    目前我们通过每日的自动化巡检,E2E不间断测试与在网络/存储端部署监控来保障云平台整体的交付能力,可用性与性能:

    1. 每日自动化巡检
      AlphaOps平台自动分析从各个层面的产品搜集到的信息,聚合后展现在巡检页面上,每天早班同事会确认巡检页面并且发出关于容量,资源使用状况的巡检报告。
    2. E2E不间断测试
      原本测试是偏重于进入正式生产阶段前的功能性验证与并发度验证,属于一次性工作的概念。平安云通过Robot Framework+Jenkins等持续集成与自动化测试工具,编写从云主机申请到负载均衡申请等一系列测试用例,每天不间断的的在生产可用区实施端到端的自动化测试,这样可以实现从用户的角度直截了当发现平台中的潜在问题。
    3. 从网络与存储聚合路径点实施监控
      平安云在接入交换机上部署了对错误日志的分析告警,在存储的控制器路径上接入了CPU使用率告警,从平台上下层的入口实现了对全局流量与io指标的监控,当发生流量超过阀值告警后通过AlphaOps的性能分析工具可以迅速定位到问题主机,从而采取必要措施保障平台稳定性。

    全天候聚焦IaaS/PaaS/SaaS最新技术动态,深度挖掘技术大咖第一手实践,及时推送云行业重大新闻,一键关注,总览国内外云计算大势!
    图片描述

    展开全文
  • 叮铃铃~ “客户又投诉了!还是投诉网络慢,快查查是怎么回事!” “好的,马上排查!” 王亮放下电话立即展开对整个数据中心网络的排查,心想,这已经是这个月第3次...偶然一次关于公有云运维的技术论坛上,王亮接触到

    叮铃铃~
    “客户又投诉了!还是投诉网络慢,快查查是怎么回事!”
    “好的,马上排查!”
    王亮放下电话立即展开对整个数据中心网络的排查,心想,这已经是这个月第3次接到这个客户投诉了,每次都是投诉网络慢,但紧急排查之后却又没有发现任何问题,这是怎么一回事呢?
    王亮作为一名运维工程师,任职于西北某省中国移动公司云数据中心(后简称“数据中心”),数据中心肩负着全省众多机关单位的托管业务,王亮作为运维团队的一员,工作中最大的困扰就是接到客户投诉,却又无法排查出故障所在。
    在这里插入图片描述
    偶然一次关于公有云运维的技术论坛上,王亮接触到了明辰智航云安网络与虚拟化性能管理系统,通过与明辰智航云安团队的交流,试探的提出了此前困扰数据中心运维团队数月的问题,咨询该问题是否能够得到解决,令王亮没想到的是,明辰智航云安团队马上就为数据中心开展了测试部署,将常接到投诉的应用拉到同一个服务组,并与王亮约定一周后可以查看结果。
    经过一周的数据采集后,部署的明辰智航云安收集了足够的数据,并针对性的为数据中心进行了故障诊断。测试工程师进入明辰智航云安的操作界面,点击进入应用服务组,查看应用拓扑图,发现Web-server03服务器出现了红色示警,并且WebServer03与APP-LB-1外部网络通信也同样出现了红色示警:
    在这里插入图片描述
    测试工程师接着点击红色示警的服务器WebServer03进一步查看,服务器详细界面中http服务出现了应用程序响应时间过长的问题:
    在这里插入图片描述
    点击红色示警的http进一步查看根本原因,在根本原因界面中,显示根本原因与CPU、内存、存储有关系的可能性为0%,与应用程序中http由WebServer03提供有关系的可能性为50%:
    在这里插入图片描述
    同时在应用交互信息界面中,部分客户端在与服务器WebServer03通过http服务交互过程中,应用程序响应时间过长,并且每次针对与同一请求都出现响应时间过长的情况,且请求回应均能够通过:
    在这里插入图片描述
    ② 服务器红色示警,应用程序响应时间过长;
    ② 根本原因应用程序中http由WebServer03提供有关系;
    ③ 应用程序每次针对同一请求都出现响应时间过长的情况,且请求回应均能够通过。
    结合以上三点,测试工程师判断问题可能是出在客户应用程序上,故障点初步确定!
    明辰智航云安随即通知王亮故障诊断结果,王亮喜出望外,马上通过数据中心将明辰智航云安的诊断数据记录发送给客户,客户工程师根据数据记录检查,最终找到问题确实出在了应用程序代码上,修正后,网络慢的问题终于被解决了!客户方工程师表示非常惊讶,一直追问是如何找到问题所在。王亮露出了释然的笑容。
    在公有云运维中,由于应用程序造成的故障时有发生,而常规手段的排查运维人员很难具体判断出故障所在,从而导致无法进行责任划分。
    运维人员可通过明辰智航云安直观的看到整个公有云环境的健康状态,通过简单的鼠标点击就可以进一步查看红色示警信息的根本原因;其中应用拓扑图可以清晰的展现各服务器应用之间的联系和状态;应用的交互信息界面则记录了每个交易请求的响应情况,为公有云运维责任划分提供强有力的证据。
    经过此次与明辰智航云安的接触,数据中心的王亮真诚的说道,“在我们团队日常运维中,如何进行责任划分,是困扰了大家很久的问题,我们迫切的需要一款像明辰智航云安这样能快速定位故障,并明确进行责任划分的运维管理系统。”

    ——入运维苦似海,手无法器难称佛。
    想要云运维,就要有云安!

    展开全文
  • 作者介绍 朱祥磊,山东移动BOSS系统架构师,负责业务支撑系统架构规划和建设。...上篇我们已经详细分享了监控相关的知识,然而运维可视化,除了构造可视化监控外,还要建立相应的运维手段化下的运维工具和传...

    作者介绍

    朱祥磊,山东移动BOSS系统架构师,负责业务支撑系统架构规划和建设。获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项,申请发明专利13项。

    工具篇:构建可视化分布式运维手段

    工欲善其事,必先利其器。上篇我们已经详细分享了监控相关的知识,然而运维可视化,除了构造可视化监控外,还要建立相应的运维手段,云化下的运维工具和传统架构的有较大不同,对集群式、分布式提出了更高的要求。

    1、自动化巡检

    从2011年开始推行巡检,最初,我们的武器仅仅是一个word文档、一些excel表格和大量的SHELL脚本,检查靠人工敲击命令或者查看表数据,内容也多数都仅限于日常维护中已经存在的主机,数据库,中间件,进程状态等,执行效率较差,并且未真正涉及业务类的健康检查。

    从2014年12月开始,正式引入自动化巡检工具,工具对原来积累的脚本进行整合,提供可视化操作局面,能够定期自动执行、自动生成巡检分析报告,巡检内容涵盖主机、数据库、中间件、应用在内的所有监控对象,并且随着巡检的深入,在2015年起又增加了业务级别的巡检内容,对于一些关键业务关键点也定期进行巡视分析。

    1)自动化巡检内容

    目前自动化巡检对象涵盖了所有的生产主机,固定巡检内容主要包括常见的系统安全隐患、入侵攻击检查,安全补丁检查,系统配置、加固检查,数据库安全配置检查,详细如下:

    巡检工具把历史积累的SHELL脚本参考上面内容进行逐步归类,作为巡检工具的基础项,也可以随时对巡检内容进行修改,所有的巡检动作全部可视化,并且巡视项、巡检方式、巡检主机等全部可以进行定制,巡检任务结束后会自动生成巡检报告,并能通过邮件、短信等渠道第一时间告知关注人。

    2)自动化巡检效果

    从2014年底以来,通过将日常巡检报告自动化,不断来提升运维的自动化程度,通过脚本管理、故障诊断、拓扑图执行远程命令调用等功能规范日常运维操作。通过巡检可以保存系统性能数据、容量信息、配置信息为系统维护、升级、扩容提供决策数据支持;同事通过灵活的工具定制,达到了对各种等资源全面的监控、多级钻取实现性能分析,提升运维的专业化水平。

    2015年中开始,在实现系统自动化巡检后,我们再接再厉,终于实现了业务巡检的工具化,目前业务相关的巡检包已涵盖了系统安全、无纸化、服开配置、业务规则等巡检内容共计10类28项业务,能够随时掌控关键业务监控度,具体的业务巡检内容和界面如下:

    2、自动化JOB

    在系统日常运维中,存在大量重复并且简单的运维操作,包括最常见主机、中间件、数据库等不同类型的软、硬件平台运维。这些运维操作重复而机械,却易于出错,占用了大量日常运维人员的精力和时间。

    通过运维自动化工具,将运维操作场景化、可视化、自动化和标准化,将以前需要编辑大量脚本和命令进行的维护操作变为只需要点击相关的场景调用以及输入合适的参数,大幅减少运维人员在编写脚本和命令分发执行所带来的资源投入。

    日常运维场景

    日常运维场景是将系统管理员的日常工作项目,集成于同一界面,可对自动执行的任务进行处理,并提供统一接入入口和监控界面。

    首先,系统管理员先进行任务配置,系统管理在任务配置页面,进行任务分类与任务的配置。使用日常任务之前,需要先配置在相应的任务分类下配置任务,才能使用。

    此后,系统管理员在任务视图是各分类的任务的执行页面。配置任务完成后,打开任务视图,可看到不同任务分类下已配置的任务,点击执行,进入参数输入页面,选择执行的目标设备,输入参数后,点击立即执行完成运维场景所需要执行的运维操作。

    自动化告警处理

    传统告警处理,主要靠人工值守进行操作,告警响应速度受到多方面因素的制约,如告警信息发布及时性,运维人员响应及时性,运维人员对系统熟悉程度等;一旦运维人员错过了告警,本来有很简单有效的运维操作没有被执行,就可能导致系统故障。

    自动化运维工具通过告警消息自动触发故障处理流程,主动高效地识别和解决故障,极大的提升运维对故障的响应速度和缩短故障时间。

    • 快速高效地识别、解决和消除服务中断的根源
    • 通过工具来查看、管理、诊断和解决问题
    • 整合运维团队积累的、厂商的专业工具和知识来加速事件和问题的诊断和解决
    • 自动进行故障问题定位并启用对应

    一键快速诊断定位性能问题:

    • I/O性能问题
    • 并发问题
    • 低效SQL或者高负载SQL
    • 对象争用
    • 锁阻塞或HANG

    运维管理人员可以通过自动化工具,根据告警触发或手工调度诊断流程,自动化工具自动进入诊断模块,首先自动判断系统所存在问题:如IO问题、并发堵塞问题、低效SQL或高负载SQL问题、hang等。自动化工具根据问题类型自动调度预定处理流程或方案(预定处理脚本集),最后返回诊断结果。

    3.自动可视化发布

    随着云化后机器数十倍的增长,传统“烟囱式”系统应用部署模式耗时耗力,并且手动发布出错的机率也非常大,我们尝试引入互联网自动配置部署工具SaltStack,并考虑到SaltStack无WEB配置界面的缺点,在其外面定制开发了一层WEB可视化界面,从而实现了云化系统下自动化可视化部署。

    1)自动化配置管理平台SaltStack整体架构

    SaltStack是一个服务器基础架构集中化配置管理平台,具备配置管理、远程执行、监控等功能,易于安装使用,便于扩展,可支撑管理上万台服务器或者虚拟机。依托云计算平台资源池实施部署了SaltStack管理平台。截至目前,SaltStack管理共计47套Linux系统,涵盖测试域36套系统以及生产域11套系统,并且还在不断的扩展。基于C/S架构,划分为主控端和被控端,分别称为Master和Minion。两者基于证书认证,安全可靠,其整体架构如下:

    2)SaltStack安装配置

    SaltStack可采用多种方式安装,通过源码安装,将SaltStackMaster部署在RHEL6.5主机,启动Master进程,并在全部受控机安装SaltStack,启动Minion进程。

    Master和Minion在通信时需要进行认证,因此需在/etc/salt/master中配置Master节点的IP地址,在/etc/salt/minion中指明Master端的地址以及本机的唯一标示。这样在Master端认证和统一配置时可以通过唯一标示进行。配置文件使用YAML$key:$value格式。

    3)SaltStack应用

    在我们的业务系统中,主要按照操作系统以及应用进行分组,具体分组方式如下:

    
    
    1. cat/etc/salt/master.d/nodegroup.conf  
    2. nodegroups:  
    3. redhatDatabase:‘redhat-db’  
    4. redhatAPP:‘redhat-app’  
    5. suseAPP:‘suse-app’  
    6. suseDatabase:‘suse-db’ 

    受控机器的信息展现是通过grain组件进行展现的,基本使用方法如下:

    salt'redhat-db1'grains.ls查看grains分类

    salt'redhat-db1'grains.items查看grains所有信息

    salt'redhat-db1'grains.itemosrelease查看grains某个信息

    4)可视化界面发布

    通过在SaltStack外部,定制开发WEB界面,使得整个发布部署过程和发布结果全部可视化,具体的应用步骤如下图所示:

    目前在多台服务器上实现了并行批量执行命令,根据不同业务特性进行配置集中化管理、分发文件、采集服务器数据、操作系统基础及软件包管理等。

    4、自动化数据管理

    云架构下的IT系统越来越多,数据库管理员需要面对成百上千的数据库,另外随着云架构下的大数据平台等技术的不断深入,数据存储将迈入EB级别,传统手工数据管理的难度越来越大。同时云架构中出于开发、测试、培训以及数据对外共享变现等环节需要从生产环境中同步和迁移大量数据,其中亦会涉及大量用户隐私数据。而之前整体IT系统数据流和业务流的关系不太清晰,业务数据可视化展示程度很低,缺少可视化的企业整体数据地图,对于数据的维护困难重重。

    1)云架构下数据管理规划

    为解决传统数据管理上的痛点,让数据管理相关工作更加标准化和流程化,我们借鉴国内外IT业界先进的数据管理和运营经验,着手在数据管理领域的自动化运营工具作出了规划。整体规划如下:

    在此规划的基础上,着手建设了在云架构下的数据安全管理以及数据生命周期管理两个主要运营场景的自动化工具化建设,其他还处在建设阶段。

    2)云架构下数据生命周期管理

    根据核心生产系统中数据的特点建立多层次数据存储体系,将用户访问频率较低的远期历史数据按规划从生产环境转移到历史数据中心和大数据平台中,在不影响绝大部分用户应用感知的情况下,有效管控系统整体数据增长,既降低系统运营成本,又满足最终用户的数据需求。我们的数据生命周期管理自动化工具,由数据管理员针对不同种类的数据梳理的数据生命周期策略进行可视化的管理,以自动化方式按不同周期识别历史数据并将历史数据完整地迁移到历史数据中心或其他大数据平台中。

    通过作业化自动化的思路,以自动化平台方式实现数据生命周期管理的全程,减少人力在策略管理、数据迁移和数据清理中的人工投入,主要目标在于:

    • 策略管理:在平台中对数据生命周期管理策略进行有效管理;策略定义包括数据生命周期定义,数据迁移策略定义,数据清理策略定义;定义数据生命周期作业,定时进行数据生命周期作业调度
    • 数据迁移:根据平台中的配置的数据生命周期策略定义,请理作业实施数据的自动化迁移,数据迁移过程无需人工干预,不同数据平台间数据迁移
    • 数据清理:数据重要程度,清理过程可以通过配置为自动执行和人工确认执行。根据平台中的配置的数据生命周期策略定义,作业实施数据的自动化清理

    3)云架构下数据安全管理

    根据生产系统中敏感数据分布情况,建立敏感数据策略化管理。在数据从生产环境中向未安全环境,包括开发、测试、培训和对外数据共享等,进行数据迁移和同步的过程中,因应数据安全管理员制定的敏感策略对数据进行自动化安全脱敏,减少敏感数据外泄的可能。

    目前数据安全自动化管理工具,实现从敏感数据识别,脱敏策略配置,数据迁移配置,以及数据在线和离线脱敏全程,自动化安全地将数据从生产环境向非安全环境迁移,同时在迁移过程中实施敏感数据脱敏。

    分析篇:利用大数据实时分析助力运维

    数据是金矿,随着云化的深入,价值数据之间分散到海量机器中,需要采用大数据技术进行集中化处理,并助力运维。我们公司进行了积极尝试,引入flume+kafka+spark+分布式内存库redis等开源技术自主进行大数据运维分析,取得了一定的效果。

    整体架构如下图所示。考虑到来自业务系统的数据是多元化的,既包括了软、硬件基础设施日志数据,也包括各类应用服务的日志数据,这两类日志数据通过主机和分布式软件代理服务、分布式消息采集服务和分析服务处理后,以流数据的方式转给大数据平台和报表平台:

    分布式数据(应用日志等)采集

    整个分布式采集分为如下四个部分:

    • 数据采集:负责从各个节点上实时采集日志数据,可以指定目录或文件,通过flume实现,仅增量采集数据。
    • 数据接入:由于上述采集数据的速度和数据处理的速度不一定同步,增加分布式消息曾作为缓冲,防止丢失数据,采用kafka。
    • 流式处理:对采集的数据进行实时分析,选用spark-streaming+redis实现。
    • 数据输出:对分析结果存储在mysql数据库中,并进行告警展示。

    以往,业务支撑网中的日志分布在各服务器上,每次检索要逐一登陆到各服务器操作,严重影响效率;同时,日志留存于操作系统本地,会受到存储空间限制而循环覆盖,导致重要数据丢失;由于对关键日志缺乏保护,也给监控、审计带来诸多困难。

    随着业务发展,来自硬件、操作系统和中间件的日志量不断膨胀,独立而分散的日志管理模式已不能满足日益增长的维护需求,特别在事件回溯、问题分析及报表统计相关工作中,其基础数据均源自这些纷繁芜杂的日志单元,亟需形成统一管理、综合分析、集中展现的新型一体化管理机制。为此一直进行着日志集中化改造的尝试。

    起初,以HTTP服务器日志统计为例,传统解决方式是定期(按5分钟、小时或天)截断日志,然后通过FTP上传到一台服务器统一处理,在有些日志的计算处理前需要考虑日志排序问题。这样的日志同步可以支持几台到几十台规模的并发服务,但当管理的服务器达到几十台,而有大量的服务器中间会有下线、上线或变更时,集中的日志定期同步更显得难于管理,且日志同步要避开白天的高峰,往往需要用凌晨的低峰时段同步,24小时下来,上G的日志同步也是风险很高的操作。而成为瓶颈的日志排序合并操作也会妨碍其他后续计算的周期。其逻辑架构如下所示。

    目前实现了应用分布但日志集中的远程存储模式,通过UDP协议实现小局域网内的日志广播,然后在多台汇聚服务器上实现各种日志的并发计算。如图所示:

    为保证日志流传输的可靠性,对整个传输链进行了改造,实现了多个特性:非阻塞的适配器、网络划分、负载均衡、传输高可用性、传输监控能力及可以动态调整的Push/Polling模式。

    无论是网络设备、应用服务器还是中间件,其日志需要与Flume节点对接,这就涉及到协议适配的问题,为此专门针对企业总线(eBus、UAP)、前端Web容器及交易中间件配置协议适配驱动,将日志以流的方式传输给Flume代理,协议适配层提供了较丰富的协议适配驱动,能够支持来自各层面基础设施的日志数据对接,目前已成功接入的基本组件有交换机、负载均衡器、各刀片服务器操作系统及应用程序,如图所示:

    当采用适配器连接Flume代理时,应用服务会调用异步附加组件AsyncAppender输出日志流,如果Flume代理宕机,且无备份节点时,会导致应用服务器阻塞,我们针对一些适配器配置了non-Blocking特性参数,当启用此参数时,即使日志流写入失败,不会影响正常业务运行。

    为确保基于UDP广播的传输模式不会形成网络风暴,我们按照不同的业务范畴、不同的组件类型划分子网,同一子网内的应用服务器仅与当前子网的Flume代理通信。在高可用性方面,应用服务器以UDP协议在子网内广播日志数据,UDP包被多个Flume代理节点截获,某一时刻仅有一个Flume Agent处于Active状态,其他为Standby,当Flume节点宕机时,其他节点可以无缝接替继续工作,所有Flume Agent通过Flume Master节点管理,实现主备接管和配置同步功能。如图所示:


    (灰色框为备机)

    为便于维护人员及时了解日志传输的工作状态,对Flume的相关命令进行了封装,在统一界面上展现来自Flume不同端口的数据接收情况。

    对于超大规模的营业厅前端用户交互日志采集,采用UDP、FTP方式可能会导致过高的网络、磁盘I/O资源消耗,因此首先保证整个架构过程中,除在汇聚服务器和日志中心外的Flume节点上均不产生文件落地,仅在汇聚服务器中实现了对来自多个Flume代理的数据聚合和排序。同时在业务高峰时段,日志采集处理能力有限,Flume代理会从Pushing模式切换为Pulling模式,即从采集转为采样。

    2、实时数据聚合+分组

    利用大数据集中处理平台的处理流程主要分两部分,通过消息队列处理Flume采集的日志,再通过ElasticSearch建立索引,最终将数据、索引导入在mysql集群。如下:

    大数据平台主要分析营业厅与用户交互日志,其中包括实时的用户体验、服务器请求记录。用户体验日志是用户在浏览器中每一步操作的性能评估,主要包括用户每一步操作的名称(如点击按钮、键盘录入、下拉框的选择、复选框的勾选及页面刷新等);用户操作整体响应时间及其构成部分:客户端响应时间(包括页面元素渲染时间、页面JavaScript脚本执行时间)、网络耗时(包括网络中的传输时延及第三方内容服务CDN的处理时间)、服务器运行时间。通过用户体验日志可以了解到用户每一步操作的感知状况,准确了解性能故障对用户操作的影响;此外,用户操作和用户请求是相互关联的,通过关联关系可以找到每一步用户操作的具体含义,如(某一步操作是在缴费业务的录入用户号码操作)。

    然后就是对用户操作业务聚合,即按时间顺序、用户操作的业务名称、用户号码等对用户真实的操作情景予以重建,这样做的好处是从整体上了解某一笔业务的操作繁琐程度(难易度、友好性);了解某一笔业务在哪一步较慢,是慢在网络层面、客户端层面、服务器层面还是用户自身原因(如间歇性停留)导致的;了解业务分布情况及成功率、转化率等。为确保业务聚合的并行计算高效,我们采取了spark流处理机制完成。目前主要应用了如下几个场景:

    场景1:以下图为例,通过大数据的数据聚合+分组手段,实现对用户行为的模式匹配,将多个操作归结到一笔业务中,实现用户体验不好根本原因是IT原因造成还是非IT因素造成(用户问题、营业员操作问题):

    场景2:结合大数据的分析,掌握用户的操作规律、操作习惯,并基于这些分析进行页面优化,如在合适位置投放广告,发布符合大众需求的产品与优惠:

    场景3:实现基于业务监控的入侵检测机制,我们基于集中日志分析,利用大数据技术实现基于业务聚合的CC攻击分析方法,将用户操作与浏览器请求建立关联,首先将URI请求按用户操作聚合,形成用户操作序列,再按照时间先后顺序及一定的业务规则将用户操作聚合为业务单元,通过对业务单元数据分析判断是否存在入侵检测。大大提高了针对仿真式DDos攻击的鉴别准确度。

    下图是近期发现的感染木马病毒的终端列表:

    3、深入性能诊断

    我们基于集中日志实时分析,可用于性能诊断等场景,并总结了一些宝贵经验:如网络故障关联分析和诊断、诊断企业总线调用外部域时发生的故障、基于接口报文的后端交易调优、针对RPC的性能分析等。

    1)网络故障诊断

    网络延迟故障一般可以从用户体验的网络耗时一项直接诊断定位,但有时很难一下子定位,也需要从用户请求中,如从HTTP服务器和WAS服务器的耗时份额对比中推导,亦可以从用户请求服务器代码路径中推导出来。

    从下图1看,某用户请求在IHS(HTTP服务器)上耗费的时间为14.69s,而端到端路径分析,在WAS(APP服务器)上的耗费时间为2.57ms,因此分析可知时间主要耗费在HTTP服务器上,而HTTP服务器主要作为一个代理与用户终端交互,因此分析得知有2种可能:在终端用户到HTTP服务器之间的链路上出现了网络故障,或HTTP服务器出现了性能问题,而经过监控发现其他业务运行均正常,HTTP服务器线程池使用正常,如图2所示,因此通过排除法得知网络故障可能性较大。

    图1 端到端路径分析

    图2 HTTP服务器的线程池使用情况

    另外通过服务器响应字节数进一步证实之前的推论,返回大小相比其他同类请求来说较大,如下图所示。

    2)基于接口报文进行的后端交易优化

    我们CRM交易处理程序基于C/C++实现,这导致交易中间件无法向基于JVM的前端Web服务一样实现运行时环境注入并动态改变监控行为,只能通过捕获应用程序触发的操作系统底层业务逻辑实现,这种情况下无法实现前端与后端的单笔交易关联。为解决此问题,首先对CICS应用服务进程启动多线程跟踪,将truss日志输出流重定向到UDP,发送给外部服务器,truss会跟踪到一些极基础的函数调用,使用truss跟踪的好处是,当和被跟踪进程依附和解除依附时,对被跟踪的进程不会造成影响,因此可以在生产环境中使用。此外,可以对CICS连接到Oracle的会话,在数据库中启动10046事件跟踪,跟踪数据库的调用轨迹,这种方式的好处是:填补了CICS跟踪的空白,实现了对业务的梳理;坏处是:只能小范围开启,需要在生产隔离出单独的一套中间件,并在此环境中回放报文处理过程。

    下图是通过启用数据库10046事件跟踪后,梳理出的合约机校验接口的业务逻辑(部分)。

    服务篇:建立面向云服务的运维架构

    目前我们的运维模式是基于ITIL的,从服务台、时间管理、变更管理、可用性管理、容量管理、CMDB等思路逐步建设整个系统,这种运维思路在传统架构下没问题,但在云计算下大规模运维的时候,越来越难以应对,或者说过多的聚焦于流程和规范的情况下,很难提升运维敏捷性和精细性。当前,IT支撑系统正在向资源池、SOA架构快速演进,系统支撑能力逐步具备了服务化的能力。通过对系统能力组件化和服务化,并配合系统弹性伸缩等能力,将支撑系统的能力以“服务”的形式提供,屏蔽内部过多的细节,可以实现“IT即服务的新型敏捷支撑与运维模式。

    为适应“IT即服务”的新型运维模式,尝试打破原有按照专业(主机、存储、数据库、中间件、网络……)和项目划分的组织架构,按照资源池运营管理模式进行架构重构,把运维工作划分为服务运营、资源运营两个核心维度,并以此为核心组织进行基础设施层面的构建和上层的管理运营,如下:

    经过上述调整,大大降低了之前各个专业之间协同难度以及不同专业间的专业壁垒,例如支撑一个项目,原来需要主机组提供主机资源、网络组提供网络、数据库组提供数据库等,现在提前建好资源池,资源池的运维人员通过云管理平台几乎可实现一切底层设施,每个人对各个专业门槛也大大降低了要求,适应了大规模环境下的运维要求。

    考虑到资源池初始阶段还有很多传统架构和云架构并存,且资源池需要提前建设,上述划分仅适应运营阶段需要,我们在运营团队中横向构建了跨专业的虚拟团队,作为项目小组,人员跨资源运营和服务运营的成员组成,例如扩容项目组、工程项目组、业务连续性项目组等,作为临时需要时的一个扁平化团队,如下图所示:

    通过上述组织架构调整,结合我们在资源池管理平台实现的IAAS和PAAS的自动管理功能,大大降低了运维难度,同时规避了繁琐的运维流程,初步实现了敏捷运维能力。同时根据测算,在人员配备上,如果按照传统运维架构,2000台服务器规模需要不同专业运维人员12人以上,而采用新的运维架构,只需3-4人即可。

    上述是在组织架构上适应云服务的运维,在技术上,我们公司积极推进企业级资源池、第三代CRM的IAAS和PAA融合架构建设,实现应用节点容量通过服务方式自动扩展,做到集中统一管控,深入运维提升核心掌控能力,目前本项目正在建设中,如下图所示:

    效果和后续计划

    通过近两年的持续探索,引入了较多的互联网开源运维工具,并经过定制化改造,目前已经初步搭建了面向云化架构下的系统运维架构。通过完善相应的监控、维护工具和数据分析,简化了系统运维难度,大大提升了系统维护效率;另外通过系统建设,运维人员接触到很多新的互联网化运维工具,人员自身的能力和工作积极性有了较大提升;而新工程项目建设时,。因为从各层级有了可视化操作工具,项目建设难度大大降低,减少了较多的项目协调工作,人员投入也从之前的8-9人变为2-3人承担。

    尽管目前引入了较多的云化运维工作,但目前各个工具还相对比较分散,未来我们计划对各个运维工具统一建设,能够集中到一个统一的操作平台上,各个工具也能够作为一个整体相互协调运作。





    作者:朱祥磊
    来源:51CTO
    展开全文
  • 腾讯云 高级云运维 TCP 20209月份真题

    千次阅读 2020-10-18 09:44:59
    腾讯云云运维TCP训练题集 一、选择题 您在本地有3台物理服务器,由于担心物理机的安全性和可靠性,所以希望能把物理机上的业务整体上云,但是您又不太懂物理机上的业务,无法重新在上部署,此时您应该使用以下哪...
  • 导语 | 腾讯云网络作为的基础设施,其质量和稳定性直接影响了的运营质量和用户口碑。同时客户对基础设施依赖度高,故障容忍度低,云网络产品迭代更新快,决定了我们需要对云网络质量有更高的要...
  • 自2016年11月发布以来,国美通过“成熟的架构经验+过硬的产品+贴身的运维”,在客户中获得了良好的口碑。今天我把自己在做运维自动化中总结的一些经验分享给大家。一、 自动化理念这几年从SA到DevOps,有幸...
  • 而十年后在运维方面已经产生了翻天覆地的变化,本文系统地总结了 UPYUN 的云运维的野蛮成长、踩过的坑以及现阶段的状况。运维的艺术运维的艺术是弹性。首先,从无到有,这非常重要。无论运维做得多厉害...
  • 有人说在云计算工程领域,最难的部分是运维,因为管100台、1万台或是100万台机器,是完全不同的概念,你想机器少可以人管,机器多了还能靠...但这里说的机房运维只是云计算运维的一个部分,事实上,随着平台被越来越
  • IT监控与运维管理是用户保障业务系统正常稳定运行的必要手段,是用户业务系统的支撑工具。随着IT建设的不断深入和完善,计算机硬软件系统的运行维护已经成为了各行各业各单位领导和信息服务部门普遍关注和不堪重负的...
  • 作者丨周小军,腾讯SNG资深运维工程师,负责社交产品分布式存储的运维及团队管理工作。对互联网网站架构、数据中心、云计算及自动化运维等领域有深入研究和理解。 12月16日,首期沙龙“海量运维实践大曝光”在腾讯...
  • 作者丨魏旸:腾讯高级工程师,具有15年运维经验的专家。负责QQ空间、微云、QQ空间相册等的运维工作。 12月16日,首期沙龙“海量运维实践大曝光”在腾讯大厦圆满举行。沙龙出品人腾讯运维技术总监、复旦大学客座讲师...
  • Hyper容器运维
  • 在标准化实施完以后,由于数目的增加,或者是一些运维场景的增多,我们会逐步的进行一些工具化和自动化,这个阶段我们的运维的效率得到提升。 但是众多的工具以及自动化脚本,会让我们的管理过程中比较困难,随着...
  • 与传统运维不同,运维人员完全接触不到物理设备,感知不到底层基础设施的细节,取而代之的是服务器、云盘、VPC 网络等已经封装好的产品形态。上云已是趋势,但如何基于上的产品形态和原生的能力做好自动化...
  • 网络运维调查报告

    2017-09-04 11:19:00
    网络运维调查报告 我未来就业地址大概在北京,大概岗位...2、精通Internet网络结构、协议及应用原理,深刻理解互联网架构和IDC及主机的网络模式;3、熟悉国内各宽带运营商的情况,熟悉互联网的IP地...
  • 摘要: 上文我们提到,运维向更自动、更敏捷、更弹性的趋势演进,但本质始终是赋能业务永续运行,助力企业战略目标和业务发展的实现。今天,我们来聊一聊如何在阿里上建立主动的运维体系。为何强调“主动...
  • 阿里RAM运维最佳实践 作者:华正 瑞理1 阿里RAM介绍 访问控制(Resource Access Management,简称RAM)是一个稳定可靠的集中式访问控制服务。您可以通过访问控制将阿里资源的访问及管理权限分配给您的企业...
  • 关于开发运维、云计算标准的一些思考 云计算目前仍然是IT领域里最热门的名词之一,在各种技术论坛或者研讨会上,都能听到大家在讨论,参与对象包括硬件厂商、软件厂商、大型企业用户。不同于以往只是大谈的...
  • 在政策红利与数字化需求推动下,5G、人工智能、物联网、区块链等为代表的新技术在各行业领域广泛应用,大量业务通过上云等手段加速数字化,带来的网络安全风险也急剧上升。 与此同时,伴随产业数字化逐步深入,...
  • 网络运维词汇汇总

    千次阅读 2014-09-06 09:12:54
    RDS与服务器搭配使用I/O性能倍增,内网互通避免网络瓶颈。   2、开放存储服务 OSS:  开放存储服务(OpenStorage Service,简称OSS)是支持任意数据类型的存储服务,支持任意时间、地点的数据上传和...
  • 运维

    2018-11-27 20:06:00
    传统运维是指企业网络软硬件的维护,也就是IT运维管理,通过IT部门相关的方法、手段、技术、制度、流程和文档,对软硬件、网络等环境、IT业务系统和IT运维人员进行的综合管理。 如今,各行各业都在进行数字化变革,...
  • 上文我们提到,运维向更自动、更敏捷、更弹性的趋势演进,但本质始终是赋能业务永续运行,助力企业战略目标和业务发展的实现。今天,我们来聊一聊如何在阿里上建立主动的运维体系。 为何强调“主动”?做...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,529
精华内容 5,411
关键字:

网络云运维手段