分类归档: Arch

再跟 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 .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

面向生产环境的SOA系统设计 by 支付宝程立

在刚刚举行的系统架构师大会上,支付宝首席架构师程立分享了《面向生产环境的SOA系统设计》这个技术话题。现在把 PPT 第一时间和大家分享一下。

程立在 SOA 功底深厚。上次在 InfoQ QCon 会议上程立的话题也是有关 SOA。本次演讲内容侧重与上次侧重点不同。只是因为会议时间有限,所以有几页没有完全展开来讲,稍稍有点遗憾。

感谢程立。大家针对该 PPT 有任何问题的话,请留言或者发邮件给我,我将第一时间转给他。

关于 PPT 作者

程立是支付宝公司的首席架构师。他从2004年起参与支付宝与淘宝网的建设,2005年正式成为支付宝人,随着支付宝的业务与技术的成长,从开发工程师、架构师到首席架构师一路走来,全身心投入并见证了支付宝业务与系统发展的完整过程。


支付宝一直在招聘软件架构师,我们是 Java 开发环境。如果您对支付宝感兴趣,并且想让自己做的东西服务于两亿多的用户,不妨联系我们或者直接发简历到: [email protected]

EOF

3PAR 存储架构解析

对于国内存储市场来说,3PAR 是不折不扣的后来者。也是个相对陌生的存储产品,以至于其竞争对手的人员甚至都不知道这家公司已经杀入中国市场。

3PAR 在 1999 年成立,几个创始人主要出自 Sun ,前身叫作 3PARdata , 2008 年上市。要知道在存储技术领域竞争还是比较激烈的,EMC / HDS 等控制着高端存储的主要市场,3PAR 能突破技术壁垒并最后成功上市,没两把刷子那是绝对做不到的。

InSpire 硬件结构

3PAR 背板采用全网状的连接结构,每个控制器节点之间高速直连。因为是全网状的,所以基本上一个链路坏掉只影响直连的两个节点的通信,对其它节点无影响。每个控制器节点内置一块硬盘,用于操作系统安装。控制器节点最多可以扩展到 8 个,是 3PAR 存储最核心的组件。

相比之下,HDS 架构采用全光线交换方式(Universal Star Network),而 EMC 是采用直连矩阵方式(新一代产品采用虚拟矩阵架构–Virtual Matrix ,其实已经放弃了直连矩阵架构了)。这些连接方式的孰优孰劣历来是厂商攻击竞争对手的着眼点,能否最大限度发挥性能是用户最需要关心的。

3Par_full-MESH.jpg

3PAR 针对 I/O 指令和数据移动使用不同的计算芯片。I/O 指令(元数据/控制Cache)用 Intel 的芯片,而 数据移动/Cache 则使用专门设计的 ASIC 芯片来完成。

3Par_Controller_Node_IO.jpg

因为有专门的硬件 ASIC 芯片用于 RAID 5 XOR 校验,3PAR 号称有了其第三代 ASIC 芯片,实现的 RAID 5 是业界最快的,甚至 SATA 盘也能有不错的性能表现。(从 Oracle 公司测试的数据来看,和 RAID 10 速度的确相差无几。)

InForm 操作系统软件与虚拟化

3PAR 的操作系统叫 InForm,最初就是面向层次化的设计。与其他存储不同的是,3PAR 所有磁盘被分成 256MB 统一大小的小盘(Chunklet),可以根据需要用多个 Chunklet 组成 RAIDlet(逻辑磁盘)。因为这个独特的设计方式,3PAR 是可以很容易做到不同容量的磁盘混用,同一个 RAID 组里都可以有不同大小、不同转速的磁盘混用,这是其他存储做不到的。而且,所有的磁盘都可以利用,因为Hotspare Chunklet 以更小的单位分散在不同的磁盘上,也不再需要单独留热备盘。空间利用率可以更充分一些。 

3Par_3level_virtualization.jpg

多说一句,有这个冗余机制,3PAR 更换磁盘也是与众不同:直接抽磁盘盒子(一个盒子可是四块磁盘啊),我当初看到 3PAR 技术人员这么操作真是着实吓了一跳。

因为固定大小的 Chunklet 的存在,可以将 I/O 更为均匀的分散到多个磁盘上。

3Par_balance.jpg

对于熟悉Oracle 的朋友来说,会发现这和 ASM 的思想非常接近。因而也可以和 Oracle 数据库进行无缝集成:

3Par_Thin_Provision_Oracle_ASM.jpg

因为软件做得非常具有易用性,日常管理与维护远远没有其他高端存储那么复杂,新增磁盘这种事情,都是一行命令之后底层自动处理。其实在 Thin Provisioning 方面 3PAR 也是很值得一说的,比一些厂商的伪 Thin Provisioning 具体多了。限于篇幅,不赘述。

3PAR 在美国有很多金融证券行业的客户,也有 Web 2.0 行业的客户–MySpace 。在保证 I/O 响应在 10ms 以内的前提下,3PAR 的 IOPS 能力非常优异(这才是卖点,不难理解其客户多集中在证券、金融领域)。虽然有些厂商号称能得到更高的 IOPS ,但那是在 I/O 响应时间很差的情况下的数据。要说明的是,现在随着一些存储厂商在高端服务器上也支持 SSD ,未来几年如何还要再看。

前两年 3PAR 推行所谓 Utility Storage(功用存储) 理念,现在貌似改成敏捷存储了。说实话,我觉得敏捷存储真的挺适合的,3PAR 命令行批量创建 LUN 真的很让人感觉舒服。当然,也在宣传云存储和绿色存储的理念,那是题外话了。

3PAR 原来只做中高端市场,只有 T 这一个系列,现在也开始关注中低端市场了,推出了 F 系列的产品。软硬件体系基本没变,倒是没仔细看过。

(Note: 相关图片主要来自 3PAR 公开资料.)

EOF

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