Установка и настройка MongoDB Sharded Cluster на CentOS 7

Кратко: пошаговая инструкция по развёртыванию шардированного кластера MongoDB на CentOS 7 с конфигурацией config-server (реплика сет), несколькими шардами (реплика сеты) и mongos. Включены рекомендации по безопасности, отладке и контрольные чеклисты для продакшена. Подходит для тестовых и учебных окружений; в продакшене используйте поддерживаемую версию MongoDB и как минимум три config-server.

Что такое шардирование

Шардирование — это механизм горизонтального разбиения данных MongoDB по разным серверам (шардам). Каждый шар хранит часть набора данных, что позволяет масштабировать ёмкость и пропускную способность при росте объёмов. Шарды обычно разворачивают в виде replica set для обеспечения высокой доступности и устойчивости к сбоям.

Ключевые термины (в одну строку):

• Шард: подмножество данных, обычно в составе replica set.
• Config Server: хранит метаданные кластера и карту размещения чанков.
• Mongos: маршрутизатор запросов между приложением и шардами.

Шардирование и репликация

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

Important: в продакшене рекомендуется минимум три config-server для отказоустойчивости и корректного голосования в репликасете configsvr.

Компоненты шардированного кластера

• Shard — хранит данные. В рабочей среде каждый шар разворачивают как replica set (включая primary/secondary/арбитр при необходимости). Это обеспечивает высокую доступность и согласованность.
• Config Server — содержит метаданные кластера: где какие чанки и к каким шардам они принадлежат. mongos читает эту информацию. Для продакшена минимум 3 сервера.
• Mongos / Query Router — интерфейс приложения к кластеру. Приложение отправляет запросы на mongos, который использует shard key и метаданные config-server для маршрутизации запросов на нужные шарды.

Предварительные требования

• 2 сервера на CentOS 7 как Config Replica Set:
  • 10.0.15.31 configsvr1
  • 10.0.15.32 configsvr2
• 4 сервера на CentOS 7 как Shard Replica Sets:
  • 10.0.15.21 shardsvr1
  • 10.0.15.22 shardsvr2
  • 10.0.15.23 shardsvr3
  • 10.0.15.24 shardsvr4
• 1 сервер на CentOS 7 как mongos/Query Router:
  • 10.0.15.11 mongos
• root-привилегии на всех серверах
• Между серверами установлено сетевое соединение, порты открыты (по умолчанию mongod/mongos использует 27017)

NOTE: В демонстрационных сценариях этого руководства используется MongoDB 3.4. В продакшене рекомендуется использовать поддерживаемую и обновлённую версию MongoDB. Инструкции по конфигурации актуальны в логике, но параметры и пути репозиториев могут отличаться в новых версиях.

Шаг 1 — Отключение SELinux и настройка hosts

В этом руководстве мы отключим SELinux, изменив конфигурацию с “enforcing” на “disabled”. Подключитесь к всем узлам через OpenSSH:

ssh root@SERVERIP

Откройте конфигурационный файл SELinux и измените значение:

vim /etc/sysconfig/selinux

Измените строку:

SELINUX=disabled

Сохраните и закройте файл.

Далее отредактируйте файл hosts на каждом сервере:

vim /etc/hosts

Вставьте следующую конфигурацию хостов (пример):

    10.0.15.31      configsvr1
    10.0.15.32      configsvr2
    10.0.15.11      mongos
    10.0.15.21      shardsvr1
    10.0.15.22      shardsvr2
    10.0.15.23      shardsvr3
    10.0.15.24      shardsvr4

Сохраните файл и перезагрузите сервера:

reboot

Important: обновление /etc/hosts упрощает адресацию по имени в командах mongo/mongod и в конфигурации replica set.

Шаг 2 — Установка MongoDB на все инстансы

В этом примере добавим репозиторий MongoDB 3.4 и установим пакет mongodb-org. На каждой ноде выполните:

cat <<'EOF' >> /etc/yum.repos.d/mongodb.repo
[mongodb-org-3.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-3.4.asc
EOF

sudo yum -y install mongodb-org

После установки проверьте версию:

mongod --version

Important: путь установки и менеджер пакетов зависят от дистрибутива и версии MongoDB. Для современных версий используйте официальную документацию MongoDB.

Шаг 3 — Создание Config Server Replica Set

В наших предположениях config-серверы: configsvr1 (10.0.15.31) и configsvr2 (10.0.15.32). На каждой ноде:

1. Остановите текущий mongod (если запущен):

systemctl stop mongod

2. Измените конфигурацию /etc/mongod.conf:

vim /etc/mongod.conf

Изменения, которые нужно внести (пример для первой ноды):

storage:
  dbPath: /data/db1

net:
  bindIp: 10.0.15.31

replication:
  replSetName: "replconfig01"

sharding:
  clusterRole: configsvr

Для второй ноды используйте dbPath: /data/db2 и bindIp: 10.0.15.32. Сохраните файл.

3. Создайте директорию данных и установите владельца:

mkdir -p /data/db1
chown -R mongod:mongod /data/db1

4. Запустите mongod с конфигом:

mongod --config /etc/mongod.conf

Проверьте порт:

netstat -plntu

5. На configsvr1 подключитесь к mongo shell и инициируйте replica set:

ssh root@configsvr1
mongo --host configsvr1 --port 27017

rs.initiate(
  {
    _id: "replconfig01",
    configsvr: true,
    members: [
      { _id : 0, host : "configsvr1:27017" },
      { _id : 1, host : "configsvr2:27017" }
    ]
  }
)

Ожидаемый результат при успешной инициализации: { “ok” : 1 }

Проверка статуса:

rs.isMaster()
rs.status()

Примечание: в продакшене рекомендуется иметь нечетное количество голосующих членов (3,5 и т.п.) для корректной работы выборов primary.

Шаг 4 — Создание Shard Replica Sets

Мы разделим 4 сервера на два replica set: shardreplica01 (shardsvr1, shardsvr2) и shardreplica02 (shardsvr3, shardsvr4).

На каждом shard-узле выполните те же операции, что и с configsvr: остановка mongod, изменение /etc/mongod.conf, создание директории данных, запуск mongod.

Пример конфигурации для shardsvr1 (10.0.15.21):

storage:
  dbPath: /data/db1

net:
  bindIp: 10.0.15.21

replication:
  replSetName: "shardreplica01"

sharding:
  clusterRole: shardsvr

Создайте директорию и запустите сервис:

mkdir -p /data/db1
chown -R mongod:mongod /data/db1
mongod --config /etc/mongod.conf

Проверьте прослушиваемые порты:

netstat -plntu

На shardsvr1 подключитесь к mongo shell и инициализируйте replica set:

ssh root@shardsvr1
mongo --host shardsvr1 --port 27017

rs.initiate(
  {
    _id : "shardreplica01",
    members: [
      { _id : 0, host : "shardsvr1:27017" },
      { _id : 1, host : "shardsvr2:27017" }
    ]
  }
)

Повторите аналогично для shardsvr3/shardsvr4 с replSetName: “shardreplica02”.

После этого у вас будут два шард-реплика сета: shardreplica01 и shardreplica02.

Шаг 5 — Настройка mongos (Query Router)

mongos — это процесс маршрутизации, который не хранит данных. На сервере mongos выполните:

ssh root@mongos
systemctl stop mongod

mongos --configdb "replconfig01/configsvr1:27017,configsvr2:27017"

Опция –configdb указывает адреса config-server реплика сета. Для продакшена указывайте все члены config серверов и рекомендуйте минимум три для устойчивости.

Ожидаемый вывод:

Successfully connected to configsvr1:27017
Successfully connected to configsvr2:27017

mongos запущен и готов принимать запросы от приложений.

Шаг 6 — Добавление шардов в mongos

Откройте новое подключение к mongos и используйте mongo shell для добавления шардов в кластер:

ssh root@mongos
mongo --host mongos --port 27017

Добавьте шард-реплика сеты:

sh.addShard("shardreplica01/shardsvr1:27017")
sh.addShard("shardreplica01/shardsvr2:27017")

sh.addShard("shardreplica02/shardsvr3:27017")
sh.addShard("shardreplica02/shardsvr4:27017")

Проверьте статус шардирования:

sh.status()

В результате вы получите зарегистрированные два shard-replica set и один mongos.

Шаг 7 — Тестирование

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

ssh root@mongos
mongo --host mongos --port 27017

Включите шардирование для базы данных:

use lemp
sh.enableSharding("lemp")
sh.status()

Включение шардирования для коллекции (выбор shard key имеет критическое значение для распределения нагрузки):

sh.shardCollection("lemp.stack", {"name":1})
sh.status()

Пример вставки документа (вставлять нужно значения, содержащие shard key):

db.stack.save({
    "name": "LEMP Stack",
    "apps": ["Linux", "Nginx", "MySQL", "PHP"],
})

Проверьте, что данные появились на соответствующем replica set (подключившись к PRIMARY одного из shard-реплик):

ssh root@shardsvr2
mongo --host shardsvr2 --port 27017

show dbs
use lemp
db.stack.find()

Если база, коллекция и документы доступны — шардированный кластер функционирует.

Частые ошибки и устранение неисправностей

• mongos не подключается к configsvr: проверьте доступность портов, /etc/hosts и правильность строки –configdb.
• Реплика сет не инициализируется: проверьте bindIp, сеть, время, правильное имя replSetName в конфиге.
• Неправильный shard key приводит к неравномерному распределению: выберите ключ, который уникально и равномерно разделяет данные.
• Нехватка голосов в replica set: для надёжности используйте нечетное количество голосующих членов или добавьте арбитра (arbiter) с осторожностью.

Troubleshooting checklist:

• Проверить логи /var/log/mongodb/mongod.log на каждой ноде.
• Убедиться в синхронности системного времени (ntpd/chrony).
• Проверить firewall/iptables/selinux.

Безопасность и жёсткие настройки

Рекомендации по hardening:

• Включите аутентификацию и создайте пользователей с ролями (администратор, читатель, приложение).
• Включите шифрование каналов (TLS) между mongod и mongos и между узлами.
• Шифрование данных на диске (LVM, dm-crypt) в сочетании с управлением ключами.
• Настройте аудит (audit) для отслеживания административных действий.
• Ограничьте доступ через firewall только к доверенным IP.

Important: храните парольные файлы и ключи вне публичных хостов; используйте secrets management для продакшен-сред.

Когда шардирование не подходит

• Небольшие объемы данных, которые помещаются на один сервер — шардирование усложнит администрирование.
• Приложения с интенсивной транзакционной логикой, требующей строгой согласованности между многими документами — шардирование может повысить сложность.
• Если невозможно подобрать shard key, который обеспечивает равномерное распределение и поддерживает ваши типичные запросы.

Альтернативы:

• Вертикальное масштабирование (увеличение ресурсов одного сервера).
• Логическое разделение (delegation) данных по приложениям или tenant-идентификаторам без общей шардовой схемы.

Контрольные списки и обязанности по ролям

Операционная команда:

• Проверить сеть и доступность портов перед развёртыванием.
• Настроить NTP/chrony на всех нодах.
• Настроить мониторинг (включая использование MMS/Atlas или сторонних инструментов).

Разработчики/архитекторы:

• Выбрать корректный shard key по паттернам запросов.
• Тестировать запросы на шардированном окружении.

SRE/DevOps:

• Подготовить процедуру резервного копирования и восстановления (hot backup, filesystem snapshot).
• Тестировать процедуру failover и восстановление replica set.

Мини-методология развёртывания (короткий план)

1. Подготовить инфраструктуру и DNS/hosts.
2. Установить MongoDB на всех нодах.
3. Настроить config-server replica set и убедиться в работоспособности.
4. Настроить shard replica sets и убедиться в работоспособности.
5. Запустить mongos и присоединить шард-реплика сеты.
6. Включить шардирование для базы/коллекции и протестировать.
7. Включить безопасность (аутентификация, TLS) и мониторинг.

Критерии приёмки

• mongos успешно подключается ко всем config-server и отображает их в sh.status().
• Все shard replica set находятся в состоянии здоров (PRIMARY/SECONDARY) и синхронизированы.
• Данные корректно читаются и записываются через mongos, присутствуют на целевых shard-репликах.
• Выполнены базовые настройки безопасности: аутентификация, TLS (если требуется), firewall правилa.
• Наличие резервного плана и тестов восстановления.

Шаблон проверки (SOP) перед выводом в продакшен

• Проверить доступность всех узлов (ping, nc/port).
• Проверить логи mongod/mongos на ошибки.
• Проверить метрики задержек репликации.
• Выполнить нагрузочное тестирование с рабочими паттернами запросов.
• Проверить корректность shard key на реальных данных.

Однострочный глоссарий

• shard key: поле(а), по которым MongoDB распределяет документы между шардами.
• chunk: диапазон значений shard key, который может быть мигрирован между шардами.
• balancer: процесс, который перемещает чанки для выравнивания нагрузки.

Резюме

Мы рассмотрели полную процедуру развёртывания простого шардированного кластера MongoDB на CentOS 7: от подготовки хостов и установки MongoDB до инициализации config-server и shard replica set, запуска mongos и теста записи/чтения. Дополнительно приведены рекомендации по безопасности, список частых проблем и контрольные чек-листы для ролей.

Notes: при переходе в продакшен переработайте количество config-server до не менее трёх, используйте актуальную поддерживаемую версию MongoDB, настройте мониторинг и резервное копирование.

Ссылки и справочные материалы

• https://docs.mongodb.com/manual/tutorial/deploy-shard-cluster/
• http://stackoverflow.com/questions/11571273/in-mongo-what-is-the-difference-between-sharding-and-replication