ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালেন্সিং

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য

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

TargetServer কনফিগারেশন, TargetEndpoint কনফিগারেশন থেকে নির্দিষ্ট এন্ডপয়েন্ট URL আলাদা করে দেয়। প্রতিটি TargetServer-কে TargetEndpoint HTTPConnection-এ নাম দিয়ে রেফার করা হয়। কনফিগারেশনে কোনও নির্দিষ্ট URL নির্ধারণ করার পরিবর্তে, আপনি TargetEndpoint বিভাগে বর্ণিত এক বা একাধিক নামযুক্ত TargetServer কনফিগার করতে পারেন।

TargetServer-এর সংজ্ঞায় একটি নাম, হোস্ট ও পোর্ট থাকে এবং TargetServer চালু বা বন্ধ আছে কিনা তা বোঝানোর জন্য একটি অতিরিক্ত এলিমেন্ট থাকে।

ভিডিও

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

Sample TargetServer Configuration

নিচের কোডটি একটি টার্গেট সার্ভারকে সংজ্ঞায়িত করে:

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

TargetServer কনফিগারেশন এলিমেন্ট

TargetServer তৈরি ও কনফিগার করার জন্য ব্যবহৃত এলিমেন্টগুলি নিম্নলিখিত সারণীতে বর্ণনা করা হয়েছে:

UI ব্যবহার করে টার্গেট সার্ভার ম্যানেজ করা

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

API ব্যবহার করে টার্গেট সার্ভার ম্যানেজ করা

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

টার্গেট সার্ভার তৈরি করতে, নিম্নলিখিত API কল ব্যবহার করুন:

$ 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
}

কোনও এনভায়রনমেন্টে TargetServer-এর তালিকা পেতে নিম্নলিখিত API কল ব্যবহার করুন:

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

উত্তরের নমুনা:

[ "target2", "target1" ]

পরীক্ষামূলক এনভায়রনমেন্টে ডিপ্লয় করা API প্রক্সি এখন দুটি TargetServer ব্যবহার করতে পারবে। এইসব TargetServer জুড়ে ট্রাফিক লোড ব্যালেন্স করতে, TargetServer ব্যবহার করার জন্য API প্রক্সির টার্গেট এন্ডপয়েন্টে HTTP কানেকশন কনফিগার করুন।

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

নাম করা TargetServer জুড়ে লোড ব্যালেন্স করার জন্য TargetEndpoint কনফিগার করা

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

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

উপরে দেখানো কনফিগারেশন হল সবচেয়ে প্রাথমিক লোড ব্যালেন্সিং কনফিগারেশন। লোড ব্যালেন্সারে তিনটি লোড ব্যালেন্সিং অ্যালগরিদম কাজ করে, সেগুলি হল রাউন্ড রবিন, ওয়েটেড ও লিস্ট কানেকশন। রাউন্ড রবিন হল ডিফল্ট অ্যালগরিদম। উপরের কনফিগারেশনে কোনও অ্যালগরিদম নির্দিষ্ট করা না থাকার কারণে, API প্রক্সি থেকে ব্যাকএন্ড সার্ভারে পাঠানো আউটবাউন্ড অনুরোধগুলি target1 ও target 2-এর মধ্যে একটি করে করে বিকল্পভাবে পরিবর্তিত হবে।

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

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

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

অ্যালগরিদম

<LoadBalancer>-এর ব্যবহার করা অ্যালগরিদম সেট করে। উপলভ্য অ্যালগরিদম হল RoundRobin, Weighted ও LeastConnections, যার প্রতিটি নিচে ডকুমেন্ট করা আছে।

রাউন্ড রবিন

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

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

ওয়েট অনুযায়ী

ওয়েটেড লোড ব্যালেন্সিং অ্যালগরিদম আপনার TargetServer-এর জন্য আনুপাতিক ট্রাফিক লোড কনফিগার করতে সাহায্য করে। ওয়েটেড LoadBalancer প্রতিটি TargetServer-এর গুরুত্বের সাথে সরাসরি সমানুপাতিকভাবে আপনার TargetServer-এ অনুরোধ ডিস্ট্রিবিউট করে। তাই, ওয়েটেড অ্যালগরিদমের জন্য আপনাকে প্রতিটি TargetServer-এর জন্য একটি 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-এ রুট করা হবে।

সর্বনিম্ন কানেকশন

সবচেয়ে কম কানেকশন অ্যালগরিদম ব্যবহার করার জন্য কনফিগার করা LoadBalancers, সবচেয়ে কম ওপেন HTTP কানেকশন সহ TargetServer-এ আউটবাউন্ড অনুরোধ রাউট করে। যেমন:

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

সর্বাধিক ব্যর্থতা

API প্রক্সি থেকে TargetServer-এ পাঠানো অনুরোধের সর্বাধিক সংখ্যা যা ব্যর্থ হলে অনুরোধটি অন্য TargetServer-এ রিডাইরেক্ট করা হয়।

উত্তর না পাওয়ার অর্থ হল, Apigee টার্গেট সার্ভার থেকে কোনও উত্তর পায়নি। এটি হলে, ব্যর্থতার কাউন্টার এক করে বেড়ে যায়।

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

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

<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 সবসময় প্রতিটি অনুরোধের জন্য টার্গেটের সাথে কানেক্ট করার চেষ্টা করে এবং কখনওই টার্গেট সার্ভারকে রোটেশন থেকে সরিয়ে দেয় না।

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

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

আবার চেষ্টা করুন

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

ডিফল্ট হিসেবে <RetryEnabled>-এর মান true হিসেবে সেট করা থাকে। আবার চেষ্টা করার সুবিধা বন্ধ করতে false-এ সেট করুন। যেমন:

<RetryEnabled>false</RetryEnabled>

IsFallback

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

<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>

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

পথ

পাথ হল একটি 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 কনফিগার করার সম্পূর্ণ নির্দেশাবলীর জন্য, এজ থেকে ব্যাকএন্ড (ক্লাউড এবং প্রাইভেট ক্লাউড) পর্যন্ত TLS কনফিগার করালিঙ্ক দেখুন।

TargetServer স্কিমা

GitHub-এ TargetServer ও অন্যান্য এন্টিটির স্কিমা দেখুন।

স্বাস্থ্য মনিটর করা

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

<MaxFailures>-এর সাথে স্বাস্থ্য মনিটরিং কাজ করে। হেলথ মনিটরিং চালু না থাকলে, <MaxFailures> API প্রক্সি থেকে TargetServer-এ পাঠানো অনুরোধের সংখ্যা নির্দিষ্ট করে, যার ফলে অনুরোধটি অন্য TargetServer-এ রিডাইরেক্ট করা হয়। আপনি প্রক্সি আবার ডেপ্লয় না করা পর্যন্ত, কাজ না করা TargetServer-কে রোটেট করা হয় না।

স্বাস্থ্য মনিটরিং চালু থাকলে, কাজ না করা TargetServer অটোমেটিক আবার রোটেট করা হয় এবং কোনও প্রক্সি আবার ডিপ্লয় করার প্রয়োজন হয় না।

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

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

সফলতা ও ব্যর্থতা

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

হেলথ চেক করলে দুটি সম্ভাব্য ফলাফলের মধ্যে একটি পাওয়া যেতে পারে:

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

  Edge যখন নির্ধারণ করে যে কোনও সার্ভার সুস্থ আছে, তখন Edge সেই সার্ভারে অনুরোধ পাঠানো চালিয়ে যায় বা আবার শুরু করে।

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

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

HealthMonitor চালু করা

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

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

TCPMonitor

নিচের কনফিগারেশন একটি HealthMonitor-কে সংজ্ঞায়িত করে যা প্রতি পাঁচ সেকেন্ডে পোর্ট ৮০-তে একটি কানেকশন খুলে প্রতিটি TargetServer-কে পোল করে। (পোর্ট ঐচ্ছিক। নির্দিষ্ট করা না থাকলে, TCPMonitor পোর্ট হল TargetServer পোর্ট।)

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

আপনি TargetEndpoint-এর HTTPTargetConnection এলিমেন্টের চাইল্ড এলিমেন্ট হিসেবে 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 কনফিগারেশন এলিমেন্ট সহ HealthMonitor

নিচের সারণীতে TCPMonitor কনফিগারেশন এলিমেন্ট সম্পর্কে বর্ণনা করা হয়েছে:

HTTPMonitor

HTTPMonitor ব্যবহার করে এমন একটি HealthMonitor স্যাম্পেল প্রতি পাঁচ সেকেন্ডে একবার করে ব্যাকএন্ড পরিষেবার কাছে GET অনুরোধ জমা দেবে। নিচের নমুনাটি অনুরোধ মেসেজে HTTP বেসিক অনুমোদন হেডার যোগ করে। ব্যাকএন্ড পরিষেবা থেকে পাওয়া আসল উত্তরের সাথে তুলনা করার জন্য উত্তর কনফিগারেশন সেটিংস নির্ধারণ করে। নিচের উদাহরণে, প্রত্যাশিত উত্তর হল একটি 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 কনফিগারেশন এলিমেন্ট সম্পর্কে বর্ণনা করা হয়েছে: