Ceph 集群整体迁移方案
場景介紹：在我們的IDC中，存在著運行了3-6年的Ceph集群的服務器，這些服務器性能和容量等都已經無法滿足當前業務的需求，在購入一批高性能機器后，希望將舊機器上的集群整體遷移到新機器上，當然，是保證業務不中斷的前提下，再將舊機器下架回收。本文就介紹了一種實現業務不中斷的數據遷移方案，并已經在多個生產環境執行。
本文的環境均為：Openstack+Ceph 運行虛擬機的場景，即主要使用RBD，不包含RGW，MDS。虛機的系統盤(Nova)，云硬盤(Cinder)，鏡像盤(Glance)的塊均保存在共享存儲Ceph中。
| con | 192.168.100.110 | nova,cinder,glance,neutron | mon，osd*1 |
| com | 192.168.100.111 | nova,neutron | mon，osd*1 |
| ceph | 192.168.100.112 | mon，osd*1 |
| con | 192.168.100.110 | nova,cinder,glance,neutron | |
| com | 192.168.100.111 | nova,neutron | |
| ceph | 192.168.100.112 | ||
| new_mon_1 | 192.168.100.113 | mon，osd*1 | |
| new_mon_2 | 192.168.100.114 | mon，osd*1 | |
| new_mon_3 | 192.168.100.115 | mon，osd*1 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------+
| ID ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | Name ? ?| Status | Task State | Power State | Networks ? ? ? ? ? ? ? ?|
+--------------------------------------+---------+--------+------------+-------------+-------------------------+
| 4f52191f-9645-448f-977b-80ca515387f7 | vm-test | ACTIVE | - ? ? ? ? ?| Running ? ? | provider=192.168.88.111 |
+--------------------------------------+---------+--------+------------+-------------+-------------------------+
[root@con ~(keystone_admin)]# cinder list
+--------------------------------------+--------+--------------+------+-------------+----------+--------------------------------------+
| ? ? ? ? ? ? ? ? ?ID ? ? ? ? ? ? ? ? ?| Status | Display Name | Size | Volume Type | Bootable | ? ? ? ? ? ? Attached to ? ? ? ? ? ? ?|
+--------------------------------------+--------+--------------+------+-------------+----------+--------------------------------------+
| 39c76d96-0f95-490c-b7db-b3da6d17331b | in-use | ?cinder-rbd ?| ?1 ? | ? ? None ? ?| ?false ? | 4f52191f-9645-448f-977b-80ca515387f7 |
+--------------------------------------+--------+--------------+------+-------------+----------+--------------------------------------+
[root@con ~(keystone_admin)]# ip netns exec `ip netns` ssh cirros@192.168.88.111
cirros@192.168.88.111's password:
$ lsblk
NAME ? MAJ:MIN RM ? ?SIZE RO TYPE MOUNTPOINT
vda ? ?253:0 ? ?0 ? ? ?1G ?0 disk
`-vda1 253:1 ? ?0 1011.9M ?0 part /
vdb ? ?253:16 ? 0 ? ? ?1G ?0 disk
$ [root@ceph cluster]# ceph -s
? ?cluster 166889ab-fa7b-4a07-83da-6dfc92913a3d
? ? health HEALTH_OK
? ? monmap e47: 3 mons at {ceph=192.168.100.112:6789/0,com=192.168.100.111:6789/0,con=192.168.100.110:6789/0}
? ? ? ? ? ?election epoch 174, quorum 0,1,2 con,com,ceph
? ? osdmap e57: 3 osds: 3 up, 3 in
? ? ? ? ? ?flags sortbitwise,require_jewel_osds
? ? ?pgmap v6577: 768 pgs, 3 pools, 45659 kB data, 23 objects
? ? ? ? ? ?178 MB used, 766 GB / 766 GB avail
? ? ? ? ? ? ? ? 768 active+clean
[root@ceph cluster]# ceph osd tree
ID WEIGHT ?TYPE NAME ? ? UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.74876 root default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
-2 0.24959 ? ? host ceph ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
0 0.24959 ? ? ? ? osd.0 ? ? ?up ?1.00000 ? ? ? ? ?1.00000
-3 0.24959 ? ? host con ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
1 0.24959 ? ? ? ? osd.1 ? ? ?up ?1.00000 ? ? ? ? ?1.00000
-4 0.24959 ? ? host com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
2 0.24959 ? ? ? ? osd.2 ? ? ?up ?1.00000 ? ? ? ? ?1.00000
[root@ceph cluster]# ceph osd pool ls detail
pool 1 'volumes' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 256 pgp_num 256 last_change 58 flags hashpspool stripe_width 0
? ?removed_snaps [1~3]
pool 2 'vms' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 256 pgp_num 256 last_change 59 flags hashpspool stripe_width 0
? ?removed_snaps [1~3]
pool 3 'images' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 256 pgp_num 256 last_change 60 flags hashpspool stripe_width 0
? ?removed_snaps [1~9]OSD的數據遷移
原理簡介
當副本數減少時，PG 1.0 => [osd.66] ,也就是說會刪除在osd.33上的第二副本，而在 osd.66上的主副本是維持不變的，所以在降低副本數時，底層OSD實際上只刪除了一份副本，而并沒有發生數據的遷移。
當副本數增加時，PG 1.0 => [osd.66, osd.33, osd.188, osd.111]，也就是說四副本的前兩個副本依舊是之前的兩個副本，而后面增加的兩副本會從主副本osd.66將數據backfill到各自的OSD上。
遷移思路
我們首先會將新的節點的所有OSD初始化完畢，然后將這些OSD?加入到另一棵osd tree下?(這里簡稱原先的集群的osd tree叫做old_tree，新建的包含新OSD的 osd tree 叫做 new_tree)，這樣部署完畢后，不會對原有集群有任何影響，也不會涉及到數據遷移的問題，此時新的OSD下還沒有保存數據。
導出 CRUSHMAP，編輯，添加三條 CRUSH rule：
?? crush rule 0 (原先默認生成的): 從 old_tree 下選出size副本（這里size=2)。
?? crush rule 1 (新生成的第一條): 從 old_tree 下選出兩副本。對于副本數為2的集群來說，crush_rule_0 和 crush_rule_1 選出的兩副本是一樣的。
?? crush rule 2 (新生成的第二條): 從 old_tree 下選出兩副本，再從 new_tree 下選出兩副本。由**原理簡介第二段**可知， 由于 old_tree 下面的 OSD結構不變也沒有增加，所以 crush_rule_0 和 crush_rule_1 選出的前兩副本是**一樣的**。
?? crush rule 3 (新生成的第三條）: 從 new_tree 下選出兩副本。 由于crush_rule_1 的第二次選擇為選出 new_tree下的前兩副本，這和 crush_rule_2 選出兩副本（也是前兩副本）其實是**一樣的**。
注入新的CRUSHMAP后，我們做如下操作：
???將所有pool(當然建議一個pool一個pool來，后面類似) 的 CRUSH RULE 從? crush_rule_0 設置為 crush_rule_1 ，此時所有PG均保持active+clean，狀態沒有任何變化。
? ?? 將所有pool的副本數設置為4， 由于此時各個 pool 的CRUSH RULE 均為 crush_rule_1 ，而這個 RULE 只能選出兩副本，剩下兩副本不會被選出，所以此時所有PG狀態在重新 peer 之后，變為 active + undersized + degraded，由于不會生成新的三四副本，所以集群沒有任何數據遷移(backfill) 動作，此步驟耗時短暫。
??? 將所有pool的 CRUSH RULE 從 crush_rule_1 設置為 crush_rule_2，此時上一條動作中沒有選出的三四副本會從 new_tree 下選出，并且原先的兩副本不會發生任何遷移，整個過程宏觀來看就是在 old_tree -> new_tree 單向數據復制克隆生成了新的兩副本，而舊的兩副本沒有移動。此時生成新的兩副本耗時較長，取決于磁盤性能帶寬數據量等，可能需要幾天到一周的時間，所有數據恢復完畢后，集群所有PG變為 active+clean 狀態。
? ?? 將所有pool的 CRUSH RULE 從 crush_rule_2 設置為 crush_rule_3，此時所有PG狀態會變為 active+remapped，發生的另一個動作是，原先四副本的PG的主副本是在 old_tree 上的某一個OSD上的，現在這個PG的主副本變為 new_tree下的選出的第一個副本，也就是發生了主副本的切換。比如原先 PG 1.0 => [osd.a, osd.b, osd.c, osd.d] 在這步驟之后會變成 PG 1.0 => [osd.c, osd.d]。原先的第三副本也就是new_tree下的第一副本升級為主副本。
??? 將所有pool的副本數設置為2，此時PG狀態會很快變為 active+clean，然后在OSD層開始刪除 old_tree 下的所有數據。此時數據已經全部遷移到新的OSD上。
遷移指令
1.初始化新的OSD
### 前往部署目錄
cd /root/cluster
echo "osd_crush_update_on_start = false " >> ceph.conf
ceph-deploy --overwrite-conf osd prepare new_mon_1:sdb ?new_mon_2:sdb ?new_mon_3:sdb --zap-disk
ceph-deploy --overwrite-conf osd activate ?new_mon_1:sdb1 ?new_mon_2:sdb1 ?new_mon_3:sdb1[root@ceph ~]# ceph osd tree
ID WEIGHT ?TYPE NAME ? ? UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.75000 root default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
-2 0.25000 ? ? host ceph ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
0 0.25000 ? ? ? ? osd.0 ? ? ?up ?1.00000 ? ? ? ? ?1.00000
-3 0.25000 ? ? host con ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
1 0.25000 ? ? ? ? osd.1 ? ? ?up ?1.00000 ? ? ? ? ?1.00000
-4 0.25000 ? ? host com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
2 0.25000 ? ? ? ? osd.2 ? ? ?up ?1.00000 ? ? ? ? ?1.00000
3 ? ? ? 0 osd.3 ? ? ? ? ? ? ?up ?1.00000 ? ? ? ? ?1.00000
4 ? ? ? 0 osd.4 ? ? ? ? ? ? ?up ?1.00000 ? ? ? ? ?1.00000
5 ? ? ? 0 osd.5 ? ? ? ? ? ? ?up ?1.00000 ? ? ? ? ?1.00000ceph osd crush add-bucket new_root ?root
ceph osd crush add-bucket new_mon_1 host
ceph osd crush add-bucket new_mon_2 host
ceph osd crush add-bucket new_mon_3 host
ceph osd crush move new_mon_1 root=new_root
ceph osd crush move new_mon_2 root=new_root
ceph osd crush move new_mon_3 root=new_root
ceph osd crush add osd.3 0.25 host=new_mon_1
ceph osd crush add osd.4 0.25 host=new_mon_2
ceph osd crush add osd.5 0.25 host=new_mon_3[root@ceph ~]# ceph osd tree
ID WEIGHT ?TYPE NAME ? ? ? ? ?UP/DOWN REWEIGHT PRIMARY-AFFINITY
-5 0.75000 root new_root ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
-6 0.25000 ? ? host new_mon_1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
3 0.25000 ? ? ? ? osd.3 ? ? ? ? ? up ?1.00000 ? ? ? ? ?1.00000
-7 0.25000 ? ? host new_mon_2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
4 0.25000 ? ? ? ? osd.4 ? ? ? ? ? up ?1.00000 ? ? ? ? ?1.00000
-8 0.25000 ? ? host new_mon_3 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
5 0.25000 ? ? ? ? osd.5 ? ? ? ? ? up ?1.00000 ? ? ? ? ?1.00000
-1 0.75000 root default ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
-2 0.25000 ? ? host ceph ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
0 0.25000 ? ? ? ? osd.0 ? ? ? ? ? up ?1.00000 ? ? ? ? ?1.00000
-3 0.25000 ? ? host con ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
1 0.25000 ? ? ? ? osd.1 ? ? ? ? ? up ?1.00000 ? ? ? ? ?1.00000
-4 0.25000 ? ? host com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
2 0.25000 ? ? ? ? osd.2 ? ? ? ? ? up ?1.00000 ? ? ? ? ?1.00000
2.編輯 CRUSH MAP
### 導出CRUSH MAP
ceph osd getcrushmap -o map
crushtool -d map -o map.txt
### 在map.txt 最后添加以下內容
vim map.txt
# rules
rule replicated_ruleset {
? ? ? ?ruleset 0
? ? ? ?type replicated
? ? ? ?min_size 1
? ? ? ?max_size 10
? ? ? ?step take default
? ? ? ?step chooseleaf firstn 0 type host
? ? ? ?step emit
}
>>>>>>>>>>>>>> 添加開始 ?>>>>>>>>>>
rule replicated_ruleset1 {
? ? ? ?ruleset 1
? ? ? ?type replicated
? ? ? ?min_size 1
? ? ? ?max_size 10
? ? ? ?step take default
? ? ? ?step chooseleaf firstn 2 type host
? ? ? ?step emit
}
rule replicated_ruleset2 {
? ? ? ?ruleset 2
? ? ? ?type replicated
? ? ? ?min_size 1
? ? ? ?max_size 10
? ? ? ?step take default
? ? ? ?step chooseleaf firstn 2 type host
? ? ? ?step emit
? ? ? ?step take new_root
? ? ? ?step chooseleaf firstn 2 type host
? ? ? ?step emit
}
rule replicated_ruleset3 {
? ? ? ?ruleset 3
? ? ? ?type replicated
? ? ? ?min_size 1
? ? ? ?max_size 10
? ? ? ?step take new_root
? ? ? ?step chooseleaf firstn 2 type host
? ? ? ?step emit
}
<<<<<<<<<<<< 添加結束 ?<<<<<<<<<<<<
# end crush map
### 編譯 CRUSH MAP，并注入到集群中
crushtool -c map.txt -o map.bin
ceph osd setcrushmap -i map.bin
3. 開始遷移數據
###確認當前 volumes 池使用的是 crush_ruleset 0
[root@ceph cluster]# ceph osd pool get volumes crush_ruleset
crush_ruleset: 0
### 將 volumes 池的 crush_ruleset 設置為 1，設置完后，集群一切正常，PG均為active+clean
[root@ceph cluster]# ceph osd pool set volumes crush_ruleset 1
set pool 1 crush_ruleset to 1
### 將 volumes 池的 副本數設置為4， 設置完后，PG經過短暫 Peer，變為 active+undersized+degraded
[root@ceph cluster]# ceph osd pool set volumes size 4
set pool 1 size to 4
[root@ceph cluster]# ceph -s
? ?cluster 166889ab-fa7b-4a07-83da-6dfc92913a3d
? ? health HEALTH_WARN
? ? ? ? ? ?256 pgs degraded
? ? ? ? ? ?256 pgs undersized
? ? ? ? ? ?recovery 183984/368006 objects degraded (49.995%)
? ? monmap e47: 3 mons at {ceph=192.168.100.112:6789/0,com=192.168.100.111:6789/0,con=192.168.100.110:6789/0}
? ? ? ? ? ?election epoch 182, quorum 0,1,2 con,com,ceph
? ? osdmap e106: 6 osds: 6 up, 6 in
? ? ? ? ? ?flags sortbitwise,require_jewel_osds
? ? ?pgmap v23391: 768 pgs, 3 pools, 403 MB data, 92011 objects
? ? ? ? ? ?1523 MB used, 1532 GB / 1533 GB avail
? ? ? ? ? ?183984/368006 objects degraded (49.995%)
? ? ? ? ? ? ? ? 512 active+clean
? ? ? ? ? ? ? ? 256 active+undersized+degraded
[root@ceph cluster]# ceph osd pool set volumes crush_ruleset 2
set pool 1 crush_ruleset to 2
### 等到 volumes 池的所有PG均變為 active+clean 后，將 volumes 池的 crush_ruleset 設置為3， 此步驟后，volumes 池的 PG狀態變為 active+remapped。但是不影響集群IO。
[root@ceph cluster]# ceph osd pool set volumes crush_ruleset 2
set pool 1 crush_ruleset to 2
set pool 1 crush_ruleset to 3
### 此時，將 volumes 池的 副本數 設置為2 ，此時 PG 狀態經過 peer 之后，很快變為 active+clean ，volumes 池的兩副本均落在新的節點下，并且后臺在自行刪除之前舊節點上的數據。
[root@ceph cluster]# ceph osd pool set volumes size ?2
Ceph 版本不一致： 由于舊的節點的 Ceph 版本為 0.94.5 ，而新節點安裝了較新版本的 10.2.7， 在副本 2=>4 的過程中Peer是正常的，而將池的crush_ruleset 設置為3 ，也就是將新節點的 PG 升級為主副本后，PG由新節點向舊節點發生Peer，此時會一直卡住，PG始終卡在了?remapped + peering，導致該 pool 無法IO。在將新舊節點 Ceph 版本一致后(舊節點升級，新節點降級)，此現象得以消除。 為了確保此現象不會在實際操作中發生，應該在變更之前，新建一個測試pool，對其寫入部分數據，再執行所有數據遷移指令，查看此過程是否順暢，確認無誤后，再對生產pool進行操作！
新節點 OSD 的重啟問題： 如果沒有添加了osd_crush_update_on_start?這個配置參數，那么當新節點的OSD重啟后，會自動添加到默認的?root=default?下，然后立刻產生數據遷移，因此需要添加這個參數，保證OSD始終位于我們人為指定的節點下，并不受重啟影響。這是個基本的Ceph運維常識，但是一旦遺忘了，可能造成較為嚴重的影響。更不用說防火墻時鐘這些配置了。
集群性能降低：總體來說，在副本從2克隆為4這段時間(約2-3天，取決于集群數據量）內，集群的實際IO表現降低到變更前的 25%->80% 左右，時間越往后表現越接近變更前，這雖然不會導致客戶端的IO阻塞，但從客戶反饋來看，可以感知到較為明顯的卡頓。因此克隆時間應該選擇業務量較低的節假日等。
新節點IP不cluster_network范圍內：這個比較好解決，只需要增大部署目錄ceph.conf內的cluster_network?或者?public_network的掩碼范圍即可，不需要修改舊節點的，當然網絡還是要通的。
變更的回退：對于生產環境來說，盡管執行步驟幾乎是嚴謹不會出錯的，但是難免會遇到意外情況，就比如上面的版本不一致導致的 peer 卡住現象。因此我們需要制定完善的回退步驟，在意外發生的時候，能夠快速將環境回退到上一步集群正常的狀況，而不是在意外發生時驚出一身冷汗，雙手顫抖得敲指令。。。所以，下面的表格給出了這個變更操作的每一步的回退步驟：
| ceph osd pool set volumes crush_ruleset 1 | 無 | ceph osd pool set volumes crush_ruleset 0 | 無 |
| ceph osd pool set volumes size 4 | PG由active+clean，變為 active+undersized+degraded | ceph osd pool set volumes size 2 | PG很快恢復active+clean |
| ceph osd pool set volumes crush_ruleset 2 | PG 開始 backfill，需要較長時間 | ceph osd pool set volumes crush_ruleset 1 | PG很快恢復到active+undersized+degraded，并刪除在新節點生成的數據。 |
| ceph osd pool set volumes crush_ruleset 3 | PG 很快變為 active+remapped。 | ceph osd pool set volumes crush_ruleset2 | PG很快恢復到 active+clean |
| ceph osd pool set volumes size 2 | PG 很快變為 active+clean，并且后臺刪除舊節點數據。 | ceph osd pool set volumes size 4 | PG 變為active+remapped。 |
原理介紹
Glance ：上傳下載鏡像等時，需要新建一個調用 librbd 的 Client 來連接 Ceph集群。
Cinder ：
創建刪除云盤時，新建一個調用 librbd 的 Client 來連接 Ceph 集群。
掛載卸載云盤時，由Nova調用librbd來實現該操作。
Nova ： 虛機(qemu-kvm進程)相當于一個始終在調用librbd的Client，并且進程始終都在。
qemu ? ? ? ?3171 ? ? ? 1 17 14:32 ? ? ? ? ?00:31:08 /usr/libexec/qemu-kvm -name guest=instance-0000000b.........
[root@con ~(keystone_admin)]# netstat -tnp |grep 3171|grep 6789
tcp ? ? ? ?0 ? ? ?0 192.168.100.110:59926 ? 192.168.100.112:6789 ? ?ESTABLISHED 3171/qemu-kvm [root@con ~(keystone_admin)]# ssh 192.168.100.112 systemctl stop ceph-mon.target
[root@con ~(keystone_admin)]# netstat -tnp |grep 3171|grep 6789
tcp ? ? ? ?0 ? ? ?0 192.168.100.110:48792 ? 192.168.100.111:6789 ? ?ESTABLISHED 3171/qemu-kvm ?
原先有三個MON： con， com， ceph
增加 new_mon_1，變為四個： con， com， ceph， new_mon_1
刪除con，變為三個：com， ceph， new_mon_1
增加 new_mon_2，變為四個： com， ceph， new_mon_1， new_mon_2
刪除com，變為三個：ceph， new_mon_1， new_mon_2
增加 new_mon_3，變為四個： ceph， new_mon_1， new_mon_2， new_mon_3
刪除con，變為三個：new_mon_1， new_mon_2， new_mon_3
Nova 側的一個問題
### 具體字段為：
mysql =>
nova ?=> block_device_mapping => connection_info
*************************** 23. row ***************************
? ? ? ? ? created_at: 2018-03-19 08:50:59
? ? ? ? ? updated_at: 2018-03-26 06:32:06
? ? ? ? ? deleted_at: 2018-03-26 09:20:02
? ? ? ? ? ? ? ? ? id: 29
? ? ? ? ?device_name: /dev/vdb
delete_on_termination: 0
? ? ? ? ?snapshot_id: NULL
? ? ? ? ? ?volume_id: 39c76d96-0f95-490c-b7db-b3da6d17331b
? ? ? ? ?volume_size: NULL
? ? ? ? ? ?no_device: NULL
? ? ?connection_info: {"driver_volume_type": "rbd", "serial": "39c76d96-0f95-490c-b7db-b3da6d17331b", "data": {"secret_type": "ceph", "name": "volumes/volume-39c76d96-0f95-490c-b7db-b3da6d17331b", "secret_uuid": "0668cc5e-7145-4b27-8c83-6c28e1353e83", "qos_specs": null, "hosts": ["192.168.100.110", "192.168.100.111", "192.168.100.112"], "auth_enabled": true, "access_mode": "rw", "auth_username": "cinder", "ports": ["6789", "6789", "6789"]}}
? ? ? ?instance_uuid: 4f52191f-9645-448f-977b-80ca515387f7
? ? ? ? ? ? ?deleted: 29
? ? ? ? ?source_type: volume
? ? destination_type: volume
? ? ? ? guest_format: NULL
? ? ? ? ?device_type: disk
? ? ? ? ? ? disk_bus: virtio
? ? ? ? ? boot_index: NULL
? ? ? ? ? ? image_id: NULL
遷移指令
### 添加 new_mon_1
[root@ceph cluster]# ceph-deploy mon add new_mon_1
[root@ceph cluster]# ceph -s
? ?cluster 166889ab-fa7b-4a07-83da-6dfc92913a3d
? ? health HEALTH_OK
? ? monmap e48: 4 mons at {ceph=192.168.100.112:6789/0,com=192.168.100.111:6789/0,con=192.168.100.110:6789/0,new_mon_1=192.168.100.113:6789/0}
? ?
### 刪除 con ?刪除完后，建議等待1-3min再添加新的MON，使得qemu-kvm進程可以建立新的socket鏈接。
[root@ceph cluster]# ceph-deploy mon destroy con
[root@ceph cluster]# ceph -s
? ?cluster 166889ab-fa7b-4a07-83da-6dfc92913a3d
? ? health HEALTH_OK
? ? monmap e49: 3 mons at {ceph=192.168.100.112:6789/0,com=192.168.100.111:6789/0,new_mon_1=192.168.100.113:6789/0}
? ?
### 依次添加 new_mon_2 ，刪除 com，添加 new_mon_3 ， 刪除 ceph：
[root@ceph cluster]# ceph-deploy mon add new_mon_2
[root@ceph cluster]# ceph-deploy mon destroy com
### 等待1-3min，
[root@ceph cluster]# ceph-deploy mon add new_mon_3
[root@ceph cluster]# ceph-deploy mon destroy ceph
[root@con ~(keystone_admin)]# ceph -s
cluster 166889ab-fa7b-4a07-83da-6dfc92913a3d
? ? health HEALTH_OK
? ? monmap e53: 3 mons at {new_mon_1=192.168.100.113:6789/0,new_mon_2=192.168.100.114:6789/0,new_mon_3=192.168.100.115:6789/0}
Glance & Cinder & Nova 服務重啟
## 在計算節點
openstack-service restart nova-compute
## 在控制節點
openstack-service restart cinder
Nova
mysql >>
use nova;
update ?block_device_mapping set connection_info=(replace(connection_info,'192.168.100.110','192.168.100.113'))；
update ?block_device_mapping set connection_info=(replace(connection_info,'192.168.100.111','192.168.100.114'))；
update ?block_device_mapping set connection_info=(replace(connection_info,'192.168.100.112','192.168.100.115'))；
exit;
參考文檔
[如何更改基于rbd塊設備的虛機的monitor ip] [https://opengers.github.io/openstack/how-to-change-guest-monitor-ip-with-rbd-disk/#%E6%9F%A5%E7%9C%8B%E8%99%9A%E6%8B%9F%E6%9C%BA%E5%BD%93%E5%89%8D%E8%BF%9E%E6%8E%A5%E7%9A%84monitor-ip]
[Ceph Monitor hardcoded IPs in Nova database] [https://bugzilla.redhat.com/show_bug.cgi?id=1414124]
總結
以上是生活随笔為你收集整理的Ceph 集群整体迁移方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 视频 | OFC上的腾讯声音
- 下一篇： 数据存储介质销毁：护航数据安全的最后一公