简单CDN部署实现

masked 贡献于2011-10-25

作者 sery  创建于2010-12-26 13:25:00   修改者sery  修改于2010-12-26 13:25:00字数28145

文档摘要:CDN是Content Delivery Network首字母缩写,译成中文就是内容分发网络。使用CDN技术的主要目的在于增加访问速度、解决南北互联(中国适用)、提高用户体验等。 最早的商业CDN服务可能诞生于1999年,但本人闻之CDN这个业务则是2005年的事情了。到了2006年的春天,我有幸得到一个CDN设计方面的工作,这才有机会全面了解CDN原理、设计、部署以及运营等。
关键词:

 第1章 设计模式基础 第7章 简单CDN 第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,防故障的几率大大降低。对于缓存服务器,多个服务器做成集群,保证了整个系统的高可用。 第7章 简单CDN (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记录。为什么呢?请继续往下看。 第7章 简单CDN 接下来,我们以图示来总结一下CDN各组件间的关系和访问流程。 DNS查询路径 DNS 本地DNS 本地DNS 内部DNS 图7-1 CDN各部分间的关系 图7-1展示了两种比较典型的访问场景,这两种场景,基本上能反映整个CDN的工作机制。 n 场景一:当“A网用户”访问被CDN加速的站点 http://www.formyz.cn时,从本地的DNS查询域名,最终可能在全局智能DNS服务器得到域名所对应的IP地址,即图7-1所示“A网的缓存服务器”的IP;接着“A网用户”浏览器向“A网的缓存服务器”发起访问请求,幸运的是所需的默认页面文件index.htm正好被缓存在“A网的缓存服务器”里,于是缓存服务器立即返还数据,完成一次访问请求。 n 场景二:当“B网用户”访问被CDN加速的站点 http://www.formyz.cn时,从本地的DNS查询域名,最终可能在全局智能DNS服务器得到域名所对应的IP地址,即图7-1所示“B网的缓存服务器”的IP;接着“B网用户”浏览器向“B网的缓存服务器”发起访问请求,但是缓存服务器并没有缓存默认页面文件index.html,它需要先从源站取得这个对象,缓存并把内容返还给“B网用户”。“B网缓存服务器”通过“内部DNS”知道源站在哪里。 7.1.4 CDN的基本特点 CDN的基本特点可概括为:内容缓存、就近访问以及以DNS视图方式根据用户来源确定其访问位置。 第7章 简单CDN n 内容缓存:缓存服务器从源站取得所需数据,然后暂存在本地的硬盘或内存。使用这种缓存机制的好处是:内容自动更新;无多个服务器数据相互同步问题。 n 就近访问:让用户的访问请求转向到离用户最近或最易于访问的缓存服务器。 n 以DNS视图方式根据用户来源确定其访问位置:即让电信的用户访问电信的缓存服务器,网通的用户访问网通的缓存服务器。 7.1.5 什么是简单CDN 简单CDN这个概念,是相对于复杂CDN来定义的。因此,我们先来了解一下什么是复杂的CDN。 笼统一点讲,CDN服务提供商所运营的环境,就是复杂CDN。就缓存服务器而言,其结构是分层次的,一般可划分为核心节点和边缘节点,并且同一层级的相邻节点之间又可形成姐妹关系,亦即在同一个集群下的节点互为姐妹关系。为了保证最高的性能和效率,不提倡跨网或跨物理范围的节点形成姐妹关系。为了更直观地理解这个结构和由此产生的好处,这里以一个最长访问路径的图示来说明,如图7-2所示。 图7-2 缓存服务器相互关系 第7章 简单CDN 说明如下: (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章 简单CDN 7.2.1 简单CDN设计的基本原则 简单CDN设计主要考虑以下几点。 n 选点合理,能覆盖大部分网络用户。最起码得在电信和网通机房放置缓存服务器,如果经费充裕,把教育网也考虑进来。 n 系统本身具备很好的高可用特性。用户的访问主要集中在缓存服务器,缓存服务器之间使用集群技术就能得到比较高的系统可用性。 n 核算自建简单CDN的成本,使之有较好的性价比。如果自建一个CDN远比购买CDN服务商所花费的资金还高(目前国内商用CDN每兆带宽为50元/月,基数是1G),基本上没必要自己建立CDN了。 n 系统应该具备很好的伸缩能力,以适应各种业务变化。如增加布点、增加设备、增加站点等。 7.2.2 需求描述 欲对3个Web服务进行加速。为了描述方便,使用域名来进行说明。这3个加速站点为图片站点 images.sery.cn、下载站点dl.sery.cn、主站 www.sery.cn,3个站点全部是静态内容,其页面文件主要是.html(htm)、.exe、.css、.jpeg、.js等,非常适合被缓存。 服务的主要目标用户包括电信线路的用户、网通线路的用户、教育网的用户,其他线路的用户(如科技网、长城宽带等)访问请求被转向到网通线路的缓存服务器。为了实现这个目标,我们可能需要放置4组服务器来做缓存,即电信1组,网通2组,教育网1组。 7.2.3 简单CDN的设计 需求明确之后,接下来的设计工作包括:布点选取、工具选取、CDN结构设计等几部分。 1.布点选取 布点包括源站、全局智能DNS和缓存服务器集群。 n 源站及全局智能DNS选择互联互通性较好的第三方BGH机房;因为使用CDN服务的站点数量有限,故在缓存服务器以主机名的方式寻址源站。 第7章 简单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所示。 第7章 简单CDN 全局智能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运营商已经开始用固态盘来做缓存空间。 第7章 简单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)下载最新的稳定版到当前目录: 第7章 简单CDN 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; } 第7章 简单CDN 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 www.sery.cn; index index.htm index.html; 第7章 简单CDN 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 images.sery.cn; 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 dl.sery.cn; 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 第7章 简单CDN : 125.88.62.100 www.sery.cn 125.88.62.100 images.sery.cn 125.88.62.100 dl.sery.cn 保存文件以后,再用浏览器分别访问这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 http://sourceforge.net/projects/varnish/files/varnish/1.1.2 /varnish-1.1.2.tar.gz/download (2)解包: tar zxvf varnish-1.1.2.tar.gz (3)切换目录: cd varnish-1.1.2 第7章 简单CDN (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 www.sery.cn 125.88.62.99 images.sery.cn 125.88.62.99 dl.sery.cn 修改保存后,用域名检查其网络连通性,如ping www.sery.cn 。 (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 = "www.sery.cn"; 4 set backend.port = "80"; 5 } 6 7 backend images{ 8 set backend.host = "images.sery.cn"; 9 set backend.port = "80"; 第7章 简单CDN 10 } 11 12 backend dl{ 13 set backend.host = "dl.sery.cn"; 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 ~ "^www.sery.cn") { 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 } 第7章 简单CDN 45 46 if (req.http.host ~ "^images.sery.cn") { 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 ~ "^dl.sery.cn") { 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") { 第7章 简单CDN 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 www.sery.com 第7章 简单CDN 等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 net.core.netdev_max_backlog = 1000 net.ipv4.tcp_max_tw_buckets = 50000 net.ipv4.ip_conntrack_max = 655360 net.ipv4.netfilter.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 提示 曾经参看张宴的文档(http://blog.s135.com/post/313/),出于安全考虑,他在部署时使用了其他用户来运行Varnish。而在我的环境里,由于缓存服务器只做缓存用,所以舍弃了这个步骤,直接用root来操作了。为了能开机自动运行Varnish,需要把这个内容追加到文件/etc/rc.local。 (6)检验Varnish是否正常运行: n 检查进程。正常运行的Varnish,应该是两个进程。 第7章 简单CDN n 检查目录/var/vcache,查看是否有varnish_cache.data等文件自动生成。 n 检查TCP 80端口是否处于监听状态。 n 查看系统日志,了解Varnish的启动状态。如果有问题的话,会在系统日志得到有用的排错信息。 n 查看Varnish 缓存情况:/usr/local/varnish/bin/varnishstat –n /var/vcache。 (7)Varnish缓存功能验证: n 在其他Windows主机修改hosts文件,新增如下3行: 211.99.76.121 www.sery.cn 211.99.76.121 dl.sery.cn 211.99.76.121 image.sery.cn n 用此Windows主机的浏览器访问 http://211.99.76.121 。正常情况下,应该访问不到任何页面(404错误)。 n 用此Windows主机的浏览器分别访问 www.sery.cn等3个域名,如果都能正常访问到页面文件,则表明Varnish完全按照我们的意愿进行工作。 接下来,在其他缓存服务器上进行相同的操作,这里不再赘述。 4.缓存服务负载均衡配置 (1)配置:请参看第6章“负载均衡”相关内容。 (2)检验Varnish集群服务(负载均衡集群的VIP是211.99.76.120)。 (3)在其他Windows主机修改hosts文件,新增如下3行。 211.99.76.120 www.sery.cn 211.99.76.120 dl.sery.cn 211.99.76.120 image.sery.cn (4)用此Windows主机的浏览器访问 http://211.99.76.120。正常情况下,应该访问不到任何页面(404错误)。 (5)用此Windows主机的浏览器分别访问 www.sery.cn等3个域名,如果都能正常访问到页面文件,则表明Varnish完全按照我们的意愿进行工作。 (6)在其他的机房做同样的部署和操作。 7.3.3 智能DNS的部署和运行 智能DNS的部署和运行分为:收集IP地址、部署DNS以及运行这几个部分。 第7章 简单CDN 1.收集IP地址 (1)收集的策略 根据前边的设计,我们需要3份地址列表,以对应电信、网通及教育网的用户。已经分配出去的IP地址那么多,我们应当怎样收集和归类呢?如果地址列表过大,可能会严重影响DNS服务器的性能(Bind将遍历一个很大的文件)。另外,可能有些IP地址即使收集上来了,也不会有什么帮助,如普通ADSL拨号自动分配的IP。 在整个CDN环节,由哪些组件来进行寻址呢?答案是用户使用的DNS(自己在电脑里指定的,称本地DNS)和做CDN名称解析DNS的这部分。 因此,我们只需要收集互联网上DNS服务器的IP地址,就可以达到我们的目的。这样一来,收集下来的数量就会大大降低。为了更进一步缩小范围,一般使用网络地址的形式,如123.175.0.0/16。在IP列表文件,就这么一行,却可以囊括很多DNS服务器。 (2)收集的方法 ① 网上查找。 ② 利用shell脚本,从apnic(http://www. apnic.net)抓取。我在网上找了一个shell脚本get_ip.sh,稍微修改了一下,其内容如下(原作者不详): #!/bin/sh FILE=/root/apnic/ip_apnic wget http://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest -O $FILE grep 'apnic|CN|ipv4|' $FILE | cut -f 4,5 -d'|'|sed -e 's/|/ /g' | while read ip cnt do     echo $ip:$cnt     mask=$(cat << EOF | bc | tail -1 pow=32; define log2(x) { if (x<=1) return (pow); pow--; return(log2(x/2)); } log2($cnt) EOF)      echo $ip/$mask>> cn.net 第7章 简单CDN NETNAME=’whois $ip@whois.apnic.net | sed -e ‘/./{H;$!d;}’ –e \ ‘x;/netnum/!d’ |grep ^netname | awk ‘{print $2}’|awk -F- ‘{print $1}’`     case $NETNAME in     CNC)        echo $ip/$mask >> UNICOM     ;;     CNCGROUP| UNICOM)        echo $ip/$mask >> UNICOM     ;;     CHINATELECOM|CHINANET)        echo $ip/$mask >> TELECOM     ;; CERNET)  echo $ip/$mask >>EUD ;;     *)        echo $ip/$mask >> OTHER     ;;     esac done 执行这个脚本,将在目录/root/apnic生成UNICOM、TELECOM等几个文件。其中UNICOM代表新联通的IP地址段,TELECOM代表电信的IP地址段。 ③ 购买IP地址段或者通过与CDN服务商合作获得IP地址列表或API接口。 (3)IP地址列表处理。通过上述方法收集来的IP,把它们各自合并【注1】、排序、删除重复的,备用。处理好后的IP列表文件分别为:unicom_ip、telecom_ip、edu_ip。 【注1】到本文撰写时,网通与联通公司已经合并,尽管在Apnic能查出CNC标识的IP分配列表,但数量已经很少,我在处理列表时,已经把它与UNICOM进行合并了。 2.DNS服务器部署 (1)选择DNS服务器操作系统平台和软件。操作系统选择CentOS或FreeBSD,DNS的软件则选择Bind,理由如下: n 开源软件,免费且能按要求定制。 第7章 简单CDN n 支持视图View。其他DNS软件可能没有这个功能。 (2)安装和初步配置Bind。具体可参见本书第4章“域名服务DNS”相关内容。 (3)产生主从DNS同步所需的TSIG KEY。共有4个视图,因此需要执行4次TSIG KEY 生成操作。其操作步骤如下: DNSsec-keygen -a hmac-md5 -b 128 -n HOST uincom DNSsec-keygen -a hmac-md5 -b 128 -n HOST telecom DNSsec-keygen -a hmac-md5 -b 128 -n HOST edu DNSsec-keygen -a hmac-md5 -b 128 -n HOST any 执行完毕后,将生成以下8个文件,如图7-4所示。 图7-4 TSIG加密生成KEY文件对 这些文件都是文本文件,可以用任何文本编辑器打开。通过对比文件对,将发现K*.key与K*.private之间的对应关系(正因为如此,我把它们叫做文件对)。在Bind的主配置文件里,我们所需的TSIG KEY就从这些文件中得到。具体的取值就是打开每个K*.private,复制第3行“key:”后面的字符串。当然,从对应的K*.key文件取值也是可以的,仅仅是字符串的位置不同而已。图7-5指出了TSIG KEY的出处。 图7-5 TSIG KEY文件内容 最好在named配置文件named.conf的同一目录/usr/local/named/etc 生成这些key文件对,以方便将来维护时查找。 (4)生成3个视图View访问控制列表文件。为何这里只有3个视图访问控制列表文件而不是4个呢?原因是“other”这个视图不需要IP列表,只需以“any”的方式来代替IP列表。实际上,这3个访问控制列表文件也不是必须的,可以通过在Bind 的配置文件中加入文件块的方式达到相同的效果。但是为了维护的便利,生成单独的文件,然后以include的方式包含进去。 (5)切换到Bind的数据目录,然后把“收集IP地址”那一步生成的“unicom_ip、telecom_ip、edu_ip”这3个文件复制过来。 第7章 简单CDN (6)分别在“unicom_ip、telecom_ip、edu_ip”这三个文件的第一行加上acl “STRINGS”{,后面的行尾加上分号“;”,文件的末尾新增一行 “};”以便与第一行的“{”配对。完成后另存文件为unicom_acl.conf、telecom_acl.conf、edu_acl.conf。在这里,我以最短的edu_acl.conf为例,来了解一下这个文件的内容究竟是什么样子: acl "EDU" { 58.154.0.0/15; 58.192.0.0/12; 59.64.0.0/12; 110.64.0.0/15; 113.54.0.0/15; 114.212.0.0/15; 114.214.0.0/16; 115.24.0.0/14; 115.154.0.0/15; 115.156.0.0/15; 115.158.0.0/16; 116.13.0.0/16; 116.56.0.0/15; 118.202.0.0/15; 118.228.0.0/15; 118.230.0.0/16; 120.94.0.0/15; 121.48.0.0/15; 121.52.160.0/19; 121.192.0.0/14; 121.248.0.0/14; 122.204.0.0/14; 125.216.0.0/13; 162.105.0.0/16; 166.111.0.0/16; 202.4.128.0/19; 202.38.64.0/18; 202.38.140.0/23; 202.38.184.0/21; 第7章 简单CDN 202.38.192.0/18; 202.112.0.0/13; 202.120.0.0/15; 202.127.216.0/21; 202.127.224.0/19; 202.179.240.0/20; 202.192.0.0/12; 203.91.120.0/21; 210.25.0.0/17; 210.25.128.0/18; 210.26.0.0/15; 210.28.0.0/14; 210.32.0.0/12; 211.64.0.0/13; 211.80.0.0/13; 218.192.0.0/13; 219.216.0.0/13; 219.224.0.0/13; 219.242.0.0/15; 219.244.0.0/14; 222.16.0.0/12; 222.192.0.0/12; }; (7)更新Bind配置文件named.conf。 ① 主DNS服务器Bind的配置文件named.conf的内容为: 1 options { 2 directory "/data/named"; 3 allow-query-cache {any;}; 4 pid-file "named.pid"; 5 }; 6 7 key "rndc-key" { 8 algorithm hmac-md5; 9 secret "AqsSl6KdixnkKwRrV7zRqA=="; 第7章 简单CDN 10 }; 11 12 controls { 13 inet 127.0.0.1 port 953 14 allow { 127.0.0.1; } keys { "rndc-key"; }; 15 }; 16 17 logging { 18 channel query_log { 19 file "query.log" versions 3 size 20m; 20 severity info; 21 print-time yes; 22 print-category yes; 23 }; 24 category queries { 25 query_log; 26 }; 27 }; 28 29 30 ### KEYS FOR TSIG #### 31 key telecomkey { 32 algorithm hmac-md5; 33 secret "LaA4Y1MHlFSTTMz1mzwarA=="; 34 }; 35 36 key unicomkey { 37 algorithm hmac-md5; 38 secret "l/rlorcG+7hhabIFKe8Kjg=="; 39 }; 40 41 key edukey { 42 algorithm hmac-md5; 43 secret "Zf7vW4wZ1ECLPVFs2bRmEQ=="; 44 }; 第7章 简单CDN 45 46 key anykey { 47 algorithm hmac-md5; 48 secret "YMXXBAck4i5Sb4PlUg00Uw=="; 49 }; 50 51 52 include "unicom_acl.conf"; 53 include "telecom_acl.conf"; 54 include "edu_acl.conf"; 55 56 view "view_unicom" { 57 match-clients {key unicomkey;UNICOM;}; 58 recursion yes; 59 allow-transfer { key unicomkey;}; 60 server 61.135.154.50 { keys unicomkey; }; 61 server 221.179.218.165 { keys unicomkey; }; 62 63 zone "." IN { 64 type hint; 65 file "named.ca"; 66 }; 67 68 zone "localhost" IN { 69 type master; 70 file "localhost.zone"; 71 allow-update { none; }; 72 }; 73 74 zone "0.0.127.in-addr.arpa" IN { 75 type master; 76 file "named.local"; 77 allow-update { none; }; 78 }; 79 第7章 简单CDN 80 zone "sery.cn" IN { 81 type master; 82 file "unicom.sery.cn.zone"; 83 allow-update { none;} ; 84 }; 85 }; 86 87 view "view_telecom" { 88 match-clients {key telecomkey ;TELECOM;}; 89 recursion yes; 90 allow-transfer { key telecomkey;}; 91 server 61.135.154.50 {keys telecomkey;}; 92 server 221.179.218.165 {keys telecomkey;}; 93 94 zone "." IN { 95 type hint; 96 file "named.ca"; 97 }; 98 99 zone "localhost" IN { 100 type master; 101 file "localhost.zone"; 102 allow-update { none; }; 103 }; 104 105 zone "0.0.127.in-addr.arpa" IN { 106 type master; 107 file "named.local"; 108 allow-update { none; }; 109 }; 110 111 zone "sery.cn" IN { 112 type master; 113 file "telecom.sery.cn.zone"; 114 allow-update { none;} ; 第7章 简单CDN 115 }; 116 }; 117 118 view "view_edu" { 119 match-clients {key edukey ;EDU;}; 120 recursion yes; 121 allow-transfer { key edukey;}; 122 server 61.135.154.50 {keys edukey;}; 123 server 221.179.218.165 {keys edukey;}; 124 125 zone "." IN { 126 type hint; 127 file "named.ca"; 128 }; 129 130 zone "localhost" IN { 131 type master; 132 file "localhost.zone"; 133 allow-update { none; }; 134 }; 135 136 zone "0.0.127.in-addr.arpa" IN { 137 type master; 138 file "named.local"; 139 allow-update { none; }; 140 }; 141 142 zone "sery.cn" IN { 143 type master; 144 145 file "edu.sery.cn.zone"; 146 allow-update { none;} ; 147 }; 148 }; 149 第7章 简单CDN 150 view "other" { 151 match-clients {key anykey;any;}; 152 recursion yes; 153 allow-transfer { key anykey;}; 154 server 61.135.154.50 {keys anykey;}; 155 server 221.179.218.165 {keys anykey;}; 156 157 zone "." IN { 158 type hint; 159 file "named.ca"; 160 }; 161 162 zone "localhost" IN { 163 type master; 164 file "localhost.zone"; 165 allow-update { none; }; 166 }; 167 168 zone "0.0.127.in-addr.arpa" IN { 169 type master; 170 file "named.local"; 171 allow-update { none; }; 172 }; 173 174 zone "sery.cn" IN { 175 type master; 176 file "sery.cn.zone"; 177 allow-update { none;} ; 178 }; 179 }; n 17 ~ 27行,启用查询日志并使用日志轮转。 n 30 ~ 49行,TSIG KEY使用定义。Secret 后面的字符串由相应的k*.private文件中取得,前面已经做了描述。 n 52 ~ 54行,把预先定义好的访问控制列表文件包含进来。注意这些文件应该被放置在options块所定义的数据目录 第7章 简单CDN (/data/named)里。 n 56 ~ 59行,定义视图view_unicom。其目的是:当有来自unicom_acl.conf文件所列IP范围内的客户发起查询请求时,使用本视图的区文件进行域名解析。通俗的说,就是让联通线路的用户,去访问联通机房的服务器。 n 60 ~ 61行,主DNS服务器的IP地址和辅助DNS的IP地址。其中61.135.154.50是主DNS服务器,另外一个则是从DNS服务器。 ② 辅助DNS服务器BIND的配置文件/usr/local/named/etc/named.conf的内容为: 1 options { 2 directory "/data/named"; 3 allow-query-cache {any;}; 4 pid-file "named.pid"; 5 }; 6 7 key "rndc-key" { 8 algorithm hmac-md5; 9 secret "BBGIMDDMQ0wskl/LlFQb6w=="; 10 }; 11 12 controls { 13 inet 127.0.0.1 port 953 14 allow { 127.0.0.1; } keys { "rndc-key"; }; 15 }; 16 17 logging { 18 channel query_log { 19 file "query.log" versions 3 size 20m; 20 severity info; 21 print-time yes; 22 print-category yes; 23 }; 24 category queries { 25 query_log; 26 }; 27 }; 第7章 简单CDN 28 29 30 ### KEYS FOR TSIG #### 31 key telecomkey { 32 algorithm hmac-md5; 33 secret "LaA4Y1MHlFSTTMz1mzwarA=="; 34 }; 35 36 key unicomkey { 37 algorithm hmac-md5; 38 secret "l/rlorcG+7hhabIFKe8Kjg=="; 39 }; 40 41 key edukey { 42 algorithm hmac-md5; 43 secret "Zf7vW4wZ1ECLPVFs2bRmEQ=="; 44 }; 45 46 key anykey { 47 algorithm hmac-md5; 48 secret "YMXXBAck4i5Sb4PlUg00Uw=="; 49 }; 50 51 52 include "unicom_acl.conf"; 53 include "telecom_acl.conf"; 54 include "edu_acl.conf"; 55 56 view "view_cnc" { 57 match-clients {key unicomkey;UNICOM;}; 58 recursion yes; 59 allow-transfer { key unicomkey;}; 60 server 61.135.154.50 { keys unicomkey; }; 61 62 zone "." IN { 第7章 简单CDN 63 type hint; 64 file "named.ca"; 65 }; 66 67 zone "localhost" IN { 68 type master; 69 file "localhost.zone"; 70 allow-update { none; }; 71 }; 72 73 zone "0.0.127.in-addr.arpa" IN { 74 type master; 75 file "named.local"; 76 allow-update { none; }; 77 }; 78 79 zone "sery.cn" IN { 80 type slave; 81 file "cnc.sery.cn.backup"; 82 masters { 61.135.154.50;} ; 83 }; 84 }; 85 86 view "view_telecom" { 87 match-clients {key telecomkey ;TELECOM;}; 88 recursion yes; 89 allow-transfer { key telecomkey;}; 90 server 61.135.154.50 {keys telecomkey;}; 91 92 zone "." IN { 93 type hint; 94 file "named.ca"; 95 }; 96 97 zone "localhost" IN { 第7章 简单CDN 98 type master; 99 file "localhost.zone"; 100 allow-update { none; }; 101 }; 102 103 zone "0.0.127.in-addr.arpa" IN { 104 type master; 105 file "named.local"; 106 allow-update { none; }; 107 }; 108 109 zone "sery.cn" IN { 110 type slave; 111 file "telecom.sery.cn.backup"; 112 masters { 61.135.154.50;} ; 113 }; 114 }; 115 116 view "view_edu" { 117 match-clients {key edukey ;EDU;}; 118 recursion yes; 119 allow-transfer { key edukey;}; 120 server 61.135.154.50 {keys edukey;}; 121 122 zone "." IN { 123 type hint; 124 file "named.ca"; 125 }; 126 127 zone "localhost" IN { 128 type master; 129 file "localhost.zone"; 130 allow-update { none; }; 131 }; 132 第7章 简单CDN 133 zone "0.0.127.in-addr.arpa" IN { 134 type master; 135 file "named.local"; 136 allow-update { none; }; 137 }; 138 139 zone "sery.cn" IN { 140 type slave; 141 file "edu.sery.cn.backup"; 142 masters { 61.135.154.50;} ; 143 }; 144 }; 145 146 view "other" { 147 match-clients {key anykey;any;}; 148 recursion yes; 149 allow-transfer { key anykey;}; 150 server 61.135.154.50 {keys anykey;}; 151 152 zone "." IN { 153 type hint; 154 file "named.ca"; 155 }; 156 157 zone "localhost" IN { 158 type master; 159 file "localhost.zone"; 160 allow-update { none; }; 161 }; 162 163 zone "0.0.127.in-addr.arpa" IN { 164 type master; 165 file "named.local"; 166 allow-update { none; }; 167 }; 第7章 简单CDN 168 169 zone "sery.cn" IN { 170 type slave; 171 file "sery.cn.backup"; 172 masters { 61.135.154.50;} ; 173 }; 174 }; 创建完毕named的配置文件后,仔细比较一下主DNS服务器与辅助DNS服务器的配置文件,相同的项有哪些,不同的项有哪些?因为辅助DNS服务器是从主DNS服务器复制数据进行同步,所以从DNS配置文件的TSIG KEY字串必须与主配置文件一致(secret后面的字符串);而控制列表文件则直接从主服务器复制过来。 (8)创建所需的区文件。用户定义的区文件,只需在主DNS服务器上进行,从DNS服务器会从主服务器同步数据,自动生成自己的区文件。在本案共需创建4个用户区文件,它们是:telecom.sery.cn.zone、unicom.sery.cn.zone、edu.sery.cn.zone及sery.cn.zone。当然,为了使DNS能正常工作,还需要其他的区文件,这里不再说明。为了便于理解,从4个区文件截取部分A记录,来进行比较,如表7-2所示。 表7-2 区文件解析对比 区文件名称 A 记 录 备 注 unicom.sery.cn.zone www IN A 211.99.76.120 dl IN A 211.99.76.120 images IN A 211.99.76.120 网通缓存服务器集群VIP telecom.sery.cn.zone www IN A 112.100.62.99 dl IN A 112.100.62.99 images IN A 112.100.62.99 电信缓存服务器集群VIP Edu.sery.cn.zone www IN A 58.192.68.102 dl IN A 58.192.68.102 images IN A 58.192.68.102 教育网缓存服务器VIP sery.cn.zone www IN A 159.226.128.222 dl IN A 159.226.128.222 images IN A 159.226.128.222 其他网络缓存服务器集群VIP 第7章 简单CDN 3.运行 (1)主DNS服务器的运行 n 检查配置文件的正确性:named-checkconf/usr/local/named/etc/named.conf。 n 检查区文件的配置:named-checkzone sery.cn unicom.sery.cn.zone、named- checkzonetelecom.sery.cn.zone、named-checkzone edu.sery.cn.zone、named- checkzone sery.cn.zone 如果书写无错误、配置完全正确,则在执行完每个命 令后,会有一个OK输出。 n 启动DNS服务:/usr/local/named/sbin/named。如果想简化输入,可以省略那一串路径,请自行把路径加入到环境变量中。 n 检查运行情况: l 检查进程 ps aux | grep named | grep –v grep。 l 检查网络监听端口 netstat -an|grep 53|grep -v UNIX。 l 用tail –f /var/log/messages 滚动输出方式查看named的运行情况。如果 named配置不正确或者有其他异常,则可以从这里得到有用的信息。。 (2)检查视图View效果 n 用tail–f /data/named/query.log滚动输出DNS查询记录。这个操作是在DNS服务器上进行的。 n 在其他计算机查询域名 nslookup www.sery.cn,同时观察查询日志输出。正常情况下,应该有类似如下的输出: [root@Postfix ~]# tail -f /data/named/query.log 07-Mar-2010 10:21:36.859 queries: client 202.103.44.165#60822: view other: query: www.sery.cn IN AAAA -E 07-Mar-2010 10:22:42.368 queries: client 221.210.200.106#9708: view view_unicom: query: www.sery.cn IN A -E 07-Mar-2010 10:23:01.928 queries: client 202.116.32.8#44242: view view_telecom: query: www.sery.cn IN AAAA -E 07-Mar-2010 10:23:28.626 queries: client 218.102.32.134#54142: view view_edu: query: www.sery.cn IN A -E 07-Mar-2010 10:23:33.613 queries: client 220.242.77.128#57608: view other: query: www.sery.cn IN A -E 07-Mar-2010 10:23:50.277 queries: client 222.200.160.1#59710: view 第7章 简单CDN view_telecom: query: www.sery.cn IN AAAA -E (3)辅助DNS服务器的运行 n 检查配置文件的正确性:named-checkconf/usr/local/named/etc/named.conf n 启动DNS服务:/usr/local/named/sbin/named。 n 检查辅助DNS的运行状态。 n 查看是否自动生成4个区文件(telecom.sery.cn.backup、unicom.sery.cn.backup。 n edu.sery.cn.backup、sery.cn.backup),并检查这些区文件的序列号是否与主DNS服务器区文件的序列号相一致。 n 在其他的计算机设置DNS为辅助DNS服务器的IP地址,然后解析域名www.sery.cn。 n 查看DNS查询日志,了解其解析情况。 7.4 简单CDN的整体效果测试 在前面的章节,我们逐一测试了源站的功能、缓存服务器的功能、集群后缓存服务器的功能以及DNS服务器的功能,现在是该对整个CDN环境做总体测试的时候了。为了获得较好的测试效果,需要发动网上不同地域的网友协同进行测试。当选取的测试点越多、越离散时,就越接近真实情况。 测试的手段选取以下几种。 n 在浏览器地址栏中输入正确的以域名标识的url,如http://www.sery.cn/ index. html,看是否正常显示页面内容。 n 在浏览器地址栏中输入缓存服务器VIP标识的url,如http://211.99.76.120/ index.html,看是否能显示页面(能显示页面,不是我们所期待的了)。 n 在浏览器地址栏中输入以域名标识的不存在的url,如http://www.sery.cn/aaa/ aaa.html,看页面的输出是什么。 在测试用户用浏览器访问的过程中,我们可以通过查看源站Web的访问日志、DNS服务器的查询记录、缓存服务器负载均衡器的输出(Ipvsadm)以及抽样查看某些缓存服务器的TCP连接状态,进一步了解整个环境的运作情况。 第7章 简单CDN 说明 似乎忘记给缓存服务器输出日志记录了?这确实是我在偷懒,不想把问题弄得很复杂。那怎么统计访问量?在页面文件嵌入第三方的代码,让别人帮我统计好了。 7.5 简单CDN的平台监控 简单CDN监控涉及源站、DNS服务器、缓存服务器、负载均衡器、服务探测等几部分。在做监控设计时,应当把CDN环境作为一个整体来考虑,这样一旦出现报警,会很快知道问题出在哪里。 7.5.1 主机资源监控 n 源站的资源监控:CPU负载、磁盘利用率、进程数等。 n DNS服务器的资源监控:CPU负载、磁盘利用率、进程数等。 n 缓存服务器的资源监控:CPU负载、磁盘利用率、进程数、TCP连接数等。 7.5.2 服务监控 n 所有服务器存活监控。 n 缓存服务器集群VIP存活监控。 n 源站TCP 80服务监控、缓存服务器TCP 80服务监控、缓存服务器集群VIP TCP 80端口监控以及DNS服务器check_DNS监控。 7.5.3 页面内容监控 有些时候,尽管网络服务还在,但却不能给用户提供正常的访问,这种情况俗称假死。为了探测此类问题的发生,需要监控系统模拟用户去访问CDN环境某个指定的页面,当取不到页面时,给系统管理员发送一个报警信息。Nagios监控平台,由check_http!url方式来完成这个监控。我们只要在监控平台设置增加主机,主机名以域名指定,如图7-6所示。 第7章 简单CDN 图7-6 Nagios监控配置片段 7.6 简单CDN系统上线 当一切都准备妥当的时候,我们就可以把正式的站点内容上传到源站服务器,替换掉原来测试用的目录和文件,接着通知相关人员和用户,CDN正式上线了。 7.7 简单CDN的运行维护 注意 需要在脚本接受多个命令行参数。有兴趣的读者,可自行编写一个脚本。 尽管在前面我们用大量的篇幅来描述怎样部署一个CDN环境,但这却不是我们的日常工作(实际工作场景没有谁整天在那里部署CDN环境)。部署和上线CDN,只是一个开始,运行和维护好这个环境,才是最关键的地方所在。 7.7.1 缓存刷新操作 缓存刷新操作是第一个常规性工作。每当在源站上更新已经存在的文件时,就必须进行缓存刷新的操作,否则有些用户看到的页面内容仍然是陈旧的。刷新缓存的操作,是在缓存服务器上进行的。但有很多缓存服务器,是一个个手工进行刷新的,既费时又容易出错和遗漏,因此最好把它自动化。下面介绍我用脚本自动更新全部缓存的方法(如果你有时间。可以写出单独对某个url更新的脚本): (1)登录某个Linux服务器,为安全起见,最好是一个无重要服务的主机。 (2)编写一个缓存服务器的所有IP地址和对应密码的列表,如图7-7所示。文件保存为/usr/local/bin/passwd.txt 第7章 简单CDN ,其权限设置为700(只有root用户有读写执行权限)。 图7-7 passwd.txt文件片段 (3)编写expect脚本,用以实现自动应答ssh远程连接。此脚本命名为ssh.exp,也把它放在/usr/local/bin目录里,其内容如下: #!/usr/bin/expect set password [lrange $argv 0 0] set ipaddr [lrange $argv 1 1] set scriptname [lrange $argv 2 2] set arg1 [lrange $argv 3 3] set timeout -1 spawn ssh root@$ipaddr $scriptname $arg1 match_max 100000 expect "(yes/no)?" { send "yes\r" expect "password:" send "$password\r" } "password:" {send "$password\r"} "*host " {exit 1} interact (4)编写脚本/usr/local/bin/purge_cache.sh,其内容为: #!/bin/bash cd /usr/local/bin for i in `awk ‘{print $1}’ passwd.txt` do j=‘awk -v I="$i" ’{if(I==$1)print $2}‘ passwd.txt’ ssh.exp $j $i purge.sh 第7章 简单CDN done (5)在每个缓存服务器上编写脚本/usr/local/bin/purge.sh,其内容为: #!/bin/sh /usr/local/varnish/bin/varnishadm -T 127.0.0.1:3500 url.purge *$ (6)在每个缓存服务器上都执行一下脚本/usr/local/bin/purge.sh,检查其运行情况。 (7)现在再回到控制服务器上,手动运行步骤(4)编写的脚本/usr/local/bin/purge_ cache.sh,等待程序执行并查看其输出。 7.7.2 备份数据 第二个常规性维护操作是备份数据。需要备份的数据有两部分:配置文件和数据文件。在CDN环境下,只有源站的网站的数据需要备份,其他的备份操作都是针对配置文件的,如DNS区文件。 7.7.3 故障处理与恢复 第三个常规性的操作是故障处理与恢复。因为整个CDN是基于高可用的架构,即便出现故障也不会导致服务全部停止,因此服务的恢复就不会有什么压力;另外也因为有监控系统的报警,很容易就知道问题出在什么地方。 7.7.4 增加CDN布点 再一个维护操作就是增加CDN布点,这是用户访问量增大时需要采取的必然措施。因为整个CDN环境是可扩展的架构,因此增加新的布点不会导致服务停止。 7.8 杂 项 7.8.1 部署CDN的重点和难点 整个CDN最重要的部分就是全局智能DNS服务,这是CDN不可替代的组件。在没有出现视图View功能之前(或者当某些系统管理员不知道有这样的功能),甚至有人以DNS轮询方式调度用户对缓存服务器的访问,这种形式都会让用户的体验时好时坏。 第7章 简单CDN 提示 在7.3.3节,我们用了一个脚本get_ip.sh来取得和归类IP地址,而未说明是怎么一回事情。那么,在本章的结尾我把它补充一下。 7.8.2 取得和归类中国大陆IP地址列表 我们知道,亚太地区的IP地址由APNIC(http://www.apnic.net)分配,通过访问APNIC官方站点的url:http://www.apnic.net/publications/research-and-insights/stats,可以知道在何处得到IP地址分配的有用信息,如图7-8所示。 图7-8 通过FTP方式可以取得原始数据 单击图7-8加下划线的链接,就进入FTP站点ftp://ftp.apnic.net/,再单击几次鼠标,最后定位在ftp://ftp.apnic.net/apnic/stats/apnic/README.TXT,这个文件帮助我们了解该下载哪个文件以及文件的格式。 让我们按照这个README.TXT的提示,在浏览器里打开页面文件ftp://ftp.apnic.net/ apnic/stats/apnic/delegated-apnic-latest,除去注释行,我们将看见形如“apnic|JP|asn|173|1| 20020801|allocated”的文本行。 把这个文件下载下来,过滤一下,便可以把分配给中国大陆(第2个字段为“CN”)的IP地址单独提取出来。在前面的get_ip脚本中,用wget下载delegated-apnic-latest文件,然后再用grep 把CN提取出来的IP地址形成一个单独的文件。具体的操作如下。 wgethttp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest-O/root/ipnic/ ip_apnic grep 'apnic|CN|ipv4|' /root/ipnic/ip_apnic | cut -f 4,5 -d'|'|sed -e 's/|/ /g' | while read ip cnt do echo $ip:$cnt     mask=$(cat << EOF | bc | tail -1 pow=32; define log2(x) { 第7章 简单CDN if (x<=1) return (pow); pow--; return(log2(x/2)); } log2($cnt) EOF) echo $ip/$mask>> cn.net done 在得到IP地址段以后,通过网站www.cnnic.net.cn查询这个地址段属于哪个运营商,或者在Linux下用whois工具查询。若用访问网站的方式进行查询,一次只能查询一个地址段,根本无法完成所有地址的查询;而使用whois则可用遍历的方式逐个查询,然后按关键字归类,形成几个单独的文件。 可能由于各IP地址租用方未能按统一的标准在APNIC提交注册信息,get_ip.sh脚本以正则表达式“netname”取得的值就未必能清楚反映运营商的名称,如netname:KLSF-LID-BJ就很难从字面上联想是哪个运营商的网络。如果你想判别更精准一些,则需要借助其他正则表达式如(mnt-by)作为辅助条件。 7.8.3 应急处理 CDN服务运营中,有可能出现某个运营中机房网络不可用的情况,如设备故障或机房维护操作。这样一来,就导致某个区域的用户彻底不能访问。出现这种极端情况时,需要把出现故障的机房资源临时从DNS的转发列表中删除,然后把前往这些机房的访问转发到其他地方。接下来,还是以我的实例来做说明。 现在假定我们放置服务器的电信IDC托管机房出现故障,造成电信的用户不能访问我的网站。当我发现故障以后,打开区文件telecom.sery.cn.zone,把它里面的A记录做修改,如果要把它的流量切换到网通机房,则把A记录对应的IP修改成跟unicom.sery.cn.zone的设置一样。 在进行流量切换操作时,很可能因为瞬间流量过大而使系统过载。因此在设计简单CDN容量的时候,每个点应该至少能承受整个系统用户的访问,否则当你从一个故障机房切换流量时,顺便把另一个点也撑死了,这种结果当然不是我们想要的。 第8章 分布式文件系统MooseFS

下载文档到电脑,查找使用更方便

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ] 27 人已下载

下载文档