~1000 rrd файлов действительно IO маленький. Когда будет десятки тысяч rrd файлов IO становиться определяющим, даже скорее seek а не IO. И там уже не важны треды, винт всё равно не успевает. В Zenoss это проблема, и мне не понятно почему хвалёный файловый кэш Linux не помогает.
Кстати запускаете же каждые 5 минут? Сколько времени уходит на один круг?
«Заменит CLI» имеется ввиду заменит управление сервером? Мониторинг и управление разные задачи. Или я чего-то не понял.
Интересно как будет жить под нагрузкой. Zenoss прожорлив до памяти и скорости доступа к диску. Проблемы начались при рисовании ~25000 графиков (OID`ов snmp). Железка HP Xeon 5110 1.60GHz, диски SAS, 4Гига оперативки.
В список требований хорошо укладывается Zenoss. Правда без sms(icq) и nessus.
Не рассматривали вариант взять за базу zenoss (али ещё чего) и допинать до уровня продажи услуги? Новые фичи community приносит, вы деньги делаете. Может что-то community перепадёт.
Вопрос про производительность. Правильно ли я понимаю, что для пользователя с белым IP внутри сети выключенный nat-control и настроеный nat 0 не отличается. Но во втором случае ASA будет тратить CPU и пересобирать пакеты. А если у меня таких много, то я могу неплохо повысить/оптимизировать пропускную способность ASA убрав nat 0 и выключив nat-control.
«а внешняя трансляция подменяет адрес источника при проходе «внутрь» МЭ.» Случаем не опечатка? Какой практический смысл подменять адрес источника при проходе внутрь?
Создаётся профиль ACL в котором определяется какие байты будут сравниваться в Ethernet кадре. Определяется отступом (offset) от начала Ethernet кадра. Возможно указать любой набор байт в диапазоне от 0 до 79.
Создаётся правило из профиля и конкретные значения байтов, набор которых указан в профиле, а так же порты коммутатора, к которым применяется данное правило ACL
Для разовых/временных решений само то. Хотя временно обхожусь пробросом портов через SSH. А на постоянку делаю IPSEC.
К тому же не люблю слоёных пирожков из протоколов (TCP-IP-PPP-SSH-TCP-IP). Хотел было сказать что нужно почитать «Why TCP Over TCP Is A Bad Idea». Но тут же нашёл вменяемое опровержение www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf
ИМХО, основной минус у таких тунелей — они не симметричны. Т.е. они должны быть всегда поднятыми, если со стороны сервера (SSH) создаются TCP соединения. В IPSEC же оба конца тунеля «равноправны».
Пользователь сам должен решить переходить или нет к следующему шагу. Нет игры и желания проходить дальше. Энтузиазм обучения тает со временем и никак не поддерживается ресурсом.
Однако прочту. Спасибо! Пробежал глазами наткнулся на это:
«Мне не хочется верить, что среди моих читателей есть люди, которые не понимают принципов организации таблицы Менделеева и не в курсе физического смысла номера химического элемента. А если подобные люди еще существуют, им нужно прекратить чтение данной книги, пойти и немедленно повеситься. Так выйдет гораздо гуманнее для всего цивилизованного человечества. Не тяните, умоляю вас…
Вы еще здесь?.. Ладно, читайте дальше, дядя шутит… „
www.youtube.com/watch?v=RirqnBUQTEU
Увидел у exler`а.
Страничка автора singularityhub.com/2010/04/28/lego-robot-solves-bigger-and-harder-rubiks-cubes-video/
Бывает, что firewall`ом рулить обязан другой человек. Поэтому проще решить задачу не прибегая к «внешним» средствам.
Кстати запускаете же каждые 5 минут? Сколько времени уходит на один круг?
Интересно как будет жить под нагрузкой. Zenoss прожорлив до памяти и скорости доступа к диску. Проблемы начались при рисовании ~25000 графиков (OID`ов snmp). Железка HP Xeon 5110 1.60GHz, диски SAS, 4Гига оперативки.
Не рассматривали вариант взять за базу zenoss (али ещё чего) и допинать до уровня продажи услуги? Новые фичи community приносит, вы деньги делаете. Может что-то community перепадёт.
Живу в Красноярске, поэтому мне неважно какие ещё есть города. Поэтому в Красноярске конкурент точно есть.
Пользуюсь эпизодически обоими продуктами. Что лучше сказать не могу.
Создаётся профиль ACL в котором определяется какие байты будут сравниваться в Ethernet кадре. Определяется отступом (offset) от начала Ethernet кадра. Возможно указать любой набор байт в диапазоне от 0 до 79.
Создаётся правило из профиля и конкретные значения байтов, набор которых указан в профиле, а так же порты коммутатора, к которым применяется данное правило ACL
К тому же не люблю слоёных пирожков из протоколов (TCP-IP-PPP-SSH-TCP-IP). Хотел было сказать что нужно почитать «Why TCP Over TCP Is A Bad Idea». Но тут же нашёл вменяемое опровержение www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf
ИМХО, основной минус у таких тунелей — они не симметричны. Т.е. они должны быть всегда поднятыми, если со стороны сервера (SSH) создаются TCP соединения. В IPSEC же оба конца тунеля «равноправны».
Вообщем, не дотягивает до video-english.ru/.
Ещё ресурс в тему И listen-and-write.com/
«Мне не хочется верить, что среди моих читателей есть люди, которые не понимают принципов организации таблицы Менделеева и не в курсе физического смысла номера химического элемента. А если подобные люди еще существуют, им нужно прекратить чтение данной книги, пойти и немедленно повеситься. Так выйдет гораздо гуманнее для всего цивилизованного человечества. Не тяните, умоляю вас…
Вы еще здесь?.. Ладно, читайте дальше, дядя шутит… „