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

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

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

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

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

ভিডিও

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

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

নিম্নলিখিত কোড একটি লক্ষ্য সার্ভার সংজ্ঞায়িত করে:

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

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

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

UI ব্যবহার করে লক্ষ্য সার্ভার পরিচালনা করা

লক্ষ্য সার্ভার পরিচালনা করুন, নীচে বর্ণিত হিসাবে..

API ব্যবহার করে লক্ষ্য সার্ভার পরিচালনা করা

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

একটি লক্ষ্য সার্ভার তৈরি করতে নিম্নলিখিত 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
}

আপনি প্রথম টার্গেট সার্ভার তৈরি করার পরে, তারপরে একটি দ্বিতীয় টার্গেট সার্ভার তৈরি করতে নিম্নলিখিত API কল ব্যবহার করুন। দুটি টার্গেট সার্ভার সংজ্ঞায়িত করে, আপনি দুটি 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
}

একটি পরিবেশে টার্গেট সার্ভারের একটি তালিকা পুনরুদ্ধার করতে নিম্নলিখিত API কল ব্যবহার করুন:

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

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

[ "target2", "target1" ]

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

প্রতি পরিবেশে 500 টার্গেট সার্ভারের একটি সীমা রয়েছে, যেমন লিমিটস বিষয়ে নথিভুক্ত করা হয়েছে।

নামযুক্ত TargetServers জুড়ে ব্যালেন্স লোড করতে একটি TargetEndpoint কনফিগার করা হচ্ছে

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

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

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

<Path> উপাদানটি সমস্ত টার্গেট সার্ভারের জন্য TargetEndpoint URI-এর বেসপাথ গঠন করে। এটি শুধুমাত্র ব্যবহার করা হয় যখন <LoadBalancer> ব্যবহার করা হয়। অন্যথায়, এটি উপেক্ষা করা হয়। উপরের উদাহরণে, "টার্গেট1"-এ পৌঁছানোর অনুরোধটি হবে 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>

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

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

LoadBalancers সর্বনিম্ন কানেকশন অ্যালগরিদম রুট আউটবাউন্ড রিকোয়েস্ট ব্যবহার করার জন্য কনফিগার করা হয়েছে টার্গেট সার্ভারে সবচেয়ে কম খোলা 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 ) নিশ্চিত করতে সাহায্য করার জন্য যে যত তাড়াতাড়ি সম্ভব একটি অস্বাস্থ্যকর সার্ভারকে লোড ব্যালেন্সিং ঘূর্ণন থেকে বের করে আনতে ব্যর্থতার কাউন্টার বৃদ্ধি করে, আপনি আপনার লোড ব্যালেন্সারের সাথে <ServerUnhealthyResponse> উপাদান <ResponseCode> চাইল্ড এলিমেন্ট যোগ করতে পারেন। কনফিগারেশন এজ সেই কোডগুলির সাথে প্রতিক্রিয়াগুলিকে ব্যর্থতা হিসাবে গণনা করবে।

নিম্নলিখিত উদাহরণে, লক্ষ্য সার্ভার থেকে কিছু 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 ডিফল্ট হল 0। এর মানে হল এজ সবসময় প্রতিটি অনুরোধের জন্য টার্গেটের সাথে সংযোগ করার চেষ্টা করে এবং ঘূর্ণন থেকে টার্গেট সার্ভারকে কখনই সরিয়ে দেয় না।

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

বিকল্পভাবে, আপনি যদি MaxFailures > 0 কনফিগার করেন এবং আপনি একটি HealthMonitor কনফিগার না করেন, Apigee ব্যর্থতা শনাক্ত করার পর Apigee স্বয়ংক্রিয়ভাবে ঘূর্ণনের মধ্যে টার্গেট সার্ভারকে পুনরায় অন্তর্ভুক্ত করবে না। এই ক্ষেত্রে, Apigee টার্গেট সার্ভারকে ঘূর্ণায়মান করার আগে আপনাকে অবশ্যই API প্রক্সি পুনরায় স্থাপন করতে হবে। একটি API প্রক্সি স্থাপন করা দেখুন।

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

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

ডিফল্টরূপে <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>

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

পথ

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

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

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

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

আপনি যদি ব্যাকএন্ড পরিষেবা সংজ্ঞায়িত করার জন্য একটি টার্গেট সার্ভার ব্যবহার করেন এবং ব্যাকএন্ড পরিষেবাটির HTTPS প্রোটোকল ব্যবহার করার জন্য সংযোগের প্রয়োজন হয়, তাহলে আপনাকে অবশ্যই TargetServer সংজ্ঞায় TLS/SSL সক্ষম করতে হবে। এটি প্রয়োজনীয় কারণ <Host> ট্যাগ আপনাকে সংযোগ প্রোটোকল নির্দিষ্ট করতে দেয় না। নীচে দেখানো হয়েছে একমুখী TLS/SSL এর জন্য টার্গেট সার্ভার সংজ্ঞা যেখানে এজ ব্যাকএন্ড পরিষেবাতে 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 কনফিগার করা দেখুন (ক্লাউড এবং প্রাইভেট ক্লাউড) ।

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

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

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

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

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

স্বাস্থ্য পর্যবেক্ষণ সক্ষম করার সাথে, একটি ব্যর্থ টার্গেট সার্ভার স্বয়ংক্রিয়ভাবে ঘূর্ণায়মান হয়ে যায় এবং কোনও প্রক্সি পুনরায় স্থাপনের প্রয়োজন হয় না।

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

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

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

আপনি যখন স্বাস্থ্য পর্যবেক্ষণ সক্ষম করেন, তখন এজ আপনার লক্ষ্য সার্ভারে স্বাস্থ্য পরীক্ষা পাঠাতে শুরু করে। একটি স্বাস্থ্য পরীক্ষা হল টার্গেট সার্ভারে পাঠানো একটি অনুরোধ যা লক্ষ্য সার্ভারটি সুস্থ কিনা তা নির্ধারণ করে।

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

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

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

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

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

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

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

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

টিসিপি মনিটর

নীচের কনফিগারেশনটি একটি হেলথ মনিটরকে সংজ্ঞায়িত করে যা প্রতি পাঁচ সেকেন্ডে পোর্ট 80 এ একটি সংযোগ খোলার মাধ্যমে প্রতিটি টার্গেট সার্ভারকে পোল করে। (পোর্টটি ঐচ্ছিক। নির্দিষ্ট না থাকলে, TCPMonitor পোর্ট হল টার্গেট সার্ভার পোর্ট।)

• যদি সংযোগ ব্যর্থ হয় বা সংযোগ হতে 10 সেকেন্ডের বেশি সময় নেয়, তাহলে সেই টার্গেট সার্ভারের জন্য ব্যর্থতার গণনা 1 দ্বারা বৃদ্ধি পাবে।
• যদি সংযোগ সফল হয়, তাহলে টার্গেট সার্ভারের ব্যর্থতার গণনা 0 এ পুনরায় সেট করা হয়।

আপনি 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 কনফিগারেশন উপাদান সহ HealthMonitor

নিম্নলিখিত টেবিলটি TCPMonitor কনফিগারেশন উপাদানগুলি বর্ণনা করে:

HTTP মনিটর

একটি নমুনা স্বাস্থ্য মনিটর যা একটি HTTP মনিটর ব্যবহার করে প্রতি পাঁচ সেকেন্ডে একবার ব্যাকএন্ড পরিষেবাতে একটি 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

নিম্নলিখিত টেবিলটি HTTP মনিটর কনফিগারেশন উপাদানগুলি বর্ণনা করে: