আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
Apigee Edge কীভাবে ব্যাকএন্ড পরিষেবা বা API-এর সাথে কানেক্ট করে তা TargetEndpoint কনফিগারেশন নির্ধারণ করে। এটি ব্যাকএন্ড পরিষেবাতে/থেকে অনুরোধ পাঠায় এবং উত্তর পায়। ব্যাকএন্ড পরিষেবা HTTP/HTTPS সার্ভার, NodeJS বা হোস্ট করা টার্গেট হতে পারে।
TargetEndpoint-এ ব্যাকএন্ড পরিষেবা নিম্নলিখিত যেকোনও একটি উপায়ে ইনভোক করা যেতে পারে:
- HTTP বা HTTPS সার্ভারের ডাইরেক্ট URL
- ScriptTarget-কে Edge-হোস্ট করা Node.js স্ক্রিপ্টে
- HostedTarget থেকে Hosted Target Environment-এ ডিপ্লয় করা NodeJS
- TargetServer কনফিগারেশন
একইভাবে, API প্রক্সি ফ্লো থেকে যেকোনও এক্সটার্নাল পরিষেবায় কল করতে পরিষেবা কলআউট নীতি ব্যবহার করা যেতে পারে। এই নীতিতে HTTP/HTTPS টার্গেট URL হয় সরাসরি নীতিতে অথবা TargetServer কনফিগারেশন ব্যবহার করে নির্ধারণ করা যায়।
TargetServer কনফিগারেশন
TargetServer কনফিগারেশন, TargetEndpoint কনফিগারেশন বা সার্ভিস কলআউট নীতি থেকে নির্দিষ্ট এন্ডপয়েন্ট URL আলাদা করে দেয়। TargetEndpoint-এ URL-এর পরিবর্তে নামের মাধ্যমে TargetServer-কে রেফার করা হয়। TargetServer কনফিগারেশনে ব্যাকএন্ড পরিষেবার হোস্টনেম, পোর্ট নম্বর ও অন্যান্য বিবরণ থাকবে।
এখানে TargetServer কনফিগারেশনের একটি নমুনা দেওয়া হল:
<TargetServer name="target1"> <Host>www.mybackendservice.com</Host> <Port>80</Port> <IsEnabled>true</IsEnabled> </TargetServer>
TargetServer আপনাকে প্রতিটি এনভায়রনমেন্টের জন্য আলাদা আলাদা কনফিগারেশন রাখতে দেয়। LoadBalancer ব্যবহার করে এক বা একাধিক নামযুক্ত TargetServers সহ TargetEndpoint/Service Callout নীতি কনফিগার করা যেতে পারে। লোড ব্যালেন্সিংয়ের জন্য বিল্ট-ইন সহায়তা API-এর উপলভ্যতা এবং কনফিগার করা ব্যাকএন্ড সার্ভার ইনস্ট্যান্সের মধ্যে ফেলওভার বাড়ায়।
TargetServers ব্যবহার করে TargetEndpoint কনফিগারেশনের একটি নমুনা এখানে দেওয়া হল:
<TargetEndpoint name="default">
<HTTPTargetConnection>>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>MaxFailures
MaxFailures কনফিগারেশনে টার্গেট সার্ভারে অনুরোধ ব্যর্থ হওয়ার সর্বাধিক সংখ্যা নির্দিষ্ট করা থাকে
যার পরে টার্গেট সার্ভারকে ডাউন হিসেবে চিহ্নিত করা হয় এবং পরবর্তী সব অনুরোধের জন্য
সেটিকে রোটেশন থেকে সরিয়ে দেওয়া হয়।
MaxFailures নির্দিষ্ট করা আছে এমন কনফিগারেশনের উদাহরণ:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Server name="target1"/>
<Server name="target2"/>
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>
</TargetEndpoint>উপরের উদাহরণে, "target1"-এর জন্য পরপর পাঁচটি অনুরোধ ব্যর্থ হলে, "target1" রোটেট করা থেকে সরিয়ে দেওয়া হবে এবং পরবর্তী সব অনুরোধ শুধুমাত্র target2-এ পাঠানো হবে।
অ্যান্টিপ্যাটার্ন
LoadBalancer কনফিগারেশনে
TargetEndpoint বা Service Callout নীতিতে MaxFailures-এর মান
শূন্য ছাড়া অন্য কোনও মান সেট করা থাকলে, একটি TargetServer ব্যবহার করার পরামর্শ দেওয়া হয় না, কারণ এর ফলে সমস্যা হতে পারে।
নিম্নলিখিত স্যাম্পেল কনফিগারেশন বিবেচনা করুন, যেখানে "target1" নামের একটি TargetServer
আছে এবং MaxFailures-এর মান ৫ (শূন্য নয় এমন মান) হিসেবে সেট করা আছে:
<TargetEndpoint name="default">
<HTTPTargetConnection>
<LoadBalancer>
<Algorithm>RoundRobin</Algorithm>
<Server name="target1" />
<MaxFailures>5</MaxFailures>
</LoadBalancer>
</HTTPTargetConnection>TargetServer "target1"-এ অনুরোধ পাঁচবার (MaxFailures-এ উল্লেখ করা সংখ্যা) ব্যর্থ হলে,
TargetServer-কে রোটেশন থেকে সরিয়ে দেওয়া হয়। যেহেতু অন্য কোনও TargetServer নেই যেখানে ফেলওভার করা যায়,
এই কনফিগারেশন সহ API Proxy-তে করা পরবর্তী সব অনুরোধ
503 Service Unavailable সমস্যার কারণে ব্যর্থ হবে।
এমনকি TargetServer "target1" স্বাভাবিক অবস্থায় ফিরে এলেও এবং সফল উত্তর পাঠানোর মতো উপযুক্ত হলেও, API প্রক্সি সংক্রান্ত অনুরোধগুলি 503 সমস্যা কোড দেখানো চালিয়ে যাবে। এর কারণ হল, টার্গেট আবার চালু হয়ে গেলেও Edge অটোমেটিক TargetServer কে আবার রোটেট করে না। এই সমস্যার সমাধান করতে, Edge-এর জন্য API Proxy আবার ডেপ্লয় করতে হবে যাতে TargetServer আবার রোটেট করা যায়।
Service Callout নীতিতে একই কনফিগারেশন ব্যবহার করা হলে, TargetServer "target1"-এ ৫ বার অনুরোধ ব্যর্থ হওয়ার পরে API অনুরোধে 500 এরর কোড দেখানো হবে।
প্রভাব
LoadBalancer কনফিগারেশনে
TargetEndpoint বা Service Callout নীতিতে MaxFailures-এর মান শূন্য ছাড়া অন্য কোনও মান সেট করা থাকলে, একটি TargetServer ব্যবহার করলে এগুলি হয়:
- API প্রক্সি আবার ডিপ্লয় না করা পর্যন্ত, API অনুরোধগুলি একটানা ৫০৩/৫০০ সমস্যার সাথে ব্যর্থ হবে (অনুরোধগুলি MaxFailures সংখ্যক বার ব্যর্থ হওয়ার পরে)।
- দীর্ঘ সময় ধরে পরিষেবা বন্ধ থাকতে পারে কারণ এই সমস্যার কারণ নির্ণয় করা কঠিন এবং এতে বেশি সময় লাগতে পারে (এই অ্যান্টিপ্যাটার্ন সম্পর্কে আগে থেকে কোনও জ্ঞান না থাকলে)।
পেশাদার পদ্ধতি
- আরও বেশি উপলভ্যতার জন্য
LoadBalancerকনফিগারেশনে একাধিক TargetServer রাখুন। MaxFailures-এর মান শূন্য ছাড়া অন্য কিছু সেট করা থাকলে, সবসময় একটি হেলথ মনিটর নির্ধারণ করুন। কোনও টার্গেট সার্ভারকে রোটেশন থেকে সরিয়ে দেওয়া হবে যখন ব্যর্থতার সংখ্যাMaxFailures-এ উল্লেখ করা সংখ্যার সমান হয়ে যাবে। HealthMonitor থাকলে এটি নিশ্চিত করে যে TargetServer-কে আবার রোটেট করা হবে যত তাড়াতাড়ি টার্গেট সার্ভার আবার উপলভ্য হবে, অর্থাৎ এর অর্থ হল প্রক্সি আবার ডিপ্লয় করার প্রয়োজন নেই।Edge যে পোর্ট নম্বর ব্যবহার করে টার্গেট সার্ভারের সাথে কানেক্ট করে, সেই একই পোর্ট নম্বরে হেলথ চেক করা হচ্ছে কিনা তা নিশ্চিত করতে, Apigee সাজেস্ট করে যে আপনি
<Port>চাইল্ড এলিমেন্টটি<TCPMonitor>বাদ দিন, যদি না এটি TargetServer পোর্ট থেকে আলাদা হয়। ডিফল্ট হিসেবে<Port>হল TargetServer পোর্টের মতো।HealthMonitor সহ Sample কনফিগারেশন:
<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> </TCPMonitor> </HealthMonitor> </HTTPTargetConnection> </TargetEndpoint>যদি এমন কোনও সীমাবদ্ধতা থাকে যে শুধুমাত্র একটি TargetServer এবং HealthMonitor ব্যবহার করা না হলে,
LoadBalancerকনফিগারেশনেMaxFailuresনির্দিষ্ট করবেন না।MaxFailures-এর ডিফল্ট ভ্যালু হল ০। এর অর্থ হল, Edge সবসময় প্রতিটি অনুরোধের জন্য টার্গেটের সাথে কানেক্ট করার চেষ্টা করে এবং কখনওই টার্গেট সার্ভারকে রোটেশন থেকে সরিয়ে দেয় না।