关于Clusters的一些相关知识和名词解释
关于Clusters的一些相关知识
TianYu 2002-12-16
来自前段时间我在准备scea part1时所做的笔记.
Study Notes目录及下载à
http://www.arkee.org/forum/showthread.jsp?forumID=7&rootID=2533&announceID=2533
摘要
服务器集群增长了系统可用性(availability)和冗余(redundancy).也提供了容错(fault tolerance).使用集群,可以分布请求以便多个服务器可以共享负载.一些服务器也可能提供确定哪台服务器利用的不充分以便均衡负载的复杂处理.
服务器亲合力(Server Affinity)或者粘性负载均衡(Sticky Load Balancing)
从相同的客户端到相同的后端机器,路由请求.如果你使用Stateful Session 或者 Entity EJBs是必要的.那会使唯一的一个有效的服务器传输后面的请求.
负载分布(Load distribution)
负载分布和服务器亲合力一样承认多个服务器可接受请求目标.但是它也承认一些请求最好直接定位具体的服务器.
弱亲合力(Weak affinity)
尽力强制亲合力.但是不总保证.
强亲合力(Strong affinity)
保证重视亲合力关系
Load Balancing vs. Load Sharing
负载分布通常在两个服务器之间通过负载共享(Load Sharing)完成.然而,共享负载是不适当的方式,因为相同点击的数量总是被分配到各个服务器,忽视在容量方面和当前负载的变化.服务器开始处理太多或者太少的负载共享,导致你的站点不一致的响应.
另一方面,均衡负载重视web服务器的容量和负载.因此所有的服务器将每次都将获得适当的负载,快速返回,一致的响应.
负载均衡靠尽力平等在所有处理器上的负载工作是更艰难的.
负载共享
Pros::
设置简单
便宜
Cons:
1. 如果一台服务器down掉了, 客户端将继续定位到这台机器,使用DNS,更加重了这个问题,因为客户端缓存DNS的事实和DNS的一些变更通过公共的DNS服务器花费时间传播 .
2. 负载共享不在需要它的地方分布负载.
举例来说server 1 过载, server 2 空闲
3. Web服务器重定向只适合HTTP.
DNS Round Robin
在许多DNS之间平等的分散接收IP包.这个意思就是说每个后续的包都被发送到清单里的下个IP地址,直到到达清单的最后,然后下个包又被发送到第一个地址.这是简单的负载均衡策略(事实上是load distribution,即load-share).它并不重视机器上的实际负载..
DNS Round Robin 负载分布不管请求的类型(也就是SSL, JSP, HTML)均匀的分离请求的过程. 如果你有三个服务器,第一个请求进入到第一台服务器,第二个请求到第二台服务器,第三个请求到第三台服务器.当第四个请求进入时,重新开始这个过程,所以这个请求来到第一台服务器.
DNS round robin支持一些应用服务的池,不只是web服务器.象Web池,email,ftp,数据库,和其他的服务器都可以使用DNS设置成load-share.
缺点:如果一台机器死掉了,将仍然把一些传输路由到已死的机器上.
DNS RR并不关心象cpu利用率这些东西,它被考虑为负载共享的解决方案.
DNS MX records
MX 允许设置多个邮件主机
Web server redirect
使用JSP/servlets/Javascript从www到www1/www2设置重定向
负载分割(Load partitioning)
基于客户端的状态,发送他们的请求到具体的服务器.
举例来说, if (userNum < 10,000) 就到server1.
Yahoo/Hotmail对于webmail使用这种技术. us.f206.mail.yahoo.com
Cons:不分布负载,用户锁定到一台服务器
负载平衡
分布处理和通信行为均匀的通过计算机网络,当单个设备失败时,可以不受影响.负载均衡对于那些很难预知发到服务器上的请求数量的网络来说是尤其重要的.典型的网站在负载均衡方案里使用两个或者更多的Web服务器.如果一台服务器开始难于应付,请求被转发到有着更大容量的别的服务器上,负载均衡也可以应用自己的通信通道.
反转代理负载均衡
根据请求的类型(也就是SSL, JSP, HTML)分开请求分别处理的过程.
通常当你的服务器有不同数量的CPUs和内存时使用.你可能使用一些强大的服务器来处理SSL sessions,其他的处理静态html.这么使用将最大化发挥你的应用的性能.
硬件负载均衡器
硬件负载均衡器提供了请求层次的失败转移.当负载均衡器检测到一个具体的节点down掉了,它将把以后到这个死节点的请求重新定位到集群里其他的活动节点上.
为了明显的获取session失败转移,集群里的节点必须彼此之间进行协作,同时具有所有的session数据都可以被存储的地方,例如共享内存区域或者一个公共的数据库.因此,如果集群里的一个节点有了问题,session会在另外一个节点上继续.
容错
容错是即使当一些系统组件有故障时防止失败的能力.完成容错的关键是冗余.冗余需要复制.
通过复制品的使用,服务器集群增加了系统的可靠性和可用性.他们给负载分布和负载均衡提供了一个容错机制.
Hot backup
在热备份(Hot backup)里,对象的活动的拷贝(复制品)为客户端请求服务,持续和原始对象同步.如果原始对象失败,一个拷贝立刻接管.
cold backups
在冷备份(cold backups)里,复制品不是经常更新.随着原始服务在定期的间隔同步它们的状态.如果原始服务失败,一个复制品在它可以为请求服务之前必须被同步.(可能用来自存储设备的数据).就是说,原始对象以某个时间间隔和稳定的存储器同步.万一失败,实例化一个新对象,读取存储器进行设置.
warm backups
在暖备份(warm backups)里,只有原始服务响应请求.然而所有的活动持续记入日志的.复制品也周期性的清洗,从这些日志里获得新状态.当原始服务失败时,一个复制品在它的状态和日志同步后立刻接管.
一个对象的备份拷贝运行时,不能为客户端服务.同步在某个固定时间间隔发生.万一失败,一个拷贝从最新的同步点接管.
错误处理包括服务复制,错误检测,错误恢复,错误通知.错误检测通常使用heartbeats(服务器周期性发送信号到监控器)或者轮询(监控器一段时间检查服务器一次)
Corba的容错处理涉及Replica Managers和Replica Service Agents.(略)
Active Replication和Passive Replication
积极复制是一种容错机制,在这里每个复制品都被认为是主要的服务,尽力为每个请求服务.所有的复制品的状态都是持续同步的.使用一个拦截器阻碍额外的响应,积极复制概念上和热备份是相似的. 意思是说每个复制品都处理请求和应答. 拦截器阻碍额外对第三个对象调用和额外的响应.
在消极复制里,原始服务处理所有请求.复制品的状态周期性的同步,如果原始服务失败,一个复制品在它的状态被同步(例如,使用日志文件)后立刻接管.一个原始复制品处理请求和同步第二个复制品状态.请求也被记录在日志里,对于失败转移来说,第二个复制品成为原始首要的,第一位的,在最新的同步点处理所有的请求.在概念上,消极复制和暖备份是相似的