વ્યસ્ત પ્રોજેક્ટ્સમાં Ceph સાથે કામ કરવા માટેની ટિપ્સ અને યુક્તિઓ

વિવિધ લોડવાળા પ્રોજેક્ટ્સમાં નેટવર્ક સ્ટોરેજ તરીકે Ceph નો ઉપયોગ કરીને, અમે વિવિધ કાર્યોનો સામનો કરી શકીએ છીએ જે પ્રથમ નજરમાં સરળ અથવા તુચ્છ લાગતા નથી. દાખ્લા તરીકે:

• નવા ક્લસ્ટરમાં અગાઉના સર્વર્સના આંશિક ઉપયોગ સાથે જૂના Cephમાંથી નવામાં ડેટાનું સ્થળાંતર;
• Ceph માં ડિસ્ક જગ્યા ફાળવણીની સમસ્યાનો ઉકેલ.

આવી સમસ્યાઓનો સામનો કરતા, અમને ડેટા ગુમાવ્યા વિના OSD ને યોગ્ય રીતે દૂર કરવાની જરૂરિયાતનો સામનો કરવો પડે છે, જે ખાસ કરીને જ્યારે મોટી માત્રામાં ડેટા સાથે કામ કરતી વખતે મહત્વપૂર્ણ છે. આ લેખમાં ચર્ચા કરવામાં આવશે.

નીચે વર્ણવેલ પદ્ધતિઓ Ceph ના કોઈપણ સંસ્કરણ માટે સુસંગત છે. વધુમાં, હકીકત એ છે કે સેફ મોટી માત્રામાં ડેટા સ્ટોર કરી શકે છે તે ધ્યાનમાં લેવામાં આવશે: ડેટાના નુકશાન અને અન્ય સમસ્યાઓને રોકવા માટે, કેટલીક ક્રિયાઓ અન્ય કેટલાકમાં "વિભાજિત" કરવામાં આવશે.

OSD વિશે પ્રસ્તાવના

ચર્ચા કરેલ ત્રણમાંથી બે વાનગીઓ OSD ને સમર્પિત હોવાથી (ઑબ્જેક્ટ સ્ટોરેજ ડિમન), વ્યવહારુ ભાગમાં ડાઇવિંગ કરતા પહેલા - તે સેફમાં શું છે અને તે શા માટે એટલું મહત્વપૂર્ણ છે તે વિશે ટૂંકમાં.

સૌ પ્રથમ, એવું કહેવું જોઈએ કે સમગ્ર Ceph ક્લસ્ટરમાં ઘણા OSDs છે. વધુ ત્યાં છે, કેફમાં ફ્રી ડેટા વોલ્યુમ વધારે છે. અહીંથી સમજવું સરળ છે મુખ્ય OSD કાર્ય: તે તમામ ક્લસ્ટર નોડ્સની ફાઇલ સિસ્ટમ્સ પર Ceph ઑબ્જેક્ટ ડેટા સ્ટોર કરે છે અને તેને નેટવર્ક ઍક્સેસ પ્રદાન કરે છે (વાંચવા, લેખન અને અન્ય વિનંતીઓ માટે).

સમાન સ્તરે, વિવિધ OSDs વચ્ચે ઑબ્જેક્ટ કૉપિ કરીને પ્રતિકૃતિ પરિમાણો સેટ કરવામાં આવે છે. અને અહીં તમે વિવિધ સમસ્યાઓનો સામનો કરી શકો છો, જેના ઉકેલો નીચે ચર્ચા કરવામાં આવશે.

કેસ નંબર 1. ડેટા ગુમાવ્યા વિના Ceph ક્લસ્ટરમાંથી OSD સુરક્ષિત રીતે દૂર કરો

OSD ને દૂર કરવાની જરૂરિયાત ક્લસ્ટરમાંથી સર્વરને દૂર કરવાથી થઈ શકે છે - ઉદાહરણ તરીકે, તેને બીજા સર્વર સાથે બદલવા માટે - જે અમારી સાથે થયું છે, આ લેખના લેખનને જન્મ આપે છે. આમ, મેનીપ્યુલેશનનો અંતિમ ધ્યેય આપેલ સર્વર પરના તમામ OSDs અને મોન્સને બહાર કાઢવાનો છે જેથી કરીને તેને રોકી શકાય.

સગવડ માટે અને એવી પરિસ્થિતિને ટાળવા માટે કે જ્યાં, આદેશોનો અમલ કરતી વખતે, અમે જરૂરી 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 લ્યુમિનસ વર્ઝન અથવા ઉચ્ચતરનો ઉપયોગ કરી રહ્યાં છો, તો ઉપરોક્ત OSD દૂર કરવાના પગલાંને બે આદેશોમાં ઘટાડી શકાય છે:

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

જો, ઉપર વર્ણવેલ પગલાંઓ પૂર્ણ કર્યા પછી, તમે આદેશ ચલાવો ceph osd tree, પછી તે સ્પષ્ટ હોવું જોઈએ કે સર્વર પર જ્યાં કાર્ય કરવામાં આવ્યું હતું ત્યાં હવે OSDs નથી કે જેના માટે ઉપરોક્ત કામગીરી કરવામાં આવી હતી:

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

રસ્તામાં, નોંધ કરો કે સેફ ક્લસ્ટરની સ્થિતિ પર જશે HEALTH_WARN, અને અમે OSD ની સંખ્યામાં અને ઉપલબ્ધ ડિસ્ક જગ્યાની માત્રામાં પણ ઘટાડો જોશું.

જો તમે સર્વરને સંપૂર્ણપણે બંધ કરવા માંગતા હોવ અને તે મુજબ, તેને Ceph માંથી દૂર કરવા માંગતા હોવ તો નીચેના પગલાંઓનું વર્ણન કરશે. આ કિસ્સામાં, તે યાદ રાખવું મહત્વપૂર્ણ છે સર્વર બંધ કરતા પહેલા, તમારે બધા OSDs દૂર કરવા આવશ્યક છે આ સર્વર પર.

જો આ સર્વર પર કોઈ વધુ 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 માં તેમની નકલ કરવાની છે. ફોર્મ્યુલા કે જેના વડે તમે PG ની જરૂરી રકમની ગણતરી કરી શકો છો તે છે સંબંધિત વિભાગ Ceph દસ્તાવેજીકરણ. આ મુદ્દાની પણ ત્યાં ચોક્કસ ઉદાહરણો સાથે ચર્ચા કરવામાં આવી છે.

તેથી: Ceph નો ઉપયોગ કરતી વખતે સામાન્ય સમસ્યાઓમાંની એક છે Ceph માં પૂલ વચ્ચે OSD અને PG ની અસંતુલિત સંખ્યા.

સૌપ્રથમ, આના કારણે, એવી પરિસ્થિતિ ઊભી થઈ શકે છે જ્યારે નાના પૂલમાં ઘણા બધા PG નો ઉલ્લેખ કરવામાં આવે છે, જે ક્લસ્ટરમાં ડિસ્ક સ્પેસનો અનિવાર્યપણે અતાર્કિક ઉપયોગ છે. બીજું, વ્યવહારમાં વધુ ગંભીર સમસ્યા છે: OSDમાંથી એકમાં ડેટા ઓવરફ્લો. આ રાજ્યમાં પ્રથમ સંક્રમણ માટે ક્લસ્ટરનો સમાવેશ કરે છે HEALTH_WARN, અને પછી HEALTH_ERR. આનું કારણ એ છે કે Ceph, જ્યારે ઉપલબ્ધ ડેટાની ગણતરી કરે છે (તમે તેને દ્વારા શોધી શકો છો MAX AVAIL આદેશ આઉટપુટમાં ceph df દરેક પૂલ માટે અલગથી) OSDમાં ઉપલબ્ધ ડેટાની માત્રા પર આધારિત છે. જો ઓછામાં ઓછા એક OSDમાં પૂરતી જગ્યા ન હોય, તો જ્યાં સુધી તમામ OSDs વચ્ચે ડેટા યોગ્ય રીતે વિતરિત ન થાય ત્યાં સુધી વધુ ડેટા લખી શકાશે નહીં.

તે સ્પષ્ટ કરવા યોગ્ય છે કે આ સમસ્યાઓ મોટાભાગે Ceph ક્લસ્ટર કન્ફિગરેશન સ્ટેજ પર નક્કી કરવામાં આવે છે. તમે ઉપયોગ કરી શકો તે સાધનો પૈકી એક છે Ceph PGCalc. તેની મદદથી, પીજીની જરૂરી રકમની સ્પષ્ટ ગણતરી કરવામાં આવે છે. જો કે, તમે સેફ ક્લસ્ટરની પરિસ્થિતિમાં પણ તેનો આશરો લઈ શકો છો પહેલેથી ખોટી રીતે ગોઠવેલ. અહીં સ્પષ્ટતા કરવી યોગ્ય છે કે ફિક્સ વર્કના ભાગ રૂપે તમારે પીજીની સંખ્યા ઘટાડવાની જરૂર પડશે, અને આ સુવિધા 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 ક્લસ્ટર સેટઅપ કરી રહ્યાં છો, તો કેલ્ક્યુલેટરનું બીજું ઉપયોગી કાર્ય એ આદેશોનું નિર્માણ છે જે કોષ્ટકમાં ઉલ્લેખિત પરિમાણો સાથે શરૂઆતથી પૂલ બનાવશે.

છેલ્લી કૉલમ તમને નેવિગેટ કરવામાં મદદ કરે છે - સૂચિત પીજી કાઉન્ટ. અમારા કિસ્સામાં, બીજો એક પણ ઉપયોગી છે, જ્યાં પ્રતિકૃતિ પરિમાણ સૂચવવામાં આવે છે, કારણ કે અમે પ્રતિકૃતિ ગુણક બદલવાનું નક્કી કર્યું છે.

તેથી, પ્રથમ તમારે પ્રતિકૃતિ પરિમાણો બદલવાની જરૂર છે - આ પ્રથમ કરવા યોગ્ય છે, કારણ કે ગુણક ઘટાડીને, અમે ડિસ્ક જગ્યા ખાલી કરીશું. જેમ જેમ કમાન્ડ એક્ઝેક્યુટ થશે, તમે જોશો કે ઉપલબ્ધ ડિસ્ક જગ્યા વધશે:

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 ની સંખ્યા બદલવી જોઈએ અને ચેતવણીઓ અદૃશ્ય થઈ જાય ત્યાં સુધી અન્ય પૂલમાં મૂલ્યો બદલવી જોઈએ નહીં "ડિગ્રેડેડ ડેટા રીડન્ડન્સી" и "ન-નંબર અધોગતિ પામેલ pgs".

તમે આદેશ આઉટપુટનો ઉપયોગ કરીને પણ તપાસ કરી શકો છો કે બધું બરાબર હતું 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 માં રુક ક્લસ્ટરને પુનઃસ્થાપિત કરવું»;
• «રુક માટે કે રુક માટે નહીં - તે પ્રશ્ન છે»;
• «રુક - કુબરનેટ્સ માટે "સ્વ-સેવા" ડેટા વેરહાઉસ»;
• «Ceph પર આધારિત કુબરનેટ્સમાં જોગવાઈ સાથે સતત સ્ટોરેજ બનાવવું».

સોર્સ: www.habr.com