В какую еще аську? :) Я не пользуюсь аськой и вообще мессенджерами (точнее есть скайп, но только для очень хорошо знакомых).
Сам переписал :) Не ленивый. Там всего одна строчка разница.
Да вот за две минуты уже лег со статичной страничкой - Nginx выгрыз весь диск. Ну нафиг. И так у нас не все слава богу последнее время и много недовольных. Не хочу невинных клиентов мучать. Они и так натерпелись.
Вот так сделали:
С раутингом не стали заморачиваться, не на столько сильная атака, чтобы iptables перегрузить. Там проблема не в мощности атаки, а в скручивании MaxClients, поэтому и iptables хватает.
Я тоже так считаю. Но тут куча народу, которые на полном серьезе говорят фразы "60Мбит/с, 80Мбит/с" и я не хочу спорить. Я не знаю, если это 60 Мбайт переданных SYN-пакетов или 60 Мбайт скачанного контента или еще чего. Хочу просто выяснить их методику подсчета сферического коня и выдать им желаемый ими результат по желаемой ими методике - мне то не принципиально.
Нету VDS, один только шаред у нас. У нас же узкая специализация. Забирайте клиента кто-нибудь :) Пропадает человек и сайт вместе с ним.
Ребят, хостер - я (whitesuite.ru). Так как мы не предоставляем услугу антидоса, то стесняться нечего и имя прятать тоже.
По поводу атаки могу дать уточняющие данные.
Размер access.log естественно не дам - мы же заблокировали сайт и он не пополняется. У него станрдартный размер. А вот SYN запросов (все, что добралось до iptables) уже 8Гб (за сутки) или 32 миллиона штук за сутки.
MaxClients любого размера (на данном сервере 512) скручивается ориентировочно за 30-40 секунд.
Как меряют Мбиты в секунду - не знаю. Если подскажете формулу, подсчитаю.
По поводу дополнительной нагрузки - тут согласен. Даже 1-й рейд будет читать вдвое медленнее (он же пишет на оба синхронно, а читает как с 0-го). Но разве может из-за этого почта "глючить"? Даже предсатвить не могу что должно так тормозить на дисках, чтобы почта стала ходить не как надо.
Я как раз подчеркиваю, что не было проблемы рейда, а не самого рейда. Есть такие варианты событий:
1) Рейда нет. Диск сгорел. - тогда бы вообще ничего не увидели, но ведь нам известно, что система еще бултыхалась.
2) Рейд есть. Сгорело дисков больше, чем требуется для работоспособности. - тогда бы вообще ничего не увидели, но ведь нам известно, система еще бултыхалась.
3) Рейд есть. Сгорело дисков меньше, чем требуется для работоспособности. - тогда бы вообще ничего не заметили. Система бы продолжила работать в штатном режиме.
4) Рейд есть. Ничего не сгорало. - тогда бы вообще ничего не заметили. Система бы продолжила работать в штатном режиме.
А значит нету сценариев, которые вообще хоть как-то приводят к вопросу а был ли рейд. Неважно был он или нет в данном инциденте.
Еще раз перечитайте свои слова. Ничего не замечаете? Вас развели как ребенка!
Давайте попробуем проанализировать. Судя по тому, что вспомнили о рейде, видимо Вам про него упомянул админ/хостер. Но если вылетел диск из рейда (какой-бы он ни был), то система либо вообще сдохнет (Raid0) либо вообще не шелохнется (Raid1,2,3,4,5,5E,6,10,20,30) - она продолжит читать с оставшегося диска(ов). Не будет такого сценария как "сюда почта отправляется, а сюда нет" или "есть ошибка от MySQL". Другими словами: если умер диск, то либо система испарится в аналах истории либо ничего не изменится кроме извещений от мониторинга.
А значит что? Рейд у Вас не ломался!
Едем дальше. Сбой файловой системы? Ок, допустимо. Но тогда почему данные начали переносить? Любой сбой файловой системы чинится в пару команд. Не чинится только полное затирание дерева с указателями на айноды и их указатели на директории, но тогда бы Вы и систему свою не увидели, а Вы часть ее работы видели как успешно сделанную. Кроме того, такие косяки бывают только с непопулярными ФС типа JFS, Reiser или XFS. Я очень сомневаюсь, что у Вас было что-то кроме ext3/4. В любом случае все это чинится легко. И они перетащили данные на другой сервер. Вы верите в то, что человек начнет перетаскивать, у него часть данных не читается, а он упорно тащит дальше? Бред!
Вывод? Сбоя файловой системы не было!
Едем дальше. Где-то промельнуло, что система не грузится. Но мы то знаем, что она есть - ведь часть писем отправлялась. А значит либо не грузилось начальное ядро либо диск не находили с которого грузится (и то и другое чинится в две команды). Это повод перетаскивать данные? Опять же нет... И даже если решили перетащить, то значит данные остались на исходном сервере? Ведь люди в такой ситуации не станут удалять ничего на всякий случай?
Так что же? Либо кто-то проявил крайне неспортивный подход либо не было этой проблемы вообще.
****
Выясняйте, что у Вас там произошло. Кто-то явно прикрывает другой косяк под предлогом "сбой файловой системы". Это распространная практика свой косяк прикрыть либо сбоем ФС либо ДДоСом. И то и другое типа как форс-мажор и никто вроде бы не виноват. Ничей профессионализм не под вопросом.
Вы считаете, что в реализации протокола OSPF есть баг? Обязательно о нем заявите разработчикам Cisco/Juniper/Nortel :) Пусть починят.
Проблема клиента в том, что он сейчас не разговаривает с позиции "мне обещали, значит пусть делают". Нет. Он знает, что ему никто ничего не должен и он не может требовать. Поэтому он занял другую позицию: хочет публично обвинить хостера в том, что он не следует рыночным понятиям максимального захвата всех существующих хостинговых ниш и отсутствие стремления к уменьшению упущенной выгоды.
Так вот я Вам расскажу, что стремление предоставить спектр всех существующих продуктов есть только у начинающих. Чем дальше, тем больше человек, ведущий бизнес, понимает, что у него есть шансы выжить на рынке только в том случае, если он сконцентрирует силы на одном направлении (кто-то как Himiko концентрируется на уровне обслуживания, кто-то как FastVPS только на VPS и дедиках, кто-то как я - только на стардартном шареде и так далее). Обсуждаемый хостер уже прошел эту моральную отметку и не может распылять силы на допиливание хостинга под UMI, потому что у него и так проблем по горло. Он рад бы взять Ваши деньги и предоставить услугу и тем самым упущенную прибыль превратить в полученную, но он распылится и не сделает другие более важные задачи, чем породит еще большее количество упущенной выгоды. Это алогично для здорового маркетинга. Это нерыночное поведение новичков.
Так что перестаньте огрызаться и обратите внимание, что при том что хостинг - рынок со злейшей конкуренцией на фоне низкого культурного уровня, в данном месте все до единого хостеры как сговорились и защищают имя своего кокурента. Это что-то значит. Просто так такого не бывает. Значит что-то Вы не заметили или недопоняли.
