企业级网络服务平台的搭建文档格式.docx

上传人:b****4 文档编号:18498817 上传时间:2022-12-17 格式:DOCX 页数:26 大小:840.19KB
下载 相关 举报
企业级网络服务平台的搭建文档格式.docx_第1页
第1页 / 共26页
企业级网络服务平台的搭建文档格式.docx_第2页
第2页 / 共26页
企业级网络服务平台的搭建文档格式.docx_第3页
第3页 / 共26页
企业级网络服务平台的搭建文档格式.docx_第4页
第4页 / 共26页
企业级网络服务平台的搭建文档格式.docx_第5页
第5页 / 共26页
点击查看更多>>
下载资源
资源描述

企业级网络服务平台的搭建文档格式.docx

《企业级网络服务平台的搭建文档格式.docx》由会员分享,可在线阅读,更多相关《企业级网络服务平台的搭建文档格式.docx(26页珍藏版)》请在冰豆网上搜索。

企业级网络服务平台的搭建文档格式.docx

在九十年代中期,万维网(WorldWideWeb)的出现以其简单操作方式将图文并茂的网上信息带给普通大众,Web正在从一种内容发送机制成为一种服务平台,大量的服务和使用(如新闻服务、网上银行、电子商务等)都是围绕着Web进行。

这促进Internet用户剧烈增长和Internet流量爆炸式地增长。

大部分网站都需要提供每天24小时、每星期7天的服务,对电子商务等网站尤为突出,任何服务中断和关键性的数据丢失都会造成直接的商业损失。

例如,根据阿里巴巴发布的信息显示,其旗下的淘宝网2010年交易额达4000亿元人民币,一个小时的服务中断都会造成巨大的损失。

所以,这对网络服务的可靠性提出了越来越高的要求。

现在Web服务中越来越多地使用CGI、动态主页等CPU密集型使用,这对服务器的性能有较高要求。

未来的网络服务会提供更丰富的内容、更好的交互性、更高的安全性等,需要服务器具有更强的CPU和I/O处理能力。

例如,通过HTTPS(SecureHTTP)取一个静态页面需要的处理性能比通过HTTP的高一个数量级,HTTPS正在被电子商务站点广为使用。

所以,网络流量并不能说明全部问题,要考虑到使用本身的发展也需要越来

越强的处理性能。

(二)国内外的研究现状

九十年代末期,Linux操作系统不断走向成熟,它的功能性不断增强,并且提供了GNU软件和标准化的PVM、MPI消息传递机制,最重要的是Linux在普通PC机上提供了对高性能网络的支持,这样就大大推动了基于Linux的集群系统的发展。

在国内,包括中国科学院在内的许多大学和研究机构早在20世纪90年代就开始了基于Linux集群研究,联想、浪潮等国内许多公司都有Linux集群产品和解决方案。

Google、Baidu和阿里巴巴后台均采用Linux集群,其中Google在2010年就达到了上千万台,不仅如此,Linux集群大量在金融、证券、电信以及IT行业使用。

名为High-AvailabilityLinux的开源项目的目标是,通过社区开发努力提供一个提升Linux可靠性(reliability)、可用性(availability)和可服务性(serviceability(RAS)的群集解决方案。

Linux-HA项目得到了广泛的使用,是很多有趣的高可用性解决方案的重要组成部分。

LVS是中国章文嵩博士发起和领导的优秀的集群解决方案,许多商业的集群产品,比如RedHat的Piranha等,都是基于LVS的核心代码的。

HA和LVS的不足主要有:

HA集群一般都是以两个节点的形式出现的,单机处理能力有限,所以当服务器压力较大时,想扩容服务器的处理能力往往得把以前的服务器淘汰掉,费了以前的投资;

LVS集群的真实服务器都是靠前端IP负载器进行调度分配的,所以存在单点故障,如果IP负载器宕机,整个集群系统就会瘫痪。

所以必须把HA和LVS整合在一起。

真实服务器的数据源所涉及的共享存储一般都是利用商业的硬件解决方案,如SAN网络区域存储,对于小型集群系统来说,投入非常高昂,完全可以利用Linux的软件RAID5技术和NFS网络文件系统来实现。

二、高可用集群

(一)集群的定义

集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源。

这些单个的计算机系统就是集群的节点(node)。

一个理想的集群是,用户从来不会意识到集群系统底层的节点,在他们看来,集群是一个系统,而非多个计算机系统。

并且集群系统的管理员可以随意增加和删改集群系统的节点。

集群计算机通常用来改进单个计算机的计算速度和/或可靠性。

一般情况下集群计算机比单个计算机,工作站或超级计算机性能价格比要高得多。

(二)集群的分类

集群计算机按功能和结构的不同可以分成:

高可用性集群(High-availabilityclusters,简称HA)、负载均衡集群(Loadbalancingclusters)、高性能计算集群(High-performanceclusters,简称HPC)等几类:

1.高可用性集群一般是指当集群中有某个节点失效的情况下,其上的任务会自动转移到其他正常的节点上。

还指可以将集群中的某节点进行离线维护再上线,该过程并不影响整个集群的运行。

2.负载均衡集群运行时一般通过一个或者多个前端负载均衡器将工作负载分发到后端的一组服务器上,从而达到整个系统的高性能和高可用性。

这样的计算机集群有时也被称为服务器群(ServerFarm)。

一般高可用性集群和负载均衡集群会使用类似的技术,或同时具有高可用性和负载均衡的特点。

3.高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力,因而主要使用在科学计算领域。

比较流行的HPC采用Linux操作系统和其它一些免费软件来完成并行运算。

这一集群配置通常被称为Beowulf集群。

这类集群通常运行特定的程序以发挥HPCcluster的并行能力。

这类程序一般使用特定的运行库,比如专为科学计算设计的MPI库。

HPC集群特别适合于在计算中各计算节点之间发生大量数据通讯的计算作业,比如一个节点的中间结果或影响到其它节点计算结果的情况。

(三)高可用集群架构

如图2-1所示,高可用集群主要由以下几部分组成。

图2-1高可用集群主要由以下几部分组成

(1)共享信息层

在基础架构上实现心跳信息探测。

双方节点可以随时探测到对方的心跳信息,以实现对对方主机工作状态的探测。

三类控制信息:

心跳(Heartbeats),集群事务信息(ClusterTransitionMessages),重传信息(RetransmissionRequest)。

配置文件:

/etc/ha.d/ha.cf。

各节点间域共享密钥,实现节点间互相通信的认证。

加密方式:

MD5、HMAC-SHA1。

常用实现软件:

HeartBeat、keepalived、ultramonkey、openais/corosync。

红帽官方提供的集群套件RHCS底层使用的通信机制就是openais/corosync。

(2)资源分配子层

在资源分配上定义资源种类,界定资源归属,每个服务需要哪些资源及这些资源之间的前后次序。

集群资源管理器(CRM,常用软件pacemaker),管理双方向外提供服务所需用到的资源,包括IP地址、Web服务、共享存储等等。

而这些资源需要依靠集群信息库CIB(XML文件)来定义,同时还必须保证一旦某个节点上的XML文件更新,即刻通知其他节点上的XML也要及时更新。

策略引擎(PEPolicyEngine):

定义法定人数以及根据法定人数所做出的动作等等本地资源管理器(LRMLocalResourceManager):

监控本地某个资源的工作状况。

(3)资源层

本地资源代理(ResourceAgent),脚本文件,一旦集群资源管理器发现某个资源工作异常,立即通知本地资源代理重启服务。

常用方法:

(1)Heartbeatv1

(2)使用脚本LSBscripts(LinuxStandardsBase)

(3)OCFOpenClusterFormat开放集群格式

(四)常用架构模型

1.一主一从架构。

2.互为主从架构。

两台主机分别提供两种不同的服务,互为提供热备。

3.多主机架构

N台主机组成一个集群,分别提供不同的服务,一台服务器空闲做备节点。

或者全部处于工作状态,一台服务器出故障,立刻将服务转移到其他主机上。

各节点之间需要以多播的形式将自己的健康情况发送给其他主机。

故障转移域,即如果一台主机发生故障,会将主机上的服务转移到域内的另一台主机上。

法定人数(Quorum)一般指一个设定值,集群超过这个值会正常工作,低于这个值会停止工作,同时也避免出现资源争用的情况。

脑裂和仲裁:

在某种情况下,由于底层通知错误,或者传递信息的介质出现故障,会出现资源争用的情况,称之为脑裂。

此时,每个部分都想取得对集群资源的控制权,以保证集群的高可用,这将破坏集群资源的完整性和一致性,导致整个集群瘫痪,硬件被破坏等严重后果。

为防止脑裂的放生,将由仲裁协议即法定代表人数来决定哪个部分取得对集群资源的控制权。

STONITH(ShootTheOtherNodeInTheHead):

避免出现资源争用的情况,为了防止错误操作的节点对集群资源进行破坏性控制和操作,使其不断重新启动或关机,从而使其无法取得对集群资源的控制权。

(五)高可用集群的设计及实现

主从架构模式如图2-2所示,环境搭建如下。

图2-2主从架构模式

Primaryeth0192.168.0.39

eth1192.168.10.10//心跳测试

提供Web服务,测试页内容为Web1

Standbyeth0192.168.0.27

eth1192.168.10.11//心跳测试

提供Web服务,测试页内容为Web2

向外提供Web服务IP:

192.168.0.100

(六)主服务器的设置

Heartbeat所需软件包如图2-3所示,直接使用yum本地安装。

图2-3Heartbeat所需软件包

[root@station39Heartbeat2]#yumlocalinstall./*--nogpgcheck

Heartbeat依靠服务器的主机名来识别服务器,因此使用hostname命令得到的结果必须

和uname-n结果保持一致。

[root@station39Heartbeat2]#vim/etc/sysconfig/network//修改主机名称;

HOSTNAME=

[root@station39Heartbeat2]#hostname

[root@station39~]#vim/etc/hosts//修改主机地址映射

192.168.0.39primary

192.168.0.27standby

[root@station39Heartbeat2]#hwclock-s//同步服务器时间

[root@station39Heartbeat2]#cd/etc/ha.d/

[39ha]#cp/usr/share/doc/heartbeat-2.1.4/ha.cf./

[39ha]#cp/usr/share/doc/heartbeat-2.1.4/authkeys./

[39ha]#cp/usr/share/doc/heartbeat-2.1.4/haresources./

[39ha]#vimha.cf//定义各节点之间Heartbeat进程如何通信

keepalive2//设定heartbeat之间的时间间隔为2秒

deadtime30//在30秒后宣布节点死亡;

warntime10//在日志中发出lateheartbeat警告之前等待的时间,单位为秒

udpport694//使用端口694进行bcast和ucast通信,默认参数

bcasteth1//在eth1接口上使用广播heartbeat

node//定义节点

[root@station39~]#ddif=/dev/urandombs=512count=1|opensslmd5//生成

节点间域共享密钥

d0f6e811a30607ec3783826d8d70ba25

[39ha]#vimauthkeys//定义心跳探测包使用哪种加密方式

auth1

1sha1d0f6e811a30607ec3783826d8d70ba25

[39ha]#chmod600authkeys//仅允许管理员修改文件

[39ha]#cp/etc/init.d/httpd/etc/ha.d/resource.d/

[39ha]#vimresource.d/haresources//定义资源;

192.168.0.100/24/eth0/192.168.0.255httpd

(七)从服务器的设置

从服务器的主机名称为,设置方法同主服务器一致。

/etc/hosts文件、Heartbeat的配置文件也必须和主机保持一致。

因此这里采用将Primary上的配置文件直接远程复制过来的方法:

[root@station26~]#cd/etc/ha.d/

[26ha]#scp192.168.0.39:

/etc/ha.d/ha.cf./

/etc/ha.d/authkeys./

/etc/ha.d/haresources./

[26ha]#cp/etc/init.d/httpd/etc/ha.d/resource.d/

[26ha]#chmod600authkeys

(八)测试效果

配置完成,此时,启动主从节点上的heartbeat服务。

使用浏览器访问http:

//192.168.0.100,可以看到图测试结果一所示,说明此时是Primary主机在工作。

我们使用Heartbeat本身自带的测试命令使Primary宕机,稍等片刻之后,再访问http:

//192.168.10.100就会发现出现如图测试结果二所示,说明Standby已经在工作。

测试结果一如图2-4所示

图2-4测试结果一

[39ha]#cd/usr/lib/heartbeat/

[root@station39heartbeat]#./hb_standby

测试结果二如图2-5所示

图2-5测试结果二

我们这里是为了方便测试故意将两台服务器上的Web服务的页面显示出不同的内容,真实的环境中两台服务器的提供Web服务应该是一模一样的,因此当服务器发生宕机的情况下用户能够正常地访问网站,丝毫感觉不到服务宕机的情况

三、LINUX虚拟服务器集群

(一)负载均衡架构

在负载均衡架构中,Director(dispatcher)负责接收客户端请求,并将请求按照某种算法分发到后台真正提供服务的服务器上。

既可以基于硬件(F5)来实现,也可以基于软件来实现。

基于软件实现的又分为四层交换:

基于IP地址和端口号组合起来对服务做重定向(LVS)。

七层交换:

通常指的是反向代理(proxy),例如squid等。

而真正提供Web服务的服务器称为RealServer,每个服务器称为一个节点。

(二)LINUXVIRTUALSERVER

LVS类似于iptables的架构,在内核中有一段代码用于实时监听数据包来源的请求,当数据包到达端口时做一次重定向,这一系列的工作必须在内核中实现。

在内核中实现数据包请求处理的代码叫做ipvs。

ipvs仅仅提供了功能框架,还需要自己手动定义是数据对哪个服务的请求,而这种定义需要通过写规则来实现,写规则的工具就称为ipvsadm。

LVS的目标:

使用集群技术和Linux操作系统实现一个高性能、高可用的服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。

图3-1LVS负载均衡架构

图3-1负载均衡架构

关于几个IP地址的解释:

VirtualIP(VIP):

Director用来向客户端提供服务的IP地址RealIP(RIP):

集群节点(后台真正提供服务的服务器)所使用的IP地址Director'

sIP(DIP):

Director用来和D/RIP进行通信的地址Clientcomputer'

sIP(CIP):

公网IP,客户端使用的IP地址。

根据前端Director和后台RealServer的通信方式将LVS分为三类:

NetworkAddressTranslation(LVS-NAT)、Directorrouting(LVS-DR)、IPtunneling(LVS-TUN):

1.VirtualServerviaNetworkAddressTranslation(LVS-NAT)

通过网络地址转换,Director重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的RealServer;

RealServer的响应报文通过Director时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。

2.VirtualServerviaDirectRouting(LVS-DR)

通过改写请求报文的MAC地址,将请求发送到RealServer,而RealServer将响应直接返回给客户。

同LVS-TUN技术一样,LVS-DR技术可极大地提高集群系统的伸缩性。

这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但要求Director和RealServer都有一块网卡连在同一物理网段上。

3.VirtualServerviaIPTunneling(LVS-TUN)

采用NAT技术时,由于请求和响应报文都必须经过Director地址重写,当客户请求越来越多时,Director的处理能力将成为瓶颈。

为了解决这个问题,Director把请求报文通过IP隧道转发至RealServer,而RealServer将响应直接返回给客户,所以Director只处理请求报文。

由于一般网络服务应答比请求报文大许多,采用LVS-TUN技术后,集群系统的最大吞吐量可以提高10倍。

(三)LVS-NAT

目标地址转换,即所有客户端的请求都被Director根据访问请求和算法被定向到后台的RealServer上,后台的RealServer回应客户端的数据包也要经过Director返回给客户端。

如负载均衡架构图3-2所示,数据包地址转换过程:

S:

CIPD:

VIP---->

Director---->

RIP---->

RealServer

RealServer---->

RIPD:

CIP---->

VIPD:

CIP

图3-2负载均衡架构

LVS-NAT特性:

Director和RealServer必须在同一个网段中

一般情况下,RIP是私有地址,只用于集群内部节点间通信

Director会响应所有的请求在客户端和RealServer之间,所承担的负载较大

所有的RealIP网关必须指向DIP以响应客户端请求

Director可以重映射网络端口,即前端使用标准端口,后端使用非标准端口

后台的RealServer可以使用任何操作系统

Director可能会成为系统瓶颈

(四)LVS-NAT集群的设计及实现

LVS-NAT网络架构如图3-3所示,环境搭建如下:

图3-3LVS-NAT网络架构

Director:

VIP192.168.0.127桥接

DIP192.168.10.1仅主机

RealServer1:

RIP192.168.10.2仅主机网关指向:

192.168.10.1

RealServer2:

RIP192.168.10.3仅主机网关指向:

Client:

192.168.0.1物理机

[root@station39html]#ifconfigeth0192.168.10.2//为eth0设置IP地址[root@station39html]#routeadddefaultgw192.168.10.1//添加网关

[root@station26html]#ifconfigeth0192.168.10.3//同上

[root@station26html]#routeadddefaultgw192.168.10.1//同上;

Director:

[root@server27~]#ifconfigeth1192.168.10.1//为Director设置DIP

[root@server27~]#echo1>

/proc/sys/net/ipv4/ip_forward//开启内核路由功能

[root@server27~]#vim/etc/sysctl.conf//修改内核参数,确保永久有效

net.ipv4.ip_forward=1

[root@server27~]#sysctl-p//查看内核参数

准备工作已经配置完毕,开始LVS-NAT的配置

[root@server27~]#yuminstallipvsadm-y//安装ipvsadm工具

[root@server27~]#ipvsadm-A-t192.168.0.127:

80-srr//定义服务,设定算法

为服务添加RealServer并设置权重

[root@server27~]#ipvsadm-a-t192.168.0.127:

80-r192.168.10.2-m

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工程科技 > 冶金矿山地质

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1