分类归档: Arch

云计算中的存储

这是去年发在《程序员》杂志的一篇文章。当时写得比较急,现在看起来,有些观点有些武断。仅供参考。

引言, “The one that is without any tradeoff is to have the logical storage master up in the cloud” by Bill Gates.

2008 年的 IT 界,云计算是个热词。很多企业都在宣称自己提供云计算服务,很多人也都在讨论云计算(一些明显是凑热闹的,比如所谓的”云安全”),从业界公认的几种云计算的服务能力看,都绕不开存储这个基础支撑组件,dSaaS(data-Storage-as-a-Service) 更是把存储提到了首要的位置。而从我们目前能得到的信息来看,在存储层已经解决很好的,恐怕也只有 Google 和 Amazon 两家,至于其他公司可能都还在路上,即使是微软,尽管也有自己的 Dryad ,但是实际上,仍然处于理论阶段,产品化的路还有点距离。

Cloud_Computing_level.png

上面表格中的举例仅仅是为了举例,如果某家已经 “云计算了” 的公司大名不在上面,并非该公司”云”的不够彻底,应该只是笔者眼光差的原因而已。

越来越迫切的信息存储需求

根据 EMC 公司赞助 IDC 进行的研究计划 “Digital Universe” 的分析报告,在整个 2007 年,我们这个世界生成、占用的数字信息及复制总量大约是 281 Exabytes (1 Exabytes=1024 Petabytes ,1 Petabytes = 1024 TB 这里换算都按照二进制的换算),这个数据平摊到地球上的所有人,大约是每个人 45 GB的数据;截至到笔者写稿的时候,2008年到现在整个世界已经生成了大约 374 EB 的数据(可以到 “Digital Universe” 页面查看最新的数据,也可以下载一个评估工具,看看自己产生的数据是大约如何);到 2011 年,每年产生的数字信息大约是 1800 EB,10倍于2006 年产生的信息量。做为对比,Google 每天处理的数据大约是 20 PB 的样子,Google 的目标是要组织所有的信息,看来并非易事。

其他可参考数据:据美国国家档案馆工作人员估计,布什政府电子档案存储量大约为1亿GB,这一数字约为前总统克林顿两届政府档案总量的50倍,是国会图书馆2000万册编目图书内容总量的5倍。

每年激增如此庞大的信息量,加上已有的历史数据信息,对整个业界的数据存储、处理带来了很大的机遇与挑战。通过该研究能看出,在可用存储之间与信息生成总量之间不是严格匹配的,一方面多媒体领域信息增长过快,一方面因为不合理的存储分配、占用情形比比皆是。例如研究表明一封大约 1M 的邮件发出后,经过不同服务器的存储、备份、归档等最后总体占用空间竟然达到惊人的 50M 之多。正如云计算的初衷是为了充分发挥计算机闲置资源,提高总体使用率以便达到经济效益,云计算中的存储方面也应该能有效提高存储利用率而进一步创造价值,盲目的复制、堆积数据是没有出路的。工业界提倡节能减排,其实 IT 界应该提倡一下节约存储了。

什么是云存储 ?

其实,什么是云计算都很难有一个权威的定义,笔者在这里更愿意把”云计算中涉及的存储”简称为云存储(Cloud Storage)。云存储本身离不开云计算,更多的时候云存储是做为云计算的一个支撑组件。

云存储不是简单的在线存储或是网络硬盘,在线存储服务只是云存储能够提供的众多服务中的一种而已。

云存储的特点

云存储至少应该能够具备如下特点:

  • 高可靠性
  • 谈到存储,可靠性还是要排到第一位的。没有人喜欢买三天两头坏掉的硬盘,代表高科技形象的云存储可靠性也要加强。

  • 高可用性
  • 如果云存储服务不是针对在线用户的,那么没有什么实际意义,如果针对在线用户,不具备足够高的可用性也是没有意义的。Amazon 的 S3 服务给足够多的 Web 2.0 企业解放了在硬件存储上的压力,但是偶然的一次宕机会影响所有的 Web 2.0 用户;

  • 低成本
  • 云存储本质上还是规模化经济。如果成本不能有效的控制,那么云存储对厂家、对用户来说是没有意义的;

  • 高扩展性
  • 云存储组件应该具有足够高的扩展性,应该能够通过在线扩充存储单元进行有效的平滑线性扩展;

  • 自动容错能力
  • 因为低成本的,存储组件的损耗率应该很高,云存储厂商应该能在软件层做到自动容错而不是依赖硬件本身的容错;

  • 易管理性
  • 构建云存储系统,可管理性应该在设计之初就要考虑到,如果管理太复杂,很难做到低成本,稳定性、可靠性也会受到挑战。

  • 去中心化
  • 对元数据的管理不应该通过少数或者单一的管理节点来操作或者存储。

云存储的关键技术与服务形式

要建设成功的云存储系统,高扩展性、高可靠性的分布式文件系统是一个关键因素。而硬件问题反而是次要的。

cloud_storage.png

云存储的服务形式见上表。

未完待续…

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

面向用户的网站性能优化

在互联网这个行业,”以用户为中心的设计“已经达成共识,但很少听到有人说”以用户为中心进行性能优化”之类的话,很多时候,网站性能优化是面向服务器来进行,或许,应该扭转一点思维,改到考虑如何面向用户进行网站性能优化的时候了。

优化的目的

为什么要做优化? 不外乎如下几种原因:

  • 节省资源,服务器、网络资源;
  • 消除或者减少系统瓶颈;
  • 提升用户体验

多数公司做优化都是从前两者出发,而”提升用户体验”虽然是从用户(网站访问者)角度出发,但却很少提升到非常重要的高度。

此外,或许也有炫技的因素在内,为了优化而优化,当然这是不可取的做法。

建立有效的度量

有效的优化方式前提是要能有有效的度量。一个用户访问网站,从 提交请求到得到响应,完整看到页面,中间的每个环节都应该确保优化得当。否则如果后端已经”完美”优化,单用户请求的页面有 N 多大图片,也是个糟糕的事情。在没有建立端到端的度量数据收集之前,很可能存在较大偏差。

end2end_web.png
(图Refer)

一些常见的问题是,您知道访问自己站点的用户在使用什么样的线路? 什么样的 ADSL 线路,有多少还在用拨号上网? 在网吧上网的用户有多少? 多少是移动设备用户? … 如果此类数据收集有所欠缺,也很难做出有效的性能度量。

一些优化的错误认识

服务器压力降低 = 用户访问速度快 这是最常见的一种优化态度。技术人员对自己的网站用尽了各种优化手段,服务器压力终于降低了,单用户会真的满意么? 未必。但如果从没观察过终端用户的访问习惯和网络连接方式能客观因素,也是徒劳。

前端优化不如后端优化重要 前端优化仍然没有受到应有的重视,仍有多数设计者对性能问题熟视无睹,随手弄个 1M 大小的活动页面对他们来说,图片设计是否华丽可能才最重要。对于越来越需要多媒体、富媒体表现的页面来说,前端优化其实是重中之重。两手抓,两手都要硬。用户访问费劲的页面,再华丽也是垃圾。

节省 PV = 减少 PV 以 KPI 为导向的 Web 公司中,PageView 可能是很多人的饭碗,轻易不要太岁头上动土。不过对于 KPI 制定者来说,起码要具备如何识别虚假繁荣的 PV (除非也是作弊团伙成员)。不必要的 PV 能节省就节省,节余的带宽资源留给更有价值的应用。

把优化作为项目来做 有些网站会有”起个项目对某某块做个优化”之类的事儿。优化应该是个长期、持续的事情,如果单纯的作为项目来做,可能一波热乎劲儿过去就没人管了。

–未完待续–

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

MySpace 系统架构

在前不久结束的 QCon 2008 上,MySpace 的首席架构师 Dan Farino 做了题为 Behind the Scenes at MySpace.com (PDF 下载)的技术演讲。

架构概况

超过 4,500 台 Web 服务器,配置为 Windows 2003/IIS 6.0/ASP.NET ;超过 1200 台 Cache 服务器,64 位的 Windows 2003,超过 500 台的数据库服务器,配置为 64 位的 Windows 2003,数据库为 SQL Server 2005 。

之前曾有一篇 揭秘 MySpace 架构的文章,也有中文版本《亿万用户网站MySpace的成功秘密》,请 Google 之!

运维数据收集

其实这个演讲我感觉主要讲的是这个数据收集模块 :) MySpace 的方案倒是让我们看到了在超大规模的 Windows 环境下如何进行数据收集的。

MySpace_OPS.png

每个客户端通过一个 TCP 连接到收集上服务器。收集的信息包括:Windows 性能计数器 Performance Counters、 WMI 对象(定制后的 WMI 对象)、事件日志、 硬件数据等等。收集器服务(Agent) 用 C#实现的,完全的异步 I/O,用了微软的 Concurrency and Coordination Runtime 库。每台主机上一个 Agent。其实国内也有超大规模的 Windows 环境 — 比如盛大,数据采集和监控的机制倒是类似的。

数据协议用的 Google 的 Protocol buffers。这倒是看到 Google 的这玩意儿公开后第一家大站点在用。也是因为用 Protocol buffers 从而不用 XMPP+ejabberd 的消息处理方案。

QCon 是我非常心仪的技术会议。可惜今年因为客观原因没能组织同事去参加。期待 2009 年在伦敦的会议。

EOF

延伸阅读:InfoQ 对 DanFarino 的专访

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

Facebook 的 Memcached 扩展经验

周末的时候看到这篇 Scaling memcached at Facebook,感觉挺有料。但似乎又没什么可写的。最多就是准翻译一下。

相比之前介绍过的数据( 5TB数据/400台服务器).,现在 Facebook 在 Memcached 上的内容已经超过 28TB,总服务器数量超过 800 台。可见硬件降价真是够快的,内存的确便宜得很。

Facebook 作出改进的第一个问题是 Apache (连接带来的)进程连接开销问题。实现了一个针对 TCP/UDP 的共享的进程连接缓冲池。共享的方式比针对单连接独占内存的方式节省不少内存资源。考虑到一共有 800 台乃至更多的服务器,总体节省的内存资源是惊人的。

第二个改进是 UDP 模式的效率问题。第三个改进是网络中断给 CPU 带来的影响,这个我觉得就是变相的实现了 Intel I/OAT 的某些功能。补充一句,网络中断的问题其实是给很多企图制造山寨存储的技术人员一个拦路虎。

最后一个问题是在 8 核芯片上发现的新瓶颈。这个问题我想对于在多核机器上跑 MySQL 也会有很大借鉴作用。CPU 不是越多越好。有些开源软件与硬件的配合上面应该的确稍微滞后(不是落后)一点。

四个大的改进的结果是从 50, 000 /s 的 UDP 请求到 300,000 /s 的 UDP 请求支撑能力,延迟只有 173 微秒。

Facebook 的技术还是挺开放的。这一点上比 Google 强多了。

EOF

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