OpenStack回顾随笔（第一章）

1. OpenStack历史

   OpenStack前身是NASA和Rackspace合作的项目，2010年开源，与其他主流开源云管理系统：Citrix的Cloudstack和桉树的OpenNebula相比，OpenStack在结构和接口设计上面更好。由于业界巨头的不断加入，OpenStack成为迭代最快的项目之一，每年发布两个版本，每年有多次社区的论坛，在论坛上面完成新功能定义，架构选择，发展方向讨论，lead的选举。上万名社区参与人员组成了整个项目的各个角色，Project Managers, Product Owners, Release Managers, Architectures, Developers, Testers, Writers, SCMs...... 

 

2. OpenStack Overview

 

ph1

OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.(作为一个云操作系统，OpenStack在数据中心中管理着大量的计算、存储、网络资源池，用户可以很方便地通过其Web UI 面板来管理基于openstack的数据中心。由于虚拟化和SDN技术的发展和成熟，使得软件定义的资源得以实现，人们可以更加智能、弹性、快捷地使用虚拟化了的硬件资源。与传统操作系统相比，目前的OpenStack更突出了其管理和运维的角色，在基础设施层面还是按需分配资源，备份资源，监控系统负荷、异常等等。随着市场需求的变化，OpenStack在系统服务、软件服务层上面引入了比如Trove这样的数据库服务，DNS服务等等，逐渐形成一个云端生态系统。不断更新和孵化的服务，使得应供开发者不需要过多关注存储、灾备、网络等common问题，而更加关注自身业务逻辑，也为应用迁入云端提供了方便。）

3. OpenStack子项目

由于良好的结构和接口设计，OpenStack子项目们提供的服务之间松耦合，服务可以热拔插。在架构设计方法上面，OpenStack从用户、技术、运维角度出发最终选出可用的架构，再进行论证。在接口设计上面遵循通用的REST API规范。常见分布式算法和灾备策略在各子项目中的应用非常广泛，值得关注和学习的有：分布式消息队列Rabbit Message Queue在OpenStack中的应用、比如DHT在SWIFT中的应用，数据的主从复制等。除此之外，在项目运作方面，如何管理一个上万人的社区，有效推动项目的发展，OpenStack也有一套有效的方法论，也值得大家认真研究。

3.1. OpenStack核心服务

核心服务的各个项目都拥有稳定的版本，也广泛地应用于各大公司生产和测试环境。

ph2

 

  3.2. OpenStack的其他可选服务

    其他13个可选服务子项目，从项目的年龄也直接反映了该项目的开发状态和产品的成熟度。

ph3

ph4

4. OpenStack架构和产品管理方法论

  刚开始看到"Methodology", 问自己这是扯淡吗？但看完整个章节后，确实不是。

 

  4.1 OpenStack如何确定产品架构

  

ph5

    一旦Use Case确定，架构师立足于这三个方面：User requirement，Technical consideration，Operational consideration讨论出架构，这个过程不断迭代，并且讨论出最合适的架构，再应用于产品。在架构阶段把运维和部署也考虑进来，也是自己之前经常忽略掉的。

  4.2 OpenStack如何做需求管理

    如何确定Use Case？

    4.2.1 整体业务目标

• 详细清晰地定义业务目标和需求
• 从业务、客户、最终用户出发增加项目的支持度和参与度

4.2.2 技术

      最求更高、更快、更强的测试是需求中非常重要的一部分。

• 从OpenStack整体项目出发，协调和整合OpenStack架构，更高效地利用社区资源。
• 尽可能多地发掘出自动化相关的需求来加速产品开发和部署，架构时也需要考虑如何实现高度自动化。
• 使用合适的工具完成开发工作。
• 做更好更多的测试度量方法和测试工具来支撑持续集成开发、测试流程和自动化。

4.2.3 组织

• 团队管理最求更高效的沟通。
• 在团队中构建更好的概念认知文化：OpenStack，云系统架构，敏捷开发，持续开发、集成、测试等所有开发过程中的概念的更好的认识。

4.2.4 需求管理本身

      开发有效的运作模型，使得他能够用于：管理需求、开发用例，跟踪项目轨迹。

    4.2.5 限制云的功能集

      需求需要抓住痛点，不能反复地造轮子，去突破一个系统的限制，限制才是需要突破的。

  4.3 OpenStack架构方法论

     这也是分布式系统架构设计常用的方法论：

• 悲观：时刻警惕任何东西和服务都有可能失效。
• 把鸡蛋放到不同的篮子里去：利用不同的服务提供者，在地理上面分区分域来避免全线停服，设计时考虑可移植性。
• 性价比：低效的系统常常是因为其无法扩展，高效的系统在扩展时所花费的精力往往非常廉价，设计时应该去除没有必要的组件。
• 偏执：深度考虑系统安全，在各个层级零容忍安全问题，系统交互过程中不能轻易相信对方。
• 不要太过于偏执：不是所有的软件系统都需要铂金级别的解决方案。对不同层级进行分层架构设计，不同层级配以不同的安全要求。
• 数据管理：对于云系统架构和集成架构来讲，数据是最不灵活的和复杂的，不要轻视数据在分析和索引寻址上面的需求。
• 自动化：利用自动化来讲强系统稳定性、质量、和减少系统响应时间。
• 分而治之：尽可能地对系统和业务进行分层、分区、分域，各个部分分而治之。设计尽可能单一功能的组件，在层级之间考虑负载均衡。
• 系统的弹性：在系统资源扩容时能直观地在性能和扩展上面得到成比例的增长，反之亦然。
• 动态性：支持对系统的动态配置，比如自动地调整规模，故障恢复，资源的发现与定位以适应生产环境中发生的各种问题。
• 缩小延迟：高交互性的组件和服务需要部署在离数据节点近的地方。
• 松耦合：坚持松耦合设计，使用良好的面向服务的API，对业务关注点的划分、抽象。
• 关注成本：系统自伸缩性，数据的传输，软件许可证，预留的资源等等都需要相当大的成本，必须紧密监控系统成本开销。