Tag Archives: Arch

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

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

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

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

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

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

关于 PPT 作者

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


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

EOF

参加系统架构师大会

下午的飞机去北京,去参加这个 2009 系统架构师大会。颇为感慨的是,现在技术会议的名字都越起越大了。

这次会议是偏向系统层面的,面向开发人员的内容比较少。支付宝首席架构师程立的《电子支付系统的分布式服务架构与开放架构研究》是关注电子商务技术人员应该听的一个课程。PPT 我已经提前看到了,很是精彩。上次在 InfoQ 上的 PPT 有些用力过猛,这次的更加实惠一些。

我个人感兴趣的几个话题是淘宝网陈吉平的《高可用分布式数据库系统架构实践》,PPT 已经看到了,期待;还有章文嵩博士讲《LVS架设的网络服务,解决百万访问瓶颈难点》,当然,百万现在不是什么大数量,应该用”亿次”更吸引眼球;51.com 的徐景春的《MySQL 数据库在线存储灾备实践分析》应该值得一听,MySQL 灾备的话题以前毕竟不多。腾讯、百度也会有人出席或作技术演讲,不过越是大公司在这种会议上越是不说干货(倒不是演讲人不愿意说,而是一些政策限制),隔空搔痒,怕不过瘾。

最后一天要匆忙上阵,给存储架构设计专场做次主持人。主办方免费提供的机票住宿总算要给个交代。要不我都不打算参加了–出差还是非常折腾人的,消磨时间消耗精力。

参会的朋友,北京见!

EOF

此文作者:, 位于 MyLife 分类 标签: 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