存档

2010年2月 的存档

轻松搞定CentOS+Nginx+PHP+MySQL标准生产环境

2010年2月27日 没有评论

PHP 5.3.1

MySQL 5.0.89

Nginx 0.8.33 或 0.7.65 (可选)

这个可比网上流传的什么一键安装包要好得多,强烈推荐此法安装,适合所有菜鸟和高手。我服务器上全用的源代码编译安装,也好不到哪去,还很费劲。我这个装完已经包含 php 的一些常用扩展, PDO,eaccelerator,memcache,tidy等等。

CentOS 最小化安装,然后先新建一个 repo

# vi /etc/yum.repos.d/centos.21andy.com.repo

放入如下内容

[21Andy.com]
name=21Andy.com Packages for Enterprise Linux 5 – $basearch
baseurl=http://www.21andy.com/centos/5/$basearch/
enabled=1
gpgcheck=0
protect=1

启用 EPEL repo

CentOS i386 输入如下命令

rpm -ihv http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

CentOS x86_64 输入如下命令

rpm -ihv http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm

然后导入key

rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL

复制代码

OK,一键安装吧

yum -y install nginx mysql-server php-fpm php-cli php-pdo php-mysql php-mcrypt php-mbstring php-gd php-tidy php-xml php-xmlrpc php-pear php-pecl-memcache php-eaccelerator

最后 yum -y update 一下,全是最新的

如果 nginx 你要用 0.7.65 最新稳定版,把

yum -y install nginx

换成

yum -y install nginx-stable

就可以了

装完你已经可以这样玩了

service mysqld start

service php-fpm start

service nginx start

别忘了设置开机启动

chkconfig –level 345 mysqld on

chkconfig –level 345 php-fpm on

chkconfig –level 345 nginx on

配置文件都在 /etc 下自己找

看看安装多自动

  Dependencies Resolved

   ==========================================================
   Package Arch Version Repository Size
   ==========================================================
   Installing:
   mysql x86_64 5.0.89-1.el5 21Andy.com 3.5 M
   mysql-server x86_64 5.0.89-1.el5 21Andy.com 10 M
   nginx x86_64 0.8.33-3.el5 21Andy.com 422 k
   php-cli x86_64 5.3.1-2.el5 21Andy.com 2.4 M
   php-eaccelerator x86_64 2:0.9.6-1.el5 21Andy.com 118 k
   php-fpm x86_64 5.3.1-2.el5 21Andy.com 1.2 M
   php-gd x86_64 5.3.1-2.el5 21Andy.com 110 k
   php-mbstring x86_64 5.3.1-2.el5 21Andy.com 1.1 M
   php-mcrypt x86_64 5.3.1-2.el5 21Andy.com 27 k
   php-mysql x86_64 5.3.1-2.el5 21Andy.com 84 k
   php-pdo x86_64 5.3.1-2.el5 21Andy.com 91 k
   php-pear noarch 1:1.9.0-1.el5 21Andy.com 420 k
   php-pecl-memcache x86_64 2.2.5-3.el5 21Andy.com 44 k
   php-tidy x86_64 5.3.1-2.el5 21Andy.com 31 k
   php-xml x86_64 5.3.1-2.el5 21Andy.com 115 k
   php-xmlrpc x86_64 5.3.1-2.el5 21Andy.com 48 k
   Installing for dependencies:
   gmp x86_64 4.1.4-10.el5 base 201 k
   libXaw x86_64 1.0.2-8.1 base 329 k
   libXmu x86_64 1.0.2-5 base 63 k
   libXpm x86_64 3.5.5-3 base 44 k
   libedit x86_64 2.11-2.20080712cvs.el5 epel 80 k
   libmcrypt x86_64 2.5.8-4.el5.centos extras 105 k
   libtidy x86_64 0.99.0-14.20070615.el5 epel 140 k
   php-common x86_64 5.3.1-2.el5 21Andy.com 554 k
   sqlite2 x86_64 2.8.17-5.el5 21Andy.com 165 k
   t1lib x86_64 5.1.1-7.el5 epel 208 k
   Updating for dependencies:
   libevent x86_64 1.4.12-1.el5 21Andy.com 129 k

   Transaction Summary
   ==========================================================
   Install 26 Package(s)
   Update 1 Package(s)
   Remove 0 Package(s)

以下分别测试我本地的虚拟机和 VPS 上 Nginx + php-fpm 的性能

我的本机虚拟机测试,配置为PD930 双核3.0G,2G内存,给虚拟机分配的是 1G 内存,安装的系统为 CentOS 5.4 64bit

测试内容为

<?php phpinfo();?>

500 并发测试,CPU使用率到了30%,系统负载在10左右,页面打开还是飞快

[root@localhost ~]# webbench -c 500 -t 30 http://127.0.0.1/
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/
500 clients, running 30 sec.

Speed=223504 pages/min, 21806556 bytes/sec.
Requests: 111752 susceed, 0 failed.

2000 并发测试,CPU使用率35%,系统负载在18左右,页面打开还是飞快

[root@localhost ~]# webbench -c 2000 -t 30 http://127.0.0.1/
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/
2000 clients, running 30 sec.

Speed=429494 pages/min, 39004788 bytes/sec.
Requests: 214747 susceed, 0 failed.

5000 并发测试,CPU使用率30%,系统负载到了35,页面打还速度还不错,看了这数据,前些天说的那个1500万PHP请求也没啥了

[root@localhost ~]# webbench -c 5000 -t 30 http://127.0.0.1/
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/
5000 clients, running 30 sec.

Speed=788986 pages/min, 66952700 bytes/sec.
Requests: 394493 susceed, 0 failed.

还不过瘾,变态一下,10000并发

10000 并发,CPU使用还是不到30%,系统负载从60左右一直升到1000左右,晕死!居然还能打开!只是有点卡!负载到600多的时候居然不卡!疯了,我这还是虚拟机,webbench 还是在自己机上开的,汗,太强了

[root@localhost ~]# webbench -c 10000 -t 30 http://127.0.0.1/
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/
10000 clients, running 30 sec.

Speed=1513718 pages/min, -17973622 bytes/sec.
Requests: 756859 susceed, 0 failed.

而我的 VPS , 2G内存,8核CPU测试,但我不是使用上面的 yum 安装,而是全用源代码编译安装的,测试结果如下:

500并发,CPU使用率20%,负载2左右

# webbench -c 500 -t 30 http://127.0.0.1/index.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/index.php
500 clients, running 30 sec.

Speed=120520 pages/min, -36244332 bytes/sec.
Requests: 60260 susceed, 0 failed.

2000并发,CPU使用率20%左右,负载2左右,没啥变化

webbench -c 2000 -t 30 http://127.0.0.1/index.php
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/index.php
2000 clients, running 30 sec.

Speed=111454 pages/min, -44285944 bytes/sec.
Requests: 55727 susceed, 0 failed.

开到3000并发也一样,但打开页面要等几秒,突然一下出来,说明我进程开少了,还有余地。

现在我明白了前几天那个1500万PHP请求还能稳定访问是怎么回事了,哈哈,你只要CentOS 5.4 64bit,再按我上面的 yum 方法安装,也一样能顶住。

原文引用:http://www.21andy.com/blog/

分类: Linux 标签:

Hadoop分布式文件系统:架构和设计

2010年2月27日 没有评论

引言

        Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodity hardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时,它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统,适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问,非常适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束,来实现流式读取文件系统数据的目的。HDFS在最开始是作为Apache Nutch搜索引擎项目的基础架构而开发的。HDFS是Apache Hadoop Core项目的一部分。这个项目的地址是http://hadoop.apache.org/core/


前提和设计目标


硬件错误

      硬件错误是常态而不是异常。HDFS可能由成百上千的服务器所构成,每个服务器上存储着文件系统的部分数据。我们面对的现实是构成系统的组件数目是巨大的,而且任一组件都有可能失效,这意味着总是有一部分HDFS的组件是不工作的。因此错误检测和快速、自动的恢复是HDFS最核心的架构目标。


流式数据访问

      运行在HDFS上的应用和普通的应用不同,需要流式访问它们的数据集。HDFS的设计中更多的考虑到了数据批处理,而不是用户交互处理。比之数据访问的低延迟问题,更关键的在于数据访问的高吞吐量。POSIX标准设置的很多硬性约束对HDFS应用系统不是必需的。为了提高数据的吞吐量,在一些关键方面对POSIX的语义做了一些修改。


大规模数据集

        运行在HDFS上的应用具有很大的数据集。HDFS上的一个典型文件大小一般都在G字节至T字节。因此,HDFS被调节以支持大文件存储。它应该能提供整体上高的数据传输带宽,能在一个集群里扩展到数百个节点。一个单一的HDFS实例应该能支撑数以千万计的文件。


简单的一致性模型

      HDFS应用需要一个“一次写入多次读取”的文件访问模型。一个文件经过创建、写入和关闭之后就不需要改变。这一假设简化了数据一致性问题,并且使高吞吐量的数据访问成为可能。Map/Reduce应用或者网络爬虫应用都非常适合这个模型。目前还有计划在将来扩充这个模型,使之支持文件的附加写操作。


“移动计算比移动数据更划算”

        一个应用请求的计算,离它操作的数据越近就越高效,在数据达到海量级别的时候更是如此。因为这样就能降低网络阻塞的影响,提高系统数据的吞吐量。将计算移动到数据附近,比之将数据移动到应用所在显然更好。HDFS为应用提供了将它们自己移动到数据附近的接口。


异构软硬件平台间的可移植性

HDFS在设计的时候就考虑到平台的可移植性。这种特性方便了HDFS作为大规模数据应用平台的推广。


Namenode 和 Datanode

      HDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器,负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的Datanode一般是一个节点一个,负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间,用户能够以文件的形式在上面存储数据。从内部看,一个文件其实被分成一个或多个数据块,这些块存储在一组Datanode上。Namenode执行文件系统的名字空间操作,比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。

HDFS 架构

      Namenode和Datanode被设计成可以在普通的商用机器上运行。这些机器一般运行着GNU/Linux操作系统(OS)。HDFS采用Java语言开发,因此任何支持Java的机器都可以部署Namenode或Datanode。由于采用了可移植性极强的Java语言,使得HDFS可以部署到多种类型的机器上。一个典型的部署场景是一台机器上只运行一个Namenode实例,而集群中的其它机器分别运行一个Datanode实例。这种架构并不排斥在一台机器上运行多个Datanode,只不过这样的情况比较少见。

      集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者,这样,用户数据永远不会流过Namenode。


文件系统的名字空间 (namespace)

        HDFS支持传统的层次型文件组织结构。用户或者应用程序可以创建目录,然后将文件保存在这些目录里。文件系统名字空间的层次结构和大多数现有的文件系统类似:用户可以创建、删除、移动或重命名文件。当前,HDFS不支持用户磁盘配额和访问权限控制,也不支持硬链接和软链接。但是HDFS架构并不妨碍实现这些特性。

        Namenode负责维护文件系统的名字空间,任何对文件系统名字空间或属性的修改都将被Namenode记录下来。应用程序可以设置HDFS保存的文件的副本数目。文件副本的数目称为文件的副本系数,这个信息也是由Namenode保存的。


数据复制

      HDFS被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块,除了最后一个,所有的数据块都是同样大小的。为了容错,文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定,也可以在之后改变。HDFS中的文件都是一次性写入的,并且严格要求在任何时候只能有一个写入者。

        Namenode全权管理数据块的复制,它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该Datanode节点工作正常。块状态报告包含了一个该Datanode上所有数据块的列表。

HDFS Datanodes


副本存放: 最最开始的一步

      副本的存放是HDFS可靠性和性能的关键。优化的副本存放策略是HDFS区分于其他大部分分布式文件系统的重要特性。这种特性需要做大量的调优,并需要经验的积累。HDFS采用一种称为机架感知(rack-aware)的策略来改进数据的可靠性、可用性和网络带宽的利用率。目前实现的副本存放策略只是在这个方向上的第一步。实现这个策略的短期目标是验证它在生产环境下的有效性,观察它的行为,为实现更先进的策略打下测试和研究的基础。

      大型HDFS实例一般运行在跨越多个机架的计算机组成的集群上,不同机架上的两台机器之间的通讯需要经过交换机。在大多数情况下,同一个机架内的两台机器间的带宽会比不同机架的两台机器间的带宽大。

      通过一个机架感知的过程,Namenode可以确定每个Datanode所属的机架id。一个简单但没有优化的策略就是将副本存放在不同的机架上。这样可以有效防止当整个机架失效时数据的丢失,并且允许读数据的时候充分利用多个机架的带宽。这种策略设置可以将副本均匀分布在集群中,有利于当组件失效情况下的负载均衡。但是,因为这种策略的一个写操作需要传输数据块到多个机架,这增加了写的代价。

        在大多数情况下,副本系数是3,HDFS的存放策略是将一个副本存放在本地机架的节点上,一个副本放在同一机架的另一个节点上,最后一个副本放在不同机架的节点上。这种策略减少了机架间的数据传输,这就提高了写操作的效率。机架的错误远远比节点的错误少,所以这个策略不会影响到数据的可靠性和可用性。于此同时,因为数据块只放在两个(不是三个)不同的机架上,所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下,副本并不是均匀分布在不同的机架上。三分之一的副本在一个节点上,三分之二的副本在一个机架上,其他副本均匀分布在剩下的机架中,这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。

当前,这里介绍的默认副本存放策略正在开发的过程中。


副本选择

        为了降低整体的带宽消耗和读取延时,HDFS会尽量让读取程序读取离它最近的副本。如果在读取程序的同一个机架上有一个副本,那么就读取该副本。如果一个HDFS集群跨越多个数据中心,那么客户端也将首先读本地数据中心的副本。


安全模式

      Namenode启动后会进入一个称为安全模式的特殊状态。处于安全模式的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳信号和块状态报告。块状态报告包括了某个Datanode所有的数据块列表。每个数据块都有一个指定的最小副本数。当Namenode检测确认某个数据块的副本数目达到这个最小值,那么该数据块就会被认为是副本安全(safely replicated)的;在一定百分比(这个参数可配置)的数据块被Namenode检测确认是安全之后(加上一个额外的30秒等待时间),Namenode将退出安全模式状态。接下来它会确定还有哪些数据块的副本没有达到指定数目,并将这些数据块复制到其他Datanode上。


文件系统元数据的持久化

        Namenode上保存着HDFS的名字空间。对于任何对文件系统元数据产生修改的操作,Namenode都会使用一种称为EditLog的事务日志记录下来。例如,在HDFS中创建一个文件,Namenode就会在Editlog中插入一条记录来表示;同样地,修改文件的副本系数也将往Editlog插入一条记录。Namenode在本地操作系统的文件系统中存储这个Editlog。整个文件系统的名字空间,包括数据块到文件的映射、文件的属性等,都存储在一个称为FsImage的文件中,这个文件也是放在Namenode所在的本地文件系统上。

      Namenode在内存中保存着整个文件系统的名字空间和文件数据块映射(Blockmap)的映像。这个关键的元数据结构设计得很紧凑,因而一个有4G内存的Namenode足够支撑大量的文件和目录。当Namenode启动时,它从硬盘中读取Editlog和FsImage,将所有Editlog中的事务作用在内存中的FsImage上,并将这个新版本的FsImage从内存中保存到本地磁盘上,然后删除旧的Editlog,因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为一个检查点(checkpoint)。在当前实现中,检查点只发生在Namenode启动时,在不久的将来将实现支持周期性的检查点。

      Datanode将HDFS数据以文件的形式存储在本地的文件系统中,它并不知道有关HDFS文件的信息。它把每个HDFS数据块存储在本地文件系统的一个单独的文件中。Datanode并不在同一个目录创建所有的文件,实际上,它用试探的方法来确定每个目录的最佳文件数目,并且在适当的时候创建子目录。在同一个目录中创建所有的本地文件并不是最优的选择,这是因为本地文件系统可能无法高效地在单个目录中支持大量的文件。当一个Datanode启动时,它会扫描本地文件系统,产生一个这些本地文件对应的所有HDFS数据块的列表,然后作为报告发送到Namenode,这个报告就是块状态报告。


通讯协议

      所有的HDFS通讯协议都是建立在TCP/IP协议之上。客户端通过一个可配置的TCP端口连接到Namenode,通过ClientProtocol协议与Namenode交互。而Datanode使用DatanodeProtocol协议与Namenode交互。一个远程过程调用(RPC)模型被抽象出来封装ClientProtocol和Datanodeprotocol协议。在设计上,Namenode不会主动发起RPC,而是响应来自客户端或 Datanode 的RPC请求。


健壮性

HDFS的主要目标就是即使在出错的情况下也要保证数据存储的可靠性。常见的三种出错情况是:Namenode出错, Datanode出错和网络割裂(network partitions)。


磁盘数据错误,心跳检测和重新复制

       每个Datanode节点周期性地向Namenode发送心跳信号。网络割裂可能导致一部分Datanode跟Namenode失去联系。Namenode通过心跳信号的缺失来检测这一情况,并将这些近期不再发送心跳信号Datanode标记为宕机,不会再将新的IO请求发给它们。任何存储在宕机Datanode上的数据将不再有效。Datanode的宕机可能会引起一些数据块的副本系数低于指定值,Namenode不断地检测这些需要复制的数据块,一旦发现就启动复制操作。在下列情况下,可能需要重新复制:某个Datanode节点失效,某个副本遭到损坏,Datanode上的硬盘错误,或者文件的副本系数增大。


集群均衡

      HDFS的架构支持数据均衡策略。如果某个Datanode节点上的空闲空间低于特定的临界点,按照均衡策略系统就会自动地将数据从这个Datanode移动到其他空闲的Datanode。当对某个文件的请求突然增加,那么也可能启动一个计划创建该文件新的副本,并且同时重新平衡集群中的其他数据。这些均衡策略目前还没有实现。


数据完整性

      从某个Datanode获取的数据块有可能是损坏的,损坏可能是由Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端软件实现了对HDFS文件内容的校验和(checksum)检查。当客户端创建一个新的HDFS文件,会计算这个文件每个数据块的校验和,并将校验和作为一个单独的隐藏文件保存在同一个HDFS名字空间下。当客户端获取文件内容后,它会检验从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配,如果不匹配,客户端可以选择从其他Datanode获取该数据块的副本。


元数据磁盘错误

      FsImage和Editlog是HDFS的核心数据结构。如果这些文件损坏了,整个HDFS实例都将失效。因而,Namenode可以配置成支持维护多个FsImage和Editlog的副本。任何对FsImage或者Editlog的修改,都将同步到它们的副本上。这种多副本的同步操作可能会降低Namenode每秒处理的名字空间事务数量。然而这个代价是可以接受的,因为即使HDFS的应用是数据密集的,它们也非元数据密集的。当Namenode重启的时候,它会选取最近的完整的FsImage和Editlog来使用。

      Namenode是HDFS集群中的单点故障(single point of failure)所在。如果Namenode机器故障,是需要手工干预的。目前,自动重启或在另一台机器上做Namenode故障转移的功能还没实现。


快照

      快照支持某一特定时刻的数据的复制备份。利用快照,可以让HDFS在数据损坏时恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能,但计划在将来的版本进行支持。


数据组织


数据块

      HDFS被设计成支持大文件,适用HDFS的是那些需要处理大规模的数据集的应用。这些应用都是只写入数据一次,但却读取一次或多次,并且读取速度应能满足流式读取的需要。HDFS支持文件的“一次写入多次读取”语义。一个典型的数据块大小是64MB。因而,HDFS中的文件总是按照64M被切分成不同的块,每个块尽可能地存储于不同的Datanode中。


Staging

      客户端创建文件的请求其实并没有立即发送给Namenode,事实上,在刚开始阶段HDFS客户端会先将文件数据缓存到本地的一个临时文件。应用程序的写操作被透明地重定向到这个临时文件。当这个临时文件累积的数据量超过一个数据块的大小,客户端才会联系Namenode。Namenode将文件名插入文件系统的层次结构中,并且分配一个数据块给它。然后返回Datanode的标识符和目标数据块给客户端。接着客户端将这块数据从本地临时文件上传到指定的Datanode上。当文件关闭时,在临时文件中剩余的没有上传的数据也会传输到指定的Datanode上。然后客户端告诉Namenode文件已经关闭。此时Namenode才将文件创建操作提交到日志里进行存储。如果Namenode在文件关闭前宕机了,则该文件将丢失。

      上述方法是对在HDFS上运行的目标应用进行认真考虑后得到的结果。这些应用需要进行文件的流式写入。如果不采用客户端缓存,由于网络速度和网络堵塞会对吞估量造成比较大的影响。这种方法并不是没有先例的,早期的文件系统,比如AFS,就用客户端缓存来提高性能。为了达到更高的数据上传效率,已经放松了POSIX标准的要求。


流水线复制

      当客户端向HDFS文件写入数据的时候,一开始是写到本地临时文件中。假设该文件的副本系数设置为3,当本地临时文件累积到一个数据块的大小时,客户端会从Namenode获取一个Datanode列表用于存放副本。然后客户端开始向第一个Datanode传输数据,第一个Datanode一小部分一小部分(4 KB)地接收数据,将每一部分写入本地仓库,并同时传输该部分到列表中第二个Datanode节点。第二个Datanode也是这样,一小部分一小部分地接收数据,写入本地仓库,并同时传给第三个Datanode。最后,第三个Datanode接收数据并存储在本地。因此,Datanode能流水线式地从前一个节点接收数据,并在同时转发给下一个节点,数据以流水线的方式从前一个Datanode复制到下一个。


可访问性

      HDFS给应用提供了多种访问方式。用户可以通过Java API接口访问,也可以通过C语言的封装API访问,还可以通过浏览器的方式访问HDFS中的文件。通过WebDAV协议访问的方式正在开发中。


DFSShell

      HDFS以文件和目录的形式组织用户数据。它提供了一个命令行的接口(DFSShell)让用户与HDFS中的数据进行交互。命令的语法和用户熟悉的其他shell(例如 bash, csh)工具类似。下面是一些动作/命令的示例:

动作 命令
创建一个名为 /foodir 的目录 bin/hadoop dfs -mkdir /foodir
创建一个名为 /foodir 的目录 bin/hadoop dfs -mkdir /foodir
查看名为 /foodir/myfile.txt 的文件内容 bin/hadoop dfs -cat /foodir/myfile.txt

DFSShell 可以用在那些通过脚本语言和文件系统进行交互的应用程序上。


DFSAdmin

DFSAdmin 命令用来管理HDFS集群。这些命令只有HDSF的管理员才能使用。下面是一些动作/命令的示例:

动作 命令
将集群置于安全模式 bin/hadoop dfsadmin -safemode enter
显示Datanode列表 bin/hadoop dfsadmin -report
使Datanode节点 datanodename退役 bin/hadoop dfsadmin -decommission datanodename


浏览器接口

      一个典型的HDFS安装会在一个可配置的TCP端口开启一个Web服务器用于暴露HDFS的名字空间。用户可以用浏览器来浏览HDFS的名字空间和查看文件的内容。


存储空间回收


文件的删除和恢复

      当用户或应用程序删除某个文件时,这个文件并没有立刻从HDFS中删除。实际上,HDFS会将这个文件重命名转移到/trash目录。只要文件还在/trash目录中,该文件就可以被迅速地恢复。文件在/trash中保存的时间是可配置的,当超过这个时间时,Namenode就会将该文件从名字空间中删除。删除文件会使得该文件相关的数据块被释放。注意,从用户删除文件到HDFS空闲空间的增加之间会有一定时间的延迟。

      只要被删除的文件还在/trash目录中,用户就可以恢复这个文件。如果用户想恢复被删除的文件,他/她可以浏览/trash目录找回该文件。/trash目录仅仅保存被删除文件的最后副本。/trash目录与其他的目录没有什么区别,除了一点:在该目录上HDFS会应用一个特殊策略来自动删除文件。目前的默认策略是删除/trash中保留时间超过6小时的文件。将来,这个策略可以通过一个被良好定义的接口配置。


减少副本系数

       当一个文件的副本系数被减小后,Namenode会选择过剩的副本删除。下次心跳检测时会将该信息传递给Datanode。Datanode遂即移除相应的数据块,集群中的空闲空间加大。同样,在调用setReplication API结束和集群中空闲空间增加间会有一定的延迟。


参考资料

by Dhruba Borthakur

分类: 架构 标签:

ZendPlatform Session 跨服务器解决方案白皮书

2010年2月8日 没有评论
介绍

这篇白皮书介绍的是Zend Platform 关于session clustering的新的模块。Zend的解决方案是唯一能为不断增加的集群提供线性升级的方案,同时它还提供空前的性能和数据完整性。

在这里,我们首先介绍目前可选的几种方案。然后,将它们与Zend提供的方案做对比,并且对Zend的Session集成模块的设计理念和架构做下阐述。

背景

因特网或者万维网的核心是HTTP协议(超文本传输协议)。同时,因为HTTP协议的无界性,网站应用无法将浏览器访问与不同的服务器连接起来。从本质上说,这意味着用户从一个业务进入到另一个业务时,新的服务器有可能无法得到该用户的信息。

为了解决这个问题,一个新的概念“Cookies”被引入了。所谓的“Cookies”指的是一个小型数据结构,这个存放在用户本地的数据是被用来储存用户的信息。当该用户访问一个网站的时候,网站的服务器从用户本地得到用户数据后经过处理再把结果返回给用户。所以,给用户的感觉是网站似乎记住了该用户的信息。同时,用户可以方便地在登陆该网站时使用原先的设置,甚至不需要输入密码进行登陆。“Cookies”使用最多的领域是记录用户的相关配置信息或者是在一个在线商店所采购的采购记录。

然而,“Cookies”数据保存在用户本地的特点容易造成两个方面的负面效果。第一、过长的“Cookies”数据的保存与传输都将是一个不小的资源消耗。第二、对于一些重要的数据,保存在用户本地容易造成数据错误,从而给用户的访问带来负面影响。为此,基于“Cookies”的HTTP Session 概念产生了。代替传统的把所有的信息存储在用户本地的做法,Session 架构把用户的信息储存在服务器端,而在用户端只保存了区分布不同用户信息的唯一的“Session ID”。

PHP是通过内嵌的扩展来实现Session应用的,并且该扩展是基于地层的架构。PHP对Session的支持允许网站实现大量的注册和访问量。

可是,当要在一个服务器集群实现PHP Session 的应用时,问题变得复杂起来。

Figure: 1 – 服务器集群环境

经典的多服务器集群包含了一组服务器,在每台服务器上面加载相同的PHP应用。同时,服务器集群的出口由一个下载均衡服务器来实现,下载均衡管理器在服务器之间分配流量保证各个服务器的负载是均衡的。这种应用使得网站应用突破了单台服务器的传统模式,而由服务器集群来承载同一个PHP应用。很明显,这种集群服务器的应用提高了PHP业务的性能并减低了终端用户的访问时间。

由于HTTP协议的不确定性,同一个用户的不同HTTP请求很有可能被发送到不同的服务器。所以,将会造成用户的session id 无法及时获取正确的用户信息的问题,并最终导致用户使用上的不方便。

Session 集群化管理

Zend之前的一些解决方案:
负载均衡Session方案

通过负载均衡服务器把特定的HTTP请求指定到相同的服务器。存在着一些不足:

• SessionID与服务器的对应很难成功地保持。在没有HTTP协议校验的前提下,HTTP协议很容易丢失目标。而且,因为负载均衡的性能问题使用HTTP协议进行校验是不稳定的。
• 如果在负载均衡服务器上面启用Session定向,将不利于负载均衡服务器本身的运行特性。尤其是在使用了了流行的NAT技术后,影响更加明显。
• 为了达到SessionID与服务器的对应的目的,负载均衡将需要花费相当昂贵的系统消耗来实现。
• 当负载均衡服务器的为了实现Session功能的时候,它的负载将会急速上升,并逐渐地成为了服务器集群升级的的瓶颈。在集群服务器上添加服务器将会因为负载均衡的的瓶颈问题而变得困难。
通过NFS系统来共享Session的方案
因为负载均衡实现Session共享的局限性,有人开始尝试用NFS来共享。通过集群中的NFS文件服务器来实现,从而来实现集群里的服务器的Session应用。甚至有人觉得通过负载均衡服务器来实现Session共享会变得没有必要,而且可以使得网络的硬件投入得到减少,DNS轮询都能够满足Session的应用。
但是这种方法同样存在着一些局限性:

• 数据完整性: NFS的文件加锁机制在许多场合下是不合适的。这种情况有可能导致Session的数据很容易出错。
• 速度缓慢:从NFS文件系统提取Session数据远远比本地提取耗时,同时网络的架构也将影响数据的传输速度。
• 将所有的数据都存储在一个服务器上意味着这是一个系统故障点:如果NFS服务器出现了故障,整个PHP应用系统将无法工作。为此就必须为NFS服务器配置更多的设备和更完善的电源管理。但是,这也是一个很大的资金投入,同时,他还是没有从根本上解决单一故障点的问题。因为NFS的网络接口还是一个。
• 系统升级: 把系统所有的数据都存放在一个中心节点伴随着的一个问题是系统的升级变得困难,而中心点就是系统升级的一个瓶颈。所以,往集群里面增加服务器所带来的效益将为因为这个瓶颈问题而被降低。
• 安全性: NFS 一直以来都被认为是一个安全性比较差的协议。许多专业的IT公司也因此放弃了NFS网络文件系统。
• 持续的硬件投入

采用数据库来存放Session信息

第三种解决Session不能跨服务器的方法是把共享的Session放在一台相应的数据库服务器中。这种方法也有效地解决了NFS文件系统方案带来的数据完整性和有效性等问题。但是这个方案同样地存在着某些不足:

• 速度:相对本地存储来说,数据库服务器将需要在数据库处理上面占用整个PHP应用平台的时间。
• 故障点:数据库服务器还是存在着单一故障点的问题。
• 系统升级:使用数据库来存储Session这个方案同样存在着升级困难的问题。而这个问题在考虑数据库服务器的处理能力和负载的时候会显得尤为突出。

小结

目前,通用的解决方案并不能满足PHP集群化应用发展的需求。总体来说,有一下几个方案的困难需要解决:

• 系统升级的瓶颈问题:目前已有的解决方案总是把问题集中在一个单一的中心节点上面。为此 ,限制了其方案的处理能力,为集群应用的发展造成了困难。
• 性能:目前已有的解决方案往往需要过度牺牲中心节点的系统资源,所以中心节点的硬件投入比较大。
• 故障点:目前已有的解决方案都需要一个中心节点,为此整个系统存在着单一故障点的问题。这也意味着系统在运行过程中存在着较大的风险。

Zend 的解决方案

Zend 公司是应许多客户的要求的情况下,开始Session clustering 模块的开发的。这么客户一直被实现Session共享而带来的系统消耗等问题而困扰。作为PHP发展的主要推动者,Zend公司强烈意识到这个问题的严重性。客户放映的问题主要是集中在Session共享的安全性和多余资源投入。在Zend的Session共享的解决方案出现之前,客户往往要搭建复杂和昂贵的框架添加数据库服务器等硬件来实现Session共享。但是这样的框架还经常无法提供稳定、可靠的Session跨服务器的解决方案。而且,这种复杂的框架还经常给商业应用的稳定性带来错误和潜在的危险。

Zend的新的Session Clustering 的模块(Zend Platform 的部件之一) 就为提供一个综合的Session跨服务器的解决方而开发的。并在这个方案中,有效地解决了上述几个解决方案存在的问题了。更为重要地,没有为现有客户增加成本。

在Zend session clustering 的解决方案中, sessions “居住” 在它第一次被生成的服务器上。同时,这些Session可以别同一个集群服务器所共享。这意味着Zend的解决方案从根本上解决了Session不能跨服务器的问题,并提供了较高的性能。同时,它的系统升级特性也可以让客户呢功能有效地使用现有的系统资源,并简便、迅速地升级。

Figure: 2 – SC 架构
图 2 给我们展示了Session集群管理的几大部件:
Session 的存储 : 可以选择存储在内存或者是存储在硬盘并在内存进行缓存。
SCD守护进程: Session clustering 守护进程, 把Session信息从Session被存储的地方提取出来提交 给PHP engine,或是从集群里别的服务器上提取并提交给PHP engine。
mod_cluster PHP扩展: 是一个PHP的session处理负责与SCD守护进程的通信。
Zend的session clustering 模块使用了强大的加锁和数据完整性机制来实现session 数据的安全性。在使用Session clustering 时,可以随时地切换两种不同的session存储模式:硬盘或只在内存。这种存储方式也提供了错误恢复的功能,因为如果发生了不可预测的故障时,能够及时恢复Session数据。
Zend的session clustering 模块对现有的PHP的兼容性很强,同时不影响其它的扩展的正常使用,也不需要修改任何代码。Zend Platform的session clustering 的解决方案就是集成了一个PHP的扩展。同时,在PHP.ini里面也可以选择是用现有的解决方案还是session clustering 模式。
结论

Zend的session clustering 模块从技术上来说,比现有的几个解决方案都更加成熟,也是现今唯一的能迅速实现系统升级的解决方案。Session clustering用较低的成本来实现PHPde 集群应用,并可以给客户带来无法比拟的性能、稳定性和数据完整性。.

Zend的 session clustering 的解决方案也是目前唯一的一个能够集成到PHP的解决方案。因为实现session clustering的设计与代码编写都是在PHP的架构下实现的。

下面列出的是session clustering与其它方案的比较:

• 线性系统升级:在系统架构中不再存在瓶颈问题。新加入的服务器能有效地发挥出应有的性能效益。同时,Session clustering 也不会给现有的网络架构和设备增加额外的负担。
• 速度优势:经过压力测试,session clustering 模块是现有的Session跨服务器解决方案的4到6倍的速度。
• 无故障点:如果因为不可预测的原因,有一台服务器停止服务了,损失的也只是那一台服务器的session数据,而不是整个系统。损失的数据可以迅速在其它的服务器上重新建立。
• 安全性: Session clustering’s 内在的数据完整性和加锁机制可以实现强大的Session应用。并允许高用户负载下的商业应用。
• 错误矫正: session clustering可以选择把session数据存储在硬盘当中。从而可以从系统或者内存的出错中恢复过来。
• Session clustering试你的资金投入均匀分布在服务器机群中:session clustering可以与任何的负载均衡技术环境运行(包括DNS轮询)。
• 强大的兼容性: Zend的 session clustering 解决方案提供了强大的集成特性,可以兼容现有的代码和PHP应用。现有的PHP项目可以直接移植到session clustering 解决方案当中应用。

分类: 架构 标签:

一次由于.htaccess文件不全导致的rewrite后500错误的问题

2010年2月1日 没有评论

之前在.htaccess中配置了rewrite后,总是会出现服务器500错误,检查过原因:

1.不是httpd.conf中没有loadModule mod_rewrite

2.也不是Directory 指令AllowOverride None的问题

3.更不是我写的.htaccess中语法的问题

 

我的.htacess是这样写的,

写道
<IfModule mod_rewrite.c>
RewriteEngineon
RewriteBase /rewrite
RewriteRule ^$ webroot/ [L]
RewriteRule (.*)webroot/$1 [L]
</IfModule>

后来找到资料发现问题的解决方案:

问题出在我用的CakePHP框架上,我当时上传文件的时候因为FTP过滤的原因没有把.htaccess文件上传过去,所以我就在根目录下面手动上传了这个文件,但/app 和/app/wwwroot目录下面均没有上传.htaccess文件,后来发现补充这两个文件夹下面的.htaccess文件后一切恢复正常

分类: PHP 标签: