1. 程式人生 > >MFS分散式儲存中mfsmaster的高可用

MFS分散式儲存中mfsmaster的高可用

部署mfsmaster高可用的原因:

在講原因之前,可以先看看mfs讀寫原理圖:

讀操作

寫操作

這裡寫圖片描述

通過讀寫操作圖可以清楚的看到,mfsmaster是排程器,是mfs最核心的地方,如果mfsmaster掛了,整個mfs架構會掛掉,對此我們要對mfsmaster進行高可用冗餘操作

構建思路:利用pacemaker構建高可用平臺,利用iscis做共享儲存,mfschunkserver做儲存裝置。
有人可能要問為什麼keepalived,我想說的是就是keepalived是可以完全做的,但是keepalived不具備對服務的健康檢查,整個corosync驗證都是需要指令碼編寫,再通過vrrp_script模組進行呼叫,利用pacemaker比較方便。

實驗環境

Linux環境:Red Hat Enterprise Linux Server release 6.5 (Santiago)

pacemaker版本:pacemaker-1.1.10-14.el6 #這個直接yum安裝,yum源要新增高可用base源

mfs版本:moose-master-3.0.100

server1:172.25.77.1 mfsmaster-master pacemaker iscsi客戶端
server2:172.25.77.2 mfschunkserver
server3:172.25.77.3 mfschunkserver
server4:172.25.77.4 mfsmaster-backup pacemaker iscsi客戶端
server5: 172.25.77.5 iscsi服務端

首先要搭建基礎的mfs分散式儲存架構,本篇不做闡述。可以檢視我之前配置的mfsmfs分散式檔案系統

1.首先配置 iscsi客戶端共享儲存:

在此實驗中,資料同步是最關鍵的。

配置iscsi服務端:
server5上:

yum list scsi* -y  #安裝scsi服務端

vim /etc/tgt/targets.conf  #進入配置檔案進行配置
 38 <target iqn.2018-03.com.example:server.target1>
 39     backing-store /dev/vdb   #新增一個新的儲存硬碟
 40     initiator-address 172.25
.77.1 #允許1和4作為客戶端 41 initiator-address 172.25.77.4 42 </target> /etc/init.d/tgtd start #開啟服務

server1和server4:

server1和server4都執行的:
yum install iscsi* -y  #安裝iscsi客戶端
/etc/init.d/iscsi start  #開啟服務
iscsiadm -m discovery -t st -p 172.25.77.5  #發現服務端
iscsiadm -m node -l  #登入共享儲存組,fdisk -l會發現出現/dev/sda硬碟,這就是共享的磁碟。

只有server1執行的:
fdisk -cu /dev/sda    #硬碟分割槽
mkfs.ext4 /dev/sda1   #初始化檔案系統
mount /dev/sda1 /mnt/  #將初始化的盤,掛載到/mnt
cd /var/lib/mfs/  
cp * /mnt/             #這一步的目的,主要將原來mfs中的changelog全部同步出來。
umount /mnt/
cd /mnt/
mount /dev/sda1 /var/lib/mfs/  #將
cd /var/lib/
chown mfs.mfs mfs -R  #要給mfs目錄下都給mfs執行許可權

server1和server4執行:
/etc/init.d/iscsi start  #開啟iscsi客戶端

配置上述,共享儲存就算做好了。

2.配置 pacemaker+corosync:

首先要配置高可用的yum源:

[rhel6.5]
name=rhel6.5
baseurl=http://172.25.77.250/rhel6.5
gpgcheck=0

[HighAvailability]   #這也是系統自帶的,但是要新增。
name=HighAvailability
baseurl=http://172.25.77.250/rhel6.5/HighAvailability
gpgcheck=0

安裝pacemaker+corosync:

server1和server4:
yum install pacemaker corosync -y #corosync做心跳檢測的。
yum install crmsh-1.2.6-0.rc2.2.1.x86_64.rpm  pssh-2.3.1-2.1.x86_64.rpm -y #crm命令列
製作corosync的配置檔案:
cd /etc/corosync/
cp corosync.conf.example corosync.conf


vim /etc/corosync/corosync.conf
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
                bindnetaddr: 172.25.77.0 #新增自己的網段地址
                mcastaddr: 226.94.1.1
                mcastport: 5405
                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  #新增pacemaker服務
        ver: 0           #這個引數設定為0,就是在開啟corosync的時候,pacemaker一併開啟
}
scp corosync.conf 172.25.77.4:/etc/corosync/
/etc/init.d/corosync start   #開啟corosync和pacemaker

pacemaker利用crm命令列進行配置:

配置之前,要修改mfsmaster的啟動指令碼:
vim /etc/init.d/moosefs-master
 29 start () {
 30     echo -n $"Starting $prog: "
 31     $prog start >/dev/null 2>&1 && success || failure
 32     if [ $? -ne 0 ];then  #這裡做個判斷,如果錯誤執行下面操作
 33     $prog -a -i >/dev/null 2>&1 && success || failure  # automatically restore metadata from change logs
 34     fi
 35     RETVAL=$?
 36     echo
 37     [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
 38     return $RETVAL
 39 }
crm配置:
[email protected] corosync]# crm
crm(live)# configure
crm(live)configure# property stonith-enabled=false #先關掉fence裝置
crm(live)configure# commit
crm(live)configure# primitive vip ocf:heartbeat:IPaddr2 params ip=172.25.77.100 op monitor interval=10s #配置vip資訊。
crm(live)configure# commit
crm(live)configure# primitive mfsdata ocf:heartbeat:Filesystem params device=/dev/sda1 directory=/var/lib/mfs fstype=ext4 op monitor interval=10s #配置儲存資訊
crm(live)configure# primitive mfsmaster lsb:moosefs-master op monitor interval=10s #配置服務資訊
crm(live)configure# group mfsgroup vip mfsdata mfsmaster  #將其加進一個組內,在啟動的時候,會一窩端走。
crm(live)configure# commit

新增解析:
vim /etc/hosts
172.25.34.1     server1 
172.25.34.2     server2 
172.25.34.3     server3
172.25.34.4     server4
172.25.34.5     server5
172.25.34.6     server6 
172.25.34.100   mfsmaster

這裡寫圖片描述

如果你害怕發現腦裂現象,可以新增fence功能。

測試:
crm node standby #在server4上執行這個操作,如果發現整個pacemaker組發現遷移動,就說明配置。
記住在測試完了後,要執行crm node online讓節點起來,防止全部down掉。

如果出現什麼問題,可以在下方留言,我看到會回覆!

OVER!!!

相關推薦

MFS分散式儲存mfsmaster可用

部署mfsmaster高可用的原因: 在講原因之前,可以先看看mfs讀寫原理圖: 讀操作 寫操作 通過讀寫操作圖可以清楚的看到,mfsmaster是排程器,是mfs最核心的地方,如果mfsmaster掛了,整個mfs架構會掛掉,對

02 . 分散式儲存之FastDFS 可用叢集部署

`單節點部署和原理請看上一篇文章` https://www.cnblogs.com/you-men/p/12863555.html #### 環境 ```mysql [Fastdfs-Server] 系統 = CentOS7.3 軟體 = fastdfs-nginx-module_v1.16

分散式檔案系統MFS的基本用法以及可用實現

實驗主機環境(redhat 6.5 x86_64bit) ip hostname softwares to install 192.168.1.8 cobbler1 mfs-master cgi-server keepali

Azure環境Nginx可用性和部署架構設計

基於 google ogl soft 可用性 pan googl 環境 keep 前幾篇文章介紹了Nginx的應用、動態路由、配置。在實際生產環境部署時,我們需要同時考慮Nginx的高可用性和部署架構。 Nginx自身不支持集群以保證自身的高可用性,商業版本的Nginx+

NameNode可用方案

http 正常 nbsp 元數據 bubuko 高可用方案 img 也不會 conda NN中元數據的可靠性是可以保證的,但是其可用性並不高,因為Namenode是單節點的,所以一旦這個節點不能工作,那麽整個hdfs都不能工作,但是由於SecondaryNameNode的機

docker部署可用負載均衡前後端專案異常

異常:在基於jdk的docker容器中可以使用jar方式啟動jar檔案,但有時候要終止程式該怎麼做? 當我在宿主機上去殺死對應的容器對映程式時,發現雖然外層宿主機刪除了程序,當容器中還是在執行 當檢視docker容器中nohup.out檔案時總是顯示地址被佔用 測試:ps -ef | g

6--SpringCloud搭建分散式配置中心(續-可用性)

  本文接之前的《5--SpringCloud搭建分散式配置中心》,繼續來說說Spring Cloud Config的使用。   先來回顧一下,在前文中我們完成了什麼: 構建了config-server,連線到Git倉庫 在Git上建立了一個5--SpringCloud--Config目錄,用來

分散式儲存HDFS與Ceph兩者的區別是什麼,各有什麼優勢?

過去兩年,我的主要工作都在Hadoop這個技術棧中,而最近有幸接觸到了Ceph。我覺得這是一件很幸運的事,讓我有機會體驗另一種大型分散式儲存解決方案,可以對比出HDFS與Ceph這兩種幾乎完全不同的儲存系統分別有哪些優缺點、適合哪些場景。 對於分散式儲存,尤其是開源的分散式儲存,站在一個SRE的角度,我認為

專案Mysql可用方案

最近又上線了一個大專案,其中mysql採用的高可用方案如下,用作後續學習 本次專案,mysql部署3臺主機,採用主從模式,總共三個結點,主節點後掛一個從節點,從節點後再掛一個從節點,即主-從-備的結構。 採用keepalived虛擬vip,當主結點掛了後,ke

61、Heartbeat V1基於NFS共享儲存的WEB可用實戰

1、涉及機器 192.168.130.61 node1.ha.com 192.168.130.62 node2.ha.com 192.168.130.63 node3.ha.com 2、安裝heartbeat V2 rpm -ivh https://mirrors.aliyun.com/ep

Heartbeat V2基於NFS共享儲存的WEB可用實戰(基於heartbeat-gui配置)

1、涉及機器 192.168.130.61 node1.ha.com 192.168.130.62 node2.ha.com 192.168.130.63 node3.ha.com 2、安裝heartbeat V2 rpm -ivh https://mirrors.aliyun.com/ep

63、Heartbeat V2基於NFS共享儲存的MySQL可用實戰(heartbeat-gui)

1、涉及機器 192.168.130.61 node1.ha.com 192.168.130.62 node2.ha.com 192.168.130.63 node3.ha.com 2、安裝heartbeat V2 rpm -ivh https://mirrors.aliyun.com/ep

SQL Server可用性(1)----可用性概覽

    自從SQL Server 2005以來,微軟已經提供了多種高可用性技術來減少宕機時間和增加對業務資料的保護,而隨著SQL Server 2008,SQL Server 2008 R2,SQL Server 2012的不斷髮布,SQL Server中已經存在了滿足不同場景的多種高可用性技術。    

hadoop完全分散式搭建HA(可用

首先建立5臺虛擬機器(最少三臺),並且做好部署規劃ip地址 主機名 安裝軟體 程序 192.168.xx.120 master jdk,hadoop,zookeeper namenode,ZKFC,Resourcemanager 192.168.xx.121 m

Hadoop2.0HDFS可用性的實現原理

        在Hadoop1.0中,NameNode在HDFS叢集中存在單點故障問題,每一個叢集中只存在一個NameNode,如果NameNode所在的機器出現故障,那麼整個叢集就無法利用,直到NameNode重啟或在另一臺主機上啟動NameNode守護程序。因此,有兩

Spring Cloud構建微服務架構 分散式配置中心(可用與動態重新整理)【Dalston版】

高可用問題 傳統作法 通常在生產環境,Config Server與服務註冊中心一樣,我們也需要將其擴充套件為高可用的叢集。在之前實現的config-server基礎上來實現高可用非常簡單,不需要我們為這些服務端做任何額外的配置,只需要遵守一個配置規則:將所有的Config Server都指向同一

SQL Server可用性(2)----檔案與檔案組

    在談到SQL Server的高可用性之前,我們首先要談一談單例項的高可用性。在單例項的高可用性中,不可忽略的就是檔案和檔案組的高可用性。SQL Server允許在某些檔案損壞或離線的情況下,允許資料庫依然保持部分線上,從而保證了高可用性。 檔案和檔案組     有關檔案和檔案組的基本概念,有很

網易視訊雲:分散式轉碼服務可用淺析

  分散式視訊處理系統中的worker、razer、sdk等模組以無狀態方式設計,即worker應用停止服務或節點宕機均不會影響整個系統對於視訊的處理。比如有worker-N應用正在處理轉碼,到了99%的時候,卻很不幸的應用崩潰,顯然該轉碼任務失敗,那麼我們該怎麼來保證該轉

BIM專案一些可用程式碼

1.頁面顯示記憶體使用情況 <%@page contentType="text/html" pageEncoding="UTF-8"%> <!DOCTYPE HTML PUBLIC

企業MySQL可用叢集架構三部曲之MM+keepalived

各位老鐵們,老張與大家又見面了。看到各位在部落格裡面給我的留言和訪問量的情況,我很是欣慰,也謝謝大家對我的認可。我寫這些部落格,就是想把自己對於MySQL資料庫的一些看法和自己平時的實戰經驗分享出來,我們可以一起探討,共同進步。也保證今後只要一有空就更新博文,推出更多