கடந்த ஆண்டு இறுதியில், ரஷ்ய PostgreSQL சமூகத்தின் மற்றொரு நேரடி ஒளிபரப்பு நடந்தது , அதன் இணை நிறுவனர் Nikolai Samokhvalov குபெர்னெட்டஸின் சூழலில் இந்த DBMS பற்றி Flant தொழில்நுட்ப இயக்குனர் Dmitry Stolyarov உடன் பேசினார்.
இந்த விவாதத்தின் முக்கிய பகுதியின் டிரான்ஸ்கிரிப்டை நாங்கள் வெளியிடுகிறோம் முழு வீடியோ வெளியிடப்பட்டது:
தரவுத்தளங்கள் மற்றும் குபெர்னெட்ஸ்
НС: இன்று வெற்றிடம் மற்றும் செக்பாயின்ட்களைப் பற்றி பேச மாட்டோம். நாங்கள் குபெர்னெட்டஸைப் பற்றி பேச விரும்புகிறோம். உங்களுக்கு பல வருட அனுபவம் இருப்பதாக எனக்குத் தெரியும். நான் உங்கள் வீடியோக்களைப் பார்த்தேன், அவற்றில் சிலவற்றை மீண்டும் பார்த்தேன்... நேராக விஷயத்திற்கு வருவோம்: K8s இல் Postgres அல்லது MySQL ஏன்?
டி.எஸ்: இந்த கேள்விக்கு திட்டவட்டமான பதில் இல்லை மற்றும் இருக்க முடியாது. ஆனால் பொதுவாக, இது எளிமை மற்றும் வசதி... சாத்தியம். எல்லோரும் நிர்வகிக்கப்பட்ட சேவைகளை விரும்புகிறார்கள்.
НС: எப்படி , வீட்டில் மட்டுமா?
டி.எஸ்: ஆம்: RDS போன்று, எங்கும்.
НС: "எங்கேயும்" ஒரு நல்ல புள்ளி. பெரிய நிறுவனங்களில், அனைத்தும் வெவ்வேறு இடங்களில் அமைந்துள்ளன. அது ஏன் பெரிய நிறுவனமாக இருந்தால் ரெடிமேட் தீர்வை எடுக்கக் கூடாது? எடுத்துக்காட்டாக, Nutanix அதன் சொந்த வளர்ச்சிகளைக் கொண்டுள்ளது, மற்ற நிறுவனங்கள் (VMware...) அதே "RDS, வீட்டில் மட்டும்" உள்ளன.
டி.எஸ்: ஆனால் சில நிபந்தனைகளின் கீழ் மட்டுமே செயல்படும் ஒரு தனி செயலாக்கத்தைப் பற்றி நாங்கள் பேசுகிறோம். நாம் குபெர்னெட்ஸைப் பற்றி பேசுகிறோம் என்றால், பலவிதமான உள்கட்டமைப்பு உள்ளது (அது K8 களில் இருக்கலாம்). முக்கியமாக இது கிளவுட் வரையிலான APIகளுக்கான தரநிலையாகும்...
НС: இதுவும் இலவசம்!
டி.எஸ்: இது அவ்வளவு முக்கியமில்லை. சந்தையின் மிகப் பெரிய பிரிவினருக்கு சுதந்திரம் முக்கியம். இன்னொன்று முக்கியமானது... ஒருவேளை உங்களுக்கு அந்த அறிக்கை நினைவிருக்கலாம்."?
НС: ஆம்.
டி.எஸ்: இது மிகவும் தெளிவற்ற முறையில் பெறப்பட்டது என்பதை உணர்ந்தேன். சிலர் நான் சொல்கிறேன் என்று நினைத்தார்கள்: "நண்பர்களே, எல்லா தரவுத்தளங்களையும் குபெர்னெட்டஸில் பெறுவோம்!", மற்றவர்கள் இவை அனைத்தும் பயங்கரமான சைக்கிள்கள் என்று முடிவு செய்தனர். ஆனால் நான் முற்றிலும் மாறுபட்ட ஒன்றைச் சொல்ல விரும்பினேன்: “என்ன நடக்கிறது, என்னென்ன பிரச்சனைகள் உள்ளன, அவற்றை எவ்வாறு தீர்க்கலாம் என்பதைப் பாருங்கள். நாம் இப்போது Kubernetes தரவுத்தளங்களைப் பயன்படுத்த வேண்டுமா? உற்பத்தியா? சரி, நீங்கள் விரும்பினால் மட்டும்... சில விஷயங்களைச் செய்யுங்கள். ஆனால் ஒரு டெவலருக்கு, நான் அதை பரிந்துரைக்கிறேன் என்று சொல்ல முடியும். ஒரு டெவலைப் பொறுத்தவரை, சூழல்களை உருவாக்குவது/நீக்குவது மிகவும் முக்கியமானது."
NS: தேவ் மூலம், நீங்கள் ப்ராடட் இல்லாத அனைத்து சூழல்களையும் குறிக்கிறீர்களா? ஸ்டேஜிங், QA…
டி.எஸ்: நாம் பெர்ஃப் ஸ்டாண்டுகளைப் பற்றி பேசுகிறோம் என்றால், ஒருவேளை இல்லை, ஏனெனில் தேவைகள் குறிப்பிட்டவை. ஸ்டேஜிங்கிற்கு மிகப் பெரிய தரவுத்தளம் தேவைப்படும் சிறப்பு நிகழ்வுகளைப் பற்றி நாம் பேசினால், ஒருவேளை இல்லை... இது நிலையான, நீண்ட கால சூழல் என்றால், K8s இல் தரவுத்தளத்தை வைத்திருப்பதால் என்ன நன்மை?
НС: இல்லை. ஆனால் நிலையான சூழல்களை நாம் எங்கே பார்க்கிறோம்? நிலையான சூழல் நாளை வழக்கற்றுப் போகும்.
டி.எஸ்: ஸ்டேஜிங் நிலையானதாக இருக்கலாம். எங்களிடம் வாடிக்கையாளர்கள் உள்ளனர்...
НС: ஆம், என்னிடம் ஒன்று உள்ளது. உங்களிடம் 10 டிபி டேட்டாபேஸ் மற்றும் 200 ஜிபி ஸ்டேஜிங் இருந்தால் அது பெரிய பிரச்சனை...
டி.எஸ்: எனக்கு மிகவும் அருமையான வழக்கு உள்ளது! மேடையில் ஒரு தயாரிப்பு தரவுத்தளம் உள்ளது, அதில் மாற்றங்கள் செய்யப்படுகின்றன. மற்றும் ஒரு பொத்தான் உள்ளது: "உற்பத்திக்கு உருட்டவும்". இந்த மாற்றங்கள் - டெல்டாக்கள் - உற்பத்தியில் சேர்க்கப்படுகின்றன (அவை வெறுமனே API வழியாக ஒத்திசைக்கப்பட்டதாகத் தெரிகிறது). இது மிகவும் கவர்ச்சியான விருப்பம்.
НС: பள்ளத்தாக்கில் RDS அல்லது Heroku இல் கூட அமர்ந்திருக்கும் ஸ்டார்ட்அப்களை நான் பார்த்திருக்கிறேன் - இவை 2-3 வருடங்களுக்கு முன்பிருந்த கதைகள் - மற்றும் அவர்கள் டம்பை தங்கள் லேப்டாப்பில் பதிவிறக்கம் செய்கிறார்கள். ஏனெனில் தரவுத்தளம் இன்னும் 80 ஜிபி மட்டுமே, மடிக்கணினியில் இடம் உள்ளது. பின்னர் அவர்கள் அனைவருக்கும் கூடுதல் வட்டுகளை வாங்குகிறார்கள், இதனால் வெவ்வேறு மேம்பாடுகளைச் செய்ய 3 தரவுத்தளங்கள் உள்ளன. இதுவும் இப்படித்தான் நடக்கும். தயாரிப்பை மேடையில் நகலெடுக்க அவர்கள் பயப்படவில்லை என்பதையும் நான் கண்டேன் - இது நிறுவனத்தைப் பொறுத்தது. ஆனால் அவர்கள் மிகவும் பயப்படுவதையும், அவர்களுக்கு அடிக்கடி போதுமான நேரமும் கைகளும் இல்லை என்பதையும் நான் பார்த்தேன். ஆனால் இந்த தலைப்புக்கு செல்வதற்கு முன், நான் குபெர்னெட்டஸைப் பற்றி கேட்க விரும்புகிறேன். இன்னும் யாரும் முன்வரவில்லை என்பதை நான் சரியாகப் புரிந்துகொள்கிறேனா?
டி.எஸ்: எங்களிடம் சிறிய தரவுத்தளங்கள் உள்ளன. நாங்கள் பல்லாயிரக்கணக்கான ஜிகாபைட்கள் மற்றும் முக்கியமான சேவைகளைப் பற்றி பேசுகிறோம், அதற்கான பிரதிகளை உருவாக்க நாங்கள் மிகவும் சோம்பேறியாக இருந்தோம் (மற்றும் அத்தகைய தேவை இல்லை). குபெர்னெட்டஸின் கீழ் சாதாரண சேமிப்பு உள்ளது. இந்த தரவுத்தளம் ஒரு மெய்நிகர் கணினியில் வேலை செய்தது - நிபந்தனையுடன் VMware இல், சேமிப்பக அமைப்பின் மேல். நாங்கள் அதை வைத்தோம் இப்போது நாம் அதை இயந்திரத்திலிருந்து இயந்திரத்திற்கு மாற்றலாம்.
НС: இந்த அளவிலான தரவுத்தளங்கள், 100 ஜிபி வரை, சில நிமிடங்களில் நல்ல வட்டுகள் மற்றும் நல்ல நெட்வொர்க்கில் உருட்டலாம், இல்லையா? வினாடிக்கு 1 ஜிபி வேகம் இனி கவர்ச்சியாக இருக்காது.
டி.எஸ்: ஆம், நேரியல் செயல்பாட்டிற்கு இது ஒரு பிரச்சனையல்ல.
НС: சரி, நாம் தயாரிப்பைப் பற்றி சிந்திக்க வேண்டும். நாம் குபெர்னெட்ஸை ப்ராட் அல்லாத சூழல்களுக்குக் கருத்தில் கொண்டால், நாம் என்ன செய்ய வேண்டும்? நான் அதை ஜலாண்டோவில் பார்க்கிறேன் , Crunchy இல் , வேறு சில விருப்பங்கள் உள்ளன. மற்றும் உள்ளது — это наш хороший знакомый Alvaro из Испании: они делают по сути не просто , மற்றும் முழு விநியோகம் (), அதில், போஸ்ட்கிரெஸுடன் கூடுதலாக, அவர்கள் ஒரு காப்புப்பிரதியை அடைக்கவும் முடிவு செய்தனர், என்வாய் ப்ராக்ஸி...
டி.எஸ்: எதற்கு தூதுவர்? குறிப்பாக Postgres போக்குவரத்தை சமநிலைப்படுத்தவா?
НС: ஆம். அதாவது, அவர்கள் அதை இவ்வாறு பார்க்கிறார்கள்: நீங்கள் லினக்ஸ் விநியோகம் மற்றும் கர்னலை எடுத்துக் கொண்டால், வழக்கமான PostgreSQL கர்னல் ஆகும், மேலும் அவர்கள் கிளவுட்-நட்பு மற்றும் குபெர்னெட்ஸில் இயங்கும் விநியோகத்தை உருவாக்க விரும்புகிறார்கள். அவர்கள் கூறுகளை (காப்புப்பிரதிகள், முதலியன) ஒன்றாக இணைத்து, அவை நன்றாக வேலை செய்யும் வகையில் பிழைத்திருத்தம் செய்கின்றன.
டி.எஸ்: மிகவும் அருமை! முக்கியமாக இது உங்களின் சொந்த நிர்வகிக்கப்படும் Postgres ஐ உருவாக்குவதற்கான மென்பொருள்.
НС: லினக்ஸ் விநியோகங்களில் நித்திய சிக்கல்கள் உள்ளன: அனைத்து வன்பொருளும் ஆதரிக்கப்படும் வகையில் இயக்கிகளை எவ்வாறு உருவாக்குவது. மேலும் அவர்கள் குபர்நெட்டஸில் வேலை செய்வார்கள் என்ற எண்ணம் அவர்களுக்கு இருக்கிறது. Zalando ஆபரேட்டரில் நாங்கள் சமீபத்தில் AWS உடனான இணைப்பைப் பார்த்தோம், இது இனி நன்றாக இல்லை என்பது எனக்குத் தெரியும். ஒரு குறிப்பிட்ட உள்கட்டமைப்புடன் ஒரு பிணைப்பு இருக்கக்கூடாது - பிறகு என்ன பயன்?
டி.எஸ்: ஜலாண்டோ எந்த சூழ்நிலையில் சிக்கினார் என்று எனக்கு சரியாகத் தெரியவில்லை, ஆனால் குபெர்னெட்டஸ் சேமிப்பகத்தில் இப்போது பொதுவான முறையைப் பயன்படுத்தி வட்டு காப்புப்பிரதி எடுக்க இயலாது. சமீபத்தில் தரநிலையில் - சமீபத்திய பதிப்பில் — நாங்கள் ஸ்னாப்ஷாட்களை சாத்தியமாக்கினோம், ஆனால் அது எங்கே செயல்படுத்தப்படுகிறது? சத்தியமா எல்லாமே இன்னும் raw தான்... AWS, GCE, Azure, vSphereனு மேலே CSI முயற்சி பண்ணிக்கிட்டு இருக்கோம், பயன்படுத்த ஆரம்பிச்சவுடனே அது இன்னும் ரெடி ஆகலைன்னு தெரியுது.
НС: அதனால்தான் நாம் சில நேரங்களில் உள்கட்டமைப்பை நம்பியிருக்க வேண்டியுள்ளது. இது இன்னும் ஆரம்ப நிலை என்று நான் நினைக்கிறேன் - வளரும் வலிகள். கேள்வி: K8s இல் PgSQL ஐ முயற்சிக்க விரும்பும் புதியவர்களுக்கு நீங்கள் என்ன ஆலோசனை வழங்குவீர்கள்? எந்த ஆபரேட்டர் இருக்கலாம்?
டி.எஸ்: பிரச்சனை என்னவென்றால், போஸ்ட்கிரெஸ் எங்களுக்கு 3% ஆகும். குபெர்னெட்ஸில் உள்ள பல்வேறு மென்பொருள்களின் மிகப் பெரிய பட்டியல் எங்களிடம் உள்ளது, நான் எல்லாவற்றையும் பட்டியலிட மாட்டேன். எடுத்துக்காட்டாக, மீள் தேடல். நிறைய ஆபரேட்டர்கள் உள்ளனர்: சிலர் தீவிரமாக வளர்ந்து வருகின்றனர், மற்றவர்கள் இல்லை. ஒரு ஆபரேட்டருக்கு என்ன இருக்க வேண்டும் என்பது பற்றி எங்களுக்கான தேவைகளை நாங்கள் வரைந்துள்ளோம். குபெர்னெட்டஸுக்கு குறிப்பாக ஒரு ஆபரேட்டரில் - "அமேசானின் நிலைமைகளில் ஏதாவது செய்ய ஆபரேட்டரில்" இல்லை... உண்மையில், நாங்கள் மிகவும் பரவலாக (= கிட்டத்தட்ட எல்லா வாடிக்கையாளர்களும்) ஒரு ஆபரேட்டரைப் பயன்படுத்துகிறோம் - (அவரைப் பற்றிய கட்டுரையை விரைவில் வெளியிடுவோம்).
НС: MySQL க்கும் இல்லையா? எனக்கு தெரியும் Percona... அவர்கள் இப்போது MySQL, MongoDB மற்றும் Postgres இல் பணிபுரிவதால், அவர்கள் ஒருவித உலகளாவிய தீர்வை உருவாக்க வேண்டும்: அனைத்து தரவுத்தளங்களுக்கும், அனைத்து கிளவுட் வழங்குநர்களுக்கும்.
டி.எஸ்: MySQLக்கான ஆபரேட்டர்களைப் பார்க்க எங்களுக்கு நேரம் இல்லை. இது இப்போது எங்கள் முக்கிய கவனம் அல்ல. MySQL தனித்தனியாக நன்றாக வேலை செய்கிறது. நீங்கள் ஒரு தரவுத்தளத்தை தொடங்கினால் ஏன் ஒரு ஆபரேட்டரைப் பயன்படுத்த வேண்டும்... நீங்கள் ஒரு Docker கொள்கலனை Postrges உடன் தொடங்கலாம் அல்லது நீங்கள் அதை எளிமையான முறையில் தொடங்கலாம்.
НС: இது குறித்தும் ஒரு கேள்வி எழுந்தது. ஆபரேட்டர் இல்லையா?
டி.எஸ்: ஆம், நம்மில் 100% PostgreSQL ஆபரேட்டர் இல்லாமல் இயங்குகிறது. இதுவரை. ப்ரோமிதியஸ் மற்றும் ரெடிஸிற்கான ஆபரேட்டரை நாங்கள் தீவிரமாகப் பயன்படுத்துகிறோம். எலாஸ்டிக் தேடலுக்கான ஆபரேட்டரைக் கண்டறியும் திட்டம் எங்களிடம் உள்ளது - இது மிகவும் "தீயில்" உள்ளது, ஏனெனில் 100% வழக்குகளில் குபெர்னெட்ஸில் இதை நிறுவ விரும்புகிறோம். MongoDB எப்போதும் Kubernetes இல் நிறுவப்பட்டிருப்பதை உறுதிசெய்ய விரும்புவது போல. இங்கே சில விருப்பங்கள் தோன்றும் - இந்த சந்தர்ப்பங்களில் ஏதாவது செய்ய முடியும் என்ற உணர்வு உள்ளது. நாங்கள் போஸ்ட்கிரெஸைப் பார்க்கவில்லை. நிச்சயமாக, வெவ்வேறு விருப்பங்கள் உள்ளன என்பதை நாங்கள் அறிவோம், ஆனால் உண்மையில் எங்களுக்கு ஒரு தனித்தன்மை உள்ளது.
குபெர்னெட்ஸில் சோதனைக்கு DB
НС: சோதனை என்ற தலைப்புக்கு செல்லலாம். தரவுத்தளத்தில் மாற்றங்களை எவ்வாறு உருவாக்குவது - DevOps கண்ணோட்டத்தில். மைக்ரோ சர்வீஸ்கள், பல தரவுத்தளங்கள் உள்ளன, எல்லா நேரத்திலும் எங்காவது ஏதாவது மாறிக்கொண்டே இருக்கிறது. DBMS கண்ணோட்டத்தில் எல்லாம் ஒழுங்காக இருக்கும் வகையில் சாதாரண CI/CD ஐ எவ்வாறு உறுதிப்படுத்துவது. உங்கள் அணுகுமுறை என்ன?
டி.எஸ்: ஒரே ஒரு பதில் இருக்க முடியாது. பல விருப்பங்கள் உள்ளன. முதலாவது நாம் உருட்ட விரும்பும் அடித்தளத்தின் அளவு. டெவ் மற்றும் மேடையில் தயாரிப்பு தரவுத்தளத்தின் நகலை வைத்திருப்பதில் நிறுவனங்கள் வெவ்வேறு அணுகுமுறைகளைக் கொண்டுள்ளன என்று நீங்களே குறிப்பிட்டுள்ளீர்கள்.
НС: மேலும் GDPR இன் நிபந்தனைகளின் கீழ், அவர்கள் மேலும் மேலும் கவனமாக இருக்கிறார்கள் என்று நான் நினைக்கிறேன்... ஐரோப்பாவில் அவர்கள் ஏற்கனவே அபராதம் விதிக்கத் தொடங்கியுள்ளனர் என்று நான் கூறலாம்.
டி.எஸ்: ஆனால் பெரும்பாலும் நீங்கள் தயாரிப்பிலிருந்து ஒரு குப்பையை எடுத்து அதை மழுங்கடிக்கும் மென்பொருளை எழுதலாம். தயாரிப்பு தரவு பெறப்பட்டது (ஸ்னாப்ஷாட், டம்ப், பைனரி நகல்...), ஆனால் அது அநாமதேயமாக உள்ளது. அதற்கு பதிலாக, தலைமுறை ஸ்கிரிப்டுகள் இருக்கலாம்: இவை சாதனங்கள் அல்லது ஒரு பெரிய தரவுத்தளத்தை உருவாக்கும் ஸ்கிரிப்டாக இருக்கலாம். பிரச்சனை: அடிப்படை படத்தை உருவாக்க எவ்வளவு நேரம் ஆகும்? விரும்பிய சூழலில் அதை வரிசைப்படுத்த எவ்வளவு நேரம் ஆகும்?
நாங்கள் ஒரு திட்டத்திற்கு வந்தோம்: கிளையண்டிடம் நிலையான தரவுத் தொகுப்பு (தரவுத்தளத்தின் குறைந்தபட்ச பதிப்பு) இருந்தால், அவற்றை முன்னிருப்பாகப் பயன்படுத்துவோம். நாங்கள் மறுஆய்வு சூழல்களைப் பற்றி பேசுகிறோம் என்றால், நாங்கள் ஒரு கிளையை உருவாக்கியபோது, பயன்பாட்டின் ஒரு உதாரணத்தை நாங்கள் பயன்படுத்தினோம் - நாங்கள் அங்கு ஒரு சிறிய தரவுத்தளத்தை உருவாக்குகிறோம். ஆனால் அது நன்றாக மாறியது , நாம் ஒரு நாளைக்கு ஒரு முறை (இரவில்) உற்பத்தியில் இருந்து ஒரு குப்பையை எடுத்து, அதன் அடிப்படையில் இந்த ஏற்றப்பட்ட தரவுகளுடன் PostgreSQL மற்றும் MySQL உடன் ஒரு டாக்கர் கொள்கலனை உருவாக்கும்போது. இந்த படத்திலிருந்து தரவுத்தளத்தை 50 முறை விரிவாக்க வேண்டும் என்றால், இது மிகவும் எளிமையாகவும் விரைவாகவும் செய்யப்படுகிறது.
НС: எளிய நகல் மூலம்?
டி.எஸ்: தரவு நேரடியாக டோக்கர் படத்தில் சேமிக்கப்படுகிறது. அந்த. எங்களிடம் 100 ஜிபி இருந்தாலும், ஆயத்தப் படம் உள்ளது. டோக்கரில் உள்ள லேயர்களுக்கு நன்றி, இந்தப் படத்தை நமக்குத் தேவையான பல முறை விரைவாகப் பயன்படுத்த முடியும். முறை முட்டாள்தனமானது, ஆனால் அது நன்றாக வேலை செய்கிறது.
НС: பிறகு, நீங்கள் சோதிக்கும் போது, அது டோக்கருக்குள்ளேயே மாறுகிறது, இல்லையா? டோக்கருக்குள் நகலெடுக்கவும் - அதைத் தூக்கி எறிந்துவிட்டு மீண்டும் செல்லவும், எல்லாம் நன்றாக இருக்கிறது. வர்க்கம்! நீங்கள் ஏற்கனவே அதை முழுமையாகப் பயன்படுத்துகிறீர்களா?
டி.எஸ்: நீண்ட காலமாக.
НС: நாங்கள் மிகவும் ஒத்த விஷயங்களைச் செய்கிறோம். நாங்கள் மட்டுமே டோக்கரின் நகல்-ஆன்-ரைட்டைப் பயன்படுத்துவதில்லை, ஆனால் வேறு சிலவற்றைப் பயன்படுத்துகிறோம்.
டி.எஸ்: இது பொதுவானது அல்ல. டோக்கர் எல்லா இடங்களிலும் வேலை செய்கிறார்.
НС: கோட்பாட்டில், ஆம். ஆனால் எங்களிடம் தொகுதிகள் உள்ளன, நீங்கள் வெவ்வேறு தொகுதிகளை உருவாக்கலாம் மற்றும் வெவ்வேறு கோப்பு முறைமைகளுடன் வேலை செய்யலாம். என்ன ஒரு கணம் இங்கே. போஸ்ட்கிரெஸ் பக்கத்தில் இருந்து, இதையெல்லாம் வித்தியாசமாகப் பார்க்கிறோம். இப்போது நான் டோக்கர் பக்கத்திலிருந்து பார்த்தேன், எல்லாம் உங்களுக்கு வேலை செய்கிறது. ஆனால் தரவுத்தளம் பெரியதாக இருந்தால், எடுத்துக்காட்டாக, 1 TB, பின்னர் இவை அனைத்தும் நீண்ட நேரம் எடுக்கும்: இரவில் செயல்பாடுகள் மற்றும் எல்லாவற்றையும் டோக்கரில் திணித்தல்... மேலும் 5 TB டோக்கரில் அடைக்கப்பட்டால்... அல்லது எல்லாம் சரியாக இருக்கிறதா?
டி.எஸ்: வித்தியாசம் என்ன: இவை குமிழ்கள், வெறும் பிட்கள் மற்றும் பைட்டுகள்.
НС: வித்தியாசம் இதுதான்: டம்ப் மற்றும் ரீஸ்டோர் மூலம் அதைச் செய்கிறீர்களா?
டி.எஸ்: தேவையே இல்லை. இந்த படத்தை உருவாக்குவதற்கான முறைகள் வேறுபட்டிருக்கலாம்.
НС: சில வாடிக்கையாளர்களுக்கு, ஒரு அடிப்படை படத்தை தொடர்ந்து உருவாக்குவதற்குப் பதிலாக, நாங்கள் அதை தொடர்ந்து புதுப்பித்த நிலையில் வைத்திருக்கிறோம். இது அடிப்படையில் ஒரு பிரதி, ஆனால் இது நேரடியாக மாஸ்டரிடமிருந்து தரவைப் பெறுவதில்லை, ஆனால் ஒரு காப்பகத்தின் மூலம். ஒவ்வொரு நாளும் WALகள் பதிவிறக்கம் செய்யப்படும் பைனரி காப்பகம், காப்புப்பிரதிகள் எடுக்கப்படும்... இந்த WALகள் சிறிது தாமதத்துடன் அடிப்படை படத்தை அடையும் (அதாவது 1-2 வினாடிகள்). அதிலிருந்து எந்த வகையிலும் குளோன் செய்கிறோம் - இப்போது எங்களிடம் இயல்பாக ZFS உள்ளது.
டி.எஸ்: ஆனால் ZFS உடன் நீங்கள் ஒரு முனைக்கு மட்டுப்படுத்தப்பட்டிருக்கிறீர்கள்.
НС: ஆம். ஆனால் ZFS லும் ஒரு மந்திரம் உள்ளது : இதன் மூலம் நீங்கள் ஒரு ஸ்னாப்ஷாட்டை அனுப்பலாம் மற்றும் (நான் இதை இன்னும் சோதிக்கவில்லை, ஆனால்...) இரண்டுக்கும் இடையே டெல்டாவை அனுப்பலாம். PGDATA. உண்மையில், இதுபோன்ற பணிகளுக்கு நாங்கள் கருத்தில் கொள்ளாத மற்றொரு கருவி எங்களிடம் உள்ளது. PostgreSQL உள்ளது , இது ஒரு "ஸ்மார்ட்" rsync போல வேலை செய்கிறது, நீங்கள் பார்க்க வேண்டிய பலவற்றை தவிர்க்கிறது, ஏனெனில் அங்கு எதுவும் மாறவில்லை. நாம் இரண்டு சேவையகங்களுக்கிடையில் விரைவான ஒத்திசைவைச் செய்யலாம் மற்றும் அதே வழியில் ரிவைண்ட் செய்யலாம்.
எனவே, இதிலிருந்து, மேலும் DBA பக்கத்திலிருந்து, நீங்கள் சொன்னதைச் செய்ய அனுமதிக்கும் ஒரு கருவியை உருவாக்க முயற்சிக்கிறோம்: எங்களிடம் ஒரு தரவுத்தளம் உள்ளது, ஆனால் நாங்கள் 50 முறை, கிட்டத்தட்ட ஒரே நேரத்தில் ஒன்றைச் சோதிக்க விரும்புகிறோம்.
டி.எஸ்: 50 முறை என்றால், நீங்கள் 50 ஸ்பாட் நிகழ்வுகளை ஆர்டர் செய்ய வேண்டும்.
НС: இல்லை, நாங்கள் அனைத்தையும் ஒரே இயந்திரத்தில் செய்கிறோம்.
டி.எஸ்: ஆனால், இந்த ஒரு தரவுத்தளமானது டெராபைட்டாக இருந்தால் எப்படி 50 மடங்கு விரிவடைவீர்கள். பெரும்பாலும் அவளுக்கு நிபந்தனைக்குட்பட்ட 256 ஜிபி ரேம் தேவையா?
НС: ஆமாம், சில நேரங்களில் உங்களுக்கு நிறைய நினைவகம் தேவை - அது சாதாரணமானது. ஆனால் இது வாழ்க்கையிலிருந்து ஒரு எடுத்துக்காட்டு. உற்பத்தி இயந்திரத்தில் 96 கோர்கள் மற்றும் 600 ஜிபி உள்ளது. அதே நேரத்தில், தரவுத்தளத்திற்கு 32 கோர்கள் (இப்போது சில நேரங்களில் 16 கோர்கள் கூட) மற்றும் 100-120 ஜிபி நினைவகம் பயன்படுத்தப்படுகின்றன.
டி.எஸ்: மற்றும் 50 பிரதிகள் அங்கு பொருந்துமா?
НС: எனவே ஒரே ஒரு நகல் உள்ளது, பின்னர் நகல்-ஆன்-ரைட் (ZFS) வேலை செய்கிறது... நான் உங்களுக்கு இன்னும் விரிவாகச் சொல்கிறேன்.
எடுத்துக்காட்டாக, எங்களிடம் 10 TB தரவுத்தளம் உள்ளது. அவர்கள் அதற்காக ஒரு வட்டை உருவாக்கினர், ZFS அதன் அளவை 30-40 சதவிகிதம் சுருக்கியது. சுமை சோதனையை நாங்கள் செய்யாததால், சரியான பதில் நேரம் எங்களுக்கு முக்கியமல்ல: இது 2 மடங்கு மெதுவாக இருக்கட்டும் - அது பரவாயில்லை.
புரோகிராமர்கள், QA, DBA போன்றவர்களுக்கு நாங்கள் வாய்ப்பளிக்கிறோம். 1-2 இழைகளில் சோதனை செய்யுங்கள். உதாரணமாக, அவர்கள் ஒருவித இடம்பெயர்வை இயக்கலாம். இதற்கு ஒரே நேரத்தில் 10 கோர்கள் தேவையில்லை - இதற்கு 1 Postgres பின்தளம், 1 கோர் தேவை. இடம்பெயர்வு தொடங்கும் - ஒருவேளை இன்னும் தொடங்கும், பின்னர் இரண்டாவது கோர் பயன்படுத்தப்படும். எங்களிடம் 16-32 கோர்கள் ஒதுக்கப்பட்டுள்ளன, எனவே 10 பேர் ஒரே நேரத்தில் வேலை செய்யலாம், எந்த பிரச்சனையும் இல்லை.
ஏனெனில் உடல் ரீதியாக PGDATA அதே, நாம் உண்மையில் Postgres ஏமாற்றுகிறோம் என்று மாறிவிடும். தந்திரம் இதுதான்: எடுத்துக்காட்டாக, 10 Postgres ஒரே நேரத்தில் தொடங்கப்பட்டது. பொதுவாக என்ன பிரச்சனை? அவர்கள் போட்டார்கள் , 25% என்று வைத்துக் கொள்வோம். அதன்படி, இது 200 ஜி.பி. இவற்றில் மூன்றிற்கு மேல் உங்களால் தொடங்க முடியாது, ஏனெனில் நினைவகம் தீர்ந்துவிடும்.
ஆனால் சில சமயங்களில் இது தேவையில்லை என்பதை நாங்கள் உணர்ந்தோம்: பகிர்ந்த_பஃபர்களை 2 ஜிபிக்கு அமைத்துள்ளோம். PostgreSQL உள்ளது , மற்றும் உண்மையில் அது மட்டுமே செல்வாக்கு செலுத்துகிறது . நாங்கள் அதை 0,5 TB ஆக அமைத்துள்ளோம். அவை உண்மையில் இல்லை என்பது கூட முக்கியமில்லை: அவை இருப்பதைப் போல அவர் திட்டங்களை உருவாக்குகிறார்.
அதன்படி, சில வகையான இடம்பெயர்வுகளை நாங்கள் சோதிக்கும்போது, எல்லா திட்டங்களையும் சேகரிக்க முடியும் - உற்பத்தியில் அது எப்படி நடக்கும் என்று பார்ப்போம். அங்குள்ள வினாடிகள் வித்தியாசமாக இருக்கும் (மெதுவாக), ஆனால் நாம் உண்மையில் படிக்கும் தரவு, மற்றும் திட்டங்களே (இணைப்புகள் உள்ளன, முதலியன) உற்பத்தியில் உள்ளதைப் போலவே இருக்கும். மேலும் இதுபோன்ற பல சோதனைகளை ஒரே கணினியில் இணையாக இயக்கலாம்.
டி.எஸ்: இங்கே சில பிரச்சனைகள் இருப்பதாக நீங்கள் நினைக்கவில்லையா? முதலாவது PostgreSQL இல் மட்டுமே செயல்படும் தீர்வு. இந்த அணுகுமுறை மிகவும் தனிப்பட்டது, இது பொதுவானது அல்ல. இரண்டாவதாக, குபெர்னெட்டஸ் (மேலும் கிளவுட் தொழில்நுட்பங்கள் இப்போது செல்லும் அனைத்தும்) பல முனைகளை உள்ளடக்கியது, மேலும் இந்த முனைகள் தற்காலிகமானவை. உங்கள் விஷயத்தில் இது ஒரு நிலை, நிலையான முனை. இந்த விஷயங்கள் என்னை முரண்பட வைக்கின்றன.
НС: முதலில், நான் ஒப்புக்கொள்கிறேன், இது முற்றிலும் போஸ்ட்கிரெஸ் கதை. எங்களிடம் சில வகையான நேரடி IO மற்றும் கிட்டத்தட்ட எல்லா நினைவகத்திற்கும் ஒரு இடையகக் குளம் இருந்தால், இந்த அணுகுமுறை வேலை செய்யாது - திட்டங்கள் வேறுபட்டதாக இருக்கும். ஆனால் இப்போதைக்கு நாங்கள் Postgres உடன் மட்டுமே வேலை செய்கிறோம், மற்றவர்களைப் பற்றி நாங்கள் நினைக்கவில்லை.
குபெர்னெட்டஸ் பற்றி. எங்களிடம் ஒரு நிலையான தரவுத்தளம் உள்ளது என்பதை நீங்களே எல்லா இடங்களிலும் எங்களிடம் கூறுகிறீர்கள். நிகழ்வு தோல்வியுற்றால், முக்கிய விஷயம் வட்டை சேமிப்பது. இங்கே குபெர்னெட்டஸில் முழு தளமும் உள்ளது, மேலும் Postgres உடன் உள்ள கூறு தனித்தனியாக உள்ளது (அது ஒரு நாள் இருக்கும் என்றாலும்). எனவே, எல்லாம் இது போன்றது: நிகழ்வு விழுந்தது, ஆனால் நாங்கள் அதன் PV ஐ சேமித்து, எதுவும் நடக்காதது போல் அதை மற்றொரு (புதிய) நிகழ்வுடன் இணைத்தோம்.
டி.எஸ்: எனது பார்வையில், நாங்கள் குபெர்னெட்டஸில் காய்களை உருவாக்குகிறோம். K8s - மீள்: முடிச்சுகள் தேவைக்கேற்ப ஆர்டர் செய்யப்படுகின்றன. பணியானது வெறுமனே ஒரு பாட் ஒன்றை உருவாக்கி அதற்கு X அளவு வளங்கள் தேவை என்று கூறுவது, பின்னர் K8 கள் அதை தானே கண்டுபிடிக்கும். ஆனால் குபெர்னெட்ஸில் சேமிப்பக ஆதரவு இன்னும் நிலையற்றது: இல் (இந்த வெளியீடு வெளியிடப்பட்டது недели முன்பு) இந்த அம்சங்கள் பீட்டாவாக மட்டுமே மாறும்.
ஆறு மாதங்கள் முதல் ஒரு வருடம் வரை கடந்து செல்லும் - அது அதிகமாகவோ அல்லது குறைவாகவோ நிலையானதாக மாறும், அல்லது குறைந்தபட்சம் அது அவ்வாறு அறிவிக்கப்படும். பின்னர் ஸ்னாப்ஷாட்கள் மற்றும் அளவை மாற்றுவதற்கான சாத்தியம் உங்கள் சிக்கலை முழுமையாக தீர்க்கிறது. ஏனென்றால் உங்களிடம் ஒரு அடிப்படை உள்ளது. ஆம், இது மிக வேகமாக இருக்காது, ஆனால் வேகமானது "ஹூட்டின் கீழ்" இருப்பதைப் பொறுத்தது, ஏனெனில் சில செயலாக்கங்கள் வட்டு துணை அமைப்பு மட்டத்தில் நகலெடுக்கலாம் மற்றும் எழுதலாம்.
НС: அனைத்து இயந்திரங்களும் (Amazon, Google...) இந்தப் பதிப்பை ஆதரிக்கத் தொடங்குவது அவசியம் - இதற்கும் சிறிது நேரம் ஆகும்.
டி.எஸ்: நாங்கள் இன்னும் அவற்றைப் பயன்படுத்தவில்லை. நாங்கள் எங்களுடையதைப் பயன்படுத்துகிறோம்.
குபெர்னெட்டஸின் உள்ளூர் வளர்ச்சி
НС: ஒரு கணினியில் அனைத்து காய்களையும் நிறுவி, இவ்வளவு சிறிய சோதனையைச் செய்ய வேண்டியிருக்கும் போது, இதுபோன்ற ஒரு ஆசை உங்களுக்கு வந்திருக்கிறதா? கருத்தின் ஆதாரத்தை விரைவாகப் பெற, பயன்பாடு குபெர்னெட்டஸில் இயங்குவதைப் பார்க்கவும், அதற்காக அதிக இயந்திரங்களை ஒதுக்காமல். மினிகுபே இருக்கிறது, இல்லையா?
டி.எஸ்: இந்த வழக்கு - ஒரு முனையில் பயன்படுத்தப்பட்டது - பிரத்தியேகமாக உள்ளூர் வளர்ச்சியைப் பற்றியது என்று எனக்குத் தோன்றுகிறது. அல்லது அத்தகைய வடிவத்தின் சில வெளிப்பாடுகள். சாப்பிடு , அங்கு உள்ளது , . நாங்கள் Kubernetes IN Docker ஐப் பயன்படுத்துவதை நோக்கி நகர்கிறோம். இப்போது நாங்கள் அதை சோதனைகளுக்காக வேலை செய்ய ஆரம்பித்தோம்.
НС: இது எல்லா காய்களையும் ஒரே டோக்கர் படத்தில் மடிப்பதற்கான முயற்சி என்று நான் நினைத்தேன். ஆனால் இது முற்றிலும் மாறுபட்ட ஒன்றைப் பற்றியது என்று மாறியது. எப்படியிருந்தாலும், தனித்தனி கொள்கலன்கள், தனி காய்கள் உள்ளன - டோக்கரில்.
டி.எஸ்: ஆம். மேலும் ஒரு வேடிக்கையான சாயல் உள்ளது, ஆனால் இதன் பொருள் இதுதான்... வரிசைப்படுத்துவதற்கு எங்களிடம் ஒரு பயன்பாடு உள்ளது - . நாங்கள் அதை நிபந்தனை பயன்முறையாக மாற்ற விரும்புகிறோம் werf up: "உள்ளூர் குபெர்னெட்ஸை என்னிடம் கொண்டு வாருங்கள்." பின்னர் அங்கு நிபந்தனையை இயக்கவும் werf follow. பின்னர் டெவலப்பர் IDE ஐத் திருத்த முடியும், மேலும் ஒரு செயல்முறை கணினியில் தொடங்கப்படும், இது மாற்றங்களைக் கண்டு படங்களை மீண்டும் உருவாக்குகிறது, அவற்றை உள்ளூர் K8 களுக்கு மீண்டும் வரிசைப்படுத்துகிறது. உள்ளூர் வளர்ச்சியின் சிக்கலை தீர்க்க நாங்கள் முயற்சிக்க விரும்புகிறோம்.
K8s ரியாலிட்டியில் ஸ்னாப்ஷாட்கள் மற்றும் தரவுத்தள குளோனிங்
НС: நகல்-ஆன்-ரைட்டிற்கு திரும்பினால். மேகங்களில் ஸ்னாப்ஷாட்கள் இருப்பதை நான் கவனித்தேன். அவர்கள் வித்தியாசமாக வேலை செய்கிறார்கள். எடுத்துக்காட்டாக, GCP இல்: அமெரிக்காவின் கிழக்குக் கடற்கரையில் உங்களிடம் பல டெராபைட் நிகழ்வு உள்ளது. நீங்கள் அவ்வப்போது ஸ்னாப்ஷாட்களை எடுக்கிறீர்கள். நீங்கள் ஒரு ஸ்னாப்ஷாட்டில் இருந்து மேற்கு கடற்கரையில் உள்ள வட்டின் நகலை எடுக்கிறீர்கள் - சில நிமிடங்களில் எல்லாம் தயாராக உள்ளது, இது மிக விரைவாக வேலை செய்கிறது, தற்காலிக சேமிப்பு மட்டுமே நினைவகத்தில் நிரப்பப்பட வேண்டும். ஆனால் இந்த குளோன்கள் (ஸ்னாப்ஷாட்கள்) ஒரு புதிய தொகுதியை 'வழங்குவதற்காக' உள்ளன. நீங்கள் நிறைய நிகழ்வுகளை உருவாக்க வேண்டியிருக்கும் போது இது அருமையாக இருக்கும்.
ஆனால் சோதனைகளுக்கு, நீங்கள் டோக்கரில் பேசும் ஸ்னாப்ஷாட்கள் அல்லது நான் ZFS, btrfs மற்றும் LVM போன்றவற்றில் பேசுவது போல் எனக்குத் தோன்றுகிறது... - ஒரு கணினியில் புதிய தரவை உருவாக்காமல் இருக்க அவை உங்களை அனுமதிக்கின்றன. மேகக்கணியில், நீங்கள் ஒவ்வொரு முறையும் அவர்களுக்காக பணம் செலுத்துவீர்கள், மேலும் வினாடிகள் அல்ல, நிமிடங்கள் காத்திருக்க வேண்டும் (மற்றும் வழக்கில் , ஒருவேளை ஒரு கடிகாரம்).
அதற்குப் பதிலாக, நீங்கள் இந்தத் தரவை ஓரிரு வினாடிகளில் பெற்று, சோதனையை இயக்கித் தூக்கி எறியலாம். இந்த ஸ்னாப்ஷாட்கள் பல்வேறு பிரச்சனைகளை தீர்க்கின்றன. முதல் வழக்கில் - அளவிட மற்றும் புதிய பிரதிகளை பெற, மற்றும் இரண்டாவது - சோதனைகள்.
டி.எஸ்: நான் ஒப்புக்கொள்ளவில்லை. வால்யூம் குளோனிங்கைச் சரியாகச் செய்வது மேகத்தின் பணி. நான் அவற்றைச் செயல்படுத்துவதைப் பார்க்கவில்லை, ஆனால் வன்பொருளில் அதை எப்படிச் செய்வது என்பது எனக்குத் தெரியும். எங்களிடம் செஃப் உள்ளது, இது எந்த உடல் அளவையும் அனுமதிக்கிறது () சொல் குளோன் மற்றும் அதே குணாதிசயங்களைக் கொண்ட இரண்டாவது தொகுதியை பத்து மில்லி விநாடிகளில் பெறவும், 'அமி, முதலியன உள்ளே ஒரு தந்திரமான நகல்-ஆன்-ரைட் இருப்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். மேகமும் அதையே ஏன் செய்யக்கூடாது? அவர்கள் இதை ஒரு வழி அல்லது வேறு வழியில் செய்ய முயற்சிக்கிறார்கள் என்று நான் நம்புகிறேன்.
НС: ஆனால் ஒரு உதாரணத்தை எழுப்ப, டோக்கரை அங்கு கொண்டு வர, இன்னும் சில வினாடிகள், பத்து வினாடிகள் ஆகும்.
டி.எஸ்: ஒரு முழு நிகழ்வையும் ஏன் எழுப்ப வேண்டும்? எங்களிடம் 32 கோர்களுடன் ஒரு உதாரணம் உள்ளது, 16... அது அதற்குள் பொருந்தும் - எடுத்துக்காட்டாக, நான்கு. ஐந்தாவது ஒன்றை நாங்கள் ஆர்டர் செய்யும் போது, நிகழ்வு ஏற்கனவே உயர்த்தப்படும், பின்னர் அது நீக்கப்படும்.
НС: ஆம், சுவாரஸ்யமானது, குபெர்னெட்டஸ் ஒரு வித்தியாசமான கதையாக மாறுகிறது. எங்கள் தரவுத்தளம் K8s இல் இல்லை, எங்களிடம் ஒரு நிகழ்வு உள்ளது. ஆனால் பல டெராபைட் தரவுத்தளத்தை குளோனிங் செய்வதற்கு இரண்டு வினாடிகளுக்கு மேல் ஆகாது.
டி.எஸ்: இது அருமை. ஆனால் இது ஒரு பொதுவான தீர்வு அல்ல என்பதே எனது ஆரம்பக் கருத்து. ஆம், இது அருமையாக இருக்கிறது, ஆனால் இது Postgres க்கு மட்டுமே பொருத்தமானது மற்றும் ஒரு முனையில் மட்டுமே.
НС: இது Postgres க்கு மட்டும் பொருத்தமானது: இந்த திட்டங்கள், நான் விவரித்தபடி, அதில் மட்டுமே செயல்படும். ஆனால் திட்டங்களைப் பற்றி நாங்கள் கவலைப்படவில்லை என்றால், செயல்பாட்டு சோதனைக்கான எல்லா தரவும் எங்களுக்குத் தேவைப்பட்டால், இது எந்த DBMS க்கும் ஏற்றது.
டி.எஸ்: பல ஆண்டுகளுக்கு முன்பு எல்விஎம் ஸ்னாப்ஷாட்களில் இதேபோன்ற ஒன்றைச் செய்தோம். இது ஒரு உன்னதமானது. இந்த அணுகுமுறை மிகவும் தீவிரமாக பயன்படுத்தப்பட்டது. மாநில முனைகள் ஒரு வலி மட்டுமே. நீங்கள் அவர்களை கைவிடக்கூடாது என்பதால், நீங்கள் அவர்களை எப்போதும் நினைவில் கொள்ள வேண்டும்.
НС: இங்கே கலப்பினத்தின் சாத்தியக்கூறுகளை நீங்கள் காண்கிறீர்களா? ஸ்டேட்ஃபுல் என்பது ஒருவித பாட் என்று வைத்துக்கொள்வோம், இது பலருக்கு (பல சோதனையாளர்கள்) வேலை செய்கிறது. எங்களிடம் ஒரு தொகுதி உள்ளது, ஆனால் கோப்பு முறைமைக்கு நன்றி, குளோன்கள் உள்ளூர். பாட் விழுந்தாலும், வட்டு அப்படியே இருந்தால், பாட் உயரும், அனைத்து குளோன்களைப் பற்றிய தகவலையும் எண்ணி, எல்லாவற்றையும் மீண்டும் எடுத்துச் சொல்லுங்கள்: "இதோ உங்கள் குளோன்கள் இந்த துறைமுகங்களில் இயங்குகின்றன, அவற்றுடன் தொடர்ந்து வேலை செய்யுங்கள்."
டி.எஸ்: தொழில்நுட்ப ரீதியாக இது குபெர்னெட்டஸில் உள்ள ஒரு பாட் ஆகும், அதில் நாம் பல Postgres ஐ இயக்குகிறோம்.
НС: ஆம். அவருக்கு ஒரு வரம்பு உள்ளது: அவருடன் ஒரே நேரத்தில் 10 பேருக்கு மேல் வேலை செய்யக்கூடாது என்று வைத்துக்கொள்வோம். உங்களுக்கு 20 தேவைப்பட்டால், நாங்கள் இரண்டாவது பாட் ஒன்றைத் தொடங்குவோம். நாங்கள் அதை முழுமையாக குளோன் செய்வோம், இரண்டாவது முழு தொகுதியைப் பெற்ற பிறகு, அது அதே 10 "மெல்லிய" குளோன்களைக் கொண்டிருக்கும். இந்த வாய்ப்பை நீங்கள் பார்க்கவில்லையா?
டி.எஸ்: இங்கே பாதுகாப்புச் சிக்கல்களைச் சேர்க்க வேண்டும். இந்த வகை அமைப்பு இந்த பாட் உயர் சலுகைகளை (திறன்கள்) கொண்டுள்ளது, ஏனெனில் இது கோப்பு முறைமையில் தரமற்ற செயல்பாடுகளைச் செய்ய முடியும்... ஆனால் நான் மீண்டும் சொல்கிறேன்: நடுத்தர காலத்தில் அவை குபெர்னெட்டஸில் சேமிப்பை சரி செய்யும் என்று நான் நம்புகிறேன். மேகங்கள் முழு கதையையும் தொகுதிகளுடன் சரிசெய்வார்கள் - எல்லாம் "வேலை செய்யும்". மறுஅளவாக்கம், குளோனிங் இருக்கும்... ஒரு தொகுதி உள்ளது - நாங்கள் சொல்கிறோம்: "அதன் அடிப்படையில் புதிய ஒன்றை உருவாக்கவும்," மற்றும் ஒன்றரை வினாடிகளுக்குப் பிறகு நமக்குத் தேவையானதைப் பெறுகிறோம்.
НС: பல டெராபைட்டுகளுக்கு ஒன்றரை வினாடிகளை நான் நம்பவில்லை. Cep இல் நீங்கள் அதை நீங்களே செய்கிறீர்கள், ஆனால் நீங்கள் மேகங்களைப் பற்றி பேசுகிறீர்கள். மேகக்கணிக்குச் சென்று, EC2 இல் மல்டி-டெராபைட் EBS தொகுதியின் குளோனை உருவாக்கி, செயல்திறன் என்னவாக இருக்கும் என்பதைப் பார்க்கவும். இது சில வினாடிகள் எடுக்காது. அவர்கள் எப்போது இந்த நிலையை அடைவார்கள் என்பதில் நான் மிகவும் ஆர்வமாக உள்ளேன். நீங்கள் சொல்வதை நான் புரிந்துகொள்கிறேன், ஆனால் நான் வேறுபடுகிறேன்.
டி.எஸ்: சரி, ஆனால் நான் நடுத்தர காலத்தில் சொன்னேன், குறுகிய காலத்தில் அல்ல. பல வருடங்களாக.
Zalando இலிருந்து PostgreSQLக்கான ஆபரேட்டர் பற்றி
இந்த சந்திப்பின் நடுவில், ஜலாண்டோவைச் சேர்ந்த முன்னாள் டெவலப்பர் அலெக்ஸி க்ளூகின், PostgreSQL ஆபரேட்டரின் வரலாற்றைப் பற்றிப் பேசினார்:
இந்த தலைப்பு பொதுவாக தொட்டது மிகவும் நல்லது: போஸ்ட்கிரெஸ் மற்றும் குபெர்னெட்ஸ். 2017 ஆம் ஆண்டு ஜலாண்டோவில் நாங்கள் அதைச் செய்யத் தொடங்கியபோது, அனைவரும் செய்ய விரும்பும் தலைப்பு, ஆனால் யாரும் செய்யவில்லை. அனைவருக்கும் ஏற்கனவே குபெர்னெட்ஸ் இருந்தது, ஆனால் தரவுத்தளங்களை என்ன செய்வது என்று கேட்டபோது, மக்கள் கூட விரும்புகிறார்கள் , K8s பற்றி பிரசங்கித்தவர், இப்படிச் சொன்னார்:
“நிர்வகிக்கப்பட்ட சேவைகளுக்குச் சென்று அவற்றைப் பயன்படுத்தவும், குபெர்னெட்ஸில் தரவுத்தளத்தை இயக்க வேண்டாம். இல்லையெனில், உங்கள் K8s முடிவு செய்யும், எடுத்துக்காட்டாக, மேம்படுத்தல் செய்ய, அனைத்து முனைகளையும் அணைக்க, உங்கள் தரவு வெகு தொலைவில் பறக்கும்.
இந்த ஆலோசனைக்கு மாறாக, குபெர்னெட்டஸில் ஒரு போஸ்ட்கிரெஸ் தரவுத்தளத்தை தொடங்கும் ஒரு ஆபரேட்டரை உருவாக்க முடிவு செய்தோம். எங்களுக்கு ஒரு நல்ல காரணம் இருந்தது - . இது PostgreSQLக்கான தானியங்கி தோல்வி, சரியாகச் செய்யப்பட்டது, அதாவது. etcd, தூதரகம் அல்லது ZooKeeper போன்றவற்றைக் கிளஸ்டர் பற்றிய தகவல்களின் சேமிப்பகமாகப் பயன்படுத்துதல். எடுத்துக்காட்டாக, தற்போதைய தலைவர் என்ன என்று கேட்கும் அனைவருக்கும் அதே தகவலைக் கொடுக்கும் அத்தகைய களஞ்சியம் - எல்லாவற்றையும் விநியோகித்திருந்தாலும் - மூளை பிளவுபடாது. மேலும் எங்களிடம் இருந்தது அவருக்காக.
பொதுவாக, உள் வன்பொருள் தரவு மையத்திலிருந்து கிளவுட்க்கு இடம்பெயர்ந்த பிறகு, நிறுவனத்தின் ஆட்டோ ஃபெயில்ஓவரின் தேவை தோன்றியது. கிளவுட் ஒரு தனியுரிம PaaS (பிளாட்ஃபார்ம்-ஆ-சேவை) தீர்வை அடிப்படையாகக் கொண்டது. இது ஓப்பன் சோர்ஸ், ஆனால் அதை இயக்குவதற்கு நிறைய உழைக்க வேண்டியிருந்தது. அது அழைக்கப்பட்டது .
ஆரம்பத்தில், குபர்னெட்ஸ் இல்லை. இன்னும் துல்லியமாக, எங்கள் சொந்த தீர்வு பயன்படுத்தப்பட்ட போது, K8s ஏற்கனவே இருந்தது, ஆனால் அது உற்பத்திக்கு ஏற்றதாக இல்லை என்று கச்சா இருந்தது. என் கருத்துப்படி, அது 2015 அல்லது 2016. 2017 வாக்கில், குபெர்னெட்ஸ் அதிகமாகவோ அல்லது குறைவாகவோ முதிர்ச்சியடைந்துவிட்டார் - அங்கு இடம்பெயர வேண்டிய அவசியம் இருந்தது.
எங்களிடம் ஏற்கனவே ஒரு டோக்கர் கொள்கலன் இருந்தது. Docker ஐப் பயன்படுத்தும் PaaS இருந்தது. ஏன் K8s முயற்சி செய்யக்கூடாது? உங்கள் சொந்த ஆபரேட்டரை ஏன் எழுதக்கூடாது? அவிடோவிலிருந்து எங்களிடம் வந்த முராத் கபிலோவ், இதை தனது சொந்த முயற்சியில் ஒரு திட்டமாகத் தொடங்கினார் - "விளையாட" - மற்றும் திட்டம் "எடுத்தது."
ஆனால் பொதுவாக, நான் AWS பற்றி பேச விரும்பினேன். ஏன் வரலாற்று AWS தொடர்பான குறியீடு இருந்தது...
நீங்கள் குபெர்னெட்டஸில் எதையாவது இயக்கும்போது, K8s போன்ற ஒரு வேலை நடந்து கொண்டிருக்கிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். இது தொடர்ந்து வளர்ச்சியடைந்து, மேம்படுத்தப்பட்டு, அவ்வப்போது உடைந்து போகிறது. குபெர்னெட்டஸில் ஏற்படும் அனைத்து மாற்றங்களையும் நீங்கள் உன்னிப்பாகக் கவனிக்க வேண்டும், ஏதாவது நடந்தால் அதில் மூழ்கி, அது எவ்வாறு செயல்படுகிறது என்பதை விரிவாகக் கற்றுக்கொள்ள நீங்கள் தயாராக இருக்க வேண்டும் - ஒருவேளை நீங்கள் விரும்புவதை விட அதிகமாக இருக்கலாம். இது, கொள்கையளவில், உங்கள் தரவுத்தளங்களை இயக்கும் எந்த தளத்திற்கும் பொருந்தும்...
எனவே, நாங்கள் அறிக்கையைச் செய்தபோது, போஸ்ட்கிரெஸ் வெளிப்புற தொகுதியில் இயங்கியது (இந்த விஷயத்தில் EBS, நாங்கள் AWS இல் பணிபுரிந்ததால்). தரவுத்தளம் வளர்ந்தது, ஒரு கட்டத்தில் அதை மறுஅளவிடுவது அவசியம்: எடுத்துக்காட்டாக, EBS இன் ஆரம்ப அளவு 100 TB, தரவுத்தளம் அதற்கு வளர்ந்தது, இப்போது EBS 200 TB ஐ உருவாக்க விரும்புகிறோம். எப்படி? நீங்கள் ஒரு புதிய நிகழ்வில் டம்ப்/ரீஸ்டோர் செய்யலாம் என்று வைத்துக்கொள்வோம், ஆனால் இது நீண்ட நேரம் எடுக்கும் மற்றும் வேலையில்லா நேரத்தை உள்ளடக்கும்.
எனவே, EBS பகிர்வை பெரிதாக்கி, புதிய இடத்தைப் பயன்படுத்தும்படி கோப்பு முறைமைக்குக் கூறும் அளவை மாற்ற வேண்டும் என்று நான் விரும்பினேன். நாங்கள் அதைச் செய்தோம், ஆனால் அந்த நேரத்தில் குபெர்னெட்டஸிடம் மறுஅளவிடல் செயல்பாட்டிற்கான ஏபிஐ எதுவும் இல்லை. நாங்கள் AWS இல் பணிபுரிந்ததால், அதன் APIக்கான குறியீட்டை எழுதினோம்.
மற்ற தளங்களுக்கும் இதைச் செய்வதிலிருந்து யாரும் உங்களைத் தடுக்கவில்லை. அதை AWS இல் மட்டுமே இயக்க முடியும் என்று அறிக்கையில் எந்த குறிப்பும் இல்லை, மற்ற எல்லாவற்றிலும் இது வேலை செய்யாது. பொதுவாக, இது ஒரு ஓப்பன் சோர்ஸ் திட்டமாகும்: புதிய API இன் பயன்பாட்டின் தோற்றத்தை யாராவது விரைவுபடுத்த விரும்பினால், நீங்கள் வரவேற்கப்படுகிறீர்கள். சாப்பிடு , கோரிக்கைகளை இழுக்கவும் - Zalando குழு அவர்களுக்கு மிக விரைவாக பதிலளிக்க மற்றும் ஆபரேட்டரை ஊக்குவிக்க முயற்சிக்கிறது. எனக்குத் தெரிந்தவரை, திட்டம் Google Summer of Code மற்றும் வேறு சில இதே போன்ற முயற்சிகளில். ஜலாண்டோ அதில் மிகவும் தீவிரமாக செயல்பட்டு வருகிறார்.
PS போனஸ்!
PostgreSQL மற்றும் Kubernetes என்ற தலைப்பில் நீங்கள் ஆர்வமாக இருந்தால், அடுத்த Postgres செவ்வாய் கடந்த வாரம் நடந்தது என்பதையும் நினைவில் கொள்ளவும், அங்கு நான் நிகோலாய் பேசினேன். ஜலாண்டோவைச் சேர்ந்த அலெக்சாண்டர் குகுஷ்கின். அதிலிருந்து வீடியோ கிடைக்கிறது .
பிபிஎஸ்
எங்கள் வலைப்பதிவிலும் படிக்கவும்:
- «";
- «";
- «";
- «".
ஆதாரம்: www.habr.com