அவர் உங்களுக்கு நல்லவர் இல்லை

ரூக்கின் வளர்ந்து வரும் புகழ் தொடர்பாக, அதன் ஆபத்துகள் மற்றும் வழியில் உங்களுக்கு காத்திருக்கும் சிக்கல்களைப் பற்றி பேச விரும்புகிறேன்.

என்னைப் பற்றி: சமூக நிறுவனர், சுத்தியல் பதிப்பிலிருந்து ceph நிர்வாகத்தில் அனுபவம் t.me/ceph_ru தந்தியில்.

ஆதாரமற்றதாக இருக்கக்கூடாது என்பதற்காக, ceph உடனான பிரச்சனைகள் பற்றி Habr (மதிப்பீட்டின் மூலம் தீர்மானிக்க) ஏற்றுக்கொண்ட இடுகைகளைப் பார்க்கிறேன். இந்த இடுகைகளில் பெரும்பாலான சிக்கல்களை நானும் சந்தித்தேன். பயன்படுத்திய பொருளுக்கான இணைப்புகள் இடுகையின் முடிவில் உள்ளன.

Rook பற்றிய இடுகையில், ஒரு காரணத்திற்காக ceph ஐக் குறிப்பிடுகிறோம் - ரூக் அடிப்படையில் ceph குபெர்னெட்ஸில் மூடப்பட்டிருக்கும், அதாவது அதன் அனைத்து பிரச்சனைகளையும் அது பெறுகிறது. ceph பிரச்சனைகளுடன் ஆரம்பிக்கலாம்.

கிளஸ்டர் நிர்வாகத்தை எளிதாக்குங்கள்

ரூக்கின் நன்மைகளில் ஒன்று, குபெரெண்டஸ் மூலம் செஃப்பை நிர்வகிப்பது எளிது.

இருப்பினும், ceph உள்ளமைவுக்கான 1000 க்கும் மேற்பட்ட அளவுருக்களைக் கொண்டுள்ளது, அதே நேரத்தில், ரூக் மூலம் அவற்றில் சிறுபான்மையினரை மட்டுமே திருத்த முடியும்.

லுமினஸ் பற்றிய எடுத்துக்காட்டு
> ceph deemon mon.a config show | wc -l
1401

ceph ஐ நிறுவ மற்றும் புதுப்பிக்க ஒரு வசதியான வழியாக Rook நிலைநிறுத்தப்பட்டுள்ளது
ரூக் இல்லாமல் ceph ஐ நிறுவுவதில் எந்த பிரச்சனையும் இல்லை - ansible playbook 30 நிமிடங்களில் எழுதப்பட்டது, ஆனால் புதுப்பிப்பதில் நிறைய சிக்கல்கள் உள்ளன.

க்ரோக்கின் இடுகையிலிருந்து மேற்கோள்

எடுத்துக்காட்டு: க்ரஷ் ட்யூனபிள்கள் ஹம்மரில் இருந்து ஜூவலுக்குப் புதுப்பித்த பிறகு சரியாக வேலை செய்யாது

> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"சுயவிவரம்": "தெரியாது",
"optimal_tunables": 0,
...
}

ஆனால் சிறிய பதிப்புகளில் கூட சிக்கல்கள் உள்ளன.

உதாரணம்: 12.2.6 புதுப்பிப்பு கிளஸ்டரை உடல்நலப் பிழை நிலை மற்றும் நிபந்தனைக்குட்பட்ட பி.ஜி.
ceph.com/releases/v12-2-8-released

புதுப்பிக்க வேண்டாம், காத்திருந்து சோதிக்க வேண்டுமா? ஆனால் புதுப்பிப்புகளின் வசதிக்காக நாங்கள் ரூக்கைப் பயன்படுத்துகிறோம், மற்றவற்றுடன்.

ரூக்கில் பேரிடர் மீட்புக் குழுவின் சிக்கலான தன்மை

உதாரணம்: OSD அதன் காலடியில் ஒரு சொறி பிழைகளுடன் விழுகிறது. config இல் உள்ள அளவுருக்களில் ஒன்றில் சிக்கல் இருப்பதாக நீங்கள் சந்தேகிக்கிறீர்கள், நீங்கள் ஒரு குறிப்பிட்ட டீமானுக்கான கட்டமைப்பை மாற்ற விரும்புகிறீர்கள், ஆனால் உங்களிடம் kubernetes மற்றும் DaemonSet இருப்பதால் உங்களால் முடியாது.

மாற்றுக் கருத்து இல்லை. ceph சொல்ல osd.Num injectargs வேலை செய்யாது - OSD பொய்.

சிரமம் பிழைத்திருத்தம்

சில அமைப்புகள் மற்றும் செயல்திறன் சோதனைகளுக்கு டீமனின் osd சாக்கெட்டுடன் நேரடியாக இணைக்க வேண்டும். ரூக்கைப் பொறுத்தவரை, நீங்கள் முதலில் விரும்பிய கொள்கலனைக் கண்டுபிடிக்க வேண்டும், பின்னர் அதற்குள் சென்று, பிழைத்திருத்தத்திற்கான கருவியைக் கண்டுபிடித்து மிகவும் வருத்தப்பட வேண்டும்.

OSD ஐ வரிசையாக உயர்த்துவதில் சிரமம்

எடுத்துக்காட்டு: OOM இல் OSD விழுகிறது, மறு சமநிலை தொடங்குகிறது, அதன் பிறகு பின்வருபவை விழும்.

தீர்வு: OSD ஐ ஒரு நேரத்தில் உயர்த்தவும், அது முழுமையாக கிளஸ்டரில் சேர்க்கப்படும் வரை காத்திருந்து அடுத்தவற்றை உயர்த்தவும். (செஃப் அறிக்கையில் மேலும் விவரங்கள். பேரழிவின் உடற்கூறியல்).

ஒரு baremetal நிறுவலின் விஷயத்தில், இது வெறுமனே கையால் செய்யப்படுகிறது; ரூக் மற்றும் ஒரு முனைக்கு ஒரு OSD விஷயத்தில், குறிப்பிட்ட சிக்கல்கள் எதுவும் இல்லை; OSD> 1 ஒரு முனையில் இருந்தால், மாற்று தூக்குவதில் சிக்கல்கள் எழும்.

நிச்சயமாக, அவை தீர்க்கப்படலாம், ஆனால் விஷயங்களை எளிமைப்படுத்த ரூக்கைப் பயன்படுத்துகிறோம், ஆனால் மிகவும் சிக்கலானதாக இருக்கும்.

செஃப் பேய்களுக்கான வரம்புகளைத் தேர்ந்தெடுப்பதில் சிரமம்

ceph இன் ஒரு baremetal நிறுவலுக்கு, ஒரு கிளஸ்டருக்கு தேவையான ஆதாரங்களைக் கணக்கிடுவது மிகவும் எளிதானது - சூத்திரங்கள் உள்ளன மற்றும் ஆராய்ச்சி கிடைக்கிறது. நீங்கள் பலவீனமான CPU ஐப் பயன்படுத்துகிறீர்கள் என்றால், Numa என்றால் என்ன என்பதைக் கண்டறிய நீங்கள் இன்னும் சில செயல்திறன் சோதனைகளை இயக்க வேண்டும், ஆனால் ரூக்கை விட இது இன்னும் எளிதானது.

ரூக்கின் விஷயத்தில், கணக்கிடக்கூடிய நினைவக வரம்புகளுக்கு கூடுதலாக, CPU வரம்பை அமைக்கும் கேள்வி உங்களுக்கு உள்ளது.

இங்கே நீங்கள் செயல்திறன் சோதனைகளுடன் கடினமாக உழைக்க வேண்டும். நீங்கள் வரம்புகளைக் குறைத்தால், மெதுவான கிளஸ்டரைப் பெறுவீர்கள்; நீங்கள் அன்லிம் அமைத்தால், மறுசீரமைப்பின் போது செயலில் உள்ள CPU பயன்பாட்டைப் பெறுவீர்கள், இது kubernetes இல் உள்ள உங்கள் பயன்பாடுகளில் மோசமான விளைவை ஏற்படுத்தும்.

நெட்வொர்க்கிங் சிக்கல்கள் v1

ceph க்கு 2x10GB நெட்வொர்க்கைப் பயன்படுத்த பரிந்துரைக்கப்படுகிறது. ஒன்று வாடிக்கையாளர் போக்குவரத்திற்கு, மற்றொன்று ceph சேவை தேவைகளுக்கு (மறு சமநிலை). நீங்கள் baremetal இல் ceph உடன் வாழ்ந்தால், இந்த பிரிவு எளிதில் கட்டமைக்கப்படும், நீங்கள் Rook உடன் வாழ்ந்தால், நெட்வொர்க்குகள் மூலம் பிரிப்பது உங்களுக்கு சிக்கல்களை ஏற்படுத்தும், ஏனெனில் ஒவ்வொரு கிளஸ்டர் கட்டமைப்பும் இரண்டு வெவ்வேறு நெட்வொர்க்குகளை நெற்றுக்கு வழங்க உங்களை அனுமதிக்காது. .

நெட்வொர்க்கிங் சிக்கல்கள் v2

நெட்வொர்க்குகளைப் பிரிக்க நீங்கள் மறுத்தால், மறுசீரமைக்கும்போது, ​​செஃப் டிராஃபிக் முழு சேனலையும் அடைத்துவிடும் மற்றும் குபெர்னெட்ஸில் உள்ள உங்கள் பயன்பாடுகள் மெதுவாக அல்லது செயலிழக்கும். நீங்கள் ceph மறுசீரமைப்பின் வேகத்தைக் குறைக்கலாம், ஆனால் நீண்ட மறுசீரமைப்பின் காரணமாக, டிஸ்க்குகள் அல்லது OOM வழியாக கிளஸ்டரிலிருந்து வெளியேறும் இரண்டாவது முனையின் அபாயத்தை நீங்கள் பெறுவீர்கள், மேலும் கிளஸ்டருக்கு மட்டும் படிக்கும் உத்தரவாதம் ஏற்கனவே உள்ளது.

நீண்ட மறு சமநிலை - நீண்ட பயன்பாடு தாமதம்

Ceph இன் இடுகையிலிருந்து மேற்கோள். ஒரு பேரழிவின் உடற்கூறியல்.

சோதனை கிளஸ்டர் செயல்திறன்:

4 KB அளவுள்ள ஒரு எழுதும் செயல்பாட்டிற்கு 1 ms ஆகும், செயல்திறன் 1000 த்ரெட்டில் 1 செயல்பாடுகள்/வினாடி ஆகும்.

4 எம்பி (பொருளின் அளவு) செயல்பாட்டிற்கு 22 எம்எஸ் ஆகும், செயல்திறன் 45 செயல்பாடுகள்/வினாடி ஆகும்.

இதன் விளைவாக, மூன்றில் ஒரு டொமைன் தோல்வியுற்றால், கிளஸ்டர் சிறிது நேரம் சிதைந்த நிலையில் உள்ளது, மேலும் சூடான பொருட்களில் பாதி வெவ்வேறு பதிப்புகளில் விநியோகிக்கப்படும், பின்னர் எழுதும் செயல்பாடுகளில் பாதி கட்டாய மீட்டெடுப்புடன் தொடங்கும்.

கட்டாய மீட்பு நேரத்தை தோராயமாக கணக்கிடுகிறோம் - சிதைந்த பொருளுக்கு செயல்பாடுகளை எழுதுங்கள்.

முதலில் நாம் 4 ms இல் 22 MB ஐப் படிக்கிறோம், 22 ms ஐ எழுதுகிறோம், பின்னர் 1 ms இல் 4 KB உண்மையான தரவை எழுதுகிறோம். ஒரு SSD இல் ஒரு சிதைந்த பொருளுக்கு எழுதும் செயல்பாட்டிற்கு மொத்தம் 45 ms, நிலையான செயல்திறன் 1 ms ஆக இருக்கும்போது - செயல்திறனில் 45 மடங்கு குறைவு.

நம்மிடம் உள்ள சிதைந்த பொருட்களின் சதவீதம் அதிகமாக இருந்தால், எல்லாம் மோசமாகிவிடும்.

கிளஸ்டரின் சரியான செயல்பாட்டிற்கு மறுசீரமைப்பின் வேகம் முக்கியமானது என்று மாறிவிடும்.

ceph க்கான குறிப்பிட்ட சர்வர் அமைப்புகள்

ceph க்கு குறிப்பிட்ட ஹோஸ்ட் டியூனிங் தேவைப்படலாம்.

எடுத்துக்காட்டு: sysctl அமைப்புகள் மற்றும் அதே ஜம்போஃப்ரேம், இந்த அமைப்புகளில் சில உங்கள் பேலோடை எதிர்மறையாக பாதிக்கலாம்.

ரூக்கின் உண்மையான தேவை கேள்விக்குறியாகவே உள்ளது

நீங்கள் கிளவுட்டில் இருந்தால், உங்கள் கிளவுட் வழங்குநரிடமிருந்து சேமிப்பிடம் உள்ளது, இது மிகவும் வசதியானது.

நீங்கள் உங்கள் சொந்த சேவையகங்களில் இருந்தால், ceph ஐ நிர்வகிப்பது kubernetes இல்லாமல் மிகவும் வசதியாக இருக்கும்.

குறைந்த கட்டண ஹோஸ்டிங்கிலிருந்து சர்வர்களை வாடகைக்கு எடுக்கிறீர்களா? நெட்வொர்க், அதன் தாமதங்கள் மற்றும் அலைவரிசையுடன் நீங்கள் மிகவும் வேடிக்கையாக இருப்பீர்கள், இது ceph ஐ தெளிவாக எதிர்மறையாக பாதிக்கிறது.

மொத்தம்: kuberentes ஐச் செயல்படுத்துவதும் சேமிப்பகத்தை செயல்படுத்துவதும் வெவ்வேறு உள்ளீடுகள் மற்றும் வெவ்வேறு தீர்வு விருப்பங்களைக் கொண்ட வெவ்வேறு பணிகளாகும் - அவற்றைக் கலப்பது என்பது ஒன்று அல்லது மற்றொன்றின் பொருட்டு அபாயகரமான வர்த்தகத்தை உருவாக்குவதாகும். வடிவமைப்பு கட்டத்தில் கூட இந்த தீர்வுகளை இணைப்பது மிகவும் கடினமாக இருக்கும், மேலும் செயல்பாட்டின் காலம் இன்னும் உள்ளது.

பயன்படுத்திய இலக்கியங்களின் பட்டியல்:

இடுகை #1 ஆனால் நீங்கள் செப் என்கிறீர்கள்... அவர் உண்மையில் நல்லவரா?
இடுகை #2 செஃப். ஒரு பேரழிவின் உடற்கூறியல்

ஆதாரம்: www.habr.com