dyakoff: Запустите скрипт который Raistlin дал на хосте, указав логи клиента, только он там под csf под iptables переписать не проблема или обращайтесь дам переписаный.
Сам переписал :) Не ленивый. Там всего одна строчка разница.
Raistlin: bugsmoran, Мдэ... В общем если не побоитесь положить хост на часок - отобьетесь. Я пока щас морально не готов хостинг ронять, тока на вдс возьму...
Да вот за две минуты уже лег со статичной страничкой - Nginx выгрыз весь диск. Ну нафиг. И так у нас не все слава богу последнее время и много недовольных. Не хочу невинных клиентов мучать. Они и так натерпелись.
С раутингом не стали заморачиваться, не на столько сильная атака, чтобы iptables перегрузить. Там проблема не в мощности атаки, а в скручивании MaxClients, поэтому и iptables хватает.
Raistlin: Меряются на синах. В мегабитах атаку не меряют...
Я тоже так считаю. Но тут куча народу, которые на полном серьезе говорят фразы "60Мбит/с, 80Мбит/с" и я не хочу спорить. Я не знаю, если это 60 Мбайт переданных SYN-пакетов или 60 Мбайт скачанного контента или еще чего. Хочу просто выяснить их методику подсчета сферического коня и выдать им желаемый ими результат по желаемой ими методике - мне то не принципиально.
Raistlin:
В общем так. Клиенту прописать VDS и wget hostace.ru/barf.pl - вчера мне за 15 секунд сворачивали 2048 max clients, сегодня я онлайн. На время фильтрации поставить статический индекс.хтмл. И смотреть сервер-статус.
Нету VDS, один только шаред у нас. У нас же узкая специализация. Забирайте клиента кто-нибудь :) Пропадает человек и сайт вместе с ним.
Ребят, хостер - я (whitesuite.ru). Так как мы не предоставляем услугу антидоса, то стесняться нечего и имя прятать тоже.
По поводу атаки могу дать уточняющие данные.
Размер access.log естественно не дам - мы же заблокировали сайт и он не пополняется. У него станрдартный размер. А вот SYN запросов (все, что добралось до iptables) уже 8Гб (за сутки) или 32 миллиона штук за сутки.
MaxClients любого размера (на данном сервере 512) скручивается ориентировочно за 30-40 секунд.
Как меряют Мбиты в секунду - не знаю. Если подскажете формулу, подсчитаю.
Romka_Kharkov: но если уж совсем внимательно почитать, там пишут про Raid-6, я могу предположить что например в масиве был мертв уже 1 винт, согласен, система должна жить - это нормально, но как жить ? А если это нода.... на сколько я помню когда в RAID5 выпадает 1 винт, данные на месте но производительность падает в разы.... если не в десятки разов.... а если мы говорим о ВПС ноде которые и так обычно в i/o упираются..... могло быть в принципе что угодно ...... Но это конечно ни коему образом не провоцирует появление lost+found..... А вот непроходимость-почты или проблемы с Mysql при сломанном рейде + нагруженной ноде вполне могут произойти как я считаю. Вы же не знаете кто там и как диагностировал изначальные проблемы :D
По поводу дополнительной нагрузки - тут согласен. Даже 1-й рейд будет читать вдвое медленнее (он же пишет на оба синхронно, а читает как с 0-го). Но разве может из-за этого почта "глючить"? Даже предсатвить не могу что должно так тормозить на дисках, чтобы почта стала ходить не как надо.
Raistlin: Но в остальном - вполне вероятно, что рейда на ноде небыло
Я как раз подчеркиваю, что не было проблемы рейда, а не самого рейда. Есть такие варианты событий:
1) Рейда нет. Диск сгорел. - тогда бы вообще ничего не увидели, но ведь нам известно, что система еще бултыхалась.
2) Рейд есть. Сгорело дисков больше, чем требуется для работоспособности. - тогда бы вообще ничего не увидели, но ведь нам известно, система еще бултыхалась.
3) Рейд есть. Сгорело дисков меньше, чем требуется для работоспособности. - тогда бы вообще ничего не заметили. Система бы продолжила работать в штатном режиме.
4) Рейд есть. Ничего не сгорало. - тогда бы вообще ничего не заметили. Система бы продолжила работать в штатном режиме.
А значит нету сценариев, которые вообще хоть как-то приводят к вопросу а был ли рейд. Неважно был он или нет в данном инциденте.
chil: Если заявлен Raid 6, каковы шансы на восстановление?
Еще раз перечитайте свои слова. Ничего не замечаете? Вас развели как ребенка!
Давайте попробуем проанализировать. Судя по тому, что вспомнили о рейде, видимо Вам про него упомянул админ/хостер. Но если вылетел диск из рейда (какой-бы он ни был), то система либо вообще сдохнет (Raid0) либо вообще не шелохнется (Raid1,2,3,4,5,5E,6,10,20,30) - она продолжит читать с оставшегося диска(ов). Не будет такого сценария как "сюда почта отправляется, а сюда нет" или "есть ошибка от MySQL". Другими словами: если умер диск, то либо система испарится в аналах истории либо ничего не изменится кроме извещений от мониторинга.
А значит что? Рейд у Вас не ломался!
Едем дальше. Сбой файловой системы? Ок, допустимо. Но тогда почему данные начали переносить? Любой сбой файловой системы чинится в пару команд. Не чинится только полное затирание дерева с указателями на айноды и их указатели на директории, но тогда бы Вы и систему свою не увидели, а Вы часть ее работы видели как успешно сделанную. Кроме того, такие косяки бывают только с непопулярными ФС типа JFS, Reiser или XFS. Я очень сомневаюсь, что у Вас было что-то кроме ext3/4. В любом случае все это чинится легко. И они перетащили данные на другой сервер. Вы верите в то, что человек начнет перетаскивать, у него часть данных не читается, а он упорно тащит дальше? Бред!
Вывод? Сбоя файловой системы не было!
Едем дальше. Где-то промельнуло, что система не грузится. Но мы то знаем, что она есть - ведь часть писем отправлялась. А значит либо не грузилось начальное ядро либо диск не находили с которого грузится (и то и другое чинится в две команды). Это повод перетаскивать данные? Опять же нет... И даже если решили перетащить, то значит данные остались на исходном сервере? Ведь люди в такой ситуации не станут удалять ничего на всякий случай?
Так что же? Либо кто-то проявил крайне неспортивный подход либо не было этой проблемы вообще.
****
Выясняйте, что у Вас там произошло. Кто-то явно прикрывает другой косяк под предлогом "сбой файловой системы". Это распространная практика свой косяк прикрыть либо сбоем ФС либо ДДоСом. И то и другое типа как форс-мажор и никто вроде бы не виноват. Ничей профессионализм не под вопросом.
Проблема клиента в том, что он сейчас не разговаривает с позиции "мне обещали, значит пусть делают". Нет. Он знает, что ему никто ничего не должен и он не может требовать. Поэтому он занял другую позицию: хочет публично обвинить хостера в том, что он не следует рыночным понятиям максимального захвата всех существующих хостинговых ниш и отсутствие стремления к уменьшению упущенной выгоды.
Так вот я Вам расскажу, что стремление предоставить спектр всех существующих продуктов есть только у начинающих. Чем дальше, тем больше человек, ведущий бизнес, понимает, что у него есть шансы выжить на рынке только в том случае, если он сконцентрирует силы на одном направлении (кто-то как Himiko концентрируется на уровне обслуживания, кто-то как FastVPS только на VPS и дедиках, кто-то как я - только на стардартном шареде и так далее). Обсуждаемый хостер уже прошел эту моральную отметку и не может распылять силы на допиливание хостинга под UMI, потому что у него и так проблем по горло. Он рад бы взять Ваши деньги и предоставить услугу и тем самым упущенную прибыль превратить в полученную, но он распылится и не сделает другие более важные задачи, чем породит еще большее количество упущенной выгоды. Это алогично для здорового маркетинга. Это нерыночное поведение новичков.
Так что перестаньте огрызаться и обратите внимание, что при том что хостинг - рынок со злейшей конкуренцией на фоне низкого культурного уровня, в данном месте все до единого хостеры как сговорились и защищают имя своего кокурента. Это что-то значит. Просто так такого не бывает. Значит что-то Вы не заметили или недопоняли.
readme.by: Вот именно хостер из своих интересов должен зарабатывать деньги.
Так Вы то ему предлагаете их потерять ради преследования Ваших интересов, которые диаметрально расходятся с общерыночными. Подстройка под UMI - это уход других клиентов, в 10 раз больших, чем тех, кто придет с UMI.
readme.by:
Знаете у хорошего хостера ни станет проблем с тем, что нужно создать дополнительно виртуальную машину под проекты на базе UMI или другой CMS, тем и отличается хороший хостер от аутсайдеров в хостинге, которые расчитывают только на большинство и забывают (забивают) на других.
А что такое хороший хостер? Мейнстрим и андеграунд необъединимы - это взаимоисключающие сущности. И для, в качестве ликбеза, андеграунд - это не значит плохо, это просто вне общего мейнстрима (например UMI - это андеграунд).
readme.by: Почитайте по поводу популярности и удобства в работе. Рейтинг CMS. Я так понимаю сдесь мы не обсуждаем рейтинг CMS.
Я вообще-то хостер (и все остальные здесь хостеры не дадут мне соврать). Я точно знаю, что популярно, а что нет. UMI не пользует вообще никто. Все сидят на Joomla(80%)/DLE/WP. Это не значит, что UMI плохая, это всего лишь значит, что Вы не правы, когда сказали, что она популярна (джаз тоже непопулярен, но это не значит, что он хуже попсы).
dyakoff: Хм, упрекать хостера за то, что он в принцыпе не предоставляет, а чего вы от него не требуете мусор у вас выносить каждый день? Дело хостера предложить, если вас не устраивает - отказатся, это рыночные отношения а не политика босоты.
Поддерживаю. Если автосервис европейских авто не берется чинить Lotus Esprit, потому что у него дюймовые болты, то это не значит, что сервис плохой. Это просто значит, что Lotus надо продать и купить машину, построенную по стандартам.
Запустите скрипт который Raistlin дал на хосте, указав логи клиента, только он там под csf под iptables переписать не проблема или обращайтесь дам переписаный.
Сам переписал :) Не ленивый. Там всего одна строчка разница.
bugsmoran, Мдэ... В общем если не побоитесь положить хост на часок - отобьетесь. Я пока щас морально не готов хостинг ронять, тока на вдс возьму...
Да вот за две минуты уже лег со статичной страничкой - Nginx выгрыз весь диск. Ну нафиг. И так у нас не все слава богу последнее время и много недовольных. Не хочу невинных клиентов мучать. Они и так натерпелись.
Вот так сделали:
-A INPUT -p tcp -m tcp --dport 80 -m string --string "zaozernoe.org" --algo kmp --to 65535 -j DROP
С раутингом не стали заморачиваться, не на столько сильная атака, чтобы iptables перегрузить. Там проблема не в мощности атаки, а в скручивании MaxClients, поэтому и iptables хватает.
Меряются на синах. В мегабитах атаку не меряют...
Я тоже так считаю. Но тут куча народу, которые на полном серьезе говорят фразы "60Мбит/с, 80Мбит/с" и я не хочу спорить. Я не знаю, если это 60 Мбайт переданных SYN-пакетов или 60 Мбайт скачанного контента или еще чего. Хочу просто выяснить их методику подсчета сферического коня и выдать им желаемый ими результат по желаемой ими методике - мне то не принципиально.
В общем так. Клиенту прописать VDS и wget hostace.ru/barf.pl - вчера мне за 15 секунд сворачивали 2048 max clients, сегодня я онлайн. На время фильтрации поставить статический индекс.хтмл. И смотреть сервер-статус.
Нету VDS, один только шаред у нас. У нас же узкая специализация. Забирайте клиента кто-нибудь :) Пропадает человек и сайт вместе с ним.
Ребят, хостер - я (whitesuite.ru). Так как мы не предоставляем услугу антидоса, то стесняться нечего и имя прятать тоже.
По поводу атаки могу дать уточняющие данные.
Размер access.log естественно не дам - мы же заблокировали сайт и он не пополняется. У него станрдартный размер. А вот SYN запросов (все, что добралось до iptables) уже 8Гб (за сутки) или 32 миллиона штук за сутки.
MaxClients любого размера (на данном сервере 512) скручивается ориентировочно за 30-40 секунд.
Как меряют Мбиты в секунду - не знаю. Если подскажете формулу, подсчитаю.
но если уж совсем внимательно почитать, там пишут про Raid-6, я могу предположить что например в масиве был мертв уже 1 винт, согласен, система должна жить - это нормально, но как жить ? А если это нода.... на сколько я помню когда в RAID5 выпадает 1 винт, данные на месте но производительность падает в разы.... если не в десятки разов.... а если мы говорим о ВПС ноде которые и так обычно в i/o упираются..... могло быть в принципе что угодно ...... Но это конечно ни коему образом не провоцирует появление lost+found..... А вот непроходимость-почты или проблемы с Mysql при сломанном рейде + нагруженной ноде вполне могут произойти как я считаю. Вы же не знаете кто там и как диагностировал изначальные проблемы :D
По поводу дополнительной нагрузки - тут согласен. Даже 1-й рейд будет читать вдвое медленнее (он же пишет на оба синхронно, а читает как с 0-го). Но разве может из-за этого почта "глючить"? Даже предсатвить не могу что должно так тормозить на дисках, чтобы почта стала ходить не как надо.
Но в остальном - вполне вероятно, что рейда на ноде небыло
Я как раз подчеркиваю, что не было проблемы рейда, а не самого рейда. Есть такие варианты событий:
1) Рейда нет. Диск сгорел. - тогда бы вообще ничего не увидели, но ведь нам известно, что система еще бултыхалась.
2) Рейд есть. Сгорело дисков больше, чем требуется для работоспособности. - тогда бы вообще ничего не увидели, но ведь нам известно, система еще бултыхалась.
3) Рейд есть. Сгорело дисков меньше, чем требуется для работоспособности. - тогда бы вообще ничего не заметили. Система бы продолжила работать в штатном режиме.
4) Рейд есть. Ничего не сгорало. - тогда бы вообще ничего не заметили. Система бы продолжила работать в штатном режиме.
А значит нету сценариев, которые вообще хоть как-то приводят к вопросу а был ли рейд. Неважно был он или нет в данном инциденте.
Если заявлен Raid 6, каковы шансы на восстановление?
Еще раз перечитайте свои слова. Ничего не замечаете? Вас развели как ребенка!
Давайте попробуем проанализировать. Судя по тому, что вспомнили о рейде, видимо Вам про него упомянул админ/хостер. Но если вылетел диск из рейда (какой-бы он ни был), то система либо вообще сдохнет (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, потому что у него и так проблем по горло. Он рад бы взять Ваши деньги и предоставить услугу и тем самым упущенную прибыль превратить в полученную, но он распылится и не сделает другие более важные задачи, чем породит еще большее количество упущенной выгоды. Это алогично для здорового маркетинга. Это нерыночное поведение новичков.
Так что перестаньте огрызаться и обратите внимание, что при том что хостинг - рынок со злейшей конкуренцией на фоне низкого культурного уровня, в данном месте все до единого хостеры как сговорились и защищают имя своего кокурента. Это что-то значит. Просто так такого не бывает. Значит что-то Вы не заметили или недопоняли.
Вот именно хостер из своих интересов должен зарабатывать деньги.
Так Вы то ему предлагаете их потерять ради преследования Ваших интересов, которые диаметрально расходятся с общерыночными. Подстройка под UMI - это уход других клиентов, в 10 раз больших, чем тех, кто придет с UMI.
Знаете у хорошего хостера ни станет проблем с тем, что нужно создать дополнительно виртуальную машину под проекты на базе UMI или другой CMS, тем и отличается хороший хостер от аутсайдеров в хостинге, которые расчитывают только на большинство и забывают (забивают) на других.
А что такое хороший хостер? Мейнстрим и андеграунд необъединимы - это взаимоисключающие сущности. И для, в качестве ликбеза, андеграунд - это не значит плохо, это просто вне общего мейнстрима (например UMI - это андеграунд).
Почитайте по поводу популярности и удобства в работе. Рейтинг CMS. Я так понимаю сдесь мы не обсуждаем рейтинг CMS.
Я вообще-то хостер (и все остальные здесь хостеры не дадут мне соврать). Я точно знаю, что популярно, а что нет. UMI не пользует вообще никто. Все сидят на Joomla(80%)/DLE/WP. Это не значит, что UMI плохая, это всего лишь значит, что Вы не правы, когда сказали, что она популярна (джаз тоже непопулярен, но это не значит, что он хуже попсы).
Хм, упрекать хостера за то, что он в принцыпе не предоставляет, а чего вы от него не требуете мусор у вас выносить каждый день?
Дело хостера предложить, если вас не устраивает - отказатся, это рыночные отношения а не политика босоты.
Поддерживаю. Если автосервис европейских авто не берется чинить Lotus Esprit, потому что у него дюймовые болты, то это не значит, что сервис плохой. Это просто значит, что Lotus надо продать и купить машину, построенную по стандартам.