Включить Cassandra PasswordAuthenticator во время работы

У меня есть кластер Cassandra (Datastax с открытым исходным кодом), и в настоящее время аутентификация не настроена (т. Е. Он использует AllowAllAuthenticator), и я хочу использовать PasswordAuthenticator. В официальном документе говорится, что я должен выполнить следующие действия:

  1. включить PasswordAuthenticator в cassandra.yaml,

  2. перезапустите узел Cassandra, который создаст пространство ключей system_auth,

  3. изменить фактор репликации system_auth,

  4. создать нового пользователя и пароль

Однако для меня это большая проблема, потому что кластер используется в производстве, поэтому у нас не может быть простоя. Между шагами 2 и 4 ни один пользователь еще не настроен, поэтому, даже если клиент предоставит имя пользователя и пароль, запрос все равно будет отклонен, что не идеально.

Я просмотрел документ Datastax Enterprise, и в нем класс TransitionalAuthenticator, который создает пространство ключей system_auth, но не отклоняет запросы. Интересно, можно ли портировать этот класс в версию с открытым исходным кодом? Или если есть другие способы обойти эту проблему? Спасибо

Обновление Это версия Cassandra, которую я использую:

cqlsh 4.1.1 | Cassandra 2.0.9 | CQL spec 3.1.1 | Thrift protocol 19.39.0

cassandra datastax datastax-enterprise cassandra-2.0 cassandra-cli
person stackoverflower    schedule 21.10.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Вы должны быть в состоянии выполнить шаги 2-4 только с одним узлом и иметь нулевое время простоя, предполагая правильную конфигурацию клиента, репликацию и емкость кластера. Затем это просто последовательный перезапуск оставшихся узлов.

Клиенты должны быть настроены с учетными данными заранее, и они начнут использовать их в качестве узлов, как только узлы с авторизаторами подключатся к сети (такое поведение может зависеть от драйвера — сначала попробуйте).

Возможно, вы сможете вручную сгенерировать схему и данные для шагов 3–4, прежде чем задействовать CassandraAuthenticator, но в этом нет необходимости.

Что вас беспокоит в связи с простоями?

person Adam Holmberg    schedule 22.10.2014
comment
Спасибо за ваш ответ. Клиент действительно настроен на отправку учетных данных, а также может балансировать нагрузку между узлами. Есть две проблемы: 1) если клиент не может подключиться к одному узлу, он попытается подключиться к следующему, что потребует некоторого дополнительного времени запроса (это критическая производительность системы) и 2) другие узлы могут внезапно столкнуться с большими объем запросов, который замедлит их или даже приведет к их сбою. - person stackoverflower; 22.10.2014
comment
В зависимости от того, какой клиентский драйвер вы используете, отключенный узел должен быть исключен из балансировки нагрузки, поэтому дальнейшие запросы вообще не будут учитываться. Если это приложение не может выдержать отказ одного узла, у вас нет возможности сделать это или выполнить множество других задач по обслуживанию. - person Adam Holmberg; 22.10.2014