برای اتصال‌دهنده S3A هادوپ 3.4.2 از طریق پراکسی HTTP، این ورودی‌ها را در پیکربندی هادوپ عملیات، معمولاً 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 نمی‌توانند به پراکسی برسند یا همان پیکربندی فایل‌سیستم را بارگذاری کنند. انتقال‌ها را همان وظایف انجام می‌دهند.

برای وظیفه ناموفق، میزبان اجرا، پیکربندی مؤثر و نقطه پایانی انتخاب‌شده را همراه با خطا نگه دارید. محیط پوسته ارسال برای یک کارگر شواهد کافی نیست.

این تنظیمات بر s3a:// حاکم است. دستورالعمل‌های قدیمی اتصال‌دهنده Jets3t پیاده‌سازی دیگری را پیکربندی می‌کنند و جایگزین گزینه‌های S3A مورد استفاده این کار نیستند.

مقالات مرتبط