Тестируем кластер MySQL

Представлены результаты тестирования кластерного решения MySQL с целью масштабирования продукта "Битрикс-управление сайтом" в части базы данных

О себе Основная область интересов - Oracle, включая настройку производительности и кластерные решения (Real Application Cluster)
Идея Протестировать технологию MySQL Cluster с ПО «Битриксом: Управление сайтом» на предмет масштабируемости базы данных и, в частности, сравнить производительность MySQL с использованием стандартного (myISAM/InnoDB) и кластерного (NDBCluster) методов хранения данных на производительность типичных генерируемых продуктом запросов к БД.
Тестовое оборудование Была выбрана конфигурация из 2-х доспупных, недорогих серверов - Intel Core Duo 2,2GHz, 4GB RAM, 140GB SATA HDD, 2x1GB NIC + выделенная Gigabit Ethernet сеть с использованием отдельного коммутатора 3com 2808 – с избытком обеспечивала минимально необходимые требования. Сразу отмечу, что используемая тестовая конфигурация далека от оптимальной: 6 серверов для обеспечения полной отказоустойчивости, RAID10 из 4 x SCSI + 16GB RAM на каждом data node – но, во-первых, это уже мало похоже на недорогую тестовую конфигурацию и , во-вторых, поскольку основная нагрузка ложится на data nodes, для оценки производительности достаточно было протестировать сервера данных и кластерную систему хранения.
На этих 2-х серверах были расположены все компоненты MySQL Cluster: 2 data nodes, 2 mysql server и один management server. Используемое ПО: Red Hat Enterprise Linux 4 (2.6.9-55.ELsmp), MySQL 5.0.45 (последний рабочий релиз).


Нестандартные параметры конфигурации серверов MySQL Cluster (рекомендованные в документации MySQL для улучшения производительности):

Для сравнения на одном из серверов MySQL была созданы БД с некластерным размещением (myISAM и InnoDB БД) без дополнительной настройки.
Выявленные ограничения Существенные (но не единственные, см. Полное описание в документации MySQL) ограничения кластерной конфигурации, которые влияют на БД «Битрикс»:
• Вся БД должна быть расположена в ОЗУ – для конфигурации из 2-х нодов – целиком на каждом из нодов. Это концептуальная особенность реализации кластерной технологии MySQL. При этом под информацию, хранимую на диске каждым из нодов, рекомендуется резервировать 12-кратный размер БД (в тестовом случае при размере БД ~350MB, кластерные логи на диске занимали более 2GB). В версии 5.1 разработчики обещают допустить размещение части табличных данных на диске, однако, на производительности кластера (в частности, скорости доступа к нелокально хранимым данным) это может сказаться не лучшим образом, imho.
• Таблицы могут иметь только фиксированную длину строки, т.е. при хранении небольших данных в VARCHAR столбцах, место в памяти и на диске будет выделяться по-максимому, что значительно «раздувает» БД. В тестовом случае, например, БД размером 80MB в myISAM, занимала 350 MB в ОЗУ, при использовании NDBCluster.
• Строка таблицы не должна превышать 8KB. Серьёзное ограничение, решить можно храня табличные данные в BLOB. Для БД «Битрикс» это ограничение коснулось только таблицы B_USER.
• В таблице не должно быть более 128 столбцов – таблицы B_STAT_DAY и B_STAT_DAY_SITE потребовалось модифицировать.
Результаты тестов производительности

)*Первые суммируемые цифры –половинки скрипта на 1-м и 2-й нодах, последние - время выполнение объединённого скрипта на myISAM и InnoDB БД.
Тесты проводились с использованием трассировочного модуля Spider, разработанного и любезно предоставленного Максимом Смирновым.
Резюме В MySQL Cluster используется концепция т.н. Shared-nothing cluster, которая, по мнению авторов, избавлена от присущих прочим кластерным решениям слабых мест (shared disk storage для Oracle RAC, например). Однако, появляются новые серьёзные требования: большая память и быстрый интерконнект.
По результатам представленного экспресс-тестирования, трудно рекомендовать технологию к использованию для обеспечения масштабируемости, ввиду драматического снижения производительности при реальных нагрузках. Хотя разработчики честно упоминают в документации, что «response time – не самое главное качество для реально масштабируемого кластера», столь значительное падение производительности трудно признать допустимым. Возможно, что при использовании для хранения данных SCSI RAID, Scalable Coherent Interface (SCI) в качестве кластерного интерконнекта и MySQL Cluster Carrier Grade Solution (платное ПО) можно достичь почти линейной масштабируемости, как описано в MySQL Cluster High Scalability DBT2 Benchmarks on next-generation Intel Xeon processors, но это достаточно дорогие тесты.
А вот для обеспечения отказоустойчивости небольших БД с невысокими требованиями по производительности этот кластер вполне можно попробовать использовать. «Data node failover» обеспечивается кластерным ПО и происходит автоматически: действительно быстро и прозрачно для пользователя. Для организации «MySQL server connection failover» - универсальный встроенный механизм отсутствует - разработчики предлагают использовать либо официальный MySQL JDBC, Connector/J (обеспечивающий round-robin failover and load-balancing), либо round-robin DNS, либо Hardware load balancing solution(Cisco, Big-IP), либо Software load balancing solution(Linux virtual servers, Linux-HA,…) – выбор есть.
Надеюсь, что разработка MySQL Cluster будет успешно продолжена и в будущий редакциях MySQL мы увидим сравнимое по производительности с традиционными для MySQL (myISAM, InnoDB) кластерное решение для использования на доступном оборудовании.