《大数据系统运维》课件 第3章 故障管理.pdf

大数据系统运维大数据应用人才培养系列教材第三章故障管理3.1集群结构32故障报告303故障处理3也故障后期管理习题3.1集群结构第三章故障管理CDH(Cloudera Distribution Hadoop)版的HADOOP集群介绍集群结构I ETL Tools I Bl Tools I Visualization Tools I Data Analytics Toolsser PPcations informatica I IBM,SAP,Oracle,SAS I Tableau,Zoomdata I QxPata,Revolution RConnectors I JDBC/ODBC I Java API I Python I Rest API I ThriftF-umeKafkaImpalaSearchPig I Hive I SparkSQL MJJJb I GraphX I Oozie|PhoenixSpark/Spark StreamingFs D HCloudera Directorcoudera c-oudera Navigator xp-a-n.-o coudera ManagerZookeeperHserl-ryLegacy Systems(RDBMS/DW,Data Mart,Archive,ESB,Log Data),Sensors,Internet3.1集群结构第三章故障管理CDH功能模块系统部署和管理数据存储安全、数据管理资源管理工具库3.1集群结构第三章故障管理集群的结构组成模块组件名称系统部署和管理Cloudera Manager Cloudera Director数据存储HDFSHBase资源管理YARN处理引擎Spark Impala Search安全、数据管理Cloudera Navigator工具款Hive3.1集群结构第三章故障管理硬件配置组成1U 或 2U硬件名称管理节点工作节点处理器两路Intel至强处理器，可选用E5-2630处理器两路Intel至强处理器，可选用E5-2660处理器rih上粕 6核/CPU（或者可选用8核/CPU），主频2.3GHz或以6核/CPU（或者可选用8核/CPU），主频内核数 上 2.0GHz或以上内存64GB ECC DDR364GB ECC DDR3硬盘 2个2TB的SAS硬盘（3.5寸）,7200RPM.RAID1康篮B白篇篇广力网络至少两个lGbE以太网电口，推荐使用光口提高性能。可以两个网口链路聚合提供更高带宽。至少两个lGbE以太网电口，推荐使用光 口提高性能。可以两个网口链路聚合提供更高带宽。硬件尺寸 1U或2U接入交换机 48口千兆交换机，要求全千兆，可堆叠聚合交换机（可选）4口SFP+万兆光纤核心交换机，一般用于50节点以上大规模集群大数据应用人才培养系列教材第三章故障管理3.1 集群结构3.2 故障报告故障处理3.4 故障后期管理 习题3.2故障报告第三章故障管理 在故障发现之后，需要精确描述，包括如何发现的故障（如果是用户，用户的联系方发现 式要保留，便于后期回访）故障发生的时间点，故障的现象，故障暂时的影响等，只有把这些描述清楚了，才有可能在后续的流程中提升效率，一个典型的故障记录单如 下表所示：分类记录单号20170511000328状态已指派等待代码等待管理员接单记录人员张三分析员李四报告时间2017-05-11 11:18:20客户王五客户组织业务一部客户电话XXX客户邮箱XXXVIP属性VIP故障来源用户报告摘要大数据分析系统X无法登录今天10:00,李四使用Chrome浏览器访问X系统时，在输入用户名和详细信息密码之后，页面出现错误信息服务器内部故障308,请联系管理员，截图如附件所示故障分类大数据分析系统/X系统/用户登录故障故障级别低 3.2故障报告第三章故障管理影响分析在运维部门，一般会有一二三线的人员划分：一线人员指的是客服人员或者监控值班人员，负责处 理日常性的用户询问和故障处理；二线人员指的是专业的系统管理员，如网络管理员，服务器管理 员,应用管理员等，当一线人员处理不了故障，会有二线的管理员跟进；三线指的是系统开发人员,产品供应商，当是比较深层的故障，例如是软件开发的问题，操作系统缺陷或者深层故障，会交给 三线人员处理。类别识别标准处理方法致命核心系统整体功能或者核心功能失 效；立即上报部门或者组织管理层；协调所有相关资源参与处置；高核心系统的非核心功能失效；非核心系统的整体功能失效；协调二线立即参与处置；中非核心系统的部分功能失效；协调二线参与处置；低个别用户反馈无法使用；尚未导致功能受影响的故障；一线参与处置和进一步分析；微小不对可用性造成影响，暂时不处理 也没关系记录；大数据应用人才培养系列教材第三章故障管理3 J集群结构3.2 故障报告3.3 故障处理3.4 故障后期管理 习题3.3故障处理第三章故障管理故障诊断参考大数据系统的系统架构，从故障发生的位置来看，可以分为：应用层故障，系统层故障，网络 层故障，硬件层故障，机房环境故障，客户端故障等。从故障的原因出发，在运维过程中的的常见 故障主要有：故障原因描述人为操作失误由于人为操作失误造成的故障，例如误删了系统重要 文件；性能容量问题H由于访问量增加，运行时间的累积，JVM HEAP空间，磁盘空间，线程数，网络连接数，打开文件数等超限；.软件缺陷H软件在开发过程中遗留的缺陷，常常在升级变更之后 发生，所以也有变更是故障之母的说法；硬件故障服务器零件故障，当集群中的服务器达到一定规模 时，硬件故障难免发生；兼容性问题由于应用，服务器，网络等配置参数的冲突，放在一 个环境运行时，产生了问题，例如杀毒软件影响了应 用的运行，备份任务干扰了网络流量，防火墙阻断了 应用的长连接等；3.3故障处理第三章故障管理故障诊断，故障的完整描述如前文3.3.1所述，准确的故障描述至关重要，能帮助管理员把故障的范围缩小，对故障的发生源有个预判定 位，避免在大范围内浪费资源。通过故障的完整描述，应该能核实以下信息，该问题的具体报错码，具体报 错时间，是不是首次发生等。如果信息比较模糊，还需要反复确认。2、监控信息，dump文件，日志等现场快照故障发生时的现场信息是排查故障的关键，如同车祸现场的视频记录一样，日志，监控信息，dump文件，网路抓包情况是故障现场的记录数据。一些没有经验的开发者往往由于开发的应用输出的日志太少，在生产 环境出现问题时，没有任何记录，排查故障时也毫无头绪。大多数故障都可以通过日志发现端倪，一些复杂 的故障要依靠多种手段才能定位原因。如果当时无法定位原因，则需要考虑通过降低日志输出的级别，在关 键位置增加日志，部署一些详细监控的策略，等待故障再次发生时，能够捕获更多的信息。3、文档，经验和知识通过现场快照发现了错误的具体信息后，还要结合系统本身的文档，知识库或者管理员的经验，进行进一步 分析。例如已经发现了服务器应用输出的日志有明显的错误信息，显示网络连接失败。可能该问题过去已经 发生过，是由于访问量上升时，服务端无法再创建新的连接造成的。如果该经验没有记录到文档或者知识库 中，而人员又不是当时处理故障的人员，则还需要花费资源进行诊断。一般的大型组织，都会建立自己的知 识库或者文档库，各种开源软件也会有相应的文档或者论坛在互联网上开放，可以通过搜索引擎检索到软件 相关的问题记录和解决情况。3.3故障处理第三章故障管理故障排除故障排除通常有两种做法，变通解决和根本解决。变通解决指的是，当故障造成了系统不可用，恢复服务 是第一要务，如同医生抢救病人一样，先救活再说。根本解决指的是找到的故障的深层原因，在源头上予 以解决。例如，应用程序的缺陷造成了程序运行了一段时间会崩溃退出，此时先将程序重新启动恢复服务,重启动作就是变通解决，等找到了程序的缺陷，通过升级变更予以消除，这就是根本解决。排除方法适应场景重启服务软件或者硬件不明原因的故障，通过重启相关模块来恢复服务，但要注意的是，复杂系统尤其是 分布式系统包含多台服务器，多个应用模块，按照怎样的顺序重启，重启哪些模块也都是需要注 意的点；性能调度当访问量激增的时候，系统会出现卡顿，一些模块可能会由于资源耗尽而无法再服务，可以通过 扩充系统性能，如果系统是部署在云上，可以通过云管理平价动态地增加cpu,内存，甚至整个服 务器等来解决性能问题；修补数据当故障造成了数据错误，丢失，重复的情况，故障的处理就会变的异常麻烦，如果数据特别重要 一定需要修复，则需要安排资源对数据进行逐笔核对，识别出错误的地方，这个工作量通常非常 大；升级变更如果是硬件故障，通过升级变更更换硬件；如果是软件问题，通过升级变更修复缺陷；隔离，重置等其他应急操作当系统存在冗余的模块，为了避免流量仍然导向到故障模块，则可以彻底手工隔离故障模块；一 些系统可能由于自身结构原因，会有一些常发性故障，例如用户登录状态错误，则可以将重置用 户登录状态做成一个功能，方便在排除故障的时候使用；自动化在有了一定故障处理经验和原则之后，对于固定场景的故障，可以考虑开发成自动处理，在捕获到异常之后，由系统管理模块对故障进程自动隔离，自动重启，自动重置，自动扩容等；大数据应用人才培养系列教材第三章故障管理3 J集群结构3生故障报告3.3 故障处理_3.4 故障后期管理习题3.4故障后期管理第三章故障管理建立和更新知识库关于企业知识库的建立，是因为运维工作所需的大量知识分散保存在文档管理系统或者 个人电脑中，需要时查找不便，找到又发现版本不统一，甚至陈旧过时。通过建设知 识管理系统，对大量有价值的案例、规范、手册、经验等知识进行分类存储和管理，积 累知识资产避免流失；规范知识的存储、分类，实现便捷高效的查询；通过记录并分析 使用者的知识行为，促进知识的学习、共享、利用和传承；并与现有的管理系统、流程 系统进行衔接，实现不同系统间知识的整合。而对于故障处理的经验，除了故障处理流 程记录之外，也可以针对一些典型故障，创建或者更新知识库，便于以后重复利用，减 少排查故障时的工作量。3.4故障后期管理第三章故障管理故障预防1、首先任何生产过程都要进行程序化，这样使整个生产过程都可以进行考量，这是发 现事故征兆的前提。2、对每一个程序都要划分相应的责任，可以找到相应的负责人，要让他们认识到安全 生产的重要性，以及安全事故带来的巨大危害性。3、根据生产程序的可能性，列出每一个程序可能发生的事故，以及发生事故的先兆，培养员工对事故先兆的敏感性。4、在每一个程序上都要制定定期的检查制度，及早发现事故的征兆。5、在任何程序上一旦发现生产安全事故的隐患，要及时的报告，要及时的排除。6、在生产过程中，即使有一些小事故发生，可能是避免不了或者经常发生，也应引起 足够的重视，要及时排除。当事人即使不能排除，也应该向安全负责人报告，以便找出 这些小事故的隐患，及时排除，避免安全事故的发生。习题:1 从故障的原因出发，故障可以分为哪些种类？2.当发生故障时，需要记录哪些相关信息？3.运维的一线，二线，三线人员的工作职责如何划分？感谢聆听