主题:【原创】云里雾里的云计算 [1] -- 邓侃
server的负载。而且大部分时候,只能比较好地做Http request的转发(Linux都是集成在kernel里面了)。而老邓说的是对不同应用的负载的均衡。并且并不一定都是用http提供服务。实验和研究证明,对于kernel级别的tcp socket的负载均衡效能还不理想。接下去就谈深了,就此打住
譬如后台有两个功能,F1,F2。假如现在各自有个machine farms。MF1的每台机器只运行F1,而MF2的机器只运行F2。
即便加了loadbalancer,F1的请求只能发到MF1的某一台机器上去。但是如果MF1里面所有机器都忙不开了呢?在这种情况下,loadbalancer也没办法。
怎么办?
把MF1和MF2合并,每台机器上即跑F1,也跑F2。
但是如果F1有bugs,导致死机,会不会影响到F2?
当然会。怎么办?
Virtualization。在同一台机器的硬件上,跑两套OSes,OS1里面只跑F1,OS2里面只跑F2。F1的bug,导致OS1崩溃,但是不会影响F2/OS2。
后端就是一个application server pool。
极端的做法,就是每个server上装全应用软件。
m个物理server,n个应用,就是门m*n个虚拟应用服务器。
整个的调度,都可以交给load balancer的。
1。浪费资源
2。前面说了,非http服务器,现有的load balancer调度效率低。(IBM有个研究,对于普通tcp socket,在kernel里面采用半连接来作负载均衡,但还不成熟并且部署困难)
3。很多时候,load balancer成了瓶颈。我们公司的load balancer就有一次memory leak,导致网络瘫痪
当然,load balancer是必须的,但是不是万能的。具体情况具体处理
Q1:即便加了loadbalancer,F1的请求只能发到MF1的某一台机器上去。但是如果MF1里面所有机器都忙不开了呢?在这种情况下,loadbalancer也没办法。
A1:这是当然,你这么设的嘛,MF2想帮忙也帮不上啊。但server利用率已经提高了。
Q2:把MF1和MF2合并,每台机器上即跑F1,也跑F2。
但是如果F1有bugs,导致死机,会不会影响到F2?
A2:那原来遇到这个问题怎么办? 不也是MF1接二连三的全瘫嘛?这是软件的问题,不是balancer该解决的问题。
Q3:Virtualization。在同一台机器的硬件上,跑两套OSes,OS1里面只跑F1,OS2里面只跑F2。F1的bug,导致OS1崩溃,但是不会影响F2/OS2。
A3:这理论上当然好了,但你现在一个server开跑两个OS,安全是提高了,开销呢?进程比线程大很多了,OS的切换怎么也比进程切要准备的东西多吧。
而且OS1的崩溃也未必不导致OS2的崩溃,只是说概率比应用层的F1崩溃引起F2崩溃概率低而已。说到底这两个OS,也无非是同一个机器上的两个并行程序而已。
1. 单点故障
现在似乎所有的virtualization的方案都是在硬件层上建一个SuperVisor,然后上面再跑Domain0(虚拟机的管理系统)或者guest OS。那么这个Supervisor不就是单点故障源吗?SV或者Domain0一旦crash了,上面跑的任何东西都跟着完蛋。如何能保证它不出问题?
2. 代价
下面的讨论有说用虚拟机可以解决LoadBalance的问题。但问题是代价多大。
还是用邓大的例子:
Virtualization。在同一台机器的硬件上,跑两套OSes,OS1里面只跑F1,OS2里面只跑F2。F1的bug,导致OS1崩溃,但是不会影响F2/OS2。
比如,F1的后台是Oracle,数T的数据,F2的后台是DB2,也是数T的数据。
那么虚拟化之后,要多powerful的机器才能够同时跑F1和F2呢?这个机器的价格,再加上虚拟化软件的费用,相比F1,F2独立放在两台机器上的费用恐怕只高不低。只为了一个loadbalance,合算吗?
就我个人所知,很多的load balance管理的server pool是按应用划分的,不做应用交叉。 而且管的应用也是要分的,典型的大科学计算等等,其实还是任务队列最划算。
但到邓侃提到的一个实例,其实描述的现状应该是各方平衡最佳了,而且连balancer都省了,web向后端的server pool扔任务,应该是用到了应用中间件的。
这种情况他还要再理想化,那就只有上load balancer管理M×N个应用服务器喽。 呵呵
一是太忙,二是需要准备一些材料所以回的晚了,望邓兄海涵。
Flashlite作为手机UI平台已经被许多OEM尝试过,象SAMSUNG F700,V910和一些LG的型号。但由于性能的关系,又大多被放弃了。毕竟有2D/3D加速的CPU以前还太贵。但Sony不一样,借新CPU更强大的东风,它的胃口要大得多。有一篇有关Sony的Capuchin的文章供你参考:
另外Adobe的AIR也值得关注,工具包括Catalyst和Alchemy:
Catalyst:外链出处
Alchemy:外链出处
可能小步快走的Adobe辖其无可替代的UI设计工具会是最终的赢家。
今天去INTEL网站看了新的系统程序员开发指南 --- “很黄很暴力”,新的VM指令 --- 很好很强大。
趁周末空闲,赶紧把云计算的系列结束掉。
下周开始,好好和大家切磋一下手机application architecture的问题。
Xen的额外开销是3%-7%, not too bad.
Xen或者VMWare都能保证做到这一点。否则它们就没有存在的意义了。
能问出这样深刻的问题,说明你已经差不多明白了。静下心再仔细想一想,就想通了。
这种情况他还要再理想化,那就只有上load balancer管理M×N个应用服务器喽。 呵呵
的确就是要想办法balancing MxN服务器的资源。云计算的价值就是动态优化资源的使用。
如果云计算仅仅是M个machine farms的简单集合,那就和IDC(Internet Data Center)没区别了。
【9】赚钱才是硬道理
本系列开篇时说到,Google开放云计算平台的目的是为了赚钱。接下去我们分析了云计算的功能以及技术实现。
现在终点回到起点,我们了解了云计算的功能和技术,那么如何用云计算平台赚钱?
黄兄推荐了一篇参考文献,题目是“[URL=http://www.ibm.com/developerworks/linux/library/l-cloud-computing /index.html]Cloud computing with Linux[/URL]”。这个题目有点推销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不仅有网络端的云计算平台,而且这个平台与各种Windows平台,以及Windows平台上各种终端产品紧密结合,形成有纵深的终端产品。
什么叫有纵深的终端产品?
Sina Music Box
Courtesy http://lh4.ggpht.com/_cz82pwdvhmg/SZWnlHyixeI/AAAAAAAAAYw/EusY1wBeFJY/s640/SinaMusicBox.PNG
拿新浪的音乐盒做个例子。它不仅仅是一个简单的MP3播放器,而且用户可以搜索音乐,音乐盒也可以根据用户以前听过的音乐,推荐音乐,用户还可以组建自己的专辑,在播放MP3的时候,音乐盒还搜索相应的歌词,配合着播放的节奏,滚动地显示歌词。
也就是说,用户电脑上显示的是终端播放器,但是提供搜索,推荐,专辑和歌词的各项功能,依托的是网络端的云计算平台。
如果Microsoft想大力拓展“云端”服务,或许新浪的音乐盒是一个很好的启发。
1. SuperVisor和Domain0会不会成为single point of failure?
理论上任何软件都会有bug,SuperVisor和Domain0也不例外。
但是Xen也好,VMWare也好,他们谋生靠的就是SuperVisor和Domain0的可靠性。实践证明,Xen和VMWare的可靠性相当不错。
2. Xen的overhead值不值?
Xen的overhead是3%-7%。
如果F1是Oracle,F2是DB2等等之类heavy duty applications,当然给它们分配dedicated machines最合适。
但是如果F1和F2不是那么heavy duty,而且负载分布交错,也就是你忙我不忙的情况经常发生,那么把F1和F2放置在同一台机器上,用Virtualization技术相互隔离,以保证互不干扰,就有价值了。
3. Loadbalancer
即便把F1和F2放置在同一台机器上,用Virtualization技术相互隔离,LoadBalancer也是有用的。
如果有M台机器,每台机器上既可以跑F1,也可以跑F2。如果发现t1时刻有几台机器很忙,而其它机器不忙,那么t2时刻来的用户请求,该让哪一台机器去处理呢?当然应当把t2时刻来的任务分发给那些不忙的机器。
分发任务的工作,可以让LoadBalancer来做。
换而言之,Virtualization的意义,不在于省掉购买Load Balancer的钱,而是减少machine farm的规模,也就是减少M。