forum.lissyara.su

LMik писал(а): Ставится два сервера, на них nginx+apache+php-fastcgi или просто nginx-php-fastcgi - как удобнее.
Сервера имеют по две сетевухи, вторыми сетевухами они соеденины серой адресацией.
mysql реплицируется в master-mastrer на обоих серверах.
Оба сервероа будет играть роль "себя как Frontend, второй как бэкап и бэкенд".
Пакет /usr/ports/net/wackamole занимается распределением обращения к адресам серверов и отказоустойчивостью.
Так на базе двух серверов получается кластер с 4 девятками точно + распределение нагрузки.
ЗЫ а DRBD на бсд работает кстати?

вариант законный, но:

1) репликация мультимастер вызывает достаточно большой оверхеад на синхронизациях записи.
2) исходя из идеологии wackamole в один момент времени только одна нода из данного кластера может обладать виртуальным айпишником (рабочим, не серым), т.е. только одна из нод кластера зайдействована в рабочем режиме. Вопрос: о каком распределении нагрузки речь?
3) что вы будете делать со своим мульти-мастер репликацией при росте нагрузки на базу данных?

drbd, на фрее, увы, не работает ;/
кстати по сути, описанная вами связка, по принципу очень похожа на drbd+heartbeat, за исключеним репликации мускиля.

1. Во время синхронизации - лок. В это время сервак ложиться. Новый ессно работает но данные не имеют актуальной свежести.
2. Аналогично
3. Дублирование критично важных узлов - одна из мер достижения того чего вы хотите.

Ваши 4 девятки достижимы только в случае построения на основе общего хранилища данных + снапшоты и бэкап.
Что мы в этом случае получаем:
1. Не надо в общем случае синхронизитровать ни базы ни контент.. он общий для 2-х серверов..отваливается один - второй работает.
2. Всегда актуальный снапшот..если вдруг косяк пошел.
3. Бэкап еще никому не вредил
4. Централизованное управление и масштабирование системы !

1. Чего? Да вон ставишь rsync скрипт в крон раз в минуту, он при запуске проверяет еть ли лок файл, есил нету создает лок файл и синхится по завершении удаляет лок - все работает везде.
2. Какие локи при реплекации? Все работает.
3. Ну так сервера дублируют друг друга во всем, можно мускулы на ndb класетрицазии построить, ещё круче получится


Это в какое место общее хранилище вам надежности добавит? вот ёпнецо оно и нету связи никакой...
Снапшот это дело конкретно разработчика/клиента
Бэкапы это отдельная тема и не имеет никокого отношение к отказоустойчивости.
Маштабируй хоть до милиона хостов, в чем проблема то?

Мы схему тут ищем для бюджетного варианта максиум на 2 сервера. А ты кластер на 30 килобаксов нарисовал если не больше.

paix писал(а):
вариант законный, но:

1) репликация мультимастер вызывает достаточно большой оверхеад на синхронизациях записи.
2) исходя из идеологии wackamole в один момент времени только одна нода из данного кластера может обладать виртуальным айпишником (рабочим, не серым), т.е. только одна из нод кластера зайдействована в рабочем режиме. Вопрос: о каком распределении нагрузки речь?
3) что вы будете делать со своим мульти-мастер репликацией при росте нагрузки на базу данных?

drbd, на фрее, увы, не работает ;/
кстати по сути, описанная вами связка, по принципу очень похожа на drbd+heartbeat, за исключеним репликации мускиля.

1. Можно NDB кластер попробовать, хотя сам не юзал, но хочу - никак не соберусь построить виртуальный для начала. Да и не будет оверхеда если апдейтов не будет много ползать.
2. А это и нужно, в днс пишется один адрес, по внутреннему интерфейсу будут работать мускул репликация и nginx бэкенд на второй сервер.
3. См п.1

Ещё возможен вариант с раундробин ДНС на оба внешних адреса а вакамолу заставить держать оба ипа на обоих серверах, чтобы в случае падения она ип второго сервака себе схватывала. Онаж вроде умеет это... надо доку пофтыкать.

С ndb тоже не очень гладко получается, т.к надо управленческий сервер держать где то включеным на случаи падения и следующего подъема нод.

LMik писал(а):Ещё возможен вариант с раундробин ДНС на оба внешних адреса а вакамолу заставить держать оба ипа на обоих серверах, чтобы в случае падения она ип второго сервака себе схватывала. Онаж вроде умеет это... надо доку пофтыкать.

Ну да, вот собственно цитата с доки.

This allows you to run a service using multiple DNS RR records without the worry of one of the machines crashing -- if the machine crashes, the virtual IP addresses it was responsible for will be managed by the remaining machines in the cluster.

LMik писал(а):

:

Балин.. ну во первых хранилище на 2-х массивах.. то что они одновременно накроются - это врядли
Во вторых... ну не совместимо слово надежно и бюджетно )))
Можно в вашем случае говорить о адекватном стоимости решения времени простоя
В третьих то шо я нарисовал в 30К не влезет
Давай тогда не будем говорить о 4-х девятках в твоем случае, любой инженер который проектирует системы хранения подразумевающих
надежность в твои 4-е девятки заложит именно не менее 20-30 косарей минимум(хотя я не верю в такие цифры

Fastman писал(а):

LMik писал(а):

:

Балин.. ну во первых хранилище на 2-х массивах.. то что они одновременно накроются - это врядли
Во вторых... ну не совместимо слово надежно и бюджетно )))
Можно в вашем случае говорить о адекватном стоимости решения времени простоя
В третьих то шо я нарисовал в 30К не влезет
Давай тогда не будем говорить о 4-х девятках в твоем случае, любой инженер который проектирует системы хранения подразумевающих
надежность в твои 4-е девятки заложит именно не менее 20-30 косарей минимум(хотя я не верю в такие цифры

Ну так вот мы тут и извращаемся чтобы надежно и бюджетно.

А че? все по правилам, все друг друга заменяет в обих серверах. Если в них ещё по зеркалу хардварному то о 4 девятках 100% можно уже говорить.

Собственно задача то не получить эти девятки в формулах, а вот на практике ИМХО реально сделать и из двух серверов.

LMik писал(а):

paix писал(а): 2) исходя из идеологии wackamole в один момент времени только одна нода из данного кластера может обладать виртуальным айпишником (рабочим, не серым), т.е. только одна из нод кластера зайдействована в рабочем режиме. Вопрос: о каком распределении нагрузки речь?
3) что вы будете делать со своим мульти-мастер репликацией при росте нагрузки на базу данных?

1. Можно NDB кластер попробовать, хотя сам не юзал, но хочу - никак не соберусь построить виртуальный для начала. Да и не будет оверхеда если апдейтов не будет много ползать.
2. А это и нужно, в днс пишется один адрес, по внутреннему интерфейсу будут работать мускул репликация и nginx бэкенд на второй сервер.
3. См п.1

2. хех, это вы уже не high-aviability, а fault-tolerance системы штоли пытаетесь строить....т.е. системы предполагающие высокодоступность и автоматическое распределение нагрузки. А это ведь совсем не дешевые системы, и на порядок более сложные.И на ограниченном бюджете - это головная боль. Я бы этого не советовал делать товарищам, желающим построить HA-системы. Для начала неплохо бы построить хотябы HA кластер.
Одна из самых веских причин, клиентов обслуживают 2 сервера, если один выпадает - второй с нагрузкой не справляется. В данном случае про мультимастер мускиля я вообще молчу

1,3. а ну ка, по подробней про nbd, afaik он сильно под линукс заточен, а фревый вариант в недописанном состоянии находится, плюс ко всему я так полагаю вы собрались штоли его на отдельную машину вынести? и в чем сдесь заключается маштабирование ?

paix писал(а):
2. хех, это вы уже не high-aviability, а fault-tolerance системы штоли пытаетесь строить....т.е. системы предполагающие высокодоступность и автоматическое распределение нагрузки. А это ведь совсем не дешевые системы, и на порядок более сложные.И на ограниченном бюджете - это головная боль. Я бы этого не советовал делать товарищам, желающим построить HA-системы. Для начала неплохо бы построить хотябы HA кластер.
Одна из самых веских причин, клиентов обслуживают 2 сервера, если один выпадает - второй с нагрузкой не справляется. В данном случае про мультимастер мускиля я вообще молчу

1,3. а ну ка, по подробней про nbd, afaik он сильно под линукс заточен, а фревый вариант в недописанном состоянии находится, плюс ко всему я так полагаю вы собрались штоли его на отдельную машину вынести? и в чем сдесь заключается маштабирование ?

1,3. Ну это я предположение высказал, да и откуда инфа что его не доточили под бсд, да и собственно код на C он везде код на C. Там точить особо нечего. Я говорю - я сам ещё не пробовал, но очень хочу протестить, и возможно устроить продакшен в итоге.

2. Ну это как последствие можно сделать, на самом деле можно и не балансировать нагрузку получится просто HA. Для этого надо делать без раунд робина и вакамолу оставить просто следить за падением основного сервера. А на бэк сервере реплицировать базу и файлы.

Все же репликация-то дело для HA лучше было бы ИМХО.

Кстати про дешевезну и т.п прошу заметить - у нас вся страна на PC роутерах вместо цисок, и т.п Это к слову о циферках 30+ килобаксах - и все у людей работает

LMik писал(а):Кстати про дешевезну и т.п прошу заметить - у нас вся страна на PC роутерах вместо цисок, и т.п Это к слову о циферках 30+ килобаксах - и все у людей работает

Да никто не спорит то
Просто у нас в странах СНГ не понимают слов "стоимость владения" и "сопровождение и поддержка проекта".
И сидим мы не на цисках только от нашего желания сделать вот прямо счас хорошо и подешевле - а потом все равно нужно будет переделывать
Я не против локального применения таких решений. Просто нужно немного в будущее смотреть

Fastman писал(а):

LMik писал(а):Кстати про дешевезну и т.п прошу заметить - у нас вся страна на PC роутерах вместо цисок, и т.п Это к слову о циферках 30+ килобаксах - и все у людей работает

Да никто не спорит то
Просто у нас в странах СНГ не понимают слов "стоимость владения" и "сопровождение и поддержка проекта".
И сидим мы не на цисках только от нашего желания сделать вот прямо счас хорошо и подешевле - а потом все равно нужно будет переделывать
Я не против локального применения таких решений. Просто нужно немного в будущее смотреть

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

На самом деле я поддерживаю твое старание придумать что нить в этом роде.
Хотя бы для своего развития - это мегаполезно
Нужно просто всегда вносить долю здоровой критики чтобы небо розовым не казалось

Fastman писал(а):На самом деле я поддерживаю твое старание придумать что нить в этом роде.
Хотя бы для своего развития - это мегаполезно
Нужно просто всегда вносить долю здоровой критики чтобы небо розовым не казалось

Теперь ждем чтобы человек построил всю эту хрень
Очень интересная система получается.

Вот только с мускулем надо определиться.

топик мастер наверное имел ввиду какойто бедного заказчика который тупо хотел бекап
а вы тут начинаете решение на 30к советовать)))

paradox писал(а):топик мастер наверное имел ввиду какойто бедного заказчика который тупо хотел бекап
а вы тут начинаете решение на 30к советовать)))

Не, я решение советую на таверах за 10к А ведь реально работать будет лол.

да не.
судя по вопросам в аське от одного гражданина, примерно в то же время - я наверно даже знаю заказчика....
=======
просто хостер у чела неадекват полный - на полдня положил всё - сказав регламентные работы... без предупреждения.
и не первый раз уже.

порнухо мастеры делают свои решение дешевле чем даже ты предлагаешь
а челу в сотню раз меньше нужно будет (нагрузка)

lissyara писал(а):да не.
судя по вопросам в аське от одного гражданина, примерно в то же время - я наверно даже знаю заказчика....
=======
просто хостер у чела неадекват полный - на полдня положил всё - сказав регламентные работы... без предупреждения.
и не первый раз уже.

тогда как я говоил
два разнесенных сервака
а в DNS две запили алияс
токо это спасет в таких случаях

это если на хосте стат инфо
а не форум какой то

живой сайтик... на мусе.
однако - как сказали - инфа за последние минут несколько не так уж и важна.
т.е. время перключения - единицы минут с потерей инфы - так что если это тот человек - не усложняйте всё...
=======
лучше расскажите как будете в нормальный режим работы всю связку выводить, после аврала....

Блин, да никто ничего не усложняет

Уже давно от частного случая ушли и флудим тут по теме в общем...

А про днс - шляпа будет, два адреса они днсами будут по очереди отдаваться и не у всех с первой попытке будет попадать на рабочий сервер.

А в нормальный режим теоретически должно само войти.

Муся как врубится сразу полезет к соседу по репликации за изменениями.
rsync полезет смотреть че с файлами произошло (ну или че то другое полезет)

>LMik
аналогия с AOL
так что я думаю нормально