Pull to refresh
46
0
Вячеслав Бирюков@Sov1et

User

Send message
Ну да, куда проще хуяк-хуяк и в продакшен.
Спаисбо за ответ.
Буду пристальней смотреть в сторону музи.
Скажите а сколько у вас сейчас клиентов которые реально пишут?
Странно, а можно поподробнее какие были именно проблемы?
ЗЫ. За MooseFS спасибо интреснная штука.
Я с вами согласен, что под каждую задачу нужно выбирать решение. Но простите, облако опенстек это не статистические выборки. И потерять контроллер не очень уж весело. Да и использовать брошенное САМИМ автором ПО, которое не разваиется, как-то выглядит странно.
Если это ваш проект/продукт, то посмотрите в сторону mongodb gridfs. Отлинчое решение, хороше скейлится, отличная конистентность данных и высокаая доступность достигается простыми средствами.
Нельзя. Сгорел сервер потеряли сторадж. Поставили два стораджа получили либо инконсистенси во времени либо сложную схему с залипанием при переключении.
Пару лет назад звучит как вечность. Новая верися GlusterFS рекомендуется RedHat www.redhat.com/summit/sessions/topics/glusterfs.html
Я не советую вам использовать MMM в продакшене. Могут быть сертёзные проблемы с консистентностью. Интересная статья про MMM от Baron'a Schwartz'а www.xaprb.com/blog/2011/05/04/whats-wrong-with-mmm/
Мммм… Пробывали запускать по крону, откатились назад, так как гибкость меньше. Вам не приходится при мейнтенсах отключать puppet? Было бы интересно как вы в таком случае поступаете?
Постоянно пропадают ноды при запуске mcollecive. То команда отработала на 15, то на 16… Глубоко не копал, но не приятно, что из коробки как-то криво. Хотя юзаю RabbitMQ. Может в нём проблема…
Я так понял вы используете mcollective. Распишите пожалуйста под какие задачи. И как боретесь с таймаутами. Спаисбо.
mysql_upgrade should be executed each time you upgrade MySQL. dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html JFYI
Такая проблема присутствует. Но любое существующее решение не решает этой проблемы. Как я и писал выше долгие запросы нужно либо убивать по таймауту при switch over'e либо ждать. + Местами помогает переписанный апликейшен.
Я бв не советовал mixed. Так как там до сих пор баги.
Что у вас именно разваливается?
Сделайте на активной ноде долгий селект/апдейт и переключитесь на другую ноду — разваливания кластера на МММ гарантированно.
Pacemaker это в первую очередь готовый стек для написания своих обвзязок. И конечно, в него нужно въехать. А писать кучу баш скриптов который при флапе сетки, проседания по спю и других не штатных ситуациях сделают вам сплит брейн с разсинхронном не только данных, а и клиентов, это действие на любителя.
А теперь представьте, что у вас таких машинок не 2, 3, 5,10 а 20, 30, 50.
Даже залогинился чтобы написать коммент.
1. Хранить в скрипте пароль для root от mysql это глупо (PCI DSS)
2. linux-ha мёрт — да здравствует pacemaker
3. Мониторить жизнь сервиса баш скриптом это худшее что можно придумать (опять же pacemaker)
Унификация решениё для построения HA это правильный выбор. И с помощью pacemaker это делать довольно просто. И я не вижу смысла использовать утилиты, у которых последние релизы были год назад.
Это всё конечно но же имхо.

Information

Rating
Does not participate
Registered
Activity