1.3 大数据计算系统的监控与运维概述

1.3.1 概述

随着各行各业的发展，大数据计算系统的规模快速膨胀，由此带来的硬件产品寿命问题、不同产品之间的兼容问题、软件系统升级问题等都需要通过系统运维来解决。同时，系统运维涉及诸多方面，从网络硬件设备到网络监控，从各类硬件驱动到内核参数调优，从服务巡检到异常处理，无一不需要系统运维的支持。

从大数据计算系统的工作特点来说，系统每分钟处理的数据量巨大，宕机一分钟造成的损失也十分巨大。与此同时，系统运维又具有不确定性与长期性，因此忽视运维可能导致灾难性的后果。一旦系统出现瘫痪等严重问题，如果不通过科学合理的运维手段解决，而是盲目添置硬件设备，不仅不能从根本上解决问题，还会增加解决问题带来的成本。因此，运维工作是大数据计算系统的重要组成部分。

在对大数据计算系统实施运维之前，有必要了解系统实时运行的情况，否则运维就是盲目的。只有在实现系统监控，掌握系统的重要组件、集群运行负载上限及工作任务特点等系统常规和工作环境的特征指标之后，对系统的运维才是有目的和有效的。监控是整个运维乃至整个产品生命周期中重要的一环，可以在事前及时发现故障并预警，事后提供详实的数据用于追查、定位问题。每个系统的实际工作环境不同，侧重的监控方向也不同，但系统监控一般应当遵循以下4个原则：

1）应对系统不间断地进行实时监控。

2）监控应实时反馈系统当前的状态，即监控某个硬件或者某个系统的当前状态，判断系统状态是正常、异常还是故障的。

3）监控的目的是保证系统、服务安全可靠。

4）当出现故障时，应第一时间接收到故障报警并及时解决故障，从而保证业务持续、稳定地运行。

监控的核心在于发现问题和定位问题。当一个已经实施了监控的大数据计算系统在运行中发生故障时，应当及时进行故障报警，将报警信息反馈给用户，同时报警信息应当将故障原因定位到较小的范围内，如报告某台主机故障及故障的内容，以帮助系统运维人员尽快发现并解决故障。

综上所述，大数据计算系统的监控与运维是不可分割的有机整体，监控为系统的运维提供数据基础，运维提升了系统监控的价值。大数据计算系统的监控和运维应结合具体的系统需求和工作场景。系统的监控常常从系统的硬件展开，兼顾大数据系统的网络环境、配置环境、计算框架、上层服务等诸多层次。运维则从大数据计算系统的基础服务传输系统、计算调度及存储系统层面考虑。运维系统中的批量作业平台要解决运维中高频的批处理任务，确保系统的稳定性和可靠性，尽量引入原生支持的组件，减少开发的工作量。

1.3.2 监控与运维的范围

大数据计算系统的监控应从多角度、多层次来实现。首先，应该掌握系统的基础环境，如硬件设备、网络、集群规模、系统配置等方面的基础信息和系统中计算框架的状态。在实施监控时，系统的硬件资源、HDFS、上层服务、Hadoop守护进程相关指标等都应该纳入考虑的范围。

确定监控的角度后，系统的运维范围和方向就可以逐步确定。大数据计算系统最基础的运维是用户的身份确认和Hadoop及相关服务的启动与停止。常规的运维包括Hadoop的单点备份及恢复处理、DataNode的维护、系统中数据的备份、容灾处理、数据迁移等。

当然，大数据计算系统的运维包括但不限于上述内容，用户可以根据系统的实际情况使系统的运维覆盖资源分配、服务巡检、网络监控、负载均衡等多个方面。

1.3.3 大数据计算系统的监控与运维方法

在阐述了监控与运维的重要性和范围之后，接下来介绍如何实现大数据计算系统的监控和运维。

首先，对于监控来说，涉及4个层面的工作。

1）全方位了解监控对象的工作流程、工作原理和工作特点，以及监控对象在整个系统中的作用和监控的意义等。

2）确定性能基准指标。在监控时，需要考虑应该监控对象的哪些属性，如CPU的使用率、负载、用户态、内核态、上下文切换、内存使用率、Swap使用率、内存缓存、网络接发字节数、接发数据报数等。

3）报警阈值的定义。确定指标属性值的报警临界点、紧急处理临界点，如CPU的负载、用户态、内核态、内存使用率的用户预警临界点等。

4）故障处理方式及流程。应当确定遇到故障或者预警时的处理方法、用户处理流程，以及采用自动化运维的处理流程等。

运维涉及5个层面的工作。

1）全局驱动。无论是全部自动化管理平台的规划，还是某个平台的规划，都应该找到一个全局的立足点。比如，持续部署服务平台时，全局的目标应放在提高产品交付的速度和质量上，这样开发、测试、运维可以很快确定一致的目标。当平台建设完成后，运维从发布变更流程中彻底退出，真正实现让运维者变成审核者。

2）分而治之。当从多个维度审视系统时，可以看到需要建设许多系统，但是建设的周期长、难度大，所以需要分而治之。特别是线上架构组件的管理系统，更需要随着组件的交付一并交付运维管理能力，如面向组件的自动化管理能力、运维的监控能力、运维的数据分析能力等。分而治之就是让不同的团队做不同的事，对不同的系统功能采用不同的运维技术和手段。

3）自底向上。应该找到一个更清晰、更具体的系统建设目标来开展工作，进行系统分解时，应避免被一个庞大而模糊的目标带入歧途，要先设定全局和最终目标，然后从底层逐步构建。

4）边界清晰。这里主要指的是职能边界，即深层次地理解各部分的功能范围。例如，让DNS跨过LVS层，负责后端服务异常时的自动容错处理是不合适的。如果不把职能界定清楚，将会导致系统做很多无用功，从而增加运维系统建设的复杂度。

5）插件化。插件化的思维无处不在。对纷繁复杂的管理对象进行抽象，提供管理模式，然后将具体的实现交给用户，这是运维系统常见的做法。例如，Nagios就采用了一种插件化的思路；对于配置管理来说，Puppet采用的也是这个思路。对于最上层的调度管理系统，可以让运维人员自行编写执行器（特别是和业务紧密相关的），但最终运维的控制权还是要交给系统和平台。

1.3.4 大数据计算系统的运维目标

大数据计算系统运维的目标包括质量、成本、效率和安全。

1）质量。美国著名的质量管理专家朱兰（J.M.Juran）博士从顾客的角度出发，提出了产品（服务）质量就是产品（服务）适用性的理论，即产品（服务）在使用时能满足用户需要的程度。对于大数据计算系统来说，系统的质量主要是指在交付后，用户对系统运算结果的满意程度。对于满意程度的衡量应该从结果的应用效果等多个维度考量。

2）成本。运维不是直接产生效益的部分，但是可以通过控制运维成本来产生效益。在海量服务的情况下，带宽、人力、计算资源都非常昂贵，成本的精细化控制给大数据计算系统运维技术和管理提出了考验。从服务器的角度来说，我们可以把服务器四大资源（CPU、内存、I/O、网络I/O）的利用率作为服务资源使用率的参考，一定要避免使用操作系统的负载来衡量服务器的利用率。应设定一个合理的使用率作为阈值，强制要求计算任务的使用率不能低于这个阈值，鼓励计算任务更充分地利用资源。如果服务器资源利用率达到50%，一旦业务压力突增，很可能会影响计算性能，因此对运维技术的要求就是能实时地扩容和调度，这是对运维自动化能力的挑战。

3）效率。从运维效率能够看出运维平台化的能力。从场景的角度，可以分解出很多对运维效率的要求，如出现故障后发现问题的效率、故障定位的效率、发布效率、DNS/LVS/网络/业务变更效率、资源交付效率等，最终检验运维效率的核心指标就是面向业务的整体调度和整体交付的能力。

4）安全。安全是大数据计算系统的生命线，应尽早建立安全机制和规范，以及全面的安全体系，从系统级别、数据级别、应用级别等维度对待安全问题。对数据的安全保护更是重中之重。数据要建立分级体系，不同级别的数据要有不同的管理策略和使用策略，这些策略包含访问密码加密、访问日志的脱敏、数据隔离访问、数据加密、数据的备份、数据的加密获取等。

第12章和第13章将具体介绍大数据计算系统的监控和运维。