疯哥哥带你飞

nova-cert顾名思义，是与证书有关的服务,用于为上传镜像生成X509证书，只在EC2 API中才会被用到。nova-cert作为rpc server运行，对外提供证书有关的RpcAPI，作用和CA类似。由于对PKI了解的不是太多，因此下面可能有错漏，还望斧正1.在服务开始运行之前，需要判断ca证书是否存在，不存在就需要使用openssl创建自己的ca证书和私钥，这些文件通

Keystone是OpenStack中负责管理身份验证、服务规则和服务令牌功能的模块。如果用户每次在访问服务的过程中，都需要提供用户名和密码，那么势必存在信息泄露的风险；token，即服务令牌，就可以解决这个问题。用户在访问OpenStack之前，首先需要使用用户名和密码获取一个token，接下来就可以使用此token访问任何资源。OpenStack目前支持4种令牌，分别是UUID令牌、PKI令牌...

nova-network是Nova组件中的网络服务，用于接收和处理网络相关的任务。在multi_host的情况下, 每个计算节点都需要运行nova-network服务，它也是作为rpc server来对外提供RpcAPI的。nova-network支持3种网络模型，flat/flatdhcp/vlan，与之对应有3种网络管理器FlatManager、FlatDHCPManager，

在上一篇中，讲解了一下flatdhcp网络下nova-network服务在启动之前的准备工作：创建网桥、启动DNSmasq服务、添加iptables和ebtables规则等。那这一篇，学习下创建虚拟机实例时，nova-network会进行的工作:创建虚拟机实例时，nova-compute会通过rpc调用相应的(multi_host下通常就是自己所在主机上的)nova-network的all

上一篇讲解了创建虚拟机实例时，nova-network所做的工作，那么这篇讲解下绑定浮动IP时的工作:在为实例绑定浮动IP时，nova-api会通过rpc调用对应主机nova-network的associate_floating_ip API

123

之前有学习过flat网络，发现作用很小，基本只能对虚拟机实例的一些网络信息进行管理。网桥需要自己建，网络规则需要自己配置，以至于浮动ip也不能自行创建分配。为了解决这些问题，引入了flatdhcp网络。顾名思义，它也是一个扁平网络，和flat类似，所有虚拟机实例处于同一个或多个虚拟网络中(注:其实我们可以创建多个虚拟网络，但是服务器的一个网卡通常只能用于创建一个虚拟网络，然后可以创建的虚拟网络

首先讲解vlan网络下nova-network服务启动之前的准备工作:通过调用VlanManager的init_host来进行初始化工作

这篇先学习下nova-compute每次启动时提供服务之前的准备工作nova-compute支持多种虚拟化驱动,包括LibvirtDriver、XenAPIDriver、FakeDriver、BareMetalDriver、VMwareESXDriver、VMwareVCDriver和HyperVDriver。从驱动名可以看出对应的虚拟化技术，一般在Linux服务器上，我们普遍会使用Qemu和

这一篇学习下nova-compute创建虚拟机的流程之前我们在nova-scheduler调度过程分析中提到过在调度完成后，由nova-scheduler通过调用目标主机nova-compute服务的run_instance RpcAPI来发起虚拟机实例的实际创建工作，那么就从run_instance这个RpcAPI开始进行分析

前面在nova-compute启动和创建虚拟机中都提到防火墙相关的代码，但是一笔带过了，这次做个详细学习使用Libvirt驱动时，默认的防火墙是nova.virt.libvirt.firewall.IptablesFirewallDriver，而这个防火墙也会使用到Libvirt内置的nwfilter防火墙，nwfilter防火墙允许我们使用XML格式字符串定义nwfilter，每个nwfil

Glance是OpenStack的镜像服务组件，对外提供虚拟机镜像的注册、上传、下载、编辑等管理服务。今天学习了下Glanceclient 1.2.0版本的代码，和其他组件的apiclient类似，基于requests这个http库访问对应服务的RestfulAPI。重点提下以下3个点:1.在新增一个镜像时，v1版本的api是需要同时提供镜像的元数据和文件数据的；v2版

Glance是OpenStack的镜像服务组件，对外提供虚拟机镜像的注册、上传、下载、编辑等管理服务。Glance由2个HTTP服务glance-api/glance-registry和一些命令行工具glance-manage、glance-replicator、glance-scrubber、glance-cache-prefetcher、glance-cache-cleaner等组

我们可以通过浏览器对虚拟机实例的控制台进行访问，为了安全，我们需要提供一个token，它的作用与keystone的token类似，但是它的验证并不是通过keystone完成的，而是由nova-consoleauth。nova-consoleauth是一个rpc server，对外提供RpcAPI，实现十分简单，并且接口也很少:authorize_console ->授权控制

nova-api-metadata是针对虚拟机实例的元数据服务以下针对Icehouse版本的nova-network网络模式进行说明nova-api-metadata作为wsgi server运行，对外提供RESTful API.需要运行在每个计算节点上，为该节点上的实例提供元数据服务。我们可以为实例创建元数据, 在实例的来宾系统中，我们通过nova-api-metadata的REST

在上一篇“nova-scheduler调度过程分析”中，对过滤称重的过程一笔带过了，这篇着重介绍一下。首先，我们声明一下host为主机，node为节点，在OpenStack中一个host可以运行多个node或者nova-compute服务。第一步，过滤filter，通过HostManager的get_filtered_hosts实现：# nova-scheduler默认

nova-conductor是nova各服务与数据库的中间件，nova各服务对数据库的CRUD操作都借由nova-conductor完成，nova-conductor通过rpc对外提供API服务。为什么要采用这种方式，而不是由服务直接访问数据库呢？原因之一，安全；之二，？nova-conductor默认采用多进程运行，在不配置[conductor]worker的情况下，进程数会与服务器的逻

123

Nova是OpenStack的为计算资源提供大规模、可扩展、按需、自助服务访问的组件。根据在系统中的地位，部署了Nova服务的节点可分为控制节点和计算节点，通常情况下，一个控制节点管理多个计算节点。以下部署方法只针对Ubuntu 14.04上的Icehouse版本一、安装控制节点1.安装所需包apt-get install nova-api nova-cert

Nova是OpenStack的为计算资源提供大规模、可扩展、按需、自助服务访问的组件。根据在系统中的地位，部署了Nova服务的节点可分为控制节点和计算节点，通常情况下，一个控制节点管理多个计算节点。以下针对Icehouse版本一般情况下，控制节点上运行以下Nova服务:nova-api 用于对外提供RESTful API服务nova-scheduler

给定一个account(例如AUTH_d5ee5d146d014b7daab1a50ea98487aa)后，首先通过md5哈希，计算出分区，再根据account.ring.gz中的replica2part2dev映射表找出该account应该存放的device列表，然后就由proxy服务向devices对应的account服务发送请求account相关的信息在存储节点上通过路径进行限定，通过将

Swift作为分布式对象存储，为了解决分布式带来的一系列热点问题，引入了一致性哈希算法。Ring，顾名思义就是环形空间，用于记录存储对象到物理设备之间的映射关系。Swift通过'Account/Container/Object'来标识一个存储对象，针对Account、Container和Object各有一个Ring，这些Ring默认是存放在各个节点的/etc/swift下，分别是account

Swift采用层次数据模型，共3层逻辑结构：Account/Container/ObjectAccount等同于租户，可以拥有多个Container；Container是object的父容器，可理解为目录或者文件夹，当然Container不支持嵌套；Object就是实际存储的对象和元数据Swift的节点分为storage节点和proxy节点proxy节点用于对外提供Restfu

Swift是OpenStack的对象存储组件，用于提供弹性可伸缩、高可用的分布式对象存储服务，适合存储大规模非结构化数据。我们现在经常用的一些云盘，就是Swift的一个典型应用场景。今天抽时间学习了一下Swift的部署方法，Swift的典型架构就是一个(或多个)Proxy节点管理多个存储节点。以下是在Ubuntu12.04或14.04上Icehouse版本的部署方法

最近在做一个分布式的任务系统，借鉴了OpenStack的思想，使用rabbitmq来做消息中间件，便于扩展。本着不重复造乱子的理念，哈哈，我也用oslo.messaging将worker做成RpcServer来提供服务。在本地写好简单的Demo后，测试了一下运行无误。上传到部署了OpenStack的服务器后，使用rpcapi发布任务，结果core dump了，悲催，使用gdb查看core fi