అతను మీకు మంచిది కాదు

రూక్ యొక్క పెరుగుతున్న జనాదరణకు సంబంధించి, నేను దాని ఆపదలు మరియు మీ కోసం ఎదురుచూసే సమస్యల గురించి మాట్లాడాలనుకుంటున్నాను.

నా గురించి: కమ్యూనిటీ వ్యవస్థాపకుడు, సుత్తి వెర్షన్ నుండి ceph పరిపాలనలో అనుభవం t.me/ceph_ru టెలిగ్రామ్‌లో.

నిరాధారంగా ఉండకుండా ఉండటానికి, నేను cephతో ఉన్న సమస్యల గురించి Habr (రేటింగ్ ద్వారా నిర్ణయించడం) ఆమోదించిన పోస్ట్‌లను సూచిస్తాను. నేను కూడా ఈ పోస్ట్‌లలో చాలా సమస్యలను ఎదుర్కొన్నాను. ఉపయోగించిన మెటీరియల్‌కి లింక్‌లు పోస్ట్ చివరిలో ఉన్నాయి.

రూక్ గురించిన పోస్ట్‌లో, మేము ఒక కారణం కోసం సెఫ్‌ని ప్రస్తావిస్తున్నాము - రూక్ తప్పనిసరిగా కుబెర్నెట్స్‌తో చుట్టబడిన సెఫ్, అంటే ఇది దాని సమస్యలన్నింటినీ వారసత్వంగా పొందుతుంది. ceph సమస్యలతో ప్రారంభిద్దాం.

క్లస్టర్ నిర్వహణను సులభతరం చేయండి

రూక్ యొక్క ప్రయోజనాల్లో ఒకటి కుబెరెంట్స్ ద్వారా సెఫ్‌ను నిర్వహించడం సులభం.

అయినప్పటికీ, ceph కాన్ఫిగరేషన్ కోసం 1000 కంటే ఎక్కువ పారామితులను కలిగి ఉంది, అదే సమయంలో, రూక్ ద్వారా మనం వాటిలో మైనారిటీని మాత్రమే సవరించగలము.

ప్రకాశించే ఉదాహరణ
> ceph డెమోన్ mon.a config షో | wc -l
1401

సెఫ్‌ను ఇన్‌స్టాల్ చేయడానికి మరియు అప్‌డేట్ చేయడానికి రూక్ అనుకూలమైన మార్గంగా ఉంచబడింది
రూక్ లేకుండా సెఫ్‌ను ఇన్‌స్టాల్ చేయడంలో ఎటువంటి సమస్యలు లేవు - అన్సిబుల్ ప్లేబుక్ 30 నిమిషాల్లో వ్రాయబడింది, కానీ అప్‌డేట్ చేయడంలో చాలా సమస్యలు ఉన్నాయి.

క్రోక్ పోస్ట్ నుండి కోట్

ఉదాహరణ: హమ్మర్ నుండి జ్యువెల్‌కి అప్‌డేట్ చేసిన తర్వాత క్రష్ ట్యూనబుల్స్ సరిగ్గా పని చేయదు

> ceph osd క్రష్ షో-ట్యూనబుల్స్
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"ప్రొఫైల్": "తెలియదు",
"optimal_tunables": 0,
...
}

కానీ చిన్న వెర్షన్లలో కూడా సమస్యలు ఉన్నాయి.

ఉదాహరణ: అప్‌డేట్ 12.2.6 క్లస్టర్‌ని హెల్త్ ఎర్రర్ స్టేట్ మరియు షరతులతో విరిగిన PGకి తీసుకువస్తుంది
ceph.com/releases/v12-2-8-released

నవీకరించవద్దు, వేచి ఉండి పరీక్షించాలా? కానీ మేము ఇతర విషయాలతోపాటు, నవీకరణల సౌలభ్యం కోసం రూక్‌ని ఉపయోగిస్తున్నట్లు అనిపిస్తుంది.

రూక్‌లో డిజాస్టర్ రికవరీ క్లస్టర్ సంక్లిష్టత

ఉదాహరణ: OSD దాని పాదాల వద్ద ఎర్రర్‌లతో పడిపోతుంది. కాన్ఫిగరేషన్‌లోని పారామీటర్‌లలో ఒకదానిలో సమస్య ఉందని మీరు అనుమానిస్తున్నారు, మీరు నిర్దిష్ట డెమోన్ కోసం కాన్ఫిగరేషన్‌ను మార్చాలనుకుంటున్నారు, కానీ మీకు kubernetes మరియు DaemonSet ఉన్నందున మీరు చేయలేరు.

ప్రత్యామ్నాయం లేదు. ceph చెప్పండి osd.Num injectargs పని చేయదు - OSD అబద్ధం చెబుతోంది.

కష్టం డీబగ్

కొన్ని సెటప్‌లు మరియు పనితీరు పరీక్షలకు నేరుగా డెమోన్ యొక్క osd సాకెట్‌కి కనెక్ట్ చేయడం అవసరం. రూక్ విషయంలో, మీరు మొదట కావలసిన కంటైనర్‌ను కనుగొనాలి, ఆపై దానిలోకి వెళ్లి, డీబగ్ కోసం తప్పిపోయిన సాధనాన్ని కనుగొని చాలా కలత చెందండి.

OSDని వరుసగా పెంచడంలో ఇబ్బంది

ఉదాహరణ: OSD OOMలో వస్తుంది, రీబ్యాలెన్స్ ప్రారంభమవుతుంది, ఆ తర్వాత కిందివి వస్తాయి.

పరిష్కారం: ఒక సమయంలో OSDని పెంచండి, అది పూర్తిగా క్లస్టర్‌లో చేర్చబడే వరకు వేచి ఉండి, తదుపరి వాటిని పెంచండి. (Ceph నివేదికలో మరిన్ని వివరాలు. విపత్తు యొక్క అనాటమీ).

బేర్‌మెటల్ ఇన్‌స్టాలేషన్ విషయంలో, ఇది కేవలం చేతితో చేయబడుతుంది; రూక్ మరియు నోడ్‌కి ఒక OSD విషయంలో, ప్రత్యేక సమస్యలు లేవు; ప్రతి నోడ్‌కు OSD > 1 ఉంటే ప్రత్యామ్నాయ లిఫ్టింగ్‌లో సమస్యలు తలెత్తుతాయి.

వాస్తవానికి, అవి పరిష్కరించబడతాయి, కాని మేము విషయాలను సరళీకృతం చేయడానికి రూక్‌ని ఉపయోగిస్తాము, కానీ మరింత సంక్లిష్టతను పొందుతాము.

సెఫ్ దెయ్యాల కోసం పరిమితులను ఎంచుకోవడంలో ఇబ్బంది

ceph యొక్క బేర్‌మెటల్ ఇన్‌స్టాలేషన్ కోసం, క్లస్టర్‌కు అవసరమైన వనరులను లెక్కించడం చాలా సులభం - ఫార్ములాలు ఉన్నాయి మరియు పరిశోధన అందుబాటులో ఉంది. మీరు బలహీనమైన CPUని ఉపయోగిస్తుంటే, నుమా అంటే ఏమిటో తెలుసుకోవడానికి మీరు ఇంకా కొన్ని పనితీరు పరీక్షలను అమలు చేయాల్సి ఉంటుంది, అయితే ఇది రూక్ కంటే చాలా సులభం.

రూక్ విషయంలో, లెక్కించగల మెమరీ పరిమితులతో పాటు, మీకు CPU పరిమితిని సెట్ చేసే ప్రశ్న ఉంది.

మరియు ఇక్కడ మీరు పనితీరు పరీక్షలతో కష్టపడి పని చేయాల్సి ఉంటుంది. మీరు పరిమితులను తగ్గిస్తే, మీరు స్లో క్లస్టర్‌ని పొందుతారు; మీరు అన్‌లిమ్‌ను సెట్ చేస్తే, రీబ్యాలెన్సింగ్ సమయంలో మీరు సక్రియ CPU వినియోగాన్ని పొందుతారు, ఇది kubernetesలోని మీ అప్లికేషన్‌లపై చెడు ప్రభావాన్ని చూపుతుంది.

నెట్‌వర్కింగ్ సమస్యలు v1

ceph కోసం 2x10GB నెట్‌వర్క్‌ని ఉపయోగించమని సిఫార్సు చేయబడింది. ఒకటి క్లయింట్ ట్రాఫిక్ కోసం, మరొకటి ceph సర్వీస్ అవసరాల కోసం (రీబ్యాలెన్స్). మీరు బేర్‌మెటల్‌లో సెఫ్‌తో నివసిస్తుంటే, ఈ విభజన సులభంగా కాన్ఫిగర్ చేయబడుతుంది, మీరు రూక్‌తో నివసిస్తుంటే, నెట్‌వర్క్‌ల ద్వారా విభజన మీకు సమస్యలను కలిగిస్తుంది, ఎందుకంటే ప్రతి క్లస్టర్ కాన్ఫిగరేషన్ పాడ్‌కు రెండు వేర్వేరు నెట్‌వర్క్‌లను ఫీడ్ చేయడానికి మిమ్మల్ని అనుమతించదు. .

నెట్‌వర్కింగ్ సమస్యలు v2

మీరు నెట్‌వర్క్‌లను వేరు చేయడానికి నిరాకరిస్తే, రీబ్యాలెన్సింగ్ చేసినప్పుడు, ceph ట్రాఫిక్ మొత్తం ఛానెల్‌ని అడ్డుకుంటుంది మరియు కుబెర్నెట్స్‌లోని మీ అప్లికేషన్‌లు నెమ్మదించబడతాయి లేదా క్రాష్ అవుతాయి. మీరు ceph రీబ్యాలెన్సింగ్ వేగాన్ని తగ్గించవచ్చు, కానీ దీర్ఘ రీబ్యాలెన్సింగ్ కారణంగా మీరు డిస్క్‌లు లేదా OOM ద్వారా క్లస్టర్ నుండి రెండవ నోడ్ పడిపోయే ప్రమాదం ఎక్కువగా ఉంటుంది మరియు ఇప్పటికే క్లస్టర్‌కు మాత్రమే రీడ్ చేయడానికి హామీ ఇవ్వబడింది.

దీర్ఘ రీబ్యాలెన్స్ - లాంగ్ అప్లికేషన్ లాగ్స్

Ceph పోస్ట్ నుండి కోట్. అనాటమీ ఆఫ్ ఎ డిజాస్టర్.

టెస్ట్ క్లస్టర్ పనితీరు:

4 KB పరిమాణంలో వ్రాసే ఆపరేషన్ 1 ms పడుతుంది, పనితీరు 1000 థ్రెడ్‌లో 1 ఆపరేషన్‌లు/సెకను.

4 MB (వస్తువు పరిమాణం) యొక్క ఆపరేషన్ 22 ms పడుతుంది, పనితీరు 45 ఆపరేషన్లు/సెకను.

పర్యవసానంగా, మూడింటిలో ఒక డొమైన్ విఫలమైనప్పుడు, క్లస్టర్ కొంత సమయం వరకు క్షీణించిన స్థితిలో ఉంటుంది మరియు హాట్ ఆబ్జెక్ట్‌లలో సగం వేర్వేరు వెర్షన్‌లలో పంపిణీ చేయబడుతుంది, అప్పుడు సగం వ్రాత కార్యకలాపాలు బలవంతంగా పునరుద్ధరణతో ప్రారంభమవుతాయి.

మేము బలవంతంగా రికవరీ సమయాన్ని సుమారుగా గణిస్తాము - క్షీణించిన వస్తువుకు కార్యకలాపాలను వ్రాయండి.

మొదట మనం 4 msలో 22 MB చదివి, 22 ms వ్రాస్తాము, ఆపై 1 msలో 4 KB వాస్తవ డేటాను వ్రాస్తాము. ప్రామాణిక పనితీరు 45 ms ఉన్నప్పుడు SSDలో క్షీణించిన వస్తువుకు ప్రతి వ్రాత ఆపరేషన్‌కు మొత్తం 1 ms - పనితీరులో 45 రెట్లు తగ్గుదల.

మన వద్ద ఉన్న క్షీణించిన వస్తువుల శాతం ఎక్కువ, ప్రతిదీ అధ్వాన్నంగా మారుతుంది.

క్లస్టర్ యొక్క సరైన ఆపరేషన్ కోసం రీబ్యాలెన్సింగ్ వేగం కీలకం అని తేలింది.

ceph కోసం నిర్దిష్ట సర్వర్ సెట్టింగ్‌లు

cephకి నిర్దిష్ట హోస్ట్ ట్యూనింగ్ అవసరం కావచ్చు.

ఉదాహరణ: sysctl సెట్టింగ్‌లు మరియు అదే JumboFrame, ఈ సెట్టింగ్‌లలో కొన్ని మీ పేలోడ్‌ను ప్రతికూలంగా ప్రభావితం చేయవచ్చు.

రూక్ యొక్క నిజమైన అవసరం ప్రశ్నగా మిగిలిపోయింది

మీరు క్లౌడ్‌లో ఉన్నట్లయితే, మీ క్లౌడ్ ప్రొవైడర్ నుండి మీకు నిల్వ ఉంటుంది, ఇది మరింత సౌకర్యవంతంగా ఉంటుంది.

మీరు మీ స్వంత సర్వర్‌లలో ఉన్నట్లయితే, కుబెర్నెట్స్ లేకుండా cephని నిర్వహించడం మరింత సౌకర్యవంతంగా ఉంటుంది.

మీరు కొన్ని తక్కువ ధర హోస్టింగ్ నుండి సర్వర్‌లను అద్దెకు తీసుకుంటారా? అప్పుడు మీరు నెట్‌వర్క్, దాని జాప్యాలు మరియు బ్యాండ్‌విడ్త్‌తో చాలా సరదాగా ఉంటారు, ఇది సెఫ్‌ను స్పష్టంగా ప్రతికూలంగా ప్రభావితం చేస్తుంది.

మొత్తం: కుబెరెంట్‌లను అమలు చేయడం మరియు నిల్వను అమలు చేయడం అనేది విభిన్న ఇన్‌పుట్‌లు మరియు విభిన్న పరిష్కార ఎంపికలతో విభిన్నమైన పనులు - వాటిని కలపడం అంటే ఒకటి లేదా మరొకటి కోసం బహుశా ప్రమాదకరమైన ట్రేడ్-ఆఫ్ చేయడం. డిజైన్ దశలో కూడా ఈ పరిష్కారాలను కలపడం చాలా కష్టంగా ఉంటుంది మరియు ఇంకా ఆపరేషన్ కాలం ఉంది.

ఉపయోగించిన సాహిత్యం జాబితా:

పోస్ట్ #1 అయితే మీరు సెఫ్ అంటున్నారు... అతను నిజంగా అంత మంచివాడా?
పోస్ట్ #2 Ceph. అనాటమీ ఆఫ్ ఎ డిజాస్టర్

మూలం: www.habr.com