November 2009 Archives

魔兽世界(World of Warcraft)的背后

| 26 Comments

《魔兽世界》(World of Warcraft )对于暴雪公司(Blizzard)来说是最为重要的一款产品。开发团队对于外界来说无疑有着神奇的色彩。这篇 An Inside Look At The Universe Of Warcraft 给我们带来不少关于《魔兽世界》开发团队的信息。暴雪开发团队也是采取三层的管理方式(还好不是更多层),但是实际的汇报是根据具体的小团队而异的。他们心目中理想的的团队规模是 5-8 人,当然实际上这是办不到的事情。

目前这棵摇钱树程序代码量有 550 万行之多,程序开发人员有 32 位,当然都是顶级工程师。平台服务部有 245 人,其中 QA 部门自从游戏上线后处理了 18 万个 BUG,惊人!程序差不多似乎千锤百炼了。

《魔兽世界》目前使用大约 13250 台刀片服务器 ,75000 个核的CPU ,内存使用超过 112TB 。服务器数其实并不是特别庞大(国内有些游戏公司,比如盛大,服务器数量也差不多这样)。 不过相信随着接下来几款重量级游戏升级版本的推出,服务器数量会暴增。数据大约有 1.3 PB。服务器分布在 10 个 IDC ,不到 70 个人运营,人力产出很惊人。维护战网的人有 150 个左右。这里面有个有趣的观点是,游戏公司对于服务的可用性要求的看法与电子商务公司的并非一致,只要不是每周都有问题,一个月遇到一次问题似乎不大。算不上致命的问题,应该是用户忠诚度更高的缘故吧。看看国内的戏剧性起伏就知道了。

另外,据我了解,魔兽计费的数据库是采用的 Oracle RDBMS 。2006 年的时候大概是跑在 RedHat 上,单个 DB 超过 1T 的数据,且据说要迁移到 HP 平台。但还不了解如何跨多个 IDC 同步 DB 数据,或许简单的分片就成了,这是面向游戏的应用设计上唯一不费力的地方。

Note: 先大致描述个轮廓,等以后了解更多再逐渐补充。

--EOF--

针对小型站点的技术普及信息,中大型网站的牛人不用看,耽误您的时间我负不起这责任。
用 Windows 做网站的也别看了,不适合。

说起单点故障(Single Point of Failure,SPOF),倒是可以想起电影 《2012》中,一把焊枪把齿轮卡住,从而导致整个舱门无法关闭,进而整个引擎无法发动。这是个有点生动的例子--如此庞大的一个系统,居然因为一把小小的焊枪而险些毁于一旦。投入巨大人力物力生产的救命方舟居然做不到高可用(High availability),这是致命的事情。

大脑对与人来说,就是一个单点,大脑损坏,人也完蛋;手是不是单点? 一只没了,另一只还能日常生活,从这个角度来说,不是单点。消除单点的最常见的做法:增加冗余。比如,人有两只手。其次,层次化。当然,分层的目的是便于隔离问题。电影 《2012》 中的这个问题,不知道谁是总架构师,看起来,隔离做得不太够 :)

一般来说,只要系统能够比较清楚的分出层次来,要消除单点故障还是有章可循的事情。比如,一个网站,从基础的硬件层,到操作系统层,到数据库层,到应用程序层,再到网络层,都有可能产生单点故障。如果要有效的消除单点故障,最重要的一点是设计的时候要尽量避免引入单点,而随着架构的变化,定期审查系统潜在单点也是有必要的。

有人或许会问,假设一个起步中的站点,只有一台服务器,什么东西都在一个盒子里,到底要怎么做呢? 这里的建议是先抛开主板、CPU 、内存这些,首先必须考虑硬盘(存储层)的问题,如果机器只有一块硬盘,即使你备份计划再完善(不要说你的备份也是备份在这块硬盘上的),还是建议你起码再弄一块。做镜像,让出错的概率降低,这是划算的投入,当然消除单点,成本几乎不可避免的要增加。如果硬盘多,或者有其他备份机制,可选的方法就更多,别刻舟求剑。

第二个要考虑网卡与网线的单点问题。先说网线,如果要问一个系统里面最容易物理损坏的是哪个组件,答案恐怕非网线莫属,对于网线这样多数时候因为距离需要定制的东西,总是购买成品还是有成本的,从我观察到的情况来看,各个 IDC 的网线使用手工制作的比例不小,这个质量几乎很难控制,一根线,两个水晶头,哪一个出问题都不能正常传输。怎么办? 想办法提升网线整体质量还是弄两根网线放在那里? 解决办法早都有了,网卡绑定 (NIC bonding)一个很简单很通用的办法(refer),但是问题是并非很多人在用。多数 PC 服务器应该都是配置了多块网卡,如果是自己攒服务器,记得网卡多一块成本没多大,但是用处会有很多。如果耐着性子看到这里,先别急着去 Google,还有问题呢,两根网线如何接到上行交换机,什么样的交换机支持绑定,如何确定绑定是真正生效的? 答案是,尝试一下。

然后是什么? 是跑多个数据库,还是跑两个 Web 服务器,一个不行用另一个顶? 对于单台服务器,其它能消除单点的地方恐怕收效也不会特别大,现在少做无用功,或许要重点考虑如何备份,如何优化,以及出现问题的时候如何做到快速恢复。有一个或许会引起争议的建议是,除了 SSH 登录之外,要不要留一个 Telnet 登录的服务呢? 毕竟 SSH 服务器端守护进程不是百分百靠谱的事儿,如果 IDC 距离较远,需要斟酌一下。好吧,网站有了一点发展,用户量也增加了,感觉需要增加服务器了。再增加一台服务器,抗风险能力一下子加强了许多,毕竟一台机器质量再好,也有出错的时候。现在,Web 服务器、DB 服务器可以考虑引入 HA 的方案,如果单台服务能力够,主备模式也不错。随着网站的发展,服务器数量继续增加...

随着服务器数量的增加,到了必须要自己购买网络设备的时候了。同样的设备,一买恐怕就要买双份,原因无它--一台总要出错,哪怕是电源被拔错--而这样的情况实际上并不少见。如果预算不够,那就再等等,但是要记住,定期审查,有可能的话,进行弥补总不会错。

到现在,所有的服务器都还在一个 IDC 呢,IDC 本身也是个单点啊,服务器被黑怎么办? 机房光线被施工工人挖断怎么办? 机房停电怎么办? 找第二个机房吧。现在选 IDC 首先要考虑什么? 中国特色的互联网问题总要考虑吧,"南北互通"怎么样...或许在选择第一个机房的时候已经遇到了类似的问题,或许现在正在受到这个问题的困扰。选好 IDC 之后,首先计划一下数据如何备份过来,然后,网站的配置信息如何同步或备份过来(这是保证第一个 IDC 出了致命问题之后的最基本的恢复要求)。多个 IDC 之后不得不提上议程的要算 DNS 这个事儿了。你的 DNS 解析商靠谱么? 如果域名提供商遭受攻击,对自己的网站影响能承受么?

更多的服务器,提供更多的应用,更多的用户,更多的收入... 接下来该怎么办呢? 现在,您所面对的已经不是一个小型 Web 站点了,可以不用看这篇文章了。

到现在,我还没说人的问题,如果这些信息只有一个人知道,万一这个人出了点事情怎么办? 作为老板,还要考虑人的单点问题。

--EOF--

Updated: DNS 的健康程度检查重要性应该提升一些。如何检查?有很多在线的工具可供使用,简单直接。

Yes! Linode VPS

| 26 Comments

感谢豆瓣独家提供的两年托管赞助费用!这几天利用空闲时间把 Blog 站点迁移到了 Linode.com 提供的 VPS 上。或许,可以在一段时间内缓解重建页面的性能问题,用户留言的速度也会好很多。

原来站点放在 Dreamhost 上,但是年初的时候频繁遇到 HTTP 500 错误,那段时间,我发布一篇文章都要反复 Build 多次才能成功,很影响积极性。可气的是,Dreamhost 还不断给我发他们的 PS (Private Server) 的折扣信息,一不小心上了贼船,发现上去后反而下不来--不让且回到原来的共享模式下,结果几个月下来花了不少银子。性能,其实也没好到什么地方去。

建议如果 Dreamhost 共享服务器够用,就别升级,也别切换了。毕竟,Dreamhost 的共享主机性价比还是不错的,迁移起来,其实也颇为费事。

我买的是 Linode 360 这个服务整年购买还能优惠 10%,也有优惠代码,不过现在都过期了。购买之后第一个决定是要选择 IDC ,都说旧金山的 Fremont 速度较快,相信大家的,没错。主机用了 Ubuntu ,然后登录进去用 APT (Advanced Packaging Tool) 安装软件或者更新系统,速度那叫一个快啊。早知道这样,再贵一点可能也要买 Linode。在 Dreamhost 上折腾来折腾去的浪费多少精力... 在 Linode 上,如果后续需要更大的内存,随时可以扩容,操作极其方便。 对于CPU 能力、硬盘空间和带宽开销,似乎也很难用到那么多,如果喜欢调试服务器,倒是可以看看怎样能更有效利用内存。对于技术爱好者来说,Linode 是个很好的操作系统玩具。

大家都喊着"云计算",但是面向个人用户这一块的市场需求似乎没有人关注。随着硬件价格的下降,VPS 服务越来越值得个人用户使用,或许,明后年,个人用户也能用上 Amazon 的 AWS 服务了。技术的乐趣在于折腾。

接下来,可以静下心来好好写一阵东西了。

广告:

  • Linode 的 Refer 代码:92405a6e282a712f7a1270e98d16eba13efb1b68 。用了这个代码注册,过几个月据说我可以得到一点好处,就当你做一回雷锋 :)
  • 如果要使用 Dreamhost ,我以前設置的优惠代码:FENNG 依然有效。
  • 另请参见 BlogKid 对 Linode 的介绍

--EOF--

延伸阅读:选择美国主机的机房地理位置与网络分析 http://oncn.net/641228

Updated: Linode 从 2011.09.20 开始提供东京的 IDC,我已经将 VPS 迁移到 Tokyo 了。速度相当不错。

SSD 趋势小窥

| 3 Comments
Image representing Andy Bechtolsheim as depict...

Image by idg.com.au via CrunchBase

来自 Sun 的大牛 Andy Bechtolsheim (Sun创始人之一)在 HPTS 2009 上做了题为 Memory Technologies for Data Intensive Computing 的演讲。其中对硬件趋势的演绎很有参考价值。

摩尔定律在未来十年内仍然有效。但是对物理磁盘来说某些方面是需要修改的--速度得不到质上的飞跃了 :)

传统 2.5 寸物理磁盘,能够提供 180 个写 IOPS,320 个读 IOPS,平均一个 IOPS 的价格是 $1(这里指价格处以 IOPS 的平均值,不是累积)。而现在主流 SSD 能够提供 8000 个写 IOPS ,3.5万个读 IOPS,每个IOPS 的成本大约是 $0.1。从性价比上看,SSD 的优势逐渐明显。根据来自 NetApp 的信息,SSD 目前一 GB 大约 $3,而磁盘则为 $ 0.10

而实际上,要想达到百万级别的 IOPS 并非易事,I/O 控制器的处理能力毕竟还有限。SSD 写能力仍然是目前的一大问题,随着时间而写能力下降,"均匀磨损算法"(Wear leveling algorithms)目前也不够完美。

密度每年翻倍,内部延时在未来几年将以每年 50% 的速度减小(现在小于100 usec,磁盘则是大于 5000 usec),而传输能力将每年翻倍。成本也将每年减少 50%。这些都是好事情。未来几年,是 SSD 的天下。而传统物理磁盘将成为磁带,SSD 将成为磁盘。(Disk is Tape,Flash is Disk。这话不是我说的,这是 Jim Gray 的名言)

Tape is Dead
Disk is Tape
Flash is Disk
RAM Locality is King
--Jim Gray 2006

--EOF--

延伸观看:MySQLConf 09: Andreas von Bechtolsheim, "The Solid State Storage Revolution"

Instrumentation 与 Profiling

| 11 Comments

看到有反馈说到《Oracle性能诊断艺术》中对于 Instrumentation 这个词的翻译问题。说实话,对这个词的处理当初挺让我头疼,这是个可以意会但很难用一个中文词汇对应的术语,一些翻译词典或是已有的翻译作品对这个词的处理也是五花八门。在图灵著译俱乐部里面提问得到很多回答(这里要致谢!)。权衡再三,最后根据整个章节的重点以及上下文选择用 "性能测量"。

我不喜欢用有些人说的测试领域内所用的术语"插桩",实在是有点诡异。当然,如果这个词不翻译的话,或许更好。其实很多计算机术语容易受到早期译者的影响,比如关系数据库的 "Lock" 这个词 ,动词的时候,很多译者喜欢翻译成 "封锁",个人觉得实在是累赘,就是锁就行了嘛,为什么非要"封"呢?

另一个比较难以处理的就是 "Profiling" ,根据维基百科的解释 ,这个词指"动态程序分析的一种形式...根据程序执行收集到的信息调查程序的运行行为,通常用来查找程序中的瓶颈"。最后我用了"剖析"。(Updated: 中文是 "性能分析"。不过我觉得似乎有点容易混淆。)

这两个词很有趣,任何一个程序或者软件项目构建的初期,如果没有考虑 Instrumentation ,在程序或项目交付后,又不能做 Profiling ,那么这个程序或者项目肯定会是灾难。所以,能对 DBA 着重强调一下这一点或许要比看更多的同质化内容更有价值。

在这本书的最后定稿的时候,编辑来信要求确认术语的统一,对于 "Hash" 这个词,要求用统一的术语"散列",最后我们几位编辑极力坚持用"哈希"这个词(当然,最后用了"哈希")。大部分的数据库图书,尤其是 Oracle 相关的图书,这个词已经是约定俗成的了。所以,说起术语标准化,个人看法也是术语对应列表用来做指导而不是生搬硬套。

翻译需要技术,更需要艺术。这活儿,真的不好干。

--EOF--

更新:Twitter联合创始人 Nick Bilton 说过这样一句话"Early on our biggest problem was that we didn't have any gauges into the system and we didn't have metrics, so we were kind of flying blind. The way we got around it was to instrument the entire system so we could see what was going on" (refer)。可见缺少 Instrumentation 会带来多么严重的问题。

《Oracle性能诊断艺术》出版了

| 21 Comments

几周前,《Oracle性能诊断艺术》(Troubleshooting Oracle Performance 的中文版)终于面市,现在线下的实体书店应该也可以买到了。这半年来一直有朋友在问什么时候能够出版,现在总算有个交代了。

关于中文版书名,图灵出版社编辑们费了不少心思,尽管最后敲定的书名中"艺术"两个字似乎有点托大,不过我个人觉得也还算好,恳请读者把重点放到内容的汲取上而不是和书名较劲。

TOP_Chinese.jpg

这本书从接手到现在也快一年的时间了,整个过程尽管有辛苦,也已经成为过去式。这或许是我最后一本翻译的图书--除非以后出版自己写作的东西(如果内容还能过得去的话)。

如果朋友们针对书中内容有任何问题,可以访问 支持页面留言反馈或者发邮件给几位译者。相信译文中仍有欠妥的地方,译者将尽量提供技术支持以及延伸内容。

--EOF--

感谢这本书翻译过程中给予我们帮助的所有朋友们,有你们的支持,是几位译者的幸运。

DRBD 与 Pacemaker

| 5 Comments

如果有人问你一台 PC 服务器是否可以达到 99.99% 的高可用,该如何回答呢? 或许没有一台机器能"确保"达到这样的可用率,当然在某个时间段或许不会出问题,但这个肯定是看运气,而高可用基本上是没办法通过一台来达到目标的,我们更多的时候是设计方案确保在出问题的时候尽快接管故障机器,当然这要付出更大的成本。

对于 Oracle 的高可用方案可以参考 Maximum Availability Architecture (MAA) 白皮书,不过 Oracle 并不推崇操作系统级别的解决方案。MySQL 的指导策略倒是更为灵活一些,DRBD® (Distributed Replicated Block Device) 就是个可以考虑的选择。以前关注过这东西,但是据我了解,好像国内实现的案例不多,不知道是不是处于对网卡同步速度的限制考虑。现在这个有了新的转机,在 8.3 版本上已经能够支持 InfiniBand 。而原来通过网卡同步数据块的方式毕竟受网卡延时和带宽的限制,InfiniBand 的支持的实现相信能赢得一部分企业用户的信赖。

DRBD_overview.jpg

Linux Kernel Summit 2009 上这次有对 DRBD 的介绍(注意对数据一致性的介绍),这意味着能正式进入 Kernel 么?

相对专有的集群管理工具,也有开源的集群管理工具 Pacemaker (支持 HeartbeatOpenAIS 标准)可供配套使用。Pacemaker 能够较为灵活的实现主备、N+1 、N-N 等多种模式。感人感觉会比较有生命力。

Pacemaker.jpg

好的开源解决方案就是设计活动木板房,廉价灵活环保,当然,牢固肯定是第一目标。

补充:

根据 MySQLPerformanceBlog 的说法,MySQL 几种高可用解决方案能达到的可用性如下:


HA_ratio.png

--EOF--

NUMA 架构与数据库性能

| 4 Comments

在这次的 Oracle Open World 上,Hammerora 的作者 Steve Shaw 做了一个关于 Linux 平台 Oracle 调优的演讲,其中重点提到了 NUMA 架构对于 Intel Nehalem CPU 上跑 Oracle 的性能影响。

对于传统 SMP 来说,CPU 增多未必系统性能就好,因为共享系统总线的限制了 CPU 数量,CPU 越多内部通信量越大共享总线越容易达到瓶颈。而 NUMA 架构则多少缓解了这个扩展问题,其大致机理是通过给每个核提供单独的本地内存,进而提高可扩展性。而每个核访问本地内存和其它核上的内存时间是不一样的,所以,应用程度对于内存的访问是有比较大的讲究的。从硬件到操作系统再到应用程序,都要支持 NUMA 才会发挥真正的处理能力。

在这里倒是可以插入介绍一下阿姆达尔定律(Amdahl's Law),这个定律指出并行处理器环境中的速度受制于程序串行的部分,也即暗示说多核未必性能就那么好。

Intel Nehalem microarchitecture

Image via Wikipedia

对一个 DBA 来说,Intel 的 Nehalem CPU (右图为结构示意图)最值得关注的特性当属 NUMA (Non-Uniform Memory Access) 架构方面的改进。

从 Oracle 数据库 8i 开始支持 NUMA 特性,NUMA 在10.2.0.4 与 11.1 上是默认启用的,不过在之前的版本以及 11.2 之后默认是关闭该特性的。在 Intel 平台上,Oracle Validated RPM 包安装后将激活 NUMA。安装的时候,当 Oracle 检测到硬件与操作系统支持 NUMA 的时候,会自动启用 NUMA 支持,Linux 在内核 2.6.9-67 以后自动支持 NUMA 。至于硬件上的开关是通过 BIOS ,如果硬件支持,则 BIOS 默认是激活(enable)该特性的。操作系统层面的开启可以通过核心参数添加 numa=off 的方式来达到。

可以通过操作系统命令查看相关的状态:

# numactl --show

NUMA 这个常看到的术语,似乎一直以来没有得到 DBA 们足够的重视。需要注意的是,硬件、操作系统、应用软件(Oracle) 三者都要支持 NUMA ,才能充分利用这一特性。对于支持 NUMA 的 DB 环境,理论上来说内存请求的利用应该会更有效一些。至于具体的性能数据还要看实测结果,暂时恐怕难以给出,留待以后补充吧。必须要说的是,作为DBA,在启用某个特性的时候,一定要明白这个特性的来龙去脉,以及潜在的影响。

延伸阅读资料

--EOF--

对于一些不能充分利用多核的软件,比如某些 Web 服务器或者 Proxy,或者需要考虑一下如何利用 NUMA 特性了。而类似跑数据统计的应用,"CPU的并行"得到利用之后或许应该考虑如何更充分利用 NUMA 特性了。

4130467396_b00ea856b8.jpg

Google 使用 Linux 的情况

| 4 Comments
Google, Inc.

Image via Wikipedia

技术爱好者大多都知道 Google 是使用 Linux 的大户,但是一直以来对于他们如何使用 Linux 却知之甚少,甚至内核开发社区对 Google 内部使用的情况也了解不多。LWN 上的这篇 How Google uses Linux 给我们带来了不少信息。

Google 使用 Linux 肯定有很多令人震惊的地方,第一个令人"惊讶"的是他们使用的代码管理工具:Perforce 。代码维护方式看起来也比较落后,当前维护的代码版本远远落后于开源社区内核版本,因为 Google 自己要维护大量的内部特性,每一个大版本发布周期是大约 18 个月,而内部特性的回归也要折腾6个月。因为版本滞后,所以有不少向后移植(Backporting)的工作要做,这个比例大约是 25%,还是不小的。

Google 内部大约有 30 个内核开发人员,而之所以外界很少看到 Google 对 Linux 的 Patch 代码,主要的原因居然是--担心代码不够优雅。我想这应该说的是大实话。我也遇到过很好的开发者对开源软件做了改进之后不愿意把代码贴出来,原因就是担心代码不好看,怕被笑话。

因为应用程序类型之故,对于 Google 来说,完全公平调度器(Completely Fair Scheduler)并不适合,采用了 O(1) 调度器,一般 16-32 核的机器要跑 5000 个线程左右。

Google 倒是喜欢用 Out-of-memory (OOM) killer 特性,这倒是出乎我的意料。Google 对于内存管理方面的改进或许是不小的突破: 通过伪 NUMA 模式来保证不同类型应用对内存的使用。除此之外,有大量的代码用于系统的监控,针对磁盘、网络等子系统或者是针对应用程序性能。

对于计划中的将实现的新特性,在一堆列表中看到了在 I/O 层对于高速 Flash 盘的支持计划。在文末,另一个有趣的技巧是,Google 喜欢把文件系统的元数据 Pin 到内存里以便提高读取响应时间。

或许将来能看到 Google 为 Linux 内核贡献更多代码,那会是一件很有意义的事情。

--EOF--

关于这篇归档

This page is an archive of entries from November 2009 listed from newest to oldest.

October 2009 is the previous archive.

December 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.