本篇内容介绍了“Container的优势有哪些”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
成都创新互联是一家专业从事网站制作、网站设计的网络公司。作为专业网站建设公司,成都创新互联依托的技术实力、以及多年的网站运营经验,为您提供专业的成都网站建设、网络营销推广及网站设计开发服务!
Container的优势总结为以下四点:
提高计算密度
一个虚机占用的资源比一个Container占用的资源不止多十倍。在一个物理机上开一百个虚机是很困难的,但要实现100多个,甚至几百个 Container是很正常的。腾讯在大量使用Container。某大型互联网公司上次升级发行版,主要就是为了使用Cgroups,方便限定资源,以 充分利用CPU。要知道有能力维护自己版本内核的公司,做出这样的决定是非常不容易的,可见其好处是巨大的。
大互联网公司非常适合Container,Facebook一台虚机都没有,因为这些互联网公司要求充分利用计算资源。虚机起码还要再跑一个Guest系统,太耗资源。
同时,在这些大公司内部并没有很多操作系统,集群只有一种操作系统,甚至连版本号都是固定的。因此,不需要虚机的异构操作系统特性。
另外,在操作系统上还有Runtime Library,Container不需要重复加载,极大的节省内存占用。
最后,因为公用的资源更多,Container相对来讲更容易超售,实际出售量的和超过了物理机的量
更精细的资源控制
这里以目前最为热门的Linux Container( LXC)为例来说,Linux Container分为两个部分,Cgroups用来做资源限制,Namespace来做资源隔离。最近Linux内核对LXC相关改进非常多,其中3.8版对Namespace新增了user,未来的3.11会加入更好的 CRIU支持,使得Container看上去可能更像一个虚拟机。
另外Container在数据库隔离方面也有着自身的优势。云化的数据库通常有两种思路:
第一,建立一个大数据库供所有人使用。但如何做资源隔离和安全隔离呢?
SAE通过增加SQL过滤器 (CSDN近期将对SAE首席架构师丛磊进行采访,详解SAE的资源隔离策略),将不合理的SQL全部过滤掉。盛大云的MongoDB服务也采用类似的策 略,通过判断执行时间来限定不合理的请求。但这种方法存在弊端,首先不能穷举所有不合理的请求,这是一个典型的停机问题,即便是工程上实用的做法,维护巨 量的规则库也会让管理员痛不欲生,看看杀毒软件要维护多少特征就知道了。其次需要修改数据库代码,而这些修改目前看不会被社区接受,因为社区认为资源隔离 并不是数据库该做的事。
第二,把每个用户的数据库放一个Container里,用Container来做资源限制。不需要对数据库进行修改。每个 用户的Container内有自己的数据库,用户之间的资源是完全隔离开的。不过有观点认为每个Container启动一个实例太浪费资源。其实,相同的 Runtime并不会重复占用资源,而且还能更好的限制资源,操作简单。目前一些Heroku的第三方插件是用这种方式进行数据库隔离的。 OpenShift通过Gear和Cartridges对资源进行隔离,每个应用有自己私有的小数据库。
更短的provisioning时间
虚机的provisioning时间在分钟级,而Container在秒级。设想在淘宝双十一的场景下,虚机需要几分钟时间启动显然太慢了。另外 LXC目前还有个非常有趣的技术,叫做systemd,是下一代的启动器,可以极大加快启动速度,并且与LXC结合得十分完美,有些高级功能就是依赖 LXC实现的。
这部分还有另外一个非常重要的技术就是文件系统。提高provisioning时间,需要文件系统配合,像ploop、aufs、overlayfs等文件系统都有一些非常有趣的技术可以用在Container的快照、复制等方面。
Container式的PaaS组装更灵活
用户根据自己的需要组装自己的PaaS,我认为这是趋势。不同的模块之间有不同的实现,可以替换。比如你认为 Docker对LXC的封装不好,就可以换一个。
Cloud Foundry也开始重视LXC,通过Warden把Container进行封装,但是从技术的角度来讲Cloud Foundry的架构过于大,它想把PaaS所有事都做了,但每一块做得都不怎么好,耦合度又高。比如我想把Warden换成Docker就很难。
Cloud Foundry为代表的PaaS平台倾向做得很重,而像Docker是轻量的框架代表。我认为轻量的平台更好,更有前途,因为更加灵活。PaaS到底该长成什么样去年我还觉得比较清楚,但今年反而觉得变数会非常多,所以我更看好灵活的方案。
Docker项目在Github上发布不到两天,就在Go语言排行榜上排名第一,说明社区很认可。额外说一句Go语言写的PaaS工具非常多,有大放异彩的趋势。而Cloud Foundry几乎都是仰仗VMware财大气粗。大家共同参与,项目才有生命力。Cloud Foundry的社区贡献度非常差,大部分都是VMware(Pivotal)自己的工程师贡献。
Container的趋势和挑战
和虚机相比,LXC的隔离做个并不彻底,而包括热迁移的等高级功能也正在完善中。程显峰将LXC的发展趋势和挑战总结为以下四点:
Container获得了更广泛的支持
OpenStack对LXC现在有很强的支持。当OpenStack支持Container了,这会导致该技术在互联网圈子里得到推广。同时,在OpenStack+LXC基础上还会有些创新。
另外, ActiveState Software早就把Cloud Foundry和LXC绑到一起,推出了商业版。
这一阵子比较火的 CoreOS、 dotCloud、 PiCloud等公司都是LXC的坚定支持者,systemd的作者以及 OpenVZ的开发团队都齐心协力支持LXC。
vps就是Container典型的应用场景,基本上全球市场上90%的VPS平台都使用OpenVZ。它是一种Container,但是因为对Container的修改过大,不被社区接受。但OpenVZ的商业版本比Linux Container成熟得多,可以支持热迁移。OpenVZ的作者为Linux Container提交了百十多个patch。已经有很多社区的活跃者对Linux Container做贡献。
LXC在有些方面与虚机有差距
资源限定和隔离做得并不彻底,比如时间就隔离不了。现在LXC隔离也就几个方面,进程、挂载资源、用户,大概也就六点,实际上还远远不够。
虚机热迁移技术已经非常成熟,而LXC还有差距,也在改进中。据报道,在Linux kernel 3.11中会有很大改善。
调试工具逐步完善
云计算调试是个非常头疼的事情,如果应用跑在虚机里,管理员是很难进行管理的。而Container对操作系统有一些透明性,如process有异常调用,管理员可以看到。
大家为什么不用云计算?大部分人都说部署习惯不一样,调试部署不方便,大家为什么还愿意用虚拟机?虚拟机的调试方式跟他在实体机上调试方式没有任何差异,这种习惯是很难改变的。
Cloud Foundry、SAE、Azure的调试都解决的不彻底。仅仅通过本地模拟器进行调试,并不能解决根本问题。
调试工具近期也会有一些新的突破,语言级别的像Ruby2.0以后加了对DTrace支持。我很看好Dtrace和SystemTap之类的技术的,尤其是在PaaS调试上,大家可以关注一下 章亦春、 余锋的博客。
PaaS服务依然不够完善
尽管各种PaaS层出不穷,Cloud Foundry、OpenShift、Azure也在不遗余力的打造更易用的PaaS平台,但仍存在各种不足和挑战。无论自建还是使用第三方平台,PaaS还远未成熟。程显峰认为:
PaaS平台没有统一的认识
PaaS到底应该搭成什么样?什么样是成熟的PaaS?现在都没有统一的认识。微软Azure、Heroku以及Cloud Foundry,各家PaaS的边界和内容都不一样。
微软Azure有弹性的数据库、 Service Bus。 亚马逊也有类似的服务。这些服务到底属于IaaS还是PaaS呢?用户需要的是非常完整的服务,无论对于IaaS还是PaaS都有大量的工作需要去做。所 以,现在看PaaS,要想在一个体系下提供服务,我认为是很难的。而Docker这种灵活的方案,只做某一块服务,再组装在一起可能是更好的方式。
从上面说的我们也可以看出,现在的云计算模型已经远远不是三层的IaaS、PaaS、SaaS那么简单的了。很多组件都能作为一个服务呢,这些组件 应该放在什么位置呢?实际上这个关系非常复杂,各家都有各家的看法,这些看法随着时间改动也还是很大。我的一个观点是从单个技术上突破做成大家都认可的组 件比较容易,总体结构要想达成一致比较难。
国内没有完善的公有云 自建IaaS也很麻烦
PaaS要底层基础资源必须弹性,如果采取自建私有云的方式,很可能需要去搭建OpenStack,工作量非常大。如果植根于公有云,国内没有美国 那样成熟的亚马逊、Azure或Rackspace,阿里云的API还不够健全,无法支撑。在国内如果底层资源弹性问题无法解决,PaaS就是空中楼阁。
标准和互操作也是比较头痛的问题。国内互联网公司相互合作不够,对于标准和规范重视程度也远远不够。有人说云就是水电,但问题是水电是高度同质的,目前还没看到哪些云是同质的。国外还有些公司做跨平台云的管理,国内就更难了,这也是做一个公有PaaS的潜在风险。
当然,国内的网络割裂比较严重也是对云计算发展的不利影响。这些都本不该是一个PaaS提供商该考虑的问题,但是我们的国情就要求必须要考虑。
需要坚实的服务支持
PaaS还需要其他服务支撑,比如Cache、负载均衡、数据库、消息队列、日志,这些服务只有全部包含PaaS平台才有价值。当开发者在PaaS上运行了应用,如果还要自己搭建这些服务,然后做HA,这就背离了PaaS的设计初衷。因为,实际上应用并不是运维的重点,重点上面提到的那些周边的服务,这些服务的运维成本很高,而且还不体现开发者的核心价值。
京东做得更好。由于Cloud Foundry的服务并不是云化的,不提供HA。京东需要做云化,自己做了上面所说的基础服务。
展望Cloud Foundry、OpenShift、Azure
Cloud Foundry今年将推出商业版,Azure越来越重视开源社区,变的更加开放, OpenShift继续着云化战略。在采访结束前,程显峰进行了总结:
京东云底层使用了OpenStack + Cloud Foundry,从长远上看仍然会走互联网式的技术路线。也许再晚一个月做决策,京东就会选择OpenShift了,因为从技术角度来讲,OpenShift比Cloud Foundry要好一点。
OpenShift代码写的还算规矩,而Cloud Foundry的代码并不是社区的产物,很多地方都不像大公司的作品。我认为但凡是脱离社区单搞一套,从历史上看绝大多数都没好结果。
从我看的一些报告来看,VMware在虚拟化技术上的领先优势已经不明显。微软的平台与VMware看不出明显的差距。毕竟微软有操作系统和大量商 用软件,这些技术积累是其他公司很难拥有的。同时微软有自己的商用的公有云Azure,对新技术是很好的试验场,VMware还没运营自己的公有云。
“Container的优势有哪些”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!