??本站以分享各種運維經驗和運維所需要的技能為主
《python零基礎入門》：python零基礎入門學習
《python運維腳本》：?python運維腳本實踐
《shell》：shell學習
《terraform》持續更新中：terraform_Aws學習零基礎入門到最佳實戰
《k8》暫未更新
《docker學習》暫未更新
《ceph學習》ceph日常問題解決分享
《日志收集》ELK+各種中間件
《運維日常》運維日常
《linux》運維面試100問
一、擴容條件
a.?一般可用容量達到70%，就要開始考慮進行物理擴容，部分由于部署不合理導致的問題，可通過調節pg和weight進行調整。
b.?擴容時需盡可能的評估當前業務規模，因為當集群達到一定規模后，累計的數據量是十分巨大的，所以盡可能的減少遷移操作。
c.?通過 ceph df 查看 %USED 是否已經達到70%，并通過ceph osd df 查看osd 使用率最高的和最低的使用率。 %USED 是按照使用率最高的osd算出來的，而ceph在一個osd滿的情況下（閾值一般為0.95，告警為0.85），集群就不可用了。
例如，通過 ceph osd df | sort -k 8 查看到最低osd使用率40%，最高osd使用率為72%，誤差32，這種情況很可能就是osd之間數據不均衡。
d.?導出osd 的pg分布，查看到部分池的數據很少（幾乎沒有），但給予了1024pg，data數據量多的池在每個osd內分布的不均勻，例如在osd 1 中，總pg數為120，但data池的pg只占用60pg，其他池meta池占用30pg，但實際上meta池數據量遠遠少于data池。查看osd 181，發現data池pg為90，而且其容量只剩剩余2T，而osd 1剩余3.6T。從而導致可用容量按osd 181的顯示，隨著業務持續寫入，很快就接近閾值，導致集群空間的浪費。
此時，應該調整池pg分布的均衡或者調節部分峰值的osd。
e.?若pg分布均衡且數據分布均衡，則考慮 物理擴容 。
二、擴容流程
擴容的過程主要是添加osd的過程，添加完osd后，還需看情況是否調節pg，具體可查看文檔后面 計算需要調節pg
擴容過程主要分為4步（文檔有具體描述）：
（1）業務規模的評估
（2）擴容前的準備工作（包括環境的檢查，pg數的計算，pg分布的統計）
（3）擴容過程中的故障處理（mon、osd進程故障，pg狀態異常故障）
（4）擴容完的收尾動作（統計pg的分布圖，調節遷移的速度等）
擴容時候出現的故障主要從 現網組網 系統 集群 進程的這幾個維度進行排查
例如出現mon down時候，可通過mon進程所提示的err進行定位，從而轉到集群的規模是否部分參數未放開限制，再到系統的內存不足或者網口負載太高，需調節系統參數，再到組網環境搭建進行排查，如交換機環路等。
（1）由于pg不均衡或者weight權重不相等的，可以通過調節osd的pg數，或者 weight值進行初步騰出容量。
| # 調節osd weight值 ceph osd reweight <osdname (id|osd.id)> <float[0.0-1.0]> # 調節pg數目 ceph osd pool set <poolname> pg_num|pgp_num <int> #int為最接近2的冪次方 |
若是由于池的pg不均衡導致，采用ceph balancer進行調整
| # 查看集群得分 ceph balancer eval # 設置均衡策略（crush-compat） ceph balancer mode <upmap/crush-compat/none> None：表示什么都不做 Upmap：通過重新映射pg來平衡pg crush-compat: 通過重新設置osd的weight值觸發pg的重新分布 # 設置均衡任務 ceph balancer optimize tune <pool_name> ceph balancer execute tune # 這時，在查看集群得分 ceph balancer eval |
（2）通過增加osd進行物理擴容
處理流程可在web上操作，這里提供添加osd的命令
| # bluestore： ceph-deploy --overwrite-conf osd create node66 --data /dev/sdb --block-db /dev/sdd2 --block-wal /dev/sdd1 ceph-deploy --overwrite-conf osd create node66 --data /dev/sdc --block-db /dev/sde2 --block-wal /dev/sde1 ... # filestore ceph-deploy osd create --filestore --fs-type xfs --data /dev/sdb1 --journal /dev/sde1 node66ceph-deploy osd create --filestore --fs-type xfs --data /dev/sdc1 --journal /dev/sde2 node66 |
（3）擴容后，看情況是否需要增加pg，或者均衡池pg。pg均衡情況可通過腳本《pg均衡查詢腳本》查看，腳本可私信獲取。
pg的計算公式：
1、輸出的值取舍到最接近的2的冪（最接近的2的冪提供了CRUSH算法效率的少量提高）
2、如果最接近的2的冪比原始值低25％以上，則使用下一個更高的2的冪
3、每個osd pg數目，建議值：
100 如果在可預見的將來，群集OSD的數量預計不會增加。
200 如果在可預見的將來，群集OSD的數量預計會增加（最多增加一倍）。
算法：
（每個OSD的目標PG）x（OSd總數）x（數據量百分比）/ （副本數）
ps：
如果以上計算的值小于（osd總數）/（副本數）的值，則該值將更新為（osd總數）/（副本數）的值。這是通過為每個池為每個OSD分配至少一個主或輔助PG來確保均勻的負載/數據分配
數據量（普通生產環境）：
| 項 | .rgw.root | rgw.control | rgw.meta | rgw.log | rgw.buckets.index | rgw.buckets.data | rgw.buckets.non-ec |
|---|---|---|---|---|---|---|---|
| 數據量占用率（%） | 0.2 | 0.1 | 0.3 | 0.6 | 1 | 94.8 | 3 |
三、擴容期間
（1）觀察pg的狀態（相關故障處理可根據《pg異常處理》處理）
Peering
peering的作用主要是在PG及其副本所在的OSD之間建立互聯,并使得OSD之間就這些PG中的object及其元數據達成一致
Remapped
當負責維護某個PG的acting set變更時,PG需要從原來的acting set遷移至新的acting set。這個過程需要一段時間,所以在此期間,相關PG的狀態便會標記為remapped
Backfills
當有新的OSD加入集群時,CRUSH會把現有集群內的部分PG分配給它。這些被重新分配到新OSD的PG狀態便處于backfilling
Recovering
當某個OSD因為某些原因down了,該OSD內PG的object會落后于它所對應的PG副本。而在該OSD重新up之后,該OSD中的內容
必須更新到當前狀態,處于此過程中的PG狀態便是recovering
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
Active
處于該狀態意味著數據已經完好的保存到了主PG及副本PG中,并且Ceph已經完成了peering工作
Clean
當某個PG處于clean狀態時,則說明對應的主OSD及副本OSD已經成功互聯,并且沒有偏離的PG。也意味著Ceph已經將該PG中的對象按照規定的副本數進行了復制操作
（2）遷移參數調整
數據的遷移的相關參數,可根據業務數據流量的時間分布，進行適當的調整，加快遷移：
這個值存在平衡點：具體可看：https://blog.csdn.net/tony_vip/article/details/100122104
| 思科參考值，具體視集群情況而定 #不在意空間釋放的話，也可以調大backfill sudo ceph tell osd.* injectargs '--osd_recovery_max_single_start 16 --osd_recovery_sleep_hdd 0 --osd_recovery_max_active 16 --osd_max_backfills 16' 【ceph】設置恢復數據速度之pg recover限流_ceph recovery速度_向往風的男子的博客-CSDN博客 |
（3）slow request
若遷移過程中出現slow request的情況，一般為集群過載了。主要可能有以下原因導致。
a. 池的pg數太少，導致某個池阻塞osd的情況
通過mon log日志，獲取到阻塞osd的信息：
| 2021-01-12 00:04:05.257239 osd.3 osd.3 172.168.30.103:6801/908686 2976 : cluster [WRN] slow request 31.493678 seconds old, received at 2021-01-12 00:03:33.763381: osd_op(client.137288303.0:1137363 7.1a 7:590 |
這里可以看到osd.3阻塞了，pg序號為7.1a，查看對應的池（ceph df）：
可查看到是default.rgw.log，在查看對應pg數目：
| ceph pg dump pgs|grep ^7.|awk '{print $1,$2}' |
環境上有80個osd，而pg只有32個，均攤到每個osd，平均一個都沒有，并沒有充分散列，假如維持單個osd承載10個相關pg，那么計算下來：
10*80/2=400 取最接近冪是512
512*2/80=12.8
平均每個osd上的為12.8個相關的pg，因為對象是207個，平坦下去每個pg只需要承擔一個對象，平均每個osd承擔不到3個對象，比現在的設置情況要好很多
b. 業務在某段時間突然觸發增長
例如項目在凌晨12點時，業務方進行批量刪除過期文件的操作，這無疑增加擴容時候的壓力，而且其中穿插著設備的批量遍歷操作和ceph生命周期操作。
故可結合現場環境進行調節：
a.?將ceph生命周期的遷移時間設置為：01：00 - 23：00，避開峰值時間段
| rgw_lifecycle_work_time = 01:00-23:00 |
b.?降低backfill修復對磁盤的壓力
| ceph tell osd.* injectargs --osd_recovery_sleep_hdd 0.5 #默認為0.1# 效果recovery: 16.1MiB/s, 6objects/s ceph tell osd.* injectargs --osd_recovery_sleep_hdd 0.1 # 效果recovery: 82.1MiB/s, 32objects/s |
c. 將池后端使用SSD代替
若集群osd數目不能抗住大量元數據的操作，可將池使用SSD進行代替，緩解SSD的更新的時延，加大并發量。
（4）盤容量接近閾值
若存在擴容不及時，導致osd的容量還未釋放，逐漸逼近設置盤滿的閾值0.95，此時需手動操作，將閾值高的osd進行優先遷移。
| # 查看滿盤osd 所需遷移的pg ceph pg dump pgs | grep <osd.x> | grep backfill_wait |
主要看UP 和 ACTING 列，可通過awk 過濾出來。
遷移流程為： ACTING[0,1] —> UP[3,4] 盡量選取UP 為新加入的osd進行遷移。
盡量將 ACTING 中存在該osd 的pg進行優先遷移，同時設置該osd的backfill 為1，相當于加快遷移出去的數據，減慢遷移進來的數據。
| ceph pg force-backfill <pg_id>ceph tell <osd.x> injectargs "--osd_max_backfills 1" |
（5）遷移所需時間
遷移所需時間可通過下面腳本進行大致評估，ceph版本不同可能截取需要數據位置不同，需適當更改下腳本。
#! /bin/sh
while ( 2>1 )
do
start=`ceph -s|grep pgs|grep mis|awk '{print $2}'|cut -d / -f 1`
sleep 5
end=`ceph -s|grep pgs|grep mis|awk '{print $2}'|cut -d / -f 1`
speed=$((start-end))
#echo $end
#echo $speed
second=$((end/speed*5))
hour=$(( $second/3600 ))
min=$(( ($second-${hour}*3600)/60 ))
sec=$(( $second-${hour}*3600-${min}*60 ))
echo 當前時間:`date`
echo 遷移剩余:$end
echo 遷移速度:$((speed/5))
echo 遷移還需要:${hour}小時${min}分${sec}秒
echo "-------------------------------------"
done
和WI(操作指導書)的聯系和區別)
