企业需求

以下章节描述了会影响云架构设计的业务、使用和性能方面的考虑因素。

成本

财务因素是任何组织的首要关注点。成本考虑因素可能会影响您构建的云的类型。例如，通用云可能不是专业应用程序最具成本效益的环境。除非业务需求规定成本是关键因素，否则在选择或设计云时，成本不应是唯一的考虑因素。

作为一般指导原则，云架构的复杂性越高，构建和维护的成本就越高。例如，涉及多个供应商和技术架构的混合或多站点云架构可能需要比其他架构更高的设置和运营成本，因为需要更复杂的编排和经纪工具。但是，通过使用云经纪工具将工作负载部署到最具成本效益的平台，总体运营成本可能会降低。

在设计云时，请考虑以下成本类别

• 计算资源

• 网络资源

• 复制

• Storage

• 管理

• 运营成本

同样重要的是要考虑云扩展时成本将如何增加。在小型系统中影响微不足道的选择，可能会在大型系统中大大增加成本。在这些情况下，重要的是在堆栈的所有层面上尽量减少资本支出 (CapEx)。大规模 OpenStack 云的运营商需要使用可靠的通用硬件和免费的开源软件组件来降低部署成本和运营费用。Open Compute（更多信息请参见 Open Compute Project）提供了更多信息。

上市时间

在构建云时，在灵活的时间范围内交付服务或产品是一种常见的业务因素。允许用户自助配置并按需访问计算、网络和存储资源，可以缩短新产品和应用程序的上市时间。

您必须平衡构建新云平台所需的时间与将用户迁移到旧平台所节省的时间。在某些情况下，现有基础设施可能会影响您的架构选择。例如，当在多个应用程序中进行现有投资时，使用多个云平台可能是一个不错的选择，因为将投资联系起来可能比迁移组件并将其重构到单个平台更快。

收入机会

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

容量规划和可扩展性

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

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

超额订阅是一种模拟比物理上存在的容量更多的方法。例如，具有 32 GB RAM 的物理 hypervisor 节点可以托管 24 个实例，每个实例配置 2 GB RAM。只要所有 24 个实例不同时使用 2 GB 内存，这种安排就可以很好地工作。但是，有些主机将超额订阅推向极端，因此，性能可能不稳定。如果可能，请确定每个主机的超额订阅率并相应地规划容量。

性能

性能是设计任何云的关键考虑因素，并且随着规模和复杂性的增长变得越来越重要。虽然单站点私有云可以被密切控制，但多站点和混合部署需要更仔细的规划，以减少网络延迟等问题。

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

这可能还需要一个 CMP，它可以确定哪个云可以最有效地运行哪种类型的工作负载。

使用本机 OpenStack 工具可以帮助提高性能。例如，您可以使用 Telemetry 测量性能，并使用 Orchestration 服务 (heat) 对需求变化做出反应。

注意

编排需要特殊的客户端配置才能与 Amazon Web Services 集成。对于其他类型的云，请使用 CMP 功能。

云资源部署

云用户期望可重复、可靠和确定性的流程来启动和部署云资源。您可以通过基于 Web 的界面或公开可用的 API 端点来提供此功能。所有合适的云资源请求选项都必须通过某种类型的用户界面、命令行界面 (CLI) 或 API 端点提供。

消费模式

云用户期望完全自助和按需的消费模式。当 OpenStack 云达到大规模规模时，预计每种方式都将提供按需服务。

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

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

位置

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

输入/输出要求

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

规模

在以存储为中心的 OpenStack 架构设计中扩展存储解决方案受初始需求驱动，包括 IOPS、容量、带宽和未来需求。基于预算周期内预计的需求规划容量对于设计非常重要。该架构应平衡成本和容量，同时允许在可用时实施新技术和方法。

网络

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

• 确定网络框架并设计最小功能测试。这确保了升级期间和升级后测试和功能得以保留。

• 跨多个云提供商的可扩展性可能会决定您在不同云提供商中选择的基础网络框架。重要的是要呈现网络 API 功能并验证所有选择的云端点上的功能是否得以保留。

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

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

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

网络配置错误

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

容量规划

云网络需要管理容量和随着时间的推移进行增长。容量规划包括购买网络电路和硬件，这些硬件的交货时间可能长达数月或数年。

网络调优

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

单点故障 (SPOF)

考虑物理和环境层面的高可用性。如果由于只有一个上游链路或只有一个电源而存在单点故障，则停机可能无法避免。

复杂性

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

非标准功能

配置云网络以利用供应商特定功能会产生额外的风险。一个例子是在网络聚合器交换机级别使用的多链路聚合 (MLAG) 用于提供冗余。MLAG 不是标准，因此，每个供应商都有自己专有的功能实现。MLAG 架构在交换机供应商之间不可互操作，这会导致供应商锁定，并可能在升级组件时导致延迟或无法升级。

动态资源扩展或爆发

需要额外资源的应用程序可能适合多云架构。例如，零售商在假日期间需要额外资源，但不想添加私有云资源来满足峰值需求。用户可以通过在这些峰值期间爆发到公共云来适应增加的负载。这些爆发可以是长周期或短周期，范围从每小时到每年。

合规性和地理位置

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

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

• 联邦法律要求

• 地方管辖法律和合规性要求

• 镜像一致性和可用性

• 存储复制和可用性（块存储和文件/对象存储）

• 身份验证、授权和审计 (AAA)

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

• 楼层空间

• 楼层重量

• 机架高度和类型

• 环境考虑因素

• 电力使用和电力使用效率 (PUE)

• 物理安全

审计

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

安全

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

服务级别协议

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

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

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

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

应用程序准备情况

有些应用程序可以容忍缺乏同步对象存储，而另一些可能需要这些对象在区域之间复制并可用。了解云实施对新旧应用程序的影响对于风险缓解和云项目的整体成功至关重要。应用程序可能需要为几乎没有冗余的基础设施或为云而设计进行编写或重写。

应用程序发展势头

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

无预定义的使用模型

缺乏预定义的使用模型使用户能够在无需提前了解应用程序要求的情况下运行各种应用程序。这提供了一种其他云场景无法提供的独立性和灵活性。

按需和自助式应用程序

从定义上讲，云为最终用户提供了一种简单而灵活的方式来自助配置计算能力、存储、网络和软件。用户必须能够将他们的资源扩展到相当大的规模，而不会破坏底层主机操作。使用通用云架构的好处之一是能够从有限的资源开始，并随着用户需求的增长而逐步增加资源。

身份验证

建议使用单个身份验证域，而不是为每个站点实施单独的身份验证。这需要一种高度可用且分布式的身份验证机制，以确保持续运行。站点身份验证服务器的本地性可能需要，并且应该提前规划。

迁移、可用性、站点丢失和恢复

中断会导致站点功能的局部或完全丢失。应实施策略来理解和规划恢复场景。

• 部署的应用程序需要继续运行，更重要的是，您必须考虑站点不可用时对应用程序性能和可靠性的影响。

• 重要的是要了解站点发生故障时，站点之间对象和数据的复制会发生什么。如果这导致队列开始累积，请考虑这些队列在发生错误之前可以安全存在多长时间。

• 在中断后，确保在站点恢复在线时，恢复站点正常运行的方法已实施。我们建议您设计恢复以避免竞争条件。

灾难恢复和业务连续性

更便宜的存储使公共云适合于维护备份应用程序。

迁移场景

混合云架构能够实现应用程序在不同云之间的迁移。

提供商可用性或实施细节

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

提供商 API 变更

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

镜像可移植性

截至 Kilo 版本，没有一种通用的镜像格式可供所有云使用。如果要在云之间迁移，则需要转换或重新创建镜像。为了简化部署，请使用尽可能小和简单的镜像，仅安装必要的内容，并使用部署管理器，例如 Chef 或 Puppet。除非您在同一云上重复部署相同的镜像，否则不要使用黄金镜像来加快流程。

API 差异

避免使用仅包含 OpenStack（或不同版本的 OpenStack）的混合云部署，因为 API 更改可能会导致兼容性问题。

业务或技术多样性

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