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