云平台openstack浅析

openstack核心组件：

1. Computer：代码名Nova，管理VM整个生命周期，主要职责包括启动、调度VMs；
2. Networking：代码名Neutron，为openstack提供NCaas，网络连接及服务，插件化设计，支持众多流行的网络管理插件。
3. Object Storage：代码名swift，分布式存储，基于RESTful的API实现非结构化数据对象的存储及检索，磁盘映像文件即保存在此。
4. Block Storage：代码名Cinder，为VM提供持久的块存储功能，卷存储在此。
5. Identity：代码名keystone，为openstack中的其他所有服务提供了认证授权以及端点编录目录（即保存了所有API接口路由）。
6. Image：代码名Glance，为磁盘映像文件提供检索入口（Glance保存了所有磁盘映像文件的基本信息），Glance保存了磁盘映像文件源数据，当启动虚拟机时首先会从Glance检索镜像文件，Glance会告知去哪个swift存储中获取，从而快速的拿到对应的磁盘映像文件。
7. Dashboard：代码名Horizon，WEBGUI界面。
8. Telemetry：代码名ceilometer，用于监控和计量服务的实现。
9. Orachestration：代码名Heat，用于多组件联动。
10. Database service：代码名Trove，为openstack提供DBaas服务。
11. Data processing service：代码名Sahara，用于openstack中实现Hadoop的管理。

openstack概念架构



> 在上面的这些服务中，哪些是 OpenStack 的核心服务呢？ 核心服务就是如果没有它，OpenStack 就跑不起来。 很显然：
1.Nova 管理计算资源，是核心服务。
2.Neutron 管理网络资源，是核心服务。
3.Glance 为 VM 提供 OS 镜像，属于存储范畴，是核心服务。
4.Cinder 提供块存储，VM怎么也得需要数据盘吧，是核心服务。
5.Swift 提供对象存储，不是必须的，是可选服务。
6.Keystone 认证服务，没它 OpenStack 转不起来，是核心服务。
7.Ceilometer 监控服务，不是必须的，可选服务。
8.Horizon 大家都需要一个操作界面吧。

云：

新建虚拟机实例：

• 用户向layer层申请，layer层根据用户申请虚拟机规格，分别向cup、内存、存储、网络等资源池拿取对应大小资源创建虚拟机实例。

• 用户需要启动虚拟机就需要磁盘映象文件，所以我们存储资源池不应该仅仅只提供存储空间，还应该为我们提供启动虚拟机所需要的磁盘映象文件，有了磁盘映象文件，我们便可以直接启动我们申请创建成功的虚拟机，此时系统将会随机为我们分配一个节点进行启动。

• 当我们关闭虚拟机后，系统会自动将资源进行回收，当下次启动时再重新分配。
  
  提示：

• cpu和内存不能够灵活的在多个节点上进行调度，因此当我们选择哪个节点上的cpu就应该选择该节点上的内存（当然分布式系统例外）

• 当我们关闭虚拟机后下次重新启动时，有很大可能启动的节点和上一次的节点不同。

• 存储系统可跨节点使用，但如果存储系统设为共享存储或分布式，多节点同时访问则会给服务器造成巨大的压力，系统性能也会变差，同时用户在本地访问自己的文件都会带来巨大的网络延迟，这种延迟取决于网络IO，因此，存储系统通常也会存放在本地节点，所以一般磁盘映象文件存储在cpu和内存所在的节点本地磁盘上的某个位置。
  

问题1：

• 对于云来讲，一旦虚拟机关闭，所有资源将会被回收，下一次启动时，很大可能都不再原来的节点上了，此时我们就无法访问之前存储在磁盘上的文件以及数据了。

解决：

• 基于上述问题，最好不要基于磁盘映象文件实现存储功能，如果我们要实现持久存储功能，可以找一个专门的卷存储，实现持久存储。
  
• 使用卷存储，按照用户需求实现按需分配，我们第一次启动时，调度在1节点上，存储有他的磁盘映像文件和操作系统，但其数据全部存储在卷上划分出的一块存储空间，通过一定方式关联虚拟机实例，关联后所有数据将会存储在该存储空间，当下次启动在另一节点时，这种关联可以重新进行，此时卷上的这块空间将成为该虚拟机的私有磁盘。

问题2：

• 假设现在有300个用户同时启动虚拟机，每个虚拟机启动，都需要对磁盘映象文件复制一份，那么我们应该将该磁盘映象文件模板放在哪里？
• 假如磁盘映象文件是ubuntu系统，我们让所有节点都能够复制一份，并启动一个实例，如果我们将该磁盘映象文件放在共享存储，那么300次复制对磁盘来讲会是一个很大的压力，很有可能有的用户等了半天才拿到磁盘映象文件，从而启动虚拟机，如果并发更高这将是毁灭性的灾难。

解决：

• 使用分布式存储系统保存磁盘映象模板文件
• 使用分布式存储，可以利用n台主机提供的存储空间以及带宽
• 所以将一个映象文件拆分，分布在一组分布式存储系统上，此时同时启动上百个服务，复制上百次模板文件，对于带宽将不会成为瓶颈，同时对他的磁盘IO也不会造成瓶颈。

• 对于上述拿到磁盘映象模板文件的虚拟机实例来讲，接下来大多数则要去关联持久性存储空间，因为他是提供存储的，所以性能也不能太差，IO和网络IO将会是巨大的挑战，所以依旧需要采用分布式，同时避免了一个挂掉则所有数据全部消失的问题。

问题3：

• 当我们申请的虚拟机关闭后，系统将会自动回收资源，下一次启动时重新创建实例，但下一次重新创建肯定是依据之前的模板进行创建的，那么当我们下次创建时，系统如何知道我们之前虚拟机的详细配置信息？

解决：

• 采用数据库存储此前所有虚拟机实例的详细配置信息，如cpu几核、内存多大、磁盘空间、网络ip…
• 此数据库还应提供的服务：启动时的检索、删除虚拟机是的更新，扩容时的更新
• 依旧需要采用分布式
• 启动时需要采用异步任务队列，避免启动时一个一个启动。