作者文章: Fenng

再跟 Flickr 学习网站运维经验

Image representing Flickr as depicted in Crunc...

Image via CrunchBase

学习了一下 Flickr 的运维工程师 John Allspaw 的这个Operational Efficiency Hacks 讲座内容。做一点笔记。

现在 Flickr 的数据相比2007年的时候真是有了显著的增长:

  • 24 TB 的 MySQL 数据
  • 每秒钟 MySQL 有 3.2 万次写操作
  • 每秒钟 MySQL 有 12万次读操作
  • 图片容量 6 PB
  • 每天要用掉 10TB 存储
  • 超过 15000 个服务监控点

在 2004 年的时候 ,Flickr 使用 ImageMagick (version 6.1.9)之后转移到 GraphicsMagick,我还以为是因为版权问题,现在知道这样做是因为速度,换用 GraphicsMagick 处理速度提升了 15%,而 ImageMagick 功能尽管强大,但都是 Flickr 用不到的功能。如无必要,勿增实体啊。GraphicsMagick 在并行方面(OpenMP)的支持也很不错(参考)。

除了技术手段的优化,Flickr 充分利用硬件本身的更新换代带来的好处,曾经用 18 台新机器替换掉原来的 67 台 Web 服务器,用 8 台新机器替换掉原来的 23 台图片处理的机器。无论从机架占用还是电力使用都节省了很多,而整理处理能力并没有削弱。我们总说摩尔定律,但是恐怕很少有人真的享受到摩尔定律带来的好处。Flickr 的做法是很值得学习的一个地方。精兵简政,不要只冲着人下手,动手”裁”掉机器,也会省钱嘛…

Flickr 技术团队随着网站的快速发展并没有增加大量人手,个人生产力的产出是相当的高。如何做到的呢?给出了四个非常有趣的原则:

  • 使得机器自动构建 (Teach machines to build themselves)
  • 使得机器自监控(Teach machines to watch themselves)
  • 使得机器自修复(Teach machines to fix themselves)
  • 通过流程减少 MTTR (Reduce MTTR by streamlining)

自动购建上,Flickr 使用了 OpsCodePuppet 以及 System Imager/Configurator 等。或许这几个工具值得我们关注一下。

Flickr 团队内部沟通工具也挺有意思,除了内部的 IRC 用于讨论之外,还利用 Yahoo! Messenger 的 IM Bot 记录更多的系统变化,并且,重要的是,将这些信息弄到搜索引擎里面 … “信息查找”,是国内多数团队交流工具忽视的地方。

最后感慨一下 Flickr 技术团队仍然是非常有活力的团队。最近的另一个消息是国内的 Yupoo.com 原创业团队也即将重装上阵,重新接管 Yupoo 网站,要知道 Flickr 仍然是最有影响力的网站之一,所以,有理由期待 Yupoo 团队的精彩。

EOF

此文作者:, 位于 Arch 分类 标签: , , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

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

《魔兽世界》(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

此文作者:, 位于 Arch 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

消除小型 Web 站点单点故障(Single Point of Failure)

针对小型站点的技术普及信息,中大型网站的牛人不用看,耽误您的时间我负不起这责任。
用 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 的健康程度检查重要性应该提升一些。如何检查?有很多在线的工具可供使用,简单直接。

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Yes! Linode VPS

感谢豆瓣独家提供的两年托管赞助费用!这几天利用空闲时间把 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 了。速度相当不错。

此文作者:, 位于 SiteLog 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.