Round robin , как им пользоваться???

Round robin это когда в ДНС для сайта указывается несколько A записей.

Или может указываться несколько NS записей.

Поисковики выдают кучу ссылок по строке «Round robin»

Смешались в кучу кони-люди. :)

Round robin - это алгоритм распределения запросов, по очереди отдается из обоймы ресурс.

Для физ.линков например используется round robin в виде 1 пакет в 1 линк, 2-й во второй, 3-й в 1 и т.д. Для DNS соответственно в зоне прописывается несколько А-записей для имени, разные айпи разумеется. Клиенту на запрос резовлвинга имени выдаются айпи по очереди.

Повышения надежности нет, производительности есть, потому как используются разные ресурсы почти одновременно.

Догадываюсь, что вас интересует кластеризация на базе rrDNS+failover(когда упавшие ноды кластера отключаются из обработки).

Вы лучше опишите задачу, Вам дадут совет как сделать лучше/производительнее/надежнее/дешевле.

yesRuslik,

Задача - пусть есть пока один сервер на нем php+apach+mysql+nginx сайт. (еще всякий софт ffmpeg, sphinx и все в таком духе все не помню и явно еще появится что то)

Думаю что лучше заняться разносом статики, баз, почт и всего по разным или сделать что-то подобное... То есть задача не бог весть какая, я просто хочу разобраться что будет лучше в моем случае.

Вроде как привлекательно, если я правильно понял - берешь 2,3, ..., X серверов и все они дублируют друг друга и похоже требования к ресурсом каждого отдельно не бог весть какие. По крайней мере я пока так думаю, но вот что тут лучше аж можно мозги поломать.

Еще подробности - у меня все за одним каналом т.е. удаленно что то выносить не хочу пока да не буду думаю, а как внутри ресурсы оптимизировать лучше интересно и вообще возможно так сделать, как я об этом думаю и синхронизировать их?

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

Почему нет? Ведь их много этих кластеров? Один отвалился еще 2-3 или сколько то осталось

Задача -с делать все это производительным, не сложно расширяемым (т.е. наращивать место и мощьность) и стабильным в работе... В случае взломов, поломок еще чего то работа продолжалась и было время все исправить без кипиша.

Если 1 сервер справляется с нагрузкой, то выносить что либо не имеет смысла. Разве что имеет смысл CDN, чтобы ближе к пользователю отдавались статика.

Если 1 сервер справляется, но хочется надежности - бюджетный вариант - это 2-й сервер с внутренним линком к первому для синхронизации, внутри раздел с DRBD, на котором живет образ виртуальной машины XEN, при падении одной машины образ мигрирует на вторую. Очень удобно выполнять профилактические работы без простоя.

Если 1 сервер не справляется - разносим нагрузку на разные машины. Синхронизировать можно через тот же DRBD. Если контент простой - можно rsync пускать для синхронизации. Или как вариант использовать общую дисковую полку и кластерную фс поверх, но это не для всех задач подойдет.

Нгинкс + бекенды неплохое решение, но что делать когда падает фронт?.

Сделать два фронта по аналогии со вторым вариантом, что вы предложили?

Вон как ее звать то эту синхронизацию...

Брр, уже намного понятнее стало. Пока основной "враг" номер один это ffmpeg, кодирование ой как любит ресурсы и в общем-то он... как сказать мешается что ли, не будь его я бы может и пока даже голову не ломал. А вот он пока самый вредный. Причем не постоянно т.е. не 24/7 это идет, однако проблемы создать может.

А потом mysql, потом скрипты, статика... рано или поздно они тоже дадут о себе знать. Правда у меня пока каша в голове из всех этих вариантов, правда не готов нормально ответить :)

Вот выходит что вы предложили два последних варианта в общем-то одно и то же, т.е. через DRBD синхронизируем и тут и повышение мощьности и так же надежности... правильно?

Одно только покоя не дает, как быть с HDD т.е. это же выходит все будет дублироваться и статика тоже? А это ой сколько HDD :(

И еще интересно, при такой синхронизации через DRBD, как быть с дампами mysql например? Тоже делать репликацию отдельно от всех этих виртуальных машин?

Для кодирования делают специальные кодировочные фермы. По-моему даже готовые скрипты типа AVS имеют платную опцию для построения этих ферм.

Ради одного кодирования видео городить кластеры неразумно.

Или KVS - полностью автоматизированная система для обработки и показа видео контента

madoff, netwind,

Спасибо, правда того как быть с остальным это все равно не решает :)

Особо интересно, если будет несколько машин с DRBD, как в таком случае лучше поступить с HDD - вроде как вынести статику будет разумно и как быть с mysql в таком случае? Пока я хотел сделать репликацию на отдельном сервере, а чуть позже и сам mysql вынести на отдельный сервер...

Но тогда уже все опять сводится к распределению - mysql отдельно, статика отдельно, кодировать видео отдельно... А DRBD использовать как yesRuslik писал для обслуживания сервера, чтобы не отключать его...

Или я не правильно понимаю как этот кластер должен работать? Объъясните плз, а то опять в итоге то же самое выходит по моему

Segey, остальное нужно просто спроектировать и настроить.

если вы гуглите и ничего не понимаете, значит и объяснения на форуме вам будут давать больше вопросов чем ответов.

Видеосайту обычно не нужна репликация базы. Им нужно забить дешевые гигабитные линки на всех серверах. Для этого достаточно копировать файлы видео на несколько раздающих серверов.

netwind,

Охота хотя бы в общем разобраться как это работает, а то въехать в это быстро боюсь не выйдет я вообще месяца два как администрированием занимаюсь, поэтому вопросов просто МНОГО, особенно что касается таких сложных систем. Опыта мало так и кластеры вообще для меня открытие пару часовой давности