精华内容
下载资源
问答
  • 针对现有集群网络服务器负载平衡调度方案的不足 ,提出具有 TCP 连接容错功能的网络负载平衡调 度系统.该系统基于LinuxVirtualServer, 使用两个前端调度设备并行调度.两个调度设备使用同构网卡为客 户提供单一系统...
  • Spark集群容错场景介绍

    千次阅读 2016-08-26 16:53:25
    对于一个大的集群系统来说,机器故障、网络异常等都是很常见的,spark这样的大型分布式计算集群提供了很多的容错机制来提高整个系统的可用性,在接下来的部分中我们会讨论spark如应对各种模块异常 master异常...

    容错指的是一个系统在部分模块出现故障时还能否持续的对外提供服务,一个高可用的系统应该具有很高的容错性;对于一个大的集群系统来说,机器故障、网络异常等都是很常见的,spark这样的大型分布式计算集群提供了很多的容错机制来提高整个系统的可用性,在接下来的部分中我们会讨论spark如应对各种模块异常,参考的版本是spark1.5.1

    spark模块信息

    spark通信组件模型

    master异常退出

    spark中通过参数spark.deploy.recoveryMode来设置master的部署模型,主要有如下几种类型;

    • NONE:只有一个master
    • ZOOKEEPER:借助zookeeper实现具有自动切换的master集群
    • FILESYSTEM:只有一个maser,但是会持久化worker、application、driver的信息

    持久化信息指的是master将其他进程上报上来的环境信息,如worker的资源信息、application应用信息等;便于在master重启恢复期间通过MasterChanged的AKKA消息知会到相应的部件重新进行注册以便master获取相应的信息

    master异常退出后重启

    ZONE

    • 不影响退出之前已经提交的application的运行,但是在退出期间executor的资源释放、异常退出重新调度等功能会收到影响;
    • 新的应用无法继续提交
    • 重启成功后原来的已经创建的应用信息和driver信息不会重新上报的master,原有的worker依然会通过heartbeat心跳信息上报,worker检测到master的退出,会重新出发重新注册的请求RegisterWorker,但是上报上来的资源未去掉之前已经分配出去的资源(极可能是bug)

    ZOOKEEPER

    • active异常后,原先处于standby的会获取到znode的权限成为active节点,同时会进行recover操作加载持久层中的信息,知会到application、worker上报最新的信息到master;如果一段时间内未接受相应的response(超时时间由spark.worker.timeout指定),master会移除掉相应的进程信息,同时开启新一轮的schedule为需要的application分配executor
    • HA切换成功后,spark集群依然能对外提供服务,支持应用的提交和executor的调度

    worker异常

    worker异常关闭

    • CoarseGrainedExecutorBackend的WorkerWatch检测到和worker的连接断裂,触发其通过System.exit(0)关闭进程,具体代码如下
      override def onDisconnected(remoteAddress: RpcAddress): Unit = { 
      if (isWorker(remoteAddress)) {
      // This log message will never be seen
      logError(s"Lost connection to worker rpc endpoint $workerUrl. Exiting.")
      exitNonZero()
      }
      }
    • master检测到worker的连接断裂,移除掉内存中保存的worker信息以及application应用中保存的worker上的executor信息,移除掉persist中保存的worker信息(此处应该直接触发schdule为应用分配executor,源码中没有,疑似bug,具体可以参考Master.removeWorker方法)

    worker节点网络故障

    • 网络故障导致心跳长时间不上报给master,经过spark.worker.timeout时间后(默认是60s),master检测到worker异常,标识为DEAD状态,同时移除掉worker信息以及其上面的executor信息,跟上一节的处理逻辑类似,worker的信息依然会在页面上显示,直到超过时间(spark.dead.worker.persistence+1) * spark.worker.timeout后才将其彻底删除
    • CoarseGrainedExecutorBackend由于和worker的通信进程,不会有任何影响
    • 一段时间后网络恢复,worker成功发送心跳,master收到心跳后,未超过时间(spark.dead.worker.persistence+1) * spark.worker.timeout,知会worker重新进行注册;但是此时worker上的executor不会再一并上报上来

    executor异常退出

    • executor异常退出,如被kill -9,同机器上的worker进程的ExecutorRunner检测到executor进程的退出,触发ExecutorStateChanged 事件给worker,worker移除掉内存中保存的有关executor的信息,同时转发消息给master,master收到消息后,移除掉application对应的executor信息,同时开始新一轮的schedule为application分配新的executor

    application异常退出

    • application异常退出,CoarseGrainedExecutorBackend检测到后触发进程退出操作
    • master检测到和application的连接断裂,移除掉内存以及persist中保存的应用的信息
    展开全文
  • dkron, Dkron分布式,容错作业调度系统 http Dkron分发,容错作业调度系统 网站:http://dkron.io/Dkron是一个分布式的cron服务,易于设置和容错具有以下功能:轻松:易于使用的用户界面可靠:完全容错可以扩展:...
  • 在实际生产环境中,部署和实现具有一定负载均衡功能的MySQL服务器集群,对于提高用户数据库应用系统的性能、速度和稳定性具有明显的作用。本文简要介绍了在FreeBSD 7.0-Release系统上部署实现MySQL服务器集群的方案...

     

    摘要:MySQL是一个高速度、高性能、多线程的关系型数据库管理系统,适用平台多,可扩展性强。在实际生产环境中,部署和实现具有一定负载均衡功能的MySQL服务器 集群,对于提高用户数据库应用系统的性能、速度和稳定性具有明显的作用。本文简要介绍了在FreeBSD 7.0-Release系统上部署实现MySQL服务器 集群的方案,并对可能出现的问题提供了相应的解决方法。

        1. 引言

      MySQL是一个高速度、高性能、多线程、开放源代码,建立在客户/服务器(Client/Server)结构上的关系型数据库管理系统(RDBMS)。它始于1979年,最初是Michael Widenius为瑞典TcX公司创建的UNIREG数据库系统,当时的UNIREG没有SQL(Structured Query Language结构化查询语言)接口,限制了它的应用。1996年5月,Widenius开发出了MySQL的最初版本,开始在Internet上公开发行。MySQL的开发人员从一开始就一直关注它的性能,为此不惜特性集,直到今天,MySQL依然保持本色,以高速度高性能为首要原则。随着时间的推移,MySQL也加入了大型数据库产品的高级特性,如存储 过程、视图、触发器等,使其在企业级数据库系统中开始被部署应用[1]。2008年10月,SUN公司收购了MySQL AB公司,开始进入开源领域。随着重量级操作系统Solaris的开源,SUN MySQL在数据库市场占有的份额将会进一步提高。因此,在生产环境中部署具有负载均衡功能的MySQL服务器集群,对于提高企业数据库应用系统的速度、稳定性及可伸缩性具有很大的现实意义,也可以有效降低应用系统的投资成本。本文将以FreeBSD 7.0-Release操作系统为例,利用MySQL数据库的复制(Replication)特性,简要介绍部署MySQL服务器集群的实现方法和相关注意事项。

      2. 系统模型

      本集群的结构为一个主MySQL服务器(Master)服务器与多个从属MySQL服务器(Slave)建立复制(replication)连接,主服务器与从属服务器实现一定程度上的数据同步,多个从属服务器存储 相同的数据副本,实现数据冗余,提供容错功能。部署开发应用系统时,对数据库操作代码进行优化,将写操作(如UPDATE、INSERT)定向到主服务器,把大量的查询操作(SELECT)定向到从属服务器,实现集群的负载均衡功能。如果主服务器发生故障,从属服务器将转换角色成为主服务器,使应用系统为终端用户提供不间断的网络服务;主服务器恢复运行后,将其转换为从属服务器,存储数据库副本,继续对终端用户提供数据查询检索服务。

      3. 部署实现

      本文以一台主服务器带三台从属服务器为例,简要介绍MySQL服务器集群的实现方案和具体方法步骤。

      3.1 系统部署

      由于FreeBSD系统对机器硬件要求较低,出于降低系统部署成本考虑,主服务器和从属服务器操作系统均采用FreeBSD 7.0-Release,并采用最小化定制安装,完成以后系统占用磁盘空间仅为254M(不计swap分区所占空间,它随具体机器内存容量的变化而变化)。为充分发挥系统硬件性能,MySQL数据库采用源代码编译安装。

      3.1.1 安装FreeBSD系统

      在主服务器和从属服务器上安装FreeBSD 7.0-Release,具体安装方法步骤不是本文主要内容,在此略过,如有疑问可以参考FreeBSD系统手册。需要说明的是为方便用户系统运行期间的维护管理,要打开系统的SSH服务功能,系统安装配置期间允许root用户远程登录,正常运行以后要关闭root用户的远程登录功能。在/etc/ssh/sshd_config配置文件中对PermitRootLogin设置为yes为允许root用户远程登录到系统,设置为no即为不允许。修改保存文件后执行kill –HUP `cat /var/run/sshd.pid`命令即可重启sshd守护进程,使设置生效[2]。上述操作需要root用户权限。

     

          3.1.2 编译安装MySQL

      到MySQL的官方网站http://www.mysql.com 下载 MySQL数据库的安装源代码压缩包,本例下载 的是mysql-5.1.30.tar.gz,以root用户身份登录到系统,开始安装MySQL数据库系统。

      由于在对MySQL进行源代码编译安装时要求使用GNU的C编译器,而FreeBSD系统本身提供的不是该编译器,因此用户必须下载 安装GNU C编译器[3]。把下载的gnumake-3.81.tar.gz解压安装,按如下步骤即可安装GNU C编译器:

      [root@FreebsdMaster/softwares]# tar –zxvf gnumake-3.81.tar.gz

      [root@FreebsdMaster /softwares]# cd make-3.81

      [root@FreebsdMaster /softwares/make-3.81]# ./configure ; make; make install; make clean

      GNU C编译器默认安装到/usr/local/bin,在安装MySQL时按绝对路径调用make命令即可,如# /usr/local/bin/make。

      MySQL的编译安装比较复杂,具体操作及相关注意事项如下:

      (1). 解压mysql-5.1.30.tar.gz,并进行配置

      [root@FreebsdMaster /softwares]# tar –zxvf mysql-5.1.30.tar.gz

      [root@FreebsdMaster /softwares]# cd mysql-5.1.30

      [root@FreebsdMaster /softwares/mysql-5.1.30]# ./configure /

      -–prefix=/app/mysql5 -–with-charset=gb2312

      说明:MySQL默认的安装目录是/usr/local/mysql,为了增强系统部署的灵活性,紧贴用户应用系统实际情况,可以用—-prefix参数定制安装目录。--with-charset参数是使MySQL数据库支持中文gb2312字符集,如果需要支持其它字符集,使用--with-extra-charset参数,格式为—-with-extra-charset=CHARSET1,CHARSET2, … 。

      (2). 编译安装MySQL

      [root@FreebsdMaster /softwares/mysql-5.1.30]# /usr/local/bin/make

      [root@FreebsdMaster /softwares/mysql-5.1.30]# /usr/local/bin/make install

      [root@FreebsdMaster /softwares/ mysql-5.1.30]# /usr/local/bin/make clean

      注意一定要按绝对路径调用GNU C编译器,否则编译过程报错退出。

      (3). 为系统添加mysql用户组和用户

      [root@FreebsdMaster /]# pw group add mysql

      [root@FreebsdMaster /]# adduser

      FreeBSD系统没有groupadd命令,其添加用户组的命令是pw,添加用户命令adduser按系统提示操作即可完成。当然用 pw user add mysql命令也可以完成添加用户mysql的功能,但不如adduser命令功能完善。

      (4). 更改/app/mysql5目录及文件属性

      [root@FreebsdMaster /app]# chmod –R mysql mysql5

      [root@FreebsdMaster /app]# chgrp –R mysql mysql5

      说明:/app/mysql5为MySQL数据库系统所在目录,如果用户部署的应用系统数据量极大,可以将数据库系统目录设在大容量磁盘阵列上。磁盘阵列设置与具体机器硬件相关性很大,具体操作设置参考具体硬件系统说明和FreeBSD操作手册。不借助第三方软件,FreeBSD 7.0-Release系统可以配置RAID0、RAID1磁盘阵列。

      (5). 安装MySQL系统初始数据库

      [root@FreebsdMaster /softwares/ mysql-5.1.30]# ./scripts/mysql_install_db.sh --basedir=/app/mysql5 –-data-dir=/app/mysql5/data

      注意:必须考虑Unix系统的文件权限特性,首先给mysql_install_db.sh脚本添加可执行属性,否则安装脚本无法执行。执行chmod +x ./scripts/mysql_install_db.sh命令即可。参数--basedir=/app/mysql5和--datadir=/app/msyql5/data为必加参数,否则脚本运行报错退出,无法安装系统初始数据库mysql和测试 数据库test,mysql数据库包含系统权限设置表,没有这些表数据库服务进程mysqld将无法启动。

      (6). 再次更改/app/mysql5目录及其文件属性

      [root@FreebsdMaster /app]# chmod –R root mysql5

      [root@FreebsdMaster /app]# chmod –R mysql mysql5/data

      这样做是为了保证系统安全 ,防止通过MySQL系统漏洞的入侵行为。MySQL以mysql用户身份运行,对/data目录具有完全访问权限,对其它目录则只有系统管理员根据需要设置的访问权限,确保FreeBSD系统的安全 。这里需要特别提醒用户注意的是要确保mysqld文件(MySQL的守护进程,位于/app/mysql5/libexec目录下)没有设置setuid标志位,如果设置了该标志位,入侵者对其它文件就具有其不应有的权限。具体原因参考关于Unix系统安全的手册,本文对这个问题不再赘述。

      (7). 启动MySQL服务器

      上述操作全部完成以后,输入如下命令启动MySQL数据库服务守护进程:

      [root@FreebsdMaster /]# /app/mysql5/bin/mysqld_safe –user=mysql &

      --user参数表示以mysql用户身份运行MySQL数据库服务守护进程,“&”符号表示以后台方式运行。输入 netstat –an|grep 3306命令,如果看到下面的输出则表示MySQL5.1.30已在用户系统上编译安装成功。其中,3306是MySQL数据库系统默认的监听端口号。

      [root@FreebsdMaster /]# netstat –an|grep 3306

      tcp4 0 0 *.3306 *.* LISTEN

      按照同样方法与步骤在其它三台机器上安装FreeBSD 7.0-Release与MySQL5.1.30,为下面的MySQL服务器集群配置准备好系统平台基础。

     

     

          3.2 系统配置

      所有系统安装完毕之后,需要对它们做一些必要的配置方可按照用户预先设计的结构模型实现具有负载均衡功能的MySQL服务器集群。

      3.2.1 FreeBSD操作系统配置

      (1). 调整内核参数,优化操作系统性能

      因为是处于生产环境的服务器,投入正常运行之前一定要对内核参数进行必要的调整,提升系统性能,加强稳定性。简要说就是去掉不必要的硬件支持选项,使新内核占用更少的内存,加快启动速度。不同机器硬件系统差异很大,用户可根据具体系统的硬件情况不断调整试验,最终定制出最优化、最安全的FreeBSD系统。一定要屏蔽掉组合键Ctrl+Alt+Del的热重启功能,防止用户误按Ctrl+Alt+Del重启系统,引起数据库系统服务意外中断。在内核配置文件如MYKERNEL中加入:

      options SC_DISABLE_REBOOT

      重新编译系统内核,重启后即可屏蔽Ctrl+Alt+Del组合键的热重启功能。如何定制新内核及重新编译FreeBSD系统,用于可参考FreeBSD系统手册,此不赘述。

      (2). 进行其它设置,增强系统安全性

      用户可根据以下一般安全准则设置自己的FreeBSD系统。

      ·选择一个好的密码并予以妥善保护。

      ·对于敏感文件采用适当安全等级的加密算法进行加密。对于敏感级别不是很高的文件采用系统自带的crypt工具加密;对于敏感度极高的文件则使用专用加密工具,如PGP、GPG进行不对称加密,提高加密文件的防攻击能力。

      ·仔细设置文件访问权限,达到保护文件目的。

      ·保护好自己的.profile文件。恰当设置.profile文件的访问权限,确保只有自己能访问。

      ·仔细维护已设置setuid或setgid标志位的任何程序。

      ·禁止不加防范地离开已注册终端。任何时候都必须按常规正常退出系统,先执行clear清屏命令,防止其它用户看到操作痕迹,再执行exit命令退出终端。

      ·防范特洛伊木马程序。正确设置PATH变量的检索顺序,确保系统目录位于当前目录的前面。

      ·防范病毒的入侵。

      ·监控最近一次注册时间,确保没有他人盗用自己的帐号。

      特别提示:对于生产环境的服务器,一定要保证服务器的物理安全,安全措施再完善的系统,一旦被入侵者物理接触,所有的安全措施将形同虚设!

      Unix系统安全是一个很大的课题,本文只是提及了一些最肤浅的常识,具体内容用户可以参考相关书籍或网上资源。为确保Unix系统的配置具有高度的安全性,可以使用Internet安全中心(Center for Internet Security,CIS)提供的安全测试 工具Benchmarks或评估工具Scoring Tools,检验和监控系统配置的安全性 [4]。

      3.2.2 MySQL数据库系统配置

      为了能使上述系统实现一对多的主从复制(replication)和冗余机制,还需要对以上四个MySQL服务器进行一些必要的配置。

      (1). 配置主机名和IP地址

      本实现方案中把MySQL服务器Master主机名设为FreebsdMaster,IP地址配置为192.168.1.100,其它三台Slave依次设为FreebsdSlave1,192.168.1.101;FreebsdSlave2,192.168.1.102;FreebsdSlave3,IP地址192.168.1.103。

      (2). 设置root用户密码

      MySQL的root用户初始密码为空,为保证系统安全必须为root用户设置密码:

      [root@FreebsdMaster /]# /app/mysql5/bin/mysql –uroot –p

      Enter password:

      mysql>SET PASSWORD=PASSWORD(‘secret’);

      同Unix系统一样,输入密码时屏幕没有任何回显,进入系统后执行SET PASSWORD SQL语句设置或修改MySQL root用户密码。为使应用系统服务器远程连接到MySQL数据库服务器,除本地root用户以外,还要设置一个能从用户内部网络其它终端登录的root用户。具体操作如下:

      mysql>USE mysql;

      mysql>UPDATE user SET Host=’%’ WHERE Host=’hostname.yourdomain’ AND User=’root’;

      mysql>flush privileges;

      完成上述操作后应用系统服务器就可以连接到MySQL数据库服务器进行各种操作了,这个远程root用户的初始密码为空,用户需要从远程终端登录,为其设置密码。

      (3). 开启MySQL服务器的二进制更新日志功能

      上述MySQL服务器安装完成后,安装程序没有生成my.cnf配置文件,为此用户需要手工添加/etc/my.cnf文件。MySQL服务是由/app/myql5/libexec/mysqld提供的,其寻找my.cnf配置文件的默认顺序为/etc/my.cnf,~/.my.cnf,/usr/local/mysql/etc/my.cnf。启动ee编辑器,# ee /etc/my.cnf,在Master机器的配置文件写入如下内容:

      [mysqld]

      log-bin=mysql-master-bin

      server-id=1

      在其它三台Slave机器的配置文件/etc/my.cnf文件写入如下内容:

      [mysqld]

      server-id=int

      其中,int为一大于1且互不相等的正整数,如2,3,4等。务必要正确设置每个机器上的/etc/my.cnf配置文件,尤其是server-id不能有重复,这是一对多数据库复制能否成功的关键[5]!

      设定好上述/etc/my.cnf文件后启动Master上的MySQL数据库服务时就自动开启了二进制更新日志功能。在Slave上启动MySQL时要加上--log-bin参数,即可开启二进制更新日志功能。在Slave机器上启动MySQL服务的命令如下:

      # /app/mysql5/bin/mysqld_safe --user=mysql --log-bin &

      这样做的目的为了实现冗余容错功能。当主服务器Master出现故障停止服务时,在预转换角色成为Master的Slave上执行STOP SLAVE; RESET MASTER SQL语句,在其它两台Slave上执行CHANGE MASTER TO SQL语句,执行STOP SLAVE; RESET MASTER SQL语句的Slave服务器即转换成新的Master,其余两台机器则从新的Master复制数据库数据(复制的是更新UPDATE、INSERT等操作,并不是简单的copy),从而实现冗余容错。

     

          3.3 系统实现

      完成上述准备后可以开始实现MySQL数据库的一对多复制,对应用系统的数据库访问代码进行优化,使更新操作UPDATE、INSERT等SQL语句定向到Master服务器,查询检索SELECT语句定向到Slave服务器,从而实现负载均衡;当主服务器Master出现故障停止服务时,通过服务器角色转换实现冗余容错;上述所有服务器通过高速核心交换 机连接在一起,协同工作,提供集群(Cluster)性能。下面,本文就此举一简例,具体说明实现(Implementation)步骤。

      3.3.1 准备主服务器

      (1). 在主服务器上创建示例数据库repl_db

      从本地或远程终端登录到Master服务器,执行CREATE DATABASE repl_db;语句,创建示例数据库repl_db。建立表repl_table:

      mysql>CREATE TABLE repl_table (f1 INT, f2 VARCHAR(20)) ;

      向表中添加数据:

      mysql>INSERT INTO repl_table (f1, f2) VALUES(1, ‘first’);

      (2). 授予Slave复制(Replication)权限

      授予从属服务器Slave进行复制的权限。假设从属服务器连接到主服务器复制的用户名为“repl”,密码为“g00r002b”:

      mysql>GRANT REPLICATION SLAVE ON *.* TO repl@’%’ IDENTIFIED BY ‘g00r002b’;

      刷新系统权限表,锁定写入语句操作:

      mysql>FLUSH TABLES WITH READ LOCK;

      这时所有写入操作都被锁定,包括支持事务(Transaction)特性的InnoDB类型表的提交(COMMIT)操作也被锁定,为数据库初始复制(copy)做好准备。

      (3). 简单备份repl_db

      在此,通过tar命令把数据库初始数据备份到/tmp目录。

      # tar –cvf /tmp/mysql-data.tar /app/mysql5/data/repl_db

      (4). 记录主服务器状态

      执行SHOW MASTER STATUS 语句:

      mysql> SHOW MASTER STATUS;

      -------------------------------------+------------------+-----------------------+---------------------------+

      | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |

      +------------------------------------+------------------+-----------------------+--------------------------+

      | mysql-master-bin.000001 | 1027 | | |

      +------------------------------------+------------------+----------------------+---------------------------+

      记下File和Position两个参数的值,从属服务器Slave为了复制(replication)连接到主服务器Master时要用到这两个参数,如果参数与此不符将导致复制(replication)失败!

      (5). 释放主服务器表级写入锁定

      mysql>UNLOCK TABLES;

      至此,主服务器解除写入锁定,一对多复制准备工作已全部完成,准备接受Slave的复制(replication)连接。

      3.3.2 准备从属服务器

      (1). 停止从属服务器的MySQL数据库服务

      # /app/mysql5/bin/mysqladmin –uroot –p shutdown

      Enter password:

      输入MySQL系统root用户密码,MySQL服务停止。

      (2). 简单copy数据库初始数据

      在从属服务器上执行ftp操作,访问主服务器,下载/tmp/mysql-data.tar文件,在/app/mysql5/data目录下执行如下操作,把初始数据copy到Slave服务器:

      [root@FreebsdSlave1 /app/mysql5/data]# tar –xvf /tmp/msyql-data.tar

      其它两台Slave服务器执行同样操作,实现数据库初始数据的简单copy。

      (3). 重启从属服务器上的MySQL数据库服务

      # /app/mysql5/bin/mysqld_safe –-user=mysql –-log-bin &

      从属服务器已启动,同时启动二进制更新日志功能,为角色转换做好准备。

      (4). 登录到从属服务器Slave的MySQL客户端

      # /app/mysql/bin/msyql –uroot -p

      (5). 启动从属服务器上的复制(replication)线程

      mysql> CHANGE MASTER TO

      -> MASTER_HOST='192.168.1.100',

      -> MASTER_USER='repl',

      -> MASTER_PASSWORD='g00r002b',

      -> MASTER_LOG_FILE=' mysql-master-bin.000001',

      -> MASTER_LOG_POS=1027;

      Query OK, 0 rows affected (0.00 sec)

      mysql> START SLAVE;

      Query OK, 0 rows affected (0.00 sec)

      在所有从属服务器上执行相同的操作,自此从属服务器已连接到主服务器,开始真正意义上的replication工作。测试从属服务器的复制工作是否正常:

      mysql>show slave status/G

      ************************** 1. row ***************************

      Slave_IO_State: Waiting for master to send event

      Master_Host: 192.168.1.100

      Master_User: repl

      Master_Port: 3306

      Connect_Retry: 60

      Master_Log_File: mysql-master-bin.000001

      Read_Master_Log_Pos: 1027

      Relay_Log_File: FreebsdSlave1-relay-bin.000005

      Relay_Log_Pos: 251

      Relay_Master_Log_File: mysql-master-bin.000001

      Slave_IO_Running: Yes

      Slave_SQL_Running: Yes

      看到上述信息说明从属服务器已启动了与replication相关的线程I/O和SQL,一对多的replication已经开始工作。

      (6). 功能测试

      在主服务器上写入新的数据:

      mysql>INSERT INTO repl_table (f1, f2) VALUES(2, ‘second’);

      mysql>SELECT * FROM repl_table;

      +--------+---------+

      | f1 | f2 |

      +--------+----------+

      | 1 | first |

      | 2 | second |

      +-----=--+----------+

      2 rows in set (0.01 sec)

      在Slave上执行相同的查询操作:

      mysql>SELECT * FROM repl_table;

      +--------+---------+

      | f1 | f2 |

      +--------+----------+

      | 1 | first |

      | 2 | second |

      +--------+----------+

      2 rows in set (0.01 sec)

      得到相同的查询结果,说明复制(replication)机制已成功开始工作!

      3.3.3 配置网络DNS服务器

      在BIND DNS服务器中,为上述三台从属服务器Slave配置同一个名字,客户端的查询检索操作将由DNS服务器定向到其中的一台Slave。因此,对于同一名字,不同的客户端会定向到不同的地址,访问不同的MySQL服务器,从而达到负载均衡的目的。假设用户为三台Slave分配的DNS名字为mysqlslave.yourdomain,DNS服务器区域文件/var/named/yourdomain.zone中应包含如下数据项[6]:

      sqlmaster.yourdomain. IN A 192.168.1.100

      sqlslave1.yourdomain. IN A 192.168.1.101

      sqlslave2.yourdomain. IN A 192.168.1.102

      sqlslave3.yourdomain. IN A 192.168.1.103

      sqlslave IN CNAME sqlslave1

      sqlslave IN CNAME sqlslave2

      sqlslave IN CNAME sqlslave3

      当客户端进行查询操作时,提交给主机sqlslave.yourdomain的请求将由DNS服务器随机定向到三台Slave中的一台,由其执行查询作业,返回结果。从而在三台Slave之间实现查询级别的负载均衡。

      3.3.4 应用系统程序代码优化

      实际应用中,对数据库的写入操作相对查询操作少得多,因此,优化应用程序的数据库连接代码,把写入操作定向到Master服务器,查询操作定向到Slave服务器,提供主服务器和从属服务器之间更新、查询的负载均衡功能。本文以PHP数据库连接代码为例,简要介绍代码优化方法[7]。

      (1). 准备不同的数据库连接配置文件

      准备两个数据库连接文件mysql_connect_master.php和mysql_connect_slave.php,其文件内容如下:

      mysql_connect_master.php文件的内容:

     

      // Connect to the Database Server

      $linkID = @mysql_connect("sqlmaster.yourdomain", "user", "password") or die("Sorry, could not connect to the database!");

      // Select the Database

      @mysql_select_db("repl_db") or die("Sorry, Could not select database!");

      ?>

      mysql_connect_slave.php文件的内容:

     

      // Connect to the Database Server

      $linkID = @mysql_connect("sqlslave.yourdomain", "user", "password") or die("Sorry, could not connect to the database!");

      // Select the Database

      @mysql_select_db("repl_db") or die("Sorry, Could not select database!");

      ?>

      (2). 优化程序SQL语句代码

      对应用程序中访问数据库的代码段做出如下优化:

     

      ...

      // $sql is the query string to be committed to MySQL server.

      if ( stripos( $sql, " SELECT" ) )

      {

      include_once("./mysql_connect_slave.php");

      ...

      mysql_close();

      }

      else

      {

      include_once("./mysql_connect_master.php");

      ...

      mysql_close();

      }

      ...

      ?>

      说明:每当向MySQL服务器提交数据库操作时,加入一个if-else判断语句对变量$sql进行判断定向,如果是SELECT查询操作,将其定向到从属服务器Slave中的一个;如果是其它更新语句,则将其定向到主服务器Master。此处代码段是应用系统实现负载均衡的关键,用户务必根据自己实际情况,写出准确无误的代码。每次对数据库操作完毕都要及时释放数据库连接,以免更新、查询操作分别定向失败,影响系统负载均衡功能。这样做虽然在一定程度上增加Web服务器或应用服务器的开销,但与MySQL服务器集群负载均衡功能带来的大幅性能提升及冗余容错特性相比,这个开销绝对是物超所值!

     

          3.4 注意事项

      正确部署实现具有负载均衡功能的MySQL服务器集群必须注意以下事项:

      (1). MySQL数据库复制(replication)特性是核心

      此处的复制不是简单的copy,从属服务器启动两个线程(thread):I/O线程和SQL线程,I/O线程接收主服务器对参与复制数据库的更新操作事件(event),并记入自己的中继二进制更新日志文件(hostname-relay-bin.00000n),由SQL线程将更新操作写入自己的数据库表项。主从服务器之间复制的不是具体的数据内容,而是具体的以二进制格式记录的操作事件,因而在一定程度上实现主从服务器之间的数据同步。(这种复制类似于生物学意义上的按基因复制,在英语中replication的主要词义就是指该种复制。)

      (2). 复制的复杂性

      主从数据库服务器间的replication要求Master与Slave上的MySQL版本最好一致,主从服务器必须设置相同的字符集,否则很容易造成复制失败。主服务器上更新权限表内容的FLUSH语句不会被复制[8]。

      (3). 按照范式化要求设计数据库

      生产环境下基于MySQL服务器的应用系统要想稳定运行,按范式化设计系统数据库是基本要求,具体内容可参考相关书籍。

      (4). 打开数据库服务器的远程用户连接功能

      打开主从服务器的远程用户连接是实现更新、查询操作分别定向的必要条件,否则,来自应用服务器的连接请求失败,影响系统应用正常运行。

      (5). 负载均衡功能的实现需要良好的团队合作

      BIND DNS服务器实现了从属服务器Slave之间的负载均衡,Slave和Master之间的负载均衡则由应用系统开发人员在程序代码级实现。整个系统的性能提升和冗余容错需要网络管理和应用系统开发团队之间的良好合作,否则负载均衡功能的实现就会失败。

     

          4. 常见问题

      (1). 如何估算MySQL服务器集群的性能提升量?

      针对本文采用的结构模式,可对应用系统整体性能提升做出大致估算。假设应用系统写操作占10%,读操作占90%,写操作耗时是读操作的2倍,系统的吞吐量(throughput)为T(用reads/s读操作次数/秒来衡量)。把写操作线性转换为读操作,则有:

      T= 2Xwrites + 9Xwrites ==>writes=T/11① (不采用主从复制模式,读写操作集中到一个服务器上)

      T= 2Xwrites + 9Xwrites/N ==> writes=T/(2+9/N)② (采用一对多的主从复制模式,读操作在从属服务器,写操作在主服务器)

      其中,writes为系统单位时间内所能承受的最大写操作次数,N为从属服务器个数,N大于等于2。在不采用主从复制模式时,系统性能writes=T/11;采用本文一对三的复制模式时,系统性能writes=T/5。采用负载均衡模式与不采用系统性能之比为11:5,即2.2:1,考虑到应用服务器的额外开销,系统整体性能提升了整整1倍!从②式可以看出,系统整体性能理论极限为T/2,当然在实际生产环境中不可能达到。具体部署时用户可以根据自己的实际情况估算出合理的从属服务器数量,主要影响因素是网络带宽和机器整体性能[9]。

      (2). 如何应对主从服务器崩溃?

      当某台从属服务器崩溃时,修复故障重启后重新连接到主服务器,根据其master.info文件更新其数据,保持与主服务器的数据同步。如果主服务器崩溃,在某一从属服务器上执行STOP SLAVES; GRANT REPLICATION SLAVE ON *.* repl_db TO ‘repl’@’%’ IDENTIFIED BY ‘g00r002b’;RESET MASTER;这三个SQL语句,由于从属服务器已启动了二进制更新日志功能,因此具备了角色转换的必要条件。更改其主机名、IP地址及server-id与Master一样,重启MySQL服务器,系统开始正常对外提供服务。其它两台从属服务器则不需执行任何操作,继续执行replication过程。BIND DNS服务器和应用程序也不需做任何调整,继续对系统用户提供不间断服务。主服务器排除故障恢复正常后,将其网络配置改为与现有Master转换角色之前一样的配置,重启MySQL服务,将其角色转换为从属服务器。也就是说,整个集群机器的角色可以相互循环转换,提高系统的冗余性和可靠性。在此需要注意的是,在应用系统调试运行正常之后,在Slave角色服务器的/etc/my.cnf文件[mysqld]段加入slave-skip-errors=all,保证集群之间复制(replication)的正常运行。

      5. 结束语

      部署与实现具有负载均衡功能的MySQL服务器集群是一项复杂的系统工程,需要多方面良好的协同合作才能做好。服务器的搭建配置、BIND DNS服务器的配置部署,以及应用系统程序的开发都要紧紧围绕实现MySQL服务器集群负载均衡功能这个目标。必须对主服务器的运行状态进行动态监控,如果发生故障,立即执行角色转换过程,确保为终端用户提供可靠、不间断的服务。可以针对具体系统环境写出监控脚本或程序,确保系统的可靠性与稳定性。

    展开全文
  • 集群系统概述

    千次阅读 2012-04-04 11:33:06
    集群系统概述 1 引言 第一台计算机问世已经半个世纪了,在这期间计算机技术经历了五次更新换代。更新换代的标志主要有两个:一个是计算机的器件,另一个是系统体系结构。从第一代到第五代计算机,器件发生了...
     
    

    集群系统概述

    1 引言

    第一台计算机问世已经半个世纪了,在这期间计算机技术经历了五次更新换代。更新换代的标志主要有两个:一个是计算机的器件,另一个是系统体系结构。从第一代到第五代计算机,器件发生了根本的变化:从电子管、晶体管发展到集成电路,而集成电路又经小规模、中规模、大规模、非常大规模等阶段发展到超大规模阶段。系统体系结构的不断改进,许多重要的概念的不断提出并且得到实现,推动计算机技术向更高的层次发展。从早期的变址寄存器、通用寄存器、程序中断和I/O通道等概念,到 虚拟存储 器、Cache存储器、微程序设计、系列机、基于总线的多CPU系统、向量处理机等概念,发展到64位RISC处理器、基于MPP、NUMA、集群等体系结构的可伸缩并行处理系统,计算机系统技术也取得了突飞猛进的发展.

         随着计算机系统技术的突飞猛进, 高性能计算所采用的硬件设备也越来越先进, 经历了从向量计算机到并行计算机再到集群系统的过度, 当前, 集群系统在高性能计算领域越来越得到广泛的应用.

    2 集群系统

    对集群的研究起源于集群系统的良好的性能可扩展性(scalability)。提高CPU主频和总线带宽是最初提供计算机性能的主要手段。但是这一手段对系统性能的提供是有限的。接着人们通过增加CPU个数和内存容量来提高性能,于是出现了向量机,对称多处理机(SMP)等。但是当CPU的个数超过某一阈值,象SMP这些多处理机系统的可扩展性就变的极差。主要瓶颈在于CPU访问内存的带宽并不能随着CPU个数的增加而有效增长。与SMP相反,集群系统的性能随着CPU个数的增加几乎是线性变化的。

      集群集群技术可如下定义:一组相互独立的服务器在网络 中表现为单一的系统,并以单一系统的模式加以管理。 此单一系统为客户工作站提供高可靠性的服务。大多数模式下,集群中所有的计算机拥有一个共同的名称,集群内任一系统上运行的服务可被所有的网络客户所使用。集群必须可以协调管理各分离的组件的错误和失败,并可透明地向集群中加入组件。一个集群包含多台( 至少二台) 拥有共享数据存储 空间的服务器。任何一台服务器运行一个应用时,应用数据被存储在共享的数据空间内。 每台服务器的操作系统和应用程序文件存储在其各自的本地储存空间上。集群内各节点服务器通过一内部局域网相互通讯。当一台节点服务器发生故障时,这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。当一个应用服务发生故障时,应用服务将被重新启动或被另一台服务器接管。 当以上任一故障发生时,客户将能很快连接到新的应用服务上

    简单的说,集群就是一组计算机,它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点(node)。一个理想的集群是,用户从来不会意识到集群系统底层的节点,在他/她们看来,集群是一个系统,而非多个计算机系统。并且集群系统的管理员可以随意增加和删改集群系统的节点。

    集群可以划分为三方面:High-Availability(HA)(高可用性集群)、Load Balance(负载 均衡 集群)、Height Performance Computation(HPC)(高性能计算集群),严格来说,这些分类存在着一些交叉, 有一些文章将负载均衡集群划分到高可用性集群内,本文将集群划分为高性能计算集群和高可用性集群。

    2.1 高性能计算集群


         简单的说,高性能计算(High-Performance Computing)是计算机科学的一个分支,它致力于开发超级计算机,研究并行算法和开发相关软件。 高性能计算主要研究如下两类问题:
    1. 大规模科学问题,象天气预报、地形分析和生物制药等;
    2. 存储 和处理海量数据,象数据挖掘、图象处理和基因测序;
         高性能计算集群主要为高性能计算的需求而设计, 从并行任务间的关系角度来看可以分成以下几类


    1.高吞吐计算(High-throughput Computing)


        这类高性能计算,可以把它分成若干可以并行的子任务,而且各个子任务彼此间没有什么关联。象在家搜寻外星人(SETI@HOME -- Search for Extraterrestrial Intelligence at Home)就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上参加SETI的计算节点,计算节点在给定的数据上用给定的模式进行搜索,然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式,所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照Flynn的分类,高吞吐计算属于SIMD(Single Instruction/Multiple Data)的范畴。

    2.分布计算(Distributed Computing)


        另一类计算刚好和高吞吐计算相反,它们虽然可以给分成若干并行的子任务,但是子任务间联系很紧密,需要大量的数据交换 。按照Flynn的分类,分布式的高性能计算属于MIMD(Multiple Instruction/Multiple Data)的范畴。


    3. 高性能计算集群.

    高性能集群通过将多台机器连接起来同时处理复杂的计算问题。模拟星球附近的磁场、预测龙卷风的出现、定位石油资源的储藏地等情况都需要对大量的数据进行处理。传统的处理方法是使用超级计算机来完成计算工作,但是超级计算机的价格比较昂贵,而且可用性和可扩展性不够强,因此集群成为了高性能计算 领域瞩目的焦点。

    高性能计算 集群 ,英文原文为High Performance Computing Cluster,简称HPC Cluster,是指以提高科学计算能力为目的计算机集群技术。HPC Cluster是一种并行计算集群的实现方法。并行计算是指将一个应用程序分割成多块可以并行执行的部分并指定到多个处理器上执行的方法。目前的很多计算机系统可以支持SMP(对称多处理器)架构并通过进程调度机制进行并行处理,但是SMP技术的可扩展性是十分有限的,比如在目前的Intel架构上最多只可以扩展到8颗CPU。为了满足哪些"计算能力饥渴"的科学计算任务,并行计算集群的方法被引入到计算机界。著名的"深蓝"计算机就是并行计算集群的一种实现。
      由于在某些廉价而通用的计算平台(如Intel+Linux)上运行并行计算集群可以提供极佳的性能价格比,所以近年来这种解决方案 越来越受到用户的青睐。 比如壳牌石油(Shell )所使用的由IBM xSeries 服务器 组成的1024 节点的Linux HPC Cluster 是目前世界上计算能力最强的计算机之一。
      高性能计算 集群 向用户提供一个单一计算机的界面。前置计算机负责与用户交互,并在接受用户提交的计算任务后通过调度器程序将任务分配给各个计算节点执行;运行结束后通过前置计算机将结果返回给用户。程序运行过程中的进程间通信(IPC )通过专用网络 进行。
      高性能计算 集群 中使用的服务器通常可以分为用户节点、管理 节点、存贮节点和计算节点四种。它们的角色分别是:
      用户节点:
      提供用户界面的计算机。它从用户那里接受任务,运行调度器(在本地或独立的"控制节点"上)将任务分派到其它计算机,并将运算结果返回给用户。
      管理节点:
      提供管理功能的计算机。它应该能够使管理员从这一计算机对集群中的任意一台计算机进行监视和操作,并处理集群中所有计算机的日志和报警信息。
      存贮节点:
      提供存贮共享的计算机。为了使任务可以并行执行,每台执行任务的计算机必须能够访问同样的数据。存贮节点通过网络共享(NFS)或其它方式来确保数据访问的同步。
      计算节点:
      真正执行计算任务的计算机。集群中的大部分计算机都是这种类型。一个HPC Cluster中通常同时使用三个网络,它们分别是IPC网络,管理网络和存贮访问网络。根据具体的使用需求和选择的节点特性,这些网络可以使用多种介质和协议。
      IPC网络:
      用于并行任务执行时的进程间通信的专用网络,通常要求延迟小,带宽大。
      管理网络:
      用来收集集群信息、监视集群计算机和执行维护任务的网络。
      存贮访问网络:
      用来访问公用存贮的专用网络。

    下面主要介绍当前应用较多的Linux集群系统

    2.2.1 Beowulf

    1.Beowulf集群历史  
       在1994年夏季,Thomas Sterling和Don Becker在CESDIS(The Center of Excellence in Space Data and Information Sciences)用16个节点和以太网 组成了一个计算机集群系统,并将这个系统命名为Beowulf。Beowulf集群。Beowulf集群提供了一种使用COTS(Commodity off the shelf)硬件构造集群系统以满足特殊的计算需求的方法。这里的COTS是指象PC和以太网这种广为应用的标准设备,它们通常可以由多家厂商提供,所以通常有很高的性价比。Beowulf集群这种方法很快从NASA传遍了整个科研机构和社团。实际上,Beowulf集群现在已被人们看作高性能计算 中的一个分支或流派。
       因为几乎每个Beowulf集群的设计者都有自己的Beowulf集群的定义,恐怕很难给Beowulf集群下一个确切的定义。一些人认为只有那些采用和原始的Beowulf集群系统一样方法构建的系统才叫Beowulf集群。而另一些人则认为凡是能够在多个工作站上运行并行代码的系统都称为Beowulf集群。这里我们只是列举多数Beowulf集群具有的特征作为Beowulf集群的定义:
      Beowulf是一种系统结构,它使得多个计算机组成的系统能够用于并行计算。Beowulf系统通常有一个管理 节点和多个计算节点构成。它们通过以太网(或其他网络)连接。管理节点监控计算节点,通常也是计算节点的网关和控制终端。当然它通常也是集群系统文件服务器。在大型的集群系统中,由于特殊的需求,这些管理节点的功能也可能由多个节点分摊。
      Beowulf系统通常由最常见的硬件设备组成,例如,PC、以太网卡和以太网交换 机。Beowulf系统很少包含用户定制的特殊设备。
      Beowulf系统通常采用那些廉价且广为传播的软件,例如,Linux 操作系统、并行虚拟机(PVM)和消息传递接口(MPI)。
    2 .Beowulf集群的分类 
      
      由于一些特殊的目的如系统性能,有些Beowulf集群系统也采用一些用户定制的设备(它们通常由一家厂商提供)。为了区分这些特殊的系统,通常把Beowulf分为两大类:

    l  第一类Beowulf集群(CLASS I Beowulf)
      
      这一类Beowulf集群全部由COTS设备组成。第一类Beowulf系统的优点是:硬件设备由多个来源,通常具有廉价和易管理维护的特点。不依赖于单个硬件供应商,所有设备驱动都由Linux开发社团提供,通常都是标准设备,例如,SCSI、以太网等等
      当然第一类Beowulf集群的缺点也是非常显然的。由于所采用的硬件都没有经过性能优化,所以其很难达到很好的性能。比如,由于以太网的高延迟和低带宽使得集群系统中消息传递很难达到MIMD应用的需求,从而使整个集群系统的计算能力大打折扣。
     

    l  第二类Beowulf集群(CLASS II Beowulf)
      
      第二类Beowulf集群是指那些采用了用户定制设备的Beowulf集群。这类集群系统最大优点是具有很好的性能。例如,采用Myrinet作为集群系统的IPC网络可以极大地提供进程间消息传递延迟和速度。它的缺点就是依赖于单个硬件提供商而且价格高昂。

    3.Beowulf 集群硬件和网络 
      
      Beowulf 集群硬件和网络层次需要解决的问题是如何组织硬件使其达到最高的性价比。为了达到很好的性价比,Beowulf通常采用廉价的COTS硬件。当然有时为了提供某些关键的性能,也会使用一些特殊的设备。
      从硬件组织的角度说,Beowulf集群中的节点都是非共享内存的计算机,它们通过消息传递进行通信。实际上,我们还有其他组织硬件完成并行计算的方式。
      简单地说,有两种组织硬件完成并行计算的方法:
    (1)通过消息传递通信的本地内存(非共享内存)计算机系统 (Beowulf集群)
    (2)通过内存访问通信的共享内存计算机系统 (SMP计算机)
      当然也存在将多个本地或共享内存计算机相连并创造一个混和的共享内存计算机系统的可能。但在最终用户看来,这种计算机系统就好像一个大型的共享内存计算机。这种技术被我们叫做非一致内存访问NUMA(Non Uniform. Memory Access)。但是从底层说,一个NUMA计算机系统必须在节点间传递消息。
      当然也可以将共享内存计算机作为一个本地内存的计算机连入一个Beowulf集群系统。由于Linux系统 支持SMP计算机,所以Linux系统本身能够在SMP中的多个CPU上调度作业。所以Beowulf集群本身就没有必要识别集群的节点是不是共享内存计算机了。
      因为Beowulf集群采用消息传递完成并行程序间通信,所以网络传输成了系统的瓶颈。在实际的系统中,通常采用有两套彼此的独立的网络设备 。一套是普通的以太网,用于象系统管理和文件服务等普通的网络通信。另一套网络是用于进程间通信的高速网,象Myrinet和Giganet。和100M以太网相比,这类网络具有低延迟和高带宽的特性。
      还有三类设备虽然不是必须,但是对于集群管理却是非常重要的:
      KVM Swither:KVM是指Keyboard、Video和Mouse。这个设备可以让系统管理员 用一套KVM管理系统中的所有节点。
      远程电源管理设备(如ASM):这类设备使得管理员可以在管理节点Power on/off其他节点。
      Terminal Server:这种设备通过串口将节点连接起来。通过这个设备,管理员可以在管理节点上虚拟出其他节点上的控制终端。和KVM相比,这种方法不需要硬件的切换。
      
      Beowulf集群在软件层次面临的问题是如何在硬件层次上获得最大的性能。通常,Beowulf集群采用Linux+MPI的方式支持并行计算。MPI是采用消息传递的方式实现并行程序间通信。虽然也可以采用其他的通信方法,但是消息传递模式是最适合于集群系统的。简单地说,有两种在并行程序间传递并发的方法:
      使用处理器间的消息传递(MPI)
      使用操作系统的线程(Thread)
      其他的方法也存在,但是这两种方法应用得最广泛。 虽然存在效率和移植的问题,这两种方法都可以在SMP,NUMA 和Cluster 上实现。
      

    2.2.2 Platform LSF

    由platform公司开发的lsf 多集群系统使多个异构的计算机能够通过局域网或广域网共享计算资源,并能够为用户提供对资源的透明访问。Lsf现在主要支持以下三种大规模资源共享:

    1. 一个大企业中的多个部门,每个部门可以有一个或多个集群,这样就使得部门内部和部门之间可以共享资源。
    2. 较小部门的数据中心。大的昂贵的计算资源如超级计算机可以透明地与远方较小的部门直接进行共享。
    3. 通过松散连接的站点共享资源。

    Lsf将多个集群连接在一起,一个集群往往是企业中的一个部门,每个集群中有一个主控机,此主控机负责收集该集群系统中的各台主机的负载 信息,并且根据各主机的负载信息情况对作业进行调度。各个集群系统之间根据一定的策略进行资源共享。在每个主控机上定义了该集群能共享哪些集群系统中的资源。当用户发送了一个任务请求时,lsf系统能将此任务发送到对应的资源所在地,并根据调度策略选择负载较轻的机器对此任务进行处理。当多个用户请求同一个资源时,根据用户的请求优先级来确保优先级高的用户的紧急任务能首先得到满足。Lsf还具有以下特点:

    1. 提供了增强的计算能力。
      通过全局资源共享,用户可以访问各种各样的计算资源,许多闲置的计算机现在都可以充分利用起来进行任务处理,许多机器也可以并行地执行同一个任务,这样就大大增强了用户的计算能力。
    2. lsf提供了用户可配置的安全 策略。
      通过让用户使用RFC931协议、Kerberos、和DCE认证等策略,系统保证了远方的任务来自授权的用户。
    3. 每一个集群都是一个自治的系统。
      每个集群中的主控机的配置文件中记录了如下信息:如允许在多个集群系统之间传输的任务的数量与类型,允许在多个集群之间共享资源的用户名。
    4. 提供非共享的用户账号和文件系统。
      当任务在多个集群之间进行传输时,用户的账号可以根据配置文件进行映射。为了支持异构的系统,lsf通过在任务执行前后将文件在集群系统之间传递来提供对非共享的文件系统的支持。
    5. 良好的可扩展性。
      在单一的集群系统中通过主控机进行管理,所有的配置信息都在主控机上,多个集群系统之间信息的传递主要是与主控机有关,而与集群中的其它主机无关。因此lsf的集群能非常容易地扩展到成百甚至上千台。

    lsf系统支持多种操作系统平台。
    如主要的UNIX平台:Sun Solaris、 HP-UX、 IBM AIX、 Digital UNIX/Compaq Tru64 UNIX、SGI IRIX以及 Red hat Linux、 Windows NT、Windows 2000等。

    2.2.3 TurboCluster

    TurboCluster是一个企业级的集群方案 ,它允许在多个计算机上构建高可用的、可扩展的网络。它支持Intel和Alpha芯片,支持Linux 、Windows NT 和Solaris操作系统平台。使用TurboCluster系统可以显著地提高基于TCP/IP协议的多种网络服务的服务质量,这些服务包括Web、Mail、News和Ftp等。TurboCluster具有良好的可用性、可扩展性和可管理性,集群内部的实际服务器 的数量可以扩充到无限台。TurboCluster是一种基于软件的集群系统解决方案 ,它还能够支持异构的网络环境。

    当客户向集群系统发送一个请求时,该请求首先到达高级流量管理 器,高级流量管理器通过一定的调度策略将此请求转发到集群中的某一台实际服务器上对此请求进行处理,最终的回应请求将直接发送给客户。由于最终的回应请求没有通过高级浏览管理器而是直接发送给客户,这样大大减轻了高级浏览管理器上的负载,从而降低了瓶颈产生的可能。TurboCluster中采用的调度策略有:轮回(Round Robin)、加权轮回(Weighted Round Robin)、最少连接(Least Connection)。为了减少高级流量管理器产生失效的可能,TurboCluster为高级流量管理器准备了一个备份机。该备份机不断询问管理器来确认它正在正常工作,一旦发现主管理器已经失效,备份机将接替它继续工作。

    TurboCluster具有如下一些增强的性能。

    1. 通过heartbeat在备份机上监测流量管理器的运行状态来提供更高的可用性。
    2. 对不可预测的系统或应用程序的失效进行自动管理。
    3. 提供动态的负载平衡,它能够消除瓶颈并且处理峰值负载。
    4. 高级流量管理器只转发已经授权的请求,通过在实际的应用程序服务器的前端增加虚拟防火墙 来提高网络的安全性。
    5. TurboCluster对外只显现出流量管理器的IP,而集群系统中的实际服务器的IP地址对外界而言是不可见的。
    6. 当实际服务器正在对外界提供服务时就可以对它进行维护工作。

    Mosix集群

    实际上把Mosix集群放在高性能集群这一节是相当牵强的,但是和Beowulf等其他集群相比,Mosix集群确实是种非常特别的集群,它致力于在Linux系统上实现集群系统的单一系统映象SSI(Single System Image)。Mosix集群将网络上运行Linux的计算机连接成一个集群系统。系统自动均衡节点间的负载。因为Mosix是在Linux系统内核中实现的集群,所以用户态的应用程序不需要任何修改就可以在Mosix集群上运行。通常用户很少会注意到Linux和Mosix的差别。对于他来说,Mosix集群就是运行Linux的一台PC。尽管现在存在着不少的问题,Mosix始终是引人注目的集群系统。

    MOSIX为Linux核心增添了集群计算的功能。它支持的操作系统平台有BSD/OS 和Linux,它允许任意多个基于X86/Pentium的服务器和工作站协同工作。在MOSIX集群环境中,用户无需对应用程序进行修改,或将应用程序与库连接起来,或将应用程序分配到不同的节点上运行。MOSIX会自动将这些工作透明地交给别的节点来执行。

    MOSIX的核心是适应性的资源管理 算法,它对各节点的负载进行监测并做出相应的回应,从而提高所有进程的整体性能。它使用抢先的进程迁移方法来在各节点中分配和再分配进程,从而充分利用所有的资源。适应性的资源管理算法具体上又包括适应性的负载平衡算法、内存引导算法和文件I/O的优化算法。这些算法都对集群中的资源使用情况的变化做出响应。如:节点上的不平衡的负载分布或由于内存不足而导致的过多的磁盘换入换出。在这种情况下,MOSIX将进程从一个节点迁移到另外一个节点上,从而来均衡 负载或将进程迁移到有足够的内存空间的节点上。

    由于MOSIX是在Linux的核心中实现的,因此它的操作对应用程序而言是完全透明的。可以用它来定义不同的集群类型,这些集群中的机器可以相同也可以不同。

    与Turbocluster、Lsf等集群系统不同的是,MOSIX集群中的每个节点既是主节点又是服务节点,不存在主控节点。对于那些在本地节点创建的进程而言,该节点就是一个主节点;对于那些从远方节点迁移过来的进程而言,该节点就是服务节点。这意味着可以在任意时刻向集群中增加节点或从集群中删除节点,而不会对正在运行的进程产生不良的影响。MOSIX的另外一个特性就是它的监测算法能够监测每个节点的速度、负载、可用内存、IPC 以及I/O rate 。系统使用这些信息来决定将进程发送到哪个具体的节点上。当在某个节点上创建了一个进程以后,该进程就在这个节点上执行。当该节点的负载超过了一定的阀值以后,就将该进程透明地迁移到别的节点上继续执行。

    MOSIX文件系统采用直接文件系统访问的方法,它可以允许迁移到别的节点的进程在本地进行I/O操作。这样就减少了需要进行I/O操作的进程与创建该进程的节点之间的通讯,从而允许这些进程更加自由地在集群中的节点中进行迁移。MOSIX文件系统使所有节点都可以像访问本地文件系统一样透明地访问其它节点上的所有目录和文件。

    一个低端的MOSIX配置可以包含通过以太网连接起来的多台PC机。一个较大的配置可以包含通过快速以太网连接起来的多台工作站和服务器。高端的MOSIX配置可以包含通过Gigabit-Ethernet连接起来的多台SMP 或非SMP工作站和服务器。

    除了高性能科学计算,MOSIX提供了一个有趣的选项,用于以共同设置创建集群环境。通过使用服务器和工作站上的闲置资源,它可以更快更有效地创建和运行应用程序。由于访问了多台服务器,并且可以动态调整群集大小和更改负载均衡规则,它还可以提供高度的服务器可用性。MOSIX的不利之处是它更改Linux内核行为的一些核心部分,于是系统级应用程序将不会按期望运行。要使用网络应用程序时,而该程序使用基于单个服务器地址的套接字连接,MOSIX通常也会受到限制。这意味着网络应用程序在一个服务器节点上开始运行时,如果IP地址与套接字绑定,那么它必须继续在该节点上运行。显然,MOSIX还正在开始迁移套接字,因此这很快就变成了争论的焦点。

    2.2.5 EDDIE

    Eddie的主要目的是提供一些供那些进行重要任务处理的网站使用的工具,从而使这些网站能够提供持续的高级服务。Eddie创建了一个真正的分布式web服务器结构,它支持分布于不同的物理地点的web服务器。它的结构如图所示。

    下图所示的分布式服务器包含两个集群,它们分别是site 1 和site 2。每个集群都包含着一台域名服务器和若干台运行web服务器软件的实际的服务器。当用户敲入一个域名时,首先在Local DNS上对这个域名进行解析,找出与其对应的IP地址。如果Local DNS无法对这个域名进行解析,就将此域名发送到Authoritative DNS上,Authoritative DNS返回应该访问的服务器的IP地址,然后用户就可以访问指定的服务器上的内容了。


    Eddie 集群结构图 
      

    Eddie主要包含两个软件包:HTTP网关和增强的DNS服务器。如图5-2所示,在每个站点上增加一个新的服务器(即前端机),在其上运行HTTP网关来接受外界发来的请求并且将请求调度到合适的后端机上执行,DNS服务器上运行增强的DNS服务器软件,通过该软件可以在多个地理上分散的网址上均衡负载。

    Eddie主要有以下与众不同的特点:

    1. 提高了web服务器的吞吐量。通过提供强大的负载平衡能力,Eddie使用户可以充分利用分布式web服务器中的所有资源。主要在两个地方使用了负载平衡。首先后端机将本机上的负载信息如CPU负载、内存、磁盘延迟、运行队列数据以及页面错等信息发送给前端机,前端机根据负载轻重将外界请求发送到合适的服务器上。另外在增强DNS服务器软件中也提供了负载平衡的功能,前端机和后端机的综合负载信息都发送到Authoritative DNS服务器上,然后Local DNS可以根据各个Authoritative DNS上的负载的轻重来决定将域名解析的任务发送到哪一台Authoritative DNS上。这样就可以充分利用分布式服务器环境中的所有资源,增强了web服务器的吞吐量。
    2. 提供很好的服务质量。首先Eddie通过使用静态和动态负载平衡策略提高了web服务器的吞吐量,减少了用户请求的响应时间;其次,当用户发一个请求时,系统就要检查是否来自该用户的连接已经存在,如果存在,就将请求继续发送到上次对该请求提供服务的服务器上,这样就保证了用户对web访问的持续性。如果没有足够的资源,则将用户请求加入等待队列,并且告诉用户它的请求要等待一会儿才会被处理。
       Eddie 功能结构图 

     

    2.2.6 Windows® Compute Cluster Server™ 2003

    Windows Compute Cluster Server™由两部分组成。第一部分是Windows Server 2003 Compute Cluster Edition(CCE),它是一种源自Windows Server 2003(标准x64版本)的64位操作系统。第二部分是Microsoft Compute Cluster Pack(CCP),它可以提供集群部署和管理工具,包括:作业调度工具、MPI以及用来管理集群节点和任务的控制台与界面。这些工具可与当前的Windows基础设施相集成,例如,可使用活动目录(Active Directory)管理用户和安全 性,集群管理控制台可利用微软管理控制台(Microsoft Management Console)等。Cluster Pack还能够与支持MPI、并行调试以及OpenMP的Visual Studio 2005协同工作。 作为HP统一集群产品组合一部分的Windows Compute Cluster Server 2003可用于HP集群平台3000和4000系统,以及集群平台4000刀片服务器系统。 HP消息传送接口(HP-MPI)是领先的MPI标准实施,对于创建和移植并行应用至关重要,而且已被计划移植到Windows产品中。另外,惠普和微软还将与软件提供商紧密合作,共同实现64位应用到Windows Computer Cluster Server 2003的移植和优化。

     

     

     

     

    2.2. 7 Windows HPC Server 2008

    Windows HPC Server 2008将是现有Windows Computer Cluster Server 2003的继任者,基于Windows Server 2008 64-bit系统核心,因此不支持32位和IA64架构硬件。无疑,新的命名方式意味着微软已经做好了准备,有信心迎接最艰苦的HPC工作量考验。

      Windows HPC Server 2008将提供新的高速网络、高效灵活的集群管理工具、面向服务的体系结构(SOA)工程进度安排、支持合作伙伴的集群文件系统,可用于计算流体力学、水利枢纽模拟等大规模并行项目,或者BLAST、蒙特卡罗模拟等复杂的并行项目。

      Altair Engineering Inc.、Cluster Resources Inc.、Platform Computing等多家相关行业企业都已宣布支持Windows HPC Server 2008,而Panasas、Quantum Corp StorNext、HP PolyServe、Sanbolic的集群文件系统均得到该系统的支持,IBM的IBM GPFS也将在不久后加入这一行列。

      在美国内布拉斯加大学PKI研究院的计算中心内,Windows HPC Server 2008已经被部署在一套拥有1151个节点的大型集群上,为政府、科研和工业用户提供服务。爱荷华大学、剑桥大学、3M、Baker Hughes Inc.(石油服务公司)也都已经着手部署这套系统。

     

    2.2.8 其它集群

    Legion


      Legion 试图构建一个真正的多计算机系统。这是一个群集,其中每个节点都是一个独立系统,但在用户看来,整个系统只是一台计算机。Legion 设计成支持一台世界范围的计算机,由上百万个主机以及数以万亿计的软件对象组成。在Legion 中,用户可以创立他们自己的合作小组。
      Legion提供了高性能并行、负载均衡、分布式数据管理和容错性。它通过其容错管理和成员节点间的动态重新配置来支持高可用性。它还有一个可扩充核心,该核心可以在出现新的改进和进展时动态替换或升级。系统并不是只接受单一控制,而是可以由任意数量的组织管理,而每个组织都支持整体的自治部分。Legion API通过其内置的并行性提供了高性能计算 。
      Legion需要使用特别编写的软件,以使它可以使用其API库。它位于用户计算机操作系统之上,协调本地资源和分布式资源。它自动处理资源调度和安全 性,还管理上下文空间以描述和访问整个系统中上亿种可能之外的对象。然而,在每个节点上运行时,不需要使用系统管理员特权,并且可以使用无特权的用户帐号进行工作。 这将增加加入Legion 的节点和用户的灵活性。

    Cplant


      Sandia National Lab中的Computational Plant是一个大规模整体并行群集,用于实现TeraFLOP(万亿次浮点运算)计算并构建在商业组件上。整个系统由“可伸缩单元”组成,这些“可伸缩单元”可以划分成适合不同目的(计算、磁盘I/O、网络I/O、服务管理)。群集中的每个节点都是一个Linux系统,带有专门开发的、提供分区服务的内核级模块。每个分区的功能可以通过装入和卸载内核级模块来修改。

      项目分三个阶段完成,开始阶段是原型,有128个基于433-MHz DEC Alpha 21164的系统,其中每个都有192 MB RAM和2 GB驱动器,相互之间用Myrinet网卡和8-端口的SAN交换机连接。第1阶段将它扩充为400个基于21164的工作站,这些工作站的运行速度为500 MHz,有192 MB RAM,没有存储 器,用16-端口的SAN交换机以超立方体结构连接起来,并且运行Red Hat 5.1。当前的第2阶段有592台基于DEC 21264的机器,它们的运行速度为500 MHz,有256 MB RAM,没有驱动器。每个节点都使用64-位,33-MHz PCI Myrinet网卡,并且仍使用16-端口交换机以超立方体结构连接。

      在Cplant上运行的应用程序包括解决稀疏线性系统、流体力学和结构力学中计算系统的优化、分子力学的模拟、线性结构力学的有限元分析,以及并行应用程序的动态负载均衡库。

    JESSICA 2


      香港大学的系统研究小组有一个基于Java的群集,叫做支持Java的单系统映像计算体系结构(JESSICA),它作为一个中间件层以完成单系统映像的幻想。该层是每个使用分布式共享内存(DSM)系统进行通信的节点上运行的所有线程的一个全局线程空间。该项目使用ThreadMark DSM,但最终将用他们自己创建的JiaJia Using Migrating-home Protocol (JUMP)。他们使用定制的基于Java的ClusterProbe软件来管理群集的50个节点。

    PARIS


      法国的IRISA研究所的“大规模数字模拟应用程序的编程并行和分布式系统”(PARIS)项目提供了几种用于创建Linux服务器群集的工具。该项目由三部分组成:群集的资源管理软件、并行编程语言的运行时环境,以及分布式数字模拟的软件工具。

      资源管理软件包括用于共享内存、磁盘和处理器资源的Globelins分布式系统,及其Dupleix和Mome分布式共享内存系统。

    资源管理软件包括用于共享内存、磁盘和处理器资源的 Globelins 分布式系统,及其 Dupleix 和 Mome 分布式共享内存系统。

        负载均衡群集负载均衡群集在多节点之间分发网络或计算处理负载。在这种情况下,区别在于缺少跨节点运行的单并行程序。大多数情况下,那种群集中的每个节点都是运行单独软件的独立系统。但是,不管是在节点之间进行直接通信,还是通过中央负载均衡服务器来控制每个节点的负载,在节点之间都有一种公共关系。通常,使用特定的算法来分发该负载。

    网络流量负载均衡是一个过程,它检查到某个群集的入网流量,然后将流量分发到各个节点以进行适当处理。它最适合大型网络应用程序,如 Web 或 FTP 服务器。负载均衡网络应用服务要求群集软件检查每个节点的当前负载,并确定哪些节点可以接受新的作业。这最适合运行如数据分析等串行和批处理作业。 那些系统还可以配置成关注某特定节点的硬件或操作系统功能:这样,群集中的节点就没有必要是一致的。

     

    EnFuzion

    EnFuzion 是 TurboLinux 推出的科学群集产品,它并不基于 Beowulf。但是,它可以支持上百个节点以及许多不同的非 Linux 平台,包括 Solaris、Windows NT、HP-UX、IBM AIX、SGI Irix 和 Tru64。EnFuzion支持在节点之间实现自动负载均衡和资源共享,而且可以自动重新安排失败的作业。EnFuzion 非常有趣,因为它运行所有现有软件,并且不需要为环境编写定制的并行应用程序。它支持在节点间实现自动负载均衡和资源共享,而且可以自动重新安排失败的作业。

     

    2.2 高可用性集群

    高可用性(HA)群集致力于使服务器系统的运行速度和响应速度尽可能快。它们经常使用在多台机器上运行的冗余节点和服务,用来相互跟踪。有许多应用程序都必须一天二十四小时地不停运转,如所有的web服务器、工业控制器、ATM、远程通讯转接器、医学与军事监测仪以及股票处理机等。对这些应用程序而言,暂时的停机都会导致数据的丢失和灾难性的后果。如果某个节点失败,它的替补将在几秒钟或更短时间内接管它的职责。因此,对于用户而言,群集永远不会停机。
      某些HA群集也可以维护节点间冗余应用程序。因此,用户的应用程序将继续运行,即使他或她使用的节点出了故障。正在运行的应用程序会在几秒之内迁移到另一个节点,而所有用户只会察觉到响应稍微慢了一点。但是,这种应用程序级冗余要求将软件设计成具有群集意识的,并且知道节点失败时应该做什么。但对于Linux,大多数现在还做不到。因为Linux系统没有HA集群标准,并且也没有公共API可供应用程序开发者构建有群集意识的软件。
      HA群集可以执行负载均衡,但通常主服务器运行作业,而系统使辅助服务器保持闲置。辅助服务器通常是主服务器操作系统设置的镜像,尽管硬件本身稍有不同。辅助节点对主服务器进行活动监控或心跳观察,以查看它是否仍在运行。如果心跳计时器没有接收到主服务器的响应,则辅助节点将接管网络和系统身份(如果是Linux系统,则是IP主机名和地址)。但是,Linux在这一领域仍有一点忽略。

    高可用集群通常有两种工作方式:

    容错系统:通常是主从服务器 方式。从服务器检测主服务器的状态,当主服务工作正常时,从服务器并不提供服务。但是一旦主服务器失效,从服务器就开始代替主服务器向客户提供服务。
    负载均衡 系统:集群中所有的节点都处于活动状态,它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型

    下面列举出市场上主要的HA集群.

     

    2.2.1 Apptime .Watchdog 3.0

      Wizard公司建立于1992年,2000年改名为Apptime。Watch-dog3.0是该公司出品的高可用及负载平衡集群产品。Watch-dog在1999年移植到linux平台上。Watch-dog Light是Watch-dog的简化版,只能支持两个节点和一个应用服务。 在Watch-dog 3.0 中数据是不能够并发访问的,每个需要数据访问的应用服务只能单独访问数据,数据在被访问期间锁定,这就避免了并发访问可能造成的冲突。

      当一个提供服务的节点需要更新时,系统管理员可以手动的在该节点上执行failover,Watch-dog 3.0 linux版本不需要改动内核,该产品适用于Red Hat, SuSE, Debian, FreeBSD,Windows NT/2000, Solaris, HP-UX, IRIX, AIX以及Tru64 UNIX.,起价为每节点1000美元,Watch-dog Light起价为每节点250美元,其用户范围包括ISP,ASP,电信运营商,电子商务等。

      下面列出了Watch-dog 3.0最重要的特点:

      1. 最多可支持32,000 个节点

      2. 一个SNMP 网关

      3 . 支持多种应用服务,包括MySQL, Oracle, Sybase, Informix, SQL Server,Samba, sendmail等

      4 . 简单的管理工具

      5 . 支持多种平台的真实服务器,包括Windows NT/2000 以及 Solaris

      Apptime的集群管理软件包含了基于X500或LDAP的分布式集群管理以及基于HTTP/XML的远程检测和管理。

     

    2.2.2 Hewlett-Packard MC/ServiceGuard

      Hewlett-Packard带来的产品是MC/ServiceGuard,它原是基于HP-UX的高可用集群产品,移植到linux平台后仍然保持了其优良的功能。MC/ServiceGuard的高可用性已经得到了验证,在UNIX环境下已经售出了超过45000份许可证。MC/ServiceGuard构成了其他HP的高可用性解决方案的基础。包括了多种容错方案(Campus Cluster, MetroCluster Continental-Clusters)

    MC/ServiceGuard和linux内核有着紧密的联系。HP的即将开放源码的Watchdog记时驱动器已经和linux内核紧密结合在了一起。MC/ServiceGuard的初期版本最多支持4个节点,预计在后续版本中会增加到16个。MC/ServiceGuard在开始阶段会安装在HP的基于intel芯片的网络服务器中,之后也会运行在基于RISC处理器的服务器上。集群中的每个节点都是对等的,每个节点提供一个或多个应用,当一个节点失效时,该节点上的应用自动转移到集群中的其他节点上去。该应用所对应的ip地址也被移动到相同的节点上去,所以客户可以使用同样的机器名或ip地址进行连接。

      HP的目标是那些需要在数据库以及应用层保护其关键任务的企业应用。 HP同时与SAP及其他公司合作以提供ERP领域中的机群解决方案。MC/ServiceGuard的价格还没有最后制订,在HP-UX平台下的MC/ServiceGuard有三个定价方法,基于每节点的;基于功能的和基于每处理器的。

      MC/ServiceGuard的重要特点有:

      1. 对于错误的快速监测和快速恢复。

      2. 在系统软硬件维护期间仍然保持应用的有效性。

      3. 在线重配置

      4. 可伸缩的负载平衡机制

      5. 应用程序不需为支持高可用性而做任何修改

      6 . 数据保护

      MC/ServiceGuard 管理及监控软件、硬件以及网络的故障,故障的检测和恢复过程是完全自动的,不需要管理员的介入。应用包可以通过几个简单的命令从一个节点移动到另一个节点。允许集群中一个节点的定期维护,同时其他节点继续工作。当该节点的维护完成后再重新加入集群。同样也允许改变节点的操作系统。

      MC/ServiceGuard拥有新的在线重配置功能,可以在系统运行时改变集群的配置。 该功能允许用户增减应用包,修改应用的属性,修改整个包,与此同时集群和其他的应用仍在运行。也允许用户在线增减节点。节点失效后,在该节点上的不同应用可以被转移到不同的新节点上去。工作量也被分配到其他的节点上。分配工作量使失效对集群的影响减少到最小。

     

    2.2.3 Legato Systems Legato Cluster

      Legato是一家在企业级存储管理软件方面处于领先地位的公司。该公司使用集群技术以提高数据和应用的可用性。Legato Cluster是该公司一系列产品的名字,该系列产品的主要组成部分是Legato Cluste Enterprise,它包含了基本的集群技术,而解决方案包则是在Legato Cluste Enterprise的基础上加上几个附加的模块,Legato eCluster是一个解决方案包,它包含了Cluster Enterprise的几个征对Apache、Netscape以及HTTP 性能检测而添加的附加模块。Legato eCluster必须有web服务器的支持。

      Legato的集群产品不公开源码,但他们提供了一个完整的perl开发环境以支持开放源码研究。Legato 的集群产品于2000年4月移植到linux平台上。Legato Cluster Enterprise不需要改变linux内核,而且没有服务器数量的限制,这意味着用户可以根据应用环境的需要部署尽可能多的服务器。

      Legato Cluster产品(Legato Cluster Enterprise和Legato eCluster)的主要特性有:

      1. 单一的配置界面,使管理和重配置大型的集群变得更容易。

      2. 没有服务器数量的限制,这对于有数百个web 服务器的商业环境来说非常重要。

      3 . 支持多种平台,包括Linux ,Unix 和Windows NT/2000

      4 . 提供一个perl开发环境,允许在Legato Cluster架构上开发开放源码的集群解决方案。以及根据特定的应用定制解决方案。

      5 . Legato Cluster提供对Apache的支持模块。

      6 . 支持TCP/IP,允许通过LAN或WAN连接。

      Legato eCluster的目标是使用ip层负载平衡解决方案的用户。ip层负载平衡通过一个director将对指定ip地址的访问请求分配到所有运行Legato eCluster软件的web服务器上。 如果服务失效,Legato eCluster 重启该服务或将机器标识,ip 地址,web 服务都转移到另一台备用机器上,然后将服务与内容连接起来。内容可以存放在SAN, NAS, NFS或本地硬盘上。如果内容的一个拷贝失效,则通过网络将服务与内容的第二份拷贝连接起来。

      Legato Cluster通过对服务器的隔离检测提供数据完整性,隔离检测提供一种机制以使Legato Cluster的节点可以检测自己是否与集群中的其他节点隔离。其主要的目的是防止两个节点都认为对方已失效,而同时向同一块磁盘空间中写入数据。

      Legato Cluster防止对数据的并发访问,任何一个时刻只有一个服务器能够对一个特定的磁盘区域进行写操作。Legato Cluster没有提供复制数据的功能,该功能需由第三方提供.

      Legato Cluster提供一个单一的配置界面,管理员可以对整个集群进行配置而不用对每个节点逐一进行配置。

     

    2.2.4 Mission Critical Linux Convolo

      Mission Critical Linux公司提供专业的linux应用服务以及咨询服务。Mission Critical Linux提供的服务包括预配置的集群解决方案;安全服务技术(SST)提供对系统的安全的远程管理,检测,更新;Crash Analysis套件提供系统core dump的能力。Convolo是Mission Critical Linux公司提供的两个节点的linux集群产品。该产品基于Mission Critical Linux公司的开放源代码的Kimberlite技术,遵循GPL。Convolo满足了商业用户对于高可用性以及数据完整性的要求。Convolo在2000年7月开始发售,售价为每节点995美元。

    Convolo 由一个有多年企业集群开发经验的开发小组做基于linux 的开发,其他大多数的高可用产品都是从unix 平台移植而来的。Convolo适用于所有主要的linux发行版本以及IA-32 及IA-64结构。

      Convolo的目标是那些需要高可用性的数据库以及提供动态内容的基础的internet服务提供商;需要高可用性的文件服务器、邮件服务器、数据库的企业用户以及定制服务的用户。

      下面是Convolo的主要特征:

      1. 开放源码

      2. 共享的存储结构,支持SCSI和Fibre Channel,任何节点都能直接访问

    所有的共享磁盘。

    3. 与linux 的版本及硬件平台无关

    4. 支持多种应用,包括Oracle, Sendmail,MySQL, NFS等

       Convolo 被设计为在大范围的系统失效后仍然能够保持数据的完整性。在Convolo的设计中包含了对通过SCSI 或Fibre Channel总线互连的磁盘共享的支持。多个节点可以同时访问存储在共享磁盘分区上的文件以得到集群的配置和状态信息,同时过程锁定机制使在一个时间内只有一个节点能修改这些信息。Convolo没有使用DLM来控制对数据的访问,所以在一个时间内只有一个节点能运行一个指定的服务及访问该服务的数据,如果该节点失效,服务及对服务数据的访问移动到另一个节点上

      为了保证数据的完整性,在Convolo 1.2中提供了整个NFS的failover功能,包括了NFS锁定协议以及一系列的鉴定机制。

    Convolo包括了一个基于web的GUI管理工具和一个命令行管理工具,简单的安装/配置脚本,以及完整的文档。

    2.2.5 PolyServe Understudy and LocalCluster

      PolyServe公司提供了两个系列的linux集群产品。第一个系统现在已经发售,它包含了failover以及应用恢复特性,其目标是中小型的互连网应用,例如web服务器、防火墙、VPN、代理服务器、FTP服务器等。第二个系列现在还在开发中。 它提供了一系列完整的工具以支持大型的互联网应用。

      第一个系列的产品包括Understudy 和LocalCluster Understudy是一个两节点的高可用性及负载均衡的集群产品,从1999年11月开始发售,

    Understudy是一个低价的纯软件解决方案。Understudy要求集群中节点的数据各自独立,节点要部署在同一个子网中。Understudy不提供数据复制的功能,所以节点的数据需要手工更新。

      LocalCluster是一个支持多节点的产品,于2000年9月开始发售。LocalCluster是一个真正的分布式解决方案,所有节点都是平等的。LocalCluster能够在节点之间复制web数据。因为数据复制到集群中所有节点上,所以当一个失效的节点恢复后,其数据会自动的更新。现在LocalCluster还不能复制数据库或动态的web内容 PolyServe的所有产品都使用了组通信技术。该技术提供了一个可复制的、可为整个集群进行配置的数据库。允许管理员管理整个集群而不是为每个节点修改配置。

      Understudy 以及其他PolyServe的集群产品可以运行Linux,FreeBSD/BSD, Windows NT/2000, 和Solaris上。PolyServe使其产品尽可能不受linux内核改变的影响,PolyServe支持多种linux发行版本,包括Red Hat, SuSE, Debian, Slackware等。

      下面介绍PolyServe系列集群产品的主要特点:

      1. 扩展能力:一个集群可以扩展到128 个节点,还可以由多个子集群构成一

    个可以容纳数千个节点的集群。

      2. 集群文件系统:由物理上的共享存储器所构成的可并发访问的文件系统。

      3. 对整个集群的配置工具

      4. 可以指定节点在failover 时的优先级,一个节点上不同的服务可以被转

    移到不同的备份节点上。

      5. 多系统的管理能力,可管理用户,打印机,安全,应用等,可在一个控制

    台下管理单一系统,子集群或整个集群。

      PolyServe 未来的集群产品将是一个共享的SSI 集群,其目标是互联网数据中心、ASP 、ISP 电子商务站点、以及内容提供商。产品的名称和细节将在2001年公布。

     

    2.2.6 Red Hat High Availability Server

        Red Hat是在世界范围内领先的linux发行商,占据50%以上的市场份额。Red Hat High出品的High Availability Server是一项开放源码的集群技术,提供动态负载平衡以及TCP/IP,UDP服务的failover支持。High Availability Server在2000年6月开始出售,两节点的负载平衡集群售价为1995美元。这个价格包含了技术支持,包括一年内的通过电话或web进行的安装和配置的支持,之后可以以每节点995美元的价格添加节点。

      High Availability Server基于Red Hat linux 6.2,它支持与其他的linux版本,Solaris, 及Windows NT/2000组成一个异构的网络环境。

      High Availability Server的目标是web服务器、FTP服务器、邮件网关、防火墙等需要负载平衡和高可用性的基于ip的应用。

      High Availability Server最主要的特点有

      1. 开放源码的发行版

      2. 简单的安装

      3. 高性能以及高伸缩性

      4. 高适应性

      5. 增强的安全性

      6 . 易管理性

      High Availability Server需要对linux内核做一些修改,所有的改变都是开放源码的。

      一个专门的安装程序负责安装集群所需要的软件包,节点的数量只取决于用户的硬件和网络环境。High Availability Server为web服务器提供了增强的安全性,为那些在开放的网络环境下工作的web服务器提供了增强的安全配置。

      High Availability Server可以被配置为FOS和LVS两种工作模式,在FOS模式下,系统被配置为两个节点的热备份集群,为应用提供冗余。在LVS模式下,系统被配置为一个多节点的集群,其中包含两个负责负载平衡的服务器,它们负责将用户的请求定向到一个或多个基于ip的服务上,负载平衡的算法有轮转调度,加权轮转调度,最小连接调度和加权最小连接调度四种,负载均衡技术有网络地址转换,Ip隧道和直接路由三种。

    2.2.7 SGI Linux FailSafe

      SGI 有两个集群产品,ACE和FailSafe。 ACE 是研发性质的技术,而FailSafe 是已经推向市场的集群技术。在本文中只介绍FailSafe技术。FailSafe于1995年发布,运行在SGI的IRIX Unix操作系统上。SGI和SuSE将其移植到了linux上,SGI在2000年8月将FailSafe的源码开放。(http://oss.sgi.com/projects/failsafe/)

      Linux FailSafe是一个高可用的集群产品,每个集群支持最多8个节点。 各节点可以访问共享的RAID 或镜象磁盘。

      Linux FailSafe 为用户提供了一组系统恢复的工具,并允许用户为特定的应用编写自己的恢复工具。Linux FailSafe为多个重要的应用提供了高可用性的支持。包括NFS, Samba, Apache, 和Oracle。Linux FailSafe不需要应用做任何修改。

      虽然Linux FailSafe具有商业集群产品的所有特征,其主要面对的还是那些有创造性

    的专业用户。 一些应用(例如建模)使用大量的数据,所有的运算耗时数小时甚至数天,所以它们更需要高可用性的支持。虽然Linux FailSafe适用于商业应用,

      SGI 的主要目标是诸如CAD/CAM 、化学及生物学、数据管理、工程分析、科学计算等用户

      下面列出了Linux FailSafe集群技术的主要特点:

      1. 高可用性服务

      2. 动态集群配置:一个节点可以动态的加入集群或从集群中删除而不会导致

    应用的中断。

      3. 基于java 的集群管理

      4. 在服务不间断的情况下对节点进行维护:用户可以将节点从集群中删除,

    对其进行升级,然后再将其重新加入到集群中,而集群的服务不会受到任

    何影响。

      5. 对数据完整性的保护

      Linux FailSafe 不需要对linux 内核的修改,Linux FailSafe 通过确保一个失效的节点不会再对一个文件系统或数据库进行写操作来提供对数据完整性的保护。当一个节点被发现失效后,集群中的其他节点将其从集群中删除。

      Linux FailSafe有基于java的GUI。 基于java 的GUI 包括用来配置集群的FailSafe 管理器以及用来以动态图形的方式显示集群状态的FailSafe 集群观测器。

    2.2.8 SteelEye Technology LifeKeeper for Linux

      SteelEye Technology公司在1999年12月从NCR收购了Life-Keeper 技术,从而也拥有了使用该技术的一系列集群产品。在此之前NCR已经在数千台服务器上部署了Life-Keeper,它们运行在Solaris, Windows NT, 和MP-RAS环境下,SteelEye对其做了一些修进,例如对java GUI的修改,但在本质上它还是那项受到好评的NCR公司的集群技术。

      LifeKeeper从2000年6月开始发售,起价为每节点1500美元,SteelEye可以提供节点的配置和全天的支持服务,但要另外收费。LifeKeeper 3.01现在支持Red Hat Linux 和 Caldera OpenLinux,在将来会支持SuSE以及其他的linux发行版本。LifeKeeper还支持Windows NT, Solaris, 和MP-RAS,对Windows 2000的支持会在2001年内实现。

      LifeKeeper的目标是ISP、ASP以及那些在intel平台上部属电子商务应用和数据库的客户。

      下面列出了LifeKeeper最主要的特点:

      1. 对关键资源的良好保护,为关键的商务应用提供最长的运行时间。

      2. 可伸缩的配置选项。

      3 . 基于java的GUI,提供良好的易用性和易配置性。

      4. 已在数千台服务器上得到了证实

      5 . 支持多种平台,包括Linux, Unix, 以及 Windows NT/2000

      LifeKeeper的linux版使用linux的API,不用对内核做任何改变。应用也同样不需改变。SteelEye提供的应用恢复工具可以在应用失效时自动切换,目前支持的应用有Oracle、 Apache、 Sendmail、 Samba、Lotus Domino和Informix。如果支付一些费用的话,你也可以得到根据需要定制的应用恢复工具。 为了确保客户能够对应用和数据进行连续的访问,LifeKeeper 在节点失效时自动将应用转移到另一个节点并保护数据。

      LifeKeepe 的体系结构没有限制节点数的上限,但是由于现今基于linux 的存储解决方案的限制,在每根SCSI总线上只能连接两个服务器,这就限制了在共享SCSI 硬盘的解决方案中,

    在一个共享的SCSI硬盘上只能连接两个节点。

      LifeKeeper 提供了对Apache 服务器的静态数据复制功能,通用的数据复制功能将在今年提供。

      为了实现数据完整性,LifeKeeper 使用SCSI 预定来保护通过共享的SCSI 总线被其他节点访问的数据。 当安装LifeKeeper,一个SCSI预定的补丁也同时被安装。这个补丁现在已经被包含在Red Hat Linux 6.2 中,而且Caldera等其他linux发行商也正在将其包含到自己的发行版中。

      LifeKeeper可以从网络上的任何地方通过一个基于java的集中的GUI来进行管理。 这个GUI 允许管理员管理所有基于linux 的应用、数据库、服务器。SteelEye 现在正与Caldera 、Compaq 、Dell 、 IBM 、 Intel, Red Hat以及其他的集群技术提供商合作。希望提供一个综合了网络和系统配置的易于配置的环境,类似于Hewlett-Packard 的OpenView 、 IBM 的NetView 和Tivoli 、 以及 Computer Associates 的Unicenter/TNG 。

     

    2.2.9 TurboLinux Cluster Server 6

      Cluster Server 6 是TurboLinux公司的第三代集群技术,它是从TurboCluster 4.0改进而来。Cluster Server 6主要是一个负载平衡及可伸缩的解决方案,TurboLinux同时也宣称其是一个高可用性的集群方案。 这意味着同一个应用及配置在所有的节点上均可用。一旦一个节点上的服务失效,它可以在另一个节点上重新启动,不会造成服务的中断。

      TurboLinux本身是遵循GPL的,但是在它之上的Cluster Server 6则不是遵循GPL的。集群中的节点可以运行TurboLinux、 Red Hat Linux、 Solaris或Windows NT/2000操作系统。TurboLinux宣称Cluster Server 6可以使网络应用的无故障运行时间达到99.995%。Cluster Server 6不需要特定的硬件,也不需要对应用的修改。

      Cluster Server 6的目标是小到中型的需要高可用的web服务及内联网服务的商务应

    用,电子商务站点,需要廉价的负载平衡软件解决方案的顾客。

      Cluster Server 6的主要特点有:

      1. 负载平衡解决方案

      2. 对节点的数目几乎没有限制

      3. 易用的集群管理接口

      4. 节点间的安全连接

      5 . 节点可运行在TurboLinux, Red Hat Linux, Solaris或Windows NT/2000操作系统之上。

      Cluster Server 6对linux内核进行了一些修改,所有对内核的改动都是开放源码的,可以下载,Cluster Server 6中没有包含对内核的补丁,因为这些修改已经加入了TurboLinux发行版本中。

      Cluster Server 6的加速连接特性改善了包路由以及传输管理的性能,添加了三种负载均衡技术:网络地址转换、ip隧道和直接路由。 一个新的集群管理控制台(CMC )使管理员可以实时观测到集群的状态,负载和性能。CMC使管理员能够管理集群的设置,维护。 管理员只需要几下鼠标的点击就可以使一个节点从集群中脱离出来以对其进行维护,同时不会对集群的性能造成影响。

     

    2.2.10 Veritas Cluster Server for Linux

      Veritas软件公司的主要产品有 Veritas Cluster Server和 Veritas Global Cluster Manager,主要运行在Windows NT/2000、HP-UX 和Solaris上。

    Cluster Server for Linux侧重于对服务的管理而不是对节点的管理。一个应用由多个资源组成,一些是基于硬件的,另一些是基于软件的。 例如,一个数据库服务包括一个或多个逻辑上的网络标识,象ip 地址;一个关系数据库管理系统(RDBMS );一个文件系统;一个逻辑磁盘管理器;多个物理磁盘。当节点失效时,所有的资源需要转移到另一个节点上以重建该服务。

      在底层,Cluster Server for Linux监测一个服务所用到的资源。 当发现服务失效时,会自动重启服务,包括本地重启或移动到另一个节点后重启,取决于失效的类型,如果一个服务的一个独立的资源失效,则不需要重启整个服务而只需要重启失效的那个部分。

      Cluster Server for Linux的目标是互联网、电信及金融方面的应用。

      Cluster Server for Linux的主要特点有

      1 . 可伸缩,2~32个节点

      2 . 可运行在HP-UX, Solaris, 和 Windows NT/2000上。

      3 . 巩固的系统管理。

      Cluster Server for Linux是一个与体系结构无关的集群技术。

    Linux虚拟服务器 (Linux Virtual Server, LVS)建筑 于实际的服务器集群之上,用户看不到提供服务的多台实际服务器,而只能看见一台作为负载 平衡器的服务器。实际的服务器通过高速局域网或地理上分散的广域网连接。实际服务器的前端是一台负载平衡器,他将用户的请求调度到实际服务器上完成,这样看起来好像所有服务都是通过虚拟服务器来完成的。Linux虚拟服务器能够提供良好的可升级性、可靠性和可用性。用户可以透明地增加或减少一个节点,可以对实际服务器进行监测,如果发现有节点失败就重新配置系统。

    Linux Virtual Server的结构如图所示。


     Linux 虚拟服务器结构图 

     

    3.1 调度算法

    LVS 提供了四种调度算法:轮转调度,加权轮转调度,最少连接调度,加权最少连接调度。

    1. 轮转调度(Round Robin Scheduling )
      轮转调度不考虑服务器的连接数和响应时间,它将所有的服务器都看作是相同的。当以轮转的形式将连接分发到不同的服务器上。
    2. 加权轮转调度(Weighted Round Robin Scheduling)
      根据每个机器的处理能力的不同给每个机器分配一个对应的权重,然后根据权重的大小以轮转的方式将请求分发到各台机器。这种调度算法的耗费比其它的动态调度算法小,但是当负载变化很频繁时,它会导致负载失衡,而且那些长请求会发到同一个服务器上。
    3. 最少连接调度(Least Connection Scheduling)
      最少连接调度将用户请求发送到连接数最少的机器上。最少连接调度是一种动态调度方法,如果集群中各台服务器的处理能力相近,则当负载的变化很大时也不会导致负载失衡,因为它不会把长请求发送到同一台机器上。但是当处理器的处理能力差异较大时,最少连接调度就不能很好的发挥效能了。
    4. 加权最小连接调度(Weighted Least Connection Scheduling)
      根据服务器的性能不同而给它们分配一个相应的权重,权重越大,获得一个连接的机会就越大。

    2.3.9 其他 HA 集群

    RESONATE DISPATCH 系列


       Resonate有一种基于软件的负载均衡方法,类似于Linux虚拟服务器。但是,它支持更多特性,以及一些更好的负载均衡算法。例如,使用Resonate,可以在每个群集节点装入一个代理,以确定该节点当前的系统负载。然后,负载均衡服务器检查每个节点的代理,以确定哪个节点的负载最少,并且将新的流量发送给它。另外,Resonate还可以使用它的Global Dispatch产品更有效地支持地区性分布式服务器。

      Resonate已经在Red Hat Linux上彻底测试了该软件,相信它也可以在其它发行版上运行。Resonate的软件还可以在其它各种平台上运行,包括Solaris、AIX、Windows NT,并且它还可以在混合环境中进行负载均衡。

    Novell HA 套件

    Novell HA 是Novell 公司的开放源代码高可用集 , Novell 公司并购了欧洲 Linux 第一大厂 SuSE 之后,成为全球能够抗衡 RedHat 的主要力量 . SuSE 企业版 Linux 带有一套开放源代码的 HA 集群软件,包括 HA project 的heartbeat, heartbeat-ldirectord, heartbeat-pils, heartbeat-stonith, 集群关联的存储软件 drbd, 虚拟 IP 的src_vipa 软件 . 和 RHCS 不同的是, SuSE/Novell 企业版 Linux 自带的 HA 集群软件并非一个独立的软件,如上介绍,而是由不同的开放源代码项目提供的不同部分的程序。

    集群软件的获得 :

    本集群软件组件已经附带在 SuSE Linux Enterprise Server 光盘中 (SLES9, SLES10), SuSE Linux Enterprise Server(SLES9, SLES10) 的光盘,可以免费从 download.novell.com 获得,并提供 2 个月的在线网络更新服务 .用户只需要在 novell 站点上免费注册一个 novell 站点账号,就可以下载 SLES9, SLES10 的所有光盘 ISO 。

    Novell Cluster Service

    Novell 在败落前,曾经是一家非常伟大的公司,有着非常雄厚的技术力量。 早在 10 多年前, Novell 公司就在集群领域独树一帜,是当时唯一能够在 PC 服务器上构建出 32 节点集群的厂商 .

    Novell 收购 SuSE 公司之后,将原来在 Novell netware 操作系统上的大量企业级应用移植和整合到了 SuSE Linux Enterprise Linux 平台 , Novell 当时名震集群领域的 Novell Cluster Service 也被整合移植到了 Linux 平台,Novell Cluster Service 是一个商业系统,并非开放源代码产品 。

    linux-HA

    linux-HA 是开放源代码的 HA 项目,linux-HA 项目历史悠久, 很多linux 发行附带的HA 集群都是采用了linux-HA的heartbeat 系统和相关的组件. 需要构建完全的开源,自由而且免费的高可用集群的用户可以选择.


      对于 Linux ,有许多集群系统可供选用。同时,那些项目中有几个是非商业性的,甚至是实验性质的。虽然对学术界和某些组织这也没有形成问题,但大公司通常首选著名供应商的商业支持平台。供应商,如 IBM 、 SGI、 HP 和 Sun ,提供了用于在 Linux 中构建科学群集的产品和服务,因为群集很流行,并且可以销售大量的服务器设备。一旦商业机构认为其它形式的集群是可靠的,那些相同的服务器供应商或许会围绕着开放源码集群解决方案创建自己的产品。 
       Linux 作为服务器平台的重要性依赖于支持大型服务器和服务器群集的能力。这就使它可以与 Sun 、 HP 、IBM 和其它公司的 UNIX 服务器在更高层面上竞争。虽然 Windows NT 和 2000 不支持 Linux 能够支持的集群范围,但是 HA 集群正规方法的可用性以及用于构建有群集意识的 API 也使它能够参与竞争。 
     如果正在考虑构建一个群集,那么您应当仔细检查那些可能性,并将它们与您的需求做比较。您也许会发现想要实现的目标还不能成为一个完整的解决方案,或许会发现已经有了现成的解决方案。

     

    3 集群的文件系统

    集群系统文件系统,主要包括Coda,Global,xFS,MOSIX,OCFS,Lustre等。 
    集群计算的发展需要发展并升级文件系统,此文件系统不仅能够对多个文件提供并行的访问,而且能在对同一文件进行访问的进程间提供cache一致性。大多数传统的网络 文件系统如NFS、AFS、Coda对于并行处理而言是远远不够的,因为它们都依赖中心文件服务器 。但是,随着越来越多的客户的加入,服务器的cpu很快就成为了性能的瓶颈。为了解决这个问题,处理能力更强的服务器已经被制造了出来,而且文件系统的设计者们也试图将更多的工作交给客户来完成,但是即使是这样,服务器的速度仍然是文件系统可升级性的瓶颈。新一代的文件系统如Global File System(GFS) 、XFS和 Frangipani 比较适合于集群系统。因为这些系统都在集群系统中的机器上分配存储 器、cache 和控制权,并且提供了并行文件访问和cache一致性的解决方法。


    3 .1 Coda 文件系统

    Coda文件系统(Coda File System)适用于分布式网络环境。它是在1987年在卡耐基梅隆大学以AFS2为原型开发出来的。 Linux Virtual Server 就采用了Coda 文件系统。Coda 提供了以下适用于网络文件系统的特性。

    1. 为移动的客户提供了断开操作。

    2. 它是一种自由软件。

    3. 通过客户访问的持续缓存提供了高可用性。

    4. 服务器复制功能。

    5. 提供了认证的安全模型、加密和访问控制。

    6. 部分网络失效后能够继续工作。

    7. 具有网络带宽适应性。

    8. 较好的可扩展性。

    9. 即使在网络失效时也为共享定义了良好的语法。

    AFS和Coda文件系统都将所有的文件放于同一个目录下,如AFS 是/afs,Coda是 /coda,这意味着所有的客户都可以使用相同的配置,所有的用户看到的是相同的文件树。对于大的安装而言这是非常重要的。对于NFS文件系统而言,客户需要服务器的最新列表而在Coda中只需要找到根目录/coda。

    当在客户端敲入"cat /coda/tmp/foo"这样的请求时,cat将调用系统调用向核心请求服务,核心首先找到对应的文件索引节点并返回与该文件相关的文件句柄。索引节点包含文件的一些相关信息,文件句柄用于打开文件。系统调用首先进入核心的虚拟文件系统(VFS),然后它将请求传送给核心中的Coda文件系统模块进行处理。Coda文件系统模块包含着从VFS来的最近的一些请求,然后它将此请求交给Coda缓冲管理器venus进行处理。Venus通过察看硬盘缓冲区、向服务器发请求等方式来定位文件的所在地。如果在硬盘缓冲区中没有找到匹配的文件,则通过远程系统调用向服务器发请求,并且将取到的文件放在cache中,这时,这个文件就是一个普通的文件了,因此可以通过本地文件系统对该文件进行读写的操作。如果在硬盘缓冲区找到了此文件,则可以直接使用这个文件。当对此文件进行了一定的修改并且关闭了以后,venus将把新文件传送给服务器从而来更新服务器上的文件。其它的操作如修改文件系统,创建新目录,删除文件,去除符号链接等都可以传送给服务器。

    但是由于网络有时会出现问题,因此如何保证文件的连续性是一个非常重要的问题。当venus意识到服务器不可用时,它就将客户端对文件的更新存储在修改日志中,当服务器重新可用时,便根据修改日志对服务器上的相应的文件进行更新。

     3. 2 Global 文件系统 

    GFS(Global File System)是Minnesota大学开发的基于SAN的共享存储的机群文件系统,后来Sistina公司将GFS产品化。GFS在很长一段时间都是以源代码 开放软件 的形式出现的,后来由于Sistina希望通过向用户提供支持和服务的计划未能取得成功,为了要促进自己的财务收入,Sistina在2001年将GFS变成了一种“专有软件”。Red Hat公司收购Sistina之后,在遵循GPL协议(General Public License)的条件下履行诺言公开了GFS的源代码。现在,GFS的全名被称为“红帽全球文件系统”(Red Hat Global File System,GFS)的软件,每台服务器每年收取2200美元的费用。

    GFS 最初是在IRIX 上开发的,后来移植到LINUX 上,并开放源码 

    通过使用GFS,多台服务器可以共用一个文件系统来存储文件。信息既可以存储在服务器上,也可以存储在一个存储局域网络上。

    GFS与GPFS结构相似,但它是全对称的机群文件系统,没有服务器,因而没有性能瓶颈和单一故障点。GFS将文件数据缓存于节点的存储设备中,而不是缓存在节点的内存中。并通过设备锁来同步不同节点对文件的访问,保持UNIX文件共享语义。GFS实现了日志,节点失效可以快速恢复。GFS使用SCSI设备锁来进行同步,目前很少设备实现这种设备锁。在没有设备锁的情况下,GFS也是通过唯一的锁服务器来进行同步,因此,锁服务器是其性能的瓶颈。

    用户通过GFS可以加快数据访问速度,并进行信息复制。一旦一台服务器出现问题,用户仍可以通过网络内其他的计算机访问有关的数据。GFS对于以以下两种方式连接而成的计算机集群尤其有用:1、计算机集群中任何一台机器都可以在另一台机器发生故障时接管这台计算机的工作,2、计算机集群中的所有机器联合起来组成一台超级计算机。

    GFS允许多个Linux机器通过网络共享存储设备。每一台机器都可以将网络共享磁盘看作是本地磁盘,而且GFS自己也以本地文件系统的形式出现。如果某台机器对某个文件执行了些操作,则后来访问此文件的机器就会读到写以后的结果。

    GFS设计 时就考虑到了可以通过NFS或者HTTP协议进行扩展。但是数据控制和数据传输的开销显然要小于NFS。

    控制路径从用户应用通过VFS传递到NFS客户端。NFS通过TCP/IP协议执行远程调用。NFS服务器端响应调用请求,通过VFS访问本地文件系统,然后由本地文件系统来访问本地的存储设备。数据传输路径包括:用户内存和NFS客户端缓存之间的内存拷贝,NFS客户端与网络缓存之间的拷贝,缓存网络缓存和NFS服务器端缓存之间的拷贝。这些拷贝通过系统总线和网络连接进行。

    控制路径从用户应用通过VFS到达GFS。GFS向网络存储池(network storage pool,NSP)中的存储设备发出请求。块对齐数据(Block aligned data )在用户内存和存储设备间传输,非对齐数据则临时的通过系统内存传递。

    GFS中有一个很重要的概念,叫网络存储池(The network storage pool,NSP)。NSP为每台机器提供了一个统一的存储地址空间。GFS通过NSP实现了存储设备的网络共享。这些存储设备可以是共享SCSI(Shared SCSI)和共享通道(Fibre Channel - FC)。NSP包装这些存储设备使得它们好像节点本地的文件系统。

    NSP还可以根据存储设备的类型分为多个子存储池(subpools)。NSP同时也对锁进行管理 。GFS发送“锁”和“解锁”命令给NSP,NSP收到后把逻辑锁号转成对应的物理设备的锁号进行锁定。

     GFS把文件系统组织成数个资源组(resource groups,RG)。通过RG,GFS把文件系统的资源分布在整个NSP上。一个存储设备上可以存在多个RG。RG实际上是各微型的文件系统(minifile system)。从文件到RG,以及从RG到NSP子池的映射。文件可能被存放在数个RG和多重存储池中。

    优点:

    GFS 的主要优点在于:

    高可用性:如果一个GFS 客户失效,数据还可以通过其他GFS 客户访问;

    扩展性:因为不需要中心服务器,所有很容易扩展存储容量和访问带宽; 

    缺点:

    和现在流行的SAN 型文件系统相比,设计思想似乎有点落后了;

    费用较高;


    3.3 xFS 文件系统


        xFS 试图通过将服务器的功能如保持cache 的一致性、定位数据和处理磁盘请求分布在各个客户上来提供对文件系统数据的低延迟、高带宽的访问。
    为了保持cache一致性,xFS采用了如下的方法。它将客户方的所有的内存空间看为一个大的cache,这样就减少了客户方的数据缓存,利用了闲置机器的内存,这种合作型的缓存可以通过减少到达磁盘的请求量来降低读延迟。
    为了将定位数据的功能分布到每个客户端,xFS让每个客户都必须对文件的一个子集对应的请求进行处理。文件数据在多个客户端加以分类从而提供更高的带宽,这些分类数据包括一些奇偶信息,通过这些信息可以在机器失效时恢复分类的数据报。 这种方法可以保证没有任何节点会产生单点失效的情况。

    xFS 主要特性包括以下几点:

      1. 数据完全性

      采用XFS文件系统,当意想不到的宕机发生后,首先,由于文件系统开启了日志功能,所以你磁盘上的文件不再会意外宕机而遭到破坏了。不论目前文件系统上存储的文件与数据有多少,文件系统都可以根据所记录的日志在很短的时间内迅速恢复磁盘文件内容。

       2. 传输特性

      XFS文件系统采用优化算法,日志记录对整体文件操作影响非常小。XFS查询与分配存储空间非常快。xfs文件系统能连续提供快速的反应时间。笔者曾经对XFS、JFS、Ext3、ReiserFS文件系统进行过测试,XFS文件文件系统的性能表现相当出众。

       3. 可扩展性

      XFS 是一个全64-bit的文件系统,它可以支持上百万T字节的存储空间。对特大文件及小尺寸文件的支持都表现出众,支持特大数量的目录。最大可支持的文件大小为263 = 9 x 1018 = 9 exabytes,最大文件系统尺寸为18 exabytes。

      XFS使用高的表结构(B+树),保证了文件系统可以快速搜索与快速空间分配。XFS能够持续提供高速操作,文件系统的性能不受目录中目录及文件数量的限制。

       4. 传输带宽

      XFS 能以接近裸设备I/O的性能存储数据。在单个文件系统的测试中,其吞吐量最高可达7GB每秒,对单个文件的读写操作,其吞吐量可达4GB每秒

     


    3. 4 MOSIX 文件系统

    MOSIX 集群使用了自己的文件系统MFS 文件系统。MFS将集群中的所有文件系统和目录都看作是一个文件系统,而且它提供了对所有节点上的所有文件系统的统一访问,它还通过只提供一个cache保证了cache的一致性。
    MFS包含了许多位于不同节点上的文件子树,因此它就允许对多个文件进行并行操作和cache一致性。
    在MOSIX集群中进行进程迁移时,如果此进程主要占用的是CPU资源,则迁移此进程对于提供系统性能是非常有效的,但是如果此进程需要进行大量的I/O操作,则迁移进程非常不利。这是因为每个I/O操作都需要与该进程原来所处的节点进行通讯。
    因此MFS增加了对DFSA(Direct File System Acess)的支持。DFSA的目的就是让那些需要进行大量I/O操作的进程迁移到远端节点上,该远端节点拥有大多数I/O操作将会涉及到的文件,因此大多数的I/O操作都能在远端节点上完成,而且在远端节点上可以通过本地访问来访问数据。如果一个系统调用是节点无关的,此系统调用就会在远端节点上执行,否则就在本地执行。 MFS 比其它网络文件系统优越的地方就是它允许使用本地文件系统,这样就减少了进程和文件服务器之间的通讯开销。

     3.5 Oracle 集群文件系统 (OCFS)

      OCFS 专门为支持 Oracle RAC 应用程序的数据和磁盘共享而设计。它在 RAC 集群的服务器节点间提供一致的文件系统映像,充当原始设备的替身。 除了简化集群数据库管理外,它还在保持原始设备性能优势的同时克服了原始设备的局限性。 
        OCFS 第 1 版支持 Oracle 数据文件、spfile、控制文件、仲裁磁盘文件、归档日志、配置文件以及 Oracle 集群注册表 (OCR) 文件(Oracle 数据库 10g 中的新文件)。设计它不是为了使用其他文件系统的文件,甚至不是为了使用那些必须在集群每个节点上安装的 Oracle 软件 — 除非您使用第三方解决方案。此外,OCFS 不提供诸如 I/O 分配(分割)等 LVM 功能,也不提供冗余功能。 

        Oracle 支持用于 32 位和 64 位发行版本的 Red Hat Advanced Server 2.1 、Red Hat Enterprise Linux 3 和Novell SUSE (United Linux) 上的 OCFS 第 1 版中的 Oracle 数据库,该数据库需要从可下载的二进制文件进行安装。如果您自己对其进行重新编译,则 Oracle 不提供支持。

     

     3.6 Lustre

    Lustre 对象存储文件系统就是由客户端(client )、存储服务器(OST ,Object Storage Target )和元数据服务器(MDS )三个主要部分组成。Lustre 的客户端运行Lustre 文件系统,它和OST 进行文件数据I/O 的交互,和MDS 进行命名空间操作的交互。为了提高Lustre 文件系统的性能,通常Client 、OST 和MDS 是分离,当然这些子系统也可以运行在同一个系统中。其三个主要部分如图所示.


     Lustre 文件系统的组成 
      

    Lustre是一个透明的全局文件系统,客户端可以透明地访问集群文件系统中的数据,而无需知道这些数据的实际存储位置。客户端通过网络读取服务器上的数据,存储服务器负责实际文件系统的读写操作以及存储设备的连接,元数据服务器负责文件系统目录结构、文件权限和文件的扩展属性以及维护整个文件系统的数据一致性和响应客户端的请求。 Lustre把文件当作由元数据服务器定位的对象,元数据服务器指导实际的文件I/O请求到存储服务器,存储服务器管理在基于对象的磁盘组上的物理存储。由于采用元数据和存储数据相分离的技术,可以充分分离计算和存储资源,使得客户端计算机可以专注于用户和应用程序的请求;存储服务器和元数据服务器专注于读、传输和写数据。存储服务器端的数据备份和存储配置以及存储服务器扩充等操作不会影响到客户端,存储服务器和元数据服务器均不会成为性能瓶颈。

    Lustre 的全局命名空间为文件系统的所有客户端提供了一个有效的全局唯一的目录树,并将数据条块化,再把数据分配到各个存储服务器上,提供了比传统SAN 的" 块共享" 更为灵活的共享访问方式。全局目录树消除了在客户端的配置信息,并且在配置信息更新时仍然保持有效。


    更多资料请参考 :

     

    Beowulf Introduction and Overview  <http://www.beowulf.org>

    Platform-lsf  <http://www.platform.com/Products/platform-lsf>

    TurboCluster Server  <http://www.hallogram.com/turbolinuxser/index.html>

    The Mosix Howto,<http://www.mosix.org>

    Eddie ,<http://eddie.sourceforge.net/>

    Windows hpc <http://www.microsoft.com/hpc/en/us/default.aspx>

    Legion,<http://legion.virginia.edu/>

    Cplant ,<http://www.cs.sandia.gov/cplant/>

    JESSICA2,<http://i.cs.hku.hk/~clwang/projects/JESSICA2.html>

    Linux HPC Cluster Installation, IBM Redbooks,http://www.redbooks.ibm.com/

    HP_UCP ,<http://h20427.www2.hp.com/program/bcs/cn/zh/Sites_levels/HP_UCP-1.asp>

    EnFuzion,<http://www.axceleon.com/science.html>

    Resonate, <http://www.resonate.com/products.html>

    Apptime .Watchdog ,<http://www.apptime.com/>

    Legato ,http://www.legato.com/

    High Availability Server , <http://www.redhat.com/cluster_suite/>

    Linux FailSafe ,<http://oss.sgi.com/projects/failsafe/>

    Lifekeeper ,<http://www.hudong.com/wiki/lifekeeper>

    TurboLinux Cluster Server,<http://www.turbolinux.com>

    Cluster Server, <http://www.symantec.com/business/cluster-server>

    Linux Virtual Server,<http://www.linuxvirtualserver.org/>

    Novell Cluster Service,<http://www.novell.com/products/openenterpriseserver/>

    OSCAR: A packaged Cluster software stack for High Performance Computing, http://www.openclutergroup.org/

    Linux-HA Heartbeat System Design, http://www.linux-ha.org

    xCAT HOW-TO, http://www.x-CAT.org

    MPICH, http://www.mcs.anl.gov/mpi/mpich.

    PVM, http://www.epm.ornl.gov/pvm/pvm_home.html

    OpenPBS,http://www.openpbs.org/

    Maui, http://www.supercluster.org/

    Intermezzo, <http:/inter-mezzo.org/>

    Coda, http://www.coda.cs.cmu.edu/

    GFS, <http://globalfilesystem.org/>

    Lustre,<http://www.novell.com/products/openenterpriseserver/> ,<http://wiki.lustre.org>

     

     

     

    展开全文
  •  我们提出的弹性分布式数据集(RDDs),是一个让程序员在大型集群上以容错的方式执行基于内存计算的分布式内存抽象。RDDs受启发于两类使用当前计算框架处理不高效的应用:迭代算法和交互式数据挖掘工具。这二者在...

    摘要

           我们提出的弹性分布式数据集(RDDs),是一个让程序员在大型集群上以容错的方式执行基于内存计算的分布式内存抽象。RDDs受启发于两类使用当前计算框架处理不高效的应用:迭代算法和交互式数据挖掘工具。这二者在内存中保存数据性能能够提高一个数量级。为了有效容错,RDDs提供一种受限的共享内存,基于粗粒度转换(transformations)而非细粒度地更新共享状态。尽管如此,RDDs仍足以表达许多类型的计算,包括最近专门用于迭代作业的编程模型(如Pregel)以及这些模型无法表示的新应用。我们已经在Spark系统中实现了RDDs。

    1 引言

           像MapReduce和Dryad这样的集群计算框架已经广泛应用于大规模数据分析。这些系统让用户使用一系列高级算子写并行计算,而不用担心工作分配和容错。 
           虽然现有框架为访问集群计算资源提供了大量抽象,但是他们缺少利用分布式内存的抽象。这使得它们对那些跨多个计算重用中间结果的新兴应用效率不高。数据重用普遍存在于很多迭代的机器学习和图像算法中,包括PageRank,K-means聚类和logistic回归。另一个引人注目的用例是交互式数据挖掘,即用户在同样的数据子集上运行多个即席查询。不幸的是,大多数现有框架中,在计算之间(比如在两个MapReduce作业之间)重用数据的唯一方式是把它写到外部稳定存储系统(如分布式文件系统)。这种方式会因为数据复制,磁盘I/O和序列化而带来巨大开销,这直接影响了应用的执行时间。 
           由于认识到这个问题,研究人员为一些需要数据重用的应用开发出了专门的框架。例如,Pregel是为迭代的图像计算而在内存中保存中间数据的系统;而HaLoop则提供一个迭代的MapReduce接口。但这些框架只提供了特定的计算模型,并对这些模式隐式地进行数据共享。它们没有为更普遍的重用提供抽象,如让用户把几个数据集加载到内存中,在它们上运行即席查询。 
           这篇论文中,我们提出一个新的抽象,叫弹性分布式数据集(RDDs),它让数据重用在广泛的应用上都是高效的。RDDs是容错的并行数据结构,它让用户显示地在内存中保存中间结果,控制它们的分区以优化数据布局,用丰富的算子去操作它们。(注:这里的它们就是中间结果) 
           在设计RDDs时主要的挑战是:设计一个能有效提供容错性的编程接口。现有的对集群上基于内存存储的抽象(如分布式共享内存、key-value stores、数据库、Piccolo)提供了基于细粒度更新可变状态(比如表中的元素)的接口。这个接口提供容错的仅有的方式是跨机器复制数据或跨机器记录更新。这两个方法对数据密集型工作负载代价很大,因为它们需要在集群网络上拷贝大量数据,它的带宽远比RAM的要小,并且导致严重的存储开销。 
           和这些系统对比,RDDs提供基于粗粒度转换(map、filter和join等)的接口。这允许它们通过记录用于构建数据集(它的lineage)的转换(transformations)去有效地提供容错性。如果RDD的分区丢失了,那个RDD会有足够的信息从其他RDDs衍生去重新计算刚才那个分区。从而,丢失的数据通常可以很快被恢复,且不需要花销很大的复制。(注:粗粒度是应用于整个数据集,如上述map、filter;细粒度是指应用于单行,如get(index)和set(index)。) 
           即便是基于粗粒度转换的接口在最初也会受限,RDDs很适合很多并行化应用,因为这些应用天然适合在多个数据项上应用相同的操作。RDDs能高效地表示很多已经提出的作为独立系统的集群编程模型,包括MapReduce、Haloop等,也包括这些系统不能很好地应用的新应用程序,如交互式数据挖掘。 
           我们已经在Spark的系统中实现了RDDs,Spark系统在UC Berkeley和个别公司被用于研究、生产应用。Spark提供一个方便语言集成的编程接口,接口是Scala语言编写的。另外,Spark可以用来从Scala解释器上交互式地查询大数据集。Spark允许通用编程语言以交互式速度用于集群上基于内存的数据挖掘,我们相信Spark是第一个这样的系统。 
           我们通过微基准和用户应用程序的测试评估RDDs。发现,对于迭代应用,Spark比Hadoop快20倍;实际数据分析类报表速度提升40倍;Spark用于交互式查询1TB的数据集只有5至7秒的延迟。为了说明RDDs的普适性,我们已经在Spark之上实现了Pregel和HaLoop编程模型,包括以相对较小的库的形式提供了它们使用的位置优化策略(每个200行代码)。 
           本文先分别在2和3节概述RDDs和Spark。然后,在第4节讨论RDDs的内部表示,第5节是RDDs内部的实现,第6节是实验结果。最后,在第7节讨论RDDs是怎样引起几个现有的集群编程模型兴趣的,第8节研究相关工作,最后是结论。

    2 弹性分布式数据集(RDDs)

           这节对RDDs进行概述。先在2.1节给RDDs下定义,2.2节阐述Spark中RDDs的编程接口,然后在2.3节比较RDDs和细粒度共享内存抽象,最后在2.4节讨论RDD模型的局限性。

    2.1 RDD抽象

           RDD是一个只读的、分区记录的集合。RDDs能通过通过以下两种方式创建: 
           (1)稳定存储中的数据注:等动手写程序时就知道原因,如从HDFS中用sc.textFile(path)读文件就能创建) 
           (2)其他RDDs 
    我们称这些操作为转换(transformations),以把它们和其他RDDs上的操作(actions)区分开。map、filter、join都属于transformations。 
           RDDs任何时候都不需要物化(真正执行操作后存入稳定存储)。相反,一个RDD有足够多的关于它是怎样从其他数据集衍生出(它的Lineage)的信息,据此从稳定存储中的数据计算出它的分区。这是一个强有力的特性:从本质上说,如果故障后无法重建RDD,程序就不能引用该RDD。(有点绕,其实就是说RDD能够被重建是个很重要的特性,RDD有很强大的容错机制) 
           最终,用户能控制RDDs的两个其他方面:持久化和分区。用户可以表明他们将重用那个RDDs并为它们选择存储策略(如in-memory 存储)。他们也可以让一个RDD的元素基于每个记录的key跨机器分区。这对位置优化是有用的,如确定两个将要join的数据集是以相同方式进行哈希分区的。

    2.2 Spark编程接口

           Spark通过一个语言集成API暴露RDD,API中每个数据集被表示为一个对象,在这些对象上transformations被使用方法调用。 
           程序员编程的第一步是通过在稳定存储中的数据调用transformations来定义RDDs(如map和filter)。然后他们可以对这些RDDs调用actions,actions是给应用程序返回值或者把数据导出到存储系统的操作。count、collect、save都属于actions。Spark只有在第一次调用action时才会真正计算RDDs,在此之前进行的transformations都是惰性计算,这样能对transformations进行并行流水线化(pipeline)。 
           另外,程序员可以调用persist方法表明在以后的操作中他们想用哪个RDDs。Spark默认在内存中持久化RDDs,但是如果没有足够的RAM将会把多余的存入磁盘。用户也可以请求其它的持久化策略,如只在磁盘上存储RDD,或跨集群复制RDD,通过flags进行persist。最后,用户可以在每个RDD上设置持久化优先级去指定哪些内存的数据应该优先被存入磁盘。

    2.2.1 示例:控制台日志挖掘

           假设有一个web服务出错了,操作员想从保存在HDFS中的TB级的日志中找出原因。通过使用Spark,操作员只需从日志中把刚才那个错误的信息加载到一组节点的RAM,并交互式地查询它们。她将先写出下面的Scala代码:

    lines =spark.textFile("hdfs://...")
    errors = lines.filter(_.startWith("ERROR"))
    errors.persist()
     

       

     

     

     

     

       第一行通过HDFS文件定义了一个RDD(即是文本形式的lines的集合),第二行对lines进

    行过滤得到一个过滤后的RDD,第三行将errors存入内存以便查询中共享。值得注意的是,在Scala语法中filter的参数是一个闭包。 
           此时,集群上并没有执行任何工作。但是,用户可以对该RDD执行动作(actions),如统计信息条数:

    errors.count()

           用户也可以在该RDD上进一步执行transformations,并使用转换后的结果,如下:

    //统计errors中涉及MySQL的行数:

    //统计errors中涉及MySQL的行数:
    errors.filter(_.contains("MySQL")).count()

    //以数组的形式返回errors中涉及HDFS的时间字段
    //(假设时间是'\t'分隔的number为3的字段)
    errors.filter(_.contains("HDFS"))
          .map(_split('\t')(3))
          .collect()
     

     

     

     

     

     

     

     

       在errors的第一个action运行后,Spark将在内存中保存errors的分区,极大地加速了后续计算。值得注意的是,最初的RDD(lines)没有被缓存。这很合理,因为错误信息可能只是数据的一小部分(小到足以存入内存)。 
           最后,为了说明我们的模型怎样容错,我们在图1中展示了第三次查询中的RDDs的血缘(lineage)图。这次查询,在lines上进行filter得到errors,然后在errors上进一步应用filter和map,之后是collect。Spark调度器将并行流水线化后两个transformations,给拥有errors的分区缓存的节点发送任务集去计算。另外,如果errors的一个分区丢失了,Spark可以仅在lines相应的分区上应用过滤器来重建该分区。 


     
    方框代表RDDs,箭头代表transformations 

    2.3 RDD模型的优势

           为了明白RDDs作为分布式内存抽象的好处,我们在表1中列出了RDDs与分布式共享内存(DSM)的对比。DSM系统中,应用在全局地址空间任意位置读写。值得注意的是,在这种定义下,DSM不仅包括传统的共享内存系统,还包括其他采用细粒度写共享状态的系统,提供共享的DHT的Piccolo和分布式数据库。DSM是非常通用的抽象,这种通用性使它难以在商业集群上实现高效率和容错性。

    方面

    RDDs

    分布式共享内存

    粗/细粒度

    细粒度

    粗粒度

    细粒度

    一致性

    不重要(不可变)

    取决于app/运行时

    故障恢复

    细粒度,使用Lineage的的开销

    需要检查点和程序回滚

    落后任务降灾

    可以使用任务备份

    难以实现

    任务安排

    基于数据本地化自动分配

    取决于app(运行时实现透明性)

    内存不足时行为

    类似于已有数据流系统

    性能差(交换?)

    表1:RDDs与DSM的对比


           RDDs和DSM主要的区别在于RDDs只能通过粗粒度transformations创建(“written”),而DSM允许读写每个存储单元。这虽然限制了RDDs只读,但允许RDDs有更高效的容错。尤其,RDDs不需要检查点的开销,因为它们可以使用lineage恢复。此外,只有RDD丢失的分区才需要重新计算,并且它们可以在不同节点上并行计算,而不用回滚整个程序。 
           RDDs的第二个好处是它们的不可变性使系统能够运行类似MapReduce的备份任务来缓和慢节点。用DSM难以实现备份任务,因为一个任务的两个副本将访问相同的内存位置,相互干扰更新。 
           RDDs相比于DSM还提供了另外两个好处。第一, 在对RDDs的批量操作中,运行时会基于数据本地化去调度任务以提高性能。第二,仅仅当它们用于基于扫描的操作时,RDDs在内存不足以存储它们时会优雅降级,内存存不下的分区会存在磁盘中,此时与现有的数据并行系统性能相当。

    2.4 不适合RDDs的应用

           就像引言中讨论的,RDDs最适合批处理应用,批处理应用就是对一个数据集的所有元素运行相同的操作。这种情况下,RDDs能够有效地记住每个transformation,每个transformation是lineage图中的一个步骤,并且,不需要记录大量数据就能够恢复丢失分区。RDDs不太适合那些对共享状态进行异步的细粒度的更新,如web应用的存储系统或web爬虫增量抓取器。对于这些应用,执行传统的更新日志和数据检查点操作更加高效,例如数据库等。我们的目标是给批处理分析提供高效编程模型,把这些异步应用程序留给专门的系统。

    3 Spark编程接口

           Spark给RDD抽象提供了一个用Scala编写了语言集成API。Scala是在JVM上的静态类型函数式编程语言。我们选择Scala是因为它简洁的组合(便于交互式使用)和效率(由于静态类型)。然而,RDD抽象并不是一定要用函数式语言。 
           为了使用Spark,开发者写一个驱动程序(driver program)连接wokers集群,如图2所示。driver定义一或多个RDDs,并在RDDs上调用action。在driver上的Spark代码还会追踪这些RDDs的lineage。wokers是长期运行的进行,能在内存中存储RDD分区。 



    Spark运行态。用户的驱动程序启动多个worker,worker从分布式文件系统读取数据块,并在内存中保存已计算的RDD分区* 


           就像在2.2.1节日志挖掘实例中所展现的,用户给RDD操作(如map)传参是传递闭包(字面函数)。Scala用一个java对象代表每个闭包,这些对象可以被序列化,可以通过网络中传递闭包加载到另一个节点上。Scala也把闭包中的变量约束保存为Java对象中的字段。例如,一个人可以写下面的代码去对RDD中每个元素加5。

    var x = 5
    rdd.map(_ + x)
    
    

     

     

     

           RDDs本身是元素类型参数化的静态类型对象。例如,RDD[Int]是整数的RDD。由于Scala支持类型推断,所以大多数例子中都省略了类型。 
           虽然用Scala实现RDDs在概念上很简单,但是我们必须使用反射解决Scala闭包对象的问题。通过Scala解释器去使用用Spark,我们还需要做很多的工作,我们将在5.2节讨论。但我们并不需要去修改Scala编译器。

    3.1 Spark中的RDD操作

           表2列出了Spark中主要的RDD的transformations和actions操作。每个操作都给出了表示,中括号表示类型参数。前面说过transformations是定义新RDD的惰性操作,而actions开始真正的计算并返回一个值给程序或是把数据写到外部存储。 


     
    Seq[T]是类型为T的元素序列 

    3.2 应用实例

           我们对2.21节中的数据挖掘示例补充两个迭代应用:logistic回归和网页排名。之后说明怎样控制RDDs的分区能提高性能。

    3.2.1 logistic回归

           很多机器学习算法都具有迭代特性,因为他们需要运行迭代优化程序去最大化一个函数,如梯度下降法。它们的数据保存在内存中会让它们运行更快。 
           下面的程序实现了logistic回归。logistic回归是一个常见的用于寻找一个能最佳分割两组点(如垃圾邮件和非垃圾邮件)的超平面w的经典算法。算法使用梯度下降法:w开始时是随机值,每一次迭代,对w的函数求和,使w朝着优化的方向移动。

    val points = spark.textFile(...)
                      .map(parsePoint).persist()
    var w = //随机初始向量for(i <- 1to ITERATIONS){
      val gradient = points.map{p =>
        p.x * (1/(1+exp(-p.y*(w dot p.x)))-1)*p.y
      }.reduce((a,b) => a+b)
      w -= gradient
    }
     

     

     

     

     

     

     

           我们一开始定义了一个缓存RDD——points,作为在一个文本文件上调用map转换的结果,即把文本的每行都解析为Point对象。然后在points上运行mapreduce来计算梯度,在每一步对当前w的函数求和。把points保存在内存中迭代能提高20倍的速度,我们将在6.1节可以看到。

    3.2.2 网页排名

           在网页排名中会出现更加复杂的数据共享模式。算法通过把链向每个页面的所有页面的贡献值(contributions)加起来,迭代地更新每个页面的rank。在每次迭代过程中,每个页面给周围页面发送r/n个contribution,这里r是它的秩,n是周围文件的个数。接下来,它把它的秩更新为αN+(1−α)ciαN+(1−α)∑ci,其中求和是对它接收到的贡献值,N是页面个数。在Spark中我们可以把网页排名写成如下代码:

    val links = spark.textFile(...).map(...).persist()
    var ranks = //(URL, rank)对的RDDfor(i <- 1 to ITERATIONS){
    //根据每个页面发送过来的贡献值创建(targetURL, float)对的RDD,
    val contibs = links.join(ranks).flatMap{
      (url, (links, rank)) =>
      links.map(dest => (dest, rank/links.size))
      }
      //根据URL对贡献值求和,并获取新的秩
      ranks = contibs.reduceByKey((x,y) => x+y)
                     .mapValues(sum => a/N+(1-a)*sum)
    }
     
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
     

     

     


           这个程序会生成如图3中的RDD血缘图。每一步迭代过程,我们都会基于上一个迭代器的contribs、ranks和静态的links集合创建一个新秩集合(秩更新了)。这个图有一个特征:随着迭代次数的增加,图会变得越来越长。因此,在一个拥有很多迭代步骤的作业中,有必要可靠复制ranks的一些版本以减少故障恢复次数。用户可以调用带可靠标识的persist来达到目的。值得注意的是,links集合不需要被复制,因为它的分区可以通过在输入文件块上重新运行map操作来重建。这个数据集将比ranks大,因为每个文件有很多链接但只有一定数量会作为它的秩,以致于在系统上使用lineage比检查点检查程序整个内存状态来恢复要更快。 
           最后,我们可以通过控制RDDs的分区来优化网页排名中的通信。如果我们为links指定一个分区方式(如根据URL对link列表跨节点哈希分区),我们则可以以相同的方式对ranks分区,并确保links和ranks的join操作不需要通信(因为每个URL的秩将会与它的link列表在相同的机器上)。我们也可以写一个Partitioner类把相互连接的页面聚在一起(比如按域名对URL分区)。这两种优化可以表示为在定义links时调用partitionBy:

    links = spark.textFile(...).map(...)
    .partitionBy(myPartFunc).persist()
    •        该初始化调用后,links和ranks的join操作将自动把每个URL的贡献值聚合到它link列表所在的机器上,在那计算它的新秩,并join它和它的links。这类多次迭代的一致性分区是指定框架(Pregel)中主要优化方式之一。RDDs让用户直接表达他的目的。

    4 代表RDDs

           把RDDs作为一个抽象会有一个问题:为它们选择一个代表在广泛的transformations中能追踪血缘。理想情况下,一个实现RDDs的系统应该提供尽可能丰富的转换算子,并让用户以任意方式组合它们。我们为RDDs提出一个简单的基于图的代表以达到这些目的。我们已经在Spark中使用这个代表去支持广泛的transformations,而且不会为任何transformation去给调度器添加特殊逻辑,这极大地简化了系统设计。 
           简而言之,我们了一个通用接口去代表每个RDD,该接口表达五种信息:

    • 一组分区(partitons),数据集的原子组成
    • 一组父RDDs上的依赖(dependencies
    • 一个基于父数据集计算的函数
    • 分区策略的元数据
    • 数据位置策略

    例如,一个RDD表示一个HDFS文件的每个块都有一个分区,并且知道每个块在哪台机器上。同时,在这个RDD上执行map操作后的结果分区不变。我们把这个接口总结在表3中。

    操作

    含义

    partitions()

    返回Partiton对象的列表

    preferredLocations(p)

    列出p分区由于数据局部性可以被快速访问的节点

    dependencies()

    返回依赖列表

    iterator(p, parentIters)

    根据为父分区指定的迭代器,逐个计算p分区的元素

    partitioner()

    返回RDD是否是hash/range分区的元数据信息

    表3:Spark中用于表示RDDs的接口

           在设计这个接口时最有趣的问题是怎样在RDDs间表示依赖。我们发现把依赖分成两类足够了,并且很有用。

    • 一类是窄依赖。父RDD的每个分区被子RDD的至多一个分区使用。
    • 一类是宽依赖。多个子分区依赖于一个父分区。

    例如,map操作会发生窄依赖,join操作发生宽依赖(除非父RDD是哈希分区)。图4显示了其他例子。 


     
    宽窄依赖的例子。每个空心框代表一个RDD,里面的阴影矩阵代表分区。 


           这个区别是有用的,有两个原因。第一,窄依赖考虑到了一个节点上的流水线执行。例如,在一个个元素上先应用filter然后map。相反,宽依赖需要父分区的所有数据可用,并用一个类似于MapReduce的操作在节点间shuffle。第二,窄依赖使节点故障后恢复更有效,因为只有丢失的父分区需要被重新计算,并且可能在不同节点上并行计算。相反,在宽依赖的血缘图中,单一的故障节点可能导致一个RDD所有祖先的一些分区丢失,需要一个完全的重新执行。 
           这个RDDs通用接口在Spark中实现的大部分transformations都少于20行代码。甚至Spark新用户在不知道调度器的细节的情况下都能够实现新的transformations(如sampling和各种join)。下面写了一些RDD实现。

    HDFS files:我们采样的输入RDDs都是来自于HDFS中的文件。对于这些RDDs,partitions返回文件每个块的分区(块的偏移量存在于每个Partition对象中)。preferredLocations给出块所在节点和读块的迭代器。

    map:在任何RDD上调用map都会返回MappedRDD对象。这个对象和它的父RDD有相同的分区和首选位置。map的参数是一个函数,对于父RDD中的所有记录,将以iterator方法的方式执行这个函数。

    union:对两个RDD调用union会返回一个分区为父RDD分区的联合的RDD。每个子分区都是在相应的父分区上进行窄依赖计算得到的。

    sample:采样类似于映射,除了RDD会为每个分区保存一个随机数生成种子以确定性地采样父分区记录。

    join:join两个RDD可能会产生两个窄依赖(如果他们具有相同的hash/range分区),可能是两个宽依赖,也可能都有(如果一个父RDD有分区,另一个没有)。

    5 实现

           我们用大约14000行Scala代码实现了Spark。系统运行在Mesos集群管理器上允许通Hadoop,MPI和其他应用分享资源。每个Spark程序都作为独立的Mesos应用运行,它有自己dirver(master)和workers,并且在这些被Mesos处理的应用中共享资源。 
           Spark可以从任何Hadoop输入源读取数据(比如HDFS、HBase),只需要使用Hadoop已存在的插件的API,在Scala的未修改版本上运行。 
           我们大致说几个该系统技术上比较有趣的部分:任务调度(5.1节),Spark解释器允许交互式使用(5.2节),内存管理(5.3节),支持检查点(5.4节)。

    5.1 工作调度

           Spark的调度器使用了RDDs的表示,在第4节已经描述过了。 
           总而言之,我们的调度器与Dryad的类似,但它另外还考虑了持久化的RDDs的哪些分区在内存中可用。无论何时用户运行在RDD上运行action,调度器都会检查RDD的血缘图,建立由stages组成的DAG,然后执行,如图5的插图。每个阶段(stage)包含尽可能多的窄依赖流水线转换(transformations)。stages的边界是宽依赖shuffle操作,或者任何已经计算过的分区,它可以截断父RDD的计算。然后,调度器在每个stage中运行任务去计算丢失的分区,知道计算出想要的RDD。 
           调度器基于数据存放位置使用延迟调度给机器指派任务。如果一个任务需要处理节点内存中可用的分区,我们就把它发送给那个节点。但是,如果处理的分区位于多个可能的位置(如HDFS文件),则把任务发送给这些节点。 
           对于宽依赖(即shuffle依赖),我们一般把中间结果物化在持有父分区的节点上,以简化故障恢复,很像MapReduce物化map的输出结果。 
           如果一个任务失败,只要它的stage的父分区还可用,我们将在另一个节点上重新运行它。如果一些stages已经不可用(例如,由于一个shuffle的map输出结果丢失了),我们会重新提交任务去并行地计算丢失分区。我们还不能对调度器故障容错,但是复制RDD血缘图是直截了当的做法。 
           最后,虽然Spark中所有当前运行的计算都对驱动程序中调用的actions响应,我们也会试验让集群上的任务(如maps)调用lookup操作,该操作允许按关键字随机访问哈希分区的RDDs的元素。在这种情况下,任务需要告诉调度器去计算哪些丢失的分区。

    5.2 解释器的集成

           Scala包含一个类似于Ruby和Python的交互式shell。考虑到实现内存中数据带来的低延迟,我们希望让用户在解释器上交互式地运行Spark,查询大数据集。 
           Scala解释器通常把用户输入的代码行编译成一个类,然后加载到JVM,之后调用类的函数。这个类包括一个单例对象(单例对象包含那行代码的变量或方法),并且在一个初始化函数中运行那行代码。例如,如果用户写入
    var x = 5,接下来println(x),解释器会定义包含x的Line1类,并让第二行编译成println(Line1.getInstance().x)。 
           我们对Spark中的编译器做了两点改变:

    • 类传输:为了让工作节点获取每行代码上创建的类的字节码,我们使解释器基于HTTP传输这些类。
    • 改进的代码生成逻辑:一般地,每行代码生成的单例对象是通过相应的类上的一个静态方法去访问的。这意味着当我们序列化一个引用了前一行定义的变量的闭包时(如上面例子中的Line1.x),Java将不会通过对象图跟踪而传输包装xLine1实例。因此,工作节点将不接受x。我们把代码生成逻辑改成了直接引用每行对象的实例。

           图6显示在做了上面两个改变后,解释器怎样把用户写的一系列代码行翻译成Java对象。 


     
    显示解释器怎样把用户输入的两行代码翻译成Java对象 


           我们发现Spark解释器便于处理大量跟踪关系,也便于研究HDFS中保存的数据集。我们也计划交互式地运行更高级的查询语言,如SQL。

    5.3 内存管理

           Spark对于持久化RDDs提供了三个选项:

    • 序列化成Java对象存储在内存中
    • 作为序列化数据存储在内存中
    • 存储在磁盘上

    第一个选项性能最快,因为JVM能在本机访问每个RDD元素。第二个选项让用户在内存空间有限时,选择比Java对象图更加有效的存储方式,性能会差一点。第三个选项对于那些太大而无法存入内存的RDDs是有用的,但是每次使用都需要重新计算,这很耗时。 
           为了管理有限的可用内存,我们基于RDDs的级别使用LRU淘汰策略。当计算一个新的RDD分区,而又没有足够的空间存储它时,我们淘汰一个最近最少访问RDD的分区,除非这个RDD和新分区的一样。在这种情况下,我们把旧分区存入内存以防止相同RDD的分区循环读入和写出。这很重要,因为大多数操作将在整个RDD上运行任务,所以很可能以后会需要用到一直在内存中的分区。我们发现,目前为止这个默认的策略在我们的应用中很好地工作,我们通过每个RDD的“持久化优先级“,让用户进一步控制RDD。 
           目前,集群上Spark的每个实例都有自己独立的内存空间。未来,我们打算研究通过统一的内存管理实现在Spark实例间共享RDDs。

    5.4 支持检查点(Checkpointing)

           虽然血缘图总是被用于在故障后恢复RDDs,但这样的恢复在血lineage链很长的时候会很耗时。因此,把一些RDD执行检查点操作存入稳定内存十分有用。 
           一般地,检查点对于Lineage图长、宽依赖的RDDs很有用,如3.2.2节中PageRank例子中的rank集合。在这些情况下,集群中节点故障可能导致会每个父RDD的一些数据分片丢失,这就需要完全重新计算,检查点操作在这里就可以避免完全重新计算。相反,对于稳定存储数据上的窄依赖RDDs,检查点没什么价值。如果节点故障,这些RDDs丢失的分区可以并行地在其他节点上计算,成本比复制整个RDD要少得多。 
           Spark目前为检查点提供了一个API(给persist传入REPLICATE标识),把checkpoint哪个数据的决定权留给了用户。然而,我们也研究了怎样实现自动的检查点。因为我们的调度器知道每个数据集的大小,也知道第一次计算花费的时间,所以它应该能选择一个优化的RDDs集合执行检查点操作,最小化系统恢复时间。 
           最后,值得注意的是RDDs的只读属性使检查点操作比常见的共享内存更简单。因为不需要关注一致性,RDDs可以在不需要程序中断或分布式快照方案的情况下在后台写出。

    6 评测

           我们再Amazon EC2上做了一系列实验,以此来评估Spark和RDDs,并与其他用户应用程序的基准做了对比。总之,我们的结果如下:

    • Spark在迭代机器学习和图像应用方面性能比Hadoop高20倍。速度的提升的原因是,把数据作为Java对象存入内存中避免了I/O和反序列化的成本。
    • 用户所写应用执行效果好。我们使用Spark对原来在Hadoop上运行的分析报告提升了40倍。
    • 当节点故障,Spark可以通过只重建丢失的RDD分区来快速恢复。
    • Spark用于交互式地查询1TB数据集,只有5-7s的延迟。

           我们将在6.1节呈现与Hadoop对比的迭代机器学习应用的基准,6.2节呈现对比后的PageRank。然后,6.3节评估Spark中故障恢复,6.4节呈现数据集在内存不足时的行为。最后,6.5节讨论用户应用程序的结果,6.6节交互式数据挖掘。 
           除非另有说明,我们的测试使用m1.xlarge EC2节点,4核,15G内存。我们使用HDFS存储,块大小256M。在每个测试之前,为了准确地测量IO成本,我们清理了操作系统缓存。

    6.1 迭代机器学习应用

           我们实现了两个迭代机器学习应用,逻辑回归和k-means,为了比较下面系统的性能:

    • Hadoop:Hadoop0.20.0稳定版本
    • HadoopBinMem:一个Hadoop部署。第一次迭代时,把输入数据转换成低开销二进制格式,以消除在之后迭代过程的文本解析,并把它存入内存中的HDFS实例。
    • Spark:RDDs的实现。

           我们用25-100台机器在100GB的数据集上对这两个算法进行了10次迭代。两个应用程序的主要区别在于他们执行数据每个字节的计算的数量。k-means的迭代时间主要取决于计算,但逻辑回归不是计算密集型的,因此时间更多地花费在反序列化和I/O上。 
           由于经典的学习算法需要几十次迭代才能收敛,所以我们在报告时间时,把首轮迭代的时间与后续迭代的时间分开。我们发现经RDDs共享数据极大地加快了后面的迭代。 


     
    图7:图表示了逻辑回归和k-means两种算法分别在Hadoop、HadoopBinMem和Spark三种集群中的首轮迭代和后续迭代的时长。实验是在有100个节点的集群上对100GB数据进行的。 
    图8:Hadoop、HadoopBinMem和Spark上后续迭代的运行时间。 


    首轮迭代 三个系统在首轮迭代时都从HDFS中读取文本输入。如图7中的浅色长方形所示,实验中Spark比Hadoop更快。这个不同是因为在Hadoop的master和workers之间的心跳协议中的通信开销。HadoopBinMem是最慢的,因为它运行了一个额外的MapReduce工作去把数据转成二进制的,它必须通过网络把这个数据写向一个复制的内存HDFS实例。 
    后续迭代 图7也显示了后续迭代的平均运行时间,图8显示了随着集群大小的变化是运行时间的分布情况。对于逻辑回归,在100台机器上,Spark比Hadoop快25.3倍,比HadoopBinMem快20.7倍。对于更加计算密集型的k-means应用,Spark有1.9到3.2倍的提速。 
    理解速度 我们惊讶地发现,Spark甚至都超过了基于内存存储二进制数据的Hadoop(HadoopBinMem)20多倍。在HadoopBinMem中,我们使用了Hadoop的标准二进制格式(SequenceFile)和256MB大的块,我们还强制HDFS的数据直接存放在内存文件系统。然而Hadoop仍然运行缓慢,有以下几个因素:

    1. Hadoop软件栈的最小开销
    2. 提供数据时HDFS的开销
    3. 把二进制记录转换成可用的内存Java对象的反序列化成本

           我们来依次研究这几个因素。为了衡量(1),我们运行没有操作的Hadoop作业,然后发现,仅仅完成作业设置,启动任何和清理工作的最小需求就需要花费至少25s的开销。对于(2),我们发现HDFS为每个块提供多次内存拷贝和计算校验和的操作。 
           最后,为了测量(3),我们在单机上运行微基准程序,在256MB多种格式的输入上运行逻辑回归计算。尤其,我们比较了来源于HDFS(这里将体现出HDFS栈的开销)和内存本地文件(内核能够非常有效地把数据传递给程序)的文本输入和二进制输入的处理时间。 
           我们在图9中展示了这些实验的结果。内存中的HDFS和本地文件的区别显示,从HDFS读取数据会多花费2s的开销,甚至数据就在本地机器的内存中。文本输入和二进制输入的区别表明,解析的开销相差7s。甚至当从内存文件读取数据时,把预解析的二进制数据转成Java对象都要花费3s,这几乎和逻辑回归本身的成本一样。而Spark通过在内存中把RDD元素直接存成Java对象,避免了以上所有开销。

    6.2 PageRank

           我们使用了54GB维基百科数据,比较分别在Spark和Hadoop上实现PageRank的性能。我们运行10轮PageRank算法去处理大约4百万文章的链接图。图10显示在30台节点上,只基于内存存储时,Spark比Hadoop快2.4倍。另外,控制RDDs的分区方式使整个迭代过程保持一致,如3.2.2节所讨论的,提升速度至7.4倍。扩展到60台机器,结果也随之近于线性地减少。 


     
    图10: 在Hadoop和Spark上PageRank的性能 


           我们也评估了PageRank的两一个版本——用Pregel在Spark上实现,我们再7.1节进行描述。迭代时间与图10类似,但是长了4s,因为Pregel会在每次迭代额外运行一个操作,这个操作让顶点“投票”是否结束作业。

    6.3 故障恢复

           我们对k-means应用评估了其在单点故障后,使用lineage重建RDD分区的成本。图11比较了在75个节点的集群上k-means10轮迭代在正常情况下和一个节点在第六轮迭代的开始时故障的情况下的运行时间。没有任何故障,每轮迭代会运行400各任务处理100GB数据。 


     
    k-means存在故障时的迭代时间。在第六轮迭代开始时kill掉一台机器导致使用lineage部分重构RDD。 


           直到第五轮迭代结束,迭代时间都是大约58s。在第六轮迭代,一台机器被kill掉,导致运行在该机器上的任务和存储该机器上的RDD分区的丢失。Spark在其他机器上并行地重新运行这些任务,他们在这些机器上重新读取相应的输入数据并通过lineage重构RDDs,这会让迭代时间增至80s。一旦丢失的RDD分区被重建,迭代时间将降回到58s。 
           值得注意的是,基于检查点的故障恢复机制,恢复将可能需要运行至少几轮迭代,取决于检查点操作的频率。更进一步说,系统将需要通过网络复制应用的100GB工作集(文本输入数据转成二进制),要么消费两次Spark内存去复制它到内存中,要么将不得不等到100GB写入磁盘。相反地,我们例子中RDDs的血缘图都是小于10KB的。

    6.4 内存不足时的行为

           目前为止,我们确保每个集群中每台机器有足够内存存储迭代中所有的RDDs。一个自然的问题是,如果没有足够的内存去存储作业的数据时Spark怎样运行。在这个实验中,我们配置Spark在每台机器上不是用超过一定百分比的内存去存储RDDs。我们在图12中展示逻辑回归在多种百分比内存空间下的运行结果。我们看见随着空间变小性能缓慢下降。 


    6.5 基于Spark建立的用户应用

    内存分析 Conviva Inc(一家视频发行公司)使用Spark加快了数据分析报告的数据,以前是基于Hadoop上运行的。举个例子,一个报告被作为一系列Hive查询运行为客户计算多种统计。这些查询全都是基于数据的相同子集(记录匹配用户提供的过滤器),但在不同分组的字段上执行聚合(averages, precentiles和COUNT DISTINCT)操作需要独立的MapReduce作业。在Spark中实现上述查询,并把数据子集一次加载到RDD中,该公司能够对报告提速40倍。一个基于200G压缩数据的报告在Hadoop集群上运行要花费20小时,现在仅仅只需要2台Spark机器就可以运行在30分钟以内。更进一步,Spark程序只需要96GB的RAM,因为它只把匹配用户过滤器的行和列存入RDD,而不是所有解压文件。 
    交通建模 在Berkeley的Mobile Millennium项目中,研究人员基于分散的汽车GPS测量,并行化一个学习算法去预测道路交通阻塞情况。源数据是城市的10000个互联的道路网,还有600,000由装备GPS的汽车采集到的点到点的行驶时间的样本(每条路线的形式时间可能包括多条互联的道路)。使用交通模型,系统可以估计跨交通网花费的时间。研究人员用一个期望最大化算法训练这个模型,这个算法迭代地重复两次mapreduceByKey步骤。这个应用近乎线性地从20个节点扩展到80个节点,每个节点4核,如图13(a)所示。 


     
    图13:用Spark实现的两个用户应用程序每次运行时间。错误条显示标准差。 


    Twitter垃圾分类 伯克利的Monarch项目用Spark识别Twitter信息中的垃圾链接。他们在Spark之上实现了一个逻辑回归分类器,和6.1节中例子类似,但他们使用分布式的reduceByKey对并行的梯度向量求和。在图13(b)中,我们展示了在超过50GB数据上训练一个分类器的扩展结果,数据包括250000URLs和10^7与网络相关的特征/维度和在每个URL的页面的内容属性。缩放不是接近线性的原因是每次迭代都会有更高的固定通信成本。

    6.6 交互式数据挖掘

           为了证明Spark在交互查询大数据集方面的能力,我们用它去分析1TB的维基百科页面访问日志(2年的数据)。这个实验,我们用8核、68GB内存的100m2.3xlarge EC2实例。我们运行查询以获得以下内容总访问次数(1)所有页面,(2)标题能精确匹配给定关键字的页面,(3)标题部分匹配关键字的页面。每个查询会扫描整个输入数据。 
           图14显示的是在整个数据集、一半数据和十分之一数据的查询响应时间。甚至在1TB的数据上,Spark上的查询只需要花费5-7s。这比查询磁盘上的数据的速度快一个数量级以上。例如,从磁盘上查询1TB的文件花费了170s。这证明了RDDs使Spark更适用于交互式数据挖掘。 


     
    图14:在Spark上交互式查询的响应时间,在100台机器上扫描持续增大的输入数据集 

    7 讨论

           虽然,由于RDDs的不可变的性质和粗粒度转换,它们提供了一个限制的编程接口,但我们发现它们适用于广泛类别的应用。尤其,RDDs可以表达的集群编程模型数量惊人,这些集群编程模型目前为止都被作为独立框架提出,允许用户在一个项目(例如,运行一个MapReduce操作图建立一个图,然后在其上运行Pregel)中compose这些模型,并在他们之间分享数据。在这一节,我们将在7.1小节讨论RDDs可以表达哪些编程模型和为什么它们应用这么广泛。另外,我们在7.2小节讨论RDDs中lineage信息的另一个好处,它是为了方便在这些模型上调试。

    7.1 表达已有的编程模型

           RDDs可以有效地表达一些目前已经独立提出的集群编程模型。这里说有效地,我们的意思是RDDs不仅可以产生和这些模型相同的结果,还可以捕获这些框架执行的优化,如把指定的数据保存在内存中,对它进行分区以最小化通信并且高效地从故障中恢复。可以使用RDDs表达的模型包括: 
    MapReduce:这个模型可以通过在Spark使用flatMapgroupByKey操作,或者在有结合器时使用reduceByKey操作来表达。 
    DryadLINQ:DryadLINQ系统提供了比在更普通的Dryad运行时的MapReduce更广泛的算子。但是这些是直接对应于Spark中可用的RDD转换的所有大型算子(如map, groupByKey,join,etc)。 
    SQL:类似于DryadLINQ表达式,SQL需要在记录集上执行数据并行化操作。 
    Pregel:谷歌的Pregel是一个用于迭代图像应用的特殊化模型。最初看起来和其他系统的面向集合编程模型十分不同。在Pregel中,一个程序作为

    7.2 利用RDDs进行调试

           虽然我们最初把RDDs设计成容错的确定性重新计算,但这个属性也方便调试。

    8 相关工作

    集群编程模型: 集群编程模型相关工作主要有几类。 
           第一,数据流模型,如MapReduce、Drayad和Ciel,支持丰富的算子去处理数据,但通过稳定外部系统共享数据。RDDs表示的是一个比稳定存储更高效的数据共享抽象,因为它们避免了数据复制、I/O和序列化的成本。 
           第二,数据流系统的高级别编程接口,包括DryadLINQ和FlumeJava,提供语言集成APIs,它们可以让用户通过像mapjoin的算子操作“并行的集合”。然而,在这些系统,并行的集合要么代表磁盘上的文件,要么代表用来表达查询计划的临时数据集。即使,系统将在相同的查询中的算子间流水线化数据(如一个map接着另一个map),它们不能在查询间高效地共享数据。我们把Spark的API基于并行集合模型是因为它的便利,并且不主张新奇的语言集成接口,但是通过这个接口的背后提供RDDs作为存储抽象,我们允许它支持更广泛类型的应用。 
           第三类系统为需要数据共享的特别类型的应用提供高级别接口。例如,Pregel支持迭代图像应用,而Twister和HaLoop迭代的MapReduce运行时系统。然而,这些框架对它们支持的计算类型隐式地执行数据共享,也不提供一个普遍地抽象让用户可以在他选择的操作间去共享他们选择的数据。例如,一个用户不能用Pregel或者Twister去把数据集加载到内存中,然后决定在它上面运行去查询什么。RDDs显示地提供一个分布式存储抽象,并可以支持这些特定系统不包括的应用,如交互式数据挖掘。 
           最后,一些系统暴露出共享可变状态以允许用户执行内存中的计算。例如,Picco让用户运行变形的函数读和更新分布式哈希表中的单元分布式共享。分布式共享内存系统和键值存储提供相似的模型。RDDs以两种方式区别这些系统。第一:RDDs提供一个高级别编程接口,接口基于如map/sort这些算子。而Piccolo和DSM中的接口仅仅是读和更新到表的单元中。第二,Piccolo和DSM系统通过检查点和回滚实现恢复,这比RDDs基于lineage的策略更耗费性能。最终,如2.3节所讨论的,RDDs也提供其他优点。 
    缓存系统:Nectar能够通过识别带有程序分析的子表达式,在DryadLINQ作业间重用中间结果。把这种功能添加到基于RDD的系统将是引人入胜的。然而,Nectar不提供内存缓存(它把数据存放在分布是文件系统中),也不让用户显示地控制持久化哪些数据集和怎样对数据集分区。Ciel和FlumeJava同样可以缓存任务结果,但是却不提供内存缓存和显示控制缓存数据。 
           Ananthanarayanan et al.提出给分布式文件系统添加一个内存缓存,以利用数据访问的时空本地化。虽然这个解决方案能够更快地访问在文件系统中的数据,但是它不像RDDs那样可以高效地在应用中共享中间结果,因为在stage间它仍然需要应用去把这些结果写到文件系统。 
    Lineage :对于一些应用,如需要说明结果的、允许其他应用复制的、如果在工作流中发现bug或者数据及丢失而导致的重新计算数据的,获取数据的血缘或出处信息一直都是科学计算和数据库的研究主题。RDDs提供了并行化编程模型,它的细粒度血缘较容易获取,所以它可以被用于故障恢复。 
           我们的基于lineage恢复机制类似于MapReduce和Dryad中计算(作业)内使用的恢复机制,它在任务的DAG中追踪依赖。但在这些系统中,血缘信息在作业结束时被丢弃,需要使用备份存储系统跨计算分享数据。相反,RDDs把血缘应用于跨计算持久化内存中的数据,没有复制和磁盘I/O的开销。 
    关系型数据库:RDDs概念上类似于数据库中的试图,持久化RDDs类似于物化试图。但,像DSM系统,数据库一般允许对所有的记录进行细粒度的读写访问,需要记录操作和数据来容错,并需要保持一致性的额外开销。

    9 结论

           我们已经介绍了RDDs,一个用于在集群应用中共享数据的高效的、普遍用途的、容错的抽象。RDDs能表达广发的并行应用,包括很多特殊的编程模型,已经提出用于迭代计算和这些模型不包含的新应用。已存在的集群存储抽象需要为容错而复制数据,而RDDs与此不同,RDDs提供一个基于粗粒度转换的API,让它们用lineage高效地恢复数据。我们已经在Spark中实现RDDs,运行迭代应用速度提升20X,可以用于交互式查询几百GB数据。我们已经开源Spark。

    致谢

     

    展开全文
  • GlusterFS集群文件系统研究

    万次阅读 热门讨论 2011-03-28 21:01:00
    GlusterFS是Scale-Out存储解决方案Gluster的核心,它是一个开源的分布式文件系统具有强大的横向扩展能力,通过扩展能够支持数PB存储容量和处理数千客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的...
  • 基于开源软件构建高性能集群NAS系统

    万次阅读 多人点赞 2011-12-29 22:32:33
    大数据时代的到来已经不可阻挡,面对数据的爆炸式增长,尤其是半结构化数据和非结构化数据,NoSQL...集群NAS是一种横向扩展(Scale-out)存储架构,具有容量和性能线性扩展的优势,已经得到全球市场的认可。从EMC对ISI
  • 集群系统实现方案详解 一、集群的基本概念 <br />  有一种常见的方法可以大幅提高服务器 的安全 性,这就是集群。 <br />  Cluster集群技术可如下定义:一组相互独立的服务器 在网络中...
  • 三、集群系统基础

    千次阅读 2018-05-14 19:21:59
    当前云计算技术领域存在两个主要技术路线,一个是基于集群技术的云计算资源整合技术,另一个是基于虚拟机技术的云计算资源切分技术。 基于集群技术的云计算资源整合技术路线将分散的计算和存储资源整合输出,主要...
  •  Cluster集群技术可如下定义:一组相互独立的服务器在网络中表现为单一的系统,并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。 大多数模式下,集群中所有的计算机拥有一个共同的名称,...
  • Cluster集群技术可如下定义:一组相互独立的服务器在网络中表现为单一的系统,并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。大多数模式下,集群中所有的计算机拥有一个共同的名称,集群内...
  • 面对现在的ddos和黑客数据的破坏,及服务器自身的故障,集群系统将大幅提高服务器的安全性。 我们在入侵虚拟主机的过程中,经常有一些不可思议的事情发生,如,明明将文件写入服务器,可是在web上就是找不到。 我们...
  • Linux 服务器集群系统实现方案详解

    千次阅读 2008-01-31 03:44:00
    Cluster集群技术可如下定义:一组相互独立的服务器在网络中表现为单一的系统,并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。 大多数模式下,集群中所有的计算机拥有一个共同的名称,...
  • 如何服务器集群系统实现方案详解

    千次阅读 2007-12-03 23:38:00
    Cluster集群技术可如下定义:一组相互独立的服务器在网络中表现为单一的系统,并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。 大多数模式下,集群中所有的计算机拥有一个共同的名称,...
  • RDD:基于内存的集群计算容错抽象

    千次阅读 2016-01-12 11:57:13
    (注意这里的DSM,不仅指传统的共享内存系统,还包括那些通过分布式哈希表或分布式文件系统进行数据共享的系统,比如Piccolo[28])DSM是一种通用的抽象,但这种通用性同时也使得在商用集群上实现有效的容错性更加...
  • Linux 集群文件系统简介

    千次阅读 2015-12-28 22:15:45
    集群应用程序具有各种级别的成熟度和功能。它们包括:  高性能 集群也称为并行集群或计算集群,通常用于那些支持大量计算处理的系统。在这些集群中,并行文件系统在节点间分配处理资源,因而允许每个节点通过并发...
  • 通常根据不同的系统配置方法而采用相应容错技术:单机容错技术 、 双机热备份技术和服务器集群技术。 1 单机容错技术 容错技术是保证系统在某些组成部分出现故障或差错时仍能正常工作的技术。系统的故障可分为两类:...
  • 亿级Web系统的高容错性实践

    千次阅读 2018-03-23 10:57:54
    原文地址:https://blog.csdn.net/linuxnews/article/details/51371338背景介绍大概三年前,我在腾讯负责的活动...后来,当时的老领导对我说:你不能总扮演一个“救火队长”的角色, 要尝试从系统整体层面思考产生...
  • MC/SG集群系统概述

    千次阅读 2015-12-30 17:58:34
    更新换代的标志主要有两个:一个是计算机的器件,另一个是系统体系结构。从第一代到第五代计算机,器件发生了根本的变化:从电子管、晶体管发展到集成电路,而集成电路又经小规模、中规模、大规模、非常大规模等阶段...
  • 大规模集群管理系统Google Borg

    千次阅读 2016-07-01 15:12:02
    Borg是Google的集群管理系统,管理着多个由成千上万台机器组成集群,上面运行着10万+的任务和上千种不同类型的应用。它组合了诸如提交控制,高效的任务包装,过量提交,进程级性能隔离的机器共享等这些方法来获取高...
  • 集群资源调度系统设计架构总结

    千次阅读 2018-04-04 10:50:14
    集群资源调度系统设计架构总结 之前为完成《AWS 下 Kylin 调度系统的设计》(https://io-meter.com/2017/10/13/kylin-aws-scheduler-system/),阅读了大量 集群资源管理和任务调度的资料和论文。了解了如...
  • Linux集群文件系统简单介绍

    千次阅读 2013-11-18 08:51:10
    集群文件系统在多个方面完善了 Oracle RAC 的数据库集群功能。  以下是它们的对比情况。  通常,集群只是一组作为单一系统运行的服务器(PC 或者工作站)。但是,这个定义的外延不断显着扩大;集群技术现在...
  • 集群

    2009-05-04 17:00:00
    简单的说,集群(cluster)就是一组计算机,它们...并且集群系统的管理员可以随意增加和删改集群系统的节点。 1)为同一种或若干种生物在某种程度上恒定地占据某一地区的,广泛的且具有社会性微细差异的用词。因而该
  • 实际上,我们发现,RDDs可以有效地用于表示迄今为止被提出作为独立系统的很多集群编程模型,包括MapReduce,DryadLINQ,SQL,Pregel和HaLoop,以及这些系统未捕获的新应用程序,如交互式数据挖掘 。我们认为,RDDs...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 36,754
精华内容 14,701
关键字:

具有容错功能的集群系统