分类归档: Arch

PC 服务器的 RAS 能力

曾经被问过很多次这样的问题:PC 服务器的可靠性到底是怎样的? 能否给出一个可用率数值?

这问题说来话长,而且也算不上是什么好问题,当然这里面有非常值得琢磨的地方,那就是 PC 服务器的 RAS 能力到底如何? 只有弄清楚这一点,才会明白在 PC 服务器计算能力已经如此强大的今天,为什么昂贵的小型机依然有市场。在服务器选型的时候才不会拍脑袋做决策。

我们说到 RAS ,也就是 Reliability 、Availability 以及 Serviceability,实际上很多人会认为前两者是一回事,至少提问的时候可能同时说的是这两者。对于多数 PC 服务器厂商来说,宣传页面上也只会写 Availability 的一些指标,对另外两点则选择性的回避? 为什么? 因为做不到高端服务器的 RAS 能力,而 RAS 能力实际上是需要成本的(硬件冗余成本、专有技术的成本),但这个问题似乎是很多用户选型的时候忽略的一点,很多人更愿意看重性能、性价比之类的指标,当然这也没错。

现在 PC 服务器宣称的卖点主要集中在内存上,比如内存的 ECC 特性(最基本的),Spare Row、ChipKill、Single Device Data Correction (SDDC)等,其中 ChipKill 是 IBM 的专利技术,主要用在高端服务器上。根据 Google 与一些机构的合作研究表明,内存错误率其实比想象中的要高(refer),这是个很有参考价值的信息。实际上,尽管有的 PC 服务器可能提供了很多内存相关的特性,但默认未必是激活的,这一点要注意。

高端设备的 RAS 能力比较,至少要看看 System 级别的 RAS 特性、CPU RAS 特性、内存 RAS 特性、I/O RAS 特性 等方面,如果有虚拟化的需求,还要关注一下 Application/Partition RAS 特性(refer)。这些都是卖点,当然,很少有销售人员懂得如何向用户宣传这一点。

即使是有了最好的设备,如果不能充分利用,其实也和普通 PC 服务器没啥区别。而对于绝大多数互联网应用来说,高端服务器也是高射炮打蚊子。

最后补充一点,充分利用带外管理能力是运维人员应该具备的基本意识。什么是”带外管理”请使用避难到香港的 Google 来搜索。

EOF

附:Dell PowerEdge 服务器激活内存 RAS 特性的指导文档

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

暂缓迷恋 Cassandra

最近 Twitter 和 Digg 的技术团队都放出话来说要从 Mysql + Memcached 的组合迁移到 Cassandra 环境(Refer 12),这些消息又会让不少人跃跃欲试,恨不得也把自家网站迁移到 Cassandra 下面过把瘾,我相信有些公司的团队又要言必称 Cassandra 了。

Twitter 和 Digg 对数据存储引擎的需求相当独特:写操作密集,基本无修改需求,读操作则多数是分散多次读取汇总展示(想象一下你 Twitter页面上同时显示好友们的 Tweet 内容)。对 MySQL 来说,Sharding 后几乎是被当作简单的存储引擎来用的,即使是加上 Memcached ,对数据读取开销相当大(Refer),因为这时候即使是最合理用索引,I/O开销也不是最优的–走的是索引范围扫描嘛。Cassandra 则相当于预存了计算结果,这要得益于其 Flexible schema 特性,按照既定规则写入,读取直接取预排序的范围键值结果(这其实是偏 OLAP 的应用,而非 OLTP)。

Twitter 和 Digg 这两家网站的数据结构其实并不复杂,尤其是 Twitter ,相当的简约(当然并不简单)。或许有人说,把 Cassandra 开源的 Facebook 不也在用呢吗 ? Facebook 数据结构不复杂么?没错,Facebook 数据结构很复杂,不过使用 Cassandra 的场景其实和 Twitter / Digg 几乎一致的—只是用在 inbox 这个地方的数据处理而已。

不要迷恋 Cassandra ,如果应用场景不合适,那么对你来说永远都只是个传说。。

EOF

来自淘宝的架构经验

日前参加了一场淘宝网架构师黄裳带来的技术分享,在最后他总计了淘宝这几年来的架构经验,这里和大家分享一下:

  • 1、适当放弃一致性
  • 2、备份和隔离解决稳定性问题
  • 3、分割和异步解决性能问题(类似 eBay 的 Asynchrony Everywhere)
  • 4、自动化降低人力成本(类似 eBay 的 Automate Everything)
  • 5、产品化管理

在这里不妨对比一下 eBay 的架构经验:

  • 1、 Partition Everything
  • 2、 Asynchrony Everywhere
  • 3、 Automate Everything
  • 4、 Remember Everything Fails
  • 5、 Embrace Inconsistency
  • 6、 Expect (R)evolution
  • 7、 Dependencies Matter
  • 8、 Be Authoritative
  • 9、 Never Enough Data
  • 10、Custom Infrastructure

关于一致性,可以延伸阅读 Amazon CTO 的大作 Eventually Consistent。此外,强调了”放弃集中的紧耦合处理”的原则。”备份”这里可以理解为”提供可用的副本”。”分割”是说水平拆分。

架构这东西说起来大致原则,其实都是类似的,但是具体如何在一些通用原则上做到运用自如,是很难的事情。前几天我还感慨,很多架构师对与”异步”与”批量处理”所能带来的益处的理解仍然相去甚远。

EOF

SmugMug 的架构介绍

本文介绍的 SmugMug 是一家提供付费图片托管服务的站点,在 2002 年由 Chris MacAskill 与 Don MacAskill 父子二人创建,最初提供面向游戏的视频服务,随后转型为现在的模式。网站流量现在是全球 1800 多,盈利能力自称良好。

在 MySQL Conf 2009 上,SmugMug 的 Don MacAskill 做了一次关于SmugMug 网站架构的分享。

SmugMug 整个网站采用 LAMP 架构(其实也有 OpenSolaris),300 多台 4 核(或更多)的服务器(大多是 AMD 的 CPU) ,分散在四个机房,两个运营的人员。SmugMug 充分运用了云计算服务,是 Amazon 的一个大客户,图片和视频总计达到了 PB 级,托管在 Amazon S3 上,图片和视频的处理也在 Amazon EC2 上。使用了 Akamai 的服务做前端的 CDN 加速,主要是 JavaScript/CSS 等文件的加速,此外,DNS 加速也带来了很好的收益。

结构化数据放在 MySQL 中,存储引擎多数用的 InnoDB,数据超过 2TB 的空间,数据库服务器为 4 核或更高配置,内存多达 64GB。缓存方面,用了 Memcached 做加速,有 1TB 的数据在这里面,平均命中率达到 96%。Memcached 里面尽量存放 MySQL 行数据,减小对 DB 的冲击。数据库设计思路是尽量做垂直分区,没有 Sharding。不过在反范式(denormalized)方面做得比较彻底,不用表连接(JOIN)方法者复杂的查询。多数查询依赖主键,更新或者删除数据也是单行,依赖主键。InnoDB 引擎打了 Percona 的 Patch,并发能力也有了很大增强。

对 DB 的数据完整性与写能力的要求高,而对于读的扩展性还是相对比较好解决。Linux 上的文件系统是 SmugMug 不太满意的地方,备份也成问题。ZFS 倒是能满足相关的需求,可惜不支持 Linux(妈的,早该支持 Linux了)。所以他们迁移到了 OpenSolaris 上。另外,对于复制中可能出现的风险,尝试了第三方提供的一些 Patch (参考 Google 发布的 MySQL Patch)。

采用 OpenSolaris 后,MySQL 放在 Sun Sushi Toro(Storage 7410,这个东西也支持 SSD ) 上,走 NFSv3 协议。写到这里,发现 SmugMug 的解决方案非常不具有通用行,看起来 Sun 是给了他们不小的硬件优惠,否则一般情况下不会有人这么搞的,用 NFS 协议走数据库,除非是测试环境或者是复制(我怀疑只是 Slave 端通过 NFS 走),产品上真的有人跑么?

网站架构的进化,其实也是选定一个方向(比如用开源工具解决),然后一直试错的过程。

EOF