Friday, April 12, 2013

OpenStack网络管理指南

主要介绍了OpenStack项目中Quantum的有关架构、操作和实现、管理等。

目前是v0.3版本见
https://github.com/yeasy/tech_writing/tree/master/OpenStack

Tuesday, April 09, 2013

OpenDaylight--源自业界的SDN控制器

2013年4月8日,OpenDaylight项目正式上线。

随着SDN产业的日益成熟,整个生产链逐渐划分为相对明确的几个部分,一是生产底层的SDN交换机;二是SDN的控制器;三是在控制器上的网络应用开发。

其中SDN的控制器在整个SDN网络的工作过程中起到了最为核心的作用,因此学术界和企业界先后纷纷设计了包括Nox、Onix、Floodlight等等一系列的控制器。这些控制器或是为了做学术研究,或是为了尝试部署生产环境,都为后人提供了丰富的设计经验。

然而,现在业界还普遍缺乏一个开源、有质量保证和开发保证的易用控制器和相应的SDN架构。
Linux基金会于是推出了OpenDaylight项目,历时半年的开发,终于发布了成功上线。

该项目最大的特色,就是其中开发和设计的多是业界的主流企业,在产品质量和方向把握上具有无可比拟的巨大优势;同时,又融合了之前几个主要控制器的特色(不少控制器的开发者都投入了OpenDaylight的开发),可谓集各家之长。最后,在接口设计上,OpenDaylight提供了最大的灵活性和松耦合,做到了最大的开放。

在OpenDaylight项目中,SDN的架构包括如下几层。



其中,网络服务层负责高层次的服务设计。控制器层提供网络服务的API,下面通过包括OpenFlow在内的协议层来管理最底层的交换机。这几层构成了一个完整的应用栈(栈的竞争将是未来网络产业竞争的核心点,正如传统互联网一样,业界提出的TCP/IP方案成了实际的标准,这次又会是谁呢?)。

OpenDaylight项目计划发布的产品包括开放的控制器、虚拟overlay网络方案、协议插件和交换机服务的增强,有机组合为一套完整的SDN解决方案。预计发布时间预计为2013年的3Q。目前参与者包括Arista Networks、Brocade、Cisco、Citrix、Ericsson、HP、IBM、Juniper Networks、NEC、Nuage Networks、PLUMgrid、Red Hat等。

OpenDaylight的最终目标是打造出业界标准的开放的SDN开发的平台,可以想象,到了那一天,网络的功能真正就像本地开发软件一样的简捷和高效。

Monday, April 08, 2013

云计算中的“存储”概念



存储(storage)是云计算提供服务中最为基本和核心的一种。
开源的云计算服务系统OpenStack中更是给出了多个存储有关的子项目。
目前根据服务目标和存储层面的不同,存储服务主要可分为三种:对象(Object)、块(Block)和文件(File)。

对象
简单的说,所有基于HTTP可访问的文件,包括图片、多媒体、网页、各类复杂文件等。对象不需要考虑是如何具体存储的,只需要通过给定的API去进行访问和管理。对象概念跟web中的对象概念很像,最为宽泛。
相关的项目包括OpenStack中的Swift、Amazon S3等。


这个就是最底层的存储设备的概念。存储设备需要用户自行进行挂载,并格式化后才能使用。一般情况下,存储设备只能被挂载在唯一的服务器上,没法在多机之间共享。
相关的项目包括OpenStack中的Cinder、Amazon EBS、iSCSI等。

文件
用户自行管理的文件。通过远程挂载,可以在给定权限下进行访问。
相关的项目包括NFS、Samba、Google Drive、Dropbox等等。

Wednesday, April 03, 2013

OpenStack 架构分析(Folsom)


OpenStack架构

v0.2: 2013-04-08
       添加服务架构说明
v0.1: 2013-04-02
       完成基于folsom版本的初始版本

1.1              组件

目前(folsom版本),OpenStack包括7个核心部件,包括前端面板、计算、对象、镜像、鉴权、网络和块存储。各部分功能为
l         前端面板 项目名称为Horizon,为所有的OpenStack服务提供web前端接口界面。利用web界面,可以进行大部分的云操作,包括运行实例、分配IP和设置访问控制等。
l         计算 项目名称为Nova,提供虚拟机服务。基于NovaHPRackspace都开发有商用的计算服务方案,同时在Mercado LibreNASA(发起人)等公司内部都有使用。
l         对象 项目名称为Swift 允许储存或获取文件(但不能像文件服务器一样挂载目录)。基于Swift,数家公司开发了商业的存储服务方案,包括KTRackspace(发起人)和InternapSwift同时在多家大型企业内部应用负责数据存储。
l         镜像 项目名称为Glance,提供登记和虚拟机镜像的管理,这些镜像主要是支持计算服务的。
l         鉴权 项目名称为Keystone,为OpenStack所有的服务提供认证和授权,同时提供了服务的登记管理。
l         网络 项目名称为Quantum,在网络接口设备之间提供连接服务。允许用户创建自由网络并挂载端口。架构开放,支持插件。从Folsom版本时引入。
l         块存储 项目名称为Cinder,为guest虚拟机提供永久性块设备,前身为nova-volume。所提供的块存储并非类似NFSCIFS share的文件系统。从Folsom版本时引入。
AmazonAWS相比,OpenStack大部分的工具和API等都有很好的兼容性。包括
l         Nova在概念上类似EC2。可以有多种方式来支持EC2API
l         Swift在概念上类似于S3.WSGI中间件上实现了部分S3 API
l         Glance提供了AmazonAMI登记服务类似的很多特性。
l         Cinder提供了类似于EBS的块设备。

1.2              架构

1.2.1      概念架构

OpenStack在整体设计上是“提供大量的可扩展的云服务的操作系统”,为了实现这点,各个组成的服务被设计一起协作提供“架构即服务(IaaS)”。这些协作通过服务提供的API之间进行操作实现。这些API允许服务之间的调用,并且相互之间松耦合。
概念架构如图表 1所示。
OpenStack Folsom Conceptual Architecture
图表 1 OpenStack概念架构
其中,Horizon提供用户的web前端;Nova存储和获取虚拟机,并且在Glance中维护元数据;QuantumNova提供虚拟网络;CinderNova提供块存储;GlanceSwift中保持实际的虚拟机硬盘文件;所有的服务都需要Keystone进行认证。

1.2.2      逻辑架构

逻辑架构比概念架构复杂的多。图表 2中给出了最常见的一些架构。
OpenStack Folsom Logical Architecture
图表 2 OpenStack逻辑架构
用户可以通过Horizon跟其他服务交互,或者通过其他服务提供的API
所有的服务都需要通过Keystone来进行认证。
部分服务通过公开的API跟其他服务进行交互。

1.2.3      服务架构


图表 3 服务和通信架构

1.3              Horizon-前端面板

Horizon是一个模块化的Django web应用,它为用户和管理员提供访问OpenStack服务的界面接口,如图表 2
OpenStack Horizon Screenshot
图表 4 Horizon提供用户接口界面
跟大部分的web应用类似,Horizon的架构比较简单:
l         Horizon一般通过Apache中的mod_wsgi进行部署。它的代码独立成为一个可重用的python模块,包括大部分的逻辑(跟不同的OpenStack API交互)和展示层(为不同站点提供容易的定制)。
l         一个数据库。因为大部分数据都是依赖自其它服务,自身存储的数据很少。
从网络架构的角度,Horizon服务需要是用户可访问的,同时能跟其他服务的公开API交互。如果同时需要一些管理功能(例如,管理其他服务),则Horizon需要能够访问到其他服务的管理API(这些API一般是用户不能直接访问的)。

1.4              Nova-计算

Nova是最复杂,同时也是最分散的一个组件。该组件包括大量的进程合作来把用户的API请求发给运行中的虚拟机。包括如下的进程:
l         Nova-api 接受和响应终端用户的计算API请求。支持OpenStack的计算APIAmazonEC2 API和一些特定的管理API(给超级用户提供管理操作)。并且发起大部分的协调(orchestration)操作,比如运行一个虚拟机实例。此外,还包括对策略的支持(主要是配额检查)。
l         Nova-compute 主要是个工作守护进程(worker daemon),通过hypervisorAPI(包括XenServer/XCPXenAPIKVMQEMUlibvirtVMWareVMWareAPI等)来创建和关闭虚拟机实例。进程要做的事情很复杂,但是工作过程却比较直观:不断从队列中获取请求并响应,执行一系列的系统命令(例如运行一个KVM实例),同时更新数据库的状态。
l         Nova-volume 负责管理为计算实例提供创建、挂载和卸载永久性存储(类似于AmazonElastic Block Storage)。该进程支持很多类型的存储,包括iSCSICeph中的Rados Block Device。新出现的Cinder项目将最终取代Nova-volume,在Folsom版本中,两者提供了类似的功能。
l         Nova-schedule 该进程在概念上是Nova中最简单的一个进程:从队列中获取创建虚拟机实例的请求,并且决定在哪里运行它(特别的,运行在哪一台物理机上)。
l         Queue 提供一个中央的hub,来在各个daemon之间传递消息。基于RabbitMQ实现,但同时支持任何兼容AMPQ消息的queue机制(包括Apache QpidZero MQ)。
l         SQL数据库 存储架构中大部分的创建和运行时状态。包括可用、在用、网络可用的实例类型和项目等。理论上,Nova可以支持被SQL_Alchemy支持的任意数据库,目前广泛应用的包括sqlite3(推荐仅用于测试和开发)、MySQLPostgreSQL
l         Nova还提供了一些控制台服务,让用户可以通过一个proxy来访问虚拟实例的控制台。包括若干daemonnova-consolenova-vncproxynova-consoleauth)。
NovaOpenStack大部分的其他服务都有交互。例如需要KeyStone提供认证、Glance提供镜像管理、Horizon提供web接口。与Glance的交互是核心。API进程可以上传和查询Glance,同时nova-compute可以通过Glance下载镜像以运行。

1.5              Swift-对象

Swift在架构上也是分布式的,以避免单点故障(single point of failure)和支持横向扩展,包括如下的子组件。
l         Swift-proxy-server 接受通过OpenStack对象API或原始HTTP的来访请求。接受包括文件上传、元信息修改和容器创建(container creation)。另外,为web浏览器提供文件或列出容器服务。该自组件通常采用可选的cache(一般部署memcache)来提高性能。
l         Account servers 管理被对象存储服务(object storage service)定义的账户。
l         Container servers 管理在对象储存服务(object store service)中容器(例如文件夹)的映射。
l         Object servers 管理存储节点上的实际对象(例如对象)。
此外,还有一些周期性的进程,负责大数据仓库中一些管理维护工作。其中最重要的是冗余服务(replication services),来确保cluster中数据的一致性和可用性。其他的周期性进程包括审计(auditors)、更新(updaters)和收获(reapers)。
对象仓促可以通过HTTP来提供静态的网页或对象。例如图像、多媒体等。
认证是通过可配置的WSGI中间件来负责的,即Keystone

1.6              Glance-镜像

Glance组件的架构从Cactus版本以来就一直很稳定。最大的改变包括添加了认证。Glance主要包括四个主要部分:
l         Glance-api 接受镜像API调用,包括发现镜像、获取镜像和存储镜像等。
l         Glance-registry 存储、处理和获取镜像的元数据(包括尺寸、类型等)。
l         数据库 存储镜像的元数据。数据库类型可选(i一般推荐MySQLSQlite)。
l         镜像文件的存储 一般镜像存储是在Swift中,但这是可以配置的。Glance支持文件系统、RADOS块设备、Amazon S3HTTP。但部分仅支持读操作。
类似SwiftGlance中也包括一些周期性进程来支持caching和冗余等。
Glance在整个OpenStack的概念架构上,起到了IaaS中的中心作用。它接受用户或Nova对镜像的请求API,并且存储磁盘文件到对象服务Swift中。

1.7              Keystone-鉴权

Keystone提供了一个对OpenStack中策略(policy)、登记(catalog)、口令(token)和认证(authentication)的支持。
l         处理API请求,包括提供可配置的登记、策略、口令和身份服务。
l         每个Keystone的功能,后面都是一个可插拔式(pluggable)的后端,从而可以采用多种不同的服务。大部分支持的标准后端包括LDAPSQLKey Value StoreKVS)。
Keystone一般常被用来提供认证服务。

1.8              Quantum-网络

Quantum试图在OpenStack其他服务(大部分情况下是Nova)管理的接口设备之间提供“网络连接即服务(network connectivity as a service)”。Quantum允许用户创建自由的网络,同时将接口连接上去。跟OpenStack中很多服务类似,Quantum的架构也是可配置的,支持插件(plug-in)。这些插件适应不同的网络设备和软件。因此,Quantum的架构和部署都是可以快速调整的。
l         Quantum-server 接受接受API请求,转发给合适的Quantum插件上。
l         Quantum插件和代理 执行实际的操作,包括插上、拔下端口、创建网络、划分子网和管理IP地址。这些插件和代理可以来自不同的提供商。Quantum自身支持或已配置的插件和代理包括Cisco虚拟和物理交换机,NiciraNVP产品,NEC OpenFlow产品、Open vSwitchLinux bridgingRyu网络控制器。Midokua提供了一个插件来帮助整合。常见的代理包括L3DHCP和其他指定的插件代理。
l         大部分情况下,Quantum采用一个消息队列来在Quantum-server和各种代理之间传递消息,同时采用数据库来为一些特定插件存储网络状态。
Quantum大部分交互都是跟Nova进行的,为虚拟机提供网络连通服务。

1.9              Cinder-块存储

Cindernova-volume服务单独剥离出来,提供永久性块存储服务。提供API来支持操作存储卷、存储类型和快照等。
l         Cinder-api 接受API请求,并转发给cinder-volume
l         Cinder-volume 通过读写Cinder数据库来响应请求,包括维护状态、跟其他进程打交道、提供软件和硬件等。通过驱动层,可以跟不同类型的存储设备交互,包括IBMSolidFireNetAppNexentaZadaraLinux iSCSI等。
l         Cinder-scheduler 选取最优的块设备节点来创建存储卷。
l         Cinder采用一个消息队列来在Cinder各个进程之间传递消息,同时采用数据库类存储存储卷状态。
Quantum类似,Cinder大部分交互都是跟Nova进行的,为虚拟实例提供存储服务。

1.10        未来版本中的部件

这些项目可能在今后版本的OpenStack中出现,包括
Ceilometer 提供一些测量(metering)信息,让提供接口展现OpenStack中的一些内部活动。该项目并非计费项目。要实现计费,需要测量、评估和计费。该项目让用户可以更好的了解哪些操作被执行了,评估则负责价格和条目、计费则计算费用,并发给用户。
Heat 提供REST API来协调多个实现标准的云应用,例如ASWCloudFormation

1.11        参考