ഒരു കഠിനമായ എന്റർപ്രൈസ് പരിതസ്ഥിതിയിൽ "സൗജന്യ" PostgreSQL എങ്ങനെ യോജിപ്പിക്കാം

നിരവധി ആളുകൾക്ക് PostgreSQL DBMS പരിചിതമാണ്, കൂടാതെ ഇത് ചെറിയ ഇൻസ്റ്റാളേഷനുകളിൽ സ്വയം തെളിയിച്ചിട്ടുണ്ട്. എന്നിരുന്നാലും, വലിയ കമ്പനികളുടെയും എന്റർപ്രൈസ് ആവശ്യകതകളുടെയും കാര്യത്തിൽ പോലും, ഓപ്പൺ സോഴ്‌സിലേക്കുള്ള പ്രവണത കൂടുതൽ വ്യക്തമാണ്. ഈ ലേഖനത്തിൽ, ഒരു കോർപ്പറേറ്റ് പരിതസ്ഥിതിയിലേക്ക് Postgres എങ്ങനെ സമന്വയിപ്പിക്കാമെന്നും Commvault ബാക്കപ്പ് സിസ്റ്റം ഉദാഹരണമായി ഉപയോഗിച്ച് ഈ ഡാറ്റാബേസിനായി ഒരു ബാക്കപ്പ് സിസ്റ്റം (BSS) സൃഷ്ടിക്കുന്നതിനുള്ള ഞങ്ങളുടെ അനുഭവം പങ്കിടുന്നത് എങ്ങനെയെന്ന് ഞങ്ങൾ നിങ്ങളോട് പറയും.

PostgreSQL ഇതിനകം തന്നെ അതിന്റെ മൂല്യം തെളിയിച്ചിട്ടുണ്ട് - DBMS മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു, ഇത് ആലിബാബ, ട്രിപ്പ്അഡ്‌വൈസർ പോലുള്ള ഫാഷനബിൾ ഡിജിറ്റൽ ബിസിനസുകൾ ഉപയോഗിക്കുന്നു, കൂടാതെ ലൈസൻസിംഗ് ഫീസിന്റെ അഭാവം MS SQL അല്ലെങ്കിൽ Oracle DB പോലുള്ള രാക്ഷസന്മാർക്ക് ഒരു പ്രലോഭനകരമായ ബദലായി മാറുന്നു. എന്നാൽ എന്റർപ്രൈസ് ലാൻഡ്‌സ്‌കേപ്പിലെ PostgreSQL-നെ കുറിച്ച് ചിന്തിക്കാൻ തുടങ്ങിയാൽ ഉടൻ തന്നെ ഞങ്ങൾ കർശനമായ ആവശ്യകതകളിലേക്ക് കടക്കുന്നു: “കോൺഫിഗറേഷൻ തെറ്റ് സഹിഷ്ണുതയുടെ കാര്യമോ? ദുരന്ത പ്രതിരോധം? എവിടെയാണ് സമഗ്രമായ നിരീക്ഷണം? യാന്ത്രിക ബാക്കപ്പുകളെ സംബന്ധിച്ചെന്ത്? ടേപ്പ് ലൈബ്രറികൾ നേരിട്ടും ദ്വിതീയ സംഭരണത്തിലും ഉപയോഗിക്കുന്നതിനെക്കുറിച്ച് എന്താണ്?


ഒരു വശത്ത്, PostgreSQL-ന് Oracle DB-യിലെ RMAN അല്ലെങ്കിൽ SAP ഡാറ്റാബേസ് ബാക്കപ്പ് പോലെയുള്ള "മുതിർന്നവർക്കുള്ള" DBMS-കൾ പോലെയുള്ള ബിൽറ്റ്-ഇൻ ബാക്കപ്പ് ടൂളുകൾ ഇല്ല. മറുവശത്ത്, കോർപ്പറേറ്റ് ബാക്കപ്പ് സിസ്റ്റങ്ങളുടെ (Veeam, Veritas, Commvault) വിതരണക്കാർ PostgreSQL-നെ പിന്തുണയ്ക്കുന്നുണ്ടെങ്കിലും, വാസ്തവത്തിൽ അവർ ഒരു നിശ്ചിത (സാധാരണയായി ഒറ്റപ്പെട്ട) കോൺഫിഗറേഷനിലും വിവിധ നിയന്ത്രണങ്ങളുടെ ഒരു കൂട്ടത്തിലും മാത്രമേ പ്രവർത്തിക്കൂ.

PostgreSQL-ന് വേണ്ടി പ്രത്യേകം രൂപകൽപ്പന ചെയ്ത ബാക്കപ്പ് സിസ്റ്റങ്ങളായ Barman, Wal-g, pg_probackup, PostgreSQL DBMS-ന്റെ ചെറിയ ഇൻസ്റ്റാളേഷനുകളിലോ ഐടി ലാൻഡ്‌സ്‌കേപ്പിന്റെ മറ്റ് ഘടകങ്ങളുടെ കനത്ത ബാക്കപ്പുകൾ ആവശ്യമില്ലാത്ത ഇടങ്ങളിലോ വളരെ ജനപ്രിയമാണ്. ഉദാഹരണത്തിന്, PostgreSQL-ന് പുറമേ, ഇൻഫ്രാസ്ട്രക്ചറിൽ ഫിസിക്കൽ, വെർച്വൽ സെർവറുകൾ, OpenShift, Oracle, MariaDB, Cassandra മുതലായവ ഉൾപ്പെട്ടേക്കാം. ഒരു പൊതു ഉപകരണം ഉപയോഗിച്ച് ഇതെല്ലാം ബാക്കപ്പ് ചെയ്യുന്നതാണ് അഭികാമ്യം. PostgreSQL-ന് മാത്രമായി ഒരു പ്രത്യേക പരിഹാരം ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഒരു മോശം ആശയമാണ്: ഡാറ്റ എവിടെയോ ഡിസ്കിലേക്ക് പകർത്തപ്പെടും, തുടർന്ന് അത് ടേപ്പിലേക്ക് നീക്കം ചെയ്യേണ്ടതുണ്ട്. ഈ ഇരട്ട ബാക്കപ്പ് ബാക്കപ്പ് സമയം വർദ്ധിപ്പിക്കുന്നു, കൂടാതെ, കൂടുതൽ ഗുരുതരമായി, വീണ്ടെടുക്കൽ സമയവും.

ഒരു എന്റർപ്രൈസ് സൊല്യൂഷനിൽ, ഒരു പ്രത്യേക ക്ലസ്റ്ററിൽ ഒരു നിശ്ചിത എണ്ണം നോഡുകൾ ഉപയോഗിച്ചാണ് ഇൻസ്റ്റാളേഷന്റെ ബാക്കപ്പ് സംഭവിക്കുന്നത്. അതേ സമയം, ഉദാഹരണത്തിന്, Commvault-ന് രണ്ട്-നോഡ് ക്ലസ്റ്ററിനൊപ്പം മാത്രമേ പ്രവർത്തിക്കാൻ കഴിയൂ, അതിൽ പ്രാഥമികവും ദ്വിതീയവും ചില നോഡുകൾക്ക് കർശനമായി നൽകിയിട്ടുണ്ട്. പ്രൈമറിയിൽ നിന്ന് ബാക്കപ്പ് ചെയ്യുന്നത് അർത്ഥമാക്കുന്നു, കാരണം സെക്കൻഡറിയിൽ നിന്നുള്ള ബാക്കപ്പിന് പരിമിതികളുണ്ട്. DBMS-ന്റെ പ്രത്യേകതകൾ കാരണം, സെക്കൻഡറിയിൽ ഒരു ഡംപ് സൃഷ്ടിക്കപ്പെടുന്നില്ല, അതിനാൽ ഒരു ഫയൽ ബാക്കപ്പിനുള്ള സാധ്യത മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ.

പ്രവർത്തനരഹിതമായ സമയത്തിന്റെ അപകടസാധ്യത കുറയ്ക്കുന്നതിന്, ഒരു തകരാർ-സഹിഷ്ണുതയുള്ള സിസ്റ്റം സൃഷ്ടിക്കുമ്പോൾ, ഒരു "ലൈവ്" ക്ലസ്റ്റർ കോൺഫിഗറേഷൻ സൃഷ്ടിക്കപ്പെടുന്നു, കൂടാതെ പ്രൈമറിക്ക് വ്യത്യസ്ത സെർവറുകൾക്കിടയിൽ ക്രമേണ മൈഗ്രേറ്റ് ചെയ്യാൻ കഴിയും. ഉദാഹരണത്തിന്, Patroni സോഫ്റ്റ്വെയർ തന്നെ ക്രമരഹിതമായി തിരഞ്ഞെടുത്ത ഒരു ക്ലസ്റ്റർ നോഡിൽ പ്രാഥമിക സമാരംഭിക്കുന്നു. ബോക്‌സിന് പുറത്ത് ഇത് ട്രാക്കുചെയ്യാൻ IBS-ന് മാർഗമില്ല, കോൺഫിഗറേഷൻ മാറുകയാണെങ്കിൽ, പ്രക്രിയകൾ തകരും. അതായത്, ബാഹ്യ നിയന്ത്രണത്തിന്റെ ആമുഖം ISR ഫലപ്രദമായി പ്രവർത്തിക്കുന്നതിൽ നിന്ന് തടയുന്നു, കാരണം കൺട്രോൾ സെർവറിന് എവിടെ നിന്ന് ഏത് ഡാറ്റയാണ് പകർത്തേണ്ടതെന്ന് മനസ്സിലാകുന്നില്ല.

Postgres-ൽ ബാക്കപ്പ് നടപ്പിലാക്കുന്നതാണ് മറ്റൊരു പ്രശ്നം. ഡംപ് വഴി ഇത് സാധ്യമാണ്, ഇത് ചെറിയ ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുന്നു. എന്നാൽ വലിയ ഡാറ്റാബേസുകളിൽ, ഡംപ് വളരെ സമയമെടുക്കുന്നു, ധാരാളം വിഭവങ്ങൾ ആവശ്യമാണ്, കൂടാതെ ഡാറ്റാബേസ് ഉദാഹരണത്തിന്റെ പരാജയത്തിലേക്ക് നയിച്ചേക്കാം.

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

പിന്മാറാൻ ഒരിടവുമില്ല! മോസ്കോ ഡെവലപ്പർമാർ പിന്നിലാണ്!

എന്നിരുന്നാലും, അടുത്തിടെ ഞങ്ങളുടെ ടീം ഒരു പ്രയാസകരമായ വെല്ലുവിളി നേരിട്ടു: ഞങ്ങൾ ഐടി ഇൻഫ്രാസ്ട്രക്ചർ സൃഷ്ടിച്ച AIS OSAGO 2.0 സൃഷ്ടിക്കുന്നതിനുള്ള പ്രോജക്റ്റിൽ, ഡവലപ്പർമാർ പുതിയ സിസ്റ്റത്തിനായി PostgreSQL തിരഞ്ഞെടുത്തു.

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

• ക്ലസ്റ്ററിന്റെ പ്രാഥമിക നോഡിൽ നിന്ന് ബാക്കപ്പുകൾ നിർമ്മിക്കാൻ SRK-യെ പഠിപ്പിക്കുക. ഇത് ചെയ്യുന്നതിന്, SRK അത് കണ്ടെത്തണം - അതായത് ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരു PostgreSQL ക്ലസ്റ്റർ മാനേജ്മെന്റ് സൊല്യൂഷനുമായുള്ള സംയോജനം ആവശ്യമാണ്. ആർഎസ്എയുടെ കാര്യത്തിൽ, പത്രോണി സോഫ്റ്റ്വെയർ ഇതിനായി ഉപയോഗിച്ചു.
• ഡാറ്റയുടെ അളവും വീണ്ടെടുക്കൽ ആവശ്യകതകളും അടിസ്ഥാനമാക്കി ബാക്കപ്പ് തരം തീരുമാനിക്കുക. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് പേജുകൾ ഗ്രാനുലാർ ആയി പുനഃസ്ഥാപിക്കേണ്ടിവരുമ്പോൾ, ഒരു ഡമ്പ് ഉപയോഗിക്കുക, ഡാറ്റാബേസുകൾ വലുതും ഗ്രാനുലാർ പുനഃസ്ഥാപിക്കൽ ആവശ്യമില്ലെങ്കിൽ, ഫയൽ തലത്തിൽ പ്രവർത്തിക്കുക.
• മൾട്ടി-ത്രെഡഡ് മോഡിൽ ഒരു ബാക്കപ്പ് കോപ്പി സൃഷ്‌ടിക്കുന്നതിന് പരിഹാരത്തിലേക്ക് ബ്ലോക്ക് ബാക്കപ്പിന്റെ സാധ്യത അറ്റാച്ചുചെയ്യുക.

അതേ സമയം, അധിക ഘടകങ്ങളുടെ ഭീകരമായ ഹാർനെസ് ഇല്ലാതെ ഫലപ്രദവും ലളിതവുമായ ഒരു സിസ്റ്റം സൃഷ്ടിക്കാൻ ഞങ്ങൾ ആദ്യം തീരുമാനിച്ചു. കുറച്ച് ഊന്നുവടികൾ, ജീവനക്കാരുടെ ജോലിഭാരം കുറയുകയും IBS പരാജയപ്പെടാനുള്ള സാധ്യത കുറയുകയും ചെയ്യുന്നു. Veeam ഉം RMAN ഉം ഉപയോഗിക്കുന്ന സമീപനങ്ങൾ ഞങ്ങൾ ഉടനടി ഒഴിവാക്കി, കാരണം രണ്ട് പരിഹാരങ്ങളുടെ ഒരു കൂട്ടം സിസ്റ്റത്തിന്റെ വിശ്വാസ്യതയില്ലായ്മയെക്കുറിച്ച് ഇതിനകം സൂചന നൽകുന്നു.

എന്റർപ്രൈസിനായി ഒരു ചെറിയ മാജിക്

അതിനാൽ, 10 നോഡുകൾ വീതമുള്ള 3 ക്ലസ്റ്ററുകൾക്ക് വിശ്വസനീയമായ ബാക്കപ്പ് ഞങ്ങൾ ഉറപ്പ് നൽകേണ്ടതുണ്ട്, അതേ ഇൻഫ്രാസ്ട്രക്ചർ ബാക്കപ്പ് ഡാറ്റാ സെന്ററിൽ പ്രതിഫലിപ്പിക്കുന്നു. PostgreSQL-ന്റെ അടിസ്ഥാനത്തിൽ ഡാറ്റാ സെന്ററുകൾ സജീവ-നിഷ്ക്രിയ തത്വത്തിൽ പ്രവർത്തിക്കുന്നു. മൊത്തം ഡാറ്റാബേസ് വലുപ്പം 50 TB ആയിരുന്നു. ഏത് കോർപ്പറേറ്റ് തലത്തിലുള്ള നിയന്ത്രണ സംവിധാനത്തിനും ഇത് എളുപ്പത്തിൽ നേരിടാൻ കഴിയും. എന്നാൽ ബാക്കപ്പ് സിസ്റ്റങ്ങളുമായി പൂർണ്ണവും ആഴത്തിലുള്ളതുമായ അനുയോജ്യതയെക്കുറിച്ച് തുടക്കത്തിൽ പോസ്റ്റ്‌ഗ്രെസിന് ഒരു സൂചനയും ഇല്ലെന്നതാണ് മുന്നറിയിപ്പ്. അതിനാൽ, പോസ്റ്റ്‌ഗ്രെഎസ്‌ക്യുഎലുമായി സംയോജിച്ച് തുടക്കത്തിൽ പരമാവധി പ്രവർത്തനക്ഷമതയുള്ള ഒരു പരിഹാരത്തിനായി ഞങ്ങൾ നോക്കേണ്ടതുണ്ട്, കൂടാതെ സിസ്റ്റം പരിഷ്‌ക്കരിക്കുകയും ചെയ്തു.

ഞങ്ങൾ 3 ആന്തരിക “ഹാക്കത്തോണുകൾ” നടത്തി - ഞങ്ങൾ അമ്പതിലധികം സംഭവവികാസങ്ങൾ നോക്കി, അവ പരീക്ഷിച്ചു, ഞങ്ങളുടെ അനുമാനങ്ങളുമായി ബന്ധപ്പെട്ട് മാറ്റങ്ങൾ വരുത്തി, അവ വീണ്ടും പരീക്ഷിച്ചു. ലഭ്യമായ ഓപ്ഷനുകൾ അവലോകനം ചെയ്ത ശേഷം, ഞങ്ങൾ Commvault തിരഞ്ഞെടുത്തു. ബോക്‌സിന് പുറത്ത്, ഈ ഉൽപ്പന്നത്തിന് ഏറ്റവും ലളിതമായ PostgreSQL ക്ലസ്റ്റർ ഇൻസ്റ്റാളേഷനുമായി പ്രവർത്തിക്കാൻ കഴിയും, കൂടാതെ അതിന്റെ ഓപ്പൺ ആർക്കിടെക്ചർ വിജയകരമായ വികസനത്തിനും സംയോജനത്തിനും പ്രതീക്ഷകൾ ഉയർത്തി (അത് ന്യായീകരിക്കപ്പെട്ടു). Commvault-ന് PostgreSQL ലോഗുകൾ ബാക്കപ്പ് ചെയ്യാനും കഴിയും. ഉദാഹരണത്തിന്, PostgreSQL-ന്റെ അടിസ്ഥാനത്തിൽ Veritas NetBackup-ന് പൂർണ്ണ ബാക്കപ്പുകൾ മാത്രമേ നിർമ്മിക്കാൻ കഴിയൂ.

വാസ്തുവിദ്യയെക്കുറിച്ച് കൂടുതൽ. CommServ HA കോൺഫിഗറേഷനിൽ ഓരോ രണ്ട് ഡാറ്റാ സെന്ററുകളിലും Commvault മാനേജ്മെന്റ് സെർവറുകൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. സിസ്റ്റം മിറർ ചെയ്യുകയും ഒരു കൺസോളിലൂടെ നിയന്ത്രിക്കുകയും ചെയ്യുന്നു, കൂടാതെ HA വീക്ഷണകോണിൽ നിന്ന് എല്ലാ എന്റർപ്രൈസ് ആവശ്യകതകളും നിറവേറ്റുന്നു.

ഓരോ ഡാറ്റാ സെന്ററിലും ഞങ്ങൾ രണ്ട് ഫിസിക്കൽ മീഡിയ സെർവറുകളും സമാരംഭിച്ചു, ഫൈബർ ചാനൽ വഴി SAN വഴി ബാക്കപ്പുകൾക്കായി പ്രത്യേകം സമർപ്പിച്ചിരിക്കുന്ന ഡിസ്ക് അറേകളും ടേപ്പ് ലൈബ്രറികളും ഞങ്ങൾ ബന്ധിപ്പിച്ചു. വിപുലീകരിച്ച ഡീപ്ലിക്കേഷൻ ഡാറ്റാബേസുകൾ മീഡിയ സെർവറുകളുടെ തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കുന്നു, കൂടാതെ ഓരോ സെർവറും ഓരോ CSV-യിലേക്കും ബന്ധിപ്പിക്കുന്നത് ഏതെങ്കിലും ഘടകം പരാജയപ്പെട്ടാൽ തുടർച്ചയായ പ്രവർത്തനം പ്രാപ്തമാക്കുന്നു. ഡാറ്റാ സെന്ററുകളിലൊന്ന് വീണാലും ബാക്കപ്പ് തുടരാൻ സിസ്റ്റം ആർക്കിടെക്ചർ അനുവദിക്കുന്നു.

ഓരോ ക്ലസ്റ്ററിനും ഒരു പ്രാഥമിക നോഡ് പത്രോണി നിർവ്വചിക്കുന്നു. ഇത് ഡാറ്റാ സെന്ററിലെ ഏത് സൗജന്യ നോഡും ആകാം - എന്നാൽ കൂടുതലും. ബാക്കപ്പിൽ, എല്ലാ നോഡുകളും ദ്വിതീയമാണ്.

ഏത് ക്ലസ്റ്റർ നോഡാണ് പ്രാഥമികമെന്ന് Commvault-ന് മനസിലാക്കാൻ, ഞങ്ങൾ സിസ്റ്റം (പരിഹാരത്തിന്റെ തുറന്ന ആർക്കിടെക്ചറിന് നന്ദി) Postgres-മായി സംയോജിപ്പിച്ചു. ഈ ആവശ്യത്തിനായി, പ്രൈമറി നോഡിന്റെ നിലവിലെ സ്ഥാനം Commvault മാനേജ്മെന്റ് സെർവറിലേക്ക് റിപ്പോർട്ട് ചെയ്യുന്ന ഒരു സ്ക്രിപ്റ്റ് സൃഷ്ടിച്ചു.

പൊതുവേ, പ്രക്രിയ ഇതുപോലെ കാണപ്പെടുന്നു:

Patroni പ്രൈമറി തിരഞ്ഞെടുക്കുന്നു → Keepalived IP ക്ലസ്റ്റർ എടുത്ത് സ്‌ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നു → തിരഞ്ഞെടുത്ത ക്ലസ്റ്റർ നോഡിലെ Commvault ഏജന്റിന് ഇതൊരു അറിയിപ്പ് ലഭിക്കുന്നു, ഇതാണ് പ്രാഥമികം → Commvault കപട-ക്ലയന്റിനുള്ളിൽ ബാക്കപ്പ് സ്വയമേവ പുനഃക്രമീകരിക്കുന്നു.

ഈ സമീപനത്തിന്റെ പ്രയോജനം, പരിഹാരം ലോഗുകളുടെ സ്ഥിരത, കൃത്യത അല്ലെങ്കിൽ പോസ്റ്റ്‌ഗ്രെസ് ഉദാഹരണത്തിന്റെ വീണ്ടെടുക്കൽ എന്നിവയെ ബാധിക്കില്ല എന്നതാണ്. Commvault പ്രൈമറി, സെക്കൻഡറി നോഡുകൾ പരിഹരിക്കേണ്ട ആവശ്യമില്ലാത്തതിനാൽ ഇത് എളുപ്പത്തിൽ അളക്കാവുന്നതുമാണ്. പ്രൈമറി എവിടെയാണെന്ന് സിസ്റ്റം മനസ്സിലാക്കിയാൽ മതി, നോഡുകളുടെ എണ്ണം ഏതാണ്ട് ഏത് മൂല്യത്തിലേക്കും വർദ്ധിപ്പിക്കാൻ കഴിയും.

പരിഹാരം അനുയോജ്യമാണെന്ന് നടിക്കുന്നില്ല കൂടാതെ അതിന്റേതായ സൂക്ഷ്മതകളും ഉണ്ട്. Commvault-ന് മുഴുവൻ ഉദാഹരണവും മാത്രമേ ബാക്കപ്പ് ചെയ്യാനാകൂ, വ്യക്തിഗത ഡാറ്റാബേസുകളല്ല. അതിനാൽ, ഓരോ ഡാറ്റാബേസിനും ഒരു പ്രത്യേക ഉദാഹരണം സൃഷ്ടിച്ചു. യഥാർത്ഥ ക്ലയന്റുകളെ വെർച്വൽ കപട-ക്ലയന്റുകളായി സംയോജിപ്പിച്ചിരിക്കുന്നു. ഓരോ Commvault pseudo-client ഉം ഒരു UNIX ക്ലസ്റ്ററാണ്. Postgres-നുള്ള Commvault ഏജന്റ് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ക്ലസ്റ്റർ നോഡുകൾ ഇതിലേക്ക് ചേർത്തിരിക്കുന്നു. തൽഫലമായി, കപട-ക്ലയന്റിൻറെ എല്ലാ വെർച്വൽ നോഡുകളും ഒരു ഉദാഹരണമായി ബാക്കപ്പ് ചെയ്യുന്നു.

ഓരോ കപട-ക്ലയന്റിലും, ക്ലസ്റ്ററിന്റെ സജീവ നോഡ് സൂചിപ്പിച്ചിരിക്കുന്നു. Commvault-നുള്ള ഞങ്ങളുടെ ഇന്റഗ്രേഷൻ സൊല്യൂഷൻ നിർവചിക്കുന്നത് ഇതാണ്. അതിന്റെ പ്രവർത്തനത്തിന്റെ തത്വം വളരെ ലളിതമാണ്: ഒരു നോഡിൽ ഒരു ക്ലസ്റ്റർ ഐപി ഉയർത്തിയാൽ, സ്ക്രിപ്റ്റ് Commvault ഏജന്റ് ബൈനറിയിൽ "ആക്റ്റീവ് നോഡ്" പാരാമീറ്റർ സജ്ജമാക്കുന്നു - വാസ്തവത്തിൽ, സ്ക്രിപ്റ്റ് മെമ്മറിയുടെ ആവശ്യമായ ഭാഗത്ത് "1" സജ്ജമാക്കുന്നു. . ഏജന്റ് ഈ ഡാറ്റ CommServe-ലേക്ക് കൈമാറുന്നു, ആവശ്യമുള്ള നോഡിൽ നിന്ന് Commvault ഒരു ബാക്കപ്പ് ഉണ്ടാക്കുന്നു. കൂടാതെ, കോൺഫിഗറേഷന്റെ കൃത്യത സ്ക്രിപ്റ്റ് തലത്തിൽ പരിശോധിക്കുന്നു, ഒരു ബാക്കപ്പ് ആരംഭിക്കുമ്പോൾ പിശകുകൾ ഒഴിവാക്കാൻ സഹായിക്കുന്നു.

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

വഴിയിൽ, PostgreSQL ആർക്കൈവ് ലോഗുകൾ ബാക്കപ്പ് ചെയ്യുന്നതിന് ഞങ്ങൾ പ്രത്യേക നയങ്ങൾ പ്രയോഗിച്ചു - അവ വ്യത്യസ്‌ത നിയമങ്ങൾക്കനുസൃതമായി സംഭരിക്കുകയും മറ്റൊരു ഷെഡ്യൂൾ അനുസരിച്ച് പകർത്തുകയും ചെയ്യുന്നു, കൂടാതെ ഈ ലോഗുകളിൽ തനതായ ഡാറ്റ അടങ്ങിയിരിക്കുന്നതിനാൽ അവയ്‌ക്കായി ഡ്യൂപ്ലിക്കേഷൻ പ്രവർത്തനക്ഷമമാക്കിയിട്ടില്ല.

മുഴുവൻ ഐടി ഇൻഫ്രാസ്ട്രക്ചറിലുടനീളം സ്ഥിരത ഉറപ്പാക്കാൻ, ഓരോ ക്ലസ്റ്റർ നോഡുകളിലും പ്രത്യേക Commvault ഫയൽ ക്ലയന്റുകൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ട്. അവ ബാക്കപ്പുകളിൽ നിന്ന് Postgres ഫയലുകൾ ഒഴിവാക്കുന്നു, OS, ആപ്ലിക്കേഷൻ ബാക്കപ്പുകൾ എന്നിവയ്ക്കായി മാത്രം ഉദ്ദേശിച്ചുള്ളതാണ്. ഡാറ്റയുടെ ഈ ഭാഗത്തിനും അതിന്റേതായ നയവും സംഭരണ ​​കാലയളവും ഉണ്ട്.

നിലവിൽ, IBS ഉൽപ്പാദനക്ഷമത സേവനങ്ങളെ ബാധിക്കുന്നില്ല, എന്നാൽ സാഹചര്യം മാറുകയാണെങ്കിൽ, Commvault-ന് ലോഡ് ലിമിറ്റിംഗ് പ്രവർത്തനക്ഷമമാക്കാൻ കഴിയും.

അത് നല്ലതാണോ? നല്ലത്!

അതിനാൽ, ഞങ്ങൾക്ക് പ്രവർത്തനക്ഷമമായത് മാത്രമല്ല, ഒരു PostgreSQL ക്ലസ്റ്റർ ഇൻസ്റ്റാളേഷനായി ഒരു പൂർണ്ണ ഓട്ടോമേറ്റഡ് ബാക്കപ്പും ലഭിച്ചു, കൂടാതെ ഇത് എന്റർപ്രൈസ് കോളുകൾക്കുള്ള എല്ലാ ആവശ്യകതകളും നിറവേറ്റുന്നു.

1 മണിക്കൂർ 2 മണിക്കൂർ RPO, RTO പാരാമീറ്ററുകൾ ഒരു മാർജിൻ കൊണ്ട് മൂടിയിരിക്കുന്നു, അതായത് സംഭരിച്ച ഡാറ്റയുടെ അളവിൽ ഗണ്യമായ വർദ്ധനവുണ്ടായാലും സിസ്റ്റം അവയ്ക്ക് അനുസൃതമായി പ്രവർത്തിക്കും. പല സംശയങ്ങൾക്കും വിരുദ്ധമായി, PostgreSQL ഉം എന്റർപ്രൈസ് പരിതസ്ഥിതിയും തികച്ചും അനുയോജ്യമാണെന്ന് തെളിഞ്ഞു. അത്തരം ഡിബിഎംഎസുകൾക്കുള്ള ബാക്കപ്പ് വൈവിധ്യമാർന്ന കോൺഫിഗറേഷനുകളിൽ സാധ്യമാണെന്ന് ഇപ്പോൾ ഞങ്ങളുടെ സ്വന്തം അനുഭവത്തിൽ നിന്ന് ഞങ്ങൾക്കറിയാം.

തീർച്ചയായും, ഈ പാതയിൽ ഞങ്ങൾക്ക് ഏഴ് ജോഡി ഇരുമ്പ് ബൂട്ടുകൾ ധരിക്കേണ്ടി വന്നു, നിരവധി ബുദ്ധിമുട്ടുകൾ തരണം ചെയ്യേണ്ടതുണ്ട്, നിരവധി റേക്കുകളിൽ ചവിട്ടുകയും നിരവധി തെറ്റുകൾ തിരുത്തുകയും ചെയ്തു. എന്നാൽ ഇപ്പോൾ ഈ സമീപനം പരീക്ഷിച്ചുകഴിഞ്ഞു, കഠിനമായ എന്റർപ്രൈസ് സാഹചര്യങ്ങളിൽ കുത്തക DBMS-കൾക്ക് പകരം ഓപ്പൺ സോഴ്സ് നടപ്പിലാക്കാൻ ഇത് ഉപയോഗിക്കാം.

നിങ്ങൾ ഒരു കോർപ്പറേറ്റ് പരിതസ്ഥിതിയിൽ PostgreSQL-ൽ പ്രവർത്തിക്കാൻ ശ്രമിച്ചിട്ടുണ്ടോ?

രചയിതാക്കൾ:

ഒലെഗ് ലാവ്രെനോവ്, ഡാറ്റ സ്റ്റോറേജ് സിസ്റ്റങ്ങളുടെ ഡിസൈൻ എഞ്ചിനീയർ, ജെറ്റ് ഇൻഫോസിസ്റ്റംസ്

ദിമിത്രി എറിക്കിൻ, ജെറ്റ് ഇൻഫോസിസ്റ്റംസിലെ കമ്പ്യൂട്ടർ സിസ്റ്റങ്ങളുടെ ഡിസൈൻ എഞ്ചിനീയർ

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