OpenStackMetadataService分析-创新互联

1、为什么Metadata Service

OpenStack Metadata Service 提供 instance 的配置信息(这些信息被统称为 metadata)。instance 启动时向 Metadata Service 请求并获得自己的 metadata,instance 的 cloud-init根据 metadata 完成个性化配置工作。

成都创新互联服务项目包括凉州网站建设、凉州网站制作、凉州网页制作以及凉州网络营销策划等。多年来,我们专注于互联网行业,利用自身积累的技术优势、行业经验、深度合作伙伴关系等,向广大中小型企业、政府机构等提供互联网行业的解决方案,凉州网站推广取得了明显的社会效益与经济效益。目前,我们服务的客户以成都为中心已经辐射到凉州省份的部分城市,未来相信会继续扩大服务区域并继续获得客户的支持与信任!

2、Metadata Service架构

OpenStack Metadata Service分析

nova-api-metadata

nova-api-metadata是nova-api的子服务,它是metadata的实际提供者,虚拟机的启动时,可以选择通过nova-api-metadata的REST API来获取metadata信息
nova-api-metadata服务运行在控制节点上,服务端口8775(可以通过nova的配置修改)

OpenStack Metadata Service分析

开启metadata服务

nova-api-metadata与nova-api服务是合并在一起的,可以通过nova.conf的enabled_apis配置来指定是否启用nova-api-metadata

OpenStack Metadata Service分析

neutron-metadata-agent

nova-api-metadata走管理网络,虚拟机走业务网络,所以虚拟机无法直接和nova-api-metadata进行通信,在这个时候就需要借助到运行在网络节点上的neutron-metadata-agent服务。

在网络节点上运行两个组件 l3 agent和dhcp agent,他们会创建一个haproxy进程,运行在各自的namespace中,用来接收虚拟机发送的metadata请求,并将该请求通过Unix Domain Socket的方式转发给neutron-metadata-agent服务,再由neutron-metadata-agent转发给nova-api-metadata。

整个流程可以总结为:
a、instance将metadata请求发送给router或者dhcp agent创建的haproxy进程
b、haproxy进程通过Unix Domian Socket将请求发送给neutron-metadata-agent
c、neutron-metadata通过内部管理网络将请求发送给nova-api-metadata服务

3、L3 agent or DHCP agent

上述描述中提到,L3 agent和dhcp agent均可以创建haproxy进程,进而实现metadata请求的转发,那么两种方案该如何选择呢?

事实上,两者各有各的应用场景,甚至两种方案可以并存,下文将详细分析两者的区别。
说在前面,l3-agent 和 dhcp-agent 访问 metadata 的实现方法是不同的。

对于 169.254.169.254:
a、l3-agent 用 iptables 规则来转发。
b、dhcp-agent 则是将此 IP 配置到自己的 interface 上。

4、L3 agent实现分析

创建一个网络test1,启用dhcp,暂时不连接到router,然后启动一个instance,然后观察instance的启动日志:

OpenStack Metadata Service分析

从上面的启动log中,我们可以发现,intance从dhcp获取到ip地址之后,向169.254.169.254发送了request请求,但是20次均失败
那么169.254.169.254到底是什么?

事实上,这个ip地址就是metadata service的ip地址,instance在启动的时候会向它发送metadata的请求。

现在我们发现,instance请求是失败的,这个是为什么呢?

上文提到,OpenStack通过L3 agent或者dhcp agent创建haproxy进程,进而实现metadata的转发,我们首先检查下网络节点上的haproxy进程。

OpenStack Metadata Service分析

发现并没有haproxy进程运行,这个也就解释了,为什么instance会请求失败。但是到底是哪里出了问题?

根本原因是:默认情况下,haproxy进程由L3 agent来创建(dhcp agent则是关闭状态),由于当前test1网络并没有挂载router上,所以没有创建haproxy进程。

创建router,并将test1挂载router上之后。我们发现haproxy进程已经在网络节点启动。

OpenStack Metadata Service分析

重启instance test1,看会发生什么变化。

OpenStack Metadata Service分析

根据instance日志显示,虚拟机已经成功从169.254.169.254获取到了metadata。
这个过程中到底发生了什么?

a、instance在启动之后,会向168.254.169.254的80端口发起metadata请求,根据
instance的路由可以发现,该请求会从instance的eth0发出,送往路由器上的qr-设备。

OpenStack Metadata Service分析

b、metadata请求到达路由,进入PREROUTING链,将目的地址为169.254.169.254,进入qr-口,目的port是80的请求,重定向到9697。

OpenStack Metadata Service分析

c、为什么是9697?
因为router创建的haproxy进程正是监听在9697端口上

OpenStack Metadata Service分析

d、在后面就简单了:haproxy进程将请求通过Unix Domain Socket转发给neutron-metadata-agent,后者再通过管理网关转发给nova-api-metadata。

5、DHCP agent实现分析

OpenStack默认通过L3 agent管理metadata的实现,进而和nova-api-metadata通信,但是并不是所有的环境都有L3 agent,比如直接使用物理router的场景,这样场景如何实现metadata呢?

答案就是DHCP agent

a、打开dhcp agent的metadata功能
vim /etc/neutron/dhcp_agent.ini

OpenStack Metadata Service分析

重启dchp agent服务

b、检查网络节点上的haproxy进程情况,会发现开启dhcp功能的网络,会创建一个对应的haproxy进程,并将169.254.169.254配置在对应的dhcp port上。

OpenStack Metadata Service分析
OpenStack Metadata Service分析

c、重启instance,instance会向169.254.169.254的80端口发送metadata请求,根据instance内部路由,请求会到达dhcp_port端口上。

OpenStack Metadata Service分析

c、metadata请求到达dhcp的namespace,会被haproxy进程监听到(haproxy进程在dhcp namespace中监听80端口)

OpenStack Metadata Service分析

d、后面流程和L3 agent完全相同:haproxy进程将请求通过Unix Domain Socket转发给neutron-metadata-agent,后者再通过管理网关转发给nova-api-metadata。

6、Instance 怎么获得自己的 Metadata

要从 nova-api-metadata 获得 metadata,需要指定 instance 的 id
而instance在启动的时候,是无法知道自己的id的,所以http请求中不会包含id,
instance id是neutron-metadata-agent添加进去的。对于L3 agent和DHCP agent
两种方案上实现又略有不同,下文会针对两者进行说明。

获取metadata流程如下:
instance -> haproxy-> neutron-metadata-agent -> nova-api-metadata

L3 agent
a、haproxy进程接受到metadata请求,在转发给neutron-metadata-agent之前,会将ip和router id添加到http的head中。
b、neutron-metadata-agent接受到请求后,会查询instance的id,然后将instance id添加到http的head中,然后转发给nova-api-metadata。
c、nova-api-metadata响应请求到指定的instance。

DHCP agent
a、haproxy进程接受到metadata请求,在转发给neutron-metadata-agent之前,会将ip和network id添加到http的head中。
b、neutron-metadata-agent接受到请求后,会查询instance的id,然后将instance id添加到http的head中,然后转发给nova-api-metadata。
c、nova-api-metadata响应请求到指定的instance。

这样,不管 instance 将请求发给 l3-agent 还是 dhcp-agent,nova-api-metadata 最终都能获知 instance 的 id,进而返回正确的 metadata。

另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。


分享名称:OpenStackMetadataService分析-创新互联
网页URL:http://myzitong.com/article/dcsseh.html