资源描述
第1章 设计模式基础
第7章 简单CDN
241
第7章 简单CDN
7.1 CDN概述
提示
CDN历史上最有名的事件当属关于克林顿丑闻的斯塔尔报告被放在互联网,因下载该报告的人太多,最终导致服务器瘫痪。该事件直接促使CDN的诞生。
CDN是Content Delivery Network首字母缩写,译成中文就是内容分发网络。使用CDN技术的主要目的在于增加访问速度、解决南北互联(中国适用)、提高用户体验等。
最早的商业CDN服务可能诞生于1999年,但本人闻之CDN这个业务则是2005年的事情了。到了2006年的春天,我有幸得到一个CDN设计方面的工作,这才有机会全面了解CDN原理、设计、部署以及运营等。
7.1.1 为什么使用CDN
(1)解决网站高流量、大并发的问题。我们知道,任何一个物理设备,其负载都有一个极限。为了应对访问量突增,使用CDN服务是一个好的系统扩容方案。
(2)解决南北互联问题。我国的网络是划江而治的格局,因为利益之争,各网络服务商之间并不是通力协作,而是采取各种手段相互限制。这就导致各网之间的互联互通存在很大的问题,具体表现为:电信的用户访问放置在网通机房的服务器,响应时间特别长,反之亦然。使用CDN技术,可以让电信的用户访问电信的内容缓存服务器,网通的用户访问网通的内容缓存服务器。通过这样一种策略,绕开了网络运营商之间人为设置的障碍。
(3)访问加速。CDN采用缓存技术,把访问对象缓存起来,有的技术甚至能把对象缓存到内存(如Varnish),这在效果上表现出来的即是访问加速。
(4)降低总体运营成本。在一些互联互通比较好的第三方BGP机房,其带宽费高达300 ~ 400元/兆/月,而二、三线城市单线接入的带宽费100M一年的费用才5万左右。使用CDN运营方案,我们把源站放在BGP机房,而把缓存服务器放置在带宽费用较低的其他地方。因为CDN的大部分流量被转移到缓存服务器上,源站只有较小的访问请求,因此总体运营成本大幅降低。
(5)提高网站的可用性。源站的访问量变得很小,这意味着源站系统有更低的负载,更低的磁盘I/O,防故障的几率大大降低。对于缓存服务器,多个服务器做成集群,保证了整个系统的高可用。
(6)防DDOS攻击。攻击负载被分配到不同的物理服务器,客观上起到防DDOS的作用。
7.1.2 CDN适用的场合
任何一门技术,都有一定的适用范围,CDN也不例外。实践证明,CDN对于静态对象的加速和发布具有很好的效果,但对于动态的网站,则效果不佳。为了使用CDN技术所带来的好处,我们可以通过动态内容静态化、静态内容分离(如动态站点里的图片)等方式,来加速访问和增强用户体验。
有哪些对象是静态可缓存的呢?这包括html页面文件、视频文件、JS文件、CSS文件、EXE文件、图片文件(JPEG、GIF、PNG)等。
7.1.3 CDN的组成
CDN是一种组合技术,包括源站、缓存服务器、智能DNS、客户端等几个部分。
n 源站指发布内容的原始站点。新增、删除和更改网站的文件,都是在源站上进行的;缓存服务器抓取的对象也全部来自于源站。
n 缓存服务器是直接提供给用户访问的站点资源,有一个或数个服务器组成;当一个用户发起访问时,他的访问请求被智能DNS定位到离他较近的缓存服务器。如果访问所需的内容没有被缓存,则缓存服务器向邻近的缓存服务器或直接向源站抓取内容,然后再返还给用户;如果用户所请求的内容刚好在缓存里面,则直接把内容返还给用户。
n 智能DNS是整个CDN的核心,它负责根据用户的来源,将其访问请求转向到离用户较近或较合适的缓存服务器,如把长沙电信的用户请求转向到长沙电信机房的缓存服务器。实现智能DNS的一种技术是:Bind View,在Bind 9以后的版本,都应该支持View 视图这个功能。另外还有一个方案,即DNS轮询方式。
n 客户端即发起访问的普通用户,一般的访问方式是浏览器。这个不再做说明。
除了前面列举的组件外,还有一个可选项目,即用来进行内部域名以及源站的域名解析。因为是可选的,因此也可以通过使用本地hosts指定主机名来代替。
注意
内部域名系统不能使用合法注册的域名服务器,也即在互联网上,找不到这个域名系统的NS记录。为什么呢?请继续往下看。
接下来,我们以图示来总结一下CDN各组件间的关系和访问流程。
DNS查询路径
DNS
本地DNS
本地DNS
内部DNS
图7-1 CDN各部分间的关系
图7-1展示了两种比较典型的访问场景,这两种场景,基本上能反映整个CDN的工作机制。
n 场景一:当“A网用户”访问被CDN加速的站点 时,从本地的DNS查询域名,最终可能在全局智能DNS服务器得到域名所对应的IP地址,即图7-1所示“A网的缓存服务器”的IP;接着“A网用户”浏览器向“A网的缓存服务器”发起访问请求,幸运的是所需的默认页面文件index.htm正好被缓存在“A网的缓存服务器”里,于是缓存服务器立即返还数据,完成一次访问请求。
n 场景二:当“B网用户”访问被CDN加速的站点 时,从本地的DNS查询域名,最终可能在全局智能DNS服务器得到域名所对应的IP地址,即图7-1所示“B网的缓存服务器”的IP;接着“B网用户”浏览器向“B网的缓存服务器”发起访问请求,但是缓存服务器并没有缓存默认页面文件index.html,它需要先从源站取得这个对象,缓存并把内容返还给“B网用户”。“B网缓存服务器”通过“内部DNS”知道源站在哪里。
7.1.4 CDN的基本特点
CDN的基本特点可概括为:内容缓存、就近访问以及以DNS视图方式根据用户来源确定其访问位置。
n 内容缓存:缓存服务器从源站取得所需数据,然后暂存在本地的硬盘或内存。使用这种缓存机制的好处是:内容自动更新;无多个服务器数据相互同步问题。
n 就近访问:让用户的访问请求转向到离用户最近或最易于访问的缓存服务器。
n 以DNS视图方式根据用户来源确定其访问位置:即让电信的用户访问电信的缓存服务器,网通的用户访问网通的缓存服务器。
7.1.5 什么是简单CDN
简单CDN这个概念,是相对于复杂CDN来定义的。因此,我们先来了解一下什么是复杂的CDN。
笼统一点讲,CDN服务提供商所运营的环境,就是复杂CDN。就缓存服务器而言,其结构是分层次的,一般可划分为核心节点和边缘节点,并且同一层级的相邻节点之间又可形成姐妹关系,亦即在同一个集群下的节点互为姐妹关系。为了保证最高的性能和效率,不提倡跨网或跨物理范围的节点形成姐妹关系。为了更直观地理解这个结构和由此产生的好处,这里以一个最长访问路径的图示来说明,如图7-2所示。
图7-2 缓存服务器相互关系
说明如下:
(1)用户向某边缘服务器(边缘A)发起访问请求,所需内容没有被缓存。
(2)边缘服务器(边缘A)于是询问其邻居,是否缓存了用户所需的请求对象,邻居节点也没有缓存所需的对象。
(3)边缘服务器(边缘A)转而向某个父节点(核心A)请求文件,如果该父节点仍然无所需的文件,则该父节点询问其邻居;如果邻居也没有所需的文件,则把请求转给源站。
(4)源站返回数据给核心节点(核心A),并缓存数据在该节点。
(5)核心节点(核心A)返还数据给边缘节点(边缘A),并缓存数据在该节点。
(6)边缘节点返还数据给用户,一次最长路径的访问完成。
这种分层机制,既能保证最高的可用性,又能最大限度地减少向上一级节点的网络流量。
除了缓存服务器结构上的差异外,复杂CDN还具备以下一些特性。
n 缓存服务器布点范围广,服务器数量庞大。
n 复杂的日志处理系统。因为计费依赖于访问日志。
n 详细的视图划分。例如精确到每个省的IP地址段。
n 预加载机制。
提示
把复杂的CDN简化,使之符合我们的业务需求,是本章“简单CDN”撰写的用意所在。
当我们了解了复杂CDN以后,再来了解简单CDN就容易多了。所谓简单CDN,就是节点层次简单、服务器数量有限、能实现有限规模站点加速和发布的平台。通常情况下,我们不必为实现CDN带来的好处而部署复杂的CDN系统,这将花费巨大的人力、物力。
7.2 简单CDN的设计
提示
先声明一下,本文所设计的简单CDN只是一个样例,并非适用于所有的场景。读者可根据我的思路,设计出更适合自己应用环境的简单CDN。
7.2.1 简单CDN设计的基本原则
简单CDN设计主要考虑以下几点。
n 选点合理,能覆盖大部分网络用户。最起码得在电信和网通机房放置缓存服务器,如果经费充裕,把教育网也考虑进来。
n 系统本身具备很好的高可用特性。用户的访问主要集中在缓存服务器,缓存服务器之间使用集群技术就能得到比较高的系统可用性。
n 核算自建简单CDN的成本,使之有较好的性价比。如果自建一个CDN远比购买CDN服务商所花费的资金还高(目前国内商用CDN每兆带宽为50元/月,基数是1G),基本上没必要自己建立CDN了。
n 系统应该具备很好的伸缩能力,以适应各种业务变化。如增加布点、增加设备、增加站点等。
7.2.2 需求描述
欲对3个Web服务进行加速。为了描述方便,使用域名来进行说明。这3个加速站点为图片站点 、下载站点、主站 ,3个站点全部是静态内容,其页面文件主要是.html(htm)、.exe、.css、.jpeg、.js等,非常适合被缓存。
服务的主要目标用户包括电信线路的用户、网通线路的用户、教育网的用户,其他线路的用户(如科技网、长城宽带等)访问请求被转向到网通线路的缓存服务器。为了实现这个目标,我们可能需要放置4组服务器来做缓存,即电信1组,网通2组,教育网1组。
7.2.3 简单CDN的设计
需求明确之后,接下来的设计工作包括:布点选取、工具选取、CDN结构设计等几部分。
1.布点选取
布点包括源站、全局智能DNS和缓存服务器集群。
n 源站及全局智能DNS选择互联互通性较好的第三方BGH机房;因为使用CDN服务的站点数量有限,故在缓存服务器以主机名的方式寻址源站。
n 缓存服务器共4组,选择二线或三线城市的机房托管,能节省大量的资金(北京、上海等城市带宽价格大概在300 ~ 400元/兆/月,而偏远一点二三线城市(如安阳)1G带宽的年总费用才8 ~ 10万)。
2.工具选取
工具包括操作系统、DNS软件、缓存服务器软件、负载均衡软件、源站软件以及定制的脚本。
n 所有的服务器均使用32位的CentOS 5.x。曾经使用过64位的系统,但在执行缓存服务器的缓存清理操作时,有些小问题。
n DNS使用Bind-9.4.0。低于9.4.0的版本,可能不支持视图View,没有视图功能,智能DNS就无法实现。
n 缓存服务器有两种选择,一种是Squid,另一种是Varnish。Squid多用在复杂CDN场景,它能实现缓存服务器间的层级关系(邻居形成姊妹、边缘节点与核心节点形成父子关系),功能强大而配置复杂;Varnish为后起之秀,配置简单而性能卓越,维护起来也比较简单,因此本案选择Varnish作为缓存工具。
提示
最初的选择是Squid,后来因为在运行过程中TCP的连接数过高而换成Varnish。
n 负载均衡由Ipvsadm和Keepalived两部分组成。Ipvsadm是核心,负责包转发和负载分摊;Keepalived为框架,负责故障隔离和失败切换FailOver。
n 可做Web服务的软件比较多,因为站点为简单的静态文件,选择Nginx比较省事。
n 定制脚本的主要目的是自动刷新缓存服务,把这个脚本放在某个服务器上,只需执行一次(也可使用Crontab自动调用)就能实现所有缓存服务器的缓存清理。
3.CDN结构设计
我们可以根据CDN的角色来设计整个结构,这些角色包括源站、智能DNS及缓存服务器3大部分,根据布点选择和其他因素综合考虑,可以绘出整个CDN的布局结构图如图7-3所示。
全局智能DNS
源站WEB服务器集群
图7-3 CDN服务器布局
从图7-3中可以看出有两组缓存服务器放置在网通机房,这两组服务器不在同一个物理位置。这样做的主要目的是:Bind规划视图View时,能收集到的地址比较有限,不再收集列表的其他IP地址段,则统统转发给网通B机房的服务器;另外网通B机房的带宽比较便宜,机器数量也比较多,跟其他网段的互联互通还可以。
(1)源站
源站为内容的原始发布,尽管采用CDN技术以后源站的负荷会变得很小,但为了有较高的可用性,可以把它部署成负载均衡集群。
(2)智能DNS
强调
IP地址列表为客户DNS服务器所在网段的列表,而不是用户接入网络的IP段。客户端计算机所设定的DNS,通常称为用户本地DNS。同样,为了使其有较高的可用性,DNS采用主从同步的架构。
智能DNS是用来实现用户访问转向功能的,即通过建立访问列表,判断用户的访问来源,确定其访问对象的位置。在本案中,建立电信、网通、教育网3个IP地址列表,未在这3个列表中的称为其他;每个列表关联一个Bind的视图View,那么一共有4个视图View。地址列表可以自己收集,也可以花钱购买,地址列表越大,DNS定向准确性越高。
(3)缓存服务器
缓存服务器是CDN环境使用量最大的设备。为保证缓存服务本身的高可用,每个布点的服务器都以负载均衡集群的方式存在。根据以往的经验,访问负荷比较重的机器,非常容易损坏硬盘,因此在设计时,尽可能地缓存内容到内存中,以增加访问的速度和延长机器的寿命。据说,一些CDN运营商已经开始用固态盘来做缓存空间。
在简单CDN的运行环境中,由于我们所使用的资源有限(服务器数量有限、带宽有限),很可能出现超负荷运行的情况,如单个服务器TCP连接数过高、CPU负载过大、流量峰值带宽超出合同规定的范围等。为了随时掌握整个系统的运行情况,并能对其进行快速反应和调整,因此必须有监控系统对其服务、资源进行实时监控。
为了对设计有一个整体把握,将上文所做的叙述做一个汇总,如表7-1所示。
表7-1 CDN设计汇总
角 色
机器数量
总带宽
高可用方式
放置位置
备 注
源站
3个
100M
负载均衡集群
第三方BGH机房
跟其他服务器共用负载均衡器
智能DNS
2个
100M
DNS主从同步
第三方BGH机房
CDN运营商可能把它的DNS服务器群放在中国科技网
缓存服务器
8*4
100M*4+1G
负载均衡集群
电信、网通、教育网
每个集群2个负载均衡器,6个真实服务器
7.3 简单CDN的实现
这里所讲“简单CDN的实现”主要偏重于技术上的实现,即怎么部署相应的服务和运行它。根据从简到繁的顺序,我们依次描述源站、缓存服务器及全局智能DNS的部署及运行。
7.3.1 源站的部署和运行
源站Web服务既可以是Apache,也可以是Nginx。基于性能和部署简单考虑,选用Nginx做Web工具。
1.安装Nginx
(1)下载最新的稳定版到当前目录:
wget http://nginx.org/download/nginx-0.7.63.tar.gz
(2)解包:
tar zxvf nginx-0.7.63.tar.gz
(3)切换目录:
cd nginx-0.7.63
(4)检查是否存在:
pcre rpm -qa | grep pcre
(5)配置:
./configure –prefix=/usr/local/nginx
(6)编译、安装:
注意
不是configure带的选项越多越高明。
make;make install
检查安装是否正常:查看是否生成指定目录/usr/local/nginx即可初步判定。
2.配置Nginx
根据前面的规划,需要把源站做成高可用的负载均衡环境,因此,需要在一个物理Web上同时运行3个站点,然后由这3个Web组成LVS集群。对于单个的Nginx配置文件,就是运行3个虚拟主机。
为了方便以后的维护,采取配置文件分割的方式进行处理。即配置文件分主配置文件和虚拟机配置文件。主配置文件include指令包含各个虚拟机配置文件。对应于3个不同的站点,其配置文件的名称分别为www.conf、dl.conf和images.conf。
(1)主配置文件 /usr/local/nginx/conf/nginx.conf(部分参数来源于小毛)。
user www;
worker_processes 10;
error_log /data/logs/error.log;
events {
worker_connections 10240;
use kqueue;
}
http {
include mime.types;
default_type application/octet-stream;
include vhosts/*.conf;
log_format main '$remote_addr - $remote_user [$time_local]
$request '
'"$status" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /data/logs/access.log main;
sendfile on;
userid_expires max;
tcp_nopush on;
tcp_nodelay on;
server_names_hash_bucket_size 256;
client_header_buffer_size 256k;
large_client_header_buffers 4 256k;
client_max_body_size 20m;
client_header_timeout 3m;
client_body_timeout 3m;
send_timeout 3m;
output_buffers 1 32k;
postpone_output 1460;
keepalive_timeout 60 10;
gzip on;
gzip_types text/plain text/html text/css application/
x-javascript;
}
(2)虚拟主机配置文件,一共3个。在/usr/local/nginx/conf下创建目录vhosts,然后在这个目录下创建3个虚拟机配置文件,其内容分别如下:
① 配置文件www.conf:
server {
listen 80 ;
server_name ;
index index.htm index.html;
root /mnt/html/www;
error_page 404 /404.htm;
autoindex_exact_size on;
access_log /data/logs/nginx-access/www.log combined;
}
② 配置文件images.conf:
server {
listen 80 ;
server_name ;
index index.htm index.html;
root /mnt/html/images;
error_page 404 /404.htm;
autoindex_exact_size on;
access_log /data/logs/nginx-access/images.log combined;
}
③ 配置文件dl.conf:
server {
listen 80 ;
server_name ;
index index.htm index.html;
root /mnt/html/dl;
error_page 404 /404.htm;
autoindex_exact_size on;
access_log /data/logs/nginx-access/dl.log combined;
}
配置文件的根文档所在的目录/mnt/html为NFS服务的挂接点,3个物理服务器共享该目录,这样做的好处是修改站点时只需登录任意一个服务器做更改,而不必额外做同步操作。如果条件许可,使用分布式文件系统共享存储,将会得到更好的可用性和更快的访问速度。
上述文件都配置好以后,安装配置文件的设定创建好相关的目录,然后把相关的站点文件复制到各自的目录。接着运行/usr/local/nginx/sbin/nginx –t检查一下语法,无误后再执行命令 /usr/local/nginx/sbin/nginx 启动Nginx。
接着,我们在Windows客户端机器修改系统的hosts文件,把如下的行追加进文件hosts:
125.88.62.100
125.88.62.100
125.88.62.100
保存文件以后,再用浏览器分别访问这3个站点,以检验配置的正确性。
3.配置负载均衡
(1)安装和配置其他两个服务器的Nginx,并逐个检查其正确性。因为3个服务器均以共享方式挂接网站的目录,因此只需要安装和配置好Nginx,而不必再复制站点的内容到本地文件系统。
(2)部署负载均衡,具体过程参见“负载均衡”一章。负载均衡被正确配置和启动以后,我们再回来修改客户端Windows 的系统hosts文件,使负载均衡的VIP与域名绑定,然后再用浏览器访问3个域名,检查加入负载均衡环境后,各站点的运行情况。记住这个VIP(125.88.62.99),以后我们在缓存服务器上会使用它。
7.3.2 缓存服务器的部署和运行
说明
最开始,我使用了Squid做缓存工具,但是运行一段时间以后,发现负载比较大,具体表现在单个服务器的TCP连接数(ESTABLISHED)一般在20000以上,从而导致一些访问失败。后来,把它换成Varnish,则单服务器的连接数稳定在1000以下的水平。
缓存服务器部署包括负载均衡和缓存工具两部分的操作。
1.安装Varnish
(1)下载Varnish到本地目录:
wget
/varnish-1.1.2.tar.gz/download
(2)解包:
tar zxvf varnish-1.1.2.tar.gz
(3)切换目录:
cd varnish-1.1.2
(4)配置,编译和安装:
提示
撰写本文的时候,Varnish的最新稳定版本是2.0.6。和旧的1.x版本相比,其配置文件的书写规则有较大的变化,具体请参照官方的文档或手册。
./configure –prefix=/usr/local/varnish ; make ; make install
2.配置Varnish
Varnish的配置分两部分:源站名称的解析和Varnish本身的配置文件。在我的应用中,总共有3个站点需要缓存,因此需要解析出3个源站和配置3个站点的缓存。
(1)源站地址解析
这里我们再来回顾一下源站地址解析的作用:缓存服务器通过这个机制来寻找源站在何处。在我们这个小规模的场景,用本地hosts绑定域名即可实现源站地址解析,而在复杂的CDN环境,则需要使用专门的DNS服务器来完成这个工作。修改后的服务器的/etc/hosts文件如下:
125.88.62.99
125.88.62.99
125.88.62.99
修改保存后,用域名检查其网络连通性,如ping 。
(2)配置Varnish
Varnish解包以后,可在解包后的目录找到一个名为default.vcl的配置样例文件,参考这个样例文件,则能编写出符合我们实际需求的配置。这里,我先列出完整的配置文件,然后再做一些说明。
more /usr/local/varnish/sery_vcl.conf
1 #write by sery,2009-10-12
2 backend www {
3 set backend.host = "";
4 set backend.port = "80";
5 }
6
7 backend images{
8 set backend.host = "";
9 set backend.port = "80";
10 }
11
12 backend dl{
13 set backend.host = "";
14 set backend.port = "80";
15 }
16
17
18 acl purge {
19 "localhost";
20 "127.0.0.1";
21 "211.99.76.0"/24;
22 }
23
24
25 sub vcl_recv {
26 if (req.request == "PURGE") {
27 if (!client.ip ~ purge) {
28 error 405 "Not allowed.";
29 }
30 lookup;
31 }
32
33 if (req.http.host ~ "^") {
34 set req.backend = www;
35 if (req.request != "GET" && req.request != "HEAD") {
36 pipe;
37 }
38 elseif(req.url ~ "\.(PHP|cgi)($|\?)") {
39 pass;
40 }
41 else {
42 lookup;
43 }
44 }
45
46 if (req.http.host ~ "^") {
47 set req.backend = images;
48 if (req.request != "GET" && req.request != "HEAD") {
49 pipe;
50 }
51 elseif(req.url ~ "\.(PHP|cgi)($|\?)") {
52 pass;
53 }
54 else {
55 lookup;
56 }
57 }
58
59 if (req.http.host ~ "^") {
60 set req.backend = dl;
61 if (req.request != "GET" && req.request != "HEAD") {
62 pipe;
63 }
64 elseif(req.url ~ "\.(PHP|cgi)($|\?)") {
65 pass;
66 }
67 else {
68 lookup;
69 }
70 }
71
72 else {
73 error 404 "Sery Cache Server";
74 lookup;
75 }
76 }
77
78 sub vcl_hit {
79 if (req.request == "PURGE") {
80 set obj.ttl = 0s;
81 error 200 "Purged.";
82 }
83 }
84
85 sub vcl_miss {
86 if (req.request == "PURGE") {
87 error 404 "Not in cache.";
88 }
89 }
90
91 sub vcl_fetch {
92 if (req.request == "GET" && req.url ~ "\.(html|htm|css|txt|js)$")
{
93 set obj.ttl = 600s;
94 }
95 else {
96 set obj.ttl = 5d;
97 }
98 }
n 2 ~ 15行定义需要做缓存的域名。
n 18 ~ 22行定义哪些主机或网段可以执行缓存刷新操作。
n 25 ~ 76行定义用户请求及缓存处理的方法:缓存哪些域名、不缓存哪些对象(如动态对象-PHP,JSP等)。不缓存的内容,则把用户的请求直接转向到源站处理。
n 91 ~ 98行定义缓存对象的过期时间。本案中,凡是url以.html、.htm、.css、.txt、.js结尾的,其缓存期限设定为600秒,其他不在这个列表中的url则设定为5天。
3.运行Varnish
与其他开源软件相比,Varnish的启动确实很复杂。为了能正确运行Varnish并检验其是否正常运行起来,建议以如下的步骤进行操作。
(1)检查/etc/hosts文件是否正确。在本案中,可以在缓存服务器ping 等3个域名,检查地址解析是否正确、网络是否连通。
(2)检查Varnish配置文件的书写是否有遗漏或错误。一般最容易犯的错误是少写花括号“}”。
(3)创建缓存目录。为提高可靠性,我把缓存目录创建到其他分区。Varnish安装的目录为/usr/local/varnish,则创建的目录为/var/vcache。注:/var与/usr是不同的分区。
(4)修改系统内核参数,以优化系统的性能。我的某个服务器的系统内核参数新增内容如下(可选):
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.ip_local_port_range = 5000 65000
net.ipv4.tcp_max_syn_backlog = 8192
dev_max_backlog = 1000
net.ipv4.tcp_max_tw_buckets = 50000
net.ipv4.ip_conntrack_max = 655360
filter.ip_conntrack_tcp_timeout_established = 180
net.ipv4.tcp_rmem = 4096 87380 524288
net.core.rmem_max = 1048576
(5)启动Varnish。内容实在太长,得写成好几行才行:
/usr/local/varnish/sbin/varnishd -n /var/vcache -f /usr/local/
varnish/sery.vcl \
-a 0.0.0.0:80\
-s file,/var/vcache/varnish_cache.data,\
2047M -w 30000,51200,10 -T 127.0.0.1:3500 -p client_http11=on
提示
曾经参看张宴的文档(
(6)检验Varnish是否正常运行:
n 检查进程。正常运行的Varnish,应该是两个进程。
n 检查目录/var/vcache,查看是否有varnish_cache.data等文件自动生成。
n 检查TCP 80端口是否处于监听状态。
n 查看系统日志,了解Varnish的启动状态。如果有问题的话,会在系统日志得到有用的排错信息。
n 查看Varni
展开阅读全文