北京快三开奖

  • <tr id="U9YkSO"><strong id="U9YkSO"></strong><small id="U9YkSO"></small><button id="U9YkSO"></button><li id="U9YkSO"><noscript id="U9YkSO"><big id="U9YkSO"></big><dt id="U9YkSO"></dt></noscript></li></tr><ol id="U9YkSO"><option id="U9YkSO"><table id="U9YkSO"><blockquote id="U9YkSO"><tbody id="U9YkSO"></tbody></blockquote></table></option></ol><u id="U9YkSO"></u><kbd id="U9YkSO"><kbd id="U9YkSO"></kbd></kbd>

    <code id="U9YkSO"><strong id="U9YkSO"></strong></code>

    <fieldset id="U9YkSO"></fieldset>
          <span id="U9YkSO"></span>

              <ins id="U9YkSO"></ins>
              <acronym id="U9YkSO"><em id="U9YkSO"></em><td id="U9YkSO"><div id="U9YkSO"></div></td></acronym><address id="U9YkSO"><big id="U9YkSO"><big id="U9YkSO"></big><legend id="U9YkSO"></legend></big></address>

              <i id="U9YkSO"><div id="U9YkSO"><ins id="U9YkSO"></ins></div></i>
              <i id="U9YkSO"></i>
            1. <dl id="U9YkSO"></dl>
              1. <blockquote id="U9YkSO"><q id="U9YkSO"><noscript id="U9YkSO"></noscript><dt id="U9YkSO"></dt></q></blockquote><noframes id="U9YkSO"><i id="U9YkSO"></i>
                企业空间 推销商城 存储论坛
                北京快三开奖全闪存阵列 IBM云盘算 Acronis 安克诺斯 安腾普 腾保数据
                首页 > 技能园地 > Docker > 注释

                假如决议运用Docker,能否有须要同时运用OpenStack?

                2014-11-28 20:56泉源:51CTO
                导读:随着Docker项目在人气方面的继续飙升,很快方才打仗这一重生事物的读者在理论进程中不由发生了如许的疑问:假如曾经决议运用Docker,能否另有须要同时运用OpenStack?

                在明天的文章中,我盼望将留意力会合在冤家们最为存眷的批评议题身上。随着Docker项目在人气方面的继续飙升,很快方才打仗这一重生事物的读者在理论进程中不由发生了如许的疑问:假如曾经决议运用Docker,能否另有须要同时运用OpenStack?

                假如决议运用Docker,能否有须要同时运用OpenStack?

                在明天的文章中,我盼望将留意力会合在冤家们最为存眷的批评议题身上。随着Docker项目在人气方面的继续飙升,很快方才打仗这一重生事物的读者在理论进程中不由发生了如许的疑问:假如曾经决议运用Docker,能否另有须要同时运用OpenStack?

                假如决议运用Docker,能否有须要同时运用OpenStack?

                从一项****性的技能效果转化并衍生出一整套社区体系,Docker在开展速率上冲破了一个又一个汗青记录。但是,Docker项目在采用与遍及方面体现出惊人态势的同时,也给我们带来了一系列疑问与狐疑。

                在明天的文章中,我盼望将留意力会合在冤家们最为存眷的批评议题身上。随着Docker项目在人气方面的继续飙升,很快方才打仗这一重生事物的读者在理论进程中不由发生了如许的疑问:假如曾经决议运用Docker,能否另有须要同时运用OpenStack?

                在给出本人的观念之前,我计划起首就配景信息动手为列位停止解说,从而更为透彻地认清这个命题面前所隐蔽的实际根底。

                配景信息

                从最为复杂的组成方式动身,Docker实践上旨在提供一套可以在共享式根底设备之上对软件任务负载停止办理的容器情况,但同时又确保差别负载之间相互断绝且互不影响。以KVM为代表的假造机零碎所做的任务也差未几:创立一套完好的操纵零碎货仓,经过假造机办理顺序将与该零碎相干的设置装备摆设席卷出去。但是与假造机处理方案的区别在于,Docker在很大水平上依赖于Linux操纵零碎所内置的一项功用——名为LXC(即Linux容器)。LXC应用内置于操纵零碎当中的各项功用将差别历程的内存停止分别,乃至可以在肯定水平上拆分CPU与网络资源。Docker镜像不需求像一套全新操纵零碎那样停止完好的引导进程,如许一来软件包的体积就能失掉大幅紧缩、使用顺序运转在共享式盘算资源之上时也将具有更为明显的轻量化劣势。除此之外,Docker还容许任务负载间接拜访设置装备摆设驱动顺序、从而带来远超越假造机办理顺序方案的I/O运转速率。在这种状况下,我们得以间接在裸机设置装备摆设上运用Docker,而这就带来了后面提到的中心题目:假如曾经运用了Docker,我们另有须要同时运用OpenStack等云方案吗?

                后面的结论绝非天花乱坠,Boden Russell近来针对Docker与KVM等假造机办理顺序在功能体现上的差别停止了基准测试,并在DockerCon大会上发布了测试后果。

                本次基准测试提供相称细致的详细数据,并且如预期一样,测试后果表现引导KVM假造机办理顺序与引导Docker容器之间存在着明显的工夫耗费差别。本次测试同时标明,二者之间在内涵与CPU应用率方面异样存在着宏大区别,详细状况如下图所示。

                假如决议运用Docker,能否有须要同时运用OpenStack?

                白色线条为KVM,蓝色线条为Docker。

                这种在功能体现上的明显区别代表着两套目标相近的处理方案在资源密度与全体应用率方面大相径庭。而如许的差别也将间接表现在运转特定任务负载所需求的资源总量上,并终极反应到实践运用本钱当中。

                结论整理

                ·上述结论并不但纯指向OpenStack,但却实用于OpenStack以及别的与之相似的云根底设备处理方案。在我看来,之以是题目的锋芒每每终极会被指向OpenStack,是由于OpenStack项目现实上曾经在公有云情况范畴具有相称高的人气,同时也是现在我们专一会思索作为Docker替换方案的技能效果。

                ·题目的中心不在于OpenStack,而在于假造机办理顺序!

                许多功能基准测试都将Docker与KVM放在了天秤的两头,但却很少将OpenStack扳连于此中。现实上,后面提到的这次专项基准测试同时将OpenStack运转在KVM镜像与Docker容器情况之下,后果表现这两类技能效果可以带来抱负的协作结果。思索到如许的状况,当我们选择将OpenStack运转在基于Docker的Nova货仓当中时——正如OpenStack阐明文档提供的下图所示——那些资源应用率参数将变得可有可无。

                假如决议运用Docker,能否有须要同时运用OpenStack?

                ·在这种状况下,云根底设备可以在容器或许假造机办理顺序当中提供一套完好的数据中央办理处理方案,而这仅仅属于巨大零碎全体当中的构成局部之一。以OpenStack为代表的云根底设备方案当中包括多租户平安性与断绝、办理与监控、存储及网络外加别的多种功用设置。任何云/数据中央办理体系都不克不及离开这些效劳而独立存在,但关于Docker或许是KVM根底情况却不会做出过多要求。

                ·就现在来讲,Docker还不算是一套功用片面的假造化情况,在平安性方面存在多种严峻范围,缺乏对Windows零碎的支持才能,并且因而临时无法作为一套真正可行的KVM备用方案。虽然正在继续停止当中的后续开辟任务将逐渐弥合这些差距,但抱持着绝对激进的心态,这些题目的处理恐怕也同时意味着容器技能将在功能体现方面有所妥协。

                ·别的需求留意的是,原始假造机办理顺序与颠末容器化的实践使用顺序功能异样存在着宏大差别,并且上面这幅来自基准测试的图表清晰地阐明了这一点。现在能够公道的表明在于,使用顺序通常会应用缓存技能来低落I/O资源开支,而这大大影响了测试后果对真实情况中运转形态的精确反应。

                假如决议运用Docker,能否有须要同时运用OpenStack?

                ·假如我们将Docker容器打包在KVM镜像当中,那么二者之间的差别将变得可以疏忽不计。这套架构通常应用假造机办理顺序担任对云盘算资源的控制,同时应用Heat、Cloudify或许Kubernetes等流程层在假造机资源的包容范畴之内停止容器办理。

                总结

                由此我得出了如许的结论:要想准确地对待OpenStack、KVM以及Docker三者之间的干系,准确的动身点是将其视为一整套辅佐货仓——此中OpenStack饰演全体数据中央办理方案的脚色,KVM作为多租户盘算资源办理东西,而Docker容器则担任与使用摆设包相干的任务。

                在如许的状况下,我们可以汇总出一套通用型处理形式,此中Docker辨别充任以下几种脚色:

                ·Docker提供颠末认证的软件包,并包管其可以与波动稳定的现有根底设备模子顺遂协作。

                ·Docker为微效劳POD提供精彩的容器化运转情况。

                ·在OpenStack之上运用Docker,并将其作用与裸机情况同等的运转平台。

                后面说了这么多,我的确亲眼见证过不少颠末准确界说的任务负载实例,关于它们来说能否运用云根底设备仅仅是种自在选项而非强迫要求。举例来说,假如我出于DevOps的目标而思索树立一套小型主动化开辟与测试情况,那么我团体更偏向于在裸机情况上间接运用Docker机制。

                而假造机与容器这两类情况之间,流程层将成为一套绝佳的笼统对接东西。

                将流程框架与Docker配合运用的一大劣势在于,我们可以依据实践需求、随时在OpenStack以及裸机情况之间停止切换。经过这种方法,我们将可以选择恣意一种处理选项——只需其实在契合我们流程引擎关于目的情况的详细需求。OpenStack Orchestration(即Heat)在最新公布的Icehouse版本当中曾经明白表现支持Docker情况。Cloudify作为一款基于TOSCA的开源流程框架,本来实用于OpenStack以及VMware、AWS以致裸机等云情况,而近来也开端将Docker支持归入本身。谷歌Kubernetes次要面向的是GCE协作目的,但我们也可以经过自界说来使其顺应别的云或许运转情况。

                英文:http://opensource.com/business/14/11/do-i-need-openstack-if-i-use-docker

                持续阅读
                要害词 :
                Docker OpenStack
                中国存储网声明:此文观念不代表本站态度,若有版权疑问请联络我们。
                相干阅读
                产物引荐
                头条阅读
                栏目热门

                Copyright @ 2006-2019 ChinaStor.COM 版权一切 京ICP备14047533号

                中国存储网

                存储第一站,存储流派,存储在线交换平台