供应商网络依赖的几个服务:
neutron-server.service
neutron-linuxbridge-agent.service
neutron-dhcp-agent.service
neutron-metadata-agent.service

自服务网络除了上边的几个服务外还依赖 neutron-l3-agent.service。
从这里也能看出,自服务网络支持三层模拟,这也是主要区别。自服务可以实现的功能就比较多,比如vxlan,FWaaS,LBaaS等。

先看看neutron-metadata-agent服务,这个服务主要功能是实例启动的时候为cloud-init获取metadata的时候转发用的。因为实例所在网络跟nova-api网络肯定不通的,所以需要一个中间转发,起这个作用的就是neutron-metadata-agent服务。看网上从实例到neutron-metadata-agent服务,中间还经过了haproxy,haproxy是l3-agent或者dhcp-agent启动的,这个也许也是分不同网络类型正好不同(但是我看官方安装文档,两种网络方式配置都是使用dhcp来启动的metadata服务, 默认是通过l3-agent启动)。然后由haproxy转发给neutron-metadata-aget,然后neutron-metadata-agent转发给nova-api-metadata服务。

服务启动命令为/usr/bin/neutron-metadata-agent --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/metadata_agent.ini
很多小模块过掉了,必须要看的时候再梳理吧。

主要是启动一个UnixDomainMetadataProxy。然后调用了agent_utils.UnixDomainWSGIServer启动,在文件neutron/agent/linux/utils.py 里,这个文件定义了好多不同类型的agnet。不得不说Openstack模块封装的太好了,接口封装的好,看起来就基本靠猜就可以了。看代码是启动了一个wsgi服务,handler为MetadataProxyHandler。然后调用_init_state_reporting,这个我看可以设置心跳,主要上报了监听的地址端口之类的信息,感觉也就监控或者排查问题有用。有个agent_rpc/context,也不知道往哪里上报的,先记住不看了。

MetadataProxyHandler里也有一个rpc(MetadataPluginAPI)/context,感觉这里不知道不行,靠猜也许行。
精简了就两行代码
instance_id, tenant_id = self._get_instance_and_tenant_id(req)
return self._proxy_request(instance_id, tenant_id, req)
第一行从header里获取请求的信息,得到实例id,我看还做了rpc调用,具体获取啥先不看了。
第二行是转发请求,把实例id和租户id,通过header传递,用requests模块发送请求给nova。返回内容无误后,返回给wsgi,请求就结束了。

好多细节没看,不过不影响流程,整个流程就是一个转发,涉及配置和验证,还有rpc没看。整体没啥复杂流程,就先这样了。

上一篇:
下一篇:

相关文章:

Categories: 博客记录

0 Responses so far.

Leave a Reply