西西河

主题:【原创】云里雾里的云计算 [1] -- 邓侃

共:💬620 🌺1262
全看树展主题 · 分页首页 上页
/ 42
下页 末页
家园 继续抛砖引玉

1.

实践证明,Xen和VMWare的可靠性相当不错。

不清楚VMware是什么构架就不评论了。Xen是基于Linux的。如果Xen能做到本身不崩溃,上面跑的某个程序(guest OS)崩溃也不会影响其他程序,那么Linux也应该能做到。那还要Xen干什么呢?

2.

heavy duty

如果MF不heavy duty,那就几乎用不到load balance和云。只要在MF1满(超)负载的情况下,才需要MF2帮忙。邓大也说过,

heavy duty applications,当然给它们分配dedicated machines最合适
。那与其花重金买机器同时装F1和F2,岂不是不如给F1,F2单独买机器了?

当然,单独给F1,F2买机器会在闲时浪费资源。不过买superpowerful机器做virtualization也是一样。你在sizing的时候,是按照F1满载,F2空载(vice versa,或者两者都50%)算呢,还是按照F1,F2同时满载算呢?如果前者,显然偶尔F1,F2都忙的时候就overload了,不符合做virtualization的初衷;而后者的代价可就不是一般的大了

3.

Virtualization的意义,不在于省掉购买Load Balancer的钱,而是减少machine farm的规模,也就是减少M

M的数目减少了,但单个的每个M更费钱了。再加上virtualization软件成本和维护成本,migration的风险,从TCO角度来说,不见得合算。当然,或许环保主义者会开心一些

关键词(Tags): #virtualization#TCO
家园 总结一下

1. Data-storage-as-a-Service(dSaas)就是个Internet数据仓库。与传统NAS,SAN和数据库不同的是,它是通过Internet访问的

2. Infrastructure-as-a-Service(IaaS)就是个Internet Mainframe。用户从终端连接变成了Internet连接

3. Platform-as-a-Service (PaaS)开始有些意思了,算是虚拟空间服务的拓展吧。用户不但能租到现成的web server,还能自己上传一些插件,比如论坛,商店,blog,聊天室,游戏什么的。当然,商业用户玩的是workflow和ERP之类的游戏。

4. Software-as-a-Service (SaaS)更绝。用户就是用户。你需要的一切我都有,你只要使用就好了,连安装,配置程序都免了。IT部?我们公司100年前就解散那群geek啦

从上面可以看出来,这4种方式,以前都有过类似的服务了。目前这个“云”字,只是发展了三下:

1. 从为内部提供服务,变成了为Internet用户提供服务

2. 从提供简单服务(如web server),到提供复杂服务(如workflow,ERP)

3. 从企业内部提供IT服务,变成IT服务外包。

所谓“云”,看着复杂变化多端,说穿了,也不过是水蒸汽嘛,呵呵

家园 问题很深刻,态度很礼貌,meokey是好榜样

1.

如果Xen能做到本身不崩溃,上面跑的某个程序(guest OS)崩溃也不会影响其他程序,那么Linux也应该能做到。那还要Xen干什么呢?

问题出在“上面跑的某个程序(guest OS)崩溃也不会影响其他程序”这一句话。某个程序的崩溃搞不好会使整个系统崩溃,从而殃及其它程序。

想举个例子,说明什么样的程序会导致整个OS崩溃。但是刚起床,没完全清醒。谁能帮个忙?

2.

如果MF不heavy duty,那就几乎用不到load balance和云。只要在MF1满(超)负载的情况下,才需要MF2帮忙。。。那与其花重金买机器同时装F1和F2,岂不是不如给F1,F2单独买机器了?

这段话隐含了一个判断,“只有在F1是heavy duty的情况下,MF1才会满负载”。这个断语是有问题的。满负载和application本身是否heavy duty没有必然联系。

例如F1程序本身并不那么heavy duty,但是如果并发用户量很大,就需要提高server的吞吐量。如何提高吞吐量?通常的办法是征用最大数量的threads,每个thread跑一个F1 instance。这样造成F1所在机器的满负载。

推而广之,如果并发用户量很大,就会造成MF1里面所有机器满负载。

3.

不过买superpowerful机器做virtualization也是一样。。。M的数目减少了,但单个的每个M更费钱了。

Virtualization不需要superpowerful machine,现在4x4GHz CPU,10G RAM的机器不过USD1500左右。硬件很便宜。

4.

你在sizing的时候,是按照F1满载,F2空载(vice versa,或者两者都50%)算呢,还是按照F1,F2同时满载算呢?如果前者,显然偶尔F1,F2都忙的时候就overload了,不符合做 virtualization的初衷;而后者的代价可就不是一般的大了。

是用IDC架构,还是用virtualization,的确是需要预先核算一下。不是说virtualization在任何情况下都比IDC方案好。

家园 大部分同意,极少数不完全同意

从上面可以看出来,这4种方式,以前都有过类似的服务了。目前这个“云”字,只是发展了三下:

1. 从为内部提供服务,变成了为Internet用户提供服务

2. 从提供简单服务(如web server),到提供复杂服务(如workflow,ERP)

3. 从企业内部提供IT服务,变成IT服务外包。

这三条严格说来,也不是云计算的特别贡献。

我的理解,云计算的最大贡献是提供了一种建高楼大厦的新方式。1. 廉价的建筑材料,2. 楼层可以不断加高。

在云计算以前,人类只见过Mainframe之类的高楼大厦。那些豪华大楼,只有富翁才用得起。但是现在高楼的建筑方式改变了,建设成本降低了,于是,寻常百姓,普通企业也用得起高楼大厦了。

家园 最后的总结,俺不献花,俺要扔半个“草”。

1.Data-storage-as-a-Service(dSaas)所谓的网上存储,已经聊无新意。如是这个目的,不上网的斗不过U盘,俺拳击日买16GB的U盘不过25加币。如果文件小上网可以用各种EMAIL(GMAIL,HOTMAIL)的DRAFT功能一存,回去一样可以打开。大点的文件有[URL=www.megaupload.com]MEGAUPLOAD[/URL]。与这些已有的网上存储相比,GOOGLE或者其它服务商的云的优势何在?牌子更亮?或者收费更低廉?或者上下载的速度更快?俺想起了一个歇后语,高射炮打蚊子 --- 大材小用。如果人人都上传数个GB的文件上去,云再把这些文件同步到世界各地的服务器上,有这种必要吗?这种同步要耗用多大的带宽成本?

2.Infrastructure-as-a-Service(IaaS)如果各种计算都可以真正的并行化的话,正真应该深挖潜力的不是GOOGLE或者Amazon,应该是INTEL,AMD,或者$MS.俺记得某个搞语言编译或者并行计算的权威说过这样的论点:如果真想挖掘目前多核CPU的能力,目前世界上一多半的程序员都要“重新回炉”,从编译器到程序设计的思路都需要调整。俺记得有个搞“并行编译”的解决方案,就是缩短一个大的PROJECT的BUILDING的时间,将这个大的PROJECT分配到若干个装有VS 200x的机器上。嘿嘿,价格不菲。当然对老板是好事情,否则程序员若干小时不干活喝咖啡老板还要付钱。俺的关键论点是,云说起来好听,并行计算不是简单的问题,难道本线中关于“负载平衡”的问题不是一个很好的注解吗?

3.Platform-as-a-Service (PaaS),这个云比传统的HOSTING有一定的优势。优势在于规模的可伸缩性与收费更趋于合理。

4.Software-as-a-Service (SaaS),优势同3.但这个要取决于基本Software功能的丰富和API的简化。否则,这就成了云上的MFC或者“咖啡豆”--- 尾大不掉,另一个循环开始。

云,俺的感觉是GOOGLE在前面吆喝,Amazon等等准备在后面收钱。

家园 虚拟化是个好东西,可以挖个大坑。
家园 1.2.不同意,3.4.赞同

1. dSaaS。网盘的意义与U盘不同。

譬如Google Docs,你在办公室可以用它写文章,回家接着写,而且是在同一个文件里写。甚至你的同事也可以对同一份文件操作。

U盘不同,或许你可以对U盘里同一份文件操作,但是你的同事呢?他们不能。

所以,U盘必然导致同一份文件,多个版本,合并起来很麻烦。

2. IaaS的分歧出在Scalability。

Intel可以把单核变四核。但是这样的扩展技术难度大,不如云计算那么容易扩展。云计算扩展,基本上就是加机器。

加机器vs多核,当然是加机器容易。

3.4. 同意。

家园 2 说的是解析度。

一个程序开始设计就是顺序执行的,放到4核上也快不了多少。

家园 云这个玩意儿:它就是个现代的主机、终端。

不过在老式主机、终端、连线这三部分上各有扩展。

不过我到在想可能有一个事情,会颠覆以前的东西:

[FLY][MOVE][SIZE=3]就是程序的编写,会从顺序执行,转为并发执行。[/SIZE][/MOVE][/FLY]

顺便试试西西河提供的各种特殊效果。 呵呵

家园 理论和实践、普通和特殊、都是有差距的。

系统的隔离保护级别与开销,历来是正相关的。

而且按照经验,开销与负载,又是指数关联的。 整个cpu利用率到20%以下的时侯,ok。但整个cpu利用率达到80%的时侯,各种切换的开销,往往比正事的消耗还大。

另外,现在所有计算机的程序运行,从根子上讲,就是一组核心态进程、一组非核心态进程。 理论上非核心态进程垮台不影响到核心态进程,概率是0。 实际上,它就不可能是0.

家园 关于2

所谓的云,基本上可视做许多连在一起的对等的计算机。一个4核CPU的机器如果装上VMWARE,运行4个相同的GUEST OS实例,每个实例指定到不同的内核,俺可不可以认为俺有了一个4个机器的“微云”。俺是否得到了相当于单核4倍的计算能力?(考虑到虚实变化,应该是3.X倍的计算能力)对于云,N台计算机应该得到的是N-M倍的计算能力,这里的M远远小于N.

你可以说俺这个“微云”中没有“负载平衡器”,某某的云里面有,问题是这个“负载平衡器”是否是“包治百病的良药” --- 任意的计算都能均匀地分配到云内不同的计算机?显然,这个答案是否定的。非常有针对意义的应用可能有戏,比如WEB访问。但是如果俺用云破解某个单机破解强度是10年加密结果,云能在几天内给俺回答出答案吗?

家园 我们讨论的问题是什么?

或许,我没有正确理解你的意思。

Infrastructure-as-a-Service(IaaS)如果各种计算都可以真正的并行化的话,正真应该深挖潜力的不是GOOGLE或者Amazon,应该是INTEL,AMD,或者$MS.

我先前对这句话的理解,是Google的大云,不如Intel的微云,加机器不如多核。

看来我的理解错了。太守的原意是什么呢?

家园 核心态进程vs非核心态进程

另外,现在所有计算机的程序运行,从根子上讲,就是一组核心态进程、一组非核心态进程。 理论上非核心态进程垮台不影响到核心态进程,概率是0。 实际上,它就不可能是0.

不是特别明白核心态进程和非核心态进程指的是什么。

一个播放音乐的MP3 player算不算非核心进程?

如果这个player出了bug,把所有RAM占满,或者不停地和disk做swap,那会出现什么局面?

家园 古人曰:治大国若烹小鲜。

或者说:一屋不扫,何以扫天下?

如今多核CPU的潜能依然有很多没有释放出来。软件的开发大大地落后于硬件的潜力。如果“微云”上的问题不能解决,俺看不出“大云”上有任何通用的解决方案,或者说云有真正通用的平(并)行计算的能力。Infrastructure-as-a-Service(IaaS),这是不是市场上的纯粹忽悠?

家园 刻薄点说,这是业界的又一个名词游戏

当年闹腾CORBA, DCOM, XML, SOAP,WS的时候比现还热闹多了。结果这些差不多都终结给了JSON。

早10年Larry Ellison叫嚣thin client,net computer的时候,不就是要把所有计算放到现在称之为“云”的地方吗?他说:

The interesting thing about cloud computing is that we’ve redefined cloud computing to include everything that we already do. I can’t think of anything that isn’t cloud computing with all of these announcements. [b]The computer industry is the only industry that is more fashion-driven than women’s fashion.[b] Maybe I’m an idiot, but I have no idea what anyone is talking about. What is it? It’s complete gibberish. It’s insane. When is this idiocy going to stop?

We’ll make cloud computing announcements. I’m not going to fight this thing. But I don’t understand what we would do differently in the light of cloud computing other than change the wording of some of our ads. That’s my view.

全看树展主题 · 分页首页 上页
/ 42
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河