ഒരു മേഖല തകരുമ്പോള്: ദുരന്തം സംഭവിച്ചാല് ഫലപ്രദമായ വീണ്ടെടുക്കല്

മേഘമേഖലകൾ വളരെ വിശ്വസനീയമാണ്. അവര് അങ്ങനെ ആകാത്തതുവരെ. പ്രധാന സേവനദാതാക്കളുടെ വലിയ വിച്ഛേദങ്ങൾ ഇടയ്ക്കിടെ സംഭവിക്കുന്നു, ചിലപ്പോൾ ഒരു പ്രദേശത്തിന്റെ മുഴുവൻ സേവനങ്ങളും മണിക്കൂറുകളോളം നിലച്ചിടുന്നു. ദുരന്തങ്ങൾ ദാതാക്കളെ മാത്രം ബാധിക്കുന്നതല്ല. ഇല്ലാതാക്കിയ ഉല്പാദന ഡാറ്റാബേസ്, റാൻസോംവെയർ ആക്രമണം, ഡാറ്റയെ നശിപ്പിക്കുന്ന മോശം വിന്യാസം, അല്ലെങ്കിൽ ഒരു അക്കൌണ്ട് സസ്പെൻഡ് ചെയ്യുന്ന കാലഹരണപ്പെട്ട പേയ്മെന്റ് രീതി.

ദുരന്ത വീണ്ടെടുക്കൽ എന്നത് സത്യസന്ധമായി ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുക എന്നതാണ്: ഏറ്റവും മോശം സംഭവിച്ചാൽ എത്ര വേഗത്തിൽ നമുക്ക് തിരിച്ചുവരാൻ കഴിയും, എത്ര ഡാറ്റ നഷ്ടപ്പെടും?

RPO ഉം RTO ഉം, ലളിതമായി

നിങ്ങളുടെ ഡി. ആർ. ലക്ഷ്യങ്ങളെ രണ്ടു സംഖ്യകളാണ് നിർവചിക്കുന്നത്:

• RPO (വീണ്ടെടുക്കൽ പോയിന്റ് ലക്ഷ്യം): എത്ര ഡാറ്റ നഷ്ടപ്പെടാൻ നിങ്ങൾക്ക് കഴിയുന്നു? നിങ്ങളുടെ RPO ഒരു മണിക്കൂറാണെങ്കിൽ, കുറഞ്ഞത് ഓരോ മണിക്കൂറിലും നിങ്ങൾക്ക് ബാക്കപ്പുകളോ റെപ്ലിക്കേഷനുകളോ ആവശ്യമാണ്.
• RTO (വീണ്ടെടുക്കൽ സമയ ലക്ഷ്യം)എത്ര നേരം നിനക്ക് കിടക്കാൻ പറ്റും? നിങ്ങളുടെ RTO നാലു മണിക്കൂറാണെങ്കിൽ, നാലു മണിക്കൂറിനുള്ളിൽ സേവനം പുനഃസ്ഥാപിക്കാൻ കഴിയണം.

കുറഞ്ഞ സംഖ്യകൾ കൂടുതല് വിലയുള്ളതാണ്. പൂജ്യം RPO, മിനിറ്റ് RTO എന്നിങ്ങനെ ഒന്നിലധികം മേഖലകളിലെ സജീവ-സജീവ സംവിധാനങ്ങൾ, അത് ചെലവേറിയതും സങ്കീർണ്ണവുമാണ്. 24 മണിക്കൂറും ഒരു ദിവസവും RTO ഒരു ആന്തരിക ഉപകരണത്തിന് നല്ലതായിരിക്കാം.

ഓരോ സിസ്റ്റത്തിനും അനുസരിച്ച്, ബിസിനസ്സുമായി. എല്ലാത്തിനും ഒരേ നിലവാരം ആവശ്യമില്ല.

നാലു തന്ത്രങ്ങൾ

വിലകുറഞ്ഞതിൽ നിന്നും വിലകൂടിയതിലേക്ക്:

1. ഒരു പാരമ്പര്യം ബാക്കപ്പ് ചെയ്ത് പുനഃസ്ഥാപിക്കുക. മറ്റൊരു മേഖലയിലോ അക്കൌണ്ടിലോ സൂക്ഷിച്ചിരിക്കുന്ന പതിവ് ബാക്കപ്പുകൾ. ഒരു ദുരന്തത്തിൽ, നിങ്ങൾ അടിസ്ഥാന സൌകര്യങ്ങൾ പുനർനിർമിക്കുന്നു (കോഡായി അടിസ്ഥാന സൌകര്യം ഉപയോഗിച്ച്) ഡാറ്റ പുനഃസ്ഥാപിക്കുന്നു. വിലകുറഞ്ഞതാണ്, പക്ഷേ സുഖം പ്രാപിക്കാൻ മണിക്കൂറുകൾ എടുക്കും. RPO ബാക്കപ്പ് ആവൃത്തിയില് ആശ്രയിച്ചിരിക്കുന്നു.

2. പൈലറ്റ് ലൈറ്റ്. പ്രധാന ഘടകങ്ങൾ (ഒരു ആവർത്തിച്ച ഡാറ്റാബേസ് പോലെ) രണ്ടാമത്തെ മേഖലയിൽ കുറഞ്ഞ വലുപ്പത്തിൽ പ്രവർത്തിക്കുന്നു. ബാക്കി എല്ലാം കോഡിൽ നിന്നും പെട്ടെന്ന് സൃഷ്ടിക്കാൻ തയ്യാറാണ്. വേഗത്തില് സുഖം പ്രാപിക്കും, ചെലവ് കുറവായിരിക്കും.

3. ഒരു കല്ല് ചൂടുള്ള സ്റ്റാൻഡ്ബൈ. രണ്ടാമത്തെ മേഖലയില് സിസ്റ്റത്തിന്റെ ഒരു ചെറിയ കോപ്പി പ്രവർത്തിക്കുന്നു. ഒരു ദുരന്തം സംഭവിച്ചാൽ, നിങ്ങൾ അത് സ്കെയിൽ ചെയ്ത് ട്രാഫിക് മാറ്റും. മിനിറ്റിനകം ഒരു മണിക്കൂറിനകം സുഖം പ്രാപിക്കും.

4. സജീവ-സജീവ (മൾട്ടി സൈറ്റ്). ഈ സംവിധാനം ഒരേസമയം പല മേഖലകളിലും പ്രവർത്തിക്കുന്നു. ഒരു മേഖലയിലെ പരാജയം ട്രാഫിക് മാറ്റുന്നു. പൂജ്യം RTO, പക്ഷെ ഏറ്റവും ചെലവേറിയതും സങ്കീർണ്ണവുമായത്, പ്രത്യേകിച്ച് ഡാറ്റാ സ്ഥിരതയ്ക്ക്.

തന്ത്രം	സാധാരണ RTO	സാധാരണ RPO	വില
ബാക്കപ്പ് ചെയ്ത് പുനഃസ്ഥാപിക്കുക	ഒരു ദിവസം മണിക്കൂറുകൾ	മണിക്കൂറുകൾ	കുറവ്
പൈലറ്റ് ലൈറ്റ്	മിനിറ്റ് മുതൽ മണിക്കൂറുകൾ വരെ	പ്രോട്ടോക്കോൾ	ഇടത്തരം
ചൂടുള്ള സ്റ്റാൻഡ്ബൈ	പ്രോട്ടോക്കോൾ	സെക്കൻഡ് മുതൽ മിനിറ്റ് വരെ	ഉയരം
സജീവമായ-സജീവമായ	പൂജ്യത്തിനു സമീപം	പൂജ്യത്തിനു സമീപം	ഏറ്റവും ഉയരം

ദുരന്തം സംഭവിച്ചാല് അത് ഒരു രേഖയല്ല. അത് ഒരു കഴിവാണ്, കഴിവ് പരിശീലനം ആവശ്യമാണ്.

അടിസ്ഥാനം

നിങ്ങള് ഏതു തന്ത്രം തെരഞ്ഞെടുത്താലും, ഈ അടിസ്ഥാനകാര്യങ്ങള് പ്രധാനമാണ്:

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

വെലറോ ഉപയോഗിച്ച് കുബർനെറ്റസ് ബാക്കപ്പുകൾ

കുബർനെറ്റിസിനായി, വെലറോ അത് ഒരു സാധാരണ ഓപ്പൺ സോഴ്സ് ടൂളാണ്. ഇത് Kubernetes റിസോഴ്സുകളും (വിന്യാസങ്ങൾ, സേവനങ്ങൾ, കോൺഫിഗറേഷൻ) സ്ഥിരമായ വോള്യങ്ങളും (സ്നാപ്പ്ഷോട്ടുകൾ അല്ലെങ്കിൽ ഫയൽ ലെവൽ ബാക്കപ്പ് ഉപയോഗിച്ച്) ഒബ്ജക്റ്റ് സംഭരണത്തിലേക്ക് ബാക്കപ്പ് ചെയ്യുന്നു, അവയെ മറ്റൊരു ക്ലസ്റ്ററിലേക്ക് പോലും പുന restore സ്ഥാപിക്കുന്നു.

# Daily backup of the shop namespace, kept for 30 days
velero schedule create shop-daily \
  --schedule="0 2 * * *" \
  --include-namespaces shop \
  --ttl 720h

# Restore into a new cluster
velero restore create --from-backup shop-daily-20261020020000

ഗിറ്റ് ഒപ്സിനൊപ്പം, നിങ്ങളുടെ കുബർനെറ്റസ് റിസോഴ്സുകൾ ഗിറ്റിലുണ്ട്, അതിനാൽ വെലറോ ചേർത്ത പ്രധാന ഭാഗം സ്ഥിരമായ ഡാറ്റ. ഡാറ്റാബേസുകൾക്ക്, സ്ഥിരമായ, പോയിന്റ്-ഇൻ-ടൈം വീണ്ടെടുക്കലിനായി ഡാറ്റാ ബേസിന്റെ സ്വന്തം ബാക്കപ്പ് ഉപകരണങ്ങൾ (അല്ലെങ്കിൽ CloudNativePG പോലുള്ള ഒരു ഓപ്പറേറ്റർ) ഇഷ്ടപ്പെടുകയും ഒരു അധിക ലെയറായി Velero ഉപയോഗിക്കുകയും ചെയ്യുക.

ശരിക്കും പരീക്ഷിച്ചുനോക്കിയതാ.

മിക്ക ടീമുകളും ഒഴിവാക്കുന്ന ഭാഗമാണിത്, ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗം.

• പതിവായി ബാക്കപ്പുകൾ പുനഃസ്ഥാപിക്കുക ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയിലേക്ക്, സാധ്യമെങ്കിൽ, സ്വയം. ഡാറ്റ ഉപയോഗിക്കാവുന്നതാണോ എന്ന് പരിശോധിക്കുക.
• ഡി. ആർ. ഡ്രില്ലുകൾ നടത്തുക: വർഷത്തിൽ ഒന്നോ രണ്ടോ തവണ, ഒരു മേഖലയോ അല്ലെങ്കിൽ ഒരു നിർണായക സംവിധാനമോ നഷ്ടപ്പെട്ടതായി സിമുലേറ്റ് ചെയ്ത്, യഥാർഥത്തിൽ വീണ്ടെടുക്കുക. സമയം നോക്കൂ. നിങ്ങളുടെ RTO യുമായി താരതമ്യം ചെയ്യുക.
• ചെറുതായി തുടങ്ങുക: ഒരു ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുക, പിന്നെ ഒരു സേവനം, പിന്നെ ഒരു പരിസ്ഥിതി.
• ഓരോ അത്ഭുതവും എഴുതി വയ്ക്കൂ. ഒരു വ്യായാമത്തില് അത് ശരിയാക്കാന് . അതിശയങ്ങൾ ഉണ്ടാകും: അനുവാദങ്ങൾ നഷ്ടപ്പെട്ടു, ആശ്രിതത്വം മറന്നു, കാലഹരണപ്പെട്ട റൺബുക്കുകൾ, വീണ്ടെടുക്കൽ മേഖലയിലെ ക്വാട്ടകൾ.
• ചാസ് പരീക്ഷണങ്ങൾ ഒരു ലഭ്യതാ മേഖലയെ പരാജയപ്പെടുത്തുന്നത് ആത്മവിശ്വാസം വളർത്താൻ സഹായിക്കും.

എവിടെ നിന്നാണ് ഞാൻ തുടങ്ങേണ്ടത്?

നിങ്ങളുടെ പ്രധാനപ്പെട്ട മൂന്ന് സംവിധാനങ്ങളുടെ RPO, RTO എന്നിവ അംഗീകരിക്കുക. അവരുടെ ബാക്കപ്പുകൾ നിലവിലുണ്ടെന്നും, മറ്റൊരു മേഖലയിലും അക്കൌണ്ടിലാണെന്നും, മാറ്റമില്ലാത്തതാണെന്നും പരിശോധിക്കുക. എന്നിട്ട് അവയില് ഒന്ന് പുതിയ അന്തരീക്ഷത്തില് ഈ മാസം പുനഃസ്ഥാപിക്കുക, സമയം ക്രമീകരിക്കുക. ആ ഒരു വ്യായാമം നിങ്ങളുടെ യഥാർത്ഥ ഡി. ആർ. തയ്യാറെടുപ്പിനെക്കുറിച്ച് ഏതെങ്കിലും രേഖയെക്കാളും കൂടുതലായി പറയും.

എന്റെ അഭിപ്രായം: ഒരു ദുരന്തത്തിൽ നിന്നും വീണ്ടെടുക്കുന്നതുവരെ നിങ്ങൾക്ക് ദുരന്ത നിവാരണ സംവിധാനം ഇല്ല, ഒരു ദുരൂഹത പോലും.

ഡെസ്ലി