പോസ്റ്റ്ഗ്രെസ് ചൊവ്വാഴ്ച നമ്പർ 5: "PostgreSQL ഉം Kubernetes ഉം. CI/CD. ടെസ്റ്റ് ഓട്ടോമേഷൻ"

കഴിഞ്ഞ വർഷം അവസാനം, റഷ്യൻ PostgreSQL കമ്മ്യൂണിറ്റിയുടെ മറ്റൊരു തത്സമയ പ്രക്ഷേപണം നടന്നു #RuPostgres, അതിന്റെ സഹസ്ഥാപകൻ നിക്കോളായ് സമോഖ്വലോവ് കുബെർനെറ്റസിന്റെ പശ്ചാത്തലത്തിൽ ഈ ഡിബിഎംഎസിനെ കുറിച്ച് ഫ്ലാന്റ് ടെക്നിക്കൽ ഡയറക്ടർ ദിമിത്രി സ്റ്റോല്യറോവുമായി സംസാരിച്ചു.

ഈ ചർച്ചയുടെ പ്രധാന ഭാഗത്തിന്റെ ഒരു ട്രാൻസ്ക്രിപ്റ്റ് ഞങ്ങൾ പ്രസിദ്ധീകരിക്കുന്നു, കൂടാതെ കമ്മ്യൂണിറ്റി YouTube ചാനൽ പൂർണ്ണ വീഡിയോ പോസ്റ്റ് ചെയ്തു:

ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും

НС: നമ്മൾ ഇന്ന് വാക്വം, ചെക്ക്‌പോയിന്റുകൾ എന്നിവയെക്കുറിച്ച് സംസാരിക്കില്ല. ഞങ്ങൾ കുബർനെറ്റസിനെക്കുറിച്ചാണ് സംസാരിക്കാൻ ആഗ്രഹിക്കുന്നത്. താങ്കൾക്ക് ഒരുപാട് വർഷത്തെ പരിചയം ഉണ്ടെന്ന് എനിക്കറിയാം. ഞാൻ നിങ്ങളുടെ വീഡിയോകൾ കാണുകയും അവയിൽ ചിലത് വീണ്ടും കാണുകയും ചെയ്തു... നമുക്ക് നേരിട്ട് കാര്യത്തിലേക്ക് കടക്കാം: K8s-ൽ എന്തുകൊണ്ട് Postgres അല്ലെങ്കിൽ MySQL?

ഡി.എസ്: ഈ ചോദ്യത്തിന് കൃത്യമായ ഉത്തരം ഇല്ല, കഴിയില്ല. എന്നാൽ പൊതുവേ, ഇത് ലാളിത്യവും സൗകര്യവുമാണ് ... സാധ്യത. നിയന്ത്രിത സേവനങ്ങൾ എല്ലാവർക്കും വേണം.

НС: എങ്ങനെ ര്ദ്സ്, വീട്ടിൽ മാത്രമോ?

ഡി.എസ്: അതെ: RDS പോലെ, എവിടെയും.

НС: "എവിടെയും" എന്നത് ഒരു നല്ല പോയിന്റാണ്. വലിയ കമ്പനികളിൽ, എല്ലാം വ്യത്യസ്ത സ്ഥലങ്ങളിൽ സ്ഥിതിചെയ്യുന്നു. ഒരു വലിയ കമ്പനിയാണെങ്കിൽ, എന്തുകൊണ്ട് ഒരു റെഡിമെയ്ഡ് സൊല്യൂഷൻ എടുക്കുന്നില്ല? ഉദാഹരണത്തിന്, Nutanix-ന് അതിന്റേതായ സംഭവവികാസങ്ങളുണ്ട്, മറ്റ് കമ്പനികൾക്ക് (VMware...) അതേ "RDS, വീട്ടിൽ മാത്രം" ഉണ്ട്.

ഡി.എസ്: എന്നാൽ ഞങ്ങൾ സംസാരിക്കുന്നത് ഒരു പ്രത്യേക നിർവ്വഹണത്തെക്കുറിച്ചാണ്, അത് ചില വ്യവസ്ഥകളിൽ മാത്രം പ്രവർത്തിക്കും. നമ്മൾ കുബെർനെറ്റസിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, വൈവിധ്യമാർന്ന ഇൻഫ്രാസ്ട്രക്ചർ ഉണ്ട് (അത് K8 കളിൽ ആകാം). അടിസ്ഥാനപരമായി ഇത് ക്ലൗഡിലേക്കുള്ള API-കൾക്കുള്ള ഒരു മാനദണ്ഡമാണ്...

НС: അതും സൗജന്യമാണ്!

ഡി.എസ്: അത് അത്ര പ്രധാനമല്ല. വിപണിയിലെ ഒരു വലിയ വിഭാഗത്തിനും സ്വാതന്ത്ര്യം പ്രധാനമാണ്. മറ്റെന്തെങ്കിലും പ്രധാനമാണ്... നിങ്ങൾ ഒരുപക്ഷേ റിപ്പോർട്ട് ഓർത്തിരിക്കാം “ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും"?

НС: അതെ.

ഡി.എസ്: വളരെ അവ്യക്തമായാണ് അത് ലഭിച്ചതെന്ന് എനിക്ക് മനസ്സിലായി. ഞാൻ പറയുകയാണെന്ന് ചിലർ വിചാരിച്ചു: "കുട്ടികളേ, നമുക്ക് എല്ലാ ഡാറ്റാബേസുകളും കുബർനെറ്റിലേക്ക് കൊണ്ടുവരാം!", മറ്റുള്ളവർ ഇതെല്ലാം ഭയങ്കരമായ സൈക്കിളുകളാണെന്ന് തീരുമാനിച്ചു. എന്നാൽ തികച്ചും വ്യത്യസ്തമായ എന്തെങ്കിലും പറയാൻ ഞാൻ ആഗ്രഹിച്ചു: “എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കൂ, എന്തൊക്കെ പ്രശ്നങ്ങൾ ഉണ്ട്, അവ എങ്ങനെ പരിഹരിക്കാം. നമ്മൾ ഇപ്പോൾ Kubernetes ഡാറ്റാബേസുകൾ ഉപയോഗിക്കണോ? ഉത്പാദനം? ശരി, നിങ്ങൾ ഇഷ്ടപ്പെടുന്നെങ്കിൽ മാത്രം... ചില കാര്യങ്ങൾ ചെയ്യുന്നു. എന്നാൽ ഒരു ദേവനെ സംബന്ധിച്ചിടത്തോളം, ഞാൻ ഇത് ശുപാർശ ചെയ്യുന്നുവെന്ന് എനിക്ക് പറയാൻ കഴിയും. ഒരു ദേവനെ സംബന്ധിച്ചിടത്തോളം, പരിതസ്ഥിതികൾ സൃഷ്‌ടിക്കുന്നതിന്റെ/ഇല്ലാതാക്കുന്നതിന്റെ ചലനാത്മകത വളരെ പ്രധാനമാണ്.

NS: ദേവ് എന്നതുകൊണ്ട്, നിങ്ങൾ ഉദ്ദേശിക്കുന്നത് പ്രോഡക്റ്റ് അല്ലാത്ത എല്ലാ പരിതസ്ഥിതികളെയും ആണോ? സ്റ്റേജിംഗ്, QA…

ഡി.എസ്: നമ്മൾ പെർഫ് സ്റ്റാൻഡുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, ഒരുപക്ഷേ അല്ല, കാരണം അവിടെ ആവശ്യകതകൾ പ്രത്യേകമാണ്. സ്റ്റേജിംഗിന് വളരെ വലിയ ഡാറ്റാബേസ് ആവശ്യമുള്ള പ്രത്യേക സാഹചര്യങ്ങളെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ, ഒരുപക്ഷേ അല്ല... ഇതൊരു സ്ഥിരവും ദീർഘകാലവുമായ അന്തരീക്ഷമാണെങ്കിൽ, ഡാറ്റാബേസ് K8-ൽ സ്ഥിതി ചെയ്യുന്നതിന്റെ പ്രയോജനം എന്താണ്?

НС: ഒന്നുമില്ല. എന്നാൽ സ്ഥിരമായ പരിതസ്ഥിതികൾ നമ്മൾ എവിടെയാണ് കാണുന്നത്? ഒരു നിശ്ചലമായ അന്തരീക്ഷം നാളെ കാലഹരണപ്പെടും.

ഡി.എസ്: സ്റ്റേജിംഗ് സ്റ്റാറ്റിക് ആകാം. ഞങ്ങൾക്ക് ഇടപാടുകാരുണ്ട്...

НС: അതെ, എനിക്കും ഉണ്ട്. നിങ്ങൾക്ക് 10 TB ഡാറ്റാബേസും 200 GB സ്റ്റേജിംഗും ഉണ്ടെങ്കിൽ അത് വലിയ പ്രശ്നമാണ്...

ഡി.എസ്: എനിക്ക് വളരെ രസകരമായ ഒരു കേസ് ഉണ്ട്! സ്റ്റേജിൽ മാറ്റങ്ങൾ വരുത്തുന്ന ഒരു ഉൽപ്പന്ന ഡാറ്റാബേസ് ഉണ്ട്. കൂടാതെ ഒരു ബട്ടണും ഉണ്ട്: "ഉത്പാദനത്തിലേക്ക് ഉരുട്ടുക". ഈ മാറ്റങ്ങൾ - ഡെൽറ്റകൾ - ഉൽപ്പാദനത്തിൽ ചേർക്കുന്നു (അവ API വഴി സമന്വയിപ്പിച്ചതായി തോന്നുന്നു). ഇത് വളരെ വിചിത്രമായ ഓപ്ഷനാണ്.

НС: താഴ്‌വരയിൽ RDS-ലോ ഹീറോകുവിലോ പോലും ഇരിക്കുന്ന സ്റ്റാർട്ടപ്പുകൾ ഞാൻ കണ്ടിട്ടുണ്ട് - ഇവ 2-3 വർഷം മുമ്പുള്ള കഥകളാണ് - അവ അവരുടെ ലാപ്‌ടോപ്പിലേക്ക് ഡംപ് ഡൗൺലോഡ് ചെയ്യുന്നു. കാരണം ഡാറ്റാബേസ് ഇപ്പോഴും 80 ജിബി മാത്രമാണ്, ലാപ്ടോപ്പിൽ സ്ഥലമുണ്ട്. തുടർന്ന് അവർ എല്ലാവർക്കുമായി അധിക ഡിസ്കുകൾ വാങ്ങുന്നു, അതുവഴി വ്യത്യസ്ത വികസനങ്ങൾ നടത്താൻ അവർക്ക് 3 ഡാറ്റാബേസുകൾ ഉണ്ട്. ഇതും ഇങ്ങനെയാണ് സംഭവിക്കുന്നത്. സ്റ്റേജിലേക്ക് ഉൽപ്പന്നം പകർത്താൻ അവർ ഭയപ്പെടുന്നില്ലെന്നും ഞാൻ കണ്ടു - ഇത് കമ്പനിയെ ആശ്രയിച്ചിരിക്കുന്നു. എന്നാൽ അവർ വളരെ ഭയപ്പെടുന്നതായും അവർക്ക് പലപ്പോഴും സമയവും കൈയും ഇല്ലെന്നും ഞാൻ കണ്ടു. എന്നാൽ ഈ വിഷയത്തിലേക്ക് കടക്കുന്നതിന് മുമ്പ്, എനിക്ക് കുബർനെറ്റസിനെ കുറിച്ച് കേൾക്കണം. ഇതുവരെ ആരും പ്രോഡിൽ ഇല്ലെന്ന് ഞാൻ ശരിയായി മനസ്സിലാക്കുന്നുണ്ടോ?

ഡി.എസ്: ഞങ്ങൾക്ക് പ്രോഡിൽ ചെറിയ ഡാറ്റാബേസുകൾ ഉണ്ട്. ഞങ്ങൾ സംസാരിക്കുന്നത് പതിനായിരക്കണക്കിന് ജിഗാബൈറ്റുകളുടെ വോള്യങ്ങളെക്കുറിച്ചും നിർണ്ണായകമല്ലാത്ത സേവനങ്ങളെക്കുറിച്ചുമാണ്, അതിന്റെ പകർപ്പുകൾ നിർമ്മിക്കാൻ ഞങ്ങൾ മടിയന്മാരായിരുന്നു (അത്തരം ആവശ്യമില്ല). കുബെർനെറ്റസിന് കീഴിൽ സാധാരണ സ്റ്റോറേജ് ഉണ്ടെന്നും നൽകിയിട്ടുണ്ട്. ഈ ഡാറ്റാബേസ് ഒരു വെർച്വൽ മെഷീനിൽ പ്രവർത്തിച്ചു - സോപാധികമായി VMware-ൽ, സ്റ്റോറേജ് സിസ്റ്റത്തിന് മുകളിൽ. ഞങ്ങൾ അത് അകത്താക്കി PV ഇപ്പോൾ നമുക്ക് അത് മെഷീനിൽ നിന്ന് മെഷീനിലേക്ക് മാറ്റാം.

НС: 100 GB വരെയുള്ള ഈ വലിപ്പത്തിലുള്ള ഡാറ്റാബേസുകൾ, നല്ല ഡിസ്കുകളിലും നല്ല നെറ്റ്‌വർക്കിലും ഏതാനും മിനിറ്റുകൾക്കുള്ളിൽ റോൾ ഔട്ട് ചെയ്യാം, അല്ലേ? സെക്കൻഡിൽ 1 GB വേഗത ഇനി അഭൗമമല്ല.

ഡി.എസ്: അതെ, ലീനിയർ പ്രവർത്തനത്തിന് ഇത് ഒരു പ്രശ്നമല്ല.

НС: ശരി, നമുക്ക് പ്രോഡിനെക്കുറിച്ച് ചിന്തിക്കേണ്ടിയിരിക്കുന്നു. പ്രോഡ് അല്ലാത്ത പരിതസ്ഥിതികൾക്കായി ഞങ്ങൾ കുബർനെറ്റുകളെ പരിഗണിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ എന്തുചെയ്യണം? ഞാൻ അത് സലാൻഡോയിൽ കാണുന്നു ഓപ്പറേറ്റർ ചെയ്യുക, Crunchy ൽ വെട്ടുന്നു, മറ്റ് ചില ഓപ്ഷനുകൾ ഉണ്ട്. ഒപ്പം ഉണ്ട് ഓൺഗ്രെസ് - ഇതാണ് സ്പെയിനിൽ നിന്നുള്ള ഞങ്ങളുടെ നല്ല സുഹൃത്ത് അൽവാരോ: അവർ ചെയ്യുന്നത് അടിസ്ഥാനപരമായി വെറുതെയല്ല ഓപ്പറേറ്റർ, കൂടാതെ മുഴുവൻ വിതരണവും (സ്റ്റാക്ക്ഗ്രെസ്), അതിൽ, പോസ്റ്റ്‌ഗ്രെസിന് പുറമേ, ഒരു ബാക്കപ്പും സ്റ്റഫ് ചെയ്യാൻ അവർ തീരുമാനിച്ചു, എൻവോയ് പ്രോക്സി...

ഡി.എസ്: എന്തിനു വേണ്ടി ദൂതൻ? Postgres ട്രാഫിക് പ്രത്യേകമായി സന്തുലിതമാക്കണോ?

НС: അതെ. അതായത്, അവർ അതിനെ ഇതുപോലെ കാണുന്നു: നിങ്ങൾ ഒരു Linux വിതരണവും കേർണലും എടുക്കുകയാണെങ്കിൽ, സാധാരണ PostgreSQL ആണ് കേർണൽ, കൂടാതെ ക്ലൗഡ്-സൗഹൃദവും കുബർനെറ്റുകളിൽ പ്രവർത്തിക്കുന്നതുമായ ഒരു വിതരണം നടത്താൻ അവർ ആഗ്രഹിക്കുന്നു. അവർ ഘടകങ്ങൾ (ബാക്കപ്പുകൾ, മുതലായവ) ഒന്നിച്ചുചേർക്കുകയും ഡീബഗ് ചെയ്യുകയും ചെയ്യുന്നു, അങ്ങനെ അവ നന്നായി പ്രവർത്തിക്കുന്നു.

ഡി.എസ്: വളരെ കൂൾ! അടിസ്ഥാനപരമായി ഇത് നിങ്ങളുടെ സ്വന്തം നിയന്ത്രിത പോസ്റ്റ്‌ഗ്രെസ് സൃഷ്‌ടിക്കുന്നതിനുള്ള സോഫ്‌റ്റ്‌വെയറാണ്.

НС: ലിനക്സ് വിതരണങ്ങൾക്ക് ശാശ്വതമായ പ്രശ്നങ്ങളുണ്ട്: എല്ലാ ഹാർഡ്‌വെയറുകളും പിന്തുണയ്ക്കുന്ന തരത്തിൽ ഡ്രൈവറുകൾ എങ്ങനെ നിർമ്മിക്കാം. അവർ കുബർനെറ്റസിൽ പ്രവർത്തിക്കുമെന്ന ആശയം അവർക്കുണ്ട്. Zalando ഓപ്പറേറ്ററിൽ ഞങ്ങൾ അടുത്തിടെ AWS-ലേക്കുള്ള ഒരു കണക്ഷൻ കണ്ടുവെന്നും ഇത് വളരെ നല്ലതല്ലെന്നും എനിക്കറിയാം. ഒരു നിർദ്ദിഷ്ട ഇൻഫ്രാസ്ട്രക്ചറുമായി ഒരു ബന്ധവും ഉണ്ടാകരുത് - അപ്പോൾ എന്താണ് പ്രയോജനം?

ഡി.എസ്: സലാൻഡോ ഏത് സാഹചര്യത്തിലാണ് അകപ്പെട്ടതെന്ന് എനിക്കറിയില്ല, പക്ഷേ കുബർനെറ്റസ് സ്റ്റോറേജിൽ ഇപ്പോൾ ഒരു ജനറിക് രീതി ഉപയോഗിച്ച് ഒരു ഡിസ്ക് ബാക്കപ്പ് എടുക്കുന്നത് അസാധ്യമായ വിധത്തിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്. അടുത്തിടെ സ്റ്റാൻഡേർഡിൽ - ഏറ്റവും പുതിയ പതിപ്പിൽ CSI സവിശേഷതകൾ — ഞങ്ങൾ സ്നാപ്പ്ഷോട്ടുകൾ സാധ്യമാക്കി, പക്ഷേ അത് എവിടെയാണ് നടപ്പിലാക്കുന്നത്? സത്യസന്ധമായി, എല്ലാം ഇപ്പോഴും അസംസ്കൃതമാണ്... ഞങ്ങൾ AWS, GCE, Azure, vSphere എന്നിവയ്‌ക്ക് മുകളിൽ CSI പരീക്ഷിക്കുന്നു, പക്ഷേ നിങ്ങൾ അത് ഉപയോഗിക്കാൻ തുടങ്ങിയ ഉടൻ തന്നെ അത് ഇതുവരെ തയ്യാറായിട്ടില്ലെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും.

НС: അതുകൊണ്ടാണ് നമുക്ക് ചിലപ്പോൾ അടിസ്ഥാന സൗകര്യങ്ങളെ ആശ്രയിക്കേണ്ടി വരുന്നത്. ഇത് ഇപ്പോഴും ഒരു പ്രാരംഭ ഘട്ടമാണെന്ന് ഞാൻ കരുതുന്നു - വളരുന്ന വേദന. ചോദ്യം: K8-കളിൽ PgSQL പരീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്ന പുതുമുഖങ്ങൾക്ക് നിങ്ങൾ എന്ത് ഉപദേശമാണ് നൽകുന്നത്? ഏത് ഓപ്പറേറ്ററായിരിക്കാം?

ഡി.എസ്: പ്രശ്നം പോസ്റ്റ്ഗ്രെസ് ഞങ്ങൾക്ക് 3% ആണ്. കുബെർനെറ്റസിൽ വ്യത്യസ്ത സോഫ്‌റ്റ്‌വെയറുകളുടെ ഒരു വലിയ ലിസ്റ്റ് ഞങ്ങളുടെ പക്കലുണ്ട്, ഞാൻ എല്ലാം ലിസ്റ്റ് ചെയ്യില്ല. ഉദാഹരണത്തിന്, ഇലാസ്റ്റിക് സെർച്ച്. ധാരാളം ഓപ്പറേറ്റർമാർ ഉണ്ട്: ചിലത് സജീവമായി വികസിച്ചുകൊണ്ടിരിക്കുന്നു, മറ്റുള്ളവർ അങ്ങനെയല്ല. ഞങ്ങൾ അത് ഗൗരവമായി എടുക്കുന്നതിന് ഒരു ഓപ്പറേറ്റർക്ക് എന്തെല്ലാം ഉണ്ടായിരിക്കണം എന്നതിനെക്കുറിച്ചുള്ള ആവശ്യകതകൾ ഞങ്ങൾ സ്വയം തയ്യാറാക്കിയിട്ടുണ്ട്. Kubernetes-ന് പ്രത്യേകമായി ഒരു ഓപ്പറേറ്ററിൽ - "ആമസോണിന്റെ അവസ്ഥയിൽ എന്തെങ്കിലും ചെയ്യാനുള്ള ഓപ്പറേറ്ററിൽ" അല്ല... വാസ്തവത്തിൽ, ഞങ്ങൾ വളരെ വ്യാപകമായി (= മിക്കവാറും എല്ലാ ക്ലയന്റുകളും) ഒരൊറ്റ ഓപ്പറേറ്ററെ ഉപയോഗിക്കുന്നു - റെഡിസിന് (അദ്ദേഹത്തെക്കുറിച്ചുള്ള ഒരു ലേഖനം ഞങ്ങൾ ഉടൻ പ്രസിദ്ധീകരിക്കും).

НС: പിന്നെ MySQL-ന് വേണ്ടിയല്ലേ? എനിക്കറിയാം Percona... അവർ ഇപ്പോൾ MySQL, MongoDB, Postgres എന്നിവയിൽ പ്രവർത്തിക്കുന്നതിനാൽ, അവർ ഏതെങ്കിലും തരത്തിലുള്ള സാർവത്രിക പരിഹാരം സൃഷ്ടിക്കേണ്ടതുണ്ട്: എല്ലാ ഡാറ്റാബേസുകൾക്കും, എല്ലാ ക്ലൗഡ് ദാതാക്കൾക്കും.

ഡി.എസ്: MySQL-നുള്ള ഓപ്പറേറ്റർമാരെ നോക്കാൻ ഞങ്ങൾക്ക് സമയമില്ല. ഇപ്പോൾ ഞങ്ങളുടെ പ്രധാന ശ്രദ്ധ ഇതല്ല. MySQL സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നു. നിങ്ങൾക്ക് ഒരു ഡാറ്റാബേസ് സമാരംഭിക്കാൻ കഴിയുമെങ്കിൽ എന്തിനാണ് ഒരു ഓപ്പറേറ്റർ ഉപയോഗിക്കുന്നത്... നിങ്ങൾക്ക് Postrges ഉപയോഗിച്ച് ഒരു ഡോക്കർ കണ്ടെയ്‌നർ സമാരംഭിക്കാം, അല്ലെങ്കിൽ നിങ്ങൾക്കത് ലളിതമായ രീതിയിൽ സമാരംഭിക്കാം.

НС: ഇതിനെപ്പറ്റിയും ഒരു ചോദ്യം ഉണ്ടായിരുന്നു. ഓപ്പറേറ്റർ ഇല്ലേ?

ഡി.എസ്: അതെ, ഞങ്ങളിൽ 100% പേർക്കും ഒരു ഓപ്പറേറ്റർ ഇല്ലാതെ തന്നെ PostgreSQL പ്രവർത്തിക്കുന്നുണ്ട്. ഇതുവരെ. പ്രൊമിത്യൂസിനും റെഡിസിനും വേണ്ടി ഞങ്ങൾ ഓപ്പറേറ്ററെ സജീവമായി ഉപയോഗിക്കുന്നു. ഇലാസ്റ്റിക് സെർച്ചിനായി ഒരു ഓപ്പറേറ്ററെ കണ്ടെത്താൻ ഞങ്ങൾ പദ്ധതിയിട്ടിട്ടുണ്ട് - ഇത് ഏറ്റവും "തീപിടിച്ചത്" ആണ്, കാരണം 100% കേസുകളിലും ഇത് കുബർനെറ്റസിൽ ഇൻസ്റ്റാൾ ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. MongoDB എപ്പോഴും Kubernetes-ൽ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നതുപോലെ. ഇവിടെ ചില ആഗ്രഹങ്ങൾ പ്രത്യക്ഷപ്പെടുന്നു - ഈ സന്ദർഭങ്ങളിൽ എന്തെങ്കിലും ചെയ്യാൻ കഴിയുമെന്ന ഒരു തോന്നൽ ഉണ്ട്. ഞങ്ങൾ പോസ്റ്റ്‌ഗ്രെസിലേക്ക് പോലും നോക്കിയില്ല. തീർച്ചയായും, വ്യത്യസ്ത ഓപ്ഷനുകൾ ഉണ്ടെന്ന് ഞങ്ങൾക്കറിയാം, എന്നാൽ വാസ്തവത്തിൽ ഞങ്ങൾക്ക് ഒരു ഒറ്റയ്ക്കുണ്ട്.

കുബർനെറ്റസിലെ പരിശോധനയ്ക്കായി ഡി.ബി

НС: നമുക്ക് ടെസ്റ്റിംഗ് എന്ന വിഷയത്തിലേക്ക് കടക്കാം. ഒരു DevOps വീക്ഷണകോണിൽ നിന്ന് ഡാറ്റാബേസിലേക്ക് എങ്ങനെ മാറ്റങ്ങൾ വരുത്താം. മൈക്രോസർവീസുകൾ ഉണ്ട്, ധാരാളം ഡാറ്റാബേസുകൾ ഉണ്ട്, എല്ലായ്‌പ്പോഴും എവിടെയെങ്കിലും എന്തെങ്കിലും മാറിക്കൊണ്ടിരിക്കുന്നു. സാധാരണ സിഐ/സിഡി എങ്ങനെ ഉറപ്പാക്കാം, അങ്ങനെ എല്ലാം ഡിബിഎംഎസ് വീക്ഷണകോണിൽ ക്രമത്തിലായിരിക്കും. എന്താണ് നിങ്ങളുടെ സമീപനം?

ഡി.എസ്: ഒറ്റ ഉത്തരമുണ്ടാവില്ല. നിരവധി ഓപ്ഷനുകൾ ഉണ്ട്. ആദ്യത്തേത് ഞങ്ങൾ ഉരുട്ടാൻ ആഗ്രഹിക്കുന്ന അടിത്തറയുടെ വലുപ്പമാണ്. ഡെവിലും സ്റ്റേജിലും പ്രോഡ് ഡാറ്റാബേസിന്റെ പകർപ്പ് കൈവശം വയ്ക്കുന്നതിന് കമ്പനികൾക്ക് വ്യത്യസ്ത മനോഭാവമുണ്ടെന്ന് നിങ്ങൾ തന്നെ സൂചിപ്പിച്ചു.

НС: GDPR-ന്റെ വ്യവസ്ഥകൾക്ക് കീഴിൽ, അവർ കൂടുതൽ കൂടുതൽ ശ്രദ്ധാലുവായിരിക്കുകയാണെന്ന് ഞാൻ കരുതുന്നു... യൂറോപ്പിൽ അവർ ഇതിനകം തന്നെ പിഴ ചുമത്താൻ തുടങ്ങിയിട്ടുണ്ടെന്ന് എനിക്ക് പറയാൻ കഴിയും.

ഡി.എസ്: എന്നാൽ പലപ്പോഴും നിങ്ങൾക്ക് പ്രൊഡക്ഷനിൽ നിന്ന് ഒരു ഡംപ് എടുത്ത് അതിനെ അവ്യക്തമാക്കുന്ന സോഫ്റ്റ്‌വെയർ എഴുതാം. ഉൽപ്പന്ന ഡാറ്റ ലഭിച്ചു (സ്നാപ്പ്ഷോട്ട്, ഡംപ്, ബൈനറി കോപ്പി...), എന്നാൽ അത് അജ്ഞാതമാക്കിയിരിക്കുന്നു. പകരം, ജനറേഷൻ സ്‌ക്രിപ്റ്റുകൾ ഉണ്ടാകാം: ഇവ ഫിക്‌ചറുകളോ വലിയ ഡാറ്റാബേസ് സൃഷ്‌ടിക്കുന്ന ഒരു സ്‌ക്രിപ്റ്റോ ആകാം. പ്രശ്നം ഇതാണ്: ഒരു അടിസ്ഥാന ഇമേജ് സൃഷ്ടിക്കാൻ എത്ര സമയമെടുക്കും? ആവശ്യമുള്ള പരിതസ്ഥിതിയിൽ ഇത് വിന്യസിക്കാൻ എത്ര സമയമെടുക്കും?

ഞങ്ങൾ ഒരു സ്കീമിൽ എത്തി: ക്ലയന്റിന് ഒരു നിശ്ചിത ഡാറ്റ സെറ്റ് (ഡാറ്റാബേസിന്റെ ഏറ്റവും കുറഞ്ഞ പതിപ്പ്) ഉണ്ടെങ്കിൽ, ഞങ്ങൾ അവ സ്ഥിരസ്ഥിതിയായി ഉപയോഗിക്കുന്നു. ഞങ്ങൾ അവലോകന പരിതസ്ഥിതികളെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, ഞങ്ങൾ ഒരു ബ്രാഞ്ച് സൃഷ്‌ടിച്ചപ്പോൾ, ഞങ്ങൾ ആപ്ലിക്കേഷന്റെ ഒരു ഉദാഹരണം വിന്യസിച്ചു - ഞങ്ങൾ അവിടെ ഒരു ചെറിയ ഡാറ്റാബേസ് പുറത്തിറക്കുന്നു. എന്നാൽ അത് നന്നായി മാറി ഓപ്ഷൻ, ഞങ്ങൾ ഒരു ദിവസത്തിൽ ഒരിക്കൽ (രാത്രിയിൽ) ഉൽപ്പാദനത്തിൽ നിന്ന് ഒരു ഡംപ് എടുത്ത് അതിനെ അടിസ്ഥാനമാക്കി ഈ ലോഡ് ചെയ്ത ഡാറ്റ ഉപയോഗിച്ച് PostgreSQL, MySQL എന്നിവ ഉപയോഗിച്ച് ഒരു ഡോക്കർ കണ്ടെയ്നർ നിർമ്മിക്കുമ്പോൾ. ഈ ചിത്രത്തിൽ നിന്ന് നിങ്ങൾക്ക് ഡാറ്റാബേസ് 50 തവണ വികസിപ്പിക്കണമെങ്കിൽ, ഇത് വളരെ ലളിതമായും വേഗത്തിലും ചെയ്യപ്പെടും.

НС: ലളിതമായി പകർത്തിക്കൊണ്ട്?

ഡി.എസ്: ഡാറ്റ നേരിട്ട് ഡോക്കർ ഇമേജിൽ സംഭരിക്കുന്നു. ആ. 100 GB ആണെങ്കിലും ഞങ്ങൾക്ക് ഒരു റെഡിമെയ്ഡ് ഇമേജ് ഉണ്ട്. ഡോക്കറിലെ ലെയറുകൾക്ക് നന്ദി, നമുക്ക് ആവശ്യമുള്ളത്ര തവണ ഈ ചിത്രം വേഗത്തിൽ വിന്യസിക്കാൻ കഴിയും. രീതി മണ്ടത്തരമാണ്, പക്ഷേ അത് നന്നായി പ്രവർത്തിക്കുന്നു.

НС: അപ്പോൾ, നിങ്ങൾ പരിശോധിക്കുമ്പോൾ, അത് ഡോക്കറിനുള്ളിൽ തന്നെ മാറുന്നു, അല്ലേ? ഡോക്കറിനുള്ളിൽ കോപ്പി-ഓൺ-റൈറ്റ് - അത് വലിച്ചെറിഞ്ഞ് വീണ്ടും പോകൂ, എല്ലാം ശരിയാണ്. ക്ലാസ്! നിങ്ങൾ ഇതിനകം ഇത് പൂർണ്ണമായി ഉപയോഗിക്കുന്നുണ്ടോ?

ഡി.എസ്: ദീർഘനാളായി.

НС: ഞങ്ങൾ വളരെ സമാനമായ കാര്യങ്ങൾ ചെയ്യുന്നു. ഞങ്ങൾ ഡോക്കറിന്റെ കോപ്പി-ഓൺ-റൈറ്റ് ഉപയോഗിക്കുന്നില്ല, മറിച്ച് മറ്റേതെങ്കിലും ഒന്ന്.

ഡി.എസ്: ഇത് ജനറിക് അല്ല. ഡോക്കർ എല്ലായിടത്തും പ്രവർത്തിക്കുന്നു.

НС: സിദ്ധാന്തത്തിൽ, അതെ. എന്നാൽ ഞങ്ങൾക്ക് അവിടെ മൊഡ്യൂളുകളും ഉണ്ട്, നിങ്ങൾക്ക് വ്യത്യസ്ത മൊഡ്യൂളുകൾ നിർമ്മിക്കാനും വ്യത്യസ്ത ഫയൽ സിസ്റ്റങ്ങളിൽ പ്രവർത്തിക്കാനും കഴിയും. ഇവിടെ എന്തൊരു നിമിഷം. പോസ്റ്റ്‌ഗ്രേസിന്റെ ഭാഗത്ത് നിന്ന്, ഞങ്ങൾ ഇതെല്ലാം വ്യത്യസ്തമായി കാണുന്നു. ഇപ്പോൾ ഞാൻ ഡോക്കറിന്റെ ഭാഗത്ത് നിന്ന് നോക്കി, എല്ലാം നിങ്ങൾക്കായി പ്രവർത്തിക്കുന്നുവെന്ന് കണ്ടു. എന്നാൽ ഡാറ്റാബേസ് വളരെ വലുതാണെങ്കിൽ, ഉദാഹരണത്തിന്, 1 TB, അപ്പോൾ ഇതിനെല്ലാം വളരെയധികം സമയമെടുക്കും: രാത്രിയിലെ പ്രവർത്തനങ്ങൾ, എല്ലാം ഡോക്കറിലേക്ക് നിറയ്ക്കൽ... കൂടാതെ 5 TB ഡോക്കറിൽ നിറച്ചാൽ... അല്ലെങ്കിൽ എല്ലാം ശരിയാണോ?

ഡി.എസ്: എന്താണ് വ്യത്യാസം: ഇവ ബ്ലബ്സ് ആണ്, വെറും ബിറ്റുകളും ബൈറ്റുകളും.

НС: വ്യത്യാസം ഇതാണ്: നിങ്ങൾ ഇത് ഡംപ് ആൻഡ് റീസ്റ്റോർ വഴിയാണോ ചെയ്യുന്നത്?

ഡി.എസ്: ഒട്ടും ആവശ്യമില്ല. ഈ ചിത്രം സൃഷ്ടിക്കുന്നതിനുള്ള രീതികൾ വ്യത്യസ്തമായിരിക്കും.

НС: ചില ക്ലയന്റുകൾക്കായി, ഞങ്ങൾ ഇത് നിർമ്മിച്ചിരിക്കുന്നതിനാൽ പതിവായി ഒരു അടിസ്ഥാന ഇമേജ് സൃഷ്ടിക്കുന്നതിനുപകരം, ഞങ്ങൾ അത് നിരന്തരം കാലികമായി നിലനിർത്തുന്നു. ഇത് അടിസ്ഥാനപരമായി ഒരു പകർപ്പാണ്, പക്ഷേ ഇത് മാസ്റ്ററിൽ നിന്ന് നേരിട്ട് അല്ല, ഒരു ആർക്കൈവ് വഴിയാണ് ഡാറ്റ സ്വീകരിക്കുന്നത്. എല്ലാ ദിവസവും WAL-കൾ ഡൗൺലോഡ് ചെയ്യപ്പെടുന്ന ഒരു ബൈനറി ആർക്കൈവ്, അവിടെ ബാക്കപ്പുകൾ എടുക്കുന്നു... ഈ WAL-കൾ ചെറിയ കാലതാമസത്തോടെ അടിസ്ഥാന ഇമേജിൽ എത്തുന്നു (അക്ഷരാർത്ഥത്തിൽ 1-2 സെക്കൻഡ്). ഞങ്ങൾ അതിൽ നിന്ന് ഏതെങ്കിലും വിധത്തിൽ ക്ലോൺ ചെയ്യുന്നു - ഇപ്പോൾ ഞങ്ങൾക്ക് സ്ഥിരസ്ഥിതിയായി ZFS ഉണ്ട്.

ഡി.എസ്: എന്നാൽ ZFS ഉപയോഗിച്ച് നിങ്ങൾ ഒരു നോഡിലേക്ക് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.

НС: അതെ. എന്നാൽ ZFS ന് ഒരു മാന്ത്രികതയുണ്ട് അയയ്ക്കുക: ഇതുപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു സ്നാപ്പ്ഷോട്ട് അയയ്‌ക്കാനും (ഞാൻ ഇത് ഇതുവരെ ശരിക്കും പരീക്ഷിച്ചിട്ടില്ല, പക്ഷേ...) രണ്ടിനും ഇടയിൽ ഒരു ഡെൽറ്റ അയയ്‌ക്കാനും കഴിയും. PGDATA. വാസ്തവത്തിൽ, അത്തരം ജോലികൾക്കായി ഞങ്ങൾ പരിഗണിക്കാത്ത മറ്റൊരു ഉപകരണം ഞങ്ങളുടെ പക്കലുണ്ട്. PostgreSQL ഉണ്ട് pg_rewind, ഒരു "സ്മാർട്ട്" rsync പോലെ പ്രവർത്തിക്കുന്നു, നിങ്ങൾ കാണേണ്ടതില്ലാത്ത പലതും ഒഴിവാക്കുന്നു, കാരണം അവിടെ ഒന്നും മാറിയിട്ടില്ല. നമുക്ക് രണ്ട് സെർവറുകൾക്കിടയിൽ ഒരു ദ്രുത സമന്വയം നടത്താനും അതേ രീതിയിൽ റിവൈൻഡ് ചെയ്യാനും കഴിയും.

അതിനാൽ, ഇതിൽ നിന്ന്, കൂടുതൽ DBA വശത്ത്, നിങ്ങൾ പറഞ്ഞ അതേ കാര്യം ചെയ്യാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ഒരു ടൂൾ സൃഷ്ടിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു: ഞങ്ങൾക്ക് ഒരു ഡാറ്റാബേസ് ഉണ്ട്, എന്നാൽ ഞങ്ങൾ എന്തെങ്കിലും 50 തവണ പരീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്നു, ഏതാണ്ട് ഒരേസമയം.

ഡി.എസ്: 50 തവണ എന്നതിനർത്ഥം നിങ്ങൾ 50 സ്പോട്ട് സംഭവങ്ങൾ ഓർഡർ ചെയ്യേണ്ടതുണ്ട് എന്നാണ്.

НС: ഇല്ല, ഞങ്ങൾ എല്ലാം ഒരു മെഷീനിൽ ചെയ്യുന്നു.

ഡി.എസ്: എന്നാൽ ഈ ഒരു ഡാറ്റാബേസ് ടെറാബൈറ്റ് ആണെങ്കിൽ നിങ്ങൾ എങ്ങനെ 50 മടങ്ങ് വികസിപ്പിക്കും. മിക്കവാറും അവൾക്ക് സോപാധികമായ 256 GB റാം ആവശ്യമുണ്ടോ?

НС: അതെ, ചിലപ്പോൾ നിങ്ങൾക്ക് ധാരാളം മെമ്മറി ആവശ്യമാണ് - അത് സാധാരണമാണ്. എന്നാൽ ഇത് ജീവിതത്തിൽ നിന്നുള്ള ഒരു ഉദാഹരണമാണ്. പ്രൊഡക്ഷൻ മെഷീനിൽ 96 കോറുകളും 600 ജിബിയും ഉണ്ട്. അതേസമയം, ഡാറ്റാബേസിനായി 32 കോറുകളും (ഇപ്പോൾ ചിലപ്പോൾ 16 കോറുകളും) 100-120 ജിബി മെമ്മറിയും ഉപയോഗിക്കുന്നു.

ഡി.എസ്: 50 കോപ്പികൾ അവിടെ യോജിച്ചിട്ടുണ്ടോ?

НС: അതിനാൽ ഒരു പകർപ്പ് മാത്രമേയുള്ളൂ, തുടർന്ന് കോപ്പി-ഓൺ-റൈറ്റ് (ZFS) പ്രവർത്തിക്കുന്നു... ഞാൻ നിങ്ങളോട് കൂടുതൽ വിശദമായി പറയാം.

ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് 10 TB ഡാറ്റാബേസ് ഉണ്ട്. അവർ അതിനായി ഒരു ഡിസ്ക് ഉണ്ടാക്കി, ZFS അതിന്റെ വലുപ്പം 30-40 ശതമാനം വരെ ചുരുക്കി. ഞങ്ങൾ ലോഡ് ടെസ്റ്റിംഗ് നടത്താത്തതിനാൽ, കൃത്യമായ പ്രതികരണ സമയം ഞങ്ങൾക്ക് പ്രധാനമല്ല: ഇത് 2 മടങ്ങ് മന്ദഗതിയിലായിരിക്കട്ടെ - അത് കുഴപ്പമില്ല.

പ്രോഗ്രാമർമാർ, QA, DBA മുതലായവയ്ക്ക് ഞങ്ങൾ അവസരം നൽകുന്നു. 1-2 ത്രെഡുകളിൽ പരിശോധന നടത്തുക. ഉദാഹരണത്തിന്, അവർ ഏതെങ്കിലും തരത്തിലുള്ള മൈഗ്രേഷൻ നടത്തിയേക്കാം. ഇതിന് ഒരേസമയം 10 ​​കോറുകൾ ആവശ്യമില്ല - ഇതിന് 1 പോസ്റ്റ്‌ഗ്രെസ് ബാക്കെൻഡ്, 1 കോർ ആവശ്യമാണ്. മൈഗ്രേഷൻ ആരംഭിക്കും - ഒരുപക്ഷേ ഓട്ടോവാക്വം ഇപ്പോഴും ആരംഭിക്കും, തുടർന്ന് രണ്ടാമത്തെ കോർ ഉപയോഗിക്കും. ഞങ്ങൾക്ക് 16-32 കോറുകൾ അനുവദിച്ചിട്ടുണ്ട്, അതിനാൽ 10 പേർക്ക് ഒരേ സമയം പ്രവർത്തിക്കാം, പ്രശ്‌നമില്ല.

കാരണം ശാരീരികമായി PGDATA അതുപോലെ, ഞങ്ങൾ യഥാർത്ഥത്തിൽ പോസ്റ്റ്‌ഗ്രെസിനെ കബളിപ്പിക്കുകയാണെന്ന് മാറുന്നു. തന്ത്രം ഇതാണ്: ഉദാഹരണത്തിന്, 10 പോസ്റ്റ്‌ഗ്രെസ് ഒരേസമയം സമാരംഭിക്കുന്നു. സാധാരണയായി എന്താണ് പ്രശ്നം? അവർ ഇട്ടു പങ്കിട്ട_ബഫറുകൾ, നമുക്ക് 25% എന്ന് പറയാം. അതനുസരിച്ച്, ഇത് 200 ജിബിയാണ്. നിങ്ങൾക്ക് ഇവയിൽ മൂന്നിൽ കൂടുതൽ സമാരംഭിക്കാൻ കഴിയില്ല, കാരണം മെമ്മറി തീർന്നുപോകും.

എന്നാൽ ചില ഘട്ടങ്ങളിൽ ഇത് ആവശ്യമില്ലെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി: ഞങ്ങൾ പങ്കിട്ട_ബഫറുകൾ 2 GB ആയി സജ്ജമാക്കി. PostgreSQL ഉണ്ട് ഫലപ്രദമായ_കാഷെ_വലിപ്പം, വാസ്തവത്തിൽ അത് മാത്രമേ സ്വാധീനിക്കുന്നുള്ളൂ പദ്ധതികൾ. ഞങ്ങൾ അത് 0,5 TB ആയി സജ്ജമാക്കി. അവ യഥാർത്ഥത്തിൽ നിലവിലില്ല എന്നത് പോലും പ്രശ്നമല്ല: അവ നിലനിൽക്കുന്നതുപോലെ അവൻ പദ്ധതികൾ തയ്യാറാക്കുന്നു.

അതനുസരിച്ച്, ഞങ്ങൾ ഏതെങ്കിലും തരത്തിലുള്ള മൈഗ്രേഷൻ പരീക്ഷിക്കുമ്പോൾ, നമുക്ക് എല്ലാ പ്ലാനുകളും ശേഖരിക്കാൻ കഴിയും - ഉൽപ്പാദനത്തിൽ അത് എങ്ങനെ സംഭവിക്കുമെന്ന് ഞങ്ങൾ കാണും. അവിടെയുള്ള സെക്കൻഡുകൾ വ്യത്യസ്തമായിരിക്കും (മന്ദഗതിയിൽ), എന്നാൽ നമ്മൾ യഥാർത്ഥത്തിൽ വായിക്കുന്ന ഡാറ്റയും പ്ലാനുകളും (എന്തൊക്കെ ജോയിനുകൾ ഉണ്ട്, മുതലായവ) ഉൽപ്പാദനത്തിലെന്നപോലെ തന്നെ മാറുന്നു. നിങ്ങൾക്ക് ഒരു മെഷീനിൽ സമാന്തരമായി അത്തരം നിരവധി പരിശോധനകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയും.

ഡി.എസ്: ഇവിടെ കുറച്ച് പ്രശ്‌നങ്ങളുണ്ടെന്ന് തോന്നുന്നില്ലേ? PostgreSQL-ൽ മാത്രം പ്രവർത്തിക്കുന്ന ഒരു പരിഹാരമാണ് ആദ്യത്തേത്. ഈ സമീപനം വളരെ സ്വകാര്യമാണ്, ഇത് പൊതുവായതല്ല. രണ്ടാമത്തേത്, കുബർനെറ്റസ് (ക്ലൗഡ് സാങ്കേതികവിദ്യകൾ ഇപ്പോൾ പോകുന്ന എല്ലാ കാര്യങ്ങളും) നിരവധി നോഡുകൾ ഉൾക്കൊള്ളുന്നു, ഈ നോഡുകൾ എഫെമെറൽ ആണ്. നിങ്ങളുടെ കാര്യത്തിൽ, ഇത് സ്ഥിരവും സ്ഥിരവുമായ ഒരു നോഡാണ്. ഈ കാര്യങ്ങൾ എന്നെ സംഘർഷഭരിതനാക്കുന്നു.

НС: ആദ്യം, ഞാൻ സമ്മതിക്കുന്നു, ഇത് തികച്ചും പോസ്റ്റ്‌ഗ്രേസ് കഥയാണ്. ഞങ്ങൾക്ക് ഏതെങ്കിലും തരത്തിലുള്ള നേരിട്ടുള്ള ഐഒയും മിക്കവാറും എല്ലാ മെമ്മറികൾക്കും ഒരു ബഫർ പൂളും ഉണ്ടെങ്കിൽ, ഈ സമീപനം പ്രവർത്തിക്കില്ല - പദ്ധതികൾ വ്യത്യസ്തമായിരിക്കും. എന്നാൽ ഇപ്പോൾ ഞങ്ങൾ പോസ്റ്റ്‌ഗ്രെസുമായി മാത്രമേ പ്രവർത്തിക്കൂ, മറ്റുള്ളവരെക്കുറിച്ച് ഞങ്ങൾ ചിന്തിക്കുന്നില്ല.

കുബർനെറ്റസിനെ കുറിച്ച്. ഞങ്ങൾക്ക് സ്ഥിരമായ ഒരു ഡാറ്റാബേസ് ഉണ്ടെന്ന് നിങ്ങൾ തന്നെ എല്ലായിടത്തും ഞങ്ങളോട് പറയുന്നു. സംഭവം പരാജയപ്പെടുകയാണെങ്കിൽ, പ്രധാന കാര്യം ഡിസ്ക് സംരക്ഷിക്കുക എന്നതാണ്. ഇവിടെ നമുക്ക് കുബെർനെറ്റസിലെ മുഴുവൻ പ്ലാറ്റ്‌ഫോമും ഉണ്ട്, പോസ്റ്റ്‌ഗ്രേസുമായുള്ള ഘടകം പ്രത്യേകമാണ് (അത് ഒരു ദിവസം ഉണ്ടെങ്കിലും). അതിനാൽ, എല്ലാം ഇതുപോലെയാണ്: ഉദാഹരണം വീണു, പക്ഷേ ഞങ്ങൾ അതിന്റെ പിവി സംരക്ഷിക്കുകയും ഒന്നും സംഭവിക്കാത്തതുപോലെ മറ്റൊരു (പുതിയ) ഉദാഹരണവുമായി ബന്ധിപ്പിക്കുകയും ചെയ്തു.

ഡി.എസ്: എന്റെ കാഴ്ചപ്പാടിൽ, ഞങ്ങൾ കുബർനെറ്റസിൽ പോഡുകൾ സൃഷ്ടിക്കുന്നു. K8s - ഇലാസ്റ്റിക്: കെട്ടുകൾ ആവശ്യാനുസരണം ക്രമീകരിച്ചിരിക്കുന്നു. ഒരു പോഡ് സൃഷ്‌ടിച്ച് അതിന് എക്‌സ് തുകയുടെ ഉറവിടങ്ങൾ ആവശ്യമാണെന്ന് പറയുക എന്നതാണ് ചുമതല, തുടർന്ന് K8-കൾ അത് സ്വയം കണ്ടെത്തും. എന്നാൽ കുബർനെറ്റിലെ സംഭരണ ​​പിന്തുണ ഇപ്പോഴും അസ്ഥിരമാണ്: 1.16അകത്ത് 1.17 (ഈ റിലീസ് പുറത്തിറങ്ങി ആഴ്ചയിൽ മുമ്പ്) ഈ സവിശേഷതകൾ ബീറ്റ മാത്രമായി മാറും.

ആറ് മാസം മുതൽ ഒരു വർഷം വരെ കടന്നുപോകും - അത് കൂടുതലോ കുറവോ സ്ഥിരത കൈവരിക്കും, അല്ലെങ്കിൽ കുറഞ്ഞത് അത് അങ്ങനെ പ്രഖ്യാപിക്കപ്പെടും. അപ്പോൾ സ്നാപ്പ്ഷോട്ടുകളുടെയും വലുപ്പം മാറ്റുന്നതിന്റെയും സാധ്യത നിങ്ങളുടെ പ്രശ്നം പൂർണ്ണമായും പരിഹരിക്കുന്നു. കാരണം നിങ്ങൾക്ക് ഒരു അടിത്തറയുണ്ട്. അതെ, ഇത് വളരെ വേഗത്തിലായിരിക്കില്ല, പക്ഷേ വേഗത "ഹൂഡിന് കീഴിൽ" എന്താണെന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, കാരണം ചില നടപ്പാക്കലുകൾക്ക് ഡിസ്ക് സബ്സിസ്റ്റം തലത്തിൽ പകർത്താനും പകർത്താനും കഴിയും.

НС: എല്ലാ എഞ്ചിനുകൾക്കും (ആമസോൺ, ഗൂഗിൾ...) ഈ പതിപ്പിനെ പിന്തുണയ്‌ക്കാൻ തുടങ്ങേണ്ടത് അത്യാവശ്യമാണ് - ഇതിന് കുറച്ച് സമയമെടുക്കും.

ഡി.എസ്: ഞങ്ങൾ ഇതുവരെ അവ ഉപയോഗിക്കുന്നില്ല. ഞങ്ങൾ ഞങ്ങളുടേത് ഉപയോഗിക്കുന്നു.

കുബർനെറ്റുകളുടെ പ്രാദേശിക വികസനം

НС: ഒരു മെഷീനിൽ എല്ലാ പോഡുകളും ഇൻസ്റ്റാൾ ചെയ്ത് ഒരു ചെറിയ ടെസ്റ്റ് നടത്തേണ്ടിവരുമ്പോൾ നിങ്ങൾക്ക് അത്തരമൊരു ആഗ്രഹം ഉണ്ടായിട്ടുണ്ടോ. ആശയത്തിന്റെ തെളിവ് വേഗത്തിൽ ലഭിക്കുന്നതിന്, ഒരു കൂട്ടം മെഷീനുകൾ സമർപ്പിക്കാതെ തന്നെ, കുബർനെറ്റസിൽ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നത് കാണുക. മിനിക്യൂബ് ഉണ്ട്, അല്ലേ?

ഡി.എസ്: ഈ കേസ് - ഒരു നോഡിൽ വിന്യസിച്ചിരിക്കുന്നത് - പ്രാദേശിക വികസനം മാത്രമാണെന്ന് എനിക്ക് തോന്നുന്നു. അല്ലെങ്കിൽ അത്തരമൊരു മാതൃകയുടെ ചില പ്രകടനങ്ങൾ. കഴിക്കുക മിനിക്യൂബ്, ഇതുണ്ട് k3 സെ, KIND. ഞങ്ങൾ കുബർനെറ്റസ് ഇൻ ഡോക്കർ ഉപയോഗിക്കുന്നതിലേക്ക് നീങ്ങുകയാണ്. ഇപ്പോൾ ഞങ്ങൾ ടെസ്റ്റുകൾക്കായി ഇത് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങി.

НС: എല്ലാ പോഡുകളും ഒരു ഡോക്കർ ഇമേജിൽ പൊതിയാനുള്ള ശ്രമമാണിതെന്ന് ഞാൻ കരുതിയിരുന്നു. എന്നാൽ ഇത് തികച്ചും വ്യത്യസ്തമായ ഒന്നിനെക്കുറിച്ചാണെന്ന് മനസ്സിലായി. എന്തായാലും, പ്രത്യേക പാത്രങ്ങളുണ്ട്, പ്രത്യേക പോഡുകൾ - ഡോക്കറിൽ മാത്രം.

ഡി.എസ്: അതെ. കൂടാതെ തമാശയുള്ള ഒരു അനുകരണം ഉണ്ടാക്കിയിട്ടുണ്ട്, എന്നാൽ അർത്ഥം ഇതാണ്... വിന്യാസത്തിനായി ഞങ്ങൾക്ക് ഒരു യൂട്ടിലിറ്റി ഉണ്ട് - വെർഫ്. ഞങ്ങൾ അതിനെ ഒരു സോപാധിക മോഡ് ആക്കാൻ ആഗ്രഹിക്കുന്നു werf up: "എനിക്ക് പ്രാദേശിക കുബർനെറ്റുകളെ കൊണ്ടുവരൂ." എന്നിട്ട് അവിടെ കണ്ടീഷണൽ പ്രവർത്തിപ്പിക്കുക werf follow. അപ്പോൾ ഡെവലപ്പർക്ക് IDE എഡിറ്റ് ചെയ്യാൻ കഴിയും, കൂടാതെ മാറ്റങ്ങൾ കാണുകയും ചിത്രങ്ങൾ പുനർനിർമ്മിക്കുകയും പ്രാദേശിക K8-കളിലേക്ക് വീണ്ടും വിന്യസിക്കുകയും ചെയ്യുന്ന ഒരു പ്രക്രിയ സിസ്റ്റത്തിൽ ആരംഭിക്കും. പ്രാദേശിക വികസനത്തിന്റെ പ്രശ്നം പരിഹരിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നത് ഇങ്ങനെയാണ്.

K8s റിയാലിറ്റിയിൽ സ്നാപ്പ്ഷോട്ടുകളും ഡാറ്റാബേസ് ക്ലോണിംഗും

НС: നമ്മൾ കോപ്പി-ഓൺ-റൈറ്റിലേക്ക് മടങ്ങുകയാണെങ്കിൽ. മേഘങ്ങൾക്ക് സ്നാപ്പ്ഷോട്ടുകളും ഉണ്ടെന്ന് ഞാൻ ശ്രദ്ധിച്ചു. അവർ വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു. ഉദാഹരണത്തിന്, GCP-യിൽ: യുണൈറ്റഡ് സ്റ്റേറ്റ്സിന്റെ കിഴക്കൻ തീരത്ത് നിങ്ങൾക്ക് ഒരു മൾട്ടി-ടെറാബൈറ്റ് ഉദാഹരണമുണ്ട്. നിങ്ങൾ ഇടയ്ക്കിടെ സ്നാപ്പ്ഷോട്ടുകൾ എടുക്കുന്നു. നിങ്ങൾ ഒരു സ്നാപ്പ്ഷോട്ടിൽ നിന്ന് പടിഞ്ഞാറൻ തീരത്തുള്ള ഡിസ്കിന്റെ ഒരു പകർപ്പ് എടുക്കുന്നു - കുറച്ച് മിനിറ്റിനുള്ളിൽ എല്ലാം തയ്യാറാണ്, ഇത് വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു, മെമ്മറിയിൽ കാഷെ മാത്രം പൂരിപ്പിക്കേണ്ടതുണ്ട്. എന്നാൽ ഈ ക്ലോണുകൾ (സ്നാപ്പ്ഷോട്ടുകൾ) ഒരു പുതിയ വോള്യം 'പ്രൊവിഷൻ' ചെയ്യാനുള്ളതാണ്. നിങ്ങൾക്ക് ധാരാളം സന്ദർഭങ്ങൾ സൃഷ്ടിക്കേണ്ടിവരുമ്പോൾ ഇത് രസകരമാണ്.

എന്നാൽ ടെസ്റ്റുകൾക്കായി, നിങ്ങൾ ഡോക്കറിൽ സംസാരിക്കുന്ന അല്ലെങ്കിൽ ഞാൻ ZFS, btrfs, LVM എന്നിവയിൽ സംസാരിക്കുന്ന സ്നാപ്പ്ഷോട്ടുകൾ... - ഒരു മെഷീനിൽ യഥാർത്ഥത്തിൽ പുതിയ ഡാറ്റ സൃഷ്ടിക്കാതിരിക്കാൻ അവ നിങ്ങളെ അനുവദിക്കുന്നു. ക്ലൗഡിൽ, നിങ്ങൾ ഓരോ തവണയും അവർക്ക് പണം നൽകുകയും സെക്കൻഡുകളല്ല, മിനിറ്റുകൾ കാത്തിരിക്കുകയും ചെയ്യും (സാഹചര്യത്തിലും അലസമായ ലോഡ്, ഒരുപക്ഷേ ഒരു വാച്ച്).

പകരം, നിങ്ങൾക്ക് ഈ ഡാറ്റ ഒന്നോ രണ്ടോ സെക്കൻഡിനുള്ളിൽ ലഭിക്കും, ടെസ്റ്റ് നടത്തി അത് വലിച്ചെറിയുക. ഈ സ്നാപ്പ്ഷോട്ടുകൾ വ്യത്യസ്ത പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നു. ആദ്യ സന്ദർഭത്തിൽ - സ്കെയിൽ അപ്പ് ചെയ്യാനും പുതിയ പകർപ്പുകൾ നേടാനും, രണ്ടാമത്തേതിൽ - ടെസ്റ്റുകൾക്കും.

ഡി.എസ്: ഞാൻ സമ്മതിക്കുന്നില്ല. വോളിയം ക്ലോണിംഗ് ശരിയായി പ്രവർത്തിക്കുന്നത് ക്ലൗഡിന്റെ ചുമതലയാണ്. അവ നടപ്പിലാക്കുന്നത് ഞാൻ നോക്കിയിട്ടില്ല, പക്ഷേ ഹാർഡ്‌വെയറിൽ ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്യുന്നുവെന്ന് എനിക്കറിയാം. ഞങ്ങൾക്ക് സെഫ് ഉണ്ട്, അത് ഏത് ഫിസിക്കൽ വോളിയവും അനുവദിക്കുന്നു (ആർബിഡി) പറയുക ക്ലോൺ പതിനായിരക്കണക്കിന് മില്ലിസെക്കൻഡിൽ സമാന സ്വഭാവസവിശേഷതകളുള്ള രണ്ടാമത്തെ വോള്യം നേടുക, IOPS'ആമി, മുതലായവ ഉള്ളിൽ ഒരു തന്ത്രപരമായ കോപ്പി-ഓൺ-റൈറ്റുണ്ടെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. എന്തുകൊണ്ട് മേഘവും അങ്ങനെ ചെയ്യാൻ പാടില്ല? അവർ ഇത് ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ ചെയ്യാൻ ശ്രമിക്കുന്നുണ്ടെന്ന് എനിക്ക് ഉറപ്പുണ്ട്.

НС: പക്ഷേ, ഒരു ഉദാഹരണം ഉന്നയിക്കാനും ഡോക്കറെ അവിടെ കൊണ്ടുവരാനും മറ്റും അവർക്ക് സെക്കൻഡുകളും പതിനായിരക്കണക്കിന് സെക്കൻഡും എടുക്കും.

ഡി.എസ്: ഒരു മുഴുവൻ ഉദാഹരണം ഉന്നയിക്കേണ്ടത് എന്തുകൊണ്ട്? ഞങ്ങൾക്ക് 32 കോറുകളുള്ള ഒരു ഉദാഹരണമുണ്ട്, 16... അത് അതിനോട് യോജിക്കും - ഉദാഹരണത്തിന്, നാല്. ഞങ്ങൾ അഞ്ചാമത്തേത് ഓർഡർ ചെയ്യുമ്പോൾ, ഉദാഹരണം ഇതിനകം ഉയർത്തപ്പെടും, തുടർന്ന് അത് ഇല്ലാതാക്കപ്പെടും.

НС: അതെ, രസകരമാണ്, കുബെർനെറ്റസ് മറ്റൊരു കഥയായി മാറുന്നു. ഞങ്ങളുടെ ഡാറ്റാബേസ് K8-ൽ ഇല്ല, ഞങ്ങൾക്ക് ഒരു ഉദാഹരണമുണ്ട്. എന്നാൽ ഒരു മൾട്ടി-ടെറാബൈറ്റ് ഡാറ്റാബേസ് ക്ലോൺ ചെയ്യുന്നതിന് രണ്ട് സെക്കൻഡിൽ കൂടുതൽ എടുക്കുന്നില്ല.

ഡി.എസ്: ഇത് കൊള്ളാം. എന്നാൽ ഇത് ഒരു പൊതു പരിഹാരമല്ല എന്നതാണ് എന്റെ പ്രാരംഭ പോയിന്റ്. അതെ, ഇത് രസകരമാണ്, പക്ഷേ ഇത് പോസ്റ്റ്ഗ്രെസിന് മാത്രം അനുയോജ്യമാണ്, ഒരു നോഡിൽ മാത്രം.

НС: ഇത് പോസ്റ്റ്ഗ്രെസിന് മാത്രമല്ല അനുയോജ്യമാണ്: ഈ പ്ലാനുകൾ, ഞാൻ വിവരിച്ചതുപോലെ, അതിൽ മാത്രമേ പ്രവർത്തിക്കൂ. എന്നാൽ ഞങ്ങൾ പ്ലാനുകളെ കുറിച്ച് വിഷമിക്കുന്നില്ലെങ്കിൽ, ഫങ്ഷണൽ ടെസ്റ്റിംഗിനായി ഞങ്ങൾക്ക് എല്ലാ ഡാറ്റയും ആവശ്യമുണ്ടെങ്കിൽ, ഇത് ഏത് ഡിബിഎംഎസിനും അനുയോജ്യമാണ്.

ഡി.എസ്: വളരെ വർഷങ്ങൾക്ക് മുമ്പ് ഞങ്ങൾ എൽവിഎം സ്നാപ്പ്ഷോട്ടുകളിൽ സമാനമായ ഒന്ന് ചെയ്തു. ഇതൊരു ക്ലാസിക് ആണ്. ഈ സമീപനം വളരെ സജീവമായി ഉപയോഗിച്ചു. സ്റ്റേറ്റ്ഫുൾ നോഡുകൾ ഒരു വേദന മാത്രമാണ്. കാരണം നിങ്ങൾ അവരെ ഉപേക്ഷിക്കരുത്, നിങ്ങൾ അവരെ എപ്പോഴും ഓർക്കണം ...

НС: ഇവിടെ ഒരു ഹൈബ്രിഡ് സാധ്യത കാണുന്നുണ്ടോ? സ്റ്റേറ്റ്‌ഫുൾ എന്നത് ഒരുതരം പോഡ് ആണെന്നിരിക്കട്ടെ, ഇത് നിരവധി ആളുകൾക്ക് (നിരവധി പരീക്ഷകർ) പ്രവർത്തിക്കുന്നു. ഞങ്ങൾക്ക് ഒരു വോള്യം ഉണ്ട്, എന്നാൽ ഫയൽ സിസ്റ്റത്തിന് നന്ദി, ക്ലോണുകൾ പ്രാദേശികമാണ്. പോഡ് വീണു, പക്ഷേ ഡിസ്ക് അവശേഷിക്കുന്നുവെങ്കിൽ, പോഡ് ഉയരും, എല്ലാ ക്ലോണുകളെക്കുറിച്ചുള്ള വിവരങ്ങളും എണ്ണുക, എല്ലാം വീണ്ടും എടുത്ത് പറയുക: "ഇതാ നിങ്ങളുടെ ക്ലോണുകൾ ഈ പോർട്ടുകളിൽ പ്രവർത്തിക്കുന്നു, അവയുമായി പ്രവർത്തിക്കുന്നത് തുടരുക."

ഡി.എസ്: സാങ്കേതികമായി ഇതിനർത്ഥം കുബെർനെറ്റിനുള്ളിൽ ഇത് ഒരു പോഡ് ആണ്, അതിനുള്ളിൽ ഞങ്ങൾ നിരവധി പോസ്റ്റ്‌ഗ്രെസ് പ്രവർത്തിപ്പിക്കുന്നു.

НС: അതെ. അവന് ഒരു പരിധിയുണ്ട്: ഒരേ സമയം 10-ൽ കൂടുതൽ ആളുകൾ അവനോടൊപ്പം പ്രവർത്തിക്കരുത്. നിങ്ങൾക്ക് 20 ആവശ്യമുണ്ടെങ്കിൽ, ഞങ്ങൾ അത്തരത്തിലുള്ള രണ്ടാമത്തെ പോഡ് ലോഞ്ച് ചെയ്യും. ഞങ്ങൾ ഇത് പൂർണ്ണമായും ക്ലോൺ ചെയ്യും, രണ്ടാമത്തെ പൂർണ്ണ വോളിയം ലഭിച്ചുകഴിഞ്ഞാൽ, അതിന് അതേ 10 "നേർത്ത" ക്ലോണുകൾ ഉണ്ടാകും. ഈ അവസരം നിങ്ങൾ കാണുന്നില്ലേ?

ഡി.എസ്: ഞങ്ങൾ ഇവിടെ സുരക്ഷാ പ്രശ്നങ്ങൾ ചേർക്കേണ്ടതുണ്ട്. ഈ പോഡിന് ഉയർന്ന പ്രത്യേകാവകാശങ്ങൾ (കഴിവുകൾ) ഉണ്ടെന്ന് ഇത്തരത്തിലുള്ള ഓർഗനൈസേഷൻ സൂചിപ്പിക്കുന്നു, കാരണം ഇതിന് ഫയൽ സിസ്റ്റത്തിൽ നിലവാരമില്ലാത്ത പ്രവർത്തനങ്ങൾ നടത്താൻ കഴിയും... എന്നാൽ ഞാൻ ആവർത്തിക്കുന്നു: ഇടത്തരം കാലയളവിൽ അവർ കുബെർനെറ്റസിലും, കൂടാതെ മേഘങ്ങൾ അവർ മുഴുവൻ കഥയും വോള്യങ്ങൾ ഉപയോഗിച്ച് ശരിയാക്കും - എല്ലാം "വെറും പ്രവർത്തിക്കും". വലുപ്പം മാറ്റൽ, ക്ലോണിംഗ് എന്നിവ ഉണ്ടാകും ... ഒരു വോളിയം ഉണ്ട് - ഞങ്ങൾ പറയുന്നു: "അതിനെ അടിസ്ഥാനമാക്കി പുതിയൊരെണ്ണം സൃഷ്ടിക്കുക," ഒന്നര സെക്കന്റ് കഴിഞ്ഞ് നമുക്ക് ആവശ്യമുള്ളത് ലഭിക്കും.

НС: ഒന്നര സെക്കന്റിൽ പല ടെറാബൈറ്റുകളും ഞാൻ വിശ്വസിക്കുന്നില്ല. സെഫിൽ നിങ്ങൾ അത് സ്വയം ചെയ്യുന്നു, പക്ഷേ നിങ്ങൾ മേഘങ്ങളെക്കുറിച്ച് സംസാരിക്കുന്നു. ക്ലൗഡിലേക്ക് പോയി, EC2-ൽ ഒരു മൾട്ടി-ടെറാബൈറ്റ് EBS വോള്യത്തിന്റെ ഒരു ക്ലോൺ ഉണ്ടാക്കി പ്രകടനം എന്തായിരിക്കുമെന്ന് കാണുക. ഇതിന് കുറച്ച് നിമിഷങ്ങൾ എടുക്കില്ല. അവർ എപ്പോൾ ഈ നിലയിലെത്തുമെന്ന് എനിക്ക് വളരെ താൽപ്പര്യമുണ്ട്. നിങ്ങൾ പറയുന്നത് ഞാൻ മനസ്സിലാക്കുന്നു, പക്ഷേ ഞാൻ വിയോജിക്കുന്നു.

ഡി.എസ്: ശരി, പക്ഷെ ഞാൻ പറഞ്ഞത് മീഡിയം ടേമിലാണ്, ഹ്രസ്വകാലമല്ല. കുറേ വർഷങ്ങളായി.

Zalando-ൽ നിന്നുള്ള PostgreSQL-നുള്ള ഓപ്പറേറ്ററെ കുറിച്ച്

ഈ മീറ്റിംഗിന്റെ മധ്യത്തിൽ, സലാൻഡോയിൽ നിന്നുള്ള മുൻ ഡെവലപ്പറായ അലക്സി ക്ല്യൂക്കിനും പോസ്റ്റ്‌ഗ്രെഎസ്‌ക്യുഎൽ ഓപ്പറേറ്ററുടെ ചരിത്രത്തെക്കുറിച്ച് സംസാരിച്ചു:

ഈ വിഷയം പൊതുവായി സ്പർശിക്കുന്നത് വളരെ നല്ലതാണ്: പോസ്റ്റ്ഗ്രെസും കുബർനെറ്റസും. 2017-ൽ ഞങ്ങൾ സലാൻഡോയിൽ ഇത് ചെയ്യാൻ തുടങ്ങിയപ്പോൾ, എല്ലാവരും ചെയ്യാൻ ആഗ്രഹിച്ച ഒരു വിഷയമായിരുന്നു അത്, പക്ഷേ ആരും ചെയ്തില്ല. എല്ലാവർക്കും ഇതിനകം കുബെർനെറ്റുകൾ ഉണ്ടായിരുന്നു, എന്നാൽ ഡാറ്റാബേസുകൾ എന്തുചെയ്യണമെന്ന് അവർ ചോദിച്ചപ്പോൾ, ആളുകൾ പോലും ഇഷ്ടപ്പെടുന്നു കെൽസി ഹൈടവർ, K8s പ്രസംഗിച്ച, ഇതുപോലൊന്ന് പറഞ്ഞു:

“നിയന്ത്രിത സേവനങ്ങളിലേക്ക് പോയി അവ ഉപയോഗിക്കുക, കുബർനെറ്റിലെ ഡാറ്റാബേസ് പ്രവർത്തിപ്പിക്കരുത്. അല്ലെങ്കിൽ, നിങ്ങളുടെ K8-കൾ തീരുമാനിക്കും, ഉദാഹരണത്തിന്, ഒരു നവീകരണം നടത്താനും എല്ലാ നോഡുകളും ഓഫാക്കാനും നിങ്ങളുടെ ഡാറ്റ വളരെ ദൂരത്തേക്ക് പറക്കും.

ഈ ഉപദേശത്തിന് വിരുദ്ധമായി, Kubernetes-ൽ ഒരു Postgres ഡാറ്റാബേസ് സമാരംഭിക്കുന്ന ഒരു ഓപ്പറേറ്ററെ നിർമ്മിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഞങ്ങൾക്ക് ഒരു നല്ല കാരണമുണ്ടായിരുന്നു - പത്രോണി. ഇത് PostgreSQL-നുള്ള ഒരു ഓട്ടോമാറ്റിക് പരാജയമാണ്, ശരിയായി ചെയ്തു, അതായത്. ക്ലസ്റ്ററിനെക്കുറിച്ചുള്ള വിവരങ്ങളുടെ സംഭരണമായി etcd, കോൺസൽ അല്ലെങ്കിൽ ZooKeeper ഉപയോഗിക്കുന്നു. ചോദിക്കുന്ന എല്ലാവർക്കും നൽകുന്ന അത്തരമൊരു ശേഖരം, ഉദാഹരണത്തിന്, നിലവിലെ നേതാവ് എന്താണെന്ന്, ഒരേ വിവരങ്ങൾ - ഞങ്ങൾക്ക് എല്ലാം വിതരണം ചെയ്തിട്ടുണ്ടെങ്കിലും - തലച്ചോറ് പിളരാതിരിക്കാൻ. കൂടാതെ ഞങ്ങൾക്ക് ഉണ്ടായിരുന്നു ഡോക്കർ ചിത്രം അവനു വേണ്ടി.

പൊതുവേ, ഒരു ആന്തരിക ഹാർഡ്‌വെയർ ഡാറ്റാ സെന്ററിൽ നിന്ന് ക്ലൗഡിലേക്ക് മൈഗ്രേറ്റ് ചെയ്‌തതിന് ശേഷം കമ്പനിയുടെ ഓട്ടോ പരാജയത്തിന്റെ ആവശ്യകത പ്രത്യക്ഷപ്പെട്ടു. ക്ലൗഡ് ഒരു പ്രൊപ്രൈറ്ററി PaaS (പ്ലാറ്റ്ഫോം-ആസ്-എ-സർവീസ്) സൊല്യൂഷൻ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഇത് ഓപ്പൺ സോഴ്‌സാണ്, പക്ഷേ ഇത് പ്രവർത്തനക്ഷമമാക്കാൻ വളരെയധികം പരിശ്രമിച്ചു. വിളിച്ചിരുന്നു STUPS.

തുടക്കത്തിൽ, കുബർനെറ്റസ് ഇല്ലായിരുന്നു. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, ഞങ്ങളുടെ സ്വന്തം പരിഹാരം വിന്യസിച്ചപ്പോൾ, K8s ഇതിനകം നിലവിലുണ്ടായിരുന്നു, പക്ഷേ അത് വളരെ അസംസ്കൃതമായിരുന്നു, അത് ഉൽപ്പാദനത്തിന് അനുയോജ്യമല്ല. എന്റെ അഭിപ്രായത്തിൽ അത് 2015 അല്ലെങ്കിൽ 2016 ആയിരുന്നു. 2017 ആയപ്പോഴേക്കും കുബർനെറ്റസ് കൂടുതലോ കുറവോ പക്വത പ്രാപിച്ചു-അവിടേക്ക് കുടിയേറേണ്ട ആവശ്യമുണ്ടായിരുന്നു.

ഞങ്ങൾക്ക് ഇതിനകം ഒരു ഡോക്കർ കണ്ടെയ്‌നർ ഉണ്ടായിരുന്നു. ഡോക്കർ ഉപയോഗിക്കുന്ന ഒരു PaaS ഉണ്ടായിരുന്നു. എന്തുകൊണ്ട് K8s പരീക്ഷിച്ചുകൂടാ? എന്തുകൊണ്ട് നിങ്ങളുടെ സ്വന്തം ഓപ്പറേറ്റർ എഴുതരുത്? അവിറ്റോയിൽ നിന്ന് ഞങ്ങളുടെ അടുത്തെത്തിയ മുറാത്ത് കബിലോവ് ഇത് സ്വന്തം മുൻകൈയിൽ ഒരു പ്രോജക്റ്റായി ആരംഭിച്ചു - “കളിക്കാൻ” - പ്രോജക്റ്റ് “തുടങ്ങി.”

എന്നാൽ പൊതുവേ, ഞാൻ AWS നെക്കുറിച്ച് സംസാരിക്കാൻ ആഗ്രഹിച്ചു. എന്തുകൊണ്ടാണ് ചരിത്രപരമായ AWS-മായി ബന്ധപ്പെട്ട കോഡ് ഉണ്ടായത്...

നിങ്ങൾ Kubernetes-ൽ എന്തെങ്കിലും പ്രവർത്തിപ്പിക്കുമ്പോൾ, K8s അത്തരത്തിലുള്ള ഒരു ജോലിയാണ് പുരോഗമിക്കുന്നതെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ഇത് നിരന്തരം വികസിക്കുകയും മെച്ചപ്പെടുത്തുകയും കാലാകാലങ്ങളിൽ തകരുകയും ചെയ്യുന്നു. കുബെർനെറ്റസിലെ എല്ലാ മാറ്റങ്ങളും നിങ്ങൾ സൂക്ഷ്മമായി നിരീക്ഷിക്കേണ്ടതുണ്ട്, എന്തെങ്കിലും സംഭവിച്ചാൽ അതിൽ മുഴുകാൻ നിങ്ങൾ തയ്യാറാകുകയും അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് വിശദമായി പഠിക്കുകയും വേണം - ഒരുപക്ഷേ നിങ്ങൾ ആഗ്രഹിക്കുന്നതിലും കൂടുതൽ. ഇത് തത്വത്തിൽ, നിങ്ങളുടെ ഡാറ്റാബേസുകൾ പ്രവർത്തിപ്പിക്കുന്ന ഏത് പ്ലാറ്റ്ഫോമിനും ബാധകമാണ്...

അതിനാൽ, ഞങ്ങൾ പ്രസ്താവന നടത്തിയപ്പോൾ, ഞങ്ങൾക്ക് പോസ്റ്റ്‌ഗ്രെസ് ഒരു ബാഹ്യ വോള്യത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നു (ഈ സാഹചര്യത്തിൽ EBS, ഞങ്ങൾ AWS-ൽ പ്രവർത്തിക്കുന്നതിനാൽ). ഡാറ്റാബേസ് വളർന്നു, ചില ഘട്ടങ്ങളിൽ അതിന്റെ വലുപ്പം മാറ്റേണ്ടത് ആവശ്യമാണ്: ഉദാഹരണത്തിന്, EBS ന്റെ പ്രാരംഭ വലുപ്പം 100 TB ആയിരുന്നു, ഡാറ്റാബേസ് അതിലേക്ക് വളർന്നു, ഇപ്പോൾ ഞങ്ങൾ EBS 200 TB ആക്കാൻ ആഗ്രഹിക്കുന്നു. എങ്ങനെ? ഒരു പുതിയ സന്ദർഭത്തിൽ നിങ്ങൾക്ക് ഒരു ഡംപ്/പുനഃസ്ഥാപിക്കാൻ കഴിയുമെന്ന് പറയാം, എന്നാൽ ഇത് വളരെ സമയമെടുക്കുകയും പ്രവർത്തനരഹിതമാക്കുകയും ചെയ്യും.

അതിനാൽ, ഇബിഎസ് പാർട്ടീഷൻ വലുതാക്കുകയും പുതിയ സ്പേസ് ഉപയോഗിക്കാൻ ഫയൽ സിസ്റ്റത്തോട് പറയുകയും ചെയ്യുന്ന ഒരു വലുപ്പം ഞാൻ ആഗ്രഹിച്ചു. ഞങ്ങൾ അത് ചെയ്തു, പക്ഷേ ആ സമയത്ത് കുബർനെറ്റസിന് വലുപ്പം മാറ്റുന്നതിനുള്ള API ഒന്നും ഇല്ലായിരുന്നു. ഞങ്ങൾ AWS-ൽ പ്രവർത്തിച്ചതിനാൽ, അതിന്റെ API-യ്‌ക്കായി ഞങ്ങൾ കോഡ് എഴുതി.

മറ്റ് പ്ലാറ്റ്‌ഫോമുകൾക്കായി ഇത് ചെയ്യുന്നതിൽ നിന്ന് ആരും നിങ്ങളെ തടയുന്നില്ല. ഇത് AWS-ൽ മാത്രമേ പ്രവർത്തിപ്പിക്കാൻ കഴിയൂ, മറ്റെല്ലാ കാര്യങ്ങളിലും ഇത് പ്രവർത്തിക്കില്ലെന്നും പ്രസ്താവനയിൽ സൂചനയില്ല. പൊതുവേ, ഇതൊരു ഓപ്പൺ സോഴ്സ് പ്രോജക്റ്റാണ്: പുതിയ API-യുടെ ഉപയോഗം വേഗത്തിലാക്കാൻ ആരെങ്കിലും ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് സ്വാഗതം. കഴിക്കുക സാമൂഹികം, അഭ്യർത്ഥനകൾ പിൻവലിക്കുക - സലാൻഡോ ടീം അവയോട് വളരെ വേഗത്തിൽ പ്രതികരിക്കാനും ഓപ്പറേറ്ററെ പ്രോത്സാഹിപ്പിക്കാനും ശ്രമിക്കുന്നു. എനിക്കറിയാവുന്നിടത്തോളം, പദ്ധതി പങ്കെടുത്തു Google സമ്മർ ഓഫ് കോഡിലും സമാനമായ മറ്റ് ചില സംരംഭങ്ങളിലും. സലാൻഡോ അതിൽ വളരെ സജീവമായി പ്രവർത്തിക്കുന്നു.

PS ബോണസ്!

PostgreSQL, Kubernetes എന്നീ വിഷയങ്ങളിൽ നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, അടുത്ത പോസ്റ്റ്‌ഗ്രേസ് ചൊവ്വാഴ്ച കഴിഞ്ഞ ആഴ്ച നടന്നിരുന്നു, അവിടെ ഞാൻ നിക്കോളായിയുമായി സംസാരിച്ചു. സലാൻഡോയിൽ നിന്നുള്ള അലക്സാണ്ടർ കുകുഷ്കിൻ. അതിൽ നിന്നുള്ള വീഡിയോ ലഭ്യമാണ് ഇവിടെ.

പിപിഎസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «കുബർനെറ്റസിലേക്കുള്ള കസാന്ദ്രയുടെ കുടിയേറ്റം: സവിശേഷതകളും പരിഹാരങ്ങളും";
• «കുബർനെറ്റസിലേക്കുള്ള മോംഗോഡിബിയുടെ തടസ്സമില്ലാത്ത മൈഗ്രേഷൻ";
• «RabbitMQ-ന്റെ കുബർനെറ്റസിലേക്കുള്ള തടസ്സങ്ങളില്ലാത്ത കുടിയേറ്റം".

അവലംബം: www.habr.com