Hadoop 3.4.2 کے S3A کنیکٹر کے لیے HTTP پراکسی کے ذریعے، یہ اندراجات آپریشن کی 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 اختیارات کا متبادل نہیں ہیں۔

متعلقہ مضامین