עבור מחבר S3A של Hadoop 3.4.2 דרך פרוקסי 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 בעוד שמכולות משימות ה-map של DistCp אינן יכולות להגיע לפרוקסי או לטעון את אותה תצורת מערכת קבצים. המשימות האלה הן שמבצעות את ההעברות.

במשימה שנכשלה, שמרו את מארח ההרצה, את התצורה התקפה ואת נקודת הקצה שנבחרה יחד עם השגיאה. סביבת מעטפת ההגשה אינה ראיה מספקת עבור worker.

הגדרות אלה חלות על s3a://. מתכוני מחבר Jets3t ישנים מגדירים מימוש אחר ואינם מחליפים את אפשרויות S3A שבהן משתמשת המשימה הזו.

מאמרים קשורים