在上面的模型中，假定了与云交互的四种人员（开发商、开发人员、操作员、用户），还定义了三层架构（表现、逻辑、资源）和两个正交领域（集成和管理）。
表现层，组件与用户交互，接受并显示用户的信息。在这一层，为非开发人员提供了一个web 图形界面，为开发人员提供了API。在这一层，还存在负载均衡、控制台代理、安全、命名服务。
逻辑层，为我们的云和控制功能提供情报。这层内包括部业务流程（工作流程复杂的任务），调度（确定作业对资源的映射），政策（配额等），镜像注册表（例如镜像的元数据），日志（事件和计量）。
集成功能，大多数服务提供商已经有一个客户的身份和计费系统。任何云架构将需要与这些系统集成。
管理层，提供一个API来管理云并提供监控功能。
资源层，因为这是一个计算云，我们需要实际的计算，网络和存储资源，以提供给客户。这一层提供这些服务，他们可能是服务器，网络交换机，网络附加存储或其他资源。

OpenStack Compute Logical Architecture

OpenStack 中有两个守护进程：
接收和调解API调用的WSGI应用程序 （nova-api，glance-api等等）。
进行编排任务的工人守护进程（nova-compute， nova-network,，nova-schedule）。
OpenStack中还包含两个组件：消息队列服务和数据库。这两个组件方便异步编排复杂的任务通过消息传递和信息共享。这个复杂的，但不是太翔实的图表可以概括为三句话：

 终端用户通过nova-api 接口与Openstack 计算交互。
 OpenStack计算守护进程通过队列的交换信息（行动）和数据库（信息）进行API请求。
 OpenStack Glance是一个完全独立的基础上设施。
各个组件的介绍：

nova-api：是对外的接口。OpenStack 云计算的核心控制器（CloudController定义在trunk/nova/api/ec2/cloud.py）。它提供了一个为所有的API查询（OpenStack API或EC2 API）的端点，引发多数业务流程的活动（如运行一个实例），并实施一些政策（主要是配额检查）。

nova-schedule：根据当前资源使用情况，决定计算节点分布到哪台计算节点上。目前实现很薄，目前已支持插件方式扩展，方便后面可能有采用更复杂算法。

nova-compute：接收队列中的动作，然后执行一系列的系统命令（如启动KVM实例），同时更新数据库中的状态。

nova-volume：给虚拟机分配额外持久化的存储，管理持久卷到计算实例的创建，连接和分离。

nova-network：网络管理，给虚拟机分配网络和管理，使外部 PC 可以可直接访问。它接受队列中的网络任务，然后执行任务操纵网络（如设立桥接接口或更改iptables规则）。

queue：提供了一个守护进程之间传递消息的*枢纽。当前由 RabbitMQ实现，理论上可以是Python的ampqlib支持的任何AMPQ消息队列。

SQL database：存储云基础设施的编译时和运行时的状态。这包括可用的实例类型，在使用中的实例，可用的网络和项目。

OpenStack Glance：OpenStack 单独的一个项目。

Nova Conceptual Mapping

OpenStack的架构示意图和目前已实现情况，蓝色是要 openstack概念上的架构图，红色是目前已实现的。

上面的功能模块对应上面模型的映射：

Service Architecture

管理和使用是走两个通道的。管理必须要经由 nova-api转发过去。而运行时，直接连接计算节点上的虚拟机即可。

部署

部署时，除了Dashboard 必须部署在 nova-api server 上以外，所有的其它进程都可以部署在不同的机器上。OpenStack提供了基于 Puppet 的自动部署工具。经过简单配置，就可以把各个组件部署到不同机器上。