MongoDB: совместное размещение процесса mongos на серверах приложений


12

Я хотел бы задать вопрос о наилучшей практике, описанной в этом документе:

http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf

Используйте несколько маршрутизаторов запросов. Используйте несколько процессов mongos, распределенных по нескольким серверам. Обычное развертывание заключается в размещении процесса mongos на серверах приложений, что обеспечивает локальную связь между приложением и процессом mongos. Соответствующее количество процессов mongos будет зависеть от характера приложения и развертывания.

Немного предыстории о нашем развертывании. У нас много узлов сервера приложений. Каждый из них запускает один процесс на основе JVM с RESTful WS без сохранения состояния. Как следует из этой передовой практики, каждый отдельный узел сервера приложений запускает свой собственный mongosпроцесс, что означает, что число процессов JVM всегда равно количеству mongosпроцессов.

Все mongosпроцессы подключаются к 3 серверам конфигурации и нескольким шардам монго (с наборами реплик внутри каждого шарда). Несмотря на то, что мы используем сегментированное развертывание, мы на самом деле не разделяем наши коллекции. Фактически у нас есть большое количество баз данных, которые распределяются по всем шардам во время их создания (и это наш основной сценарий использования шардинга на данный момент).

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

Каково ваше мнение о наилучшем подходе к определению количества mongosэкземпляров, соответствующих количеству экземпляров сервера приложений или размеру кластера MongoDB?

Недавно мы начали изучать управление кластерами для наших веб-служб без учета состояния, под которыми я подразумеваю такие инструменты, как Docker, Apache Mesos и Kubernetes. Если мы используем Docker, то обычно не рекомендуется запускать более одного процесса в контейнере. Учитывая этот факт, становится действительно трудно убедиться, что контейнер сервера приложений и mongosконтейнер всегда находятся на одном физическом узле и имеют одинаковое количество процессов. Это заставляет меня задуматься, применима ли эта передовая практика к кластерной архитектуре, которую я только что описал. Если нет, то не могли бы вы порекомендовать, как было бы лучше найти и развернуть mongosпроцессы в этой архитектуре?

Ответы:


12

Поскольку уже есть и ответ представлен, и при этом полезный и действительный, я не хочу отвлекаться от его собственной полезности, но действительно есть моменты, которые нужно поднять, выходящие за рамки простого краткого комментария. Поэтому рассмотрим это «увеличение», которое, мы надеемся, действительно, но в первую очередь в дополнение к тому, что уже было сказано.

Истина заключается в том, чтобы по-настоящему рассмотреть «то, как ваше приложение использует данные», а также знать факторы в «изолированной среде», а также предлагаемую «контейнерную среду», которые влияют на это.

Фоновый случай

Общая рекомендация по практической рекомендации для совместного размещения mongosпроцесса вместе с экземпляром приложения состоит в том, чтобы устранить любые сетевые издержки, необходимые для взаимодействия приложения с этим mongosпроцессом. Конечно, это также «рекомендуемая практика» - указывать количество mongosэкземпляров в строке подключения приложения в случае, когда этот «ближайший» узел по какой-то причине не должен быть доступен, тогда может быть выбран другой, хотя и с возможными накладными расходами на соединение с удаленный узел.

Случай с «докером», о котором вы говорите, кажется несколько произвольным. Хотя верно и то, что одной из основных целей контейнеров (а до этого, например, BSD-джейлов или даже chroot), как правило, является достижение некоторого уровня «изоляции процессов», нет ничего действительно плохого в запуске нескольких процессов, пока вы понять последствия.

В этом конкретном случае mongosпредполагается, что он «легкий» и запускается как «дополнительная функция» к процессу приложения таким образом, что он в значительной степени является «парной» частью самого приложения. Таким образом, сами образы Docker не имеют процесса, подобного initd, но на самом деле нет ничего плохого в том, чтобы запускать контроллер процесса, такой как supervisord (например), в качестве основного процесса для контейнера, который затем дает вам точку управления процессом этот контейнер также. Такая ситуация «парных процессов» является разумным случаем, а также достаточно распространенным вопросом, что для этого есть официальная документация .

Если вы выбрали такой тип «парной» операции для развертывания, то она действительно затрагивает основную точку поддержки mongosэкземпляра в том же сетевом соединении и действительно «экземпляр сервера», как и сам сервер приложений. Это также может рассматриваться как случай, когда «весь контейнер» потерпит неудачу, тогда этот узел сам по себе будет просто недействительным. Не то, чтобы я рекомендовал это, и на самом деле вам, вероятно, все равно следует настроить соединения для поиска других mongosэкземпляров, даже если они доступны только через сетевое соединение, которое увеличивает задержку.

Зависит от версии / использования

Теперь, когда эта точка зрения сделана, другое рассмотрение здесь возвращается к первоначальному рассмотрению совместного размещения mongosпроцесса с приложением для целей задержки в сети. В версиях MongoDB до 2.6 и, в частности, в отношении таких операций, как с платформой агрегации, существовал случай, когда сетевой трафик будет намного больше и впоследствии после обработки, выполняемой mongosпроцессом обработки данных из разных сегментов. , Сейчас это не так много, так как большая часть рабочей нагрузки обработки может теперь выполняться на самих этих осколках перед тем, как «перегоняться» к «маршрутизатору».

Другой случай - это шаблоны использования вашего приложения в отношении шардинга. Это означает, является ли основная рабочая нагрузка «распределением записей» по нескольким сегментам или же подходом «разброса» при консолидации запросов на чтение. В этих сценариях

Тестируй, тестируй и тестируй снова

Таким образом, последний пункт здесь действительно говорит сам за себя и сводится к общему согласию любого здравомыслящего ответа на ваш вопрос. Это не новость для MongoDB или любого другого решения для хранения данных, но ваша фактическая среда развертывания должна быть протестирована на ее «шаблонах использования», максимально приближенных к реальной реальности, равно как и любое «модульное тестирование» ожидаемой функциональности от основных компонентов или Общие результаты должны быть проверены.

На самом деле не существует «окончательного» выражения «настроить таким образом» или «использовать таким образом», которое действительно имеет смысл, кроме тестирования того, что «действительно работает лучше» для производительности и надежности вашего приложения, как и ожидалось.

Конечно, «лучшим случаем» всегда будет не «переполнять» mongosэкземпляры запросами «многих» источников серверов приложений. Но затем, чтобы дать им некоторый естественный «паритет», который может быть распределен по рабочим нагрузкам ресурсов, имеющим, по крайней мере, «пул ресурсов», который может быть выбран, и, в идеале, в идеале во многих случаях, но устраняет необходимость вызывать дополнительный "издержки сетевого транспорта".

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

Я также настоятельно рекомендую «бесплатные» (как в пиве) курсы, доступные, как уже упоминалось, и независимо от того, какой у вас уровень знаний. Я считаю, что различные источники материалов курса часто предлагают «скрытые жемчужины», чтобы дать более глубокое понимание вещей, которые вы, возможно, не рассматривали или иным образом упускали из виду. Класс M102, как упомянуто, создан и проведен Адамом Коммерфордом, которому я могу засвидетельствовать, обладает высоким уровнем знаний о крупномасштабных развертываниях MongoDB и других архитектур данных. Стоит потратить время, чтобы хотя бы по-новому взглянуть на то, что, как вы думаете, вы уже знаете.


5

Поскольку передовая практика также предполагает, что «надлежащее количество процессов mongos будет зависеть от характера приложения и развертывания», я начал задумываться о том, действительно ли уместно использование нами mongos.

Я думаю, что это вопрос, на который в конечном итоге могут ответить только вы, как указано в документации.

Одна из рекомендуемых стратегий заключается в том, чтобы mongosна каждом узле приложения была служба, а возможно, и дополнительный выделенный узел для дополнительной доступности. Поскольку у вас есть это в настоящее время, я не вижу ничего плохого в вашем текущем развертывании. Если в вашей архитектуре ничего не изменится, то вы в настоящее время находитесь в пределах лучших практик. Тем не мение...

Если мы используем Docker, то обычно не рекомендуется запускать более одного процесса в контейнере.

Поскольку этот mongosпроцесс не очень ресурсоемкий, вы также можете поместить его экземпляр на каждый из ваших шардов и позволить каждому mongodузлу также действовать как mongosузел. Это может иметь больше смысла, если вы несколько усложните архитектуру сервера приложений.

Лично я не слишком знаком с этими продуктами, но я бы также проконсультировался с поставщиком об их рекомендациях, поскольку они mongosмогут быть менее интенсивными, чем большинство других процессов, которые вы могли бы выполнять параллельно.

Наконец, вы всегда можете задействовать выделенные узлы для mongosпроцесса в зависимости от вашего масштаба, ресурсов и т. Д., Что также будет соответствовать наилучшей практике. Реальный вывод здесь заключается в том, что, пока у вас где- то есть куча mongosпроцессов, у вас все хорошо.

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

Вы можете посмотреть это видео на онлайн-курсе MongoDB M102, в котором рассматриваются эти темы, и, возможно, захотите попробовать записаться на M102 для класса DBA в следующий раз, когда он будет в сессии (бесплатно, онлайн).


Спасибо за отличный ответ! «но если вы собираетесь использовать выделенные узлы, я постараюсь максимально приблизить количество узлов приложения». В чем причина этого заявления?
Теньши

Мое мнение: в большинстве случаев меньше узлов приложений, чем шардов, и, поскольку рекомендуется использовать узлы приложений для mongos, сопоставление с тем же числом выделенных узлов должно обеспечить как минимум достаточное количество mongosэкземпляров. Это не точная наука и зависит от ваших потребностей, но именно так я бы предпочел производственную среду.
LowlyDBA
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.