Mail.ru ക്ലൗഡ് സൊല്യൂഷൻസ് പ്ലാറ്റ്‌ഫോമിൽ എങ്ങനെയാണ് തെറ്റ്-സഹിഷ്ണുതയുള്ള വെബ് ആർക്കിടെക്ചർ നടപ്പിലാക്കുന്നത്

ഹായ്, ഹബ്ര്‍! ഞാന്‍ ആര്‍ടെം കറമിഷേവ് ആണ്, സിസ്റ്റംസ് അഡ്മിനിസ്ട്രേഷന്‍ ടീമിന്റെ തലവന്‍. മെയിൽ.റു ക്ലൗഡ് സൊല്യൂഷൻസ് (എംസിഎസ്)കഴിഞ്ഞ ഒരു വർഷത്തിനിടെ ഞങ്ങൾ നിരവധി പുതിയ ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കി. ഞങ്ങളുടെ API സേവനങ്ങൾ എളുപ്പത്തിൽ അളക്കാവുന്നതും, തെറ്റുകളെ ചെറുക്കുന്നതും, ദ്രുതഗതിയിലുള്ള ഉപയോക്തൃ ലോഡ് വളർച്ചയ്ക്ക് തയ്യാറാകുന്നതും ആയിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിച്ചു. ഞങ്ങളുടെ പ്ലാറ്റ്‌ഫോം OpenStack-ൽ നിർമ്മിച്ചതാണ്, തെറ്റുകളെ ചെറുക്കുന്ന ഒരു സംവിധാനം കൈവരിക്കുന്നതിന് ഞങ്ങൾ പരിഹരിക്കേണ്ടി വന്ന ചില ഘടക തെറ്റുകളെ ചെറുക്കുന്ന പ്രശ്‌നങ്ങൾ പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. OpenStack-ൽ ഉൽപ്പന്നങ്ങൾ വികസിപ്പിക്കുന്നവർക്കും ഇത് താൽപ്പര്യമുള്ളതായിരിക്കുമെന്ന് ഞാൻ കരുതുന്നു.

പ്ലാറ്റ്‌ഫോമിന്റെ മൊത്തത്തിലുള്ള പ്രതിരോധശേഷി അതിന്റെ ഘടകങ്ങളുടെ പ്രതിരോധശേഷിയെ ആശ്രയിച്ചിരിക്കുന്നു. അതിനാൽ, അപകടസാധ്യതകൾ തിരിച്ചറിഞ്ഞ് അവ അഭിസംബോധന ചെയ്ത എല്ലാ തലങ്ങളിലൂടെയും ഞങ്ങൾ ക്രമേണ പ്രവർത്തിക്കും.

ഈ കഥയുടെ ഒരു വീഡിയോ പതിപ്പ്, ഇതിന്റെ യഥാർത്ഥ ഉറവിടം അപ്‌ടൈം ഡേ 4 കോൺഫറൻസിലെ ഒരു അവതരണമായിരുന്നു, ഇത് സംഘടിപ്പിച്ചത് ഐടിസുമ്മ, നിങ്ങൾക്ക് ഒന്ന് നോക്കാം അപ്‌ടൈം കമ്മ്യൂണിറ്റി യൂട്യൂബ് ചാനലിൽ.

ഭൗതിക വാസ്തുവിദ്യയുടെ തെറ്റ് സഹിഷ്ണുത

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

ഭൗതികവും യുക്തിപരവുമായ തലങ്ങളിൽ ഡാർക്ക് ഫൈബർ അനാവശ്യമാണ്. ചാനൽ റിഡൻഡൻസി പ്രക്രിയ ആവർത്തിച്ചുള്ളതായിരുന്നു, പ്രശ്നങ്ങൾ ഉയർന്നുവന്നെങ്കിലും, ഡാറ്റാ സെന്ററുകൾ തമ്മിലുള്ള കണക്ഷൻ ഞങ്ങൾ നിരന്തരം മെച്ചപ്പെടുത്തിക്കൊണ്ടിരിക്കുന്നു.

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

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

ഒരു ദാതാവ് പരാജയപ്പെടുകയാണെങ്കിൽ, ഞങ്ങൾ സ്വയമേവ അടുത്ത ദാതാവിലേക്ക് മാറുന്നു. ഒരു ഡാറ്റാ സെന്റർ പരാജയപ്പെട്ടാൽ, മുഴുവൻ ലോഡും ഏറ്റെടുക്കുന്ന രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിൽ ഞങ്ങളുടെ സേവനങ്ങളുടെ ഒരു മിറർ പകർപ്പ് ഞങ്ങളുടെ പക്കലുണ്ട്.

ഭൗതിക അടിസ്ഥാന സൗകര്യങ്ങളുടെ പ്രതിരോധശേഷി

ആപ്ലിക്കേഷൻ-ലെവൽ ഫോൾട്ട് ടോളറൻസിന് നമ്മൾ ഉപയോഗിക്കുന്നത്

ഞങ്ങളുടെ സേവനം നിരവധി ഓപ്പൺ സോഴ്‌സ് ഘടകങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

എക്സാബിജിപി — BGP-അധിഷ്ഠിത ഡൈനാമിക് റൂട്ടിംഗ് പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് നിരവധി പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കുന്ന ഒരു സേവനം. ഉപയോക്താക്കൾ API ആക്‌സസ് ചെയ്യുന്ന വൈറ്റ്‌ലിസ്റ്റ് ചെയ്‌ത IP വിലാസങ്ങൾ പരസ്യപ്പെടുത്തുന്നതിന് ഞങ്ങൾ ഇത് സജീവമായി ഉപയോഗിക്കുന്നു.

HAProxy — OSI മോഡലിന്റെ വ്യത്യസ്ത ലെയറുകളിൽ ഉയർന്ന വഴക്കമുള്ള ട്രാഫിക് ബാലൻസിംഗ് നിയമങ്ങൾ കോൺഫിഗർ ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു ഹൈ-ലോഡ് ലോഡ് ബാലൻസർ. എല്ലാ സേവനങ്ങളിലും ലോഡ് ബാലൻസിംഗിനായി ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു: ഡാറ്റാബേസുകൾ, സന്ദേശ ബ്രോക്കർമാർ, API സേവനങ്ങൾ, വെബ് സേവനങ്ങൾ, ഞങ്ങളുടെ ആന്തരിക പ്രോജക്റ്റുകൾ - എല്ലാം HAProxy ആണ് നൽകുന്നത്.

API ആപ്ലിക്കേഷൻ — പൈത്തണിൽ എഴുതിയ ഒരു വെബ് ആപ്ലിക്കേഷൻ, അതുപയോഗിച്ച് ഉപയോക്താവ് അവരുടെ അടിസ്ഥാന സൗകര്യങ്ങളും സേവനങ്ങളും കൈകാര്യം ചെയ്യുന്നു.

തൊഴിലാളി അപേക്ഷ (ഇനി മുതൽ വർക്കർ എന്ന് വിളിക്കുന്നു) ഓപ്പൺസ്റ്റാക്ക് സേവനങ്ങളിലെ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ ഡെമൺ ആണ്, ഇത് API കമാൻഡുകൾ ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് കൈമാറാൻ പ്രാപ്തമാക്കുന്നു. ഉദാഹരണത്തിന്, ഡിസ്ക് സൃഷ്ടി ഒരു വർക്കറിൽ സംഭവിക്കുന്നു, കൂടാതെ സൃഷ്ടി അഭ്യർത്ഥന API ആപ്ലിക്കേഷനിലേക്ക് അയയ്ക്കുന്നു.

ഓപ്പൺസ്റ്റാക്ക് ആപ്ലിക്കേഷൻ സ്റ്റാൻഡേർഡ് ആർക്കിടെക്ചർ

ഓപ്പൺസ്റ്റാക്കിനായി വികസിപ്പിച്ച മിക്ക സേവനങ്ങളും ഒരു ഏകീകൃത മാതൃക പിന്തുടരാൻ ശ്രമിക്കുന്നു. ഒരു സേവനത്തിൽ സാധാരണയായി രണ്ട് ഭാഗങ്ങളുണ്ട്: ഒരു API, വർക്കർമാർ (ബാക്കെൻഡ് എക്സിക്യൂട്ടർമാർ). സാധാരണയായി, API എന്നത് പൈത്തണിൽ എഴുതിയ ഒരു WSGI ആപ്ലിക്കേഷനാണ്, ഇത് ഒരു സ്വതന്ത്ര പ്രക്രിയയായി (ഡെമൺ) അല്ലെങ്കിൽ Nginx അല്ലെങ്കിൽ Apache പോലുള്ള ഒരു വെബ് സെർവർ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു. API ഉപയോക്താവിന്റെ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുകയും നിർവ്വഹണത്തിനായി വർക്കർ ആപ്ലിക്കേഷനിലേക്ക് കൂടുതൽ നിർദ്ദേശങ്ങൾ കൈമാറുകയും ചെയ്യുന്നു. ഈ ട്രാൻസ്മിഷൻ ഒരു സന്ദേശ ബ്രോക്കർ വഴിയാണ് സംഭവിക്കുന്നത്, സാധാരണയായി RabbitMQ; മറ്റ് തരങ്ങൾക്ക് പിന്തുണയില്ല. സന്ദേശങ്ങൾ ബ്രോക്കറിൽ എത്തുമ്പോൾ, തൊഴിലാളികൾ അവ പ്രോസസ്സ് ചെയ്യുകയും ആവശ്യമെങ്കിൽ ഒരു പ്രതികരണം നൽകുകയും ചെയ്യുന്നു.

ഈ മാതൃക പരാജയത്തിന്റെ ഒറ്റപ്പെട്ട പൊതുവായ പോയിന്റുകളെ സൂചിപ്പിക്കുന്നു: RabbitMQ ഉം ഡാറ്റാബേസും. എന്നിരുന്നാലും, RabbitMQ ഒരൊറ്റ സേവനത്തിനുള്ളിൽ ഒറ്റപ്പെട്ടതാണ്, തത്വത്തിൽ, ഓരോ സേവനത്തിനും പ്രത്യേകമായിരിക്കാം. അതിനാൽ, MCS-ൽ, ഞങ്ങൾ ഈ സേവനങ്ങളെ കഴിയുന്നത്ര വേർതിരിക്കുന്നു, ഓരോ വ്യക്തിഗത പ്രോജക്റ്റിനും ഒരു പ്രത്യേക ഡാറ്റാബേസും ഒരു പ്രത്യേക RabbitMQ ഉം സൃഷ്ടിക്കുന്നു. ദുർബലമായ ഒരു ഘട്ടത്തിൽ ഒരു പരാജയം സംഭവിച്ചാൽ, മുഴുവൻ സേവനത്തെയും അല്ല, സേവനത്തിന്റെ ഒരു ഭാഗം മാത്രമേ ബാധിക്കുകയുള്ളൂ എന്നതിനാൽ ഈ സമീപനം പ്രയോജനകരമാണ്.

വർക്കർ ആപ്ലിക്കേഷനുകളുടെ എണ്ണത്തിന് പരിധിയില്ല, അതിനാൽ പ്രകടനവും തെറ്റ് സഹിഷ്ണുതയും വർദ്ധിപ്പിക്കുന്നതിന് ബാലൻസറുകൾക്ക് പിന്നിൽ API എളുപ്പത്തിൽ തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യാൻ കഴിയും.

ചില സേവനങ്ങൾക്ക് ഇൻട്രാ-സർവീസ് ഏകോപനം ആവശ്യമാണ്—എപിഐകൾക്കും തൊഴിലാളികൾക്കും ഇടയിൽ സങ്കീർണ്ണമായ തുടർച്ചയായ പ്രവർത്തനങ്ങൾ നടക്കുമ്പോൾ. ഈ സാഹചര്യത്തിൽ, ഒരൊറ്റ ഏകോപന കേന്ദ്രം ഉപയോഗിക്കുന്നു, റെഡിസ്, മെംകാഷെ, etcd പോലുള്ള ഒരു ക്ലസ്റ്റർ സിസ്റ്റം, ഇത് ഒരു തൊഴിലാളിയെ മറ്റൊരു ജോലിക്കാരന് ഒരു ടാസ്‌ക് ഏൽപ്പിച്ചിട്ടുണ്ടെന്ന് പറയാൻ അനുവദിക്കുന്നു ("ദയവായി അത് എടുക്കരുത്"). ഞങ്ങൾ etcd ഉപയോഗിക്കുന്നു. സാധാരണയായി, തൊഴിലാളികൾ ഡാറ്റാബേസുമായി സജീവമായി ആശയവിനിമയം നടത്തുന്നു, അതിൽ നിന്ന് വിവരങ്ങൾ എഴുതുകയും വായിക്കുകയും ചെയ്യുന്നു. ഞങ്ങളുടെ മൾട്ടി-മാസ്റ്റർ ക്ലസ്റ്ററിൽ സ്ഥിതി ചെയ്യുന്ന ഞങ്ങളുടെ ഡാറ്റാബേസായി ഞങ്ങൾ mariadb ഉപയോഗിക്കുന്നു.

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

ഈ സ്കീമിലെ ദുർബലമായ പോയിന്റുകൾ RabbitMQ ഉം MariaDB ഉം ആണ്. അവയുടെ ആർക്കിടെക്ചർ ഒരു പ്രത്യേക ലേഖനം അർഹിക്കുന്നു. ഈ ലേഖനത്തിൽ, API ഫോൾട്ട് ടോളറൻസിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ഓപ്പൺസ്റ്റാക്ക് ആപ്ലിക്കേഷൻ ആർക്കിടെക്ചർ: ഒരു ക്ലൗഡ് പ്ലാറ്റ്‌ഫോമിനുള്ള ബാലൻസിംഗും ഫോൾട്ട് ടോളറൻസും

ExaBGP ഉപയോഗിച്ച് HAProxy ലോഡ് ബാലൻസർ തെറ്റ്-സഹിഷ്ണുതയുള്ളതാക്കുന്നു

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

ലോഡ് ബാലൻസറിന്റെ തന്നെ തെറ്റ് സഹിഷ്ണുതയായിരുന്നു ആദ്യം പരിഹരിക്കേണ്ട പ്രശ്നം. ലോഡ് ബാലൻസർ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് തന്നെ ഒരു പരാജയ പോയിന്റ് സൃഷ്ടിക്കുന്നു: ലോഡ് ബാലൻസർ പരാജയപ്പെടുകയാണെങ്കിൽ, സേവനം പ്രവർത്തനരഹിതമാകും. ഇത് തടയാൻ, ഞങ്ങൾ ExaBGP-യുമായി ചേർന്ന് HAProxy ഉപയോഗിച്ചു.

ExaBGP ഒരു സർവീസ് ഹെൽത്ത് ചെക്ക് മെക്കാനിസം പ്രാപ്തമാക്കുന്നു. HAProxy-യുടെ ആരോഗ്യം പരിശോധിക്കുന്നതിനും, പ്രശ്നങ്ങൾ ഉണ്ടായാൽ, BGP-യിൽ നിന്നുള്ള HAProxy സേവനം പ്രവർത്തനരഹിതമാക്കുന്നതിനും ഞങ്ങൾ ഈ മെക്കാനിസം ഉപയോഗിച്ചു.

ExaBGP+HAProxy സ്കീം

1. മൂന്ന് സെർവറുകളിൽ ആവശ്യമായ സോഫ്റ്റ്‌വെയർ, ExaBGP, HAProxy എന്നിവ ഞങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു.
2. ഓരോ സെർവറുകളിലും ഞങ്ങൾ ഒരു ലൂപ്പ്ബാക്ക് ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നു.
3. മൂന്ന് സെർവറുകളിലും, ഈ ഇന്റർഫേസിൽ ഞങ്ങൾ ഒരേ വെളുത്ത ഐപി വിലാസം രജിസ്റ്റർ ചെയ്യുന്നു.
4. ExaBGP വഴി വെള്ള ഐപി വിലാസം ഇന്റർനെറ്റിൽ പ്രഖ്യാപിക്കുന്നു.

മൂന്ന് സെർവറുകളിൽ നിന്നും ഒരേ ഐപി വിലാസം പരസ്യപ്പെടുത്തുന്നതിലൂടെയാണ് തെറ്റ് സഹിഷ്ണുത കൈവരിക്കുന്നത്. നെറ്റ്‌വർക്കിന്റെ വീക്ഷണകോണിൽ നിന്ന്, മൂന്ന് വ്യത്യസ്ത അടുത്ത ഹോപ്പുകളിൽ നിന്ന് ഒരേ വിലാസം ആക്‌സസ് ചെയ്യാൻ കഴിയും. റൂട്ടർ മൂന്ന് സമാന റൂട്ടുകൾ കാണുന്നു, സ്വന്തം മെട്രിക് അടിസ്ഥാനമാക്കി ഉയർന്ന മുൻഗണനയുള്ള റൂട്ട് തിരഞ്ഞെടുക്കുന്നു (സാധാരണയായി ഒരേ റൂട്ട്), ട്രാഫിക് സെർവറുകളിൽ ഒന്നിലേക്ക് മാത്രമേ റൂട്ട് ചെയ്യൂ.

HAProxy യിൽ പ്രശ്‌നങ്ങൾ ഉണ്ടായാലോ സെർവർ പരാജയം ഉണ്ടായാലോ, ExaBGP റൂട്ട് പരസ്യം ചെയ്യുന്നത് നിർത്തുകയും ട്രാഫിക് മറ്റൊരു സെർവറിലേക്ക് സുഗമമായി മാറുകയും ചെയ്യും.

ഈ രീതിയിൽ, ഞങ്ങൾ ബാലൻസറിന്റെ തെറ്റ് സഹിഷ്ണുത നേടി.

HAProxy ലോഡ് ബാലൻസർ ഫോൾട്ട് ടോളറൻസ്

സജ്ജീകരണം മികച്ചതായിരുന്നില്ല: HAProxy ബാക്കപ്പ് ചെയ്യാൻ ഞങ്ങൾ പഠിച്ചു, പക്ഷേ സേവനങ്ങളിലുടനീളം ലോഡ് എങ്ങനെ വിതരണം ചെയ്യണമെന്ന് ഞങ്ങൾ പഠിച്ചില്ല. അതിനാൽ ഞങ്ങൾ സജ്ജീകരണം ചെറുതായി വികസിപ്പിച്ചു, ഒന്നിലധികം പൊതു IP വിലാസങ്ങളിലുടനീളം ലോഡ് ബാലൻസിംഗിലേക്ക് മാറി.

DNS-അധിഷ്ഠിത ലോഡ് ബാലൻസിംഗ് പ്ലസ് BGP

നമ്മുടെ HAProxy യുടെ മുന്നിലുള്ള ലോഡ് ബാലൻസിംഗ് പ്രശ്നം പരിഹരിക്കപ്പെട്ടിട്ടില്ല. എന്നിരുന്നാലും, നമ്മൾ സ്വന്തമായി ചെയ്തതുപോലെ, ഇത് വളരെ എളുപ്പത്തിൽ പരിഹരിക്കാൻ കഴിയും.

മൂന്ന് സെർവറുകൾ സന്തുലിതമാക്കാൻ, നിങ്ങൾക്ക് മൂന്ന് പൊതു IP വിലാസങ്ങളും നല്ല പഴയ DNS-ഉം ആവശ്യമാണ്. ഈ വിലാസങ്ങൾ ഓരോന്നും ഓരോ HAProxy-യുടെയും ലൂപ്പ്ബാക്ക് ഇന്റർഫേസിലേക്ക് നിയോഗിക്കുകയും ഇന്റർനെറ്റിൽ പരസ്യപ്പെടുത്തുകയും ചെയ്യുന്നു.

ഓരോ സേവനത്തിനുമുള്ള API എൻഡ്‌പോയിന്റ് നിർവചിക്കുന്ന ഒരു സേവന കാറ്റലോഗ് ആണ് OpenStack റിസോഴ്‌സുകൾ കൈകാര്യം ചെയ്യാൻ ഉപയോഗിക്കുന്നത്. ഈ കാറ്റലോഗിൽ, ഞങ്ങൾ ഒരു ഡൊമെയ്ൻ നാമം വ്യക്തമാക്കുന്നു—public.infra.mail.ru—അത് DNS വഴി മൂന്ന് വ്യത്യസ്ത IP വിലാസങ്ങളിലേക്ക് പരിഹരിക്കുന്നു. ഇത് DNS ഉപയോഗിച്ച് മൂന്ന് വിലാസങ്ങളിലുടനീളം ലോഡ് ബാലൻസിംഗിന് കാരണമാകുന്നു.

എന്നിരുന്നാലും, വൈറ്റ്‌ലിസ്റ്റ് ചെയ്‌ത IP വിലാസങ്ങൾ പ്രഖ്യാപിക്കുമ്പോൾ സെർവർ തിരഞ്ഞെടുക്കൽ മുൻഗണനകൾ ഞങ്ങൾ നിയന്ത്രിക്കാത്തതിനാൽ, ഇത് ഇതുവരെ ബാലൻസ് ചെയ്തിട്ടില്ല. സാധാരണയായി, ഏറ്റവും ഉയർന്ന IP വിലാസത്തെ അടിസ്ഥാനമാക്കി ഒരു സെർവർ മാത്രമേ തിരഞ്ഞെടുക്കൂ, അതേസമയം BGP-യിൽ മെട്രിക്സുകളൊന്നും വ്യക്തമാക്കിയിട്ടില്ലാത്തതിനാൽ മറ്റ് രണ്ടെണ്ണം നിഷ്‌ക്രിയമായി തുടരും.

വ്യത്യസ്ത മെട്രിക്സുകളുള്ള ExaBGP വഴി റൂട്ടുകൾ വിതരണം ചെയ്യാൻ ഞങ്ങൾ ആരംഭിച്ചു. ഓരോ ലോഡ് ബാലൻസറും വൈറ്റ്‌ലിസ്റ്റ് ചെയ്ത മൂന്ന് IP വിലാസങ്ങളെയും പരസ്യപ്പെടുത്തുന്നു, എന്നാൽ അവയിലൊന്നായ ആ ലോഡ് ബാലൻസറിനായുള്ള പ്രാഥമിക IP വിലാസം, ഏറ്റവും കുറഞ്ഞ മെട്രിക് ഉപയോഗിച്ചാണ് പരസ്യപ്പെടുത്തുന്നത്. അതിനാൽ, മൂന്ന് ലോഡ് ബാലൻസറുകളും പ്രവർത്തനക്ഷമമാണെങ്കിലും, ആദ്യത്തെ IP വിലാസത്തിലേക്കുള്ള അഭ്യർത്ഥനകൾ ആദ്യത്തെ ലോഡ് ബാലൻസറിലേക്കും, രണ്ടാമത്തേതിലേക്കുള്ള അഭ്യർത്ഥനകൾ രണ്ടാമത്തേതിലേക്കും, മൂന്നാമത്തേതിലേക്കുള്ള അഭ്യർത്ഥനകൾ മൂന്നാമത്തേതിലേക്കും പോകുന്നു.

ലോഡ് ബാലൻസറുകളിൽ ഒന്ന് പരാജയപ്പെടുമ്പോൾ എന്തുസംഭവിക്കും? ഏതെങ്കിലും ലോഡ് ബാലൻസർ പരാജയപ്പെട്ടാൽ, അതിന്റെ പ്രാഥമിക വിലാസം മറ്റ് രണ്ടെണ്ണം ഇപ്പോഴും പരസ്യപ്പെടുത്തുകയും ട്രാഫിക് അവയ്ക്കിടയിൽ പുനർവിതരണം ചെയ്യുകയും ചെയ്യുന്നു. ഈ രീതിയിൽ, ഞങ്ങൾ ഉപയോക്താവിന് DNS വഴി ഒന്നിലധികം IP വിലാസങ്ങൾ നൽകുന്നു. DNS വഴിയും വ്യത്യസ്ത മെട്രിക്സുകളിലൂടെയും ബാലൻസ് ചെയ്യുന്നതിലൂടെ, മൂന്ന് ലോഡ് ബാലൻസറുകളിലും തുല്യമായ ലോഡ് വിതരണം ഞങ്ങൾ കൈവരിക്കുന്നു, അതേസമയം തെറ്റ് സഹിഷ്ണുത നിലനിർത്തുന്നു.

DNS, BGP എന്നിവയുമായുള്ള HAProxy ലോഡ് ബാലൻസിങ്

ExaBGP-യും HAProxy-യും തമ്മിലുള്ള ഇടപെടൽ

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

അതിനാൽ, മുമ്പത്തെ സ്കീം വികസിപ്പിച്ചുകൊണ്ട്, ഞങ്ങൾ ExaBGP യും HAProxy യും തമ്മിലുള്ള ഒരു ഹാർട്ട്ബീറ്റ് നടപ്പിലാക്കി. ExaBGP യും HAProxy യും തമ്മിലുള്ള ഇടപെടലിന്റെ ഒരു സോഫ്റ്റ്‌വെയർ നടപ്പിലാക്കലാണിത്, ഇവിടെ ExaBGP ആപ്ലിക്കേഷനുകളുടെ നില പരിശോധിക്കാൻ ഇഷ്ടാനുസൃത സ്ക്രിപ്റ്റുകൾ ഉപയോഗിക്കുന്നു.

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

HAProxy ആരോഗ്യ പരിശോധന

HAProxy പിയേഴ്‌സ്: സെഷൻ സിൻക്രൊണൈസേഷൻ

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

ബാലൻസിംഗിന് വ്യത്യസ്ത രീതികളുണ്ട്: ലളിതമായവ, ഉദാഹരണത്തിന് റ round ണ്ട് റോബിൻ, കൂടാതെ ക്ലയന്റിന്റെ സെഷൻ ഓർമ്മിക്കപ്പെടുകയും ഓരോ തവണയും ഒരേ സെർവറിലേക്ക് നയിക്കപ്പെടുകയും ചെയ്യുന്ന വിപുലീകൃതമായവയും. രണ്ടാമത്തെ ഓപ്ഷൻ നടപ്പിലാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു.

ക്ലയന്റ് സെഷനുകൾ സംഭരിക്കുന്നതിന് HAProxy സ്റ്റിക്ക് ടേബിളുകൾ ഉപയോഗിക്കുന്നു. അവ ക്ലയന്റിന്റെ ഉറവിട IP വിലാസം, തിരഞ്ഞെടുത്ത ലക്ഷ്യ വിലാസം (ബാക്കെൻഡ്), ചില സേവന വിവരങ്ങൾ എന്നിവ സംഭരിക്കുന്നു. സ്റ്റിക്ക് ടേബിളുകൾ സാധാരണയായി സോഴ്‌സ്-IP, ഡെസ്റ്റിനേഷൻ-IP ജോഡികൾ സംഭരിക്കാൻ ഉപയോഗിക്കുന്നു, ഇത് റൗണ്ട് റോബിൻ ലോഡ് ബാലൻസിംഗ് മോഡ് പോലുള്ള മറ്റൊരു ലോഡ് ബാലൻസറിലേക്ക് മാറുമ്പോൾ ഉപയോക്തൃ സെഷൻ സന്ദർഭം കൈമാറാൻ കഴിയാത്ത ആപ്ലിക്കേഷനുകൾക്ക് പ്രത്യേകിച്ചും ഉപയോഗപ്രദമാണ്.

വ്യത്യസ്ത HAProxy പ്രക്രിയകൾക്കിടയിൽ (ഇവയ്ക്കിടയിൽ ലോഡ് ബാലൻസിംഗ് സംഭവിക്കുന്നു) സ്റ്റിക്ക് ടേബിളിനെ നീങ്ങാൻ പഠിപ്പിക്കുന്നതിലൂടെ, ഞങ്ങളുടെ ലോഡ് ബാലൻസറുകൾക്ക് സ്റ്റിക്ക് ടേബിളുകളുടെ ഒരൊറ്റ പൂളുമായി പ്രവർത്തിക്കാൻ കഴിയും. ഒരു ലോഡ് ബാലൻസർ പരാജയപ്പെട്ടാൽ തടസ്സമില്ലാത്ത ക്ലയന്റ് നെറ്റ്‌വർക്ക് ഫെയിൽഓവർ ഇത് പ്രാപ്തമാക്കും, കൂടാതെ മുമ്പ് തിരഞ്ഞെടുത്ത അതേ ബാക്കെൻഡുകളിൽ ക്ലയന്റ് സെഷനുകൾ നൽകുന്നത് തുടരും.

ശരിയായ പ്രവർത്തനത്തിന്, സെഷൻ സ്ഥാപിച്ചിരിക്കുന്ന ലോഡ് ബാലൻസറിന്റെ ഉറവിട ഐപി വിലാസത്തിലെ പ്രശ്നം പരിഹരിക്കപ്പെടണം. ഞങ്ങളുടെ കാര്യത്തിൽ, ഇത് ലൂപ്പ്ബാക്ക് ഇന്റർഫേസിലെ ഒരു ഡൈനാമിക് വിലാസമാണ്.

ചില പ്രത്യേക സാഹചര്യങ്ങളിൽ മാത്രമേ പിയറുകൾ ശരിയായി പ്രവർത്തിക്കൂ. പ്രത്യേകിച്ചും, TCP ടൈംഔട്ടുകൾ ആവശ്യത്തിന് ദൈർഘ്യമുള്ളതായിരിക്കണം, അല്ലെങ്കിൽ TCP സെഷൻ അവസാനിപ്പിക്കുന്നത് തടയാൻ സ്വിച്ച്ഓവർ വേഗതയുള്ളതായിരിക്കണം. എന്നിരുന്നാലും, ഇത് സുഗമമായ സ്വിച്ചിംഗിന് അനുവദിക്കുന്നു.

അതേ സാങ്കേതികവിദ്യ ഉപയോഗിച്ച് നിർമ്മിച്ച IaaS-ൽ ഞങ്ങൾക്ക് ഒരു സേവനമുണ്ട്. ഓപ്പൺസ്റ്റാക്കിനുള്ള ഒരു സേവനമായി ലോഡ് ബാലൻസർഒക്ടാവിയ എന്ന് വിളിക്കപ്പെടുന്നു. ഇത് രണ്ട് HAProxy പ്രക്രിയകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, കൂടാതെ സഹപ്രവർത്തകർക്ക് നേറ്റീവ് പിന്തുണയുമുണ്ട്. ഈ സേവനത്തിന് അവർ മികച്ചവരാണെന്ന് തെളിയിച്ചിട്ടുണ്ട്.

മൂന്ന് HAProxy സംഭവങ്ങൾക്കിടയിലുള്ള പിയർ ടേബിളുകളുടെ ചലനം ചിത്രം സ്കീമാറ്റിക് ആയി ചിത്രീകരിക്കുന്നു, ഇത് എങ്ങനെ സജ്ജീകരിക്കാമെന്ന് വ്യക്തമാക്കുന്നതിന് ഒരു കോൺഫിഗറേഷൻ നൽകിയിരിക്കുന്നു:

HAProxy പിയേഴ്‌സ് (സെഷൻ സിൻക്രൊണൈസേഷൻ)

സമാനമായ ഒരു സ്കീം നിങ്ങൾ നടപ്പിലാക്കുകയാണെങ്കിൽ, നിങ്ങൾ അത് ശ്രദ്ധാപൂർവ്വം പരിശോധിക്കണം. ഇത് 100% സമയവും പ്രവർത്തിക്കുമെന്ന് ഉറപ്പില്ല. എന്നാൽ ക്ലയന്റിന്റെ ഉറവിട ഐപി ഓർമ്മിക്കേണ്ടിവരുമ്പോൾ നിങ്ങളുടെ സ്റ്റിക്കി ടേബിളുകൾ നഷ്ടപ്പെടില്ല.

ഒരേ ക്ലയന്റിൽ നിന്നുള്ള ഒരേസമയം അഭ്യർത്ഥനകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുന്നു

ഞങ്ങളുടെ API-കൾ ഉൾപ്പെടെ, പൊതുവായി ആക്‌സസ് ചെയ്യാവുന്ന ഏതൊരു സേവനവും അഭ്യർത്ഥനകളുടെ ഒരു പ്രളയത്തിന് വിധേയമാകാം. ഉപയോക്തൃ പിശകുകൾ മുതൽ ടാർഗെറ്റുചെയ്‌ത ആക്രമണങ്ങൾ വരെ കാരണങ്ങൾ വ്യാപകമായി വ്യത്യാസപ്പെടാം. ഞങ്ങൾ ഇടയ്ക്കിടെ IP DDoS ആക്രമണങ്ങൾ നേരിടുന്നു. ക്ലയന്റുകൾ പലപ്പോഴും അവരുടെ സ്ക്രിപ്റ്റുകളിൽ പിശകുകൾ വരുത്തുകയും മിനി-DDoS ആക്രമണങ്ങൾക്ക് കാരണമാവുകയും ചെയ്യുന്നു.

എന്തായാലും, അധിക സുരക്ഷാ നടപടികൾ ആവശ്യമാണ്. API അഭ്യർത്ഥനകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുകയും ക്ഷുദ്രകരമായ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതിൽ CPU സമയം പാഴാക്കുന്നത് ഒഴിവാക്കുകയും ചെയ്യുക എന്നതാണ് ഒരു വ്യക്തമായ പരിഹാരം.

ഈ നിയന്ത്രണങ്ങൾ നടപ്പിലാക്കാൻ, അതേ സ്റ്റിക്ക് ടേബിളുകൾ ഉപയോഗിച്ച് HAProxy-യിൽ നിർമ്മിച്ച റേറ്റ് പരിധികൾ ഞങ്ങൾ ഉപയോഗിക്കുന്നു. പരിധികൾ ക്രമീകരിക്കാൻ വളരെ എളുപ്പമാണ് കൂടാതെ ഒരു ഉപയോക്താവിന് ചെയ്യാൻ കഴിയുന്ന API അഭ്യർത്ഥനകളുടെ എണ്ണം പരിമിതപ്പെടുത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു. അഭ്യർത്ഥനകൾ നടത്തുന്ന ഉറവിട IP-യെ അൽഗോരിതം ഓർമ്മിക്കുകയും ഓരോ ഉപയോക്താവിനും ഒരേസമയം അഭ്യർത്ഥനകളുടെ എണ്ണം പരിമിതപ്പെടുത്തുകയും ചെയ്യുന്നു. സ്വാഭാവികമായും, ഓരോ സേവനത്തിനും ശരാശരി API ലോഡ് പ്രൊഫൈൽ ഞങ്ങൾ കണക്കാക്കുകയും ഈ മൂല്യത്തേക്കാൾ ഏകദേശം 10 മടങ്ങ് കൂടുതൽ പരിധി നിശ്ചയിക്കുകയും ചെയ്തു. സ്ഥിതിഗതികൾ സൂക്ഷ്മമായി നിരീക്ഷിച്ചുകൊണ്ട് ഞങ്ങൾ തുടരുന്നു.

ഇത് പ്രായോഗികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നു? ഓട്ടോസ്കെയിലിംഗിനായി ഞങ്ങളുടെ API-കൾ നിരന്തരം ഉപയോഗിക്കുന്ന ഉപഭോക്താക്കളുണ്ട്. അവർ രാവിലെ ഏകദേശം ഇരുനൂറ് മുതൽ മുന്നൂറ് വരെ വെർച്വൽ മെഷീനുകൾ സൃഷ്ടിക്കുകയും വൈകുന്നേരം അവ ഇല്ലാതാക്കുകയും ചെയ്യുന്നു. OpenStack-ന്, പ്രത്യേകിച്ച് PaaS സേവനങ്ങളിൽ ഒരു വെർച്വൽ മെഷീൻ സൃഷ്ടിക്കുന്നതിന്, കുറഞ്ഞത് 1000 API അഭ്യർത്ഥനകളെങ്കിലും ആവശ്യമാണ്, കാരണം സേവനങ്ങൾ തമ്മിലുള്ള ഇടപെടലുകളും API-കൾ വഴിയാണ് സംഭവിക്കുന്നത്.

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

ഉപയോക്താക്കൾക്കായി നിങ്ങളുടെ കോഡ്ബേസ് എങ്ങനെ തടസ്സമില്ലാതെ അപ്ഡേറ്റ് ചെയ്യാം

കോഡ് വിന്യാസ പ്രക്രിയ തലത്തിലും ഞങ്ങൾ തെറ്റ് സഹിഷ്ണുത നടപ്പിലാക്കുന്നു. വിന്യാസ സമയത്ത് പരാജയങ്ങൾ സംഭവിക്കാറുണ്ട്, പക്ഷേ സേവന ലഭ്യതയിൽ അവയുടെ ആഘാതം കുറയ്ക്കാൻ കഴിയും.

ഞങ്ങളുടെ സേവനങ്ങൾ ഞങ്ങൾ നിരന്തരം അപ്‌ഡേറ്റ് ചെയ്യുന്നു, ഉപയോക്താക്കളെ ബാധിക്കാതെ കോഡ്‌ബേസ് അപ്‌ഡേറ്റുകൾ നടപ്പിലാക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കണം. HAProxy-യുടെ മാനേജ്‌മെന്റ് കഴിവുകൾ പ്രയോജനപ്പെടുത്തിക്കൊണ്ടും ഞങ്ങളുടെ സേവനങ്ങളിൽ ഗ്രേസ്‌ഫുൾ ഷട്ട്‌ഡൗൺ നടപ്പിലാക്കിക്കൊണ്ടുമാണ് ഞങ്ങൾ ഇത് നേടിയത്.

ഈ പ്രശ്നം പരിഹരിക്കുന്നതിന്, ബാലൻസർ മാനേജ്മെന്റും "ശരിയായ" സർവീസ് ഷട്ട്ഡൗണും ഉറപ്പാക്കേണ്ടത് ആവശ്യമാണ്:

• HAProxy-യിൽ, മാനേജ്മെന്റ് കൈകാര്യം ചെയ്യുന്നത് ഒരു സ്റ്റാറ്റ്സ് ഫയൽ വഴിയാണ്, ഇത് അടിസ്ഥാനപരമായി HAProxy കോൺഫിഗറേഷൻ ഫയലിൽ നിർവചിച്ചിരിക്കുന്ന ഒരു സോക്കറ്റാണ്. കമാൻഡുകൾ stdio വഴി അതിലേക്ക് കൈമാറാൻ കഴിയും. എന്നിരുന്നാലും, ഞങ്ങളുടെ പ്രാഥമിക കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് ടൂൾ Ansible ആണ്, അതിനാൽ HAProxy കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു ബിൽറ്റ്-ഇൻ മൊഡ്യൂൾ ഇതിലുണ്ട്, അത് ഞങ്ങൾ സജീവമായി ഉപയോഗിക്കുന്നു.
• ഞങ്ങളുടെ മിക്ക API, എഞ്ചിൻ സേവനങ്ങളും മനോഹരമായ ഷട്ട്ഡൗൺ പിന്തുണയ്ക്കുന്നു: ഷട്ട് ഡൗൺ ചെയ്യുമ്പോൾ, നിലവിലുള്ള ടാസ്‌ക് പൂർത്തിയാകുന്നതുവരെ അവ കാത്തിരിക്കുന്നു, അത് ഒരു HTTP അഭ്യർത്ഥനയോ മറ്റേതെങ്കിലും സേവന ടാസ്‌കോ ആകട്ടെ. ഒരു തൊഴിലാളിയുടെ കാര്യത്തിലും ഇതുതന്നെ സംഭവിക്കുന്നു. അത് ചെയ്യുന്ന എല്ലാ ജോലികളും അത് അറിയുകയും എല്ലാം വിജയകരമായി പൂർത്തിയാകുമ്പോൾ അവസാനിപ്പിക്കുകയും ചെയ്യുന്നു.

ഈ രണ്ട് പോയിന്റുകൾക്ക് നന്ദി, ഞങ്ങളുടെ സുരക്ഷിത വിന്യാസ അൽഗോരിതം ഇതുപോലെ കാണപ്പെടുന്നു.

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

ഇതോടെ വിന്യാസം പൂർത്തിയാകുന്നു.

സേവന അപ്‌ഡേറ്റ് സൈക്കിൾ

ഒരു നിയമം ഇല്ലായിരുന്നെങ്കിൽ ഈ സിസ്റ്റം പ്രവർത്തിക്കില്ലായിരുന്നു. പഴയതും പുതിയതുമായ പതിപ്പുകൾ ഞങ്ങൾ ഒരേസമയം പരിപാലിക്കുന്നു. സോഫ്റ്റ്‌വെയർ വികസന സമയത്ത്, സേവനത്തിന്റെ ഡാറ്റാബേസിൽ മാറ്റങ്ങൾ വരുത്തിയാലും, അവ മുമ്പത്തെ കോഡിനെ തകർക്കില്ലെന്ന് ഞങ്ങൾ തുടക്കം മുതൽ ഉറപ്പാക്കുന്നു. തൽഫലമായി, കോഡ്ബേസ് ക്രമേണ അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്നു.

തീരുമാനം

തെറ്റുകളെ സഹിക്കുന്ന വെബ് ആർക്കിടെക്ചറിനെക്കുറിച്ചുള്ള എന്റെ ചിന്തകൾ പങ്കുവെക്കുമ്പോൾ, അതിന്റെ പ്രധാന പോയിന്റുകൾ ഞാൻ ആവർത്തിക്കാൻ ആഗ്രഹിക്കുന്നു:

• ശാരീരികമായ തെറ്റുകൾ സഹിക്കാനുള്ള കഴിവ്;
• നെറ്റ്‌വർക്ക് ഫോൾട്ട് ടോളറൻസ് (ബാലൻസറുകൾ, ബിജിപി);
• ഉപയോഗിക്കുന്നതും വികസിപ്പിച്ചതുമായ സോഫ്റ്റ്‌വെയറിന്റെ തെറ്റ് സഹിഷ്ണുത.

എല്ലാവർക്കും സ്ഥിരതയുള്ള പ്രവർത്തനസമയം ആശംസിക്കുന്നു!

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