手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜Qcloud , 注册 | 登陆
浏览模式: 标准 | 列表Tag:负载均衡

使用Apache做负载均衡

看到这个标题的时候,我和此文作者是一样的心态,apache也能做这个?我一向以为是nginx之类的才行?
仔细一想,如果可行,那应该是用了apache 的 proxy吧?以前用proxy做过asp的代理,如果负载均衡,估计用这个也应该可以吧?
究竟是不是这样呢?看看原文内容就知道了
原文地址为:http://tech.idv2.com/2009/07/22/loadbalancer-with-apache/
内容如下:

第一次看到这个标题时我也很惊讶,Apache居然还能做负载均衡?真是太强大了。 经过一番调查后发现的确可以,而且功能一点都不差。 这都归功于 mod_proxy 这个模块。 不愧是强大的Apache啊。

废话少说,下面就来解释一下负载均衡的设置方法。

一般来说,负载均衡就是将客户端的请求分流给后端的各个真实服务器, 达到负载均衡的目的。还有一种方式是用两台服务器,一台作为主服务器(Master), 另一台作为热备份(Hot Standby),请求全部分给主服务器,在主服务器当机时, 立即切换到备份服务器,以提高系统的整体可靠性。

负载均衡的设置

Apache可以应对上面这两种需求。先来讨论一下如何做负载均衡。 首先需要启用Apache的几个模块:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

mod_proxy提供代理服务器功能,mod_proxy_balancer提供负载均衡功能, mod_proxy_http让代理服务器能支持HTTP协议。如果把mod_proxy_http换成 其他协议模块(如mod_proxy_ftp),或许能支持其他协议的负载均衡, 有兴趣的朋友可以自己尝试一下。

然后要添加以下配置:

ProxyRequests Off
<Proxy balancer://mycluster>
BalancerMember http://node-a.myserver.com:8080
BalancerMember http://node-b.myserver.com:8080
</Proxy>
ProxyPass / balancer://mycluster

# 警告:以下这段配置仅用于调试,绝不要添加到生产环境中!!!
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from localhost
</Location>

从上面的 ProxyRequests Off 这条可以看出,实际上负载均衡器就是一个反向代理, 只不过它的代理转发地址不是某台具体的服务器,而是一个 balancer:// 协议:

ProxyPass / balancer://mycluster

协议地址可以随便定义。然后,在<Proxy>段中设置该balancer协议的内容即可。 BalancerMember指令可以添加负载均衡组中的真实服务器地址。

下面那段<Location /balancer-manager>是用来监视负载均衡的工作情况的, 调试时可以加上(生产环境中禁止使用!),然后访问 http://localhost/balancer-manager/ 即可看到 负载均衡的工作状况。

OK,改完之后重启服务器,访问你的Apache所在服务器的地址,即可看到负载均衡的效果了。 打开 balancer-manager 的界面,可以看到请求是平均分配的。

如果不想平均分配怎么办?给 BalancerMember 加上 loadfactor 参数即可,取值范围为1-100。 比如你有三台服务器,负载分配比例为 7:2:1,只需这样设置:

ProxyRequests Off
<Proxy balancer://mycluster>
BalancerMember http://node-a.myserver.com:8080 loadfactor=7
BalancerMember http://node-b.myserver.com:8080 loadfactor=2
BalancerMember http://node-c.myserver.com:8080 loadfactor=1
</Proxy>
ProxyPass / balancer://mycluster

默认情况下,负载均衡会尽量让各个服务器接受的请求次数满足预设的比例。 如果要改变算法,可以使用 lbmethod 属性。如:

ProxyRequests Off
<Proxy balancer://mycluster>
BalancerMember http://node-a.myserver.com:8080 loadfactor=7
BalancerMember http://node-b.myserver.com:8080 loadfactor=2
BalancerMember http://node-c.myserver.com:8080 loadfactor=1
</Proxy>
ProxyPass / balancer://mycluster
ProxySet lbmethod=bytraffic

lbmethod可能的取值有:

lbmethod=byrequests 按照请求次数均衡(默认)
lbmethod=bytraffic 按照流量均衡
lbmethod=bybusyness 按照繁忙程度均衡(总是分配给活跃请求数最少的服务器)

各种算法的原理请参见Apache的文档

热备份(Hot Standby)

热备份的实现很简单,只需添加 status=+H 属性,就可以把某台服务器指定为备份服务器:

ProxyRequests Off
<Proxy balancer://mycluster>
BalancerMember http://node-a.myserver.com:8080
BalancerMember http://node-b.myserver.com:8080 status=+H
</Proxy>
ProxyPass / balancer://mycluster

从 balancer-manager 界面中可以看到,请求总是流向 node-a ,一旦node-a挂掉, Apache会检测到错误并把请求分流给 node-b。Apache会每隔几分钟检测一下 node-a 的状况, 如果node-a恢复,就继续使用node-a。

Tags: apache, 负载均衡

网站多服务器负载均衡引起的开发问题及解决方案

本文来自kakapo的博客,kakapo,如果没有记错,应该是pchome的人吧。。。负载均衡我暂时还没有用到,毕竟我就一台服务器也没必要在服务器上装上17、8个虚拟机来跑这些负载均衡吧。

原文地址:http://www.kakapo.cn/blog/read.php?153

内容:

先罗列一下问题:
1、session会话数据共享问题
2、缓存数据文件共享问题
3、用户数据共享问题
4、上传数据存储问题
5、Log日志文件共享同步问题
6、配置文件管理问题
7、web服务器时间获取不一致问题

这些问题都是从项目经验中总结出来的,接下来在一一讨论解决的办法。
1、session会话数据共享问题    

推荐使用memcached分布式缓存系统来解决,可以参考我之前写一篇文章《Memcached的介绍和应用》。

2、缓存数据文件共享问题解决方案

所谓缓存数据,一般指网站前台程序本身产生的数据,比如,数据库查询类产生的数据对象缓存,缓存类产生的本地缓存数据,远程抓取类产生的本地临时缓存文件等等。    
有 些数据看似不需要共享,就像那些在每台机器上都能自动产生的数据。但是如果刚好碰到某个时刻数据更新了,缓存时间又不同步,就会造成负载均衡上的每台机器 缓存数据不相同。这也会给用户的访问带来一定的困扰。当然针对的解决办法就是想办法让缓存同时过期,保证缓存的内容相同,这就不需要考虑共享的问 题。    
远程抓取经常会涉及到模拟登陆,在本地一般会保存模拟登陆用户的cookie数据,这个就一定得想办法解决共享。否则用户在负载 A机器上执行了模拟登陆程序,在本地产生了cookie文件,但是下次请求被分配到负载B机器上执行抓取程序,却发现需要用上的cookie文件在本地不 存在,马上程序就会被远程服务器拒绝访问。这种cookie的临时文件很多而且改动频繁。目前我们采用了NFS的方案,mount指定的一个缓存目录,让 负载的每台机器都能像本地目录一样访问,暂且还行的通。也可以将这个单独的应用放到一台机器,来避免这个问题。

3、用户数据共享问题    
所谓用户数据,范围比较广。这里一般指在用户的独立目录空间保存的用户独用的数据。比例用户自己的相片,头像等等。    
之 前我们采用的方法是搞一台存储服务器,通过一定的规则为用户创建目录空间,然后存储服务器通过NFS共享到所有负载均衡的web服务器。这种做法在几百万 用户的网站还行得通。主要问题在于NFS在高并发访问下会出现一些不稳定,会丢失文件访问句柄。另外还有mount管理带来的麻烦,以及数据安全等风险。 顺便提起用户目录空间的创建规则,分散均匀是一个最大的原则,采用哈希值切分方式比较合适。 采用用户名或者时间因子虽然方便了一些记忆和查询,但是容易碰到局部目录达到系统最大限制的问题。    
所以,推荐使用分布式文件系统解决方案。国人happy_fish100开发了一个高效的开源的分布式文件系统FastDFS,比较完善,使用简单,功能强大。特别适合解决我当前遇到的问题。自称比国外的Mogilefs还强大。让我更心动的是提供了PHP client API,采用socket访问。在应用中调用也非常方便。

4、上传数据存储问题    

这 个问题再单独拿出来谈是有根据的。在前台用户上传的自己相关的数据可以归属前面一个问题的范畴。前台也有一些用户上传的数据跟用户无关,还有网站后台也会 有很多上传的数据。之前的做法可以是通过FTP服务将这些数据上传到存储静态文件的服务器上,也有通过NFS方式共享静态文件服务器的指定目录到web服 务器。现在除了FTP方案之外,我也推荐尝试使用FastDFS来管理静态文件服务器的数据,但是要修改一下设计,可以在FastDFS的storge服 务器上直接架设http服务器,让静态文件能直接通过URL访问。

5、Log日志文件共享同步问题    

所谓的Log日志也是web服务器程序自动产生的,比如错误日志,访问日志等。在一般情况一下也可以考虑让其不共享,无非是分析日志的时候每台机器都要做一遍。

6、配置文件管理问题&web服务器时间获取不一致问题      

配置文件管理问题严格来讲不属于开发遇到的问题,而是运维人员烦恼的事情。当然,通过合理的将配置文件进行归类和存储,还是可以减少运维人员的困难的。web服务器的配置文件的最好也不用共享,文件的同步可以让系统管理员通过系统命令去自动完成。
web服务器时间不一致虽然可以通过系统定时跟全球的时间服务器同步,但是在开发过程中程序还是要尽量避免使用本地时间函数,特别是跟数据库有关系的数据,可以通过采用数据库的时间函数来解决。

 

Tags: kakapo, 负载均衡

PHP负载均衡

文章的内容写的不错,所以转载一下。
原文:http://xinsync.xju.edu.cn/index.php/archives/2946
内容如下:

XML/HTML代码
  1. 过去当运行一个大的web应用时候意味着运行一个大型的web服务器。因为你的应用吸引了大量的用户,你将不得不在你的服务器里增加更多的内存和处理器。  
  2.   
  3. 今天,’大型服务器’模式已经过去,取而代之的是大量的小服务器,使用各种各样的负载均衡技术。这是一种更可行的方法,将使硬件成本降至最低。  
  4.   
  5. ‘更多小服务器’的优势超过过去的’大型服务器’模式体现在两个方面:  
  6.   
  7.    1. 如果服务器宕机,那么负载均衡系统将停止请求到宕机的服务器,转而分发负载到其他正常运行的服务器上。  
  8.    2. 扩展你的服务器更加容易。你要做的仅仅是加入新的服务器到负载均衡系统。不需要中断你的应用运行。  
  9.   
  10. 所以,把握住这个机会:). 当然,代价就是这要求你的应用开发时增加一点复杂度。这就是本文要覆盖的内容。  
  11.   
  12. 这时你可能对自己说: ‘但是我怎么知道我正在使用负载均衡呢?’。最诚实的回答是,如果你正在问这个问题,那么答案是你多半没有在使用负载均衡系统并且你的系统不需要考虑这个问题。大多数情况,当应用成长足够大的规模时,负载均衡就需要明确提出和设置了。然而,我也偶尔看见虚拟主机公司为客户的应用做这个负载均衡,或者像下面描述的那样要自己来做。  
  13.   
  14. 在继续下面的内容之前,我要指出本文主要描述PHP的负载均衡。将来我可能会写有关数据负载均衡的文字,但是现在你必须等待。  
  15.   
  16. 注意,我一直提“web应用”而不是website,这是想区分’web应用’是那些复杂的站点往往涉及服务器端编程和数据库,而不是website那样只显示简单的静态内容。  
  17. 1. PHP文件  
  18.   
  19. 第一个问题是,如果你有大量的小型服务器,你怎么把你的php文件上传到所有的服务器上?有如下的方法供你参考:  
  20.   
  21.    1. 分别上传所有的文件到每一个服务器 , 这种方法带来的问题是:想像一下你有20个服务器,那么上传过程中这将很容易导致错误,并且更新时极有可能导致不同服务器上有不同版本的文件。  
  22.    2. 使用 ‘rsync ‘ (或类似的软件) . 这样的工具能同步本地目录和多个远程主机目录上的文件。  
  23.    3. 使用版本控制软件(如subversion ) . 这是我最喜欢的方法。用它可以很好地维护我得代码,当发布我的应用时,可以在每一个服务器上运行svn update命令同步。这种方法也使切换服务器得代码到过去的某一个版本更加容易。  
  24.    4. 使用一个文件服务器(你可能发现NFS 非常适合做这件事情). 这种方式是使用一个文件服务器来存放你的web应用. 当然,如果你的文件服务器宕机,那么多所有你的站点将不能使用。这时,你就需要花费更多的开支来恢复它。  
  25.   
  26. 选择哪种方式依赖于你的需求和你掌握的技能。如果你使用版本控制系统,那么你可能得计划一个方法如果同时执行一个更新命令更新所有服务器上的代码。然而,如果使用文件服务器,你就要实现一些失败恢复机制,防止万一服务器宕机导致请求失败。  
  27. 2. 文件上传  
  28.   
  29. 当只有一台服务器时,文件上传不是一个问题。但是当我们有多台服务器时,那么上传的文件应该怎么存放呢?上传文件的问题和跨服务器php文件存储是类似的。下面是几种可能的方案:  
  30.   
  31.    1. 把文件存储到数据库中 。大多数数据允许存储二进制数据。当你请求文件下载时,访问数据把二进制数据和相应的文件名和类型输出给用户。在使用这种方案前应该考虑数据库怎样存储你的文件。该方法的问题在于如果数据库服务器宕机将使文件不可用。  
  32.    2. 在一个文件服务器上存储上传的文件 . 与前面的介绍一样,你要安装一个文件服务器让所有web服务器共享,把所有上传的文件上传到这里,上传后所有的web服务器就都可以使用它。但是,如果文件服务器宕机,那么可能发生图像文件下载中断。  
  33.    3. 设计你自己的上传机制传输文件到服务器到每一个服务器 . 这个方法没有单个文件服务器或者数据库方案的缺陷,但是将增加你代码的复杂度。例如,如果上传到多个服务器过程中,服务器宕机,你要怎么处理?  
  34.   
  35. 用数据库存储上传文件但是设计一个文件缓存机制是一个不错的方案。当服务器接收一个文件下载请求时,首先检查缓存系统中是否有该文件,如果发现那么从缓存系统下载,否则从数据库读取并把它缓存到文件系统中。  
  36. 3. 会话(Sessions)  
  37.   
  38. 如果你熟悉php的session处理,你将可能知道默认情况下,它存储session数据在服务器的临时文件里。而且,这个文件仅仅在你请求处理的那个服务器上,但是接下来的请求可能被另外一个服务器处理,这将在另一个服务器上生成新的session。这导致session频繁地不被识别,如登录用户总是要求重新登录。  
  39.   
  40. 我推荐的方案是,要么重新php内建的session处理机制存储session数据到数据库,或者实现你自己的机制保证发送一个用户的请求到同一台服务器。  
  41. 4. 配置(Configuration)  
  42.   
  43. 尽管这个话题不是和php特别相关,我感觉还是有必要提及。当运行集群服务器时,用某种方法保持服务器之间的配置文件同步是一个好主意。如果配置文件不一致,可能导致一些非常奇怪的断断续续的行为导致很难排查这些问题。  
  44.   
  45. 我推荐使用版本控制系统单独管理他们。这样你可以为不同的项目安装存储不同的php配置文件,也可以保持所有服务器配置文件同步。  
  46. 5. 日志(Logging)  
  47.   
  48. 像配置问题一样,logging不是仅仅和php相关。但是对于保持服务器健康运行它仍然是非常重要的。没有正确的logging系统,你怎么知道如果PHP代码开始产生错误(在系统正式运行时,你总是关闭display_errors 设置,不是吗?)  
  49.   
  50. 有几种方法你可以实现logging:  
  51.   
  52.    1. 在每一个服务器上记录日志。 这是最简单的方法。每一个机器仅仅记录一个文件。好处是简单,可能只要很少的配置。但是,随着服务器数量的增多,监控每台服务器上的日志文件将变得非常困难。  
  53.    2. 记录日志到一个共享 这种方法每一个服务器仍然有这个日志文件,但是他们通过共享机制被存储在一个中央文件服务器上,这将使监控日志变得更简单。该方案的问题在于,如果文件服务器不可用将导致一个简单的日志不能写入问题最终导致整个应用崩溃。  
  54.    3. 记录日志到logging服务器 你可以使用一个logging软件,如syslog 来把所有的日志写到一个中央服务器。尽管这个方法要求更多的配置,但是他也提供了最健壮的方案。  

SVN的机制确实是很多人现在所考虑的,一来这样保证了代码的同步,二来也不需要担心开发版和上线版的区别,更重要的是,每次的update你肯定不会有错。

文件上传其实才是一个大头,当你的服务器过多的时候,你如何保证每一台服务器的上传内容同步?如果你同步了,那么这么多的冗余文件是否是一个浪费?如果你不同步,而采用同一个NFS服务器来存储,那么就象文中说的如果NFS宕机了怎么办?给NFS也来一个负载均衡?

总之,当服务器越来越多的时候,你考虑的就不仅仅是代码的问题,而是架构的问题

Tags: php, server, 负载均衡, 配置