Squid ഫോർവേഡ് പ്രോക്സിക്കായി HAProxy ആരോഗ്യ പരിശോധനകൾ

പ്രോക്സി ഹോസ്റ്റിലെ /check.txt എന്ന ഫയൽ ആരോഗ്യത്തിന്റെ വ്യക്തമായ ലക്ഷ്യമായി തോന്നുന്നു. പ്രശ്നം, Squid ന്റെ വ്യക്തമായ ഫോർവേഡ് ലിസണർ ആ ഹോസ്റ്റിന്റെ ഡോക്യുമെന്റ് റൂട്ട് നൽകുന്ന സാധാരണ വെബ്സൈറ്റ് അല്ല എന്നതാണ്.

HEAD /check.txt HTTP/1.1 പോലുള്ള ഉറവിട ശൈലിയിലുള്ള അഭ്യർത്ഥന ഫോർവേഡ് പ്രോക്സി വഴിയുള്ള സാധാരണ HTTP അഭ്യർത്ഥനയ്ക്ക് പ്രതീക്ഷിക്കുന്ന കേവല ലക്ഷ്യം ഒഴിവാക്കുന്നു. കോൺഫിഗറേഷൻ അനുസരിച്ച് അത് നിരസിക്കപ്പെടാം അല്ലെങ്കിൽ മറ്റൊരു പ്രാദേശിക സേവനം കൈകാര്യം ചെയ്യാം. രണ്ട് ഫലങ്ങളും ഡാഷ്ബോർഡ് സൂചിപ്പിക്കുന്നതിലും കുറച്ച് പറഞ്ഞേക്കാം.

ലഭ്യമായി നിലനിർത്തേണ്ട സേവനം തിരഞ്ഞെടുക്കുക

മൂന്നാമത്തെ കേസിൽ അഭ്യർത്ഥനയ്ക്ക് ലക്ഷ്യം വേണം, ഉദാഹരണത്തിന്:

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

ഹോസ്റ്റ്നെയിം ഉദാഹരണത്തിന് മാത്രം. പ്രോക്സിക്ക് പരിഹരിക്കാനാകുന്നതും ബോധപൂർവം എത്തിച്ചേരാൻ അനുവാദമുള്ളതുമായ നിയന്ത്രിത എൻഡ്പോയിന്റ് ഉപയോഗിക്കുക. HAProxy യുടെ http-check send രീതി, URI, പതിപ്പ്, ഹെഡറുകൾ എന്നിവ തിരഞ്ഞെടുക്കുന്നത് പിന്തുണയ്ക്കുന്നു; ഒറിജിൻ സെർവർ ഉദാഹരണം മാറ്റമില്ലാതെ പാരമ്പര്യമായി സ്വീകരിക്കുന്നതിന് പകരം ആ അഭ്യർത്ഥന വ്യക്തമായി കോൺഫിഗർ ചെയ്യുക.

HEAD പ്രതികരണ നിലയും ഹെഡറുകളും പരിശോധിക്കാം. ഒരിക്കലും കൈമാറാത്ത പ്രതികരണ ബോഡി അതിന് സാധൂകരിക്കാനാവില്ല. ആരോഗ്യ കരാർ ബോഡിയിൽ അടയാളം ആവശ്യപ്പെടുന്നുവെങ്കിൽ അനുയോജ്യമായ GET പരിശോധന തിരഞ്ഞെടുത്ത് ആ അടയാളം സാധൂകരിക്കുക.

പ്രോക്സി പ്രാമാണീകരണം ഉൾപ്പെടുമ്പോൾ പരിശോധന അക്കൗണ്ടും ഉറവിട നിയന്ത്രണങ്ങളും ഇടുങ്ങിയതാക്കുക. പച്ച അടയാളം ലഭിക്കാൻ മുഴുവൻ ലിസണറും പ്രാമാണീകരണത്തിൽ നിന്ന് ഒഴിവാക്കുന്നത് സംരക്ഷിക്കപ്പെടുന്ന സേവനത്തെ മാറ്റുന്നു.

അവസാനം, പരാജയപ്പെട്ട പരിശോധന എന്താണ് നീക്കം ചെയ്യേണ്ടതെന്ന് തീരുമാനിക്കുക. നിയന്ത്രിത ഉറവിട തടസ്സം എല്ലാ പ്രോക്സികളുടെയും ഫോർവേഡിംഗ് പരിശോധന ഒരേസമയം പരാജയപ്പെടുത്താം. അത് നിങ്ങൾ അളക്കാൻ ആഗ്രഹിക്കുന്ന ആശ്രിതത്വമാകാം, അല്ലെങ്കിൽ ലിസണർ ആരോഗ്യവും അറ്റം മുതൽ അറ്റം വരെയുള്ള ലഭ്യതയും വേറിട്ട സിഗ്നലുകളായി നിലനിർത്താനുള്ള കാരണമാകാം.