Hadoop DistCp: S3A პროქსის კონფიგურაცია worker-ის ამოცანებში
კონფიგურაცია გაუკეთეთ Hadoop S3A კონექტორის პროქსის და კონფიგურაცია ხელმისაწვდომი გახადეთ იქ, სადაც DistCp-ის worker-ები გადატანას ასრულებენ.
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 კავშირს ამ პროქსისთან; ის არ გამორთავს TLS-ს S3A-დან S3-მდე. გამოიყენეთ მნიშვნელობა, რომელიც შეესაბამება პროქსის რეალურ მსმენელს.
შეამოწმეთ ორივე მომხმარებელი. გამომგზავნი კლიენტი შეიძლება წარმატებით ჩამოთვლიდეს S3-ს, მაშინ როცა DistCp-ის map-ამოცანების კონტეინერები ვერ აღწევენ პროქსის ან ვერ ტვირთავენ იმავე ფაილური სისტემის კონფიგურაციას. გადატანას სწორედ ეს ამოცანები ასრულებენ.
წარუმატებელი ამოცანისთვის შეინახეთ შესრულების ჰოსტი, მოქმედი კონფიგურაცია და არჩეული საბოლოო წერტილი შეცდომასთან ერთად. გაგზავნის shell-ის გარემო არ არის საკმარისი მტკიცებულება worker-ისთვის.
ეს პარამეტრები მართავს s3a://-ს. Jets3t კონექტორის ძველი რეცეპტები სხვა იმპლემენტაციას აკონფიგურირებს და არ ცვლის ამ სამუშაოში გამოყენებულ S3A პარამეტრებს.