HTTP പ്രോക്സിലൂടെയുള്ള Hadoop 3.4.2-ന്റെ S3A കണക്ടറിന്, ഈ എൻട്രികൾ പ്രവർത്തനത്തിന്റെ 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 ഓപ്ഷനുകൾക്ക് പകരമാകുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ