вопрос по Round-Robin DNS

1) синхронизацию какую ? rr ? что-ли ?

2) помима днса есть сервесы http mysql

3) Надо собрать всё в кучу а потом думать за dns-rr

1) синхронизация данных на дисках, которые редко-изменяются. (данные с 20гбайт скоро вырастут до 40тбайт с большим объемом единичного файла (до 5гб). система расположена в одном ДЦ, соединена мною через оптический коммутатор и (!!) ДАННЫЕ СКОРО НАЧНУТ ИЗМЕНЯТЬСЯ ОЧЕНЬ ЧАСТО).

2) да, мускуль - живет отдельно на отдельной машине, только httpd.

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

и самое главное: сейчас - это один ресурс с одной БД и данными. в менеджменте нет проблем.

скоро - это будет 16 проектов с разной нагрузкой, разными актуальными данными. когда единиц обслуживания много - важно еще и учесть - как эти единицы обслуживать малыми человеко-часами. например панели управления хостингами: для 2-5 сайтов - панель не нужна, для 20+ сайтов - уже тяжело без панели.

---------- Добавлено в 19:29 ---------- Предыдущее сообщение было в 19:27 ----------

попробую поставить вопрос иначе:

дайте почитать литературу как обеспечить высокую доступность и высокую надежность 16 шт проектов? у меня мыслей много, но они все пока не соединяются в единое решение.

возможно есть смысл смотреть в сторону hadoop, в нем и репликация реализована нормально, и расширяемость хорошая.

С помощью Round-Robin DNS выхотите распределить нагрузку для отдачи статических файлов или для динамических PHP ?

Не понял сути этой фразы «когда не один сайт заведен в ррднс-домен, а скажем 300сайтов»

Добрый

Нагрузочное тестирование проводил? Один из серверов для теста выключал?

От кластерной файловой системы до примитивного rsync.

Правильно чуешь.

Если бюджет разумно неограничен, то рекомендую потратить его часть на платную консультацию. Так как есть масса нюансов, которые способны попортить кровь.

А пока рекомендую клиенту дать почитать ссылку: http://dedic.ru/highload

Поможет ему избежать ошибок

собсно, никак. пока mysql живет на отдельной машине - это единая точка сбоя.

раз уж проекты реально отдельные, то перенеси 8 проектов на одну , 8 проектов на другую на глазок подбирая нагрузку.

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

Ай да молодца!!!! :D :D Вот сразу же видно наш человек :D Сказали .... сделал... что уж там.

+100500

Попробую натолкнуть, комьюнити рассудит: Я лично не сталкивался с масштабами в 300 и более сайтов но видел достаточно много распределенных систем отдачи и скорее всего, мне кажется, что синхронизация 300 сайтов (что я думаю мало само по себе, реально то на любом хостинг сервере может быть 3000 сайтов...) это процесс который растягивать через интернет вообще не имеет смысла, такие решения могут базироваться на том же rrDNS, но уже с более серьезной отдачей в каждой из точек, так сказать развитие "изнутри", мне кажется что развитие с "наружи" с точки зрения маршрута мир->ваш сайт, заканчивается на DNS... :) когда вы 1й A записи выдали 20 IP адресов... вы уже не кисло распределили. Почему например Google не вкидывает по 20 серверов в каждый ДЦ в стране, а строит 1 свой (грубо говоря)... вот на этот участок "их схемы" будет 1 ip овтернут в rDNS :D а реально там 100.000 тазиков будут запросы поисковика обслуживать :D

---------- Post added at 21:39 ---------- Previous post was at 21:33 ----------

Мне вот становится не ясно, почему вы в контексте rrDNS упоминаете drbd, если я все правильно помню, то при использовании кажется hearthbeat или как-то так мы получаем точно такую-же машинку, она даже IP адрес основной на себя перехватывает... зачем тут rrDNS. В моем понимании rrDNS это например:

Когда за один домен отвечает несколько серверов, а DRBD по моему такой возможности не дает, они работают заменяя друг друга в случае падения мастера.. хотя тут могу ошибаться, работал ОЧЕНЬ давно с DRBD :)

---------- Post added at 21:42 ---------- Previous post was at 21:39 ----------

А что бы ты предложил с точки зрения кластерных FS если у меня например стоит 5-10 серверов в 5-10 странах мира, ну и как бы хотелось бы адекватную скорость ответа FS в точке её монтирования.... Я понял для себя пока, что всякие glusterfs, lustrefs хороши только в тех случаях когда у вас винты оптикой друг в друга включены :D а если они на расстоянии витой пары, то тот-же glusterfs уничтожил паритетные 100Mb/s для работы FS при нагрузке кажется в 30-40Mb/s на винты (write to FS)

---------- Post added at 21:43 ---------- Previous post was at 21:42 ----------

Поддерживаю, я думаю нужно некое подобие RAID-5 с точки зрения MYSQL (nmbd, replication), то есть 3 тазика с подменой, и на FS нужно что-то подобное... это в одной точке даст мало мальски но устойчивость, если разнести это за пределы ДЦ - думаю равно самоубийству :D

3000 на виртуальном хостинге - это мало.

Тут более любопытно другое, где ТС взял 300 проектов, которым *нужна* эта самая "распределенность" (и они готовы за нее платить)? Допуская даже, что "сайт" у ТС значило "доменное имя" != веб-сайт в обычном смысле - не думаю что у яндекса наберется в сумме столько ;)

"Чую бесовщину, но обосновать не могу" (с)

Настроить шейпер, чтоб не весь канал забирало, например 🍿

красивее преоритизация трафика.