设为首页 收藏本站
查看: 1234|回复: 0

[经验分享] Moosefs分布式存储

[复制链接]

尚未签到

发表于 2019-2-1 09:08:13 | 显示全部楼层 |阅读模式
Moosefs分布式存储

  第一部分:原理讲解
  首先,我们熟悉的百度网盘就是分布式文件系统的一个例子,百度用来做存储的。
  MFS 特性:
  1. Free(GPL )
  2. 通用文件系统,不需要修改上层应用就可以使用
  3. 可以在线扩容,体系架构可伸缩性极强。
  4. 部署简单。
  5. 高可用,可设置任意的文件冗余程度(提供比 raid1+0 更高的冗余级别,而绝对不会影响读或写的性能,只会加速!)
  6. 可回收在指定时间内删除的文件(回收站提供的是系统级别的服务,不怕误操作了,提供类似 oralce 的闪回等高级 dbms 的即时回滚特性!)
  7. 提供 netapp,emc,ibm 等商业存储的 snapshot 特性。(可以对整个文件甚至在正在写入的文件创建文件的快照)
  8. google filesystem 的一个 c 实现。
  9. 提供 web gui 监控接口。
  10. 提高随机读或写的效率。 11. 提高海量小文件的读写效率。
  可能的瓶颈:
  1. master 本身的性能瓶颈。mfs系统 master 存在单点故障如何解决?moosefs+drbd+heartbeat 来保证 master 单点问题?不过在使用过程中不可能完全不关机和间歇性的网络中断!
  2. 体系架构存储文件总数的可遇见的上限。(mfs 把文件系统的结构缓存到 master 的内存中,文件越多,master 的内存消耗越大,8g 对应 2500w 的文件数,2 亿文件就得 64GB 内存 )。
  master 服务器 CPU 负载取决于操作的次数,内存的使用取决于文件和文件夹的个数。
  MFS 文件系统结构:包含 4 种角色:
  管理服务器 managing server (master),这里不是存贮数据的地方,但是这里包含着存储的数据的权限,大小,分别存放在那些服务器上等信息.
  元数据日志服务器MetaloggerserverMetalogger)
  数据存储服务器 data servers chunkservers)
  客户机挂载使用 client computers
  
  各种角色作用:
  1. 管理服务器:负责各个数据存储服务器的管理,文件读写调度,文件空间回收以及恢复.多节点拷贝。
  2. 元数据日志服务器:负责备份 master 服务器的变化日志文件,文件类型为
  changelog_ml.*.mfs,以便于在 master server 出问题的时候接替其进行工作。
  3. 数据存储服务器:负责连接管理服务器,听从管理服务器调度,提供存储空间,并为客户提供数据传输。
  4. 客户端:通过 fuse 内核接口挂接远程管理服务器上所管理的数据存储服务器,看起来共享的文件系统和本地 unix 文件系统使用一样的效果。
  5. MFS 读写原理:   






  第二部分:MFS 部署:
  主机环境:RHEL6.0
  selinux and iptables disabled
  Master:192.168.0.66
  Metalogger: 192.168.0.77
  Chunkserver: 192.168.0.1 192.168.0.2
  Client: 192.168.0.3
  软件下载: www . moosefs . org
  生成 rpm,便于部署
  # yum install gcc make rpm-build fuse-devel zlib-devel –y
  # rpmbuild -tb mfs-1.6.26.tar.gz
  # ls ~/rpmbuild/RPMS/x86_64
  mfs-cgi-1.6.26-1.x86_64.rpm
  mfs-master-1.6.26-1.x86_64.rpm
  mfs-chunkserver-1.6.26-1.x86_64.rpm
  mfs-metalogger-1.6.26-.x86_64.rpm mfs-client-1.6.26-1.x86_64.rpm
  主控服务器 Master server 安装:
  # yum localinstall -y mfs-master-1.6.26-1.x86_64.rpm mfs-cgi-1.6.26-1.x86_64.rpm
  # cd /etc
  # cp mfsmaster.cfg.dist mfsmaster.cfg
  此文件中凡是用#注释掉的变量均使用其默认值,基本不需要就可以工作:
  #WORKING_USER 和 WORKING_GROUP:是运行 master server 的用户和组;
  #SYSLOG_IDENT:是 master server 在 syslog 中的标识;
  #LOCK_MEMORY:是否执行 mlockall()以避免 mfsmaster 进程溢出(默认为 0); #NICE_LEVE:运行的优先级(如果可以默认是 -19; 注意: 进程必须是用 root 启动);
  #EXPORTS_FILENAME:被挂接目录及其权限控制文件的存放位置
  #TOPOLOGY_FILENAME : 定义 MFS 网络拓扑结构的文件位置
  #DATA_PATH:数据存放路径,此目录下大致有三类文件,changelog,sessions 和 stats;
  #BACK_LOGS:metadata的改变 log 文件数目(默认是 50) ;
  #BACK_META_KEEP_PREVIOUS:保存以前 mfs元数据的文件数,默认值是 1;
  #REPLICATIONS_DELAY_INIT:延迟复制的时间(默认是 300s);
  #REPLICATIONS_DELAY_DISCONNECT:chunkserver 断开的复制延迟(默认是 3600);
  # MATOML_LISTEN_HOST:metalogger 监听的 IP 地址(默认是*,代表任何 IP);
  # MATOML_LISTEN_PORT:metalogger 监听的端口地址(默认是 9419);
  # MATOCS_LISTEN_HOST:用于 chunkserver 连接的 IP 地址(默认是*,代表任何 IP);
  # MATOCS_LISTEN_PORT:用于 chunkserver 连接的端口地址(默认是 9420);
  # MATOCU_LISTEN_HOST/MATOCL_LISTEN_HOST:用于客户端挂接连接的 IP 地址(默认是*,代表任何 IP);
  # MATOCU_LISTEN_PORT/MATOCL_LISTEN_PORT:用于客户端挂接连接的端口地址(默认是 9421);
  #CHUNKS_LOOP_CPS:chunks 的回环每秒检查的块最大值,默认 100000;
  # CHUNKS_LOOP_TIME :chunks 的回环频率(默认是:300 秒);
  # CHUNKS_SOFT_DEL_LIMIT :一个 chunkserver 中可以删除 chunks 的最大数,软限 (默认:
  10)
  #CHUNKS_HARD_DEL_LIMIT:一个 chunkserver 中可以删除 chunks 的最大数,硬限 (默认:
  25)
  # REPLICATIONS_DELAY_DISCONNECT:chunkserver 断开后的复制延时(默认:3600 秒)
  # CHUNKS_WRITE_REP_LIMIT:在一个循环里复制到一个 chunkserver 的最大 chunk 数目(默认是 2)
  # CHUNKS_READ_REP_LIMIT :在一个循环里从一个 chunkserver 复制的最大 chunk 数目(默认是 10)
  # REJECT_OLD_CLIENTS:弹出低于 1.6.0的客户端挂接(0 或 1,默认是 0)
  # deprecated:
  # CHUNKS_DEL_LIMIT - use CHUNKS_SOFT_DEL_LIMIT instead
  # LOCK_FILE - lock system has been changed, and this option is used only to search for old lockfile
  # cp mfsexports.cfg.dist mfsexports.cfg
  # vi mfsexports.cfg
  192.168.0.0/24 / rw,alldirs,maproot=0
  该文件每一个条目分为三部分:
  第一部分:客户端的 ip 地址
  第二部分:被挂接的目录
  第三部分:客户端拥有的权限
  地址可以指定的几种表现形式:
  * 所有的 ip 地址
  A.B.C.D 单个 ip 地址
  A.B.C.D/BITS IP 网络地址/位数掩码 A.B.C.D/E.F.G.H IP 网络地址/子网掩码 A.B.C.D-E.F.G.H IP 地址范围
  目录部分需要注意两点:
  / 标识 MooseFS 根;
  . 表示 MFSMETA 文件系统
  权限部分:    
  ro
  只读模式共享
  rw
  读写方式共享
  alldirs
  许挂载任何指定的子目录

  maproot
  映射为 root,还是 指定的用户

  password
  指定验证密码,客户端挂载时使用
  # cd /var/lib/mfs
  # cp metadata.mfs.empty metadata.mfs
  # chown nobody /var/lib/mfs
  修改/etc/hosts 文件,增加下面的行:
  192.168.0.66 mfsmaster
  # mfsmaster start 启动 master server
  working directory: /var/lib/mfs lockfile created and locked initializing mfsmaster modules ... loading sessions ... file not found if it is not fresh installation then you have to restart all active mounts !!!
  exports file has been loaded
  mfstopology configuration file (/etc/mfstopology.cfg) not found - using defaults loading metadata ... create new empty filesystemmetadata file has been loaded
  no charts data file - initializing empty charts master  metaloggers module: listen on *:9419 master  chunkservers module: listen on *:9420 main master server module: listen on *:9421 mfsmaster daemon initialized properly
  此时进入/var/lib/mfs 可以看到 moosefs 所产生的数据:
  .mfsmaster.lock 文件记录正在运行的 mfsmaster 的主进程 metadata.mfs, metadata.mfs.back MooseFS 文件系统的元数据 metadata的镜像
  changelog.*.mfs是 MooseFS 文件系统元数据的改变日志(每一个小时合并到 metadata.mfs 中一次)
  Metadata 文件的大小是取决于文件数的多少(而不是他们的大小)。changelog 日志的大小是取决于每小时操作的数目,但是这个时间长度(默认是按小时)是可配置的。
  # mfscgiserv #启动 CGI 监控服务
  lockfile created and locked starting simple cgi server (host: any , port: 9425 , rootpath: /usr/share/mfscgi)
  # cd /usr/share/mfscgi/
  # chmod +x chart.cgi mfs.cgi
  在浏览器地址栏输入 http://192.168.0.66:9425 即可查看 master 的运行情况
  元数据日志服务器 Metalogger server 安装:
  # yum localinstall -y mfs-metalogger-1.6.26-1.x86_64.rpm
  # cd /etc
  # cp mfsmetalogger.cfg.dist mfsmetalogger.cfg 文件 mfsmetalogger.cfg 的修改是可选的:
  # WORKING_USER = nobody
  # WORKING_GROUP =
  # SYSLOG_IDENT = mfsmetalogger
  # LOCK_MEMORY = 0:是否执行 mlockall()以避免交换出 mfsmaster 进程(默认是 0,即 no);
  # NICE_LEVEL = -19
  # DATA_PATH = /var/lib/mfs
  # BACK_LOGS = 50
  # BACK_META_KEEP_PREVIOUS = 3
  # META_DOWNLOAD_FREQ = 1
  metadata 元数据下载间隔时间(默认是 24 小时,单位是小时,至多是 BACK_LOGS 的 1/2)
  # MASTER_RECONNECTION_DELAY = 5 :在失去连接之后延迟多少秒重新连接 master
  # MASTER_HOST = mfsmaster:连接 MooseFS master 主机的地址(默认是 mfsmaster)
  # MASTER_PORT = 9419:连接 MooseFS master 主机的端口(默认是 9420) ;
  # MASTER_TIMEOUT = 60:连接 master 的超时时间(默认 60 秒) ;
  # deprecated, to be removed in MooseFS 1.7
  # LOCK_FILE = /var/run/mfs/mfsmetalogger.lock
  # mkdir /var/lib/mfs
  # chown nobody /var/lib/mfs
  # vi /etc/hosts
  192.168.0.66 mfsmaster
  # mfsmetalogger start
  在/var/lib/mfs 目录中可以看到从 master 上复制来的元数据
  changelog_ml.*.mfs 是 MooseFS 文件系统的元数据的 changelog 日志(备份的 Master 的 Master 的 changelog 日志)
  metadata_ml.mfs.back 是从 Master 主机上下载的最新的完整 metadata.mfs.back 的拷贝 sessions.ml.mfs 是从 master 下载的最新的 sessions.mfs 文件拷贝。
  Mfsmetalogger 并不能完美的接管 master server,在实际生产环境中使用 HA 解决 master 的单点
  故障。
  存储块服务器 Chunk servers 安装:
  # yum localinstall -y mfs-chunkserver-1.6.26-1.x86_64.rpm
  # cd /etc/
  # cp mfschunkserver.cfg.dist mfschunkserver.cfg
  # WORKING_USER = nobody
  # WORKING_GROUP =
  # SYSLOG_IDENT = mfschunkserver
  # LOCK_MEMORY = 0
  # NICE_LEVEL = -19
  # DATA_PATH = /var/lib/mfs
  # MASTER_RECONNECTION_DELAY = 5:在失去连接之后延迟多少秒重新连接 master
  # BIND_HOST = *:本地地址用于连接 mfsmaster(默认值是*,即默认的本地地址)
  # MASTER_HOST = mfsmaster:master 服务器的主机名或是 ip 地址。
  # MASTER_PORT = 9420
  # MASTER_TIMEOUT = 60
  # CSSERV_LISTEN_HOST = *:允许挂载的客户端连接的 IP 地址(*允许全部)
  # CSSERV_LISTEN_PORT = 9422:允许挂载的客户端连接的端口
  # HDD_CONF_FILENAME = /etc/mfshdd.cfg:分配给 MFS 使用的磁盘空间配置文件的位置
  # HDD_TEST_FREQ = 10:块的测试期(单位为秒)
  # deprecated, to be removed in MooseFS 1.7
  # LOCK_FILE = /var/run/mfs/mfschunkserver.lock
  # BACK_LOGS = 50
  # CSSERV_TIMEOUT = 5
  # cp mfshdd.cfg.dist mfshdd.cfg
  # vi mfshdd.cfg 定义 mfs 共享点
  /mnt/mfschunks1
  /mnt/mfschunks2
  # mount /dev/VolGroup/data1 /mnt/mfschunks1/
  # mount /dev/VolGroup/data2 /mnt/mfschunks2/
  # chown -R nobody:nobody /mnt/mfschunks1
  # chown -R nobody:nobody /mnt/mfschunks2
  修改/etc/hosts 文件,增加下面的行:
  192.168.0.66 mfsmaster
  mkdir /var/lib/mfs
  chown nobody /var/lib/mfs
  # mfschunkserver start
  working directory: /var/lib/mfs lockfile created and locked initializing mfschunkserver modules ...
  hdd space manager: path to scan: /mnt/mfschunks2/ hdd space manager: path to scan: /mnt/mfschunks1/hdd
  space manager: start background hdd scanning (searching for available chunks) main server module: listen on *:9422 no charts data file - initializing empty charts mfschunkserver daemon initialized properly
  现在再通过浏览器访问 http://192.168.0.66:9425/ 应该可以看见这个 MooseFS 系统的全部信息, 包括主控 master 和存储服务 chunkserver 。
  客户端 client 安装:
  # yum localinstall -y mfs-client-1.6.26-1.x86_64.rpm
  # cd /etc
  # cp mfsmount.cfg.dist mfsmount.cfg
  # vi mfsmount.cfg 定义客户端默认挂载
  mfsmaster=mfsmaster /mnt/mfs
  # mfsmount
  # df -h
  ...
  mfsmaster:9421 2729728 0 2729728 0% /mnt/mfs
  MFS 测试:
  在 MFS 挂载点下创建两个目录,并设置其文件存储份数:
  # cd /mnt/mfs
  # mkdir dir1 dir2
  # mfssetgoal -r 2 dir2/ 设置在 dir2 中文件存储份数为两个,默认是一个 dir2/:
  inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0
  对一个目录设定“goal”,此目录下的新创建文件和子目录均会继承此目录的设定,但不会改变已经存在的文件及目录的 copy 份数。但使用-r 选项可以更改已经存在的 copy 份数。
  拷贝同一个文件到两个目录
  # cp /etc/passwd dir1
  # cp /etc/passwd dir2
  查看文件信息
  # mfsfileinfo dir1/passwd dir1/passwd: chunk 0: 0000000000000001_00000001 / (id:1 ver:1)
  copy 1: 192.168.0.2:9422 # mfsfileinfo dir2/passwd dir2/passwd: chunk 0: 0000000000000002_00000001 / (id:2 ver:1)
  copy 1: 192.168.0.1:9422 copy 2: 192.168.0.2:9422
  关闭 mfschunkserver2 后再查看文件信息
  # mfsfileinfo dir1/passwd dir1/passwd: chunk 0: 0000000000000001_00000001 / (id:1 ver:1) no valid copies !!! # mfsfileinfo dir2/passwd dir2/passwd: chunk 0: 0000000000000002_00000001 / (id:2 ver:1) copy 1: 192.168.0.1:9422
  启动 mfschunkserver2 后,文件回复正常。
  恢复误删文件
  # rm -f dir1/passwd # mfsgettrashtime dir1/ dir1/: 86400
  文件删除后存放在“ 垃圾箱”中的时间称为隔离时间, 这个时间可以用 mfsgettrashtime 命令来查看,用 mfssettrashtime 命令来设置,单位为秒,默认为 86400 秒。
  # mkdir /mnt/mfsmeta
  # mfsmount -m /mnt/mfsmeta/ -H mfsmaster
  挂载 MFSMETA 文件系统,它包含目录 trash (包含仍然可以被还原的删除文件的信息)和 trash/undel (用于获取文件)。把删除的文件,移到/ trash/undel 下,就可以恢复此文件。
  # cd /mnt/mfsmeta/trash
  # mv 00000004 \|dir1\|passwd undel/
  到 dir1 目录中可以看到 passwd 文件恢复
  在 MFSMETA 的目录里,除了 trash 和 trash/undel 两个目录,还有第三个目录 reserved,该目
  录内有已经删除的文件,但却被其他用户一直打开着。在用户关闭了这些被打开的文件后, reserved 目录中的文件将被删除,文件的数据也将被立即删除。此目录不能进行操作。
  修改 linux 下最大文件描述符的限制:在进行大量小文件写时,可能会出现了一个严重错误,有可能和操作系统文件描述符有关。操作系统默认文件描述符为 1024.
  1.6.26 版本默认为 100000 建议上线时,master 和 chunker 修改文件描述符系统级限制:它是限制所有用户打开文件描述符的总和,可以通过修改内核参数来更改该限制:
  # vi /etc/sysctl.conf 添加
  fs.file-max=102400 如果此值默认够大可以不用更改
  # sysctl -p 命令使其生效。
  用户级限制:只是修改用户级的最大文件描述符限制,也就是说每一个用户登录后执行的程序占
  用文件描述符的总数不能超过这个限制。
  # vi /etc/security/limits.conf
  * - nofile 102400
  保存退出后重新登录,其最大文件描述符已经被永久更改了。
  与 file-max 参数相对应的还有 file-nr,这个参数是只读的,可以查看当前文件描述符的使用情况。
  # sysctl -a|grep file fs.file-nr = 12800 0 782554 fs.file-max = 782554
  在 kernel 2.6 之前的版本中,file-nr 中的值由三部分组成,分别为:1.已经分配的文件句柄数,2. 已经分配单没有使用的文件句柄数,3.最大文件句柄数。但在 kernel 2.6 版本中第二项的值总为 0,这并不是一个错误,它实际上意味着已经分配的文件句柄无一浪费的都已经被使用了,file-max 的值是 linux 内核可以分配的最大文件句柄数。如果你看到了很多关于打开文件数已经达到了最大值的错误信息,你可以试着增加该值的限制。file-max 的默认值大概是系统内存的 10 %(系统内存以 kb 计算)快照
  MooseFS 系统的另一个特征是利用 mfsmakesnapshot 工具给文件或者是目录树做快照:
  # mfsmakesnapshot source … destination
  Mfsmakesnapshot 是在一次执行中整合了一个或是一组文件的拷贝,而且任何修改这些文件的源文件都不会影响到源文件的快照,就是说任何对源文件的操作,例如写入源文件,将不会修改副本(或反之亦然)。
  文件快照可以用 mfsappendchunks,例如:
  # mfsappendchunks destination-file source-file …
  当有多个源文件时,它们的快照被加入到同一个目标文件中(每个 chunk 的最大量是 chunk)。
  为了安全停止 MooseFS 集群,建议执行如下的步骤:    
  # umount -l /mnt/mfs
  #客户端卸载 MooseFS 文件系统
  # mfschunkserver stop
  #停止 chunk server 进程
  # mfsmetalogger stop
  #停止 metalogger 进程
  #mfsmaster stop 安全的启动 MooseFS 集群:
  #停止主控 master server 进程
  # mfsmaster start
  #启动 master 进程
  # mfschunkserver start
  #启动 chunkserver 进程
  # mfsmetalogger start
  #启动 metalogger 进程
  # mfsmount
  #客户端挂载 MooseFS 文件系统
  实际上无论如何顺序启动或关闭,未见任何异常,master 启动后,metalogger、chunker、client 三个元素都能自动与 master 建立连接。
  故障测试:
  Client 客户端断电、断网对 MFS 的体系不产生影响.
  如果客户端误杀 killall -9 mfsmount 进程,需要先 umount /mnt/mfs,然后再 mfsmount。否则会提示:/mnt/mfs: Transport endpoint is not connected
  chunkserver 端:
  传输一个大文件,设置存储 2 份。传输过程中,关掉 chunker1,这样绝对会出现有部分块只存在 chunker2 上;启动 chunker1,关闭 chunker2,这样绝对会有部分块只存在 chunker1 上。把 chunker2 启动起来。整个过程中,客户端一直能够正常传输。使用 mfsfileinfo 查看此文件,发现有的块分布在 chunker1 上,有的块分布在 chunker2 上。使用 mfssetgoal -r 1 后,所有块都修改成 1 块了,再 mfssetgoal -r 2,所有块都修改成 2 份了。
  # mfssetgoal -r 1 bigfile bigfile:
  inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0
  # mfsfileinfo bigfile bigfile:
  chunk 0: 0000000000000010_00000001 / (id:16 ver:1)
  copy 1: 192.168.0.1:9422
  chunk 1: 0000000000000011_00000002 / (id:17 ver:2)
  copy 1: 192.168.0.2:9422
  # mfssetgoal -r 2 bigfile bigfile:
  inodes with goal changed: 1 inodes with goal not changed: 0 inodes with permission denied: 0
  # mfsfileinfo bigfile bigfile:
  chunk 0: 0000000000000010_00000001 / (id:16 ver:1)
  copy 1: 192.168.0.1:9422 copy 2: 192.168.0.2:9422
  chunk 1: 0000000000000011_00000002 / (id:17 ver:2)
  copy 1: 192.168.0.1:9422 copy 2: 192.168.0.2:9422
  断网、杀掉 mfschunkserver 程序对 MFS 系统无影响。断电:
  #无文件传输时,对两个 chunker 都无影响;
  #当有文件传输时,但是文件设置存储一份时,对文件的存储无影响。
  #文件设置存储两份,数据传输过程中,关掉 chunker1,等待数据传输完毕后,启动 chunker1.chunker1 启动后,会自动从 chunker2 复制数据块。整个过程中文件访问不受影响。
  #文件设置存储两份,数据传输过程中,关掉 chunker1,不等待数据传输完毕,开机启动chunker1.chunker1 启动后,client 端会向 chunker1 传输数据,同时 chunker1 也从 chunker2 复制缺失的块。只要不是两个 chunker 服务器同时挂掉的话,就不会影响文件的传输,也不会影响服务的使用。
  master
  断网、杀掉 MFS 的 master 服务对 MFS 系统无影响。断电可能会出现以下的情况:
  #当没有文件传输时,可在服务器重启之后,运行 mfsmetarestore –a 进行修复,之后执行 mfsmaster start 恢复 master 服务。
  # mfsmetarestore -a
  loading objects (files,directories,etc.) ... ok
  loading names ... ok loading deletion timestamps ... ok loading chunks data ... ok checking filesystem consistency ... ok connecting files and chunks ... ok
  store metadata into file: /var/lib/mfs/metadata.mfs
  # mfsmaster start working directory: /var/lib/mfs lockfile created and locked initializing mfsmaster modules ... loading sessions ... ok sessions file has been loaded exports file has been loaded
  mfstopology configuration file (/etc/mfstopology.cfg) not found - using defaults loading metadata ... loading objects (files,directories,etc.) ... ok
  loading names ... ok loading deletion timestamps ... ok loading chunks data ... ok checking filesystem consistency ... ok connecting files and chunks ... ok all inodes: 5 directory inodes: 3
  file inodes: 2 chunks: 2
  metadata file has been loaded stats file has been loaded
  master  metaloggers module: listen on *:9419 master  chunkservers module: listen on *:9420 main master server module: listen on *:9421 mfsmaster daemon initialized properly
  #当有文件传输时,可能会在/usr/local/mfs/sbin/mfsmetarestore –a 进行修复时可能会出现:
  # mfsmetarestore -a
  loading objects (files,directories,etc.) ... ok
  loading names ... ok loading deletion timestamps ... ok loading chunks data ... ok checking filesystem consistency ... ok connecting files and chunks ... ok
  ?S:115: error: 32 (Data mismatch)
  此时无法修复也无法启动 master 服务,有个应急的办法是将metadata.mfs.back 复制成 metadata.mfs,然后再启动 master。这样将会丢失那些正在传输的数据。
  mfsmaster 热备:
  解决方案:drbd+corosync+pacemaker
  drbd 配置:
  # cat /etc/drbd.d/mfs.res resource mfsdata { meta-disk internal; device /dev/drbd1; syncer { verify-alg sha1;
  }
  on server89.example.com { disk /dev/vgdrbd/mfs;
  address 192.168.0.189:7789;
  }
  on server87.example.com { disk /dev/vgdrbd/mfs;
  address 192.168.0.187:7789;
  }
  }
  corosync 配置:
  # cat /etc/corosync/corosync.conf # Please read the corosync.conf.5 manual page compatibility: whitetank
  totem { version: 2 secauth: off threads: 0 interface { ringnumber: 0 bindnetaddr: 192.168.0.0 mcastaddr: 226.94.2.1
  mcastport: 5408
  ttl: 1
  }
  }
  logging {
  fileline: off to_stderr: no to_logfile: yes to_syslog: yes logfile: /var/log/cluster/corosync.log debug: off timestamp: on logger_subsys { subsys: AMF debug: off
  }
  }
  amf { mode: disabled
  }
  service { name: pacemaker
  ver: 0 }
  mfs 启动脚本
  # cat /etc/init.d/mfs
  #!/bin/bash
  #
  # Init file for the MooseFS master service
  #
  # chkconfig: - 92 84
  #
  # description: MooseFS master
  #
  # processname: mfsmaster
  # Source function library.
  # Source networking configuration.
  . /etc/init.d/functions
  . /etc/sysconfig/network
  # Source initialization configuration.
  # Check that networking is up.
  [ "${NETWORKING}" == "no" ] && exit 0
  [ -x "/usr/sbin/mfsmaster" ] || exit 1
  [ -r "/etc/mfsmaster.cfg" ] || exit 1
  [ -r "/etc/mfsexports.cfg" ] || exit 1
  RETVAL=0
  prog="mfsmaster" datadir="/var/lib/mfs" mfsbin="/usr/sbin/mfsmaster" mfsrestore="/usr/sbin/mfsmetarestore"
  start () {
  echo -n $"Starting $prog: "
  $mfsbin start >/dev/null 2>&1 if [ $? -ne 0 ];then
  $mfsrestore -a >/dev/null 2>&1 && $mfsbin start >/dev/null 2>&1 fi
  RETVAL=$?
  echo
  return $RETVAL
  }
  stop () {
  echo -n $"Stopping $prog: "
  $mfsbin -s >/dev/null 2>&1 || killall -9 $prog #>/dev/null 2>&1
  RETVAL=$? echo
  return $RETVAL
  }
  restart () { stop start }
  reload () {
  echo -n $"reload $prog: " $mfsbin reload >/dev/null 2>&1
  RETVAL=$? echo
  return $RETVAL
  }
  restore () {
  echo -n $"restore $prog: " $mfsrestore -a > /dev/null 2>& 1
  RETVAL=$? echo
  return $RETVAL
  }
  case "$1" in start)
  start
  ;;
  stop) stop
  ;;
  restart)
  restart
  ;;
  reload)
  reload
  ;;
  restore)
  restore
  ;;
  status) status $prog RETVAL=$?
  ;;
  *)
  echo $"Usage: $0 {start|stop|restart|reload|restore|status}"
  RETVAL=1 esac exit $RETVAL
  pacemaker 配置:
  node server87.example.com node server89.example.com
  primitive MFSdata ocf:linbit:drbd params drbd_resource="mfsdata" primitive MFSfs ocf:heartbeat:Filesystem \
  params device="/dev/drbd1" directory="/var/lib/mfs" fstype="ext4" primitive MFSmaster lsb:mfs op monitor interval="30s" primitive vip ocf:heartbeat:IPaddr2 \
  params ip="192.168.0.163" cidr_netmask="24" \ op monitor interval="30s" \ group MFSgroup MFSfs vip MFSmaster ms MFSdataclone MFSdata \
  meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1"
  notify="true" target-role="Started" colocation mfs-with-drbd inf: MFSgroup MFSdataclone:Master order mfs-after-drbd inf: MFSdataclone:promote MFSgroup:start
  property $id="cib-bootstrap-options" \ stonith-enabled="false" \
  dc-version="1.1.6-3.el6-a02c0f19a00c1eb2527ad38f146ebc0834814558" cluster-infrastructure="openais" \ expected-quorum-votes="2" \ no-quorum-policy="ignore" \ start-failure-is-fatal="false"
  第三部分:实验操作
  实验环境:
  实验主机:172.25.0.1(master)
  172.25.0.2(chunkserver)
  172.25.0.3(chunkserver)
  172.25.0.251(client)
  ##下载mfs源码包,创建rpm包,在不同服务器上安装所需包
  
  #命令rpmbiuld为系统命令,可以直接安装(yum install –y rpm-build)
  #在创建rpmnn包过程中会有各种依赖关系,可以到pkgs.org上下载所需要的包
  ##在master端(节点1),进入刚刚创建的rpm包目录,安装master端包
  
  ##在chunkserver端(节点2,3),安装所需包,并且解决依赖性
  
  ##在客户端(节点251)安装client,当然,在部署中还需要元数据服务器,这里就不做累述,只需安装相应包,修改配置文件,指向master,开启就好了。
  ##在master端可以查看管理服务器的配置文件
  
  ##这里边注释掉的代表默认,需要注意的是和mfs相关的文件的用户只mfs,所以后面会修改文件的用户和组
  
  ##查看元数据配置文件,这里是允许所有人有读写权限
  
  
  ##master上数据存放目录,当没有medadata.mfs时,可以用*。*。empty来复制一份,当master启动后,会在后面加上.back,当没有数据传输时,关闭master,会变成.mfs,当正在传输数据,master异常掉线,回复不了时,可以将.back去掉,这样就可以恢复了
  
  ##然后就可以启动master了,没有启动脚本,只需要master就可以启动(没有路径限制)
  
  ##client监听master的9421端口,master监听chunkserver的9420端口,元数据日志服务器监听master的9419端口
  
  #切换到/usr/share/mfscgi目录下,开启mfscgiserv这样就可以用图形界面来看整个分布式文件系统的动态情况了
  
  ##浏览器访问会出现下面的情况,找不到master,这是因为mfs文件系统是通过主机名来通信的,所以在所有主机的/etc/hosts中0.1对应的主机名加进
  
  ##在master的配置文件中有提示,指明需要将master所在主机的解析中加进去
  
  ##然后是存储端的配置
  首先在两台主机上各增加一快磁盘,这里的磁盘可以直接做成标准的磁盘,也可以做成Lvm逻辑卷,都行,标准磁盘满后,可以加进磁盘,增加挂载点来继续工作,逻辑卷的话,就可以直接扩容,这里我们将节点2做成标准分区,将节点三做成逻辑卷
  #节点2,创建分区n>>是新建,
  
  #创建完成,退出之前,用p可以查看创建好的分区
  
  ##格式化
  
  ##挂载
  
  ##编辑配置文件,告诉
  首先chunkserver的用户和组是mfs,需要修改数据存放目录的权限,包括/var/lib/mfs和磁盘挂载点/mnt/chunk1的权限
  
  
  ##实现磁盘的永久挂载
  
  
  
  ##配置文件中还指明了作为存贮服务器的主机名和本存储服务器制定的master服务器的主机名,只需要在解析中加进ip对应的mfsmaster就可以找到了,当然如果有dns服务器就可以省去这些麻烦了
  
  
  ##还指明了挂载点文件名
  
  ##将挂载点加进去
  
  
  ##然后开启存储服务器
  
  ##网页上就可以看到加进来的磁盘
  
  ##mfs以块存储,会将磁盘换份为256个大块,每个块的大小是64M
  ##节点3中做类似的步骤,唯一的区别就是将磁盘标签换成8e,
  
  
  #创建逻辑卷
  
  
  
  
  
  ##然后就是将磁盘永久挂载,修改磁盘挂载点的权限,,告诉chunkserver挂载点在哪,做好解析,开启服务,最后就完成了
  ##在客户端,安装client软件,然后在配置文件中将自己的挂载目录放进去,做好解析,开启,就完成了
  #这是安装完软件的结果
  
  #在/mnt下创建目录,不必修改权限
  
  #修改配置文件
  
  
  #做好解析
  
  ##这样就真正完成了分布式文件系统的构建
  
  ##测试mfs
  #在client,挂载目录下创建两个目录,
  
  ##将目录1中数据只存一份
  
  ##确实只放在了节点3中
  
  ##而节点2中就不同,会存两份
  
  ##这样当存储设备节点3坏坏掉之后(我们以手动停掉为例),client存放在目录2中的数据不会有影响,而目录一中的数据将会丢失
  
  
  ##将节点三的存储回复正常,client都又可以看到数据
  ##图形界面能够更清晰的看到各个节点的chunk(块)数
  
  ##需要注意的是对于空文件,mfs文件系统会记录块的个数,但是不会消耗存储空间
  
  ##一块64M,100M将会被分成两块
  
  ##再写进500M
  
  ##图形界面上显示了存储的块的个数以及写入的速度,但是,不会占用空间
  
  ##在存储节点上,挂载目录大小依然不变,但是每个块中确实有存储的信息
  
  ##这就是放进空文件的原因,下面我们在客户端往目录一中放一个镜像
  
  ##这次磁盘使用情况就会变化
  
  ##mfsinfo 镜像名字,就会看到镜像被均匀的分配在两个chunkserver上
  
  ##删除数据的恢复,例如百度云,在我们删除数据后,其实并不是完全删除,都会有一个防止误删机制,一般会保存3-5天,当然只要你愿意交钱,百度会为你保存更长的时间
  ##查看目录一中文件能够在垃圾箱中存放的时间,为一天(86400秒)
  
  ##挂载元数据目录
  
  
  ##在元数据目录中会有存放删除的文件的目录trash
  
  ##只要将我们不想删除的文件重新放进trash中的undel中就好了
  
  ##我们将目录一中的passwd删除
  
  ##用find命令找到passwd
  
  ##将其移动到undel中,这样就又可以在目录一中查看passwd了
  
  
  ##元数据服务器的作用是在master异常关闭后重启后恢复数据
  
  ##master作为整个分布式文件系统的瓶颈,我们可以用高可用实现高可用
  以前我们用过几个高可用套件,其中drbd(网络raid)+heartbeat最简单
  Pacemaker比较复杂,有资源监控,而heartbeat只是纯心跳
  ##这里我们以pacemaker+corosync+iscsi搭建master端的高可用,节点一盒节点四作为master实现高可用,iscsi作为HA集群的一部分,我们这里用251作为服务器(安装scsi),节点一和节点四作为iscsi客户端安装iscsi
  
  ##在iscsi服务器端,安装完软件后,编辑配置文件,将磁盘和客户端ip加进来,记得磁盘必须是没有格式化的磁盘,只是做存储
  
  
  ##开启iscsi
  
  ##查看iscsi集群状态,要有新加进来的磁盘和ip
  
  
  ##在两个客户端,都安装iscsi,并且发现,加载iscsi磁盘
  
  
  
  ##这是用fdisk –l可以查看到可以用的磁盘,这里就包括iscsi磁盘
  
  ##挂载,这里是我们之前所做数据库时的iscsi,将里边的数据删除
  
  ##将mfs的数据存放进iscsi中
  
  
  ##当然在做这之前需要将master停掉,以防止数据丢失
  
  ##停掉后,这里我们将cp过来的数据删除,再进行cp,主要的区别就是.mfs 和.mfs.back区别
  
  ##对于要写进数据的目录和文件一定要记得改权限
  
  ##将iscsi挂载到master的数据目录下面,并开启master
  
  ##
  
  ##关闭
  
  ##写入mfs启动脚本
  
  
  ##当然,上面的脚本需要修改
  
  ##
  
  ##现在查看进程,master已经开启,然后关闭,将启动脚本cp给节点4
  
  ##当然也要在节点4上安装master软件包
  
  ##卸载
  
  ##发现加载
  
  ##挂载
  
  ##两边mfs用户的uid和gid要一样,这里节点一 是498,499,节点四是497,498需要修改成一样的,节点一上的zabbix用户占据了498
  
  
  ##现在在251上可以看到iscsi状态
  
  ##
  
  ##
  
  ##然后,在节点1和4上安装pacemaker,需要配置yum源
  
  ##然后,在新配的yum源中能够发现7509个包
  
  ##
  
  ##然后安装pacemaker和上面下载的两个包,节点4上做相同的做法
  ##
  
  ##修改下面这一行,并在最后一行增加服务
  
  
  ##cp给节点4
  
  ##开启
  
  
  
  ##
  
  ##在真机上查看fence的key
  
  
  ##将key拷贝给节点1和4,没有目录,要先建立
  
  
  ##
  
  ##
  
  ##安装fence
  
  
  
  ##配置
  
  
  ##查看
  
  ##继续配置
  
  ##这时开启了(节点4中查看)
  
  ##增加虚拟ip
  
  ##查看
  
  ##节点2,3上关闭
  
  ##将VIP对应mfsmaster主机(在所有mfs节点上)
  
  ##
  
  ##
  
  ##将存储节点,客户端服务都打开
  
  ##写进大文件
  
  ##本来是节点4在作为master,现在让他靠边
  
  ##在节点1上查看
  
  
  ##节点1接管了
  ##再将节点4上线,会自动回切
  
  
  
  #
  
  #至此就完成了高可用部分。
  




运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-670285-1-1.html 上篇帖子: MooseFS的使用总结 下篇帖子: 轻量级分布式系统
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表