在openstack虚拟机和swift啥关系
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了在openstack虚拟机和swift啥关系相关的知识，希望对你有一定的参考价值。
参考技术A OpenStack其实有三个与存储相关的组件，这三个组件被人熟知的程度和组件本身出现时间的早晚是相符的，按熟悉程度排列如下：Swift——提供对象存储（ObjectStorage），在概念上类似于AmazonS3服务，不过swift具有很强的扩展性、冗余和持久性， 参考技术B OpenStack由以下五个相对独立的组件构成：- OpenStack Compute(Nova)是一套控制器，用于虚拟机计算或使用群组启动虚拟机实例;
- OpenStack镜像服务(Glance)是一套虚拟机镜像查找及检索系统，实现虚拟机镜像管理;
- OpenStack对象存储(Swift)是一套用于在大规模可扩展系统中通过内置冗余及容错机制，以对象为单位的存储系统，类似于Amazon S3;
- OpenStack Keystone，用于用户身份服务与资源管理以及
- OpenStack Horizon，基于Django的仪表板接口，是个图形化管理前端。
这个起初由美国国家航空航天局和Rackspace在2010年末合作研发的开源项目，旨在打造易于部署、功能丰富且易于扩展的云计算平台。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性，企图成为数据中心的操作系统，即云操作系统。
KVM：开放虚拟化技术
KVM(Kernel-based Virtual Machine)是一个开源的系统虚拟化模块，它需要硬件支持，如Intel VT技术或者AMD V技术，是基于硬件的完全虚拟化，完全内置于Linux。
2008年，红帽收购Qumranet获得了KVM技术，并将其作为虚拟化战略的一部分大力推广，在2011年发布RHEL6时支持KVM作为唯一的hypervisor。KVM主打的就是高性能、扩展性、高安全，以及低成本。
与Linux的缘分
一个被某些热心支持者成为云时代的Linux，是公有云与私有云的开源操作系统。一个则是Linux内核的一部分，将Linux转换成一个Type-1 hypervisor，无需任何变更就能享受现有的Linux内核进程调度、内存管理和设备支持。
OpenStack炙手可热，它如同Linux一样，旨在构建一个内核，所有的软件厂商都围绕着它进行工作。OpenStack的许多子项目，对云计算平台中的各种资源(如计算能力、存储、网络)提供敏捷管理。此外，OpenStack也提供对虚拟化技术的支持。
KVM集成在Linux的各个主要发行版本中，使用Linux自身的调度器进行管理。KVM专注于成为最好的虚拟机监控器，是使用Linux企业的不二选择，加上它还支持Windows平台，所以也是异构环境的最佳选择。
OpenStack与KVM都发展迅猛
OpenStack是一个拥有众多支持者的大项目。时至今日，已经有超过180家企业和400多位开发人员对这一项目积极地做着贡献，而其生态系统甚至更为庞大，已经超过了5600人和850家机构。在今年9月，OpenStack基会正式成立。白金会员有红帽、IBM与惠普等，黄金会员包括思科、戴尔与英特尔等。
OpenStack基本上是一个软件项目，有近55万行代码。分解成核心项目、孵化项目，以及支持项目和相关项目。除了以上提及的五大组成，与虚拟网络有关的Quantum首次被列为核心项目。
KVM是一个脱颖而出的开放虚拟化技术。它是由一个大型的、活跃的开放社区共同开发的，红帽、IBM、SUSE等都是其成员。2011年，IBM、红帽、英特尔与惠普等建立开放虚拟化联盟(OVA)，帮助构建KVM生态系统，提升KVM采用率。如今，OVA已经拥有超过250名成员公司，其中，IBM有60多位程序员专门工作于KVM开源社区。
OpenStack与KVM的解决方案
在去年9月22日发布Diablo之后，OpenStack社区随即开始着手新版本的设计和开发，新版本开发代号为Essex。此前发布有四个版本：Austin、Bexar、Cactus与Diablo。新版本发布包含云计算控制中心Nova、镜像服务Glance、认证服务Keystone和Dashboard项目Horizon，也包括对象存储项目Swift。
由此可以看出，OpenStack是一个框架，一个可以建立公有云和私有云的基础架构。它并不是一个现成的产品，要想开展基础架构方面的工作，企业需要顾问和开发人员。很多时候还需要第三方的集成工具。
KVM可通过购买Linux版本获得，或作为独立hypervisor单独购买。最近，IBM KVM(北京)卓越中心落户北京，展示IBM及合作伙伴基于KVM的产品，包括IBM SmartCloud Entry、IBM System Director VMControl、Red Hat Enterprise Virtualization及SUSE云。
OpenStack与KVM相互辉映
OpenStack几乎支持所有的虚拟化管理程序，不论是开源的(Xen与KVM)还是厂商的(Hyper-V与VMware)。但在以前，OpenStack是基于KVM开发的，KVM常常成为默认的虚拟机管理程序。两者都使用相同的开放源理念与开发方法。
如今，多数企业用户在IT环境中使用了超过一种的虚拟化软件，有一半的用户选择将开源产品作为性价比更高的虚拟化替代方案。IDC报道中指出，OpenStack是KVM增长的一个巨大机会。OpenStack是一个具有巨大的行业发展动力，并拥有一个充满活力的社区的云计算平台，有95%的OpenStack平台由KVM驱动。因此，随着OpenStack的增长，KVM也会相应增长。
实现OpenStack与容器互动 Magnum项目备受瞩目
软件容器不同于托管它们的虚拟机和虚拟层，它们需要一套完全不同的管理工具，以便在大型企业、超大规模数据中心和云环境中被使用。我们无法用Docker全面替代虚拟层，并且想当然地认为所有东西都能够正常工作。现实情况要比这复杂的多。
更为重要的是，Docker和OpenVZ、Rocket、LXC等容器解决方案正在将软件和它们的运行时打包、管理，并逐渐开始分解和孤立“微服务”应用的模块，因为它们不仅能够在独立的服务器集群中被升级、管理和迁移，同时还能够继续协同工作。这种在不为系统和网络性能增加过多的虚拟化日常开支情况下，管理软件堆栈的能力是HPC和分析领域中广泛部署容器的原因之一。而在HPC和分析领域中，流行使用裸机已经有很长的时间了。
在OpenStack世界，Magnum项目虽然是一个相对较新的项目，但是它们扮演了一个重要角色。Magnum 容器即服务团队主管Adrian Otto日前就Magnum项目，以及对其成熟时的期望值展开了一些探讨。（Otto还担任Solum项目的主管。）
Magnum项目推出的同时，OpenStack社区内部的技术人员也在考虑应该如何管理容器。在Linux世界，管理容器至少由控制组和命名空间两大核心功能组成，这两大功能类似于搜索引擎巨头谷歌开发的隔离大型基础设施中工作负载的技术。谷歌在过去八年中一直在为这些功能提供帮助，帮助将这些功能植入到Linux内核当中。
Otto称，起初虽然未必每个人都会认同，但是他还是建议将现有的OpenStack计算控制器Nova拓展用于控制Linux环境中的容器；最终致力于解决这一问题的技术人员认识到，容器完全不同于虚拟机，他们的管理系统也完全不同于其项目所使用的虚拟层。
Magnum项目由此诞生。它们所做的工作是实现OpenStack与集群中的容器管理系统的互动。这其中包括用于Docker容器和谷歌Kubernetes的Docker Swarm。Docker Swarm不仅能够控制Docker容器，还可以为CoreOS 的AppC容器格式提供支持。此外，它们还可以与针对容器的flannel虚拟网络服务实现协作。
目前，CoreOS正在考虑将flannel虚拟网络服务作为其Tectonic容器管理系统的一部分。尽管这些容器管理系统对于他们的工作来说已经足够了，但是出于多种原因，他们还需要像OpenStack这样的云控制器系统。首先，企业创建云的目的可能是希望拥有许多在其集群上运行的Swarm和Kubernetes实例，为（运行在公有云上的）客户、工作负载或（企业中的）业务部门提供所需要的隔离。一些东西必须要为每个独立的Swarm或Kubernetes集合管理资源分配。
其次，Magnum可以作为一个适合不同容器工具管理风格的接口。Otto说：“OpenStack不会对用户所选择的虚拟化或网络类型有所挑剔，我们也不会对用户所选择的容器技术有所限制。”这意味着如果用户希望接入支持LXC、OpenVZ、rkt或其他容器格式与运行时的容器管理系统，那么Magnum的可插入式架构将使之成为可能。
Magnum支持并不仅仅局限于Linux，即便是目前现有的容器也可以某种形式使用控制组和命名空间。正如之前所报道的那样，微软正在将Windows Server容器和Hyper-V容器这两个不同类型的容器整合至Windows Server 2016（也就是之前所说的Windows Server 10）之中。这两个容器都可以由Docker Engine管理。很自然地，Magnum最终将能够覆盖Docker或微软自己的容器管理工具，以管理OpenStack云中的微软容器与虚拟层技术。
Otto在谈及对Docker非常友好的Windows Server 版本时说：“我认为，在用户能够真正使用之前还需要数年开发时间，不过这真的非常重要。”
“Magnum会为OpenStack配置服务Heat请求计算实例，但是它们并不在意提供的是哪种类型的计算实例。它们可能来自裸机服务器的Nova，也可能是运行在Xen或KVM上的Nova虚拟机，或者是运行在其他容器内部的实例。这样一来，我能够拥有自己的容器操作环境，而这个环境运行在容器内部。这听起来可能有点让人感到混乱，但是这恰恰是我们想这么做的原因。因此我们并不在意底层云使用的是哪种virt驱动。”Otto说。
展望未来，Otto认为，必须要解决如何将容器与虚拟网络结合在一起的问题。尽管还没有做出任何决定，但是这一理念与一起使用虚拟机的解决方案类似。在它们上面不必增加任何管理层，用户使用虚拟交换机就可能将容器彼此连接在一起。在许多情况下，企业将在虚拟机内部运行容器，与单独使用虚拟机相比，前者可以提供更高的安全性和更好的资源隔离。
在OpenStack的众多项目中，Magnum还是一个相对较新的项目。OpenStack社区在2014年11月才接受其首个提交，并在2015年3月底了推出其首个版本。Otto称，Magnum的复杂程度不亚于在OpenStack项目早期阶段出现的Nova控制器。得益于所有工作的不断推进，以及OpenStack开发者在开发Nova过程所积累的丰富经验，Magnum在OpenStack计划于2015年10月推出的“Liberty”版本时将进入生产级。
以上是关于在openstack虚拟机和swift啥关系的主要内容，如果未能解决你的问题，请参考以下文章