分类： LINUX
2008-01-17 16:37:32
文件:
LVS.rar
大小:
361KB
下载:
下载
http://sery.blog.51cto.com/10037/40660
可扩展、高可用服务网络设计方案
作者:田逸()
定义
可扩展：在用户访问数量快速增长的情况下，不终止现有服务来扩展系统的容量。比如web服务器目前已经不能接受更多的用户访问，可以在不停止服务的情况下增加第2台服务器，甚至更多的服务器，而且新增服务器对已有的服务器不会造成负面影响。
高可用性：没有办法保证系统7*24不发生故障，但用户却要求任何时候都可以正常访问系统，这就是系统高可靠性的需求。一般来说，一个服务是运行在一个系统/机器上，一旦系统/机器出现故障，用户就不能再正常访问这个服务；如果把同一个服务分开放在2个不同的系统/机器，那么即使是一个系统出故障，服务依然是可以访问的。另外一个好处是恢复故障的压力减轻了。
负载均衡：将用户的访问按照某种方式分配到不同的服务器，这样既能减轻单个服务器的负荷，又能增加访问容量。
要点
可扩展性和高可用性不是孤立的，只有结合起来，才能达到理想的效果。因此称这个方案为高可用、可扩展设计。
一、现状
1、 系统多数是windows，可靠性和稳定性都非常的差。在历次的网络安全事故中，windows都是最大的受害者。尽管windows占据了绝大部分的桌面市场，但在服务器领域，其份额还是很少的：象google、yahoo、baidu等拥有上万台服务器应用的机构都不约而同的选择linux/unix做为运营平台来支撑巨大的业务访问。
2、 存在单点故障。每个业务都运行在一个系统/机器上，一旦系统/机器发生故障，业务将不可避免的停止服务。拿网站做例子，web服务apache或数据库(mysql)只要任意一个服务出故障，整个网站的访问将变成不可能。
3、 缺乏集中的，可靠性高的存储机制。现有的配置文件、程序、数据库等数据都是单独存放在各自运行的系统上，维护成本非常高，而且很容易丢失。
4、 不具备可扩展性和高可用性。任何一个服务器出故障，运行在上面的业务将不再问用户提供有效服务。
5、 缺乏有效的流量监控设施。现在总的访问流量是未知数，因此对总带宽的使用率没有评估的依据。租了
二、改进措施
1、尽可能的把应用移植到linux平台。
2、采用NAS存储解决方案。
3、部署同一个业务到不同的服务器，然后使用LVS-DR做负载均衡，同时避免了单点故障。
4、后台数据库mysql采用主从方式的复制机制保证database的高可用性。
三、基本原理：
1、 LVS-DR：这是一个开源的产品，已经成为linux内核的一部分。用户的访问首先被转向到LVS-DR,然后根据业务的类别被重新定向到真实的服务器，由于LVS-DR只是转发，一旦客户短与提供服务的真实服务器连接成功，就不再使用LVS-DR的资源。
2、 多服务器运行同一个应用。既克服单点故障，又能增加系统的容量。
3、 NAS存储。提供集中可靠的存储机制。
4、 Mysql复制。避免数据库单点故障；如果将来访问量增大到一定程度的时候，可以改变到mysql集群的方式
三、实施步骤
1、 移植应用到linux平台
2、 配置LVS-DR负载均衡控制器部分。
3、 部署相同的应用(web等)到两个不同的服务器
4、 部署NAS
5、 测试
6、 正式运营。
四、设备分配
1、 LVS-DR 1个服务器
2、 Web服务器2个
3、 Mysql服务器2个
4、 其他的几个服务器暂时不变
5、 可网管交换机一个(cisco 2950)
6、 NAS一套
五、进度安排
|
名称 |
花费时间 |
备注 |
|
LVS-DR控制器配置 |
1天（以后逐步增加转发条目） |
以配置ipvs转发规则和防火墙规则 |
|
平台移植（windowsàlinux） |
5天 |
已经移植了web和bbs |
|
把服务器加入lvs集群 |
2天 |
已经加了一个bbs和mms |
|
新建一个邮件服务器 |
1天 |
测试中 |
|
部署流量监控 |
1天 |
|
|
Nas上线及配置 |
2天 |
|
|
其他 |
7天 |
|
http://sery.blog.51cto.com/10037/54645
网络环境
1、 硬件：服务器、网络附属存储（NAS）和交换机。3个服务器用来做web,2个服务器
来做流媒体，1个服务器做LVS-DR,2个mysql服务器，一个邮件服务器，2个交换机，一个NETAPP NAS。
2、 运行环境：流媒体windows,其他的都是linux。
逻辑结构：除数据库服务器和NETAPP存储外，其他的服务器都使用2个网络地址，一个公网地址和一个私有网络地址。设置为公网ip的网络接口连接在一个交换机，设置为私有网络ip的网络接另外一个交换机，处于安全和网络带宽考虑，网络存储设备和数据库只使用私有网络地址。网络拓扑图如下所示：
基本原理：
传统模式下，用户的访问请求通过DNS服务器解析后，把服务请求转发给web服务器，取得数据后返回给用户。这种模式有2个麻烦：同时访问的用户增加到某个程度后，服务器不能提供所需的正常访问；遇到故障，所有的访问请求都将失败。要解决这样一个难题,LVS是上上之选。当我们采用lvs方案之后，更改dns服务器的记录，这样用户的访问将首先到达LVS控制器所在的服务器，LVS把请求按照某种算法转发给后面真正的服务器。那么数据的返还是怎样的一个过程呢？在采用DR方式的集群形式下，真实服务器直接把数据返还给用户而不再经过LVS控制器。访问数据的流向在上图中用带箭头的虚线标识出来了，这样设计使得结构更简单一些，lvs控制器的压力也小很多。
根据应用的实际情况考虑，本项目采用LVS/DR方式。
技术实现：
先列出个相关服务器的ip地址：
|
名称 |
Ip地址 | |
|
真实ip地址(RIP) | ||
|
LVS/DR(控制器) |
61.135.55.100/24 |
|
|
RealServer1（Web1） |
61.135.55.150/24 |
192.168.55.150/24 |
|
RealServer2（Web2） |
61.135.55.151/24 |
192.168.55.151/24 |
|
RealServer3（Web3） |
61.135.55.152/24 |
192.168.55.152/24 |
|
RealServer4 （流媒体1） |
61.135.55.153/24 |
192.168.55.153/24 |
|
RealServer5 (流媒体2 ) |
61.135.55.154/24 |
192.168.55.154/24 |
|
MysqlServer1 |
|
192.168.55.90/24 |
|
MysqlServer2 |
|
192.168.55.91/24 |
|
Netapp(网络共享存储) |
|
192.168.55.92/24 |
|
虚拟ip地址（VIP） | ||
|
Web虚拟地址（VIP1） |
61.135.55.160 |
|
|
流媒体虚拟地址（VIP2） |
61.135.55.161 |
|
一、修改DNS记录。
|
www IN A 61.135.55.160 media IN A 61.135.55.161 |
修改bind完成后测试一下，看是否被正确的解析。注意：主机记录应该解析到虚拟地址。
二、配置LVS/DR。
LVS/DR主要由控制器和真实服务器2部分构成，需要在控制器和真实服务器上做好配置才能提供正常的服务，下面分步来说明。
请问你的拓扑图是用什么软件花的啊
office 里的visio 2002
http://netsecurity.51cto.com/art/200706/48728.htm
大型社区网站的架构 (大型社群网站的架构 )[转]
最近一段时间看了一些大型社区网站的架构设计, livejournal,mixi.jp,flick,feedburner,这些网站都有一些共同的特点；数据量大，在线人数多，并发请求多，pageview高，响应速度快，甚至mixi.jp宣称其平均页装载速度0.02秒。
这些网站都没有使用什么大型的"高级"的数据库，全都是Mysql，也没有使用什么"高级"的语言，主要都是perl/php等，只有FB用的是java。这些网站的这些高性能指标基本上都要归功与各网站都有很好的架构设计。
总结了一下各个大型社区网站的架构，希望对我们的产品能够有所借鉴，
主要提高效率及稳定性的几个地方包括：
1，基于集群的负载均衡，失败恢复，包括应用服务器和数据库服务器
基于linux-ha的服务状态检测及高可用化
2，前端的基于静态页面缓存的web加速器，主要应用有squid等
squid 将大部分静态资源(图片，js，css等）缓存起来，直接返回给访问者，减少应用服务器的负载
3，数据库服务器的master-slave模式，利用数据库服务器在主从服务器间进行同步，应用只把数据写到主服务器，而读数据时则根据负载选择一台从服务器或者主服务器来读取
4，将数据按不同策略划分到不同的服务器（组）上，分散数据库压力
5，利用Memcache进行缓存，用大内存把这些不变的数据全都缓存起来，而当修改时就通知cache过期
memcache是LJ开发的一款分布式缓存产品，很多大型网站在应用，我们可以把Cache Server与App Server装在一起。因为Cache Server对CPU消耗不大，而有了Cache Server的支援，App Server对内存要求也不是太高，所以可以和平共处，更有效的利用资源
以上一些不太成熟的想法，我们可以从某一个层次开始，逐步细化，把我们产品的性能指标逐步搞上去。
大型社区网站的架构！
