Сравнение распределения ресурсов для членов набора реплик и узлов шардинга

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

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

Понимание стратегий развертывания MongoDB

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

Наборы реплик: высокая доступность и избыточность данных

Набор реплик MongoDB — это группа экземпляров mongod, которые поддерживают один и тот же набор данных. Это обеспечивает высокую доступность и избыточность данных. Набор реплик обычно состоит из:

Первичный узел: Единственный узел, который принимает все операции записи. Он записывает все изменения в свой журнал операций (oplog). В наборе реплик может быть только один первичный узел в любой момент времени.
Вторичные узлы: Реплицируют oplog первичного узла и применяют эти изменения к своим собственным наборам данных, обеспечивая согласованность данных. Вторичные узлы могут обслуживать операции чтения в зависимости от настроек предпочтения чтения и могут быть избраны первичными, если текущий первичный узел становится недоступным.
Узел-арбитр: Участвует в выборах для определения первичного узла, но не хранит данные. Арбитры потребляют минимальные ресурсы и могут использоваться для добавления голоса, когда невозможно развернуть другой узел, содержащий данные. Они не предотвращают все проблемы с выборами и должны использоваться экономно.

Шардированные кластеры: горизонтальная масштабируемость

Шардинг — это метод MongoDB для распределения данных по нескольким машинам. Это обеспечивает горизонтальное масштабирование для обработки больших наборов данных и операций с высокой пропускной способностью, с которыми не может справиться один набор реплик. Шардированный кластер состоит из нескольких ключевых компонентов:

Mongos (маршрутизаторы запросов): Действуют как интерфейс между клиентскими приложениями и шардированным кластером. Они направляют запросы к соответствующим шардам, агрегируют результаты и управляют соединениями.
Серверы конфигурации (CSRS): Хранят метаданные кластера, включая то, какие диапазоны данных находятся на каких шардах ('карта шардов'). Серверы конфигурации развертываются как набор реплик (Config Server Replica Set - CSRS) для обеспечения высокой доступности.
Шарды: Каждый шард сам по себе является набором реплик, который хранит подмножество данных кластера. Данные распределяются по этим шардам на основе ключа шардирования.

Распределение ресурсов для членов набора реплик

Требования к ресурсам для членов набора реплик существенно различаются в зависимости от их роли и общей рабочей нагрузки.

Первичный узел

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

ЦП: Высокий. Нагрузки с интенсивной записью, сложные конвейеры агрегации, операции индексирования и обработка большого количества одновременных соединений требуют значительной вычислительной мощности ЦП. Если ваше приложение часто обновляет документы или выполняет интенсивные запросы, ЦП первичного узла может быстро стать узким местом.
ОЗУ: Критично. Механизм хранения WiredTiger в MongoDB сильно зависит от ОЗУ для своего кэша. Первичному узлу требуется достаточно ОЗУ для хранения часто используемых данных и индексов в памяти, чтобы минимизировать дисковый ввод-вывод. Распространенная рекомендация — выделить достаточно ОЗУ для размещения вашего рабочего набора (данные и индексы, активно используемые вашими приложениями) плюс некоторый буфер.
Хранилище: Высокая производительность IOPS и пропускная способность. Все операции записи попадают на диск первичного узла, включая журналирование. Быстрые хранилища (SSD/NVMe) с высоким IOPS (операции ввода-вывода в секунду) необходимы для предотвращения задержек записи, становящихся узким местом. Емкость должна быть достаточной для полного набора данных и его роста, а также для пространства oplog.

Вторичные узлы

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

ЦП: Умеренный или высокий. Использование ЦП зависит от скорости репликации и рабочей нагрузки чтения. Если вторичные узлы обрабатывают значительную часть чтений, их требования к ЦП могут приближаться к требованиям первичного узла. Если они в основном используются для репликации и отказоустойчивости, использование ЦП будет ниже, но все равно важно для эффективного применения записей oplog.
ОЗУ: Критично. Как и первичный узел, вторичные узлы поддерживают кэш WiredTiger и нуждаются в достаточном объеме ОЗУ для хранения рабочего набора, чтобы эффективно применять записи oplog и обслуживать чтения без чрезмерного дискового ввода-вывода. Кэш вторичного узла в идеале должен зеркалировать кэш первичного для обеспечения стабильной производительности при отказе.
Хранилище: Высокая производительность IOPS и пропускная способность. Вторичные узлы должны успевать за записями первичного узла, применяя записи oplog. Это также требует высокой производительности ввода-вывода. Емкость должна быть идентична первичному узлу, так как они хранят полную копию данных.

Совет: Убедитесь, что вторичные узлы подготовлены аналогично первичному. Это обеспечивает плавный отказ и стабильную производительность, когда вторичный узел становится первичным.

Узел-арбитр

Арбитры — это легковесные узлы, предназначенные исключительно для участия в выборах. Они не хранят данные и не обслуживают операции чтения/записи.

ЦП: Очень низкий. Арбитры выполняют минимальные вычисления, связанные с протоколами выборов.
ОЗУ: Очень низкое. Требуется только достаточно памяти для базовых накладных расходов процесса mongod и состояния выборов.
Хранилище: Очень низкое. Хранятся только минимальные файлы конфигурации и журналы, без файлов данных.

Предупреждение: Никогда не запускайте приложение или другие процессы базы данных на узле-арбитре. Это должен быть выделенный минимальный экземпляр для обеспечения его доступности для выборов и предотвращения конкуренции за ресурсы.

Распределение ресурсов для компонентов шардирования

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

Mongos (маршрутизаторы запросов)

Экземпляры mongos — это процессы маршрутизации без сохранения состояния. Они не хранят данные, но координируют операции между шардами.

ЦП: Умеренный или высокий. Использование ЦП масштабируется с количеством клиентских соединений, работой по маршрутизации запросов, запросами scatter-gather и работой по слиянию агрегаций, которую должен координировать mongos. Можно добавить больше экземпляров mongos для обработки более высоких нагрузок.
ОЗУ: Умеренное. В основном используется для управления соединениями, кэширования метаданных с серверов конфигурации (карта шардов) и временных буферов агрегации. Не так критично, как узлы, содержащие данные, но достаточный объем ОЗУ предотвращает подкачку и обеспечивает быстрое время отклика.
Хранилище: Очень низкое. Хранятся только журналы. Локальных SSD обычно более чем достаточно.

Совет: Для оптимальной производительности развертывайте экземпляры mongos рядом с серверами ваших приложений, чтобы минимизировать задержку в сети.

Серверы конфигурации (Config Server Replica Set - CSRS)

Серверы конфигурации имеют решающее значение для работы шардированного кластера, храня метаданные о состоянии кластера. Они всегда развертываются как набор реплик (CSRS).

ЦП: Умеренный. Использование ЦП может возрасти во время миграции блоков, ребалансировки шардов или частых обновлений метаданных. Хотя он не так высок, как у первичного узла, содержащего данные, стабильная производительность жизненно важна.
ОЗУ: Умеренное или высокое. Требуется достаточно ОЗУ для хранения критических метаданных кластера в памяти. Размер метаданных зависит от количества шардов, блоков и баз данных. Недостаточный объем ОЗУ может серьезно ухудшить производительность и стабильность кластера.
Хранилище: Умеренная производительность IOPS и емкость. Хотя размер метаданных обычно меньше, чем пользовательские данные, обновления карты шардов и другой информации о состоянии кластера могут быть частыми, что требует достойной производительности ввода-вывода. Емкость должна соответствовать растущим метаданным и oplog.

Предупреждение: Производительность и доступность ваших серверов конфигурации имеют первостепенное значение. Любое ухудшение может парализовать весь ваш шардированный кластер. Обеспечьте их высоконадежной и производительной инфраструктурой.

Члены шардов (наборы реплик, содержащие данные)

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

ЦП: Высокий для первичного, умеренный или высокий для вторичных. Первичный узел каждого шарда обрабатывает все записи и, возможно, чтения для своего подмножества данных. Требования пропорциональны рабочей нагрузке, направляемой на этот конкретный шард.
ОЗУ: Критично для первичного и вторичных узлов. Каждому mongod шарда требуется достаточный объем ОЗУ для его кэша WiredTiger, пропорциональный рабочему набору хранящихся данных. Это критически важно для производительности в пределах его сегмента данных.
Хранилище: Высокая производительность IOPS и пропускная способность для первичного и вторичных узлов. Как и в автономном наборе реплик, требуется быстрое хранилище для обработки записи, чтения и репликации для подмножества данных шарда. Емкость должна быть достаточной для части данных шарда и его роста.

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

Сравнение распределения ресурсов: набор реплик против шардированного кластера

Характеристика	Набор реплик (автономный)	Шардированный кластер
Назначение	Высокая доступность, избыточность данных, умеренное масштабирование	Горизонтальное масштабирование, очень большие наборы данных, высокая пропускная способность
Всего узлов	Обычно 3 узла с данными; арбитры только при необходимости	3 сервера конфигурации + N наборов реплик шардов (обычно по 3+ члена) + M экземпляров Mongos
ЦП	Первичный узел обрабатывает весь ЦП записи. Вторичные узлы обрабатывают ЦП чтения. Арбитр минимален.	Распределен между `mongos`, серверами конфигурации и несколькими первичными узлами шардов. В целом более высокий общий ЦП.
ОЗУ	Первичному и вторичным узлам требуется ОЗУ для всего рабочего набора.	Каждому первичному/вторичному узлу шарда требуется ОЗУ для своего подмножества рабочего набора. Серверам конфигурации требуется ОЗУ для метаданных. В целом более высокий общий объем ОЗУ.
Хранилище	Первичному и вторичным узлам требуется емкость и IOPS для всего набора данных.	Каждому первичному/вторичному узлу шарда требуется емкость и IOPS для своего подмножества набора данных. Серверам конфигурации требуется умеренная производительность IOPS/емкость. В целом более высокий общий объем хранилища.
Узкое место	Первичный узел для записи; ограничения ресурсов одной машины.	Любой компонент (`mongos`, серверы конфигурации или отдельный шард) может стать узким местом при недостаточном выделении ресурсов.
Сложность	Относительно проще в настройке и управлении.	Значительно сложнее в планировании, развертывании и управлении.
Стоимость	Более низкая стоимость инфраструктуры для умеренного масштаба.	Более высокая стоимость инфраструктуры из-за большего количества экземпляров и распределенного характера.

Практические соображения и лучшие практики

Анализ рабочей нагрузки: Тщательно изучите шаблоны чтения/записи вашего приложения, прогнозы роста данных и сложность запросов. Это самый важный фактор в планировании ресурсов.
Мониторинг — ключевой фактор: Внедрите комплексный мониторинг для всех компонентов MongoDB (ЦП, ОЗУ, дисковый ввод-вывод, сеть, метрики базы данных, такие как использование кэша WiredTiger, отставание oplog, время выполнения запросов). Это помогает выявить узкие места и позволяет проводить упреждающее масштабирование.
Производительность сети: Для шардированных кластеров задержка в сети и пропускная способность между mongos, серверами конфигурации и шардами имеют решающее значение. Межшардовая связь и операции балансировки данных могут сильно пострадать от плохой производительности сети.
Выделенные ресурсы: Каждый процесс mongod, будь то первичный, вторичный узел или член шарда, должен работать на выделенном оборудовании или выделенной виртуальной машине. Избегайте совместного размещения с серверами приложений или другими экземплярами баз данных, чтобы предотвратить конкуренцию за ресурсы.
Облако vs. Локальная инфраструктура: Облачные провайдеры предлагают гибкость для легкого масштабирования ресурсов. Однако убедитесь, что выбранные типы экземпляров соответствуют требованиям IOPS и пропускной способности, особенно для операций с интенсивным использованием хранилища.
Тестирование и бенчмаркинг: Всегда тестируйте запланированную инфраструктуру с реалистичными рабочими нагрузками перед выходом в производство. Это помогает подтвердить ваши предположения о распределении ресурсов.

Вывод

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