OpenStack 系列（架构篇 1）- 企业需求
前言：个人看法，学习一门技术，先从整体架构视角去了解，让自己有个总体概念。带着问题去查阅官方文档，技术路线会更加清晰，比如它为什么会出现（背景）、帮助谁解决什么样的问题（场景）、如何解决的（方式）、设计思路是什么（架构）。
本篇文章内容翻译自 OpenStack 官网 ^1。
总的看，从 13 个方面来考虑影响基于 OpenStack 构建的云设施。分别是：
- 成本
- 上市耗时
- 机遇收益
- 容量规划与扩展
- 性能
- 网络
- 规约与地理位置
- 审计
- 安全
- 服务承诺
- 应用就绪状态
- 认证
- 迁移，可用性，站点损失及恢复
对于任何一个组织，财务都是主要考虑的因素。成本的考虑会很大程度上影响你所能构建成什么类型的云平台。在选择或者设计云平台时，成本不应该成为制约因素。
作为一份通用指引，云平台架构复杂性的增加，构建和维护的成本也会同步增加。比如，一朵混合或多站点部署的云架构，涵盖了多供应商和多种技术架构，就可能需要投入更高的安装和运维成本；因为相比其他架构，它需要更先进的编排系统和易用的工具集。
设计一套云平台，通常会考虑以下成本目录：
- 计算资源
- 网络资源
- 平台副本
- 存储资源
- 平台管理
- 运维成本
云平台扩展时所需的成本，需要重点考虑。同时，整体建设成本最小化也是比较重要的。运维海量可扩展的 OpenStack 云平台时，使用商业硬件和自由可用的开源软件组件，有助于降低部署成本和运维投入，可参考 Open Compute 提供的额外信息。
上市耗时
构建云平台时，是否具备相对稳定的服务或产品发布耗时能力，是常见的商业因素。让用户自助按需获得计算、网络、存储资源，可能帮助到他们的产品或者应用减少投产上市的时间。
你需要权衡构建云平台和迁移用户上云的耗时。在某些场景下，现有的基础设施会影响他们的架构选型。比如，对于一个已有的投资系统（内含多个应用），使用多云平台可能会是一个更优选项，毕竟它能快速地将各组件串联在一起而不是全部重构上到一套云平台。
机遇收益
机遇收益很大程度上受制于云平台的意图和用户案例。商业需求、客户面临的产品都会不同程度上影响到一套内部的、私有的云平台。你一定要考虑云平台具备哪些功能特性，来吸引你的用户。
容量规划与扩展
容量和工作负载的布置是云平台的关键设计因素。长期的容量规划必定满足随时间推移的增长需求，避免资源耗尽的情况。
预测特定应用工作负载是比较困难的，因为它受用户量、应用成熟度等因素影响。定义出应用需求还是很有可能的，比如 vCPU，RAM，bandwidth，及其他资源。不同云平台可能使用不同的度量维度，甚至会有不同的超售配额。
超售配额是一种虚拟化出比物理资源更多大容量的方式。例如，一台 32 GB RAM 物理节点可能承载着 24 个 2 GB RAM 主机实例。这 24 个实例并不会同时都使用 2 GB RAM，这种超售方案能很好工作。但是，某些主机消耗超过了资源极限，最终会产生不符合预期的性能表现。固然是需要根据容量规划来设计超售配比。
性能
设计任何一套云平台，性能都是核心考虑因素。随着规模和复杂度的提升，性能越显突出。单站点、私有云基本是可控的，多站点和混合部署则需要更多关注规划来减少问题，比如站点间的延迟。
例如，你应该考虑各种方法来降低不同云平台间的工作负载耗时。这可能需要将数据搬得离应用更近些，或者将应用更靠近数据的地方以及功能化分组，最终在单套云平台内获得更低延迟的连接，甚至在多套云平台间。
这样可能需要一套 CMP 云管平台来协助决策哪些云资源适合哪些类的工作负载。
使用原生的 OpenStack 工具集能够帮助提升性能。比如，你可以使用遥测来衡量性能以及编排服务（心跳），以应对按需带来的变化。
云资源部署
云平台用户期望拥有可重叠的、可依赖的以及确定的进程来拉起和部署云资源。你应该通过基于 web 界面接口或者公共可用的 API 端点来发布这些资源。所有请求云资源的可能选项都必需通过某种用户接口、命令式接口（CLI）或者 API 端点来启用。
消费模型
云平台用户期望一种完全自助、按需获取的消费模型。当一个 OpenStack 云平台满足了海量可伸缩的资源诉求，能轻松应对该种消费模型。
- 一切必需自动化。例如，所有的计算硬件、存储硬件、网络硬件，采用某种可支持的软件来进行安装及配置。手动操作对构建海量可伸缩的 OpenStack 设计架构是不切实际的。
- 海量可伸缩的 OpenStack 云平台需要配齐可扩展的度量和监控功能来最大化运维效率，通过保持知悉这些基础设施的状态信息。这就包括了全部硬件和软件的状态度量。一套同类的日志和告警功能需同样配备，用于存储和开启这些有度量和监控方案提供的度量指标。云平台运维者需要知道度量和监控方案提供的数据用于规划容量和容量趋势分析。
位置
对于许多用户使用场景，他们的应用性能受到工作负载的直接影响，所以在设计时应该考虑到。特定的应用通过部署在多位置的云平台，有可能获取接近零延迟。这些位置可能分布在不同的数据中心、城市、国家或者地理区域，取决于用户需求及用户所在位置。
I/O 需求
I/O 性能需求需在决定一个最终存储框架前完成调研和建模。运行基准测试来提供预期的性能水平基线。如果这些测试包含了许多细节，最终数据能更有利于建模和评估不同的工作负载。在整个架构生命周期内，运行脚本化的小基准测试能及时记录系统健康度。这些来自脚本化基准测试的数据，在未来能帮助限定和深入理解一个组织的需求。
伸缩
在关注存储方面，OpenStack 架构设计可伸缩存储方案是由最初的需求驱动的，包括了 IOPS，容量，带宽以及未来需求。基于项目的容量规划，需要覆盖全程的消耗，在设计时是非常重要的。该架构应该平衡成本和容量，在两者间通过新技术和方法来满足灵活性要求。
网络
考虑网络的功能性、安全性、可伸缩性、可用性和可测试性是非常重要的，特别是在选择一套 CMP 平台及一家云厂商的时候。
- 依赖于网络框架和设计最小功能测试用例。在升级期间或之后，这能确保测试和功能的完整性。
- 可伸缩性涵盖多云厂商可能限定的底层网络框架，尤其在选择不同云厂商时。提供网络 API 接口功能及用于验证功能完整性，特别是选择了跨多云端点，就显得尤为重要。
- 高可用在功能实现和设计时，都需要考虑到。常见的模式主 - 热备、主备和主主。高可用的开发和测试框架，对于保证功能和条约是非常有必要的。
- 考虑数据在客户端和端点、不同云平台间传输流量的安全性。
例如，视频流延迟和低质量的 VoIP 通话就会较大影响用户体验，潜在可能导致产品和经济的损失。
网络误配置
配置了不正确的 IP 地址、VLAN 号和路由器，都有可能引起大范围的网络故障，极端情况下，影响整套基础设施。自动化的网络配置能极小化这种运维错误的几率而导致灾难性的事故。
容量规划
云网络需要对容量进行管理和及时的扩充。容量规划包括了网络设备购买和硬件潜在长达数月/年的中断。
网络调优
配置云网络需要最小化链路缺失、丢包、包风暴、广播风暴及环路。
单点故障
在物理和各种环境，都要考虑高可用。如果存在单故障点，比如单个上游连接、单电源供电，都会导致无法避免的故障。
复杂度
一份过于复杂的网络设计，会难以运维及问题定位。在设备层面配置要易于维护，能用自动化工具处理覆盖式网络，在功能和特定设备上，通过避免或者记录下非传统式的交汇点，进而规避故障。
非标准特性
通过配置云厂商网络来获得厂商的特定特性，这是比较冒险的。例如 MLAG 多链接聚合模式，用来在网络交换聚合器中提供冗余度。MLAG 不是一份标准，结果不同厂商都有自己的实现逻辑。MLAG 架构是不适合于跨多交换机厂商的，它会导致被厂商锁定，以及组件升级延迟甚至不可用等。
动态资源扩张或突发
一个应用需要额外的资源来满足多云架构。例如，零售商只是在假期需要额外的资源，但不想再添加其他的云资源来应对需求洪峰。这些用户额外带来的突增负载，在这期间，可在公共云资源上来对应。这些突增的时间，有可能长达数小时到年不等。
规约与地理位置
一个组织可能有明确的法律义务和正规规约来评估哪些明确的工作负载或数据不能被落地到指定的区域。
对于多站点的云平台，规约要素是相当重要的，包括：
- 联邦法律需求
- 本地司法法律和规约需求
- 镜像一致性和可用性
- 存储副本和可用性（包括块存储和文件/对象存储）
- 认证、授权和审计（AAA）
地理因素可能同样影响数据中心构建/租赁成本，包括：
- 楼宇空间
- 楼宇承重
- 机柜高度和类型
- 环境因素
- 电力使用和电力使用有效性
- 物理安全性
审计
一个全方位的审计计划，对于快速排查问题是非常关键的。持续跟踪安全组的变化和租户的变化，在生产环境对于需要回滚变更是很有用的。比如，如果某个租户的所有安全组规则消失了，迅速跟踪出该问题的能力，对于运维和合理性解释是非常的重要。
安全
各类型组织使用云平台有着不同级别的安全需求。例如，政府和金融机构通常由非常高的安全需求。安全应当依据资产、威胁和漏洞风险等多方位来保障。
服务承诺
SLA 是一定涵括在商业、技术和法律里。小的、私有的云平台可能是包含一份简单 SLA，但混合或者公有云平台通常会有多份正式协议书给到用户。
对于一个海量可伸缩的 OpenStack 公有云平台用户，对于掌控安全、性能或可用性是没有多少期望。用户只关注 API 服务运行时长 SLA、基本的服务 SLA。用户根据职责来定位这些他们关心的议题。对于公有云设施，超出预期的是非常的罕见，构建私有或政府机构的则会有明确的清单。
搞性能系统会有 SLA 清单说明最低等级的服务质量，涵盖保证运行时长、延迟和带宽。SLA 等级更多会受网络架构和系统冗余度需求的影响。
混合云的 SLA 一定要满足厂商的能力和权力范围的差异。
应用就绪状态
有些应用是能容忍对象存储同步缺失的，但其他则需要这些对象副本并在各区域可用。理解这些云资源实现逻辑如何影响新建、或存量的应用，对于风险迁移、成功上云都是很重要的。应用可能需要重写来适配无冗余的基础设施或云平台。
应用压力
存量应用的业务，可能会发现，相比迁移到一套云平台，集成到多套云平台会更加艰难。
非预期使用模型
缺失预定义使用模型，会让用户不知如何为各种应用评估需求。它可以提供应用所需的独立程度和灵活性，这些不是其他非云平台场景下能提供的。
按需和自助式应用
云平台提供终端用户能通过简单灵活的方式去按需获取计算、存储、网络和软件资源。用户能够扩展资源来提升服务质量，避免受到底层操作影响。使用通用型云平台架构收益之一，就是有能力从最初有限资源开始按需扩展资源应对增长诉求。
认证
比较推荐采用集中式认证服务，而不是每个站点都实现一套。这就要求认证机制是高可用且支持分布式的。认证服务器定位就应该提前做好设计。
迁移，可用性，站点损失及恢复
故障都可能会导致部分或全部站点功能不可用。提前制定策略来应对这些场景：
- 部署的应用需能够持续提供服务，站点不可用一定要考虑带来的性能和应用可靠性影响。
- 站点故障时，弄清楚各种对象和数据副本发生了什么是很重要的。如果产生了队列阻塞，需要评估这些阻塞会持续多久就会导致系统错误。
- 故障过后，确保能找到正确的方法来应对下一次同样的出现。我们建议你从架构上恢复策略而避免各种竞态条件。
灾难恢复与业务持续性
更加偏移的存储策略能让公有云找到合适的备份策略。
迁移场景
混合云架构能让应用在不同云平台间迁移。
厂商可用性或实现细节
业务变更能影响厂商的可用性。比如，服务变更就可能中断一个混合云的环境或者增加成本。
厂商 API 变更
依赖外部云厂商服务，难以控制厂商不去变更 API，变更可能会破坏兼容性。尽量使用通用的 API 来尽可能减少潜在的冲突。
镜像插拔
就像 Kilo 版本发布一样，没有一个通用镜像格式适用于所有的云平台。在不同云平台间迁移，需要提前协商好镜像格式。为了简化部署，使用最小化和最简单的镜像，只安装那些必需的组件，使用部署管理器（如 Chef、Puppet）。别为了加速处理而使用笨重的镜像，除非你是在同一云平台上部署这些镜像。
API 差异
避免使用不仅仅只是 OpenStack 或者带有不同版本 OpenStack 的混合云平台，就像 API 变更一样会带来兼容性问题。
业务或技术多样性
许多组织根据业务多样性，使用多厂商的混合云平台方案来分摊这些工作负载。这能保证应用的主机资源不被厂商锁定。