it-swarm.cn

在多服务器/集群环境中需要注意哪些潜在问题?

我一直在与一个客户的网站上工作一段时间,该网站本身已经大受欢迎。我们现在正处于这样一个阶段:我们托管网站的单机正在努力跟上请求,我们已尽可能地优化网站本身(缓存等)。

我们现在正处于需要添加另一台服务器的阶段,以便承受额外的压力,从而导致我的问题 - 在迁移到Web场或集群托管时,我需要注意或测试网站有哪些潜在的缺陷和警告环境?

3
Wolfwyrd

有几个可能的警告:

会话

如果会话存储在服务器端(即PHP),两个服务器都需要访问共享会话存储路径。否则,当负载均衡器将请求从一个服务器发送到另一个服务器时,您将丢失会话,或者可能(喘气)让一个用户具有两个唯一会话。这对AJAX来说尤其令人沮丧。根据您的负载均衡器,也可能会出现“粘滞”的会话。

临时文件

如果确实在处理请求时使用任何类型的临时文件,则两个服务器应共享相同的/ tmp目录。这可能是一个压缩下载的临时存档,一个跟踪某些东西的平面文件DB,无论如何。

SQLite Locking

如果您使用SQLite3,您可能会注意到之前从未出现的一些怪癖,特别是如果您使用NFS之类的东西来共享服务器之间的数据库文件。 NFS很慢,所以我建议使用其他东西。像Lustre这样的分布式文件系统很容易设置,或者你可以使用GFS/OCFS2。

SSL

您可能希望负载均衡器处理SSL握手,然后使用任何旧的自签名证书向后端服务器发出请求。

一些一般性说明:

  • 如上所述,使用高性能文件系统来共享目录。所有共享文件都应该存在于网络存储上,而不是其中一个Web服务器上。否则,如果一个人倒下,两个都没用,就有点失败了。

  • 如果站点使用RDBMS,您有两个选择。在两个节点上运行它并使用主 - 主同步,或将数据库服务器放在自己的主目录上。我推荐第二个,因为这可以让你的网络服务器更加灵活。

  • 负载平衡器也需要冗余。

在大多数情况下,您可以从单个服务器转到负载平衡的服务器场,对实际站点/应用程序本身几乎没有任何更改,但您需要确保所有节点都可以读取和写入相同的文件。这可能需要您添加一些逻辑以锁定应用程序本身。

1
Tim Post

会话状态(如果这是一个问题)是一个潜在的问题。大多数负载平衡设备可以使用粘性会话,这意味着最终在SERVER1上启动的用户将保留在SERVER1上,通常是通过使用存储在浏览器内存中的cookie。唯一需要注意的是,当SERVER1因任何原因而脱机时,该用户必须再次在另一台服务器上登录。

我已经开始通过在服务器场中共享会话来绕过我的应用程序(它们是CF应用程序)。因此,一台机器不会影响用户体验。

我在将内容正确复制到服务器场中的所有服务器时遇到的唯一其他挑战。那里有软件可以做到这一点(robocopy,NCH软件的Fling是我用过的两个),但我仍然有一些实例,其中同步在100%的时间内都不起作用。

0
Milner

您的应用程序是否关心状态?如果用户有一个请求由一台机器提供服务而另一台服务器由另一台机器提供服如果你需要在请求之间保持某种形式的状态,那么一切都更复杂,并且有各种方法来处理问题。

如果您不需要担心状态,那么建立您的网站的工作很好,而且您应该使用 代理 和一些后端服务器。

如果你确实需要保持状态,有多种方法可以通过代理创建粘性会话,以便同一个后端服务器处理来自单个用户的所有请求,但也有很多事情使这些会话很难保持粘性。

您还可以在后端的公共介质中保持状态,因此每个服务器将为同一用户加载相同的状态。您可以使用数据库(可能太慢)或类似 memcached

您是否也在扩大数据库服务器的数量?这将带来另一堆问题需要担心。

一些会话问题在Stack Overflow Podcast Number 6 中讨论

为了进行测试,请确保您点击类似的测试群集,这样您就可以看到您的请求在多个服务器上的指示时的操作,因为从同一客户端到不同后端的许多请求是您可能遇到问题的地方,因此请确保测试计划中的某些内容会导致这种情况发生。

您可能还想阅读Stack Overflow的 网络配置

0
danivovich