[置顶] 轻掠Web 图片服务器
本文转自:http://www.dbanotes.net/web/web_image_server.html
现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片，如果前期没有很好的规划，那么随着图片文件的增多，无论是管理还是性能上都带来很多问题。就自己的一点理解，抛砖引玉，以期能引出更具价值的信息。
事关图片的存储
把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备，那么简单的很；如果有能力自己开发单独存储图片的文件系统，那么也不用接着往下看了。
如果上述条件不具备，只想在普通的硬盘上存储，首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的，实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ，怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑，选择合适大小的 inode size ，在空间和速度上做取舍，同时防患于未然，注意单个文件系统下文件个数别达到极限。
独立，独立的服务器
无论从管理上，还是从性能上看，只要有可能，尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后，在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd 。
如果不想在几台机器间同步所有图片，只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题，以及 NFS 特定的传输速度。
独立，独立的域名
如果大部分 Web 页面必须要载入很多图片，那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。
前几天有个朋友在线上问我，”一些大网站，图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?” ，粗糙一点的答案：除了管理方便，便于CDN 同步处理，上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知，有请 Yahoo！的同学发言) 【还有一个我没考虑到的是 Cookie 的因素，参加楼下高春辉的留言】
2009/02/19 23:10 | 作者: Luke Lai | 同意转载, 转载时请以超链接形式标明文章原始出处，谢谢!
网址: http://www.it-infra.cn/Ultradns_vs_IP_Anycast/
今天又收到Ultradns发过来的每月Intenet infrastructure的邮件，其中有条挺有意思的，是关于IP Anycast，中文翻译应该叫IP任播吧。曾经跟Ultradns相关的技术经理沟通过Ultradns的架构，感觉那哥们跟偏重于商务，技术都是美国那边控制着，包括在中国建点也是美国那边直派技术人员过来，其实Ultradns的技术还是挺牛。
听说销售最好的业务员没有比较最差的业务员多打几个电话，这里可以看得出来，销售最牛的业务员一定有自己实现的方法，一定跟其它的业务员有区别。随着对Ultradns的了解，觉得Ultradns还是真有自己的一套。它的基础架构跟一般我们从书中上学到的DNS架构完全不一样。其中就是核心架构IP Anycast + BGP。
关于IP Anycast简单解释Neustart公司这么说的：
UltraDNS在五大洲已经搭建14个公共节点，虽然在国外鼎鼎大名,但在中国没有什么名气。我想也是跟UltraDNS的基础架构有一定的关系，这种架构第一要求拥有自己的公网IP地址段。第二要跟该国家的主要运营商有BGP广播。目前国内运营部不像国外那么好商谈，坐地起价，漫天要价，而且BGP震荡且不提供任何SLA保证。呵呵，Ultradns也正是因为这种架构“枷锁”在中国难以到处开花，上次听说Ultradns已经在香港开了一个Node，提供一些国外网站在华业务的支持。
呵呵，乱七八糟说了一通UltraDNS，其实IP Anycast还可以应用在企业内部作为DNS高速及冗余可靠方案，回头有时间再写点。
简单的UltraDNS结构图，没有搜到详细些，但也有想象空间，呵呵，版权所有@NeuStart
参考资料：
UltraDNS: http://www.ultradns.com/technology/overview.html
IP Anycast: http://en.wikipedia.org/wiki/Anycast
[置顶] Google会在冰岛建IDC?
网址: http://www.it-infra.cn/Iceland_vs_IDC/
相传Google要在冰岛建立IDC，在这之前对冰岛的认识还停留在中学的地理课中：冰岛是欧洲最西部国家，位于大西洋北部，靠近北极圈，这个世界上最冷的国家处在北极圈边上，冬天平均温度是零下30℃～40℃。
偶尔查了一下源自冰岛本国的招商的网站赫然有一篇这样文章<<Iceland: the coolest location for Data Centers>>，里面极力推荐的主要理由有三，第一电力资源丰富且便宜，主要是水力发电(hydropower) 和 地热发电 (Geothermal power）两种绿色能源；第二安全（主要是政治风险小，没有军队，而且从来没有参战）；第三土地成本及居住成本低。而且欧洲主要的海底光缆也能到达。
看到这篇文章<<Iceland: Cheap Power, But Some Risk>>虽然看起来冰岛的环境非常适合于建立IDC，但这位老哥也提醒大家风险在什么地方：大家要注意“地热发电”，那来的“地热发电”，如果这个地方不挨着火山，地层活跃地带，那来的地热？ 按照上面一篇文章<<如何考察托管机房--灾难恢复10问>>这个地方不太适合建立IDC，如果我觊觎人家电力与空调环境的话，这个地方说实话也只能搞个Disaster recovery Center，但Google会放心吗？
但冰岛现在的经济形势（国家破产）却是最好投资时机，便宜电力，以及长期的低温使得IDC热交换式空调有用武之地，这是在目前经济形势情况多大诱惑呀，让我们拭目以待到底那家公司是一个先行者。
Image Copyright@Invest IN ICELAND AGENCY
网址: http://www.it-infra.cn/How_to_handle_interruption
今天读了<<时间管理--给系统管理员>> 主要原因是当年拜读了Thomas A. Limoncelli的系统<<系统网络管理技术实践>> ，获益菲浅，一直是作为我在IT基础设施部门的指南，仿佛是海上迷雾中的灯塔。以致在现在这家IT基础架构相当优秀公司里，我仍能找到这些思想的影子，优秀的系统管理员都有共同的性格/思维的特性，难道不是吗？
这本时间管理的薄书（加上后记也只是210页），浓缩了接近二十年IT基础设施管理工作中积累的经验，有很多精彩的篇章。其中有一点我想的比较多，那就是如何帮你的系统管理团队搭建防“扰”墙?
相信每个系统管理员在专心做某个项目性的工作，都会对寻求支持的来电这种事情大为光火，呵呵...... 每次手中事情被中断之后，都要补上好几分钟才能把刚才的思路接上，而且非常容易出错。
书中在多处强调“共同防线”，简单来说就是两个系统管理员商量好，一个SA上午处理各种会被打断的杂事务，另外一人在处理一些项目事务，下午则反之。当然，如果重大故障影响了业务中断，那两个家伙必须一起扑上去解决问题。我个人觉得这个处理方法非常棒且灵活。
我们还有很多技巧，比如在系统管理员处理重大故障的时候，我们可以让其它人员来接听电话，向用户解释出了什么问题，我们正在处理，解决之后通知他/她们等等，避免打断系统管理员的思路。但这只是头痛医头，脚痛医脚，如果没有计良好的支持体系，这些技巧也用不多长时间，这本书最后，我觉得也是系统管理员时间管理较高的境界，就是一句话"最终的时间管理技巧是良好IT基础架构"，当然也包括支持架构，这句话在书中的第158页。
在良好的IT支持架构下搭建防“扰”墙才是最根本的办法。在大型公司或者非常庞大的系统，比如Google, Yahoo及其它需要系统网络支撑整个核心业务的公司，他们不但有数量庞大的服务器，网络设备，跨时区支持，而且这些公司都要求非常高的SLA可用性。我们IT infrastructure Manager怎么建立可靠，灵活，高效的支持结构？ 我在这里分享一下实战的经验:
第一：把系统管理团队分成三个虚拟组(Build virtual groups)。
首先是虚拟组是普通系统管理员组(Junior SA)，第二个是系统管理员组(SA)。第三个虚拟组我们称为系统架构组(Senor SA / Sys Arch)。
第二：建立请求跟踪系统(Ticket tracked system)
比较有名的商业的ticket系统叫：BMC Remedy Action Request System
开源的项目有RT系统，也是这Thomas推荐的：RT System
第三：建立值班轮倒制度
建立值班制度，假设公司要求你网站的业务是7X24小时，比如Dell.com，这个时候就要求有24小时值班人员。
第四：把监控系统跟你“请求跟踪系统”连接起来，并在重大故障时短信/电话值班人员
第五：值班支持
平时只有前二个虚拟组成员值班，先让Junior SA（第一组成员）挡掉80%的工作，另外15~20%难度比较大的转到后面SA（第二组成员）上，可能是会有5%的问题涉及到架构性，则转给架构组成员进行研究。
举个例子：公司有5位Jr SA，2位SA，1位Sr SA，平时上班时候，只安排2位Jr SA，1位SA进行值班，处理所有请求跟踪系统过来的请求，以及接听IT热线打过来的电话，时不时还要看看监控报告系统。而其它3位Jr SA就可以进行一些项目性的工作，如公司上线搜索系统需要在机房物理安装十台服务器，包括的工作从资产部门领取硬件到系统安装完成。而另外一位SA就可以准备该搜索系统相关系统配置脚本及验证十台服务器的相关配置。另外一个大牛呢，Senior SA/ Arch就在琢磨怎么用开源的东东搭一个在服务器关机的情况如何远程重启/开机，免得那几个Jr.SA老在抱怨大周末把他们叫到机房重启服务器去。
这样IT支持体系结构不但保证了日常运行维护的请求响应及项目性的IT支持，而且建立了稳固的“防扰墙”，系统管理员高兴，客户happy，你也Happy。
[置顶] 某中大型网站系统架构--实战案例研究
网址: http://www.it-infra.cn/Web_Site_Architecture
你是否一直考虑网站架构要有冗余性，安全性? 同时又有经济性呢？
你是否经历过痛苦的思索网站的架构到底怎么样还算合理？
怎么保证关键业务能够冗余，而其它业务可以选择冗余或不冗余。资金紧张的情况下 可以选择不冗余，一旦资金到位，系统架构又具备一定的灵活性，从而非常方便增加冗余设备？
相信每个网站的系统网络部门都经历了网站系统架构的艰苦摸索，从一开始只有简单的几台服务器，随着业务增长，到了上百台服务器，但从未停止过探索。下面我想把从几次实战的中实验贡献出来，该架构已经在好几个较大的网站已经实施过，其中一个已经运行了4~5年，其中经历过无数次业务高峰的考验。
