Запуск балансировщика нагрузки и проверка MySQL Cluster

7. Запуск балансировщика нагрузки и тестирование

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

Хосты: loadb1.example.com / loadb2.example.com

Остановите ldirectord (если он запущен) и запустите heartbeat:

/etc/init.d/ldirectord stop
/etc/init.d/heartbeat start

Если ошибок нет, перезагрузите оба балансировщика:

Хосты: loadb1.example.com / loadb2.example.com

shutdown -r now

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

Хосты: loadb1.example.com / loadb2.example.com

ip addr sh eth0

Активный балансировщик должен содержать виртуальный IP-адрес (192.168.0.105). Пример вывода на активном узле:

| 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:3e:45:fc:f8 brd ff:ff:ff:ff:ff:ff inet 192.168.0.103/24 brd 192.168.0.255 scope global eth0 inet 192.168.0.105/24 brd 192.168.0.255 scope global secondary eth0 |

Резервный (hot-standby) узел должен не иметь виртуального IP в интерфейсе eth0. Пример вывода на резервном узле:

| 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:16:3e:16:c1:4e brd ff:ff:ff:ff:ff:ff inet 192.168.0.104/24 brd 192.168.0.255 scope global eth0 |

Проверьте статус ldirectord на обоих узлах:

Хосты: loadb1.example.com / loadb2.example.com

ldirectord ldirectord.cf status

Вывод на активном балансировщике:

| ldirectord for /etc/ha.d/ldirectord.cf is running with pid: 1603 |

Вывод на резервном (hot-standby):

| ldirectord is stopped for /etc/ha.d/ldirectord.cf |

Проверьте таблицу виртуальных серверов IPVS:

Хосты: loadb1.example.com / loadb2.example.com

ipvsadm -L -n

Вывод на активном балансировщике:

| IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.105:3306 wrr -> 192.168.0.101:3306 Route 1 0 0 -> 192.168.0.102:3306 Route 1 0 0 |

Вывод на резервном (hot-standby):

| IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn |

Проверьте LVSSyncDaemonSwap (синхронизация состояния IPVS):

Хосты: loadb1.example.com / loadb2.example.com

/etc/ha.d/resource.d/LVSSyncDaemonSwap master status

Вывод на активном балансировщике:

| master running (ipvs_syncmaster pid: 1766) |

Вывод на резервном:

| master stopped (ipvs_syncbackup pid: 1440) |

Если тесты прошли успешно, попробуйте подключиться к MySQL с другого сервера в той же сети (192.168.0.x) по виртуальному IP 192.168.0.105:

mysql -h 192.168.0.105 -u ldirector -p

Важно: клиент MySQL должен быть версии не ниже 4.1; более старые клиенты несовместимы с MySQL 5.

Вы также можете выключить один из узлов MySQL кластера для тестирования отказоустойчивости: доступ к базе должен сохраняться.

Важно: выполняйте тесты в изолированной приватной сети. Открытые сервисы кластерного управления — риск безопасности.

8. Примечания и рекомендации по MySQL Cluster

Есть несколько важных моментов при эксплуатации MySQL Cluster.

Вся активная база хранится в оперативной памяти (RAM). Это значит, что требуется достаточно ОЗУ на каждом ноде. Формула примерного расчёта потребной памяти на узел:

(Размер_Базы × Количество_Копий × 1.1) / Количество_Дейта_Нод

Пример: если база 1 ГБ и реплик по 2, то при коэффициенте 1.1 нужно ~1.1 ГБ ОЗУ на каждый узел данных.

Узел управления кластером (management node) слушает порт 1186 и по умолчанию допускает соединения отовсюду. Это небезопасно — запускать в приватной/изолированной сети или ограничить доступ брандмауэром.

Рекомендуемые ресурсы:

MySQL Cluster FAQ: http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-faq.html
MySQL Cluster документация: http://dev.mysql.com/doc/refman/5.0/en/ndbcluster.html

Практические дополнения (когда это полезно)

Когда схема может не сработать

Неправильно настроенные сетевые маршруты или VLAN могут помешать виртуальному IP переключиться.
Несовместимость версий клиента MySQL и сервера (см. требование клиента ≥ 4.1).
Недостаток RAM на нодах данных приведёт к ошибкам производительности и сбоям.

Альтернативные подходы

Использовать аппаратные балансировщики или виртуальные L4/L7 (например, HAProxy, LVS на отдельном оборудовании).
Применить репликацию MySQL (master-slave/GTID) вместо in-memory NDB Cluster, если память — узкое место.

Мини-методология проверки перед вводом в эксплуатацию

Подготовить изолированную тестовую сеть.
Запустить оба балансировщика и убедиться в наличии виртуального IP только на активном узле.
Проверить состояние ipvsadm, ldirectord и LVSSyncDaemonSwap.
Тестовое подключение к виртуальному IP и переключение узлов MySQL.
Логи и мониторинг: собрать и проанализировать ошибки.

Роль‑ориентированные контрольные списки

Оператор сети:

проверить привязку виртуального IP на eth0;
проверить таблицу ipvsadm;
убедиться, что heartbeat работает.

Системный администратор:

контролировать запущенные процессы ldirectord и LVSSyncDaemonSwap;
убедиться в корректности конфигураций /etc/ha.d/* и ldirectord.cf.

DBA:

выполнить подключение к MySQL через виртуальный IP;
проверить доступность базы после выключения/включения нод.

Критерии приёмки (Test cases / acceptance)

Подключение к MySQL по виртуальному IP успешно с корректными учётными данными.
При остановке активного балансировщика виртуальный IP появляется на резервном в пределах допустимого времени переключения.
Таблица ipvsadm на активном показывает backend-узлы и веса.
LVSSyncDaemonSync синхронизирует состояние (master running / backup stopped).

План отката и простая инструкция (SOP)

Если после изменения конфигурации ldirectord не стартует — вернуть резервную конфигурацию из файла конфигурации или бэкапа.
Перезапустить heartbeat и проверить состояние демонов.
При проблемах с IPVS временно снять виртуальный IP и вручную назначить на работоспособный узел для восстановления обслуживания.
Оповестить команду DBA и при необходимости переключить приложение на прямое подключение к одному из MySQL-узлов.

Безопасность и соответствие

Закрыть порт 1186 на firewall/ACL, ограничив доступ только из доверенной сети.
Шифровать трафик MySQL (TLS) при пересылке между приложениями и балансировщиком, если кластер пересекает менее доверенные сети.

Краткий глоссарий (1 строка)

Virtual IP (VIP): общий IP, который перемещается между балансировщиками для предоставления единой точки доступа.
ldirectord: демон из проекта Ultra Monkey / LVS для управления балансировкой.
ipvsadm: утилита для просмотра и управления таблицей IPVS.
LVSSyncDaemonSwap: компонент, синхронизирующий состояние таблицы IPVS между узлами.

Ссылки

MySQL: http://www.mysql.com/

MySQL Cluster документация: http://dev.mysql.com/doc/refman/5.0/en/ndbcluster.html

MySQL Cluster FAQ: http://dev.mysql.com/doc/refman/5.0/en/mysql-cluster-faq.html

Ultra Monkey: http://www.ultramonkey.org/

The High-Availability Linux Project: http://www.linux-ha.org/

Итог

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