Hadoop DistCp: налада праксі S3A ў заданнях рабочых вузлоў

Наладзьце праксі канектара Hadoop S3A і зрабіце канфігурацыю даступнай там, дзе рабочыя DistCp выконваюць перадачу.

Для канектара 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 не могуць дасягнуць праксі або загрузіць тую ж канфігурацыю файлавай сістэмы. Менавіта гэтыя заданні выконваюць перадачу.

Для няўдалага задання захавайце хост выканання, дзейную канфігурацыю і выбраны эндпойнт разам з памылкай. Асяроддзе абалонкі адпраўкі — недастатковы доказ для рабочага вузла.

Гэтыя налады кіруюць s3a://. Старыя рэцэпты канектара Jets3t наладжваюць іншую рэалізацыю і не замяняюць опцыі S3A, што выкарыстоўваюцца ў гэтай працы.

Падобныя артыкулы