OpenStack系列(十八) 超融合架构
1 | 作者：李晓辉 |
超融合的概念
今天咱们来聊聊OpenStack里的超融合概念，这玩意儿挺有意思的。
超融合，简单来说就是把计算、存储和网络这些原本各自为政的功能，都整合到一个统一的平台上。就好比以前家里各种电器都有自己的插线板和开关，现在有了一个智能插座，把它们都集中管理起来，方便多了。
在OpenStack里，超融合架构能够把服务器的计算资源（CPU、内存这些）、存储资源（硬盘空间）以及网络资源（虚拟交换机等）融合在一起。这样做的好处可不少呢。首先，管理起来方便得很，以前可能要分别管理服务器、存储设备和网络设备，现在通过OpenStack的管理界面，就能一站式搞定，大大减少了运维的工作量。
其次，资源利用率也高了不少。因为这些资源都是共享的，根据不同的需求可以灵活分配。比如某个应用需要更多的存储空间，就可以直接从共享的存储资源池里分配，不需要像以前那样重新规划存储设备，还避免了资源的闲置浪费。
再有，这种架构的扩展性也很棒。要是业务量增加了，需要更多的资源，只需要简单地往超融合系统里添加一些节点（服务器），然后通过OpenStack的配置，就能把这些新节点的资源整合进来，整个过程比较平滑，不会对现有的业务造成太大影响。
不过，超融合也有一些需要注意的地方。比如，它对硬件的要求可能会高一些，因为需要硬件能够支持这种融合的架构。而且，一旦超融合系统中的某个节点出现故障，可能会影响到多个资源，所以对可靠性和容错机制的要求也更高了。
总的来说，OpenStack里的超融合概念是一个挺先进的思路，它让数据中心的资源管理更加高效、灵活，特别适合那些对资源动态调配需求比较高的场景，像云计算环境、一些大型企业的数据中心等。要是你对这方面感兴趣，可以再深入研究研究，现在这方面的技术也在不断发展呢！
超融合节点
在OpenStack的overcloud（也就是部署好的云环境）里，节点是按照角色（roles）来部署的，每个角色决定了节点上安装的服务和组件。在典型的Red Hat课堂部署中，你会看到像Controller（控制器）、Compute（计算节点）和CephStorage（存储节点）这样的预定义角色，不过实际上还有好多其他预定义角色呢。
今天重点给你说说另一个预定义角色——ComputeHCI。这个角色是用来部署超融合计算节点的。超融合节点就是把普通的虚拟化计算角色（hypervisor）和本地的Ceph OSD（存储组件）放在同一个计算节点上。简单来说，就是把计算和存储的功能都集成在一个节点里，而且Red Hat的超融合架构永远是用Ceph作为存储组件。超融合节点上的Ceph组件和普通的Ceph存储节点上的组件是一模一样的。
超融合存储的好处可不少！首先，成本更低，因为你不需要单独买一堆存储设备。其次，它在资源管理上更高效，操作起来也更灵活。比如在偏远分支机构或者边缘网络这种场景里，超融合节点就特别适合，因为这些地方资源有限，超融合可以更好地利用有限的资源。
那怎么把超融合节点加入到overcloud部署里呢？有两种方法。第一种方法不用单独配置或者分配ComputeHCI角色。你只需要设置一个参数，告诉系统把所有Compute角色的节点都当作ComputeHCI节点来配置。用这种方法，所有的计算节点都会变成超融合节点，不会出现普通的计算节点。
第二种方法是启用ComputeHCI角色，然后给每个计算节点分配Compute角色或者ComputeHCI角色。这种方法的好处是，你可以在一个Red Hat OpenStack Platform（RHOSP）集群里同时部署不同类型的计算节点。比如，你可以有一部分是普通的计算节点，另一部分是超融合节点，这样就能根据不同的需求灵活配置。
总之，超融合节点在很多场景下都非常实用，尤其是那些需要节省成本、提高资源利用效率的地方。要是你对这个感兴趣，可以再深入研究一下，说不定能发现更多好玩的东西呢！
查看课程中的超融合配置
角色分配
Overcloud节点是通过RHOSP（Red Hat OpenStack Platform）Director来部署的，而且它会用到部署配置模板（deployment configuration templates）。这些模板就像是一个“配方”，告诉系统怎么把各种角色（roles）分配到节点上。
现在，咱们可以去查看一下用来部署这个课堂环境Overcloud的模板文件，里面会列出所有配置好的角色。这些角色决定了每个节点上会安装哪些服务和组件，比如是控制器（Controller）、计算节点（Compute）、存储节点（CephStorage），还是超融合节点（ComputeHCI）之类的。
你可以把模板文件找出来，打开它，看看里面到底写了啥。说不定你会发现一些有意思的东西，比如某个节点被分配了特别多的角色，或者某个角色的配置有点不一样。这些信息对于理解整个Overcloud的架构和功能分布超有帮助！
先看看角色分配，都分配了哪些角色
1 | (undercloud) [stack@director ~]$ cd /home/stack/templates |
网络接口分配
再看看网络分配情况
在OpenStack的部署中，每个节点（比如计算节点、控制器节点）都需要连接到不同的管理网络（management networks），这样才能和其他节点通信，完成各种任务。而这些网络接口的配置，是通过网络配置模板文件（network configuration template file）来定义的。
简单来说，这个模板文件里会有一个“网络端口规范”（network port specification），它决定了哪些OpenStack管理网络会在分配了这个角色的节点上有一个接口。换句话说，它告诉系统：“嘿，这个角色的节点需要连接到这些管理网络哦！”
比如说，一个计算节点可能需要连接到管理网络、存储网络和外部网络，而控制器节点可能只需要管理网络和存储网络。这个规范就是用来定义这些连接关系的。
你可以去找到那个网络配置模板文件，然后查看里面的内容，看看哪些管理网络被分配给了某个特定的角色。这样你就能明白，为什么某些节点会有特定的网络接口，而其他节点则没有。
1 | (undercloud) [stack@director ~]$ cd /home/stack/templates/classroom-environment |
IP地址分配
说到网络接口，那些分配给这些接口的IP地址也是在同一个网络配置模板文件里定义的。这就像是给每个接口贴了个“地址标签”，让它们能在网络里找到自己的位置。
你可以把网络配置模板文件里的IP地址信息拿出来，然后去对比一下computehci0节点上的实际接口配置。比如，模板文件里可能写着某个管理网络接口的IP地址范围是192.168.1.0/24，然后你去computehci0节点上看，就会发现它的管理网络接口确实被分配了一个这个范围内的IP地址，比如192.168.1.10。
通过对比，你可以验证模板文件里的配置是否正确地应用到了实际的节点上。要是发现有不对劲的地方，比如IP地址冲突或者接口没正确配置，就可以及时调整。这种对比检查是个很实用的小技巧，能帮你更好地理解整个网络是怎么搭建起来的，也能确保系统运行得更稳定。
1 | (undercloud) [stack@director ~]$ cd /home/stack/templates/classroom-environment |
超融合概念总结
超融合架构（HCI）真的是个超级厉害的玩意儿！它最大的好处就是省钱和省空间。为啥呢？因为它允许你用标准化的私有云组件来搭建整个系统。这就像是搭积木一样，用统一的模块来构建，不仅方便，而且成本也低。而且，超融合架构还能把计算和存储功能当作一个整体来管理，这可比分开管理方便多了。
超融合架构的另一个大优点是，它能让应用在数据中心和远程网络之间更轻松地迁移。想象一下，你有一个应用，不管是在本地数据中心还是在偏远的分支机构，都能无缝切换，这得多方便啊！而且，超融合架构在边缘网络的网络功能虚拟化（NFV）部署上也有很大的优势，能让你在边缘网络上更灵活地部署各种功能。
再来说说Red Hat OpenStack Platform（RHOSP）。这东西真的是太灵活了！它允许你在同一个集群里混用标准的计算节点、Ceph存储节点和超融合节点。这就像是一个“万能拼图”，你可以根据自己的需求，把不同类型的功能模块组合在一起。
RHOSP的扩展性也特别强。不管你的业务是增长了，还是应用需求变了，RHOSP都能灵活调整，增加计算资源或者存储资源。而且，它既可以支持集中式的节点配置，也可以支持分布式的节点配置。换句话说，你可以根据自己的场景，选择最适合的架构。
举个例子，如果你的业务主要集中在数据中心，你可以用集中式的配置；如果你有很多远程分支机构，那分布式配置可能更适合。RHOSP都能搞定！
总之，超融合架构和RHOSP的结合，简直就是“强强联手”，既能省钱省空间，又能灵活应对各种复杂的场景。要是你手头有类似的项目，真的可以考虑一下这种方案！
构建超融合环境注意事项
要是你想在OpenStack的overcloud里用超融合节点，那在部署之前得先搞定一些配置
资源隔离
超融合节点把计算服务（Compute）和Ceph存储服务（OSD）放在同一个系统里，这就像是在一个房间里同时住两个人。但默认情况下，计算服务并不知道它要和另一个“大块头”服务共享资源。这就容易出问题，比如系统不稳定，或者能运行的虚拟机数量变少。所以，超融合节点需要“调教”一下，给计算服务设置资源限制，这样才能保证系统稳定，还能最大化运行虚拟机的数量。
这些资源限制是在部署或者升级overcloud的时候，通过计划环境文件（plan environment files）来配置的。虽然RHOSP的具体安装步骤咱这课里不讲，但了解一下这些资源限制是怎么算出来的，还是很实用的。Red Hat提供了一些默认的计划样本文件，里面有好几种CPU和内存分配的工作负载配置文件（workload profiles），你可以根据自己的需求选一个合适的。
工作负载配置文件里有两个关键参数：average_guest_memory_size_in_mb（平均虚拟机内存大小）和average_guest_cpu_utilization_percentage（平均虚拟机CPU利用率）。这两个参数用来计算计算服务的reserved_host_memory（预留主机内存）和cpu_allocation_ratio（CPU分配比例）设置。这些值是根据Red Hat的建议算出来的，不过你也可以在计划环境文件里手动修改其中一个或两个最终的计算服务设置。
举个例子，reserved_host_memory参数决定了在超融合节点上，要给Ceph OSD服务和每个虚拟机的额外开销预留多少内存。假设一个节点有256GB内存，有10个OSD，每个OSD平均占用3GB内存，那给Ceph预留30GB内存后，剩下的226GB内存就可以用来做计算，能运行113个每个占用2GB内存的虚拟机。
再比如，cpu_allocation_ratio参数决定了计算调度器在选择部署虚拟机的计算节点时，应该用什么比例来分配CPU资源。默认值是16:1，也就是说，如果一个节点有24个CPU核心，那计算调度器会在这个节点上安排足够多的虚拟机，直到它们总共占用384个vCPU，才会认为这个节点不能再运行更多虚拟机了。
Red Hat的《超融合架构指南》里附录有个“计算CPU和内存计算器”，专门解释了这些资源限制参数是怎么算出来的。要是你对这块感兴趣，可以去瞅瞅。
Ceph回填（Backfill）
Ceph存储有个机制，当移除一个OSD时，它会通过回填（backfill）和恢复（recovery）过程来重新平衡存储集群。为啥要这么做呢？因为Ceph要根据放置组策略，保持数据的多个副本。不过，这两个操作会占用系统资源，所以当Ceph存储集群负载很高时，性能就会下降，因为Ceph会把资源优先分配给回填和恢复操作。
为了在移除OSD时保持Ceph存储的性能，可以降低回填和恢复操作的优先级。不过，这么做也有代价：数据副本的数量会在更长的时间内减少，数据的风险会稍微增加一点。
和资源限制类似，这些回填和恢复操作的调整参数也是在overcloud部署计划环境文件里设置的。这里简单说说需要修改的三个变量：
osd_recovery_max_active参数设置了每个OSD同时允许的活动恢复请求的数量。请求越多，恢复速度越快，但也会给集群带来更大的负载。osd_max_backfills参数设置了单个OSD允许的最大回填数量。osd_recovery_op_priority参数设置了恢复操作的优先级，它是相对于osd_client_op_priority参数来说的。
总之，搭建超融合环境需要提前做好这些配置，虽然听起来有点复杂，但其实都是为了让系统更稳定、更高效。
要是你想了解更多关于Ceph OSD（Object Storage Daemon）可配置参数的内容，可以去瞅瞅《Red Hat Ceph Storage Configuration Guide》（Red Hat Ceph存储配置指南）。这本指南里有超多细节，能帮你深入了解怎么调整和优化Ceph存储的各种参数。
主机聚合
主机聚合就像是在可用区（Availability Zone）里给节点们再细分一下“小组”。你可以把一些节点归到一个组里，然后给这个组贴上一些“标签”（其实就是键值对，比如key=value这种形式的元数据）。这些标签能帮助你更精细地控制虚拟机（实例）的部署和调度。
比如说，你可以把一些性能很强的节点归到一个组里，给它们贴上一个“高性能”的标签；或者把有特殊硬件（比如GPU）的节点归到另一个组，贴上“有GPU”的标签。这样一来，当你需要部署一个需要高性能或者GPU的虚拟机时，系统就能根据这些标签，把虚拟机放到合适的节点上。
怎么创建和配置主机聚合？
创建和配置主机聚合需要管理员权限，因为这是比较核心的管理功能。你可以创建多个主机聚合，一个节点也可以属于多个聚合。而且，你可以给一个聚合设置多个键值对标签，只要能满足你的需求就行。
主机聚合怎么工作？
当你要启动一个虚拟机的时候，你可以给这个虚拟机指定一些自定义的“口味”（flavor metadata，也就是一些特殊的配置要求）。这些要求会传递给计算调度器（Compute scheduler），然后调度器就会根据这些要求，在可用区里找到合适的主机聚合。
比如说，你有一个虚拟机需要高性能的CPU，你就在它的配置里加上一个“高性能”的标签。调度器收到这个要求后，就会去那些被标记为“高性能”的主机聚合里找节点来部署这个虚拟机。这样一来，你就能根据节点的特性，把虚拟机放到最合适的地方，还能控制虚拟机的部署或者迁移。
主机聚合是个特别实用的功能，它能让你在OpenStack里更灵活地管理节点，还能根据虚拟机的需求，把它们放到最适合的节点上。要是你正在用OpenStack，或者想优化你的资源管理，主机聚合绝对值得一试！
咱们再深入聊聊OpenStack里的主机聚合（Host Aggregates）和可用区（Availability Zones），还有它们怎么影响用户和管理员的操作。
用户视角：看不见聚合，但能用“口味”来选择
对于普通用户来说，他们其实看不到后台配置好的主机聚合。用户不需要直接和主机聚合打交道，而是通过选择合适的“口味”（flavors）来间接指定虚拟机需要的主机特性。这些“口味”里包含了元数据（metadata），比如“需要高性能CPU”或者“需要GPU”之类的。
当用户启动虚拟机的时候，这些元数据会被传递给计算调度器（Compute scheduler）。调度器会根据这些要求，从主机聚合里筛选出符合要求的节点来部署虚拟机。所以，用户只需要关心“我要什么特性”，而不用管“这些特性在哪个节点上”。
管理员视角：配置主机聚合和“口味”
管理员就厉害多了，他们可以配置主机聚合和“口味”，并且给它们设置匹配的元数据属性。管理员需要在主机聚合上设置键值对（key-value pairs），比如“高性能CPU=true”，然后在对应的“口味”上也设置同样的属性。
举个例子，管理员可以在一个主机聚合上设置high_performance=true，然后创建一个“高性能”口味，也在这个口味上设置high_performance=true。这样一来，当用户选择了这个“高性能”口味来启动虚拟机时，调度器就会把虚拟机部署到那个被标记为“高性能”的主机聚合里的节点上。
可用区：特殊的主机聚合
可用区其实也是一种主机聚合，只不过它通常用来表示地理位置上的分组，比如“数据中心A”或者“数据中心B”。可用区有一个特殊的标志（flag），这个标志可以让普通用户看到并选择可用区来控制虚拟机的启动。管理员可以在任何主机聚合上设置这个标志，让它看起来像一个可用区。
不过，可用区和普通主机聚合有一个重要的区别：一个节点可以属于多个主机聚合，但只能属于一个可用区。这就像是一个节点可以有多个“标签”，但只能属于一个“地理位置”。
简单来说，普通用户通过选择合适的“口味”来间接指定虚拟机需要的特性，而管理员则通过配置主机聚合和“口味”的元数据来实现这些需求。可用区是一种特殊的主机聚合，可以让用户根据地理位置来选择节点。这种设计既方便用户使用，又给了管理员足够的灵活性来管理资源。
互动环节
- 你认为超融合架构在你的项目中是否适用？为什么？
- 你是否尝试过在OpenStack中配置主机聚合？遇到了哪些问题？
- 你对超融合节点的资源隔离配置有什么建议？
- 微信
- 支付宝
