在云计算中，metadata 并不是一个陌生的概念。从字面上看，Metadata 是元数据的意思。而在云计算中，Metadata 服务能够向虚机注入一些额外的信息，这样虚机在创建之后可以有一些定制化的配置。在 OpenStack 中，Metadata 服务能够向虚机提供主机名，ssh 公钥，用户传入的一些定制数据等其他信息。这些数据被分为两类：metadata和user>
在 OpenStack 中，虚拟机获取 Metadata 信息的方式有两种：Config drive 和 metadata RESTful 服务。下面我们分别对这两种机制进行介绍与分析
Config drive
Config drive 机制是指 OpenStack 将 metadata 信息写入虚拟机的一个特殊的配置设备中，然后在虚拟机启动时，自动挂载并读取 metadata 信息，从而达到获取 metadata 的目的。在客户端操作系统中，存储 metadata 的设备需要是 ISO9660 或者 VFAT 文件系统。具体的实现会根据 Hypervisor 的不同和配置有所差异，以 libvirt 为例：OpenStack 会将 metadata 写入 libvirt 的虚拟磁盘文件中，并指示 libvirt 将其虚拟为 cdrom 设备，如图 1 和图 2 所示。另一方面，虚拟机在启动时，客户操作系统中的 cloud-init 会去挂载并读取该设备，然后根据所读取出的内容对虚拟机进行配置。
图 1.虚拟机定义的 xml 文件
图 2.存储 metadata 的虚拟磁盘文件
当然，要实现上述功能，需要宿主机和虚拟机镜像两者协同完成，它们需要各自满足一些条件：
宿主机（OpenStack 的计算节点）
虚拟机镜像
OpenStack 提供了命令行参数–config-drive 用于配置是否在创建虚拟机时使用 config drive 机制。比如：
清单 1
./my-user-data.txtmyinstance--file/etc/network/interfaces=/home/myuser/instance-interfaces或者也可以如清单 2 所示，在/etc/nova/nova.conf 中配置，使得 OpenStack 计算服务在创建虚拟机时默认使用 config drive 机制。
清单 2
force_config_drive=用户可以在虚拟机中查看写入的 metadata 信息，如果客户操作系统支持通过标签访问磁盘的话，可以使用如下命令查看：
清单 3
Metadata RESTful 服务
OpenStack 提供了 RESTful 接口，虚拟机可以通过 REST API 来获取 metadata 信息。提供该服务的组件为：nova-api-metadata。当然，要完成从虚拟机至网络节点的请求发送和相应，只有 nova-api-metadata 服务是不够的，此外共同完成这项任务的服务还有：Neutron-metadata-agent 和 Neutron-ns-metadata-proxy。下面我们将剖析它们是如何协同工作为虚拟机提供 metadata 服务的。
Nova-api-metadata
nova-api-metadata 启动了 RESTful 服务，负责处理虚拟机发送来的 REST API 请求。从请求的 HTTP 头部中取出相应的信息，获得虚拟机的 ID，继而从数据库中读取虚拟机的 metadata 信息，最后将结果返回。
Neutron-metadata-agent
Neutron-metadata-agent 运行在网络节点，负责将接收到的获取 metadata 的请求转发给 nova-api-metadata。Neutron-metadata-agent 会获取虚拟机和租户的 ID，添加到请求的 HTTP 头部中。nova-api-metadata 会根据这些信息获取 metadata。
Neutron-ns-metadata-proxy
Neutron-ns-metadata-proxy 也运行在网络节点。为了解决网络节点的网段和租户的虚拟网段重复的问题，OpenStack 引入了网络命名空间。Neutron 中的路由和 DHCP 服务器 都在各自独立的命名空间中。由于虚拟机获取 metadata 的请求都是以路由和 DHCP 服务器作为网络出口，所以需要通过 neutron-ns-metadata-proxy 联通不同的网络命名空间，将请求在网络命名空间之间转发。Neutron-ns-metadata-proxy 利用在 unix domain socket 之上的 HTTP 技术，实现了不同网络命名空间之间的 HTTP 请求转发。并在请求头中添加’X-Neutron-Router-ID’和’X-Neutron-Network-ID’信息，以便 Neutron-metadata-agent 来辨别发送请求的虚拟机，获取虚拟机的 ID。
图 3.Metadata 请求发送流程
如图 3 所示，虚拟机获取 metadata 的大致流程为：首先请求被发送至 neutron-ns-metadata-proxy，此时会在请求中添加 router-id 和 network-id，然后请求通过 unix domian socket 被转发给 neutron-metadata-agent，根据请求中的 router-id、network-id 和 IP，获取 port 信息，从而拿到 instance-id 和 tenant-id 加入请求中，最后请求被转发给 nova-api-metadata，其利用 instance-id 和 tenant-id 获取虚拟机的 metadata，返回相应。
上面我们分析了各个服务之间转发请求的流程，那么现在只存在一个问题，整个获取 metadata 的路线就通畅了：虚拟机如何将请求发送至 neutron-ns-metadata-proxy？
我们首先来分析虚拟机发送的请求。由于 metadata 最早是由亚马逊提出的，当时规定 metadata 服务的地址为 169.254.169.254:80，OpenStack 沿用了这一规定。所以虚拟机会向 169.254.169.254:80 发送 medtadata 请求。那么这一请求是如何从虚拟机中发送出来的呢？目前 Neutron 有两种方式来解决这个问题：通过 router 发送请求和通过 DHCP 发送请求。 通过 router 发送请求 如果虚拟机所在 subnet 连接在了 router 上，那么发向 169.254.169.254 的报文会被发至 router。如图 4 所示，Neutron 通过在 router 所在网络命名空间添加 ipTABLEs 规则，将该报文转发至 9697 端口，而 neutron-ns-metadata-proxy 监听着该端口，所以报文被 neutron-ns-metadata-proxy 获取，进入上述后续处理和转发流程。
图 4.router 所在网络命名空间的 iptables 规则
图 5.监听在 9697 端口上的 Neutron-ns-metadata-proxy 服务
通过 DHCP 发送请求
如果虚拟机所在 subnet 没有连接在任何 router 上，那么请求则无法通过 router 转发。此时 Neutron 通过 DHCP 服务器来转发 metadata 请求。DHCP 服务通过 DHCP 协议的选项 121 来为虚拟机设置静态路由。如图 6 所示，图中 10.0.0.3 为 DHCP 服务器的 IP 地址。通过查看虚拟机的静态路由表，我们可以发现发送至 169.254.169.254 的报文被发送到了 10.0.0.3，即 DHCP 服务器。
图 6.虚拟机中的静态路由表
另外再查看 DHCP 服务器的 IP 配置信息，发现 DHCP 服务器配置了两个 IP，其中一个就是 169.254.169.254。与 router 类似的，Neutron 在 DHCP 网络命名空间中启动了监听 80 端口的 neutron-ns-metadata-proxy 服务，从而进入处理和转发请求的流程。
图 7.DHCP 服务器的 IP 配置
Metadata 服务为用户自定义配置虚拟机提供了有效的解决方案。本文剖析了 OpenStack 提供 metadata 服务的两种机制：config drive 和 RESTful 服务。Config drive 机制主要用于配置虚拟机的网络信息，包括 IP、子网掩码、网关等。当虚拟机无法通过 DHCP 正确获取网络信息时，config drive 是获取 metadata 信息的必要方式。如果虚拟机能够自动正确配置网络，那么可以通过 RESTful 服务的方式获取 metadata 信息。
Unable to open stack trace file '/data/anr/traces.txt': Is a directory怎么解决？？？
没有权限 加入这个
数据结构课设编译程序提示是Cannot open include file: 'ClientStack.h': No such file or directory,
编译器没有找到Stack.h文件，有3个办法可以解决1. 将Stack.h文件和你的主文件放在同一个文件夹里2. 在 include 时指明 Stack.h 的相对路径。 比如你的Stack.h在上层目录的include文件夹下，那就写#include ../include/Stack.h3. 在编译选项里面加上 Stack.h 文件的路径 -I ../include另外，你的Stack.h文件少了一个define定义 。 正确的格式是：#ifndef _Stack_h#define _Stack_h......//这里是你的头文件实际代码...#endif这样写才能保证你的Stack.h不会被重复包含。
Ruby和Java有什么关系么?
在Ruby中，一切皆是对象。 下面举一个例子来更直观地说明Ruby语言的这一特点。 在Java中，求一个数的绝对值的代码如下。 int c = (-20);而在Ruby语言中，一切皆是对象，也就是说“-20”这个数也是一个对象，因此，求一个数绝对值的Ruby代码形式如下。 c = 这样的代码编写方式是不是更形象一些呢？Rails 框架是一个更符合实际需要而且更高效的Web开发框架，Rails结合了PHP体系的优点（快速开发）和Java体系的优点（程序规整）。 Rails是一个全栈式的MVC框架，换句话说，通过Rails可以实现MVC模式中的各个层次，并使它们无缝地协同运转起来。 在实际开发一个MVC模式的Web应用项目时，如果使用Java开发，需要用到Struts、Hibernate和Spring等框架，而且需要额外整合3个框架开发出的内容。 而使用Ruby语言开发相同的项目时，只需要用到Rails框架就可以完成。 RoR的效率肯定要比Java高一个数量级，这确实是事实，比PHP至少也要高好几倍，这也是事实，这一点在这篇文章中不展开了，但是为什么开发效率这么高，我也想谈谈我的看法，当然还很不成熟的看法：一、主要原因是ruby语言的语法非常强大我记得庄表伟说过一个观点：“框架是强化的语法”，意思就是说语法比较弱，所以才需要n多框架，如果语法很强，框架就很少。 这一点在Java和ruby身上得到了验证。 1、ruby的open class VS Java的AOP，反射、动态代理，字节码增强等技术JDK1.3开始引入反射，就已经打开了Java这种静态类型语言通往动态类型语法的潘多拉魔盒。 随后的动态代理技术，字节码增强技术，静态和动态的AOP技术开始层出不穷，为什么呢？就是需要在程序运行期动态改变对象的行为。 但是对于ruby来说是open class的，语法级别上就支持程序运行期修改对象行为，所以Java需要很复杂技术才能实现的功能对于ruby来说就是非常简单的搞定了。 2、ruby的duck typing VS Java的IoC，泛型Java的IoC不用说了，泛型在库级别也开始广泛使用。 IoC就是根据对象行为来进行对象组装，泛型就是在不确定对象行为的情况下确定对象的交互。 但是ruby的对象行为是在运行期才确定的，天然就是泛型的，行为不是静态的，所以不需要IoC。 3、ruby的block，closure VSJava的匿名内部类大家对spring的Template肯定印象很深刻，但是这是ruby标准的用法，所以各种资源释放，异常处理在语法级别上就支持的很好，做起来很简单。 4、ruby的Meta programming VSJava缺乏method_missing机制大家耳熟能详了，Java没有这么强的Meta programming，很多ruby magic耍不出来。 5、脚本语言 VS编译语言这也是一个很大的优势，脚本编程速度确实快。 二、rails框架确实做的很棒1、full-stackrails是一个概念一致的fullstack框架，不知道为什么，在Java世界目前只有Rife这一个可以和RoR相提并论的fullstack框架，但是Rife的实现并不好(作者从PHP转过来的，和DHH爆发过口水战)。 不过因为底层语法支持的不同，用Java是做不出来RoR框架的。 因此也有人用Groovy做Grails，不过这帮人不太争气。 2、CoC这个不用说了，现在很多Java框架开始吸收这一点。 3、为web开发良身打造web开发需要用到各种技术全部提供，绝对的贴心，如果用Java，这些东西都需要自己集成或者自己实现，省了一大堆麻烦事。 4、开发测试部署快速这个不说了，Java劣势太明显了关于“效率提高的来源”问题，我的理解就是次要复杂性被ROR降低到了极致。 说的难听一点，不是ROR太聪明，而是我们以前做得蠢事太多了。 各种各样的xml, taglib，单元测试困难 ... ...做过项目的人都知道这些次要复杂性很多情况下真的是要命的。 ROR没有降低软件的内在复杂性，也就是业务问题。 但是它把复杂性降低到无限趋近于业务复杂性，也有人称ROR是Web开发的DSL。 而解决业务问题正是人发挥聪明才智的地方，ROR不能代替人，但是它把人从次要复杂性的泥潭之中解救了出来。 参考资料：南京赛威信息科技
发表评论