大数据、小程序、云计算、复活节兔子

By , 2013年1月27日 8:49 下午

最近,我看了一份关于各个公司使用公有云服务进行大数据分析所产生的费用方面的分析报告。尽管费用方面的数据很有意思,不过我更感兴趣的是这份报告关于在大数据分析当中如何使用云计算资源方面的描述。譬如说,从这份报告第11页的内容看来,在用于大数据分析的虚拟机实例当中,89%的实例属于小型虚拟机实例。换句话说,用来进行大数据分析的程序,其代码规模是相对较小的。

毫无疑问,管理大规模数据是一件很困难的事情。当数据的规模越来越大时,实时性、完整性、私密性就越来越难以实现。别的不说,光是确认什么时候可以安全地删除一份数据就够让人头疼的。

但是,如果说大数据就是“那个答案”的话,我们需要一些小程序来提出那个问题。

由此我们引出大数据和基础设施服务(IaaS)之间的关系。我们已经积累了一些在Eucalyptus上进行大数据分析(例如Hadoop和Cassandra等等)的用户,也经常有人问我们这些用户为什么要这样做。这些技术在裸机上运行起来性能很好,在公有云环境中让它们运行在虚拟机之上通常是因为没有别的选择。那么,在一个企业自有的基础设施中,为什么系统管理员或者数据分析者会选择使用在Eucalyptus(或者其他云管理平台)之上进行大数据分析呢?

在这里我试图用小量程序来回答这个问题(也许可以总结为“小程序”)。几年前,我和一位同事在UCSB共同开设了一门关于隐写术(Steganography)课程 - 简单地说,就是怎样将一条信息藏在另外一条信息中。

很多大数据分析应用 - 例如Web分析 - 看起来与隐写术具有相同的特征。这个特征就是通过一些“解密算法”(通常是统计性质的)在大量数据中寻找隐藏的“信息”。

换句话说,大数据分析就像是用机械化工具寻找复活节彩蛋。

更重要的是,尽管数据的规模很大,并且经常随着时间发生变化,但是用来进行数据分析的程序规模相对较小,并且几乎没有什么变化。

前段时间,Netflix公司的Adrian Cockcroft (@adrianco) 到我们Eucalyptus公司来参观,并且做了一场关于NetflixOSS的讲座。Netflix所拥有的内容显然能够被纳入大数据的范畴,不过Andrian花了75分钟当中的一大半来给我们讲他们的程序。

通常来说,需要应用到大数据分析的问题,有点类似于海底捞针。作为一个缩微版的例子,我请我们公司的首席执行官Marten Mickos (@martenmickos)给我们透露一点他不愿公开披露的秘诀,然后我通过隐写术将他的秘诀隐藏在下面这张图片中。

Marten PNG

Marten在多个领域都享有卓越的声望,很多人将他的教诲奉为至宝。在这里我请他送给我们一个复活节彩蛋。

用来破译Marten这个复活节彩蛋的相关图片、程序、以及编译脚本可以从这里下载。在Linux或者OS X操作系统上,可以用下面这些命令来破译Marten的密码:

 tar -xzf sw.tgz ; make all ; ./extract-message

这时候当前目录下会多出一个名为martens-message.png的图片文件。打开这个图片文件,就可以看到解密后的信息。

你试过了吗?当然没有。

如果你读到这里的话,我打赌你根本就没有打算去运行上面列出的几个命令。这可能是因为你实在太忙了。并且,即使是你有很强的好奇心,你也可能是在使用一台不具备计算能力的设备(智能手机或者平板电脑)或者是在Windows操作系统上看这篇文章。我已经在Linux和OS X上测试过这段程序,遗憾的是我没有本事将它移植到Windows或者是其他平台上(从这些代码可以看出,我的编程技巧实在是比较古老)。

理由一:可移植性 — 这是在基础设施服务上进行大数据分析的第一个重要理由。通常来说,大数据技术的侧重点在于大数据,而不是程序的可移植性。实现代码的平台无关性本来就比较困难,要保证不同平台上的性能(性能是大数据分析中的一个关键性要求)就更加困难了。

基础设施服务使得运行一个应用所必需的运行环境成为这个应用自身的一部分。

通常来说,应用程序的复杂度越高,其功能与性能和运行环境之间的相关度也越高。基础设施服务保证了应用程序能够运行在为其量身定做的运行环境上。

你试过了吗?当然试过。

如果你是一个比较强悍的工程师,你可能已经在Linux或者OS X上试过上面这些命令了。你成功地找到复活节彩蛋了吗?在OS X上,你需要安装Xcode才能够使用gccmake来编译这个程序。尽管这两个工具在Linux上的非常重要,但是有一些Linux发行版并没有缺省地安装它们。因此,就算是你在Linux上尝试运行上面这些命令,你也有可能没有成功。也就是说

理由二:依赖关系 - 部署大数据分析应用通常涉及到一大堆软件依赖关系。在这个例子中,我们的程序既依赖于编译环境,也依赖于运行环境(下面我们会详细解释)。基础设施服务使得用户可以通过编程管理和保障程序所具有的依赖关系。

在我们的程序中调用了一个名为libpng的开源的软件库。这个软件库是用来对PNG文件进行操作的,当前的版本是1.5.x。我敢说,libpng是一个管理得很好的开源项目,它的1.5.x版本向下兼容1.4.x版本,由此可见libpng有一个充满活力的用户社区。

不过,我这段隐写术程序是在2006年写的,当时用到的libpng的版本是1.2.50。我不知道当前最新版本的libpng是否与其兼容,或者更早版本的libpng是否与其兼容。Ubuntu 10.04 (Lucid) 里面自带的libpng12-dev似乎能够编译和运行我的程序。但是我手头有一份2006年保存下来的libpng,它和我的程序配合得很好。因此我不打算深究是否可以升级(或者如何升级)我的程序以便更好地利用这一依赖关系,或者最新版本的libpng的向后兼容性是否好到可以完美支持我的古老程序。升级七年以前写的古老程序而没有增加任何新的功能,这可不是我愿意去干的事情。由于我的懒惰,可以得出

理由三: 遗留应用 - 当程序的年龄与日俱增时,基础设施服务所带来的好处也逐渐凸现。尽管数据随时都在发生变化,但是程序的生命周期通常远大于数据的生命周期(少数特殊场景除外)。在大数据应用场景中,基础设施服务使得用户能够将数据的生命周期与程序的生命周期快速匹配起来。

必需指出,libpng是一个维护得非常好的项目。在它们的下载页面还提供了存档的1.2.50版本,也就是我七年前使用的那个版本。如果你决心要完成这个练习,你可能需要下载一份libpng的古老版本,并且修改我所提供的Makefile以便它能够在恰当的位置找到恰当版本的libpng。这时候你最好小心一点,可不要让旧版本的libpng和预装在你机器上的新版本发生冲突。

或者,你可以在桉树社区云服务上免费注册一个帐号,启动一个虚拟机实例,然后将这些程序丢到虚拟机实例里。也就是说

理由四:沙箱环境 - 基础设施服务给大数据带来的最后一个好处是为互不兼容的代码提供沙箱环境。同一份数据可能需要经由不同的程序进行分析,这些不同的程序可能要求互相冲突的依赖关系。在这个例子中,对一个老旧版本的libpng的要求可能会造成依赖关系的冲突。当程序的规模增长时,类似的版本冲突就会越来越频繁。基础设施服务允许具有不同依赖关系的程序和平共处,能够对同一份数据进行处理。

总结

有些时候人们认为大数据和类似于基础设施服务的云计算是相互联系的,有些时候却又认为它们是互不相关的。我个人的观点是基础设施服务通过程序控制为软件工程以及运行环境所提供的支持会使得大数据相关的技术和应用越来越普及。大数据会是那个答案,但是我们都需要一些小代码来提出问题。毕竟,只有复活节兔子才知道彩蛋到底藏在哪里。

译者注:作者Rich Wolski是Eucalyptus的联合创始人与首席技术官,也是UCSB计算机系的著名教授。他在大数据和云计算方面有丰富的研究,其观点总是令人耳目一新。译者在OS X 10.8.2和Ubuntu 12.04.1上都编译运行过Rich所提供的程序。在OS X上让这个程序跑起来的确需要经过一些周折,但是在Ubuntu上几乎不需要做任何额外的工作,可以认为这是这个例子的一个不足之处。

原文链接:

http://www.eucalyptus.com/blog/2013/01/23/big-data-and-little-code-or-why-iaas-easter-bunny

球球的故事

By , 2013年1月25日 11:44 上午

(1)

婉清爱听故事。我们给她买了一个放CD的机器,还有大堆的CD,她就一天到晚地呆在屋里听。球球现在开始听得懂话了,也经常凑在姐姐身边一起听。据婉清说,球球不但听得懂,还会一边听一边思考。

听到大禹治水三过家门而不入的故事时,球球问:“难道他不累吗?他不困吗?他不需要妈妈陪吗?”

(2)

我们家的大黑狗在院子里吃草,球球就问姐姐:“狗狗在吃草呢,难道它是羊吗?”

 

使用Nagios监控Eucalyptus云平台

By , 2013年1月24日 9:50 下午

简介

和运行在数据中心里的任何生产系统一样,用于生产环境的Eucalyptus私有云需要一个健康监测系统。健康监测系统的功能是使得系统管理员能够及时了解资源使用状况,未来的发展趋势,并在资源池(服务器、网络、存储等等)出现问题的情况下提供可靠的真短信息。我们在我们自己的生产系统当中使用Nagios来对Eucalyptus云平台进行监控。如果您所部署的Eucalyptus云平台还没有任何监控系统,我们推荐您也使用Nagios来对Eucalyptus云平台进行监控。

Nagios是一个开放源代码的IT资源监控系统,可以从Nagios的网站或者其他开源软件仓库获得。在Nagios的网站上对Nagios的介绍如下:

“Nagios是一个强大的监控系统。它使得企业能够及时发现并解决IT设施中存在的问题,以免关键性业务流程受到影响。(Nagios is a powerful monitoring system that enables organizations to identify and resolve IT infrastructure problems before they affect critical business processes.)”

在这个文档中,我们通过一些简单的步骤来介绍如何利用Nagios来监控一个运行在CentOS或者RHEL 6上的Eucalyptus系统。

步骤一:安装配置Eucalyptus

在这个文档中,我们将跳过如何安装配置Eucalyptus。如果您需要帮助的话,您可以参考《在CentOS 6.3上安装Eucalyptus》这个教程。

步骤二:Nagios快速安装

如果你是按照Eucalyptus的官方文档通过软件仓库安装了Eucalyptus的话,我们已经为您添加了安装Nagios所需要的软件仓库。在所有运行Eucalyptus组件的服务器上,用如下命令安装Nagios NRPE插件:

# yum install nrpe nagios-plugins-all

然后,在一台我们称为“Nagios前端服务器”的主机上安装Nagios软件包:

# yum install nagios

Nagios的安装就这么简单。

步骤三:Nagios简单配置

在将Nagios投入使用之前,我们需要进行一些简单的配置。需要说明的是,在如下教程中,我们假定在整个系统中只有一台Nagios前端服务器。也就是说,所有被监控主机上的监控配置都是一致的,这样我们就不需要为每台主机维护一个专有的配置文件。

在所有被监控主机上进行如下设置,允许Nagios前端服务器与被监控主机上的NRPE守护进程进行交互:

  • 编辑文件 /etc/nagios/nrpe.cfg
  • 将 ‘allowed_hosts=127.0.0.1‘ 修改为 ‘allowed_hosts=<ip address of your nagios server>
  • 在该配置文件的末尾,修改如下监控参数
command[check_users]=/usr/lib64/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib64/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
command[check_disk]=/usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /
command[check_procs]=/usr/lib64/nagios/plugins/check_procs -w 250 -c 400 -s RSZDT
command[check_swap]=/usr/lib64/nagios/plugins/check_swap -w 20% -c 10%
  • 使用命令 ‘service nrpe start‘ 启动NRPE守护进程

接下来,在Nagios前端服务器上进行如下设置以启用NRPE,以及允许Nagios从一个本地文件夹中读取远程被监控节点上的配置文件,这些配置文件提供了每一个Eucalyptus节点的配置信息:

  • 编辑文件 /etc/nagios/nagios.cfg
  • 取消这一行前面的注释符号 ‘cfg_dir=/etc/nagios/servers‘ ,然后保存文件
  • 创建目录 /etc/nagios/servers
  • 编辑文件 /etc/nagios/objects/commands.cfg ,在文件的末尾添加如下内容,然后保存文件
define command { command_name check_nrpe command_line /usr/lib64/nagios/plugins/check_nrpe -H $HOSTADDRESS$ -c $ARG1$ }
  •  运行命令 ‘htpasswd -bc /etc/nagios/passwd nagiosadmin nagios‘ 将Nagios管理员的密码设置为 ‘nagios’(建议您选择一个您自己定义的密码)

接下来,在Nagios前端服务器上为每一个Eucalyptus节点创建一个配置文件,这个配置文件定义了被监控主机的入口(end-point)以及需要监测的参数(服务)。所有被监控主机的的配置文件都需要存放在 /etc/nagios/servers 这个目录下 。下面是一个配置文件的例子,需要注意的是您需要将’host’部分的address设置为被监控节点的IP地址。

###############################################################################
###############################################################################
#
# HOST DEFINITION
#
###############################################################################
###############################################################################
# Define a host for the local machine
define host{
 use linux-server
 host_name my-cloud-controller
 alias Cloud Controller
 address 10.102.1.24
 check_interval 1
 }
###############################################################################
###############################################################################
#
# SERVICE DEFINITIONS
#
###############################################################################
###############################################################################
# Define a service to "ping" the local machine
define service{
 use local-service ; Name of service template to use
 host_name my-cloud-controller
 service_description PING
 check_command check_ping!100.0,20%!500.0,60%
 }
# Define a service to check the disk space of the root partition
# on the local machine. Warning if < 20% free, critical if
# < 10% free space on partition.
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Root Partition
 check_command check_nrpe!check_disk
 }
# Define a service to check the number of currently logged in
# users on the local machine. Warning if > 20 users, critical
# if > 50 users.
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Current Users
 check_command check_nrpe!check_users
 }
# Define a service to check the number of currently running procs
# on the local machine. Warning if > 250 processes, critical if
# > 400 users.
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Total Processes
 check_command check_nrpe!check_procs
 }
# Define a service to check the load on the local machine.
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Current Load
 check_command check_nrpe!check_load
 }
# Define a service to check the swap usage the local machine. 
# Critical if less than 10% of swap is free, warning if less than 20% is free
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Swap Usage
 check_command check_nrpe!check_swap
 }
# Define a service to check SSH on the local machine.
# Disable notifications for this service by default, as not all users may have SSH enabled.
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description SSH
 check_command check_ssh
 notifications_enabled 0
 }

将所有被监控节点的配置文件都创建完毕后,使用如下命令在Nagios前端服务器上启动Nagios:

service httpd start
service nagios start

现在Nagios应该处于运行状态并为您的系统提供基本的监测服务了。 您可以通过浏览器访问Nagios的用户界面(默认的URL地址为http://ip_address/nagios),登录时使用的用户名是’nagiosadmin’,密码是’nagios’(或者您刚刚设定的其他密码)。为了验证基本的监控功能已经正常运转,我们可以看一下’hosts’和’services’部分是否显示了我们在配置文件中所定义的所有主机和服务。当我们刚刚启动Nagios的时候,Nagios需要几分钟的时间从被监控主机上提取必要的信息,大概五分钟之后我们可以看到服务的状态从’PENDING’变更为’OK’(或者是’WARNING’或者’CRITICAL’)。

步骤四:Eucalyptus相关配置

到目前为止,我们已经有了一个可以用来管理和维护Eucalyptus部署环境的监控工具。我们能够及时得知网络的通畅状况(up / down),磁盘的使用状况(free / full),负载的具体状况(low / high)等等在大多数情况下都需要了解的信息。接下来,我们添加一些与Eucalyptus相关的监测参数,这些监测参数使用Nagios自带的日志文件监测程序(logfile checker)来对Eucalyptus服务进行基本的健康状况监控。

  • 编辑文件 /etc/nagios/nrpe.cfg
  • 增加如下监控参数的定义
# Eucalyptus checks
  command[check_cclog]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/cc.log -O /tmp/nagioscc.log -q "ERROR|FATAL"
  command[check_ccfaults]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/cc-fault.log -O /dev/null -q "ERR-"
  command[check_nclog]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/nc.log -O /tmp/nagiosnc.log -q "ERROR|FATAL"
  command[check_ncfaults]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/nc-fault.log -O /dev/null -q "ERR-"
  command[check_cloudlog]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/cloud-output.log -O /tmp/nagioscloud.log -q "ERROR|FATAL"
  command[check_cloudfaults]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/cloud-fault.log -O /dev/null -q "ERR-"
  command[check_walrusfaults]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/walrus-fault.log -O /dev/null -q "ERR-"
  command[check_scfaults]=/usr/lib64/nagios/plugins/check_log -F /opt/eucalyptus/var/log/eucalyptus/sc-fault.log -O /dev/null -q "ERR-"
  • 保存如上文件,并将发布为所有Eucalyptus节点上的 /etc/nagios/nrpe.cfg

接下来,修改 /etc/nagios/servers 目录下与每个被监控主机相关的配置文件,添加与特定被监控主机相关的监控参数(例如,在Cloud Controller主机的配置文件中添加Cloud Controller监控参数,在Walrus主机的配置文件中添加Walrus监控参数,在Cluster Controller主机的配置文件中添加Cluster Controller监控参数,以此类推)。您可以从下列监控参数中拷贝您所需要的监控参数,并将其粘贴到相对应的被监控主机配置文件中。需要注意得失,当您往被监控主机配置文件中粘贴监控参数的时候, ‘host_name‘ 字段的内容需要与本配置文件中的’host’部分所定义的host_name保持一致。

## Cloud Controller Checkers
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Cloud Logs
 check_command check_nrpe!check_cloudlog
 }
define service{
 use generic-service ; Name of service template to use
 host_name my-cloud-controller
 service_description Cloud Faults
 check_command check_nrpe!check_cloudfaults
 }
## Walrus Checkers
define service{
 use generic-service ; Name of service template to use
 host_name my-walrus
 service_description Walrus Logs
 check_command check_nrpe!check_cloudlog
 }
define service{
 use generic-service ; Name of service template to use
 host_name my-walrus
 service_description Walrus Faults
 check_command check_nrpe!check_walrusfaults
 }
## Storage Controller Checkers
define service{
 use generic-service ; Name of service template to use
 host_name my-storage-controller
 service_description SC Logs
 check_command check_nrpe!check_cloudlog
 }
define service{
 use generic-service ; Name of service template to use
 host_name my-storage-controller
 service_description SC Faults
 check_command check_nrpe!check_scfaults
 }
## Cluster Controller Checkers
define service{
 use generic-service ; Name of service template to use
 host_name my-cluster-controller
 service_description Cluster Controller Logs
 check_command check_nrpe!check_cclog
 }
define service{
 use generic-service ; Name of service template to use
 host_name my-cluster-controller
 service_description Cluster Controller Faults
 check_command check_nrpe!check_ccfaults
 }
## Node Controller Checkers
define service{
 use generic-service ; Name of service template to use
 host_name my-node-controller
 service_description Node Controller Logs
 check_command check_nrpe!check_nclog
 }
define service{
 use generic-service ; Name of service template to use
 host_name my-node-controller
 service_description Node Controller Faults
 check_command check_nrpe!check_ncfaults
 }

最后,在Nagios前端服务器上重启nagios服务,并在所有的被监控节点上重启NRPE服务,然后刷新浏览器界面。

步骤五:使用Nagios

下面是使用Nagios对Eucalyptus私有云进行监控的一个屏幕截图。在这个屏幕截图中,被监控主机cloud-walrus-sc上出现了一个CRITICAL级别的错误信息,这是因为我们故意地向Cloud Controller发送了一个非法请求。(点击图片可以看到大图。)

nagios-euca

后续配置

我们可以对Nagios进行配置,使得Nagios在某些监控参数出现错误的时候自动地以特定的频率向特定的电子邮件地址发送报警信息。此外我们还可以对监控频率、报警阈值(例如在发送报警信息之前需要经历过多少次监控错误)、以及其他参数进行配置。您可以参考 Nagios 文档 以了解如何对Nagios进行更进一步的配置。

译者注:本文档翻译自Eucalyptus公司共同创始人Daniel Nurmi的博客。原文的出处是:

http://nurmiblog.wordpress.com/2013/01/24/eucalyptus-and-nagios/

《普罗米修斯》

By , 2013年1月21日 6:45 上午

埃斯库罗斯的悲剧《普罗米修斯》,罗念生翻译。

 

《普罗米修斯》

普罗米修斯(Prometheus)是伊阿珀托斯(Iapetos)与忒弥斯(Themis)的儿子。传说普罗米修斯曾盗取天上的火送给人类,因此遭到了宙斯(Zeus)的惩罚,把他钉在高加索山上,叫一只鹰每天来啄他的肝,但是那肝第二天又会恢复原样,重新遭受那鹰的蹂躏。在这一出悲剧的开始,火神赫淮斯托斯(Hephaistos)跟随押送普罗米修斯的威力神(Kratos)和暴力神(Bia)一同来到高加索山,要将普罗米修斯钉在悬崖的边上。

威力神和暴力神分别是帕拉斯(Pallas,是天神乌兰诺斯和地神该亚的儿子)与斯堤克斯(Stys,是河神Okeanos的女儿)的儿子和女儿。天神乌兰诺斯(Ouranos)是地神该亚(Gaia)的儿子,也是该亚的丈夫。该亚给乌兰诺斯生了六男六女,称为提坦神。在希腊神话中,乌兰诺斯是最早的君王,他的儿子克洛诺斯(Kronos)推翻了乌兰诺斯的统治成为第二代君王,克洛诺斯的儿子宙斯(Zeus)又推翻了克洛诺斯的统治成为第三代君王。宙斯登上王位之后,将所有的提坦神都禁闭在冥土下面一个叫做塔耳塔洛斯(Tartaros)的深渊里。赫淮斯托斯是宙斯与赫拉(Hera)的儿子,由于出生的时候就是个跛子被其亲生母亲丢到海里,幸好宙斯将他救上来给他安排了一份铁匠的工作。在奥林匹斯(Olympus)山上诸神中,赫淮斯托斯是一个精巧的工匠,是一个下贱的体力劳动者。

威力神和暴力神仗着宙斯的权势,对普罗米修斯颐指气使。唯有善良而正直的赫淮斯托斯对普罗米修斯充满了同情,但是又无力违反宙斯的命令。当威力神和暴力神命令赫淮斯托斯将普罗米修斯钉起来的时候,他说:

啊,威力神,暴力神,宙斯的命令你们是执行完了,没有事儿了;我却不忍心把同族的神绑在寒风凛冽的峡谷边上。可是我又不得不打起精神做这件事;因为漠视了父亲的命令是要受到惩罚的。

谨慎的忒弥斯的高傲儿子啊,尽管你和我不情愿,我也得拿这条解不开得銅链把你锁起来,钉在这荒凉的悬岩上,在这里你将听不见人声,看不见人影;太阳的闪烁火焰会把你烤焦,使你的皮肤失掉颜色;直到满天星斗的夜遮住了阳光,或太阳出来化去了晨霜,你才松快。这眼前的苦难将永远折磨你,没有人救得了你。

这就是你爱护人类所获得的报酬。你自己是一位神,不怕众神发怒,竟把那宝贵的东西送给了人类,那不是他们应得之物。由于这缘故,你将站在这凄凉的石头上守望,睡不能睡,坐不能坐;你将发出无数的哀叹,无益的呻吟;因为宙斯的心是无情的;每一位新得势的神都是很严厉的。

每一位新得势的神都是很严厉的!这是何其形象的语言啊!在威力神和暴力神的严格监督下,赫淮斯托斯一边悲叹普罗米修斯所受到的不公正待遇,一边将普罗米修斯钉在悬崖的边上。我们的英雄在受难的过程当中一声不吭,只有等到威力神、暴力神还有赫淮斯托斯离开之后,他在寂寞与凄凉的双重袭击下终于发出了悲叹:

啊,晴明的天空,快翅膀的风,江河的流水,万顷海波的欢笑,养育万物的大地和太阳普照的光轮,我向你们呼吁:请看我这个神怎样受到众神迫害。请看我忍受什么痛苦,要经过万年的挣扎。这就是众神的新王想出来对付我、有伤我体面的束缚。哎,哎,我为这眼前和未来的灾难而悲叹!我这苦难的救星会在什么地方出现啊?

 这是什么话呀?一切未来的事我预先看得清清楚楚;绝不会有什么意外的灾难落到我头上。我既知道定数的力量不可抵抗,就得尽可能忍受这注定的命运。这些灾难说起来痛苦,闷在心里也痛苦!只因为我把神们特有的东西送给了人类,哎呀,才受这样的罪!我把火种偷来,藏在茴香杆里,使它成为人们各种技艺的教师,绝大的资力。为了这点过错,我受罚受辱,在这露天之下戴上脚镣手铐。

但是,并不是除了赫淮斯托斯之外就没有别的人或者神敢于对普罗米修斯表示同情了。你看,河神俄克阿诺斯(Okeanos)的十二个女儿乘着飞车前来探望我们的英雄了。她们得到了父亲的准许,连鞋都来不及穿就赶过来了。她们眼睛里充满了朦胧的泪水,控诉宙斯滥用法令,专制横行。我们的英雄在这巨大的抚慰之下,又一次显示出了他的坚强与忍耐。他告诉河神的女儿们宙斯原本是在他的帮助下才登上王位的。那时候天神们起了内讧,要把克洛诺斯轰下台去,改立他的儿子宙斯为王。普罗米修斯和母亲忒弥斯预见到宙斯的法律统治将要取代提坦神的暴力统治,因此帮助宙斯取得了胜利。刚刚登上王位的宙斯将权力分配给众神,但是对可怜的人类毫不关心,甚至打算要灭绝人类另行创造新的种族。普罗米修斯完全是出于对人类的怜悯才帮助人类的,他自己说道:

只有我有胆量拯救人类,使他们不至于完全被毁灭,被打进冥府。为此,我屈服在这样大的苦难之下,忍受着痛苦,看起来可怜!我怜悯人类,自己却得不到怜悯;我在这里受惩罚,没有谁怜悯,这景象真是使宙斯丢脸啊!

就在这个时候,河神俄克阿诺斯也亲自来看望普罗米修斯了。不过他似乎不是前来表示同情,而是前来向普罗米修斯劝降的:

天上已经立了一个新的君王……你的遭遇就是太夸口的报应……你既看见一位严厉的、不受审查的君王当了权,你就得奉我为师,不要伸脚踢刺棍。

但是普罗米修斯拒绝了河神的好意,河神的女儿们又一次为普罗米修斯的遭遇而悲叹了:

普罗米修斯,我为你这不幸的命运而悲叹,泪珠从我眼里大量滴出来,一行行泪水打湿了我的细嫩双颊。真是可怕啊,宙斯凭自己的法律统治,向前朝的神显出一副傲慢的神情。

现在,整个世界都为你大声痛哭……海潮下落,发出悲声,海地在呜咽,下界黑暗的地牢在号啕,澄清的河流也为你的不幸灾难而悲叹……普罗米修斯,你不怕宙斯,意志坚强,但是你未免太重视人类了。

让我们暂且把这剪不断理还乱的人物关系理一理吧。河神俄克阿诺斯是天和地的儿子,普罗米修斯的父亲伊阿珀托斯和母亲忒弥斯也都是天和地的儿女。所以河神俄克阿诺斯是普罗米修斯的叔叔,普罗米修斯是俄克阿诺斯的侄儿,河神的女儿们是普罗米修斯的堂妹。普罗米修斯的妻子赫西俄涅(Hesione)是河神众多女儿中的一个,所以河神还是普罗米修斯的岳父,河神的女儿们是普罗米修斯的表亲。宙斯的父亲克洛诺斯是天和地的儿子,威力神和暴力神的父亲帕拉斯也是天和地的儿子,所以普罗米修斯、宙斯、威力神、暴力神、还有河神的女儿们都是堂兄堂弟堂姐堂妹。

如果就这样让普罗米修斯和河神可爱的女儿们就这样一直哀叹下去,那么终究会让普罗米修斯显露出软弱的一面的。于是诗人及时地让伊俄出场了。伊俄是伊那科斯的女儿,原来是赫拉庙上的祭司,但是被宙斯看上了。赫拉当然不能够容忍自己的祭司变成丈夫的情人,宙斯于是把伊俄变成一头牛以躲避妻子的干涉。赫拉派了个牧人看守这头牛,但是牧人被宙斯的儿子赫尔墨斯杀死了。赫拉又叫一只牛氓追赶伊俄,不让宙斯接近她。伊俄被牛氓追赶到了高加索山上,看见了被绑在石头上遭受风暴的普罗米修斯。普罗米修斯认出了伊俄,并向她预言她未来颠沛流离的生活。(宙斯最后在埃及找到伊俄,让她恢复勒人形,并且和她生了一个儿子。这个儿子就是埃及日后的国王厄帕福斯Epaphos。)这一段对话我们看起来冗长,但是据说当时很能引起观众的兴趣,因为观众对于自己未知的世界是抱有很大好奇心的。另外,普罗米修斯和伊俄之间的关系,在于很多很多年之后,伊俄的第十三代传人赫剌克勒斯将要把普罗米修斯从苦难中解救出来。

河神的劝说,以及河神女儿们的同情,都不能够使普罗米修斯向宙斯屈服。普罗米修斯坚信自己保守着一个能够让宙斯失去权势的秘密,总有一天宙斯会回心转意重新与他结盟,以避免被下一个君主推下王位。于是宙斯的使臣赫尔墨斯趾高气昂地前来向普罗米修斯索要这个秘密了。你看,这个依附权势的小人说起话来是多么的傲慢无礼啊:

你这个十分狡猾,满肚子怨气的家伙,我是在说你 — 你得罪了众神,把他们的权利送给了朝生暮死的人,你是个偷火的贼;父亲叫你把你常说的会使他丧失权力的婚姻指出来;告诉你,不要含糊其辞,要详详细细的指出来;普罗米修斯,不要使我再跑一趟;你知道,含含糊糊的话平息不了宙斯的愤怒。

面对这样的小人,普罗米修斯怎么可能会屈服呢?宙斯是无法用苦刑或诡计强迫普罗米修斯道破一个秘密的。恼羞成怒的赫尔墨斯终于亮出了底牌:

如果你不听我的话,你要注意,什么样的风暴和灾难的鲸滔鲵浪会落到你身上,逃也逃不掉:首先,父亲将用雷电把这峥嵘的峡谷劈开,把你的身体埋葬,这岩石的手臂依然会拥抱你。你在那里住满le很长的时间,才能回到阳光里来;那时候宙斯的有翅膀的狗,那凶猛的鹰,会贪婪地把你的肉撕成一长条、一长条的,它是个不速之客,整天地吃,会把你的肝啄得血淋淋的。

不要盼望这种痛苦是有期限的,除非有一位神来替你受害,自愿进入那幽暗的冥土和漆黑的塔耳塔洛斯深坑。

是的,这家伙所说的消息普罗米修斯早已知道。对于普罗米修斯来说,忍受仇敌的迫害算不得耻辱。他说:

让电火的分叉的鬈须射到我身上吧,让雷霆和狂风的震动扰乱天空吧;让飓风吹得大地根基动摇,吹得海上的波浪向上猛冲,扰乱了天上星辰的轨道吧,让宙斯用严厉的定数和旋风把我的身体吹起来,使我落进幽暗的塔耳塔洛斯吧;总之,他弄不死我。

在普罗米修斯说了这番话之后,赫尔墨斯就要开始展开报复行动了。他劝河神的女儿们离开这是非之地,免得那无情的霹雳震得她们神志昏迷。河神的女儿们回答道:

请你说别的话,劝我做你能劝我做的事吧;你插进这句话,使我受不了!为什么叫我做这卑鄙的事呢?我愿意和他一起忍受任何注定的苦难;我学会了憎恨叛徒,再也没有什么恶行庇出卖朋友更使我恶心。

这是普罗米修斯留下的最后的话语:

看呀话已成真:大地在动摇,雷声在地底下作响,闪电的火红的鬈须在闪烁,旋风卷起了尘土,各处的狂风在奔腾,彼此冲突,互相斗殴;天和海已经混淆了!这风暴分明使从宙斯那里吹来吓唬我的。我的神圣的母亲啊,推动那阳光普照的天空啊,你们看见我要遭受什么样的迫害啊!

在悲剧的最后,普罗米修斯在雷电中小时,歌队也跟着不见了。

普罗米修斯并不是孤独的。

 

 

《波斯人》

By , 2013年1月21日 6:34 上午

埃斯库罗斯的悲剧《波斯人》,罗念生翻译。

 

波斯老国王大流士(Darius)兵败马拉松(Marathon)战役。老国王死后,新国王塞克塞斯(Xerxes)带领远征军讨伐希腊,留下一些元老代为执行政务。当时希腊人比波斯人善于航海,而波斯人比希腊人精于骑射。塞克塞斯这一回出征希腊,不仅带去了1207只兵船,还有一支精锐的骑兵部队。塞克塞斯用六条巨绳在赫勒海峡(Hellespont)上搭起了一座浮桥,使得骑兵也可以顺利渡过大海。

由于军情隔绝,长老们聚集在一起讨论战事的吉凶。由长老们组成的歌队这样描述波斯大军的狂妄、暴戾、以及专制:

那争城夺地的王师渡到西邻的对岸去了,他们用绞织的巨绳系在赫勒海峡上公然越过,这系束的浮桥就像一条羁绊套在大海的颈上。

亚细亚的暴烈君主信靠他凶狠的将帅驱使着精良的大军水陆并进,去征服全世界;我们的国王与天神同尊,他的祖先原是“金雨”的结晶。

他眼中射出毒蛇的黑光,乘着叙利亚的车銮,带着水陆两军和勇敢的箭手去攻打那著名的茅兵。

长老们的歌队也表达了战争给人民所带来的痛苦:

婚床上滴满了眼泪,为的是思念良人;这些波斯妇人离开了他们暴烈的夫君,在想念中,在悲痛中愈觉孤单。

皇太后阿托萨(Atossa)出来请求长老们为她解释一个噩梦。在噩梦中有两位美丽无暇的高大女郎发生了争吵,两人各穿着希腊和波斯的服饰。塞克塞斯出来试图制服两位女郎,用绊带系在她们的脖子上驾在马前。有一位女郎顺从地听使缰绳的牵引,另一位却竭力反抗把横轭折成了两端。塞克塞斯从车上滚了下来,他已故的父亲站在旁边怜悯地看着他。无地自容的塞克塞斯在父亲的注视下撕毁了身上的长袍。

长老们听了这个不吉利的梦境,不敢跟皇太后解释噩梦的含义,只好劝她去祭祀地母和阴魂。这时候,从前线回来的信使报告了确实的军信:

全亚细亚的都城啊,波斯的领土和财富的藏府啊,怎么轻轻一打击,你们的幸福便消失了?波斯的花朵便枯萎了?啊,做一个首先传播凶信的人真是苦啊;但是呀,我得把战败的消息透露出来,波斯人啊,我们的全军覆灭了!

波斯人的失败是从海上开始的。如果单说战船的数量的话,波斯人用1207艘兵船将希腊人的300艘兵船包围在一个萨拉弥斯(Salamis)狭小的海湾里,大有将希腊海军一举歼灭之势。但是希腊人派了一个奸细来到波斯人的军中,谎称是希腊的兵船想要乘黑逃跑。波斯人严阵以待,彻夜不眠,而养精蓄锐的希腊人在日出时分冲杀出来,于是疲惫不堪的波斯海军大祸临头了。从前线回来的信使这么说道:

等到这许多船只集中在那狭小的港内时,非但不能彼此顾及,并且用那包铜的船头对着自己的船身撞击,撞坏了全船的桡扁。敌舰不肯失去良机,围着我们攻打,把我们的船弄翻了。海面上看不见水,净是破船片和被杀的尸;海滩上和礁石上也堆满着尸体……惨痛的事情多者呢,就叫我细数十天,我也数不完啊。但是你很可以相信,我们从未在一日之内丧失过这么多人。

波斯人的陆军也好不到哪里去。为了截击逃跑的希腊人,塞克塞斯派遣精锐兵士埋伏在一个小岛上。但是希腊人的战船将小岛团团围住,身穿战甲的兵士登上岛来,用石头、弓箭和长矛对着波斯人任意宰杀。塞克塞斯坐在海边的高山上,目惊口呆,高声嚎啕,撕破王袍,下令撤军。然而溃败的大军在返回波斯的途中又遭遇了严酷天气的袭击,有的人累死了,有的人渴死了,有的人饿死了,还有的人掉在刚刚结冰的河里淹死了。国王塞克塞斯倒是安全地回到了波斯,但是与他一起前去讨伐希腊的大军,大部分都埋骨在异国他乡了。

长老们的歌队这样哀叹波斯所遭受的打击:

我主宙斯啊,你如今毁灭了高傲的波斯人的大军,用一层灰暗的忧愁掩罩着苏萨城。许多妇女同来哭悼,用纤弱的手指撕毁了面纱,那浸濡的眼泪湿透了她们胸前的衣褶。那些波斯的妻子痛哭不定,在忧伤里想望新婚的夫君,他们离弃了那柔软的床帏,再不能在那床帏里享受青春和快乐。我自己也放出这真诚的悲歌来哭悼那些从军的死者。

唉,那些被迫留在萨拉弥斯的死者依然在那海滩上漂浮。哦,快哭啊,把这苦痛的悲音送入云天!伤心啊,把这愁惨的哭声送入云天!

唉,涡流撕毁他们的尸体,净海里无声的鳞介吞噬他们的骨肉。哎呀,家家门户哀悼人丁的死丧,孤独的亲老听了这全盘的灾难,一齐痛哭这天降的惩罚。

全亚细亚的人民不再遵守波斯的王法,不再受国王的威迫前来进贡,不再伏在地下敬畏至尊:因为波斯哦王权已经崩溃了。

他们不再保持缄默,暴力的钳制既然松懈了,他们便会自由议论。波斯的一切都埋藏在萨拉弥斯的红沙里。

这个时候噩梦的含义已经非常明了,皇太后阿托萨放弃了对神的祭祀,却跑到先夫大流士的坟前去祈祷。老国王的阴魂被长老们的咒语所惊醒,出来责备他的儿子不该贸然带领大军出征。他把儿子的失败归咎于天神的诅咒,说道:

哎呀!那神示竟显验得这样快,天帝宙斯把他得话应在我的儿子身上,我还相信要过了许多时候才能实现呢。但凡人作孽时,天神更是相催。现在啊,一大祸患临到了我的人民身上。我的儿子糊里糊涂地,凭着方刚的血气闹出了乱子。他想用镣铐把赫勒海峡的圣洁潮汐当一个努力锁起来,因此创出了一种新奇的水道:他用铁制的巨链抛过对岸,为他的大军筑成了一道长桥。他原是一个凡人,却妄想征服海神,征服一切的天神。这岂不是我的儿子发疯了?恐惧我辛辛苦苦为人民聚下的财宝会给那先下手的人掠去了。 

在悲剧的最后部分,丢魂落魄的塞克塞斯回到了波斯,在长老们的追问下哭诉战争中损失的精兵强将,并与长老们共同哀叹波斯所遭受的悲痛。

在这个悲剧里,大流士看起来是多么的热爱和平啊。诗人似乎忘记了大流士再其当政期间经历了两次惨败,一次是败于斯库提亚(Scythia),另一次在著名的马拉松战役中败于希腊。虽然大流士没有亲自出征,但是马拉松的败讯使得大流士一直耿耿于怀,征集了全部的人马和兵辐准备前往雅典进行报复。不幸的是正当大流士信心满满准备停当的时候,却被冥神永久地召唤到地府去了。他的儿子塞克塞斯本来是不打算去打仗的,但是他的谋臣们不断地用先王的遗志和天神的预言来怂恿他。从某种意义上来说,塞克塞斯也许是被谋臣们绑架出征的。

而诗人自己就亲身参加过击败波斯人的马拉松战役。他在自己的墓碑上全然没有提及自己在戏剧方面的成就,而是强调了自己在战场上的英勇:

马拉松的圣林能道出我盖世的英豪,那鬓发丛生的波斯人也必能深铭熟忆。

埃斯库罗斯出生于公元前525年,这个时候波斯和希腊之间战争刚刚开始。马拉松战役发生于公元前490年,波斯老国王大流士死于公元前486年,萨拉弥斯海战发生于公元前480年。直到公元前449年塞浦路斯战役之后,波斯和希腊之间的战争才宣告结束。《波斯人》这部悲剧据说是在公元前472年上演的,距离萨拉弥斯海战不过只有八年时间。从诗人的墓碑上来看,诗人参加了马拉松战役可以说是证据确凿的。也有传说认为诗人也参加了萨拉弥斯海战,这一类的传说可能不太可靠。但是在整个雅典人都放弃了城池将财产转移到岛上去躲避时,诗人完全有可能就在附近的海岛上目睹了大战的整个过程。《波斯人》是古希腊悲剧中现存的唯一一部以当时现实为题材的作品,为我们了解当时的历史提供了宝贵的资料。诗人亲自参加战争捍卫希腊的自由,其爱国热情毫无保留的自然流露在其作品中。然而诗人又没有对波斯所遭受的失败表示幸灾乐祸,而是对其人民所遭受的深重苦难表示了真切的怜悯与同情。也许可以这么认为,诗人出于爱国热情参加了卫国战争并为此感到骄傲,但是在其内心深处其实是反对战争的。

《波斯人》这一部悲剧,结构比较简单,情节也不算曲折,但是诗人的从军经历成就了其宏大场面。这中宏大的场面是我们在欧里庇得斯的悲剧中所看不到的。

 

 

Aquilaria Introduction

By , 2013年1月17日 6:03 上午

Aquilaria-Introduction-1

This is a lightning presentation I gave to my Eucalyptus colleagues at Santa Barbara during our all-hands meeting. I think this is an interesting presentation and would like to share it with the rest of my friends. For those who prefer to read Chinese I have an older version in Chinese that was created in 2009, and the content in that version is quite similar to this one.

Aquilaria-Introduction-2

Aquilaria refers to a collection of 15 species of trees in the Thymelaeaceae. These are trees that grow in the rain forests in Southeast Asia. The heights of the trees are quite different, depending on the actual species and the geographic location they grow, but usually fall within the range of 6 to 20 meters. I myself have seen trees as tall as 30 meters in the south part of Thailand, and I assure you that these are very very old trees.

From this slide you can also see the flowers, the fruit, and the seeds.

Aquilaria-Introduction-3

As said just now, these trees usually occur in Southeast Asia, especially within the yellow square on this map. This includes the south part of China, the north part of India, Burma, Cambodia, Vietnam, Laos, Thailand, Malaysia, Philippines, and Indonesia.

屏幕快照 2013-01-17 上午6.00.57

Aquilaria is considered as the major source of agarwood. By saying agarwood we usually refer to the resinous material produced by the Aquilaria trees. Some people think that agarwood is the heart wood of the tree, but actually it is not. The Aquilaria tree produces epoxy-like material to protect itself when it get wounded, either by the force of nature such as birds and worms or by human beings. As time goes by the concentration of this epoxy-like material gets richer, and the color of the wound becomes darker. And then people harvest the dark and resinous part from the tree, which is called agarwood.

Aquilaria-Introduction-5

Agarwood is well known by its fragrance, which is very appealing and pleasing. Therefore it is widely used in religion rituals among the buddhist world and the islamic world. Further more,  agarwood has a decent hardness so that people make it into prayer beats or sculptures. It is believe that if you wear such prayer beats or host such sculptures you will receive special blessing from the Buddha, or Shiva, or some other god or goddess.

Aquilaria-Introduction-6

Agarwood can also be further processed to produce essential oil. The oldest — and also the simplest — method to produce essential oil is water distillation. You crash the wood into powder, boil it along with water, cool down the steam, and separate the oil from water. In the market agarwood essential oil is very expensive, way more expensive then gold. Therefore, the majority of the so-called “agarwood oil” available in the market are usually highly diluted, or even fake.

The essential oil produced can be used for aromatic therapy, body massage, as well as the “magic portion” in high end cosmetics.

I myself have tried this process, and it worked pretty well. The picture on the top-left side was actually taken by myself in my lab several years ago.

Aquilaria-Introduction-7

As you can imagine, agarwood is only an extremely small part of the Aquilaria tree. When people harvest agarwood, they usually cut down the whole tree, get rid of the white wood, extract the dark part, and abandon the rest. This is especially true when the harvest practice is done in an illegal way — and it usually is. As the demand for agarwood increases, the number of standing Aquilaria trees decreases rapidly. Currently, all 15 species of Aquilaria are considered as endangered species, according to Convention on International Trade in Endangered Species of Wild Fauna and Flora (CITES).

Aquilaria-Introduction-8

Starting from 2007, I myself have been actively involved in the preservation and protection of the endangered Aquilaria species. I have a small farm in Hainan, which is a big island in the very south part of China. This is a screenshot from Google Maps, and it shows where I and my family live. In this small garden I have about 200 Aquilaria trees, and I have identified 6 different species out of them. Also, I am in the process of collecting Aquilaria seeds from other countries (legally, of course) and cultivate them in my own farm, so that I can preserve more species in the future.

我的网络会变得更快吗?

By , 2013年1月16日 9:16 上午

译者注:

最近Eucalyptus公司的联合创始人Graziano Obertelli连续写了几篇关于云服务的可维护性方面的博客文章。译者读后觉得很受启发,并决定花点时间将这几篇文章翻译成中文。这些博客文章的原始出处如下:

[1] http://gobertelli.blogspot.com/2012/12/its-maintainability-stupid.html
[2] http://gobertelli.blogspot.com/2013/01/maintainability-and-eucalyptus.html
[3] http://gobertelli.blogspot.com/2013/01/will-my-internet-be-faster.html

最近我写了篇关于云平台的可维护性的博客文章,又举了一个Eucalyptus的可维护性的例子。这回我要换一个角度,通过例子说明如何粗略地进行“负载-资源”映射。

我的网络会变得更快吗?(Will my Internet be Faster?)

在侏罗纪时代,我帮助一位用户安装一个古老版本的Eucalyptus(我想是Eucalyptus 1.4)。我们经历了一些麻烦(那时候还没有Faststart),不过他最终能够在两台服务器上创建虚拟机实例了。然后他问我:“现在我的网络变得更快了吗?”

我想,这个问题正确地表明了云计算这个流行语正在被越来越多的人等同于解决所有IT问题的万金油。另外,它也正确地指出了我们需要充分了解底层的硬件设施才能够获得理想的性能。一个私有云能够达到和底层网络设施一样的传输速度,能够具备和底层硬件资源同样的处理能力。云计算提供了很强的灵活性,但是也有性能损失的危险 - 如果我们没有根据负载来规划硬件设施的话。

案例讨论:云存储(Case In Point: Cloud Storage)

所有的云计算资源最终都要映射成物理资源,例如CPU、内存、网络、磁盘。在这里我要着重讨论一下云存储,一方面是因为它很重要(没有人不关心他的数据吧?),另一方面是因为历史上有很多与云存储相关的问题。值得一提的是,我们在Eucalyptus 3.1.2中解决了由于磁盘负载过高而导致的随机性失效问题。

back-envelope
这篇文章里要进行的一些估算

从我上面这幅涂鸦作品中,你可以看到临时性存储是存放在计算节点(Node Controller,NC)上的,而弹性块存储(Elastic Block Storage,EBS)是由存储控制器(Storage Controller,SC)来处理的。我们很快地看一下这两者是如何使用的:

  • 临时性存储:基于实例仓库(instance-store)的实例和从EBS启动(Boot from EBS,BfEBS)的实例都使用到临时性存储,不同之处在于基于实例仓库的实例还使用临时性存储来存放root分区和交换空间(swap);
  • 弹性块存储(EBS):任何挂载到实例上的卷都使用弹性块存储,从EBS启动的实例还使用弹性块存储来存放root分区和交换空间(swap)。

资源竞争的情形:

  • 临时性存储:在同一个计算节点上的实例会竞争同一个存储资源;
  • 弹性块存储:在同一个可用域(availability zone,在Eucalyptus中等同于一个集群)中使用弹性块存储的实例会并竞争同一个存储控制器。

在这个例子中,我用了一个简单的电子表格来帮我进行计算。你可以任意拷贝、修改、改进这个电子表格,不过你需要记住这只是一个学习工具而不是一个真正的资源计算器 - 为了简化计算,有太多的因素没有被包括在这个电子表格中。

在这个例子中,我使用IOPS来衡量底层存储的速度.

reference-values
不同设备的IOPS数据可能有很大的差异。如上数据只是粗略地表明IOPS性能的量级。

在接下来的例子中,我做了一个不太合理的假设 - 所有的实例都平等地访问存储资源(包括临时性存储和弹性块存储),以及它们可能在20%或者100%的时间里需要访问存储资源。需要说明的是,在20%的情况下,Oracle 会自动地对并行的磁盘访问请求进行优化(也就是说,如果同时运行少于五个实例的话,它们得到的是最快的存储性能,实例之间不存在资源竞争的情况)。

也就是说,20%代表了轻量级的应用场景,实例在大部分时间里都在发呆;而100%代表了重量级应用场景,实例可能正在进行压力测试。启动实例是一个磁盘IO密集型进程,一方面是因为Eucalyptus需要为启动实例准备磁盘映像(需要拷贝好几个个GB的文件),另一方面是因为操作系统在启动过程中需要读取磁盘。在这个电子表格中,我专门添加了一栏以显示在轻量级应用场景下启动实例的磁盘负载开销。

家庭级配置(Home setup)

一个家庭级的云试验环境通常使用基于本地存储的存储控制器。这里我们用一个IOPS计算器来进行性能估算。在存储控制器上,我使用了两块15000转的Seagate Cheetah硬盘,做了个RAID 0,估算得到的IOPS数据是343(为了简单起见,就算是350吧)。在节点控制器上,我使用了一块相对较快的硬盘(非SSD硬盘),假定其IOPS可以达到150。

对于一个家庭级的云试验环境来说,三个计算节点看起来是个不错的数字。我们假定每个计算节点都有足够的CPU核心以及内存,能够运行多于10个虚拟机实例(12~24个CPU核心,12~24 GB的内存应该足够了)。如果我在每个计算节点上运行一个基于实例仓库的实例、一个从EBS启动的实例、以及一个EBS卷。这个不太靠谱的计算器给出的数据如下:

small-light
家庭级的云试验环境,在虚拟机数量较少的情况下,在最坏情形下存储性能也相当于一块5400转硬盘。

这个家庭级的云试验环境看起来还不错嘛。就算是在各个实例中对所有的磁盘进行iozone测试(最坏情形),我们也能够得到相当于单块5400转硬盘的性能。 接下来我们增加一点负载,在每个计算节点上运行四个基于实例仓库的实例、四个从EBS启动的实例、以及两个EBS卷。这时候我们得到如下数据:

small-heavy
家庭级的云试验环境,在虚拟机数量较多的情况下,在最坏情形下存储性能可能跟软盘差不多。

这回就有点意思了。如果各个实例的磁盘负载不大的话(最优情形),我们可以得到类似于7200转硬盘的性能。但是,如果各个实例的磁盘负载很高的话,磁盘IO的性能就跟侏罗纪时代的软盘差不多了。哼哼!

企业级配置(A More Enterprisy setup)

根据上面的数据,在大型的云计算环境中,显然需要考虑使用基于SAN存储的存储控制器。在这个例子中,我使用了一套Dell Equallogic存储设备,将其存储性能配置为5000个IOPS。此外,我们将计算节点的数量增加到10个。

我们还是从较轻的负载开始。在每个计算节点上运行一个基于实例仓库的实例、一个从EBS启动的实例、以及一个EBS卷。(和家庭级云试验环境是一样的,但是现在我们一共有20个正在运行的虚拟机实例了。)

medium-light
配备了SAN存储设备的企业级云试验环境,在虚拟机数量较少情况下,所有的数据看起来都很好。

这个结果看起来非常好。EBS存储性能在最坏情形下还能够达到250 IOPS,在最优情形下甚至能够达到1250 IOPS。临时性存储的性能与家庭级云实验环境相比没有发生什么变化,在最坏情形下还能够达到75 IOPS,相当于一块5400转硬盘(也就是常见的3.5寸台式机所配备的硬盘)的性能。

接下来我们增加一点负载,在每个计算节点上运行四个基于实例仓库的实例、四个从EBS启动的实例、以及四个EBS卷。这时候我们得到如下数据:

medium-high
配备了SAN存储设备的企业级云试验环境,在虚拟机数量较多情况下,在最坏情形下EBS存储性能相当于一块5400转硬盘。

临时性存储的表现还是不够理想,就跟我们在家庭级云实验环境所看到的一样 - 现在每块本地硬盘上要承载8 个虚拟机实例(从EBS启动的实例也需要访问本地硬盘,在这个简化计算中所有的磁盘是使用情况是一样的)。EBS的性能有了大幅度的降低,在最坏的情形下与一块5400转硬盘相当。虽然所有的实例还有足够的IOPS来访问存储设备,但是这时候云管理员应该考虑增加一个可用域(集群)了。

快照(Snapshots)

上面的例子没有考虑到制作快照对存储性能的影响。快照使得我们可以对卷进行备份,并将数据从一个可用域转移到另一个可用域(在一个可用域中制作的快照,可以作为母本在任何可用域中创建新的卷)。快照被存储在Walrus上,也就是说每次我们创建快照的时候,我们从存储控制器(SC)上将一个卷的完整拷贝保存在Walrus上。如果在一个云上频繁地制作快照,可以想像存储控制器、Walrus、还有网络的性能都会受到很大的影响。

期望值(Expectations)

可以认为,上面例子中的数据反映的都是特定应用场景下的最佳性能。在这些分析中我们忽略了网络性能、来自其他进程的磁盘访问等等众多因素。譬如说,Eucalyptus缺省地使用实例仓库来提供交换空间(swap),而大部分Linux发行版都会在安装的时候创建一个swap分区(在Eucalyptus中,从EBS启动的实例可能大部分都需要swap)。因此,这些虚拟机实例在内存不够用的时候都会往相应的磁盘上写数据,从而造成额外的负载。

在这些模拟分析中,我们假定虚拟机实例的负载是相互独立的,并且假定它们之间有一个协作机制使得整个云试验环境的整体磁盘访问达到了最佳情形。在一个生产环境中,创建虚拟机、销毁虚拟机、创建EBS卷、创建快照的时间和顺序基本上是无法预测的,这些都会对存储(包括临时性存储和弹性块存储)造成额外的负载。

在我前段时间发表的关于可维护性的博客文章里面提到,对负载进行采样能够帮助你对云服务进行测试和性能调优,使其能够满足最终用户的要求。

让网络快起来(Making Internet Faster)

在上面的估算中,我们没有考虑任何来自软件因素的性能影响(例如Eucalyptus各个组件本身也是消耗资源的)。事实上,Eucalyptus各个组件对物理资源的需求是在不断降低的。譬如说,在Eucalyptus 3.0以前,计算节点直接地拷贝多个GB的磁盘影像文件,现在我们使用device mapper来减少磁盘访问请求。此外,配置有SAN存储插件的存储控制器增加了一个称为DASManager的模块(DAS是Direct Attached Storage的缩写,指的是直接挂载到宿主机上的存储资源,例如一块磁盘或者一个分区),使得我们能够绕过文件系统对卷进行操作。

speed

和以前的版本相比较,Eucalyptus 3有了很大的性能提升,但是我们还有很大的优化空间,譬如使用分布式文件系统和软件定义网络(Software Defined Network,SDN)。的确,目前Eucalyptus还不能够让网络快起来,但是我们正在往这个方向努力。

Eucalyptus的可维护性

By , 2013年1月16日 3:43 上午

译者注:

最近Eucalyptus公司的联合创始人Graziano Obertelli连续写了几篇关于云服务的可维护性方面的博客文章。译者读后觉得很受启发,并决定花点时间将这几篇文章翻译成中文。这些博客文章的原始出处如下:

[1] http://gobertelli.blogspot.com/2012/12/its-maintainability-stupid.html
[2] http://gobertelli.blogspot.com/2013/01/maintainability-and-eucalyptus.html
[3] http://gobertelli.blogspot.com/2013/01/will-my-internet-be-faster.html

最近我写了一篇博客文章讨论私有云的可维护性为何重要。在这篇文章中,我列出了成功部署一朵私有云需要采取的一些措施,并在部署和维护阶段用Eucalyptus作为IaaS管理软件的例子进行了讨论。

部署(Deploy)

我已经提过我们做很多工作,使得Eucalyptus的安装更加容易,在这里我做一个简单的小结。Eucalyptus为主要的Linux发行版制作了安装包,只需要简单配置一下软件仓库,就可以用yum install或者apt-get install命令来完成软件安装。Eucalyptus的配置还是稍微有点复杂,需要将各个组件进行注册,但是这些步骤是可以自动化的(在FastStart里面各个组件就是自动注册的)。

显而易见,对完美的追求是永无止境的。不过我敢说,从分布式系统的角度来看,我们已经已经把安装过程做得尽可能简单。此外,优秀的系统管理员们都在用软件来管理基础设施。所以,我认为能够用脚本来定制化并管理安装过程是至关重要的(例如Eucalyptus可以用ansiblechefpuppet来定制化和管理安装过程)。

维护(Maintain)

如果你关注我们的最新进展的话,你可能已经知道我们最近发布了Eucalyptus 3.2版本。RichMarten通过博客对这个版本进行了一些描述,DavidAndrewKyo也通过博客对某些特性进行了详细说明。作为一个云管理员,我觉得他们的博客文章并没有详细说明我们在改善Eucalyptus的可维护性方面所做的努力。

Screenshot from 2012-12-30 14_23_32
在Eucalyptus 3.2中修复的缺陷

Eucalyptus 3.2修复了350个缺陷 - 这里我指的是那些被记录在案的缺陷,还有一些缺陷是我们在对代码进行重构的时候直接修复的。各位可能注意到大部分的缺陷是与新特性相关的,但是还有大量的缺陷是与Eucalyptus的健壮性(也就是可维护性)相关的。不相信吗?我可以举几个例子:

  • 重写了存储控制器(Storage Controller,SC)的部分代码,防止云管理员意外地配置了一个不希望被使用的后端存储;
  • 为高可用(HA)功能增加了安全机制,防止云控制器(Cloud Controller,CLC)精神分裂(译者注:也就是两个云控制器都以为自己才是老大);
  • 为孤儿实例(如果节点控制器由于某种意外不能够及时地将该节点上的实例信息更新给云控制器的话,该节点上的实例可能成为无人照看的孤儿实例)提供了更健壮的处理方法;
  • 修复了内存泄漏和数据库连接池泄漏的问题(在特定的应用场景下,这样的缺陷可能需要重启某些组件,估计大家都不会喜欢的)。
你可能会觉得我们新的用户界面很酷。我认为这也是一个强大的基础设施令人喜欢的特性之一。
euca-console-dashboard
用户界面的屏幕截图,借用自David的博客

改进的空间(Are we there yet?)

前面我已经说过,对完美的追求是永无止境的。我们在Eucalyptus 3.2版本中的主要工作在于扩大质量测试(QA)的范围、使得代码更加健壮,能够适应更多的应用场景。这些工作对于大部分人来说是不可见的,但也正是这些工作使得一个基础设施能够经受时间的考验。
这些不可见的工作完成之后,我们接下来的工作就更容易理解和分类了。在Eucalyptus 3.3版本的研发计划中,我看到了许多令人期待的特性,例如自动扩展(AutoScaling)、 云监控(CloudWatch),以及弹性负载均衡(ELB)。如果你特别需要某个特性,请你告诉我们,或者在我们的缺陷跟踪系统中给这个特性投上一票。我们不会因为不断地增加新的特性而忘记了一个基础设施的根本。譬如说,我们在维护模式(Maintenance Mode)以及网络方面的工作能够使得我们更好地管理云计算资源,例如VM类型(vmtypes)和标签(tagging)。
还有其他改进的空间吗?我在前一篇博客文章里面提到,除非是一个基础设施已经被废弃,不然的话总有事情要做。的确,我们还有很大的改进空间,不过我们现在已经挺好用的。

云平台的可维护性

By , 2013年1月15日 5:20 下午

译者注:

最近Eucalyptus公司的联合创始人Graziano Obertelli连续写了几篇关于云服务的可维护性方面的博客文章。译者读后觉得很受启发,并决定花点时间将这几篇文章翻译成中文。这些博客文章的原始出处如下:

[1] http://gobertelli.blogspot.com/2012/12/its-maintainability-stupid.html
[2] http://gobertelli.blogspot.com/2013/01/maintainability-and-eucalyptus.html
[3] http://gobertelli.blogspot.com/2013/01/will-my-internet-be-faster.html

最近我一直在使用FastStartSilvereye,并参与开发了一个在单台服务器上安装云服务的脚本。我还写了一篇博客文章,介绍如何在一台笔记本上安装Eucalyptus。我甚至用发布推特消息的方法来计时,结果表明只要15分钟的时间就可以完成Eucalyptus的安装。这的确是个不错的成绩,但是我想我们可不能忘记了我们搭建私有云的最终目的。

私有云基础设施(On-Premise Cloud as Infrastructure)

我认为Eucalyptus(或者任何其他私有云管理软件)的安装仅仅是部署私有云过程中的一个环节。它既不是第一个环节,更不是最重要的环节。我所说的私有云,指的是基础设施服务(Infrastructure as a Service, IaaS),其重点在于基础设施而不是服务。当我说起基础设施这个词的时候,我会想起卫星、电网、渡槽、互联网等等。作为基础设施,它们具有一些共同的特征。这里我想要讨论的一个特征是可维护性。

可维护性(Why Maintainability?)

基础设施的作用是提供或者支持最基本的服务。当基础设施崩溃时,其结果通常是非常严重的(想象一下断电、断水、断路)。基础设施必须是可依赖的(你能够在不牢靠的地基上盖房子吗),必须具有很长的声明周期(只有演示原型才是临时性的),在其服役期间能够承受各种不同的负载(想象一下高速公路和互联网,它们现在所承担的负载和设计初衷是完全不同的)。因此,基础设施需要具备适应负载的能力(弹性,elasticity)以及分离或者限制失效范围的能力(可靠性,reliability),保持正常的功能并且能够被正常访问(可用性,availability),能够与多个具有类似设计的基础设施相互操作(互操作性,inter-operability),并且限制操作人员的介入(减少人为故障)。在我看来,如上所述种种都是可维护性的根本。在这里我同意Cloud Admin的观点,可维护性包含了可靠性和可用性,因为从管理的角度来看,一个不可靠也不可用的基础设施根本是不可维护的。

部署私有云(Deploying On-Premise Cloud)

那么,我们如何才能够成功地部署一朵私有云呢?我认为主要的困难集中在早期规划、前期准备、负载预测这些环节。其中最重要的部分是理解未来私有云的实施形式以及负载来源,以及设计一个逐步将硬件资源和软件应用转移到私有云上的迁移路线。这听起来似乎很简单,对吧?

1、理解你的负载(Learn your Workload)

在大多数情形下,一朵私有云是为一组特定应用、特定部门、特定用户、或者是特定场景提供服务的。也就是说,未来私有云上的负载情况基本上是可以预知的。我们需要将这些负载分解为计算、网络、存储几个部分,了解各种负载平行发生的可能性以及峰值范围。在可能的情况下,对未来的负载进行预测。

在这个环节,对真实的负载进行采样或者创建模拟负载 是非常有用的。这样做并不容易,在有些情况下甚至不可能。但是,有了一个负载模型之后,我们就能够对架构设计和部署实施进行验证。

2、“负载-资源”映射(Map Workload to Cloud Resources)

云计算资源有三个基本组成部分:计算(CPU和内存)、存储、网络(带宽、安全、隔离、IP地址)。将系统的负载转换成云计算资源的使用量,能够帮助我们规划私有云的规模和容量。

此外,云计算资源的使用情况与最终用户的成熟度也有很大的关系。刚刚接触云计算的用户,往往严重依赖于EBS(基于EBS的实例,使用EBS卷);但是当应用具备了云觉知(cloud-aware)能力之后,他们就习惯于使用实例仓库(instance-store)了。

3、准备物理设施(Prepare your Physical Infrastructure)

当我们用云计算资源使用量来定义负载时,我们就可以定位可能的性能瓶颈,并在此基础上准备必要的物理资源来承担这些负载。需要注意的是,某些类别的云计算资源可能同时对不同类别的物理资源都有需求。例如:基于EBS启动的实例可能同时对存储控制器(提供EBS服务)和网络(节点控制器需要调用远程的存储进行启动)都造成压力。

此外,我们还需要将进行某些操作所造成的负载考虑在内。例如,启动实例的时候节点控制器可能需要将虚拟机映像从Walrus服务拷贝到本地磁盘。这些操作可能会对网络(传输虚拟机映像的流量,虚拟机实例本身的流量)、Walrus服务(多个节点同时请求不同的虚拟机映像)、或者本地磁盘(实例的缓存、临时性存储)造成contention压力。

物理设施的准备工作对于私有云的可扩展性是至关重要的。如果不能够轻便地增加存储或者升级网络(或者重新配置网络),就无法根据负载需求对云服务进行动态扩容(除非是停止服务进行重新安装)。

4、部署实施(Deploy)

当物理设施准备停当之后,我们终于可以进行部署了。现在我们开始在对应的服务器上安装各个组件:云控制器(Cloud Controller,CLC)、Walrus、集群控制器(Cluster Controller,CC)、存储控制器(Storage Controller,SC)、节点控制器(Node Controller,NC)。通常来说,做这些事情花不了多少时间,半个小时总可以搞定了吧。当然,在一个配置有多个集群、高可用性、SAN存储的生产环境里面,部署时间还要更长些。

5、运营维护(Maintain)

当一朵云被部署完毕后,它就成了一个基础设施。因此我们需要保证它总是可用的,包括在升级(云管理软件、宿主机操作系统、路由器固件都需要在不关闭整体云服务的前提下进行升级)、失效(单台宿主机或者单个组件的失效不能够影响整体云服务,但是可以影响某些实例和某些请求)、扩容(增加节点、集群、存储、网络)、负载峰值(性能可以逐步恶化,但是不能崩溃)等等情况下。

如上所述各个步骤也可以在部署实施之后进行(你可能需要对有问题的负载进行采样,或者部署新的组件),但是它们依然属于维护的范畴。唯有如此,一个基础设施才能够有条不紊地提供服务,成为人们必不可少但又经常被忽视的一个部分。当一个基础设施存在的时间足够长之后,人们会认为这些服务是利索当然的,只有在出现问题或者是短缺的时候才会引起人们的注意(只有在断电的时候电网才会出现在新闻里)。也就是说,当你的云服务不再是可维护的时候,你就会出现在新闻里。

译者注:
翻译完这篇文章,突然想起最近关于AWS的新闻比较多呢。

使用AWS CLI操作Eucalyptus私有云

By , 2013年1月14日 9:01 下午

翻看Eucalyptus网站上的博客聚合页面,看到Andy Grimm最近写的一篇如何使用AWS CLI操作Eucalyptus私有云的帖子。按照Andy Grimm提供的教程快速地做了一遍,觉得这是个不错的工具,就顺手记录下来。这个帖子参考了Andy Grimm原的原文,但是并不是原文的一个中文翻译版。

原文地址:http://agrimmsreality.blogspot.com/2013/01/using-aws-cli-with-eucalyptus.html

[快速安装]

AWS CLI的安装非常简单。在Ubuntu下都只需要运行如下命令:

sudo apt-get install python-setuptools

sudo easy_install awscli

如果你有幸生活在伟大的防火墙以外的话,你可能不会遇到类似于下面的彩蛋。如果你不幸遇到下面的彩蛋,建议你先花点时间找释迦牟尼、默罕默德、救主耶稣谈谈心,或者找个移民中介帮你办理一些简单的手续。

Downloading http://argparse.googlecode.com/files/argparse-1.2.1.tar.gz
error: Download error for http://argparse.googlecode.com/files/argparse-1.2.1.tar.gz: [Errno 54] Connection reset by peer

[配置AWS帐号]

首先你需要在AWS有一个帐号,然后通过浏览器登录到http://aws.amazon.com/,点击右上角的“我的帐户/控制台”链接,然后在Security Crendentials部分找到你的Access Key ID和Secret Access Key。

创建一个新的配置文件~/aws_config.conf,内容如下:

[default]
aws_access_key_id = AWS_Access_Key_ID
aws_secret_access_key = AWS_Secret_Access_Key
region = us-east-1

将如上文件的属性设置为仅有所有者可读,例如0600。然后设置一个名为AWS_CONFIG_FILE的环境变量,该环境变量的值是如上所述配置文件的全路径,例如:

export AWS_CONFIG_FILE = ~/aws_config.conf

完成如上简单配置之后,可以用如下命令测试一下配置是否成功:

aws help

aws ec2 help

aws ec2 describe-instances

[配置Eucalyptus帐号] 

找到你的botocore安装目录,在Ubuntu 12.04 Server操作系统上,这个目录是/usr/local/lib/python2.7/dist-packages/botocore-0.4.2-py2.7.egg/botocore。在Mac OS X 10.8.2操作系统上,这个目录是/Library/Python/2.7/site-packages/botocore-0.4.2-py2.7.egg/botocore。进入该目录下的data/aws子目录,修改两个文件:

首先修改_regions.json文件,在region的定义最后增加一个条目:

“ecc”: {
“description”: “Eucalyptus Community Cloud”
}

然后修改_services.json文件,在ec2的regions部分的末尾增加一个条目:

“ecc”: “http://eucalyptus.ecc.eucalyptus.com:8773/services/Eucalyptus”

需要说明的是,上面这个设置中所提供的URL是针对桉树社区云服务的。如果您使用的是您自己的私有云,您需要根据您的私有云设置修改这个URL。

创建一个新的配置文件~/euca_config.conf,内容如下:

[default]
aws_access_key_id = EUCA_Access_Key_ID
aws_secret_access_key = EUCA_Secret_Access_Key
region = ecc

如上配置中的EUCA_Access_Key_ID和EUCA_Secret_Access_Key可以从您下载到的eucarc文件中获得。具体的方法可以参考使用桉树社区云服务(Eucalyptus Community Cloud)或者在Mac上安装euca2ools工具这两个链接。

重新设定AWS_CONFIG_FILE环境变量:

export AWS_CONFIG_FILE=~/euca_config.conf

完成如上简单配置之后,可以用如下命令测试一下配置是否成功:

aws ec2 describe-images

如果你需要在AWS和Eucalyptus之间进行切换,只需要重新设定AWS_CONFIG_FILE环境变量即可。(现在大家可以看出Eucalyptus与AWS相兼容的好处了吧。任何一个针对AWS开发的工具,经过简单的配置之后就可以用在Eucalyptus上。)

Panorama Theme by Themocracy