Example architecture
example architecture 至少需要两个节点启动一个虚拟机或者实例。可选的服务，例如Block storage和Object storage需要额外的节点。example architecture和minimal production architecture的区别如下所示：
（1）、Networking agent存在于controller node中，而不是一个或多个独立的network nodes
（2）、对于self-service network的Overlay(tunnel)是走management network而不是dedicated network
Controller
Controller node运行identify service, image service, networking的管理部分，各种networking agents和dashbord。其中还可以包括很多supporting service，例如SQL 数据库，消息队列和NTP
事实上，controller node还可以运行block storage，object storage，orchestration和telemetry service。最后，controller node 需要至少两个网卡
Compute
compute node运行compute的hypervisor部分用于操作虚拟机实例。默认情况下，Compute使用KVM作为hypervisor。compute node还要运行networking service agent，它能将虚拟机连接到虚拟网络中，并且给虚拟机提供firewalling service。我们可以部署多个compute node，每个node需要至少两个网卡。
Block Storage
Block Storage node是可选的，其中包含了为虚拟机提供的Blocke storage和Shared File System service的磁盘。为了简单起见，compute node和本节点是使用management network进行通信的。在生产环境中需要提供专有的网络用于提高性能和安全性。我们可以部署多个block storage node，每个node至少需要一个网卡
Object Storage
Object Storage node是可选的，其中存放了Object Storage service的磁盘用于存放accounts，containers以及object。和Block node类似，为了简单起见，compute node和本节点直接是使用management network进行通信的。但是在生产环境中，需要实现专有的网络用于通信。该服务需要至少两个节点，每个node至少需要包含一个网卡。
Networking
Networking Option 1：Provider networks
Provider networks 用的是最简单的OpenStack Networking service部署方案，提供了基本的layer-2(birdging/switching)services和VLAN segmentation of networks。本质上，它将虚拟网络和物理网络相连，并且依赖物理网络的基础设施来提供layer-3(routing) services。另外，DHCP service为虚拟机提供IP信息
Networking Option 2：Self-service networks
self-service networks 在provider networks的基础上提供了layer-3(routing) service，主要是利用overlay segmentation methods，例如VXLAN实现的。事实上，它通过NAT将虚拟网络路由到物理网络。另外，这种network option提供了一些高级的服务，例如LBaas和FWaas。
Identity service
OpenStack的Identity service提供了对于管理认证，授权，以及service目录的单点集成。Identity service通常是用户解除的第一个service，一旦通过认证，端用户就能通过它们的identity去获取OpenStack service。同样，其他的OpenStack services利用Identity service来确认用户，以及发现其他service部署在什么地方。Identity service还能和其他的外部用户管理系统集成（例如LDAP）。
用户和service能够通过service目录获取其他目录的位置。如名字所示，service目录是OpenStack集群上可用的service的集合。每个service都可以有一个或多个endpoint，每个endpoint都是admin, internal或者public三个类型中的一种。在生产环境中，不同的endpoint类型会存在于不同的network中，因为处于安全的考虑，不同的类型是有不同的network的。比如，public API network在Internet上是可见的，从而用户能管理他们的云。而admin API network可能仅仅局限于那些云基础设施的管理者。internal API network则局限于那些运行着OpenStack service的主机。为了扩展性，OpenStack支持多region，但是出于简单起见，我们对于所有的类型都使用同一网络并且使用默认的RegionOne region。总之，Identity service中创建的region，service和endpoint构成了集群中的service目录。对于每一个OpenStack service，都需要在Identity service中存放一个伴有相应endpoint的service entry。这些都能在Identity service安装和配置好之后完成。
Identity service由以下组件组成：
Server：一个中心化的server提供使用RESTful接口的授权和认证
Drivers：drivers或者service back end是和中心化server集成的。它们是用于为OpenStack外部的库提供identity信息的，并且可能在OpenStack还在部署的时候就已经存在了。
Modules：OpenStack组件地址空间上运行的Middleware module也使用identity service。这些modules解析service request，抽取出user credentials，并且将它们发送给中心server用于授权。Middleware和OpenStack组件之间通过Python Web Server Gateway Interface进行通信。
Image service
Image service能够让用户发现，注册，检索虚拟机镜像。它提供了一个REST API，从而让你能查询虚拟机镜像的元数据以及检索实际的镜像。我们可以将虚拟机镜像存放在各种地方，从简单的文件系统到像OpenStack Object Storage的对象存储系统
为了简单起见，我们使用file back end来配置image service，即将镜像存放在运行image service的controller node的目录中。默认情况下，该目录为/var/lib/glance/images/。在进行操作之前，我们需要确保在controller node中的相应目录至少有几个G的存储空间。需要注意的是，file back end通常是在controller node的本地的，而这对于多节点的部署显然是不合适的。
OpenStack的image service位于IAAS的中心。它接收来自端用户或者OpenStack计算组件对于磁盘，服务镜像以及元数据定义的API请求。同时，它还支持磁盘存储，多种类型的服务镜像，包括OpenStack Object Storage。OpenStack image service上有一定数目的周期性运行的进程用于支持caching。Replication services用来确保集群的一致性和可用性。其他周期性运行的进程包括，auditors， updaters，reapers。
glance-api：接收镜像API调用，包括镜像发现，检索和存储
glance-registry：存储，处理和恢复镜像的元数据。元数据包括大小和类型。（注：registry是OpenStack image service的一个private internal service，不能将它暴露给用户）
Database：用于存储镜像的元数据，我们可以根据自己的偏好任意选择数据库。大多数部署使用MySQL或者SQLite
Storage repository for image files：OpenStack支持各种各样的repository type，包括普通的文件系统（或者任何挂载在glance-api所在的controller node上的文件系统），对象存储，RADOS块设备，VMware数据库以及HTTP。需要注意的是，一些repository只支持只读。
Metadata definition service：一个通用的API用于为vendor，admins，service，以及user定义它们自己的元数据。这些元数据可以被用于不同类型的资源，例如images，artifacts，volumes，flavors以及aggregates。一个标准的定义通常包括，新特性的键值，描述，约束以及相关的资源类型。
Compute service overview
使用OpenStack Compute管理云计算系统。OpenStack Compute是IAAS系统的主要部分。它的主要部分是由Python实现的。OpenStack Compute通过和OpenStack Identity交互来进行认证；和OpenStack image service交互用于磁盘和服务镜像；和OpenStack dashboard交互用于user和administrative的接口。镜像的访问受项目和用户的限制，配额则受到项目的限制（例如实例的数目）。OpenStack Compute可以在标准硬件上水平扩展，并且下载镜像来生成实例。
OpenStack Compute由以下这些组件构成：
nova-api service：用于接收以及回复端用户的compute API调用，该service支持OpenStack Compute API，Amazon EC2 API，以及special Admin API为特权用户执行管理员操作。它强行执行一些策略，以及初始化大多数的编排操作，例如运行一个实例。
nova-api-metadata service：接收来自实例的元数据请求。nova-api-metadata service通常在运行multi-host模式并且安装了nova-network的时候使用。
nova-compute service：一个worker daemon通过hypervisor API创建并且终止虚拟机实例。比如：XenAPI for XenServer/XCP，libvirt for KVM or QEMU，VMware for VMware。
处理的过程是非常复杂的。通常，daemon从队列中接收指令，再执行一系列的系统命令，例如启动一个KVM实例，以及更新它在数据库中的状态。
nova-scheduler service：从队列中获取一个虚拟机实例请求，并且决定在哪个compute server上运行。
nova-conductor module：nova-compute service和数据库的中介。它限制了nova-compute service对于云数据库的直接访问。nova-conductor module可以水平扩展。然而不要将它部署在运行nova-compute service运行的节点上。
nova-cert module：用于提供X509 certificate Nova Cert service的server daemon。用于为euca-bundle-image生成证书。只在EC2 API中使用。
nova-network worker daemon：和nova-compute service类似，从队列中接收并处理networking tasks。执行例如设置网桥接口或者改变IPtables 规则等任务。
nova-consoleauth daemon：验证console proxies提供的tokens。参见nova-novncproxy和nova-xvpvncproxy。如果要console proxies能正常工作，这个service必须运行。在集群配置了单个的nova-consoleauth就能运行两个proxy中的任意一个。
nova-novncproxy daemon：为通过VNC连接一个运行实例提供代理。支持基于浏览器的novnc客户端。
nova-spicehtml5proxy daemon：为通过SPICE连接一个运行实例提供代理。支持基于浏览器的HTML5客户端。
nova-xvpvncproxy daemon：为通过VNC连接一个运行实例提供代理。支持OpenStack的Java客户端。
nova-cert daemon：x509证书。
nova client：使用户能够作为租户管理员或者端用户提交请求
The queue：用于daemon之间传递数据的central hub。通常通过RabbitMQ实现，也能通过另外的例如AMQP消息队列实现，例如ZeroMQ。
SQL database：用于存储大多数云基础设施的build-time和run-time状态，包括：可用的实例类型，正在使用的实例，可用的网络，Project。
理论上来说，OpenStack Compute能支持任何SQL-Alchemy支持的数据库。通用的数据库为SQLite3，用于测试和开发工作，MySQL，MariaDB和PostgreSQL。