上一篇我们从MySpace的发展历程中总结出了数据库和磁盘IO的瓶颈是大型高负载高并发网站系统架构需要解决的问题。
  这次我们通过另外一个案例,来看看别人又碰到了什么问题,如果解决的。

从LiveJournal后台发展看大规模网站性能优化方法

于敦德 2006-3-16

一、LiveJournal发展历程

LiveJournal是99年始于校园中的项目,几个人出于爱好做了这样一个应用,以实现以下功能:
  • 博客,论坛
  • 社会性网络,找到朋友
  • 聚合,把朋友的文章聚合在一起
LiveJournal采用了大量的开源软件,甚至它本身也是一个开源软件。

在上线后,LiveJournal实现了非常快速的增长:

  • 2004年4月份:280万注册用户。
  • 2005年4月份:680万注册用户。
  • 2005年8月份:790万注册用户。
  • 达到了每秒钟上千次的页面请求及处理。
  • 使用了大量MySQL服务器。
  • 使用了大量通用组件。

二、LiveJournal架构现状概况

livejournal_backend.png

三、从LiveJournal发展中学习

LiveJournal从1台服务器发展到100台服务器,这其中经历了无数的伤痛,但同时也摸索出了解决这些问题的方法,通过对LiveJournal的学习,可以让我们避免LJ曾经犯过的错误,并且从一开始就对系统进行良好的设计,以避免后期的痛苦。

下面我们一步一步看LJ发展的脚步。

1、一台服务器

一台别人捐助的服务器,LJ最初就跑在上面,就像Google开始时候用的破服务器一样,值得我们尊敬。这个阶段,LJ的人以惊人的速度熟悉的Unix的操作管理,服务器性能出现过问题,不过还好,可以通过一些小修小改应付过去。在这个阶段里LJ把CGI升级到了FastCGI。

最终问题出现了,网站越来越慢,已经无法通过优过化来解决的地步,需要更多的服务器,这时LJ开始提供付费服务,可能是想通过这些钱来购买新的服务器,以解决当时的困境。
毫无疑问,当时LJ存在巨大的单点问题,所有的东西都在那台服务器的铁皮盒子里装着。

LJ-backend-7.png

2、两台服务器

用付费服务赚来的钱LJ买了两台服务器:一台叫做Kenny的Dell 6U机器用于提供Web服务,一台叫做Cartman的Dell 6U服务器用于提供数据库服务。

LJ-backend-8.png

LJ有了更大的磁盘,更多的计算资源。但同时网络结构还是非常简单,每台机器两块网卡,Cartman通过内网为Kenny提供MySQL数据库服务。

暂时解决了负载的问题,新的问题又出现了:

  • 原来的一个单点变成了两个单点。
  • 没有冷备份或热备份。
  • 网站速度慢的问题又开始出现了,没办法,增长太快了。
  • Web服务器上CPU达到上限,需要更多的Web服务器。

3、四台服务器

又买了两台,Kyle和Stan,这次都是1U的,都用于提供Web服务。目前LJ一共有3台Web服务器和一台数据库服务器。这时需要在3台Web服务器上进行负载均横。

LJ-backend-9.png

LJ把Kenny用于外部的网关,使用mod_backhand进行负载均横。

然后问题又出现了:

  • 单点故障。数据库和用于做网关的Web服务器都是单点,一旦任何一台机器出现问题将导致所有服务不可用。虽然用于做网关的Web服务器可以通过保持心跳同步迅速切换,但还是无法解决数据库的单点,LJ当时也没做这个。
  • 网站又变慢了,这次是因为IO和数据库的问题,问题是怎么往应用里面添加数据库呢?

4、五台服务器

又买了一台数据库服务器。在两台数据库服务器上使用了数据库同步(Mysql支持的Master-Slave模式),写操作全部针对主数据库(通过Binlog,主服务器上的写操作可以迅速同步到从服务器上),读操作在两个数据库上同时进行(也算是负载均横的一种吧)。

LJ-backend-10.png

实现同步时要注意几个事项:

  • 读操作数据库选择算法处理,要选一个当前负载轻一点的数据库。
  • 在从数据库服务器上只能进行读操作
  • 准备好应对同步过程中的延迟,处理不好可能会导致数据库同步的中断。只需要对写操作进行判断即可,读操作不存在同步问题。

5、更多服务器

有钱了,当然要多买些服务器。部署后快了没多久,又开始慢了。这次有更多的Web服务器,更多的数据库服务器,存在 IO与CPU争用。于是采用了BIG-IP作为负载均衡解决方案。

LJ-backend-11.png

6、现在我们在哪里:

LJ-backend-1.png

现在服务器基本上够了,但性能还是有问题,原因出在架构上。

数据库的架构是最大的问题。由于增加的数据库都是以Slave模式添加到应用内,这样唯一的好处就是将读操作分布到了多台机器,但这样带来的后果就是写操作被大量分发,每台机器都要执行,服务器越多,浪费就越大,随着写操作的增加,用于服务读操作的资源越来越少。

LJ-backend-2.png

由一台分布到两台

LJ-backend-3.png

最终效果

现在我们发现,我们并不需要把这些数据在如此多的服务器上都保留一份。服务器上已经做了RAID,数据库也进行了备份,这么多的备份完全是对资源的浪费,属于冗余极端过度。那为什么不把数据分布存储呢?

问题发现了,开始考虑如何解决。现在要做的就是把不同用户的数据分布到不同的服务器上进行存储,以实现数据的分布式存储,让每台机器只为相对固定的用户服务,以实现平行的架构和良好的可扩展性。

为了实现用户分组,我们需要为每一个用户分配一个组标记,用于标记此用户的数据存放在哪一组数据库服务器中。每组数据库由一个master及几个slave组成,并且slave的数量在2-3台,以实现系统资源的最合理分配,既保证数据读操作分布,又避免数据过度冗余以及同步操作对系统资源的过度消耗。

LJ-backend-4.png

由一台(一组)中心服务器提供用户分组控制。所有用户的分组信息都存储在这台机器上,所有针对用户的操作需要先查询这台机器得到用户的组号,然后再到相应的数据库组中获取数据。

这样的用户架构与目前LJ的架构已经很相像了。

在具体的实现时需要注意几个问题:

  • 在数据库组内不要使用自增ID,以便于以后在数据库组之间迁移用户,以实现更合理的I/O,磁盘空间及负载分布。
  • 将userid,postid存储在全局服务器上,可以使用自增,数据库组中的相应值必须以全局服务器上的值为准。全局服务器上使用事务型数据库InnoDB。
  • 在数据库组之间迁移用户时要万分小心,当迁移时用户不能有写操作。

7、现在我们在哪里

LJ-backend-5.png

问题:

  • 一个全局主服务器,挂掉的话所有用户注册及写操作就挂掉。
  • 每个数据库组一个主服务器,挂掉的话这组用户的写操作就挂掉。
  • 数据库组从服务器挂掉的话会导致其它服务器负载过大。

对于Master-Slave模式的单点问题,LJ采取了Master-Master模式来解决。所谓Master-Master实际上是人工实现的,并不是由MySQL直接提供的,实际上也就是两台机器同时是Master,也同时是Slave,互相同步。

Master-Master实现时需要注意:

  • 一个Master出错后恢复同步,最好由服务器自动完成。
  • 数字分配,由于同时在两台机器上写,有些ID可能会冲突。

解决方案:

  • 奇偶数分配ID,一台机器上写奇数,一台机器上写偶数
  • 通过全局服务器进行分配(LJ采用的做法)。

Master-Master模式还有一种用法,这种方法与前一种相比,仍然保持两台机器的同步,但只有一台机器提供服务(读和写),在每天晚上的时候进行轮换,或者出现问题的时候进行切换。

8、现在我们在哪里

LJ-backend-6.png

现在插播一条广告,MyISAM VS InnoDB。

使用InnoDB:

  • 支持事务
  • 需要做更多的配置,不过值得,可以更安全的存储数据,以及得到更快的速度。

使用MyISAM:

  • 记录日志(LJ用它来记网络访问日志)
  • 存储只读静态数据,足够快。
  • 并发性很差,无法同时读写数据(添加数据可以)
  • MySQL非正常关闭或死机时会导致索引错误,需要使用myisamchk修复,而且当访问量大时出现非常频繁。

9、缓存

去年我写过一篇文章介绍memcached,它就是由LJ的团队开发的一款缓存工具,以key-value的方式将数据存储到分布的内存中。LJ缓存的数据:

  • 12台独立服务器(不是捐赠的)
  • 28个实例
  • 30GB总容量
  • 90-93%的命中率(用过squid的人可能知道,squid内存加磁盘的命中率大概在70-80%)

如何建立缓存策略?

想缓存所有的东西?那是不可能的,我们只需要缓存已经或者可能导致系统瓶颈的地方,最大程度的提交系统运行效率。通过对MySQL的日志的分析我们可以找到缓存的对象。

缓存的缺点?

  • 没有完美的事物,缓存也有缺点:
  • 增大开发量,需要针对缓存处理编写特殊的代码。
  • 管理难度增加,需要更多人参与系统维护。
  • 当然大内存也需要钱。

10、Web访问负载均衡

在数据包级别使用BIG-IP,但BIG-IP并不知道我们内部的处理机制,无法判断由哪台服务器对这些请求进行处理。反向代理并不能很好的起到作用,不是已经够快了,就是达不到我们想要的效果。

所以,LJ又开发了Perlbal。特点:

  • 快,小,可管理的http web 服务器/代理
  • 可以在内部进行转发
  • 使用Perl开发
  • 单线程,异步,基于事件,使用epoll , kqueue
  • 支持Console管理与http远程管理,支持动态配置加载
  • 多种模式:web服务器,反向代理,插件
  • 支持插件:GIF/PNG互换?

11、MogileFS

LJ使用开源的MogileFS作为分布式文件存储系统。MogileFS使用非常简单,它的主要设计思想是:

  • 文件属于类(类是最小的复制单位)
  • 跟踪文件存储位置
  • 在不同主机上存储
  • 使用MySQL集群统一存储分布信息
  • 大容易廉价磁盘

到目前为止就这么多了,更多文档可以在http://www.danga.com/words/找到。Danga.comLiveJournal.com的同学们拿这个文档参加了两次MySQL Con,两次OS Con,以及众多的其它会议,无私的把他们的经验分享出来,值得我们学习。在web2.0时代快速开发得到大家越来越多的重视,但良好的设计仍是每一个应用的基础,希望web2.0们在成长为Top500网站的路上,不要因为架构阻碍了网站的发展。

  从这个例子中,我们可以学习到一些设计理念。不仅仅服务器系统架构要搭建好了,相应的程序设计也必须按照系统架构做相应的设计,这个例子采用的是大量的开源软件和MySpace基于不同的系统架构,并采用了Mysql集群和分布式文件存储系统。将系统的性能大大提升,让我们有很大的借鉴意义。

现在ArthurXF本人正在搞PHP等技术培训,如果想学习的人可以跟我联系。另外培训的招生简章在这个网址,想了解的可以去看看。加我QQ:29011218交流也可。 PHP培训招生简章
  随着互联网的用户激增,每个网站的日访问量都在扩大,由于系统架构初期规划设计不当,将导致大量的架构改造工作,所以初期规划好架构可以为将来节省非常多的工作。
  本人提出来的网站架构优化部分,应该因地制宜,根据需要选择不同的优化功能,切忌生搬硬套。
  有意进行深入探讨的,可以和我联系,QQ:29011218,MSN:onenight11@hotmail.com
  在我们探讨网站架构之前,我们先来看两篇文章,希望大家能够从这些文章中总结出些经验。
引用
亿万用户网站MySpace的成功秘密
◎ 文 / David F. Carr   译 / 罗小平

高速增长的访问量给社区网络的技术体系带来了巨大挑战。MySpace的开发者多年来不断重构站点软件、数据库和存储系统,以期与自身的成长同步——目前,该站点月访问量已达400亿。绝大多数网站需要应对的流量都不及MySpace的一小部分,但那些指望迈入庞大在线市场的人,可以从MySpace的成长过程学到知识。

用户的烦恼
Drew,是个来自达拉斯的17岁小伙子,在他的MySpace个人资料页上,可以看到他的袒胸照,看样子是自己够着手拍的。他的好友栏全是漂亮姑娘和靓车的链接,另外还说自己参加了学校田径队,爱好吉他,开一辆蓝色福特野马。
不过在用户反映问题的论坛里,似乎他的火气很大。“赶紧弄好这该死的收件箱!”他大写了所有单词。使用MySpace的用户个人消息系统可以收发信息,但当他要查看一条消息时,页面却出现提示:“非常抱歉……消息错误”。

Drew的抱怨说明1.4亿用户非常重视在线交流系统,这对MySpace来说是个好消息。但也恰是这点让MySpace成了全世界最繁忙的站点之一。
11月,MySpace的美国国内互联网用户访问流量首次超过Yahoo。comScore Media Metrix公司提供的资料显示,MySpace当月访问量为387亿,而Yahoo是380.5亿。
显然,MySpace的成长太快了——从2003年11月正式上线到现在不过三年。这使它很早就要面对只有极少数公司才会遇到的高可扩展性问题的严峻挑战。
事实上,MySpace的Web服务器和数据库经常性超负荷,其用户频繁遭遇“意外错误”和“站点离线维护”等告示。包括Drew在内的MySpace用户经常无法收发消息、更新个人资料或处理其他日常事务,他们不得不在论坛抱怨不停。

尤其是最近,MySpace可能经常性超负荷。因为Keynote Systems公司性能监测服务机构负责人Shawn White说,“难以想象,在有些时候,我们发现20%的错误日志都来自MySpace,有时候甚至达到30%以至40%……而Yahoo、Salesforce.com和其他提供商用服务的站点,从来不会出现这样的数字。”他告诉我们,其他大型站点的日错误率一般就1%多点。

顺便提及,MySpace在2006年7月24号晚上开始了长达12小时的瘫痪,期间只有一个可访问页面——该页面解释说位于洛杉矶的主数据中心发生故障。为了让大家耐心等待服务恢复,该页面提供了用Flash开发的派克人(Pac-Man)游戏。Web站点跟踪服务研究公司总经理Bill Tancer说,尤其有趣的是,MySpace瘫痪期间,访问量不降反升,“这说明了人们对MySpace的痴迷——所有人都拥在它的门口等着放行”。
现Nielsen Norman Group 咨询公司负责人、原Sun Microsystems公司工程师,因在Web站点方面的评论而闻名的Jakob Nielsen说,MySpace的系统构建方法显然与Yahoo、eBay以及Google都不相同。和很多观察家一样,他相信MySpace对其成长速度始料未及。“虽然我不认为他们必须在计算机科学领域全面创新,但他们面对的的确是一个巨大的科学难题。”他说。

MySpace开发人员已经多次重构站点软件、数据库和存储系统,以满足爆炸性的成长需要,但此工作永不会停息。“就像粉刷金门大桥,工作完成之时,就是重新来过之日。”(译者注:意指工人从桥头开始粉刷,当到达桥尾时,桥头涂料已经剥落,必须重新开始)MySpace技术副总裁Jim Benedetto说。
既然如此,MySpace的技术还有何可学之处?因为MySpace事实上已经解决了很多系统扩展性问题,才能走到今天。

Benedetto说他的项目组有很多教训必须总结,他们仍在学习,路漫漫而修远。他们当前需要改进的工作包括实现更灵活的数据缓存系统,以及为避免再次出现类似7月瘫痪事件的地理上分布式架构。

背景知识
MySpace目前的努力方向是解决扩展性问题,但其领导人最初关注的是系统性能。
3年多前,一家叫做Intermix Media(早先叫eUniverse。这家公司从事各类电子邮件营销和网上商务)的公司推出了MySpace。而其创建人是Chris DeWolfe和Tom Anderson,他们原来也有一家叫做ResponseBase的电子邮件营销公司,后于2002年出售给Intermix。据Brad Greenspan(Intermix前CEO)运作的一个网站披露,ResponseBase团队为此获得2百万美金外加分红。Intermix是一家颇具侵略性的互联网商务公司——部分做法可能有点过头。2005年,纽约总检察长Eliot Spitzer——现在是纽约州长——起诉Intermix使用恶意广告软件推广业务,Intermix最后以790万美元的代价达成和解。

2003年,美国国会通过《反垃圾邮件法》(CAN-SPAM Act),意在控制滥发邮件的营销行为。Intermix领导人DeWolfe和Anderson意识到新法案将严重打击公司的电子邮件营销业务,“因此必须寻找新的方向。”受聘于Intermix负责重写公司邮件营销软件的Duc Chau说。
当时有个叫Friendster的交友网站,Anderson和DeWolfe很早就是它的会员。于是他们决定创建自己的网上社区。他们去除了Friendster在用户自我表述方面的诸多限制,并重点突出音乐(尤其是重金属乐),希望以此吸引用户。Chau使用Perl开发了最初的MySpace版本,运行于Apache Web服务器,后台使用MySQL数据库。但它没有通过终审,因为Intermix的多数开发人员对ColdFusion(一个Web应用程序环境,最初由Allaire开发,现为Adobe所有)更为熟悉。因此,最后发布的产品采用ColdFusion开发,运行在Windows上,并使用MS SQL Server作为数据库服务器。
Chau就在那时离开了公司,将开发工作交给其他人,包括Aber Whitcomb(Intermix的技术专家,现在是MySpace技术总监)和Benedetto(MySpace现技术副总裁,大概于MySpace上线一个月后加入)。

MySpace上线的2003年,恰恰是Friendster在满足日益增长的用户需求问题上遭遇麻烦的时期。在财富杂志最近的一次采访中,Friendster总裁Kent Lindstrom承认他们的服务出现问题选错了时候。那时,Friendster传输一个页面需要20到30秒,而MySpace只需2到3秒。

结果,Friendster用户开始转投MySpace,他们认为后者更为可靠。
今天,MySpace无疑已是社区网站之王。社区网站是指那些帮助用户彼此保持联系、通过介绍或搜索、基于共同爱好或教育经历交友的Web站点。在这个领域比较有名的还有最初面向大学生的Facebook、侧重职业交流的LinkedIn,当然还少不了Friendster。MySpace宣称自己是“下一代门户”,强调内容的丰富多彩(如音乐、趣事和视频等)。其运作方式颇似一个虚拟的夜总会——为未成年人在边上安排一个果汁吧,而显著位置则是以性为目的的约会,和寻找刺激派对气氛的年轻人的搜索服务。

用户注册时,需要提供个人基本信息,主要包括籍贯、性取向和婚姻状况。虽然MySpace屡遭批评,指其为网上性犯罪提供了温床,但对于未成年人,有些功能还是不予提供的。
MySpace的个人资料页上表述自己的方式很多,如文本式“关于本人”栏、选择加载入MySpace音乐播放器的歌曲,以及视频、交友要求等。它还允许用户使用CSS(一种Web标准格式语言,用户以此可设置页面元素的字体、颜色和页面背景图像)自由设计个人页面,这也提升了人气。不过结果是五花八门——很多用户的页面布局粗野、颜色迷乱,进去后找不到东南西北,不忍卒读;而有些人则使用了专业设计的模版(可阅读《Too Much of a Good Thing?》第49页),页面效果很好。
在网站上线8个月后,开始有大量用户邀请朋友注册MySpace,因此用户量大增。“这就是网络的力量,这种趋势一直没有停止。”Chau说。

拥有Fox电视网络和20th Century Fox影业公司的媒体帝国——新闻集团,看到了他们在互联网用户中的机会,于是在2005年斥资5.8亿美元收购了MySpace。新闻集团董事局主席Rupert Murdoch最近向一个投资团透露,他认为MySpace目前是世界主要Web门户之一,如果现在出售MySpace,那么可获60亿美元——这比2005年收购价格的10倍还多!新闻集团还惊人地宣称,MySpace在2006年7月结束的财政年度里总收入约2亿美元,而且预期在2007年度,Fox Interactive公司总收入将达到5亿美元,其中4亿来自MySpace。
然而MySpace还在继续成长。12月份,它的注册账户达到1.4亿,而2005年11月时不过4千万。当然,这个数字并不等于真实的用户个体数,因为有些人可能有多个帐号,而且个人资料也表明有些是乐队,或者是虚构的名字,如波拉特(译者注:喜剧电影《Borat》主角),还有像Burger King(译者注:美国最大的汉堡连锁集团)这样的品牌名。

当然,这么多的用户不停发布消息、撰写评论或者更新个人资料,甚至一些人整天都泡在Space上,必然给MySpace的技术工作带来前所未有的挑战。而传统新闻站点的绝大多数内容都是由编辑团队整理后主动提供给用户消费,它们的内容数据库通常可以优化为只读模式,因为用户评论等引起的增加和更新操作很少。而MySpace是由用户提供内容,数据库很大比例的操作都是插入和更新,而非读取。
浏览MySpace上的任何个人资料时,系统都必须先查询数据库,然后动态创建页面。当然,通过数据缓存,可以减轻数据库的压力,但这种方案必须解决原始数据被用户频繁更新带来的同步问题。

MySpace的站点架构已经历了5个版本——每次都是用户数达到一个里程碑后,必须做大量的调整和优化。Benedetto说,“但我们始终跟不上形势的发展速度。我们重构重构再重构,一步步挪到今天”。
尽管MySpace拒绝了正式采访,但Benedetto在参加11月于拉斯维加斯召开的SQL Server Connections会议时还是回答了Baseline的问题。本文的不少技术信息还来源于另一次重要会议——Benedetto和他的老板——技术总监Whitcomb今年3月出席的Microsoft MIX Web开发者大会。
据他们讲,MySpace很多大的架构变动都发生在2004和2005年早期——用户数在当时从几十万迅速攀升到了几百万。

在每个里程碑,站点负担都会超过底层系统部分组件的最大载荷,特别是数据库和存储系统。接着,功能出现问题,用户失声尖叫。最后,技术团队必须为此修订系统策略。
虽然自2005年早期,站点账户数超过7百万后,系统架构到目前为止保持了相对稳定,但MySpace仍然在为SQL Server支持的同时连接数等方面继续攻坚,Benedetto说,“我们已经尽可能把事情做到最好”。

里程碑一:50万账户
按Benedetto 的说法,MySpace最初的系统很小,只有两台Web服务器和一个数据库服务器。那时使用的是Dell双CPU、4G内存的系统。
单个数据库就意味着所有数据都存储在一个地方,再由两台Web服务器分担处理用户请求的工作量。但就像MySpace后来的几次底层系统修订时的情况一样,三服务器架构很快不堪重负。此后一个时期内,MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。
但到在2004年早期,MySpace用户数增长到50万后,数据库服务器也已开始汗流浃背。
但和Web服务器不同,增加数据库可没那么简单。如果一个站点由多个数据库支持,设计者必须考虑的是,如何在保证数据一致性的前提下,让多个数据库分担压力。
在第二代架构中,MySpace运行在3个SQL Server数据库服务器上——一个为主,所有的新数据都向它提交,然后由它复制到其他两个;另两个全力向用户供给数据,用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器,加大硬盘,就可以应对用户数和访问量的增加。

里程碑二:1-2百万账户
MySpace注册数到达1百万至2百万区间后,数据库服务器开始受制于I/O容量——即它们存取数据的速度。而当时才是2004年中,距离上次数据库系统调整不过数月。用户的提交请求被阻塞,就像千人乐迷要挤进只能容纳几百人的夜总会,站点开始遭遇“主要矛盾”,Benedetto说,这意味着MySpace永远都会轻度落后于用户需求。
“有人花5分钟都无法完成留言,因此用户总是抱怨说网站已经完蛋了。”他补充道。
这一次的数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能,如登录、用户资料和博客。于是,站点的扩展性问题看似又可以告一段落了,可以歇一阵子。
垂直分割策略利于多个数据库分担访问压力,当用户要求增加新功能时,MySpace将投入新的数据库予以支持它。账户到达2百万后,MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN(Storage Area Network,存储区域网络)——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性,Benedetto说。

里程碑三:3百万账户
当用户继续增加到3百万后,垂直分割策略也开始难以为继。尽管站点的各个应用被设计得高度独立,但有些信息必须共享。在这个架构里,每个数据库必须有各自的用户表副本——MySpace授权用户的电子花名册。这就意味着一个用户注册时,该条账户记录必须在9个不同数据库上分别创建。但在个别情况下,如果其中某台数据库服务器临时不可到达,对应事务就会失败,从而造成账户非完全创建,最终导致此用户的该项服务无效。
另外一个问题是,个别应用如博客增长太快,那么专门为它服务的数据库就有巨大压力。
2004年中,MySpace面临Web开发者称之为“向上扩展”对“向外扩展”(译者注:Scale Up和Scale Out,也称硬件扩展和软件扩展)的抉择——要么扩展到更大更强、也更昂贵的服务器上,要么部署大量相对便宜的服务器来分担数据库压力。一般来说,大型站点倾向于向外扩展,因为这将让它们得以保留通过增加服务器以提升系统能力的后路。
但成功地向外扩展架构必须解决复杂的分布式计算问题,大型站点如Google、Yahoo和Amazon.com,都必须自行研发大量相关技术。以Google为例,它构建了自己的分布式文件系统。
另外,向外扩展策略还需要大量重写原来软件,以保证系统能在分布式服务器上运行。“搞不好,开发人员的所有工作都将白费”,Benedetto说。
因此,MySpace首先将重点放在了向上扩展上,花费了大约1个半月时间研究升级到32CPU服务器以管理更大数据库的问题。Benedetto说,“那时候,这个方案看似可能解决一切问题。”如稳定性,更棒的是对现有软件几乎没有改动要求。
糟糕的是,高端服务器极其昂贵,是购置同样处理能力和内存速度的多台服务器总和的很多倍。而且,站点架构师预测,从长期来看,即便是巨型数据库,最后也会不堪重负,Benedetto说,“换句话讲,只要增长趋势存在,我们最后无论如何都要走上向外扩展的道路。”
因此,MySpace最终将目光移到分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。拿数据库来说,就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作一个应用。现在,数据库模型里只有一个用户表,支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
既然所有的核心数据逻辑上都组织到一个数据库,那么MySpace必须找到新的办法以分担负荷——显然,运行在普通硬件上的单个数据库服务器是无能为力的。这次,不再按站点功能和应用分割数据库,MySpace开始将它的用户按每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server实例。目前,MySpace的每台数据库服务器实际运行两个SQL Server实例,也就是说每台服务器服务大约2百万用户。Benedetto指出,以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。
当然,还是有一个特殊数据库保存了所有账户的名称和密码。用户登录后,保存了他们其他数据的数据库再接管服务。特殊数据库的用户表虽然庞大,但它只负责用户登录,功能单一,所以负荷还是比较容易控制的。

里程碑四:9百万到1千7百万账户
2005年早期,账户达到9百万后,MySpace开始用Microsoft的C#编写ASP.NET程序。C#是C语言的最新派生语言,吸收了C++和Java的优点,依托于Microsoft .NET框架(Microsoft为软件组件化和分布式计算而设计的模型架构)。ASP.NET则由编写Web站点脚本的ASP技术演化而来,是Microsoft目前主推的Web站点编程环境。
可以说是立竿见影,MySpace马上就发现ASP.NET程序运行更有效率,与ColdFusion相比,完成同样任务需消耗的处理器能力更小。据技术总监Whitcomb说,新代码需要150台服务器完成的工作,如果用ColdFusion则需要246台。Benedetto还指出,性能上升的另一个原因可能是在变换软件平台,并用新语言重写代码的过程中,程序员复审并优化了一些功能流程。

最终,MySpace开始大规模迁移到ASP.NET。即便剩余的少部分ColdFusion代码,也从Cold-Fusion服务器搬到了ASP.NET,因为他们得到了BlueDragon.NET(乔治亚州阿尔法利塔New Atlanta Communications公司的产品,它能将ColdFusion代码自动重新编译到Microsoft平台)的帮助。
账户达到1千万时,MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。
原因之一是每数据库1百万账户的分割策略,通常情况下的确可以将压力均分到各台服务器,但现实并非一成不变。比如第七台账户数据库上线后,仅仅7天就被塞满了,主要原因是佛罗里达一个乐队的歌迷疯狂注册。
某个数据库可能因为任何原因,在任何时候遭遇主要负荷,这时,SAN中绑定到该数据库的磁盘存储设备簇就可能过载。“SAN让磁盘I/O能力大幅提升了,但将它们绑定到特定数据库的做法是错误的。”Benedetto说。
最初,MySpace通过定期重新分配SAN中数据,以让其更为均衡的方法基本解决了这个问题,但这是一个人工过程,“大概需要两个人全职工作。”Benedetto说。
长期解决方案是迁移到虚拟存储体系上,这样,整个SAN被当作一个巨型存储池,不再要求每个磁盘为特定应用服务。MySpace目前采用了一种新型SAN设备——来自加利福尼亚州弗里蒙特的3PARdata。
在3PAR的系统里,仍能在逻辑上按容量划分数据存储,但它不再被绑定到特定磁盘或磁盘簇,而是散布于大量磁盘。这就使均分数据访问负荷成为可能。当数据库需要写入一组数据时,任何空闲磁盘都可以马上完成这项工作,而不再像以前那样阻塞在可能已经过载的磁盘阵列处。而且,因为多个磁盘都有数据副本,读取数据时,也不会使SAN的任何组件过载。
当2005年春天账户数达到1千7百万时,MySpace又启用了新的策略以减轻存储系统压力,即增加数据缓存层——位于Web服务器和数据库服务器之间,其唯一职能是在内存中建立被频繁请求数据对象的副本,如此一来,不访问数据库也可以向Web应用供给数据。换句话说,100个用户请求同一份资料,以前需要查询数据库100次,而现在只需1次,其余都可从缓存数据中获得。当然如果页面变化,缓存的数据必须从内存擦除,然后重新从数据库获取——但在此之前,数据库的压力已经大大减轻,整个站点的性能得到提升。
缓存区还为那些不需要记入数据库的数据提供了驿站,比如为跟踪用户会话而创建的临时文件——Benedetto坦言他需要在这方面补课,“我是数据库存储狂热分子,因此我总是想着将万事万物都存到数据库。”但将像会话跟踪这类的数据也存到数据库,站点将陷入泥沼。
增加缓存服务器是“一开始就应该做的事情,但我们成长太快,以致于没有时间坐下来好好研究这件事情。”Benedetto补充道。

里程碑五:2千6百万账户
2005年中期,服务账户数达到2千6百万时,MySpace切换到了还处于beta测试的SQL Server 2005。转换何太急?主流看法是2005版支持64位处理器。但Benedetto说,“这不是主要原因,尽管这也很重要;主要还是因为我们对内存的渴求。”支持64位的数据库可以管理更多内存。
更多内存就意味着更高的性能和更大的容量。原来运行32位版本的SQL Server服务器,能同时使用的内存最多只有4G。切换到64位,就好像加粗了输水管的直径。升级到SQL Server 2005和64位Windows Server 2003后,MySpace每台服务器配备了32G内存,后于2006年再次将配置标准提升到64G。

意外错误
如果没有对系统架构的历次修改与升级,MySpace根本不可能走到今天。但是,为什么系统还经常吃撑着了?很多用户抱怨的“意外错误”是怎么引起的呢?
原因之一是MySpace对Microsoft的Web技术的应用已经进入连Microsoft自己也才刚刚开始探索的领域。比如11月,超出SQL Server最大同时连接数,MySpace系统崩溃。Benedetto说,这类可能引发系统崩溃的情况大概三天才会出现一次,但仍然过于频繁了,以致惹人恼怒。一旦数据库罢工,“无论这种情况什么时候发生,未缓存的数据都不能从SQL Server获得,那么你就必然看到一个‘意外错误’提示。”他解释说。
去年夏天,MySpace的Windows 2003多次自动停止服务。后来发现是操作系统一个内置功能惹的祸——预防分布式拒绝服务攻击(黑客使用很多客户机向服务器发起大量连接请求,以致服务器瘫痪)。MySpace和其他很多顶级大站点一样,肯定会经常遭受攻击,但它应该从网络级而不是依靠Windows本身的功能来解决问题——否则,大量MySpace合法用户连接时也会引起服务器反击。
“我们花了大约一个月时间寻找Windows 2003服务器自动停止的原因。”Benedetto说。最后,通过Microsoft的帮助,他们才知道该怎么通知服务器:“别开枪,是友军。”
紧接着是在去年7月某个周日晚上,MySpace总部所在地洛杉矶停电,造成整个系统停运12小时。大型Web站点通常要在地理上分布配置多个数据中心以预防单点故障。本来,MySpace还有其他两个数据中心以应对突发事件,但Web服务器都依赖于部署在洛杉矶的SAN。没有洛杉矶的SAN,Web服务器除了恳求你耐心等待,不能提供任何服务。
Benedetto说,主数据中心的可靠性通过下列措施保证:可接入两张不同电网,另有后备电源和一台储备有30天燃料的发电机。但在这次事故中,不仅两张电网失效,而且在切换到备份电源的过程中,操作员烧掉了主动力线路。
2007年中,MySpace在另两个后备站点上也建设了SAN。这对分担负荷大有帮助——正常情况下,每个SAN都能负担三分之一的数据访问量。而在紧急情况下,任何一个站点都可以独立支撑整个服务,Benedetto说。
MySpace仍然在为提高稳定性奋斗,虽然很多用户表示了足够信任且能原谅偶现的错误页面。
“作为开发人员,我憎恶Bug,它太气人了。”Dan Tanner这个31岁的德克萨斯软件工程师说,他通过MySpace重新联系到了高中和大学同学。“不过,MySpace对我们的用处很大,因此我们可以原谅偶发的故障和错误。” Tanner说,如果站点某天出现故障甚至崩溃,恢复以后他还是会继续使用。
这就是为什么Drew在论坛里咆哮时,大部分用户都告诉他应该保持平静,如果等几分钟,问题就会解决的原因。Drew无法平静,他写道,“我已经两次给MySpace发邮件,而它说一小时前还是正常的,现在出了点问题……完全是一堆废话。”另一个用户回复说,“毕竟它是免费的。”Benedetto坦承100%的可靠性不是他的目标。“它不是银行,而是一个免费的服务。”他说。
换句话说,MySpace的偶发故障可能造成某人最后更新的个人资料丢失,但并不意味着网站弄丢了用户的钱财。“关键是要认识到,与保证站点性能相比,丢失少许数据的故障是可接受的。”Benedetto说。所以,MySpace甘冒丢失2分钟到2小时内任意点数据的危险,在SQL Server配置里延长了“checkpoint”操作——它将待更新数据永久记录到磁盘——的间隔时间,因为这样做可以加快数据库的运行。
Benedetto说,同样,开发人员还经常在几个小时内就完成构思、编码、测试和发布全过程。这有引入Bug的风险,但这样做可以更快实现新功能。而且,因为进行大规模真实测试不具可行性,他们的测试通常是在仅以部分活跃用户为对象,且用户对软件新功能和改进不知就里的情况下进行的。因为事实上不可能做真实的加载测试,他们做的测试通常都是针对站点。
“我们犯过大量错误,”Benedetto说,“但到头来,我认为我们做对的还是比做错的多。”


  看了这么长的故事,让我们来总结一下:
引用
里程碑一:50万账户
只有两台Web服务器和一个数据库服务器。遇到数据库瓶颈,后改成数据库集群,1台Master数据库服务器写,2台Slave数据库服务器读。

里程碑二:1-2百万账户
数据库服务器开始受制于I/O容量——即它们存取数据的速度。解决方案就是数据库架构按照垂直分割模式设计,不同的数据库服务于站点的不同功能。还从存储设备与数据库服务器直接交互的方式切换到SAN(Storage Area Network,存储区域网络)——用高带宽、专门设计的网络将大量磁盘存储设备连接在一起,而数据库连接到SAN。

里程碑三:3百万账户
面临数据独立和数据共享问题,过度独立提高了出错率,个别应用增长太快,造成个别数据库压力巨大。选择“向上扩展”或“向外扩展”(译者注:Scale Up和Scale Out,也称硬件扩展和软件扩展)?尝试了硬件扩展后,发现软件扩展是必须的,这次采用分布式计算架构——它在物理上分布的众多服务器,整体必须逻辑上等同于单台机器。按照用户每百万一组分割,然后将各组的全部数据分别存入独立的SQL Server。以后还可以按照这种模式以更小粒度划分架构,从而优化负荷分担。

里程碑四:9百万到1千7百万账户
用ASP.NET重写程序,运行更有效率,节省了大量的服务器,但又遭遇了存储瓶颈问题,但站点目前的要求已经开始周期性超越SAN的I/O容量——即它从磁盘存储系统读写数据的极限速度。SAN让磁盘I/O能力大幅提升了,但将它们绑定到特定数据库的做法是错误的。长期解决方案是迁移到虚拟存储体系上,仍能在逻辑上按容量划分数据存储,但它不再被绑定到特定磁盘或磁盘簇,而是散布于大量磁盘,读写动作都由多个磁盘完成,就避免了磁盘存储系统读写数据的瓶颈。后增加数据缓存层,减轻存储系统压力,在Web服务器和数据库服务器之间,将频繁请求数据对象在内存中建立副本。

里程碑五:2千6百万账户
数据库换成了SQL Server 2005。2005版支持64位处理器,支持64位的数据库可以管理更多内存,更多内存就意味着更高的性能和更大的容量。

从上面五个里程碑中可以看出,碰到的主要问题,并不在Web服务上,而是数据库和磁盘IO的瓶颈上,增加数据缓存层,合理的设计规划数据库,减轻存储系统压力,才是大型高负载高并发网站系统架构需要解决的问题。



现在ArthurXF本人正在搞PHP等技术培训,如果想学习的人可以跟我联系。另外培训的招生简章在这个网址,想了解的可以去看看。加我QQ:29011218交流也可。
PHP培训招生简章
  开源软件运动正在获得很大成功,正在改变软件业的开发模式、运营方法等,也自然改变着软件测试的方法,借助开源软件测试工具完全可以构造一个完整的测试解决方案,可以极大地提高测试效率,又能大大的降低测试成本。
     
  从单元测试、功能测试到性能测试,从Web页面测试到VoIP/Telephony等一些多媒体应用的测试,直至测试的管理平台和缺陷跟踪系统,能覆盖整个测试工作领域。

1. 测试模型:见 开源软件测试模型 ,阐述了开放源码软件测试模型框架以及环境、元素和技术等。    

2. 单元测试工具:JUint (大家太熟悉了)- see: http://www.junit.org/index.htm
 针对各种语言 (C/C++/C#, PHP, SQL ) Cactus, Cgreen, Check, CppTest, NUnit, NUnitForms , PHPUnit, SQLUnit, ...
 还有针对各种对象(HTTP, XML, Database, ) 进行的单元测试:HttpUnit, XMLUnit, DBUnit,  ObjcUnit, SIPUnit, ...
 Mockrunner用在J2EE环境中进行应用程序的单元测试,不仅支持Struts actions, servlets,过滤器和标签类还包括一个JDBC和一个JMS测试框架,可以用于测试基于EJB的应用程序。

3.  Web 功能测试 :  要数 Selenium,see: 强大的Web开源测试工具—Selenium
   再结合 Ant, EMMA 一起使用就更完美了, see:使用 EMMA 测量测试覆盖率
   功能测试工具很多,可以发现多达几十个:http://www.opensourcetesting.org/functional.php

4. Java 客户端,可以使用 Abbot, see:   http://abbot.sourceforge.net/doc/overview.shtml
   Abbot是一个用来测试Java GUIs的框架, 用简单的基于XML的脚本或者Java代码,就可以开始一个GUI.

5. 性能测试, 著名的有 Jmeter 和 OpenSTA,使用都很方便
     Jmeter可以完成针对静态资源和动态资源( Servlets, Perl脚本, Java对象, 数据查询s, FTP服务等)的性能测试。
     性能测试工具很多,可以访问 http://www.opensourcetesting.org/performance.php  

6. 数据库测试: DBMonster, DBProbe, OraRep, phpMyAdmin
   OSDL Database Test Suite, 是根据Linux开发人员需要而开发的测试框架中数据库测试工具套件,具有很好的实用价值。
   see: http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite/
   More: http://dbcommander.sourceforge.net/            

7. 多媒体(VoIP/Vedio)、IP电话 等测试
   Ethereal, AuthTool, ... SIPp, Sofia SIP, ...  Seagull, ... Asterisk - the Open Source PBX,X-Lite
   其中经常使用的有:Ethereal, SIPp 和 Seagull。而Asterisk 不仅可以作为测试工具,还可以构造企业内部电话网络。
   更多的还有:http://voipsa.org/Resources/tools.php

8.  缺陷跟踪
    Bugzilla一款不错的软件缺陷管理工具
    Mantis是一款基于WEB的软件缺陷管理工具,配置和使用都很简单,适合中小型软件开发团队

9. 测试平台
   TestMaker (solve functionality, scalability and performance of services)-  http://www.pushtotest.com/
   Eclipse Test & Performance Tools Platform (TPTP 4.3)

10. Reference
       http://www.eclipse.org/tptp/
       http://sourceforge.net/search/?type_of_search=soft&words=Test+Tool
       http://www.opensourcetesting.org
       http://testingfaqs.org/
       http://www.pushtotest.com/
       http://www.openqa.org/


现在ArthurXF本人正在搞PHP等技术培训,如果想学习的人可以跟我联系。另外培训的招生简章在这个网址,想了解的可以去看看。也可以联系我QQ:29011218。
PHP培训招生简章
/*
* 架构根据电信、网通用户自动解析不同IP的DNS服务器
* 本文介绍了如何让DNS服务器根据用户的IP地址解析出不同的镜像服务器IP

* 版本: 1.1.0
* 作者: 声仔(奶罩)
* 网站: http://wuhongsheng.com
* 版权: (C) 1999-2006 wuhongsheng.com
* 修订: 2006-01-19 23:13
* 原始出处: http://wuhongsheng.com/blog/?p=235
*/

本文档基于FreeBSD、BIND平台,Win用户请回避,没有FreeBSD基础的用户请回避。Linux或者其他Unix用户可以作为参考文档。

修订记录:
2006-01-19 修订了部分网通用户的IP地址,修正了NS部分,修正了一些错误,增加了常见问题。

配置步骤:
1. 前言
2. 软件列表
3. 安装BIND 9
4. 配置BIND 9
5. 测试BIND 9
6. 添加一个NS地址
7. 添加一个域名
8. 测试域名
9. 常见问题

一、 前言
本文假设你有一定的FreeBSD操作经验,懂得日常的FreeBSD操作,有良好的耐心,可以
把文档看完,可以处理突发的问题。
本文再假设你已经有了一个域名,并且已经指向所操作的服务器,服务器的/etc/rc.conf
已经正确的设置此域名。在本文里面,此域名为ns.naizhao.com,IP为219.132.1.1。
/etc/rc.conf如下所设置
hostname=”ns.naizhao.com” #机器的域名,请酌情修改
ifconfig_fxp0=”inet 219.132.1.1 netmask 255.255.255.0″ #此行可能有所不同,
请别照抄。fxp0为我机器上面的网卡。

二、 软件列表
本文所用到的软件可从以下地址获取。连接地址最后更新为2005/12/12

BIND 9.3.1
ftp://ftp.isc.org/isc/bind9/9.3.1/bind-9.3.1.tar.gz

三、 安装BIND 9
我们假设你已经把BIND 9使用fetch或者wget到/root/下,并且已经su为root。
# tar zxvf bind-9.3.1.tar.gz
# cd bind-9.3.1
# ./configure
# make
# make install
# make clean
到此,BIND 9已经安装上了。如果安装过程中出现什么问题,一般不会是你的人品有问题,
请分析错误信息,把缺少的包给安装上。

四、 配置BIND 9
先别急,看看你的BIND版本再说。
# named -v
如果你是FreeBSD 4,估计你看到的提示类似下面的
named 8.3.7-REL Sun Dec 12 04:15:36 CST 2004
如果你是FreeBSD 5,估计你不会看到上面的信息。然后我们再来输入
# /usr/local/sbin/named -v
这次,不管你是FreeBSD 4还是FreeBSD 5,都会看到下面的信息
BIND 9.3.1
所以在这里,我们统一使用/usr/local/sbin/named
废话少说,开始配置吧。
# cd /etc/namedb
# chmod +x make-localhost
# ./make-localhost
会在当前目录生成一个localhost.rev和localhost-v6.rev。后者是用于IPv6
生成rndc的key
# /usr/local/sbin/rndc-confgen >rndc.conf
打开rndc.conf,把
# Use with the following in named.conf, adjusting the allow list as needed:
……
# End of named.conf
之间的内容,去掉注释#,添加到named.conf中
编辑named.conf
# ee named.conf
找到
zone “.” {
type hint;
file “named.root”;
};

zone “0.0.127.IN-ADDR.ARPA” {
type master;
file “localhost.rev”;
};

// RFC 3152
zone “1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA” {
type master;
file “localhost-v6.rev”;
};

// RFC 1886 — deprecated
zone “1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT” {
type master;
file “localhost-v6.rev”;
};
把上面的内容全部用/**/注释
/*
zone “.” {
type hint;
……
file “localhost-v6.rev”;
};
*/
在named.conf文件的最后,把刚才rndc.conf里面的内容添加进去
key “rndc-key” {
algorithm hmac-md5;
secret “ILzfx8ONk2444ix9jnDfKA==”;
};

controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { “rndc-key”; };
};
(上面的内容只供参考)
接下来的,就是文章里面的重头戏了。
在上面添加的内容后面添加:
//include cnc acl
include “acl.conf”;

//view add by naizhao
view “view_cnc” {
match-clients { CNC; };
zone “.” {
type hint;
file “named.root”;
};

zone “0.0.127.IN-ADDR.ARPA” {
type master;
file “localhost.rev”;
};

include “master/cnc.def”;
};

view “view_any” {
match-clients { any; };
zone “.” {
type hint;
file “named.root”;
};

zone “0.0.127.IN-ADDR.ARPA” {
type master;
file “localhost.rev”;
};

include “master/telecom.def”;
};

添加完成后,保存。
# ee acl.conf
输入以下内容:
//cnc acl list by naizhao
acl “CNC” {
58.16.0.0/16;
58.17.0.0/17;
58.17.128.0/17;
58.18.0.0/16;
58.19.0.0/16;
58.20.0.0/16;
58.21.0.0/16;
58.22.0.0/15;
58.240.0.0/15;
58.242.0.0/15;
58.244.0.0/15;
58.246.0.0/15;
58.248.0.0/13;
60.0.0.0/13;
60.8.0.0/15;
60.10.0.0/16;
60.11.0.0/16;
60.12.0.0/16;
60.13.0.0/18;
60.13.128.0/17;
60.14.0.0/15;
60.16.0.0/13;
60.24.0.0/14;
60.30.0.0/16;
60.31.0.0/16;
60.208.0.0/13;
60.216.0.0/15;
60.218.0.0/15;
60.220.0.0/14;
61.48.0.0/13;
61.133.0.0/17;
61.134.96.0/19;
61.134.128.0/17;
61.135.0.0/16;
61.137.128.0/17;
61.138.0.0/17;
61.138.128.0/18;
61.139.128.0/18;
61.148.0.0/15;
61.156.0.0/16;
61.158.0.0/16;
61.159.0.0/18;
61.161.0.0/18;
61.161.128.0/17;
61.162.0.0/16;
61.163.0.0/16;
61.167.0.0/16;
61.168.0.0/16;
61.176.0.0/16;
61.179.0.0/16;
61.180.128.0/17;
61.181.0.0/16;
61.182.0.0/16;
61.189.0.0/17;
125.32.0.0/16;
125.40.0.0/13;
202.96.0.0/18;
202.96.64.0/21;
202.96.72.0/21;
202.97.128.0/18;
202.97.224.0/21;
202.97.240.0/20;
202.98.0.0/21;
202.98.8.0/21;
202.99.64.0/19;
202.99.96.0/21;
202.99.128.0/19;
202.99.160.0/21;
202.99.168.0/21;
202.99.176.0/20;
202.99.208.0/20;
202.99.224.0/21;
202.99.232.0/21;
202.99.240.0/20;
202.102.128.0/21;
202.102.224.0/21;
202.102.232.0/21;
202.106.0.0/16;
202.107.0.0/17;
202.108.0.0/16;
202.110.0.0/17;
202.111.128.0/18;
203.93.8.0/24;
203.93.192.0/18;
210.13.128.0/17;
210.14.160.0/19;
210.14.192.0/19;
210.15.32.0/19;
210.15.96.0/19;
210.15.128.0/18;
210.16.128.0/18;
210.21.0.0/16;
210.51.0.0/16;
210.52.128.0/17;
210.53.0.0/17;
210.53.128.0/17;
210.74.96.0/19;
210.74.128.0/19;
210.82.0.0/15;
211.152.0.0/13;
218.7.0.0/16;
218.8.0.0/14;
218.12.0.0/16;
218.21.128.0/17;
218.24.0.0/14;
218.28.0.0/15;
218.56.0.0/14;
218.60.0.0/15;
218.62.0.0/17;
218.67.128.0/17;
218.68.0.0/15;
218.104.0.0/14;
219.154.0.0/15;
219.156.0.0/15;
219.158.0.0/17;
219.158.128.0/17;
219.159.0.0/18;
220.252.0.0/16;
221.0.0.0/15;
221.2.0.0/16;
221.3.0.0/17;
221.3.128.0/17;
221.4.0.0/16;
221.5.0.0/17;
221.5.128.0/17;
221.6.0.0/16;
221.7.0.0/19;
221.7.32.0/19;
221.7.64.0/19;
221.7.96.0/19;
221.7.128.0/17;
221.8.0.0/15;
221.10.0.0/16;
221.11.0.0/17;
221.11.128.0/18;
221.11.192.0/19;
221.12.0.0/17;
221.12.128.0/18;
221.13.0.0/18;
221.13.64.0/19;
221.13.96.0/19;
221.13.128.0/17;
221.14.0.0/15;
221.192.0.0/15;
221.194.0.0/16;
221.195.0.0/16;
221.196.0.0/15;
221.198.0.0/16;
221.199.0.0/19;
221.199.32.0/20;
221.199.128.0/18;
221.199.192.0/20;
221.200.0.0/14;
221.204.0.0/15;
221.206.0.0/16;
221.207.0.0/18;
221.207.64.0/18;
221.207.128.0/17;
221.208.0.0/14;
221.212.0.0/16;
221.213.0.0/16;
221.216.0.0/13;
222.128.0.0/14;
222.132.0.0/14;
222.136.0.0/13;
222.160.0.0/15;
222.162.0.0/16;
222.163.0.0/19;
222.163.32.0/19;
222.163.64.0/18;
222.163.128.0/17;
219.235.56.194;
};
//cnc acl list by naizhao

# mkdir master
# touch master/cnc.def
# touch master/telecom.def
完成,接着就是测试

五、 测试BIND 9
# /usr/local/sbin/named -gc /etc/namedb/named.conf
正常的情况下你会看到下面的信息
12-Dec-2005 13:55:46.772 starting BIND 9.3.1 -gc /etc/namedb/named.conf
12-Dec-2005 13:55:46.816 loading configuration from ‘/etc/namedb/named.conf’
12-Dec-2005 13:55:46.824 no IPv6 interfaces found
12-Dec-2005 13:55:46.825 listening on IPv4 interface fxp0, 219.132.1.1#53
12-Dec-2005 13:55:46.825 listening on IPv4 interface lo0, 127.0.0.1#53
……
12-Dec-2005 13:55:46.866 running
只要有最后一行,那么你的配置就算是基本成功了。
按一下键盘的ctrl+c,先把BIND 9停掉。

六、 添加一个NS
平时大家修改域名信息的时候,都会发现有一个DNS信息的修改,里面会有一些类似
ns7.hichina.com一样的东西。添加这个东西不难,在新网的后台就可以添加。添加
的时候要注意,域名状态设置里面的域名必须不能在锁定状态。
登陆新网的后台->域名管理->注册本域名下的DNS->DNS名字:ns->IP地址219.132.1.1
(按照自己要求修改IP地址)->确定->MyDNS功能->添加新的A记录->ns->IP地址
219.132.1.1->提交。
对于一些收费的(如万网)或者不提供DNS服务器注册的管理后台,我们一样有办法去
解决。首先按照上面的,先添加一个A记录,然后打开
http://domain.cnic.ac.cn/domain/nameserver/createhost.jsp
按照上面的提示注册一下就行。
OK,等待DNS生效吧
这里要说明以下,如果按照上面的方法添加ns记录,在查询一个域名的时候,用户需要经过三步:
根域名服务器->新网/万网域名服务器->用户自己的域名服务器
所以我建议大家,尽量在国外注册域名,安全和稳定性比国内有保障,而且自由度高,像这样
的服务都不需要收费的,并且查询只需要经过两步:
根域名服务器->用户自己的域名服务器
另外,对于.CN的域名,用户是需要经过四步的:
根域名服务器->DNS.cn->新网/万网域名服务器->用户自己的域名服务器
在国外注册域名来解析,也是有窍门的,用户可以自己对自己的域名来解析。比如:
wuhongsheng.com这个域名,我可以使用ns1.wuhongsheng.com/ns2.wuhongsheng.com
来对自己进行解析,在国内我发现还无法做到这点。
国外注册自己的NS记录,一般为Nameserver Registration,按照提示输入IP就行

七、 添加一个域名
# cd /etc/namedb/master
# mkdir cnc
# mkdir telecom
# ee cnc.def
添加
zone “wuhongsheng.com” {
type master;
file “master/cnc/wuhongsheng.com”;
};

# ee telecom.def
添加
zone “wuhongsheng.com” {
type master;
file “master/telecom/wuhongsheng.com”;
};
添加网通的解析,解析到的IP为202.111.1.1
#ee cnc/wuhongsheng.com
添加
$TTL 3600
$ORIGIN wuhongsheng.com.
@ IN SOA ns.naizhao.com. root.ns.naizhao.com.(
2005121013 ;Serial
3600 ; Refresh ( seconds )
900 ; Retry ( seconds )
68400 ; Expire ( seconds )
15 );Minimum TTL for Zone ( seconds )
;
@ IN NS ns.naizhao.com.
@ IN A 202.111.1.1
www IN A 202.111.1.1
;
;end
添加电信的解析,解析到的IP为219.132.1.2
#ee telecom/wuhongsheng.com
添加
$TTL 3600
$ORIGIN wuhongsheng.com.
@ IN SOA ns.naizhao.com. root.ns.naizhao.com.(
2005121013 ;Serial
3600 ; Refresh ( seconds )
900 ; Retry ( seconds )
68400 ; Expire ( seconds )
15 );Minimum TTL for Zone ( seconds )
;
@ IN NS ns.naizhao.com.
@ IN A 219.132.1.2
www IN A 219.132.1.2
;
;end
添加一个脚本,用于在系统启动的时候自动把DNS服务器启起来
# ee /usr/local/etc/rc.d/named.sh
添加内容
/usr/local/sbin/named -gc /etc/namedb/named.conf &
# chmod 777 /usr/local/etc/rc.d/named.sh
把服务器启起来
# /usr/local/etc/rc.d/named.sh
OK,到此你的DNS服务器就算是跑起来了。试一下分别用网通和电信的线路ping一下吧,嘿嘿。

八、 测试域名
除了用简单的ping来测试域名外,你还可以使用nslookup来测试域名
# nslookup
>server ns.naizhao.com
>set q=a
>wuhongsheng.com
当然,unix系统下面还可以使用dig来进行高级查询
dig @ns.naizhao.com a wuhongsheng.com
原创文章,转载请注明来自http://wuhongsheng.com

九、常见问题
Q:为什么我测试的时候,得到的IP不是网通的?
A:首先确认你的配置是否对了。另外一个最重要的问题,你本地的DNS请求不是直接向你的DNS服务器发送,而是你本机先向系统设置的DNS服务器发送请求,然后由DNS服务器再向你自己的DNS服务器发送请求。所以,如果你本机设置了电信的DNS服务器地址,自然就解析不出网通的记录了。


现在ArthurXF本人正在搞PHP等技术培训,如果想学习的人可以跟我联系。另外培训的招生简章在这个网址,想了解的可以去看看。加我QQ:29011218交流也可。
PHP培训招生简章
Tags: , ,
分页: 5/5 第一页 上页 1 2 3 4 5 最后页 [ 显示模式: 摘要 | 列表 ]