在不同負載的專案中使用Ceph作為網路存儲,我們可能會遇到各種乍看之下並不簡單或瑣碎的任務。 例如:
- 將資料從舊 Ceph 遷移到新集群,部分使用新集群中先前的伺服器;
- Ceph中磁碟空間分配問題的解決方案。
處理此類問題,我們面臨著需要在不遺失資料的情況下正確刪除OSD,這在處理大量資料時尤其重要。 這將在文章中討論。
下面描述的方法適用於任何版本的 Ceph。 此外,還會考慮到Ceph可以儲存大量資料的事實:為了防止資料遺失和其他問題,某些操作將被「拆分」為其他幾個操作。
關於 OSD 的前言
由於所討論的三個配方中有兩個專用於 OSD(
首先應該說整個Ceph叢集是由很多OSD組成的。 越多,Ceph 中的可用資料量就越大。 從這裡就很容易理解了 主要 OSD 功能:它將 Ceph 物件資料儲存在所有叢集節點的檔案系統上,並提供對其的網路存取(用於讀取、寫入和其他請求)。
在同一級別,複製參數是透過在不同OSD之間複製物件來設定的。 在這裡您可能會遇到各種問題,以下將討論其解決方案。
案例1。 從 Ceph 叢集中安全刪除 OSD,不會遺失數據
刪除 OSD 的需要可能是由於從叢集中刪除伺服器而導致的 - 例如,用另一台伺服器替換它 - 這就是我們遇到的情況,從而引發了本文的寫作。 因此,操縱的最終目標是提取給定伺服器上的所有 OSD 和 mon,以便可以停止它。
為了方便起見,並避免在執行命令時錯誤指示所需的 OSD,我們將設定一個單獨的變量,其值將是要刪除的 OSD 的編號。 我們就這樣稱呼她吧 ${ID}
- 在這裡和下面,這樣的變數替換了我們正在使用的 OSD 的編號。
我們先來看看開始工作前的情況:
root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.46857 root default
-3 0.15619 host hv-1
-5 0.15619 host hv-2
1 ssd 0.15619 osd.1 up 1.00000 1.00000
-7 0.15619 host hv-3
2 ssd 0.15619 osd.2 up 1.00000 1.00000
要啟動 OSD 刪除,您需要順利執行 reweight
就將其歸零。 透過這種方式,我們可以透過平衡其他 OSD 來減少 OSD 中的資料量。 為此,請執行以下命令:
ceph osd reweight osd.${ID} 0.98
ceph osd reweight osd.${ID} 0.88
ceph osd reweight osd.${ID} 0.78
……依此類推,直到為零。
需要平穩平衡以免遺失資料。 如果 OSD 包含大量數據,則尤其如此。 確保執行命令後 reweight
一切順利,你可以完成它 ceph -s
或在單獨的終端機視窗中運行 ceph -w
以便即時觀察變化。
當 OSD 被「清空」時,您可以繼續標準操作將其刪除。 為此,請將所需的 OSD 轉移到狀態 down
:
ceph osd down osd.${ID}
讓我們將 OSD 從叢集中「拉」出來:
ceph osd out osd.${ID}
讓我們停止 OSD 服務並卸載其在 FS 中的分區:
systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}
刪除 OSD
ceph osd crush remove osd.${ID}
讓我們刪除 OSD 用戶:
ceph auth del osd.${ID}
最後,讓我們刪除 OSD 本身:
ceph osd rm osd.${ID}
注意:如果您使用的是Ceph Luminous版本或更高版本,那麼上面的OSD刪除步驟可以減少為兩個命令:
ceph osd out osd.${ID}
ceph osd purge osd.${ID}
如果完成上述步驟後,您執行命令 ceph osd tree
,那麼應該要清楚的是,在執行工作的伺服器上不再有執行上述操作的 OSD:
root@hv-1 ~ # ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 0.46857 root default
-3 0.15619 host hv-1
-5 0.15619 host hv-2
-7 0.15619 host hv-3
2 ssd 0.15619 osd.2 up 1.00000 1.00000
在此過程中,請注意 Ceph 叢集的狀態將變為 HEALTH_WARN
,我們還將看到 OSD 數量和可用磁碟空間量的減少。
以下將描述如果您想要完全停止伺服器並相應地將其從 Ceph 中刪除所需的步驟。 在這種情況下,重要的是要記住 關閉伺服器之前,必須刪除所有 OSD 在此伺服器上。
如果該伺服器上不再有 OSD,則在刪除它們後,您需要從 OSD 對應中排除該伺服器 hv-2
透過執行以下命令:
ceph osd crush rm hv-2
刪除 mon
從伺服器 hv-2
透過在另一台伺服器上執行以下命令(即在本例中,在 hv-1
):
ceph-deploy mon destroy hv-2
此後,您可以停止伺服器並開始後續操作(重新部署等)。
案例2。 已建立的 Ceph 叢集中的磁碟空間分佈
我將從關於PG的序言開始第二個故事(
所以:使用Ceph時常見的問題之一是Ceph中池之間的OSD和PG數量不平衡。
首先,正因為如此,可能會出現在一個小池中指定過多PG的情況,這本質上是叢集中磁碟空間的不合理使用。 其次,在實務上存在一個更嚴重的問題:其中一個OSD的資料溢位。 這需要集群首先轉換到狀態 HEALTH_WARN
, 進而 HEALTH_ERR
。 原因是 Ceph 在計算可用資料量時(可以透過 MAX AVAIL
在命令輸出中 ceph df
分別針對每個池)基於 OSD 中的可用資料量。 如果至少一個 OSD 中沒有足夠的空間,則無法寫入更多數據,直到資料在所有 OSD 之間正確分配為止。
這些問題值得澄清 很大程度是在Ceph叢集配置階段決定的。 您可以使用的工具之一是
那麼,我們想像一下下面的圖:集群有一個狀態 HEALTH_WARN
由於其中一個 OSD 空間不足。 這將由錯誤指示 HEALTH_WARN: 1 near full osd
。 下面是擺脫這種情況的演算法。
首先,您需要在剩餘的 OSD 之間分配可用資料。 當我們「耗盡」節點時,我們已經在第一種情況下執行了類似的操作 - 唯一的區別是現在我們需要稍微減少 reweight
。 例如,最大 0.95:
ceph osd reweight osd.${ID} 0.95
這會釋放 OSD 中的磁碟空間並修復 ceph 運作狀況中的錯誤。 然而,正如已經提到的,這個問題主要是由於 Ceph 在初始階段的配置不正確而導致的:重新配置非常重要,這樣以後就不會發生這種情況。
在我們的具體案例中,一切都歸結為:
- 價值太高
replication_count
在其中一個水池中, - 一個池中的 PG 太多,而另一個池中的 PG 太少。
讓我們使用已經提到的計算器。 它清楚地顯示了需要輸入的內容,原則上沒有什麼複雜的。 設定必要的參數後,我們得到以下建議:
注意:如果您要從頭開始設定 Ceph 集群,計算器的另一個有用功能是產生命令,這些命令將使用表中指定的參數從頭開始建立池。
最後一欄可協助您導覽 - 建議 PG 數。 在我們的例子中,第二個也很有用,其中指示了複製參數,因為我們決定更改複製乘數。
因此,首先您需要更改複製參數 - 這是值得首先做的,因為透過減少乘數,我們將釋放磁碟空間。 當命令執行時,您會注意到可用磁碟空間會增加:
ceph osd pool $pool_name set $replication_size
完成後,我們更改參數值 pg_num
и pgp_num
如下所示:
ceph osd pool set $pool_name pg_num $pg_number
ceph osd pool set $pool_name pgp_num $pg_number
這一點很重要:我們必須依序更改每個池中的 PG 數量,並且不要更改其他池中的值,直到警告消失 “資料冗餘降級” и “n-數量的 pgs 降級”.
您也可以使用命令輸出檢查一切是否順利 ceph health detail
и ceph -s
.
案例3。 將虛擬機器從 LVM 遷移到 Ceph RBD
當專案使用租用的裸機伺服器上安裝的虛擬機器時,經常會出現儲存容錯的問題。 也非常希望這個存儲有足夠的空間...另一種常見情況:伺服器上有一個帶有本地存儲的虛擬機,需要擴展磁碟,但無處可去,因為沒有伺服器上剩餘的可用磁碟空間。
該問題可以透過不同的方式解決 - 例如,遷移到另一台伺服器(如果有)或向該伺服器新增磁碟。 但並不總是能夠做到這一點,因此從 LVM 遷移到 Ceph 可以很好地解決這個問題。 透過選擇此選項,我們還簡化了伺服器之間的進一步遷移過程,因為無需將本機儲存從一個虛擬機器管理程式移至另一個虛擬機器管理程式。 唯一的問題是您必須在工作進行時停止虛擬機器。
以下食譜摘自
讓我們進入實際部分。 在範例中,我們使用 virsh,並相應地使用 libvirt。 首先,請確保資料要移轉到的 Ceph 池已連接到 libvirt:
virsh pool-dumpxml $ceph_pool
池描述必須包含與 Ceph 的連線資料和授權資料。
下一步是將 LVM 映像轉換為 Ceph RBD。 執行時間主要取決於圖像的大小:
qemu-img convert -p -O rbd /dev/main/$vm_image_name rbd:$ceph_pool/$vm_image_name
轉換後,將保留 LVM 映像,如果將 VM 移轉到 RBD 失敗並且您必須回滾更改,則該映像將非常有用。 另外,為了能夠快速回滾更改,讓我們對虛擬機器設定檔進行備份:
virsh dumpxml $vm_name > $vm_name.xml
cp $vm_name.xml $vm_name_backup.xml
....並編輯原始內容(vm_name.xml
)。 讓我們找到一個包含磁碟描述的區塊(以行開頭 <disk type='file' device='disk'>
並以 </disk>
) 並將其簡化為以下形式:
<disk type='network' device='disk'>
<driver name='qemu'/>
<auth username='libvirt'>
<secret type='ceph' uuid='sec-ret-uu-id'/>
</auth>
<source protocol='rbd' name='$ceph_pool/$vm_image_name>
<host name='10.0.0.1' port='6789'/>
<host name='10.0.0.2' port='6789'/>
</source>
<target dev='vda' bus='virtio'/>
<alias name='virtio-disk0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
讓我們來看一些細節:
- 至協議
source
指示 Ceph RBD 中儲存的位址(這是指示 Ceph 池和 RBD 映像名稱的位址,在第一階段確定)。 - 在街區裡
secret
類型已指示ceph
,以及連接到它的秘密的 UUID。 可以使用指令找到它的uuidvirsh secret-list
. - 在街區裡
host
指示了 Ceph 監視器的位址。
編輯設定檔並完成 LVM 到 RBD 轉換後,您可以套用修改後的設定檔並啟動虛擬機器:
virsh define $vm_name.xml
virsh start $vm_name
現在是時候檢查虛擬機器是否正確啟動了:例如,您可以透過 SSH 連接到虛擬機器或透過 virsh
.
如果虛擬機器運作正常且您沒有發現任何其他問題,那麼您可以刪除不再使用的LVM映像:
lvremove main/$vm_image_name
結論
我們在實踐中遇到了所有描述的案例 - 我們希望這些說明能夠幫助其他管理員解決類似的問題。 如果您對使用 Ceph 的經歷有任何評論或其他類似的故事,我們將很高興在評論中看到它們!
聚苯乙烯
另請閱讀我們的博客:
- «
我們的雙手不是為了無聊:在 K8s 中恢復 Rook 集群 “; - «
去魯克還是不去魯克——這是一個問題 “; - «
Rook - Kubernetes 的「自助」資料倉儲 “; - «
基於 Ceph 的 Kubernetes 中的配置建立持久性存儲 “。
來源: www.habr.com