《云计算与OpenStack：虚拟机Nova篇》这本书是一部非常具有实用性和深度的著作。作者在书中详细解析了OpenStack架构的设计理念和具体实现，并将其与云计算管理平台建设理论相结合，使读者能够全面了解OpenStack的工作原理和应用场景。通过本书的阅读，读者不仅能够掌握OpenStack的基本概念和操作技巧，还能够深入理解其背后的设计思想和发展趋势。本书的内容丰富全面，通俗易懂，适合各个层次的读者阅读。无论是想进一步了解云计算和OpenStack的专业人士，还是初学者，都能从中获得丰厚的知识收益。本书以其理论与实践相结合的方法，为读者提供了一本权威且实用的指导手册，是学习和研究云计算领域的一本不可多得的好书。
云计算与OpenStack：虚拟机Nova篇电子书封面
读者评价
一本openstack的入门书籍、可以简单了解openstack的基础架构和简单的workflow、openstack现在已经出到了icehouse版本、本书以F版和G版来介绍ops，在功能上还是相差好多
这本书不错，从原理上讲解了openstack，虽然版本有点老，但是基本原理讲到了
虽然openstack的版本还是H，现在都有了Icehouse版本了，但是相信原理还是大同小异的。值得学习！
最近在学习OpenStack，今天一拿到书就连看了两章，写得很好，不过有一些错误的地方。内容是针对F版本的，但是当前已经出到H版本了，不过总体感觉还不错。
内容介绍
本书通过深入剖析OpenStack架构的设计理念及具体实现，结合云计算管理平台建设理论，将理论与实践相结合，让读者知其然并知其所以然。
全书在组织形式上，采用简单明了的语法，段落简洁，配合大量的图文以及部分核心代码，形象地表述出技术应用原理。本文穿插了笔者团队积累的一些经验，特别是在应用篇，为不同场景下云计算落地提供了建设实践案例，这在业界是相对少见且比较全面的解决方案。
本书适合于IT首席技术官、云计算研发和运维等相关人员阅读。
目录
- PartⅠ 概念篇
- 第1章 云计算概述 2
- 第2章 OpenStack安装体验及入门 26
- PartⅡ 架构篇
- 第3章 系统架构 52
- 第4章 功能剖析 70
- Part Ⅲ 实现篇
- 第5章 计算资源池实现剖析 114
- 参考文献 154
- 第6章 存储资源池实现剖析 155
- 第7章 网络资源池实现剖析 173
- 第8章 Glance镜像管理 212
- 第9章 Horizon前端界面实现剖析 227
- 第10章 Keystone认证管理 238
- Part Ⅳ 应用篇
- 第11章 私有云平台建设 262
- 第12章 公有云平台建设 297
- 后记 309
基础概念 Openstack云中实例（instances）生命周期的所有活动都由组件Nova处理。这样使得Nova成为一个负责管理计算资源、网络、所需可扩展性的平台。其功能和特点在于： 1) 实例生命周期 2) 管理计算 3) REST（Representional StateTransfer表征状态转移软件架构风格，具有CS结构，连接协议无状态性等特点，适合云计算环境）风格的API 4) 异步的一致性通信 5) Hypervisor透明：支持Xen，XenServer/XCP，KVM，UML，VMware vSphere and Hyper-V Nova组件构成 Nova组件有以下六部分组成： 1) API服务器 API Server（Nova-api） 2) 计算工作者Compute Workers（Nova-compute） 3) 网络控制器Network Controller（Nova-network） 4) 卷工作者Volume Worker（Nova-volume） 5) 调度器Schedule（Nova-schedule） 6) 消息队列Message Queue（rabbitmq server）
安装与配置 多种部署方式与手动安装 配置文件 整体架构 依赖的下层模块 内部各部件的调用关系 整体模型 从细节入手 以命令行为切入点1 命令行参数的解析 配置文件的解析 如何调用其它组件 如何调用自定义组件 尝试自定义组件并集成
一个PRO环境中的Openstack集群，在倒下后1个月还没完全恢复，我也是醉了。如果不在这里，实在无法想象到外企的工作效率。 不过还好坑的只是部门内部的人，倒也没闹出什么大的幺蛾子。 一个月下来，有些感想，仅作记录吧。 1.永远不要低估一个线上操作的影响。 线上的每个操作，都应该在beta环境经过测试验证没有危害才能实行。有些操作可能看起来只会影响那么一点，但是总会有那些隐藏的side affect. 2.一个和PRO环境一致的beta环境。 beta环境的重要性是毋庸置疑的，用beta环境首先得明确beta的作用，它存在的意义应该是为PRO环境变化做实验。像我们不停的拆东墙补西墙，把beta环境拆的乱七八糟的来缓解 PRO环境的危机是不可取的，这样做只会让PRO环境越来越乱，beta环境越来越凋零。 所以一个好的beta环境应该是： a.架构和PRO基本一致，且不说一致到机器型号，整个集群的架构应该是一致的，比如多台CN，一台CC b.OS，软件版本必须一致 3.操作权限管理 对集群的操作权限管理是个很蛋疼的问题，既要不影响平时的开发运维，又要防止不可靠之人（比如我）的瞎眼操作。 对于配置的更改： puppet 自动化部署已经不是新鲜事了，但是总会有人偷懒自己去改配置而不是通过Puppet，所以总会有一些诡异的事发生。 对于需要admin权限的操作：我觉得对horizon的权限应该开放给基本可靠之人，运维工作人员也算是半个admin，如果和普通用户一样的权限，那活就没法干了，当然也可以不怕麻烦的设置个半admin状态的用户，可以自己去慢慢grant一些权限。 4.凝聚力 一个混日子的团队是不会有高的工作效率，作为一个scrum的团队，既然人不多，就应该要关注到每个人的情绪和状态。木桶效应随时会在teamwork中发生，一个积极性不高的人，可能会影响整个团队工作的进度，卡壳会经常发生，这样的话，频繁的迭代还怎么实现。 可能不是每个人都对别人的感觉很敏锐，so，这一点，只能看scrum master是否优秀了吧。 PS： 虽然集群恢复的很慢，但是这一个月来我的收获还是蛮大的。作为一个才来的时候linux一窍不通、搭个3节点都要一个月的人，前几个月都是干一些边角活，起码现在我能接触到组里最核心的东西了。 可是这一个月的代价未免也太大了。