Репозиторий S3

Для регистрации репозитория S3 укажите тип как s3 при создании репозитория. Репозиторий по умолчанию использует учетные данные ECS IAM Role для аутентификации. Также вы можете использовать учетные записи Kubernetes service accounts для аутентификации.

Единственным обязательным параметром является имя ведра:

resp = client.snapshot.create_repository(
    name="my_s3_repository",
    repository={
        "type": "s3",
        "settings": {
            "bucket": "my-bucket"
        }
    },
)
print(resp)

const response = await client.snapshot.createRepository({
  name: "my_s3_repository",
  repository: {
    type: "s3",
    settings: {
      bucket: "my-bucket",
    },
  },
});
console.log(response);

PUT _snapshot/my_s3_repository
{
  "type": "s3",
  "settings": {
    "bucket": "my-bucket"
  }
}

Клиент, используемый для подключения к S3, имеет ряд доступных настроек. Настройки имеют вид s3.client.CLIENT_NAME.SETTING_NAME. По умолчанию, s3 хранилища используют клиента с именем default, но это можно изменить с помощью настройки хранилища client. Например:

resp = client.snapshot.create_repository(
    name="my_s3_repository",
    repository={
        "type": "s3",
        "settings": {
            "bucket": "my-bucket",
            "client": "my-alternate-client"
        }
    },
)
print(resp)

const response = await client.snapshot.createRepository({
  name: "my_s3_repository",
  repository: {
    type: "s3",
    settings: {
      bucket: "my-bucket",
      client: "my-alternate-client",
    },
  },
});
console.log(response);

PUT _snapshot/my_s3_repository
{
  "type": "s3",
  "settings": {
    "bucket": "my-bucket",
    "client": "my-alternate-client"
  }
}

Большинство настроек клиента можно добавить в файл конфигурации elasticsearch.yml, за исключением защищённых настроек, которые добавляются в хранилище ключей Elasticsearch. Дополнительную информацию о создании и обновлении хранилища ключей Elasticsearch см. в Разделе настроек безопасности.

Например, если вы хотите использовать определённые учетные данные для доступа к S3, выполните следующие команды, чтобы добавить эти учетные данные в хранилище ключей.

bin/elasticsearch-keystore add s3.client.default.access_key
bin/elasticsearch-keystore add s3.client.default.secret_key
# a session token is optional so the following command may not be needed
bin/elasticsearch-keystore add s3.client.default.session_token

Если вместо этого вы хотите использовать роль экземпляра или роль контейнера для доступа к S3, оставьте эти настройки не заданными. Вы можете переключиться с использования определённых учетных данных обратно к использованию роли экземпляра или роли контейнера по умолчанию, удалив эти настройки из хранилища ключей следующим образом:

bin/elasticsearch-keystore remove s3.client.default.access_key
bin/elasticsearch-keystore remove s3.client.default.secret_key
# a session token is optional so the following command may not be needed
bin/elasticsearch-keystore remove s3.client.default.session_token

Все защищённые настройки клиента этого типа хранилища перезагружаемые. Вы можете определить эти настройки до запуска узла или вызвать API перезагрузки защищённых настроек узлов после определения настроек, чтобы применить их к работающему узлу.

После перезагрузки настроек внутренние s3 клиенты, используемые для передачи содержимого моментального снимка, будут использовать последние настройки из хранилища ключей. Любые существующие s3 хранилища, а также любые вновь созданные хранилища, будут использовать новые значения, сохранённые в хранилище ключей.

Следующий список содержит доступные настройки клиента. Те, которые должны храниться в хранилище ключей, помечены как «защищённые» и являются перезагружаемыми; другие настройки относятся к файлу elasticsearch.yml.

Тип репозитория s3 поддерживает ряд настроек для настройки способа хранения данных в S3. Эти настройки можно указать при создании репозитория. Например:

resp = client.snapshot.create_repository(
    name="my_s3_repository",
    repository={
        "type": "s3",
        "settings": {
            "bucket": "my-bucket",
            "another_setting": "setting-value"
        }
    },
)
print(resp)

const response = await client.snapshot.createRepository({
  name: "my_s3_repository",
  repository: {
    type: "s3",
    settings: {
      bucket: "my-bucket",
      another_setting: "setting-value",
    },
  },
});
console.log(response);

PUT _snapshot/my_s3_repository
{
  "type": "s3",
  "settings": {
    "bucket": "my-bucket",
    "another_setting": "setting-value"
  }
}

Поддерживаются следующие настройки:

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

Например:

resp = client.snapshot.create_repository(
    name="my_s3_repository",
    repository={
        "type": "s3",
        "settings": {
            "client": "my-client",
            "bucket": "my-bucket",
            "endpoint": "my.s3.endpoint"
        }
    },
)
print(resp)

const response = await client.snapshot.createRepository({
  name: "my_s3_repository",
  repository: {
    type: "s3",
    settings: {
      client: "my-client",
      bucket: "my-bucket",
      endpoint: "my.s3.endpoint",
    },
  },
});
console.log(response);

PUT _snapshot/my_s3_repository
{
  "type": "s3",
  "settings": {
    "client": "my-client",
    "bucket": "my-bucket",
    "endpoint": "my.s3.endpoint"
  }
}

Это создает репозиторий, который использует все настройки клиента из клиента my_client_name, за исключением endpoint, которая переопределяется на my.s3.endpoint настройками репозитория. `

Amazon S3 поддерживает различные классы хранения, каждый из которых предлагает разные характеристики работы. Например, некоторые классы стоят меньше за байт хранимых данных в месяц, но дороже за запрос, а другие классы могут отличаться по гарантиям доступности.

Вы можете указать класс хранения, который Elasticsearch использует для хранения объектов данных, с помощью настройки репозитория storage_class.

Изменение настройки storage_class в существующем репозитории влияет только на класс хранения для вновь созданных объектов, что приводит к смешанному использованию классов хранения.

Вы можете использовать политику жизненного цикла S3 для изменения класса хранения существующих объектов в вашем репозитории, но вы не должны переводить объекты в недопустимый класс, такой как классы Glacier, и вы не должны истекать объекты. Если вы используете класс Glacier или другой недопустимый класс хранения или истечение срока действия объекта, вы можете навсегда потерять доступ к содержимому своего репозитория.

Вы можете использовать класс хранения intellligent_tiering для автоматического управления классом объектов, но вы не должны включать дополнительные уровни доступа к архивам или глубокому архиву. Если вы используете эти уровни, вы можете навсегда потерять доступ к содержимому своего репозитория.

Дополнительная информация о классах хранения S3 доступна в Руководстве по классам хранения AWS S3.

Для ограничения процесса создания снимков Elasticsearch до минимально необходимых ресурсов рекомендуется использовать Amazon IAM в сочетании с уже существующими хранилищами S3. Вот пример политики, которая разрешит доступ к снимкам для хранилища S3 с именем «snaps.example.com». Это можно настроить через консоль AWS IAM, создав пользовательскую политику и используя документ политики, аналогичный этому (изменив snaps.example.com на имя вашего хранилища).

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads",
        "s3:ListBucketVersions"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::snaps.example.com"
      ]
    },
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::snaps.example.com/*"
      ]
    }
  ],
  "Version": "2012-10-17"
}

Вы можете дополнительно ограничить разрешения, указав префикс внутри хранилища, например, «foo».

{
  "Statement": [
    {
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation",
        "s3:ListBucketMultipartUploads",
        "s3:ListBucketVersions"
      ],
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "foo/*"
          ]
        }
      },
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::snaps.example.com"
      ]
    },
    {
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::snaps.example.com/foo/*"
      ]
    }
  ],
  "Version": "2012-10-17"
}

Хранилище должно существовать для регистрации репозитория снимков. Если вы не создали хранилище, регистрация репозитория завершится ошибкой.

Если вы хотите использовать учетные записи Kubernetes для аутентификации, вам нужно добавить символическую ссылку на переменную среды $AWS_WEB_IDENTITY_TOKEN_FILE (которая должна быть автоматически установлена подсистемой Kubernetes) в директории конфигурации репозитория S3, чтобы репозиторий мог получить доступ для чтения для учетной записи сервиса (репозиторий не может читать файлы вне своей директории конфигурации). Например:

mkdir -p "${ES_PATH_CONF}/repository-s3"
ln -s $AWS_WEB_IDENTITY_TOKEN_FILE "${ES_PATH_CONF}/repository-s3/aws-web-identity-token-file"

Если символическая ссылка существует, она будет использоваться по умолчанию всеми репозиториями S3, у которых нет явных client учетных данных.

Инстансы AWS разрешают S3-эндпоинты по общедоступному IP. Если инстансы Elasticsearch находятся в частной подсети в AWS VPC, весь трафик к S3 будет проходить через NAT-инстанс VPC. Если ваш NAT-инстанс VPC имеет меньший размер (например, t2.micro) или обрабатывает большой объем сетевого трафика, ваша пропускная способность к S3 может быть ограничена ограничениями пропускной способности сети NAT-инстанса. Вместо этого рекомендуется создать эндпоинт VPC, который позволяет подключаться к S3 из инстансов, находящихся в частной подсети в AWS VPC. Это устранит любые ограничения, накладываемые пропускной способностью сети NAT-инстанса VPC.

Инстансы, находящиеся в публичной подсети в AWS VPC, будут подключаться к S3 через интернет-шлюз VPC и не будут ограничены пропускной способностью NAT-инстанса VPC.

Существует ряд систем хранения, которые предоставляют S3-совместимый API, и тип репозитория s3 позволяет использовать эти системы вместо AWS S3. Для этого следует установить настройку s3.client.CLIENT_NAME.endpoint на эндпоинт системы. Эта настройка принимает IP-адреса и имена хостов и может включать порт. Например, эндпоинт может быть 172.17.0.2 или 172.17.0.2:9000.

По умолчанию Elasticsearch общается с вашей системой хранения с использованием HTTPS и проверяет цепочку сертификатов репозитория с использованием системного хранилища доверия JVM. Убедитесь, что системное хранилище доверия JVM содержит запись для вашего репозитория. Если вы хотите использовать небезопасное HTTP-соединение вместо HTTPS, установите s3.client.CLIENT_NAME.protocol в http.

MinIO — это пример системы хранения, которая предоставляет S3-совместимый API. Тип репозитория s3 позволяет Elasticsearch работать как с репозиториями, поддерживаемыми MinIO, так и с репозиториями, хранящимися в AWS S3. Другие S3-совместимые системы хранения также могут работать с Elasticsearch, но они не покрываются набором тестов Elasticsearch.

Существует множество систем, в том числе от очень известных поставщиков хранилищ, которые заявляют о поддержке S3-совместимого API, но на практике не полностью эмулируют поведение S3. Если вы используете такую систему для создания снимков, рассмотрите использование репозитория общего файловой системы, основанного на стандартном протоколе, таком как NFS, для доступа к вашей системе хранения вместо этого. Тип репозитория s3 требует полной совместимости с S3. В частности, он должен поддерживать тот же набор API-эндпоинтов с теми же параметрами, возвращать те же ошибки в случае сбоя и обеспечивать согласованность и производительность по крайней мере не хуже S3, даже при одновременном доступе нескольких узлов. Вам нужно будет связаться с поставщиком вашей системы хранения, чтобы решить любые возникающие несовместимости. Пожалуйста, не сообщайте о проблемах Elasticsearch, связанных с системами хранения, которые заявляют о совместимости с S3, если вы не можете продемонстрировать, что та же проблема существует при использовании настоящего репозитория AWS S3.

Вы можете выполнить некоторые базовые проверки пригодности вашей системы хранения с помощью API анализа репозитория. Если этот API не выполняется успешно или указывает на низкую производительность, ваша система хранения не полностью совместима с AWS S3 и поэтому не подходит для использования в качестве репозитория снимков. Однако эти проверки не гарантируют полной совместимости.

Большинство систем хранения можно настроить на ведение журнала взаимодействия с Elasticsearch. Если вы исследуете предполагаемую несовместимость с AWS S3, проще всего собрать эти журналы и предоставить их поставщику вашей системы хранения для дальнейшего анализа. Если несовместимость не очевидна из журналов, выпущенных системой хранения, настройте Elasticsearch на ведение журнала каждого запроса, который он отправляет в S3 API, установив уровень ведения журнала логгера com.amazonaws.request на DEBUG.

Чтобы предотвратить утечку конфиденциальной информации, такой как учетные данные и ключи, в журналах, Elasticsearch отклоняет настройку этого логгера с высокой детализацией, если не включено ведение журнала трассировки небезопасных сетевых запросов. Для этого нужно явно включить его на каждом узле, установив системную переменную es.insecure_network_trace_enabled в значение true.

После включения можно настроить логгер com.amazonaws.request:

resp = client.cluster.put_settings(
    persistent={
        "logger.com.amazonaws.request": "DEBUG"
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'logger.com.amazonaws.request' => 'DEBUG'
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "logger.com.amazonaws.request": "DEBUG",
  },
});
console.log(response);

PUT /_cluster/settings
{
  "persistent": {
    "logger.com.amazonaws.request": "DEBUG"
  }
}

Собирайте журналы Elasticsearch, охватывающие период неудачного анализа со всех узлов кластера, и предоставьте их поставщику вашей системы хранения вместе с ответом анализа, чтобы они могли использовать их для определения проблемы. См. документацию AWS Java SDK для получения дополнительной информации, включая сведения об использовании других логгеров для получения более подробных логов. После сбора необходимых журналов поставщику, верните настройки логгера обратно к значению null, чтобы вернуться к стандартной конфигурации ведения журнала и отключить небезопасное ведение журнала трассировки сети. См. Логгер и API обновления настроек кластера для получения дополнительной информации.

Реализация линейно-допустимого регистра для репозиториев S3 основана на строго последовательных семантиках API многочастной загрузки. Elasticsearch сначала создает многочастную загрузку, чтобы указать свое намерение выполнить операцию линейно-допустимого регистра. Затем Elasticsearch перечисляет и отменяет все другие многочастные загрузки для того же регистра. Затем Elasticsearch пытается завершить загрузку. Если загрузка завершится успешно, значит, операция сравнения и обмена была атомарной.