ceph叢集單個osd超95%導致叢集無法讀寫叢集恢復過程

阿新 • • 發佈：2019-01-12

ceph新手，最近遇到的一個問題，已解決，請參考，文中有錯誤的話歡迎指正

故障描述

openstack環境中若干臺虛擬機器無法正常操作，嘗試從horizon中重啟虛擬機器，重啟過程中虛擬機器狀態一直停留在”powering on”的狀態，無法進入系統

檢視openstack環境，發現後端ceph的狀態異常,一個OSD full，一個near full。（clock是這個叢集已知問題，這裡不做介紹）

(ceph-mon)[[email protected]160 /]# ceph -s
    cluster 8a946765-1bb5-40bc-a0bc-4cd830aee2a4
     health HEALTH_ERR
            clock skew detected on 
 mon.192.168.1.159, mon.192.168.1.160
            1 full osd(s)
            1 near full osd(s)
            full flag(s) set
            Monitor clock skew detected 
     monmap e1: 3 mons at {192.168.1.158=192.168.1.158:6789/0,192.168.1.159=192.168.1.159:6789/0,192.168.1.160=192.168.1.160:6789/0}
            election epoch 16 
, quorum 0,1,2 192.168.1.158,192.168.1.159,192.168.1.160
     osdmap e321: 13 osds: 13 up, 13 in
            flags nearfull,full,sortbitwise,require_jewel_osds
      pgmap v2886234: 624 pgs, 11 pools, 1706 GB data, 383 kobjects
            5121 GB used, 2061 GB / 7183 GB avail
                 624 active+clean
  client io 365 
 kB/s rd, 436 op/s rd, 0 op/s wr

其中一個osd的使用率顯示是full的狀態。根據Ceph官方文件中的描述，當一個OSD full比例達到95%時，叢集將不接受任何Ceph Client端的讀寫資料的請求。所以導致虛擬機器在重啟時，無法啟動的情況。

檢視ceph叢集中各osd的使用率

發現osd的使用不均衡，最高的已超過95%，最低的才40%多點，預設的均衡方式是按照PGS數量來做均衡，osd之間相差不大，但是真實佔用的空間差別太大，根據ceph叢集的定義，即使只有一個osd的使用率超過95%，整個叢集將不可用，無法讀寫。

(ceph-mon)[[email protected]158 /]# ceph osd df  
ID WEIGHT  REWEIGHT SIZE  USE   AVAIL  %USE  VAR  PGS 
 0 1.00000  1.00000  552G  353G   198G 64.02 0.90 142 
 2 1.00000  1.00000  552G  371G   181G 67.21 0.94 136 
 1 1.00000  1.00000  552G  440G   112G 79.71 1.12 159 
 4 1.00000  1.00000  552G  381G   170G 69.11 0.97 140 
 3 1.00000  1.00000  552G  338G   214G 61.20 0.86 125 
 5 1.00000  1.00000  552G  431G   120G 78.15 1.10 162 
 6 1.00000  1.00000  552G  422G   130G 76.45 1.07 160 
 7 1.00000  1.00000  552G  492G 61380M 89.15 1.25 158 
 8 1.00000  1.00000  552G  416G   135G 75.42 1.06 143 
 9 1.00000  1.00000  552G  525G 28015M 95.05 1.33 153 
10 1.00000  1.00000  552G  348G   203G 63.15 0.89 135 
11 1.00000  1.00000  552G  242G   310G 43.90 0.62 127 
12 1.00000  1.00000  552G  354G   197G 64.20 0.90 132 
              TOTAL 7183G 5120G  2062G 71.29          
MIN/MAX VAR: 0.62/1.33  STDDEV: 12.67

解決方法

根據官方的建議，首選的方案是新增osd磁碟，新增後將觸發資料的重新均衡，full的osd使用率降到95%以下後err狀態自然會清除。當時的實際情況無法新增。

網上查到的方案：

方案一，刪除無用的rbd磁碟，這個辦法也能夠解決問題，由於當前的叢集狀態是err狀態，不允許任何讀寫操作，所以刪除的時候也會被卡住，網上查詢的辦法是使用“ceph osd unset full”命令暫時強制叢集恢復讀寫，但是刪除的時候遇到另一個”image still has watchers“的問題，所以該方法也未測試成功

方案二，臨時調整osd full的閾值，然後刪除不需要的rbd磁碟
ceph tell osd.* injectargs '--mon-osd-full-ratio 0.98'
實際執行命令的時候提示該引數unchangeable，所以也沒成功。

臨時方案

為了使叢集能儘快回覆讀寫狀態，臨時把osd.9所在的節點關機，叢集丟失一個osd，但沒了這個full的osd，叢集的是warnning狀態，這個狀態下叢集開始恢復資料，雖然不是active+clean的狀態，但是ceph是可用的。這樣做只是個臨時方案，osd.9所在的節點如果不開機，資料無法達到完整狀態，但只要開機，叢集檢測到full的osd，又會變成ERR狀態。

最後方案

調整每個osd的weigh值，使資料重新分佈

(ceph-mon)[[email protected]158 ceph]# ceph osd crush reweight osd.10 1.05 
reweighted item id 10 name 'osd.10' to 1.05 in crush map

osd預設的weight值為1，調整以後資料會向weigh值高的osd上重新分佈，
把一些比較空閒的osd weight值調高，接收資料,使用率高的osd weight調低，釋放資料

  (ceph-mon)[[email protected]158 ceph]# ceph osd df
ID WEIGHT  REWEIGHT SIZE  USE   AVAIL %USE  VAR  PGS 
 0 1.00000  1.00000  552G  298G  254G 53.97 0.91 144 
 2 1.00000  1.00000  552G  319G  233G 57.79 0.98 145 
 1 0.89999  1.00000  552G  329G  223G 59.60 1.01 148 
 4 1.00000  1.00000  552G  323G  229G 58.53 0.99 144 
 3 1.04999  1.00000  552G  311G  241G 56.37 0.95 135 
 5 1.00000  1.00000  552G  372G  179G 67.46 1.14 166 
 6 1.00000  1.00000  552G  381G  171G 68.97 1.17 167 
 7 0.79999  1.00000  552G  345G  207G 62.50 1.06 132 
 8 1.00000  1.00000  552G  349G  202G 63.29 1.07 146 
 9 0.75000  1.00000  552G  360G  192G 65.16 1.10 126 
10 1.04999  1.00000  552G  303G  249G 54.89 0.93 141 
11 1.09999  1.00000  552G  249G  302G 45.23 0.77 139 
12 1.00000  1.00000  552G  298G  254G 53.99 0.91 139 
              TOTAL 7183G 4242G 2941G 59.06          
MIN/MAX VAR: 0.77/1.17  STDDEV: 6.23

最終叢集恢復正常

附：（轉帖）刪除image時image still has watchers問題處理
抱歉忘了從哪轉的了，親測有效

在Ceph叢集日常運維中，管理員可能會遇到有的image刪除不了的情況，有一種情況是由於image下有快照資訊，只需要先將快照資訊清除，然後再刪除該image即可，還有一種情況是因為該image仍舊被一個客戶端在訪問，具體表現為該image中有watcher，如果該客戶端異常了，那麼就會出現無法刪除該image的情況。還有一種情況，就算image沒有watcher了，但是還有mount佔用，也可能刪除不了
watcher是什麼？
　　Ceph中有一個watch/notify機制(粒度是object)，它用來在不同客戶端之間進行訊息通知，使得各客戶端之間的狀態保持一致，而每一個進行watch的客戶端，對於Ceph叢集來說都是一個watcher。
如何檢視當前image上的watcher?
　　因為watch的粒度是object，想要了解一個image上的watcher資訊，最簡單的方法就是檢視該image的header物件上的watcher資訊。
　　首先找到image的header物件
　　[[email protected] ~]# rbd info test_img
　　rbd image 'test_img':
　　size 5000 MB in 1250 objects
　　order 22 (4096 kB objects)
　　block_name_prefix: rbd_data.fa7b2ae8944a
　　format: 2
　　features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
　　查詢到該image的block_name_prefix為 rbd_data.fa7b2ae8944a那麼該image的header物件則為rbd_header.fa7b2ae8944a，然後我們就可以通過命令檢視該image的header物件上的watcher資訊。
　　[[email protected] ~]# rados listwatchers -p rbd rbd_header.fa7b2ae8944a
　　watcher=192.8.8.10:0/1262448884 client.170939 cookie=140096303678368
      也可以：
[email protected]:~/my-cluster# rbd status test-imgWatchers:    watcher=172.16.71.203:0/52000001 client.134475 cookie=140465230511472
    如果image為格式1：
     [[email protected] ~]# rbd info hzb-mysql
     rbd image 'hzb-mysql':
     size 2048 MB in 512 objects
     order 22 (4096 kB objects)
     block_name_prefix: rb.0.11895f.6b8b4567
     format: 1
     則用：rados -p rbd listwatchers 'hzb-mysql.rbd
Ceph叢集異常客戶端Watcher處理
　　剛才檢視到test_img這個image上有一個watcher，假設客戶端watcher=192.8.8.10:0/1262448884出現異常，那麼我們如何處理呢？其實我們只需要將此異常客戶端設定到OSD的黑名單即可：
　　[[email protected] ~]# ceph osd blacklist add 192.8.8.10:0/1262448884
　　blacklisting 192.8.8.10:0/1262448884 until 2017-03-27 02:11:54.206165 (3600 sec)
　　此時我們再去檢視該image的header物件的watcher資訊：
　　[[email protected] ~]# rados listwatchers -p rbd rbd_header.fa7b2ae8944a
　　異常客戶端的watcher資訊已經不存在了，這個時候我們就可以對該image進行刪除操作了。這種方法不是最推薦的，但是目前還找不到很好的解決方法。
       查詢黑名單列表：
ceph osd blacklist ls
     從黑名單移出某一個
[email protected]:~# ceph osd blacklist rm 172.16.71.203:0/2000001un-blacklisting 172.16.71.203:0/2000001
   清空黑名單裡面的東西
[email protected]:~# ceph osd blacklist clear removed all blacklist entries

ceph叢集單個osd超95%導致叢集無法讀寫叢集恢復過程

ceph新手，最近遇到的一個問題，已解決，請參考，文中有錯誤的話歡迎指正故障描述 openstack環境中若干臺虛擬機器無法正常操作，嘗試從horizon中重啟虛擬機器，重啟過程中虛擬機器狀態一直停留在”powering on”的狀態，無法進入系統

Percona Mysql Galera多讀寫叢集部署生產環境實記

一、部署MySQL：yum install https://www.percona.com/redir/downloads/percona-release/redhat/latest/percona-release-0.1-6.noarch.rpm -y 安裝percona的倉庫檔案。yum install

SpringBoot微服務 +tomcat叢集+Ngnix負載均衡+Mysql主從複製，讀寫分離（4）

四：mysql主從複製，讀寫分離 1.首先把mysql原始碼包檔案拷到兩臺linux伺服器上，然後在兩臺伺服器上安裝Mysql資料庫安裝 MySQL 1 安裝 ncurses Ncurses 提供字元終端處理庫，包括面板和選單。它提供了

HBase叢集無法讀寫資料

1 問題現象 HBase叢集於11.17晚無法寫入資料，所有的同步至HBase的服務都無法寫入HBase庫。 2 問題原因所有的寫入服務都無法寫入資料，排除應用本身的問題，考慮HBase叢集本身出現問題。進入hbase shell，scan一下當中的表是

超詳細搭建Mysql5.5讀寫分離

系統 cts http 剪切修改 names 部署 authent 一次 Amoeba簡介 Amoeba(變形蟲)項目,該開源框架於2008年開始發布一款 Amoeba for Mysql軟件。這個軟件致力於MySQL的分布式數據庫前端代理層，它主要在應用層訪問MySQ

Oracle Rac中某一節點因儲存鏈路出錯導致資料庫IO讀寫卡頓的問題解決

環境：Oracle 11.2.4.0 RAC問題描述：資料庫IO讀寫卡頓，隨之某一節點的asm磁碟組被強制dismount，例項被迫停止。問題分析：通過系統日誌分析，發現有Buffer I/O error的故障刷屏，如下圖：用multipath -ll檢視伺服器磁碟多路徑，發

CEPH Ubuntu14.04 叢集刪除 OSD 節點

[問題] 刪除 ceph-node1 上的 osd.4 節點的方法？ [解答] 一般步驟是將 osd.4 標記為out，停止 osd.4 對應的 OSD 服務，將 osd.4 從 cursh map中刪除，將 osd.4 對應 osd data 和

springboot之專案叢集生成hash的key導致快取不一致。

場景：叢集專案使用訪問策略使用的隨機，快取使用的redis，自定義key當傳入兩個引數以上時候，使用Arrays.deepHashCode來計算快取的key。問題：然後出現在機器1剛訪問過這個介面，redis也有快取，訪問到機器2的時候仍然走service方法，也就是沒有從redi

超時導致的Galera節點加入叢集失敗

需求：為galera叢集新增新的節點。初始化新的節點，加入的時候一直報錯，加入失敗，報錯日誌如下 1 WSREP_SST: [ERROR] Removing /var/lib/mysql//.sst/xtrabackup_galera_info file due to signal

GreenPlum叢集搭建安裝超詳細步驟

目錄一，安裝說明 1.1環境說明名稱版本作業系統

hadoop叢集搭建（超詳細版）

1.準備好需要安裝的軟體虛擬機器VMware12.pro作業系統CentOS 6.5遠端控制虛擬機器的終端SecureCRT8.12.在虛擬機器中安裝CentOS作業系統安裝好虛擬機器，圖形介面如下圖建立新的虛擬機器，選擇自定義（高階），點選下一步虛擬機器硬體相容性預設，瀏覽

(二)超詳細純手工搭建kubernetes(k8s)叢集

1. 部署ETCD（主節點）1.1 簡介kubernetes需要儲存很多東西，像它本身的節點資訊，元件資訊，還有通過kubernetes執行的pod，deployment，service等等。都需要持久化。etcd就是它的資料中心。生產環境中為了保證資料中心的高可用和資料的一

Zookeeper叢集報錯：myid檔案缺失導致zookeeper無法啟動（myid file is missing）

搭建叢集存在的問題 zoo.cfg: dataDir=/home/ubuntu/data/zkdata/zookeeper 設定伺服器編號：在~/data/zkdata/myid: echo "1

使用Docker Toolbox 建立Swarm叢集的問題-概念混淆導致

使用Docker Toolbox 時，不帶--swarm --swarm-master選項建立Docker虛擬機器，並在主控節點的虛擬機器上執行初始化叢集命令，在管理節點上執行加入叢集命令，在工作節點執行加入叢集命令，這樣就搭建好了一個Swarm叢集，用於測試環境非常

超詳細，多圖文介紹redis叢集方式並搭建redis偽叢集

# 超詳細，多圖文介紹redis叢集方式並搭建redis偽叢集 > 超多圖文，對新手友好度極好。敲命令的過程中，難免會敲錯，但為了截好一張合適的圖，一旦出現一點問題，為了好的演示效果，就要從頭開始敲。且看且珍惜。再認識redis叢集前，若想先知道redis單機版的可檢視，[springboot

SecureRandom生成隨機數超慢導致tomcat啟動時間過長的解決辦法

tails spa centos 7 屬性 gpo org 解決辦法 hang iss 用騰訊雲的CentOS 7.2 CVM 服務器跑Tomcat時發現，Tomcat啟動的特別慢，通過查看日誌，發現時間主要花在實例化SecureRandom對象上了。由該日誌可以看

Ceph：刪除OSD

ntp require 5.6 bash swap req warn 信息 flags 1、查看OSD的分布信息：# ceph osd tree ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMAR

ceph添加osd（ceph-deploy）

配置文件秘鑰之一 alt udev dep 修改主機名 ceph host 修改主機名和 /etc/hosts 關閉防火墻和 SELINUX 安裝和配置 NTP ceph-deploy 節點安裝安裝 ceph-deploy sudo yum install ceph-

MySQL Insert語句單個批次數量過多導致的CPU性能問題分析

padding 異常線程處理 mys add context table 占比我們原文:MySQL Insert語句單個批次數量過多導致的CPU性能問題分析【問題】最近有臺服務器比較頻繁的CPU報警，表現的特征有CPU sys占比偏高，大量慢查詢，大量並發線程堆積

檢視叢集基本情況（重要）！！檢視hadoop叢集有多少節點（hdfs fsck /）

[email protected]:~$ hdfs fsck / Connecting to namenode via http://localhost:9870/fsck?ugi=liugen&path=%2F FSCK started by li

ceph叢集單個osd超95%導致叢集無法讀寫叢集恢復過程

故障描述

openstack環境中若干臺虛擬機器無法正常操作，嘗試從horizon中重啟虛擬機器，重啟過程中虛擬機器狀態一直停留在”powering on”的狀態，無法進入系統

檢視openstack環境，發現後端ceph的狀態異常,一個OSD full，一個near full。（clock是這個叢集已知問題，這裡不做介紹）

檢視ceph叢集中各osd的使用率

解決方法

網上查到的方案：

臨時方案

最後方案

相關推薦