标签 Server 下的文章

Ganglia配置

ganglia工作原理 ganglia主要有两个角色,gmond(ganglia monitor daemons)和gmetad(ganglia metadata daemons)。gmond是agent,需要在被监控的每台机器上部署,负责采集所在机器的系统状态,信息都是存储在内存里面的。

ganglia-icm ganglia有一种工作模式是组播,顾名思义,以组播的形式发出自己采集到的信息。这时候集群内所有配置成组播的都可以接收数据,也就是说在组播的情形下,集群内的数据都是共享并且一致的(和路由协议很像),gmetad的功能就是从采集集群内所有系统状态信息,在组播的工作模式下,gmetad可以从任一台gmond上采集集群信息。但是组播的局限性就是在于集群要在一个网段内,并且网络负载提高。 ganglia还有一种工作模式是单播,每个agent上的gmond采集好各自的信息,然后通过udp汇总到一台gmond上,然后这台gmond汇总所有来自其他gmond的信息并且联合本机信息也发送给ganglia,单播的模式就是push,gmetad等待从gmond中心节点上过来的信息。 gmetad会把从gmond收集到的信息写入rrdtool里面,rrdtool是一个环形数据库,用来存储集群信息,然后在ganglia-web可以去读取rrdtool,并且绘图呈现给前端。

- 阅读剩余部分 -

logstash kibana3显示坐标

按照之前logstash+kibana3 GeoIP地理位置那样配置出来的geo地理位置里有经度和纬度,但是是独立开来的。在官网的demo上可以有coordinates的字段,只要是以数组的形式显示经纬度。下面是logstash的配置,在kibana3上呈现坐标形式。

filter {
geoip {
   source => "source_ip"
   type => "linux-syslog"
   add_tag => [ "geoip" ]
   add_field => [ "[geoip][coordinates]", "%{[geoip][longitude]}" ]
   add_field => [ "[geoip][coordinates]", "%{[geoip][latitude]}"  ]
}

mutate {
    convert => [ "[geoip][coordinates]", "float" ]
}

下面是显示后的效果

- 阅读剩余部分 -

puppet安装和使用

puppet是一种Linux、Unix、windows平台的集中配置管理系统,使用自有的puppet描述语言,可管理配置

文件、用户、cron任务、软件包、系统服务等。puppet把这些系统实体称之为资源,puppet的设计目标

是简化对这些资源的管理以及妥善处理资源间的依赖关系。

puppet采用C/S星状的结构,所有的客户端和一个或几个服务器交互。每个客户端周期的(默认半个小时)

向服务器发送请求,获得其最新的配置信息,保证和该配置信息同步。每个puppet客户端每半小时(可以设

置)连接一次服务器端, 下载最新的配置文件,并且严格按照配置文件来配置服务器. 配置完成以后,puppet客

户端可以反馈给服务器端一个消息. 如果出错,也会给服务器端反馈一个消息.

puppet通信过程中,客户端向服务端请求时端口是8140,若是服务器推送到客户端时通信端口是8319,

所以安装和通信过程要注意防火墙的配置!!!可以先关闭.

更新puppet源


rpm -ivh "http://yum.puppetlabs.com/el/5/products/i386/puppetlabs-release-5-1.noarch.rpm"
rpm -ivh "http://yum.puppetlabs.com/el/5/products/x86_64/puppetlabs-release-5-1.noarch.rpm"
rpm -ivh "http://yum.puppetlabs.com/el/6/products/i386/puppetlabs-release-6-1.noarch.rpm"
rpm -ivh "http://yum.puppetlabs.com/el/5/products/x86_64/puppetlabs-release-5-1.noarch.rpm"

puppet服务端安装


# puppet server install ==>> 主机名 : puppet_server IP : 1.1.1.1

yum -y install ruby ruby-lib ruby-rdoc
yum -y install puppet-server
chkconfig puppet on
service puppetmaster start
/etc/init.d/iptables stop > /dev/null 2>&1

puppet客户端安装


# puppet client install  ==>> 主机名 : puppet_clientIP : 1.1.1.2

echo "1.1.1.1 puppet_server" >> /etc/hosts  (服务端主机名)
yum -y install ruby ruby-lib ruby-rdoc
yum -y install puppet

puppet客户端发送证书


#客户端第一次启动向服务端发送证书,要求签好之后才能通信
puppet agent --no-daemonize --onetime --verbose --debug --server=puppet_server(服务端主机名)

puppet服务端签证书


puppet cert list --all #查看所有客户端的请求(有+号的代表已经签好证书可以通信,没有加号的代表尚未签好证书)
puppet cert --sign puppet_client(客户端主机名) #这条命令加客户端主机名就能签字,自此可以通信

1.下面是一个文件同步的例子


puppet服务端
# vim /etc/puppet/fileserver.conf

# This file consists of arbitrarily named sections/modules
# defining where files are served from and to whom

# Define a section 'files'
# Adapt the allow/deny settings to your needs. Order
# for allow/deny does not matter, allow always takes precedence
# over deny
# [files]
#  path /var/lib/puppet/files
#  allow *.example.com
#  deny *.evil.example.com
#  allow 192.168.0.0/24

# 在下面加一个配置域,名字叫做opencdn,路径是 /etc/puppet
opencdn
  path /etc/puppet
  allow *

# vim /etc/puppet/manifests/site.pp

node default {
        file {
                "/tmp/helloworld.txt" :				==>>推送到客户端的路径文件
                source=>"puppet:///opencdn/test1/helloworld.txt", ==>> 根据/etc/puppet/fileserver.conf里面配置的opecnd域
               							#最终路径是/etc/puppet/test1/helloworld.txt
		recurse=>"true",				==>>可以传送目录
                owner=>"root",
                group=>"root",
                mode=>777,
        }
}

# mkdir /etc/puppet/test1/
# cat /etc/puppet/test1/helloworld.txt
到这里为止puppet的服务端已经设置好了

puppet客户端

# puppet agent --test --server=puppet_server(服务端主机名)
# cat /tmp/helloworld.txt 就OK了

2.puppet从服务端推送系统命令到客户端执行


# vim /etc/puppet/manifests/site.pp

node default {
	exec { "/bin/ls > 1.txt": ==>> 这里对于""里面的字符要求很高,/bin/ls之前都不能有空格,否则就会提示错误
		cwd => "/tmp",	==>> 客户端执行命令的路径
		path=> "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin", ==>> 对于命令的系统路径
	}
}

3.一次推送多个指令


node default {
        exec { "service opencdn restart":
                cwd => "/tmp",
                path=> "/usr/bin:/usr/sbin:/bin:/sbin",
        }
        exec { "ls > 1.txt":
                cwd => "/tmp",
                path=> "/usr/bin:/usr/sbin:/bin:/sbin",
        }
	file {
		"/tmp/helloworld.txt" :
		source=>"puppet:///opencdn/test1/helloworld.txt",
		owner=>"root",
		group=>"root",
		mode=>777,
	}
}

puppet推送到客户端

iptables


puppet客户端

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 8319 -j ACCEPT

puppet服务端

iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 8140 -j ACCEPT

puppet服务端推送 puppet 指令或者文件到客户端的时候可以用 kick 实现

puppet kick -d --hostpuppet_client

但是会出现 error

puppet failed: Connection refused - connect(2)

解决:

puppet客户端


# vim /ect/puppet/puppet.conf ==>> 客户端加入监听

[agent]
listen = true

# vim /ect/puppet/auth.conf

# this one is not stricly necessary, but it has the merit
# to show the default policy which is deny everything else
path /
auth any
allow *

重启 puppet 服务

service puppet restart

puppet服务端


/etc/puppet/namespaceauth.conf

[puppetrunner]
allow *

详情查看

不过按照以上配置好之后,还是会有一些bug,我也不明白是什么原因.

我在服务端设置 site.pp

node default {
        exec { "service opencdn stop":
                cwd => "/tmp",
                path=> "/usr/bin:/usr/sbin:/bin:/sbin",
        }
        exec { "ls > 1.txt":
                cwd => "/tmp",
                path=> "/usr/bin:/usr/sbin:/bin:/sbin",
        }
        file {
                "/tmp/helloworld.txt" :
                source=>"puppet:///opencdn/test1/helloworld.txt",
                owner=>"root",
                group=>"root",
                mode=>777,
        }
}

然后在服务端执行puppet kick -d --hostpuppet_client这个命令的时候,在客户端实际上

只执行了一条命令,其他的几条语句都没有执行.

解决方案


在puppet客户端

# vim /etc/sysconfig/puppet

# The puppetmaster server
PUPPET_SERVER=puppet_server

OpenCDN安装说明


OpenCDN管控中心安装


# wget http://ocdn.me/wp-content/down/ocdn_console_last.tar.gz
# tar -zxvf ocdn_console_last.tar.gz
# cd ocdn_console 
# ./install.sh

1

2

3

4

OpenCDN节点端安装


# wget http://ocdn.me/wp-content/down/ocdn_node_last.tar.gz
# tar -zxvf ocdn_node_last.tar.gz
# cd ocdn_node
# ./install.sh

1

2

OpenCDN管控中心卸载


5

OpenCDN节点端卸载


3

LBNAMED--DNS轮询实现负载均衡

传统的DNS轮询主要实现是在DNS服务器上,做一个CNAME,然后把CNAME解析到不同的IP上,这样就

能基本基于DNS的负载均衡,但是一旦有一台分配到的IP挂了,DNS不会管,还是会返回给客户挂的IP,而

且对于流量的分配也不是很智能,上次看到LBNAMED,折腾了几天,但是没能实现我想要的功能。

LBNAMED(Load Balancing Named)按照网上的说法它能智能的进行DNS轮询,对于轮询列表主机的健

康状态检测,以及负载均衡分配都做了。下面主要说下原理,

  1. 客户端要去访问 www.firefoxbug,net,客户端的DNS修改成我们自己的DNS。
  2. 在我们的DNS Server 会把 www.firefoxbug.net CNAME 成 www.best.firefoxbug.net
  3. DNS服务器会把向LBNAMED Server 发出请求查询 www.best.firefoxbug.net的A记录
  4. LBNAMED Server收到请求后会列出本地www.best.firefoxbug.net的服务器池
  5. LBNAMED Server上的poller根据服务器池的健康状况,通过算法返回给DNS服务器一个最优IP
  6. DNS返回给客户端最优的IP

在服务器池列表上安装的主要是lbcd,这个专门用于向lbnamed主机发送健康状态,LBNAMED服务器安装

的是lbnamed(包含poller检测程序)和Stanford-DNSserver(这是一个库)。下面是基本安装过程

[cc lang="c"]
wget http://archives.eyrie.org/software/system/lbcd-3.4.0.tar.gz
tar -zxvf lbcd-3.4.0.tar.gz
cd lbcd-3.4.0
./configure
make;make install
lbcd #start
lbcd -s #stop

wget http://www.stanford.edu/~riepel/lbnamed/Stanford-DNSserver/Stanford-DNSserver.tar.gz
tar -zxvf Stanford-DNSserver.tar.gz
cd Stanford-DNSserver-1.2.0/
perl Makefile.PL
make
make test
make install

wget http://www.stanford.edu/~riepel/lbnamed/lbnamed-2.3.2.tar.gz
tar -zxvf lbnamed-2.3.2.tar.gz
mv lbnamed-2.3.2 /usr/local/lbnamed
cd /usr/local/lbnamed
cp poller /usr/sbin/
[/cc]

在 /usr/local/lbnamed 目录下是主要的配置文件,

lbnamed.conf 是服务器池,lbnamed是主要的配置文件,详细的查看

http://blog.csdn.net/x5yw/article/details/1729101

iftop安装笔记

磊哥推荐了我一款流量带宽推荐的软件,iftop,我用了,还是不错的。下面是安装过程。

yum install flex byacc libpcap ncurses ncurses-devel libpcap-devel

wget http://www.ex-parrot.com/pdw/iftop/download/iftop-1.0pre2.tar.gz
tar -zxvf iftop-1.0pre2.tar.gz
cd iftop-1.0pre2
./configure
make && make install

- 阅读剩余部分 -

bind 服务器搭建

Linux上DNS上服务器只要是BIND,是伯克利大学开发的。下面是主要的安装以及配置,

yum install bind*

bind安装好之后主要的daemon是named,一般情况下会自动安装好bind-chroot,chroot的存在主要就是为了保护系统的安全性,就算bind被黑了,黑客也只能在chroot的目录里面活动,有点vsftpd里的味道,但是不相同。

- 阅读剩余部分 -

大型网站架构演变和知识体系–<转>

from http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html

 

 

之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行业的同学一点初步的概念 ,文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效果。

架构演变第一步:物理分离webserver和数据库
最开始,由于某些想法,于是在互联网上搭建了一个网站,这个时候甚至有可能主机都是租借的,但由于这篇文章我们只关注架构的演变历程,因此就假设这个时候 已经是托管了一台主机,并且有一定的带宽了,这个时候由于网站具备了一定的特色,吸引了部分人访问,逐渐你发现系统的压力越来越高,响应速度越来越慢,而这个时候比较明显的是数据库和应用互相影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时候,应用也容易出问题,于是进入了第一步演变阶段:将应用和数据库从物理上分离,变成了两台机器,这个时候技术上没有什么新的要求,但你发现确实起到效果了,系统又恢复到以前的响应速度了,并且支撑住了更高的流量,并且不会因为数据库和应用形成互相的影响。

看看这一步完成后系统的图示:


这一步涉及到了这些知识体系:

- 阅读剩余部分 -

通过NAT实现虚拟服务器(VS/NAT)--<转>

转自  http://zh.linuxvirtualserver.org/node/26

由于IPv4中IP地址空间的日益紧张和安全方面的原因,很多网络使用保留IP地址(10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0)[64, 65, 66]。这些地址不在Internet上使用,而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时,就需要采用网络地址转换(Network Address Translation, 以下简称NAT),将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信它们连接一个IP地址,而不同IP地址的服务器组也认为它们是与客户直接相连的。由此,可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

- 阅读剩余部分 -

通过直接路由实现虚拟服务器(VS/DR)--<转>

转自   http://zh.linuxvirtualserver.org/node/28

跟VS/TUN方法相同,VS/DR利用大多数Internet服务的非对称特点,负载调度器中只负责调度请求,而服务器直接将响应返回给客户,可以极大地提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似,但IBM的NetDispatcher是非常昂贵的商品化产品,我们也不知道它内部所使用的机制,其中有些是IBM的专利。

- 阅读剩余部分 -

通过IP隧道实现虚拟服务器(VS/TUN)--<转>

转自 http://zh.linuxvirtualserver.org/node/27

在VS/NAT的集群系统中,请求和响应的数据报文都需要通过负载调度器,当真实服务器的数目在10台和20台之间时,负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点:请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理,即在负载调度器中只负责调度请求而响应直接返回给客户,将极大地提高整个集群系统的吞吐量。

- 阅读剩余部分 -

ARP problem in VS/TUN and VS/DR

In the VS/TUN and VS/DR clusters, the Virtual IP (VIP) addresses are shared by both the load balancer and real servers, because they all configure the VIP address on one of their interfaces. In some configurations that real servers are on the same network that the load balancer accepts request packets, if real servers answers arp request for the VIP, there will be race condition, no winner. Packets for the VIP may be sent to the load balancer at one time, to a real server at another time, to another real server at another time, and so on. Then, connections will be broken, everything will be in a mess, and the whole LVS cluster won't work. Therefore, in the VS/TUN and VS/DR cluster, we must guarantee that only the load balancer answers arp request for the VIP to accept incoming packets for virtual service, and the real servers(in the same network of load balancer) don't answer arp request for the VIP but can process packets destined for the VIP locally.

Linux kernel 2.0.xx doesn't do arp response on loopback alias and tunneling interfaces, it is good for the LVS cluster. However, Linux kernel 2.2.xx does all arp responses of all its IP addresses except the loopback addresses (127.0.0.0/255.0.0.0) and multicast addresses. So, you will probably have problem in VS/TUN or VS/DR cluster of real servers running kernel 2.2.xx with instructions provided in other pages. After kernel 2.2.14, there is the "hidden" flag available to make interfaces hidden from ARP broadcast, thank Julian Anastasov and Alexey Kuznetsov for adding this nice ARP policy in the standard kernel!

from http://www.linuxvirtualserver.org/docs/arp.html