工欲善事情，必先利其器，生产环境中的服务器在处理请求并生成回应数据的时间主要消耗在服务器端，包括了众多的环节，如何全面了解我们linux服务器的CPU使用率、使用时间、内存占用比例、磁盘IO数据、网络相关数据等等众多指标，保证我们的linux服务器顺利完成每一个请求，怎能没有几个趁手的利刃，而今天就让我们见识一下系统管理中三大利刃。

一、七星绝命剑 [top]

相传一把三尺长的软剑，叫七星绝命剑，剑刃上嵌着七颗星状的暗器，一剑刺出，使剑人的内力劲透剑身之时，那七颗星状的暗器便飞脱疾出，出其不意地取人性命，（见古龙《吸血娥》）。而htop便是我们今天所讲的第一把利刃，和上面传说中的七星绝命剑类似，有着七个最常用命令，让我们先来看一下htop的真面目：

从上图可以看出，相较于CentOS发行版上系统自带的top工具，htop工具无论是信息内容丰富程度，还是在用户界面的友好度上，都有着无可比拟的优势，而且htop工具支持交互式命令，下面让我们来认识一下htop工具常见的七个交互式命令。

[]u ：具有过滤功能，能显示用户指定用户的进程[/][]s ：选定某个进程后，使用该命令可以跟踪该进程所发起的系统调用[/][]l ：选定某个进程后，使用该命令可以显示该经常打开的文件有那些[/][]t ：直接使用该命令可以显示进程的层级机构[/][]a ：使用该命令可以设定某个进程的cpu亲缘性[/][]k ：使用该命令可以结束某个指定进程[/][]h ：该工具还有众多功能，使用该命令可以获取该工具其他帮助信息[/]

以上七个命令就是htop工具最常用的命令，掌握好这七个命令就好比拥有了七星绝命剑的七颗星状暗器，杀人于无形，旨在一瞬间，但是如何把握这七个形状暗器的力度和功用，需要我们对htop有着更深入的理解，接下来我们详细介绍htop的众多输出信息的详解

[]CPU usage bar：该行主要显示CPU使用情况，而且不光这些，htop还为将不同颜色来区分是使用情况，蓝色的表示low-prority使用，绿色的表示normal使用情况，红色的表示kernel使用情况，青色的表示vistualiz使用情况。[/][]Memory bar：该行主要表示内存使用情况，同样的htop使用了不同颜色来区分是使用情况，绿色的表示已经使用内存情况，蓝色的表示用于缓冲的内存使用情况，黄色的表示用于缓存的内存使用情况。[/][]Swap bar：该行主要显示交换分区使用情况，当你发现你的交换分区已经派上用场的时候，说明你的物理内存已经不足，需要考虑增加内存了。[/][]PID：表示进程号[/][]USER：发起该进程的用户名[/][]PRI：进程优先级[/][]NI：nice值[/][]VIRT：进程需要的虚拟内存[/][]RES：常驻内存，也就是物理内存[/][]SHR：共享内存[/][]S：进程的运行状况：R表示正在运行，S表示休眠，Z表示僵死状态[/][]CPU%：占用的CPU使用率[/][]MEM%：物理内存使用率[/][]TIME%：占用CPU的累计时长[/][]Command：进程启动的启动命令名称即路径[/]

有了以上的详解，我想htop这把利刃将会发挥最大的用处 二、君子淑女剑 [glances ]

相传君子剑剑身乌黑，没半点光泽，就似一段黑木一般，和平常的宝剑不同，这剑既无尖头，又无剑锋，圆头钝边，倒有些似一条薄薄的木鞭，但寒气逼人，而且锋锐异常。此剑与淑女剑一模一样，大小长短，全无二致，双剑的材料完全相同，都具有极强的磁性，如果放的距离较近，双剑会自动吸在一起此剑后落到少年杨过手中，与小龙女手里的淑女剑联剑出击，以玉女素心剑法威震天下，（见《神雕侠侣》）。而glances就是我们要说的第二把利刃，与相传的君子剑有相似之处，glances支持客户端/服务器模式，远程模式使用将会有奇效，接下来我们认识这把君子淑女剑吧。

glances并不是CentOS发行版默认安装的工具，需要在epel源里面安装使用，首先让我们先来认识一下glances吧，如下图：

glances工具支持的选项众多，我们先来认识一下glances的常用选项：

[]b ：以byte/s为单位显示网卡设备[/][]d ：禁用或者关闭显示磁盘IO功能模块[/][]f ：通常和-o一起使用设置输出文件位置即格式[/][]o ：指明输出的格式，通常为｛CSV|HTML｝[/][]m ：关闭mount功能模块[/][]n ：关闭网络功能模块[/][]t ：指明刷新时长，默认为3秒[/][]1 ：单独显示每颗CPU相关的负载数据信息[/]

以上就是glances工具常用选项，同时glances工具还支持在工作界面下直接按相对应的选项就可以关闭或者设置相关功能的，上面曾说过glances工具支持C/S模式，那它是如何在C/S模式下工作的那？ 首先：server端以监听模式启动glances；其次：client端以远程模式启动glances远程连入指定服务器，并获取server上相关的性能数据。

服务端命令：glances -s -B IPADDRESS（指定用于监听的本地地址）客户端命令：glances -c IPADDRESS（指明连入的服务器地址）

glances所显示的丰富信息包括了系统运行的众多模块，包括了cpu相关模块，多核情况下每个核心的负载情况，内存使用模块，交换分去使用情况，网络使用状况，磁盘IO使用情况，以及各分区挂载情况，我相信通过了解以上系统运行期间的状况，一定能判断出当前系统运行是所出现的问题，帮助我们找出问题所在。

三、绝世好剑 [dstat]

相传当初傲日并非打算铸造「绝世好剑」，而是要铸造「败亡之剑」，可惜「败亡」的铸造过程太过邪异，每次铸剑，均会造成人命伤亡，故此傲家中人弃「败亡」而改铸「绝世」。铸剑的最后步骤是以三毒之血「贪」（剑贪之血），「瞋」（步惊云之血），「痴」（断浪之血）炼制。但所铸成的只是威力神髓所在的真元，而真正的剑体已藏于千万铸好的绝世好剑中，绝世好剑本身有吸摄天地灵气之能，同样也可吸收别人功力转为己用。位列当世十大神兵之一，见《风云》。而我们今天所说的第三把系统管理的兵刃，于绝世好剑有过之而不及，绝世好剑需要集三毒之血（剑贪之血）、（步惊云之血）、（断浪之血）炼制而成，而dstat整合了vmstat、iostat、netstat、ifstat四款工具的功能于一身，功能无比强大，首先来看看这个利刃的庐山真面目，如下图：

通过上图可以更直观的看出系统各功能模块的使用状况，而且dstat是CentOS默认提供的一款工具，并且使用起来十分的灵活，可以通过不同的组合来显示出我们需要的功能模块，下面来认识一下dstat这款工具的主要选项有那些：

[]c ：显示CPU相关的统计数据[/][]d ：显示磁盘相关的统计数据[/][]g ：显示Page相关的速率数据[/][]i ：显示中断相关的统计数据[/][]l ：显示load average相关的统计信息[/][]m：显示内存相关的统计信息[/][]n ：显示网络相关的统计数据速率信息[/][]N ：指定接口[/][]p ：显示进程相关的统计数据[/][]r ：显示IO请求的速率[/][]s ：显示swap交换分区的相关数据[/][]y ：显示系统相关的数据包括中断和进程间切换等相关信息[/][]top-cpu：显示最占用CPU的进程[/][]top-bio：显示最消耗块级别IO的进程[/][]top-time：显示最占用CPU时长的进程[/][]top-io：显示最占用io的进程[/][]top-mem：显示最占用内存的进程[/][]ipc：显示进程间通信相关的速率数据[/][]tcp：显示tcp套接字相关的数据[/][]udp：显示udp套接字的相关数据[/][]raw：显示raw套接字相关数据[/][]unix：显示unix sock接口相关的统计数据[/][]a ：相当于-cdngy[/]

以上就是dstat工具的常用选项，之所以说该使用该工具十分领过是因为它即可以加上众多的参数来显示系统运行时丰富的各个功能模块的状态信息，如下图：

同时又可以根据自己的需要来单独显示某一个功能模块的信息或者显示当前系统最占用CPU的进程，如下图：

有人的地方就有江湖，运维的你的趁手武器是什么？

以上就是系统管理中的三把利刃，只要精通任何一个工具，都有助于我们更加深入的了解我们系统运行过程中的问题和不足，及时的发行并解决这些问题，但同时我们也应该认识到，所谓的这些工具都是通过整合或分析/proc/这个伪文件系统，为什么说它是伪文件系统那，因为它只存在内存当中而不占用外存空间，它是以文件系统的方式访问系统内核数据的操作提供接口，要想使用好以上三个工具，还需要更深入的理解系统是究竟怎么运行起来的，以及系统运行的原理是什么，当我们真的理解了这些，我想那个时候就是我们自己制作工具开始，正所谓真正的高手也都是制作工具的高手，就如同江湖里说的最好的境界乃是无剑胜有剑，摘叶飞花皆可伤人。

谈到运维，监控应该是运维的重中之重。怎么说呢？有很多人说这个监控应该是运维的第三只眼睛，一个好的监控平台对我们这个工作本身来说，应该有很大的帮助。那么，如何要构建一个完善的监控平台。那就是我们今天要讨论的话题：

以我的理解来说这个运维的核心工作其实是监控和故障处理。两个方面的工作首先是对这个业务系统我们要有一个精确的完善的监控。那么他的目的就是能够保证在第一时间去发现问题并且去通知相关人员解决问题。其实出现问题了并不可怕，可怕的是我们很久没有发现问题，那么最终被客户发现我们的业务系统出现故障，那么就是个很严重的问题了，这些都是靠业务系统监控平台来完成的。

提纲介绍：

1、统一监控报警平台设计思路
2、Ganglia作为数据收集模块
3、Centreon作为监控报警模块
4、Ganglia与Centreon的无缝整合
5、统计监控系统架构图
6、数据流向图

第一：统一监控报警平台设计思路

构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等纳入统一的运维监控平台中，并通过消除管理软件的差别，数据采集手段的差别，对各种不同的数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。

智能的运维监控平台，设计架构从低到高可以分为6层，三大模块，如图1所示：

数据收集层：位于最底层，主要收集网络数据、业务系统数据、数据库数据、操作系统数据等，然后将收集到的数据进行规范化，并进行存储。

数据展示层：位于第二层，是一个web展示界面，主要是将数据收集层获取到的数据进行统一展示，展示的方式可以是曲线图、柱状图、饼状态等，通过将数据图形化，可以帮助运维人员了解一段时间内主机或网络的运行状态和运行趋势，并作为运维人员排查问题或解决问题的依据。

数据提取层：位于第三层，主要是将数据收集层获取到的数据进行规格化和过滤处理，提取需要的数据到监控报警模块，这个部分是监控和报警两个模块的衔接点。

报警规则配置层：位于第四层，主要是根据第三层获取到的数据进行报警规则设置、报警阀值设置、报警联系人设置和报警方式设置等。

报警事件生成层：位于第五层，主要是将报警事件进行实时记录，并将报警结果存入数据库以备调用，并将报警结果形成分析报表，以统计一段时间内的故障率和故障发生趋势。

用户展示管理层：位于最顶层，是一个web展示界面，主要是将监控统计结果、报警故障结果进行统一展示，并实现多用户、多权限管理，实现统一用户和统一权限控制。
 
在这6层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取模块和监控报警模块，每个模块完成的功能如下：

数据收集模块：此模块主要完成基础数据的收集与图形展示，数据收集的方式有很多种，可以通过SNMP实现，也可以通过代理模块实现，还可以通过自定义脚本实现，这里采用数据收集工具Ganglia来实现。

数据提取模块：此模板主要完成数据的筛选过滤和采集，将需要的数据从数据收集模块提取到监控报警模块中。可以通过数据收集模块提供的接口或者自定义脚本实现数据的提取。

监控报警模块：此模块主要完成监控脚本的设置、报警规则设置，报警阀值设置、报警联系人设置等，并将报警结果进行集中展现和历史记录，常见的监控报警工具有Nagios、Centreon等。

图2是根据图1的设计思路形成的一个运维监控平台实现拓扑图，从图中可以看出，主要有三大部分组成，分别是数据收集模块、监控报警模块和数据提取模块。

其中，数据提取模块用于其它两个模块之间的数据通信，而数据收集模块可以有一台或多台数据收集服务器组成，每个数据收集服务器可以直接从服务器群组收集各种数据指标，经过规范数据格式，最终将数据存储到数据收集服务器中。

监控报警模块通过数据抽取模块从数据收集服务器获取需要的数据，然后对数据设置报警阀值、报警联系人等，最终实现实时报警，报警方式支持手机短信报警、邮件报警等，另外，也可以通过插件或者自定义脚本来扩展报警方式。这样一整套监控报警平台就基本实现了。

第二：Ganglia作为数据收集模块​

Ganglia是一款为HPC（高性能计算）集群而设计的可扩展的分布式监控系统，它可以监视和显示集群中的节点的各种状态信息，它由运行在各个节点上的gmond守护进程来采集cpu 、mem、硬盘利用率、I/O负载、网络流量情况等方面的数据，然后汇总到gmetad守护进程下，使用rrdtools存储数据，最后将历史数据以曲线方式通过php页面呈现。

特点如下：

1. 灵活的分布式、分层体系结构，使Ganglia支持上万个监控节点的数据收集，并且性能表现稳定，同时，Ganglia也可以根据地域环境、网络结构的不同，分地域、分层次的灵活部署Ganglia数据收集点，而对于数据收集节点可以动态添加或删除，对Ganglia整体监控不产生任何影响。因此，可以灵活的扩展Ganglia数据收集节点。
2. Ganglia收集到的数据更加精确，它不但可以收集实时数据，以图表的形式展示出来，而且还允许用户查看历史统计数据，因此，用户可以通过这些数据，做出性能调整、升级、扩容等决策，从而保证应用系统能够满足不断增长的业务需求。
3. Ganglia可以通过组播、单播的方式收集数据，在监控的节点较多时通过组播方式收集数据可以大大降低数据收集的负载，提高监控和数据收集性能。而对于不能使用组播收集数据的网络环境，还可以通过单播的方式收集数据，因此Ganglia在数据收集方式上非常灵活。
[]Ganglia可收集各种度量的数据，Ganglia默认情况下可收集cpu、memory、disk、I/O、process、network六大方面的数据，同时Ganglia提供了C或者Python接口，用户通过这个接口可以自定义数据收集模块，并且这些模块可以被直接插入到Ganglia中以监控用户自定义的应用。[/]

基于以上Ganglia这些优点，使它非常适合作为监控报警平台的数据收集模块，虽然Cacti/zabbix也可以实现数据的收集和图形报表的展示，但是当监控节点越来越多时，Cacti和zabbix的缺点就慢慢暴露出来了，数据收集的准确性、实时性就很难得到保障了。因此，要构建一个高性能的监控报警平台，Ganglia是首选的数据收集模块。

第三：Centreon作为监控报警模块

对主机或服务的状态值进行监控，当达到指定阀值时进行报警，要实现这个功能并不是什么难的事情，可以写个简单的脚本就能实现，但是这样太原始了，没有层次，维护性差，并且当需要监控报警的主机或服务越来越多时，脚本的性能就变得很差，管理也非常不方便，更别说有什么可视化效果了，因此，就需要有一个专业的监控报警工具来实现这个功能。

Centreon就是这样一个专业的分布式监控、报警工具，它通过第三方组件可以实现对网络、操作系统和应用程序的监控与报警，在底层，centreon通过nagios作为监控软件，在数据层，Centreon通过ndoutil模块将监控到的数据定时写入数据库中，在展示层，Centreon提供了Web界面来配置、管理需要监控的主机或服务，并提供多种报警通知方式，同时还可以展现监控数据和报警状态，并可查询历史报警记录。

第四：Ganglia与Centreon的无缝整合
Nagios和Ganglia都是很好的数据中心监控工具，虽然它们的功能有重叠部分，但是两者对监控的侧重点并不相同：Ganglia侧重于收集数据，并随时跟踪数据状态，通过Ganglia不但可以看到数据的历史状态，也可以预计数据的未来发展趋势，为我们的应用程序修正和硬件采购提供决策。而Nagios更侧重与监控数据并进行过载报警，综合Ganglia和Nagios的优缺点，同时运行这两个工具可以相互弥补它们的不足：

从数据抽取模块完成的功能可以看出，此模块主要用来衔接数据收集模块和监控报警模块，进而完成Ganglia和Centreon的无缝整合。

要实现数据抽取模块的功能，没有现成的方法可用，需要在ganglia基础上做二次开发，较简单的方法是在通过程序在ganglia上开发一个数据提取接口，然后将数据抽取到nagios中，初步方案是通过python程序来实现。
 
第五：统计监控系统架构图

简单描述如下：

第六：数据流向图

基本流程如下：

QA环节：
1、gmond在客户端之间通过udp方式互相传递的，有什么意义？
答：通过udp方式传输数据，一方面是轻量级传输，在大量服务器监控的情况下，不会过大消耗服务器和网络资源，另一方面udp方式的组播方式可以将数据保存到多个节点，这样可以在管理端设置多个收集数据节点，当一个节点故障时，自动去另一个节点收集数据，保证了数据收集的稳定性。
 
2、如何监控系统不通过tcpip而是通过读取数据库形式完成数据抓取，发现故障的延时会好很多么？​
答：抓取数据的方式决定了是否存在延时，这个跟ganglia无关，ganglia可以接收接口过来的任意数据，但是是否有延时，决定权在你的数据收集脚本。
 
3、如果为了备份数据的话，采用udp方式，一旦各个节点之间发生网络抖动，数据完整性如何保证？​
答：数据在每个节点的保存时间基本在10秒左右，超过这个时间，数据会再次进行更新，因此不存在抖动问题，至于数据完整性，也可以不用考虑，在收集到数据后，gmetad会对数据进行统一整理，更多关注的是数据的及时性。
微信分享原文

 

Linux系统启动流程大概总结下来是这么一个过程:

POST-->BootLoader(MBR)-->Kernel(硬件探测、加载驱动、挂载根文件系统、/sbin/init)-->init(/etc/inittab:设定默认级别、系统初始化脚本、启动及关闭对应级别的服务、启动终端)

详细分析上面的流程​

第一步

1.POST 打开电源按钮，CPU会把位于CMOS中的BIOS程序加载到内存里面执行，BIOS会探测并识别主板上的所有硬件，然后按照BIOS程序里面设定的启动顺序（1.光驱 2.硬盘 3.软驱 等），它会挨个去这些设备里面找启动设备，一旦找到就停止寻找，如：第一个先从光驱找到，但是没有找到光盘，那么找第二个硬盘，找到硬盘也不一定能启动，要看硬盘是否包含MBR，如果有MBR那就从硬盘启动，如果没有就继续向下寻找，如果一直没有找到可启动的设备，那么本次启动宣告失败



开电之后，CPU就到出厂时指定的内存地址空间（是由内存和CMOS组成）去加载BIOS程序（存储在CMOS里面），BIOS是由一系列的汇编指令组成，用于进行硬件检测（把检测到的结果存储到内存的低地址空间里，是由于BIOS 的寻址能力有限），BIOS首先会探测有几块内存以及其他设备是不是都基本正常，有任何问题就会报警，就无法往下启动，接着去扫描ISA总线和PCI总线去查找各关联到的设备，并且能指挥各硬件完成中断注册和IO端口注册

第二步

2.在上一步中，BIOS找到硬盘的MBR（位于硬盘的0磁道0扇区 大小为512字节，该区域不能被分配给任何分区），然后在MBR中寻找BootLoader（目前比较常用有LILO 和 GRUB，LILO已经不常用，BootLoader在MBR所占446字节，所以必须短小精悍，还有16字节是分区表信息，剩下2字节是用来标明该MBR是否有效），然后把BootLoader加载到内存中开始执行，BootLoader主要功能就是从硬盘找到内核文件，把内核文件加载到内存执行。

[][x] GRUB的功能[/]

1、选择启动的内核映像或操作系统；2、传递参数：e: 编辑模式 b: 引导3、基于密码保护 (这个工具 grub-md5-crypt 可以生成 然后放到grub.conf里面 password --md5 密码 )启用内核映像 传递参数

[][x] 疑问? 内核文件在哪里？GRUB是怎么找到内核文件？​[/]

内核文件（vmlinuz-2.6.18-308.el5）是位于/boot分区下（在我们给硬盘分区的时候都会把/boot单独分区），这时又有疑问了，这时候/都没有被挂载，又如何从硬盘上找到内核文件？

vm.png

[][x] 这时看GRUB的配置文件/boot/grub/grub.conf 可以看到 root (hd0,0)，这一行实际上就是指定boot目录所在的位置[/][]而kernel /vmlinuz-2.6.18-308.el5 ro root=LABEL=/ 这里指定的是内核文件所在的位置，而前面的/并不是真正的根，而是指的是boot目录所在的位置，那么其全路径为(hd0,0)/vmlinuz-2.6.18-308.el5,而这里的(hd0,0)指的是第1个硬盘的第1个分区，GRUB在识别硬盘的时候都是识别为hd开头的[/]

 

[][x] 总结:[/]

GRUB不是通过文件系统来找内核文件的，因为这时候内核还没有启动所以也不存在什么文件系统，而是直接访问硬盘的第1个硬盘第1个分区（MBR里面存在分区表）的来找到内核文件

[][x] 这时候又有个问题 GRUB是怎么识别分区表中这些分区的文件系统的？ 且看/boot/grub目录下的文件[/]

[root@server1 grub]# ll总计 257-rw-r--r-- 1 root root     63 2013-01-05 device.map-rw-r--r-- 1 root root   7584 2013-01-05 e2fs_stage1_5-rw-r--r-- 1 root root   7456 2013-01-05 fat_stage1_5-rw-r--r-- 1 root root   6720 2013-01-05 ffs_stage1_5-rw------- 1 root root    562 2013-01-05 grub.conf-rw-r--r-- 1 root root   6720 2013-01-05 iso9660_stage1_5-rw-r--r-- 1 root root   8192 2013-01-05 jfs_stage1_5lrwxrwxrwx 1 root root     11 2013-01-05 menu.lst -> ./grub.conf-rw-r--r-- 1 root root   6880 2013-01-05 minix_stage1_5-rw-r--r-- 1 root root   9248 2013-01-05 reiserfs_stage1_5-rw-r--r-- 1 root root  55808 2009-03-13 splash.xpm.gz-rw-r--r-- 1 root root    512 2013-01-05 stage1-rw-r--r-- 1 root root 104988 2013-01-05 stage2-rw-r--r-- 1 root root   7072 2013-01-05 ufs2_stage1_5-rw-r--r-- 1 root root   6272 2013-01-05 vstafs_stage1_5-rw-r--r-- 1 root root   8904 2013-01-05 xfs_stage1_5

其实GRUB启动是分阶段的

[][x] 第1个阶段[/]

BIOS加载MBR里面的GRUB（属于第1阶段的文件），由于只有GRUB只占用446字节所以不能实现太多的功能，所以就有此阶段里面的文件来加载第1.5阶段的文件（/boot/grub下的文件）

[][x] 第1.5个阶段[/]

这个阶段里面的就是加载识别文件系统的程序，来识别文件系统，不加载就无法识别文件系统，进而就找不到boot目录，由于GRUB是无法识别LVM，所以你不能把/boot分区设置为LVM，所以必须要把/boot单独分区

[][x] 第2个阶段 这里面才是正在的开始寻找内核的过程，然后是启动内核[/]

 

第3步3.在上一步中，GRUB成功找到内核文件，并把内核加载到内存，同时把/boot/initrd-2.6.18-308.el5.img这个文件也加载进来，这个文件是做什么的呢？

那么首先看看内核在这一步骤里面做的事情

探测硬件加载驱动挂载根文件系统执行第一个程序/sbin/init

[][x] BIOS检查硬件，而内核是会初始化硬件设备，那么首先会探测硬件（第1步），知道是什么硬件了就该加载硬件驱动程序（第2步），不然是没办法指挥着硬件工作的，关键是内核去哪里找驱动程序（驱动程序是硬盘上，是内核模块.ko存在的）而此时根文件系统还没有挂载上，怎么办？ 那可以②③对调，先挂载根文件系统，然后再加载驱动，那此时又有问题了，我不加载驱动程序又如何驱动着硬盘工作呢？ 这个陷入了是先有蛋还是有先鸡的问题了，这该如何解决？[/]

 

[][x] 这时候 这个文件/boot/initrd-2.6.18-308.el5.img（该文件是一个.gz的压缩文件） 就派上用场了，这个文件也是被GRUB加载内存当中，构建成一个虚拟的根文件系统，这个文件里面包含有硬件驱动程序（），这个文件是可以展开如下操作：[/]

 

[root@server1 boot]# cp initrd-2.6.18-308.el5.img ~[root@server1 boot]# cd[root@server1 ~]# lsinitrd-2.6.18-308.el5.img[root@server1 ~]# mv initrd-2.6.18-308.el5.img initrd-2.6.18-308.el5.img.gz[root@server1 ~]# gzip -d initrd-2.6.18-308.el5.img.gz[root@server1 ~]# lsinitrd-2.6.18-308.el5.img[root@server1 ~]# file initrd-2.6.18-308.el5.imginitrd-2.6.18-308.el5.img: ASCII cpio archive (SVR4 with no CRC) 可以看到此时是一个cpio的归档文件[root@server1 ~]# mkdir test[root@server1 ~]# mv initrd-2.6.18-308.el5.img  test[root@server1 ~]# cd test[root@server1 test]# lsinitrd-2.6.18-308.el5.img[root@server1 test]# cpio -id < initrd-2.6.18-308.el5.img  利用cpio来展开该文件12111 blocks[root@server1 test]# lsbin  dev  etc  init  initrd-2.6.18-308.el5.img  lib  proc  sbin  sys  sysroot[root@server1 test]# mv initrd-2.6.18-308.el5.img ../[root@server1 test]# ls  可以看到这不就是跟真实的根很像吗bin  dev  etc  init  lib  proc  sbin  sys  sysroot[root@server1 test]# ls lib/    可以看到这目录下包含了ext3.ko的内核模块，该模块就可以驱动着硬盘进行工作了ata_piix.ko            dm-mod.ko              ext3.ko                mptbase.ko             scsi_mod.kodm-log.ko              dm-raid45.ko           firmware/              mptscsih.ko            scsi_transport_spi.kodm-mem-cache.ko        dm-region_hash.ko      jbd.ko                 mptspi.ko              sd_mod.kodm-message.ko          ehci-hcd.ko            libata.ko              ohci-hcd.ko            uhci-hcd.ko[root@server1 test]#

[][x] 至此内核利用虚拟的根文件系统的ext3.ko内核模块，驱动了硬盘，然后挂载了真正的根文件系统，那么此时虚拟的根文件系统是否还有作用，它还可以挂载/proc文件系统等操作。[/][][x] 此阶段中最后一个步骤 由内核来启动第一个程序/sbin/init，启动好之后剩下的工作就有init进程来完成了。[/]

第4步

init进程首先会读取/etc/inittab文件，根据inittab文件中的内容依次执行

设定系统运行的默认级别（id:3:initdefault:）

执行系统初始化脚本文件（si::sysinit:/etc/rc.d/rc.sysinit）

执行在该运行级别下所启动或关闭对应的服务（l3:3:wait:/etc/rc.d/rc 3）

启动6个虚拟终端

     l0:0:wait:/etc/rc.d/rc 0

     l1:1:wait:/etc/rc.d/rc 1

     l2:2:wait:/etc/rc.d/rc 2

     l3:3:wait:/etc/rc.d/rc 3

     l4:4:wait:/etc/rc.d/rc 4

     l5:5:wait:/etc/rc.d/rc 5

     l6:6:wait:/etc/rc.d/rc 6



进一步的启动操作请看 -> 详解/etc/inittab文件

简介

SaltStack是一种新的基础设施管理方法开发软件,简单易部署,可伸缩的足以管理成千上万的服务器,和足够快的速度控制,与他们交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。SaltStack项目于2011年启动,年增长速度较快,五年期固定基础设施编制和配置管理的开源项目。SaltStack社区致力于保持盐项目集中、友好、健康、开放。 

简单来说它的两大基础功能就是：配置管理、远程命令执行。剩下就是根据你的需求自由组合，实现更复杂的功能和系统管理。

SaltStack学习过程

大概步骤如下：

[]安装和配置SaltStack[/][]远程执行命令所有管理系统[/][]设计、开发和部署系统配置[/][]用SaltStack反应器来自动化基础设施[/][]协调使用SaltStack编排复杂的管理操作[/]

SaltStack组件

1、SaltStack  Master
中央管理系统\服务端，这个系统是用来发送命令和配置到SaltStack Minion上运行。

 
2、SaltStack Minion
接受受管理系统\客户端，该系统接收来自SaltStack Master命令和配置。

 
3、执行模块过程
特别对一个或多个命令从命令行执行受管理系统。 适用于:

[]实时监控、状态和库存[/][]一次性命令和脚本[/][]部署关键更新[/]

 
4、规则(States)
声明或命令式表示一个系统的配置。

 
5、Grains
系统变量， Grains是静态信息基础管理系统,包括操作系统、内存和许多其他的系统属性，您还可以定义定制的Grains为任何系统。

 
6、Pillar
用户定义的变量，这些安全变量定义和存储在Salt Master,然后“分配”到一个或多个下属，Pillar数据存储值,文件路径,配置参数,和密码。

 
7、Top File
数据匹配公式

 
8、Runners
模块执行SaltStack Master执行支持任务,Runners报告的工作状态、连接状态读取数据从外部api,查询连接Salt Minions,和更多。
例如,安排Runners在许多系统之间协调配置部署。

 
9、Returners
SaltStack Minion返回的数据发送到另一个系统,如数据库,Returners可以运行在Salt Minion或Salt Minion。

 
10、Reactor
SaltStack环境中触发事件发生时的反应。

 
11、Salt Cloud / Salt Virt
云提供商提供系统/管理程序并立即把他们管理下。

 
12、SaltStack SSH
SaltStack使用ssh运行命令，在没有Salt Minion的情况下。

到这里SaltStack组件和构成架构体系就介绍到这里，还有一些比如高可用没有介绍
参考：docs.saltstack.com

场景

有时候我们有批量修改主机名和同步hosts文件到多台主机的需求，例如新上了一批服务器等，可能主机名称上并不能满足你的命名规则或规范，但如果一台台去更改可能就太慢又无聊，所以shell脚本绝对是你的最佳选择。

需求分析

[]ssh公钥拷贝，提供无密码管理。[/][]批量同步hosts文件到多台主机。[/][]批量修改主机名。[/]

实现

首先编辑一份用于同步到多台主机的hosts文件

# vi /etc/hosts



192.168.0.1 server1

192.168.0.2 server2

192.168.0.3 server3

192.168.0.4 server4

192.168.0.5 server5

192.168.0.6 server6

192.168.0.7 server7

192.168.0.8 server8

192.168.0.9 server9

192.168.0.10 server10

然后编辑shell脚本：

# vi changename.sh



#!/bin/bash

# This is a shell script to change hostname



export PATH=$PATH

export USER=root

export SNAMEPRE=server

export PASSWD=test01   #定义密码

for i in {1..10};

 do /usr/bin/expect << EOF     [size=16]这里用到了expect完成了确认yes和密码输入交互[/size]

spawn ssh-copy-id -i /root/.ssh/id_rsa.pub $USER@$SNAMEPRE$i

expect {

"(yes/no)?" {send "yes\r";exp_continue}

"password:" {send "$PASSWD\r"}

}

interact

expect eof

EOF

    ssh $USER@$SNAMEPRE$i "sed -i s/^HOST.*/HOSTNAME=$SNAMEPRE$i/ /etc/sysconfig/network";

    scp /etc/hosts $USER@$SNAMEPRE$i:/etc/hosts;

 done;

这里用到了expect完成自动交互确认和密码输入。



Expect是一个免费的编程工具语言，用来实现自动和交互式任务进行通信，而无需人的干预。Expect的作者Don Libes在1990年 开始编写Expect时对Expect做有如下定义：Expect是一个用来实现自动交互功能的软件套件 (Expect [is a] software suite for automating interactive tools)。使用它系统管理员 的可以创建脚本用来实现对命令或程序提供输入，而这些命令和程序是期望从终端（terminal）得到输入，一般来说这些输入都需要手工输入进行的。

更多Expect信息请查看站点  http://expect.sourceforge.net/
这样一个简单的脚本就帮你完成3件事，拷贝公钥、修改主机名、同步hosts文件。
 
如果使用ansible会更简单！

起因

鄙人折腾Salt也已经一年有余了，从最开始Linux运维的基础知识，包括啥叫配置管理都一无所知，事到如今好歹也做了一些事情，虽然没啥功劳，也埋了一些坑，但是总归在自动化方面贡献了一些微薄的力量。

为什么要搞Salt高可用架构呢? 起因是因为公司内部对于Salt的要求从工具上升到了基础架构组件的层面，要求在响应时间和服务可用性方面有一些更高的要求，简单来说，就是内部的一些重要组件依赖于它来完成一些事情。而Salt原生是默认的单点Master - Minion结构，其Salt-API也是Daemon方式的裸奔运行，我们踩了很多坑，发现实在是痛的不行，鄙人向领导反馈了这一严重隐患，终于也就有了这样的一次折腾。
 
至今，我们研究的成果已经推广到了生产环境，虽然它还是有很多的问题，然而之所以写下这篇博客，实在只是为了聊以纪念一下整个项目团队几个月来的共同努力。

启发

Salt 高可用架构方面的文档和参考案例还是相当稀少的，直到今年（2015）的5月份左右的样子，才看到官方有整理出一篇高可用相关的文档：http://docs.saltstack.com/en/latest/topics/highavailability/index.html
 
而这里面讲的也还是比较宽泛，可以选择的架构以及对应的优缺点信息都比较稀少。好在开源大牛们从来都不缺乏分享的精神，鄙人挖了一下SaltConf15上一些成功的案例分享，最主要的当然是Linkedin的Thomas Jackson大牛的分享，最终通过反复研究，有些收获（期间多亏Kenny的几次指点，真的非常感谢）。
 
MultiSyndic、MultiMaster、Failover Minion、Ext Job Cache
我们这边最后采用的架构采用了MultiSyndic + MultiMaster + Failover Minion这几个salt原生的重要特性，为了不让读者们困惑，这里先首先讲解下这几个特性。

MultiSyndic

MultiSyndic 是 2014.7版本以后才引入的一个重要特性，它使得SYndic架构变得更加灵活，即一台SYndic可以同时被多台MOfM管理（你可以理解为MultiSyndic的MultiMaster），官方文档这方面做的还不是很完善，只是简单的介绍了一下该如何配置，大家可以看看：https://docs.saltstack.com/en/latest/topics/topology/syndic.html。
 
具体的源码则是放到了minion.py的这一块，本身原理便是MultiSYndic会去复用一些Syndic的功能，然后做一些转发的处理。
 
MultiSyndic的配置其实有点综合MultiMaster，你需要设置syndic本身的一些配置，包括每台syndic设置syndic_master为一个list mofm，另外Key等文件做共享配置，其次写入一些必要的syndic本身的配置，由于过于细节，这里不再赘述。

Failover Minion(Or MultiMinion)

Failover Minion 则是Salt引入的一个Minion端实现的特性，它允许minion定期的去探测当前master的存活性，一旦发现master不可用，可以在一定时间内做出切换，从而提高整体服务调用的可用性，具体的配置文档也可以参见官方文档，需要注意的是配置MultiMaster 亦或是 MultiMaster PKI都可以使用failover特性，这一点已经由官方强调过，minion配置内容如下：

# multi-master

master:  

    - 172.16.0.10

    - 172.16.0.11

    - 172.16.0.12



# 设置为failover minion

master_type: failover



# 设置启动时随机选择一台master

master_shuffle: True



# 探测master是否存活的schedule job

# 即使用salt schedule特性实现的功能

master_alive_interval: 

Ext Job Cache

如何分解出master的压力？一方面，可以做负载均衡，将minion分散到不同的Master去管理，另外一方面，跑salt-job的主要需求还是获取job结果，为了减轻查询结果方面的压力，也为了提高整体架构的并发能力，鄙人推荐了引入ext job cache的特性。

实际上，使用ext_job_cache配置搭配合适的returner便可以让salt-master默认将job数据写入到指定的存储，然而这样带来的坏处是一旦你存储的组件挂掉了，比如配的redis returner，redis一旦挂掉，那么job便根本无法下发（因为job下发的时候便会将job load写入到cache，即这次job的执行参数和命中的具体minion数据），为了规避这一个坑，鄙人改造了绿肥同学基于Salt Event系统构建Master端returner这篇博客里讲解的监听event并写入job数据的方案，通过配置额外的服务来实现了ext job cache的写入。

几种高可用架构的选择

OK，至此，我们已经了解了一些基本的Salt原生提供的高可用特性，接下来，鄙人将为您分享我个人认为不同的量级和场景下推荐的Salt高可用架构方案。

备注：这里统一建议一下salt-master的配置性能，我个人之前使用的salt-master是2C6G的低配虚拟机，踩了非常多的坑，包括Auth风暴等等，1k台机器之后使用起来体验也相当糟糕，所以个人建议salt-master配置至少> 8C的计算能力~
 
方案1： Single Master With Warm Backup

适用场景：< 1k Minion的小规模应用

Salt版本限制：印象中至少0.17已经支持了这个特性



问题：我个人也没有在生产具体应用过该架构，但是

SaltConf15上已有这样的用例，应该是完备的一方案~

Salt 原生支持salt-master指向配置成DNS域名，它会通过resolv_dns函数来解析具体的master ip，所以在minion发现与master中断后，它会尝试和master重新连接，而可以通过重新解析DNS来实现Master的切换。
 
方案2：MultiMaster

适用场景: 1k ~ 4k，调用强度集中于小规模机器

鄙人也和几位业内的运维交流了salt的一些心得，应该目前来说，MultiMaster算是最常见的应用架构，它足够的简单，并且Salt原生的支持也相对比较成熟，个人也推荐在中等规模及一般使用的情况下可以使用这样的一个架构来满足需求。
 
方案3：MultiMaster + MultiSYndic + FailoverMinion（linkedin分享的架构#5）

适用场景：并发调用强度相对较高，并且分多套salt各自维护（比如UAT和PROD不是一个团队的人来维护这样一个情况），

对于salt服务的SLA以及性能方面有较高要求的场景，机器数量方面可以通过横向扩展来解决，

一般来说，建议 ~10k 及以上的规模采用此架构方案（并且鄙人尝试配置过官方原生的这个架构，

貌似有很多的坑，我们这边是通过修改了MultiSyndic的部分代码才使得整体架构可用）

话不多说，一图胜千言，实际上，我们内部用的就是linkedin分享的第5套架构，可能有人会问，为啥不用第6套架构呢? 我个人测试过，第6套架构是可行的，但是貌似只能跑两台master互为master\syndic，一旦配成三台便会出现event loop，这个我们内部分析过，应该是一个合理的逻辑，不知道为啥linkedin最终是推荐的这个架构?

采用这一架构的话，首先一点，我们可以在MofM这一层架设Salt-API，并设置负载均衡，这样一来的话，能实现API这一层的负载均衡及横向扩展。另外一方面，MultiSyndic这一层，由于每台minion实际一个时刻只由一台SYndic Master管理，因此Syndic Master的压力被分散到了每台机器上，再者，MofM由于可以和所有的SYndic通信，因而上层的Salt-API可以ping通全量的Minion！值得补充的是，我们将syndic的job event额外吐到了统一的redis job cache，这样一来，通过调整salt api的调用方式（从同步改成异步），即可极大的减轻Master的负载，将压力均摊到了redis cache（减少了大量的find_job任务，当然，问题即在于你必须给出一个大致的超时时间，因为问询salt-minion是否完成的逻辑改成了query job cache，所以无法感知minion实际是否真的在执行与否）。

如此一来，即实现了负载均衡 + 高可用 + 可横向扩展的Salt架构方案！Success！

当前架构的利与弊

通过生产环境的线上实际体验，我们也获知了我们当前采取的#5架构的一些具体的利弊所在，不敢私藏，在此分享一二。
利：

这一架构的优势在于高并发的爆发能力和可扩展的负载均衡能力。



首先，我们用nginx + UWSGI将salt-api封装了一层，使得其并发能力和稳定性有了一定的提高。



另外， 这个架构下，上层MofM只负责下发Job并且可以横向扩展，这便实现了强大的API高并发的可能，另外， Syndic每台管理1/n的minion机器，相对的负载被分散到了各台机器上，理论上来说它可以支撑的minion机器规模是足够数量级的。

弊：

诶，这个架构目前的劣势也是相当的明显，成也MultiSyndic，败也MultiSyndic, Syndic的逻辑是处理完结果后会把job数据回吐给MofM，而MofM理论上是可以ping通所有minion的，所以一旦执行类似Salt * test.ping命令的时候，MofM就等于承受了一次短时间的数据流量的冲击，所有Syndic会在短时间内把job result回吐给MofM，1w台minion便是1w条minion job数据，再加上find_job任务，后果不堪设想..



因此，我们如今也在推动整改成异步调用的方式，并且也在思考如何优化这一层的处理，实际上，用户如何使用也是一个很大的哲学。

结语

这篇文章是鄙人今天整理这几个月的感受仓促而成，很多的细节还没有完全的揭露，实际上，生产环境的线上考验仍然不够充分，然而，毕竟还是完成了一个小小的milestone，写出这篇文章，也是为了分享一下个人的踩坑记。Salt的确很坑，有很多的问题， 但是，在决定使用它并将其作为基础架构组件的情况下，抱怨变得毫无意义，如何有方法的具体的去实施，去解决问题才是我们实际需要考虑的事情。



在这几个月的过程中，从最开始的茫然，焦躁，到在Kenny带领下研究架构的方案，再到找上Dingw大哥一起研究和改动MultiSYndic的代码，实在是成长了很多，多亏了几位大哥的帮扶，尤其是Kenny， Dingw，Bshu, JY 几位大哥，在架构和代码二次开发方面出了很多力气，鄙人也算是在几位大哥的carry下算是一起完成了这件事情罢。目前，只是完成了新架构的生产切换，未来可能还会有很多的挑战，鄙人很遗憾后续无法更多的参与，但是很感恩与团队里的同事们一起攻克问题的这几个月的经历。



这个架构是否可以完全适应我们公司内部的使用也有待进一步的考验，也相信我们项目团队会进一步的优化和改善Salt的使用，最终促成一个健壮的Salt基础架构组件服务！！

分享原文作者：jacky
分享原文地址：http://devopstarter.info/saltstack-ha-arch/

前言

rsync用来同步数据非常的好用，特别是增量同步。但是有一种情况如果不增加特定的参数就不是很好用了。比如你要同步多个几十个G的文件，然后网络突然断开了一下，这时候你重新启动增量同步。但是发现等了好久都没有进行数据传输，倒是机器的IO一直居高不下。

原因

rsync具体的增量同步算法不太清楚。根据它的表现来看，可能在增量同步已经存在的一个文件时，会校验已传输部分数据是否已源文件一致，校验完成才继续增量同步这个文件剩下的数据。所以如果对一个大文件以这样的算法来增量同步是非常花时间并且占用IO资源的。

方法

集中花了一段时间查看了rsync的文档，发现有一个参数能快速恢复大文件的增量同步，–append。设置–append参数会在增量同步时计算文件大小并直接追加新的数据到文件，这样就省了费IO校验的过程。不过这个参数最好只在源文件和目标文件都不会更改的时候使用比较安全，比如备份的文件。

#!/bin/sh



/etc/init.d/syslog stop



echo 1 > /proc/sys/vm/block_dump



sleep 60



dmesg | awk '/(READ|WRITE|dirtied)/ {process[$1]++} END {for (x in process) \



print process[x],x}' |sort -nr |awk '{print $2 " " $1}' | \



head -n 10



echo 0 > /proc/sys/vm/block_dump



/etc/init.d/syslog start