消除小型 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 的健康程度检查重要性应该提升一些。如何检查？有很多在线的工具可供使用，简单直接。

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 了。速度相当不错。

SSD 趋势小窥

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

看到有反馈说到《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 会带来多么严重的问题。