OpenStack 该项目是一个开源云计算平台，适用于所有类型的云，旨在实现简单、大规模的扩展和丰富的功能。来自世界各地的开发人员和云计算技术人员创建了它 OpenStack 项目。

OpenStack基础设施是通过一组相互关联的服务提供的服务 (IaaS)解决方案 应用程序编程接口 (API)促进这种集成。

设计、部署和配置 OpenStack，管理员必须了解逻辑结构。

如 概念架构 中所示，OpenStack 由几个独立的部分组成，称为 OpenStack 服务。所有服务均通过公共身份服务进行身份验证。所有服务均通过公共服务进行。 API 互动，除非需要特权管理员的命令。

在内部，OpenStack 服务由多个过程组成。所有服务至少有一个 API 进程，它监听 API 请求，预处理并将其传递给服务的其他部分。除身份服务外，实际工作由不同的流程完成。

服务流程之间的通信使用 AMQP 消息（rabbitmq）代理。存储在数据库中的服务状态。部署和配置 OpenStack 云时，您可以在多种消息代理和数据库解决方案中进行选择，例如 RabbitMQ、MySQL、MariaDB 和 SQLite。

用户可以通过 Horizon Dashboard 实现的基于 Web 通过浏览器插件或curl等工具发出 API 请求来访问 OpenStack 。有几个应用程序 SDK 可用。最后，所有这些访问方法都将进行各种访问 OpenStack 服务发出 REST API 调用。

下图显示了 OpenStack 云最常见但不是唯一可能的架构:

OpenStack该项目是支持所有类型云环境的开源云计算平台。该项目旨在实现简单的实现、大规模的可扩展性和丰富的功能集。来自世界各地的云计算专家为该项目做出了贡献。

OpenStack通过各种互补服务提供基础服务 (IaaS)解决方案 应用程序编程接口 (API)促进这种集成。

本指南适用于足够的使用 Linux 经验的 OpenStack 逐步部署新用户的功能示例架构 OpenStack 服务。本指南不是为了安装生产系统，而是为了理解 OpenStack 创建最低概念验证的目的。

熟悉这些 OpenStack 基本安装、配置、操作和故障排除后，应考虑以下步骤：

确定并实施必要的核心和可选服务，以满足性能和冗余要求。

采用防火墙、加密和服务策略来提高安全性。

使用 Ansible、Chef、Puppet 或 Salt 部署和管理自动化生产环境等部署工具。OpenStack 项目有几个部署项目，每个版本都有具体的指南：

Yoga 版本
Xena 版本
Wallaby 版本
Victoria 版本
Ussuri 版本
Train 版本
Stein 版本
Rocky 版本
Queens 版本
Pike 版本

架构设计指南提供了相关的规划和设计 OpenStack 云信息。它解释了核心概念、云架构设计要求和 OpenStack 云中关键组件和服务的设计标准。该指南还描述了五个常见的云用例。

先决条件:

• 先验知识具有云架构和原理。
• Linux 虚拟化体验。
• 基本了解网络原理和协议。

安装指南
部署指南
OpenStack 操作指南

财务因素是任何组织的首要焦点。成本考虑可能会影响您构建的云类型。例如，通用云不太可能成为特殊应用程序中最具成本效益的环境。除非业务需求表明成本是一个关键因素，否则成本不应该是选择或设计云的唯一考虑因素。

作为一般标准，增加云架构的复杂性将增加其建设和维护的成本。例如，多个供应商和技术架构的混合或多站云架构可能需要更高的设置和运营成本，因为它需要比其他架构更复杂的安排和代理工具。然而，通过使用云代理工具将工作负载部署到最具成本效益的平台上，整体运营成本可能会更低。

考虑以下成本类别：

• 计算资源
• 网络资源
• 复制
• 贮存
• 管理
• 运营成本

考虑如何增加云的扩展成本也很重要。在小系统中，可以忽略的选择可能会大大增加大系统的成本。在这些情况下，尽量减少堆栈各层的资本支出是很重要的 (CapEx)。大规模可扩展 OpenStack 云运营商需要使用可靠的商品硬件和免费的开源软件组件来降低部署成本和运营成本。开放计算（开放计算项目提供更多信息）等计划提供更多信息。

在灵活的时间范围内交付服务或产品的能力是构建云时常见的业务因素。允许用户自行配置和计算，网络和存储资源可能会缩短新产品和应用程序的上市时间。

您必须平衡构建新云平台所需的时间，以及将用户从旧平台迁移出来所节省的时间。在某些情况下，现有的基础设施可能会影响您的架构选择。例如，当现有投资多个应用程序时，使用多个云平台可能是一个很好的选择，因为将投资捆绑在一起可能比迁移组件和重建到单个平台更快。

收入机会因云的意图和用例而异。商业产品对客户的要求通常与内部私有云非常不同。你必须考虑哪些功能使你的设计对用户最有吸引力。

容量和工作负荷的放置是云计算的关键设计考虑因素。这些设计的长期容量计划必须随着时间的推移而增加，以防止更昂贵的外部云永久消耗。为避免这种情况，请考虑未来应用程序的容量需求，并适当规划增长。

如果用户数量波动或应用程序使用意外增加，则很难预测特定应用程序可能产生的负载。可以根据 vCPU、RAM、带宽或其他资源定义应用程序要求并进行适当的规划。然而，其他云可能不使用相同的计量器，甚至不使用相同的超额订阅率。

超额订阅是一种模拟比实际可能存在更多容量的方法。例如，具有 32 GB RAM 物理管理程序节点可以托管 24 个实例，每个实例配备 2 GB RAM。只要所有 24 不同时使用个例子 2 GB，这种安排可以很好地工作。然而，一些主机过度订阅到极端，因此性能可能不一致。如有可能，确定每台主机的超额订阅率，并相应规划容量。

在设计任何云时，性能都是一个关键因素，随着规模和复杂性的增长而变得越来越重要。虽然单站私有云可以严格控制，但需要更仔细地规划多站点和混合部署，以减少网站之间的网络延迟。

例如，您应该考虑在不同的云中运行工作负载所需的时间和减少此时间的方法。这可能需要将数据移动到更接近应用程序或应用程序的数据，并分组功能，以便在单个云上发生低延迟连接，而不是跨云。

这可能还需要 CMP 确定哪种云能最有效地运行哪种工作负荷。

使用原生 OpenStack 工具有助于提高性能。例如，您可以使用遥测来衡量性能，并使用安排服务（热量）来响应需求变化。

注意
安排需要特殊的客户端配置 Amazon Web Services 集成。请使用其他类型的云 CMP 功能。

云用户希望启动和部署云资源的过程具有可重复性、可靠性和确定性。你可以通过基础 Web 界面或公开可用 API 端点提供此功能。All appropriate options for requesting cloud resources must be available through some type of user interface, a command-line interface (CLI), or API endpoints.

云用户希望完全自助和按需消费模式。 OpenStack 当云达到可以大规模扩张的规模时，它希望以各种方式消费即服。

一切都必须能够自动化。例如，从计算硬件、存储硬件、网络硬件到支持软件的安装和配置。在大规模可扩展的 OpenStack 设计架构中，手动流程是不切实际的。

大规模可扩展的 OpenStack 云需要广泛的计量和监控功能，通过让操作员了解基础设施的状态和状态来最大限度地提高运营效率。这包括硬件和软件状态的全面计量。还需要相应的日志记录和警报框架来存储和启用操作以对计量和监控解决方案提供的计量表进行操作。云运营商还需要一个解决方案，使用计量和监控解决方案提供的数据来提供容量规划和容量趋势分析。

对于许多用例，用户与其工作负载的接近程度直接影响应用程序的性能，因此在设计中应予以考虑。某些应用程序需要零到最小的延迟，这只能通过在多个位置部署云来实现。这些位置可能位于不同的数据中心、城市、国家或地理区域，具体取决于用户需求和用户的位置。

输入输出性能要求需要在决定最终存储框架之前进行研究和建模。运行输入输出性能基准测试为预期的性能水平提供了基准。如果这些测试包含详细信息，则生成的数据可以帮助对不同工作负载期间的行为和结果进行建模。在架构的生命周期中运行脚本化的小型基准测试有助于记录不同时间点的系统运行状况。来自这些脚本基准的数据有助于未来确定范围并更深入地了解组织的需求。

在以存储为中心的 OpenStack 架构设计中扩展存储解决方案是由初始需求驱动的，包括 IOPS、容量、带宽和未来需求。根据预算周期过程中的预计需求规划容量对于设计很重要。该架构应该平衡成本和容量，同时还允许灵活地实施新技术和方法，因为它们变得可用。

在选择 CMP 和云提供商时，重要的是要考虑网络的功能、安全性、可扩展性、可用性和可测试性。

确定网络框架并设计最低限度的功能测试。这可确保测试和功能在升级期间和升级后持续存在。

跨多个云提供商的可扩展性可能决定您在不同的云提供商中选择哪种底层网络框架。展示网络 API 功能并验证功能是否在所选的所有云端点上持续存在是很重要的。

高可用性实现在功能和设计上有所不同。一些常见方法的示例是主动-热备、主动-被动和主动-主动。开发高可用性和测试框架对于确保理解功能和限制是必要的。

考虑客户端和端点之间数据的安全性，以及穿越多个云的流量的安全性。

例如，降级的视频流和低质量的 VoIP 会话会对用户体验产生负面影响，并可能导致生产力和经济损失。

网络配置错误
配置不正确的 IP 地址、VLAN 和路由器可能会导致网络区域中断，或者在最坏的情况下会导致整个云基础架构中断。自动化网络配置以最大限度地减少操作员错误的机会，因为它可能导致破坏性问题。

容量规划
随着时间的推移，云网络需要对容量和增长进行管理。容量规划包括购买可能具有以月或年为单位的交货时间的网络电路和硬件。

网络调优
配置云网络以最大程度地减少链路丢失、丢包、包风暴、广播风暴和环路。

单点故障 (SPOF)
考虑物理层和环境层的高可用性。如果仅由于一个上游链路或仅一个电源而导致单点故障，则中断可能变得不可避免。

复杂
过于复杂的网络设计可能难以维护和排除故障。虽然设备级配置可以缓解维护问题，自动化工具可以处理覆盖网络，但可以避免或记录功能和专用硬件之间的非传统互连，以防止中断。

组织可能有某些法律义务和法规遵从措施，可能要求某些工作负载或数据不能位于某些区域。

合规性考虑对于多站点云尤其重要。考虑因素包括：

• 联邦法律要求
• 当地司法管辖区的法律和合规要求
• 图像一致性和可用性
• 存储复制和可用性（块和文件/对象存储）
• 身份验证、授权和审计 (AAA)

地理因素也可能影响建设或租赁数据中心的成本。考虑因素包括：

一个经过深思熟虑的审计计划对于快速发现问题至关重要。如果更改影响生产，则跟踪对安全组和租户更改所做的更改对于回滚更改很有用。例如，如果租户的所有安全组规则都消失了，那么出于运营和法律原因，快速追踪问题的能力将很重要。有关审计的更多详细信息，请参阅OpenStack 安全指南中的合规性章节。

安全性的重要性因使用云的组织类型而异。例如，政府和金融机构往往有非常高的安全要求。应根据资产、威胁和漏洞风险评估矩阵实施安全。请参阅安全要求。

服务水平协议 (SLA) 必须与业务、技术和法律投入一起制定。小型私有云可能在非正式的 SLA 下运行，但混合云或公共云通常需要与其用户达成更正式的协议。

对于可大规模扩展的 OpenStack 公共云的用户，不需要对安全性、性能或可用性进行控制。用户只期望与 API 服务的正常运行时间相关的 SLA，以及所提供服务的非常基本的 SLA。用户有责任自行解决这些问题。这种期望的例外是为具有特定要求的私人或政府组织构建的大规模可扩展云基础架构的罕见情况。

高性能系统在保证正常运行时间、延迟和带宽方面具有最低服务质量的 SLA 要求。SLA 的级别会对网络架构和系统冗余要求产生重大影响。

混合云设计必须适应提供商之间 SLA 的差异，并考虑其可执行性。

一些应用程序可以容忍缺少同步对象存储，而另一些应用程序可能需要这些对象被复制并跨区域可用。了解云实施如何影响新的和现有的应用程序对于缓解风险以及云项目的整体成功非常重要。可能必须为几乎没有冗余的基础架构编写或重写应用程序，或者考虑到云。

申请势头
拥有现有应用程序的企业可能会发现，将应用程序集成到多个云平台上比将它们迁移到单个平台更具成本效益。

没有预定义的使用模型
缺乏预定义的使用模型使用户能够运行各种各样的应用程序，而无需提前知道应用程序的需求。这提供了其他云方案无法提供的独立性和灵活性。

按需和自助服务应用程序
根据定义，云为最终用户提供了以简单灵活的方式自行配置计算能力、存储、网络和软件的能力。用户必须能够在不中断底层主机操作的情况下将其资源扩展到相当大的水平。使用通用云架构的好处之一是能够从有限的资源开始，并随着用户需求的增长而随着时间的推移增加资源。

建议使用单个身份验证域，而不是为每个站点单独实现。这需要一种高度可用和分布式的身份验证机制，以确保连续运行。身份验证服务器位置可能是必需的，并且应该进行规划。

中断可能导致站点功能部分或全部丧失。应实施策略以了解和计划恢复方案。

1. 部署的应用程序需要继续运行，更重要的是，您必须考虑站点不可用时对应用程序性能和可靠性的影响。
2. 重要的是要了解当站点出现故障时站点之间的对象和数据复制会发生什么。如果这导致队列开始建立，请考虑这些队列可以安全存在多长时间，直到发生错误。
3. 停电后，确保站点恢复正常运行的方法在站点重新上线时得到实施。我们建议您构建恢复以避免竞争条件。

灾难恢复和业务连续性
更便宜的存储使公共云适合维护备份应用程序。

迁移场景
混合云架构支持应用程序在不同云之间的迁移。

提供者可用性或实施细节
业务变化可能会影响提供商的可用性。同样，提供商服务的变化可能会破坏混合云环境或增加成本。

提供者 API 更改
外部云的消费者很少能够控制提供者对 API 的更改，并且更改可能会破坏兼容性。仅使用最常见和基本的 API 可以最大限度地减少潜在冲突。

image可移植性
在 Kilo 版本中，没有可供所有云使用的通用图像格式。如果在云之间迁移，则需要转换或重新创建图像。要简化部署，请使用可行的最小和最简单的映像，仅安装必要的部分，并使用 Chef 或 Puppet 等部署管理器。除非您在同一云上重复部署相同的映像，否则不要使用黄金映像来加快进程。

API 差异
避免将混合云部署与 OpenStack（或不同版本的 OpenStack）一起使用，因为 API 更改可能会导致兼容性问题。

业务或技术多样性
利用基于云的服务的组织可以拥抱业务多样性，并利用混合云设计将其工作负载分布在多个云提供商之间。这确保了没有一个云提供商是应用程序的唯一主机。

OpenStack 集群的网络设计包括有关集群内互连需求的决策、允许客户端访问其资源的需求以及操作员管理集群的访问要求。您应该考虑这些网络的带宽、延迟和可靠性。

考虑有关监控和警报的其他设计决策。如果您使用的是外部提供商，服务水平协议 (SLA) 通常会在您的合同中定义。带宽、延迟和抖动等操作考虑因素可以成为 SLA 的一部分。

随着对网络资源的需求增加，请确保您的网络设计能够适应扩展和升级。运营商添加额外的 IP 地址块并增加额外的带宽容量。此外，考虑管理硬件和软件生命周期事件，例如升级、退役和中断，同时避免租户服务中断。

服务级别协议 (SLA) 定义了将影响 OpenStack 云设计以提供冗余和高可用性的可用性级别。

影响设计的 SLA 条款包括：

• API 可用性保证意味着多个基础设施服务和高可用性负载平衡器。
• 网络正常运行时间保证会影响交换机设计，这可能需要冗余交换机和电源。
• 网络安全策略要求。

在任何大于几台主机的环境中，有两个区域可能需要遵守 SLA：

• 数据平面 - 提供虚拟化、网络和存储的服务。客户通常要求这些服务持续可用。
• 控制平面 - 辅助服务，例如 API 端点，以及控制 CRUD 操作的服务。此类别中的服务通常受制于不同的 SLA 预期，并且可能更适合与数据平面服务分开的硬件或容器。

为了有效地运行云安装，初始停机时间规划包括创建支持计划内维护和计划外系统故障的流程和架构。

作为 SLA 协商的一部分，在发生中断时确定哪一方负责监控和启动计算服务实例非常重要。

对于某些服务，升级、修补和更改配置项可能需要停机。停止构成控制平面的服务可能不会影响数据平面。可能需要实时迁移计算实例来执行任何需要停机到数据平面组件的操作。

在纯 OpenStack 代码领域之外有许多服务会影响云设计满足 SLA 的能力，包括：

• 数据库服务，例如MySQL或PostgreSQL。
• 提供 RPC 的服务，例如RabbitMQ.
• 外部网络附件。
• 物理限制，例如电源、机架空间、网络布线等。
• 共享存储，包括基于 SAN 的阵列、存储集群（如Ceph）和/或 NFS 服务。

根据设计，某些网络服务功能可能同时属于控制平面和数据平面类别。例如，neutron L3 代理服务可能被认为是控制平面组件，但路由器本身将是数据平面组件。

在具有多个区域的设计中，SLA 还需要考虑使用共享服务，例如身份服务和仪表板。

任何 SLA 协商还必须考虑对第三方设计关键方面的依赖。例如，如果存储系统等组件上存在现有 SLA，则 SLA 必须考虑此限制。如果云所需的 SLA 超过云组件商定的正常运行时间水平，则需要额外的冗余。这种考虑在涉及多个第三方的混合云设计中至关重要。

操作人员支持、管理和维护 OpenStack 环境。他们的技能可能是专业的或因安装的大小和目的而异。

应考虑操作员的维护功能：

维护任务
操作系统修补、硬件/固件升级和数据中心相关更改，以及对 OpenStack 组件的次要和版本升级都是持续的操作任务。OpenStack 项目的六个月发布周期需要被视为持续维护成本的一部分。该解决方案应考虑存储和网络维护以及对底层工作负载的影响。

可靠性和可用性
可靠性和可用性取决于许多支持组件的可用性以及服务提供商采取的预防措施水平。这包括网络、存储系统、数据中心和操作系统。

有关管理和维护 OpenStack 环境的更多信息，请参阅 OpenStack 操作指南。

OpenStack 云需要适当的监控平台来识别和管理错误。

笔记
我们建议利用现有的监控系统来查看它们是否能够有效地监控 OpenStack 环境。

对捕获至关重要的特定仪表包括：

• 映像磁盘利用率
• 计算 API 的响应时间

对于多站点 OpenStack 云，日志记录和监控没有显着差异。操作指南中的日志记录和监控中描述的工具仍然适用。可以在每个站点的基础上，在一个公共的集中位置提供日志记录和监控。

在尝试将日志记录和监控设施部署到集中位置时，必须注意站点间网络链接上的负载

经常使用为云环境提供集群、日志记录、监视和警报详细信息的管理软件。这会影响和影响整个 OpenStack 云设计，并且必须考虑额外的资源消耗，例如 CPU、RAM、存储和网络带宽。

是否包含集群软件（例如 Corosync 或 Pacemaker）主要取决于云基础架构的可用性以及部署后支持配置的复杂性。OpenStack 高可用性指南提供了有关 Corosync 和 Pacemaker 的安装和配置的 更多详细信息，如果这些软件包需要包含在设计中。

其他一些潜在的设计影响包括：

• 操作系统-管理程序组合
  确保选定的日志记录、监视或警报工具支持建议的操作系统管理程序组合。
• 网络硬件
  网络硬件选择需要得到日志、监控和警报软件的支持。

大多数 OpenStack 组件需要访问后端数据库服务来存储状态和配置信息。选择满足 OpenStack 服务的可用性和容错要求的适当后端数据库。

MySQL 是 OpenStack 的默认数据库，但也可以使用其他兼容的数据库。

所选的高可用性数据库解决方案会根据所选数据库而变化。例如，MySQL 提供了几个选项。使用 Galera 等复制技术进行主动-主动集群。对于主动-被动使用某种形式的共享存储。这些潜在的解决方案中的每一个都会对设计产生影响：

• 采用 Galera/MariaDB 的解决方案至少需要三个 MySQL 节点。
• MongoDB 对高可用性有自己的设计考虑。
• OpenStack 设计通常不包括共享存储。但是，对于某些高可用性设计，某些组件可能需要它，具体取决于具体实现。

在云环境中托管云操作系统是一种趋势。操作员需要访问这些系统来解决重大事件。

确保网络结构连接所有云，形成一个集成系统。还要考虑切换状态，该状态必须可靠且延迟最小，以实现系统的最佳性能。

如果云的很大一部分位于外部管理的系统上，请为可能无法进行更改的情况做好准备。此外，云提供商可能会在必须如何管理和公开基础设施方面有所不同。这可能会导致根本原因分析的延迟，其中供应商坚持认为责任在于其他供应商。

在设计 OpenStack 云时，重要的是要考虑服务水平协议 (SLA)规定的需求。这包括维持正在运行的计算服务实例、网络、存储和在这些资源之上运行的其他服务的可用性所需的核心服务。这些服务通常被称为数据平面服务，并且通常期望始终可用。

其余的服务，负责创建、读取、更新和删除 (CRUD) 操作、计量、监控等，通常称为控制平面。SLA 可能会规定这些服务的正常运行时间要求较低。

构成 OpenStack 云的服务有许多要求，您需要了解这些要求才能满足 SLA 条款。例如，为了提供最少的存储空间，消息队列和数据库服务以及它们之间的网络是必需的。

如果数据平面和控制平面系统在逻辑和物理上分离，则持续维护操作会变得更加简单。例如，可以在不影响客户的情况下重新启动控制器。如果一个服务故障影响了整个服务器的运行 ( )，控制平面和数据平面之间的分离可以实现快速维护，而对客户运营的影响有限。

OpenStack 适合以高度可用的方式进行部署，预计至少需要使用 2 台服务器。这些可以运行消息队列服务所涉及的所有服务，例如RabbitMQor QPID，以及适当部署的数据库服务，例如MySQLor MariaDB。随着云中服务的横向扩展，后端服务也需要扩展。监控和报告服务器利用率和响应时间，以及对系统进行负载测试，将有助于确定横向扩展决策。

OpenStack 服务本身应该部署在不代表单点故障的多台服务器上。通过将这些服务置于具有多个 OpenStack 服务器作为成员的高可用性负载平衡器之后，可以确保可用性。

有少量 OpenStack 服务旨在一次只在一个地方运行（例如，ceilometer-agent-central服务）。为了防止这些服务成为单点故障，可以通过集群软件如Pacemaker.

在 OpenStack 中，基础设施是提供服务不可或缺的一部分，并且应该始终可用，尤其是在使用 SLA 操作时。确保网络可用性是通过设计网络架构来实现的，以便不存在单点故障。核心基础设施以及相关的网络绑定应考虑交换机的数量、路由和电源冗余的数量，以便为您的高可用性交换机基础设施提供多种路由。

在决定网络功能时必须小心。目前，OpenStack 支持传统的网络（nova-network）系统和更新的、可扩展的 OpenStack 网络（neutron）。OpenStack 网络和传统网络都有其优点和缺点。它们都是适用于OpenStack Operations Guide中描述的不同网络部署模型的有效且受支持的选项。

使用网络服务时，OpenStack 控制器服务器或单独的网络主机处理路由，除非选择了用于路由的动态虚拟路由器模式。直接在控制器服务器上运行路由会混合数据和控制平面，并可能导致复杂的性能和故障排除问题。可以使用第三方软件和外部设备来帮助维护高度可用的第三层路由。这样做允许通用应用程序端点控制网络硬件，或以安全的方式提供复杂的多层 Web 应用程序。也可以从 Networking 中完全移除路由，转而依赖硬件路由功能。在这种情况下，交换基础设施必须支持第三层路由。

应用程序设计还必须考虑到底层云基础设施的功能。如果计算主机不提供无缝实时迁移功能，那么必须预计如果计算主机发生故障，该实例以及该实例本地的任何数据都将被删除。但是，当向用户提供实例具有高水平正常运行时间保证的期望时，必须以一种在计算主机消失时消除任何单点故障的方式部署基础设施。这可能包括利用企业存储或 OpenStack 块存储上的共享文件系统来提供与服务特性相匹配的保证水平。

如果使用包含对集中式存储的共享访问的存储设计，请确保其设计也没有单点故障，并且解决方案的 SLA 匹配或超过数据平面的预期 SLA。

一些服务通常在多个区域之间共享，包括身份服务和仪表板。在这种情况下，有必要确保支持服务的数据库被复制，并且在丢失单个区域的情况下可以保持对每个站点的多个工作人员的访问。

应在站点之间部署多个网络链接，以为所有组件提供冗余。这包括存储复制，它应该被隔离到一个专用网络或 VLAN 中，并能够分配 QoS 来控制复制流量或为此流量提供优先级。

注意
如果数据存储高度可变，则网络要求可能会对维护站点的运营成本产生重大影响。

如果设计包含多个站点，则在两个站点中保持对象可用性的能力对对象存储设计和实施具有重大影响。它还对站点之间的 WAN 网络设计产生重大影响。

如果在云中运行的应用程序不是云感知的，则应该有明确的措施和期望来定义基础设施可以支持和不能支持的内容。一个例子是站点之间的共享存储。这是可能的，但是这样的解决方案不是 OpenStack 原生的，需要第三方硬件供应商来满足这样的要求。另一个例子可以在能够直接消耗对象存储资源的应用程序中看到。

连接两个以上的站点会增加挑战并增加设计考虑的复杂性。多站点实施需要规划解决用于内部和外部连接的附加拓扑。一些选项包括全网状拓扑、中心辐条、脊叶和 3D Torus。

中断可能导致站点功能部分或全部丧失。应实施策略以了解和计划恢复方案。

• 部署的应用程序需要继续运行，更重要的是，您必须考虑站点不可用时对应用程序性能和可靠性的影响。
• 重要的是要了解当站点出现故障时站点之间的对象和数据复制会发生什么。如果这导致队列开始建立，请考虑这些队列可以安全存在多长时间，直到发生错误。
• 中断后，确保站点恢复联机时恢复运行。我们建议您构建恢复以避免竞争条件。

传统上，复制一直是保护对象存储实现的最佳方法。存储架构中存在多种复制方法，例如同步和异步镜像。大多数对象存储和后端存储系统在存储子系统层实现复制方法。对象存储还定制复制技术以适应云的要求。

组织必须在数据完整性和数据可用性之间找到适当的平衡。复制策略也可能影响灾难恢复方法。

跨不同机架、数据中心和地理区域的复制增加了对确定和确保数据位置的关注。保证从最近或最快的存储访问数据的能力对于应用程序的良好运行可能是必要的。

注意
运行嵌入式对象存储方法时，请确保您不会引发额外的数据复制，因为这可能会导致性能问题。

设计 OpenStack 云需要了解云用户的需求，并需要确定最佳配置。本章为您在设计过程中需要做出的决定提供指导。

要设计、部署和配置 OpenStack，管理员必须了解逻辑架构。OpenStack 模块是以下类型之一：

守护进程
作为后台进程运行。在 Linux 平台上，守护程序通常作为服务安装。

脚本
安装虚拟环境并运行测试。

命令行界面 (CLI)
使用户能够通过命令向 OpenStack 服务提交 API 调用。

OpenStack 逻辑架构展示了 OpenStack 中最常见的集成服务的一个示例，以及它们如何相互交互。最终用户可以通过仪表板、CLI 和 API 进行交互。所有服务都通过公共身份服务进行身份验证，并且各个服务通过公共 API 相互交互，除非需要特权管理员命令。

在设计计算资源池时，请考虑处理器数量、内存量、网络要求、每个管理程序所需的存储量，以及对通过 Ironic 配置的裸机主机的任何要求。

在构建 OpenStack 云时，作为规划过程的一部分，您不仅要确定要使用的硬件，还要确定计算资源是在单个池中提供，还是在多个池或可用区中提供。您应该考虑云是否会为计算提供截然不同的配置文件。

例如，基于 CPU、内存或本地存储的计算节点。对于基于 NFV 或 HPC 的云，甚至可能存在应为特定计算节点上的特定工作负载保留的特定网络配置。这种将特定资源设计成计算组或区域的方法可以称为装箱。

注意
在 bin oacking 设计中，每个独立的资源池都为特定的口味提供服务。由于实例被调度到计算管理程序上，每个独立节点的资源将被分配以有效地使用可用硬件。虽然 bin 打包可以将工作负载特定资源分离到各个服务器上，但 bin 打包还需要通用硬件设计，计算资源池中的所有硬件节点共享通用处理器、内存和存储布局。这使得在节点的整个生命周期内部署、支持和维护节点变得更加容易。

增加支持计算环境的大小会增加网络流量和消息，增加用于支持 OpenStack 云或网络节点的控制器和管理服务的负载。在考虑控制器节点的硬件时，无论是使用单片控制器设计，其中所有控制器服务都位于一个或多个物理硬件节点上，还是在任何较新的无共享控制平面模型中，都必须分配和扩展足够的资源以满足规模要求。对环境的有效监控将有助于扩展容量决策。随着云的扩展，适当的规划将有助于避免瓶颈和网络超额订阅。

计算节点自动连接到 OpenStack 云，从而在向 OpenStack 云添加额外计算容量时实现水平扩展过程。为了进一步对计算节点进行分组并将节点放置到适当的可用区和主机聚合中，需要进行额外的工作。有必要规划机架容量和网络交换机，因为横向扩展计算主机会直接影响数据中心基础设施资源，就像任何其他基础设施扩展一样。

虽然在大型企业中并不常见，但计算主机组件也可以升级以满足需求的增长，这称为垂直扩展。根据正在运行的应用程序是 CPU 密集型还是内存密集型，升级具有更多内核的 CPU 或增加整体服务器内存可以增加额外所需的容量。我们建议滚动升级计算节点以实现冗余和可用性。升级后，当计算节点返回 OpenStack 集群时，会重新扫描，并在 OpenStack 数据库中调整发现新资源。

选择处理器时，比较特性和性能特征。一些处理器包括特定于虚拟化计算主机的功能，例如硬件辅助虚拟化，以及与内存分页相关的技术（也称为 EPT 影子）。这些类型的功能会对虚拟机的性能产生重大影响。

处理器内核和线程的数量会影响可以在资源节点上运行的工作线程的数量。设计决策必须与在其上运行的服务直接相关，并为所有服务提供平衡的基础架构。

另一种选择是评估平均工作负载并通过调整过量使用率来增加可以在计算环境中运行的实例数量。此比率可针对 CPU 和内存进行配置。默认 CPU 过量使用比例为 16:1，默认内存过量使用比例为 1.5:1。在设计阶段确定过度使用比率的调整非常重要，因为它直接影响计算节点的硬件布局。

注意
更改 CPU 过度使用率可能会产生不利影响，并导致嘈杂邻居的潜在增加。

磁盘容量不足也可能对包括 CPU 和内存使用在内的整体性能产生负面影响。根据 OpenStack 块存储层的后端架构，容量包括向企业存储系统添加磁盘架或安装额外的块存储节点。可能需要升级安装在计算主机中的直接附加存储，并为共享存储增加容量以便为实例提供额外的临时存储。

考虑非管理程序节点（也称为资源节点）的计算要求。这包括控制器、对象存储节点、块存储节点和网络服务。

应考虑为不可预测的工作负载创建池或可用区的能力。在某些情况下，对某些实例类型或风格的需求可能无法证明单独的硬件设计是合理的。分配能够服务于最常见实例请求的硬件设计。可以稍后将硬件添加到整体架构中。

管理程序提供软件来管理虚拟机对底层硬件的访问。管理程序创建、管理和监视虚拟机。OpenStack Compute (nova) 在不同程度上支持许多虚拟机管理程序，包括：

Ironic
KVM
LXC
QEMU
VMware ESX/ESXi
Xen (using libvirt)
XenServer
Hyper-V
PowerVM
UML
Virtuozzo
zVM

选择管理程序的一个重要因素是您当前组织的管理程序使用或体验。同样重要的是管理程序的功能对等、文档和社区体验水平。

根据最近的 OpenStack 用户调查，KVM 是 OpenStack 社区中采用最广泛的管理程序。除了 KVM，还有许多运行其他管理程序的部署，例如 LXC、VMware、Xen 和 Hyper-V。但是，与更常用的管理程序相比，这些管理程序要么使用较少，要么是小众管理程序，要么功能有限。

笔记
还可以使用主机聚合或单元在单个部署中运行多个管理程序。但是，单个计算节点一次只能运行一个管理程序。

有关虚拟机管理程序以及 Ironic 和 Virtuozzo（以前称为 Parallels）的功能支持的更多信息，请参阅 配置参考中的虚拟机管理程序支持矩阵 和虚拟机管理程序。

在选择计算服务器硬件时考虑以下因素：

服务器密度
衡量有多少服务器可以放入给定的物理空间度量中，例如机架单元 [U]。

资源容量
给定服务器提供的 CPU 内核数、RAM 量或存储量。

可扩展性
在服务器达到容量之前可以添加到服务器的额外资源的数量。

成本
硬件的相对成本与基于预定要求的硬件可用容量总量相权衡。

权衡这些考虑因素以确定达到预期目的的最佳设计。例如，增加服务器密度意味着牺牲资源容量或可扩展性。它还可以降低可用性并增加嘈杂的邻居问题的机会。增加资源容量和可扩展性会增加成本，但会降低服务器密度。降低成本通常意味着降低可支持性、可用性、服务器密度、资源容量和可扩展性。

在构建云之前确定对云的要求，并规划硬件生命周期，以及可能需要不同硬件的扩展和新功能。

如果云最初是用接近生命周期的但具有成本效益的硬件构建的，那么新工作负载的性能和容量需求将推动购买更现代的硬件。随着单个硬件组件随时间变化，您可能更愿意将配置作为库存单位 (SKU) 进行管理。这种方法为企业提供了一个标准的计算配置单元（服务器），可以放置在任何 IT 服务经理或供应商提供的订购系统中，可以手动或通过高级操作自动化触发。这简化了订购、供应和激活额外计算资源的过程。例如，有几个商业服务管理工具的插件可以与硬件 API 集成。它们根据标准配置从备用硬件配置和激活新的计算资源。使用这种方法，可以为数据中心订购备用硬件，并根据从 OpenStack Telemetry 获得的容量数据进行配置。

计算容量（CPU 内核和 RAM 容量）是选择服务器硬件的次要考虑因素。所需的服务器硬件必须提供足够的 CPU 插槽、额外的 CPU 内核和足够的 RA。有关详细信息，请参阅 选择 CPU。

在计算服务器架构设计中，您还必须考虑网络和存储要求。有关网络注意事项的更多信息，请参阅 网络架构。

以下是为计算服务器选择硬件时需要考虑的其他一些因素。

如果设计架构使用双路硬件设计，则需要更多主机来支持预期规模。

对于通用 OpenStack 云，规模是一个重要的考虑因素。每个虚拟机管理程序可以托管的预期或预期实例数量是用于确定部署规模的常用计量器。选定的服务器硬件需要支持预期或预期的实例密度。

解决更高主机数量的另一个选择是使用四插槽平台。采用这种方法会降低主机密度，这也会增加机架数量。这种配置会影响电源连接的数量，也会影响网络和冷却要求。

物理数据中心的物理空间、电力和冷却能力有限。可以适应给定指标（机架、机架单元或地砖）的主机（或管理程序）的数量是确定大小的另一种重要方法。地板重量是一个经常被忽视的考虑因素。

数据中心地板必须能够支撑一个或一组机架内建议数量的主机的重量。这些因素需要作为主机密度计算和服务器硬件选择的一部分加以应用。

由于主机密度较低（通过使用 2U、3U 甚至 4U 服务器设计），电源和冷却密度要求可能低于刀片式服务器、底座或 1U 服务器设计。对于基础设施较旧的数据中心，这可能是一个理想的功能。

数据中心向给定的机架或一组机架提供特定数量的电力。较旧的数据中心的每个机架的功率密度可能低至 20A，而当前的数据中心可以设计为支持每个机架高达 120A 的功率密度。选择的服务器硬件必须考虑功率密度。

在选择适合您的 OpenStack 设计架构的服务器硬件外形尺寸时，请考虑以下因素：

• 大多数刀片服务器都可以支持双插槽多核 CPU。要避免此 CPU 限制，请选择或刀片。但是请注意，这也会降低服务器密度。例如，HP BladeSystem 或 Dell PowerEdge M1000e 等高密度刀片服务器仅在 10 个机架单元中支持多达 16 个服务器。使用半高刀片的密度是使用全高刀片的两倍，这导致每十个机架单元只有八台服务器。full widthfull height

• 1U 机架式服务器能够提供比刀片服务器解决方案更高的服务器密度，但通常仅限于双插槽、多核 CPU 配置。与 32 个全宽刀片服务器相比，可以在一个机架中放置 40 个 1U 服务器，为架顶式 (ToR) 交换机提供空间。

要在 1U 机架式外形尺寸中获得超过双插槽的支持，客户需要从原始设计制造商 (ODM) 或二级制造商处购买系统

警告
这可能会导致具有首选供应商政策或关注非 1 级供应商的支持和硬件保修的组织出现问题。

• 2U 机架式服务器提供四插槽、多核 CPU 支持，但服务器密度相应降低（是 1U 机架式服务器提供的密度的一半）。

• 更大的机架式服务器，例如 4U 服务器，通常提供更大的 CPU 容量，通常支持四个甚至八个 CPU 插槽。这些服务器具有更大的可扩展性，但此类服务器的服务器密度要低得多，而且通常更昂贵。

• Sled servers是机架式服务器，支持单个 2U 或 3U 机箱中的多个独立服务器。与典型的 1U 或 2U 机架式服务器相比，它们提供更高的密度。例如，许多雪橇服务器在 2U 中提供四个独立的双插槽节点，在 2U 中总共有八个 CPU 插槽。

在设计 OpenStack 云计算服务器架构时，您必须决定是要纵向扩展还是横向扩展。选择较少数量的大型主机或大量小型主机取决于多种因素：成本、电力、冷却、物理机架和占地面积、支持-保修和可管理性。通常，横向扩展模型在 OpenStack 中很受欢迎，因为它通过将工作负载分散到更多基础架构中来减少可能的故障域的数量。然而，不利的一面是额外服务器的成本以及为服务器供电、联网和冷却所需的数据中心资源。

OpenStack 允许您在计算节点上过度使用 CPU 和 RAM。这允许您以降低实例性能为代价增加在云上运行的实例数量。Compute 服务默认使用以下比率：

• CPU分配比例：16:1
• RAM分配比例：1.5:1

默认的 CPU 分配比例 16:1 意味着调度程序为每个物理内核分配最多 16 个虚拟内核。例如，如果一个物理节点有 12 个核心，调度程序会看到 192 个可用的虚拟核心。对于每个实例 4 个虚拟内核的典型风味定义，这个比率将在一个物理节点上提供 48 个实例。

计算节点上虚拟实例数的公式为 (OR*PC)/VC，其中：

或者
CPU 过量使用率（每个物理内核的虚拟内核数）

个人电脑
物理核心数

风险投资
每个实例的虚拟核心数

同样，默认的 RAM 分配比率 1.5:1 意味着调度程序将实例分配给物理节点，只要与实例关联的 RAM 总量小于物理节点上可用 RAM 量的 1.5 倍。

例如，如果一个物理节点有 48 GB 的 RAM，则调度程序将实例分配给该节点，直到与实例关联的 RAM 总和达到 72 GB（例如 9 个实例，在每个实例都有 8 GB RAM 的情况下） ）。

笔记
无论超量使用率如何，都不能将实例放置在原始（超量使用前）资源少于实例类型所需资源的任何物理节点上。

您必须为您的特定用例选择适当的 CPU 和 RAM 分配比率。

作为计算集群架构设计的一部分，您必须为运行实例化实例的磁盘指定存储。提供临时存储的主要方法有以下三种：

• 离计算节点存储——共享文件系统

• 计算节点存储——共享文件系统

• 在计算节点存储——非共享文件系统

一般来说，您在选择存储时应该问的问题如下：

• 我的工作量是多少？

• 我的工作负载是否有 IOPS 要求？

• 是否有读、写或随机访问性能要求？

• 我对计算存储扩展的预测是什么？

• 我的企业当前使用什么存储？可以重新利用吗？

• 如何在操作上管理存储？

许多运营商使用单独的计算和存储主机，而不是超融合解决方案。计算服务和存储服务有不同的要求，计算主机通常比存储主机需要更多的 CPU 和 RAM。因此，对于固定预算，为您的计算节点和存储节点设置不同的配置是有意义的。计算节点将投资于 CPU 和 RAM，存储节点将投资于块存储。

但是，如果您在可用于创建云的物理主机数量方面受到更多限制，并且您希望能够将尽可能多的主机专用于运行实例，那么在同一台服务器上运行计算和存储是有意义的机器或使用可用的现有存储阵列。

接下来的几节将提供三种主要的实例存储方法。

在此选项中，存储正在运行的实例的磁盘托管在计算节点之外的服务器中。

如果您使用单独的计算和存储主机，您可以将您的计算主机视为“无状态”。只要您当前没有在计算主机上运行任何实例，您就可以使其脱机或完全擦除它，而不会对云的其余部分产生任何影响。这简化了计算主机的维护。

这种方法有几个优点：

• 如果计算节点发生故障，实例通常很容易恢复。

• 运行专用存储系统可以在操作上更简单。

• 您可以扩展到任意数量的主轴。

• 可能出于其他目的共享外部存储。

这种方法的主要缺点是：

• 根据设计，某些实例的大量 I/O 使用可能会影响不相关的实例。

• 使用网络会降低性能。

• 可扩展性会受到网络架构的影响。

在此选项中，每个计算节点都指定有大量磁盘空间，但分布式文件系统将每个计算节点的磁盘绑定到一个安装中。

此选项的主要优点是，当您需要额外存储时，它可以扩展到外部存储。

但是，此选项有几个缺点：

• 与非共享存储相比，运行分布式文件系统可能会使您失去数据局部性。

• 由于依赖于多个主机，实例的恢复变得复杂。

• 计算节点的机箱尺寸会限制计算节点中能够使用的心轴数量。

• 使用网络会降低性能。

• 计算节点的丢失会降低所有主机的存储可用性。

在此选项中，每个计算节点都指定有足够的磁盘来存储它托管的实例。

有两个主要优点：

• 一个计算节点上的大量 I/O 使用不会影响其他计算节点上的实例。直接 I/O 访问可以提高性能。

• 每个主机可以有不同的存储配置文件用于主机聚合和可用区。

有几个缺点：

• 如果计算节点发生故障，与在该节点上运行的实例关联的数据将丢失。

• 计算节点的机箱尺寸会限制计算节点中能够使用的心轴数量。

• 将实例从一个节点迁移到另一个节点更加复杂，并且依赖于可能不会继续开发的功能。

• 如果需要额外的存储空间，则此选项无法扩展。

在除计算节点之外的存