Можно ли масштабировать Hashicorp Vault с помощью серверной части хранилища DynamoDB?

Я использую Vault на AWS с серверной частью DynamoDB. Бэкэнд поддерживает HA.

storage "dynamodb" {
  ha_enabled = "true"
  region     = "us-west-2"
  table      = "vault-data"
}

Чтение документации по концепции высокой доступности: https://www.vaultproject.io/docs/concepts/ha.html

Для обеспечения высокой доступности один из узлов сервера Vault захватывает блокировку в хранилище данных. Успешный серверный узел затем становится активным узлом; все остальные узлы становятся резервными узлами. На этом этапе, если резервные узлы получают запрос, они либо перенаправят запрос, либо перенаправят клиента в зависимости от текущей конфигурации и состояния кластера - подробности см. В разделах ниже. Из-за этой архитектуры HA не обеспечивает повышенной масштабируемости.

Меня не интересует наличие целого парка инстансов EC2 за ELB, где только 1 инстанс ведет себя как мастер и разговаривает с DynamoDB.

Я хотел бы запустить N экземпляров Ec2 под управлением Vault, которые читают и пишут независимо от DynamoDB.

Поскольку DynamoDB поддерживает чтение / запись из нескольких экземпляров EC2, я ожидал, что смогу распечатать Vault из нескольких экземпляров одновременно и выполнять операции чтения и записи. Это должно работать даже с ha_enabled = "false", без выбора лидера.

Почему эта архитектура не предлагается в документации? Почему не должно работать? Есть ли какие-то криптографические ограничения, которых мне не хватает?

Спасибо


amazon-dynamodb hashicorp-vault
person Saverio Proto    schedule 08.03.2019    source источник
comment
отличный вопрос, удалось ли вам это настроить?   -  person karthikeayan    schedule 19.10.2020
comment
Я смог задать этот вопрос разработчику Vault на HashiConf EU в Амстердаме в 2019 году. Он подтвердил, что несколько экземпляров Vault EC2 не должны не обращаться к внутреннему хранилищу DynamoDB одновременно, и что это может привести к неожиданные проблемы. Я не получил достаточно информации, чтобы подробно объяснить, откуда взялось ограничение. Предлагаемое решение заключалось в использовании Vault Enterprise с функциями для поддержки горизонтальной масштабируемости. Мне все еще было бы очень интересно понять, откуда берется предел.   -  person Saverio Proto    schedule 23.10.2020

Ответы (1)


arrow_upward
1
arrow_downward

Это особенность Vault Enterprise. С его помощью вы можете настроить первичный кластер и столько же вторичных кластеров, более известных как реплики производительности. Каждый кластер имеет собственное хранилище и механизм распечатки. Таким образом, у вас может быть один кластер на Dynamo DB, а другой на Raft. Если оба находятся в Dynamo DB, вам понадобится таблица Dynamo DB для каждого.

Но имейте в виду, что реплики производительности всегда перенаправляют операции записи в основной кластер. Операция записи - это то, что влияет на глобальное состояние Vault. В этом смысле POST для /transit не считается операцией записи.

Другой вариант - установить локальный магазин kv (с флагом -local). Тогда он будет вести себя как первичный, даже если он установлен на реплике производительности, за счет невозможности репликации в другой кластер.

Последнее замечание: кластеры DR являются точной копией любого кластера. Каждый кластер, будь то первичный или реплика, может иметь свой кластер аварийного восстановления.

person ixe013    schedule 19.10.2020