കുബർനെറ്റസിലെ ഡാറ്റ സംഭരണ ​​പാറ്റേണുകൾ

ഹേ ഹബർ!

വളരെ രസകരവും ഉപയോഗപ്രദവുമായ മറ്റൊന്ന് ഞങ്ങൾ പുറത്തിറക്കിയതായി ഞങ്ങൾ നിങ്ങളെ ഓർമ്മിപ്പിക്കുന്നു ഒരു പുസ്തകം കുബർനെറ്റസ് പാറ്റേണുകളെക്കുറിച്ച്. ഇതെല്ലാം ആരംഭിച്ചത് "പാറ്റേണുകൾ" ബ്രണ്ടൻ ബേൺസ്, കൂടാതെ, ഈ സെഗ്‌മെൻ്റിൽ ഞങ്ങൾക്ക് ജോലിയുണ്ട് തിളച്ചുമറിയുന്നു. MinIO ബ്ലോഗിൽ നിന്നുള്ള ഒരു ലേഖനം വായിക്കാൻ ഇന്ന് ഞങ്ങൾ നിങ്ങളെ ക്ഷണിക്കുന്നു, അത് Kubernetes-ലെ ഡാറ്റ സ്റ്റോറേജ് പാറ്റേണുകളുടെ ട്രെൻഡുകളും പ്രത്യേകതകളും സംക്ഷിപ്തമായി വിവരിക്കുന്നു.

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

ഈ ത്വരണം സാധ്യമാക്കുന്നത് കുബെർനെറ്റസ് നൽകുന്ന അമൂർത്തീകരണം വഴിയാണ് - അതായത്, ഫിസിക്കൽ അല്ലെങ്കിൽ വെർച്വൽ മെഷീനുകളുടെ താഴ്ന്ന നിലയിലുള്ള വിശദാംശങ്ങളുമായി കുബർനെറ്റ്സ് തന്നെ ഇടപഴകുന്നു, ഇത് ഉപയോക്താക്കളെ ആവശ്യമുള്ള പ്രോസസ്സർ, ആവശ്യമുള്ള മെമ്മറി, കണ്ടെയ്നറിൻ്റെ എണ്ണം എന്നിവ പ്രഖ്യാപിക്കാൻ അനുവദിക്കുന്നു. മറ്റ് പാരാമീറ്ററുകൾക്കൊപ്പം ഉദാഹരണങ്ങൾ. കുബെർനെറ്റസിനെ പിന്തുണയ്‌ക്കുന്ന ഒരു വലിയ കമ്മ്യൂണിറ്റിയും അതിൻ്റെ ദത്തെടുക്കൽ തുടർച്ചയായി വികസിച്ചുകൊണ്ടിരിക്കുന്നതിനാൽ, എല്ലാ കണ്ടെയ്‌നർ ഓർക്കസ്‌ട്രേഷൻ പ്ലാറ്റ്‌ഫോമുകളിലും വിശാലമായ മാർജിനിൽ കുബർനെറ്റസ് നേതാവാണ്.

കുബർനെറ്റസിൻ്റെ ഉപയോഗം വർദ്ധിക്കുന്നതിനനുസരിച്ച്, അതിൻ്റെ സംഭരണ ​​പാറ്റേണുകളെക്കുറിച്ചുള്ള ആശയക്കുഴപ്പം വർദ്ധിക്കുന്നു..

കുബെർനെറ്റസ് പൈയുടെ (അതായത്, ഡാറ്റ സംഭരണം) എല്ലാവരും മത്സരിക്കുന്നതിനാൽ, ഡാറ്റ സംഭരണത്തിൻ്റെ കാര്യത്തിൽ, സിഗ്നൽ വളരെയധികം ശബ്ദത്തിൽ മുങ്ങിപ്പോകുന്നു.
ആപ്ലിക്കേഷൻ ഡെവലപ്‌മെൻ്റ്, വിന്യാസം, മാനേജ്‌മെൻ്റ് എന്നിവയ്‌ക്കായുള്ള ആധുനിക മാതൃകയാണ് കുബർനെറ്റസ് ഉൾക്കൊള്ളുന്നത്. ഈ ആധുനിക മോഡൽ കംപ്യൂട്ടേഷനിൽ നിന്ന് ഡാറ്റ സംഭരണത്തെ വിഘടിപ്പിക്കുന്നു. Kubernetes-ൻ്റെ പശ്ചാത്തലത്തിൽ ഡിറ്റാച്ച്‌മെൻ്റ് പൂർണ്ണമായി മനസ്സിലാക്കാൻ, സ്‌റ്റേറ്റ്‌ഫുൾ, സ്‌റ്റേറ്റ്‌ലെസ്സ് ആപ്ലിക്കേഷനുകൾ എന്താണെന്നും ഡാറ്റ സ്റ്റോറേജ് അതിനോട് എങ്ങനെ യോജിക്കുന്നുവെന്നും നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ഇവിടെയാണ് S3 ഉപയോഗിക്കുന്ന REST API സമീപനത്തിന് മറ്റ് പരിഹാരങ്ങളുടെ POSIX/CSI സമീപനത്തേക്കാൾ വ്യക്തമായ ഗുണങ്ങളുള്ളത്.

ഈ ലേഖനത്തിൽ, ഞങ്ങൾ Kubernetes-ലെ ഡാറ്റാ സ്റ്റോറേജ് പാറ്റേണുകളെക്കുറിച്ച് സംസാരിക്കും കൂടാതെ അവ തമ്മിലുള്ള വ്യത്യാസം എന്താണെന്നും എന്തുകൊണ്ട് അത് പ്രധാനമാണെന്നും നന്നായി മനസ്സിലാക്കാൻ സ്റ്റേറ്റ്ഫുൾ, സ്റ്റേറ്റ്ലെസ് ആപ്ലിക്കേഷനുകൾ തമ്മിലുള്ള സംവാദത്തിൽ സ്പർശിക്കുകയും ചെയ്യും. കണ്ടെയ്‌നറുകളിലും കുബർനെറ്റുകളിലും പ്രവർത്തിക്കുന്നതിനുള്ള മികച്ച രീതികളുടെ വെളിച്ചത്തിൽ ബാക്കിയുള്ള വാചകം ആപ്ലിക്കേഷനുകളും അവയുടെ ഡാറ്റ സംഭരണ ​​പാറ്റേണുകളും പരിശോധിക്കും.

നിലയില്ലാത്ത കണ്ടെയ്നറുകൾ

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

സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്നറുകൾ

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

തികച്ചും സാങ്കേതിക വീക്ഷണകോണിൽ നിന്ന്, സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്നറുകൾ മറ്റ് നോഡുകളിലേക്ക് നീക്കാൻ കഴിയും. വിതരണം ചെയ്ത ഫയൽ സിസ്റ്റങ്ങൾ ഉപയോഗിച്ചോ അല്ലെങ്കിൽ പ്രവർത്തിക്കുന്ന എല്ലാ നോഡുകളിലേക്കും ഘടിപ്പിച്ചിട്ടുള്ള നെറ്റ്‌വർക്ക് സ്റ്റോറേജ് ബ്ലോക്ക് ഉപയോഗിച്ചോ ആണ് ഇത് സാധാരണയായി നേടുന്നത്. ഈ രീതിയിൽ, സ്ഥിരമായ ഡാറ്റ സംഭരണത്തിനായി കണ്ടെയ്നറുകൾ വോളിയം ആക്സസ് ചെയ്യുന്നു, കൂടാതെ നെറ്റ്വർക്കിലുടനീളം സ്ഥിതി ചെയ്യുന്ന ഡിസ്കുകളിൽ വിവരങ്ങൾ സംഭരിക്കുന്നു. ഞാൻ ഈ രീതിയെ വിളിക്കും "സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്നർ സമീപനം", കൂടാതെ ലേഖനത്തിൻ്റെ ബാക്കി ഭാഗങ്ങളിൽ ഞാൻ അതിനെ ഏകീകൃതതയ്ക്കായി വിളിക്കും.

ഒരു സാധാരണ സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്‌നർ സമീപനത്തിൽ, എല്ലാ ആപ്ലിക്കേഷൻ പോഡുകളും ഒരൊറ്റ വിതരണം ചെയ്ത ഫയൽ സിസ്റ്റത്തിൽ ഘടിപ്പിച്ചിരിക്കുന്നു-എല്ലാ ആപ്ലിക്കേഷൻ ഡാറ്റയും താമസിക്കുന്ന ഒരു തരം പങ്കിട്ട സംഭരണം. ചില വ്യതിയാനങ്ങൾ സാധ്യമാണെങ്കിലും, ഇത് ഒരു ഉയർന്ന തലത്തിലുള്ള സമീപനമാണ്.

ഒരു ക്ലൗഡ് കേന്ദ്രീകൃത ലോകത്ത് സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്‌നർ സമീപനം ഒരു വിരുദ്ധ പാറ്റേണായിരിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് ഇപ്പോൾ നോക്കാം.

ക്ലൗഡ്-നേറ്റീവ് ആപ്ലിക്കേഷൻ ഡിസൈൻ

പരമ്പരാഗതമായി, ആപ്ലിക്കേഷനുകൾ വിവരങ്ങളുടെയും ലോക്കൽ ഡിസ്കുകളുടെയും ഘടനാപരമായ സംഭരണത്തിനായി ഡാറ്റാബേസുകൾ ഉപയോഗിച്ചു അല്ലെങ്കിൽ എല്ലാ ഘടനാരഹിതമായ അല്ലെങ്കിൽ അർദ്ധ-ഘടനാപരമായ ഡാറ്റ പോലും വലിച്ചെറിയപ്പെടുന്ന വിതരണം ചെയ്ത ഫയൽ സിസ്റ്റങ്ങൾ. ഘടനാരഹിതമായ ഡാറ്റയുടെ അളവ് വർദ്ധിച്ചതോടെ, POSIX വളരെ ചാറ്റിയാണെന്നും, കാര്യമായ ഓവർഹെഡുണ്ടെന്നും, യഥാർത്ഥത്തിൽ വലിയ സ്കെയിലുകളിലേക്ക് നീങ്ങുമ്പോൾ ആപ്ലിക്കേഷൻ പ്രകടനത്തെ തടസ്സപ്പെടുത്തുന്നുവെന്നും ഡെവലപ്പർമാർ മനസ്സിലാക്കി.

ഇത് പ്രധാനമായും REST API-യെ അടിസ്ഥാനമാക്കി പ്രവർത്തിക്കുന്ന ക്ലൗഡ് അധിഷ്‌ഠിത സംഭരണം, ഒരു പ്രാദേശിക ഡാറ്റാ സംഭരണത്തിൻ്റെ ഭാരമുള്ള അറ്റകുറ്റപ്പണികളിൽ നിന്ന് ആപ്ലിക്കേഷനെ മോചിപ്പിക്കുന്നതിന്, ഡാറ്റ സംഭരണത്തിനായി ഒരു പുതിയ മാനദണ്ഡത്തിൻ്റെ ആവിർഭാവത്തിന് കാരണമായി. ഈ സാഹചര്യത്തിൽ, ആപ്ലിക്കേഷൻ ഫലപ്രദമായി സ്റ്റേറ്റ്ലെസ് മോഡിലേക്ക് പോകുന്നു (സംസ്ഥാനം വിദൂര സംഭരണത്തിലായതിനാൽ). ഈ ഘടകം മനസ്സിൽ വെച്ചാണ് ആധുനിക ആപ്ലിക്കേഷനുകൾ ആദ്യം മുതൽ നിർമ്മിച്ചിരിക്കുന്നത്. ചട്ടം പോലെ, ഒരു തരത്തിലുള്ള അല്ലെങ്കിൽ മറ്റൊന്നിൻ്റെ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്ന ഏതൊരു ആധുനിക ആപ്ലിക്കേഷനും (ലോഗുകൾ, മെറ്റാഡാറ്റ, ബ്ലോബ്സ് മുതലായവ) ഒരു ക്ലൗഡ്-ഓറിയൻ്റഡ് മാതൃക അനുസരിച്ചാണ് നിർമ്മിച്ചിരിക്കുന്നത്, അവിടെ സംസ്ഥാനം അതിൻ്റെ സംഭരണത്തിനായി പ്രത്യേകം സമർപ്പിച്ചിരിക്കുന്ന ഒരു സോഫ്റ്റ്വെയർ സിസ്റ്റത്തിലേക്ക് മാറ്റുന്നു.

സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്നർ സമീപനം ഈ മുഴുവൻ മാതൃകയെയും അത് ആരംഭിച്ചിടത്ത് തന്നെ തിരികെ കൊണ്ടുവരാൻ പ്രേരിപ്പിക്കുന്നു!

ഡാറ്റ സംഭരിക്കുന്നതിന് POSIX ഇൻ്റർഫേസുകൾ ഉപയോഗിക്കുന്നതിലൂടെ, ആപ്ലിക്കേഷനുകൾ അവ സ്‌റ്റേറ്റ്‌ഫുൾ പോലെ പ്രവർത്തിക്കുന്നു, ഇക്കാരണത്താൽ, ക്ലൗഡ് കേന്ദ്രീകൃത രൂപകൽപ്പനയുടെ ഏറ്റവും പ്രധാനപ്പെട്ട തത്ത്വങ്ങളിൽ നിന്ന് അവ പുറപ്പെടുന്നു, അതായത്, ഇൻകമിംഗ് അനുസരിച്ച് ആപ്ലിക്കേഷൻ വർക്കർ ത്രെഡുകളുടെ വലുപ്പം മാറ്റാനുള്ള കഴിവ്. ഇൻപുട്ട് ലോഡ് ചെയ്യുക, നിലവിലെ നോഡ് പരാജയപ്പെടുമ്പോൾ ഉടൻ ഒരു പുതിയ നോഡിലേക്ക് നീങ്ങുക തുടങ്ങിയവ.

ഈ സാഹചര്യം സൂക്ഷ്മമായി പരിശോധിക്കുമ്പോൾ, ഒരു ഡാറ്റ സ്റ്റോർ തിരഞ്ഞെടുക്കുമ്പോൾ, ഞങ്ങൾ വീണ്ടും വീണ്ടും POSIX വേഴ്സസ് REST API ദ്വന്ദ്വത്തെ അഭിമുഖീകരിക്കുന്നതായി ഞങ്ങൾ കണ്ടെത്തുന്നു, എന്നാൽ Kubernetes പരിതസ്ഥിതികളുടെ വിതരണ സ്വഭാവം കാരണം POSIX പ്രശ്നങ്ങൾ കൂടുതൽ വഷളാക്കുന്നു. പ്രത്യേകിച്ച്,

• POSIX ചാറ്റിയാണ്: POSIX സെമാൻ്റിക്‌സിന് ഓരോ ഓപ്പറേഷനും മെറ്റാഡാറ്റയുമായും പ്രവർത്തനത്തിൻ്റെ അവസ്ഥ നിലനിർത്താൻ സഹായിക്കുന്ന ഫയൽ ഡിസ്ക്രിപ്റ്ററുകളുമായും ബന്ധപ്പെടുത്തേണ്ടതുണ്ട്. ഇത് യഥാർത്ഥ മൂല്യമില്ലാത്ത കാര്യമായ ചിലവുകൾക്ക് കാരണമാകുന്നു. ഒബ്ജക്റ്റ് സ്റ്റോറേജ് API-കൾ, പ്രത്യേകിച്ച് S3 API, ഈ ആവശ്യകതകളിൽ നിന്ന് മുക്തി നേടുന്നു, ഇത് ആപ്ലിക്കേഷനെ ഫയർ ചെയ്യാനും തുടർന്ന് കോളിനെക്കുറിച്ച് "മറക്കാനും" അനുവദിക്കുന്നു. പ്രവർത്തനം വിജയകരമാണോ അല്ലയോ എന്ന് സ്റ്റോറേജ് സിസ്റ്റം പ്രതികരണം സൂചിപ്പിക്കുന്നു. ഇത് പരാജയപ്പെടുകയാണെങ്കിൽ, അപ്ലിക്കേഷന് വീണ്ടും ശ്രമിക്കാവുന്നതാണ്.
• നെറ്റ്‌വർക്ക് നിയന്ത്രണങ്ങൾ: ഒരു വിതരണം ചെയ്ത സിസ്റ്റത്തിൽ, ഒരേ അറ്റാച്ച് ചെയ്ത മീഡിയയിലേക്ക് ഡാറ്റ എഴുതാൻ ശ്രമിക്കുന്ന നിരവധി ആപ്ലിക്കേഷനുകൾ ഉണ്ടാകാമെന്ന് സൂചിപ്പിക്കുന്നു. അതിനാൽ, ഡാറ്റാ ട്രാൻസ്ഫർ ബാൻഡ്‌വിഡ്‌ത്തിന് (മീഡിയയിലേക്ക് ഡാറ്റ അയയ്‌ക്കുന്നതിന്) അപ്ലിക്കേഷനുകൾ പരസ്പരം മത്സരിക്കുമെന്ന് മാത്രമല്ല, ഫിസിക്കൽ ഡിസ്‌കുകളിലുടനീളം ഡാറ്റ അയച്ചുകൊണ്ട് സ്റ്റോറേജ് സിസ്റ്റം തന്നെ ഈ ബാൻഡ്‌വിഡ്‌ത്തിന് മത്സരിക്കും. POSIX-ൻ്റെ ലോക്വസിയസ് കാരണം, നെറ്റ്‌വർക്ക് കോളുകളുടെ എണ്ണം നിരവധി തവണ വർദ്ധിക്കുന്നു. മറുവശത്ത്, S3 API, ക്ലയൻ്റിൽ നിന്ന് സെർവറിലേക്കുള്ള നെറ്റ്‌വർക്ക് കോളുകളും സെർവറിനുള്ളിൽ സംഭവിക്കുന്നവയും തമ്മിലുള്ള വ്യക്തമായ വ്യത്യാസം നൽകുന്നു.
• സുരക്ഷ: POSIX സുരക്ഷാ മോഡൽ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് സജീവമായ മനുഷ്യ പങ്കാളിത്തത്തിന് വേണ്ടിയാണ്: അഡ്മിനിസ്ട്രേറ്റർമാർ ഓരോ ഉപയോക്താവിനും അല്ലെങ്കിൽ ഗ്രൂപ്പിനും പ്രത്യേക ആക്സസ് ലെവലുകൾ ക്രമീകരിക്കുന്നു. ഈ മാതൃക ഒരു ക്ലൗഡ് കേന്ദ്രീകൃത ലോകവുമായി പൊരുത്തപ്പെടാൻ പ്രയാസമാണ്. ആധുനിക ആപ്ലിക്കേഷനുകൾ API-അധിഷ്ഠിത സുരക്ഷാ മോഡലുകളെ ആശ്രയിച്ചിരിക്കുന്നു, ഇവിടെ ആക്സസ് അവകാശങ്ങൾ ഒരു കൂട്ടം നയങ്ങളായി നിർവചിക്കപ്പെടുന്നു, സേവന അക്കൗണ്ടുകൾ, താൽക്കാലിക ക്രെഡൻഷ്യലുകൾ മുതലായവ അനുവദിച്ചിരിക്കുന്നു.
• കൈകാര്യം ചെയ്യാനുള്ള കഴിവ്: സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്നറുകൾക്ക് ചില മാനേജ്മെൻ്റ് ഓവർഹെഡ് ഉണ്ട്. ഡാറ്റയിലേക്കുള്ള സമാന്തര ആക്സസ് സമന്വയിപ്പിക്കുന്നതിനെക്കുറിച്ചാണ് ഞങ്ങൾ സംസാരിക്കുന്നത്, ഡാറ്റ സ്ഥിരത ഉറപ്പാക്കുന്നു, ഇതിനെല്ലാം ഏത് ഡാറ്റ ആക്സസ് പാറ്റേണുകൾ ഉപയോഗിക്കണമെന്ന് ശ്രദ്ധാപൂർവ്വം പരിഗണിക്കേണ്ടതുണ്ട്. അധിക സോഫ്‌റ്റ്‌വെയർ ഇൻസ്റ്റാൾ ചെയ്യുകയും നിരീക്ഷിക്കുകയും കോൺഫിഗർ ചെയ്യുകയും വേണം, അധിക വികസന ശ്രമങ്ങൾ പരാമർശിക്കേണ്ടതില്ല.

കണ്ടെയ്നർ ഡാറ്റ സ്റ്റോറേജ് ഇൻ്റർഫേസ്

കണ്ടെയ്‌നർ സ്‌റ്റോറേജ് ഇൻ്റർഫേസ് (സിഎസ്ഐ) ക്യൂബർനെറ്റസ് വോളിയം ലെയറിൻ്റെ വ്യാപനത്തിന് വലിയ സഹായമാണ്, അത് ഭാഗികമായി മൂന്നാം കക്ഷി സ്റ്റോറേജ് വെണ്ടർമാർക്ക് ഔട്ട്‌സോഴ്‌സ് ചെയ്യുന്നു, കൂടാതെ സ്റ്റേറ്റ്ഫുൾ കണ്ടെയ്‌നർ സമീപനമാണ് ശുപാർശ ചെയ്യുന്ന രീതിയെന്ന വിശ്വാസത്തിന് ഇത് അശ്രദ്ധമായി സംഭാവന നൽകി. കുബർനെറ്റസിൽ ഡാറ്റ സംഭരിക്കുന്നു.

Kubernetes-ൽ പ്രവർത്തിക്കുമ്പോൾ ലെഗസി ആപ്ലിക്കേഷനുകൾക്ക് അനിയന്ത്രിതമായ ബ്ലോക്ക്, ഫയൽ സ്റ്റോറേജ് സിസ്റ്റങ്ങൾ നൽകുന്നതിനുള്ള ഒരു സ്റ്റാൻഡേർഡ് ആയി CSI വികസിപ്പിച്ചെടുത്തു. കൂടാതെ, ഈ ലേഖനം കാണിച്ചിരിക്കുന്നതുപോലെ, ഒബ്‌ജക്റ്റ് സ്റ്റോറേജ് API-യ്‌ക്ക് പിന്തുണ ചേർക്കുന്നത് സാധ്യമല്ലാത്ത ഒരു ലെഗസി സിസ്റ്റമായിരിക്കുമ്പോൾ മാത്രമാണ് സ്റ്റേറ്റ്‌ഫുൾ കണ്ടെയ്‌നർ സമീപനം (അതിൻ്റെ നിലവിലെ രൂപത്തിൽ CSI) അർത്ഥമാക്കുന്നത്. .

CSI അതിൻ്റെ നിലവിലെ രൂപത്തിൽ ഉപയോഗിക്കുന്നത്, അതായത്, ആധുനിക ആപ്ലിക്കേഷനുകൾക്കൊപ്പം പ്രവർത്തിക്കുമ്പോൾ വോള്യങ്ങൾ മൗണ്ടുചെയ്യുമ്പോൾ, POSIX ശൈലിയിൽ ഡാറ്റ സംഭരണം ക്രമീകരിച്ചിരിക്കുന്ന സിസ്റ്റങ്ങളിൽ ഉണ്ടായ ഏതാണ്ട് സമാനമായ പ്രശ്നങ്ങൾ ഞങ്ങൾ നേരിടേണ്ടിവരുമെന്ന് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്.

ഒരു മെച്ചപ്പെട്ട സമീപനം

ഈ സാഹചര്യത്തിൽ, ഭൂരിഭാഗം ആപ്ലിക്കേഷനുകളും അന്തർലീനമായി സ്റ്റേറ്റ് അല്ലെങ്കിൽ സ്റ്റേറ്റ്ലെസ് വർക്കിനായി പ്രത്യേകമായി രൂപകൽപ്പന ചെയ്തിട്ടില്ലെന്ന് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്. ഈ സ്വഭാവം മൊത്തത്തിലുള്ള സിസ്റ്റം ആർക്കിടെക്ചറിനെയും നിർദ്ദിഷ്ട ഡിസൈൻ തിരഞ്ഞെടുപ്പിനെയും ആശ്രയിച്ചിരിക്കുന്നു. സ്റ്റേറ്റ്ഫുൾ ആപ്ലിക്കേഷനുകളെക്കുറിച്ച് നമുക്ക് കുറച്ച് സംസാരിക്കാം.

തത്വത്തിൽ, എല്ലാ ആപ്ലിക്കേഷൻ ഡാറ്റയും പല വിശാലമായ തരങ്ങളായി തിരിക്കാം:

• ലോഗ് ഡാറ്റ
• ടൈംസ്റ്റാമ്പ് ഡാറ്റ
• ഇടപാട് ഡാറ്റ
• മെറ്റാഡാറ്റ
• കണ്ടെയ്നർ ചിത്രങ്ങൾ
• ബ്ലോബ് (ബൈനറി വലിയ ഒബ്‌ജക്റ്റ്) ഡാറ്റ

ഈ ഡാറ്റ തരങ്ങളെല്ലാം ആധുനിക സ്റ്റോറേജ് പ്ലാറ്റ്‌ഫോമുകളിൽ നന്നായി പിന്തുണയ്ക്കുന്നു, കൂടാതെ ഈ നിർദ്ദിഷ്ട ഫോർമാറ്റുകളിൽ ഓരോന്നിലും ഡാറ്റ ഡെലിവർ ചെയ്യുന്നതിനായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന നിരവധി ക്ലൗഡ്-നേറ്റീവ് പ്ലാറ്റ്‌ഫോമുകൾ ഉണ്ട്. ഉദാഹരണത്തിന്, ഇടപാട് ഡാറ്റയും മെറ്റാഡാറ്റയും CockroachDB, YugaByte മുതലായവ പോലുള്ള ഒരു ആധുനിക ക്ലൗഡ്-നേറ്റീവ് ഡാറ്റാബേസിൽ വസിക്കാം. MinIO അടിസ്ഥാനമാക്കിയുള്ള ഒരു ഡോക്കർ രജിസ്ട്രിയിൽ കണ്ടെയ്നർ ചിത്രങ്ങളോ ബ്ലോബ് ഡാറ്റയോ സംഭരിക്കാൻ കഴിയും. ടൈംസ്റ്റാമ്പ് ഡാറ്റ InfluxDB മുതലായ സമയ ശ്രേണി ഡാറ്റാബേസിൽ സംഭരിക്കാൻ കഴിയും. ഓരോ ഡാറ്റാ തരത്തെക്കുറിച്ചും അതിൻ്റെ ആപ്ലിക്കേഷനുകളെക്കുറിച്ചും ഞങ്ങൾ ഇവിടെ വിശദമായി പറയില്ല, എന്നാൽ പ്രാദേശിക ഡിസ്ക് മൗണ്ടിംഗിനെ ആശ്രയിക്കുന്ന സ്ഥിരമായ ഡാറ്റ സംഭരണം ഒഴിവാക്കുക എന്നതാണ് പൊതുവായ ആശയം.

കൂടാതെ, ആപ്ലിക്കേഷനുകൾക്കായുള്ള ഒരു താൽക്കാലിക ഫയൽ സ്റ്റോറായി വർത്തിക്കുന്ന ഒരു താൽക്കാലിക കാഷിംഗ് ലെയർ നൽകുന്നത് പലപ്പോഴും ഫലപ്രദമാണ്, എന്നാൽ സത്യത്തിൻ്റെ ഉറവിടമായി ആപ്ലിക്കേഷനുകൾ ഈ ലെയറിനെ ആശ്രയിക്കരുത്.

സ്റ്റേറ്റ്ഫുൾ ആപ്ലിക്കേഷൻ സ്റ്റോറേജ്

മിക്ക കേസുകളിലും ആപ്ലിക്കേഷനുകൾ സ്റ്റേറ്റില്ലാത്തതായി സൂക്ഷിക്കുന്നത് ഉപയോഗപ്രദമാണെങ്കിലും, ഡാറ്റ സംഭരിക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ള ആപ്ലിക്കേഷനുകൾ - ഡാറ്റാബേസുകൾ, ഒബ്ജക്റ്റ് സ്റ്റോറുകൾ, കീ-വാല്യൂ സ്റ്റോറുകൾ എന്നിവ - സ്റ്റേറ്റ്ഫുൾ ആയിരിക്കണം. എന്തുകൊണ്ടാണ് ഈ ആപ്ലിക്കേഷനുകൾ കുബർനെറ്റസിൽ വിന്യസിച്ചതെന്ന് നോക്കാം. നമുക്ക് MinIO ഒരു ഉദാഹരണമായി എടുക്കാം, എന്നാൽ സമാനമായ തത്ത്വങ്ങൾ മറ്റേതൊരു വലിയ ക്ലൗഡ്-നേറ്റീവ് സ്റ്റോറേജ് സിസ്റ്റത്തിനും ബാധകമാണ്.

കണ്ടെയ്‌നറുകളിൽ അന്തർലീനമായിരിക്കുന്ന വഴക്കം പൂർണ്ണമായി പ്രയോജനപ്പെടുത്തുന്നതിനാണ് ക്ലൗഡ്-നേറ്റീവ് ആപ്ലിക്കേഷനുകൾ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഇതിനർത്ഥം അവർ വിന്യസിക്കപ്പെടുന്ന പരിസ്ഥിതിയെക്കുറിച്ച് അവർ യാതൊരു അനുമാനവും നടത്തുന്നില്ല എന്നാണ്. ഉദാഹരണത്തിന്, പകുതി ഡിസ്കുകൾ പരാജയപ്പെടുകയാണെങ്കിൽപ്പോലും പ്രവർത്തനക്ഷമമായി തുടരുന്നതിന് ആവശ്യമായ പ്രതിരോധശേഷി സിസ്റ്റത്തിന് നൽകുന്നതിന് MinIO ഒരു ആന്തരിക മായ്ക്കൽ കോഡിംഗ് സംവിധാനം ഉപയോഗിക്കുന്നു. പ്രൊപ്രൈറ്ററി സെർവർ-സൈഡ് ഹാഷിംഗും എൻക്രിപ്ഷനും ഉപയോഗിച്ച് മിനിഐഒ ഡാറ്റ സമഗ്രതയും സുരക്ഷയും കൈകാര്യം ചെയ്യുന്നു.

അത്തരം ക്ലൗഡ് കേന്ദ്രീകൃത ആപ്ലിക്കേഷനുകൾക്ക്, ബാക്കപ്പ് സ്റ്റോറേജ് എന്ന നിലയിൽ ലോക്കൽ പെർസിസ്റ്റൻ്റ് വോള്യങ്ങൾ (പിവികൾ) ഏറ്റവും സൗകര്യപ്രദമാണ്. അസംസ്‌കൃത ഡാറ്റ സംഭരിക്കുന്നതിനുള്ള കഴിവ് ലോക്കൽ പിവി നൽകുന്നു, അതേസമയം ഈ പിവികൾക്ക് മുകളിൽ പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകൾ ഡാറ്റ സ്കെയിൽ ചെയ്യുന്നതിനും വർദ്ധിച്ചുവരുന്ന ഡാറ്റ ആവശ്യകതകൾ നിയന്ത്രിക്കുന്നതിനുമായി സ്വതന്ത്രമായി വിവരങ്ങൾ ശേഖരിക്കുന്നു.

ഈ സമീപനം CSI-അധിഷ്‌ഠിത പിവികളേക്കാൾ വളരെ ലളിതവും ഗണ്യമായ തോതിൽ കൂടുതൽ സ്കെയിലബിൾ ആണ്, അവ അവരുടെ സ്വന്തം ഡാറ്റാ മാനേജ്‌മെൻ്റിൻ്റെയും ആവർത്തനത്തിൻ്റെയും പാളികൾ സിസ്റ്റത്തിൽ അവതരിപ്പിക്കുന്നു; ഈ ലെയറുകൾ സാധാരണയായി സ്റ്റേറ്റ്ഫുൾ ആയി രൂപകല്പന ചെയ്ത ആപ്ലിക്കേഷനുകളുമായി വൈരുദ്ധ്യം പുലർത്തുന്നു എന്നതാണ് കാര്യം.

കണക്കുകൂട്ടലുകളിൽ നിന്ന് ഡാറ്റ വേർപെടുത്തുന്നതിനുള്ള ശക്തമായ ചലനം

ഈ ലേഖനത്തിൽ, അവസ്ഥ സംരക്ഷിക്കാതെ ആപ്ലിക്കേഷനുകൾ എങ്ങനെ പുനഃക്രമീകരിക്കപ്പെടുന്നു എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിച്ചു, അല്ലെങ്കിൽ, മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഡാറ്റ സംഭരിക്കുന്നത് അതിലെ കമ്പ്യൂട്ടിംഗിൽ നിന്ന് വേർപെടുത്തുന്നു. ഉപസംഹാരമായി, ഈ പ്രവണതയുടെ ചില യഥാർത്ഥ ഉദാഹരണങ്ങൾ നോക്കാം.

തീപ്പൊരി, ഒരു പ്രമുഖ ഡാറ്റാ അനലിറ്റിക്സ് പ്ലാറ്റ്ഫോം, പരമ്പരാഗതമായി സ്റ്റേറ്റ്ഫുൾ ആയതും HDFS-ൽ വിന്യസിച്ചിട്ടുള്ളതുമാണ്. എന്നിരുന്നാലും, സ്പാർക്ക് ഒരു ക്ലൗഡ് കേന്ദ്രീകൃത ലോകത്തിലേക്ക് നീങ്ങുമ്പോൾ, `s3a` ഉപയോഗിച്ച് പ്ലാറ്റ്ഫോം കൂടുതലായി ഉപയോഗിക്കപ്പെടുന്നു. മറ്റ് സിസ്റ്റങ്ങളിലേക്ക് അവസ്ഥ കൈമാറാൻ സ്പാർക്ക് s3a ഉപയോഗിക്കുന്നു, അതേസമയം സ്പാർക്ക് കണ്ടെയ്‌നറുകൾ പൂർണ്ണമായും സ്‌റ്റേറ്റ്‌ലെസ് ആയി പ്രവർത്തിക്കുന്നു. ബിഗ് ഡാറ്റ അനലിറ്റിക്സ് മേഖലയിലെ മറ്റ് പ്രധാന എൻ്റർപ്രൈസ് കളിക്കാർ, പ്രത്യേകിച്ച്, വെർട്ടിക്ക, തെരദത, ഗ്രീൻപ്ലം ഡാറ്റ സംഭരണവും അവയുടെ കണക്കുകൂട്ടലുകളും വേർതിരിക്കുന്നതിനൊപ്പം പ്രവർത്തിക്കാനും അവർ നീങ്ങുന്നു.

Presto, Tensorflow to R, Jupyter ഉൾപ്പെടെയുള്ള മറ്റ് വലിയ വിശകലന പ്ലാറ്റ്‌ഫോമുകളിലും സമാനമായ പാറ്റേണുകൾ കാണാൻ കഴിയും. റിമോട്ട് ക്ലൗഡ് സ്റ്റോറേജ് സിസ്റ്റങ്ങളിലേക്ക് സ്റ്റേറ്റ് ഓഫ്‌ലോഡ് ചെയ്യുന്നതിലൂടെ, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ മാനേജ് ചെയ്യാനും സ്കെയിൽ ചെയ്യാനും വളരെ എളുപ്പമാകും. കൂടാതെ, വിവിധ പരിതസ്ഥിതികളിലേക്ക് ആപ്ലിക്കേഷൻ്റെ പോർട്ടബിലിറ്റി ഇത് സുഗമമാക്കുന്നു.

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