Некоторое время назад проект нашей компании по мониторингу серверов и сайтов перешел из категории «сделано для себя» в плоскость привлечения массовых пользователей. Этому частично способствовало получение проектом посевных инвестиций от ФРИИ и плюс, конечно же, наличие желания поделиться с миром нашей технологией, которую мы также используем для мониторинга своих серверов. Но, это не рекламный пост, а практический, поэтому о проекте потом.
Итак, с ростом нагрузки на базу данных, а наш сервис — это SaaS платформа по сбору метрик с серверов, количество запросов на запись в нашу базу данных (сейчас более 1000 серверов посылают порядка 20 своих метрик в БД каждые 4 минуты) начало приводить к перегрузке БД и нестабильной работе сервиса. Это зачастую происходило из-за превышения установленного максимального количества соединений к MySQL и большой нагрузки на сервер. К сожалению, все попытки оптимизации MySQL, увеличения серверных ресурсов и настройки параметров max_connections, query cache и т.д. не приводили к успеху.
Т.к. у нас нет отдельного человека, отвечающего за базы данных, а программисты и системные администраторы не могут каждый день тратить кучу времени на поддержание стабильности MySQL и реагировать на каждое падение, мы решили перейти на MariaDB Galera кластер с master-master репликацией и балансировкой нагрузки с помощью HaProxy. У нас до этого не было опыта внедрения бд кластера в production environment и поэтому пришлось наступать на все грабли самостоятельно.
К счастью, на Хабре нашлось много полезных статей на тему настройки Percona XtraDB, HaProxy и Zabbix для Percona, а также серия статей «Идеальный Кластер», которые нам очень помогли в начальной установке.
К сожалению, либо отсутствие опыта работы с кластерами, либо недостаток времени (тестирование проводилось по большей части ночью, когда количество пользователей в системе минимально) приводило к тому, что запись данных в кластер могла быть произведена только через основной Master node, а запись в режиме roundrobin или leastconn приводила к падению всей системы. Мы потратили много времени на устранение данной проблемы и уже были готовы отказаться от использования кластера, т.к. решили, что проблема заключается в недостатке навыков настройки кластера.
Тем не менее, дальнейшие поиски решения данной проблемы привели к открытию для себя программного комплекса мониторинга кластеров Galera Percona и MariaDB от компании SeveralNines — ClusterControl. И, хотя сам комплекс имеет достаточно дорогие платные пакеты услуг (от $1000 в год за каждый сервер), у SeveralNines есть и бесплатная версия и 14 дневный период для тестирования полной версии.
Скажу сразу, нам так же пришлось потратить несколько часов на установку данного решения, прежде чем мы узнали о наличии на сайте ClusterControl удобных генераторов конфигураций, которые позволяют полностью автоматизировать установку как частей кластера (нодов), так и самой системы мониторинга и даже автоматической настройки HaProxy.
Ниже мы приводим один из вариантов конфигурации, которую мы использовали для подготовки кластера MariaDB.
После генерации файла конфигурации, все что вам нужно — это скачать его на сервер, откуда будет осуществляться управление кластером, распаковать архив и запустить файл deploy.sh (инструкции по установке будут показаны после генерации скрипта установки).
При установке кластера важно учитывать следующее:
- Все серверы в кластере, включая сервер мониторинга, должны работать на одном типе операционной системы
- Установка кластера на CentOS 6 и 7 не приводила к положительному результату и постоянно требовала доработки, которая занимала несколько часов (возможно из-за недочетов в скрипте установки ClusterControl). Установка на Debian 6 прошла без проблем с первого раза, поэтому мы рекомендуем использовать именно Debian
- Вы также всегда можете открыть тикет в тех.поддержку Severalnines, которая бесплатно поможет с установкой
- Кластер должен иметь минимум 3 нода (сервера) + сервер мониторинга ClusterControl для исключения ситуаций типа split-brain.
После установки, вы сможете зайти в панель управления ClusterControl, через: ip-адрес-вашего-сервера/clustercontrol/
Далее, вам необходимо будет перейти в пункт «Manage >> Load Balancers» и установить HaProxy на одном из ваших кластер нодов. Мы рекомендуем делать это через панель управления, а не вручную — так вы будете уверены, что не забыли ничего добавить в файлы конфигурации кластера.
Отмечу, что благодаря данному решению (прим., мы не имеем никакого отношения к продукту Severalnines) мы смогли обеспечить бесперебойность работы нашего сервиса. Тем не менее, в ближайшее время мы будем проводить нагрузочное тестирование как front-end'a, так и БД, и обязательно поделимся результатами.
В заключение, мы надеемся что данная статья будет полезна тем, кто впервые столкнулся с необходимостью масштабирования базы данных своего приложения и поможет вам сохранить какое-то время и силы, потраченные на установку кластера. Тем временем, наша команда продолжает работу в 6м наборе ФРИИ и в ближайшее время мы также напишем статью об опыте миграции нашей инфраструктуры в облако Microsoft Azure, партнером которого мы теперь являемся.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (8)
kireevco
11.06.2015 19:27Спасибо, всегда хотелось увидеть Galera у кого-нибудь еще в продакшене.
При такой структуре инженерного ресурса люди часто смотрят в сторону NoSQL, в том числе MongoDB, оно хоть и не ACID, но имеет свои преимущества. В том числе практически беспроблемный шардинг, высокая (из-за модели доступа к памяти) а также массу дополнительных приятных плюшек (типа поиска), и прочего. Я не знаю какая у Вас структура данных, но судя по наличию большому количеству метрик мониторинга очень рекомендую также посмотреть на Elastic Search.
nazarpc
11.06.2015 20:40Имею противоположный опыт астрономического роста объема данных (из-за JSON) по сравнению с реляционной БД, катастрофически медленного map reduce и диких тормозов при вставке данных в коллекцию с несколькими миллионами элементов (на SSD должен заметить).
kireevco
11.06.2015 20:48MongoDB, конечно, не панацея. И просто «пихать» в нее все подряд тоже не выход. На одном проекте растянули все на 17 шардов по несколько ТБ… Вот там были тормоза, ведь данные просто клались как попало. Решили вопрос сменой структуры данных и переносом части вещей в kafka/elasticsearch.
Kostyanych
12.06.2015 11:44В MongoDB начиная с версии 3.0 добавлена поддержка WiredTiger Storage Engine который поддерживает компрессию данных и обещает от 7х до 10х скорость вставки.
Но как говорят сами разработчики пока, «тестируйте тестируйте тестируйте».
afiskon
15.06.2015 14:51Извиняюсь за глупый вопрос, но вы не рассматривали вариант перехода на Cassandra?
Melkij
Хочу пожелать удачи в соблюдении взаимоисключающих параграфов.
Сервис мониторинга — такая задача же элементарно партицируется горизонтально, данные по крайней мере разных аккаунтов не связаны между собой должны быть. Зачем вам мастер-мастер реплика?
aquanet Автор
Мы работаем над разработкой и улучшением самого сервиса и, в основном, front-end'a. С масштабируемостью MySQL у нас не очень большой опыт, но мы работаем над этим.
Останется ли в этом случае проблема слишком большого количества подключений к базе? Или при партиционировании тоже настраивается LB?
Melkij
При горизонтальном масштабировании (aka шардирование, погуглите, я опишу только самые азы) вы берёте вашу одну базу и делите на части (например, на две машины) по какому-то признаку. Поскольку аккаунты должны быть независимые друг от друга по самой идее предметной области — хороший выбор делить по аккаунтам.
На приложении выясняете, на каком сервере хранятся данные нужного пользователя, открываете соединение только к этой БД и работаете только с ней. Получили два полностью независимых писателя, т.е. удвоили производительность БД. Можете одного даже случайно уронить, эффект заметит только та часть клиентов, которая обслуживается этим сервером. Так же просто добавляется любое потребное число серверов по мере роста проекта.
Как хранить соответствие пользователя и сервера БД — самое гибкое решение — делаете нулевой сервер БД, который будет хранить таблицу соответствия user_id -> server. Таблицу можно легко кэшировать тем же memcache и проблем нет (но становится точкой отказа). На нём же вполне уместна всякая авторизация и регистрация юзеров.