Hadoop DistCp: ওয়ার্কার টাস্কে S3A প্রক্সি কনফিগার করুন
Hadoop S3A কানেক্টরের প্রক্সি কনফিগার করুন এবং DistCp ওয়ার্কাররা যেখানে স্থানান্তর চালায় সেখানে কনফিগারেশনটি উপলব্ধ করুন।
HTTP প্রক্সির মাধ্যমে Hadoop 3.4.2-এর S3A কানেক্টরের জন্য, এই এন্ট্রিগুলো অপারেশনের Hadoop কনফিগারেশনে, সাধারণত প্রযোজ্য core-site.xml-এ, যোগ করুন:
<property>
<name>fs.s3a.proxy.host</name>
<value>gateway.example</value>
</property>
<property>
<name>fs.s3a.proxy.port</name>
<value>8080</value>
</property>
<property>
<name>fs.s3a.proxy.ssl.enabled</name>
<value>false</value>
</property>প্রক্সি শংসাপত্র ছাড়াই প্রকাশ্যে পৌঁছানো যায় এমন S3 এন্ডপয়েন্টের বিরুদ্ধে পৃথকভাবে অনুমোদিত পরীক্ষার জন্য, HTTP প্রক্সি তালিকা হোস্টনেম ও স্পষ্ট পোর্টের জন্য প্রার্থী মান সরবরাহ করে। fs.s3a.proxy.ssl.enabled=false এই প্রক্সিতে সাধারণ HTTP সংযোগ বেছে নেয়; এটি S3A থেকে S3-তে TLS নিষ্ক্রিয় করে না। প্রকৃত প্রক্সি লিসেনারের সাথে মিলে এমন মান ব্যবহার করুন।
উভয় ভোক্তা যাচাই করুন। জমাদানকারী ক্লায়েন্ট S3 সফলভাবে তালিকাভুক্ত করতে পারে, অথচ DistCp ম্যাপ-টাস্ক কন্টেইনার প্রক্সিতে পৌঁছাতে বা একই ফাইলসিস্টেম কনফিগারেশন লোড করতে পারে না। ওই টাস্কগুলোই স্থানান্তর সম্পাদন করে।
ব্যর্থ টাস্কের জন্য, সম্পাদন হোস্ট, কার্যকর কনফিগারেশন ও নির্বাচিত এন্ডপয়েন্ট ত্রুটির সাথে সংরক্ষণ করুন। জমাদানের শেলের পরিবেশ একজন ওয়ার্কারের জন্য যথেষ্ট প্রমাণ নয়।
এই সেটিংসগুলো s3a:// নিয়ন্ত্রণ করে। পুরোনো Jets3t কানেক্টর রেসিপি অন্য একটি বাস্তবায়ন কনফিগার করে এবং এই কাজে ব্যবহৃত S3A অপশনগুলোর বিকল্প নয়।