天天看點

Ceph 正常操作筆記 - 運維小結

一、Ceph叢集管理

每次用指令啟動、重新開機、停止Ceph守護程序(或整個叢集)時,必須指定至少一個選項和一個指令,還可能要指定守護程序類型或具體例程。
      

**指令格式如

{commandline} [options] [commands] [daemons]      

常用的commandline為"ceph",對應的options如下表:

Ceph 正常操作筆記 - 運維小結

對應的commands如下表:

Ceph 正常操作筆記 - 運維小結

能指定的daemons(守護程序)類型包括mon,osd及mds。

通過SysVinit機制運作ceph:

在 CentOS、Redhat、發行版上可以通過傳統的SysVinit運作Ceph,Debian/Ubuntu的較老的版本也可以用此方法。      

使用SysVinit管理Ceph守護程序的文法如下:

[root@ceph ~] sudo /etc/init.d/ceph [options] [start|restart] [daemonType|daemonID]      

1.  管理Ceph叢集内所有類型的守護程序:

通過預設[daemonType|daemonID],并添加"-a" options,就可以達到同時對叢集内所有類型的守護程序進行啟動、關閉、重新開機等操作目的。

  • 啟動預設叢集(ceph)所有守護程序:
    [root@ceph ~] sudo /etc/init.d/ceph -a start      
  • 停止預設叢集(ceph)所有守護程序:
    [root@ceph ~] sudo /etc/init.d/ceph -a stop      
  • 如果未使用"-a"選項,以上指令隻會對目前節點内的守護程序生效。

2.  管理Ceph叢集内指定類型的守護程序:

根據指令文法,要啟動目前節點上某一類的守護程序,隻需指定對應類型及ID即可。

  • 啟動程序,以OSD程序為例:
    #啟動目前節點内所有OSD程序
    [root@ceph ~] sudo /etc/init.d/ceph start osd
    #啟動目前節點内某一個OSD程序,以osd.0為例
    [root@ceph ~] sudo /etc/init.d/ceph start osd.0        
  • 重新開機及關閉程序,以OSD程序為例:      
    #關閉目前節點内所有OSD程序
    [root@ceph ~] sudo /etc/init.d/ceph stop osd
    #關閉目前節點内某一個OSD程序,以osd.0為例
    [root@ceph ~] sudo /etc/init.d/ceph stop osd.0
    #重新開機目前節點内所有OSD程序
    [root@ceph ~] sudo /etc/init.d/ceph restart osd
    #重新開機目前節點内某一個OSD程序,以osd.0為例
    [root@ceph ~] sudo /etc/init.d/ceph restart osd.0      

二、Ceph叢集狀态監控

1.  檢查叢集健康狀況 

  • 檢查Ceph叢集狀态
    [root@ceph ~] ceph health [detail]      

如果叢集處于健康狀态,會輸出HEALTH_OK,如果輸出HEALTH_WARN甚至HEALTH_ERR,表明Ceph處于一個不正常狀态,可以加上"detail"選項幫助排查問題。

  • 快速了解Ceph叢集概況:
    [root@ceph ~] sudo ceph -s
    #輸出的内容大緻如下:
    cluster b370a29d-xxxx-xxxx-xxxx-3d824f65e339
    health HEALTH_OK
    monmap e1: 1 mons at {ceph1=10.x.x.8:6789/0}, election epoch 2, quorum  0 ceph1
    osdmap e63: 2 osds: 2 up, 2 in
    pgmap v41338: 952 pgs, 20 pools, 17130 MB data, 2199 objects
      115 GB used, 167 GB / 297 GB avail
              952 active+clean      

通過以上指令,可以快速了解Ceph叢集的clusterID,health狀況,以及monitor、OSD、PG的map概況。

如果需要實時觀察Ceph叢集狀态變化,可使用如下指令:

[root@ceph ~] sudo ceph -w 
      

2.  檢查叢集容量使用情況

[root@ceph ~] sudo ceph df
#輸出的内容大緻如下
GLOBAL:
     SIZE      AVAIL     RAW USED     %RAW USED
     1356G     1284G       73943M          5.32
POOLS:
     NAME        ID     USED       %USED     MAX AVAIL     OBJECTS
     images      1      24983M      1.80          421G        3158
     volumes     2      32768k         0          421G          20
     vms         3       3251M      0.23          421G         434      

輸出的GLOBAL段顯示了資料所占用叢集存儲空間概況。

  • SIZE: 叢集的總容量
  • AVAIL: 叢集的總空閑容量
  • RAW USED: 已用存儲空間總量
  • %RAW USED: 已用存儲空間百分比

輸出的POOLS段展示了存儲池清單及各存儲池的大緻使用率。本段沒有展示副本、克隆品和快照占用情況。 例如,把1MB的資料存儲為對象,理論使用量将是1MB,但考慮到副本數、克隆數、和快照數,實際使用量可能是2MB或更多。

  • NAME: 存儲池名
  • ID: 存儲池唯一辨別符
  • USED: 使用量,機關可為KB、MB或GB,以輸出結果為準
  • %USED: 存儲池的使用率
  • MAX AVAIL: 存儲池的最大可用空間
  • OBJECTS: 存儲池内的object個數

注:POOLS 段内的數字是理論值,它們不包含副本、快照或克隆。是以,它與USED和%USED數量之和不會達到GLOBAL段中的RAW USED和 %RAW USED數量。

三、PG管理操作

PG(歸置組)是多個object的邏輯存儲集合,每個PG會根據副本級别而被複制多份。一個POOL的PG個數可以在建立時指定,也可以在之後進行擴大。但是需要注意的是,目前Ceph尚不支援減少POOL中的PG個數。

1.  預定義PG個數

Ceph對于叢集内PG的總個數有如下公式:

(OSD個數\*100)/ 副本數 = PGs
      

以上公式計算得出結果後,再取一個與之較大的2的幂的值,便可作為叢集的總PG數。例如,一個配置了200個OSD且副本數為3的叢集,計算過程如下:

(200\*100)/3 = 6667. Nearest power of 2 : 8192
      

得到8192後,可以根據叢集内所需建立的POOL的個數及用途等要素,進行PG劃分。具體劃分細則請參考官 方計算工具 PGcalc: http://ceph.com/pgcalc/

2.  設定PG數量

要設定某個POOL的PG數量(pg_num),必須在建立POOL時便指定,指令如下:

[root@ceph ~] sudo ceph osd pool create "pool-name" pg_num [pgp_num]
[root@ceph ~] sudo ceph osd pool create image 256 256
      

需要注意的是,在後續增加PG數量時,還必須增加用于歸置PG的PGP數量(pgp_num),PGP的數量應該與PG的數量相等。但在新增POOL時可以不指定pgp_num,預設會與pg_num保持一緻。

新增PG數量:

[root@ceph ~] sudo ceph osd pool set "pool-name" pg_num [pgp_num]
[root@ceph ~] sudo ceph osd pool set image 512 512
      

3.  檢視PG資訊

若需要擷取某個POOL的PG數量或PGP數量,可以使用如下指令:

[root@ceph ~] sudo ceph osd pool get "pool-name" pg_num/pgp_num
[root@ceph ~] sudo ceph osd pool get image pg_num
pg_num : 512
[root@ceph ~] sudo ceph osd pool get image pgp_num
pgp_num : 512
      

若要擷取叢集裡PG的統計資訊,可以使用如下指令,并指定輸出格式:

#不指定輸出格式的情況下,會輸出純文字内容,可指定格式為json
[root@ceph ~] sudo ceph pg dump [--format json]
      

若要擷取狀态不正常的PG的狀态,可以使用如下指令:

[root@ceph ~] sudo ceph pg dump_stuck  inactive|unclean|stale|undersized|degraded [--format <format>]
      

4.  PG狀态概述

一個PG在它的生命周期的不同時刻可能會處于以下幾種狀态中:

Creating (建立中)

在建立POOL時,需要指定PG的數量,此時PG的狀态便處于creating,意思是Ceph正在建立PG。

Peering (互聯中)

peering的作用主要是在PG及其副本所在的OSD之間建立互聯,并使得OSD之間就這些PG中的object及其中繼資料達成一緻。

Active (活躍的)

處于該狀态意味着資料已經完好的儲存到了主PG及副本PG中,并且Ceph已經完成了peering工作。

Clean (整潔的)

當某個PG處于clean狀态時,則說明對應的主OSD及副本OSD已經成功互聯,并且沒有偏離的PG。也意味着Ceph已經将該PG中的對象按照規定的副本數進行了複制操作。

Degraded (降級的)

當某個PG的副本數未達到規定個數時,該PG便處于degraded狀态,例如:

在用戶端向主OSD寫入object的過程,object的副本是由主OSD負責向副本OSD寫入的,直到副本OSD在建立object副本完成,并向主OSD發出完成資訊前,該PG的狀态都會一直處于degraded狀态。又或者是某個OSD的狀态變成了down,那麼該OSD上的所有PG都會被标記為degraded。

當Ceph因為某些原因無法找到某個PG内的一個或多個object時,該PG也會被标記為degraded狀态。此時用戶端不能讀寫找不到的對象,但是仍然能通路位于該PG内的其他object。

Recovering (恢複中)

當某個OSD因為某些原因down了,該OSD内PG的object會落後于它所對應的PG副本。而在該OSD重新up之後,該OSD中的内容必須更新到目前狀态,處于此過程中的PG狀态便是recovering。

Backfilling (回填)

當有新的OSD加入叢集時,CRUSH會把現有叢集内的部分PG配置設定給它。這些被重新配置設定到新OSD的PG狀态便處于backfilling。

Remapped (重映射)

當負責維護某個PG的acting set變更時,PG需要從原來的acting set遷移至新的acting set。這個過程需要一段時間,是以在此期間,相關PG的狀态便會标記為remapped。

Stale (陳舊的)

預設情況下,OSD守護程序每半秒鐘便會向Monitor報告其PG等相關狀态,如果某個PG的主OSD所在acting set沒能向Monitor發送報告,或者其他的Monitor已經報告該OSD為down時,該PG便會被标記為stale。

四、Monitor管理操作

1.  檢查叢集内Monitor狀态

如果你有多個螢幕(很可能),你啟動叢集後、讀寫資料前應該檢查螢幕法定人數狀态。運作着多個螢幕時必須形成法定人數,最好周期性地檢查螢幕狀态來确定它們在運作。
      

要檢視monmap,可以執行如下指令:

[root@ceph ~] sudo ceph mon stat
#輸出内容大緻如下:
e3: 3 mons at {controller-21=172.x.x.21:6789/0,controller-22=172.x.x.22:6789/0,
controller-23=172.x.x.23:6789/0}, election epoch 48710,
quorum 0,1,2 controller-21,controller-22,controller-23
      

通過以上資訊可以了解到叢集内monmap版本為3,共有3個Monitor守護程序,分别處于哪些主機( 主機名、IP位址、端口号)上,目前的Monitor選舉版本為48710,Monitor叢集内的法定螢幕共有3個(顯示的qourumID個數總和),以及它們的MonitorID。

如果希望進一步了解monmap,可以通過如下指令檢視:

[root@ceph ~] sudo ceph mon dump
#輸出内容大緻如下:
dumped monmap epoch 3
epoch 3
fsid 86673d4c-xxxx-xxxx-xxxx-b61e6681305d
last_changed 2016-09-02 16:05:02.120629
created 2016-09-02 16:03:39.311083
0: 172.16.130.21:6789/0 mon.controller-21
1: 172.16.130.22:6789/0 mon.controller-22
2: 172.16.130.23:6789/0 mon.controller-23
      

通過以上資訊可以額外了解到monmap建立時間及最近一次修改時間。

要獲知Ceph叢集内Monitor叢集法定螢幕的情況,可以使用如下指令檢視:

[root@ceph ~] sudo ceph quorum_status
#輸出内容大緻如下:
{"election_epoch":48710,"quorum":[0,1,2],
     "quorum_names":["controller-21","controller-22","controller-23"],
     "quorum_leader_name":"controller-22",
     "monmap":{"epoch":3,
     "fsid":"86673d4c-xxx-xxxx-xxxxx-b61e6681305d",
     "modified":"2016-09-02 16:05:02.120629",
     "created":"2016-09-0216:03:39.311083",
     "mons":[{"rank":0,"name":"controller-21","addr":"172.16.130.21:6789\ /   0"},
     {"rank":1,"name":"controller-22","addr":"172.16.130.22:6789\/0"},
     {"rank":2,"name":"controller-23","addr":"172.16.130.23:6789\/0"}]}}
      

通過以上資訊,可以了解到Monitor叢集法定螢幕的個數,以及螢幕leader。

2.  實際業務場景

場景一、使用ceph-deploy新增mon節點

需求:産品标準部署完成時,ceph mon一般會部署在某些OSD節點上,需要将mon拆到其他節點上。

操作步驟:

->  使用ceph-deploy建立mon

[root@host-name ~]#ceph-deploy mon create {host-name [host-name]...}
[root@host-name ~]#ceph-deploy mon create newhostname
      

注意事項:

  • 使用ceph-deploy指令的節點上必須有相應權限,可以使用ceph-deploy gatherkeys指令配置設定權限
  • 使用ceph-deploy新增的monitor預設會使用ceph public網絡

->  停止原本在計算節點上的mon程序,驗證叢集是否正常,如果正常則進行下一步。

[root@host-name ~]# /etc/init.d/ceph stop mon
      

->  删除原本在計算節點上的monitor。

[root@host-name ~]# ceph-deploy mon destroy {host-name [host-name]...}
[root@host-name ~]# ceph-deploy mon destroy oldhostname
      

->  修改配置檔案中關于mon的配置,不要使用主機名,應直接使用IP(public網絡),之後同步到所有ceph節點上并重新開機所有mon程序。

由于預設情況下,主機名和IP的對應關系是使用的管理網絡,而使用ceph-deploy新增的monitor預設會使用ceph public網絡是以需要修改配置檔案中"mon_intial_members"及"mon_host"中的主機名為ip位址。

場景二、從一個monitor狀态異常的Ceph叢集中擷取monmap

需求:當一個Ceph叢集的monitor叢集狀态出現異常時,叢集的基本指令都無法使用,這個時候可以嘗試提取出monmap,幫助排查問題。

-> 導出叢集monmap

[root@host-name ~]# ceph-mon -i mon-host-name --extract-monmap /tmp/monmap-file
      

注意:以上指令在mon狀态正常的節點上無法使用。會報如下錯誤:

IO error: lock /var/lib/ceph/mon/ceph-cont01/store.db/LOCK: Resource temporarily unavailable
      

->  使用monmaptool檢視

[root@host-name ~]# monmaptool --print /tmp/monmap-file
monmaptool: monmap file /tmp/monmap
epoch 3
fsid 86673d4c-xxxx-xxxx-xxxx-b61e6681305d
last_changed 2016-10-13 16:17:33.590245
created 2016-10-13 16:16:33.801453
0: 172.16.50.136:6789/0 mon.cont01
1: 172.16.50.137:6789/0 mon.cont02
2: 172.16.50.138:6789/0 mon.cont03
      

五、OSD管理操作

1.  OSD狀态

單個OSD有兩組狀态需要關注,其中一組使用in/out标記該OSD是否在叢集内,另一組使用up/down标記該OSD是否處于運作中狀态。兩組狀态之間并不互斥,換句話說,當一個OSD處于“in”狀态時,它仍然可以處于up或down的狀态。

OSD狀态為in且up

這是一個OSD正常的狀态,說明該OSD處于叢集内,并且運作正常。

OSD狀态為in且down

此時該OSD尚處于叢集中,但是守護程序狀态已經不正常,預設在300秒後會被踢出叢集,狀态進而變為out且down,之後處于該OSD上的PG會遷移至其它OSD。

OSD狀态為out且up

這種狀态一般會出現在新增OSD時,意味着該OSD守護程序正常,但是尚未加入叢集。

OSD狀态為out且down

在該狀态下的OSD不在叢集内,并且守護程序運作不正常,CRUSH不會再配置設定PG到該OSD上。

2.  檢查OSD狀态

在執行ceph health、ceph -s或ceph -w等指令時,也許會發現叢集并未處于HEALTH狀态,就OSD而言,應該關注它是否處于叢集内,以及是否處于運作中狀态。我們可以通過以下指令檢視叢集内所有OSD的狀态:

[root@ceph ~] sudo ceph osd stat
#輸出内容大緻如下:
osdmap e3921: 5 osds: 5 up, 5 in;
      

指令的結果顯示,目前osdmap的版本号為e3921,叢集内共有5個OSD,其中處于“up”狀态的OSD為5個,處于“in”狀态的OSD也為5個。這說明叢集中OSD的狀态處于正常情況。

如果要啟動一個OSD守護程序,請參考前文"叢集管理操作"内容

3.  檢視叢集OSD配置

要了解叢集OSD的配置情況,可以使用下列指令進行檢視。

檢視OSD容量的使用情況

[root@ceph ~] sudo ceph osd df
#輸出内容大緻如下:
ID WEIGHT  REWEIGHT SIZE  USE    AVAIL %USE VAR
0 0.25999  1.00000  269G 21378M  248G 7.75 1.38
3 0.25999  1.00000  269G 19027M  250G 6.90 1.23
4 0.25999  1.00000  269G 14207M  255G 5.15 0.92
1 0.53999  1.00000  548G 23328M  525G 4.15 0.74
     TOTAL 1356G 77942M 1280G 5.61
MIN/MAX VAR: 0/1.38  STDDEV: 1.47
      

從輸出結果可以看到每個OSD的總容量、目前使用量以及可用容量等資訊。

檢視OSD在叢集布局中的設計分布

[root@ceph ~] sudo ceph osd tree
#輸出内容大緻如下:
ID WEIGHT  TYPE NAME       UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.08995 root default
-2 0.02998     host ceph01
 0 0.00999         osd.0        up  1.00000          1.00000
 1 0.00999         osd.1        up  1.00000          1.00000
 2 0.00999         osd.2        up  1.00000          1.00000
-3 0.02998     host ceph02
 3 0.00999         osd.3        up  1.00000          1.00000
 4 0.00999         osd.4        up  1.00000          1.00000
 5 0.00999         osd.5        up  1.00000          1.00000
-4 0.02998     host ceph03
 6 0.00999         osd.6        up  1.00000          1.00000
 7 0.00999         osd.7        up  1.00000          1.00000
 8 0.00999         osd.8        up  1.00000          1.00000
      

從輸出結果可以看到每個OSD的位置分布情況,預設的CRUSHMAP中,OSD按照所在的主機節點分布,可以通過修改CRUSHMAP進行定制化分布設計。同時可以看到每個OSD的WEIGHT值,WEIGHT值與OSD的容量相關,1TB容量換算WEIGHT值為1.0。

檢視OSD的dump概況

[root@ceph ~] sudo ceph osd dump
      

OSD dump輸出的條目較多,基本可以分為三個部分:

輸出OSDmap資訊,包括版本号、叢集ID以及map相關的時間;

POOL的相關資訊,包括POOL ID、POOL名稱、副本數、最小副本數、ruleset ID等資訊;

列出所有OSD的狀态等資訊,包括OSD ID、狀态、狀态版本記錄以及被監聽的IP位址及端口等資訊。

4.  實際業務場景

場景一、使用ceph-deploy新增OSD節點

需求:由于某些原因無法使用salt進行擴容Ceph叢集時,可以考慮使用ceph-deploy工具擴容Ceph叢集。

-> 任選一個monitor節點,安裝ceph-deploy。

[root@host-name ~]# yum install ceph-deploy
      

->  切換至Ceph叢集配置檔案所在目錄,如使用預設名稱ceph,則切換至如下目錄。

[root@host-name ~]# cd /etc/ceph
      

->  編輯/etc/hosts目錄,将新增節點的主機名及IP加入該檔案中。

[root@host-name ~]# vim /etc/hosts
      

->  在新增節點上安裝ceph軟體,并解決依賴關系,也許需要安裝redhat-lsb。

[root@new-node ~]# yum install ceph
[root@new-node ~]# yum install redhat-lsb
      

->  推送相關密鑰及配置檔案至新增節點。

[root@host-name ceph]# ceph-deploy admin new-node
      

->  建立叢集關系key。

[root@host-name ceph]# ceph-deploy gatherkeys 目前節點
[root@host-name ceph]# ceph-deploy gatherkeys new-node
      

->  檢查新增OSD節點的磁盤。

[root@host-name ceph]# ceph-deploy disk list new-node
      

->  建立所要新增OSD節點上的osd。

[root@host-name ceph]# ceph-deploy osd create new-node:new-disk
      

->  少數情況下,需要手動激活新增的osd後,叢集才能正常識别新增的osd。

[root@new-node ~]# ceph-disk activate-all
      

場景二、完全删除osd

需求:需要删除Ceph叢集中一個或多個osd時,可以參考以下做法實作。

-> 停止需要删除的osd程序。

[root@host-name ~]# /etc/init.d/ceph stop osd.x
      

->  将該osd的叢集标記為out。

[root@host-name ~]# ceph osd out osd.x
      

->  将該osd從Ceph crush中移除。

[root@host-name ~]# ceph osd crush remove osd.x
      

->  從叢集中完全删除該osd的記錄。

[root@host-name ~]# ceph osd rm osd.x
      

->  删除該osd的認證資訊,否則該osd的編号不會釋放。

[root@host-name ~]# ceph auth del osd.x
      

六、POOL管理操作

1.  擷取POOL概況

在部署一個Ceph叢集時,會建立一個預設名為rbd的POOL,使用以下指令,可以擷取叢集内所有POOL的概況資訊。

[root@ceph ~] sudo ceph osd pool ls detail
      

使用該指令你可以了解到叢集内POOL的個數、對應的POOL id、POOL名稱、副本數、最小副本數,ruleset及POOL snap等資訊。

2.  建立POOL

在建立一個新的POOL前,可先檢視配置檔案中是否有關于POOL的預設參數,同時了解叢集内CRUSHMAP的設計,之後再建立POOL。

例如,配置檔案中有關于pg_num,pgp_num等預設參數,那麼在使用ceph-deploy自動化部署工具,便會以此參數建立指定POOL。

要手動建立一個POOL的指令文法如下:

#建立一個副本類型的POOL
[root@ceph ~] sudo ceph osd pool create {pool-name} {pg-num} [{pgp-num}] [replicated] \
              [ruleset]
#建立一個糾删碼類型的POOL
[root@ceph ~] sudo ceph osd pool create {pool-name} {pg-num} {pgp-num} erasure \
              [erasure-code-profile] [ruleset]
      

在{}内的參數為必選項,[]内的參數均設有預設值,如果沒有更改設計,可以不添加。

參數的含義如下:

  • pool-name: POOL的名字;必須添加。
  • pg-num: POOL擁有的PG總數;必須添加。具體内容可參考前文:PG管理操作
  • pgp-num: POOL擁有的PGP總數;非必須添加。預設與pg-num相同。
  • replicated|erasure: POOL類型;非必須添加。如不指定為erasure,則預設為replicated類型。
  • ruleset: POOL所用的CRUSH規則ID。非必須添加。預設為0,若需指定其他ruleset,需確定ruleset必須存在。
  • erasure-code-profile: 僅用于糾删碼類型的POOL。指定糾删碼配置架構,此配置必須已由osd erasure-code-profile set 定義

3.  重命名POOL

如果需要重命名存儲池,可以使用以下指令:

[root@ceph ~] sudo ceph osd pool rename {current-pool-name}    {new-pool-name}
      

需要注意的是,在POOL被重命名後,需要用新的POOL名更新對應的認證使用者權限。此部分内容請參考:使用者管理操作

4.  删除POOL

删除存儲池,可以使用以下指令:

[root@ceph ~] sudo ceph osd pool delete {pool-name} [{pool-name} --yes-i-really-really-mean-it]
      

如果有某個認證使用者擁有該池的某些權限,那麼你應該确認該認證使用者是否還有其他作用,确認完畢後,或更 新,或将該使用者删除。

此部分内容請參考:使用者管理操作

5.  設定POOL的配置

可以為每個POOL進行配額,可以設定最大位元組數及最大object數,指令如下:

[root@ceph ~] sudo ceph osd pool set-quota {pool-name} [max_objects {obj-count}] [max_bytes {bytes}]

例如:
[root@ceph ~] sudo ceph osd pool set-quota data max_objects 10000
[root@ceph ~] sudo ceph osd pool set-quota data max_bytes 10240
      

如果要取消配額,隻需要将值設定為0即可。

6.  檢視POOL的統計資訊

檢視叢集内POOL的使用情況,可以使用以下指令:

[root@ceph ~] sudo rados df
      

7.  POOL快照操作

要拍下某個POOL的快照,可以使用以下指令:

[root@ceph ~] sudo ceph osd pool mksnap {pool-name} {snap-name}

例如:
[root@ceph ~] sudo ceph osd pool mksnap snappool snap1
      

要删除某個POOL的快照,可以使用以下指令:

[root@ceph ~] sudo ceph osd pool rmsnap {pool-name} {snap-name}

例如:
[root@ceph ~] sudo ceph osd pool rmsnap snappool snap1
      

要檢視叢集中POOL的快照資訊,暫時未提供ls-snap相關的指令,但可以借助前文提到的指令檢視:

[root@ceph ~] sudo ceph osd pool ls detail
      

8.  置object副本數量

要設定副本類型POOL的對象副本數,可以使用以下指令:

[root@ceph ~] sudo ceph osd pool set {pool-name} size {num-replicas}

例如:
[root@ceph ~] sudo ceph osd pool set replpool size 3
      

當一個object的副本數小于規定值時,仍然可以接受I/O請求。為了保證I/O正常,可以為POOL設定最低副本數,如:

[root@ceph ~] sudo ceph osd pool set replpool min_size 3
      

這確定了該POOL内任何副本數小于min_size的對象都不會再進行I/O。

###############   Ceph常見故障排除方法  ###############

1.  修改 OSD CRUSH weight

1.1  問題描述

部署完成後,叢集處于 PG Degraded 狀态,經查 ceph health detail,發現 PG 的 acting OSD 隻有 [0],而不是兩個。查 osd tree,osd 日志等,看不出明顯問題。

1.2  原因分析

我的 Ceph 叢集的 OSD 的 weight 都是 0!!

[root@ceph1]# /etc/ceph# ceph osd tree
# id    weight  type name       up/down reweight
-1      0       root default
-2      0               host ceph1
0       0                       osd.0   up      1
2       0                       osd.2   up      1
-3      0               host ceph2
1       0                       osd.1   up      1
3       0                       osd.3   up      1
      

從上面 ceph osd tree 的結果裡面可以看到這裡有兩個weight:weight 和 reweight。這篇文章 有詳細的分析。簡單來說:

  • weight:即 osd crush weight,表示裝置(device) 容量的相對值,比如如果1TB對應1.00,那麼 500MB 對應 0.50。bucket weight 是所有 item weight 之和,item weight 的變化會影響 bucket weight 的變化,也就是 osd.X 會影響host。 對于 straw bucket,如果 item weight 為0,則 item straw 也為0,當CRUSH 算法在 bucket 選擇 item 時,也就不太可能選中該 item。
  • reweight:取值為0~1。osd reweight 并不會影響 host。當 osd 被踢出叢集(out)時,osd weight 被設定0,加入叢集時,設定為1。它會參與 CRUSH 建立 PG 的過程。CRUSH在選擇 OSD 時,如果發現 weight 為0,就跳過該 OSD。

是以,問題的症結就在于 osd crush weight 為0。至于為什麼會這樣,以及該值對 PG 配置設定的影響,有待進一步查明。

1.3)解決辦法:修改 osd crush weight

ceph osd crush reweight osd.0 1
ceph osd crush reweight osd.1 1
ceph osd crush reweight osd.2 1
ceph osd crush reweight osd.3 1
      

修改後,叢集就回到了 HEALTH_OK 狀态。

注意:修改 OSD 的 crush weight 會帶來部分 PG 之間的資料移動,這可能會影響叢集的性能,是以在生産環境中使用要小心。你可以參考 這篇文章 來看資料移動的情況。

2.  修改 CRUSH tunables(可調參數)

2.1  問題描述

将 osd.1 設定為 out 後,叢集并沒有開始做 recovery,部分 PG 保持在 remapped 狀态:

[root@ceph1]# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 88 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e71: 4 osds: 4 up, 3 in
      pgmap v442: 256 pgs, 4 pools, 285 MB data, 8 objects
            690 MB used, 14636 MB / 15326 MB avail
                  88 active+remapped
                 168 active+clean
      

2.2  原因分析

->  檢視 ceph health detail

[root@ceph1]# ceph health detail
HEALTH_WARN 88 pgs stuck unclean
pg 1.23 is stuck unclean for 337.342290, current state active+remapped, last acting [0,1]
pg 0.1f is stuck unclean for 336.838743, current state active+remapped, last acting [0,1]
pg 1.1f is stuck unclean for 337.355851, current state active+remapped, last acting [0,1]
      

Remapped(重映射):當 PG 的 acting set 變化後,資料将會從舊 acting set 遷移到新 action set。新主 OSD 需要過一段時間後才能提供服務。是以,它會讓老的主 OSD 繼續提供服務,直到 PG 遷移完成。資料遷移完成後,PG map 将使用新 acting set 中的主OSD。

以 PG 為例,比較在 osd.1 out 前後的 PG map:

state           state_stamp                     v       reported        up      up_primary      acting      acting_primary
active+clean    2016-06-03 00:31:44.220896      0'0     57:74           [0,1]    0              [0,1]       0               #osd.1 out 之前
active+remapped 2016-06-03 00:47:12.703537      0'0     71:109          [0]      0              [0,1]       0               #osd.1 out 之後
      

2.3  解決辦法

辦法一:将 cursh tunables 設定為 optimal

->  從這篇文章中獲得線索,這可能和 crush tunables 有關系。它的預設值應該是 legacy,運作下面的指令将其修改為 optimal 後,叢集狀态回到正常。

ceph osd crush tunables optimal
      

->  繼續找原因,Red Hat 這篇文章 給出了一些線索。

在新版本的Ceph 叢集中使用 legacy 值可能會有一些問題,包括:

  • 當葉子bucket(往往是 host)所擁有的裝置數目很小時,一些 PG 被映射到的 OSD 數目少于存儲池的size。這在 host 節點的 OSD 數目為 1-3 時較為常見。
  • 大型叢集中,小部分的 PG 被映射到的 OSD 數目小于規定的數目。這在 CRUSH 層級結構中好幾層(比如 row,rack,host,osd 等)時比較常見。
  • 當一些 OSD 被标記為 out 時,重新分布的資料會更多地在附近的 OSD 上而不是整個層級結構中。

而第一種情況正是我的測試叢集所遇到的情況,每個 host 擁有的 OSD 數目在3個以内,然後部分 PG 所在的 OSD 數目較 replica 少一些。

辦法二:将 OSD 的 reweight 修改為 0 而不是使用 out 指令

Ceph 官方的這篇文章 給出了另一個思路。它認為在主機數目很小的叢集中,當一個 OSD 被 out 後,部分 PG 限于 active+remapped 狀态是經常出現的。解決辦法是先運作 ceph osd in {osd-num} 将叢集狀态恢複到初始狀态,然後運作 ceph osd crush reweight osd.{osd-num} 0 來将這個 osd 的 crush weight 修改為 0,然後叢集會開始資料遷移。對小叢集來說,reweight 指令甚至更好些。

當叢集中 PG 限于 active + remapped 狀态時,可以通過 reweight 指令來使得叢集恢複正常。當往叢集中新加入 OSD 時,為了減少資料移動對叢集性能的影響,Ceph 官方建議逐漸地增加 OSD 的 crush weight,比如起始值為0,先設定為 0.2,等資料遷移結束,再設定為 0.4,依此類推,逐漸增加為 0.6,0.8 和 1 甚至更高。在要停用一個 OSD 時,建議采用相反操作,逐漸減少 OSD 的 crush weight 直至 0.

3.  修改 CRUSH ruleset

3.1  問題描述

繼續将跟 osd.1 在同意個host 上的 osd.3 out,看看 Ceph 叢集能不能繼續恢複。Ceph 叢集中部分 PG 再次進入 remapped 狀态:

[root@ceph1:~]# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 256 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e77: 4 osds: 4 up, 2 in
      pgmap v480: 256 pgs, 4 pools, 285 MB data, 8 objects
            625 MB used, 9592 MB / 10217 MB avail
                 256 active+remapped
      

運作 ceph pg 1.0 query 檢視 PG 1.0 的狀态:

"recovery_state": [
        { "name": "Started\/Primary\/Active",
          "enter_time": "2016-06-03 01:31:22.045434",
          "might_have_unfound": [],
          "recovery_progress": { "backfill_targets": [],
              "waiting_on_backfill": [],
              "last_backfill_started": "0\/\/0\/\/-1",
              "backfill_info": { "begin": "0\/\/0\/\/-1",
                  "end": "0\/\/0\/\/-1",
                  "objects": []},
              "peer_backfill_info": [],
              "backfills_in_flight": [],
              "recovering": [],
              "pg_backend": { "pull_from_peer": [],
                  "pushing": []}},
          "scrub": { "scrubber.epoch_start": "0",
              "scrubber.active": 0,
              "scrubber.block_writes": 0,
              "scrubber.finalizing": 0,
              "scrubber.waiting_on": 0,
              "scrubber.waiting_on_whom": []}},
        { "name": "Started",
          "enter_time": "2016-06-03 01:31:20.976290"}],
      

可見它已經開始 recovery 了,但是沒完成。

3.2  原因分析

PG 的分布和 CRUSH ruleset 有關。我的叢集目前隻有一個預設的 ruleset:

[root@ceph1:~]# ceph osd crush rule dump
[
    { "rule_id": 0,
      "rule_name": "replicated_ruleset",
      "ruleset": 0,
      "type": 1,
      "min_size": 1,
      "max_size": 10,
      "steps": [
            { "op": "take",
              "item": -1,
              "item_name": "default"},
            { "op": "chooseleaf_firstn",
              "num": 0,
              "type": "host"},
            { "op": "emit"}]}]
      

注意其 type 為 “host”,也就是說 CRUSH 不會為一個 PG 選擇在同一個 host 上的兩個 OSD。而我的環境中,目前隻有 ceph1 上的兩個 OSD 是in 的,是以,CRUSH 無法為所有的 PG 重新選擇一個新的 OSD 來替代 osd.3.

3.3  解決辦法

按照以下步驟,将 CRUSH ruleset 的 type 由 “host” 修改為 “osd”,使得 CRUSH 為 PG 選擇 OSD 時不再局限于不同的 host。

[root@ceph1:~]# ceph osd getcrushmap -o crushmap_compiled_file
got crush map from osdmap epoch 77
[root@ceph1:~]# crushtool -d crushmap_compiled_file -o crushmap_decompiled_file
[root@ceph1:~]# vi crushmap_decompiled_file
rule replicated_ruleset {
        ruleset 0
        type replicated
        min_size 1
        max_size 10
        step take default
        step chooseleaf firstn 0 type osd #将 type 由 “host” 修改為 “osd”
        step emit
}

[root@ceph1:~]# crushtool -c crushmap_decompiled_file -o newcrushmap
[root@ceph1:~]# ceph osd setcrushmap -i newcrushmap
set crush map      

以上指令執行完畢後,可以看到 recovery 過程繼續進行,一段時間後,叢集恢複 OK 狀态。

[root@ceph1:~]# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 256 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e80: 4 osds: 4 up, 2 in
      pgmap v493: 256 pgs, 4 pools, 285 MB data, 8 objects
            552 MB used, 9665 MB / 10217 MB avail
                 256 active+remapped
[root@ceph1:~]# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_WARN 137 pgs stuck unclean
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e80: 4 osds: 4 up, 2 in
      pgmap v494: 256 pgs, 4 pools, 285 MB data, 8 objects
            677 MB used, 9540 MB / 10217 MB avail
                 137 active+remapped
                 119 active+clean
recovery io 34977 B/s, 0 objects/s
[root@ceph1:~]# ceph -s
    cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71
     health HEALTH_OK
     monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1
     osdmap e80: 4 osds: 4 up, 2 in
      pgmap v495: 256 pgs, 4 pools, 285 MB data, 8 objects
            679 MB used, 9538 MB / 10217 MB avail
                 256 active+clean
recovery io 18499 kB/s, 0 objects/s
      

4.  将一個 OSD 移出叢集

4.1  将該 osd 設定為 out

[root@ceph1:/home/s1]# ceph osd out osd.1
marked out osd.1.
      

4.2  叢集做 recovery

2017-06-03 01:54:21.596632 mon.0 [INF] osdmap e90: 4 osds: 4 up, 3 in
2017-06-03 01:54:21.608675 mon.0 [INF] pgmap v565: 256 pgs: 256 active+clean; 1422 MB data, 2833 MB used, 12493 MB / 15326 MB avail
2017-06-03 01:54:26.352909 mon.0 [INF] pgmap v566: 256 pgs: 1 active, 255 active+clean; 1422 MB data, 2979 MB used, 12347 MB / 15326 MB avail; 2/40 objects degraded (5.000%); 51033 B/s, 0 objects/s recovering
2017-06-03 01:54:28.624334 mon.0 [INF] pgmap v567: 256 pgs: 4 active, 252 active+clean; 1422 MB data, 3427 MB used, 11899 MB / 15326 MB avail; 8/40 objects degraded (20.000%); 51053 B/s, 0 objects/s recovering
2017-06-03 01:54:31.320973 mon.0 [INF] pgmap v568: 256 pgs: 3 active, 253 active+clean; 1422 MB data, 3539 MB used, 11787 MB / 15326 MB avail; 6/40 objects degraded (15.000%); 19414 kB/s, 0 objects/s recovering
2017-06-03 01:54:32.323443 mon.0 [INF] pgmap v569: 256 pgs: 256 active+clean; 1422 MB data, 3730 MB used, 11595 MB / 15326 MB avail; 77801 kB/s, 0 objects/s recovering
2017-06-03 01:56:10.949077 mon.0 [INF] pgmap v570: 256 pgs: 256 active+clean; 1422 MB data, 3730 MB used, 11595 MB / 15326 MB avail
      

4.3  完成後,該 osd 的狀态還是 up,表示它的服務還在運作。現在将其服務停掉。

[root@ceph1:/home/s1]# ssh ceph2 service ceph stop osd.1
/etc/init.d/ceph: osd.1 not found (/etc/ceph/ceph.conf defines , /var/lib/ceph defines )
      

該指令出錯,需要将 osd.1 加入 ceph.conf 中。在 ceph1 上的 ceph.conf 中添加:

[osd]

[osd.1]
host = ceph2

[osd.2]
host = ceph1

[osd.3]
host = ceph2

[osd.0]
host = ceph1
      

然後運作 ceph-deploy –overwrite-conf config push ceph2 将它拷貝到 ceph2 上。重新開機所有的 osd 服務。詭異的事情出現了:

[root@ceph1:/etc/ceph]# ceph osd tree
# id    weight  type name       up/down reweight
-1      4       root default
-2      4               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
1       1                       osd.1   up      0
3       1                       osd.3   up      1
-3      0               host ceph2
      

osd.1 和 osd.3 跑到了 ceph1 節點上!檢視 start 指令,它将 curshmap 中的 osd.1 的 host 修改為了 ceph2:

[root@ceph1:/etc/ceph]# /etc/init.d/ceph -a start osd
=== osd.1 ===
df: ‘/var/lib/ceph/osd/ceph-1/.’: No such file or directory
create-or-move updating item name 'osd.1' weight 1 at location {host=ceph1,root=default} to crush map
Starting Ceph osd.1 on ceph2...
starting osd.1 at :/0 osd_data /var/lib/ceph/osd/ceph-1 /var/lib/ceph/osd/ceph-1/journal
      

從 這篇文章 可以看出,這其實是Ceph的一個 bug:make osd crush placement on startup handle multiple trees (e.g., ssd + sas)。該bug 在 OSD location reset after restart 中也有讨論。目前 Ceph 沒有機制可以確定 CRUSH map 結構不變,最簡單的辦法是在 ceph.conf 中 [OSD] 部分設定 osd crush update on start = false。

嘗試手工挪動 osd.1 和 osd.3:

[root@ceph1:/etc/ceph]# ceph osd crush remove osd.1
removed item id 1 name 'osd.1' from crush map
[root@ceph1:/etc/ceph]# ceph osd crush remove osd.3
removed item id 3 name 'osd.3' from crush map

[root@ceph1:/etc/ceph]# ceph osd tree
# id    weight  type name       up/down reweight
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
1       0       osd.1   up      0
3       0       osd.3   up      1

[root@ceph1:/etc/ceph]# ceph osd crush set 1 1 root=default host=ceph2
Error ENOENT: unable to set item id 1 name 'osd.1' weight 1 at location {host=ceph2,root=default}: does not exist
      

該錯誤的原因待查。索性直接修改 crush map,然後正确的結果就回來了:

[root@ceph1:/etc/ceph]# ceph osd tree
# id    weight  type name       up/down reweight
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
1       1                       osd.1   up      0
3       1                       osd.3   up      1
      

繼續運作指令 ssh ceph2 /etc/init.d/ceph stop osd.1 去停止 osd.1 的服務,但是無法停止。據說是因為用 ceph-deploy 部署的 OSD 的服務都沒法停止。隻能想辦法把程序殺掉了。

然後繼續執行:

[root@ceph1:/etc/ceph]# ceph osd crush remove osd.1
removed item id 1 name 'osd.1' from crush map
[root@ceph1:/etc/ceph]# ceph auth del osd.1
updated
[root@ceph1:/etc/init]# ceph osd rm osd.1
removed osd.1
      

此時,osd tree 中再也沒有 osd.1 了:

[root@ceph1:/etc/ceph]# ceph osd tree
# id    weight  type name       up/down reweight
-1      3       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      1               host ceph2
3       1                       osd.3   up      1
      

5.  将一個 OSD 加入叢集

  • /dev/sdb1 分區删除
  • 清理磁盤:ceph-deploy disk zap ceph2:/dev/sdb
  • 建立 OSD:ceph-deploy osd create ceph2:sdb:/dev/sdd1

結果OSD就回來了:

[root@ceph1:~]# ceph-deploy osd create ceph2:sdb:/dev/sdd1c^C
[root@ceph1:~]# ceph osd tree
# id    weight  type name       up/down reweight
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
4       0                       osd.4   up      1
1       0                       osd.1   up      1
      

其實将上面第四步和第五步合并在一起,就是替換一個故障磁盤的過程。

6.  在特定 OSD 上建立存儲池

假設 osd.0 和 osd.2 的磁盤是 SSD 磁盤,osd.1 和 osd.4 的磁盤是 SATA 磁盤。我們将建立兩個pool:pool-ssd 和 pool-sata,并確定 pool-ssd 中的對象都儲存在 osd.0 和 osd.2 上,pool-sata 中的對象都儲存在 osd.1 和 osd.4 上。

6.1  修改 CRUSH map

[root@ceph1:~]# ceph osd getcrushmap -o crushmapdump
got crush map from osdmap epoch 124
[root@ceph1:~]# crushtool -d crushmapdump -o crushmapdump-decompiled
[root@ceph1:~]# vi crushmapdump-decompiled
[root@ceph1:~]# crushtool -c crushmapdump-decompiled -o crushmapdump-compiled
[root@ceph1:~]# ceph osd setcrushmap -i crushmapdump-compiled
      

在 crushmapdump-decompiled 檔案中添加如下内容:

root ssd {
        id -5
        alg straw
        hash 0
        item osd.0 weight 1
        item osd.2 weight 1
}

root sata {
        id -6
        alg straw
        hash 0
        item osd.1 weight 1
        item osd.4 weight 1
}

# rules
...

rule ssd-pool {
        ruleset 1
        type replicated
        min_size 1
        max_size 10
        step take ssd
        step chooseleaf firstn 0 type osd
        step emit
}

rule sata-pool {
        ruleset 2
        type replicated
        min_size 1
        max_size 10
        step take sata
        step chooseleaf firstn 0 type osd
        step emit
}
      

6.2  ceph osd tree 

[root@ceph1:~]# ceph osd tree
# id    weight  type name       up/down reweight
-6      2       root sata
1       1               osd.1   up      1
4       1               osd.4   up      1
-5      2       root ssd
0       1               osd.0   up      1
2       1               osd.2   up      1
-1      2       root default
-2      2               host ceph1
0       1                       osd.0   up      1
2       1                       osd.2   up      1
-3      0               host ceph2
4       0                       osd.4   up      1
1       0                       osd.1   up      1
      

6.3  建立 ssd-pool,其預設的 ruleset 為 0

[root@ceph1:~]# ceph osd pool create ssd-pool 8 8
pool 'ssd-pool' created
root@ceph1:~# ceph osd dump | grep -i ssd
pool 4 'ssd-pool' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change 126 flags hashpspool stripe_width 0
      

6.4  修改 ssd-pool 的 ruleset 為 ssd-pool 其id 為 1

[root@ceph1:~]# ceph osd pool set ssd-pool crush_ruleset 1
set pool 4 crush_ruleset to 1
[root@ceph1:~]# ceph osd dump | grep -i ssd
pool 4 'ssd-pool' replicated size 2 min_size 1 crush_ruleset 1 object_hash rjenkins pg_num 8 pgp_num 8 last_change 128 flags hashpspool stripe_width 0
      

6.5  類似地建立 sata-pool 并設定其 cursh ruleset 為 sata-pool 其id 為 2

[root@ceph1:~]# ceph osd pool create sata-pool 8 8
pool 'sata-pool' created
[root@ceph1:~]# ceph osd pool set sata-pool crush_ruleset 2
set pool 5 crush_ruleset to 2
[root@ceph1:~]# ceph osd dump | grep -i sata
pool 5 'sata-pool' replicated size 2 min_size 1 crush_ruleset 2 object_hash rjenkins pg_num 8 pgp_num 8 last_change 131 flags hashpspool stripe_width 0
      

6.6  分别放一個檔案進這兩個pool

[root@ceph1:/home/s1]# rados -p ssd-pool put root-id_rsa root-id_rsa
[root@ceph1:/home/s1]# rados -p sata-pool put root-id_rsa root-id_rsa
[root@ceph1:/home/s1]# rados -p ssd-pool ls
root-id_rsa
[root@ceph1:/home/s1]# rados -p sata-pool ls
root-id_rsa
      

6.7  檢視對象所在的 OSD

[root@ceph1:/home/s1]# ceph osd map ssd-pool root-id_rsa
osdmap e132 pool 'ssd-pool' (4) object 'root-id_rsa' -> pg 4.38e001ef (4.7) -> up ([2,0], p2) acting ([2,0], p2)
[root@ceph1:/home/s1]# ceph osd map sata-pool root-id_rsa
osdmap e132 pool 'sata-pool' (5) object 'root-id_rsa' -> pg 5.38e001ef (5.7) -> up ([4,1], p4) acting ([4,1], p4)
      

可見,兩個pool各自在ssd 和 sata 磁盤上。

###############  ceph-deploy常見運維指令  ###############

# ceph-deploy new [initial-monitor-node(s)]
開始部署一個叢集,生成配置檔案、keyring、一個日志檔案。

# ceph-deploy install [HOST] [HOST…]
在遠端主機上安裝ceph相關的軟體包, --release可以指定版本,預設是firefly。

# ceph-deploy mon create-initial
部署初始monitor成員,即配置檔案中mon initial members中的monitors。部署直到它們形成表決團,然後搜集keys,并且在這個過程中報告monitor的狀态。

# ceph-deploy mon create [HOST] [HOST…]
顯示的部署monitor,如果create後面不跟參數,則預設是mon initial members裡的主機。

# ceph-deploy mon add [HOST]
将一個monitor加入到叢集之中。

# ceph-deploy mon destroy [HOST]
在主機上完全的移除monitor,它會停止了ceph-mon服務,并且檢查是否真的停止了,建立一個歸檔檔案夾mon-remove在/var/lib/ceph目錄下。

# ceph-deploy gatherkeys [HOST] [HOST…]
擷取提供新節點的驗證keys。這些keys會在新的MON/OSD/MD加入的時候使用。

# ceph-deploy disk list [HOST]
列舉出遠端主機上的磁盤。實際上調用ceph-disk指令來實作功能。

# ceph-deploy disk prepare [HOST:[DISK]]
為OSD準備一個目錄、磁盤,它會建立一個GPT分區,用ceph的uuid标記這個分區,建立檔案系統,标記該檔案系統可以被ceph使用。

# ceph-deploy disk activate [HOST:[DISK]]
激活準備好的OSD分區。它會mount該分區到一個臨時的位置,申請OSD ID,重新mount到正确的位置/var/lib/ceph/osd/ceph-{osd id}, 并且會啟動ceph-osd。

# ceph-deploy disk zap [HOST:[DISK]]
擦除對應磁盤的分區表和内容。實際上它是調用sgdisk –zap-all來銷毀GPT和MBR, 是以磁盤可以被重新分區。

# ceph-deploy osd prepare HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
為osd準備一個目錄、磁盤。它會檢查是否超過MAX PIDs,讀取bootstrap-osd的key或者寫一個(如果沒有找到的話),然後它會使用ceph-disk的prepare指令來準備磁盤、日志,并且把OSD部署到指定的主機上。

# ceph-deploy osd active HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
激活上一步的OSD。實際上它會調用ceph-disk的active指令,這個時候OSD會up and in。

# ceph-deploy osd create HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
上兩個指令的綜合。

# ceph-deploy osd list HOST:DISK[:JOURNAL] [HOST:DISK[:JOURNAL]…]
列舉磁盤分區。

# ceph-deploy admin [HOST] [HOST…]
将client.admin的key push到遠端主機。将ceph-admin節點下的client.admin keyring push到遠端主機/etc/ceph/下面。

# ceph-deploy push [HOST] [HOST…]
将ceph-admin下的ceph.conf配置檔案push到目标主機下的/etc/ceph/目錄。 # ceph-deploy pull [HOST]是相反的過程。

# ceph-deploy uninstall [HOST] [HOST…]
從遠處主機上解除安裝ceph軟體包。有些包是不會删除的,像librbd1, librados2。

# ceph-deploy purge [HOST] [HOST…]
類似上一條指令,增加了删除data。

# ceph-deploy purgedata [HOST] [HOST…]
删除/var/lib/ceph目錄下的資料,它同樣也會删除/etc/ceph下的内容。

# ceph-deploy forgetkeys
删除本地目錄下的所有驗證keyring, 包括client.admin, monitor, bootstrap系列。

# ceph-deploy pkg –install/–remove [PKGs] [HOST] [HOST…]
在遠端主機上安裝或者解除安裝軟體包。[PKGs]是逗号分隔的軟體包名清單。

##########################################################################################
對ceph叢集中某個節點ceph-node解除安裝其上的服務
# stop ceph-all                                             # 停止所有ceph程序
# ceph-deploy uninstall  [{ceph-node}]                      # 解除安裝所有ceph程式
# ceph-deploy purge   [[ceph-node} [{ceph-node}]            # 删除ceph相關的包
# ceph-deploy purgedata {ceph-node} [{ceph-node}]           # 删除ceph相關的包
# ceph-deploy forgetkeys                                    # 删除key

##########################################################################################
ceph安裝包介紹:
1.ceph-deploy
ceph的部署軟體,通過該軟體可以簡便部署,這個軟體并非整個ceph叢集系統中必須的

2.ceph
ceph整個服務叢集中的每個節點必須的軟體。提供分布式的存儲與檔案系統服務 (osd,mon守護程序)

3.ceph-mds
中繼資料服務端 (mds 守護程序)

4.libcephfs
用戶端的程式設計接口(c語言)

5.python-cephfs
用戶端的程式設計接口(python)

6.ceph-common,ceph-fs-common 用戶端:
使用ceph服務的用戶端必須要有的

############################################
下面這三種程序分布于叢集中的伺服器上,伺服器中可以隻運作一種,也可以多個同時運作,推薦為一個伺服器運作一種,使得負載均衡:
osd 守護程序:即為存儲守護程序
mon 守護程序:螢幕守護程序
mds 守護程序:中繼資料守護程序      

###############  ceph-deploy部署ceph叢集的簡單流程  ###############

架構說明:
node1:admin-node,mon,mgr,osd
node2:osd
node3:osd

server:  3台虛拟機,挂載卷/dev/vdb 10G
系統:    centos7.2
ceph版本:luminous

一、準備工作
####################################################################################
1、安裝centos、epel repo
使用阿裡雲mirros,https://opsx.alibaba.com/mirror
# mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
# curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
# mv /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backup
# mv /etc/yum.repos.d/epel-testing.repo /etc/yum.repos.d/epel-testing.repo.backup
# curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

2、安裝ceph repo
# yum install centos-release-ceph-luminous -y

3、安裝ceph-deploy
# yum update -y
# yum installl ceph-deploy -y

4、安裝、配置ntp
# yum install ntp ntpdate ntp-doc -y

5、安裝ssh(系統自帶請忽略或更新)
确認所有節點的ssh server 運作
# yum install openssh-server -y

6、使用者設定
使用root使用者,雖然官方不推薦這樣。配置管理節點到其他server免密登入
生成秘鑰對
# ssh-keygen -t rsa
将管理節點公鑰注入到其他server
# ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

7、確定networking 啟動
8、配置hosts,将ip hostname 寫入/etc/hosts
9、關閉iptables
10、關閉selinux
11、安裝yum-plugin-priorities
# yum install yum-plugin-priorities -y

二、部署叢集
####################################################################################
在管理節點使用ceph-deploy部署ceph cluster

建立部署目錄
# mkdir ~/my-cluster
# cd ~/my-cluster

從頭開始(非第一次部署ceph,清理環境)
# ceph-deploy purge {ceph-node}[{ceph-node}]
# ceph-deploy purgedata {ceph-node}[{ceph-node}]
# ceph-deploy forgetkeys
# rm ceph.*

建立叢集
建立monitor節點,指令是"ceph-deploy new {initial-monitor-node(s)}"
# ceph-deploy new node1

安裝ceph包到各個節點
# ceph-deploy install node1 node2 node3

初始化monitor節點,擷取keys
# ceph-deploy mon create-initial

上述指令執行成功後,你會在目前目錄下得到以下keyring檔案
# ceph.client.admin.keyring
# ceph.bootstrap-mgr.keyring
# ceph.bootstrap-osd.keyring
# ceph.bootstrap-mds.keyring
# ceph.bootstrap-rgw.keyring
# ceph.bootstrap-rbd.keyring

将keyring檔案分發到各個節點
# ceph-deploy admin node1 node2 node3

部署manager(l版本之上才需要)
# ceph-deploy mgr create node1

部署osd節點(這裡使用虛拟機,挂載了/dev/vdb卷)
# ceph-deploy osd create node1:/dev/vdb node2:/dev/vdb node3:/dev/vdb

檢查叢集,在管理節點執行
# ceph health
# ceph -s

三、擴充叢集
####################################################################################
node1 擴充了metadata,(rgw)
node2 擴充了metadata,monitor
node3 擴充了metadata,monitor

添加metadate server
# ceph-deploy mds create node1

添加monitors
# ceph-deploy mon add node2 node3

添加新的monitor節點之後,ceph會同步monitor,選舉代表quorum
檢視quorum狀态
# ceph quorum_status --format json-pretty

添加managers
manager使用active/standby模式,多節點部署,可以在master down時,無縫頂替
# ceph-deploy mgr create node2 node3

添加rgw執行個體
為了使用ceph object gateway,需要部署rgw執行個體
# ceph-deploy rgw create node1

rgw預設監聽端口是7480,可以通過編輯ceph.conf修改端口
[client]
rgw frontends = civetweb port=80

四、存儲、檢索對象資料
####################################################################################
為了存儲對象資料,ceph client需要具備:
1. 設定一個對象名
2. 指定一個pool

ceph client 檢索最近的叢集map和CRUSH算法去計算怎樣映射對象到PG,然後計算如何動态映射PG到OSD,
隻需要對象name和pool name即可找到對象的位置。指令為"ceph osd map {poolname}{object-name}"

練習:定位對象
建立一個對象,測試檔案
# echo {Test-data}> testfiles.txt
# ceph osd pool create mytest 8

使用rados put 指令指定對象名,含有對象資料的測試檔案,pool name。指令格式"rados put {object-name} {file-path} --pool=mytest"
# rados put test-object-1 testfile.txt --pool=mytest

驗證ceph叢集已經存儲了此object
# rados -p mytest ls

找到對象位置。指令格式"ceph osd map {pool-name} {object-name}"
# ceph osd map mytest test-oobject-1

ceph會輸出對象位置
# osdmap e537 pool 'mytest'(1) object 'test-object-1'-> pg 1.d1743484(1.4)-> up [1,0] acting [1,0]

删除測試對象object
# rados rm test-object-1--pool-mytest

删除mytest pool
# ceph osd pool rm mytest

随着叢集的發展,對象位置可能會動态變化。Ceph的動态重新平衡的一個好處是,Ceph可以讓您不必手動執行資料遷移或平衡。

五、如果虛拟機沒有硬碟,可使用裸裝置模拟
####################################################################################
安裝lvm
# yum install lvm2 -y

建立虛拟磁盤
# mkdir /ceph && dd if=/dev/zero of=/ceph/ceph-volumes.img bs=1M count=10240 oflag=direct
# sgdisk -g --clear /ceph/ceph-volumes.img
# vgcreate ceph-volumes $(losetup --show -f /ceph/ceph-volumes.img)
# lvcreate -L 9G -n ceph1 ceph-volumes
# mkfs.xfs -f /dev/ceph-volumes/ceph1
 
挂載
# mkdir -p /var/local/osd1
# chown ceph:ceph /var/local/osd1   #修改屬主屬組,不然在添加osd時候會報權限錯誤
# mount /dev/ceph-volumes/ceph1 /var/local/osd1      

###############  Ceph添加OSD節點 (非ceph-deploy方法)  ###############

1. 首先需要在新的節點(ceph5,ip為172.16.60.15)上安裝ceph軟體。
需要先做一系列的準備工作,如:配置ntp,做好管理節點到新增osd節點的ssh無密碼信任關系。

在管理節點上執行:
[root@ceph-admin ~]# ceph-deploy install --no-adjust-repos ceph5

2. 擷取osd的ID 
這個操作是在管理節點上執行
[root@ceph-admin ~]# ceph osd create          #記錄得到的編号,如下編号0就是下面建立的osd的ID。 
0

3. 編輯配置檔案,這個檔案是在管理節點上的,為了安全也可以同步到别的節點上儲存
[root@ceph-admin ~]# vim /etc/ceph/ceph.conf  
添加 [osd.0]  public addr = 172.16.60.15 

4. 同步配置文檔到節點ceph5,這個操作在管理節點上執行(172.16.60.10是ceph管理節點位址)
[root@ceph-admin ~]# scp -r [email protected]:/etc/ceph/ [email protected]:/etc/ 

5. 部署osd節點 
登陸到ceph5或者ssh到ceph5機器上都可以
[root@ceph-admin ~]# ssh [email protected] 

6. 對磁盤做處理
[root@ceph5 ~]# parted /dev/sdb mktable gpt  
[root@ceph5 ~]# parted /dev/sdb mkpart osd.0 1 20g      #新加的硬碟為20g,并将所有空間劃分為一個分區 

7. 格式化和挂載,ceph5機器上的磁盤
[root@ceph5 ~]# mkfs -t xfs /dev/sdb1 
[root@ceph5 ~]# mkdir -p /data/osd.0
[root@ceph5 ~]# mkdir -p /var/lib/ceph/osd/ceph-0
[root@ceph5 ~]# mount /dev/sdb1 /data/osd.1 

8. 安裝新osd的相關,初始化 OSD 資料目錄
[root@ceph5 ~]# ceph-osd -i 0 --mkfs --mkkey             #這裡的"0就是osd是的編号,即上面"ceph osd create"輸出的數字

9. 注冊此 OSD 的密鑰
[root@ceph5 ~]# ceph auth add osd.1 osd 'allow *' mon 'allow rwx' -i /var/lib/ceph/osd/ceph-0/keyring

10. 把此 OSD 加入 CRUSH 圖之後,它就能接收資料了
[root@ceph5 ~]# ceph osd crush add osd.0 0.2 root=default host=ceph5

11. 啟動osd程序 
[root@ceph5 ~]# ceph-osd -i 0

12. 檢視程序  
[root@ceph5 ceph-0]# ps -ef|grep ceph-osd 
root       3238      1 21 10:54 ?        00:00:01 ceph-osd -i 0
root       3369   2654  0 10:54 pts/0    00:00:00 grep --color=auto ceph-osd  

13. 檢視osd狀态
[root@ceph5 ceph-0]# ceph osd stat  osd添加成功  
[root@ceph5 ceph-0]# ceph osd stat 
     osdmap e175: 6 osds: 5 up, 5 in
            flags sortbitwise,require_jewel_osds      

############### Ceph删除osd的正确方式 ###############

在ceph的叢集當中關于節點的删除問題,一直按照以前的方式進行的處理,處理的步驟如下:

1. 停止osd程序
# /etc/init.d/ceph stop osd.0
這一步是停止osd的程序,讓其他的osd知道這個節點不提供服務了

2. 将節點狀态标記為out
# ceph osd out osd.0
這個一步是告訴mon,這個節點已經不能服務了,需要在其他的osd上進行資料的恢複了

3. 從crush中移除節點
# ceph osd crush remove osd.0
從crush中删除是告訴叢集這個點回不來了,完全從叢集的分布當中剔除掉,讓叢集的crush進行一次重新計算,之前節點還占着這個crush weight,
會影響到目前主機的host crush weight

4. 删除節點
# ceph osd rm osd.0
這個是從叢集裡面删除這個節點的記錄

5. 删除節點認證(不删除編号會占住)
# ceph auth del osd.0
這個是從認證當中去删除這個節點的資訊

================================================================================================================
這個一直是處理故障節點osd的方式,其實這個會觸發兩次遷移:一次是在節點osd out以後,一個是在crush remove以後。
兩次遷移對于ceph叢集來說是不好的,其實可以調整步驟是可以避免二次遷移的,做法如下新的處理方式。
================================================================================================================

################# 對于osd故障節點删除的新的處理方式(推薦)##########################
1. 調整osd的crush weight
# ceph osd crush reweight osd.0 0.1
說明:這個地方如果想慢慢的調整就分幾次将crush 的weight 減低到0 ,這個過程實際上是讓資料不分布在這個節點上,讓資料慢慢的分布到其他節點上,
直到最終為沒有分布在這個osd,并且遷移完成這個地方不光調整了osd 的crush weight ,實際上同時調整了host 的 weight ,這樣會調整叢集的整體的crush 分布,
在osd 的crush 為0 後, 再對這個osd的任何删除相關操作都不會影響到叢集的資料的分布

2. 停止osd程序
# /etc/init.d/ceph stop osd.0
停止到osd的程序,這個是通知叢集這個osd程序不在了,不提供服務了,因為本身沒權重,就不會影響到整體的分布,也就沒有遷移。

3. 将節點狀态标記為out
# ceph osd out osd.0
停止到osd的程序,這個是通知叢集這個osd不再映射資料了,不提供服務了,因為本身沒權重,就不會影響到整體的分布,也就沒有遷移

4. 從crush中移除節點
# ceph osd crush remove osd.0
這個是從crush中删除,因為已經是0了 是以沒影響主機的權重,也就沒有遷移了

5. 删除節點
# ceph osd rm osd.0
這個是從叢集裡面删除這個節點的記錄

6. 删除節點認證(不删除編号會占住)
# ceph auth del osd.0
這個是從認證當中去删除這個節點的資訊

經過驗證,第二種方式隻觸發了一次遷移,雖然隻是一個步驟先後上的調整,對于生産環境的的叢集來說,遷移的量要少了一次,實際生産環境當中節點是有自動out的功能,
這個可以考慮自己去控制,隻是監控的密度需要加大,畢竟這個是一個需要監控的叢集,完全讓其自己處理資料的遷移是不可能的,帶來的故障隻會更多。      

############### Ceph替換OSD操作的優化與分析 ###############

上面介紹了"删除OSD的正确方式",在上面隻是簡單的說了下删除的方式怎樣能減少遷移量。下面要說的屬于一個擴充,介紹了Ceph運維當中經常出現的"壞盤替換盤的步驟及優化"。

基礎環境:
兩台主機,每台主機8個OSD,一共16個OSD,副本設定為2,PG 數設定為800,計算下來平均每個OSD上的PG數目為100個,下面将通過資料來分析不同的處理方法的差别!

需要注意:
開始測試前,先把環境設定為 noout,然後通過停止OSD來模拟OSD出現了異常,之後進行下面三種不同的處理方法:

一、測試方法1:首先out一個OSD,然後剔除OSD,然後增加OSD
#########################################################################################################
總的思路:
1. 停止指定OSD程序
2. out指定OSD
3. crush remove指定OSD
4. 增加一個新的OSD

一般生産環境會設定為noout,當然不設定也可以,那就交給程式去控制節點的 out,預設是在程序停止後的五分鐘,總之這個地方如果有 out 觸發,
不管是人為觸發,還是自動觸發,資料流是一定的。這裡為了便于測試,使用的是人為觸發,上面提到的預制環境就是設定的noout。

開始測試前擷取最原始的分布
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg1.txt
擷取目前的 PG 分布,儲存到檔案pg1.txt,這個 PG 分布記錄是 PG 所在的 OSD,記錄下來,友善後面進行比較,進而得出需要遷移的數。

1. 停止指定的OSD程序
[root@ceph1106 ~]# systemctl stop ceph-osd@15
停止程序并不會觸發遷移,隻會引起 PG 狀态的變化,比如原來主 PG 在停止的 OSD 上,那麼停止掉 OSD 以後,原來的副本的那個 PG 就會角色更新為主 PG 了

2. out掉一個OSD
[root@ceph1106 ~]# ceph osd out 15
在觸發out以前,目前的PG狀态應該有active+undersized+degraded, 觸發 out 以後,所有的 PG 的狀态應該會慢慢變成 active+clean,等待叢集正常後,
再次查詢目前的 PG 分布狀态
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg > pg2.txt
儲存目前的 PG 分布為pg2.txt

比較 out 前後的 PG 的變化情況,下面是比較具體的變化情況,隻列出變化的部分
[root@ceph1106 ~]# diff -y -W 100 pg1.txt pg2.txt  --suppress-common-lines

這裡比較關心的是變動的數目,隻統計變動的 PG 的數目
[root@ceph1106 ~]# diff -y -W 100 pg1.txt pg2.txt  --suppress-common-lines|wc -l
102

第一次 out 以後有102個 PG 的變動,這個數字記住,後面的統計會用到

3. 從crush裡面删除OSD
[root@ceph1106 ~]# ceph osd crush remove osd.15
crush 删除以後同樣會觸發遷移,等待 PG 的均衡,也就是全部變成 active+clean 狀态

[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > pg3.txt
擷取目前的 PG 分布的狀态

現在來比較 crush remove 前後的 PG 變動
[root@ceph1106 ~]# diff -y -W 100 pg2.txt pg3.txt  --suppress-common-lines|wc -l
137

重新加上新的 OSD
[root@ceph1106 ~]# ceph-deploy osd prepare ceph1107:/dev/sdi
[root@ceph1106 ~]# ceph-deploy osd activate ceph1107:/dev/sdi1

加完以後統計目前的新的 PG 狀态
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > pg4.txt

比較前後的變化
[root@ceph1106 ~]# diff -y -W 100 pg3.txt pg4.txt  --suppress-common-lines|wc -l
167

整個替換流程完畢,統計上面的 PG 總的變動
102 +137 +167 = 406
也就是按這個方法的變動為406個 PG,因為是隻有雙主機,裡面可能存在某些放大問題,這裡不做深入讨論,因為這裡三組測試環境都是一樣的情況,
隻做橫向比較,原理相通,這裡是用資料來分析出差别。

二、測試方法2:先crush reweight 0 ,然後out,然後再增加osd
#########################################################################################################
首先恢複環境為測試前的環境
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 2pg1.txt
記錄最原始的 PG 分布情況

1. crush reweight 指定OSD
[root@ceph1106 ~]# ceph osd crush reweight osd.16 0
reweighted item id 16 name 'osd.16' to 0 in crush map

等待平衡了以後記錄目前的 PG 分布狀态
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 2pg2.txt
dumped pgs in format plain

比較前後的變動
[root@ceph1106 ~]# diff -y -W 100 2pg1.txt 2pg2.txt  --suppress-common-lines|wc -l
166

2. crush remove 指定 OSD
[root@ceph1106 ~]# ceph osd crush remove osd.16
removed item id 16 name 'osd.16' from crush map

這個地方因為上面crush 已經是0了,是以删除也不會引起 PG 變動,然後直接 ceph osd rm osd.16 同樣沒有 PG 變動

3. 增加新的 OSD
[root@ceph1106 ~]# ceph-deploy osd prepare ceph1107:/dev/sdi
[root@ceph1106 ~]# ceph-deploy osd activate ceph1107:/dev/sdi1

等待平衡以後擷取目前的 PG 分布
[root@ceph1106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 2pg3.txt

來比較前後的變化
[root@ceph1106 ~]# diff -y -W 100 2pg2.txt 2pg3.txt --suppress-common-lines|wc -l
159

總的 PG 變動為
166+159=325

三、測試方法3:開始做norebalance,然後做crush remove,然後做add
#########################################################################################################
恢複環境為初始環境,然後擷取目前的 PG 分布
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 3pg1.txt
dumped pgs in format plain

1. 給叢集做多種标記,防止遷移
設定為 norebalance,nobackfill,norecover,後面是有地方會解除這些設定的
[root@ceph1106 ~]# ceph osd set norebalance
set norebalance

[root@ceph1106 ~]# ceph osd set nobackfill
set nobackfill

[root@ceph1106 ~]# ceph osd set norecover
set norecover

2. crush reweight 指定 OSD
[root@ceph1106 ~]# ceph osd crush reweight osd.15 0
reweighted item id 15 name 'osd.15' to 0 in crush map

這個地方因為已經做了上面的标記,是以隻會出現狀态變化,而沒有真正的遷移,我們也先統計一下
[root@ceph1106 ~]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 3pg2.txt
[root@ceph1106 ~]# diff -y -W 100 3pg1.txt 3pg2.txt --suppress-common-lines|wc -l
158

注意這裡隻是計算了,并沒有真正的資料變動,可以通過監控兩台的主機的網絡流量來判斷,是以這裡的變動并不用計算到需要遷移的 PG 數目當中。

3. crush remove 指定 OSD
[root@ceph1106 ~]# ceph osd crush remove osd.15

4. 删除指定的 OSD
删除以後同樣是沒有 PG 的變動的
[root@ceph1106 ~]# ceph osd rm osd.15

這裡有個小地方需要注意一下:
不做 ceph auth del osd.15 把15的編号留着,這樣好判斷前後的 PG 的變化,不然相同的編号,就無法判斷是不是做了遷移了。

5. 增加新的 OSD
[root@ceph1106 ~]# ceph-deploy osd prepare ceph1107:/dev/sdi
[root@ceph1106 ~]# ceph-deploy osd activate ceph1107:/dev/sdi1

這裡測試環境下,新增的 OSD 的編号為16了

6. 解除各種标記
放開上面的設定,看下資料的變動情況
[root@ceph1106 ceph]# ceph osd unset norebalance
unset norebalance

[root@ceph1106 ceph]# ceph osd unset nobackfill
unset nobackfill

[root@ceph1106 ceph]# ceph osd unset norecover
unset norecover

設定完了後資料才真正開始變動了,可以通過觀察網卡流量看到,來看下最終pg變化
[root@ceph1106 ceph]# ceph pg dump pgs|awk '{print $1,$15}'|grep -v pg   > 3pg3.txt
dumped pgs in format plain

[root@ceph1106 ~]# diff -y -W 100 3pg1.txt 3pg3.txt --suppress-common-lines|wc -l
195

這裡隻需要跟最開始的PG分布狀況進行比較就可以了,因為中間的狀态實際上都沒有做資料的遷移,是以不需要統計進去,可以看到這個地方動了195個PG,
總共的 PG 遷移量為195

四、資料彙總
#########################################################################################################
#########################################################################################################
現在通過表格來對比下三種方法的遷移量的比較 (括号内為遷移 PG 數目)

                     方法1                        方法2                            方式3
                     stop osd (0)                crush reweight osd (166)        set 标記 (0)
                     out osd (102)               out osd (0)                     crush reweight osd (0)
所做操作              crush remove osd (137)      crush remove osd (0)            crush remove osd (0)
                     add osd (167)               add osd (159)                   add osd (195)

PG遷移數量            406                         325                             195

可以很清楚的看到三種不同的方法,最終的觸發的遷移量是不同的,處理的好的話,能節約差不多一半的遷移的資料量,
這個對于生産環境來說還是很好的,關于這個建議先在測試環境上進行測試,然後再操作,上面的操作隻要不對磁盤進行格式化,
操作都是可逆的,也就是可以比較放心的做,記住所做的操作,每一步都做完都去檢查 PG 的狀态是否是正常的

最後總結
從以往操作經驗來看,最開始是用的第一種方法,後面就用第二種方法減少了一部分遷移量,網上有資料說做剔除OSD的時候可以關閉遷移,防止無效的過多的遷移,
然後就測試了一下,确實能夠減少不少的遷移量,這個減少在某些場景下還是很好的,當然如果不太熟悉,用哪一種都可以,最終能達到的目的是一樣的。      

############### Ceph的節點問題 ###############

ceph的整體讀寫性能下降,經檢視ceph osd perf有一塊osd延遲較大在200多ms以上,決定剔除後,整體性能恢複。
這就說明osd的一個節點問題有時會影響整體ceph的性能。
[root@ceph-admin ~]# ceph --admin-daemon /var/run/ceph/ceph-osd.105.asok perf dump | more
"WBThrottle": {
"bytes_dirtied": 13333504,
"bytes_wb": 0,
"ios_dirtied": 86,
"ios_wb": 0,
"inodes_dirtied": 27,
"inodes_wb": 0
},

整體都應該是0

可以結合MegaCli檢視是否有壞道導緻的問題,不要急于恢複磁盤。
長時間的資料積累對磁盤的性能和使用周期是有影響的 也可以定時清理磁盤碎片。

檢視磁盤碎片
[root@ceph-admin ~]# xfs_db -c frag -r /dev/sdd1

整理碎片
[root@ceph-admin ~]# xfs_fsr /dev/sdd1      

*************** 當你發現自己的才華撐不起野心時,就請安靜下來學習吧!***************