Гео-хостинг как мера увеличения надёжности или противодействия DDOS

Если кластерные FS такая универсальная "пуля от всех болезней" почему на них давно не перешли все повально?

Очень регурялная синхронизация ФС по расписанию при помощи rsync почти решает вопрос аватаров с совпадающим названием.

Но при этом основательно убъет производительность дисковой системы.

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

Для коробочных CMS тоже можно решить вопрос, в общем виде.

Могу на спор (порядка 20$) объяснить на пальцах как можно организовать синхронизацию

в практически реальном времени (задержка синка порядка 1 секунды) с примерением rsync и без применения кластерных ФС.

Синхронизация баз данных - вообще крайне просто решается. Репликация по полносвязной схеме. Но есть очень большой подводный камень, просто глыба - autoincrement.

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

Второе решение - отправка всех запросов на запись в единый мастер, а чтение - из локальных слейвах.

Но тут требуется либо работа напильником над CMS, либо достаточно стремный софт.

Но никто здесь экономически не поднял вопрос о том, что DDoS на VPS подразумевает пролетание трафика через 1 реальный интерфейс, и 2 виртуальных. Это утраивает накладные расходы на процессор, irq и т.д.

Строить такую систему на распределенных атомах - сложно и не рационально. Есть более рациональные варианты.

На VPS-ах - просто бред.

Я не знаю, кто такие "все". Вероятно "все" - это те, кто используют говносервер с дохлым sata2 диском? Тогда воплне понятно, почему.

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

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

Вот например - какие из популярных форумов умеют искаропки работать с master-slave или ndb aka mysql-cluster? Да никакие!

Вы путаете 7200 rpm и sata2 (ssd диски тоже sata, нет?)

Вы путаете процесс и поток. (можно запустить несколько процессов mysql на одном сервере, нет?)

Полносвязная репликация подразумевает что каждый ноявляется мастером и слейвом одновременно.

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

Речь вообще не об отказоустойчивости, а о ддос атаке (или я что то пропустил?) Кто сказал что какой то из серверов mysql обязан находиться в атакуемой точке/иметь отношение к атаке?

Какие то из CMS (популярных) точно заточены под работу в режиме master-slave, видел в настройках. Но пруфлинки не дам, ибо не помню, и искать лениво.

А в чем проблема работать из "каропки" с ndb? Между репликацией и кластером есть большая разница.

Нет, ssd - это твердотельные. А sata - это с random seek bo-bo. Сравнение потока с процессом в данном случае не корректно. Если используете говносерверы - так и пишите, мол да, sata диски.

"Полносвязная репликация" возможна только школохрстеров, он умеет очень красиво падать, с поломкой целостности данных. Случаев было множетсво. Но пруфлинки не дам, ибо не помню, и искать лениво.

И часто ломает данные, если серверы не подключены друг к другу прямым шнурком :) Тоже лично сталкивался, так что для гео-нужд это не работает.

sataII - Это интерфейс. Точка.

Он одинаков и для твердотельных дисков, и для "говновеников" rpm 7200. И для энтерпрайз веников rpm7200 тоже (hitachi ultrastar или wd black это говновеник по вашему?)

Поток с процессом я не сравнивал. И в мыслях не имел. Репликация идет в 1 поток на 1 процесс. Если записей идет слишком (настолько) много что слейв отстает от мастера и не может его догнать значит либо между ними слишком медленный канал (настолько что данные бинлога не успевают передаться в один поток) тогда запускаем несколько процессов Mysql (по одному на одну базу например) и получаем несколько потоков репликации (threads) и несколько потоков при передаче (tcp connections). Либо производительность слейва настолько отличается от мастера, что он не успевает обрабатывать все операции insert+update (это проблемы не с mysql и не с репликацией, а с головой или деньгами)

Падение с поломкой целостности данных возможно в 2-х случаях - либо повреждение данных при передаче бинлога по сети (а при этом и обычная репликация сталобыть падает с ровно такой же вероятностью/2) либо при совпадении данных индексов по автоинкременту, а это я упомянул. И как это можно пытаться обходить тоже упомянул.

В общем слив засчитан.

hvosting добавил 10.07.2011 в 00:17

А вот с вами я как раз согласен. Действительно падает. Если в течение б-м продолжительного времени между серверами отсутствовала связь, и в каждый из них за это время успела прийти кипа запросов с использованием автоинкремента. Именно поэтому выше встречается слово "пытаться". Но ведь мы обсуждаем не промышленное отказоустойчивое решение для hiload систем, а сферический велосипед с квадратными колесами в вакууме для временно малобюджетной защиты мелких коробочных сайтов от DDoS?

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

Но для совсем несерьезных баз должно быть незаметно, да.

Если говорить о штатных методах , то скорее всего никак, но можно ведь и учитывать куда upload состоялся... (допустим механизм работает так: при upload берется какая-то переменная из кукисов которые у клиента остались и подается на сторону случайно выданной ноды.... а та её уэе принимая делает отметку о том, что такая-то сессия закачало такой-то файлик....) и потом синхронизировать контент по папочкам нода1/ нода2/ нодаX/. Сильно не бейте :D Я вообще молчу про то, что имена файлов, раз уж разговор о них зашел, могут быть привязаны хоть к IP ноды на которую upload пошел.... лишь бы "общая схема" понимала как потом с этими данными работать :D

Но на сколько я понимаю из последующего ответа про CMS..... взять вот так и натравить обычное веб решение на такой распределенный механизм не выйдет :)

Romka_Kharkov добавил 10.07.2011 в 04:05

Меня вот всегда интересовало :) А если DNS в момент атаки поменять не на 127.0.0.1 а на парочку ip адресов гугла и прочих компаний ? ;)

А вообще надо создавать целое комьюнити по переработке ддос атаки :) Прикинь nslookup по домену сделал, а тебе в ответ пару сотен ИП выехало :D Как идея ?:)

Romka_Kharkov добавил 10.07.2011 в 04:12

Ну давайте не много посчитаем, вот идет на вас ну допустим 1 GB ддоса, это как бы не много, просто считать будет удобнее, вот мы берем скажем 10 VPS серверов, что бы каждый (допускаем что атака будет четко распределена) справлялся с 100Mb/s , так вот какова стоимость такого ВПС выйдет? который будет 100Mb/s переворачивать? Я думаю что по голым-ценам ~150$ обойдется полоса такая + стоимость ВПС.... 10 штук по 150$ это 1500$ / месяц. Я вообще молчу про переписку движков которые надо научить работать с X разных мест одновременно, синхронизируя базы и прочее, решение из коробки тут не создать, для того что бы разделить нагрузку между серверами мне не надо 100 ДНС серверов... мне 2х хватит.... они отдадут 100 А записей и пойдет ДНС балансировка..... (не в количестве обращений к ДНС дело же....). Или вы думаете атаки нацелены на выведения из строя ДНС домена? Такая атака может быть на целевые ДНС... это да... такие которые много зон держут , что бы навредить провайдеру, а атаковать ДНС сайта "мои картинки.ру" не имеет никакого смысла, проще долбить в ИП самого сайта :D

Та ладно :D Её уже можно использовать? Я около года назад гонял (может полтора) .... вообще отстой :D

Romka_Kharkov добавил 10.07.2011 в 04:19

А я за 20$ еще могу на пальцах фокус показать под рассказ :) Причем тут синхронизация, вы опять же говорите о том, чего можно добиться если заливать на одну ноду... такие системы уместны с точки зрения балансировки, вы правы, но увы они не практичны с точки зрения атаки.... Точнее могут быть практичны, но представьте себе бюджет мероприятия хотя бы для отсеивания 1 Gb/s...

И опять, вы говорите о синхронизации картинок, это по моему самое простое о чем можно вообще думать в этой схеме, расскажите мне лучше как вы будете SQL реплицировать и между сколькими нодами?, а потом можете мне еще рассказать какой механизм будет применен для обработки сессий когда ваш клиент делая на сайте 10 тычков посетит 8 разных серверов в балансировке.

Как рсинком пользоваться тут пол форума знает, как он будет SQL и сессии реплицировать тоже не понятно, а самое главное не ясно причем тут ДДОС. :)

Romka_Kharkov добавил 10.07.2011 в 04:20

А как же MultiMaster ?:)

Romka_Kharkov добавил 10.07.2011 в 04:22

5 лет использую в MultiMaster режиме два MySQL сервера, описанных вами проблем не наблюдал, иногда бывают моменты рассинхронизации, от этого сложно уйти (проблемы в сети, и прочее)..... Но так что бы кердык и ничего не восстановить это по моему сильно :))))

P.S: Но бекапы я все равно делаю :D

Romka_Kharkov добавил 10.07.2011 в 04:24

server-id=1 & server-id=2 вроде решает с головой.

Да да! Четность ! :) Есть такое :D Причем если я не ошибаюсь достаточно давно :D