这两天关注了一下基于 SAN/NAS 的集群文件系统的产品。找到了关于 Alexa 的一则旧闻，之后又发现了一篇关于 AOL 部署 SAN 文件系统的文章。
Alexa 超过 1000 台 Linux 服务器 Farm，每半年增长 300T 新数据。经过了同类产品的选型后，最后选择了 Ibrix 融合文件系统。
SAN 使用的是 HP Modular Smart Array (MSA1000) ，最大支持 12T ，Cache I/O 最大 3 万个，算是个中低端的阵列。Amazon 没有透漏这套系统的吞吐能力，只是说 Ibrix 这套系统能达到 1T 的 I/O 聚合能力，单个 NameSpace 可达 16PB 容量。
不过从现在的一些迹象上来看，Amazon 对存储层重新做了改造。这套解决方案被替换掉了也说不定.
原有状况：3000 台主机通过 10000 多个光纤通道端口连接到传统的 SAN 上。其中有 8PB 的非结构化数据，分布在大约 1000 台 文件服务器上。管理维护的复杂度可想而知。
解决方案：文件服务器采用直连的磁盘，每个 12 块 700GB 的 ATA 磁盘，然后通过 Ibrix 融合文件系统进行集群化。
看起来，Ibrix 提供的解决方案很有竞争力。现在一些比较大的用户对于存储层的集群的需求越来越多，快成为趋势，一揽子解决方案还是有必要的，毕竟不是每家技术能力都强如 Amazon、Google ，有的时候用第三方的成本是能小于自己动手 DIY 的。
–EOF–
偶然发现了这个 NagiosChecker ，更方便的显示 Nagios 报警信息的 Firefox 插件。
这个插件几乎能搞定 Nagios Alert检查的方方面面，具备足够丰富的的过滤规则与显示条件；还能够定期调度；有趣的是，居然还提供声音报警。
一般人我不告诉他！
–EOF–
在公司洗手间看到一个关于“密码提示问题”的笑话。不过仔细一琢磨发现不是这回事儿。电子商务网站几乎都设置密码提示问题的。一个有趣的现象是有些 UE(或交互设计师？反正是干这个活儿的人) 工程师自己都没搞清楚这个 “密码提示问题“ 要给用户什么。
对于 UE 我是门外汉，不过我理解的这个过程就是建立公钥和私钥：公开的密钥即“密码提示问题”，是其他用户也可以看到的)，只有自己知道的叫私钥，也就是答案。很明显，既然说到私钥，那么私钥的保护就是关键。设计者有必要引导用户保护好自己的私钥。
我们先看个例子(类似的网站很多，就别说具体哪家了，都那鸟样)：
告诉我，用户需要填入”正确”的还是”错误”的答案?
就这个密码提示问题来说，如果没有直接明白的告诉用户正确的使用方式(你的用意!），那么很多用户还是输入“真实”的答案。除了第一个和第四个问题之外，其他几个问题我想在SNS 网络如此盛行、搜索引擎如此强大的今天，要得到答案是不存在什么障碍的。用户并不傻，但用户也不是都会耍小聪明，如果你去做个统计，我相信会有大量的用户输入的答案是可以猜到的。
或许有人会说，”没事啊，即使别人猜到了这个答案，密码最后也会发到原用户自己的信箱里的啊”。拜托，安全本来就是一环套一环的，这个如果被搞定了，你能确保用户的信箱不会被搞定么?
到各个站点查看帮助说明，发现原易趣的说明还是比较到位的(是否在用户设定问题的时候提示，我就不知道了)：
选择一个容易回答但其他人难以猜到答案的问题。
密码提示问题与任何其他机密信息一样重要，所以不要向其他人透露。
为安全起见，可以为问题提供并不正确或答非所问的回答。
前几天白鸦有篇文章《跟着用户走到沟里》，其实很多时候网站是设计者把用户带到沟里。
–EOF–