一、为何选择云计算/云计算之前遇到的问题
1.有效解决硬件单点故障问题
单点故障是指某个硬件的故障造成网站某个服务的中断。要真正解决这个问题，需要为每个硬件准备冗余，这不仅大大增加了硬件购置成本，而且部署与维护成本也不容小视。
而云计算平台是基于服务器集群，从设计之初就考虑了单点故障问题，并在建设时有效地解决了这个问题。如果一家云服务商出现单点故障问题，就如同存在银行的钱丢了。
2.按需增/减硬件资源
自己托管服务器，增/减硬件一直是头疼的问题。
1. 增加服务器的时候，购买服务器需要时间，而且这个时间自己无法控制。而使用云服务器，随时可以增加服务器——垂手可得。
2. 减服务器只能从机房拉回办公室，无法再把服务器退给厂商，购置服务器的成本就浪费了。而使用云服务器，如果下个月不用，不续费就行了（针对阿里云按月购买的情况）——想用就用，想扔就扔。
3. 不能按需增加满足基本需求的服务器配置。假如我们现在需要一台低配置的服务器用Linux跑缓存服务，如果为之单独购买一台便宜的低配置的服务器很不合算，因为这台服务器仅仅一年的电费就至少要3000元左右。所以只能尽量减少服务器数量，提高单台服务器的配置，在让一台服务器跑更多东西。而使用云服务器，需要什么样的配置就买什么样的配置，让各个服务器的职责更单一，互相之间的影响更小——职责分明，效率更高。
openstack新建云主机流程图:
虚拟机启动过程如下：
- 界面或命令行通过RESTful API向keystone获取认证信息。
- keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
- 界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
- nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
- keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
- 通过认证后nova-api和数据库通讯。
- 初始化新建虚拟机的数据库记录。
- nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
- nova-scheduler进程侦听消息队列，获取nova-api的请求。
- nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
- 对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
- nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
- nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
- nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
- nova-conductor从消息队队列中拿到nova-compute请求消息。
- nova-conductor根据消息查询虚拟机对应的信息。
- nova-conductor从数据库中获得虚拟机对应信息。
- nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
- nova-compute从对应的消息队列中获取虚拟机信息消息。
- nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
- glance-api向keystone认证token是否有效，并返回验证结果。
- token验证通过，nova-compute获得虚拟机镜像信息(URL)。
- nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
- neutron-server向keystone认证token是否有效，并返回验证结果。
- token验证通过，nova-compute获得虚拟机网络信息。
- nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
- cinder-api向keystone认证token是否有效，并返回验证结果。
- token验证通过，nova-compute获得虚拟机持久化存储信息。
- nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。
