ਵਿਅਸਤ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ Ceph ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸੁਝਾਅ ਅਤੇ ਜੁਗਤਾਂ

ਵੱਖ-ਵੱਖ ਲੋਡਾਂ ਵਾਲੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਨੈੱਟਵਰਕ ਸਟੋਰੇਜ ਦੇ ਤੌਰ 'ਤੇ Ceph ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਵੱਖ-ਵੱਖ ਕਾਰਜਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਸਧਾਰਨ ਜਾਂ ਮਾਮੂਲੀ ਨਹੀਂ ਲੱਗਦੇ। ਉਦਾਹਰਣ ਲਈ:

• ਨਵੇਂ ਕਲੱਸਟਰ ਵਿੱਚ ਪਿਛਲੇ ਸਰਵਰਾਂ ਦੀ ਅੰਸ਼ਕ ਵਰਤੋਂ ਦੇ ਨਾਲ ਪੁਰਾਣੇ Ceph ਤੋਂ ਨਵੇਂ ਵਿੱਚ ਡੇਟਾ ਦਾ ਮਾਈਗਰੇਸ਼ਨ;
• Ceph ਵਿੱਚ ਡਿਸਕ ਸਪੇਸ ਵੰਡ ਦੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ.

ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਨਜਿੱਠਣ ਲਈ, ਸਾਨੂੰ ਡਾਟਾ ਗੁਆਏ ਬਿਨਾਂ OSD ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਹਟਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਜੋ ਕਿ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਨਾਲ ਨਜਿੱਠਣ ਵੇਲੇ ਖਾਸ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ। ਇਸ ਲੇਖ ਵਿਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ.

ਹੇਠਾਂ ਦੱਸੇ ਗਏ ਤਰੀਕੇ Ceph ਦੇ ਕਿਸੇ ਵੀ ਸੰਸਕਰਣ ਲਈ ਢੁਕਵੇਂ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਤੱਥ ਕਿ Ceph ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ, ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਵੇਗਾ: ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਅਤੇ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰੋਕਣ ਲਈ, ਕੁਝ ਕਾਰਵਾਈਆਂ ਨੂੰ ਕਈ ਹੋਰਾਂ ਵਿੱਚ "ਵੰਡਿਆ" ਜਾਵੇਗਾ।

OSD ਬਾਰੇ ਮੁਖਬੰਧ

ਕਿਉਂਕਿ ਵਿਚਾਰੇ ਗਏ ਤਿੰਨ ਪਕਵਾਨਾਂ ਵਿੱਚੋਂ ਦੋ OSD ਨੂੰ ਸਮਰਪਿਤ ਹਨ (ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਡੈਮਨ), ਵਿਹਾਰਕ ਹਿੱਸੇ ਵਿੱਚ ਗੋਤਾਖੋਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ - ਸੰਖੇਪ ਵਿੱਚ ਇਸ ਬਾਰੇ ਕਿ ਇਹ Ceph ਵਿੱਚ ਕੀ ਹੈ ਅਤੇ ਇਹ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਪੂਰੇ Ceph ਕਲੱਸਟਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ OSD ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ. ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਹਨ, Ceph ਵਿੱਚ ਮੁਫਤ ਡਾਟਾ ਵਾਲੀਅਮ ਓਨਾ ਹੀ ਵੱਧ ਹੈ। ਇੱਥੋਂ ਸਮਝਣਾ ਆਸਾਨ ਹੈ ਮੁੱਖ OSD ਫੰਕਸ਼ਨ: ਇਹ ਸਾਰੇ ਕਲੱਸਟਰ ਨੋਡਾਂ ਦੇ ਫਾਈਲ ਸਿਸਟਮਾਂ 'ਤੇ Ceph ਆਬਜੈਕਟ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ (ਪੜ੍ਹਨ, ਲਿਖਣ ਅਤੇ ਹੋਰ ਬੇਨਤੀਆਂ ਲਈ)।

ਉਸੇ ਪੱਧਰ 'ਤੇ, ਵੱਖ-ਵੱਖ OSDs ਵਿਚਕਾਰ ਵਸਤੂਆਂ ਦੀ ਨਕਲ ਕਰਕੇ ਰੀਪਲੀਕੇਸ਼ਨ ਪੈਰਾਮੀਟਰ ਸੈੱਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਅਤੇ ਇੱਥੇ ਤੁਹਾਨੂੰ ਕਈ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਦੇ ਹੱਲਾਂ ਬਾਰੇ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ.

ਕੇਸ ਨੰ: 1. ਡਾਟਾ ਗੁਆਏ ਬਿਨਾਂ Ceph ਕਲੱਸਟਰ ਤੋਂ OSD ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਹਟਾਓ

OSD ਨੂੰ ਹਟਾਉਣ ਦੀ ਲੋੜ ਕਲੱਸਟਰ ਤੋਂ ਸਰਵਰ ਨੂੰ ਹਟਾਉਣ ਦੇ ਕਾਰਨ ਹੋ ਸਕਦੀ ਹੈ - ਉਦਾਹਰਨ ਲਈ, ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਸਰਵਰ ਨਾਲ ਬਦਲਣ ਲਈ - ਜੋ ਕਿ ਸਾਡੇ ਨਾਲ ਵਾਪਰਿਆ ਹੈ, ਇਸ ਲੇਖ ਦੇ ਲਿਖਣ ਨੂੰ ਜਨਮ ਦਿੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਹੇਰਾਫੇਰੀ ਦਾ ਅੰਤਮ ਟੀਚਾ ਇੱਕ ਦਿੱਤੇ ਸਰਵਰ 'ਤੇ ਸਾਰੇ OSD ਅਤੇ ਮੋਨਸ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨਾ ਹੈ ਤਾਂ ਜੋ ਇਸਨੂੰ ਰੋਕਿਆ ਜਾ ਸਕੇ।

ਸਹੂਲਤ ਲਈ ਅਤੇ ਅਜਿਹੀ ਸਥਿਤੀ ਤੋਂ ਬਚਣ ਲਈ ਜਿੱਥੇ, ਕਮਾਂਡਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ, ਅਸੀਂ ਲੋੜੀਂਦੇ 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}

ਚਲੋ ਓਐਸਡੀ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚੋਂ ਬਾਹਰ ਕੱਢੀਏ:

ceph osd out osd.${ID}

ਚਲੋ OSD ਸੇਵਾ ਨੂੰ ਬੰਦ ਕਰੀਏ ਅਤੇ FS ਵਿੱਚ ਇਸਦੇ ਭਾਗ ਨੂੰ ਅਨਮਾਊਂਟ ਕਰੀਏ:

systemctl stop ceph-osd@${ID}
umount /var/lib/ceph/osd/ceph-${ID}

ਤੋਂ OSD ਹਟਾਓ CRUSH ਨਕਸ਼ਾ:

ceph osd crush remove osd.${ID}

ਚਲੋ OSD ਉਪਭੋਗਤਾ ਨੂੰ ਮਿਟਾਉਂਦੇ ਹਾਂ:

ceph auth del osd.${ID}

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਆਓ ਆਪਾਂ ਓਐਸਡੀ ਨੂੰ ਹਟਾ ਦੇਈਏ:

ceph osd rm osd.${ID}

ਟਿੱਪਣੀ: ਜੇਕਰ ਤੁਸੀਂ Ceph Luminous ਸੰਸਕਰਣ ਜਾਂ ਉੱਚਾ ਵਰਜਨ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਉਪਰੋਕਤ OSD ਹਟਾਉਣ ਦੇ ਕਦਮਾਂ ਨੂੰ ਦੋ ਕਮਾਂਡਾਂ ਤੱਕ ਘਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

ceph osd out osd.${ID}
ceph osd purge osd.${ID}

ਜੇ, ਉੱਪਰ ਦੱਸੇ ਗਏ ਕਦਮਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ ceph osd tree, ਫਿਰ ਇਹ ਸਪੱਸ਼ਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਰਵਰ 'ਤੇ ਜਿੱਥੇ ਕੰਮ ਕੀਤਾ ਗਿਆ ਸੀ ਉੱਥੇ ਹੁਣ ਓਐਸਡੀ ਨਹੀਂ ਹਨ ਜਿਨ੍ਹਾਂ ਲਈ ਉਪਰੋਕਤ ਓਪਰੇਸ਼ਨ ਕੀਤੇ ਗਏ ਸਨ:

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 ਕਲੱਸਟਰ ਵਿੱਚ ਡਿਸਕ ਸਪੇਸ ਦੀ ਵੰਡ

ਮੈਂ ਦੂਜੀ ਕਹਾਣੀ ਪੀਜੀ (ਪੀਜੀ) ਬਾਰੇ ਪ੍ਰਸਤਾਵਨਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗਾਪਲੇਸਮੈਂਟ ਸਮੂਹ). Ceph ਵਿੱਚ PG ਦੀ ਮੁੱਖ ਭੂਮਿਕਾ ਮੁੱਖ ਤੌਰ 'ਤੇ Ceph ਵਸਤੂਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ OSD ਵਿੱਚ ਅੱਗੇ ਦੁਹਰਾਉਣਾ ਹੈ। ਉਹ ਫਾਰਮੂਲਾ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਪੀਜੀ ਦੀ ਲੋੜੀਂਦੀ ਮਾਤਰਾ ਦੀ ਗਣਨਾ ਕਰ ਸਕਦੇ ਹੋ ਸੰਬੰਧਿਤ ਭਾਗ Ceph ਦਸਤਾਵੇਜ਼. ਇਸ ਮੁੱਦੇ 'ਤੇ ਵੀ ਖਾਸ ਉਦਾਹਰਣਾਂ ਦੇ ਨਾਲ ਚਰਚਾ ਕੀਤੀ ਗਈ ਹੈ।

ਇਸ ਲਈ: Ceph ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਆਮ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚੋਂ ਇੱਕ Ceph ਵਿੱਚ ਪੂਲ ਦੇ ਵਿਚਕਾਰ OSD ਅਤੇ PG ਦੀ ਅਸੰਤੁਲਿਤ ਸੰਖਿਆ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਸਦੇ ਕਾਰਨ, ਇੱਕ ਸਥਿਤੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ ਜਦੋਂ ਇੱਕ ਛੋਟੇ ਪੂਲ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ PGs ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਜੋ ਕਿ ਕਲੱਸਟਰ ਵਿੱਚ ਡਿਸਕ ਸਪੇਸ ਦੀ ਇੱਕ ਤਰਕਹੀਣ ਵਰਤੋਂ ਹੈ। ਦੂਜਾ, ਅਭਿਆਸ ਵਿੱਚ ਇੱਕ ਹੋਰ ਗੰਭੀਰ ਸਮੱਸਿਆ ਹੈ: OSD ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਡੇਟਾ ਓਵਰਫਲੋ। ਇਸ ਵਿੱਚ ਰਾਜ ਵਿੱਚ ਕਲੱਸਟਰ ਦੀ ਪਹਿਲੀ ਤਬਦੀਲੀ ਸ਼ਾਮਲ ਹੈ HEALTH_WARN, ਅਤੇ ਫਿਰ HEALTH_ERR. ਇਸਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ Ceph, ਡੇਟਾ ਦੀ ਉਪਲਬਧ ਮਾਤਰਾ ਦੀ ਗਣਨਾ ਕਰਦੇ ਸਮੇਂ (ਤੁਸੀਂ ਇਸਨੂੰ ਇਸ ਦੁਆਰਾ ਲੱਭ ਸਕਦੇ ਹੋ MAX AVAIL ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਵਿੱਚ ceph df ਹਰੇਕ ਪੂਲ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ) OSD ਵਿੱਚ ਉਪਲਬਧ ਡੇਟਾ ਦੀ ਮਾਤਰਾ 'ਤੇ ਅਧਾਰਤ ਹੈ। ਜੇਕਰ ਘੱਟੋ-ਘੱਟ ਇੱਕ OSD ਵਿੱਚ ਲੋੜੀਂਦੀ ਥਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਕੋਈ ਹੋਰ ਡੇਟਾ ਉਦੋਂ ਤੱਕ ਨਹੀਂ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਜਦੋਂ ਤੱਕ ਡੇਟਾ ਨੂੰ ਸਾਰੇ OSD ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਵੰਡਿਆ ਨਹੀਂ ਜਾਂਦਾ।

ਇਹ ਸਪੱਸ਼ਟ ਕਰਨ ਯੋਗ ਹੈ ਕਿ ਇਹ ਸਮੱਸਿਆਵਾਂ ਹਨ ਮੁੱਖ ਤੌਰ 'ਤੇ Ceph ਕਲੱਸਟਰ ਸੰਰਚਨਾ ਪੜਾਅ 'ਤੇ ਫੈਸਲਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਇੱਕ ਸੰਦ ਹੈ ਜੋ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ Ceph PGCalc. ਇਸਦੀ ਮਦਦ ਨਾਲ, ਪੀਜੀ ਦੀ ਲੋੜੀਂਦੀ ਮਾਤਰਾ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ. ਹਾਲਾਂਕਿ, ਤੁਸੀਂ ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਵੀ ਇਸਦਾ ਸਹਾਰਾ ਲੈ ਸਕਦੇ ਹੋ ਜਿੱਥੇ Ceph ਕਲੱਸਟਰ ਹੀ ਗਲਤ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਥੇ ਇਹ ਸਪੱਸ਼ਟ ਕਰਨ ਯੋਗ ਹੈ ਕਿ ਫਿਕਸ ਵਰਕ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਤੁਹਾਨੂੰ ਪੀਜੀ ਦੀ ਸੰਖਿਆ ਨੂੰ ਘੱਟ ਕਰਨ ਦੀ ਲੋੜ ਪਵੇਗੀ, ਅਤੇ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ Ceph ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਉਪਲਬਧ ਨਹੀਂ ਹੈ (ਇਹ ਸਿਰਫ ਸੰਸਕਰਣ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ। ਨਟੀਲਸ).

ਇਸ ਲਈ, ਆਓ ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਦੀ ਕਲਪਨਾ ਕਰੀਏ: ਕਲੱਸਟਰ ਦੀ ਇੱਕ ਸਥਿਤੀ ਹੈ HEALTH_WARN ਇੱਕ OSD ਦੀ ਸਪੇਸ ਖਤਮ ਹੋਣ ਕਾਰਨ। ਇਹ ਇੱਕ ਗਲਤੀ ਦੁਆਰਾ ਦਰਸਾਇਆ ਜਾਵੇਗਾ HEALTH_WARN: 1 near full osd. ਇਸ ਸਥਿਤੀ ਤੋਂ ਬਾਹਰ ਨਿਕਲਣ ਲਈ ਹੇਠਾਂ ਇੱਕ ਐਲਗੋਰਿਦਮ ਹੈ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਬਾਕੀ ਬਚੇ OSDs ਵਿਚਕਾਰ ਉਪਲਬਧ ਡੇਟਾ ਨੂੰ ਵੰਡਣ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਪਹਿਲੇ ਕੇਸ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸਮਾਨ ਓਪਰੇਸ਼ਨ ਕੀਤਾ ਹੈ, ਜਦੋਂ ਅਸੀਂ ਨੋਡ ਨੂੰ "ਨਿਕਾਸ" ਕੀਤਾ ਸੀ - ਸਿਰਫ ਫਰਕ ਨਾਲ ਕਿ ਹੁਣ ਸਾਨੂੰ ਥੋੜ੍ਹਾ ਜਿਹਾ ਘਟਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ reweight. ਉਦਾਹਰਨ ਲਈ, 0.95 ਤੱਕ:

ceph osd reweight osd.${ID} 0.95

ਇਹ OSD ਵਿੱਚ ਡਿਸਕ ਸਪੇਸ ਖਾਲੀ ਕਰਦਾ ਹੈ ਅਤੇ ceph ਹੈਲਥ ਵਿੱਚ ਗਲਤੀ ਨੂੰ ਠੀਕ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ ਸਮੱਸਿਆ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਵਾਂ 'ਤੇ Ceph ਦੀ ਗਲਤ ਸੰਰਚਨਾ ਦੇ ਕਾਰਨ ਹੁੰਦੀ ਹੈ: ਇੱਕ ਪੁਨਰ ਸੰਰਚਨਾ ਕਰਨਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਤਾਂ ਜੋ ਇਹ ਭਵਿੱਖ ਵਿੱਚ ਦਿਖਾਈ ਨਾ ਦੇਵੇ.

ਸਾਡੇ ਖਾਸ ਕੇਸ ਵਿੱਚ, ਇਹ ਸਭ ਹੇਠਾਂ ਆਇਆ:

• ਮੁੱਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ replication_count ਇੱਕ ਪੂਲ ਵਿੱਚ,
• ਇੱਕ ਪੂਲ ਵਿੱਚ ਬਹੁਤ ਜ਼ਿਆਦਾ 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

ਮਹੱਤਵਪੂਰਣ: ਸਾਨੂੰ ਹਰੇਕ ਪੂਲ ਵਿੱਚ ਕ੍ਰਮਵਾਰ PGs ਦੀ ਸੰਖਿਆ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਚੇਤਾਵਨੀਆਂ ਗਾਇਬ ਹੋਣ ਤੱਕ ਦੂਜੇ ਪੂਲ ਵਿੱਚ ਮੁੱਲਾਂ ਨੂੰ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ "ਡਿਗਰੇਡਡ ਡੇਟਾ ਰਿਡੰਡੈਂਸੀ" и "ਪੀਜੀਐਸ ਦੀ n-ਨੰਬਰ ਘਟੀ".

ਤੁਸੀਂ ਇਹ ਵੀ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਭ ਕੁਝ ਠੀਕ ਚੱਲ ਰਿਹਾ ਹੈ ceph health detail и ceph -s.

ਕੇਸ ਨੰ: 3। ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ LVM ਤੋਂ Ceph RBD ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨਾ

ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ ਜਿੱਥੇ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਕਿਰਾਏ ਦੇ ਬੇਅਰ-ਮੈਟਲ ਸਰਵਰਾਂ 'ਤੇ ਸਥਾਪਤ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਸਟੋਰੇਜ ਦਾ ਮੁੱਦਾ ਅਕਸਰ ਉੱਠਦਾ ਹੈ। ਇਹ ਵੀ ਬਹੁਤ ਫਾਇਦੇਮੰਦ ਹੈ ਕਿ ਇਸ ਸਟੋਰੇਜ਼ ਵਿੱਚ ਕਾਫ਼ੀ ਥਾਂ ਹੈ... ਇੱਕ ਹੋਰ ਆਮ ਸਥਿਤੀ: ਸਰਵਰ 'ਤੇ ਸਥਾਨਕ ਸਟੋਰੇਜ ਵਾਲੀ ਇੱਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਡਿਸਕ ਦਾ ਵਿਸਤਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਜਾਣ ਲਈ ਕਿਤੇ ਵੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇੱਥੇ ਕੋਈ ਨਹੀਂ ਹੈ. ਸਰਵਰ ਉੱਤੇ ਖਾਲੀ ਡਿਸਕ ਸਪੇਸ ਬਚੀ ਹੈ।

ਸਮੱਸਿਆ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ - ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਹੋਰ ਸਰਵਰ (ਜੇ ਕੋਈ ਹੈ) ਤੇ ਮਾਈਗਰੇਟ ਕਰਕੇ ਜਾਂ ਸਰਵਰ ਵਿੱਚ ਨਵੀਂ ਡਿਸਕਾਂ ਜੋੜ ਕੇ। ਪਰ ਅਜਿਹਾ ਕਰਨਾ ਹਮੇਸ਼ਾ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ, ਇਸਲਈ LVM ਤੋਂ Ceph ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ ਇਸ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਵਧੀਆ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਵਿਕਲਪ ਨੂੰ ਚੁਣ ਕੇ, ਅਸੀਂ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਮਾਈਗ੍ਰੇਸ਼ਨ ਦੀ ਅਗਲੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੀ ਸਰਲ ਬਣਾਉਂਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਸਥਾਨਕ ਸਟੋਰੇਜ ਨੂੰ ਇੱਕ ਹਾਈਪਰਵਾਈਜ਼ਰ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਲਿਜਾਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੋਵੇਗੀ। ਇੱਕੋ ਇੱਕ ਕੈਚ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ VM ਨੂੰ ਰੋਕਣਾ ਹੋਵੇਗਾ ਜਦੋਂ ਕੰਮ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ.

ਹੇਠ ਦਿੱਤੀ ਵਿਅੰਜਨ ਤੋਂ ਲਿਆ ਗਿਆ ਹੈ ਇਸ ਬਲੌਗ ਤੋਂ ਲੇਖ, ਜਿਸ ਦੀਆਂ ਹਦਾਇਤਾਂ ਨੂੰ ਕਾਰਵਾਈ ਵਿੱਚ ਪਰਖਿਆ ਗਿਆ ਹੈ। ਉਂਜ, ਮੁਸ਼ਕਲ ਰਹਿਤ ਪਰਵਾਸ ਦਾ ਤਰੀਕਾ ਵੀ ਉੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਹਾਲਾਂਕਿ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਸੀ, ਇਸਲਈ ਅਸੀਂ ਇਸਦੀ ਜਾਂਚ ਨਹੀਂ ਕੀਤੀ। ਜੇਕਰ ਇਹ ਤੁਹਾਡੇ ਪ੍ਰੋਜੈਕਟ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਨਤੀਜਿਆਂ ਬਾਰੇ ਸੁਣ ਕੇ ਖੁਸ਼ੀ ਹੋਵੇਗੀ।

ਚਲੋ ਪ੍ਰੈਕਟੀਕਲ ਹਿੱਸੇ ਵੱਲ ਵਧਦੇ ਹਾਂ। ਉਦਾਹਰਨ ਵਿੱਚ ਅਸੀਂ 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>

ਆਓ ਕੁਝ ਵੇਰਵਿਆਂ 'ਤੇ ਗੌਰ ਕਰੀਏ:

1. ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ source Ceph RBD ਵਿੱਚ ਸਟੋਰੇਜ ਦਾ ਪਤਾ ਦਰਸਾਇਆ ਗਿਆ ਹੈ (ਇਹ Ceph ਪੂਲ ਅਤੇ RBD ਚਿੱਤਰ ਦੇ ਨਾਮ ਨੂੰ ਦਰਸਾਉਂਦਾ ਪਤਾ ਹੈ, ਜੋ ਕਿ ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਸੀ)।
2. ਬਲਾਕ ਵਿੱਚ secret ਕਿਸਮ ਦਰਸਾਈ ਗਈ ਹੈ ceph, ਨਾਲ ਹੀ ਇਸ ਨਾਲ ਜੁੜਨ ਲਈ ਗੁਪਤ ਦਾ UUID। ਇਸ ਦਾ uuid ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ virsh secret-list.
3. ਬਲਾਕ ਵਿੱਚ host Ceph ਮਾਨੀਟਰਾਂ ਲਈ ਪਤੇ ਦਰਸਾਏ ਗਏ ਹਨ।

ਸੰਰਚਨਾ ਫਾਇਲ ਨੂੰ ਸੋਧਣ ਅਤੇ LVM ਨੂੰ RBD ਰੂਪਾਂਤਰਨ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਸੋਧੀ ਹੋਈ ਸੰਰਚਨਾ ਫਾਇਲ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ:

virsh define $vm_name.xml
virsh start $vm_name

ਇਹ ਜਾਂਚ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ ਕਿ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਸਹੀ ਢੰਗ ਨਾਲ ਸ਼ੁਰੂ ਹੋਈ ਹੈ: ਤੁਸੀਂ ਇਹ ਪਤਾ ਲਗਾ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, SSH ਦੁਆਰਾ ਜਾਂ ਇਸ ਰਾਹੀਂ ਇਸ ਨਾਲ ਜੁੜ ਕੇ virsh.

ਜੇਕਰ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਕੋਈ ਹੋਰ ਸਮੱਸਿਆ ਨਹੀਂ ਮਿਲੀ, ਤਾਂ ਤੁਸੀਂ LVM ਚਿੱਤਰ ਨੂੰ ਮਿਟਾ ਸਕਦੇ ਹੋ ਜੋ ਹੁਣ ਵਰਤੀ ਨਹੀਂ ਗਈ ਹੈ:

lvremove main/$vm_image_name

ਸਿੱਟਾ

ਅਸੀਂ ਅਭਿਆਸ ਵਿੱਚ ਸਾਰੇ ਵਰਣਨ ਕੀਤੇ ਕੇਸਾਂ ਦਾ ਸਾਹਮਣਾ ਕੀਤਾ - ਅਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹਾਂ ਕਿ ਨਿਰਦੇਸ਼ ਹੋਰ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨਗੇ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ Ceph ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਆਪਣੇ ਤਜ਼ਰਬੇ ਤੋਂ ਟਿੱਪਣੀਆਂ ਜਾਂ ਹੋਰ ਸਮਾਨ ਕਹਾਣੀਆਂ ਹਨ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਦੇਖ ਕੇ ਖੁਸ਼ ਹੋਵਾਂਗੇ!

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਸਾਡੇ ਹੱਥ ਬੋਰੀਅਤ ਲਈ ਨਹੀਂ ਹਨ: K8s ਵਿੱਚ Rook ਕਲੱਸਟਰ ਨੂੰ ਬਹਾਲ ਕਰਨਾ";
• «Rook ਜਾਂ ਨਹੀਂ Rook, ਇਹ ਸਵਾਲ ਹੈ";
• «ਰੂਕ ਕੁਬਰਨੇਟਸ ਲਈ ਇੱਕ "ਸਵੈ-ਸੇਵਾ" ਡੇਟਾ ਸਟੋਰ ਹੈ";
• «Ceph 'ਤੇ ਆਧਾਰਿਤ Kubernetes ਵਿੱਚ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਸਥਾਈ ਸਟੋਰੇਜ ਬਣਾਓ".

ਸਰੋਤ: www.habr.com