Am1G0

Слепой, блин :( Пардоньте.

Сабж: http://habrahabr.ru/company/eset/blog/264619/ В конце статьи указан forum.nag.ru. По форуму искал упоминания инцидента, но ничего не нашёл.

это правда? это ведь самое настоящее вредительство, если так. разве для подрядчиков не выставляется sla на rtt для участка?

ок, что подразумевается тогда под "если залочить первый канал в инет (ISP1), не роняя сам интерфейс"? и можно ip r в студию?

rp_filter?

hast memsync/fullsync/async? исходя из этого уже и плясать. способна конфигурация на многое, нужно крутить.

между тем, ipfw(+dummynet) значительно удобнее tc.

глючная и медленная какаха. по крайней мере именно такой и была, когда тестил. выше 15к событий в секунду на 4 ядрах ксеона e74870 никак не смогла прожевать, хотя как БД и использует офигенный es, который с rsyslog и с полтинником без дропов свободно справлялся.

Там каких только не целевых модулей не нарожали, вон и tcpproxy даже сделали. вот tcpproxy я бы не назвал нецелевым, я с его помощью как раз сейчас приспосабливаю nginx для проксирования https.

ну можно и так, только это совсем уже нецелевое использование жинкса.

bmc remedy

Много пилили? Конфигом поделитесь, пожалуйста. нет, state-машину для разбора http-заголовков поправил, да добавил опцию включения/отключения. конфигом не поделюсь, так как он совершенно обычный. для вырезания же рекламы bfilter->nginx, только вот зачем её вырезать?

Я примерно представляю абонентскую базу на 500 комутаторов. Вопрос: для чего нужно такое большое количество серверов? По моим прикидкам должно хватить 7 максимум. У самого 400 комутаторов, сислог-нг справляется на ура на одной машине. На горячую не резервирую. Храню в мускуле. Очень доволен. например, под кеш. хотя под это, конечно, логичнее было бы собрать 1 хранилку.

Имеется ввиду ngx_http_sub_module? Вы пробовали использовать его для какого-нибудь "вконтакте"? да, пробовал. более того, отлично работает, потребовалось допилить только возможность прозрачного проксирования для nginx. Если говорить о проксе, которая вырезает чужую рекламу и вставляет свою - нет. да.

sh: line 1: 18024 Segmentation fault (core dumped) /home/sybase/ASE-15_0/bin/dataserver -d/home/sybase/data/master.dat -b240M -z16k -spqbsyb1 -e/home/sybase/ASE-15_0/install/pqbsyb1.log -T1623 -f > /tmp/sbm2nvHw 2>&1 у вас инсталлер падает. поковыряйте корку дебагером. можно ещё пальцем в небо попробовать: [root@sce sybase]# export LD_POINTER_GUARD=0; ./installsyb.sh --sybhome=/home/sybase --datadir=/home/sybase_db/ или [root@sce sybase]# export LD_POINTER_GUARD=1; ./installsyb.sh --sybhome=/home/sybase --datadir=/home/sybase_db/

читалка за пару часов на любимом яп, не дольше. вопрос скорее стоит в том, насколько продвинутую хотите читалку, так как у меня дошло до того, что помимо вебуя со свистоперделками и аналитикой понадобились ещё и консольные инструменты, заменяющие собой tail, grep, head и прочую лабуду. есть, кстати, ещё один интересный вариант: rsyslog + elasticsearch, но это если требуется настоящий и довольно быстрый полнотекстовый поиск. в монго настоящего полнотекстового поиска нет.

достаточно использовать nginx (squid обычно слишком медленный) как forward proxy. собственная разработка - смех.

1) На коммутаторах не удастся указать два узла назначения логов? зачем? 2) Можно ли заставить коммутаторы слать логи по tcp? это стоит искать в доках самих коммутаторов 3) Как ретранслировать логи с центрального сервера логов на другой сервер, на котором крутится NOC.Project? уже отвечено было ранее - релеить их 4) Почему вы считаете, что логи надо слать только по udp? Лично я предпочитаю их получать гарантированно по tcp. А лучше вообще закриптованными в туннеле :) tcp - это негарантированно, sctp - гарантированно, но известные мне syslog-сервера не умеют его, хотя можно использовать sctp proxy, но это всё-равно фуфло, поддержка должна быть на уровне приложения. 5) Насколько стабильно работает syslog-ng при 100-1000 r/s ? Не надо ли его перегружать? по моим тестам стабильно до 100krps, больше не тестил. в качестве бд сразу рекомендую использовать mongo, дабы не трахаться потом с приколами разных rdbms. бд стоит ставить отдельно и обеспечивать её отказоустойчивость внутренними средствами.

ожидаем изменения "до" на "может быть до".

да, всё прекрасно, но 18 тысяч классов... что ж, если иных альтернатив нет :)

Приветствую, коллеги, возникла очень интересная задача: организовать шейпинг средствами tc таким образом, чтобы каждый клиент (уникальный IP) имел собственный лимит, но численно идентичный для всех. Задача становится интересной благодаря тому, что клиентов в районе 18 тысяч и создавать для каждого отдельный qdisc и фильтр - совсем неправильно. Hash-based матчинг не подходит потому, что лимит должен распространяться на каждого клиента отдельно, не объединяя доступную полосу нескольким клиентам. Если делать в лоб, то получится по 18 тысяч фильтров и qdisc'ов, что совсем не айс. Если более глобально, то задача выглядит так: шейпить входящий трафик и пошейпленный уже пускать дальше. Общий шейпинг (для всех клиентов) реализован с помощью редиректа трафика на ifb и использования htb на нём, но вот как изящно и без костылей реализовать внутри ещё и per-ip independent шейпинг, который численно вовсе необязательно соотносится с общим - ума не приложу и буду очень признателен за советы.

именно! дисковый кэш был отключен, со включенным не тестировал. 100% отжирал. смысла его параллелить нет никакого, а мультипоточность он не поддерживает. 2.6 использовал. нет, достаточно с помощью того же iptables редиректить https трафик на сквид, а http на nginx.

А в чем прожорливость сквида? При каких нагрузках ничинаются проблемы и в чем выражаются? Железо будет тоже не слабое. Просто интересно, как работотает сквид под большими нагрузками. Или squid оринтирован только на небольшие корпоративные сети? от 2к на core2quad начинаются проблемы. дико тормозит.

крайне не советую использовать для http squid. лучше взять nginx чисто под http и написать perl handler, который будет реализовывать возможности белых листов и не париться за железо вообще. сквид дико прожорливый в сравнении с nginx, хотя Сысоев и не рекомендует использовать nginx как forward-proxy, но с этим нет никаких проблем. другое дело, что https трафик придётся всё-равно на squid рулить, т.к. nginx не поддерживает https.

не могли бы объяснить, почему вы так считаете? только, пожалуйста, не с провайдерской точки зрения (любименький мимими хомячок, лишь бы не свалил никуда), а аргументировано?если что, то речь шла о чём-то вроде RTBH, только при отсутствии возможности использовать IGP.