分布式文件系统MFS(moosefs)实现存储共享(第二版)

作者:田逸(sery@163.com)

由于用户数量的不断攀升,我对访问量大的应用实现了可扩展、高可靠的集群部署(即lvs+keepalived的方式),但仍然有用户反馈访问慢的问题。通过排查个服务器的情况,发现问题的根源在于共享存储服务器NFS。在我这个网络环境里,N个服务器通过nfs方式共享一个服务器的存储空间,使得NFS服务器不堪重负。察看系统日志,全是nfs服务超时之类的报错。一般情况下,当nfs客户端数目较小的时候,NFS性能不会出现问题;一旦NFS服务器数目过多,并且是那种读写都比较频繁的操作,所得到的结果就不是我们所期待的。下面是某个集群使用nfs共享的示意图:

 

这种架构除了性能问题而外,还存在单点故障,一旦这个NFS服务器发生故障,所有靠共享提供数据的应用就不再可用,尽管用rsync方式同步数据到另外一个服务器上做nfs服务的备份,但这对提高整个系统的性能毫无帮助。基于这样一种需求,我们需要对nfs服务器进行优化或采取别的解决方案,然而优化并不能对应对日益增多的客户端的性能要求,因此唯一的选择只能是采取别的解决方案了;通过调研,分布式文件系统是一个比较合适的选择。采用分布式文件系统后,服务器之间的数据访问不再是一对多的关系(1个NFS服务器,多个NFS客户端),而是多对多的关系,这样一来,性能大幅提升毫无问题。

到目前为止,有数十种以上的分布式文件系统解决方案可供选择,如lustre,hadoop,Pnfs等等。我尝试了PVFS,hadoop,moosefs这三种应用,参看了lustre、KFS等诸多技术实施方法,最后我选择了moosefs(以下简称MFS)这种分布式文件系统来作为我的共享存储服务器。为什么要选它呢?我来说说我的一些看法:

1、  实施起来简单。MFS的安装、部署、配置相对于其他几种工具来说,要简单和容易得多。看看lustre 700多页的pdf文档,让人头昏吧。

2、  不停服务扩容。MFS框架做好后,随时增加服务器扩充容量;扩充和减少容量皆不会影响现有的服务。注:hadoop也实现了这个功能。

3、  恢复服务容易。除了MFS本身具备高可用特性外,手动恢复服务也是非常快捷的,原因参照第1条。

4、  我在实验过程中得到作者的帮助,这让我很是感激。

MFS特性(根据官方网站翻译) 

★     高可靠性(数据能被分成几个副本存储在不同的计算机里)

  

★     通过增加计算机或增加新的硬盘动态扩充可用磁盘空间

★     可以设置删除文件的空间回收时间

[root@mysql-bk serydir]# mfsgettrashtime bind-9.4.0.tar.gzbind-9.4.0.tar.gz: 600

   文件被删除10分钟后(600秒),才真正删除文件,回收磁盘空间。

★     为文件创建快照

MFS文件系统的组成 

1、  元数据服务器。在整个体系中负责管理管理文件系统,目前MFS只支持一个元数据服务器master,这是一个单点故障,需要一个性能稳定的服务器来充当。希望今后MFS能支持多个master服务器,进一步提高系统的可靠性。

2、  元数据日志服务器。备份master服务器的变化日志文件,文件类型为changelog_ml.*.mfs。当元数据服务器数据丢失或者损毁,可从日志服务器取得文件进行恢复。

3、  数据存储服务器chunkserver。真正存储用户数据的服务器。存储文件时,首先把文件分成块,然后这些块在数据服务器chunkserver之间复制(复制份数可以手工指定,建议设置副本数为3)。数据服务器可以是多个,并且数量越多,可使用的“磁盘空间”越大,可靠性也越高。

4、  客户端。使用MFS文件系统来存储和访问的主机称为MFS的客户端,成功挂接MFS文件系统以后,就可以像以前使用NFS一样共享这个虚拟性的存储了。

元数据服务器安装和配置 

元数据服务器可以是linux,也可以是unix,你可以根据自己的使用习惯选择操作系统,在我的环境里,我是用freebsd做为MFS元数据的运行平台。GNU源码,在各种类unix平台的安装都基本一致。 (全文 …)

简单cdn续一

On 2010年01月7日, in 未分类, by admin
0

7.1.4 cdn的基本原理

Cdn的基本原理可概括为:内容缓存、就近访问以及以dns视图方式根据用户来源确定其访问位置。

◆     内容缓存:缓存服务器从源站取得所需数据,然后暂存在本地的硬盘或内存。使用这种缓存机制的好处是:(1)内容自动更新;(2)无多个服务器数据相互同步问题。

◆     就近访问:让用户的访问请求转向到离用户最近或最易于访问的缓存服务器。

◆     以dns视图方式根据用户来源确定其访问位置:即让电信的用户访问电信的缓存服务器,网通用户访问网通的缓存服务器。

7.1.5 什么是简单cdn

简单cdn这个概念,是相对于复杂cdn来定义的。因此,我们先来了解一下什么是复杂的cdn。

笼统一点的讲,cdn服务提供商所运营的环境,就是复杂cdn。就缓存服务器而言,其结构是分层次的,一般可划分成核心节点和边缘节点。并且同一层级的相邻节点之间又可形成姐妹关系,亦即在同一个集群下的节点互为姐妹关系。为了保证最高的性能能和效率,不建议跨网或跨物理范围的节点形成姐妹关系。为了更直观的理解这个结构和由此产生的好处,我在这里以一个最长访问路径的图示来说明:

 

图7-2 缓存服务器相互关系

1、  用户向某边缘服务器(边缘A)发起访问请求,所需内容没有被缓存。

2、  边缘服务器(边缘A)于是询问其邻居,是否缓存了用户所需的请求对象,邻居节点也没有缓存所需的对象。

3、  边缘服务器(边缘A)转而向某个父节点(核心A)请求文件,如果该父节点仍然无所需的文件,则该父节点询问其邻居;如果邻居也没有所需的文件,则把请求转给源站。

4、  源站返回数据给核心节点(核心A),并缓存数据在该节点。

5、  核心节点(核心A)返还数据给边缘节点(边缘A),并缓存数据在该节点。

6、  边缘节点返还数据给用户,一次最长路径的访问完成。

这种分层次的机制,既能保证最高的可用性,又能最大限度的减少向上一级节点的网络流量。

除了缓存服务器结构上的差异外,复杂cdn还具备以下一些特性:

(1)       缓存服务器布点范围广,服务器数量庞大。

(2)       复杂的日志处理系统。因为计费依赖于访问日志。

(3)       详细的视图划分。例如精确到每个省的ip地址段。

(4)       预加载机制。

当我们了解清楚复杂cdn以后,再来了解简单cdn就容易多了。所谓简单cdn,就是节点层次简单、服务器数量有限、能实现有限规模站点加速和发布的平台。通常情况下,我们不必为实现cdn带来的好处而部署复杂的cdn系统,这将花费巨大的人力物力。把复杂的cdn简化,使之符合我们的业务需求,是本章“简单cdn”撰写的用意所在。

7.2简单cdn设计

 

先申明一下,本文所设计的简单cdn只是一个样例,并非适用于所有的场景。读者可根据我的思路,设计出更适合自己应用环境的简单cdn。

7.2.1 简单cdn设计的基本原则

 

简单cdn设计主要考虑以下几点:

(1)       选点合理,能覆盖大部分网络用户。最起码得在电信和网通机房放置缓存服务器,如果经费充裕,把教育网也考虑进来。

(2)       系统本身具备很好的高可用特性。用户的访问主要集中在缓存服务器,缓存服务器之间使用集群技术就能得到比较高的系统可用性。

(3)       核算自建简单cdn的成本,使之有较好的性价比。如果自建一个cdn远比购买cdn服务商所花费的资金还高(目前国内商用cdn每兆带宽为50元/月,基数是1G),基本上没必要自己建立cdn了。

(4)       系统应该具备很好的伸缩能力,以适应各种业务变化。如增加布点、增加设备、增加站点等等。

7.2.2 需求描述

欲对三个web服务进行加速,为了描述方便,使用域名来进行说明。这三个加速站点为图片站点 images.sery.cn、下载站点dl.sery.cn、主站 www.sery.cn,3个站点全部是静态内容,其页面文件主要是.html(htm)、.exe、css、jpeg、js等,非常适合被缓存。

服务的主要目标用户包括电信线路的用户、网通线路的用户、教育网的用户,其他线路的用户(如科技网、长城宽带等)访问请求被转向到网通线路的缓存服务器。为了实现这个目标,我们可能需要放置4组服务器来做缓存,即电信一组,网通2组,教育网一组。

7.2.3 简单cdn设计

 

需求明确之后,接下来的设计工作包括:布点选择、工具选取、cdn结构设计等几部分。

◆     布点选取

布点包括源站、全局智能dns、缓存服务器集群。

(1)       源站及全局智能dns选择互联互通性较好的第三方bgp机房;因为使用cdn服务的站点数量有限,故在缓存服务器以主机名的方式寻址源站。

(2)       缓存服务器共4组,选择二线或三线城市的机房托管,能节省大量的资金—北京、上海等城市带宽价格大概在300~400元/兆/月,而偏远一点二三线城市(如安阳)1G带宽的年总费用才8-10万。

◆     工具选取

工具包括操作系统、dns软件、缓存服务器软件、负载均衡软件、源站软件以及定制的脚本。

(1)       所有的服务器均使用32位的centos 5.x。曾经使用过64位的系统,但在执行缓存服务器的缓存清理操作时,有些小问题。

(2)       Dns使用bind-9.4.0。低于9的版本,可能不支持视图view,没有视图功能,智能dns就无法实现。不知道其他的dns软件有没有支持视图view的,愿知者告知。

(3)       缓存服务器有两种选择,一种是squid,另一种是varnish。Squid多用在复杂cdn场景,它能实现缓存服务器间的层级关系(邻居形成姊妹、边缘节点与核心节点形成父子关系),功能强大而配置复杂;Varnish为后起之秀,配置简单而性能卓越,维护起来比较简单,因此本案选择varnish作为缓存工具【注1

(4)       负载均衡由ipvsadm和keepalived两部分组成。ipvsadm是核心,负责包转发和负载分摊;keepalived为框架,负责故障隔离和失败切换failover。

(5)       可做web服务的软件比较多,因为站点为简单的静态文件,选择nginx比较省事。

(6)       定制脚本主要目的是自动刷新缓存服务,把这个脚本放在摸个服务器上,只需执行一次(也可使用crontab自动调用)就能实现所有缓存服务器的缓存清理。

◆     cdn结构设计

我们可根据cdn的角色来设计整个结构,这些角色包括:源站、智能dns及缓存服务器3大部分,根据布点选择和其他因素综合考虑,我们可绘出整个cdn的布局结构图。

 

图7-3 cdn服务器布局

从图中可以看出有2组缓存服务器放置在网通机房,这两组服务器不在同一个物理位置,这样做主要目的是:bind规划视图view时,能收集到的地址比较有限,不在收集列表的其他ip地址段,则统统转发给网通B机房的服务器;另外网通B机房的带宽比较便宜,机器数量也比较多,跟其他网段的互联互通还可以。

(1)       源站

源站为内容的原始发布,尽管采用cdn技术以后源站的负荷会变得很小,但为了有较高的可用性,可把它部署成负载均衡集群。

(2)智能dns

智能dns是用来实现用户访问转向功能,即通过建立访问列表,判断用户的访问来源,确定其访问对象的位置。在本案中,我建立电信、网通、教育网三个ip地址列表,未在这三个列表的称为其他;每个列表关联一个bind的视图view,那么一共就有4个视图view。地址列表可以自己收集,也可以花钱购买,地址列表越大,dns定向准确性越高。在这里强调一下:ip地址列表为客户dns服务器所在网段的列表,而不是用户接入网络的ip段。客户端计算机所设定的dns,通常称为用户本地dns。同样,为了使其有较高的可用性,dns采用主从同步的架构。

Tagged with:
 

Requirements for the master server, chunk servers and clients

 

MASTER

As the managing server (master) is a crucial element of MooseFS, it should be installed on a machine which guarantees high stability and access requirements which are adequate for the whole system. It is advisable to use a server with a redundant power supply, ECC memory, and disk array RAID1/RAID5/RAID10. The managing server OS has to be POSIX compliant (systems verified so far: Linux, FreeBSD, Mac OS X and OpenSolaris).

The most important factor in the master machine is RAM, as the full file system structure is cached in RAM for speed. The master server should have approximately 300 MiB of RAM allocated to handle 1 million files on chunkservers.

The necessary size of HDD depends both on the number of files and chunks used (main metadata file) and on the number of operations made on the files (metadata changelog); for example the space of 20GiB is enough for storing information for 25 million files and for changelogs to be kept for up to 50 hours.

METALOGGER

MooseFS metalogger just gathers metadata backups from the MooseFS master server – so the hardware requirements are not higher than for the master server itself; it needs about the same disk space. Similarly to the master server – the OS has to be POSIX compliant (Linux, FreeBSD, Mac OS X, OpenSolaris, etc.)

If you would like to use the metalogger as a master server in case of its failure, the metalogger machine should have at least the same amount of RAM and HDD as the main master server.

CHUNKSERVERS

Chunkserver machines should have appropriate disk space (dedicated exclusively for MooseFS) and POSIX compliant OS (verified so far: Linux, FreeBSD, Mac OS X and OpenSolaris).

Minimal configuration should start from several gigabytes of storage space (only disks with more than 256 MB and chunkservers reporting more than 1 GB of total free space are accessible for new data).
(全文 …)