【原创】有关网站集群架构的一点点思考

AMD-K6

摘自： http://www.gracecode.com/Archive/Display/24

我目前所在的公司打算重新部署服务器集群架构。对于此，作为名项目开发人员本身对于 Linux 有点了解，想谈谈我的看法。

首先参看下面的网络和服务器架构图：



基本上此集群的架构可以分为三层：网络链路层、应用服务层和数据存储层。然后大体上再安排两台服务器分别作为数据备份服务器和监控服务器。


网络链路层

网络链路层主要分配请求的负载平衡。前端通过一个防火墙和交换机以后，再交由 LVS 处理。然后 LVS 决定相应的应用服务器处理请求并返回。

此端我部门里的某一成员计划采用脚本程序控制。但个人认为对于此我想一来是效率不高，二来的确对于高负载的要求来说，稳定性还是有待测试的。所以我们听从了我们的管理员的看法，采用网络层的动态分配。


应用服务层

应用服务器主要用作存放各种应用服务器，比如 Web 服务器、搜索服务器和文件服务器。Web 服务器可能要根据具体的流量来确定具体的服务器规模。

大体上按照服务器的性质来分， Web 服务器和搜索服务器对于 CPU 的要求是比较高的。而文件服务器则偏向于磁盘的吞吐性能。


数据存储层

数据存储层在这里我理解为数据库集群。按照现有的项目规划数据库的性能要求是当前的服务器集群中最高的，所以个人认为这块是重点。


其他

相对的后期扩展性问题

这点我们也已经意识到了。后期如果对于数据更新频率不是很高的应用，可以在个层之间中加入诺干台缓存服务器，以提高响应速度并缓解应用服务器的压力。

预算问题

预算和现实总是有些差距的。此规模的服务器集群主要的预算基本上都应该在数据库服务器上面了。对于此在不降低性能的前提下，可以适当的缩减服务器的规模和数量。

但是对于长期的项目规划来看，任何的付出都会获得一定的回报的。对于此，我想我的态度是乐观的。

linux_pro

我上来丢人一下 .

先贴图,再仔细吧 K6大大的帖子看完.

linux_pro

引子...

学校 MZH的管理员说

1. 今天再次仔细检查了整个MZH系统的运行环境和日志。现对MZH最近故障的原因做一说明。
   
2. 
   
3. 
   
4.       从今年6月下旬开始，MZH的同时在线人数长时间超过5K，导致MZH访问缓慢和经常出现连接数已超过限制等问题，所以对数据库连接数进行了调整。
   
5. 
   
6.       由于调整时未考虑到部分用户快速刷新页面带来的数据库压力，导致从9月9日以来，时不时的出现论坛完全无法访问。
   
7. 
   
8.       经查，MZH宕掉的原因是数据库服务占用了过多的系统资源而导致数据库服务器假死。目前已做调整。
   
9. 
   
10.      另，由于WWW服务器过于频繁的访问数据库服务器，数据库服务器防火墙时不时的把正常连接当成攻击连接而被拒绝。目前此问题暂时没找到很好的解决办法。
    
11.    
    
12. 
    
13. 大家有什么想法，欢迎提出。
    
14. 谢谢。

复制代码

然后我给出了上面的图片.

linux_pro

目前还停留在硬件筹备中.

图中硬件都是已经准备好的.

目前的想法是.

在SP 2500 +  5721 千兆网卡的机器 既要充当 REAL SERVER1  又要充当调度器.

P4 2.8 G 的充当 REAL SERVER2了.

不过目前来说有几个概念没搞清楚.

问题:
1 是共享存储.  用iscsi. 可是我没有SCSI的硬盘 ,能否实现 iscsi呢?
2 至于文件系统,我更加CU的 NTTP 大大 的建议绝对 EXT3 wirteback 的参数.可是到底如何实现现在完全没头绪...


看到你的K6最后一句话,经济... 想起了CU的NTTP的建议,然后结合学校4T 硬盘柜只有20M的输出量(SATA RAID x 具体不知道RAID 的方式)   认为无论如何 的省钱 都不能省掉 scsi的钱.

要多多请教K6大大.

linux_pro

高可用集群( High Availability Cluster)
负载均衡集群(Load Balance Cluster)

这个是看CU上来的.

估计你们公司是想 创建 LOAD balance cluster

我是越看头越晕.

看来 这个 学习曲线真的对我来说难度高了点...废话不多说.继续看.