GitLab எப்படி பெரிய NextCloud சேமிப்பகங்களை காப்புப் பிரதி எடுக்க உதவுகிறது

ஹே ஹப்ர்!

வெவ்வேறு கட்டமைப்புகளில் Nextcloud சேமிப்பகங்களிலிருந்து பெரிய தரவுகளின் காப்புப்பிரதியை தானியங்குபடுத்துவதில் எங்களின் அனுபவத்தைப் பற்றி இன்று நான் பேச விரும்புகிறேன். நான் மோல்னியா AK இல் ஒரு சேவை நிலையமாக பணிபுரிகிறேன், அங்கு நாங்கள் IT அமைப்புகளின் உள்ளமைவு மேலாண்மை செய்கிறோம்; Nextcloud தரவு சேமிப்பிற்காக பயன்படுத்தப்படுகிறது. பகிர்ந்தளிக்கப்பட்ட அமைப்புடன், பணிநீக்கத்துடன்.

நிறுவல்களின் அம்சங்களில் இருந்து எழும் சிக்கல்கள் நிறைய தரவு உள்ளது. Nextcloud வழங்கும் பதிப்பு, பணிநீக்கம், அகநிலை காரணங்கள் மற்றும் பல நகல்களை உருவாக்குகிறது.

முன்வரலாறு

Nextcloud ஐ நிர்வகிக்கும் போது, ​​பயனுள்ள காப்புப்பிரதியை ஒழுங்கமைப்பதில் சிக்கல் எழுகிறது, இது குறியாக்கம் செய்யப்பட வேண்டும், ஏனெனில் தரவு மதிப்புமிக்கது.

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

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

முதலில், உள்ளீட்டுத் தரவைப் பார்ப்போம். எங்களுக்கு வேண்டும்:

• ஒரு முனை அல்லது பலவற்றின் அடிப்படையில் அளவிடுதல். பெரிய நிறுவல்களுக்கு மினியோவை சேமிப்பகமாகப் பயன்படுத்துகிறோம்.
• காப்புப்பிரதிகளைச் செய்வதில் உள்ள சிக்கல்களைக் கண்டறியவும்.
• உங்கள் வாடிக்கையாளர்கள் மற்றும்/அல்லது எங்களுடன் காப்புப்பிரதியை வைத்திருக்க வேண்டும்.
• பிரச்சனைகளை விரைவாகவும் எளிதாகவும் சமாளிக்கவும்.
• வாடிக்கையாளர்கள் மற்றும் நிறுவல்கள் ஒருவருக்கொருவர் மிகவும் வேறுபட்டவை - சீரான தன்மையை அடைய முடியாது.
• இரண்டு காட்சிகளில் மீட்பு வேகம் குறைவாக இருக்க வேண்டும்: முழு மீட்பு (பேரழிவு), ஒரு கோப்புறை தவறுதலாக அழிக்கப்பட்டது.
• இரட்டிப்பு செயல்பாடு தேவை.

காப்புப்பிரதிகளை நிர்வகிப்பதற்கான சிக்கலைத் தீர்க்க, நாங்கள் GitLab ஐ நிறுவினோம். தடுப்பாட்டம் மூலம் மேலும் விவரங்கள்.

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

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

காப்பு கருவிகள்

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

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

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

காப்புப்பிரதிகளை நிர்வகித்தல்

போர்க் மற்றும் ரெஸ்டிக் நல்லது, ஆனால் எந்த தயாரிப்புக்கும் மையப்படுத்தப்பட்ட கட்டுப்பாட்டு வழிமுறை இல்லை. மேலாண்மை மற்றும் கட்டுப்பாட்டின் நோக்கத்திற்காக, நாங்கள் ஏற்கனவே செயல்படுத்திய ஒரு கருவியைத் தேர்ந்தெடுத்தோம், இது இல்லாமல் ஆட்டோமேஷன் உட்பட எங்கள் வேலையை கற்பனை செய்து பார்க்க முடியாது - இது நன்கு அறியப்பட்ட CI/CD - GitLab ஆகும்.

யோசனை பின்வருமாறு: நெக்ஸ்ட் கிளவுட் தரவைச் சேமிக்கும் ஒவ்வொரு முனையிலும் கிட்லாப்-ரன்னர் நிறுவப்பட்டுள்ளது. ரன்னர் காப்புப்பிரதி செயல்முறையை கண்காணிக்கும் அட்டவணையில் ஒரு ஸ்கிரிப்டை இயக்குகிறார், மேலும் அது போர்க் அல்லது ரெஸ்டிக்கைத் தொடங்குகிறது.

நமக்கு என்ன கிடைத்தது? செயல்பாட்டிலிருந்து கருத்து, மாற்றங்களின் மீது வசதியான கட்டுப்பாடு, பிழை ஏற்பட்டால் விவரங்கள்.

இங்கே இங்கே GitHub இல் பல்வேறு பணிகளுக்கான ஸ்கிரிப்ட்டின் எடுத்துக்காட்டுகளை நாங்கள் இடுகையிட்டோம், மேலும் அதை நெக்ஸ்ட்க்ளவுட் மட்டுமல்ல, பல சேவைகளின் காப்புப்பிரதியிலும் இணைத்தோம். நீங்கள் அதை கைமுறையாக உள்ளமைக்க விரும்பவில்லை என்றால் (நாங்கள் விரும்பவில்லை) மற்றும் .gitlab-ci.yml அங்கு ஒரு திட்டமிடல் உள்ளது.

கிட்லாப் ஏபிஐயில் சிஐ/சிடி காலக்கெடுவை மாற்ற இன்னும் வழி இல்லை, ஆனால் அது சிறியது. அதை அதிகரிக்க வேண்டும், சொல்லுங்கள் 1d.

GitLab, அதிர்ஷ்டவசமாக, ஒரு உறுதிப்பாட்டின் படி மட்டும் தொடங்க முடியாது, ஆனால் ஒரு அட்டவணையின்படி மட்டுமே, இது நமக்குத் தேவையானது.

இப்போது ரேப்பர் ஸ்கிரிப்ட் பற்றி.

இந்த ஸ்கிரிப்ட்டுக்கு பின்வரும் நிபந்தனைகளை அமைத்துள்ளோம்:

• இது ரன்னர் மூலமாகவும் கன்சோலில் இருந்து ஒரே செயல்பாட்டுடன் கைமுறையாகவும் தொடங்கப்பட வேண்டும்.
• பிழை கையாளுபவர்கள் இருக்க வேண்டும்:
• திரும்ப குறியீடு.
• பதிவில் ஒரு சரத்தைத் தேடவும். எடுத்துக்காட்டாக, எங்களைப் பொறுத்தவரை, பிழை என்பது நிரல் ஆபத்தானதாகக் கருதாத செய்தியாக இருக்கலாம்.
• செயலாக்க நேரம் முடிந்தது. முன்னணி நேரம் நியாயமானதாக இருக்க வேண்டும்.
• எங்களுக்கு மிகவும் விரிவான பதிவு தேவை. ஆனால் பிழை ஏற்பட்டால் மட்டுமே.
• தொடங்குவதற்கு முன் பல சோதனைகளும் மேற்கொள்ளப்படுகின்றன.
• ஆதரவு செயல்பாட்டின் போது எங்களுக்கு பயனுள்ளதாக இருக்கும் வசதிக்காக சிறிய போனஸ்கள்:
• தொடக்கம் மற்றும் முடிவு உள்ளூர் இயந்திரத்தின் syslog இல் பதிவு செய்யப்பட்டுள்ளது. இது கணினி பிழைகள் மற்றும் காப்புப்பிரதி செயல்பாட்டை இணைக்க உதவுகிறது.
• பிழை பதிவின் ஒரு பகுதி, ஏதேனும் இருந்தால், stdout க்கு வெளியீடாக இருந்தால், முழு பதிவும் ஒரு தனி கோப்பில் எழுதப்படும். அற்பமானதாக இருந்தால் உடனடியாக CI ஐப் பார்த்து பிழையை மதிப்பிடுவது வசதியானது.
• பிழைத்திருத்த முறைகள்.

முழு பதிவும் GitLab இல் ஒரு கலைப்பொருளாக சேமிக்கப்படுகிறது; பிழை இல்லை என்றால், பதிவு நீக்கப்படும். ஸ்கிரிப்டை பாஷில் எழுதுகிறோம்.

திறந்த மூலத்தைப் பற்றிய ஏதேனும் பரிந்துரைகள் மற்றும் கருத்துகளைக் கருத்தில் கொள்வதில் நாங்கள் மகிழ்ச்சியடைவோம் - வரவேற்கிறோம்.

இது எப்படி வேலை செய்கிறது

பேஷ் எக்ஸிகியூட்டருடன் ஒரு ரன்னர் காப்பு முனையில் தொடங்கப்பட்டது. திட்டமிடுபவர் படி, வேலை CI/CD ஒரு சிறப்பு டர்னிப்பில் தொடங்கப்பட்டது. ரன்னர் அத்தகைய பணிகளுக்கு உலகளாவிய ரேப்பர் ஸ்கிரிப்டைத் தொடங்குகிறார், இது காப்புக் களஞ்சியத்தின் செல்லுபடியாகும், மவுண்ட் பாயிண்ட்கள் மற்றும் நாம் விரும்பும் அனைத்தையும் சரிபார்க்கிறது, பின்னர் காப்புப் பிரதி எடுத்து பழையதை சுத்தம் செய்கிறது. முடிக்கப்பட்ட காப்புப்பிரதியே S3க்கு அனுப்பப்படும்.

இந்த திட்டத்தின் படி நாங்கள் வேலை செய்கிறோம் - இது வெளிப்புற AWS வழங்குநர் அல்லது ரஷ்ய சமமானதாகும் (இது வேகமானது மற்றும் தரவு ரஷ்ய கூட்டமைப்பை விட்டு வெளியேறாது). அல்லது இந்த நோக்கங்களுக்காக வாடிக்கையாளருக்கான தனி மினியோ கிளஸ்டரை அவரது தளத்தில் நிறுவுகிறோம். பாதுகாப்பு காரணங்களுக்காக நாங்கள் வழக்கமாக இதைச் செய்கிறோம், கிளையன்ட் தரவு தங்கள் சர்க்யூட்டில் இருந்து வெளியேறுவதை விரும்பவில்லை.

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

உங்கள் உள்ளூர் இயந்திரத்தை ஹேக்கரிடமிருந்து பாதுகாக்க, அவர் S3 இல் உள்ள தரவை அழிக்க முடியும் என்பதால், நீங்கள் பதிப்பை இயக்க வேண்டும்.
காப்புப்பிரதி எப்போதும் காப்புப்பிரதியை குறியாக்குகிறது.

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

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

ரஷ்ய மொழியில் ரீட்மீ

முக்கிய செயல்பாடுகள்

• prepare பயிற்சி
• testcheck தயார்நிலை சரிபார்ப்பு
• maincommand முக்கிய குழு
• forcepostscript இறுதியில் அல்லது பிழையால் செயல்படுத்தப்படும் ஒரு செயல்பாடு. பகிர்வை அவிழ்க்க இதைப் பயன்படுத்துகிறோம்.

சேவை செயல்பாடுகள்

• cleanup நாங்கள் பிழைகளை பதிவு செய்கிறோம் அல்லது பதிவு கோப்பை அழிக்கிறோம்.
• checklog பிழையுடன் ஒரு வரி ஏற்பட்டதற்கான பதிவை அலசவும்.
• ret வெளியேறும் கையாள்.
• checktimeout காலக்கெடுவை சரிபார்க்கவும்.

சுற்றுச்சூழல்

• VERBOSE=1 பிழைகளை உடனடியாக திரையில் காண்பிக்கிறோம் (stdout).
• SAVELOGSONSUCCES=1 வெற்றியின் மீது பதிவை சேமிக்கவும்.
• INIT_REPO_IF_NOT_EXIST=1 அது இல்லை என்றால் ஒரு களஞ்சியத்தை உருவாக்கவும். இயல்பாகவே முடக்கப்பட்டது.
• TIMEOUT முக்கிய செயல்பாட்டிற்கான அதிகபட்ச நேரம். இறுதியில் 'm', 'h' அல்லது 'd' என அமைக்கலாம்.

பழைய நகல்களுக்கான சேமிப்பு முறை. இயல்புநிலை:

• KEEP_DAILY=7
• KEEP_WEEKLY=4
• KEEP_MONTHLY=6

ஸ்கிரிப்ட்டின் உள்ளே மாறிகள்

• ERROR_STRING - பிழைக்கான சரிபார்ப்பு பதிவிற்கான சரம்.
• EXTRACT_ERROR_STRING — பிழை என்றால் ஷோ ஸ்ட்ரிங்க்கான வெளிப்பாடு.
• KILL_TIMEOUT_SIGNAL - நேரம் முடிந்தால் கொலை செய்வதற்கான சமிக்ஞை.
• TAIL - திரையில் எத்தனை சரங்கள் பிழைகள் உள்ளன.
• COLORMSG - செய்தியின் நிறம் (இயல்புநிலை மஞ்சள்).

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

ரெஸ்டிக் எதிராக போர்க்

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

எங்களின் தேர்வு அளவுகோல்கள், ஏற்கனவே குறிப்பிட்டுள்ளதைத் தவிர (குறைப்பு, விரைவான மீட்பு போன்றவை):

• முடிக்கப்படாத வேலைக்கு எதிர்ப்பு. கொலை -9 சரிபார்க்கவும்.
• வட்டில் அளவு.
• ஆதாரங்களுக்கான தேவை (CPU, நினைவகம்).
• சேமிக்கப்பட்ட குமிழ்களின் அளவு.
• S3 உடன் பணிபுரிகிறது.
• நேர்மை சோதனை.

சோதனைக்காக, உண்மையான தரவு மற்றும் மொத்த அளவு 1,6 TB கொண்ட ஒரு கிளையண்டை எடுத்தோம்.
நிபந்தனைகள்.

S3 உடன் நேரடியாக வேலை செய்வது எப்படி என்று போர்க்கிற்குத் தெரியாது, மேலும் வட்டை ஒரு உருகியாக ஏற்றினோம் முட்டாள்கள். ரெஸ்டிக் அதை S3 க்கு அனுப்பியது.

Goofys மிக விரைவாகவும் நன்றாகவும் வேலை செய்கிறது, மற்றும் உள்ளன வட்டு கேச் தொகுதி, இது வேலையை இன்னும் வேகப்படுத்துகிறது. இது பீட்டா கட்டத்தில் உள்ளது, வெளிப்படையாகச் சொன்னால், சோதனைகளின் போது (மற்றவை) தரவு இழப்புடன் செயலிழந்தோம். ஆனால் வசதி என்னவென்றால், காப்புப்பிரதி செயல்முறைக்கு அதிக வாசிப்பு தேவையில்லை, ஆனால் பெரும்பாலும் எழுதுவது, எனவே ஒருமைப்பாடு சரிபார்ப்புகளின் போது மட்டுமே தற்காலிக சேமிப்பைப் பயன்படுத்துகிறோம்.

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

ஒப்பீட்டு சோதனை முடிவுகள்.

• கில் -9 மேலும் மறுதொடக்கம் இரண்டும் வெற்றி பெற்றன.
• வட்டில் அளவு. போர்க் சுருக்க முடியும், எனவே முடிவுகள் எதிர்பார்த்தபடி இருக்கும்.

பேக்கப்பர்
அளவு

போர்க்
562Gb

ரெஸ்டிக்
628Gb

• CPU மூலம்
  போர்க், இயல்புநிலை சுருக்கத்துடன் சிறிதளவு பயன்படுத்துகிறது, ஆனால் அது முட்டாள்தனமான செயல்முறையுடன் ஒன்றாக மதிப்பீடு செய்யப்பட வேண்டும். மொத்தத்தில், அவை ஒப்பிடக்கூடியவை மற்றும் அதே சோதனை மெய்நிகர் கணினியில் சுமார் 1,2 கோர்களைப் பயன்படுத்துகின்றன.
• நினைவு. Restic தோராயமாக 0,5GB, போர்க் தோராயமாக 200MB. ஆனால் கணினி கோப்பு தற்காலிக சேமிப்புடன் ஒப்பிடும்போது இவை அனைத்தும் முக்கியமற்றவை. எனவே அதிக நினைவகத்தை ஒதுக்குவது நல்லது.
• குமிழ் அளவு வித்தியாசம் வேலைநிறுத்தம்.

பேக்கப்பர்
அளவு

போர்க்
சுமார் 500MB

ரெஸ்டிக்
சுமார் 5MB

• ரெஸ்டிக்கின் S3 அனுபவம் சிறப்பாக உள்ளது. கூஃபிஸ் மூலம் போர்க் உடன் பணிபுரிவது எந்த கேள்வியையும் எழுப்பாது, ஆனால் தற்காலிக சேமிப்பை முழுமையாக மீட்டமைக்க காப்புப்பிரதி முடிந்ததும் umount செய்வது நல்லது என்று குறிப்பிடப்பட்டுள்ளது. S3 இன் தனித்தன்மை என்னவென்றால், கீழ்-பம்ப் செய்யப்பட்ட துண்டுகள் ஒருபோதும் வாளிக்கு அனுப்பப்படாது, அதாவது முழுமையடையாமல் நிரப்பப்பட்ட தரவு பெரிய சேதத்திற்கு வழிவகுக்கிறது.
• ஒருமைப்பாடு சரிபார்ப்பு இரண்டு சந்தர்ப்பங்களிலும் நன்றாக வேலை செய்கிறது, ஆனால் வேகம் கணிசமாக வேறுபடுகிறது.
  ரெஸ்டிக் 8 மணிநேரம்.
  போர்க், 100GB SSD கோப்பு தற்காலிக சேமிப்புடன் – 8 மணிநேரம்.உள்ளூர் வட்டில் தரவு இருந்தால் தோராயமாக அதே வேகம் கிடைக்கும்.
  போர்க் தற்காலிக சேமிப்பு இல்லாமல் S3 இலிருந்து நேரடியாகப் படிக்கிறார் 8 மணிநேரம். ஒரு பயங்கரமான நீண்ட காலம்.

இதன் முக்கிய அம்சம் என்னவென்றால், போர்க் சுருக்கக்கூடியது மற்றும் பெரிய குமிழ்களைக் கொண்டுள்ளது - இது S3 இல் சேமிப்பு மற்றும் GET/PUT செயல்பாடுகளை மலிவானதாக்குகிறது. ஆனால் இது மிகவும் சிக்கலான மற்றும் மெதுவான சரிபார்ப்பு செலவில் வருகிறது. மீட்பு வேகத்தைப் பொறுத்தவரை, நாங்கள் எந்த வித்தியாசத்தையும் கவனிக்கவில்லை. ரெஸ்டிக் அடுத்தடுத்த காப்புப்பிரதிகளை (முதலில் பிறகு) சிறிது நேரம் எடுக்கும், ஆனால் குறிப்பிடத்தக்கதாக இல்லை.

கடைசியாக ஆனால் தேர்வில் குறைந்தது அல்ல சமூகத்தின் அளவு.

நாங்கள் போர்க்கைத் தேர்ந்தெடுத்தோம்.

சுருக்கத்தைப் பற்றி சில வார்த்தைகள்

போர்க் அதன் ஆயுதக் களஞ்சியத்தில் ஒரு சிறந்த புதிய சுருக்க அல்காரிதம் உள்ளது - zstd. சுருக்க தரம் gzip ஐ விட மோசமாக இல்லை, ஆனால் மிக வேகமாக உள்ளது. மற்றும் இயல்புநிலை lz4 உடன் வேகத்தில் ஒப்பிடலாம்.

எடுத்துக்காட்டாக, ஒரு MySQL தரவுத்தள டம்ப் அதே வேகத்தில் lz4 ஐ விட இரண்டு மடங்கு சிறப்பாக சுருக்கப்படுகிறது. இருப்பினும், உண்மையான தரவுடனான அனுபவம், Nextcloud முனையின் சுருக்க விகிதத்தில் மிகக் குறைந்த வித்தியாசம் இருப்பதைக் காட்டுகிறது.

போர்கிற்கு போனஸ் சுருக்க முறை உள்ளது - கோப்பில் அதிக என்ட்ரோபி இருந்தால், சுருக்கம் பயன்படுத்தப்படாது, இது வேகத்தை அதிகரிக்கிறது. உருவாக்கும் போது விருப்பத்தால் இயக்கப்பட்டது
-C auto,zstd
zstd அல்காரிதத்திற்கு
எனவே இந்த விருப்பத்துடன், இயல்புநிலை சுருக்கத்துடன் ஒப்பிடுகையில், எங்களுக்கு கிடைத்தது
முறையே 560ஜிபி மற்றும் 562ஜிபி. மேலே உள்ள எடுத்துக்காட்டில் உள்ள தரவு, சுருக்கம் இல்லாமல் 628Gb ஆகும். 2 ஜிபி வித்தியாசத்தின் முடிவு எங்களை ஆச்சரியப்படுத்தியது, ஆனால் நாங்கள் அதைத் தேர்ந்தெடுப்போம் என்று நினைத்தோம். auto,zstd.

காப்பு சரிபார்ப்பு முறை

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

goofys --cache "--free:5%:/mnt/cache" -o allow_other --endpoint https://storage.yandexcloud.net --file-mode=0666 --dir-mode=0777 xxxxxxx.com /mnt/goofys
export BORG_PASSCOMMAND="cat /home/borg/.borg-passphrase"
borg list /mnt/goofys/borg1/
borg check --debug -p --verify-data /mnt/goofys/borg1/

அதே திட்டத்தைப் பயன்படுத்தி, வைரஸ் தடுப்பு மூலம் கோப்புகளைச் சரிபார்க்கிறோம் (உண்மைக்குப் பிறகு). எல்லாவற்றிற்கும் மேலாக, பயனர்கள் வெவ்வேறு விஷயங்களை Nextcloud இல் பதிவேற்றுகிறார்கள், அனைவருக்கும் வைரஸ் தடுப்பு இல்லை. கொட்டும் நேரத்தில் ஆய்வுகளை நடத்துவது அதிக நேரம் எடுக்கும் மற்றும் வணிகத்தில் தலையிடுகிறது.

வெவ்வேறு குறிச்சொற்களுடன் வெவ்வேறு முனைகளில் ரன்னர்களை இயக்குவதன் மூலம் அளவிடுதல் அடையப்படுகிறது.
எங்கள் கண்காணிப்பு GitLab API வழியாக காப்புப் பிரதி நிலைகளை ஒரு சாளரத்தில் சேகரிக்கிறது; தேவைப்பட்டால், சிக்கல்கள் எளிதில் கவனிக்கப்பட்டு, எளிதாக உள்ளூர்மயமாக்கப்படும்.

முடிவுக்கு

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

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