OpenStack Havana 的配置项成百上千，大部分配置项都是可以使用默认值的，否则光是理解这么多的配置项的含义就足以让运维人员崩溃，尤其是对那些并不熟悉源码的运维人员来说 更是如此。下文将列举若干网易私有云中较关键的配置项，并解释它们如何影响到服务的功能，安全性，以及性能等问题。

 

my_ip = 内网地址

此项是用来生成宿主机上的 nova metadata api 请求转发 iptables 规则，如果配置不当，会导致虚拟机内部无法通过 169.254.169.254 这个 IP 获取 ec2/OpenStack metadata 信息；生成的 iptable 规则形如：

-A nova-network-PREROUTING -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -j DNAT \ --to-destination ${my_ip}:8775

它另外的用途是虚拟机在 resize、cold migrate 等操作时，与目的端宿主机进行数据通信。该项的默认值为宿主机的外网 IP 地址，建议改为内网地址以避免潜在的安全风险。

metadata_listen = 内网地址

此项是 nova-api-metadata 服务监听的 IP 地址，可以从上面的 iptables 规则里面看出它与 my_ip 的配置项有一定的关联，保持一致是最明智的选择。

novncproxy_base_url = vncserver_proxyclient_address = ${private_ip_of_compute_host} vncserver_listen = ${private_ip_of_compute_host} novncproxy_host = ${private_ip_of_host}

 

我们仅在部分节点上部署 novncproxy 进程，并把这些进程加入到 HAProxy 服务中实现 novnc 代理进程的高可用，多个 HAProxy 进程使用 Keepalived 实施 HAProxy 的高可用，对外只需要暴露 Keepalived 管理的虚拟 IP 地址即可：

这种部署方式好处是：

1）实现 novnc 代理服务的高可用

2）不会暴露云平台相关节点的外网地址

3）易于 novnc 代理服务的扩容

但也有不足：

1）虚拟机都监听在其所在的计算节点的内网 IP 地址，一旦虚拟机与宿主机的网络隔离出现问题，会导致所有虚拟机的 VNC 地址接口暴露出去

2）在线迁移时会遇到问题，因为 VNC 监听的内网 IP 在目的端计算节点是不存在的，不过这个问题 nova 社区已经在解决了，相信很快就会合入 J 版本。

resume_guests_state_on_host_boot = true

在 nova-compute 进程启动时，启动应该处于运行状态的虚拟机，应该处于运行状态的意思是 nova 数据库中的虚拟机记录是运行状态，但在 Hypervisor 上该虚拟机没有运行，在计算节点重启时，该配置项具有很大的用处，它可以让节点上所有虚拟机都自动运行起来，节省运维人员手工处理的时间。

api_rate_limit = false

不限制 API 访问频率，打开之后 API 的并发访问数量会受到限制，可以根据云平台的访问量及 API 进程的数量和承受能力来判断是否需要打开，如果关闭该选项，则大并发情况下 API 请求处理时间会比较久。

osapi_max_limit = 5000

nova-api-os-compute api 的最大返回数据长度限制，如果设置过短，会导致部分响应数据被截断。

scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter, ImagePropertiesFilter, JsonFilter, EcuFilter, CoreFilter

nova-scheduler 可用的过滤器，Retry 是用来跳过已经尝试创建但是失败的计算节点，防止重调度死循环；AvailabilityZone 是过滤那些用户指定的 AZ 的，防止用户的虚拟机创建到未指定的 AZ 里面；Ram 是过滤掉内存不足的计算节点；Core 是过滤掉 VCPU 数量不足的计算节点；Ecu 是我们自己开发的过滤器，配合我们的 CPU QoS 功能开发的，用来过滤掉 ecu 数量不足的计算节点；ImageProperties 是过滤掉不符合镜像要求的计算节点，比如 QEMU 虚拟机所用的镜像不能在 LXC 计算节点上使用；Json 是匹配自定义的节点选择规则，比如不可以创建到某些 AZ，要与那些虚拟机创建到相同 AZ 等。其他还有一些过滤器可以根据需求进行选择。

running_deleted_instance_action = reap

nova-compute 定时任务发现在数据库中已经删除，但计算节点的 Hypervisor 中还存在的虚拟机（也即野虚拟机审计操作方式）后的处理动作，建议是选择 log 或者 reap。log 方式需要运维人员根据日志记录找到那些野虚拟机并手工执行后续的动作，这种方式比较保险，防止由于 nova 服务出现未知异常或者 bug 时导致用户虚拟机被清理掉等问题，而 reap 方式则可以节省运维人员的人工介入时间。

until_refresh = 5

用户配额与 instances 表中实际使用量的同步阈值，也即用户的配额被修改多少次后强制同步一次使用量到配额量记录

max_age = 86400

用户配额与实际使用量的同步时间间隔，也即距上次配额记录更新多少秒后，再次更新时会自动与实际使用量同步。

众所周知，开源的 nova 项目目前仍然有很多配额方面的 bug 没有解决，上面两个配置项可以在很大程度上解决用户配额使用情况与实际使用量不匹配的问题，但也会带来一定的数据库性能开销，需要根据实际部署情况进行合理设置。

 

vcpu_pin_set = 4-$

虚拟机 vCPU 的绑定范围，可以防止虚拟机争抢宿主机进程的 CPU 资源，建议值是预留前几个物理 CPU，把后面的所有 CPU 分配给虚拟机使用，可以配合 cgroup 或者内核启动参数来实现宿主机进程不占用虚拟机使用的那些 CPU 资源。

cpu_allocation_ratio = 4.0

物理 CPU 超售比例，默认是 16 倍，超线程也算作一个物理 CPU，需要根据具体负载和物理 CPU 能力进行综合判断后确定具体的配置。

ram_allocation_ratio = 1.0

内存分配超售比例，默认是 1.5 倍，生产环境不建议开启超售。

reserved_host_memory_mb = 4096

内存预留量，这部分内存不能被虚拟机使用

reserved_host_disk_mb = 10240

磁盘预留空间，这部分空间不能被虚拟机使用

service_down_time = 120

服务下线时间阈值，如果一个节点上的 nova 服务超过这个时间没有上报心跳到数据库，api 服务会认为该服务已经下线，如果配置过短或过长，都会导致误判。

rpc_response_timeout = 300

RPC 调用超时时间，由于 Python 的单进程不能真正的并发，所以 RPC 请求可能不能及时响应，尤其是目标节点在执行耗时较长的定时任务时，所以需要综合考虑超时时间和等待容忍时间。

multi_host = True

是否开启 nova-network 的多节点模式，如果需要多节点部署，则该项需要设置为 True。

 

配置项较少，主要是要权衡配置什么样的后端驱动，来存储 token，一般是 SQL 数据库，也可以是 memcache。sql 可以持久化存储，而 memcache 则速度更快，尤其是当用户要更新密码的时候，需要删除所有过期的 token，这种情况下 SQL 的速度与 memcache 相差很大很大。

包括两个部分，glance-api 和 glance-registry，：

workers = 2

glance-api 处理请求的子进程数量，如果配置成 0，则只有一个主进程，相应的配置成 2，则有一个主进程加 2 个子进程来并发处理请求。建议根据进程所在的物理节点计算能力和云平台请求量来综合确定。

api_limit_max = 1000

与 nova 中的配置 osapi_max_limit 意义相同

limit_param_default = 1000

一个响应中最大返回项数，可以在请求参数中指定，默认是 25，如果设置过短，可能导致响应数据被截断。