首页 » 云计算 » OPENSTACK » OpenStack几个讨论题

OpenStack几个讨论题

 

1. 讨论:如何回馈 OpenStack 社区

张三:

  • 积极关注并回馈社区,贡献代码,争取成为 committer;

  • 积极将研发使用中遇到的问题及代码 ,回馈到社区;

  • 将 issue、idea、丰富的 feature 提交到 bluePrint,提交到社区;

  • 利用自己的一切资源致力于扩大中国 IT 力量在国际的影响力!(评:看到这句好欣慰!我想如果有更多这样的同学在,中国的 IT 前途很有希望);

李四:

  • 关注各种社区并加入到符合自己实际状况的社区中,认真学习前辈的经验,在实际中发现和探索问题,并在社区中讨论自己解决不了的问题,以及帮助他人解答问题;

王五:

  • 积极参加到社区的讨论中来,将一些发现的问题提交到 Issue;

  • 如果有新的 idea,更丰富的 Feature 想法,可以写成 BluePrint 提交到社区;

赵六:

  • 可以提交一些意见和建议(blueprint),自己在初学时遇到的一些问题(issue)

  • 继续学习,争取早日进入社区,能够发现问题思考问题反馈问题

王二麻子:

  • 能,现在水平有限,应该先从写文档和提交 issue、idea、blueprint 做起,同时打好编程基础,多做项目,多看书,多总结。

2. 讨论:OpenStack 管理的资源及提供的服务

OpenStack 管理哪些资源?提供哪些服务?这些服务在公有云上有没有对应的例子?(请尽量多举例)

OpenStack 管理的资源有:计算资源、存储资源、网络资源;

提供的服务有:

  • Nova 计算服务;

  • Cinder 块存储服务;

  • Neutron 网络服务;

  • Swift 高可用分布式对象存储服务;

  • GLance 镜像服务;

  • Keystone 身份验证服务;

  • Horizon 图形界面;

  • 扩展服务:Heat、Sahara

例子:

  1. 虚拟机 -- Nova -- 对应亚马逊上的 EC2

  2. 虚拟块存储 -- Cinder -- 对应亚马逊上的 EBS

  3. 虚拟网络 -- Neutron -- 对应亚马逊上的 VPC

  4. 对象存储 -- Swift -- 对应亚马逊上的 S3

  5. 权限认证 -- Keystone -- 在 AWS 的服务是看不见的,隐藏在叫作计费系统的后端(DOS 系统的后端)

  6. 镜像管理 -- Glance -- 对应亚马逊上的 VM Import/Export

  7. 控制面板 -- Horizon -- 对应亚马逊上的 Console

3. 讨论: OpenStack 之间的通信关系

OpenStack 之间有哪些通信关系?分别应用在什么地方?

OpenStack 组件之间的通信分为四类:

  1. 基于 HTTP 协议

  2. 基于 AMQP 协议(基于消息队列协议)

  3. 基于数据库连接(主要是 SQL 的通信)

  4. Native API(基于第三方的 API)

关于应用:

  • 基于 HTTP 协议进行通信。通过各项目的 API 建立的通信关系,基本上都属于这一类,这些 API 都是 RESTful Web API,最常见的就是通过 Horizon 或者说命令行接口对各组件进行操作的时候产生的这种通信,然后就是各组件通过 Keystone 对用户身份进行校验,进行验证的时候使用这种通信,还有比如说 Nova Compute 在获取镜像的时候和 Glance 之间,对 Glance API 的调用,还有比方说 Swift 数据的读写,也是通过这个 HTTP 协议的 RESTful Web API 来进行的。

  • 基于高级消息队列协议。基于 AMQP 协议进行的通信,主要是每个项目内部各个组件之间的通信,比方说 Nova 的 Nova Compute 和 Scheduler 之间,然后 Cinder 的 Scheduler 和 Cinder Volume 之间。

  • 基于 SQL 的通信。通过数据库连接实现通信,这些通信大多也属于各个项目内部,也不要求数据库和项目其它组件安装在同一个节点上,它也可以分开安装,还可以专门部署数据库服务器,把数据库服务放到上面,之间通过基于 SQL 的这些连接来进行通信。OpenStack 没有规定必须使用哪种数据库,虽然通常用的是 MySQL

  • 通过 Native API 实现通信。出现在 OpenStack 各组件和第三方的软硬件之间,比如说,Cinder 和存储后端之间的通信,Neutron 的 agent 或者说插件和网络设备之间的通信,这些通信都需要调用第三方的设备或第三方软件的 API。

4. 讨论:如何对 OpenStack 的组件做高可用部署或者负载均衡

请举例说明,如何对 OpenStack 的组件做高可用部署或者负载均衡?

高可用 HA(High Availability)指的是通过尽量缩短因日常维护操作(计划)和突发的系统崩溃(非计划)所导致的停机时间,以提高系统和应用的可用性。 负载均衡指集群中所有的节点都处于活动状态,它们分摊系统的工作负载。 分布式系统 OpenStack 要想做高可用部署或者负载均衡,需要遵循如下步骤:

  1. 针对不同的需求设计相应的方案,合理规划计算资源、网络资源、存储资源;

  2. 将服务、服务中的组件拆开部署,学习 swift 的跨地域部署,有利于提高服务可用性及 OpenStack 的负载均衡;

  3. 将同一服务部署在不同节点,形成双机热备和多机热备的高可用集群,最大化 SOA 架构的作用;

  4. 在复杂的数据中心环境中不断优化与第三方服务的对接和集成,最大化优化 OpenStack 从逻辑架构到物理架构的映射;

我的举例说明:

  • 规模较大的情况下,把各种管理服务部署到不同的服务器上。把这些服务拆开部署 到不同的节点上,甚至要把同 一个服务的不同组件也拆开部署,比如说可以把 Nova 的数据库给独立拧出来部署成一个 MySQL 数据库集群,还有 Cinder 里面的 Scheduler 和 Volume 可以部署到不同的节点上,实际上因为 Swift 项目具有一定的独立性,所以 Swift 本身就有跨地域部署的生产环境,规模非常之大,跨地域部署,所以它的服务的可用性极高,自然有这种栽培的特性,可以提供极高可用性和数据持久性的对象存储服务。

  • 出于高可用的考虑,生产环境中我们会把 OpenStack 的同一个服务部署到不同的节点上,形成双机热备或者多机热备的高可用集群。(或者用负载均衡集群)。

  • 在复杂的数据中心环境中,还有很多第三方服务,比方说 LDAP 服务、DNS 服务等等,考虑如何与第三方服务进行对接和集成。

5. 讨论:比较 Swift 和 Cinder 两种存储之间的异同

异:

Swift 比较独立,Swift 是做对象存储的,提供的是对象存储的接口,采用的是全对等架构。Cinder 是提供块存储的,提供的是块存储的接口,屏蔽了底层的硬件异构性。 关于数据流流向,Swift 对它的操作不仅仅是通过它的 Swift Proxy Server 提供的 RESTful API 进行操作的,它的数据也是通过 RESTful API 走的,我们要把数据放在Swift里面或者从Swift里把数据拿出来,都是通过 RESTful Web API。但是在 Cinder 不一样,Cinder API 基本上只能提供一些操作和管理功能,是直接通过 FC/iSCSI 传输数据到服务器,数据不会通过 Volume 去走,也不会通过 RESTful API。

同:

Swift 和 Cinder 都是软件定义存储,都属于资源管理层中的存储管理模块,都是 OpenStack 最主要的存储组件

6. 讨论:比较 Neutron 和 Nova-Network 的异同

相同点:

  1. 都可以实现网络管理功能;

  2. (租户之间)都可以实现基于 Vlan 的隔离;

不同点:

  1. Nova-Network 只能实现简单的网络管理,Neutron 则比较强大;

  2. Nova-Network 在以前网桥的基础上加模块实现 2 种工作模式:Flat DHCP 和基于 Vlan 的隔离的工作模式;而 Neutron 对上不仅可以提供 Vlan 的隔离,还可以实现 SDN,对下还支持第三方 API、Plugin 的扩展;

  3. Neutron 支持每个租户创建自己的虚拟网络,定义自己网络拓扑,租户间隔离即 Rich Topologies。

7. 讨论:Heat 中的模板和 Sahara 中的模板的异同

相同点:

都是通过模板来实现对资源的创建,销毁,生命周期的管理等等

不同点:

  • Heat 模板 Template 操作的对象是 Stack,并且只有一种方式进行调用,实现的是各个组件资源的整合和形成一个有机的整体

  • Sahara 由于存在两种使用模式:用户模式(edp 模式)和管理模式(iaas 模式),所以模板的使用主要集中在 iaas 模式上,分为两种:集群模板和节点组模板。实现的是对 Hadoop 集群的快速创建

8. 讨论:Ceilometer 获取计量数据的方式

获取计量数据的方式:

(1)需要原始数据的来源

  • 通过 MQP 消息中间件收集各个组件发出来的消息

  • 通过 Ceilometer 的一些 agent 调用 OpenStack 各个 component 的 api 获得数据

  • 如果要有效的采集和 Nova 相关的数据,通过在每个计算节点上运行 Ceilometer 的 polling agent 获得虚拟机的信息

(2)存在数据的存储:依赖第三方后端来实现,默认的后端数据库是 MongoDB。

(3)来自第三方系统:最主要的使用方式就是第三方系统,通过调用 Ceilometer API 获得计量数据,设置报警条件和预值,监听报警,进一步去实现计费和监控功能,具体使用的时候涉及到 Ceilometer 怎么设置,每项数据通过调用什么 API 获得,怎么设置报警的预值等等

9. 讨论:安装 Swift、Cinder 等其他服务的步骤

如果在目前已经完成的 OpenStack 演示环境部署的基础上,继续安装 Swift、Cinder 等其他服务,一般来说有哪些步骤?

Cinder

  1. 配置管理网络 nova-network;

  2. 安装、配置 NTP 服务(本机时间与网络时间同步,将本机作为服务器提供给其他主机使用);

  3. 下载安装 Cinder;

  4. 创建 cinder-volumns 并进行配置;

  5. 配置 keystone 验证、数据库访问(删除 sqlite 文件)及 RabbitMQ 消息中间件;

  6. 重启 volumn 服务。

或者描述为

  1. 安装 openstack 包

  2. 配置管理网络网卡

  3. 修改 hosts 为 block

  4. 重启

  5. 安装 NTP 安装LVM 包

  6. 创建 LVM 卷组 cinder-volumes

  7. lvm 扫描修改

  8. 安装配置块存储卷组件

  9. 验证安装

参考:http://www.aboutyun.com/thread-11681-1-1.html

Swift

  1. 创建 Swift 用户和组;

  2. 创建数据库并进行配置(删除 sqlite 配置文件);

  3. 创建镜像 glance 并配置 rsync.conf,配置完成后重启服务;

  4. 下载安装 swift;

  5. 对 swift 服务进行配置;

  6. 创建 Swift 并运行脚本。

10. 讨论:面对 Ceph 和 Swift 两种存储方案如何进行选型

(1)规模小,节点数量少的使用 Ceph,因为 Swift 至少要用到 5 个节点,划不来。

(2)需要提供云盘的服务的时候选择 Swift,做云盘就意味着要面对大量的用户,还希望用户的体验好,可以让用户来选择数据怎么存,这个时候选择 Swift 是更好的,一方面对于这种规模化部署的支持比较好,第二方面它有一些先进的 Feature,第三方面它的价格成本比 Ceph 要低一些

11. 讨论:OpenStack 和 Docker 如何结合

  1. 使用 Swift 做 Docker 镜像的存储后端

  2. 用 Nova 调度和管理 Docker 容器

  3. 使用 Heat 实现 Docker 容器

  4. 使用 Heat 实现 Docker 的 Orchestration

  5. 基于 Neutron 设计与实现适用于 Docker 的 SDN 方案

  6. 用 Glance 来管理 Docker 的镜像

 

原文链接:OpenStack几个讨论题,转载请注明来源!

0