13518219792
这篇文章将为大家详细讲解有关OpenStack如何横向扩展配置，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
专注于为中小企业提供成都网站设计、成都网站制作服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业宽城免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了1000多家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。
起点
如何计划云系统扩展性需要在很多的变量配置中进行平衡。没有***方案可以满足所有的扩展需求。即使这样在实际运维中监控大量系统指标还是有很多益处。
常见的规划出发点就是云系统的核心数量。可用一些基本公式，估算相关容量信息。如：(重用因子 X 物理核数) / 每实例所需虚拟核：估算可运行虚拟机数量；磁盘空间 X 实例数量：估算系统需求的存储容量。通过这些估算信息可以决定在云中额外需要添加多少资源。
OpenStack的系统默认值如下：
| 名称 | 虚拟核数 | 内存 | 磁盘空间 | 临时空间 |
| m1.tiny | 1 | 512 MB | 0 GB | 0 GB |
| m1.small | 1 | 2 GB | 10 GB | 20 GB |
| m1.medium | 2 | 4 GB | 10 GB | 40 GB |
| m1.large | 4 | 8 GB | 10 GB | 80 GB |
| m1.xlarge | 8 | 16 GB | 10 GB | 160 GB |
我们假设以下条件：
200个物理核 大部分实例是m1.medium类型(2虚拟核，50GB存储空间) 默认是的CPU重用因子16:1（在nova.conf文件中配置cpu_allocation_ratio参数) 按照公式计算(16 X 200) / 2 = 1600，该硬件环境可以支持1600个虚拟机实例和需要80TB的存储空间 |
对于API服务，数据库和消息队列则需要更多信息才能进行评估。你还需要了解云系统的使用规律。比如：比较2种虚拟机的使用情况，一种是用于web平台，另一种是用于项目开发过程中使用的集成测试。前者所用的虚拟机可能每隔几个月才有增加；而后者则经常会发生变动，造成对云控制器较多请求负荷。收集虚拟机的平均使用时间，当该指标值较大时相应的云控制器的负荷会较小。
伴随的虚拟机的开启和关闭，还需要考虑用户对于服务访问所造成的影响，特别是nova-api和相应的数据库。用户最常用的就是列出虚拟机实例清单和相关信息。当云系统有很多用户时，列出虚拟机实例清单这样的操作也会带来较大的系统负荷。有时用户自己都没有意识到这种操作(如：打开OpenStack仪表盘进入实例页界面中，浏览器会每隔30秒刷新一次虚拟机列表信息)。
在考虑了以上因素后，你可以大致判断出云控制器的配置要求。通常8核，8G内存的服务器足以应付一个服务器机架内的计算节点。
除此外为了用户使用虚拟机的性能，你还需要考虑硬件本身的一些指标，同时平衡预算和性能需求。如：存储性能(磁盘数量/核数)，内存可用性(内存空间/核数),网络带宽(Gbps/核数)和CPU总性能(CPU/核数)。
可以查看**监控**章节获得可以跟踪哪些指标来判断是否需要进行云系统的扩展。
添加控制器节点
你可方便的通过添加更多的节点来横向扩展云系统。添加计算节点是一件容易的事情，你只需要和原来一致的方式进行安装配置。但同时为了云系统的高可用，你在设计时就需要考虑以下几个要点。
本书中的例子中云控制节点上会运维多个服务。有些直接通过消息队列通讯的服务(如：nova-scheduler，nova-console)可以较简单的安装到其他硬件环境中。但其他服务则更麻烦一些。
对于用户访问的服务，如：仪表盘，nova-api，对象存储，则建议采用通过负载均衡方式分摊访问请求。任何标准的HTTP负载均衡方式都可以使用(DNS轮询，负载均衡硬件或软件(如Pound或HAProxy))。仪表盘需要注意的是VNC proxy。VNC proxy使用的是WebSocket协议，而对于第7层应用的负载均衡处理这种协议则有问题。请参见横向回话存储(Horizon session storage)(http://docs.openstack.org/developer/horizon/topics/deployment.html#session-storage)
有些服务(如：nova-api，glance-api)通过修改配置文件中的标示可以支持多进程。多进程可以更好的在多核CPU的硬件上分配计算任务。
有部分的配置可用于MySQL负载均衡，RabbitMQ也支持内建的集群机制。请参考运维章节获得更多关于配置各种服务的信息。
云系统隔离
使用OpenStack中的方法进行云系统的隔离，方法有：cells, regions, zones和host aggregates。每种方法提供了不同的功能，具体功能能描述如下：
cells 使用场景：需要单个API endpoint或需要二次调度；例子：云系统中有多个地点，虚拟机可以任意调度运行或指定地点运行；系统开销：每个节点除nova-api外都需要完整安装nova环境，和nova-cell服务；共享服务：Keystone，nova-api。 Regions 使用场景：需要分割的Region，Region间没有通讯协调机制，各自需要独立的API endpoint；例子：云系统需要区分多个地点，可以指定在这些地点间调度分配虚拟机。多个地点间是共享底层基础架构；系统开销：每个Region中需要独立的API endpoint，每个Region需要安装完整的nova环境； 共享服务：Keystone。 Availability Zones 使用场景：为了保证硬件的隔离和冗余，可以逻辑上将nova分散部署；例子：一个地点的云系统，底层硬件分别有2个供电系统；系统开销：配置nova.conf配置文件；共享服务：Keystone，所有nova服务。 Host Aggregates 使用场景：一组具有类似特性的主机，期望能组合在一起进行虚拟机调度；例子：在一组信赖的服务器上调度运行虚拟机；系统开销：配置nova.conf配置文件；共享服务：Keystone，所有nova服务。 |
以上隔离方案可以分成2大类：
cells & regions：用于将nova部署服务进行隔离。 availability zones & host aggregates：用于将部署地点进行隔离。
Cells & Regions
OpenStack的cell是一种分布式运行方式，该方式下不需要引入过于复杂的技术且也不会影响已存在nova环境。支持运行云系统的服务器通过分组，每组就是一个Cell，Cell是一种按照树状方式组织资源的方式。Cell树根节点cell(API cell)服务运行nova-api服务，该服务器上不运行nova-compute服务。在根节点之下的服务器运行除nova-api外所有nova-*服务。每个Cell运行自己的消息队列，数据库和nova-cells服务。nova-cells服务管理根节点cell和子节点cell之间的通讯。
以上的Cell方式可以运行单个的API服务用于控制多个云环境。在nova-scheduler直接调度选择服务器资源外，也引入了二次调度的形式(调度选择cell资源)。cell的这种间接调度方式给控制虚拟机带来了更灵活的控制方式。
和Cell不同的是Region是一种隔离度比cell更高的方式，该方式下不同的region中需要独立有相应的API endpoint。用户需要在不同的Region中运行虚拟机实例需要明确的指定Region。Region下没有其他额外的服务需要运行。
当前OpenStack仪表盘服务只支持单个Region，所以每个Region需要运行一个仪表盘服务。Region用于提供了在共享同一基础架构上建立健壮服务一种方式，该方式可用于在较高层次建立容错机制。
Availability Zones & Host Aggregates
Host Aggregates和Availability Zones是用于将nova部署进行分隔。Host Aggregates和Availability Zones虽然配置类似但是用途不同。Host Aggregates是用于逻辑上分组适用于负载均衡和分布虚拟机实例；Availability Zones是用于同其他Zone分隔的物理冗余和隔离分组(如：分隔电源或网络物理不同的服务器设备)。Host Aggregates可以视作对于Availability Zones中进一步分组的方式，如：可将服务器分成多个组，每组共享相似的资源如存储、网络；或区分特别的资源(可信赖计算硬件)。
Host Aggregates常用于将服务器分组提供nova-scheduler调度资源，如：将某种类型的虚拟机类型或镜像限制在给定子网中的某些服务器。
Availability zones可以将OpenStack中的计算服务或对象存储服务所用的服务器进行逻辑分组。通常是将一些具有相同属性的服务器分配到同一个zone中。如：数据中心中有部分机架的电源同其他机架的电源来自不同的供电线路，那么这些在独立供电机架上的服务器需要分配在同一个Availability zone中。
Availability zones也可以用于区分不同档次的硬件。特别是对于OpenStack对象存储服务比较有用，用于运行对象存储的服务器可能配置了不同的磁盘。当用户选择应用所需的配置时，就可以通过指定不同的zone上的虚拟主机实例或磁盘卷。用户通过自主选择就可以确定他们的应用运行是分布在不同的底层硬件服务器上，这样就可以在硬件故障时，实现应用的高可用性。
硬件扩展
在准备了部署和安装OpenStack相关的资源同时，另一项非常重要的任务是提前准备好扩展的硬件部署准备。本书建议是至少在现有运行的OpenStack云环境之外有空闲机架供使用，同时还需要准备何时，如何扩展硬件的方案。
硬件采购
“云系统”常备描述成灵活多变的环境，在云上运行的服务环境经常随意的开启和关闭。这种对云系统的描述无误，但不代表支持运行云系统的底层服务器是经常变动的。只有底层硬件的稳定和正确的配置才能确保其上云系统的正常稳定的运行。通常需要将主要的工作集中在建立一个稳定的基础硬件环境才能提供用户一个灵活多变的云系统环境。
OpenStack可部署于任何支持的Linux发行版所兼容的硬件环境上，如：本书所使用到的Ubuntu 21.04
服务器硬件环境不必完全一致，但是至少需要相同的CPU类型，以便于能支持实例在不同硬件环境上的迁移。
OpenStack建议的典型硬件就是商品硬件(commodity)。商品硬件就是指市场上大部分硬件供应商所提供的标准硬件配置。如果能直接采购，则可以直接按照需要建立类型的系统(如：计算，对象存储，云控制器)进行采购即可。另一种情况是预算不多，在现存的服务器上进行升级以满足性能和虚拟化要求，这样也可以支持部署OpenStack。
规划容量
OpenStack在于增加系统容量方面相对简单容易。请参考扩展性章节，其中特别需要注意的是对于云控制器容量考虑。建议在可能情况下考虑对于计算和对象存储节点留有额外的容量。增加的新节点不必要同现存节点保持相同配置，相同供应商。
在计算节点上，nova-scheduler将根据核数，内存信息进行系统资源的调配和管理。同时需要注意的是当使用不同CPU时，由于CPU计算速度的差异会导致用户体验的不一致。当添加对象存储节点时，不同节点需要给出权重用以反映出节点的性能。
监控资源的使用和用户的增长可以帮助你了解到何时需要考虑采购新资源。在监控章节中会提供详细有用的监控指标。
高负荷测试
服务器硬件在刚开始使用和快到使用寿命时最容易产生故障。所以为了避免在生产环境中忙于应付硬件故障，可以在初期适当采用高负荷测试方式来测试硬件故障。通常高负荷测试可以连续运行几天的CPU或磁盘性能基准测试软件，用以将硬件负荷增加至极限。
关于“OpenStack如何横向扩展配置”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
