ব্যাকএন্ড সার্ভার জুড়ে ভারসাম্য বজায় রাখা

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

Apigee Edge একাধিক ব্যাকএন্ড সার্ভার ইনস্ট্যান্স জুড়ে লোড ব্যালান্সিং এবং ফেইলওভারের জন্য অন্তর্নির্মিত সমর্থন প্রদানের মাধ্যমে আপনার API-এর প্রাপ্যতা বৃদ্ধি করে।

টার্গেটসার্ভার কনফিগারেশনগুলো সুনির্দিষ্ট এন্ডপয়েন্ট ইউআরএল-কে টার্গেটএন্ডপয়েন্ট কনফিগারেশন থেকে পৃথক করে। প্রতিটি টার্গেটসার্ভারকে একটি টার্গেটএন্ডপয়েন্ট HTTPConnection-এ তার নাম দ্বারা উল্লেখ করা হয়। কনফিগারেশনে একটি সুনির্দিষ্ট ইউআরএল নির্ধারণ করার পরিবর্তে, আপনি টার্গেটএন্ডপয়েন্ট বিভাগে বর্ণিত পদ্ধতি অনুযায়ী এক বা একাধিক নামযুক্ত টার্গেটসার্ভার কনফিগার করতে পারেন।

একটি টার্গেটসার্ভার সংজ্ঞায় একটি নাম, একটি হোস্ট এবং একটি পোর্ট থাকে, এবং টার্গেটসার্ভারটি সক্রিয় নাকি নিষ্ক্রিয় তা নির্দেশ করার জন্য একটি অতিরিক্ত উপাদান থাকে।

ভিডিও

টার্গেট সার্ভার ব্যবহার করে এপিআই রাউটিং এবং লোড ব্যালান্সিং সম্পর্কে আরও জানতে নিম্নলিখিত ভিডিওগুলি দেখুন।

নমুনা টার্গেটসার্ভার কনফিগারেশন

নিম্নলিখিত কোডটি একটি টার্গেট সার্ভার নির্ধারণ করে:

<TargetServer  name="target1">
  <Host>1.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >

টার্গেটসার্ভার কনফিগারেশন উপাদানসমূহ

নিম্নলিখিত সারণিতে একটি টার্গেটসার্ভার তৈরি এবং কনফিগার করতে ব্যবহৃত উপাদানগুলি বর্ণনা করা হয়েছে:

UI ব্যবহার করে টার্গেট সার্ভারগুলো পরিচালনা করা

নিম্নে বর্ণিত পদ্ধতি অনুযায়ী টার্গেট সার্ভারগুলো পরিচালনা করুন।

এপিআই ব্যবহার করে টার্গেট সার্ভারগুলো পরিচালনা করা

আপনি Edge API ব্যবহার করে টার্গেট সার্ভার তৈরি, মুছে ফেলা, আপডেট, সংগ্রহ এবং তালিকাভুক্ত করতে পারেন। আরও তথ্যের জন্য, TargetServers দেখুন।

একটি টার্গেট সার্ভার তৈরি করতে নিম্নলিখিত এপিআই কলটি ব্যবহার করুন:

$ curl -H "Content-Type:text/xml" -X POST -d \
'<TargetServer name="target1">
   <Host>1.mybackendservice.com</Host>
   <Port>80</Port>
   <IsEnabled>true</IsEnabled>
 </TargetServer>' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

নমুনা প্রতিক্রিয়া:

{
  "host" : "1.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target1",
  "port" : 80
}

প্রথম TargetServer তৈরি করার পরে, দ্বিতীয় TargetServer তৈরি করতে নিম্নলিখিত API কলটি ব্যবহার করুন। দুটি TargetServer নির্ধারণ করার মাধ্যমে, আপনি দুটি URL প্রদান করেন যা একটি TargetEndpoint লোড ব্যালেন্সিংয়ের জন্য ব্যবহার করতে পারে:

$ curl -H "Content-type:text/xml" -X POST -d \
'<TargetServer  name="target2">
  <Host>2.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer >' \
-u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

নমুনা প্রতিক্রিয়া:

{
  "host" : "2.mybackendservice.com",
  "isEnabled" : true,
  "name" : "target2",
  "port" : 80
}

একটি এনভায়রনমেন্টে থাকা টার্গেটসার্ভারগুলোর তালিকা পেতে নিম্নলিখিত এপিআই কলটি ব্যবহার করুন:

$ curl -u email:password https://api.enterprise.apigee.com/v1/o/{org_name}/environments/test/targetservers

নমুনা প্রতিক্রিয়া:

[ "target2", "target1" ]

টেস্ট এনভায়রনমেন্টে ডেপ্লয় করা এপিআই প্রক্সিগুলোর ব্যবহারের জন্য এখন দুটি টার্গেটসার্ভার উপলব্ধ আছে। এই টার্গেটসার্ভারগুলোর মধ্যে ট্র্যাফিক লোড ব্যালেন্স করতে, আপনাকে একটি এপিআই প্রক্সির টার্গেট এন্ডপয়েন্টে HTTP কানেকশনটি কনফিগার করতে হবে যাতে এটি টার্গেটসার্ভারগুলো ব্যবহার করে।

লিমিটস টপিকে যেমন উল্লেখ করা হয়েছে, প্রতি এনভায়রনমেন্টে ৫০০টি টার্গেটসার্ভারের একটি সীমা রয়েছে।

নির্দিষ্ট টার্গেটসার্ভারগুলির মধ্যে লোড ব্যালেন্স করার জন্য একটি টার্গেটএন্ডপয়েন্ট কনফিগার করা

এখন যেহেতু আপনার কাছে দুটি TargetServer উপলব্ধ আছে, আপনি TargetEndpoint HTTP সংযোগ সেটিং পরিবর্তন করে নাম দ্বারা সেই দুটি TargetServer-কে উল্লেখ করতে পারেন:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Server name="target1" />
      <Server name="target2" />
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

উপরের কনফিগারেশনটি হলো সম্ভাব্য সবচেয়ে মৌলিক লোড ব্যালান্সিং কনফিগারেশন। লোড ব্যালান্সারটি তিনটি লোড ব্যালান্সিং অ্যালগরিদম সমর্থন করে: রাউন্ড রবিন, ওয়েটেড এবং লিস্ট কানেকশন। রাউন্ড রবিন হলো ডিফল্ট অ্যালগরিদম। যেহেতু উপরের কনফিগারেশনে কোনো অ্যালগরিদম নির্দিষ্ট করা নেই, তাই এপিআই প্রক্সি থেকে ব্যাকএন্ড সার্ভারগুলিতে পাঠানো অনুরোধগুলি টার্গেট১ এবং টার্গেট২-এর মধ্যে পর্যায়ক্রমে, একের পর এক যাবে।

<Path> এলিমেন্টটি সমস্ত টার্গেট সার্ভারের জন্য TargetEndpoint URI-এর বেসপ্যাথ গঠন করে। এটি শুধুমাত্র তখনই ব্যবহৃত হয় যখন <LoadBalancer> ব্যবহার করা হয়। অন্যথায়, এটি উপেক্ষা করা হয়। উপরের উদাহরণে, "target1"-এ পৌঁছানো একটি অনুরোধ হবে http://target1/test এবং অন্যান্য টার্গেট সার্ভারগুলোর ক্ষেত্রেও একই হবে।

লোড ব্যালেন্সার বিকল্পগুলি সেট করা

আপনি লোড ব্যালেন্সার এবং টার্গেটসার্ভার স্তরে লোড ব্যালেন্সিং ও ফেইলওভারের অপশনগুলো ব্যবহার করে প্রাপ্যতা নিয়ন্ত্রণ করতে পারেন। এই বিভাগে এই অপশনগুলো বর্ণনা করা হয়েছে।

অ্যালগরিদম

<LoadBalancer> দ্বারা ব্যবহৃত অ্যালগরিদম নির্ধারণ করে। উপলব্ধ অ্যালগরিদমগুলো হলো RoundRobin , Weighted এবং LeastConnections , যার প্রত্যেকটির বিবরণ নিচে দেওয়া হলো।

রাউন্ড রবিন

ডিফল্ট অ্যালগরিদম, রাউন্ড রবিন, টার্গেট এন্ডপয়েন্ট HTTP কানেকশনে সার্ভারগুলো যে ক্রমে তালিকাভুক্ত থাকে, সেই ক্রমেই প্রতিটি টার্গেটসার্ভারে একটি অনুরোধ ফরোয়ার্ড করে। উদাহরণস্বরূপ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

ওজনযুক্ত

ওয়েটেড লোড ব্যালান্সিং অ্যালগরিদম আপনাকে আপনার টার্গেটসার্ভারগুলোর জন্য আনুপাতিক ট্র্যাফিক লোড কনফিগার করতে সক্ষম করে। ওয়েটেড লোডব্যালান্সার প্রতিটি টার্গেটসার্ভারের ওয়েটের সরাসরি অনুপাতে আপনার টার্গেটসার্ভারগুলোতে রিকোয়েস্ট বিতরণ করে। তাই, ওয়েটেড অ্যালগরিদমের জন্য আপনাকে প্রতিটি টার্গেটসার্ভারের জন্য একটি weight অ্যাট্রিবিউট সেট করতে হবে। উদাহরণস্বরূপ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>Weighted</Algorithm>
      <Server name="target1">
        <Weight>1</Weight>
      </Server>
      <Server name="target2">
        <Weight>2</Weight>
      </Server>
    </LoadBalancer>
    <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

এই উদাহরণে, target1-এ পাঠানো প্রতিটি একটি অনুরোধের জন্য target2-এ দুটি অনুরোধ পাঠানো হবে।

সর্বনিম্ন সংযোগ

সর্বনিম্ন সংযোগ অ্যালগরিদম ব্যবহার করার জন্য কনফিগার করা লোডব্যালেন্সারগুলি বহির্গামী অনুরোধগুলিকে সেই টার্গেটসার্ভারে পাঠায় যেখানে সবচেয়ে কম খোলা HTTP সংযোগ থাকে। উদাহরণস্বরূপ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>LeastConnections</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
      </LoadBalancer>
  </HTTPTargetConnection>
  <Path>/test</Path>
</TargetEndpoint>

সর্বোচ্চ ব্যর্থতা

এপিআই প্রক্সি থেকে টার্গেটসার্ভারে পাঠানো সর্বাধিক সংখ্যক ব্যর্থ অনুরোধ, যার ফলে অনুরোধটি অন্য একটি টার্গেটসার্ভারে পুনঃনির্দেশিত হয়।

রেসপন্স ফেইলর মানে হলো Apigee টার্গেট সার্ভার থেকে কোনো রেসপন্স পায় না। এমনটা হলে, ফেইলর কাউন্টার এক বেড়ে যায়।

তবে, যখন Apigee কোনো টার্গেট থেকে রেসপন্স পায়, এমনকি যদি রেসপন্সটি একটি HTTP এরর (যেমন 500 ) হয়, সেটিও টার্গেট সার্ভারের রেসপন্স হিসেবে গণ্য হয় এবং ফেইলর কাউন্টারটি রিসেট হয়ে যায়। খারাপ HTTP রেসপন্সগুলো (যেমন 500 ) যাতে ফেইলর কাউন্টার বাড়িয়ে দেয় এবং একটি আনহেলদি সার্ভারকে যত দ্রুত সম্ভব লোড ব্যালেন্সিং রোটেশন থেকে সরিয়ে দেয়, তা নিশ্চিত করতে আপনি আপনার লোড ব্যালেন্সার কনফিগারেশনে <ResponseCode> চাইল্ড এলিমেন্টসহ <ServerUnhealthyResponse> এলিমেন্টটি যোগ করতে পারেন। Edge-ও এই কোডযুক্ত রেসপন্সগুলোকে ফেইলর হিসেবে গণ্য করবে।

নিম্নলিখিত উদাহরণে, টার্গেট সার্ভার থেকে কিছু 5XX প্রতিক্রিয়া সহ পাঁচটি ব্যর্থ অনুরোধের পর target1 রোটেশন থেকে সরিয়ে দেওয়া হবে।

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
        <ServerUnhealthyResponse>
            <ResponseCode>500</ResponseCode>
            <ResponseCode>502</ResponseCode>
            <ResponseCode>503</ResponseCode>
        </ServerUnhealthyResponse>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures-এর ডিফল্ট মান হলো ০। এর মানে হলো, Edge প্রতিটি অনুরোধের জন্য সর্বদা টার্গেট সার্ভারের সাথে সংযোগ করার চেষ্টা করে এবং রোটেশন থেকে টার্গেট সার্ভারটিকে কখনোই সরিয়ে দেয় না।

হেলথমনিটরের সাথে MaxFailures > 0 ব্যবহার করাই সর্বোত্তম। আপনি যদি MaxFailures > 0 কনফিগার করেন, তাহলে আপনার নির্দেশিত সংখ্যক বার টার্গেট ব্যর্থ হলে TargetServer-টি রোটেশন থেকে অপসারিত হয়। যখন একটি হেলথমনিটর চালু থাকে, তখন টার্গেটটি পুনরায় চালু ও সচল হওয়ার পর Apigee সেই হেলথমনিটরের কনফিগারেশন অনুযায়ী TargetServer-টিকে স্বয়ংক্রিয়ভাবে রোটেশনে ফিরিয়ে আনে। আরও তথ্যের জন্য হেলথ মনিটরিং দেখুন।

বিকল্পভাবে, যদি আপনি MaxFailures > 0 কনফিগার করেন এবং কোনো হেলথ মনিটর কনফিগার না করেন, তাহলে প্রথম ব্যর্থতা শনাক্ত হওয়ার সাথে সাথেই Apigee স্বয়ংক্রিয়ভাবে টার্গেট সার্ভারটিকে রোটেশন থেকে সরিয়ে দেবে। Apigee প্রতি পাঁচ মিনিট অন্তর টার্গেট সার্ভারটির স্বাস্থ্য পরীক্ষা করবে এবং এটি স্বাভাবিকভাবে সাড়া দিলে সেটিকে আবার রোটেশনে ফিরিয়ে আনবে।

পুনরায় চেষ্টা করুন

যদি রিট্রাই (retry) সক্ষম করা থাকে, তাহলে যখনই কোনো রেসপন্স ব্যর্থ হয় (যেমন I/O এরর বা HTTP টাইমআউট) অথবা প্রাপ্ত রেসপন্সটি <ServerUnhealthyResponse> দ্বারা সেট করা কোনো মানের সাথে মিলে যায়, তখন অনুরোধটি পুনরায় চেষ্টা করা হবে। <ServerUnhealthyResponse> সেট করার বিষয়ে আরও জানতে উপরের ‘সর্বোচ্চ ব্যর্থতা’ (Maximum failures) অংশটি দেখুন।

ডিফল্টরূপে <RetryEnabled> মান true সেট করা থাকে। রিট্রাই নিষ্ক্রিয় করতে এটিকে false সেট করুন। উদাহরণস্বরূপ:

<RetryEnabled>false</RetryEnabled>

ফলব্যাক

একটি (এবং শুধুমাত্র একটি) টার্গেটসার্ভারকে 'ফলব্যাক' সার্ভার হিসেবে সেট করা যেতে পারে। লোড ব্যালেন্সার দ্বারা অন্য সব টার্গেটসার্ভারকে অনুপলব্ধ হিসেবে চিহ্নিত না করা পর্যন্ত ফলব্যাক টার্গেটসার্ভারটি লোড ব্যালেন্সিং রুটিনে অন্তর্ভুক্ত হয় না। যখন লোড ব্যালেন্সার নির্ধারণ করে যে সমস্ত টার্গেটসার্ভার অনুপলব্ধ, তখন সমস্ত ট্র্যাফিক ফলব্যাক সার্ভারে পাঠানো হয়। উদাহরণস্বরূপ:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <Server name="target3">
          <IsFallback>true</IsFallback>
        </Server>
      </LoadBalancer>
      <Path>/test</Path>
  </HTTPTargetConnection>
</TargetEndpoint>

উপরের কনফিগারেশনটির ফলে টার্গেট ১ এবং ২ উভয়ই অনুপলব্ধ না হওয়া পর্যন্ত তাদের মধ্যে রাউন্ড রবিন লোড ব্যালান্সিং চলতে থাকে। যখন টার্গেট ১ এবং ২ উভয়ই অনুপলব্ধ থাকে, তখন সমস্ত ট্র্যাফিক টার্গেট ৩-এ পাঠানো হয়।

পথ

Path একটি URI খণ্ডাংশকে সংজ্ঞায়িত করে, যা TargetServer থেকে ব্যাকএন্ড সার্ভারে পাঠানো সমস্ত অনুরোধের সাথে যুক্ত করা হবে।

এই এলিমেন্টটি একটি আক্ষরিক স্ট্রিং পাথ অথবা একটি মেসেজ টেমপ্লেট গ্রহণ করে। একটি মেসেজ টেমপ্লেট আপনাকে রানটাইমে ভেরিয়েবল স্ট্রিং প্রতিস্থাপন করতে দেয়। উদাহরণস্বরূপ, নিম্নলিখিত টার্গেট এন্ডপয়েন্ট সংজ্ঞায়, পাথের জন্য {mypath} এর মান ব্যবহার করা হয়েছে:

<HTTPTargetConnection>
    <SSLInfo>
      <Enabled>true</Enabled>
    </SSLInfo>
    <LoadBalancer>
      <Server name="testserver"/>
    </LoadBalancer>
    <Path>{mypath}</Path>
</HTTPTargetConnection>

TLS/SSL এর জন্য একটি টার্গেট সার্ভার কনফিগার করা

যদি আপনি ব্যাকএন্ড সার্ভিস সংজ্ঞায়িত করার জন্য একটি TargetServer ব্যবহার করেন, এবং ব্যাকএন্ড সার্ভিসটির সংযোগের জন্য HTTPS প্রোটোকল ব্যবহারের প্রয়োজন হয়, তাহলে আপনাকে অবশ্যই TargetServer সংজ্ঞায় TLS/SSL সক্রিয় করতে হবে। এটি প্রয়োজনীয় কারণ <Host> ট্যাগ আপনাকে সংযোগ প্রোটোকল নির্দিষ্ট করার সুযোগ দেয় না। নিচে একমুখী TLS/SSL-এর জন্য TargetServer সংজ্ঞাটি দেখানো হলো, যেখানে Edge ব্যাকএন্ড সার্ভিসে HTTPS অনুরোধ পাঠায়:

<TargetServer name="target1">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo> 
</TargetServer>

যদি ব্যাকএন্ড সার্ভিসের জন্য দ্বিমুখী বা পারস্পরিক TLS/SSL-এর প্রয়োজন হয়, তাহলে আপনি TargetEndpoints-এর মতোই একই TLS/SSL কনফিগারেশন সেটিংস ব্যবহার করে TargetServer কনফিগার করবেন:

<TargetServer  name="TargetServer 1">
    <IsEnabled>true</IsEnabled>
    <Host>www.example.com</Host>
    <Port>443</Port>
    <SSLInfo>
        <Ciphers/>
        <ClientAuthEnabled>true</ClientAuthEnabled>
        <Enabled>true</Enabled>
        <IgnoreValidationErrors>false</IgnoreValidationErrors>
        <KeyAlias>keystore-alias</KeyAlias>
        <KeyStore>keystore-name</KeyStore>
        <Protocols/>
        <TrustStore>truststore-name</TrustStore>
    </SSLInfo>
</TargetServer >

<SSLInfo> প্রোপার্টি, যেমন <Ciphers> এবং <ClientAuthEnabled> সম্পর্কে তথ্যের জন্য, "প্রাইভেট ক্লাউডের জন্য একটি API-তে TLS অ্যাক্সেস কনফিগার করা" অংশে একটি ভার্চুয়াল হোস্টের জন্য সেই প্রোপার্টিগুলি সেট করার তথ্য দেখুন।

আউটবাউন্ড TLS/SSL কনফিগার করার সম্পূর্ণ নির্দেশাবলীর জন্য, ‘Configuring TLS from Edge to the backend (Cloud and Private Cloud)’ দেখুন।

টার্গেটসার্ভার স্কিমা

GitHub- এ TargetServer এবং অন্যান্য এনটিটিগুলোর স্কিমা দেখুন।

স্বাস্থ্য পর্যবেক্ষণ

হেলথ মনিটরিং আপনাকে টার্গেটসার্ভার কনফিগারেশনে সংজ্ঞায়িত ব্যাকএন্ড সার্ভিস ইউআরএলগুলো সক্রিয়ভাবে পোল করার মাধ্যমে লোড ব্যালেন্সিং কনফিগারেশন উন্নত করতে সক্ষম করে। হেলথ মনিটরিং সক্রিয় থাকলে, হেলথমনিটর যখন নির্ধারণ করে যে টার্গেটসার্ভারটি সক্রিয়, তখন একটি ব্যর্থ টার্গেটসার্ভার স্বয়ংক্রিয়ভাবে পুনরায় রোটেশনে ফিরে আসে।

হেলথ মনিটরিং <MaxFailures> এর সাথে কাজ করে। হেলথ মনিটরিং সক্রিয় না থাকলে, <MaxFailures> এপিআই প্রক্সি থেকে টার্গেটসার্ভারে পাঠানো ব্যর্থ অনুরোধের সংখ্যা নির্দিষ্ট করে, যার ফলে অনুরোধটি অন্য একটি টার্গেটসার্ভারে পুনঃনির্দেশিত হয়। এরপর ব্যর্থ হওয়া টার্গেটসার্ভারটিকে রোটেশন থেকে সরিয়ে নেওয়া হয়, যতক্ষণ না আপনি প্রক্সিটি পুনরায় স্থাপন করেন।

হেলথ মনিটরিং চালু থাকলে, একটি ব্যর্থ টার্গেটসার্ভার স্বয়ংক্রিয়ভাবে পুনরায় রোটেশনে ফিরে আসে এবং কোনো প্রক্সি রি-ডিপ্লয়মেন্টের প্রয়োজন হয় না।

হেলথমনিটর একটি সাধারণ ক্লায়েন্ট হিসেবে কাজ করে যা TCP বা HTTP-এর মাধ্যমে একটি ব্যাকএন্ড পরিষেবা আহ্বান করে:

• একটি TCP ক্লায়েন্ট কেবল এটি নিশ্চিত করে যে একটি সকেট খোলা যাবে।
• আপনি ব্যাকএন্ড সার্ভিসে একটি বৈধ HTTP অনুরোধ জমা দেওয়ার জন্য HTTP ক্লায়েন্ট কনফিগার করেন। আপনি HTTP GET, PUT, POST, বা DELETE অপারেশনগুলো সংজ্ঞায়িত করতে পারেন। HTTP মনিটর কলের প্রতিক্রিয়া অবশ্যই <SuccessResponse> ব্লকে কনফিগার করা সেটিংসের সাথে মিলতে হবে।

সাফল্য এবং ব্যর্থতা

আপনি যখন হেলথ মনিটরিং চালু করেন, Edge আপনার টার্গেট সার্ভারে হেলথ চেক পাঠানো শুরু করে। হেলথ চেক হলো টার্গেট সার্ভারে পাঠানো একটি অনুরোধ, যা নির্ধারণ করে যে টার্গেট সার্ভারটি সুস্থ আছে কি না।

স্বাস্থ্য পরীক্ষার দুটি সম্ভাব্য ফলাফল হতে পারে:

• সফলতা: যখন একটি সফল স্বাস্থ্য পরীক্ষা সম্পন্ন হয়, তখন টার্গেট সার্ভারটিকে সুস্থ বলে গণ্য করা হয়। এটি সাধারণত নিম্নলিখিত এক বা একাধিক কারণের ফল:
  • টার্গেট সার্ভার নির্দিষ্ট পোর্টে একটি নতুন সংযোগ গ্রহণ করে, সেই পোর্টে করা অনুরোধের উত্তর দেয় এবং তারপর নির্দিষ্ট সময়সীমার মধ্যে পোর্টটি বন্ধ করে দেয়। টার্গেট সার্ভারের প্রতিক্রিয়াতে “Connection: close” লেখা থাকে।
  • টার্গেট সার্ভার একটি হেলথ চেক রিকোয়েস্টের জবাবে 200 (OK) অথবা আপনার দ্বারা গ্রহণযোগ্য অন্য কোনো HTTP স্ট্যাটাস কোড পাঠায়।
  • টার্গেট সার্ভার একটি হেলথ চেক অনুরোধের জবাবে প্রত্যাশিত মেসেজ বডির সাথে মেলে এমন একটি মেসেজ বডি প্রেরণ করে।

  যখন Edge কোনো সার্ভারকে সুস্থ বলে নির্ধারণ করে, তখন Edge সেটিতে অনুরোধ পাঠানো অব্যাহত রাখে বা পুনরায় শুরু করে।

• ব্যর্থতা: চেকের ধরনের উপর নির্ভর করে, টার্গেট সার্ভার বিভিন্ন উপায়ে হেলথ চেকে ব্যর্থ হতে পারে। টার্গেট সার্ভার নিম্নলিখিত ক্ষেত্রে ব্যর্থ হিসেবে লগ করা হতে পারে:
  • Edge থেকে হেলথ চেক পোর্টে সংযোগ প্রত্যাখ্যান করে।
  • নির্দিষ্ট সময়ের মধ্যে স্বাস্থ্য পরীক্ষার অনুরোধে সাড়া দেয় না।
  • একটি অপ্রত্যাশিত HTTP স্ট্যাটাস কোড ফেরত দেয়।
  • এমন একটি বার্তা মূলাংশ দিয়ে সাড়া দেয় যা প্রত্যাশিত বার্তা মূলাংশের সাথে মেলে না।

  যখন কোনো টার্গেট সার্ভার হেলথ চেক-এ ব্যর্থ হয়, Edge সেই সার্ভারের ফেইলর কাউন্ট বাড়িয়ে দেয়। যদি সেই সার্ভারের ব্যর্থতার সংখ্যা একটি পূর্বনির্ধারিত থ্রেশহোল্ড ( <MaxFailures> ) পূরণ করে বা অতিক্রম করে, Edge সেই সার্ভারে রিকোয়েস্ট পাঠানো বন্ধ করে দেয়।

হেলথমনিটর সক্রিয় করা

একটি হেলথমনিটর তৈরি করতে, আপনাকে প্রক্সির জন্য টার্গেটএন্ডপয়েন্টের HTTPConnection কনফিগারেশনে <HealthMonitor> এলিমেন্টটি যোগ করতে হবে। আপনি এটি UI-তে করতে পারবেন না। এর পরিবর্তে, আপনাকে একটি প্রক্সি কনফিগারেশন তৈরি করে সেটিকে একটি ZIP ফাইল হিসেবে Edge-এ আপলোড করতে হবে। একটি প্রক্সি কনফিগারেশন হলো একটি API প্রক্সির সমস্ত দিকের একটি কাঠামোগত বিবরণ। প্রক্সি কনফিগারেশনগুলো একটি পূর্ব-নির্ধারিত ডিরেক্টরি কাঠামোতে XML ফাইল নিয়ে গঠিত। আরও তথ্যের জন্য, API প্রক্সি কনফিগারেশন রেফারেন্স দেখুন।

একটি সাধারণ হেলথমনিটর একটি IntervalInSec সাথে একটি TCPMonitor বা একটি HTTPMonitor নির্ধারণ করে। <MaxFailures> এলিমেন্টটি API প্রক্সি থেকে TargetServer-এ পাঠানো সর্বাধিক সংখ্যক ব্যর্থ অনুরোধ নির্দিষ্ট করে, যার ফলে অনুরোধটি অন্য একটি TargetServer-এ পুনঃনির্দেশিত হয়। ডিফল্টরূপে <MaxFailures> -এর মান ০ থাকে, যার অর্থ Edge কোনো সংশোধনমূলক ব্যবস্থা গ্রহণ করে না। একটি হেলথ মনিটর কনফিগার করার সময়, নিশ্চিত করুন যে আপনি <TargetEndpoint> ট্যাগের <HTTPTargetConnection> ট্যাগে <MaxFailures> -এর মান একটি অশূন্য মানে সেট করেছেন।

টিসিপি মনিটর

নিচের কনফিগারেশনটি একটি হেলথমনিটর নির্ধারণ করে, যা প্রতি পাঁচ সেকেন্ডে পোর্ট ৮০-তে একটি সংযোগ স্থাপন করে প্রতিটি টার্গেটসার্ভারকে পোল করে। (পোর্ট ঐচ্ছিক। যদি নির্দিষ্ট না করা হয়, তাহলে টিসিপিমনিটর পোর্টটিই টার্গেটসার্ভার পোর্ট হবে।)

• যদি সংযোগ ব্যর্থ হয় অথবা সংযোগ হতে ১০ সেকেন্ডের বেশি সময় লাগে, তাহলে সেই টার্গেটসার্ভারটির জন্য ব্যর্থতার সংখ্যা ১ বেড়ে যায়।
• সংযোগ সফল হলে, টার্গেটসার্ভারের ব্যর্থতার সংখ্যা ০-তে রিসেট করা হয়।

আপনি TargetEndpoint-এর HTTPTargetConnetion এলিমেন্টের একটি চাইল্ড এলিমেন্ট হিসেবে HealthMonitor যোগ করতে পারেন, যেমনটি নিচে দেখানো হয়েছে:

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <Server name="target2" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
      <Path>/test</Path>
      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <TCPMonitor>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <Port>80</Port>
        </TCPMonitor>
      </HealthMonitor>
  </HTTPTargetConnection>
. . .

টিসিপি মনিটর কনফিগারেশন উপাদান সহ হেলথ মনিটর

নিম্নলিখিত সারণিতে TCPMonitor-এর কনফিগারেশন উপাদানগুলো বর্ণনা করা হয়েছে:

HTTPMonitor

একটি নমুনা হেলথমনিটর, যা একটি HTTPMonitor ব্যবহার করে, প্রতি পাঁচ সেকেন্ডে একবার ব্যাকএন্ড সার্ভিসে একটি GET রিকোয়েস্ট পাঠাবে। নিচের নমুনাটিতে রিকোয়েস্ট মেসেজে একটি HTTP Basic Authorization হেডার যোগ করা হয়েছে। রেসপন্স কনফিগারেশন এমন সব সেটিংস নির্ধারণ করে, যা ব্যাকএন্ড সার্ভিসের প্রকৃত রেসপন্সের সাথে তুলনা করা হবে। নিচের উদাহরণে, প্রত্যাশিত রেসপন্স হলো একটি HTTP রেসপন্স কোড 200 এবং একটি কাস্টম HTTP হেডার ImOK যার ভ্যালু হলো YourOK । যদি রেসপন্সটি না মেলে, তাহলে লোড ব্যালেন্সার কনফিগারেশন দ্বারা রিকোয়েস্টটিকে একটি ব্যর্থ প্রচেষ্টা হিসেবে গণ্য করা হবে।

HTTPMonitor, HTTP এবং একমুখী HTTPS প্রোটোকল ব্যবহার করার জন্য কনফিগার করা ব্যাকএন্ড সার্ভিসগুলোকে সমর্থন করে। তবে, এটি নিম্নলিখিতগুলো সমর্থন করে না:

• দ্বিমুখী HTTPS (যাকে দ্বিমুখী TLS/SSL-ও বলা হয়)
• স্ব-স্বাক্ষরিত সনদপত্র।

মনে রাখবেন যে, একটি HTTP মনিটরের সমস্ত রিকোয়েস্ট এবং রেসপন্স সেটিংস সেই ব্যাকএন্ড সার্ভিসের জন্য নির্দিষ্ট হবে, যেটিকে কল করতে হবে।

    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <HTTPMonitor>
        <Request>
          <IsSSL>true</IsSSL>
          <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
          <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
          <Port>80</Port>
          <Verb>GET</Verb>
          <Path>/healthcheck</Path>
          <Header name="Authorization">Basic 12e98yfw87etf</Header>
          <IncludeHealthCheckIdHeader>true</IncludeHealthCheckIdHeader>
        </Request>
        <SuccessResponse>
          <ResponseCode>200</ResponseCode>
          <Header name="ImOK">YourOK</Header>
        </SuccessResponse>
      </HTTPMonitor>
    </HealthMonitor>
    

HTTPMonitor কনফিগারেশন উপাদান সহ HealthMonitor

নিম্নলিখিত সারণিতে HTTPMonitor কনফিগারেশনের উপাদানগুলো বর্ণনা করা হয়েছে: