బిజీ ప్రాజెక్ట్‌లలో Cephతో పని చేయడానికి చిట్కాలు & ఉపాయాలు

బిజీ ప్రాజెక్ట్‌లలో Cephతో పని చేయడానికి చిట్కాలు & ఉపాయాలు

వివిధ లోడ్‌లతో కూడిన ప్రాజెక్ట్‌లలో Cephని నెట్‌వర్క్ నిల్వగా ఉపయోగించడం, మొదటి చూపులో సాధారణ లేదా చిన్నవిషయం అనిపించని వివిధ పనులను మనం ఎదుర్కోవచ్చు. ఉదాహరణకి:

  • కొత్త క్లస్టర్‌లో మునుపటి సర్వర్‌ల పాక్షిక వినియోగంతో పాత Ceph నుండి కొత్తదానికి డేటాను తరలించడం;
  • Cephలో డిస్క్ స్థలం కేటాయింపు సమస్యకు పరిష్కారం.

అటువంటి సమస్యలతో వ్యవహరించేటప్పుడు, డేటాను కోల్పోకుండా OSDని సరిగ్గా తీసివేయవలసిన అవసరాన్ని మేము ఎదుర్కొంటున్నాము, ఇది పెద్ద మొత్తంలో డేటాతో వ్యవహరించేటప్పుడు చాలా ముఖ్యమైనది. ఇది వ్యాసంలో చర్చించబడుతుంది.

క్రింద వివరించిన పద్ధతులు Ceph యొక్క ఏదైనా సంస్కరణకు సంబంధించినవి. అదనంగా, Ceph పెద్ద మొత్తంలో డేటాను నిల్వ చేయగలదనే వాస్తవం పరిగణనలోకి తీసుకోబడుతుంది: డేటా నష్టం మరియు ఇతర సమస్యలను నివారించడానికి, కొన్ని చర్యలు అనేక ఇతర వాటికి "విభజింపబడతాయి".

OSD గురించి ముందుమాట

చర్చించబడిన మూడు వంటకాలలో రెండు OSDకి అంకితం చేయబడినందున (ఆబ్జెక్ట్ స్టోరేజ్ డెమోన్), ప్రాక్టికల్ పార్ట్‌లోకి ప్రవేశించే ముందు - క్లుప్తంగా అది సెఫ్‌లో ఉంది మరియు ఎందుకు చాలా ముఖ్యమైనది.

అన్నింటిలో మొదటిది, మొత్తం Ceph క్లస్టర్ అనేక OSDలను కలిగి ఉందని చెప్పాలి. ఎంత ఎక్కువ ఉంటే, Cephలో ఉచిత డేటా వాల్యూమ్ పెరుగుతుంది. ఇక్కడ నుండి అర్థం చేసుకోవడం సులభం ప్రధాన OSD ఫంక్షన్: ఇది అన్ని క్లస్టర్ నోడ్‌ల ఫైల్ సిస్టమ్‌లలో Ceph ఆబ్జెక్ట్ డేటాను నిల్వ చేస్తుంది మరియు దానికి నెట్‌వర్క్ యాక్సెస్‌ను అందిస్తుంది (చదవడం, రాయడం మరియు ఇతర అభ్యర్థనల కోసం).

అదే స్థాయిలో, వివిధ OSDల మధ్య వస్తువులను కాపీ చేయడం ద్వారా ప్రతిరూపణ పారామితులు సెట్ చేయబడతాయి. మరియు ఇక్కడ మీరు వివిధ సమస్యలను ఎదుర్కోవచ్చు, వాటికి పరిష్కారాలు క్రింద చర్చించబడతాయి.

కేసు సంఖ్య 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}

క్లస్టర్ నుండి 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 క్లస్టర్‌లో డిస్క్ స్థలం పంపిణీ

నేను పీజీ గురించి ముందుమాటతో రెండవ కథను ప్రారంభిస్తాను (ప్లేస్‌మెంట్ గ్రూపులు) Cephలో PG యొక్క ప్రధాన పాత్ర ప్రధానంగా Ceph వస్తువులను సమగ్రపరచడం మరియు వాటిని OSDలో మరింతగా ప్రతిబింబించడం. PG అవసరమైన మొత్తాన్ని మీరు లెక్కించగల సూత్రం ఉంది సంబంధిత విభాగం Ceph డాక్యుమెంటేషన్. ఈ సమస్య కూడా నిర్దిష్ట ఉదాహరణలతో అక్కడ చర్చించబడింది.

కాబట్టి: Cephని ఉపయోగిస్తున్నప్పుడు సాధారణ సమస్యలలో ఒకటి Cephలోని కొలనుల మధ్య OSD మరియు PG యొక్క అసమతుల్య సంఖ్య.

ముందుగా, దీని కారణంగా, ఒక చిన్న పూల్‌లో చాలా ఎక్కువ PGలు పేర్కొనబడినప్పుడు ఒక పరిస్థితి ఏర్పడవచ్చు, ఇది తప్పనిసరిగా క్లస్టర్‌లో డిస్క్ స్థలాన్ని అహేతుకంగా ఉపయోగించడం. రెండవది, ఆచరణలో మరింత తీవ్రమైన సమస్య ఉంది: OSDలలో ఒకదానిలో డేటా ఓవర్‌ఫ్లో. ఇది రాష్ట్రానికి క్లస్టర్ మొదటి పరివర్తనను కలిగిస్తుంది HEALTH_WARN, ఆపై HEALTH_ERR. దీనికి కారణం Ceph, అందుబాటులో ఉన్న డేటా మొత్తాన్ని లెక్కించేటప్పుడు (మీరు దీన్ని దీని ద్వారా కనుగొనవచ్చు MAX AVAIL కమాండ్ అవుట్‌పుట్‌లో ceph df ప్రతి పూల్ కోసం విడిగా) OSDలో అందుబాటులో ఉన్న డేటా మొత్తంపై ఆధారపడి ఉంటుంది. కనీసం ఒక OSDలో తగినంత స్థలం లేకపోతే, అన్ని OSDల మధ్య డేటా సరిగ్గా పంపిణీ చేయబడే వరకు ఎక్కువ డేటా వ్రాయబడదు.

ఈ సమస్యలు ఉన్నాయని స్పష్టం చేయడం విలువ Ceph క్లస్టర్ కాన్ఫిగరేషన్ దశలో ఎక్కువగా నిర్ణయించబడతాయి. మీరు ఉపయోగించగల సాధనాల్లో ఒకటి Ceph PGCalc. దాని సహాయంతో, PG యొక్క అవసరమైన మొత్తం స్పష్టంగా లెక్కించబడుతుంది. అయితే, మీరు Ceph క్లస్టర్ ఉన్న పరిస్థితిలో కూడా దీనిని ఆశ్రయించవచ్చు ఇప్పటికే తప్పుగా కాన్ఫిగర్ చేయబడింది. పరిష్కార పనిలో భాగంగా మీరు PGల సంఖ్యను తగ్గించవలసి ఉంటుందని ఇక్కడ స్పష్టం చేయడం విలువ, మరియు 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 మరియు మరొక కొలనులో చాలా తక్కువ.

ఇప్పటికే పేర్కొన్న కాలిక్యులేటర్‌ని ఉపయోగిస్తాము. ఇది నమోదు చేయవలసిన వాటిని స్పష్టంగా చూపిస్తుంది మరియు సూత్రప్రాయంగా, సంక్లిష్టంగా ఏమీ లేదు. అవసరమైన పారామితులను సెట్ చేసిన తర్వాత, మేము ఈ క్రింది సిఫార్సులను పొందుతాము:

వ్యాఖ్య: మీరు స్క్రాచ్ నుండి 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-number of pgs degraded".

మీరు కమాండ్ అవుట్‌పుట్‌లను ఉపయోగించి ప్రతిదీ సరిగ్గా జరిగిందో లేదో కూడా తనిఖీ చేయవచ్చు 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

మా బ్లాగులో కూడా చదవండి:

మూలం: www.habr.com

ఒక వ్యాఖ్యను జోడించండి