openstack之nova-api服务流程分析

本文详细分析了openstack-nova-api的服务流程,包括paste.deploy的配置解析、webob对WSGI的封装、routes的URL映射功能。通过理解这些组件,可以更好地掌握nova-api的工作原理。 paste.deploy负责加载wsgi app,webob简化HTTP请求处理,而routes则实现了内部URL到具体函数的映射。通过对这些库的了解,进一步分析了nova-api如何根据请求URL和方法分发到相应处理函数。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

       nova-api发布api服务没有用到一个些框架,基本都是从头写的。在不了解它时,以为它非常复杂,难以掌握。花了两三天的时间把它分析一遍后,发现它本身的结构比较简单,主要难点在于对它所使用的一些类库不了解,如paste.deploy/webob/routes。对于paste.deploy,结合它的官网文档把它的源码看了两遍。webob看的是源码。routes看的是文档。对于这些类库提供的函数,如果从文档中去理解他们想要做什么,真不是件容易的事。查看其实现源码,就明了了。不过在分析源码过程中,碰到每一个类库都去翻一遍它的源码,这也是非常累人的,后期甚至都不想再看下去了,因为脑子比较厌烦了。所以在学习routes时主要是看它的文档,基本理解了。


paste.deploy

用来解析/etc/nova/api-paste.ini文件,加载用于服务的wsgi app。它的功能有:

  •  api-paste.ini中配置多个wsgi app,deploy可根据传入的app name加载指定的wsgi app;

deploy.loadapp("config:/etc/nova/api-paste.ini", name="osapi-compute")
加载api-paste.ini中,名为osapi-compute的WSGI APP,并作为结果返回。

  • 通过写入api-paste.ini的配置,可方便地实现特定字符开始的url到特定wsgi app的映射。如:

[composite:osapi_compute]                                                       
use = call:nova.api.openstack.urlmap:urlmap_factory                             
/: oscomputeversions                                                 
/v2: openstack_compute_api_v2 

通过该配置,以“/v2”开始的url将交给名为openstack_compute_api_v2的WSGI APP处理,其它以“/”开的url就交给oscomputerversions处理。其实这并非deploy的功能,而是上面配置的urlmap实现的。不过通过配置文件,再由deploy调用urlmap,使用就更简单了。

  • middle ware的简单加载和去除。

[composite:openstack_compute_api_v2]                                            
use = call:nova.api.auth:pipeline_factory             
keystone = faultwrap sizelimit authtoken keystonecontext ratelimit osapi_compute_app_v2

上面的faultwrap sizelimit authtoken keystonecontext ratelimit都为middle ware(在nova代码中称为MiddleWare,deploy中称为filter),osapi_compute_app_v2才是wsgi app。请求先交给middle ware处理,再由middle ware决定要不要或者怎么交给wsgi app处理。这些middle ware是可以添加和去除的,如果不想对osapi_compute_app_v2进行限速,那么去掉ratelimit就可以了。其实这是pipeline_factory实现的功能,不过通过deploy来配置加载更方便。

      nova-api中提供了很多服务API:ec2(与EC2兼容的API),osapi_compute(openstack compute自己风格的API),osapi_volume(openstack volume服务API),metadata(metadata 服务API)等。通过配置文件api-paste.ini,可以方便管理这些API。

      deploy提供了server、filter、app的概念,其中filter(即middle ware)、app在nova-api被重度使用,的确太好用了。发布每个API时,它们有时需要一些相同的功能,如:keystone验证、限速、错误处理等功能。nova将这些功能实现为middle ware,如果需要,通过api-paste.ini配置,给它加上就可以。比如,我需要记录每个访问nova-api的ip,及它们的访问次数和访问的时间。那么我实现一个middle ware--nova.api.middleware:MonitorMiddleware来记录这些数据。通过下面的api-paste.ini配置,就可对nova-api的访问进行记录了。

[composite:openstack_compute_api_v2]                                            
use = call:nova.api.auth:pipeline_factory             
keystone = faultwrap sizelimit authtoken keystonecontext ratelimit <strong>monitor</strong> osapi_compute_app_v2

[filter:<strong>monitor</strong>]                                                                
paste.filter_factory = nova.api.middleware:MonitorMiddleware.factory

webob

用于对wsgi app进行封装,简化wsgi app的定义与编写。webob主要提供三种功能。

  • Request。该类用于对传给wsgi app的env参数进行封装,简化对HTTP请求参数的访问和设置。这种简化体现在(假设用env对Request实例化了一个对象req):

1) 使用间接明了的属性名对HTTP参数进行访问,req.method可获取HTTP请求方法(替代REQUEST_METHOD);req.scheme可获取HTTP请求协议http or https(替代wsgi.url_scheme);req.body获取请求body(替代wsgi.input)。

2)大量使用property,省去繁琐细节,简化HTTP参数的访问和设置。req.body直接访问HTTP请求的body,而不用考虑(body的长度和字符编码);req.

<think>好的,我现在需要帮助用户解决如何启动OpenStack Nova Compute服务的问题。首先,我需要整理用户提供的引用内容,看看里面有没有关键信息。 根据引用[4],计算节点无法启动服务可能是因为不知道控制节点的IP,所以需要将控制节点的IP添加到hosts文件中。这应该是第一步,检查/etc/hosts文件是否正确配置,确保计算节点能解析控制节点的主机名。 然后引用[2]提到,重启libvirtd.service和相关服务可能有效,但问题仍然存在。可能需要检查libvirtd的状态,确保它正常运行。另外,引用[3]中的用户通过启动libvirtd和nova-compute服务成功解决问题,所以正确的启动顺序可能很重要。 引用[5]提醒要备份配置和数据,并在测试环境中操作,避免生产环境出现问题。因此,在指导用户时,应该强调备份的重要性。 接下来,我需要按照步骤来组织答案。首先检查hosts文件,然后验证配置文件,接着检查依赖服务如libvirtd的状态,然后尝试启动服务,最后查看日志排查问题。同时,可能还需要考虑SELinux或防火墙的问题,以及软件包是否安装正确。 还要注意用户可能遇到的常见错误,比如配置文件中的权限问题、数据库连接失败或者消息队列无法访问。需要引导用户逐步排查这些可能性,并参考提供的引用中的解决方法,比如正确设置控制节点IP,确保服务启动顺序正确等。 最后,生成相关问题,帮助用户深入理解可能的相关问题,比如服务依赖、配置文件错误处理等。</think>### 如何启动OpenStack Nova Compute服务? #### 步骤1:检查基础配置 1. **确认hosts文件配置** 确保计算节点的`/etc/hosts`文件中包含控制节点和本机的IP与主机名映射。例如: ```bash 10.0.0.11 controller 10.0.0.31 compute1 ``` 如果未正确配置,计算节点可能无法识别控制节点,导致服务启动失败[^4]。 2. **验证Nova配置文件** 检查`/etc/nova/nova.conf`中以下关键参数是否正确: - `transport_url`:消息队列(如RabbitMQ)的连接地址 - `auth_strategy`:通常为`keystone` - `my_ip`:计算节点自身的IP地址 - `vnc_enabled`和`novncproxy_base_url`:确保VNC代理配置与控制节点一致 #### 步骤2:启动依赖服务 1. **重启libvirtd服务** ```bash systemctl restart libvirtd.service systemctl status libvirtd.service # 确认状态为active ``` libvirtd是虚拟化管理工具,若未启动会导致nova-compute服务依赖失败[^2]。 2. **检查Nova相关服务** 确保计算节点已安装所有必要软件包: ```bash yum install openstack-nova-compute ``` #### 步骤3:启动Nova Compute服务 ```bash systemctl start openstack-nova-compute.service systemctl enable openstack-nova-compute.service # 设置开机自启 systemctl status openstack-nova-compute.service # 检查是否启动成功 ``` #### 步骤4:排查常见问题 1. **查看日志定位错误** ```bash journalctl -u openstack-nova-compute.service -n 100 # 查看最近100条日志 ``` 常见错误原因: - 控制节点IP解析失败 - 数据库连接超时(检查`[database]`配置) - 权限问题(如SELinux未关闭或文件权限错误) 2. **防火墙与SELinux** - 关闭SELinux(临时):`setenforce 0` - 开放防火墙端口(如5672/RabbitMQ、8774/Nova API) 3. **验证服务注册** 在控制节点执行: ```bash openstack compute service list --service nova-compute ``` 若计算节点未显示,需检查服务注册流程。 #### 引用说明 - 配置hosts文件是解决计算节点服务启动失败的关键步骤[^4]。 - 启动顺序应优先确保libvirtd服务正常运行[^3]。 - 日志分析是定位服务启动问题的核心方法[^5]。
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值