OpenStack的架构详解(4)

3.2 概念映射

将逻辑架构映射到概念架构中(如3-2所示)，可以看见我们还缺少什么。

3-2 逻辑架构到概念架构的映射

这种覆盖方式并不是唯一的，这里的只是作者的理解。通过覆盖OpenStack Compute 逻辑组件，Glance和Dashboard，来表示功能范围。对于每一个覆盖，都有相应的提供该功能的逻辑组件的名称。

a) 在这种覆盖范围中，最大的差距是logging和billing。此刻，OpenStack Compute没有能协调logging事件、记录日志以及创建/呈现bills的Billing组件。真正的焦点是logging和Billing的整合。这能通过以下方式来补救。比如代码扩充，商业产品或者服务或者自定义日志解析的整合。

b) Identity也是未来可能要补充的一点。

c) customer portal也是一个整合点。user dashboard(见运行的实例，启动新的实例)没有提供一个界面，来允许应用拥有者签署服务，跟踪它们的费用以及声明有问题的票据(lodge trouble tickets)。而且，这很可能对我们设想的服务提供商来说是合适的。

d) 理想的情况是，Admin API会复制我们能通过命令行接口做的所有功能。在带有Admin API work的Diablo 发布中会更好。

e) 云监控和操作将是服务提供商关注的重点。好操作方法的关键是好的工具。当前，OpenStack Compute 提供 nova-instancemonitor，它跟踪计算结点使用情况。未来我们还需要三方工具来监控。

f) Policy是极其重要的方面，但是会与供应商很相关。从quotas到QoS，到隐私控制都在其管辖内。当前图上有部分覆盖，但是这取决于供应商的复杂需求。为准确起见，OpenStack Compute 为实例，浮点IP地址以及元数据提供配额。

g) 当前，OpenStack Compute内的Scheduling对于大的安装来说是相当初步的。调度器是以插件的方式设计的，目前支持chance(随机主机分配)，simple(最少负载)和zone(在一个可用区域里的随机结点。)分布式的调度器和理解异构主机的调度器正在开发之中。

如你所见，OpenStack Compute为我们想象的服务提供商，提供了一个不错的基础，只要服务提供商愿意做一些整合。