LINUX.ORG.RU
ФорумAdmin

Два инстанса MongoDB на одном хранилище

 ,


0

3

Всем привет.

Возникла необходимость сокращения расходуемого дискового пространства (точнее его эффективного использования) в системе, где для отказоустойчивости используются две разных виртуальных машины с двумя разными копиями одной и той же базы Mongo. Они независимы по своей сути, хотя данные инсертятся в них параллельно (сначала в одну, потом - в другую) с помощью скрипта на PHP.

База сама по себе немаленькая - около 3 Тб и если бы их получилось высвободить, было бы весьма недурно.

У меня есть возможность подключить к обеим виртуалкам общий сторадж нужного объёма. Писать одновременно в него я не собираюсь, но на всякий случай могу использовать какую-нибудь кластерную файловую систему вроде OCFS2 или GFS2.

Собственно вопрос: возможна ли работа двух инстансов Mongo с одним стораджем при условии, что писать будет только один. А второй подключаться только в том случае, если первый становится недоступным. Переключение регулируется через L7-балансер - выделен виртуальный IP, на который направлен приложение.

Заранее благодарю за любую помощь.


В твоем описании это не два стораджа одновременно, а по очереди. Если так, то проблем нет.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Спасибо за ответ.

Не совсем понял. Сторадж - один. Работа инстансов с ним будет одновременной. Только писать в базу будет лишь один из них, второй - только читать. Возможно, я не совсем правильно передал суть вопроса. То есть будут запущены две монги, направленные на директорию с одной и той же базой на общем шаред-сторадже. Работа будет идти только через активный инстанс (он всегда будет один). При отключении основного, соединения будут перенаправлены на второй. В таком случае он сможет продолжить работу и запись в базу? Вот что меня интересует.

Korben
() автор топика
Ответ на: комментарий от Korben

Два инстанса БД с одним файлом работать не смогут.

А какой смысл в таком решении? От падения процесса сервера должен защищать простой watchdog, если при падении возникнут проблемы с файлами базы, то второй инстанс работать не будет.

Для обеспечения резервирования нужны две полностью развязанных базы и очень желательно — на разных машинах.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

Благодарю за комментарий.

Watchdog есть, но возможны случаи (и они уже были), когда в системе по разным причинам, спровоцированным извне, исчерпывались ресурсы и система переставала отвечать полностью и помогала только перезагрузка. Вот для таких моментов такая схема и прощупывается.

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

Неужели нет решения для отказоустойчивости Монго?

Korben
() автор топика
Ответ на: комментарий от Korben

исчерпывались ресурсы и система переставала отвечать полностью и помогала только перезагрузка. Вот для таких моментов такая схема и прощупывается.

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

Неужели нет решения для отказоустойчивости Монго?

На одной копии данных? Нет ни для какой системы :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Korben

Неужели нет решения для отказоустойчивости Монго?

Разработчики монго не расчитывали на тотальных бомжей, это правда.

anonymous
()
Ответ на: комментарий от anonymous

Разработчики монго не расчитывали на тотальных бомжей, это правда.

Ну не то, чтобы совсем тотальных. Если база сейчас 3 Тб, и она постоянно растёт, то для replica-set нужно ещё 6 Тб. То есть не менее 12 Тб, причём на независимых устройствах. Не так уж и мало, как мне кажется.

На одной копии данных? Нет ни для какой системы :)

Ну, скажем, веб-приложение таким образом резервируется весьма успешно. Но, в целом, я так и думал, что вряд ли это реализуемо. Просто хотел убедиться до конца. Спасибо за помощь!

Korben
() автор топика
Ответ на: комментарий от Korben

Ну, скажем, веб-приложение таким образом резервируется весьма успешно.

Два инстанса web-серверов на одном наборе статики? Но смысл? Всё равно не понимаю преимущества по сравнению с обычным watchdog и одним инстансом. Более того, в данном случае будет фактически один инстанс с вотчдогом против трёх инстансов (ибо ещё нужен балансер).

KRoN73 ★★★★★
()
Ответ на: комментарий от Korben

Если база сейчас 3 Тб, и она постоянно растёт

Вопрос на засыпку, ты случаем не логи там хранишь?

anonymous
()
Ответ на: комментарий от anonymous

Нет, не логи. Хотя и логи тоже есть частично, но разве это принципиально?

Два инстанса web-серверов на одном наборе статики? Но смысл?

Ну, например - балансировка нагрузки между двумя узлами. К примеру, у меня в гипервизоре конвергентной системы можно установить максимум 12 ядер у виртуалки, по ОЗУ тоже есть потолок. Ну и случалось так, что при небольших DoS-ах, веб-сервер не успевал обслуживать всех клиентов, начинал ждать ответа от базы, в итоге всё это переходило в подобие syn flood'а и система переставала отвечать вовсе. В этот момент, как раз, балансировщик переключал запросы на второй узел, который пока ещё не был забит соединениями. Разумеется, через время и он переставал отвечать. Но во-первых, был небольшой выигрыш по времени. Во-вторых, не обязательно DoS-атака - достаточно какого-нибудь незавершившегося таска в кроне, который из-за невнимательности программиста проглотил все ресурсы.

Согласен с вами, что случаи должны быть уж очень частные, но иногда они происходят и в некотором роде такое решение может выручить.

Korben
() автор топика
Ответ на: комментарий от Korben

но разве это принципиально?

3TB данных для бедного приложения это много.

A1
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.