Опять валшебные олгаритмы, которые никому не покажу...
Ну хватит уже, фантазер вы наш. Нету таких алгоритмов, которые _гарантированно_ исключат ложные срабатывания хоть по типу предложенных netwind.
Расчитывать тут можно только на эвристику. Причем, задумайтесь - DDoS вовсе не обязательно сводится к просму потоку "GET /". И нет в принципе универсальных способов отличить слешдот-эффект от DDoS.
Слово вумное понравилось. Вот и твердит как попугай.
Смотрю я на все это дело и вспомнился эпизод "Cripple Fight" сауспарка (ничего личного)
Трафик может быть и сравнительно небольшим - а нагрузка от него на виртуальном хостинга уже будет мешать соседям.
Так что это лишь часть защиты.
с какой руганью отваливается?
начните с демонстрации вывода
iptables -vL
Только под отдельного клиента (а еще лучше - под проект). Со всеми блеклистами и проч.
В ином случае я бы начал заморачиваться с защитой уровня "нагрузка от клиента мешает - оперативно отключаем".
Есть желание сделать зашибись, но нет ни малейшего представления о желаемом результате. Понятно.
Советую начинать с вопросов: как такая-то схема защиты может сказаться на других клиентах, не мишени атаки. Пример проблемы я только что привел.
Это защита _других_ клиентов.
Зависит от цены, но Вы вряд-ли вложитесь в серьезную защиту для клиента на 5$ - когда у Вас есть еще 1k таких. Некоторые вещи экономически неоправданы.
Получаем следующий геморой:
1) разработку системы и интеграцию в СУХ
2) защита "от многого", но не ддос (никаких SLA Вы пообещать клиенту не сможете - и нахрена ему четвертьзонтика над головой?)
3) вероятность потенциальных проблем, ложного срабатывания и т.п. - в следствии усложнения системы в целом
4) счастливую техподдержку, которая будет объяснять марьванне почему она не может попасть на сайт о домашних кошках из-за вирусни, которая долбилась в недавнем ddos на какой-нибудь порносайт того же хостинга... Или у Вас отдельные списки для блокировки будут, per client?
Когда Вы поймете, что
1) абсолютно никто не возражал, что raid1 дает прирост скорости чтения на данном типе нагрузки
2) что устроена оптимизация подобного чтения очень непохоже на "алгоритм" alw
?
Там вроде 6 дисков. Так что тут - медленнее чем линейный рост получается, что тоже вполне закономерно.
"Грубо говоря". Вот это позиционирование - один из факторов при выборе откуда и когда читать. Четный оттуда, нечетный отсюда - просто заставит таскать головки по блинам.
Понизьте скорость ребилда, поиграйтесь с приоритетами. Зачем что-то рубать?
Думаю, тут у Вас виновата больше запись, а не чтение.
Raistlin, тогда уж: man 4 md
но да, уязвили ;)
Возможно, мы лучше подождем и прочитаем следующий близкий блок на этом же диске, чем полезем на другой - в ситуации когда это потребует существенного перепозиционирования головки там. Короче, написали выше.
Вот я и пытался: показав что нужно добавить к этой фантазии, чтобы только она заработала. alw понял - Вы нет. Ну, бывает ;)
И повторюсь, она - не реальность. (Думаю, не только для md raid)
Не так. Все гораздо сложнее, причем уже давно. Это - раз.
И зря. Т.к. я подробно описал _что_ нужно было бы добавить к "этой фантазии", чтобы она давала профит при последовательном чтении. Вот этой добавки и нету. С чем Вы тогда спорили?
Как минимум, неполный. Что для технического текста почти наверняка означает "плохой и неправильный". Я уж молчу про то, что 100% пользовательских команд по управлению рейдом (всякие ckraid, mdadd, mdstart ...) - волей аллаха давно помре.
Пожалуй, помимо комментариев и Documentation/md.txt я знаю только один связный источник информации по рейду в linux - это блог автора.
Вот это уже ближе к делу. Сам я затрудняюсь изложить алгоритм полностью, но он действительно не настолько примитивен - что читаются попеременно блоки с разных устройств. К примеру, учитываются позиционирование головок. Короче, см. read_balance().
