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

User

Send message
Посмотрите в сторону Pacemaker.
ЗАЧЕМ?!?! Скажите зачем?!?! Делать make install и тд. Когда вот тут есть пакеты под разные системы!
tsung.erlang-projects.org/dist/
Ужас. Не делай так. Лучше почитайте про bacula. Один раз разобраться и счастья на всю жизь.
И добавить геморой с DRBD. Имхо лучше хорошая железка.
logrotate можно кастомно дёргать по крону со своим конфигом хоть кажую минуту.
По поводу демона для кеша: если у вас девелоперами можно договариться — то самымое простое это чтобы приложение на бэкенде само дёргало урлу для инвалидации кеша. А вообще, да, мемкеш наше всё.
Сущесвет ли подобное для более «часых» файловых систем (XFS, ext3/4)?
Спасибо за интересный инструмент — для тестов репликаций в самый раз.
А не лучше ли делать reload apache? Так как можете обламать кого-то с комитом.
Спасибо не знал, что поддерживается только одна версия и по TCP. А что в случае с другими гипервизорами. К примеру KVM. На какой верии предпочтительно ехать?
Какую версию NFS рекомендуете использовать для этих целей?
Меня всегда интересует пожаробезопасность таких строений.
Посмотрите в сторону Pacemaker если вам нужен high availability. Документации не много, но система очень сильная. А для построения облака сейчас модно смотереть в сторону openstack
Интересная идея. Нада будет погонять её на тестовом стенде.
с DRBD мы получаеи уверенность в том, что данные на обоих машинах консинстентны (использование типа С), однако мы получаем не Hot Spare. Т.к. нужно время на старт сервиса Mysql, который, при таком старте, будет проверять таблицы базы.
Решение с мастер-мастер репликацией обладает своими недостатками, кроме вероятности потерять часть транзацкций, к примеру, — не правильно разогретый кэш.
Как я писал нужно дублировать соединения, выносить их отдельно. Также как вариант — добавить третью ноду, которая будет находиться в состоянии standby и будет участвовать только для кворума. К примеру, в роли такой ноды, может вуступать роутер либо любой другой сервер в вашей сети.
Использовать STONITH в двухнодном кластере при пропаже линков — бесмысленно. Ноды просто убъют друг друга. Мы получим, так называемый deathmatch,: одна убивает другую — другая перезагружается и убивает первую и тд. Т.к. не понятно какая из нод «правильная» и нету кворума.
В свою очердь STONITH нужен для убийства ноды с зависшим ресурсом. Однако тут много тонкостей с таймаутами мониторинга и остановки ресурсов. Можно убить ноду, которая просто замешкалась с отмонтирование файловой системы, ожидая, когда её просто освободит процесс. Это вообще отдельная большая тема.
Не совсем понял схему подключения. Но ваше решение исключает крос-кабель, не так ли? На мой взгляд, в кластере 1+1, крос кабель очень важен и прост. А в таких системах, чем проще сделал — тем легче и быстрее чинить ;)

Information

Rating
Does not participate
Registered
Activity