6g下载网
当前位置: 主页 > 软件教程 > 云计算 >

OpenStack云控制器和云管理设计教程

时间: 2016-12-27 17:17 来源: 本站整理

分享到:

今天小编整理一篇OpenStack云控制器和云管理设计教程的文章和大家分享,希望能给大家提供帮助。

OpenStack被设计为可大规模水平扩展,这允许所有服务广泛分布。然而,为了简化本指南,我们决定使用云控制器的概念来讨论更中心性的服务。云控制器只是一个概念上的简化。在现实世界中,您为云控制器设计一个架构,实现高可用性,以便任何节点发生故障时,另一个节点可以接管所需的任务。实际上,云控制器任务分布在多个单一节点上。

云控制器为OpenStack部署提供中央管理系统。通常,云控制器管理认证并通过消息队列向所有系统发送消息。

对于许多部署,云控制器是单个节点。但是,为了具有高可用性,您必须考虑几个注意事项,我们将在本章中介绍。

云控制器管理云的以下服务:

- 数据库

跟踪有关用户和实例的当前信息,例如,在数据库中,通常是每个服务管理的一个数据库实例。

- 消息队列服务

服务的所有高级消息队列协议(AMQP)消息根据队列代理接收和发送

- Conductor服务

数据库代理请求。

- 身份管理的身份认证和授权

指示哪些用户可以对某些云资源执行什么操作; 但是,配额管理在服务之间是分散的。

- 镜像管理服务

存储和提供包含元数据的图片,可在云中启动。

- 调度服务

指示首先使用哪些资源; 例如,基于算法在实例被启动的地方展开。

- 使用仪表板

提供基于Web的前端,供用户使用OpenStack云服务。

- API端点

提供每个服务的REST API访问权限,其中API端点目录由身份服务管理。

对于我们的示例,云控制器具有表示云的全局状态的nova- *组件的集合;谈判服务如认证;在数据库中维护关于云的信息;通过队列与所有计算节点和存储工作者通信;并提供API访问。在指定的云控制器上运行的每个服务可以被分解成单独的节点以用于可扩展性或可用性。

作为另一个示例,您可以使用成对的服务器用于集合云控制器 - 一个活动的,一个备用 - 用于冗余节点,提供给定的一组相关服务,例如:

- 用于API请求的前端Web,用于选择引导实例的计算节点的调度程序,Identity服务和仪表板

- 数据库和消息队列服务器(如MySQL,RabbitMQ)

- 图像管理的图像服务

现在你看到了无数的设计来控制你的云,阅读更多关于进一步的考虑,以帮助您的设计决策。

硬件考虑

云控制器的硬件可以与计算节点相同,但您可能需要根据运行的云的大小和类型进一步指定。还可以使用虚拟机来处理云控制器管理的所有或部分服务,例如消息队列。 在本指南中,我们假设所有服务都直接在云控制器上运行。下表包括在为云控制器设计调整硬件大小时需要查看的常见注意事项。

OpenStack云控制器和云管理设计教程

服务分离

虽然我们的示例将所有中央服务都包含在一个位置,但是将服务分离到不同的物理服务器上也是一个好主意。 下表是一些服务分离的部署方案及其理由的列表。

OpenStack云控制器和云管理设计教程

总是出现的一个选择是是否虚拟化。 某些服务(如nova-compute,Swift-proxy和swift-object服务器)不应进行虚拟化。 然而,控制服务器通常可以快速虚拟化 - 性能损失通常可以通过简单地运行更多的服务来抵消。

数据库

OpenStack Compute使用SQL数据库来存储和检索状态信息。 MySQL是OpenStack社区中流行的数据库选择。数据库的丢失导致错误。 因此,我们建议您对数据库进行集群,以使其容错。 配置和维护数据库集群在OpenStack外部完成,并由您选择在云环境中使用的数据库软件决定。 MySQL / Galera是基于MySQL数据库的流行选项。

消息队列

大多数OpenStack服务使用消息队列相互通信。例如,Compute通过消息队列与块存储服务和网络服务进行通信。此外,您可以选择启用任何服务的通知。 RabbitMQ,Qpid和Zeromq都是消息队列服务的流行选择。一般来说,如果消息队列失败或变得不可访问,集群会停止并停止在只读状态,信息会停留在发送最后一条消息的点。因此,我们建议您对消息队列进行集群。请注意,集群消息队列可能是许多OpenStack部署的一个痛点。尽管RabbitMQ具有本机集群支持,但是在大规模运行它时出现了一些问题。当其他排队解决方案可用时,如Zeromq和Qpid,Zeromq不提供状态队列。 Qpid是Red Hat及其衍生产品的首选消息系统。 Qpid没有本机集群功能,需要一个补充服务,如Pacemaker或Corsync。对于消息队列,您需要确定您感到舒适的数据丢失级别,以及是否使用OpenStack项目在发生故障时重试多个MQ主机的能力,例如使用Compute的能力这样做。

Conductor服务

在先前版本的OpenStack中,所有nova-compute服务都需要直接访问托管在云控制器上的数据库。这是有问题的两个原因:安全性和性能。关于安全性,如果计算节点被攻破,攻击者固有地访问数据库。关于性能,对数据库的nova-compute调用是单线程和阻塞。这会创建性能瓶颈,因为数据库请求是顺序执行的,而不是并行执行的。指挥服务通过充当nova-compute服务的代理来解决这两个问题。现在,不是nova-compute直接访问数据库,而是与nova-conductor服务联系,nova-conductor代表nova-compute访问数据库。由于nova-compute不再直接访问数据库,因此安全问题已解决。另外,nova-conductor是非阻塞服务,因此来自所有计算节点的请求被并行地实现。

注意:如果您在云环境中使用nova网络和多主机网络,nova-compute仍然需要直接访问数据库。

nova-conductor服务是水平可扩展的。 为了使nova-conductor具有高可用性和容错能力,只需在同一服务器或多个服务器上启动更多的nova-conductor进程实例。

应用程序接口(API)

所有公共访问(无论是直接的,通过命令行客户端还是通过基于Web的仪表板)都使用API​​服务。在http://developer.openstack.org/找到API参考。您必须选择是要支持Amazon EC2兼容性API还是仅支持OpenStack API。在运行两个API时可能会遇到的一个问题是在引用图像和实例时遇到不一致的体验。例如,EC2 API是指使用包含十六进制的ID的实例,而OpenStack API使用名称和数字。类似地,EC2 API倾向于依靠DNS别名来联系虚拟机,而OpenStack通常列出IP地址。如果OpenStack没有以正确的方式设置,则很容易出现用户由于只有不正确的DNS别名而无法联系他们的实例的情况。尽管如此,EC2兼容性可以帮助用户迁移到您的云。与数据库和消息队列一样,拥有多个API服务器是一件好事。传统的HTTP负载均衡技术可用于实现高可用性nova-api服务。

扩展

API规范定义了OpenStack API的核心操作,功能和介质类型。 客户端可以始终依赖于此核心API的可用性,并且实施者总是需要对其进行全面支持。 要求严格遵守核心API允许客户端在与同一API的多个实现进行交互时依赖于最低级别的功能。 OpenStack Compute API是可扩展的。 扩展向API添加了超出核心中定义的能力。 新功能,MIME类型,操作,状态,标题,参数和资源的引入都可以通过对核心API的扩展来实现。 这允许在API中引入新特性,而不需要版本更改,并允许引入供应商特定的利基功能。

调度

调度服务负责确定应当创建虚拟机或块存储卷的计算或存储节点。 调度服务从消息队列接收这些资源的创建请求,然后开始确定资源应该驻留的适当节点的过程。 该过程通过对可用的节点集合应用一系列用户可配置的过滤器来完成。目前有两个调度器:虚拟机的nova-scheduler和块存储卷的cinder-scheduler。 两个调度程序都能够水平扩展,因此为了实现高可用性,或者对于非常大或高调度频率的安装,您应该考虑运行每个调度程序的多个实例。 调度器都侦听共享消息队列,因此不需要特殊的负载均衡。

镜像

OpenStack Image服务由两部分组成:glance-api和glance-registry。 前者负责图像的交付; 计算节点使用它从后端下载图像。 后者维护与虚拟机映像相关联的元数据信息,并且需要数据库。 glance-api部分是允许选择后端的抽象层。 目前,它支持: OpenStack对象存储允许将图像存储为对象。文件系统使用任何传统的文件系统将图像存储为文件。 S3 允许您从Amazon S3抓取图像。 HTTP 允许您从Web服务器获取图像。 您无法使用此模式写入图像。如果您有OpenStack对象存储服务,我们建议将其用作可扩展的地方来存储图像。 您还可以使用具有足够性能的文件系统或Amazon S3,除非您不需要通过OpenStack上传新映像的能力。

仪表板

OpenStack仪表板(地平线)为各种OpenStack组件提供基于Web的用户界面。 仪表板包括用于管理其虚拟基础架构的最终用户区域和用于云运营商作为整体管理OpenStack环境的管理区域。仪表板实现为通常在Apache httpd中运行的Python Web应用程序。 因此,您可以将其视为与任何其他Web应用程序相同,只要它可以通过网络访问API服务器(包括其管理端点)。

认证和授权

支持OpenStack认证和授权的概念来自于很好理解和广泛使用的类似性质的系统。用户具有可用于验证的凭据,他们可以是一个或多个组(称为项目或租户,可互换)的成员。例如,云管理员可能能够列出云中的所有实例,而用户只能看到他当前组中的那些实例。资源配额(如可用的核心数量,磁盘空间等)与项目相关联。 OpenStack Identity提供认证决策和用户属性信息,然后由其他OpenStack服务使用来执行授权。策略在policy.json文件中设置。有关如何配置这些的信息,请参阅管理项目和用户 OpenStack Identity支持用于身份验证决策和身份存储的不同插件。这些插件的示例包括:内存中键值存储(简化的内部存储结构) SQL数据库(如MySQL或PostgreSQL) Memcached(分布式内存对象缓存系统) LDAP(如OpenLDAP或Microsoft的Active Directory)许多部署使用SQL数据库;然而,对于需要集成的现有身份验证基础架构的人来说,LDAP也是一个受欢迎的选择。

网络注意事项

因为云控制器处理这么多不同的服务,它必须能够处理击中它的流量。 例如,如果您选择在云控制器上托管OpenStack Image服务,则云控制器应能够支持以可接受的速度传输映像。作为另一个示例,如果选择使用单主机网络,其中云控制器是所有实例的网络网关,则云控制器必须支持在云和公共Internet之间传输的总流量。我们建议您使用快速NIC,例如10 GB。 您也可以选择使用两个10 GB NIC并将其绑定在一起。 虽然您可能无法获得完全绑定的20 GB速度,但不同的传输流使用不同的NIC。 例如,如果云控制器传输两个图像,每个图像使用不同的NIC,并获得完整的10 GB带宽。

OpenStack云控制器和云管理设计教程的文章和大家分享结束,感谢阅读!

(责任编辑:大卫)

分享到:

------分隔线----------------------------