工作原理图：

主从复制的原理：
分为同步复制和异步复制，实际复制架构中大部分为异步复制。 复制的基本过程如下：

1).Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

2).Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；

3).Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；

4).Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

收起阅读 »

工作拓扑

MySQL Proxy有一项强大功能是实现“读写分离”，基本原理是让主数据库处理写方面事务，让从库处理SELECT查询。
 
Amoeba for MySQL是一款优秀的中间件软件，同样可以实现读写分离，负载均衡等功能，并且稳定性也高于MySQL Proxy，有兴趣的可以测试一下。
环境描述：
操作系统：CentOS6.3_x64

[]主服务器Master：192.168.0.202[/][]从服务器Slave：192.168.0.203[/][]调度服务器MySQL-Proxy：192.168.0.204[/]

一、Mysql主从复制

主从复制这里就不多说了，可以参考：http://openskill.cn/article/110

二、Mysql-proxy读写分离实现

1、安装mysql-proxy
实现读写分离是有lua脚本实现的，现在mysql-proxy里面已经集成，无需再安装
下载：http://dev.mysql.com/downloads/mysql-proxy/

tar zxvf mysql-proxy-0.8.3-linux-glibc2.3-x86-64bit.tar.gz

mv mysql-proxy-0.8.3-linux-glibc2.3-x86-64bit /usr/local/mysql-proxy

2、配置mysql-proxy，创建主配置文件

cd /usr/local/mysql-proxy

mkdir lua  #创建脚本存放目录

mkdir logs  #创建日志目录

cp share/doc/mysql-proxy/rw-splitting.lua ./lua  #复制读写分离配置文件

cp share/doc/mysql-proxy/admin-sql.lua ./lua  #复制管理脚本

vi /etc/mysql-proxy.cnf    #创建配置文件

[mysql-proxy]

user=root  #运行mysql-proxy用户

admin-username=proxy  #主从mysql共有的用户

admin-password=123.com  #用户的密码

proxy-address=192.168.0.204:4000  #mysql-proxy运行ip和端口，不加端口，默认4040

proxy-read-only-backend-addresses=192.168.0.203  #指定后端从slave读取数据

proxy-backend-addresses=192.168.0.202  #指定后端主master写入数据

proxy-lua-script=/usr/local/mysql-proxy/lua/rw-splitting.lua  #指定读写分离配置文件位置

admin-lua-script=/usr/local/mysql-proxy/lua/admin-sql.lua  #指定管理脚本

log-file=/usr/local/mysql-proxy/logs/mysql-proxy.log  #日志位置

log-level=info  #定义log日志级别，由高到低分别有(error|warning|info|message|debug)

daemon=true     #以守护进程方式运行

keepalive=true  #mysql-proxy崩溃时，尝试重启

保存退出！

chmod 660 /etc/mysql-porxy.cnf

3、修改读写分离配置文件

vi /usr/local/mysql-proxy/lua/rw-splitting.lua

if not proxy.global.config.rwsplit then

 proxy.global.config.rwsplit = {

  min_idle_connections = 1, #默认超过4个连接数时，才开始读写分离，改为1

  max_idle_connections = 1, #默认8，改为1

  is_debug = false

 }

end

4、启动mysql-proxy

/usr/local/mysql-proxy/bin/mysql-proxy --defaults-file=/etc/mysql-proxy.cnf

netstat -tupln | grep 4000 #已经启动

tcp 0 0 192.168.0.204:4000 0.0.0.0:* LISTEN 1264/mysql-proxy

关闭mysql-proxy使用：killall -9 mysql-proxy

5、测试读写分离
1>.在主服务器创建proxy用户用于mysql-proxy使用，从服务器也会同步这个操作

mysql> grant all on [i].[/i] to 'proxy'@'192.168.0.204' identified by '123.com';

2>.使用客户端连接mysql-proxy

mysql -u proxy -h 192.168.0.204 -P 4000 -p123.com

创建数据库和表，这时的数据只写入主mysql，然后再同步从slave，可以先把slave的关了，看能不能写入，这里我就不测试了，下面测试下读的数据！

mysql> create table user (number INT(10),name VARCHAR(255));

mysql> insert into test values(01,'zhangsan');

mysql> insert into user values(02,'lisi');

3>.登陆主从mysq查看新写入的数据如下

mysql> use test;

Database changed

mysql> select * from user;

+--------+----------+

| number | name |

+--------+----------+

| 1 | zhangsan |

| 2 | lisi |

+--------+----------+

4>.再登陆到mysql-proxy，查询数据，看出能正常查询

mysql -u proxy -h 192.168.0.204 -P 4000 -p123.com

mysql> use test;

mysql> select * from user;

+--------+----------+

| number | name |

+--------+----------+

| 1 | zhangsan |

| 2 | lisi |

+--------+----------+

5>.登陆从服务器关闭mysql同步进程，这时再登陆mysql-proxy肯定会查询不出数据

slave stop；

6>.登陆mysql-proxy查询数据，下面看来，能看到表，查询不出数据

mysql> use test;

Database changed

mysql> show tables;

+----------------+

| Tables_in_test |

+----------------+

| user |

+----------------+

mysql> select * from user;

ERROR 1146 (42S02): Table 'test.user' doesn't exist

配置成功！真正实现了读写分离的效果！

原文作者：李振良
分享原文地址：http://lizhenliang.blog.51cto.com/7876557/1305083

收起阅读 »

# python startup file

import sys

import readline

import rlcompleter

import atexit

import os

# tab completion

readline.parse_and_bind('tab: complete')

# history file

histfile = os.path.join(os.environ['HOME'], '.pythonhistory')

try:

    readline.read_history_file(histfile)

except IOError:

    pass

atexit.register(readline.write_history_file, histfile)

收起阅读 »

BAT分别掌握着一般型数据、交易型数据和关系型数据领域的话语权，但彼此间并不开放,试图颠覆BAT将变得更难，它们已经控制了整个中国的互联网江湖。

中国最大的三家互联网公司百度、阿里巴巴和腾讯（简称BAT）如何通过对外投资，控制了整个中国互联网江湖？《商业周刊/中文版》根据公开信息，梳理并归纳了三家公司超过200桩投资交易，试图用一张图表，展示投资信息和投资版图，并邀请互联网分析师尹生撰文，分析这一轮轮由BAT主导或参与的密集投资，会对中国互联网行业产生怎样的深远影响。

过去中国创业者们最担心的是中国最大的三家互联网公司百度、阿里巴巴和腾讯（简称BAT）是否会复制它们。现在，这个话题已经演变为，BAT是否会投资甚至收购它们。在过去那种“被复制”的情况下，创业者们还有成为下一个BAT级存在的机会——前提是克服BAT的关注；而在当前的境况下，中国的创业者，必须要面对的现实则是：如果不能入局BAT（被投资或收购），往往就意味着衰落甚至死亡。

这种变化的影响在最近已经集中爆发：几个月前还怀着“成就千亿美元市值”梦的美团创始人王兴，以及梦想将大众点评打造为本地生活入口级公司的张涛，突然之间宣布两家公司将合并；此前一直打得不可开交、都希望做中国的Priceline的去哪儿和携程，也闪电宣布结合；各自承载着中国版Uber梦、相互刺刀见红的滴滴和快的，已然携手入梦。

所有这些看似不可能的整合背后，都离不开BAT的排兵布阵。

在一日千里的中国互联网行业大战中，表面上的主角是这些陷入剧烈竞争的创业公司，但实际上，它们不过是BAT的代理人——尽管有时这些公司自己对此也可能不自知。道理简单而直接：对一家互联网创业公司而言，要想成功，就必须有持续不断的资金投入，以及用户流量等方面的支持，而BAT有这些资源。

根据最近一期季报，截至9月底，百度手握现金、现金等价物和短期投资110亿美元，阿里巴巴为166亿美元，而腾讯的现金净额和股权与金融资产价值合计也超过100亿美元。这还没有计算这些公司利用杠杆的融资能力。

据不完全统计，在过去3年不到的时间里，BAT用于外部投资和收购的资金，累计可能超过了人民币上千亿元。规模最大的一起，是今年10月中旬阿里巴巴斥资45亿美元对优酷土豆发起的全资购案（截至发稿，该交易尚未最终完成）。

不仅对外出手阔绰，在对内投资上，这些公司也毫不手软，比如百度几个月前就高调宣布要在自己看重的本地生活O2O领域投入30亿美元，有分析指出，正是这笔投资直接迫使美团和大众点评走向合并。

对BAT而言，资本市场的战争只是业务市场竞争的延续。
全屏可看清生态图
看着生态圈越发感觉创业公司不容易啊！容易归不容易，但是15年就快结束了，身为互联网的你，改早点回家看看父母，看看孩子，看看老婆，早点回去，再怎么努力，你也挣不过BAT。过年最怕抢票了，先下手为强吧！

早点回家过年喽！ 收起阅读 »

工欲善事情，必先利其器，生产环境中的服务器在处理请求并生成回应数据的时间主要消耗在服务器端，包括了众多的环节，如何全面了解我们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会对数据进行统一整理，更多关注的是数据的及时性。
微信分享原文 收起阅读 »

调优背景

2015年11月上旬，CRMAPP系统所使用的KVM虚拟机的CPU使用率过高异常，达到70%以上，相同业务压力下同性能配置的Vmware虚拟机的负载却非常低，只在10%以内波动，并且发现KVM宿主机的CPU使用率也异常高。

分析与解决

分别从以下几个方面逐一分析排查问题原因：
1、KVM的CPU虚拟模式
首先查看KVM虚拟机CPU信息如下：

与Vmware虚拟机CPU相比较如下：

通过比较Vmware与KVM的虚拟机CPU信息发现KVM虚拟机CPU模式存在如下几个问题：

[]缺少L3 Cache：初步分析是虚拟机CPU虚拟化模式选择不合理所导致。[/][]CPU不是NUMA架构并且CPU Topology不合理：KVM宿主机物理CPU属于NUMA多node的结构，虚拟机的CPU只有一个NUMA node，所有CPU Core都在这一个node中，且虚拟机CPU的Topology是多Socket单Core的形式。[/]

 处理措施>>>> 缺少L3 Cache

针对该问题，检查了Openstack的nova.conf配置文件libvirt部分的cpu_mode的参数配置是host-model，该参数含义是根据物理CPU的特性，选择一个最靠近的标准CPU型号进行虚拟化模拟。 除了host-model外还可以有host-passthrough模式，该模式直接将物理CPU暴露给虚拟机使用，在虚拟机上完全可以看到的就是物理CPU的型号。因Openstack 仍承载业务，选择小范围的修改cpu_mode的参数，通过将Openstack的代码文件 driver.py中cpu_mode的取值修改为host-passthrough并重启宿主机上Nova-computer服务与KVM虚拟机，将自动重新生成虚拟机的 libvirt.xml文件。

>>>> CPU不是NUMA架构并且CPU Topology不合理

经过梳理Openstack虚拟机的创建流程，并查阅Openstack官方文档与代码，发现在JUNO版的Openstack中，KVM的CPU的拓扑可以通过image或者flavor进行元数据传递来定义，如果没有特别的定义此类元数据，则模拟的CPU将是多Socket单Core单NUMA节点的CPU，这样的CPU与物理CPU完全不同。通过nova命令对flavor增加了hw:numa_cpu、hw:numa_nodes、hw:cpu_sockets等属性。

处理结果经过上面两个方面的修改后，新建KVM虚拟机的CPU的信息发生如下改变，CPU的使用率有了明显下降，在10%到20%之间波动。

[]从单个NUMA节点变成4个NUMA节点[/][]具备了L3 cache[/][]CPU的Topology从32个Socket每个Socket 1个 core,变成了4个Socket每个Socket 8个Core[/]

 2、KVM宿主机与NUMA运行状况

在NUMA的CPU内存架构下，无论是物理主机还是虚拟机，如果NUMA的配置不合理对应用程序的性能都有较大的影响，并且不同类型的应用都有不同的配置需求。Vmware ESX 5.0及之后的版本支持一种叫做vNUMA的特性，它将Host的NUMA特征暴露给了GuestOS，从而使得Guest OS可以根据NUMA特征进行更高性能的调度。SUSE与Redhat作为原生的操作系统在NUMA调度上需要人为的根据应用程序的类型的做特殊配置，对云平台来说，这部分的工作是难以做到的。在优化之前，CRM APP的KVM虚拟机的NUMA调度状态非常不理想，表现为所有NUMA 节点的numa_miss统计数值大于numa_hit，这意味着CPU访问内存的路径不是优化的，存在大量CPU访问remote memory的情况。因为宿主机Ubuntu 12.02自身带有Automatic NUMA balancing，所以物理主机NUMA调度运行状态良好。

处理措施

升级KVM虚拟机的操作系统 到SUSE 12 ，因为新版本的SUSE支持Automatic NUMA balancing，并且操作系统检测到硬件属于NUMA架构时将自动开启。

处理结果

在新建的KVM虚拟机的 dmesg日志中可以看到如下信息：Enablingautomatic NUMA balancing. Configure with numa_balancing= or sysctl经过24小时的运行之后，CRMAPP的KVM虚拟机运行状态良好,CPU用率可以稳定在10%左右。

同时NUMA调度也有了较大程度的改善

总结

[list=1][]通过各环节的优化，目前KVM虚拟机的CPU利用率过高问题不再发生，整体运行达到Vmware虚拟机水平。[/][]不同类型的应用程序对于NUMA适应性不同，需要进行针对性优化。JAVA在NUMA方面也可尝试进行优化。参考Oracle官方文档，JAVA7针对并行扫描垃圾回收站（Parallel Scavenger garbage collector）加入了对NUMA体系结构的支持,实现了NUMA感知的内存分配器，由它为Java应用提供自动的内存分配优化。[/][]目前RedHat7与SUSE 12都加入了NUMA自动负载均衡的特性，可以尽量采用较新版本的操作系统，无论是物理机还是虚拟机，对于NUMA调度的优化不仅与KVM虚拟机有关，其实物理主机也应该关注NUMA调度是否是最优的。[/]
收起阅读 »

 

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

收起阅读 »