Доступ к множественному экземпляру COS под одной и той же учетной записью IBM

Question

Я пытаюсь получить доступ к нескольким экземплярам COS, которые находятся под одной учетной записью IBM. Я вижу, что у каждого экземпляра COS свой ключ доступа, секретный ключ. Свойство в hive.xml (fs.s3a.access.key, fs.s3a.secret.key) может принимать только одно значение за один раз для одного экземпляра. Если я предоставляю несколько ключей доступа, то такие ключи, как access.key1, не работают, так как куст не понимает, к какому экземпляру принадлежит этот ключ. Любое предложение или альтернатива, чтобы исправить эту проблему. Облачное хранилище IBM имеет дополнительный уровень экземпляров COS -> сегментов по сравнению с amazon s3, где его просто сегменты. Для кого-то, кто не знаком с облаком IBM, этот вопрос можно представить так: можно ли будет ссылаться на две разные учетные записи s3 в одной и той же конфигурации улья. Потому что эти две разные учетные записи s3 будут иметь разные пары ключей. ПРИМЕЧАНИЕ: уведомление несколько экземпляров cos - это термин, относящийся к облаку IBM. в контексте aws все сегменты s3 идентифицируются по сегментам.

1. Несколько экземпляров улья для нескольких экземпляров cos. Эта штуковина работает, но я чувствую, что у нас может быть n случаев. 2. Попытка добавить дополнительные свойства в core-site.xml, например (fs.s3a.secret.key, fs.s3a.secret1.key), это не сработало для второго экземпляра.

       <name>fs.s3a.endpoint</name>
       <value>xxxxxxxx</value>
</property>
<property>
     <name>fs.s3a.access.key</name>
     <value>xxxxxxxx</value>
</property>
<property>
     <name>fs.s3a.secret.key</name>
     <value>xxxxxxxx</value>
   </property>```

Answer 1

Это не необычная ситуация;distcp между учетными записями распространен даже в AWS S3.

Hadoop 2.8+ поддерживает «конфигурацию для каждого сегмента», где вы можете определить секреты (и любой другой параметр) для отдельных сегментов: для конфигурации сегментов

Этого должно быть достаточно.

Answer 2

Похоже, вы используете более старую установку IaaS COS.

В идеале вы должны были бы перейти на более новую службу с поддержкой IAM, где вы можете легко использовать один набор учетных данных для любого экземпляра службы или группы, к которой вы хотите предоставить доступ.Это связано с тем, что IAM будет назначать учетные данные идентификатору, а не экземпляру службы (или учетной записи хранения, терминология может быть противоречивой).

Учетные данные могут быть связаны с «идентификатором службы», и этот «идентификатор службы» (в основном пользователь, не являющийся человеком) может быть предметом политик доступа, которые предоставляют роли в каждом из экземпляров, которые вы хотитеID для доступа.

Как правило, основной причиной наличия нескольких экземпляров является обеспечение большей детализации при выставлении счетов - нет практического ограничения на количество данных в экземпляре или количество объектов в корзине (хотя количество корзин)в одном случае в большинстве случаев их следует ограничивать сотнями).

Кроме того, в качестве забавного факта «экземпляр» является немного неправильным.COS - это настоящая многопользовательская система - все общедоступное облако представляет собой единый экземпляр COS (и IaaS, и IAM-совместимые на самом деле являются разными окнами в одной и той же системе).Поэтому, когда вы предоставляете новый «экземпляр», вы фактически получаете доступ к созданию новых сегментов внутри оплачиваемой сущности в существующей системе, но на самом деле ничего нового для вас не создается.