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 পরীক্ষা বেছে নিয়ে সেই চিহ্ন যাচাই করুন।

প্রক্সি প্রমাণীকরণ জড়িত থাকলে পরীক্ষা-অ্যাকাউন্ট ও উৎস নিষেধাজ্ঞা সংকীর্ণ রাখুন। সবুজ চিহ্ন পেতে পুরো লিসেনারকে প্রমাণীকরণ থেকে মুক্ত করা সুরক্ষিত সেবাটিকেই বদলে দেয়।

শেষে ঠিক করুন, ব্যর্থ পরীক্ষা কী সরাবে। নিয়ন্ত্রিত উৎস বিঘ্ন একসঙ্গে প্রতিটি প্রক্সির ফরওয়ার্ডিং পরীক্ষা ব্যর্থ করতে পারে। সেটিই হতে পারে আপনি যে নির্ভরতা মাপতে চান, অথবা লিসেনার স্বাস্থ্য ও প্রান্ত-থেকে-প্রান্ত প্রাপ্যতাকে আলাদা সংকেত রাখার কারণ।