一个程序员的喃喃自语
netperf 是围绕着基本的客户‐服务器模式设计的。主要有两个可执行部分：客户端程序netperf 和服务器端程序netserver.。netserver 可单独在一台机器上运行,也可与客户端程序netperf 在同一机器上运行。测试时，netperf 首先建立和远程系统的控制连接。该操作通过调用establish‐control(host‐name,test‐port)为测试打开一个使用相应协 议的端口.然后,根据测试者指定的测试类型,调用相应的函数(如测试TCP 流性能,则调用send‐tcp‐stream(hostname)函数)进行处理,并等待测试结果,当测试完成时显示测试结果,关闭连接,退出该次测 试。
服务器端运行的 netserver 是一个系统守护程序,它在一个指定的监听端口循环等待测试请求，当有测试请求时,进行初始化,读取测试的类型,调用相应的模块进行处理,并读取发送方和接 收方的套接字和消息大小以及此次测试所用的时间,计算出网络的吞吐量返回计算结果,然后继续等待下一轮测试。
在构建或管理一个网络系统时，我们更多的是关心网络的可用性，即网络是否连通，而对于其整体的性能往往考虑不多，或者即使考虑到性能的问题，但是却发现没有合适的手段去测试网络的性能。
当开发出一个网络应用程序后，我们会发现，在实际的网络环境使用中，网络应用程序的使用效果不是很理想，问题可能出现在程序的开发上面，也有可能由于实际的网络环境中存在着瓶颈。面对这种问题，程序员一般会一筹莫展，原因就在于不掌握一些网络性能测量的工具。
在本文中，首先介绍网络性能测量的一些基本概念和方法，然后结合 netperf 工具的使用，具体的讨论如何测试不同情况下的网络性能。
网络性能测试概述
网络性能测量的五项指标
测量网络性能的五项指标是：
•可用性（availability）
•响应时间（response time）
•网络利用率（network utilization）
•网络吞吐量（network throughput）
•网络带宽容量（network bandwidth capacity）
1． 可用性
测试网络性能的第一步是确定网络是否正常工作，最简单的方法是使用 ping 命令。通过向远端的机器发送 icmp echo request，并等待接收 icmp echo reply 来判断远端的机器是否连通，网络是否正常工作。
Ping 命令有非常丰富的命令选项，比如 -c 可以指定发送 echo request 的个数，-s 可以指定每次发送的 ping 包大小。
网络设备内部一般有多个缓冲池，不同的缓冲池使用不同的缓冲区大小，分别用来处理不同大小的分组（packet）。例如交换机中通常具有三种类型的 包缓冲：一类针对小的分组，一类针对中等大小的分组，还有一类针对大的分组。为了测试这样的网络设备，测试工具必须要具有发送不同大小分组的能力。 Ping 命令的 -s 就可以使用在这种场合。
2． 响应时间
Ping 命令的 echo request/reply 一次往返所花费时间就是响应时间。有很多因素会影响到响应时间，如网段的负荷，网络主机的负荷，广播风暴，工作不正常的网络设备等等。
在网络工作正常时，记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。
3． 网络利用率
网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，Ethernet 虽然是共享的，但同时却只能有一个报文在传输。因此在任一时刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
计算一个网段的网络利用率相对比较容易，但是确定一个网络的利用率就比较复杂。因此，网络测试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。
4． 网络吞吐量
网络吞吐量是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。
网络吞吐量可以帮组寻找网络路径中的瓶颈。比如，即使 client 和 server 都被分别连接到各自的 100M Ethernet 上，但是如果这两个 100M 的Ethernet 被 10M 的 Ethernet 连接起来，那么 10M 的 Ethernet 就是网络的瓶颈。
网络吞吐量非常依赖于当前的网络负载情况。因此，为了得到正确的网络吞吐量，最好在不同时间（一天中的不同时刻，或者一周中不同的天）分别进行测试，只有这样才能得到对网络吞吐量的全面认识。
有些网络应用程序在开发过程的测试中能够正常运行，但是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是因为测试只是在空闲的网络环境中，没有考虑到实际的网络环境中还存在着其它的各种网络流量。所以，网络吞吐量定义为剩余带宽是有实际意义的。
5． 网络带宽容量
与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。这是由组成网络的设备的能力所决定的。
测试网络带宽容量有两个困难之处：在网络存在其它网络流量的时候，如何得知网络的最大可用带宽；在测试过程中，如何对现有的网络流量不造成影响。网络测试工具一般采用 packet pairs 和 packet trains 技术来克服这样的困难。
收集网络性能数据的方式
当确定了网络性能的测试指标以后，就需要使用网络测试工具收集相应的性能数据，分别有三种从网络获取数据的方式：
1． 通过snmp协议直接到网络设备中获取，如net-snmp工具
2． 侦听相关的网络性能数据，典型的工具是tcpdump
3． 自行产生相应的测试数据，如本文中使用的netperf工具
——————————————————————————–
回页首
Netperf
Netperf是一种网络性能的测量工具，主要针对基于TCP或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即 批量数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统 发送数据，以及另外一个系统能够以多块的速度接收数据。
Netperf工具以client/server方式工作。server端是netserver，用来侦听来自client端的连接，client 端是netperf，用来向server发起网络测试。在client与server之间，首先建立一个控制连接，传递有关测试配置的信息，以及测试的结 果；在控制连接建立并传递了测试配置信息以后，client与server之间会再建立一个测试连接，用来来回传递着特殊的流量模式，以测试网络的性能。
TCP网络性能
由于TCP协议能够提供端到端的可靠传输，因此被大量的网络应用程序使用。但是，可靠性的建立是要付出代价的。TCP协议保证可靠性的措施，如建立并维护连接、控制数据有序的传递等都会消耗一定的网络带宽。
Netperf可以模拟三种不同的TCP流量模式：
1） 单个TCP连接，批量（bulk）传输大量数据
2） 单个TCP连接，client请求/server应答的交易（transaction）方式
3） 多个TCP连接，每个连接中一对请求/应答的交易方式
UDP网络性能
UDP没有建立连接的负担，但是UDP不能保证传输的可靠性，所以使用UDP的应用程序需要自行跟踪每个发出的分组，并重发丢失的分组。
Netperf可以模拟两种UDP的流量模式：
1） 从client到server的单向批量传输
2） 请求/应答的交易方式
由于UDP传输的不可靠性，在使用netperf时要确保发送的缓冲区大小不大于接收缓冲区大小，否则数据会丢失，netperf将给出错误的结果。因此，对于接收到分组的统计不一定准确，需要结合发送分组的统计综合得出结论。
Netperf的命令行参数
在unix系统中，可以直接运行可执行程序来启动netserver，也可以让inetd或xinetd来自动启动netserver。
当netserver在server端启动以后，就可以在client端运行netperf来测试网络的性能。netperf通过命令行参数来控制 测试的类型和具体的测试选项。根据作用范围的不同，netperf的命令行参数可以分为两大类：全局命令行参数、测试相关的局部参数，两者之间使用–分 隔：
netperf [global options]– [test-specific options]
这里我们只解释那些常用的命令行参数，其它的参数读者可以查询netperf的man手册。
-H host ：指定远端运行netserver的server IP地址。
-l testlen：指定测试的时间长度（秒）
-t testname：指定进行的测试类型，包括TCP_STREAM，UDP_STREAM，TCP_RR，TCP_CRR，UDP_RR，在下文中分别对它们说明。
在后面的测试中，netserver运行在192.168.0.28，server与client通过局域网连接（100M Hub）。
Netperf测试网络性能
测试批量（bulk）网络流量的性能
批量数据传输典型的例子有ftp和其它类似的网络应用（即一次传输整个文件）。根据使用传输协议的不同，批量数据传输又分为TCP批量传输和UDP批量传输。
1． TCP_STREAM
Netperf缺省情况下进行TCP批量传输，即-t TCP_STREAM。测试过程中，netperf向netserver发送批量的TCP数据分组，以确定数据传输过程中的吞吐量：
./netperf -H 192.168.0.28 -l 60
TCP STREAM TEST to 192.168.0.28
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.00 88.00 |
从netperf的结果输出中，我们可以知道以下的一些信息：
1） 远端系统（即server）使用大小为87380字节的socket接收缓冲
2） 本地系统（即client）使用大小为16384字节的socket发送缓冲
3） 向远端系统发送的测试分组大小为16384字节
4） 测试经历的时间为60秒
5） 吞吐量的测试结果为88Mbits/秒
在缺省情况下，netperf向发送的测试分组大小设置为本地系统所使用的socket发送缓冲大小。
TCP_STREAM方式下与测试相关的局部参数如下表所示：
参数 说明
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-m size 设置本地系统发送测试分组的大小
-M size 设置远端系统接收测试分组的大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项
通过修改以上的参数，并观察结果的变化，我们可以确定是什么因素影响了连接的吞吐量。例如，如果怀疑路由器由于缺乏足够的缓冲区空间，使得转发大的分组时存在问题，就可以增加测试分组（-m）的大小，以观察吞吐量的变化：
./netperf -H 192.168.0.28 -l 60 – -m 2048
TCP STREAM TEST to 192.168.0.28
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 2048 60.00 87.62 |
在这里，测试分组的大小减少到2048字节，而吞吐量却没有很大的变化（与前面例子中测试分组大小为16K字节相比）。相反，如果吞吐量有了较大的提升，则说明在网络中间的路由器确实存在缓冲区的问题。
2． UDP_STREAM
UDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是，此时测试分组的大小不得大于socket的发送与接收缓冲大小，否则netperf会报出错提示：
./netperf -t UDP_STREAM -H 192.168.0.28 -l 60
UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28
udp_send: data send error: Message too long
为了避免这样的情况，可以通过命令行参数限定测试分组的大小，或者增加socket的发送/接收缓冲大小。UDP_STREAM方式使用与TCP_STREAM方式相同的局部命令行参数，因此，这里可以使用-m来修改测试中使用分组的大小：
./netperf -t UDP_STREAM -H 192.168.0.28 – -m 1024
UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
65535 1024 9.99 114127 0 93.55
65535 9.99 114122 93.54 |
UDP_STREAM方式的结果中有两行测试数据，第一行显示的是本地系统的发送统计，这里的吞吐量表示netperf向本地socket发送分组的能力。但是，我们知道，UDP是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。
第二行显示的就是远端系统接收的情况，由于client与server直接连接在一起，而且网络中没有其它的流量，所以本地系统发送过去的分组几乎 都被远端系统正确的接收了，远端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是，在实际环境中，一般远端系统的socket缓冲大小不同于本地系统的 socket缓冲区大小，而且由于UDP协议的不可靠性，远端系统的接收吞吐量要远远小于发送出去的吞吐量。
测试请求/应答（request/response）网络流量的性能
另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易（transaction）中，client向server发出小的查询分组，server接收到请求，经处理后返回大的结果数据。如下图所示：
1． TCP_RR
TCP_RR方式的测试对象是多次TCP request和response的交易过程，但是它们发生在同一个TCP连接中，这种模式常常出现在数据库应用中。数据库的client程序与server程序建立一个TCP连接以后，就在这个连接中传送数据库的多次交易过程。
./netperf -t TCP_RR -H 192.168.0.28
TCP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 9502.73
16384 87380 |
Netperf输出的结果也是由两行组成。第一行显示本地系统的情况，第二行显示的是远端系统的信息。平均的交易率（transaction rate）为9502.73次/秒。注意到这里每次交易中的request和response分组的大小都为1个字节，不具有很大的实际意义。用户可以通 过测试相关的参数来改变request和response分组的大小，TCP_RR方式下的参数如下表所示：
参数 说明
-r req,resp 设置request和reponse分组的大小
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项
通过使用-r参数，我们可以进行更有实际意义的测试：
./netperf -t TCP_RR -H 192.168.0.28 – -r 32,1024
TCP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 32 1024 10.00 4945.97
16384 87380 |
从结果中可以看出，由于request/reponse分组的大小增加了，导致了交易率明显的下降。注：相对于实际的系统，这里交易率的计算没有充分考虑到交易过程中的应用程序处理时延，因此结果往往会高于实际情况。
2． TCP_CRR
与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP，每次HTTP交易是在一条单独的TCP连接中进行的。因此，由于需要不停地建立新的TCP连接，并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。
./netperf -t TCP_CRR -H 192.168.0.28
TCP Connect/Request/Response TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
131070 131070 1 1 9.99 2662.20
16384 87380 |
即使是使用一个字节的request/response分组，交易率也明显的降低了，只有2662.20次/秒。TCP_CRR使用与TCP_RR相同的局部参数。
3． UDP_RR
UDP_RR方式使用UDP分组进行request/response的交易过程。由于没有TCP连接所带来的负担，所以我们推测交易率一定会有相应的提升。
./netperf -t UDP_RR -H 192.168.0.28
UDP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
65535 65535 1 1 9.99 10141.16
65535 65535 |
结果证实了我们的推测，交易率为10141.16次/秒，高过TCP_RR的数值。不过，如果出现了相反的结果，即交易率反而降低了，也不需要担心，因为这说明了在网络中，路由器或其它的网络设备对UDP采用了与TCP不同的缓冲区空间和处理技术。
——————————————————————————–
结束语
除了netperf以外，还有很多其它的网络性能测试工具，如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。这些工具有其各自的特色和不同的侧重点，我们可以根据具体的应用环境，有选择的使用它们，这样就可以使这些工具发挥出最大的功效。虽然都是开 放源代码的软件，但是这些工具的功能与商业的网络测试工具同样强大，而且也得到了广泛的应用，熟悉这些工具对我们的实际工作一定会有很大的帮助。
启动防火墙
1) 重启后生效
开启： chkconfig iptables on
关闭： chkconfig iptables off
2) 即时生效，重启后失效
开启： service iptables start
关闭： service iptables stop
需要说明的是对于Linux下的其它服务都可以用以上命令执行开启和关闭操作。
在开启了防火墙时，做如下设置，开启相关端口。
修改/etc/sysconfig/iptables 文件，添加以下内容：
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
查看所有进程，包括服务，命令里ps -aux是netconfig在redhat里面是字符界面下的网卡配置工具。
chkconfig –list
可以列出sysV和xinet服务在各个runlevel的默认启动状态。
service 服务名 参数
查看状态的参数好像是status 吧。
自启动服务
【结束语】
什么是云计算？说白了，就是把一堆廉价PCs捆绑在一起，统一管理，使用起来如同一台超级大型机（Mainframe）一样。
与大型机相比，云计算平台不仅价格便宜，稳定性不差，而且便于不断扩张其计算能力和存储空间。
云计算的意义在于，
1. 让社会普遍获得超大规模的数据处理和存储能力。而过去，只有少数机构拥有这些能力。
【9】赚钱才是硬道理
本系列开篇时说到，Google开放云计算平台的目的是为了赚钱。接下去我们分析了云计算的功能以及技术实现。
现在终点回到起点，在我们了解了云计算的功能和技术以后，最后的问题是如何借用云计算平台赚钱？
黄 兄推荐了一篇参考文献，题目是“Cloud computing with Linux”（http://www.ibm.com/developerworks/linux/library/l-cloud-computing /index.html）。这个题目有点推销Linux的倾向，但是仔细看正文，发现这是一篇好文章。好在三个方面，
1. 它把云计算能够提供的服务分成了4类。各个服务层面针对需求不同的目标客户群。
2. 在这4类服务内，列举了各个参与竞争的公司。战场的形势一目了然。
3. 如果你想参与云计算，从中获利。仔细琢磨这篇文章，你将对自己的产品的定位有一个比较清晰的理解。
Cloud computing layers
Courtesy http://www.ibm.com/developerworks/linux/library/l-cloud-computing/figure4.gif
这篇文章把云计算的目标客户分成四类。从最底层说起，
1. Data-storage-as-a-Service（dSaas），说白了就是把云计算包装成一个巨大的网盘，客户想保存什么文件，不论是什么格式的，统统可以上传到这个网盘里。
云 计算的网盘有一个优势，是PC的硬盘无法媲美的。譬如，你在办公室里写了一个文件，晚上回家想接着写。文件存放在办公室的PC里，想调用这个文件，你先得 设置VPN，才能访问你办公室的PC，比较麻烦。如果你下班前，把文件上传到云计算的网盘里，你回家后想调用这份文件就容易得多。
如果把云计算和房地产开发相比较。盖了一栋空房子，没有装修，也没有通电通水通气，如何赚钱？最简单的办法是把空房子出租，给客户做仓库用。网盘就相当于仓库。
2. Infrastructure-as-a-Service（IaaS），是指提供计算能力，就像提供标准厂房，供电供水供气。
客户租用标准厂房，是为了组装一个生产车间。所以，客户光租了标准厂房还不够，他们还得自己动手，购置机器，雇用工人。
把云计算包装成IaaS，目标客户是动画制作商，数据挖掘商，天气预报局等等。他们编写自己的程序，自己负责运行和分析结果。之所以借助云计算IaaS服务，主要是借重云计算的平行计算的能力。
把云计算IaaS与标准厂房做个逐项类比，云计算的IaaS类似于标准厂房，天气预报局编写的程序就像是客户购置的机器，天气预报分析师就像是车间里的工人。
3. Platform-as-a-Service (PaaS)。类似于开发商盖了一栋商厦，里面分割成很多摊位，把摊位出租给各个小摊贩，卖衣服鞋帽等等。
PaaS针对的客户是各种传统行业的服务提供商，他们想建一个网站，开设网络商店，但是他们不太了解IT技术，他们开设网络商店所需要做的，基本上只是上传内容。
4. Software-as-a-Service (SaaS)。类似于开发商不仅建了房子，而且装修成酒店，聘用了酒店管理人员。
酒店面向是两类客户，1. 最终消费者，他们来酒店吃饭和住宿。2. 服务提供商，譬如婚庆代理公司，他们租用餐厅和客房，为新婚者承办婚宴。又譬如会议承办机构，他们利用酒店的会议室等等设施，代办各种会议。
SaaS也一样，它可以给企业提供ERP之类的服务，也可以给其它网站提供Gadgets，譬如地图指南，或者日历等等。
Amazon Web Service bandwidth
Courtesy http://aws.typepad.com/photos/uncategorized/2008/05/16/aws_bandwidth.gif
云计算的商务做得最好的，当属Amazon.com。
Amazon发轫于网络书店，后来业务扩展到卖电子产品，甚至服装，玩具，家具以及食品等等。再后来，Amazon不满足于零售业，而是想着开商厦，吸引各色摊贩借用Amazon的平台，营销各自的产品和提供各自的服务，而Amazon坐收摊位费。
尝到甜头后，Amazon干脆进军房地产，构建自己的云计算平台，提供相应的基础服务，犹如供电供水供气。所谓基础服务，严格定义不容易，但是举几个例子反而容易理解。
1. 系统整合类，
Amazon Simple Queue Service (SQS)，负责数据信息的交互。
Amazon Mechanical Turk (Mturk)，负责工作流程的组织。
Amazon Flexible Payments Service (FPS)，小额支付服务。
Amazon DevPay，记账和会计服务。
Amazon AWS，客户身份认证服务。
2. 统计类，
Alexa Web Services，流量分析。
Amazon Historical Pricing，查看历史记录。
AWS Management Console (AWS Console)，监控客户租用的计算资源的使用情况。
再来看看Google的情况。
Google 的抱负很大，dSaaS，IaaS，PaaS和SaaS，各个市场层面，它都想参与。但是奇怪的是，最容易做的网盘，即dSaaS业务，Google没有 开展。IaaS不容易找到客户，暂时也无可奈何。针对PaaS，也就是针对想建网站的那一批客户，Google的对策是AppEngine，但是受限于 AppEngine本身的不完善，目前似乎也没有吸引太多客户。Google做得最好的，是SaaS。不仅有Gmail，Google Docs，还有Maps，Picasa，YouTube，Orkut，Reader等等。
最后谈谈Microsoft的情况。
Microsoft的决心也很大。像Amazon，Yahoo，IBM等等企业，都在借用开源项目，如Hadoop，Xen等等，迅速构建自己的云计算平台，尽早占领市场。而Microsoft的战略是不用开源项目，从头构建自己的云计算平台，Azure。
Microsoft把自己的云称作“云端”。这个“端”字很有意思，强调的是Microsoft不仅有网络端的云计算平台，而且这个平台与各种Window OSes，以及Window OSes上各种终端产品紧密结合，形成大纵深的终端产品。
什么叫大纵深的终端产品？
Sina Music Box
Courtesy http://lh4.ggpht.com/_cz82pwdvhmg/SZWnlHyixeI/AAAAAAAAAYw/EusY1wBeFJY/s640/SinaMusicBox.PNG
拿新浪的音乐盒做个例子。它不仅仅是一个简单的MP3播放器，而且用户可以搜索音乐，音乐盒也可以根据用户以前听过的音乐，推荐音乐，用户还可以组建自己的专辑，在播放MP3的时候，音乐盒还搜索相应的歌词，配合着播放的节奏，滚动地显示歌词。
也就是说，用户电脑上显示的是终端播放器，但是提供搜索，推荐，专辑和歌词等等的各项功能，依托的是网络端的云计算平台。
如果Microsoft想大力拓展“云端”服务，或许新浪的音乐盒是一个很好的启发。
Linux 既有良好的灵活性，在虚拟化方面同样出色。但是最近，随着内核虚拟机（KVM）的出现，Linux 虚拟化的前景发生了变化。KVM 是构成主流 Linux 内核（V2.6.20）一部分的第一个虚拟化解决方案。KVM 支持 Linux 客户操作系统的虚拟化 —— 甚至支持其硬件对虚拟化敏感的 Windows 系统的虚拟化。了解 Linux KVM 的架构并了解它与内核的紧密集成为何会改变您使用 Linux 的方式。
简介
虚拟化 概念很早就已出现。简单来说，虚拟化就是使用某些程序，并使其看起来类似于其他程序的过程。将这个概念应用到计算机系统中可以让不同用户看到不同的单个系 统（例如，一台计算机可以同时运行 Linux 和 Microsoft Windows）。这通常称为全虚拟化（full virtualization）。
虚拟化也可以使用更加复杂的格式，其中单个计算机看上去具有多个架构（对于一个用户 来说，它是一个标准的 x86 平台；对于另外一个用户来说，它是 IBM Power PC 平台）。这种虚拟化形式通常被称为 硬件仿真。
最后，更加简单的一种虚拟化是操作系统虚拟化，其中一台计算机可以运行相同类型的多 个操作系统。这种虚拟化可以将一个操作系统的多个服务器隔离开来（这意味着全都必须使用相同类型和版本的操作系统）。
虚拟化和准虚拟化（para-virtualization）
虚拟化最常使用的两种方法是全虚拟化 和准虚拟化。使用全虚拟化，在虚拟化的操作系统和硬件之间存在一个层，用于决定访问。这个层称为系统管理程序 或虚拟机监视器（VMM）。准虚拟化与之类似，但是系统管理程序会以一种更具协作性的方式进行操作。这是因为每个客户操作系统都了解自己正在虚拟化模式中 运行，因此每个系统都与系统管理程序协作，来实现底层硬件的虚拟化。
全虚拟化的例子包括商业虚拟化解决方案 VMware，以及商业 IBM zSeries 计算机上使用的 IBM System z9 Virtual Machine（z/VM）操作系统。准虚拟化的例子有 Xen 和 User-Mode-Linux (UML)。 KVM 也被认为是一个全虚拟化解决方案，不过我们稍后再介绍这个问题。
虚拟化的工作原理
我们首先简要介绍一下虚拟化技术及其涉及的元素。虚拟化解决方案的底部是要进行虚拟 化的机器。这台机器可能直接支持虚拟化，也可能不会直接支持虚拟化；那 么就需要系统管理程序 层的支持。系统管理程序，或称为 VMM，可以看作是平台硬件和操作系统的抽象化。在某些情况中，这个系统管理程序就是一个操作系统；此时，它就称为主机操作系统，如 图 1 所示。
图 1. 虚拟化的分层抽象
系统管理程序之上是客户机操作系统，也称为虚拟机（VM）。这些 VM 都是一些相互隔离的操作系统，将底层硬件平台视为自己所有。但是实际上，是系统管理程序为它们制造了这种假象。
目前使用虚拟化解决方案的问题是，并非所有硬件都可以很好地支持虚拟化。较老的 x86 处理器根据执行范围对特定指令会产生不同结果。这就产生了一个问题，因为系统管理程序应该只能在一个最受保护的范围中执行。由于这个原因，诸如 VMWare 之类的虚拟化解决方案会提前扫描要执行的代码，从而将这些指令替换为一些陷阱指令（trap instruction），这样系统管理程序就可以正确地处理它们。Xen 可以支持一种协作的虚拟化方法，它不需要任何修改，因为客户机知道自己正在进行虚拟化，并已经进行了修改。KVM 会简单地忽略这个问题，如果您希望进行虚拟化，就强制必须在更新的硬件上运行。
刚开始会觉得这有些不方便，但是考虑到目前上市的较新机器都可以支持虚拟化（例如 Intel VT 和 AMD SVM），用不了多久，这将成为标准方法而不是少数例外情况。
KVM 系统管理程序
考虑到虚拟化技术的发展时间并不长，KVM 实际上还是一种相对来说比较新的技术。目前存在各具功能的开源技术，例如 Xen、Bochs、UML、Linux-VServer 和 coLinux，但是 KVM 目前正在被大量使用。另外，KVM 不再仅仅是一个全虚拟化解决方案，而将成为更大的解决方案的一部分。
KVM 所使用的方法是通过简单地加载内核模块而将 Linux 内核转换为一个系统管理程序。这个内核模块导出了一个名为 /dev/kvm 的设备，它可以启用内核的客户模式（除了传统的内核模式和用户模式）。有了 /dev/kvm 设备，VM 使自己的地址空间独立于内核或运行着的任何其他 VM 的地址空间。设备树（/dev）中的设备对于所有用户空间进程来说都是通用的。但是每个打开 /dev/kvm 的进程看到的是不同的映射（为了支持 VM 间的隔离）。
KVM 然后会简单地将 Linux 内核转换成一个系统管理程序（在安装 kvm 内核模块时）。由于标准 Linux 内核就是一个系统管理程序，因此它会从对标准内核的修改中获益良多（内存支持、调度程序等）。对这些 Linux 组件进行优化（例如 2.6 版本内核中的新 O(1) 调度程序）都可以让系统管理程序（主机操作系统）和 Linux 客户操作系统同时受益。但是 KVM 并不是第一个这样做的程序。UML 很久以前就将 Linux 内核转换成一个系统管理程序了。使用内核作为一个系统管理程序，您就可以启动其他操作系统，例如另一个 Linux 内核或 Windows 系统。
KVM
安装 KVM 之后，您可以在用户空间启动客户操作系统。每个客户操作系统都是主机操作系统（或系统管理程序）的一个单个进程。 图 2 提供了一个使用 KVM 进行虚拟化的视图。底部是能够进行虚拟化的硬件平台（目前指的是 Intel VT 或 AMD-SVM 处理器）。在裸硬件上运行的是系统管理程序（带有 KVM 模块的 Linux 内核）。这个系统管理程序与可以运行其他应用程序的普通 Linux 内核类似。但是这个内核也可以支持通过 kvm 工具加载的客户操作系统。最后，客户操作系统可以支持主机操作系统所支持的相同应用程序。
图 2. 使用 KVM 的虚拟化组件
记住 KVM 只是虚拟化解决方案的一部分。处理器直接提供了虚拟化支持（可以为多个操作系统虚拟化处理器）。内存可以通过 kvm 进行虚拟化（这在下一节中将会讨论）。最后，I/O 通过一个稍加修改的 QEMU 进程（执行每个客户操作系统进程的一个拷贝）进行虚拟化。
KVM 向 Linux 中引入了一种除现有的内核和用户模式之外的新进程模式。这种新模式就称为客户 模式，顾名思义，它用来执行客户操作系统代码（至少是一部分代码）。回想一下内核模式表示代码执行的特权模式，而用户模式则表示非特权模式（用于那些运行 在内核之外的程序）。根据运行内容和目的，执行模式可以针对不同的目的进行定义。客户模式的存在就是为了执行客户操作系统代码，但是只针对那些非 I/O 的代码。在客户模式中有两种标准模式，因此客户操作系统在客户模式中运行可以支持标准的内核，而在用户模式下运行则支持自己的内核和用户空间应用程序。客 户操作系统的用户模式可以用来执行 I/O 操作，这是单独进行管理的。
在客户操作系统上执行 I/O 的功能是由 QEMU 提供的。QEMU 是一个平台虚拟化解决方案，允许对一个完整的 PC 环境进行虚拟化（包括磁盘、图形适配器和网络设备）。客户操作系统所生成的任何 I/O 请求都会被中途截获，并重新发送到 QEMU 进程模拟的用户模式中。
KVM 通过 /dev/kvm 设备提供了内存虚拟化。每个客户操作系统都有自己的地址空间，并且是在实例化客户操作系统时映射的。映射给客户操作系统的物理内存实际上是映射给这个进程 的虚拟内存。为了支持客户物理地址到主机物理地址的转换，系统维护了一组影子页表（shadow page table）。处理器也可以通过在访问未经映射的内存位置时使用系统管理程序（主机内核）来支持内存转换进程。
实例化新客户操作系统
新客户操作系统的实例化是由一个名为 kvm 的工具提供的。这个工具可以与 kvm 模块协同工作，使用 /dev/kvm 来加载客户操作系统，将它与虚拟磁盘（主机操作系统中的一个普通文件）关联起来，然后启动客户操作系统。
通过一组在 /dev/kvm 设备上执行的 ioctls 可以提供控制支持。当第一次打开这个特殊文件时，就会创建一个新的 VM 对象，它与一个虚拟 CPU 关联在一起。您然后可以使用几个 ioctls 来创建一个虚拟 CPU，检查 kvm 版本，创建内存区域，然后启动一个虚拟 CPU。您可以使用 kvm 命令实现这种功能。在接下来的几节中，我们将介绍 kvm 命令，并给出几个受支持的 ioctls 的示例。
使用 KVM
如果硬件支持的话，使用 KVM 实际上非常简单。您需要一个具有虚拟化支持的处理器。通过查看 /proc/cpuinfo 可以知道系统是否支持虚拟化。这个文件指定了是否支持 vmx（Intel）或 svm（AMD）扩展。
接下来，您需要一个启用了 KVM 支持的 Linux 内核。您可以在 Device Drivers > Virtualization 下的内核配置中完成这种配置。还必须启用处理器对环境的支持。另外，还必须具有 kvm 和 qemu 用户空间应用程序。
有了启用了虚拟化支持的引导内核，接下来的一个步骤是为客户操作系统创建一个磁盘映 像。您可以使用 qeumu-img 来完成此操作，如下所示。注意这个映像的大小是 4GB，但是使用 QEMU 的写时复制格式（copy-on-write，qcow）时，整个文件将根据需要增长，而不是完全占据这 4 GB 的空间。 $ qemu-img create -f qcow vm-disk.img 4G
复制代码在创建虚拟磁盘之后，就可以将客户操作系统加载到其上。下面的例子假设客户 操作系统是在 CD-ROM 上。除了使用 CD-ROM ISO 映像来填充虚拟磁盘之外，还必须在结束时启动这个映像。 $ kvm -no-acpi -m 384 -cdrom guestos.iso -hda vm-disk.img -boot d
复制代码Ari Kivity 已经编写了一组测试工具来测试 KVM，而不需要全部的设备模型。下面的代码片断（来自于 kvm-12/user/main.c）从较高的层次上查看了 VM 的启动（请参见 清单 1）。控制特性是由内核中的 ioctls 提供的（具体来说，在 ./linux-2.6.20/drivers/kvm/kvm_main.c 文件中）。
对 kvm_init 的调用会打开 /dev/kvm 设备，检查版本号（由 KVM 内核模块导出），然后分配一个 KVM 上下文对象并填充一些回调函数。kvm_create 函数会建立并映射两个内存区域，然后使用 ioctl（KVM_CREATE_VCPU）创建一个虚拟 CPU（VCPU）。
load_file 函数然后会将映像加载到给定的 VM 的地址空间中，然后调用 kvm_run 执行该 VM（使用 ioctl KVM_RUN）。尽管这个过程非常简单，但是它解释了如何使用 KVM 实例化新客户操作系统。
清单 1. 测试 KVM 系统管理程序的应用程序片断 int main()
{
void *vm_mem;
kvm = kvm_init(&test_callbacks, 0);
if (!kvm) {
fprintf(stderr, “kvm_init failedn”);
return 1;
}
if (kvm_create(kvm, 128 * 1024 * 1024, &vm_mem) < 0) { kvm_finalize(kvm); fprintf(stderr, “kvm_create failedn”); return 1; } if (ac > 1)
if (strcmp(av[1], “-32”) != 0)
load_file(vm_mem + 0xf0000, av[1]);
else
enter_32(kvm);
if (ac > 2)
load_file(vm_mem + 0x100000, av[2]);
kvm_show_regs(kvm, 0);
kvm_run(kvm, 0);
return 0;
}
KVM 是解决虚拟化问题的一个有趣的解决方案，但是由于它是第一个进入内核的虚拟化解决方案，很难想象它会很快用于服务器虚拟化。还有其他一些方法一直在为进入 内核而竞争（例如 UML 和 Xen），但是由于 KVM 需要的修改较少，并且可以将标准内核转换成一个系统管理程序，因此它的优势不言而喻。
KVM 的另外一个优点是它是内核本身的一部分，因此可以利用内核的优化和改进。与其他独立的系统管理程序解决方案相比，这种方法是一种不会过时的技术。KVM 两个最大的缺点是需要较新的能够支持虚拟化的处理器，以及一个用户空间的 QEMU 进程来提供 I/O 虚拟化。但是不论好坏，KVM 位于内核中，这对于现有解决方案来说是一个巨大的飞跃。
转自http://daimajishu.iteye.com/blog/1081267
twitter或豆瓣用户一定会发现，有时候，在别的网站，点登录后转到 twitter登录，之后转回原网站，你会发现你已经登录此网站了，比如像 feedtwitterrss2twitter推特中文圈（这个目前好像有点问题转回来的时候是个错误地址）这种网站就是这个效果。其实这都是拜 OAuth所赐。
OAuth是一个开放的认证协议，让你可以在Web或桌面程序中使用简单而标准的，安全的API认证。
网络开放是一个不变的趋势，那么不可避免的会有各种网络服务间分享内容的需要。
举个我们身边国内的例子吧：比如人人网想要调用QQ邮箱的联系人列表，现在的方法是你需要在人人网输入你的QQ号，QQ密码才能调用，虽然网站上可能都自谓“不保留QQ用户名密码”，但是大家信吗？
OAuth就是为了解决这个问题而诞生的，用户访问第三方资源，不再需要网站提交你的用户名，密码。这样好处自己是安全，而且不会泄露你的隐私给不信任的一方。
OAuth中有三方：一，用户；二，Consumer（不知杂翻译，类似上面的 twitterfeed 角色）；三，服务提供商（如上例的twitter角色）。
可得到：Consumer Key，Consumer Secret。twitter申请oauth的话，在 setting – connection – developer 里面申请。 同时给出三个访问网址：
Consumer需要先取得 请求另牌（Request Token）。网址为上面的 request_token_url，参数为：
这样 Consumer就取得了 请求另牌（包括另牌名 oauth_token，另牌密钥 oauth_token_secret。
网址为authorize_url?oauth_token=请求另牌名
那么会自动转回上面的 oauth_callback 里定义的网址。同时加上 oauth_token （就是请求另牌），及oauth_verifier（验证码）。
NO。现在还需要再向 服务提供商 请求 访问另牌（Access Token）。网址为上面的access_token_url，参数为：
这样就可以取得 访问另牌（包括Access Token 及 Access Token Secret）。这个就是需要保存在 Consumer上面的信息（没有你的真实用户名，密码，安全吧！）
Consumer就可以作为用户的身份访问 服务提供商上被保护的资源了。提交的参数如下：
OAuth 使用的签名加密方法有 HMAC-SHA1,RSA-SHA1 （可以自定义）。拿 HMAC-SHA1 来说吧，HMAC-SHA1这种加密码方法，可以使用 私钥 来加密 要在网络上传输的数据，而这个私钥只有 Consumer及服务提供商知道，试图攻击的人即使得到传输在网络上的字符串，没有 私钥 也是白搭。
私钥是：consumer secret&token secret （哈两个密码加一起）
要加密的字符串是：除oauth_signature 外的其它要传输的数据。按参数名字符排列，如果一样，则按 内容排。如：domain=kejibo.com&oauth_consumer_key=XYZ& word=welcome………………….
前面提的加密里面都是固定的字符串，那么攻击者岂不是直接可以偷取使用吗？
不，oauth_timestamp，oauth_nonce。这两个是变化的。而且服务器会验证一个 nonce（混淆码）是否已经被使用。
那么这样攻击者就无法自已生成 签名，或者偷你的签名来使用了。
【8】云中说禅
云计算是一个大买卖，各大公司不会眼睁睁看着Google吃独食。IBM，Yahoo，Amazon，Microsoft等等相继跟进，都在宣传自己的云计算方案。
Google 致力于云计算研究与实践，已经有十年了，技术积累厚实，说话底气足。其它公司嚷嚷归嚷嚷，总得拿出点真材实料，否则靠什么争取客户？从头开始研究开发当然是来不及了，于是IBM也好，Yahoo也好，Amazon也好，纷纷借Open Source的Hadoop，作为自己切入云计算市场的基石。
看一看IBM的Blue Cloud方案，以及Amazon的EC2方案，除了Hadoop以外，它们还用到了另一个开源软件，Xen。Xen是Zen的异体词，Zen的意思是禅。
计算机技术和禅有什么关系？
看看Lucent公司的Logo。第一次见到这个logo的时候，不解。请教老美，老美很吃惊，说，“这是禅啊，你们东方的东西。”
这个用毛笔画出来的圆圈，英文名字叫Enso。这个符号来自日本，通常被当作禅的标记。凭心而论，日本在世界范围内弘扬东方文化，是做了很大贡献的。譬如西方人对禅的了解，主要来自于日本的推介。
2003年，剑桥大学计算技术实验室的几个人在合写一篇论文，文章写得差不多了，但是还缺一个标题。其中一位开玩笑地建议到，“要么就叫Zen and the Art of CPU Cycle Maintenance吧”。众人大悦。
最后论文定名为“Xen and the Art of Virtualization”。同时，把整个项目定名为Xen。 Xen是做什么的？
用一句话来概括，Xen的目标，是如何在一台计算机的硬件上，同时运行多个OS。什么情况下需要在同一台计算机上同时运行多个OS？
举个例子，现在电脑病毒日益猖獗。纵然有卡巴斯基等等解药，但是道高一尺魔高一丈，病毒屡禁不止，而且毒性越来越烈，常常危及整个OS。
有人出了一个主意，在同一台电脑的硬件上，同时运行多个OS，把一些基本的应用放在一个OS上，其它的应用留在其它OS上。用户切换OS的方式，犹如切换窗口一样。如果一些应用染上了病毒，最多把该应用所在的OS重装，而不至于影响其它OS，尤其是不必担心硬盘上重要的文件遭到破坏。
为什么Xen与云计算有关？
在云计算平台上运行的程序，来自不同的客户。不能保证这些客户程序没有bugs，也不能杜绝恶意的破坏性程序。如何保证一个客户的程序，不至于破坏其它客户的程序运行，不至于损坏其它客户的文件？
最简单的办法是给不同的客户分配不同的机器，井水不犯河水。但是这样的做法不能高效率地使用资源。美国客户的高峰时段，恰巧是中国客户的夜间休息时段。如果分别给美国中国客户分配不同机器，美国高峰时段，美国客户的机器忙不过来，而中国客户的机器却在闲置。
所以最理想的做法，是让不同客户共享计算机硬件，但是各自拥有各自的OS。这样，既高效地使用硬件资源，又保证井水不犯河水。
Xen提供了实现这一目标的技术解决方案，所以借着云计算的东风，Xen大热。
The structure of a machine running the Xen, hosting a number of different guest OSes. Courtesy http://www.freesoftwaremagazine.com/files/www.freesoftwaremagazine.com/nodes/1159/slide2.jpg
上图描述的是Xen的体系结构。最底层的是计算机硬件，包括CPU，RAM，硬盘接口，网卡，外设数据总线等等。
硬件层之上，是Xen hypervisor层，包括总控界面（Xen Control Interface），虚拟CPU，虚拟RAM，虚拟硬盘，虚拟网卡等等。
在 Xen层之上，是各个OS实例（OS instances）。其中最左边的OS实例很特别。在启动Xen的时候，最左边的OS实例，Domain0 on XenoLinux，自动被启动。Domain0里运行着Xen Control Software，这个软件控制着各个OS实例的启动，终止，以及监控其运行情况。
Domain0对于其它OS实例的控制，是通过Xen层中Xen Control Interface来实现的。而这个Xen Control Interface只对Domain0开放。其它OS实例只有被管理的义务，而没有管理其它实例的权力。
每个OS实例都被分配一套虚拟的CPU，RAM，硬盘和网卡。每个OS实例使用这些虚拟的设备，与通常的OS并无不同。
多 个OS实例共享CPU的实现，是通过两套机制来完成。当多个OS实例请求使用CPU，这些请求被放置在hypercall队列里。Xen hypervisor根据预先设定的优先级政策，在hypercall队列里挑选出下一个被执行的请求。请求被处理完了以后，Xen通过异步的事件响应机制（async event-callback handler），把结果反馈给相应的OS实例。所谓虚拟CPU，说白了就是这两套机制的interface APIs。
在启动一个新的 OS实例的时候，Domain0会给它分配一部份RAM。如果实际运行中，需要更多的RAM，Domain0会增加这个OS实例的配额，直至最高上限。各个OS实例都有自己的RAM区域，彼此不相互干扰。从每个OS实例的眼中看，似乎自己的RAM区域在物理上位于相邻区域。但是事实上不是这样。这种善意的欺骗归功于虚拟RAM。虚拟RAM不仅记录着物理RAM的分配和使用，而且负责地址的翻译等等工作。
至于Disk IO和Network IO的读写请求，被放置在一个环状队列中，通过Consumer-Producer锁机制进行异步操作。
每个OS实例配备着一个虚拟硬盘，这个虚拟硬盘记录着每个OS实例所占用的物理硬盘的空间。每个OS实例只能看到分配给自己的硬盘空间，而不能看到其它OS实例的硬盘里的文件。而Domain0是例外，它能够看到整个硬盘系统中所有文件。
Xen的详细描述和分析，可以读前面提到的那篇论文，“Xen and the Art of Virtualization”，http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf。
Xen开源软件的下载，可以去Xen网站寻找。http://www.xen.org/
VMWare infrastructure Courtesy http://www.topgreat.com.tw/WebMaster/uploads/images/1_images/l_070508152747.jpg
Xen 并不是横空出世的新创意。计算机界往往出现工业界领先于学术界的局面，Virtualization技术就是这样一个例子。早在1998年，硅谷Palo Alto出现了一家公司，最早实现了多个OS共享一台计算机的设想。这家公司的名字叫VMWare，现在卖给了EMC。 http://www.vmware.com
Xen与VMWare在技术上有很大相似之处。从Xen的论文看，Xen的技术似乎比VMWare有更多优势。但是从产品系列的完整，以及多年来的实际运行经验来看，VMWare似乎能够提供用户更可靠的稳定性和售后服务。
【7】天上究竟会有几朵云？
上一章长篇大论地讨论，云计算是否能够提供有效的加密措施，保障客户的内容以及程序，不被云计算平台的拥有者偷窥。
我们的结论是悲观的。
既然云计算平台无法提供有效的加密措施，那么云计算平台只能吸引那些对于自己的内容和程序的保密不那么敏感的企业。
但是大型企业，包括银行和电信，它们对云计算能够提供的超大规模存储能力，以及超大规模并行数据处理的能力，有天然的需求。
怎么办？
现实的解决办法是帮助大型企业建设属于它们自己的云计算平台。
换而言之，未来的天空中，将漂浮着Google和Microsoft几朵云，这是几朵大云。在大云的周围，散落着一些小云。
如何构建云计算平台？
说来也不很神秘。云计算平台的基本思想，可以简单概括为，设计一套操作系统，同时管理多台电脑，尤其是把多台电脑结合起来，当一台超级电脑使用。
想深入了解云计算技术，以下论文是不能不看的。
1. Google File System: http://research.google.com/archive/gfs-sosp2003.pdf
把多个电脑的硬盘组合起来，形成一个超大规模的硬盘，用来存储海量数据，同时保障万一有某些硬盘崩溃了，不至于遗祸整个系统。
2. MapReduce: http://labs.google.com/papers/mapreduce-osdi04.pdf
如何实现并行计算。道理很简单，但是用好却不容易。下面两篇论文，可以作为范例，指导如何正确使用MapReduce。
3. Chubby lock service: http://research.google.com/archive/chubby-osdi06.pdf
电脑操作经常要用到锁机制，譬如用锁防止两个进程同时向同一个文件写数据。这篇论文谈的是，在由多台电脑组成的分布式系统中，集中管理锁的机制。
4. BigTable: http://research.google.com/archive/bigtable-osdi06.pdf
这篇文章既是讲如何实现分布式数据库，同时也可以把它看成范例，如何正确使用Chubby锁机制，和GFS文件系统。
5. The Google cluster architecture: http://www.computer.org/micro/mi2003/m2022.pdf
各个组成部分完成以后，如何组建一个计算中心。这是这篇文章的主题。
Google式云计算平台有两大特色，
1. 便宜。即使用几台穷人买得起的烂PC，也能构建一个麻雀虽小但是五脏俱全的Google式云计算平台。其实，Google自己就是这么起家的。
2. 稳定。便宜的机器经常死机。Google式云计算平台，能保证一部份机器死机不会造成整个系统的崩溃。
A cluster consisting of many cheap PCs Courtesy http://www.inria.fr/actualites/inedit/images/inedit29_parta.fr.jpg
以前CMU有个教授，说过这么一段话，大意是：遇到一篇以前没有读过的论文，最好先蹲在厕所里翻翻。很多论文无病呻吟，或者装神弄鬼。对待这样的论文，处理的办法是立刻冲掉。不幸的是，大多数论文都可以这样处理。
后来，这段话被记者捅了出去。系主任不得以，不仅公开道歉，而且内部通报批评该教授，不该说这种politically incorrect的话。但是暗地里，很多师生都非常认同教授的看法。
前面几篇文章，不仅不能被冲掉，而且值得反复读，再三读。读完这些论文，你一定会对这两个人感到亲切，Jeffrey Dean和Sanjay Ghemawat。
如 果说Google的两位创始人Larry Page和Sergey Brin确定了Google搜索引擎的算法和数据结构，那么奠定了Google后台的集群系统，也就是我们今天耳熟能详的Google云计算平台，就是 Jeffrey Dean 和Sanjay Ghemawat这两位。
Jeffrey Dean, Ph.D Courtesy http://research.google.com/people/jeff/jeff.jpg
Sanjay Ghemawat, Ph.D Courtesy http://research.google.com/people/sanjay/sanjay.jpg
但是，只读这么几篇论文是不是就足够了呢？
No!
对比一下传统的单机的操作系统，如果把GFS理解为云计算版的文件系统，把MapReduce理解为云计算版的进程管理，把Chubby理解为云计算版的synchronization。
缺了什么？
1. Memory management。2. Scheduling。
为什么不列举这两个方面的论文，方便大家阅读？
因为Google没有发表。或许是Google把这两个方面的技术，视为Google云计算的核心机密，所以才没有发表论文公开介绍。
读完论文后，想构建一个云计算平台，是不是必须写程序，从头实现？
No!
Hadoop是一个开源项目，把前面提到的几个Google式云计算技术，用Java实现了。
我们不妨站在Hadoop台阶上，把未尽的事业推向前进。前进方向，
1. Memory management。2. Scheduling。
如何参与开源项目
1、从Google Code svn上下载源代码
2、maven 导入项目
找到你感兴趣的点来入手，然后就来社区上混就可以了，否则只是看文档什么的其实是很无聊的。但是有一点要注意，在问问题的时候一定要经过思考，而不是一有问题就马上发问。我也经常会看见这样的问题，但是如果你有更好的建议，或者你能说出功能上哪些地方有问题，你就可以把想法写出来，甚至是把代码写出来，这样就会收到有效的反馈。甚至你的英文不太好，都不是什么问题。只要你肯持之以恒、足够勤奋就可以了。还有一点就是要积极地回答问题。只要掌握这三点，其实一个普通程度的人就可以启动了。知识改变命运，想通过开源项目获取知识，只要你愿意，地球上没有人能阻挡你。 在这里不拼爹，不拼公司背景，拼的是对技术追求的那颗心。