分类归档: Arch

IDC 的电力问题到底有多严重?

最近在不同场合都遇到涉及 IDC 电力问题的讨论。对于这个话题我一直不是特别留意,直到昨天我说了一句比较武断的话之后,感觉到没有调查就没有发言权,所以找了一些数据来。

国内很多互联网公司关心 IDC 电力问题,可能有一部分是受了一些美国公司(尤以 Google 为代表)的影响。根据美国环境保护署的预测数据,到了 2011 年,美国数据中心消耗的电力将达到 1000 亿千瓦–这个数字够惊人的,这个问题如果放到美国的大环境上来看可能又不算什么,因为这个数字占美国总耗电量的比例 大约是 2.625%。那么中国呢? 考虑到中美能源利用效率的差异,我想现在数据中心用电量绝对不会超过 1%。Google 这类公司强调节能、绿色 IDC 之类的说法有他们的理由,且不说提高企业形象 — 在欧美如果大企业不提倡环保,还不被那些环保组织骂死 ? 另外,省钱也的确是硬道理。此外,有一大票鼓吹绿色 IT 的家伙是各色商业公司,当然,宣传的目的是为了多购买他们的”更加省电”的产品。

中美电力使用的一个巨大差异是,美国工业用电与商业用电相对比较便宜,而居民用电反而比较贵。在中国倒是相反,居民用电相对便宜,而工业用电和商业用电是比较贵的(前不久的发改委才要求工业、商用同价格,参考)。考虑到地域差异,以及各种因素,美国居民用电平均大约 10 美分左右(信息来源),而国内的价格,是一笔糊涂账,我所居住的杭州,正常时段的价格要超过 0.55 元,而且根据用电量大小、时间、类型等等有不同的计算价格,以我这个智商恐怕算不清楚的。不管怎么样,中美的居民用电价格是相差不大的,考虑到中美人民的收入,这里面实际差异还是很大的。(国内在 2008 年 7 月 1 日曾经提过一次电价,每千瓦时提价 2 分 5 厘– 看似很小的涨价? 这意味着每年就可以多收近千亿的人民币。嗯,有点跑题了。) 限于这多少算技术贴,其他层面的东西就不说了。

工业用电价格贵,那么似乎的确应该节电了? 在目前国内,有一些数据中心的确已经面临电力问题,但这些问题集中在 IDC 如何抢到电力资源(毕竟不同地区电力资源分配不均衡),而不是如何少用电,更为关键的是,你少用你那么一点点电(本来就没多用多少),可能真的解决不了什么问题,因为如果收费的标准不根据你用了多少电来衡量 — 体现到经济效益上来也就不会有多大,要是新闻联播每天少播 5 分钟,那全国要节省多少电阿… 很少有 IDC 根据电力对用户收费,更多还是根据物理空间、网络带宽等指标收费。作为用户一厢情愿的考虑 IDC 的问题乃至环保,或许还有点早(不是说不重要,而是这个问题不是我们最迫切的事情,当然,有这样的想法还是好的,是值得肯定的)。个人觉得提升计算性能充分发挥机器能力或是提供更好的产品给用户,可能也会节省大量资源,产生更大的经济效益。既然丁磊都说了”企业最大的慈善就是把产品做好”,我们可以套用一句,做好产品、给用户提供更好的体验也是环保…

对了,我那句武断的话是(洁本):

三年内,中国网络公司不用担心电力太贵;五年之内,不需要讨论环保问题。

不是这方面专家,引用的数据或许有误,当然,我的结论也明显有问题,您就对付着看吧。

EOF

电这个问题,如果 IDC 抢到的少,即使你用的少,别人也同样会用得多。经济因素影响真的不是那么大。

更新一下结论,IDC 如果抢不到电力,别的说什么都是收效甚微的事情。

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

从 Twitter 运维技术经验可以学到什么

没有一个网站的性能像 Twitter 这样这么令人牵肠挂肚,看见那条大鲸鱼总是让人感觉很无奈。Twitter 的运维专家 John Adams 在 Velocity 2009 上做了一篇题为 Fixing Twitter 的技术分享(PDF),人家也是一直在努力阿。John Adams 在 2008 年七月加入的 Twitter ,对于 Twitter 的站点稳定的确做了不少工作。

Twitter 运维团队的职责:

  • 软件性能(后端) Software Performance (back-end)
  • 可用性 Availability
  • 容量规划 Capacity Planning (metrics-driven)
  • 配置管理 Configuration Management

看完这个接近 50 页的 PDF ,除了满足我们一小部分技术窥探的癖好,或许也可以学到点什么。

不重复发明轮子

对于监控,Twitter 用的就是 RRDtoolGangliaMRTG 这些已经成为很多网站标准配备的组件。而不是自己写一大堆功能重复的东西。值得注意的是, Twitter 也一直在用 Google Analytics 进行业务分析。

不重复发明轮子,可以打磨轮子,比进行如一些功能脚本定制之类的工作。

发明不重复的轮子

Twitter 开源了他们自己用的一个 Apache 模块 mod_memcache_block(a distributed IP blocking system),这个模块根据 HTTP 代码请求限制访问频率。熟悉 Twitter 的朋友会知道这是针对第三方应用程序的必须的一个功能,否则的话,会产生类似 DDos 的效果 :) John Adams 说这个模块是他多年以来就期待的东西,我相信,如果有人已经做了同样的事情,他们肯定不会自己再写一个。

尽可能的自动化

无论是配置管理还是针对各项功能的”开关”,都尽可能的自动化。依赖于人来控制一些事情容易”规范”,但是流程冗杂,节奏变慢。

更好的理解硬件

拥抱新技术体系,使用更有经济效益的硬件(比如对 8 核 CPU 的选型与更换)会带来更好的收益。而这个要建立在对硬件体系的正确理解上才行。

另外几句话要记住:

  • Disk is the new Tape. (内存是新类型的磁盘. 磁盘是新类型的磁带)
  • Kill long running queries before they kill you. (问题是如何提前发现? 有效的监控!)
  • Use metrics to make decisions, not guesses.
  • “Cache Everything!” not the best policy

或许还应该学到更多…

EOF

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

关于 I/O 的五分钟法则(Five-Minute Rule)

去年在对 SSD 做调查的时候就关注过这个五分钟法则,今天又发现了这篇文章的修订版(为了纪念 Jim Gray),这个话题倒是可以简单介绍一下,对架构师衡量 I/O 能力、Cache 评估和做硬件选型还是会有一些帮助的。

在 1987 年,Jim Gray 与 Gianfranco Putzolu 发表了这个”五分钟法则”的观点,简而言之,如果一条记录频繁被访问,就应该放到内存里,否则的话就应该待在硬盘上按需要再访问。这个临界点就是五分钟。看上去像一条经验性的法则,实际上五分钟的评估标准是根据投入成本判断的,根据当时的硬件发展水准,在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400 秒的开销(接近五分钟)。这个法则在 1997 年左右的时候进行过一次回顾,证实了五分钟法则依然有效(硬盘、内存实际上没有质的飞跃),而这次的回顾则是针对 SSD 这个”新的旧硬件”可能带来的影响。

graefe_table3.gif

随着闪存时代的来临,五分钟法则一分为二:是把 SSD 当成较慢的内存(extended buffer pool )使用还是当成较快的硬盘(extended disk)使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后,在闪存时代,5 分钟法则依然有效,只不过适合更大的内存页(适合 64KB 的页,这个页大小的变化恰恰体现了计算机硬件工艺的发展,以及带宽、延时)。

根据数据结构和数据特点的不同,对于文件系统来说, 操作系统倾向于将 SSD 当作瞬时内存(cache)来使用。而对于数据库,倾向于将 SSD 当作一致性存储来用。

这是一篇非常重要的文章(所以,建议读一下原文),其中对于数据库一节的描述尤其有趣(针对 DB 也有个五分钟)。限于篇幅,就不罗嗦了。

EOF

Voldemort — 分布式 key-value 存储系统

拜读了关于 LinkedIn 几位工程师写的构建 TB 级的 key-value 系统的经验:Building a terabyte-scale data cycle at LinkedIn with Hadoop and Project Voldemort。具体实现过程有大致的描述,就不鹦鹉学舌了。

linkedin_arch.png

其实现在很多公司可能都面临着这个抽象架构图中的类似问题。以 Hadoop 作为后端的计算集群,计算得出来的数据如果要反向推到前面去,用什么方式存储更为恰当? 再放到 DB 里面的话,构建索引是麻烦事;放到 Memcached 之类的 Key-Value 分布式系统中,毕竟只是在内存里,数据又容易丢。Voldemort 算是一个不错的改良方案。

值得借鉴的几点:

  • 键(Key)结构的设计,有点技巧;
  • 架构师熟知硬件结构是有用的。越大的系统越是如此。
  • 用好并行。Amdahl 定律以后出现的场合会更多。

关于 key-value 应用的解决方案又多了一种。LinkedIn 对此应用案例也还在发展中。如果业务类型类似,不妨关注一下。

EOF