hadoop版本与支持的hbase版本对照表

As of Hive 0.9.0 the HBase integration requires at least HBase 0.92, earlier versions of Hive were working with HBase 0.89/0.90

以下内容来自下载的HBASE-0.94.7的book中( $HBASE_HOME/docs/book/configuration.html)




HBase-0.92.x



HBase-0.94.x


                                 

HBase-0.96

                        


Hadoop-0.20.205



S



X



X



Hadoop-0.22.x



S



X



X



Hadoop-1.0.x



S



S



S



Hadoop-1.1.x



NT



S



S



Hadoop-0.23.x



X



S



NT



Hadoop-2.x



X



S



S


S = 支持且已测试,

X = 不支持,

NT = 可以运行,但未充分测试。



——————————————————————————————————————————



以下内容来自:HBASE官网


HBase-0.92.x

HBase-0.94.x

HBase-0.95

Hadoop-0.20.205

S

X

X

Hadoop-0.22.x

S

X

X

Hadoop-1.0.0-1.0.2[a]

S

S

X

Hadoop-1.0.3+

S

S

S

Hadoop-1.1.x

NT

S

S

Hadoop-0.23.x

X

S

NT

Hadoop-2.x

X

S

S

[a]HBase 至少得hadoop
1.0.3; 在Hadoop早期版本中有一个问题——无法找到编译KerberosUtil。



S = 支持且已测试,

X = 不支持,

NT = 可以运行,但未充分测试。


来源:http://hbase.apache.org/book/configuration.html#hadoop

版权声明:本文为博主原创文章,未经博主允许不得转载。

UNIX 读书笔记01

标准输出流默认不能随着管道流下,可以使用如下脚本:

ls n* 2> errors   

2> 代表标准错误流的处理方式跟随标准输出流保持一致

vim:
1,$s/^/爱/  给从第一行开始每行行头加上”爱“
15,$s/$/爱  给从第15行开始每行行尾加上“爱

1,$s/[0-9]/*/g 将所有的数字替换成*
1,$s/[^*]//g 将所有非*号字符删除掉
1,$s/^.\{10\}//g 删除每行前10个字符
cut:
ls -alh | cut -c1          截取第一个字符
ls -alh | cut -c1-20     截取第1到20个字符

ls -alh | cut -c1,20      截取第1个和第20个字符

ls -alh | cut -c21-      
截取从第21个字符后面所有
cut -d: -f6 passwd     
以逗号切割passwd 取第6段
cut -d: -f1-6 passwd   以逗号切割passwd
取第1到6段
cut -d: -f1-6 passwd   以逗号切割passwd
取第1到6段

cut -d: -f1,6 passwd    以逗号切割passwd
取第1段和第6段


paste:

sed:
sed ‘s/z/*/’ file 将file每行第一个z替换成*
sed ‘s/z/*/g’ file 将file每行所有的z替换成*
sed -n ‘1,4p’ shadow 只显示1~4行
sed -n ‘/ad/p’ shadow 包括ad的行显示出来
sed ‘1,2d’ names  删除文件中的1~2行
sed ‘/z/d’ names 将包含z的行全部删除
sed ‘2a love’ 在第二行后面追加love
sed ‘2i love’ 在第二行前面追加love

 
 
tr:
 tr : ^ < shadow 将所有:字符替换成<字符
 tr ‘[a-z]’ ‘[A-Z]’ <  passwd  将所有小写字符替换成大写字符
tr ‘:’ ‘\11’ < passwd   将所有冒号替换成制表符
 
    已经存储于:h[0][0]c[0][0]
grep:
grep -vn ‘z’ names 显示不包含z的行,并且显示行号
grep -l ‘in’ *.log  在所有的log文件中查找in,只显示文件名
sort:
sort -u names 排序并且去重复
sort -r names 颠倒顺序(倒序)
sort  names -o names 将排序后的结果重新写入源文件,此处不能用重定向操作符.重定向会破坏源文件,导致操作失败
sort -n num 按照算术排序(数字排序)
ls -l | sort -k 5 -n 按照第五列进行算术排序(文件大小排序)
uniq:
sort  num|uniq 将num中重复行删除(使用sort的原因是将num中的重复行排序成连续行)
sort num|uniq -d 将重复行显示出来
sort num | uniq -c 去重并显示重复次数,该命令带与不带-c选项区别就在于是否会显示重复次数
awk:
cat /etc/passwd | awk -F ‘:’ ‘{print $0}’  用;分割,打印整行
awk -F ‘:’ ‘{print $1}’ /etc/passwd 用;分割,打印第一列
awk -F ‘:’ ‘BEGIN {print “print file begin”} {print $1} END {print “print file end”}’  /etc/passwd  用;分割,打印第一列,并且在最前最后加上消息

版权声明:本文为博主原创文章,未经博主允许不得转载。

Linux负载均衡集群之LVS原理

一、 LVS简介

        LVS是Linux Virtual Server的简称,也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目,它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分,在Linux2.4内核以前,使用LVS时必须要重新编译内核以支持LVS功能模块,但是从Linux2.4内核以后,已经完全内置了LVS的各个功能模块,无需给内核打任何补丁,可以直接使用LVS提供的各种功能。

        使用LVS技术要达到的目标是:通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集,它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。

        LVS自从1998年开始,发展到现在已经是一个比较成熟的技术项目了。可以利用LVS技术实现高可伸缩的、高可用的网络服务,例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等,有许多比较著名网站和组织都在使用LVS架设的集群系统,例如:Linux的门户网站(www.linux.com)、向RealPlayer提供音频视频服务而闻名的Real公司(www.real.com)、全球最大的开源网站(sourceforge.net)等。

二、 LVS体系结构

        使用LVS架设的服务器集群系统有三个部分组成:最前端的负载均衡层,用Load
Balancer
表示,中间的服务器群组层,用Server
Array
表示,最底端的数据共享存储层,用Shared
Storage
表示,在用户看来,所有的内部应用都是透明的,用户只是在使用一个虚拟服务器提供的高性能服务。 

下面对LVS的各个组成部分进行详细介绍: 

 Load Balancer层:位于整个集群系统的最前端,有一台或者多台负载调度器(Director Server)组成,LVS模块就安装在Director Server上,而Director的主要作用类似于一个路由器,它含有完成LVS功能所设定的路由表,通过这些路由表把用户的请求分发给Server Array层的应用服务器(Real Server)上。同时,在Director Server上还要安装对Real Server服务的监控模块Ldirectord,此模块用于监测各个Real
Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除,恢复时重新加入。

 Server Array层:由一组实际运行应用服务的机器组成,Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个,每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中,Director Server也可以同时兼任Real Server的角色。

Shared Storage层:是为所有Real Server提供共享存储空间和内容一致性的存储区域,在物理上,一般有磁盘阵列设备组成,为了提供内容的一致性,一般可以通过NFS网络文件系统共享数据,但是NFS在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,例如Red hat的GFS文件系统,oracle提供的OCFS2文件系统等。

        从整个LVS结构可以看出,Director Server是整个LVS的核心,目前,用于Director Server的操作系统只能是Linux和FreeBSD,linux2.6内核不用任何设置就可以支持LVS功能,而FreeBSD作为Director Server的应用还不是很多,性能也不是很好。

对于Real Server,几乎可以是所有的系统平台,Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

三、  LVS集群的特点

3.1  IP负载均衡与负载调度算法

1.IP负载均衡技术

        负载均衡技术有很多实现方案,有基于DNS域名轮流解析的方法、有基于客户端调度访问的方法、有基于应用层系统负载的调度方法,还有基于IP地址的调度方法,在这些负载调度算法中,执行效率最高的是IP负载均衡技术。

       LVS的IP负载均衡技术是通过IPVS模块来实现的,IPVS是LVS集群系统的核心软件,它的主要作用是:安装在Director Server上,同时在Director Server上虚拟出一个IP地址,用户必须通过这个虚拟的IP地址访问服务。这个虚拟IP一般称为LVS的VIP,即Virtual IP。访问的请求首先经过VIP到达负载调度器,然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求。

        当用户的请求到达负载调度器后,调度器如何将请求发送到提供服务的Real Server节点,而Real Server节点如何返回数据给用户,是IPVS实现的重点技术,IPVS实现负载均衡机制有三种,分别是NAT、TUN和DR,详述如下: 

 VS/NAT: 即(Virtual Server via Network Address Translation)

        也就是网络地址翻译技术实现虚拟服务器,当用户请求到达调度器时,调度器将请求报文的目标地址(即虚拟IP地址)改写成选定的Real Server地址,同时报文的目标端口也改成选定的Real Server的相应端口,最后将报文请求发送到选定的Real Server。在服务器端得到数据后,Real Server返回数据给用户时,需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户,完成整个负载调度过程。

        可以看出,在NAT方式下,用户请求和响应报文都必须经过Director Server地址重写,当用户请求越来越多时,调度器的处理能力将称为瓶颈。

VS/TUN:即(Virtual Server via IP Tunneling) 

        也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样,只是它的报文转发方法不同,VS/TUN方式中,调度器采用IP隧道技术将用户请求转发到某个Real Server,而这个Real Server将直接响应用户的请求,不再经过前端调度器,此外,对Real Server的地域位置没有要求,可以和Director Server位于同一个网段,也可以是独立的一个网络。因此,在TUN方式中,调度器将只处理用户的报文请求,集群系统的吞吐量大大提高。

 VS/DR: 即(Virtual Server via Direct Routing) 

        也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样,但它的报文转发方法又有不同,VS/DR通过改写请求报文的MAC地址,将请求发送到Real Server,而Real Server将响应直接返回给客户,免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的,但是必须要求Director
Server与Real Server都有一块网卡连在同一物理网段上。

2.负载调度算法

        上面我们谈到,负载调度器是根据各个服务器的负载情况,动态地选择一台Real Server响应用户请求,那么动态选择是如何实现呢,其实也就是我们这里要说的负载调度算法,根据不同的网络服务需求和服务器配置,IPVS实现了如下八种负载调度算法,这里我们详细讲述最常用的四种调度算法,剩余的四种调度算法请参考其它资料。

轮叫调度(Round Robin)[最基本的算法]

        “轮叫”调度也叫1:1调度,调度器通过“轮叫”调度算法将外部用户请求按顺序1:1的分配到集群中的每个Real Server上,这种算法平等地对待每一台Real Server,而不管服务器上实际的负载状况和连接状态。 

加权轮叫调度(Weighted Round Robin)[适用不同性能的Real Server同时存在的情况] 

        “加权轮叫”调度算法是根据Real Server的不同处理能力来调度访问请求。可以对每台Real Server设置不同的调度权值,对于性能相对较好的Real Server可以设置较高的权值,而对于处理能力较弱的Real Server,可以设置较低的权值,这样保证了处理能力强的服务器处理更多的访问流量。充分合理的利用了服务器资源。同时,调度器还可以自动查询Real Server的负载情况,并动态地调整其权值。 

最少链接调度(Least Connections) [适用于Real Server性能相近的情况]

        “最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用“最小连接”调度算法可以较好地均衡负载。 

加权最少链接调度(Weighted Least Connections) [适用不同性能的Real Server同时存在的情况] 

        “加权最少链接调度”是“最少连接调度”的超集,每个服务节点可以用相应的权值表示其处理能力,而系统管理员可以动态的设置相应的权值,缺省权值为1,加权最小连接调度在分配新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。

其它四种调度算法分别为:基于局部性的最少链接(Locality-Based Least Connections)、带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)、目标地址散列(Destination Hashing)和源地址散列(Source Hashing),对于这四种调度算法的含义,本文不再讲述,如果想深入了解这其余四种调度策略的话,可以登陆LVS中文站点zh.linuxvirtualserver.org,查阅更详细的信息。

3.2 高可用性

        LVS是一个基于内核级别的应用软件,因此具有很高的处理性能,用LVS构架的负载均衡集群系统具有优秀的处理能力,每个服务节点的故障不会影响整个系统的正常使用,同时又实现负载的合理均衡,使应用具有超高负荷的服务能力,可支持上百万个并发连接请求。如配置百兆网卡,采用VS/TUN或VS/DR调度技术,整个集群系统的吞吐量可高达1Gbits/s;如配置千兆网卡,则系统的最大吞吐量可接近10Gbits/s。

3.3 高可靠性

        LVS负载均衡集群软件已经在企业、学校等行业得到了很好的普及应用,国内外很多大型的、关键性的web站点也都采用了LVS集群软件,所以它的可靠性在实践中得到了很好的证实。有很多以LVS做的负载均衡系统,运行很长时间,从未做过重新启动。这些都说明了LVS的高稳定性和高可靠性。

3.4 适用环境

        LVS对前端Director Server目前仅支持Linux和FreeBSD系统,但是支持大多数的TCP和UDP协议,支持TCP协议的应用有:HTTP,HTTPS ,FTP,SMTP,,POP3,IMAP4,PROXY,LDAP,SSMTP等等。支持UDP协议的应用有:DNS,NTP,ICP,视频、音频流播放协议等。

         LVS对Real Server的操作系统没有任何限制,Real Server可运行在任何支持TCP/IP的操作系统上,包括Linux,各种Unix(如FreeBSD、Sun Solaris、HP Unix等),Mac/OS和Windows等。

3.5 开源软件 

        LVS集群软件是按GPL(GNU Public License)许可证发行的自由软件,因此,使用者可以得到软件的源代码,并且可以根据自己的需要进行各种修改,但是修改必须是以GPL方式发行。

本文出自 “技术成就梦想” 博客,请务必保留此出处http://ixdba.blog.51cto.com/2895551/552947

 

四层和七层负载均衡

简单理解四层和七层负载均衡:

所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说,二层负载均衡会通过一个虚拟MAC地址接收请求,然后再分配到真实的MAC地址;三层负载均衡会通过一个虚拟IP地址接收请求,然后再分配到真实的IP地址;四层通过虚拟IP+端口接收请求,然后再分配到真实的服务器;七层通过虚拟的URL或主机名接收请求,然后再分配到真实的服务器。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

所谓的四到七层负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡,就是通过发布三层的IP地址(VIP),然后加四层的端口号,来决定哪些流量需要做负载均衡,对需要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个连接的所有流量都同样转发到同一台服务器处理。 七层的负载均衡,就是在四层的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,比如同一个WEB服务器的负载均衡,除了根据VIP加80端口辨别是否需要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,如果你的web服务器分成两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就可以当用户来访问你的域名时,自动辨别用户语言,然后选择对应的语言服务器组进行负载均衡处理。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层,实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外,还有分析应用层的信息,如HTTP协议URI或Cookie信息。

1、负载均衡分为L4 switch(四层交换),即在OSI第4层工作,就是TCP层啦。此种Load Balance不理解应用协议(如HTTP/FTP/MySQL等等)。

例子:LVS,F5

2、另一种叫做L7 switch(七层交换),OSI的最高层,应用层。此时,该Load Balancer能理解应用协议。

例子:  haproxy,MySQL Proxy

注意:上面的很多Load Balancer既可以做四层交换,也可以做七层交换。

负载均衡设备也常被称为”四到七层交换机”,那么四层和七层两者到底区别在哪里?

第一,技术原理上的区别。

所谓四层负载均衡,也就是主要通过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

以常见的TCP为例,负载均衡设备在接收到第一个来自客户端的SYN 请求时,即通过上述方式选择一个最佳的服务器,并对报文中目标IP地址进行修改(改为后端服务器IP),直接转发给该服务器。TCP的连接建立,即三次握手是客户端和服务器直接建立的,负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下,为保证服务器回包可以正确返回给负载均衡设备,在转发报文的同时可能还会对报文原来的源地址进行修改。所谓七层负载均衡,也称为“内容交换”,也就是主要通过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。

以常见的TCP为例,负载均衡设备如果要根据真正的应用层内容再选择服务器,只能先代理最终的服务器和客户端建立连接(三次握手)后,才可能接受到客户端发送的真正应用层内容的报文,然后再根据该报文中的特定字段,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器。负载均衡设备在这种情况下,更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看,七层负载均衡明显的对负载均衡设备的要求更高,处理七层的能力也必然会低于四层模式的部署方式。

第二,应用场景的需求。

七层应用负载的好处,是使得整个网络更”智能化“。例如访问一个网站的用户流量,可以通过七层的方式,将对图片类的请求转发到特定的图片服务器并可以使用缓存技术;将对文字类的请求可以转发到特定的文字服务器并可以使用压缩技术。当然这只是七层应用的一个小案例,从技术原理上,这种方式可以对客户端的请求和服务器的响应进行任意意义上的修改,极大的提升了应用系统在网络层的灵活性。很多在后台,(例如Nginx或者Apache)上部署的功能可以前移到负载均衡设备上,例如客户请求中的Header重写,服务器响应中的关键字过滤或者内容插入等功能。

另外一个常常被提到功能就是安全性。网络中最常见的SYN Flood攻击,即黑客控制众多源客户端,使用虚假IP地址对同一目标发送SYN攻击,通常这种攻击会大量发送SYN报文,耗尽服务器上的相关资源,以达到Denial of Service(DoS)的目的。从技术原理上也可以看出,四层模式下这些SYN攻击都会被转发到后端的服务器上;而七层模式下这些SYN攻击自然在负载均衡设备上就截止,不会影响后台服务器的正常运营。另外负载均衡设备可以在七层层面设定多种策略,过滤特定报文,例如SQL Injection等应用层面的特定攻击手段,从应用层面进一步提高系统整体安全。

现在的7层负载均衡,主要还是着重于应用HTTP协议,所以其应用范围主要是众多的网站或者内部信息平台等基于B/S开发的系统。 4层负载均衡则对应其他TCP应用,例如基于C/S开发的ERP等系统。

第三,七层应用需要考虑的问题。 

1:是否真的必要,七层应用的确可以提高流量智能化,同时必不可免的带来设备配置复杂,负载均衡压力增高以及故障排查上的复杂性等问题。在设计系统时需要考虑四层七层同时应用的混杂情况。

2:是否真的可以提高安全性。例如SYN Flood攻击,七层模式的确将这些流量从服务器屏蔽,但负载均衡设备本身要有强大的抗DDoS能力,否则即使服务器正常而作为中枢调度的负载均衡设备故障也会导致整个应用的崩溃。

3:是否有足够的灵活度。七层应用的优势是可以让整个应用的流量智能化,但是负载均衡设备需要提供完善的七层功能,满足客户根据不同情况的基于应用的调度。最简单的一个考核就是能否取代后台Nginx或者Apache等服务器上的调度功能。能够提供一个七层应用开发接口的负载均衡设备,可以让客户根据需求任意设定功能,才真正有可能提供强大的灵活性和智能性。


本文出自 “ADC技术博客” 博客,请务必保留此出处http://virtualadc.blog.51cto.com/3027116/591396

负载均衡四七层介绍:

负载均衡(Load Balance)建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。

  负载均衡有两方面的含义:首先,大量的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间;其次,单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到大幅度提高。

  本文所要介绍的负载均衡技术主要是指在均衡服务器群中所有服务器和应用程序之间流量负载的应用,目前负载均衡技术大多数是用于提高诸如在Web服务器、FTP服务器和其它关键任务服务器上的Internet服务器程序的可用性和可伸缩性。

负载均衡技术分类

  目前有许多不同的负载均衡技术用以满足不同的应用需求,下面从负载均衡所采用的设备对象、应用的网络层次(指OSI参考模型)及应用的地理结构等来分类。

软/硬件负载均衡

  软件负载均衡解决方案是指在一台或多台服务器相应的操作系统上安装一个或多个附加软件来实现负载均衡,如DNS Load Balance,CheckPoint Firewall-1 ConnectControl等,它的优点是基于特定环境,配置简单,使用灵活,成本低廉,可以满足一般的负载均衡需求。

  软件解决方案缺点也较多,因为每台服务器上安装额外的软件运行会消耗系统不定量的资源,越是功能强大的模块,消耗得越多,所以当连接请求特别大的时候,软件本身会成为服务器工作成败的一个关键;软件可扩展性并不是很好,受到操作系统的限制;由于操作系统本身的Bug,往往会引起安全问题。

  硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备,这种设备我们通常称之为负载均衡器,由于专门的设备完成专门的任务,独立于操作系统,整体性能得到大量提高,加上多样化的负载均衡策略,智能化的流量管理,可达到最佳的负载均衡需求。 

  负载均衡器有多种多样的形式,除了作为独立意义上的负载均衡器外,有些负载均衡器集成在交换设备中,置于服务器与Internet链接之间,有些则以两块网络适配器将这一功能集成到PC中,一块连接到Internet上,一块连接到后端服务器群的内部网络上。

  一般而言,硬件负载均衡在功能、性能上优于软件方式,不过成本昂贵。

本地/全局负载均衡 

  负载均衡从其应用的地理结构上分为本地负载均衡(Local Load Balance)和全局负载均衡(Global Load Balance,也叫地域负载均衡),本地负载均衡是指对本地的服务器群做负载均衡,全局负载均衡是指对分别放置在不同的地理位置、有不同网络结构的服务器群间作负载均衡。

  本地负载均衡能有效地解决数据流量过大、网络负荷过重的问题,并且不需花费昂贵开支购置性能卓越的服务器,充分利用现有设备,避免服务器单点故障造成数据流量的损失。其有灵活多样的均衡策略把数据流量合理地分配给服务器群内的服务器共同负担。即使是再给现有服务器扩充升级,也只是简单地增加一个新的服务器到服务群中,而不需改变现有网络结构、停止现有的服务。 

  全局负载均衡主要用于在一个多区域拥有自己服务器的站点,为了使全球用户只以一个IP地址或域名就能访问到离自己最近的服务器,从而获得最快的访问速度,也可用于子公司分散站点分布广的大公司通过Intranet(企业内部互联网)来达到资源统一合理分配的目的。

网络层次上的负载均衡

  针对网络上负载过重的不同瓶颈所在,从网络的不同层次入手,我们可以采用相应的负载均衡技术来解决现有问题。 

  随着带宽增加,数据流量不断增大,网络核心部分的数据接口将面临瓶颈问题,原有的单一线路将很难满足需求,而且线路的升级又过于昂贵甚至难以实现,这时就可以考虑采用链路聚合(Trunking)技术。

  链路聚合技术(第二层负载均衡)将多条物理链路当作一条单一的聚合逻辑链路使用,网络数据流量由聚合逻辑链路中所有物理链路共同承担,由此在逻辑上增大了链路容量,使其能满足带宽增加的需求。

  现代负载均衡技术通常操作于网络的第四层或第七层。第四层负载均衡将一个Internet上合法注册的IP地址映射为多个内部服务器的IP地址,对每次 TCP连接请求动态使用其中一个内部IP地址,达到负载均衡的目的。在第四层交换机中,此种均衡技术得到广泛的应用,一个目标地址是服务器群VIP(虚拟 IP,Virtual IP address)连接请求的数据包流经交换机,交换机根据源端和目的IP地址、TCP或UDP端口号和一定的负载均衡策略,在服务器IP和VIP间进行映射,选取服务器群中最好的服务器来处理连接请求。

  第七层负载均衡控制应用层服务的内容,提供了一种对访问流量的高层控制方式,适合对HTTP服务器群的应用。第七层负载均衡技术通过检查流经的HTTP报头,根据报头内的信息来执行负载均衡任务。 

  第七层负载均衡优点表现在如下几个方面: 

通过对HTTP报头的检查,可以检测出HTTP400、500和600系列的错误信息,因而能透明地将连接请求重新定向到另一台服务器,避免应用层故障。

可根据流经的数据类型(如判断数据包是图像文件、压缩文件或多媒体文件格式等),把数据流量引向相应内容的服务器来处理,增加系统性能。

能根据连接请求的类型,如是普通文本、图象等静态文档请求,还是asp、cgi等的动态文档请求,把相应的请求引向相应的服务器来处理,提高系统的性能及安全性。

  第七层负载均衡受到其所支持的协议限制(一般只有HTTP),这样就限制了它应用的广泛性,并且检查HTTP报头会占用大量的系统资源,势必会影响到系统的性能,在大量连接请求的情况下,负载均衡设备自身容易成为网络整体性能的瓶颈。

负载均衡策略

  在实际应用中,我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器,而不管服务器是否宕机。而是想使Pentium III服务器比Pentium II能接受更多的服务请求,一台处理服务请求较少的服务器能分配到更多的服务请求,出现故障的服务器将不再接受服务请求直至故障恢复等等。

  选择合适的负载均衡策略,使多个设备能很好的共同完成任务,消除或避免现有网络负载分布不均、数据流量拥挤反应时间长的瓶颈。在各负载均衡方式中,针对不同的应用需求,在OSI参考模型的第二、三、四、七层的负载均衡都有相应的负载均衡策略。

  负载均衡策略的优劣及其实现的难易程度有两个关键因素:一、负载均衡算法,二、对网络系统状况的检测方式和能力。 

  考虑到服务请求的不同类型、服务器的不同处理能力以及随机选择造成的负载分配不均匀等问题,为了更加合理的把负载分配给内部的多个服务器,就需要应用相应的能够正确反映各个服务器处理能力及网络状态的负载均衡算法

轮循均衡(Round Robin):每一次来自网络的请求轮流分配给内部中的服务器,从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。

权重轮循均衡(Weighted Round Robin):根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求。例如:服务器A的权值被设计成1,B的权值是 3,C的权值是6,则服务器A、B、C将分别接受到10%、30%、60%的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重。

随机均衡(Random):把来自网络的请求随机分配给内部中的多个服务器。

权重随机均衡(Weighted Random):此种均衡算法类似于权重轮循算法,不过在处理请求分担时是个随机选择的过程。

响应速度均衡(Response Time):负载均衡设备对内部各服务器发出一个探测请求(例如Ping),然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态,但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间,而不是客户端与服务器间的最快响应时间。

最少连接数均衡(Least Connection):客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间加长,如果采用简单的轮循或随机均衡算法,每一台服务器上的连接进程可能会产生极大的不同,并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录,记录当前该服务器正在处理的连接数量,当有新的服务连接请求时,将把当前请求分配给连接数最少的服务器,使均衡更加符合实际情况,负载更加均衡。此种均衡算法适合长时处理的请求服务,如FTP。 

处理能力均衡:此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号、CPU数量、内存大小及当前连接数等换算而成)最轻的服务器,由于考虑到了内部服务器的处理能力及当前网络运行状况,所以此种均衡算法相对来说更加精确,尤其适合运用到第七层(应用层)负载均衡的情况下。

DNS响应均衡(Flash DNS):在Internet上,无论是HTTP、FTP或是其它的服务请求,客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下,分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求,并在同一时间内把此域名解析成各自相对应服务器的IP地址(即与此负载均衡设备在同一位地理位置的服务器的IP地址)并返回给客户端,则客户端将以最先收到的域名解析IP地址来继续请求服务,而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下,对本地负载均衡是没有意义的。

  尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载,但如果负载均衡策略没有对网络系统状况的检测方式和能力,一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下,负载均衡设备依然把一部分数据流量引向那台服务器,这势必造成大量的服务请求被丢失,达不到不间断可用性的要求。所以良好的负载均衡策略应有对网络故障、服务器系统故障、应用服务故障的检测方式和能力

Ping侦测:通过ping的方式检测服务器及网络系统状况,此种方式简单快速,但只能大致检测出网络及服务器上的操作系统是否正常,对服务器上的应用服务检测就无能为力了。

TCP Open侦测:每个服务都会开放某个通过TCP连接,检测服务器上某个TCP端口(如Telnet的23口,HTTP的80口等)是否开放来判断服务是否正常。

HTTP URL侦测:比如向HTTP服务器发出一个对main.html文件的访问请求,如果收到错误信息,则认为服务器出现故障。

  负载均衡策略的优劣除受上面所讲的两个因素影响外,在有些应用情况下,我们需要将来自同一客户端的所有请求都分配给同一台服务器去负担,例如服务器将客户端注册、购物等服务请求信息保存的本地数据库的情况下,把客户端的子请求分配给同一台服务器来处理就显的至关重要了。有两种方式可以解决此问题,一是根据IP地址把来自同一客户端的多次请求分配给同一台服务器处理,客户端IP地址与服务器的对应信息是保存在负载均衡设备上的;二是在客户端浏览器 cookie内做独一无二的标识来把多次请求分配给同一台服务器处理,适合通过代理服务器上网的客户端。

  还有一种路径外返回模式(Out of Path Return),当客户端连接请求发送给负载均衡设备的时候,中心负载均衡设备将请求引向某个服务器,服务器的回应请求不再返回给中心负载均衡设备,即绕过流量分配器,直接返回给客户端,因此中心负载均衡设备只负责接受并转发请求,其网络负担就减少了很多,并且给客户端提供了更快的响应时间。此种模式一般用于HTTP服务器群,在各服务器上要安装一块虚拟网络适配器,并将其IP地址设为服务器群的VIP,这样才能在服务器直接回应客户端请求时顺利的达成三次握手。

负载均衡实施要素

  负载均衡方案应是在网站建设初期就应考虑的问题,不过有时随着访问流量的爆炸性增长,超出决策者的意料,这也就成为不得不面对的问题。当我们在引入某种负载均衡方案乃至具体实施时,像其他的许多方案一样,首先是确定当前及将来的应用需求,然后在代价与收效之间做出权衡。

  针对当前及将来的应用需求,分析网络瓶颈的不同所在,我们就需要确立是采用哪一类的负载均衡技术,采用什么样的均衡策略,在可用性、兼容性、安全性等等方面要满足多大的需求,如此等等。 

  不管负载均衡方案是采用花费较少的软件方式,还是购买代价高昂在性能功能上更强的第四层交换机、负载均衡器等硬件方式来实现,亦或其他种类不同的均衡技术,下面这几项都是我们在引入均衡方案时可能要考虑的问题:

性能:性能是我们在引入均衡方案时需要重点考虑的问题,但也是一个最难把握的问题。衡量性能时可将每秒钟通过网络的数据包数目做为一个参数,另一个参数是均衡方案中服务器群所能处理的最大并发连接数目,但是,假设一个均衡系统能处理百万计的并发连接数,可是却只能以每秒2个包的速率转发,这显然是没有任何作用的。性能的优劣与负载均衡设备的处理能力、采用的均衡策略息息相关,并且有两点需要注意:一、均衡方案对服务器群整体的性能,这是响应客户端连接请求速度的关键;二、负载均衡设备自身的性能,避免有大量连接请求时自身性能不足而成为服务瓶颈。有时我们也可以考虑采用混合型负载均衡策略来提升服务器群的总体性能,如DNS负载均衡与NAT负载均衡相结合。另外,针对有大量静态文档请求的站点,也可以考虑采用高速缓存技术,相对来说更节省费用,更能提高响应性能;对有大量ssl/xml内容传输的站点,更应考虑采用ssl/xml加速技术。

可扩展性:IT技术日新月异,一年以前最新的产品,现在或许已是网络中性能最低的产品;业务量的急速上升,一年前的网络,现在需要新一轮的扩展。合适的均衡解决方案应能满足这些需求,能均衡不同操作系统和硬件平台之间的负载,能均衡HTTP、邮件、新闻、代理、数据库、防火墙和 Cache等不同服务器的负载,并且能以对客户端完全透明的方式动态增加或删除某些资源。

灵活性:均衡解决方案应能灵活地提供不同的应用需求,满足应用需求的不断变化。在不同的服务器群有不同的应用需求时,应有多样的均衡策略提供更广泛的选择。

可靠性:在对服务质量要求较高的站点,负载均衡解决方案应能为服务器群提供完全的容错性和高可用性。但在负载均衡设备自身出现故障时,应该有良好的冗余解决方案,提高可靠性。使用冗余时,处于同一个冗余单元的多个负载均衡设备必须具有有效的方式以便互相进行监控,保护系统尽可能地避免遭受到重大故障的损失。

易管理性:不管是通过软件还是硬件方式的均衡解决方案,我们都希望它有灵活、直观和安全的管理方式,这样便于安装、配置、维护和监控,提高工作效率,避免差错。在硬件负载均衡设备上,目前主要有三种管理方式可供选择:一、命令行接口(CLI:Command Line Interface),可通过超级终端连接负载均衡设备串行接口来管理,也能telnet远程登录管理,在初始化配置时,往往要用到前者;二、图形用户接口(GUI:Graphical User Interfaces),有基于普通web页的管理,也有通过Java Applet
进行安全管理,一般都需要管理端安装有某个版本的浏览器;三、SNMP(Simple Network Management Protocol,简单网络管理协议)支持,通过第三方网络管理软件对符合SNMP标准的设备进行管理。

eclipse 远程调试hadoop代码

zxxJPDA 简介
Sun Microsystem 的 Java Platform Debugger Architecture (JPDA) 技术是一个多层架构,使您能够在各种环境中轻松调试 Java 应用程序。JPDA 由两个接口(分别是 JVM Tool Interface 和 JDI)、一个协议(Java Debug Wire Protocol)和两个用于合并它们的软件组件(后端和前端)组成。它的设计目的是让调试人员在任何环境中都可以进行调试。
更详细的介绍,您可以参考使用 Eclipse 远程调试 Java 应用程序
JDWP 设置
JVM本身就支持远程调试,Eclipse也支持JDWP,只需要在各模块的JVM启动时加载以下参数:
dt_socket表示使用套接字传输。
address=8000
JVM在8000端口上监听请求,这个设定为一个不冲突的端口即可。
server=y
y表示启动的JVM是被调试者。如果为n,则表示启动的JVM是调试器。
suspend=y
y表示启动的JVM会暂停等待,直到调试器连接上才继续执行。suspend=n,则JVM不会暂停等待。
需要在$HADOOP_HOME/etc/hadoop/hadoop-env.sh文件的最后添加你想debug的进程
#远程调试namenode
export HADOOP_NAMENODE_OPTS=”-agentlib:jdwp=transport=dt_socket,address=8888,server=y,suspend=y”
#远程调试datanode
export HADOOP_DATANODE_OPTS=”-agentlib:jdwp=transport=dt_socket,address=9888,server=y,suspend=y”
#远程调试RM
export YARN_RESOURCEMANAGER_OPTS=”-agentlib:jdwp=transport=dt_socket,address=10888,server=y,suspend=y”
#远程调试NM
export YARN_NODEMANAGER_OPTS=”-agentlib:jdwp=transport=dt_socket,address=10888,server=y,suspend=y”

版权声明:本文为博主原创文章,未经博主允许不得转载。

iptables 简单配置示例

iptables防火墙简介
iptables/netfilter是Linux下自带的一款免费且优秀的基于包过滤的防火墙工具,它的功能十分强大,使用非常灵活,
可以对流入、流出、流经服务器的数据包进行精细的控制。
iptables是Linux2.4及2.6内核中集成的模块。
防火墙果汁的执行顺序默认是从前到后依次执行,遇到匹配的规则就不在继续向下检查,若果遇到不匹配的规则会继续向下执行,
匹配上了拒绝规则也是匹配,因此不再继续。
在iptables中有三个最常用的表,分别是filter,nat和mangle,每一个表中都包含了各自不同的链。
filter表:
filter是iptables默认使用的表,负责对流入、流出本机的数据包进行过滤,该表中定义了3个链:
  1. INPOUT 
    负责过滤所有目标地址是本机地址的数据包,就是过滤进入主机的数据包。
  2. FORWARD
    负责转发流经本机但不进入本机的数据包,起到转发的作用。
  3. OUTPUT
    负责处理所有源地址是本机地址的数据包,就是处理从主机发出去的数据包。
NAT表:
NAT是Network Address Translation的缩写,是网络地址转换的意思,用来负责来源与目的ip地址和port的转换。
一般用于局域网多人共享上网或将内网ip映射成外网ip+port转换的功能。该表主要包含3个链:
OUTPUT
和主机发出去的数据包有关,在数据包路由之前改变主机产生的数据包的目的地址。
PREROUTING
在数据包刚到达防火墙时,进行路由判断之前执行的规则。改变包的目的地址(DNAT功能)、端口等
POSTROUTING
在数据包离开防火墙时,进行路由判断之后执行的规则。改变包的源地址(SNAT功能)、端口等
Mangle表:
Mangle表主要负责修改数据包中的特殊路由标记,如TTL、TOS、MARK等。这个表中包含了5个链:INPUT、FORWARD、OUTPUT、PREROUTING、POSTROUTING,
这张表与特殊的标记相关,一般情况我们很少使用。
iptables:
    0.0.0.0 所有ip

#查看帮助
iptables -h
man iptables
列出iptables规则
iptables -L -n
列出iptables规则并显示规则编号
iptables -L -n –line-numbers
列出iptables nat表规则(默认是filter表)
iptables -L -n -t nat
清除默认规则(注意默认是filter表,如果对nat表操作要加-t nat)
#清楚所有规则
iptables -F
#删除用户自定义的链
iptables -X
#将链的计数器清零
iptables -Z
#重启iptables发现规则依然存在,因为没有保存
service iptables restart
#保存配置
service iptables save
#禁止ssh登陆(若果服务器在机房,一定要小心)
iptables -A INPUT -p tcp –dport 22 -j DROP
#清除规则
iptables -D INPUT -p tcp –dport 22 -j DROP
iptables -D INPUT [line-number]    // 根据
-A, –append chain 追加到规则的最后一条
-D, –delete chain [rulenum] Delete rule rulenum (1 = first) from chain
-I, –insert chain [rulenum] Insert in chain as rulenum (default 1=first) 添加到规则的第一条
-p, –proto  proto protocol: by number or name, eg. ‘tcp’,常用协议有tcp、udp、icmp、all
-j, –jump target 常见的行为有ACCEPT、DROP和REJECT三种,但一般不用REJECT,会带来安全隐患
注意:INPUT和DROP这样的关键字需要大写
#禁止192.168.10.0网段从eth0网卡接入
iptables -A INPUT -p tcp -i eth0 -s 192.168.10.0/24 -j DROP
#禁止ip地址非192.168.10.10的所有类型数据接入
iptables -A INPUT ! -s 192.168.10.10 -j DROP
#禁止ip地址非192.168.10.10的ping请求
iptables -I INPUT -p icmp –icmp-type 8 ! -s 192.168.98.10 -j DROP
#扩展匹配:1.隐式扩展 2.显示扩展
#隐式扩展
-p tcp
–sport PORT 源端口
–dport PORT 目标端口
#显示扩展:使用额外的匹配规则
-m EXTENSTION –SUB-OPT
-p tcp –dport 22 与 -p tcp -m tcp –dport 22功能相同
state:状态扩展,接口ip_contrack追踪会话状态
NEW:新的连接请求
ESTABLISHED:已建立的连接请求
INVALID:非法连接
RELATED:相关联的连接
#匹配端口范围
iptables -I INPUT -p tcp –dport 22:80 -j DROP
#匹配多个端口
iptables -I INPUT -p tcp -m multiport –dport 22,80 -j DROP
#不允许源端口为80的数据流出
iptables -I OUTPUT -p tcp –sport 80 -j DROP
#服务器一般默认规则问拒绝,如果想允某种流量通过需要额外添加
                         _____
Incoming                 /     \         Outgoing
       –>[Routing ]—>|FORWARD|——->
          [Decision]     \_____/        ^
               |                        |
               v                       ____
              ___                     /    \
             /   \                  |OUTPUT|
            |INPUT|                  \____/
             \___/                      ^
               |                        |
                —-> Local Process —-
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-6.html
配置防火墙:
两种模式:电影院模式和逛公园模式
配置一个生产环境的防火墙
#1.清空所有规则
iptables -F
iptables -Z
iptables -X
#2.配置允许ssh协议的22端口进入
iptables -A INPUT -p tcp –dport 22 -s 192.168.10.0/24 -j ACCEPT
#3.配置允许lo接口数据的进出
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
#4.设置默认的进出规则,DROP掉INPUT链和FORWARD链,保留OUTPUT链
iptables –policy OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
#5.开启信任的IP段
iptables -A INPUT -p all -s 192.168.10.0/24 -j ACCEPT
#6.开放http的80端口
iptables -A INPUT -p tcp –dport 80 -j ACCEPT
#7.允许icmp类型协议通过
iptables -A INPUT -p icmp –icmp-type 8 -j ACCEPT
#8.允许关联状态包进出
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
#对于FTP而言,就需要 RELATED 才能实现 21 端口白名单,如不加此项需要额外开放端口,而那些额外开放端口是不受连接状态保护的。
#9.保存iptables配置到文件
service iptables save
iptables –policy INPUT DROP // 将INPUT表策略修改为DROP
iptables的NAT功能:将Linux服务器配置为上网网关和端口映射功能
上网网关:就是将Linux服务器配置成路由器或者网关,实现其他服务器能通过这台服务器进行上网的功能,如果需要实在该功能,就要借助iptables的nat表
NAT的两种方式:DNAT和SNAT
SNAT的全称是Source Network Address Translation,意思是源网络地址转换,这是一种改变数据包源ip地址等功能的技术,
经常用来实现使多台计算机共享一个Internet地址访问互联网的功能,如x小区宽带、企业内部机器上网。(nat表的POSTROUTING)
DNAT的全称是Destination Network Address Translation,意思是目的网络地址转换,DNAT是一种改变数据包目的ip地址等功能的技术,它可以使多台服务器共享一个ip地址连入Internet,并且继续对外提供服务。通过对同一个外部ip地址分配不同的端口,可以映射到不同的内部服务器的ip和端口,从而实现提供各种服务的目的。除了进行端口映射外,还可以配合SNAT的功能,来实现类似防火墙设备才能实现的DMZ功能,即ip的一对一映射。(nat表的PREROUTING)
SNAT实验步骤:
1.准备两台服务器,其中一台服务器作为网关服务器,这台服务器要有两块网卡。另外一台作为内网服务器,有一块网卡。
2.网关服务器内核文件/etc/sysctl.conf需要开启转发功能。编辑/etc/sysctl.conf修改内容为net.ipv4.ip_forward=1,然后执行sysctl -p使修改立即生效。
3.设置iptables的filter表的FORWARD链允许转发。iptables  iptables -P FORWARD ACCEPT
4.将内网服务器的网关设置为网关服务器的内网ip地址
5.在网关服务器的iptables的nat表中加一条规则:iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j SNAT –to-source 172.16.50.128
6.验证:ping 8.8.8.8可以ping通,但是ping百度不同,需要配置DNS
DNAT实验步骤
在网关服务器的iptables的nat表中加一条规则:
iptables -t nat -A PREROUTING -d 172.16.50.128 -p tcp -m tcp –dport 80 -j DNAT –to-destination 192.168.10.129:80
一对一映射:
ifconfig eth0:1 172.16.50.100/24
// 外网对该IP所有端口进行转发
iptables -t nat -A PREROUTING -d 172.16.50.100 -j DNAT –to-destination 192.168.10.129
// 内网访问外网前,先通过VM1 SNAT. 所有端口转发  这个和上面标绿字体部分差不多
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.10.129 -j SNAT –to-source 172.16.50.100  
一个网卡多个IP的方式:
1.网卡别名
    ifconfig eth0:1 192.168.50.200
2.?
删除nat表POSTROUTING 第一条rule
iptables -t nat -D POSTROUING 1
DNAT -> PREROUTING 
SNAT -> POSTROUTING
回路走的MAC记录

版权声明:本文为博主原创文章,未经博主允许不得转载。

haproxy + keepalived 实现简单负载均衡高可靠

ip addr add 192.168.50.50/24 dev etho   添加辅助ip  

ip addr del 192.168.50.50/24 dev etho   删除辅助ip  
脑裂:某种原因导致集群各节点之间无法通讯,各自都为master或者slave
killall -0 haproxy   不杀死进程,只是用作检测。后续脚本可以读取$?进行逻辑控制,为0则认为存活

实验结果
1.互主互备架构时,如果将master停掉之后,如果辅助IP没有跳转,可能是同一网段存在virtual_router_id和网段相同并且也启动了keepalived服务导致的。将不相关机器停了就可以了

2.keepalived 支持一主多备。

3.如果在一个 virtual_instance 里面配置了多个辅助ip,那么master挂了之后4个ip都会跳转到新的backup如下:
    
4.在master挂了之后,如果重新启动了会将辅助IP重新抢回。 而如果master挂了,剩下所有活着的节点都是backup的话,重新启动一个新backup启动则不会抢回辅助IP。

ip addr add 192.168.50.50/24 dev etho   添加辅助ip  

ip addr del 192.168.50.50/24 dev etho   删除辅助ip  
脑裂:某种原因导致集群各节点之间无法通讯,各自都为master或者slave
killall -0 haproxy   不杀死进程,只是用作检测。后续脚本可以读取$?进行逻辑控制,为0则认为存活

实验结果
1.互主互备架构时,如果将master停掉之后,如果辅助IP没有跳转,可能是同一网段存在virtual_router_id和网段相同并且也启动了keepalived服务导致的。将不相关机器停了就可以了

2.keepalived 支持一主多备。

3.如果在一个 virtual_instance 里面配置了多个辅助ip,那么master挂了之后4个ip都会跳转到新的backup如下:
    
4.在master挂了之后,如果重新启动了会将辅助IP重新抢回。 而如果master挂了,剩下所有活着的节点都是backup的话,重新启动一个新backup启动则不会抢回辅助IP。

版权声明:本文为博主原创文章,未经博主允许不得转载。

HDFS读取文件步骤

  1. client调用FileSystem.open(),该FileSystem指向的实例是DistrbutedFileSystem(DFS),它通过RPC请求到Namenode.
  2. Namenode收到请求后,对于每一个块返回存有该副本的Datanode地址。并且依照“网络拓扑”来排序。(就近原则)
  3. DFS获取到BlockLocations后,可以根据当前读取偏移量计算指定DataNode并进行通讯,返回一个FSDataInputStream,该对象管理DataNode和NameNode的I/O, 客户端反复调用stream.read()方法获取数据 (这步包含了权威指南的3,4步骤)。
  4. 到达块的末端时,stream关闭与当前交互的DataNode的连接,继续寻找下一个最佳的DataNode再执行步骤3操作
  5. client从stream读取数据时,块是按照打开stream和DataNode的顺序读取的,它也会询问NameNode来检索下一批数据块DataNode的位置。(《权威指南第三版》76页倒数第4行描述有误,事实上一次性获取了完整的BlockLocations) 一旦client读取完成,就对stream执行close操作
    
    上述流程是在正常读取,并且没有发生故障的理想情况下。

    
补充:
    
总结:
    这个设计的重点是,NameNode告知客户端每个块中最佳的DataNode,并让客户端直接连接到该DataNode检索数据。由于数据流分散在集群中的所有DataNode,所以这种设计能使HDFS可扩展到大量的并发客户端。同时,NameNode只需要响应块位置的请求(这些信息存储在内存中,所以非常高效),无须响应数据请求,否则随着客户端数量的增长,NameNode会很快成为瓶颈。

版权声明:本文为博主原创文章,未经博主允许不得转载。

洞悉linux下的Netfilter&iptables:什么是Netfilter?

本人研究linux的防火墙系统也有一段时间了,由于近来涉及到的工作比较纷杂,久而久之怕生熟了。趁有时间,好好把这方面的东西总结一番。一来是给自己做个沉淀,二来也欢迎这方面比较牛的前辈给小弟予以指点,共同学习,共同进步。

    能在CU上混的人绝非等闲之辈。因此,小弟这里说明一下:本系列博文主要侧重于分析Netfilter的实现机制,原理和设计思想层面的东西,同时从用户态的iptables到内核态的Netfilter其交互过程和通信手段等。至于iptables的入门用法方面的东西,网上随便一搜罗就有一大堆,我这里不浪费笔墨了。

    很多人在接触iptables之后就会这么一种感觉:我通过iptables命令配下去的每一条规则,到底是如何生效的呢?内核又是怎么去执行这些规则匹配呢?如果iptables不能满足我当下的需求,那么我是否可以去对其进行扩展呢?这些问题,都是我在接下来的博文中一一和大家分享的话题。这里需要指出:因为Netfilter与IP协议栈是无缝契合的,所以如果你要是有协议栈方面的基础,在阅读本文时一定会感觉轻车熟路。当然,如果没有也没关系,因为我会在关键点就协议栈的入门知识给大家做个普及。只是普及哦,不会详细深入下去的,因为涉及的东西太多了,目前我还正在研究摸索当中呢。好了,废话不多说,进入正题。

备注:我研究的内核版本是2.6.21,iptables的版本1.4.0。

 

什么是Netfilter?

    为了说明这个问题,首先看一个网络通信的基本模型:

    在数据的发送过程中,从上至下依次是“加头”的过程,每到达一层数据就被会加上该层的头部;与此同时,接受数据方就是个“剥头”的过程,从网卡收上包来之后,在往协议栈的上层传递过程中依次剥去每层的头部,最终到达用户那儿的就是裸数据了。

那么,“栈”模式底层机制基本就是像下面这个样子:

对于收到的每个数据包,都从“A”点进来,经过路由判决,如果是发送给本机的就经过“B”点,然后往协议栈的上层继续传递;否则,如果该数据包的目的地是不本机,那么就经过“C”点,然后顺着“E”点将该包转发出去。

对于发送的每个数据包,首先也有一个路由判决,以确定该包是从哪个接口出去,然后经过“D”点,最后也是顺着“E”点将该包发送出去。

协议栈那五个关键点A,B,C,D和E就是我们Netfilter大展拳脚的地方了。

Netfilter是Linux 2.4.x引入的一个子系统,它作为一个通用的、抽象的框架,提供一整套的hook函数的管理机制,使得诸如数据包过滤、网络地址转换(NAT)和基于协议类型的连接跟踪成为了可能。Netfilter在内核中位置如下图所示:

这幅图,很直观的反应了用户空间的iptables和内核空间的基于Netfilter的ip_tables模块之间的关系和其通讯方式,以及Netfilter在这其中所扮演的角色。

回到前面讨论的关于协议栈那五个关键点“ABCDE”上来。Netfilter在netfilter_ipv4.h中将这个五个点重新命了个名,如下图所示,意思我就不再解释了,猫叫咪咪而已:

在每个关键点上,有很多已经按照优先级预先注册了的回调函数(后面再说这些函数是什么,干什么用的。有些人喜欢把这些函数称为“钩子函数”,说的是同一个东西)埋伏在这些关键点,形成了一条链。对于每个到来的数据包会依次被那些回调函数“调戏”一番再视情况是将其放行,丢弃还是怎么滴。但是无论如何,这些回调函数最后必须向Netfilter报告一下该数据包的死活情况,因为毕竟每个数据包都是Netfilter从人家协议栈那儿借调过来给兄弟们Happy的,别个再怎么滴也总得“活要见人,死要见尸”吧。每个钩子函数最后必须向Netfilter框架返回下列几个值其中之一:

n  NF_ACCEPT 继续正常传输数据报。这个返回值告诉 Netfilter:到目前为止,该数据包还是被接受的并且该数据包应当被递交到网络协议栈的下一个阶段。

n  NF_DROP 丢弃该数据报,不再传输。

n  NF_STOLEN 模块接管该数据报,告诉Netfilter“忘掉”该数据报。该回调函数将从此开始对数据包的处理,并且Netfilter应当放弃对该数据包做任何的处理。但是,这并不意味着该数据包的资源已经被释放。这个数据包以及它独自的sk_buff数据结构仍然有效,只是回调函数从Netfilter 获取了该数据包的所有权。

n  NF_QUEUE 对该数据报进行排队(通常用于将数据报给用户空间的进程进行处理)

n  NF_REPEAT 再次调用该回调函数,应当谨慎使用这个值,以免造成死循环。

为了让我们显得更专业些,我们开始做些约定:上面提到的五个关键点后面我们就叫它们为hook点,每个hook点所注册的那些回调函数都将其称为hook函数。

Linux 2.6版内核的Netfilter目前支持IPv4、IPv6以及DECnet等协议栈,这里我们主要研究IPv4协议。关于协议类型,hook点,hook函数,优先级,通过下面这个图给大家做个详细展示:

对于每种类型的协议,数据包都会依次按照hook点的方向进行传输,每个hook点上Netfilter又按照优先级挂了很多hook函数。这些hook函数就是用来处理数据包用的。

Netfilter使用NF_HOOK(include/linux/netfilter.h)宏在协议栈内部切入到Netfilter框架中。相比于2.4版本,2.6版内核在该宏的定义上显得更加灵活一些,定义如下:

#define NF_HOOK(pf, hook, skb, indev, outdev, okfn) \

         NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, INT_MIN)

关于宏NF_HOOK各个参数的解释说明:

1)         pf:协议族名,Netfilter架构同样可以用于IP层之外,因此这个变量还可以有诸如PF_INET6,PF_DECnet等名字。

2)         hook:HOOK点的名字,对于IP层,就是取上面的五个值;

3)         skb:不解释;

4)         indev:数据包进来的设备,以struct net_device结构表示;

5)         outdev:数据包出去的设备,以struct net_device结构表示;

(后面可以看到,以上五个参数将传递给nf_register_hook中注册的处理函数。)

6)         okfn:是个函数指针,当所有的该HOOK点的所有登记函数调用完后,转而走此流程。

而NF_HOOK_THRESH又是一个宏:

#define NF_HOOK_THRESH(pf, hook, skb, indev, outdev, okfn, thresh)                \

({int __ret;                                                                                \

if ((__ret=nf_hook_thresh(pf, hook, &(skb), indev, outdev, okfn, thresh, 1)) == 1)\

         __ret = (okfn)(skb);                                                       \

__ret;})

我们发现NF_HOOK_THRESH宏只增加了一个thresh参数,这个参数就是用来指定通过该宏去遍历钩子函数时的优先级,同时,该宏内部又调用了nf_hook_thresh函数:

static inline int nf_hook_thresh(int pf, unsigned int hook,

                            struct sk_buff **pskb,

                            struct net_device *indev,

                            struct net_device *outdev,

                            int (*okfn)(struct sk_buff *), int thresh,

                            int cond)

{

if (!cond) 

return 1;

#ifndef CONFIG_NETFILTER_DEBUG

if (list_empty(&nf_hooks[pf][hook]))

         return 1;

#endif

return nf_hook_slow(pf, hook, pskb, indev, outdev, okfn, thresh);

}

这个函数又只增加了一个参数cond,该参数为0则放弃遍历,并且也不执行okfn函数;为1则执行nf_hook_slow去完成钩子函数okfn的顺序遍历(优先级从小到大依次执行)。

在net/netfilter/core.h文件中定义了一个二维的结构体数组,用来存储不同协议栈钩子点的回调处理函数。

struct list_head nf_hooks[NPROTO][NF_MAX_HOOKS];

其中,行数NPROTO为32,即目前内核所支持的最大协议簇;列数NF_MAX_HOOKS为挂载点的个数,目前在2.6内核中该值为8。nf_hooks数组的最终结构如下图所示。

在include/linux/socket.h中IP协议AF_INET(PF_INET)的序号为2,因此我们就可以得到TCP/IP协议族的钩子函数挂载点为:

PRE_ROUTING:     nf_hooks[2][0]

LOCAL_IN:        nf_hooks[2][1]

FORWARD:      nf_hooks[2][2]

LOCAL_OUT:      nf_hooks[2][3]

POST_ROUTING:          nf_hooks[2][4]

同时我们看到,在2.6内核的IP协议栈里,从协议栈正常的流程切入到Netfilter框架中,然后顺序、依次去调用每个HOOK点所有的钩子函数的相关操作有如下几处:

       1)、net/ipv4/ip_input.c里的ip_rcv函数。该函数主要用来处理网络层的IP报文的入口函数,它到Netfilter框架的切入点为:

NF_HOOK(PF_INETNF_IP_PRE_ROUTING, skb, dev, NULL,ip_rcv_finish)

根据前面的理解,这句代码意义已经很直观明确了。那就是:如果协议栈当前收到了一个IP报文(PF_INET),那么就把这个报文传到Netfilter的NF_IP_PRE_ROUTING过滤点,去检查[R]在那个过滤点(nf_hooks[2][0])是否已经有人注册了相关的用于处理数据包的钩子函数。如果有,则挨个去遍历链表nf_hooks[2][0]去寻找匹配的match和相应的target,根据返回到Netfilter框架中的值来进一步决定该如何处理该数据包(由钩子模块处理还是交由ip_rcv_finish函数继续处理)。

[R]:刚才说到所谓的“检查”。其核心就是nf_hook_slow()函数。该函数本质上做的事情很简单,根据优先级查找双向链表nf_hooks[][],找到对应的回调函数来处理数据包:

struct list_head **i;

list_for_each_continue_rcu(*i, head) {

struct nf_hook_ops *elem = (struct nf_hook_ops *)*i;

if (hook_thresh > elem->priority)

                  continue;

         verdict = elem->hook(hook, skb, indev, outdev, okfn);

         if (verdict != NF_ACCEPT) { … … }

    return NF_ACCEPT;

}

上面的代码是net/netfilter/core.c中的nf_iterate()函数的部分核心代码,该函数被nf_hook_slow函数所调用,然后根据其返回值做进一步处理。

2)、net/ipv4/ip_forward.c中的ip_forward函数,它的切入点为:

NF_HOOK(PF_INETNF_IP_FORWARD, skb, skb->dev, rt->u.dst.dev,ip_forward_finish);

在经过路由抉择后,所有需要本机转发的报文都会交由ip_forward函数进行处理。这里,该函数由NF_IP_FOWARD过滤点切入到Netfilter框架,在nf_hooks[2][2]过滤点执行匹配查找。最后根据返回值来确定ip_forward_finish函数的执行情况。

3)、net/ipv4/ip_output.c中的ip_output函数,它切入Netfilter框架的形式为:

NF_HOOK_COND(PF_INETNF_IP_POST_ROUTING, skb, NULL, dev,ip_finish_output,

                                !(IPCB(skb)->flags & IPSKB_REROUTED));

这里我们看到切入点从无条件宏NF_HOOK改成了有条件宏NF_HOOK_COND,调用该宏的条件是:如果协议栈当前所处理的数据包skb中没有重新路由的标记,数据包才会进入Netfilter框架。否则直接调用ip_finish_output函数走协议栈去处理。除此之外,有条件宏和无条件宏再无其他任何差异。

如果需要陷入Netfilter框架则数据包会在nf_hooks[2][4]过滤点去进行匹配查找。

4)、还是在net/ipv4/ip_input.c中的ip_local_deliver函数。该函数处理所有目的地址是本机的数据包,其切入函数为:

NF_HOOK(PF_INETNF_IP_LOCAL_IN, skb, skb->dev, NULL,ip_local_deliver_finish);

发给本机的数据包,首先全部会去nf_hooks[2][1]过滤点上检测是否有相关数据包的回调处理函数,如果有则执行匹配和动作,最后根据返回值执行ip_local_deliver_finish函数。

5)、net/ipv4/ip_output.c中的ip_push_pending_frames函数。该函数是将IP分片重组成完整的IP报文,然后发送出去。进入Netfilter框架的切入点为:

NF_HOOK(PF_INETNF_IP_LOCAL_OUT, skb, NULL, skb->dst->dev, dst_output);

对于所有从本机发出去的报文都会首先去Netfilter的nf_hooks[2][3]过滤点去过滤。一般情况下来来说,不管是路由器还是PC中端,很少有人限制自己机器发出去的报文。因为这样做的潜在风险也是显而易见的,往往会因为一些不恰当的设置导致某些服务失效,所以在这个过滤点上拦截数据包的情况非常少。当然也不排除真的有特殊需求的情况。

 

小节:整个Linux内核中Netfilter框架的HOOK机制可以概括如下:

在数据包流经内核协议栈的整个过程中,在一些已预定义的关键点上PRE_ROUTING、LOCAL_IN、FORWARD、LOCAL_OUT和POST_ROUTING会根据数据包的协议簇PF_INET到这些关键点去查找是否注册有钩子函数。如果没有,则直接返回okfn函数指针所指向的函数继续走协议栈;如果有,则调用nf_hook_slow函数,从而进入到Netfilter框架中去进一步调用已注册在该过滤点下的钩子函数,再根据其返回值来确定是否继续执行由函数指针okfn所指向的函数。

未完,待续…

 

linux平台下防火墙iptables原理(转)

iptables简介

    netfilter/iptables(简称为iptables)组成Linux平台下的包过滤防火墙,与大多数的Linux软件一样,这个包过滤防火墙是免费的,它可以代替昂贵的商业防火墙解决方案,完成封包过滤、封包重定向和网络地址转换(NAT)等功能。

iptables基础


    规则(rules)其实就是网络管理员预定义的条件,规则一般的定义为“如果数据包头符合这样的条件,就这样处理这个数据包”。规则存储在内核空间的信息包过滤表中,这些规则分别指定了源地址、目的地址、传输协议(如TCP、UDP、ICMP)和服务类型(如HTTP、FTP和SMTP)等。当数据包与规则匹配时,iptables就根据规则所定义的方法来处理这些数据包,如放行(accept)、拒绝(reject)和丢弃(drop)等。配置防火墙的主要工作就是添加、修改和删除这些规则。

iptables和netfilter的关系:

    这是第一个要说的地方,Iptables和netfilter的关系是一个很容易让人搞不清的问题。很多的知道iptables却不知道netfilter。其实iptables只是Linux防火墙的管理工具而已,位于/sbin/iptables。真正实现防火墙功能的是netfilter,它是Linux内核中实现包过滤的内部结构。

iptables传输数据包的过程

① 当一个数据包进入网卡时,它首先进入PREROUTING链,内核根据数据包目的IP判断是否需要转送出去。 
② 如果数据包就是进入本机的,它就会沿着图向下移动,到达INPUT链。数据包到了INPUT链后,任何进程都会收到它。本机上运行的程序可以发送数据包,这些数据包会经过OUTPUT链,然后到达POSTROUTING链输出。 
③ 如果数据包是要转发出去的,且内核允许转发,数据包就会如图所示向右移动,经过FORWARD链,然后到达POSTROUTING链输出。

iptables的规则表和链:

    表(tables)提供特定的功能,iptables内置了4个表,即filter表、nat表、mangle表和raw表,分别用于实现包过滤,网络地址转换、包重构(修改)和数据跟踪处理。

   链(chains)是数据包传播的路径,每一条链其实就是众多规则中的一个检查清单,每一条链中可以有一条或数条规则。当一个数据包到达一个链时,iptables就会从链中第一条规则开始检查,看该数据包是否满足规则所定义的条件。如果满足,系统就会根据该条规则所定义的方法处理该数据包;否则iptables将继续检查下一条规则,如果该数据包不符合链中任一条规则,iptables就会根据该链预先定义的默认策略来处理数据包。

    Iptables采用“表”和“链”的分层结构。在REHL4中是三张表五个链。现在REHL5成了四张表五个链了,不过多出来的那个表用的也不太多,所以基本还是和以前一样。下面罗列一下这四张表和五个链。注意一定要明白这些表和链的关系及作用。

规则表:

1.filter表——三个链:INPUT、FORWARD、OUTPUT
作用:过滤数据包  内核模块:iptables_filter.
2.Nat表——三个链:PREROUTING、POSTROUTING、OUTPUT
作用:用于网络地址转换(IP、端口) 内核模块:iptable_nat
3.Mangle表——五个链:PREROUTING、POSTROUTING、INPUT、OUTPUT、FORWARD
作用:修改数据包的服务类型、TTL、并且可以配置路由实现QOS内核模块:iptable_mangle(别看这个表这么麻烦,咱们设置策略时几乎都不会用到它)
4.Raw表——两个链:OUTPUT、PREROUTING
作用:决定数据包是否被状态跟踪机制处理  内核模块:iptable_raw
(这个是REHL4没有的,不过不用怕,用的不多)

规则链:


1.INPUT——进来的数据包应用此规则链中的策略
2.OUTPUT——外出的数据包应用此规则链中的策略
3.FORWARD——转发数据包时应用此规则链中的策略
4.PREROUTING——对数据包作路由选择前应用此链中的规则
(记住!所有的数据包进来的时侯都先由这个链处理)
5.POSTROUTING——对数据包作路由选择后应用此链中的规则
(所有的数据包出来的时侯都先由这个链处理)


规则表之间的优先顺序:

Raw——mangle——nat——filter
规则链之间的优先顺序(分三种情况):

第一种情况:入站数据流向

    从外界到达防火墙的数据包,先被PREROUTING规则链处理(是否修改数据包地址等),之后会进行路由选择(判断该数据包应该发往何处),如果数据包的目标主机是防火墙本机(比如说Internet用户访问防火墙主机中的web服务器的数据包),那么内核将其传给INPUT链进行处理(决定是否允许通过等),通过以后再交给系统上层的应用程序(比如Apache服务器)进行响应。

第二冲情况:转发数据流向

    来自外界的数据包到达防火墙后,首先被PREROUTING规则链处理,之后会进行路由选择,如果数据包的目标地址是其它外部地址(比如局域网用户通过网关访问QQ站点的数据包),则内核将其传递给FORWARD链进行处理(是否转发或拦截),然后再交给POSTROUTING规则链(是否修改数据包的地址等)进行处理。

第三种情况:出站数据流向
     防火墙本机向外部地址发送的数据包(比如在防火墙主机中测试公网DNS服务器时),首先被OUTPUT规则链处理,之后进行路由选择,然后传递给POSTROUTING规则链(是否修改数据包的地址等)进行处理。

管理和设置iptables规则

 

文章参考

  http://netfilter.org/ iptables官方网站
  http://www.linux.gov.cn/netweb/iptables.htm iptables配置手册
  http://man.chinaunix.net/
  http://man.chinaunix.net/network/iptables-tutorial-cn-1.1.19.html iptables配置手册
  http://blog.csdn.net/thmono/archive/2010/04/08/5462043.aspx
  http://netsecurity.51cto.com/art/200512/14457.htm
  http://blog.sina.com.cn/s/blog_40ba724c0100jz12.html
  http://qiliuping.blog.163.com/blog/static/1023829320105245337799/