博客

返回总目录

nova-api

1. 大部分内容和cinder-api相同 参考见08.存储Cinder→4.Cinder组件详解→1.cinder-api
2. OpenStack 用术语 “Instance” 来表示虚拟机，后面我们将统一使用这个术语。
   1. 只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。 大部分操作都可以在 Dashboard 上找到。打开Instance管理界面，点击下拉箭头，列表中就是 nova-api 可执行的操作
      1.     

nova-conductor

1. nova-compute 需要获取和更新数据库中 instance 的信息。但 nova-compute 并不会直接访问数据库，而是通过 nova-conductor 实现数据的访问。
2. 这样做有两个显著好处
   1. 更高的系统安全性
      1. 在 OpenStack 的早期版本中，nova-compute 可以直接访问数据库，但这样存在非常大的安全隐患。 因为 nova-compute 这个服务是部署在计算节点上的，为了能够访问控制节点上的数据库，就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息，比如
         

         1 2	[database] connection = mysql+pymysql://root:secret@controller/nova?charset=utf8

         secret表示密码，controller是控制节点的主机名。rooth和controller可以对比。现在配置nova时仅在控制节点的nova.conf中配置，不在计算节点的nova.conf中配置。

      2. 任意一个计算节点被黑客入侵，都会导致部署在控制节点上的数据库面临极大风险。为了解决这个问题，从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。 这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性。
   2. 更好的系统伸缩性
      1. nova-conductor 将 nova-compute 与数据库解耦之后还带来另一个好处：提高了 nova 的伸缩性。
      2. nova-compute 与 conductor 是通过消息中间件交互的。这种松散的架构允许配置多个 nova-conductor 实例。 在一个大规模的 OpenStack 部署环境里，管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问。