Настройка MongoDB ShardedCluster с X.509 аутентификацией

[@zeezdev]

Спасибо, данный сервис рассматривали — пока не хотим привязываться к Амазону. Возможно есть достойные опенсорс-решения?

[@Dr_Zoidberg]

consul не подходит?

[@zeezdev]

не пробовал, спасибо за вариант!

[@Sovigod]

Очень редкий пример настройки со сложной авторизацией. Это вам спасибо!
Но смущает колхоз с 2,5 серверами под кластер монги. Что случается с кластером из 2 нод без резервных мощностей при падении одной из нод = Вторая падает еще быстрее чем первая. «Высокая отказоустойчивость» — это не про ваш пример.

[@zeezdev]

Спасибо за комментарий! Приведенная конфигурация кластера, скажем так «минимально-необходимая», но вполне пригодная для миграции с возможностью расширения. В статье «2.5» сервера для того чтобы показать пример ОТ И ДО без пробелов в манипуляциях (надеюсь мне это удалось) ну и основной акцент на реализацию механизма x.509.
По поводу отказоустойчивости: даже такая конфиграция спасает от разных «мелочей жизни», например на одном из физических серверов внезапно кончилось место или отвалилась сеть, а в части высокой нагрузки согласен, нужно больше серверов.

[@Kolyuchkin]

Ув. автор, нет такого «механизма аутентификации х.509». Х.509 — это международный стандарт для инфраструктуры открытых ключей ( https://datatracker.ietf.org/wg/pkix/documents/ — здесь поинтересовались бы о X.509).

[@zeezdev]

Про стандарт читал, спасибо. Добавил в пост пару слов о нем самом.

В контексте MongoDB, x.509 (именно с маленькой буквы по всей документации) преподносится как один из механизмов реализованных для аутентификации в данной СУБД с использованием данных сертификатов:
https://docs.mongodb.com/manual/core/authentication-mechanisms/

В Python-драйвере (pymongo) он так прямо и именуется «The MONGODB-X509 mechanism»:
http://api.mongodb.com/python/current/examples/authentication.html#mongodb-x509

[@Razaz]

Это Mutal TLS Authentication

[@Kolyuchkin]

В контексте MongoDB, x.509 (именно с маленькой буквы по всей документации) преподносится как один из механизмов реализованных для аутентификации в данной СУБД с использованием данных сертификатов

В документации правильно сказано (не беря в расчет маленькую букву «х»), потому как «механизм аутентификации с использованием сертивикатов х.509» и «механизм аутентификации х.509» — совершенно разные вещи (второе, ваше, вводит в заблуждение знающих людей).

Чтобы выполнить условия x.509 нам необходим единый ключ – так называемый “Центр сертификации” Certificate Authority (CA).

Это тоже чушь… Я думал, что Вы хотя бы вскользь прочтете документы, ссылку на которые я Вам дал. ЦС (Центр сертификации) — это не «единый ключ», а неотъемлимая часть УЦ (Удостоверяющий центр), который в свою очередь является доверенной (т.н. «третьей», «арбитражной») стороной в инфраструктуре открытых ключей (ИОК, PKI). УЦ регистрирует пользователей и издает сертификаты открытых ключей пользователей, подписывая их на ключе подписи ЦС (проверить эту подпись можно открытым ключом ЦС). ЦС может получить свой сертификат либо от вышестоящего УЦ (ЦС), либо выпустить самоподписанный сертификат. Таким образом строится инфраструктура «доверия» (на основе цепочки сертификатов, начиная от сертификата пользователя и заканчивая сертификатом «корневого» ЦС, общего для всех). Это я Вам вкратце описал ИОК, чтобы Вы больше не писали подобное цитате выше)))

[@Seboreia]

А как у вас обстоят дела с восстановлением упавшей ноды? Столкнулся с такой проблемой, что после починки упавшей ноды вернуть ее в кластер сразу нельзя — синхронизация запускается, но не завершается, и нода висит в статусе 'recovery'. Приходиться останавливать другую рабочую ноду, rsync'ом заливать данные на новую и только после этого запускать. Очень неудобно, особенно когда в сете 3 ноды и последняя рабочая переходит в secondary

[@zeezdev]

Что подразумевается под падением ноды? На тестовом кластере отрабатывали ситуацию когда останавливали mongod на одном из серверов (Secondary) и физически удаляли каталог с его данными. После этого подсовывали пустой каталог и запускали инстанс, запускалась синхронизия с репликой и через некоторое время все успешно завершалось. Извеняюсь если не ответил на вопрос, было бы интересно если вы более подробно расписали о «падении» и «починке» ноды.

[@Seboreia]

Под падением имелось в виду возникновение любой нештатной ситуации (у нас, в частности, подвис хост виртуализации, на котором крутилась эта нода). А на сколько большая база у вас? У нас ~ 20 гигабайт, ждали 3-4 часа, но так и не дождались синхронизации. Версия монго 3.2

[@uran238]

Возможно стоит увеличить Oplog. Для того чтобы выяснить сколько времени может лежать нода, чтобы успешно «догнаться», можно выполнить команду db.getReplicationInfo

[@zeezdev]

У нас поменьше, на момент тестов думаю было ~ 2Гб (~5М док. в самой «жирной» коллекции). Версия 3.2.8. По времени точно не скажу, но насколько помню в районе 30мин-1час. Думаю для вашего объема стоит подождать подольше если нет прямых указаний на повисание синхронизации. Можно во время восстановления попробовать что-нибудь узнать командами зайдя на Primary:
https://docs.mongodb.com/manual/reference/command/replSetGetStatus/#dbcmd.replSetGetStatus
https://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/

[@Seboreia]

Хм, как будет время, попробую воспроизвести ситуацию и более тщательно промониторить. Но в любом случае это очень долго (даже у вас — 2Гб за 30 минут)