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 சரிபார்ப்பைத் தேர்ந்தெடுத்து அந்தக் குறியீட்டைச் சரிபார்க்கவும்.

ப்ராக்ஸி அங்கீகாரம் சம்பந்தப்பட்டால் சரிபார்ப்புக் கணக்கையும் மூலக் கட்டுப்பாடுகளையும் குறுகலாக வைத்திருங்கள். பச்சைக் குறியீட்டைப் பெற முழு கேட்பானையும் அங்கீகாரத்திலிருந்து விலக்குவது பாதுகாக்கப்படும் சேவையையே மாற்றுகிறது.

இறுதியாக, தோல்வியடைந்த சரிபார்ப்பு எதை நீக்க வேண்டும் என்பதை முடிவு செய்யுங்கள். கட்டுப்படுத்தப்பட்ட மூல பழுது ஒரே நேரத்தில் ஒவ்வொரு ப்ராக்ஸியின் அனுப்பீட்டுச் சரிபார்ப்பையும் தோல்வியடையச் செய்யும். அதுவே நீங்கள் அளக்க விரும்பும் சார்பாக இருக்கலாம், அல்லது கேட்பவர் நலத்தையும் முனை-முதல்-முனை கிடைக்கும் தன்மையையும் தனித்தனி சமிக்ஞைகளாக வைத்திருக்கக் காரணமாக இருக்கலாம்.