这周在折腾openstack，下面是过程小记。

这周在折腾openstack，下面是过程小记。

参考：
http://docs.openstack.org/admin-guide-cloud/networking_introduction.html#load-balancer-as-a-service-lbaas-overview

最近开始折腾openstack，下面是过程小记。

参考：Appendix B. Firewalls and default ports

这周在折腾openstack，下面是过程小记。

这周在折腾openstack，下面是过程中问题小记。

Telemetry 提供一个监控和检测 OpenStack 云的框架。也就是大家所知道的 ceilometer 项目。

Telemetry 模块表现有如下功能:

Efficiently polls metering data related to OpenStack services.

Collects event and metering data by monitoring notifications sent from services.

Publishes collected data to various targets including data stores and message queues.

Creates alarms when collected data breaks defined rules.

Telemetry 模块通常包含下面组件:

• A compute agent (ceilometer-agent-compute)
  运行在每个计算节点中，推送资源的使用状态，也许在未来会有其他类型的代理，但是目前来说社区专注于创建计算节点代理。

• A central agent (ceilometer-agent-central)
  Runs on a central management server to poll for resource utilization statistics for resources not tied to instances or compute nodes. Multiple agents can be started to scale service horizontally.

• A notification agent (ceilometer-agent-notification)
  Runs on a central management server(s) and consumes messages from the message queue(s) to build event and metering data.

• A collector (ceilometer-collector)
  运行在一个或多个中心管理服务器，当警告发生是由于相关联的统计趋势超过阈值以上的滑动时间窗口，然后作出决定。

• An alarm evaluator (ceilometer-alarm-evaluator)
  运行在一个或多个中心管理服务器，允许警告为一组收集的实例基于评估阀值来设置。

• An alarm notifier (ceilometer-alarm-notifier)
  Runs on one or more central management servers to allow alarms to be set based on the threshold evaluation for a collection of samples.

• An API server (ceilometer-api)
  运行在一个或多个中心管理服务器，提供从数据存储的数据访问。

这些服务使用OpenStack消息总线来通信，只有收集者和API服务可以访问数据存储。

参考：Chapter 11. Add the Telemetry module

Orchestration module concepts

Orchestration模块提供了一个基于模板的orchestration，用于描述云的应用，通过运行的OpenStack API调用生成运行的云应用。软件和OpenStack其他核心组件集成为一个单一文件的模板系统。模板允许用户创建大多数的OpenStack资源类型，诸如实例，floating IP,卷，安全组，用户等，它也提供高级功能，诸如实例高可用，实例自动扩展，以及嵌套的OpenStack,这给OpenStack的核心项目带来了大量的用户基础。

服务鼓励部署者去直接集成Orchestration模块，或者通过自定义插件实现。

Orchestration模块通常包含下面的组件:

• heat command-line client
  一个命令行工具，和heat-api通信，以运行AWS CloudFormation API，最终开发者可以直接使用Orchestration REST API。

• heat-api component
  一个OpenStack本地 REST API ,发送API请求到heat-engine，通过远程过程调用(RPC)。

• heat-api-cfn component
  AWS 队列API，和AWS CloudFormation兼容，发送API请求到heatengine，通过远程过程调用。

• heat-engine
  启动模板和提供给API消费者回馈事件。

参考：Chapter 10. Add the Orchestration module

OpenStack对象存储是一个多租户的对象存储系统，它支持大规模扩展，可以以低成本来管理大型的非结构化数据，通过RESTful HTTP 应用程序接口。

它包含下列组件：

• Proxy servers (swift-proxy-server)
  接收OpenStack对象存储API和纯粹的HTTP请求以上传文件，更改元数据，以及创建容器。它可服务于在web浏览器下显示文件和容器列表。为了改进性能，代理服务可以使用可选的缓存，通常部署的是memcache。
• Account servers (swift-account-server)
  管理由对象存储定义的账户。
• Container servers (swift-container-server)
  管理容器或文件夹的映射，对象存储内部。
• Object servers (swift-object-server)
  在存储节点管理实际的对象，诸如文件。
• Various periodic processes
  为了驾驭大型数据存储的任务，复制服务需要在集群内确保一致性和可用性，其他定期进程有审计，更新和reaper。
• WSGI middleware
  掌控认证，使用OpenStack认证服务。

参考：Chapter 9. Add Object Storage

OpenStack块存储服务(cinder)为虚拟机添加持久的存储，块存储提供一个基础设施为了管理卷，以及和OpenStack计算服务交互，为实例提供卷。此服务也会激活管理卷的快照和卷
类型的功能。

块存储服务通常包含下列组件：

• cinder-api
  接收API请求，然后将之路由到cinder-volume这里执行。
• cinder-volume
  直接和块存储的服务交互，以及诸如 cinder-scheduler这样的流程交互，它和这些流程交互是通过消息队列。cinder-volume
  服务响应那些发送到块存储服务的读写请求以维护状态，它可以可多个存储供应商通过driver架构作交互。
• cinder-scheduler守护进程
  选择最佳的存储节点来创建卷，和它类似的组件是novascheduler。
• 消息队列
  在块存储的进程之间路由信息。

参考：Chapter 8. Add the Block Storage service

这周在折腾openstack，下面是过程小记。

参考：Chapter 7. Add the dashboard

dashboard 安装在控制节点。