OpenStack云计算相关问题解答

OpenStack支持哪几种虚拟化技术？

在 OpenStack 环境中，计算服务通过 API 服务器来控制虚拟机管理程序，它具备一个抽象层，可以在部署时选择一种虚拟化技术来创建虚拟机，向用户提供云服务。

KVM

基于内核的虚拟机（Kernel-based Virtual Machine,KVM）是通用的开放虚拟化技术，也是OpenStack用户使用较多的虚拟化技术，它支持OpenStack的所有特性。

Xen

Xen是部署快速、安全、开源的虚拟化软件技术，可使多个同样的操作系统或不同操作系统的虚拟机运行在同一主机上。Xen技术主要包括XenServer（服务器虚拟化平台）、Xen Cloud Platform （XCP，云基础架构）、XenAPI（管理XenServer和XCP的API程序）、XAPI（XenServer和XCP的主守护进程，可与XenAPI直接通信）、基于Libvirt的Xen。OpenStack通过XenAPI支持XenServer和XCP两种虚拟化技术。不过，在RHEL等平台上，OpenStack使用的是基于Libvirt的Xen。

容器

容器是在单一 Linux 主机上提供多个隔离的 Linux 环境的操作系统级虚拟化技术。不像基于虚拟化管理程序的传统虚拟化技术，容器并不需要运行专用的客户操作系统。目前的容器有以下两种技术。

（1）Linux容器（Linux Container,LXC）：提供了在单一可控主机节点上支持多个相互隔离的服务器容器同时执行的机制。

（2）Docker：一个开源的应用容器引擎，让开发者可以把应用以及依赖包打包到一个可移植的容器中，然后发布到任何流行的Linux平台上。利用Docker也可以实现虚拟化，容器完全使用沙箱机制，相互之间不会有任何接口。

Docker 的目的是尽可能减少容器中运行的程序，减少到只运行单个程序，并且通过 Docker来管理这个程序。LXC可以快速兼容所有应用程序和工具，以及任意管理和编制层次，来替代虚拟机。

虚拟化管理程序提供更好的进程隔离，呈现一个完全的系统。LXC/Docker除了一些基本隔离，并未提供足够的虚拟化管理功能，缺乏必要的安全机制。基于容器的方案无法运行与主机内核不同的其他内核，也无法运行一个完全不同的操作系统。目前 OpenStack 社区对容器的驱动支持还不如虚拟化管理程序。在OpenStack项目中，LXC属于计算服务项目Nova，通过调用Libvirt来实现；Docker驱动是一种新加入的虚拟化管理程序的驱动，目前无法替代虚拟化管理程序。

Hyper-V

Hyper-V是微软推出的企业级虚拟化解决方案。Hyper-V的设计借鉴了Xen，管理程序采用微内核的架构，兼顾了安全性和性能的要求。Hyper-V作为一种免费的虚拟化方案，在OpenStack中得到了很多支持。

VMware ESXi

VMware提供业界领先且可靠的服务器虚拟化平台和软件定义计算产品，其中ESXi虚拟化平台用于创建和运行虚拟机及虚拟设备。在OpenStack中它也得到了支持，但是如果没有vCenter和企业级许可，一些API的使用会受限。

Baremetal与Ironic

有些云平台除了提供虚拟化和虚拟机服务，还提供传统的主机服务。在 OpenStack 中可以将Baremetal（裸金属）与其他部署有虚拟化管理程序的节点通过不同的计算池（可用区域，Availabity Zone）一起管理。

Baremetal是计算服务的后端驱动，与Libvirt驱动、XenAPI驱动、VMware驱动一样，只不过它是用来管理没有虚拟化的硬件，主要通过PXE和IPMI进行控制管理。

现在Baremetal已由Ironic所替代，Nova管理的是虚拟机的生命周期，而Ironic管理的是主机的生命周期。Ironic提供了一系列管理主机的API接口，可以对“裸”操作系统的主机进行管理，从主机上架安装操作系统到主机下架维修，可以像管理虚拟机一样地管理主机，创建一个Nova计算物理节点，只需告诉Ironic，然后自动地从镜像模板中加载操作系统到nova-compute安装完成即可。Ironic解决主机的添加、删除、电源管理、操作系统部署等问题，目标是成为主机管理的成熟解决方案，让OpenStack不仅可以在软件层面解决云计算问题，而且供应商可以对应自己的服务器开发Ironic插件。

简单描述KVM架构。

KVM作为Hypervisor主要包括两个重要的组成部分：一个是Linux内核的KVM模块，主要负责虚拟机的创建、虚拟内存的分配、VCPU寄存器的读写以及VCPU的运行；另一个是提供硬件仿真的 QEMU，用于模拟虚拟机的用户空间组件、提供 I/O 设备模型和访问外设的途径。

在KVM模型中，每一个虚拟机都是一个由Linux调度程序管理的标准进程，可以在用户空间启动客户机操作系统。一个普通的Linux进程有两种运行模式：内核和用户，而KVM增加了第三种模式——客户模式，客户模式又有自己的内核和用户模式。

当新的虚拟机在KVM上启动时（通过一个称为kvm的实用程序），它就成为主机操作系统的一个进程，因此就可以像其他进程一样调度它。但与传统的 Linux 进程不一样，客户端被 Hypervisor标识为处于Guest模式（独立于内核和用户模式）。每个虚拟机都是通过/dev/kvm设备映射的，它们拥有自己的虚拟地址空间，该空间映射到主机内核的物理地址空间。KVM使用底层硬件的虚拟化支持来提供完整的（原生）虚拟化。I/O 请求通过主机内核映射到在主机上（Hypervisor）执行的QEMU进程。

什么是OpenStack？

OpenStack是一个云操作系统，通过数据中心控制大型的计算、存储、网络资源池，并可以使用Web界面和API进行管理。

OpenStack项目旨在提供开源的云计算解决方案以简化云的部署过程，实现类似AWS EC2和S3的IaaS服务。其主要应用场合包括Web应用、大数据、电子商务、视频处理与内容分发、大吞吐量计算、容器优化、主机托管、公共云、计算启动工具包（Compute Starter Kit）和DBaaS（数据库即服务，DateBase-as-a-Service）等。

Open意为开放，Stack意为堆栈或堆叠，OpenStack是一系列开源软件的组合，包括若干项目。每个项目都有自己的代号（名称），包括不同的组件，每个组件又包括若干服务，一个服务意味着运行的一个进程。这些组件部署灵活，支持水平扩展，具有伸缩性，支持不同规模的云平台。

OpenStack最初仅包括Nova和Swift两个项目，现在已经有数十个项目。这些项目之间相互关联，协同管理各类计算、存储和网络资源，提供云计算服务。

简述OpenStack的概念架构与逻辑架构。

OpenStack的概念架构

OpenStack通过一组相关的服务提供一个基础设施即服务（IaaS）的解决方案。这些服务以虚拟机为中心。虚拟机主要是由Nova、Glance、Cinder和Neutron 4个核心模块进行交互的结果。Nova为虚拟机提供计算资源，包括vCPU、内存等。Glance为虚拟机提供镜像服务，安装操作传统的运行环境。Cinder提供存储资源，类似传统计算机的磁盘或卷。Neutron为虚拟机提供网络配置，以及访问云平台的网络通道。

云平台用户（开发者与运维人员，甚至包括其他OpenStack组件）在经Keystone服务认证授权后，通过Horizon或REST API模式创建虚拟机服务。创建过程包括利用Nova服务创建虚拟机实例，虚拟机实例采用Glance提供的镜像服务，然后使用Neutron为新建的虚拟机分配IP地址，并将其纳入虚拟网络中，之后再通过Cinder创建的卷为虚拟机挂载存储块。整个过程都在Ceilometer模块的资源监控下，Cinder 产生的卷（Volume）和 Glance 提供的镜像（Image）可以通过 Swift 的对象存储机制进行保存。

Horizon、Ceilometer、Keystone 提供访问、监控、身份认证（权限）功能，Swift 提供对象存储功能，Heat实现应用系统的自动化部署，Trove用于部署和管理各种数据库，Sahara提供大数据处理框架，而Ironic提供裸金属云服务。

云平台用户通过nova-api等来与其他OpenStack服务交互，而这些OpenStack服务守护进程通过消息总线（动作）和数据库（信息）来执行API请求。

消息队列为所有守护进程提供一个中心的消息机制，消息的发送者和接收者相互交换任务或数据进行通信，协同完成各种云平台功能。消息队列将各个服务进程解耦，所有进程可以任意分布式部署，协同工作在一起。目前RabbitMQ是默认的消息队列实现技术。

SQL 数据库保存了云平台大多数创建和运行时的状态，包括可用的虚拟机实例类型，正在使用的实例、可用的网络和项目等。理论上，OpenStack可以使用任一支持SQL-Alchemy的数据库。

OpenStack的逻辑架构

要设计、部署和配置OpenStack，管理员必须理解其逻辑架构（Logical Architecture）。

OpenStack包括若干称为OpenStack服务的独立组件。所有服务均可通过一个公共的身份服务进行身份验证。除了那些需要管理权限的命令，每个服务之间均可通过公共API进行交互。

每个 OpenStack 服务又由若干组件组成，包含多个进程。所有的服务至少有一个 API 进程，用于侦听 API 请求，对这些请求进行预处理，并将它们传送到该服务的其他组件。除了认证服务，实际工作是由具体的进程完成的。

至于一个服务的进程之间的通信，则使用AMQP消息代理。服务的状态存储在数据库中。部署和配置OpenStack云时，可以从几种消息代理和数据库解决方案中进行选择，如RabbitMQ、MySQL、MariaDB和SQLite。

用户访问OpenStack有多种方法，可以通过由Horizon仪表板服务实现的基于Web的用户界面，也可以通过命令行客户端，或者通过浏览器插件或curl发送API请求。对于应用程序来说，可以使用多种软件开发工具包（Software Development Kit,SDK）。所有这些访问方法最终都要将REST API调用发送给各种不同的OpenStack服务。

在实际的部署方案中，各个组件可以部署到不同的物理节点上。OpenStack本身是一个分布式系统，不仅各个服务可以分布部署，服务中的组件也可以分布部署。这种分布式特性让OpenStack具备极大的灵活性、伸缩性和高可用性。当然，从另一个角度来看，这一特性也使OpenStack比一般系统复杂，学习难度也更大。

OpenStack的物理架构

OpenStack是分布式系统，必须从逻辑架构映射到具体的物理架构，将各个项目和组件以一定的方式安装到实际的服务器节点，部署到实际的存储设备上，并通过网络将它们连接起来，这就是OpenStack的物理部署架构。

OpenStack的部署分为单节点部署和多节点部署两种类型。单节点部署就是将所有的服务和组件都放在一个物理节点上，通常是用于学习、验证、测试或者开发。多节点部署就是将服务和组件分别部署在不同的物理节点上。常见的节点类型有控制节点（Control Node）、计算节点（Compute Node）、存储节点（Storage Node）和网络节点（Network Node）

OpenStack组件之间是如何通信的？

OpenStack组件之间的通信关系，可分为以下4种类型。

基于AMQP

基于AMQP（Advanced Message Queuing Protocol，高级消息队列协议）进行的通信，主要是每个项目内部各个组件之间的通信，如 Nova 的 nova-compute 与 nova-scheduler 之间，Cinder 的cinder-scheduler 和cinder-volume之间。

虽然通过AMQP进行通信的大部分组件属于同一个项目，但是并不要求它们都安装在同一个节点上，这就大大方便了系统的水平（横向）扩展。管理员可以对其中的各个组件分别按照其负载进行水平扩展，使用不同数量的主机节点承载这些服务。

基于SQL的通信

通过数据库连接实现的通信大多用于各个项目内部，也不要求数据库和项目中的其他组件安装在同一节点上，可以分开安装，也可以专门部署数据库服务器，通过基于SQL的连接进行通信。

基于HTTP进行通信

通过各项目的API建立的通信关系基本都属于这一类，这些API都是RESTful Web API。最常见的就是通过Horizon仪表板或者命令行接口对各组件进行操作时产生的这种通信，然后就是各组件通过Keystone 对用户身份进行认证时使用的这种通信。还有一些基于 HTTP 进行通信的情形，如nova-compute在获取镜像时对Glance API的调用、Swift数据的读写等。

通过Native API实现通信

这是OpenStack各组件和第三方软硬件之间的通信方式。例如，Cinder与存储后端之间的通信，Neutron的代理（即插件）与网络设备之间的通信，都需要调用第三方的设备或第三方软件的API，这些API被称为Native API，这些通信是基于第三方API的。

OpenStack的节点类型有哪些？

常见的节点类型有控制节点（Control Node）、计算节点（Compute Node）、存储节点（Storage Node）和网络节点（Network Node）

控制节点

控制节点又称管理节点，安装并运行各种OpenStack控制服务，负责管理、节制其余节点，执行虚拟机建立、迁移、网络分配、存储分配等任务。OpenStack的大部分服务都是运行在控制节点上，通常包括以下服务。

1. 支持服务（Supporting Service）

• 数据库服务器，如SQL数据库。
• 消息队列服务，如RabbitMQ。
• 网络时间协议（Network Time Protocol,NTP）服务。

2. 基础服务
   运行Keystone认证服务、Glance镜像服务、Nova计算服务的管理组件、Neutron网络服务的管理组件、多种网络代理（Networking agent）和Horizon仪表板。
3. 扩展服务
   运行Cinder块存储服务、Swift对象存储服务、Trove数据库服务、Heat编排服务和Ceilometer计量服务的部分组件。这对于控制节点来说是可选的。

控制节点一般只需要一个网络端口用于通信和管理各个节点。

计算节点

计算节点是实际运行虚拟机的节点，主要负责虚拟机的运行，为用户创建并运行虚拟机，为虚拟机分配网络。通常包括以下服务。

1. 基础服务
   Nova计算服务的Hypervisor（虚拟机管理器）组件，提供虚拟机的创建、运行、迁移、快照等各种围绕虚拟机的服务，并提供API与控制节点对接，由控制节点下发任务。默认计算服务使用的Hypervisor是KVM。
   网络插件代理，用于将虚拟机实例连接到虚拟网络中，通过安全组为虚拟机提供防火墙服务。
2. 扩展服务
   Ceilometer计量服务代理，提供计算节点的监控代理，将虚拟机的情况反馈给控制节点。
   虚拟机可以部署多个计算节点，一个计算节点至少需要两个网络端口，一个与控制节点进行通信，受控制节点统一调配；另一个与网络节点及存储节点进行通信。

存储节点

存储节点负责对虚拟机的外部存储进行管理等，即为计算节点的虚拟机提供持久化卷服务。这种节点存储需要的数据，包括磁盘镜像、虚拟机持久性卷。存储节点包含Cinder和Swift等服务，可根据需要安装共享文件服务。

块存储和对象存储可以部署在同一个存储节点上，也可以分别部署块存储节点和对象存储节点。不论采用哪种方式，都可以部署多个存储节点。

最简单的网络连接存储节点只需要一个网络接口，直接使用管理网络在计算节点和存储节点之间进行通信。而在生产环境中，存储节点最少需要两个网络接口，一个连接管理网络，与控制节点进行通信，接受控制节点下发的任务，受控制节点统一调配；另一个专门的存储网络（数据网络），与计算节点和网络节点进行通信，完成控制节点下发的各类数据传输任务。

网络节点

网络节点可实现网关和路由的功能，它主要负责外部网络与内部网络之间的通信，并将虚拟机连接到外部网络。网络节点仅包含Neutron服务，Neutron负责管理私有网段与公有网段的通信，以及管理虚拟机网络之间的通信拓扑，管理虚拟机上的防火墙等。

网络节点通常需要3个网络端口，分别用来与控制节点进行通信、与除控制节点外的计算节点和存储节点之间的通信、外部的虚拟机与相应网络之间的通信。

网络节点根据虚拟网络选项来决定要部署的服务和组件，它有两种选择，一种是提供者网络（Provider Networks，又译为供应商网络），另一种是自服务网络（Self-service Networks）

1. 提供者网络
   选择提供者网络选项，将以最简单的方式部署 OpenStack 网络服务，它使用基本的二层（网桥/交换机）服务和虚拟局域网（Virtual Local Area Network,VLAN）分段。它实质上是将虚拟网络桥接到物理网络，并依靠物理网络基础设施提供的三层（路由）服务。另外，还需一个动态主机配置协议（Dynamic Host Configuration Protocal,DHCP）服务为虚拟机实例提供IP地址信息。
   OpenStack用户需要了解底层网络基础设施的更多信息来创建虚拟网络，以精确匹配基础设施。
   提供者网络不支持自服务（私有）网络、三层路由服务，以及像 LBaaS（负载平衡服务）和FWaaS（防火墙服务）这样的高级服务。如果要使用这些特性，应选择自服务网络选项。
2. 自服务网络
   选择自服务网络选项，会在提供者网络的基础上增加三层（路由）服务，这样才能够使用像VXLAN这样的覆盖分段方法。它实质上是通过NAT将虚拟网络路由到物理网络。另外，该选项将提供像LBaaS和FWaaS这样的高级服务。
   OpenStack无须了解数据网络的底层基础设施即可创建虚拟网络。如果配置相应的二层插件，这也会包括VLAN。
   在提供者网络架构中，所有实例均可直接连接到提供者网络。在自服务（私有）网络架构中，实例可以连接到自服务或提供者网络。自服务网络可以完全在OpenStack环境中或者通过外部网络使用NAT方式提供某种级别的外部网络访问。

节点的组合

OpenStack是一个松散耦合系统，具有弹性的设计和部署，上述节点可以根据需要进行整合。

可以从控制节点中分出一个专门的API节点，API节点去除Neutron服务之外的管理控制服务（如Nova、Glance、KeyStone等）。API节点又可以与网络节点合二为一。

数据库服务器和消息队列协议可以部署在控制节点（或 API 节点）上，也可以运行于网络节点上。Glance、Keystone、Cinder服务可以在API节点上运行，也可以在网络节点上运行，还可以在控制节点上运行。既可以创建单独的认证节点来运行Keystone服务，还可以创建单独的镜像节点来运行Glance服务。

cinder-api与cinder-scheduler需要在同一节点上运行，共用同一配置文件；nova-api、nova-scheduler、nova-novncproxy服务应在同一节点上运行，共用相同的配置文件。

存储节点可以合并到某个计算节点上。

nova-compute与Neutron（openswitch、neutron-openvswitch-agent）服务必须在一个节点上运行，否则虚拟机实例无法获得网络分配。

OpenStack的物理网络有哪些类型？

OpenStack的物理部署就是将承载不同服务的物理节点通过物理网络进行连接，从而使各个服务在云平台上协同工作。这里所讲的是主机节点之间的物理网络连接，而不是OpenStack网络服务中的虚拟网络。OpenStack环境中的物理网络配置往往包括以下类型。

公共网络（Pulic Network）

公共网络通常使用由电信运营商提供的公共IP地址。

外部网络（External Network）

数据中心 Intranet用于为虚拟机分配浮动的 IP地址，让 Internet用户能够访问该网络上的 IP地址。

管理网络（Management Network）

管理网络提供OpenStack各个组件之间的内部通信，以及API访问端点（Endpoint）。为安全考虑，该网络必须限制在数据中心内，也就是说，IP 地址通常只能在数据中心内部访问。这是一个单独的网络，确保系统管理和监控访问域虚拟机网络分离，以防止来自用户虚拟机网络的监听和攻击，保证云平台的安全性。

API网络

API网络用于为用户提供OpenStack API。实际上这不是一个单独的网络，而是包含在外部和内部网络中。API的端点（Endpoint）包括公共URL（Uniform Resource Locator，统一资源定位符）和内部URL，前者包含的是外部网络的IP 地址，后者包含的是管理网络的IP地址。为简单起见，提供给内外网络访问的API的公共URL和内部URL相同，而只给内部网络访问的API使用内部URL。

数据网络（Data Network）

数据网络可以细分为以下网络类型。

1. 项目（租户）网络（Tenant Network）：又称虚拟机（Virtual Machine,VM）网络，提供虚拟机在计算节点之间，以及计算节点和网络节点之间的通信。同样这也是数据中心的内部网络。
2. 存储访问网络（Storage Access Network）：访问存储的网络。
3. 存储后端网络（Storage Backend Network）：如Ceph和Swift集群用于后端数据复制的网络。
   它们可以合为一种，也可以从性能方面考虑分离出一种或几种作为单独的网络。

硬件管理网络

除了以上网络类型，往往还有各种功能网络，包括IPMI网络、PXE网络、监控网络等，这些可以称为硬件管理网络。大型数据中心通常会建立单独的硬件管理网络。

上述网络，除公共网络和外部网络之外，都可以统称为OpenStack内部网络。这些网络类型可以根据需要灵活组配。管理网络与硬件管理网络可以合并为一个管理网络；API网络与外部网络也可以合二为一，通常这两个网络都是为外部用户提供服务的；管理网络与存储网络也可以合并到一起，因为管理网络流量很少；外部网络、API网络和数据网络也可以合并，以减少路由器物理设备，降低网络的复杂度；当然也可以将所有网络类型合并成一个网络，用于OpenStack的原型验证或开发测试。文章来源地址https://www.toymoban.com/news/detail-842140.html

到了这里，关于OpenStack云计算相关问题解答的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！