两年前OpenStack基于NASA的Nova项目和Rackspace的Swift项目合并得以建立，而今OpenStack已经成为云计算领域的一颗新星，继2012年四月发布Essex版本之后，在今年九月底OpenStack第6版Folsom正式发布，本文简要分析了OpenStack Folsom的架构。
Folsom逻辑结构图
Object Store
Swift结构是分布式的，这样既可以防止任何单一的节点上出问题，又可以进行横向的扩展。它包含的组件有：
Prox server：它负责接受由OpenStack Object API传入的请requests或者直接就接受HTTP requests。接受的请求有文件上传，修改元数据和创建container单元。此外还为浏览器提供文件和continer的列表。通常我们会使用一个可选的缓存来提高它的性能。
Account servers：它们负责管理由object存储服务创建的账户。Container servers：它们负责管理object存储服务里面containers（也就是文件夹）映射。Object servers：它们负责管理storage节点上的真正的objects。（也就是文件）
在服务器上通常有许多用来执行日常任务的周期性进程。其中最重要的就是replication services，它通过集群保证了一致性和可以用性。其他的一些周期进程有：auditors,updaters和reapers。
Object store也通过HTTP为静态页面和对象服务。实时上，本文的那张图片就是来自Rackspace Cloud的Switf service。
Image Store
自从Cactus版本发布以后，Glance结构相对来说比较稳定。最大的结构变化大概就是在Diablo版本加入了身份验证。让我们快速浏览下Glacnce的四个主要部分：
glance-api：她接受Image API的发现图片，检索图片和存储图片的请求。glance-registry：她存储，处理和检索元图片元数据。（像大小，类型等）一个存储图片元数据的数据库。像Nova一样，你可以根据你的需求参数选择你的数据库。（但大部分人都选择MySQL或者SQlite）一个存贮实际图片文件的图片库。在上面的图片中，Swift被当作了图片库，而且这是可以配置的。除了Swift，Glance支持普通的文件系统，RADOS块设备，Amazon S3和HTTP。需要清楚的一点儿是这些选择中的一部分是有只读限制的。
就像你在上面的概念结构图部分看到的一样，Glance在所有IaaS图片服务中是个核心角色。她接受来自终端用户或者Nova组件的图片（或者图片元数据）的API requests，并且她可以把她的文件存在object storage service（Swift）中。
Identity
Keystone把OpenStack policy,catalog,token和authentication等功能集成于一身。不仅处理API requests，同时也提供可以配置的catalog，policy，token和identity服务。
每一个Keystone功能都有一个允许用不同方式使用它的独特服务的插件化后台。大部分功能都支持标准的后台，比如LDAP，SQL和Key Value Stores等。
Network
Quantum在其他OpenStack服务管理的接口设备之间提供网络连接服务。她首先允许用户创建他们自己的网络，然后给他们提供接口。和其他的OpenStack服务一样，Quantum使用了插件化结构，这使得他可以被详细配置。这些插件使用了不同的网络设备和软件。这样，结构和部署就非常的灵活了。在上面的结构中，使用了一个非常简单了Linux网络。
quantum-server：接受API requests然后把他们转发到合适的quantum插件去执行。quantum 插件和代理执行插件的添加或者卸载，创建网络或者子网和IP地址分配等实际操作。这些插件和代理在特定的云服务里面依赖不同公司和使用不同的技术。Quantum装载了的插件和代理有：Cisco的虚拟的和物理的交换机，Nicira的NVP产品，NECO的OpenFlow产品，Open vSwitch，Linux的bridging和Rye的网络操作系统。Midokua也为Quantum集成服务提供了一款插件。Quantum中普通的代理有L3，DHCP和定制的代理插件。大部分的Quantum设备都通过一个消息队列来转发在quantum-server和各种代理之间的信息，也有一个用来存储每个插件自己的网络状态的数据库。Quantum主要和Nova进行交互，Nova为他的实例提供网络和链接。
Block Storage
Cinder 将之前在OpenStack Compute中的部分持久性块存储功能分离了出来，集成到了自己的服务中。OpenStack块存储API允许对卷，卷的类型，卷的快照进行处理。
cinder-api 接受API requests并且将他们转发到cinder-volume去执行。cinder-volume处理cinder数据库的维护状态的读写请求，通过消息队列和直接在块存储设备或软件上与其他进程交互。和nova-scheduler非常相似，后台进程cinder-scheduler会选择在最优的块存储提供节点上去创建卷。Cinder deployments也使用消息队列去转发cinder进程之间的消息并且使用一个数据库来存储这些卷的状态信息。和Quantum类似，Cinder主要和Noa交互，为她提供她的卷需要的实例。