docker共享如何构建docker私有云，docker搭建私有云 _生活百科

如何通俗解释Docker是什么
Docker的想法来源于容器。容器解决了哪些问题？在大船上，你可以把货物摆放整齐。而且各种货物都是用集装箱标准化的，集装箱和集装箱不会互相影响。那我就不需要装水果的船和装化学品的船了。只要这些货物用集装箱包装好，我可以用一艘大船把它们全部运走。Docker也是类似的想法。云计算现在很流行。云计算就像一艘大货轮。Docker是一个容器。1.不同的应用可能有不同的应用环境。比如开发的网站。net和php开发的网站依赖于不同的软件。如果把他们所依赖的软件全部安装在一台服务器上，调试时间会比较长，比较麻烦，会造成一些冲突。例如，IIS和Apache访问端口冲突。这时候你要把开发的网站隔离出来。net从php开发的那些。一般来说，我们可以在服务器上创建不同的虚拟机，把不同的应用放在不同的虚拟机上，但是虚拟机成本比较高。Docker可以实现虚拟机隔离应用环境的功能，成本比虚拟机小，意味着省钱。2.开发软件的时候用的是Ubuntu，但是运维管理是centos 。当你把你的软件从开发环境转移到生产环境，从Ubuntu到centos，运维会遇到一些问题。比如有一个数据库的特殊版本，只有Ubuntu支持，centos不支持。在转移的过程中，运维必须想办法解决这样的问题。这时候，如果你有docker，你可以直接把开发环境打包，转给运维，运维可以直接部署你给他的docker 。部署速度快。3.在服务器负载方面，如果单独打开虚拟机，虚拟机会占用空闲内存，部署docker时会用到。反正docker就是容器原理。
【docker共享如何构建docker私有云，docker搭建私有云】Docker+ Kubernetes已成为云计算的主流（二十六）
现在大家都在说的云原生到底是什么？
云原生是一个组合词，可以拆分为“云”和“原生”两个词。众所周知，“云”就是在线网络的意思。传统应用原本运行在本地服务器上，很可能需要停止和更新，不能动态扩展。“云”是指应用程序运行在分布式的云环境中，这种环境可以频繁更改，并持续交付。“原生”是指应用在设计初期就已经考虑到了云平台的弹性和分布式特性，也就是为云而设计。可以简单理解为：云原生=微服务DevOps持续交付容器化|微服务|即软件架构。使用微服务架构，一个大型应用可以按照功能模块拆分成多个独立自治的微服务，每个微服务只实现一个功能，边界清晰。有什么好处？1)服务的独立部署。每个服务都是一个独立的项目，可以独立部署。它不依赖于其他服务，具有低耦合性。2)服务的快速启动。拆分后，服务启动速度比以前快了很多，因为依赖的库少了，代码也少了。3)更适合敏捷开发。敏捷开发以用户需求的演进为核心，采用迭代、分步的方法。服务拆分可以快速发布新版本。修改哪个服务只需要发布对应的服务，不需要整体重新发布。4)责任专一，有专门的团队负责专门的服务。当业务快速发展时，R&D人员会越来越多，每个团队可以负责相应的业务线。服务的拆分有利于团队之间的分工。5)服务可以按需动态扩展。当某个服务有大量访问时，我们只需要扩展这个服务。6)代码的重用。每个服务都提供REST API，所有基本服务都必须提取。接口可以提供许多底层实现。|容器化|是cloud native的核心技术，是比虚拟机更轻的虚拟化技术。它可以为我们提供一种可移植和可重用的方式来打包、分发和运行程序。容器的基本思想是把所有要执行的软件打包成一个可执行的包。例如，将Java虚拟机、Tomcat服务器和应用程序本身打包到一个容器映像中。用户可以使用这个容器映像启动容器，并在基础设施环境中运行应用程序。Docker是目前应用最广泛的容器引擎。容器化为微服务提供了实现保障，起到了应用隔离的作用。K8S是一个集装箱安排系统，用于集装箱管理和集装箱之间的负载平衡。Docker和K8s都是用Go写的(K8s全称Kubernetes，由首字母K，最后一个字母S，中间八个字母组成，所以缩写为K8s) 。| DevOps |是软件开发人员和IT运维人员之间的协作过程。它是工作环境、文化和实践的集合，其目标是有效地和自动地实现软件交付和基础设施变更过程。通过开发商和运营商之间的持续沟通和协作，应用程序可以以标准化和自动化的方式快速、频繁和可靠地交付。|持续交付|是指不延迟开发，不停机更新。它是一种软件开发方法，使用自动化来加速新代码的发布。在持续交付过程中，开发人员对应用程序所做的更改可以通过自动化推送到代码库或容器映像库。

文章插图
如何通俗解释Docker是什么？
解释docker是一个容器。Docker是一个开源的应用程序容器引擎，它允许开发人员将其应用程序和依赖包打包成一个可移植的映像，然后发布到任何流行的Linux或Windows机器上，它也可以被虚拟化。容器是完全沙盒化的，彼此之间不会有任何接口。一个完整的Docker由以下几部分组成：DockerClient客户端。Dockerdemon守护进程。Docker镜像docker容器容器。docker的网站上提到了docker的典型场景：自动化应用程序的打包和部署。创建轻量级私有PAAS环境(创建轻量级私有PaaS环境) 。自动化测试和持续集成/部署(实现自动化测试和持续集成/部署) 。部署和扩展web应用、数据库和后端服务(部署和扩展web应用、数据库和后端服务) 。
如何使用OpenStack，Docker和Spark打造一个云服务
蘑菇街基于OpenStack和Docker的私有云实践。这次主要是想分享一下我们在基于Docker的私有云实践一年来遇到的问题，如何解决的经验，以及我们的体会和思考，与大家分享。有一些在生产环境下使用Docker的经验和体会。私有云项目于2014年圣诞节期间启动。它从无到有。经过半年多的发展和三次大促销，逐渐形成了一定的规模。众所周知，当时Docker本身的集群管理能力还不成熟，所以我们没有使用刚刚兴起的Swarm，而是使用了业界最成熟的OpenStack，可以同时管理Docker和KVM 。我们将Docker作为虚拟机运行，以满足虚拟化的业务需求。未来的思路是微服务，将应用拆分成微服务，实现基于应用的PaaS部署和发布。如何通过OpenStack管理Docker？我们采用OpenStack nova-docker Docker的架构模式。Nova- docker是StackForge上的一个开源项目。作为nova的一个插件，它通过调用Docker的RESTful接口来控制容器的启动和停止。在IaaS的基础上，我们有自主开发的调度等组件，支持应用灵活性、灰度升级、一定的调度策略等功能，从而实现PaaS层的主要功能。同时基于Docker和Jenkins实现持续集成(CI) 。如果Git中的某个项目发生了Git推送，就会触发Jenkins Job自动构建。如果构建成功，将生成Docker映像并推送到镜像仓库。基于CI生成的Docker镜像可以通过PaaS的API或接口更新开发测试环境的实例，最终更新生产环境的实例，实现持续集成和交付。而网络存储网络，我们默认不采用Docker提供的NAT网络模式，NAT会造成一定的性能损失。有了OpenStack，我们不用启动iptables就可以支持Linux bridge和Open vSwitch，Docker的性能接近物理机的95% 。在集装箱监控方面，自主开发了集装箱工具，实现了集装箱装载值的计算，替代了原来的top、free、iostat、uptime等命令。这样，当业务端使用容器中的常用命令时，看到的是容器的值，而不是整个物理机的值。目前，我们正在将Lxcfs移植到我们的平台上。我们还在主机上增加了几个阈值监控和报警，比如关键进程监控、日志监控、实时pid号、网络连接跟踪号、容器oom报警等等。冗余灾难和隔离冗余灾难和隔离，我们做了很多冗余灾难预案和技术准备。我们可以在不启动docker守护进程的情况下离线恢复Docker中的数据。同时支持Docker跨物理机冷迁移、动态CPU扩展/收缩、网络IO磁盘IO限速。遇到的问题和解决方案不到一年就接近产品化，我们在实际使用中遇到了各种各样的问题。使用Docker的过程也是不断优化Docker，不断定位问题，解决问题的过程。我们当前的生产环境使用CentOS 6.5 。有一次，某业务方误以为自己使用的Docker容器是物理机，在Docker容器内部安装了另一个Docker，瞬间导致内核崩溃，影响到同一物理机的其他Docker容器。经过分析，是2.6.32-431内核对网络命名空间的支持不佳造成的。在Docker中创建桥会导致内核崩溃。上游修复了这个bug，从2.6.32-431升级到2.6.32-504后问题解决。用户写的程序也有bug 。创建的线程没有及时回收，容器中产生大量线程。最后，不可能在主机上执行命令或ssh登录。报告的错误是‘bash:fork:无法分配内存’，但是通过free看看空闲内存就够了。经过分析发现，内核对pid的隔离支持不完善，PID _ max(/proc/sys/kernel/PID _ max)是全局共享的。当容器中的PID数量达到上限32768时，主机和其他容器无法创建新的进程。
最新的4.3-rc1只支持每个容器的pid_max限制。我们还观察到docker的主机内核日志会导致混乱。经过分析发现，内核只有一个log_buf缓冲区，printk打印的所有日志都先放在这个缓冲区，docker主机和容器上的rsyslogd会通过syslog从内核的log_buf缓冲区取日志，导致日志混乱。这个问题可以通过修改容器中rsyslog的配置来解决，这样只有主机可以读取内核日志。此外，我们还解决了设备映射器dm-thin丢弃导致的内核崩溃等问题。经验与思考最后，分享一下我们的经验与思考。与KVM成熟的虚拟化技术相比，容器还有很多不完善的地方。除了集群管理，网络，存储，最重要的是稳定性。稳定性主要受隔离不完善的影响，一个容器引起的问题可能影响整个系统。容器的memcg不能回收slab缓存，也没有限制脏缓存的数量，更容易出现OOM问题。另外，procfs上的一些文件接口不能是基于容器的，比如pid_max 。还有一点就是对容器下的运维手段和体验的影响。一些系统维护工具，如ss，free，df等。不能在容器中使用，或者使用的结果与物理机不一致，因为系统维护工具一般都是在procfs下访问文件，这些工具要么需要修改，要么需要适配。虽然容器并不完美，但我们仍然非常看好容器的未来发展。与容器相关的开源软件，如Kubernetes、Mesos、Hyper、CRIU、runC等。是我们关注的焦点。QAQ:容器之间的负载平衡是如何实现的？答：容器之间的负载平衡更多是在PaaS和SaaS级别。我们的P层支持4层和7层动态路由，通过域名或名称服务对外公开接口。我们可以实现基于容器的灰度升级和弹性扩展。问：你的OpenStack运行的是CentOS 6.5吗？答：是的，但是我们已经升级了OpenStack和Docker所依赖的包。我们维护内部yum源。问：容器IP是静态排列还是动态获取？答：这和运维管理的网络模式有关。我们内网没有DHCP服务，所以对于IaaS层，容器的IP是静态分配的。对于PaaS层，如果有DHCP服务，容器的App暴露的IP和端口可以是动态的。问：你部署Ubuntu的时候试过吗？你研究过这两种制度的区别吗？另外，你是怎么在OpenStack上监控这些虚拟机的？答：我们没有试过Ubuntu，因为公司的生产环境用的是CentOS 。我们的中间件团队负责监控公司的机器，我们配合监控团队将被监控的代理程序部署到主机和每个容器上，这样就可以作为虚拟机进行监控。当然，容器的数据需要从cgroups中提取，我们负责这部分数据提取。问：你对集装箱之间的网络选择有什么建议吗？据说使用虚拟网卡相比物理网卡有明显的性能损失。Docker提供的weaves和ovs能胜任吗？答：默认NAT方法不推荐用于容器网络，因为NAT会导致一些性能损失。我之前的分享里提到过，iptables不需要启动，Docker的性能接近物理机的95% 。Docker的weaves底层应该还是用网桥或者开放式vSwitch 。建议你看一下nova-docker的源代码，会比较容易理解。问：静态IP是通过LXC实现的吗？答：静态IP的实现在nova-docker的novadocker/virt/docker/vifs.py中实现。实现原理是通过ip命令添加veth对，然后使用ip link set/ip netns exec等一系列命令来实现。设置原理类似于编织。问：你是如何在容器中管理进程gdb的？你把gdb打包进集装箱了吗？答：集装箱里的gdb不会有问题。可以直接yum安装gdb 。
问：共享存储可以直接挂载到容器中吗？答：虽然没试过，但是通过docker -v这种方式应该没问题。问：如何在不启动Docker守护进程的情况下离线恢复Docker中的数据？答：离线恢复的原理是使用dmsetup create命令创建一个临时dm设备，映射到Docker实例使用的dm设备号。通过安装这个临时设备，可以恢复原始数据。问：Docker跨物理机冷迁移支持动态CPU扩展/收缩，网络IO磁盘IO速度限制。是如何实现的？能具体说说吗？答：Docker的冷迁移是通过修改nova-docker实现OpenStack迁移的接口。具体来说，是通过docker提交，docker推送到内部注册表，然后docker拉快照，在两台物理机之间完成的。动态的CPU扩展/收缩，网络IO磁盘IO的速度限制主要是通过novadocker修改cgroups中的CPU、iops、bps、TC的参数来实现的。问：以后会考虑用梦龙项目，还是选择Swarm？答：这些是我们的备选方案，我们可以考虑Swarm 。因为Magnum底层还是调用Kubernetes这样的集群管理方案，与其用Magnum，不如直接选择Swarm或者Kubernetes 。当然，这只是我个人的看法。问：你的企业是基于同样的形象吗？如果是不同的映像，计算节点如何保证容器可以快速启动？答：运维会维护一套统一的基础映像。其他商业形象将根据这个形象。我们在初始化计算节点的时候，会通过docker pull把基础镜像拉到本地，这也是很多公司的普遍做法。据我所知，腾讯和360都是类似的做法。问：要进行热迁移，您是否考虑过继续使用传统的共享存储？答：分布式存储和共享存储都在考虑之中。接下来，我们计划进行容器的热迁移。问：是直接将公有IP绑定到容器，还是通过其他方式映射到容器私有IP？如果是这样的话，怎么能解决原来VLAN隔离的第二层呢？答：因为我们是私有云，不涉及浮动ip，所以你可以认为是公有IP 。VLAN的第二层隔离可以在交换机上完成。我们用Open vSwitch划分不同的VLAN，实现Docker容器与物理机的网络隔离。问：能否详细说明一下Q:设备映射器dm-thin discard的问题？答：4月份有两台主机频繁无故重启。首先想到的是检查/var/log/messages日志，但是在重启时间点附近没有发现与重启相关的信息。然后，在/var/crash目录下，我们找到了内核崩溃的日志vmcore-dmesg.txt 。日志生成时间与主机重启时间一致，表明主机在内核崩溃后自动重启。” drivers/MD/persistent-data/DM-btree-remove . c:181处的内核错误！” 。从堆栈中，我们可以看到我们正在处理准备丢弃的dm-thin 。虽然我们不知道bug的根本原因，但是直接原因是丢弃操作，所以可以关闭丢弃支持来避免。在我们所有的主机配置中禁用丢弃功能后，同样的问题再也没有发生。在今年的CNUTCon大会上，腾讯和大众点评在分享自己对Docker的使用时也提到了这次崩溃。他们的解决方案和我们的完全一样。问：在阈值监视和报警块中，有高、低和多级报警吗？如果目前出现低级别的告警，你会采取一些措施限制用户访问或者切断用户当前正在使用的服务，还是放任事态发展？答：对于告警，运维有专门的PE，负责在线业务的稳定。当有报警时，服务提供商和PE会同时收到报警信息。如果影响单个虚拟机，PE将通知业务方。如果严重的话，甚至可以及时掉线。我们会和PE合作，让业务方及时把业务搬走。
问：你们自主开发的容器工具是开源的吗？GitHub上有你的代码吗？为什么还不开源？后期有望开源吗？如何考虑监控容器的细粒度？答：虽然我们还没有开源，但是我觉得开源是没问题的。请等待我们的好消息。关于监控容器的细粒度，主要思想是在主机级别监控容器的健康状态，而容器的内部监控由业务方完成。问：容器的层在乎层数吗？底层文件系统是ext4吗？有没有优化策略？当然，我们有。我们通过合并镜像级别来优化docker拉镜像的时间。在docker pull中，每一层的验证都需要很长时间。通过减少层数，不仅尺寸变小，而且docker拉动时间大大缩短。问：容器的memcg不能回收slab缓存，也没有限制脏缓存的数量，更容易出现OOM问题。-你如何处理这个缓存问题？答：根据实际经验值，我们将缓存的一部分计算为已用内存，尽量接近真实使用值。此外，对于容器，内存警报阈值适当降低。同时增加集装箱OOM的报警。如果升级到CentOS 7，还可以配置kmem.limit_in_bytes进行某些限制。问：你能告诉我们更多关于你的容器网络的隔离吗？答：访问隔离。目前第二层隔离主要使用VLAN，未来会考虑使用VXLAN进行隔离。网络流量控制，我们只是用OVS自带的基于端口的QoS，底层用TC 。稍后将考虑基于流的流控制。问：这一套你们都用CentOS 6.5吗？这项技术的实现。是更多参与运维还是开发？答：生产环境的稳定是第一位的。CentOS 6.5主要负责整个公司的运维。我们会在升级大版本的时候给出运维建议。同时做好虚拟化本身的稳定性。问：容器如何与容器直接通信？如何设置网络？你是说在同一台物理机器上吗？目前还是通过IP沟通。具体网络可以采用网桥模式或VLAN模式。我们使用开放式vSwitch支持VLAN模式，可以实现容器之间的隔离或通信。问：你使用nova-api来集成Dcoker吗？可以使用Docker的高级功能吗，比如docker-api？另外，为什么不用热来整合Docker呢？答：我们用的是nova-docker，一个开源软件。nova-docker是StackForge上的一个开源项目。作为nova的一个插件，它取代了现有的libvirt，通过调用Docker的RESTful接口来控制容器的启动和停止。到底是用Heat还是NOVA来整合Docker，在业内一直有争议。我们更关心我们想要解决的问题。热本身依赖于一个复杂的关系，但它并没有在行业内广泛使用，否则社区不会推出Magnum 。问：目前，你们是否有集装箱穿越DC或类似方向的业务？答：我们在多个机房部署了多个集群，每个机房都有一个独立的集群。在此基础上，我们开发了自己的管理平台，可以实现多个集群的统一管理。同时我们已经搭建了Docker注册表V1，内部准备升级到Docker注册表V2，可以实现Docker镜像的跨DC镜像功能。问：我现在也在推广Docker的持续集成和集群管理，但是我发现更多容器的管理也是一个问题，比如容器的灵活管理或者资源监控。Kubernetes和Mesos哪个好？如果用于商业，如何解析外部域名？因为都是通过主机通信，但是它只有一个外部IP？答：对于Kubernetes和Mesos，我们还在预研阶段。我们目前的P层调度是自行开发的。我们通过etcd维护实例的状态、端口和其他信息。对于第7层，可以用Nginx解决；对于第4层，它需要依赖命名服务。我们内部有自主开发的命名服务，可以解决这些问题。虽然对外只有一个IP，但是暴露的端口是不一样的。
问：你考虑过使用Hyper Hypernetes吗？在保证启动速度的同时实现容器与主机内核的隔离？答：我们一直在关注Hyper 。Hyper是一个非常好的想法，我们不排除在未来使用Hyper 。其实我们最希望Hyper实现的是热迁移，Docker目前还做不到。问：您的主机通常使用什么配置？单机还是云服务器？答：我们有自己的机房，使用独立的服务器和物理机。问：哪个解决方案用于容器跨主机通信？答：容器必须使用第三层来跨主机通信，即IP 。容器可以有独立的IP，也可以通过映射主机的IP端口来实现。目前我们更多使用的是独立ip，便于管理。问：感觉贵公司对Docker的使用更像是虚拟机。为什么不仅仅从容器的角度考虑使用呢？是历史原因吗？答：我们首先考虑的是用户的接受度和改造成本。从用户的角度来看，他不关心业务是在容器中运行还是在虚拟机中运行。他更关心的是应用的部署效率，以及对应用本身的稳定性和性能的影响。从容器的角度来看，业务方的一些现有应用程序可能需要进行改革。比如日志系统，全链路监控等等。当然最重要的是对现有运维体系的冲击会比较大。容器的管理对于运维来说是一个挑战，运维的验收需要一个过程。当然，用Docker作为容器封装应用，实现PaaS的部署和动态调度，是我们的目标。其实我们也在朝这个方向努力。这也需要业务端拆分应用，实现微服务，这需要一个过程。问：实际上，我们也想用容器作为虚拟机。你在虚拟机上运行什么中间件？我们想解决测试key和大量相对独立环境的矛盾WebLogic？答：我们经营很多业务，从前端网站到后端中间件服务。我们的中间件服务是另一个团队开发的产品，实现了前后台业务逻辑的分离。问：贵公司是否使用OpenStack同时管理Docker和KVM？是有自己的Web配置接口，还是只是用API来管理？答：我们有自主开发的网络管理平台。我们希望通过一个平台管理多个集群，连接运维、日志、监控等系统，暴露出统一的API接口。问：在上面分享的一个案例中，关于2.6内核命名空间bug，Docker环境可以安装在这个较低的内核中吗？Docker对procfs的隔离目前还不完善。你们开发的容器工具是基于应用层还是内核需要修改？答：安装使用应该没有问题，但是如果去生产环境，就需要综合考虑了。主要是稳定性和隔离性不够。较低版本的内核更容易导致系统崩溃或各种严重问题。有些不是bug，是功能不完善。比如在容器中创建桥会导致崩溃，这是网络命名空间内核支持不完善造成的。我们开发的容器工具是基于应用的，不需要修改内核。问：关于冗余灾难有没有更详细的介绍，比如如何实现离线状态下的数据恢复？答：如何在离线状态下恢复数据？这个问题我之前已经回答过了。具体来说，就是用dmsetup create命令创建一个临时dm设备，并映射到docker实例使用的dm设备号。通过安装该临时设备，可以恢复原始数据。其他冗余的灾难计划因为内容更多，可以重新整理和共享。你可以关注http://mogu.io/,然后我们将分享它。问：贵公司当前的在线容器化系统是无状态的还是有状态的？你在选择场景时有哪些考虑或困难？答：互联网公司的应用主要是无状态的。事实上，有状态业务可以从业务层面转化为部分有状态或完全无状态的应用。你说的场景选择我不太懂，但是我们尽量满足业务端的各种需求。
对于那些对稳定性要求高或者对时延IO特别敏感的，比如redis服务，我们不推荐使用容器，这些服务不可能完全隔离或者无状态。工艺有多好或者多线程有多好等等。并不代表因为Spark很流行就一定要用。遇到这些问题的时候，我们还在研究图计算：作为一种流行的大数据处理技术？陈，它可以很快创建一个星火集群供大家使用。我们用OpenStack？陈。问：Hadoop软硬件协同优化，Spark在采用OpenPOWER架构的服务器上的性能分析和优化：这次演讲你们会分享哪些话题？问吧。参与Spark社区的讨论。曾在《程序员》杂志上分享多篇关于分布式计算、Docker和Spark构建SuperVessel大数据公有云的文章” 。向上游贡献代码是切入SQL的好方法，他在大数据、MapRece性能分析和调优工具领域拥有八项技术专利。例如，许多公司正在使用Impala进行数据分析：企业希望拥抱Spark技术，优化Swift对象存储的性能，等等。比如更好的与Docker Container整合，大数据云方向的技术领导者，Spark还有很多工作要做？企业要想快速应用Spark，应该怎么做？具体的技术选择应该基于自己的业务场景。Docker容器因其在提高云的资源利用率和生产效率方面的优势而备受关注。将高性能FPGA加速器应用于大数据平台等项目，然后调整相关参数来优化这些性能瓶颈。一些公司正在使用Storm和Samaza进行流式计算：与MapRece相比，性能大幅提升？

文章插图
请问想学云计算需要具备什么基础
云计算和大数据是互联网催生的新型专业云计算的关键技术。有三点：虚拟化技术：云计算的虚拟化技术不同于传统的单一虚拟化。它涵盖了整个IT架构，包括资源、网络、应用和桌面的全系统虚拟化。其优点是可以隔离所有的硬件设备、软件应用和数据，打破硬件配置、软件部署和数据分发的边界，实现动态的it架构，实现资源的集中管理。对于信息系统仿真来说，云计算虚拟化技术的应用意义不仅在于提高资源利用率和降低成本，还在于提供强大的计算能力。众所周知，信息系统仿真系统是一个计算量巨大的复杂系统，计算能力对系统的运行效率、准确性和可靠性有很大的影响。虚拟化技术可以将大量分散的、未被充分利用的计算能力整合到高计算负载的计算机或服务器上，实现全网资源的统一调度和使用，从而在存储、传输、运行等计算方面实现高效率。分布式资源管理技术：大多数情况下，信息系统仿真系统会处于多节点并发执行环境。为了保证系统状态的正确性，必须保证分布式数据的一致性。为了解决分布式一致性的问题，计算机领域的许多公司和研究人员提出了各种协议，这些协议是一些需要遵循的规则。也就是说，在云计算出现之前，解决分布式一致性的问题依赖于很多协议。但是对于大规模，甚至超大规模的分布式系统，不可能保证所有子系统和子系统使用相同的协议，无法解决分布一致性的问题。云计算中的分布式资源管理技术成功解决了这一问题。Google的Chubby是最著名的分布式资源管理系统，它实现了Chubby服务锁机制，使得解决分布式一致性问题不再仅仅依靠一个协议或者一个算法，而是拥有一个统一的服务。并行编程技术：云计算采用并行编程模式。在并行编程模式下，并发处理、容错、数据分布、负载均衡等细节。被抽象成一个函数库。通过统一的接口，用户的大规模计算任务被自动并发执行和分布，即一个任务被自动划分为多个子任务并行处理海量数据。对于信息系统仿真等复杂系统的编程来说，并行编程模式是一场颠覆性的革命。它是由网络计算等一系列优秀成果发展而来的，因此更形象地体现了面向服务架构(SOA)技术。可以预见，如果将这种并行编程模式引入信息系统仿真领域，必将带来信息系统仿真软件建设的巨大进步。如果想专业学习云计算，需要更多的时间和精力。车间的课程很好。你可以根据自己的实际需要，现场看一下。试听好了，就选适合自己的。只要努力学习真才实学，前途自然不会差。