Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Очень редкий пример настройки со сложной авторизацией. Это вам спасибо!
Но смущает колхоз с 2,5 серверами под кластер монги. Что случается с кластером из 2 нод без резервных мощностей при падении одной из нод = Вторая падает еще быстрее чем первая. «Высокая отказоустойчивость» — это не про ваш пример.
Но смущает колхоз с 2,5 серверами под кластер монги. Что случается с кластером из 2 нод без резервных мощностей при падении одной из нод = Вторая падает еще быстрее чем первая. «Высокая отказоустойчивость» — это не про ваш пример.
Спасибо за комментарий! Приведенная конфигурация кластера, скажем так «минимально-необходимая», но вполне пригодная для миграции с возможностью расширения. В статье «2.5» сервера для того чтобы показать пример ОТ И ДО без пробелов в манипуляциях (надеюсь мне это удалось) ну и основной акцент на реализацию механизма x.509.
По поводу отказоустойчивости: даже такая конфиграция спасает от разных «мелочей жизни», например на одном из физических серверов внезапно кончилось место или отвалилась сеть, а в части высокой нагрузки согласен, нужно больше серверов.
По поводу отказоустойчивости: даже такая конфиграция спасает от разных «мелочей жизни», например на одном из физических серверов внезапно кончилось место или отвалилась сеть, а в части высокой нагрузки согласен, нужно больше серверов.
Ув. автор, нет такого «механизма аутентификации х.509». Х.509 — это международный стандарт для инфраструктуры открытых ключей ( https://datatracker.ietf.org/wg/pkix/documents/ — здесь поинтересовались бы о X.509).
Про стандарт читал, спасибо. Добавил в пост пару слов о нем самом.
В контексте 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
В контексте 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
В контексте MongoDB, x.509 (именно с маленькой буквы по всей документации) преподносится как один из механизмов реализованных для аутентификации в данной СУБД с использованием данных сертификатов
В документации правильно сказано (не беря в расчет маленькую букву «х»), потому как «механизм аутентификации с использованием сертивикатов х.509» и «механизм аутентификации х.509» — совершенно разные вещи (второе, ваше, вводит в заблуждение знающих людей).
Чтобы выполнить условия x.509 нам необходим единый ключ – так называемый “Центр сертификации” Certificate Authority (CA).
Это тоже чушь… Я думал, что Вы хотя бы вскользь прочтете документы, ссылку на которые я Вам дал. ЦС (Центр сертификации) — это не «единый ключ», а неотъемлимая часть УЦ (Удостоверяющий центр), который в свою очередь является доверенной (т.н. «третьей», «арбитражной») стороной в инфраструктуре открытых ключей (ИОК, PKI). УЦ регистрирует пользователей и издает сертификаты открытых ключей пользователей, подписывая их на ключе подписи ЦС (проверить эту подпись можно открытым ключом ЦС). ЦС может получить свой сертификат либо от вышестоящего УЦ (ЦС), либо выпустить самоподписанный сертификат. Таким образом строится инфраструктура «доверия» (на основе цепочки сертификатов, начиная от сертификата пользователя и заканчивая сертификатом «корневого» ЦС, общего для всех). Это я Вам вкратце описал ИОК, чтобы Вы больше не писали подобное цитате выше)))
А как у вас обстоят дела с восстановлением упавшей ноды? Столкнулся с такой проблемой, что после починки упавшей ноды вернуть ее в кластер сразу нельзя — синхронизация запускается, но не завершается, и нода висит в статусе 'recovery'. Приходиться останавливать другую рабочую ноду, rsync'ом заливать данные на новую и только после этого запускать. Очень неудобно, особенно когда в сете 3 ноды и последняя рабочая переходит в secondary
Что подразумевается под падением ноды? На тестовом кластере отрабатывали ситуацию когда останавливали mongod на одном из серверов (Secondary) и физически удаляли каталог с его данными. После этого подсовывали пустой каталог и запускали инстанс, запускалась синхронизия с репликой и через некоторое время все успешно завершалось. Извеняюсь если не ответил на вопрос, было бы интересно если вы более подробно расписали о «падении» и «починке» ноды.
Возможно стоит увеличить Oplog. Для того чтобы выяснить сколько времени может лежать нода, чтобы успешно «догнаться», можно выполнить команду db.getReplicationInfo
У нас поменьше, на момент тестов думаю было ~ 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/
https://docs.mongodb.com/manual/reference/command/replSetGetStatus/#dbcmd.replSetGetStatus
https://docs.mongodb.com/manual/tutorial/troubleshoot-replica-sets/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка MongoDB ShardedCluster с X.509 аутентификацией