如何利用Linux和GFS打造集群存储

负载均衡是一项困难的任务。我们经常需要通过NFS(网络文件系统)或其他机制来为数据提供中心地址，从而共享文件系统。虽然你的安全机制可能可以让你免于Web服务器节点的故障，但是你仍然需要通过中央存储节点来共享数据。

网站建设哪家好，找创新互联公司！专注于网页设计、网站建设、微信开发、微信小程序定制开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了榆林免费建站欢迎大家使用！

通过GFS(全局文件系统)——Linux的一个免费集群文件系统——你可以创建一个不需要依赖其他服务器的真正稳定的集群。在这篇文章中，我们将展示如何正确地设置GFS.

从概念上来说，一个集群文件系统可以允许多个操作系统载入同一个文件系统并可以在同一时间内向同一文件系统写入数据。现在有许多集群文件系统，包括Sun的Lustre，Oracle的OCFS(Oracle集群文件系统)，以及Linux的GFS.

有许多方法可以让一个块设备同时被多个服务器所使用。你可以分区出一个对多个服务器都可视的SAN(存储局域网)LUN(逻辑单元号)，设置好相应的iSCSI(互联网小型计算机系统接口)，或使用DRBD(分布式复制块设备)在两台服务器之间复制一个分区。在使用DRBD的时候，你将需要在主/主节点中设置好DRBD以使用GFS.

GFS要求

运行GFS意味着你在运行一个集群。目前为止，运行GFS的最简单的手段就是使用Red Hat Cluster Suite(RHCS：Red Hat集群套件)。这个套件在CentOS中就有。此外，还需要下面这些包：cman——集群管理器;lvm2-cluster——使LVM(逻辑卷管理器)可以支持集群的CLVM(集群逻辑卷管理器)包;kmod-gfs——GFS内核模块;最后是gfs-utils.

集群管理器(cman)包含必要的工具，比如分布式锁管理器。除非你希望花时间来确认各种不同的分发版本是如何采用cman的，否则我们强烈推荐使用CentOS或RHEL.同时，你还将获得RH(Red Hat)所维护的各种最新版本的集群服务，此外你还可以获得一个比较稳定的环境。

Fencing(阻绝)机制是绝对必要的。一些指导性文章建议将阻绝模式设定成"手动"，因为阻绝设置有可能比较复杂。阻绝意味在集群中进行隔离，或马上中断某些危险节点的运作。如果集群无法阻绝某个发生故障的节点，那么你的GFS将会出现很多问题，因此不要跳过这个步骤。

创建集群设置

你可以通过/etc/cluster/里面的cluster.conf完成大部分的集群设置。我不建议使用各种集群管理应用程序来创建这个设置文件。即使是完全支持的RHEL应用程序，比如两个月前发布的Conga，也经常会创建一些无效的cluster.conf文件，并且无法被必要的服务所解析。

下面是一个cluster.conf文件的例子。这个设置文件采用漂亮的XML格式，其内容非常直接。首先，我们对集群进行命名，我们将这个集群称作"Web.1".

先跳过fence daemon选项，下一个部分就是集群主体的设置内容。你需要在clusternodes部分定义两个节点。设置文件将同时存放在两个节点上，这样这两个节点就都知道彼此的情况。

集群内的每个节点都声明其阻绝方式的名称是独一无二的。在clusternames结束标签下面，我们看到fencedevice部分定义了每个节点如何阻绝其他节点的方式。使用一个支持IPMI(智能平台管理接口)的服务器是最好的方式，而且其设置也是相当简单。你只要将IPMI的地点以及登录方式告诉IP就可以了。为了避免在cluster.conf中留下密码，你可以将它指向一个由根所拥有的脚本并由这个脚本来返回密码。

我们还要指出的是我们在设置中定义了两个节点。这是必须的，因为通常来说，除非大部分节点都同意自己的状态，否则集群无法达到"Quorate"状态。如果只有两个节点的话，没有肯定多数，因此这种方式让集群只能在两个节点下工作，而不能只在只有一个节点的情况下工作。这是设置基本集群的必要方式。

在每个节点上运行"service cman start"，系统应该可以开始正常运作。你可以检查"clustat"或"cman nodes"来确认节点是否良好运行。如果有哪个必要的部分没有启动，那么集群将不会显示"Quorate"状态。

GFS设置

首先，我们需要设置CLVM，这样我们才可以通过GFS使用LVM.激活CLVM只要在lvm.conf中设定"locking type=3"就可以了。

然后，就像平常一样创建一个LVM卷组和卷，但是使用的是共享的块设备。如果你使用的是DRBD，你将有可能使用/dev/drbd0.我创建了一个物理卷，然后创建一个名为vg01的卷组，然后创建一个名为web1的逻辑卷，这个卷在：/dev/vg01/web1.

最后，我们需要创建文件系统：

gfs_mkfs -t web1：mygfs -p lock_dlm -j 2 /dev/vg01/web1

-t中给定的名称必须是集群的名称，然后后面是你给这个文件系统所起的名字。只有web1集群的成员才可以载入这个文件系统。然后，设定分布式锁管理器的锁钥类型，指明你需要两份journal(因为这是一个双节点集群)。如果你预计未来要增加更多的节点，那么你需要在这时设定足够高的journal数量。

总结

我们现在可以开始使用这个文件系统了。在两个节点上启动"clvmd"和"gfs"服务。现在你就可以通过"-t gfs"来将类型指定为GFS，从而载入文件系统。

在开始启动之前，一定要设定好cman，clvmd和gfs服务。你最好能熟悉clustat和gfs_tool命令，因为在系统出现问题的时候，你可以用这些命令来查找问题所在。

不要指望GFS能很快。如果有一个节点在进行大量的写入操作的话，那么在访问文件系统的时候出现停顿是很正常的。对于一个数据读取操作比数据写入操作多得多的Web集群来说，这倒不是什么问题。如果出现明显延迟，那么首先要检查一下所有组件的状况，然后评估正在写入的数据。防止延迟现象的最常见措施就是确保HTTP对话中的数据不是写入GFS卷。

如何查询linux 分区是gfs格式

Linux下查看当前内核系统支持的文件系统：

一般都在 /lib/modules/kernl-version/kernel/fs/ 目录下包含了当前内核版本支持的文件系统：

ls /lib/modules/kernl-version/kernel/fs/

1、mount 用挂载命令查看当前分区挂载的格式、类型

2、查看/etc/fstab挂载文件系统脚本：

less /etc/fstab文件

3、使用df -T 查看挂载的文件系统类型：

df -T -h

Google文件系统--GFS详解

  Google File System(简称GFS)是适用于大规模且可扩展的分布式文件系统，可以部署在廉价的商务服务器上，在保证系统可靠性和可用 性的同时，大大降低了系统的成本。GFS的设计目标是高性能、高可靠、高可用性。

  GFS把机器故障视为正常现象，可以很好地处理系统故障。GFS系统通常会部署在上百台甚至上千台廉价服务器上，并会有相当多台廉价服务器上部署GFS Client来访问GFS服务，所以应用故障、操作系统bug、连接故障、网络故障、甚至机器供电故障都是经常发生的故障。GFS系统可以支持系统监控、故障检测、故障容忍和自动恢复，提供了非常高的可靠性。其次，GFS系统中的文件一般都是大文件，且文件操作大部分场景下都是append而不是overwrite。一旦文件写入完成后，大部分操作都是读文件且是顺序读。

  GFS提供了非标准（比如POSIX）的文件系统接口，支持 create、delete、open、close、read以及write。另外GFS支持snapshot和record append操作。snapshot可以以很低的代价创建文件或者目录树的拷贝，record append可以支持多个client并发地向同一个文件append data，同时还能保证每个client的append操作的原子性。

  master记录了文件系统的metadata，包括名字空间、权限控制信息、文件到chunk的mapping以及chunk的分布。master也负责chunk的lease管理、无用chunk的垃圾回收、chunk迁移等。master定期与chunkserver通信，向chunkserver发送指令并搜集chunkserver的状态。GFS client通过GFS的API与GFS系统通信（读写数据）。client向master请求获取metadata，真正的读写数据是直接与chunkserver交互。client和chunkserver都不cache文件数据。因为大部分应用都是基于API来streaming read 大文件且系统的文件数据太多，所以client缓存文件数据没有意义。chunkserver所在机器的Linux的buffer cache以及cache了频繁访问的数据，chunkserver也是没有去cache文件数据的。

  单点master大大简化了系统设计，因为master知晓所有的meta信息，所以可以执行更加复杂的chunk位置分配和副本策略。但是，在读写数据时必须降低master的参与，以避免单点的master称为系统瓶颈。client不会通过master来读写文件数据，但是client会向master发送查询chunk位置分布的请求，然后client端缓存chunk的分布信息，然后直接向chunkserver读写数据。大致的读过程如下：

1、client根据文件名、byte offset以及chunk size计算出要读取的文件的chunk index

2、client通过文件名、chunk index向master查询chunk的分布

3、master回复chunk handler以及副本分布

4、client 缓存chunk的meta信息，key由文件名和chunk index组成

5、client从chunk的分布信息中查找距离自己最新的chunkserver，并发送查询请求。查询请求中包括chunk hander以及byte range。后续对相同chunk的查询不需要再次向master查询meta信息，因为client已经缓存了meta信息。

  chunk size是GFS系统的关键参数，通常设置为64MB，远大于文件系统的block大小。每个chunk的副本都chunkserver所在机器上以Linux file存储。之所为将chunk size定为64MB，主要有以下考虑：

1、可以减少client访问master查询meta信息的次数，降低master的访问压力。因为chunk size设计比较大，顺序访问一个超大文件时因为chunk数较少且client缓存了chunk meta信息，所以访问master的次数就会降低。甚至，client可以缓存所有文件的chunk的meta信息，就算是随机读文件，master也不会成为系统性能瓶颈。

2、可以减少网络开销，保持client与chunkserver的TCP连接，可以执行更多的chunk操作。

3、可以减少master上需要在内存中记录的meta data数据量，降低master的内存占用。

   size大的缺点是：小文件包含很少的chunk，甚至只有一个。这样的话，在多个client高并发查询该小文件时对应的chunk会成为热点。实际上，这种情况在GFS系统中很少发生，因为大部分client的操作都是顺序读大文件。但是，考虑以下场景，我们部署一个服务的二进制文件到GFS系统中，然后数百台的服务器同时查询二进制文件并启动服务，此时该二进制文件副本所在的chunkserver立马就会成为查询瓶颈。当然，可以通过增加副本数和分散服务器的查询时间来解决这种场景下的问题。

  master主要存储三种类型的metadata：file和chunk的名字空间，file到chunk的mapping信息以及chunk的副本分布。所有的metadata都在master的内存中存储。前两种meta信息可以持久化存储，将操作日志存储在master的本地磁盘以及将备份日志存储在远端机器上。master不持久化存储chunk的副本分布信息，而是通过与chunkserver交互来获取chunkserver上的chunk信息。

4.1 in-memory data structure

  meta信息在内存中，所有master的操作很快。另外，master可以高效地定期在后台scan所有的meta数据，来执行垃圾回收、副本修复、均衡等。metadata都记录在内存中，所以GFS系统会比较关注chunk的数量以及master的可用内存量。但是在实际场景下，这不是问题。每个64MB的chunk的metadata小于64字节，大部分的chunk都是满负荷存储的，除了文件最后一个chunk的空间是没有完全被占用。由于文件的名字空间采用了前缀压缩的方式存储，单个文件的meta信息也是小于64字节。如果需要扩大系统规模的话，可以很简单地通过增大master的内存就可以了。相比于系统的高可靠、高性能和简洁性，增加内存是很最小的代价了。

4.2 chunk 分布

  并没有持久化存储chunk的副本分布信息，而是在master启动时向chunkserver查询其chunk信息，然后通过heartbeat来持续更新master的副本分布信息，以与chunkserver数据保持一致。GFS起初设计时尝试将chunk的分布信息持久化存储在master端，随后发现通过master启动时拉取然后通过heartbeat同步chunk信息的方式更简单。因为，当chunkserver加入、退出、名字改变、重启等行为经常发生，这会导致维护master的chunk meta数据的正确性是非常困难的。从另一个角度考虑就是，只有chunkserver汇报的chunk信息才是集群中最真实的chunk分布，因为master不需要自己维护一个chunk分布状态，只需要以chunkserver的状态汇报为准即可。

4.3 操作日志

  日志记录了GFS集群数据更改的历史记录。操作日志对GFS来说是至关重要的，因为它不仅是metadata的持久化记录，还记录了并发操作的时序。因为操作日志很重要，所以必须可靠地存储。在metadata的change没有持久化之前，client是不能看到的数据的更改。当client修改数据时，操作记录需要保存在多个远端机器上，而且只有当操作记录持久化存储在本地和远端以后，才会回复client数据更改成功。

  可以通过回放操作日志来恢复文件系统。为了减少系统启动时replay的时间，必须缩减回放的日志量。master可以定期存储metadata的checkpoint，master重启时可以从checkpoint加载metadata，然后回放checkpoint之后的少量日志即可。

1、client向master查询chunk的primary所在的chunkserver以及其他副本的分布，如果没有primary的花，master会选择一个作为该chunk的primary

2、master回复client primary和其他副本的分布信息。client会cache返回的metadata

3、client将数据发送所有的副本。client可以以任意顺序执行。每个chunkserser都会在内存的LRUbuffer中记录数据。

4、当所有的副本都返回已经接收数据成功后，client会向primary发送一个写请求。primary会为每一个数据更改的请求附加一个序列号，数据更改是按照序列号的顺序执行的。

5、primary将数据更改同步到其他副本中，副本也是按照序列号执行数据更改操作。

6、primary接收到其他副本回复的数据操作完成

7、primary返回client结果。期间发生的所有错误都会报给client。

   GFS集群一般都会有上百台的chunkserver，分布在多个机架上。chunkserver也会接收来自本机架或者其他机架的上百个client的查询请求。不同机架的服务器通信可能会途径一个或者多个交换机转发。chunk的副本分布选择策略主要目的是尽量提高数据的可靠性和可用性，同时最大化地充分利用网络带宽。所以，仅仅将副本跨机器部署是不够的。GFS将副本是跨机架部署的，这样可以保证在一个机架被损坏或者下线时，chunk至少会有副本是可用的。

   chunk的副本在下列情况下会被创建：创建chunk、副本修复、rebalance。当master创建chunk时，会选择存储该chunk副本的chunkserver。主要考虑以下几点：

1、新副本所在chunkserver的磁盘利用率低于系统的平均水平

2、限制每个chunkserver最近一段时间创建chunk的数量

3、每个chunk的所有副本不能都在一个机架

   chunk的副本数少于一定数量是，master会复制一个副本。这可能发生在chunkserver宕机或者chunkserver汇报自己的副本损坏或者chunkserver所在机器的磁盘损坏等等。每个chunk 复制任务都有优先级，按照优先级由高到低子master中排队等待执行。master还会定期扫描当前副本的分布情况，一旦发现磁盘使用量或者机器负载不均衡，就会发起负载均衡操作。无论是chunk创建、chunk复制还是负载均衡，选择chunk副本的位置的策略都是相同的，并且需要限制副本修复和均衡的速度，否则会影响系统的正常读写服务。

  Google的成功表明单master的设计师可行的。这不仅简化了系统，而且能够较好地实现一致性，给予性能考虑，GFS提出了“记录至少原子性追加一次”的一致性模型。通过租约的方式将每个chunk的修改授权到chunkserver从而减少了master的负载，通过流水线的方式复制多个副本以减少延时。master维护的元数据很多，需要设计高效的数据结构，且要保证占用内存小和支持快照操作。支持COW的B树可以满足需求，但是实现确实相当复杂。

如何查看和停止Linux启动的服务

1. 查看Linux启动的服务

chkconfig --list 查询出所有当前运行的服务

chkconfig --list atd 查询atd服务的当前状态

2.停止所有服务并且在下次系统启动时不再启动，如下所示：

chkconfig --levels 12345 NetworkManager off

如果想查看当前处于运行状态的服务，用如下语句过滤即可

chkconfig --list |grep on

3.如果只是想当前的设置状态有效，在系统重启动后即不生效的话，可以用如下命令停止服务

service sshd stop

示例，可以把不需要启动的服务写入到一个脚本中，直接用sh 文件名一执行就可以了

chkconfig --levels 0123456 NetworkManager off

chkconfig --levels 0123456 anacron off

chkconfig --levels 0123456 auditd off

chkconfig --levels 0123456 avahi-daemon off

chkconfig --levels 0123456 bluetooth off

chkconfig --levels 0123456 clvmd off

chkconfig --levels 0123456 cman off

chkconfig --levels 0123456 cups off

chkconfig --levels 0123456 gfs off

chkconfig --levels 0123456 gfs2 off

chkconfig --levels 0123456 hidd off

chkconfig --levels 0123456 httpd off

chkconfig --levels 0123456 iptables off

chkconfig --levels 0123456 ip6tables off

chkconfig --levels 0123456 ipvsadm off

chkconfig --levels 0123456 luci off

chkconfig --levels 0123456 mcstrans off

chkconfig --levels 0123456 pand off

chkconfig --levels 0123456 Nrestorecond off

chkconfig --levels 0123456 ricci off

chkconfig --levels 0123456 rmanager off

chkconfig --levels 0123456 saslauthd off

chkconfig --levels 0123456 sendmail off

chkconfig --levels 0123456 smb off

chkconfig --levels 0123456 snmp off

chkconfig --levels 0123456 snmptrapd off

chkconfig --levels 0123456 tog-pegasus off

chkconfig --levels 0123456 wdaemon off

linux怎么格式化gfs文件系统

GFS文件系统为分布式结构，它是一个高度容错网络文件系统，主要chunkserver由一个master（主）和众多chunkserver（大块设备）构成的，体系结构如下图：

GFS文件系统的工作过程：

客户端使用固定大小的块将应用程序指定的文件名和字节偏移转换成文件的一个块索引，向master（主）发送包含文件名和块索引的请求；

master收到客户端发来的请求，master向块服务器发出指示，同时时刻监控众多chunkserver的状态。Chunkserver缓存master从客户端收到的文件名和块索引等信息。

master通过和chunkserver的交互，向客户端发送chunk-handle和副本位置。其中文件被分成若干个块，而每个块都是由一个不变的，全局唯一的64位的chunk-handle标识。Handle是由master在块创建时分配的。而出于安全性考虑，每一个文件块都要被复制到多个chunkserver上，一般默认3个副本；

客户端向其中的一个副本发出请求，请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。

客户端从chunkserver获得块数据，任务完成。

怎么用gfs-Linux系统管理

　GFS的精彩在于它采用了多种方法，从多个角度，使用不同的容错措施来确保整个系统的可靠性。

2.1.1 系统架构

GFS的系统架构如图2-1[1]所示。GFS将整个系统的节点分为三类角色：Client（客户端）、Master（主服务器）和Chunk Server（数据块服务器）。Client是GFS提供给应用程序的访问接口，它是一组专用接口，不遵守POSIX规范，以库文件的形式提供。应用程序直接调用这些库函数，并与该库链接在一起。Master是GFS的管理节点，在逻辑上只有一个，它保存系统的元数据，负责整个文件系统的管理，是GFS文件系统中的“大脑”。Chunk Server负责具体的存储工作。数据以文件的形式存储在Chunk Server上，Chunk Server的个数可以有多个，它的数目直接决定了GFS的规模。GFS将文件按照固定大小进行分块，默认是64MB，每一块称为一个Chunk（数据块），每个Chunk都有一个对应的索引号（Index）。

分享标题：linuxgfs命令 linux NFS
URL网址：http://hbruida.cn/article/docipco.html