Debian объявляет об официальной поддержке kFreeBSD

> как отключить mtime? можно пример команды для zfs?

Ну погорячился товарищ, погорячился. С кем не бывает... Впрочем, вдруг он ZFS хакнул и у него это можно сделать ;-)

Совсем забыл!

>Но в опене сейчас таких средств нет. Юзаем сторонние

Какие IDS/IPS под опенок порекомендуете? Очень интересен опыт использования.

> Какие IDS/IPS под опенок порекомендуете? Очень интересен опыт использования.

Юзаю снорт, больше ничего и не пробовал толком.

> Как я понял, ftp-proxy парсит трафик и по мере необходимости добавляет нужные правила в pf. Честно говоря, по сравнению с conntrack, который просто выставляет связанным соединениям _стейты_, производит некоторое впечатление костыльности. Ну ладно.

ну как-бы так, да не совсем. он не парсит трафик, ну то есть парсит, но не в том смысле. он _прокси_, и к нему заведомо поступают только пакеты фтп. прокси открывает только те порты, которые реально использует, и только для себя, а также использует рдр-цепь для того, чтобы просто форвардить нужные пакеты клиенту, без копирования в юзаерспейсную проксю и назад. мне вот например кажется не меньшим костылем то, что стейты должны учитывать кривизну одного протокола и специально для него иметь отдельное состояние. на самом деле, это нюансы, хорошо, что все работает.

> А для SIP, IRC, H.323 тоже подобные штуки есть?

да, но не в base system

>> в смысле? ты имеешт ввиду если пф на фтп сервере?
> Ага. И пассивный режим.

ну тут два варианта - открыть порты или прокси. диапазон используемых портов в стандартном фтпд опенка конфигурируемый, но нужно понимать, что тем самым мы ограничиваем макс. кол-во одновременных сессий передачи данных.


это просто спор о том, какие костыли костылястее. необходимо признать, что кривы протоколы, и в данном конкретном слечае необоснованно кривы (точнее, единственное оправдание - это легаси).
важно, что с такими проблемами приходится бороться, и что линукс, что опен, имеют для этого инструменты.

>это просто спор о том, какие костыли костылястее. необходимо признать, что кривы протоколы, и в данном конкретном слечае необоснованно кривы (точнее, единственное оправдание - это легаси).

Больше всего меня настораживает именно то, что традиция выбирать порты на лету вовсе не проявляет тенденции к затуханию.

Если FTP, возникший в 1971, еще можно считать архейской древностью, то про разработанные в 1996 и активно используемые поныне SIP и H.323 я бы так не сказал. Не говоря уж о расплодившихся ныне p2p-сетях, многие из которых также используют этот прием.

Имхо в сложившейся ситуации нужно кардинальное и общесистемное решение, например, выделение специальных полей в заголовках транспортного уровня. И тут уже в качестве легаси выступают TCP и UDP. Правда, сейчас им существуют альтернативы — SCTP и DCCP. К сожалению, с этими протоколами я знаком не очень хорошо. И вроде бы, структура IPv6 тоже имеет определенные возможности для расширения.

Поправь если я ошибаюсь — с твоей точки зрения весь вопрос сводится к наличию выделенных полей в заголовках транспортного уровня и, при необходимости, специальной процедуре регистрации дополнительного соединения? Если они есть, то это работа фаервола, если нет — прокси?

С моей же точки зрения, подобные меры — это лишь небольшой формализм, упрощающий процесс получения данных о новых соединениях. И если фаервол может решать эти задачи на уровне ядра, то он, имхо, и должен это делать, не напрягая на это юзерспейс.

>Юзаю снорт, больше ничего и не пробовал толком.

Тоже на небольшом трафике?

пока - да.
на второй пост отвечу завтра, спать пора ж)

>> Я может чего не догоняю, благородные доны, но ZFS - copy on write. Какой там смысл в дефрагментации если данные не планируется делать readonly? :)

> Замечание абсолютно справедливое. Однако, некоторая польза все же есть - большие диапазоны свободного пространства способствуют позволяют писать последовательно на максимальной скорости.

Замечание абсолютно справедливое для случая с 1 диском. Для количества дисков >1 это существенно менее существенно. Для Ынтырпрайз массивов - не нужно.

> Имхо в сложившейся ситуации нужно кардинальное и общесистемное решение, например, выделение специальных полей в заголовках транспортного уровня. И тут уже в качестве легаси выступают TCP и UDP. Правда, сейчас им существуют альтернативы — SCTP и DCCP. К сожалению, с этими протоколами я знаком не очень хорошо. И вроде бы, структура IPv6 тоже имеет определенные возможности для расширения.

то что решение нужно, это я согласен. но вот чем тебе поможет новое поле в ИПв6? (добавить расширение туда не проблема). Вариантов не так много, имхо. Новых полей в транспортном уровне не надо, но можно бы увеличить размер поля "порт". Но ведь серверных портов все равно будет не хватать - слишком много протоколов. Мне кажется, нормальным выходом в стиле ИЕТФ стали бы публичные конекшн-прокси. А если подумать глобальнее, то если убрать нат, проблема отпадет фактически. а чтобы убрать нат, нужно внедрить ипв6. правда, тут уже рассуждают о т.н. carrier-scale nat, это будет ад для админов имхо.
SCTP и DCCP - классные протоколы, особенно SCTP, но много ли ты видел приложений, которые их используют? я кроме демонстрационных и своих поделок - ниодного. тут сильно тормозит МС и мс-ориентед девелоперы, вроде как мс стек не поддерживает СЦТП. по крайней мере, раньше не поддерживал. но проблему портов он бы не решил, все равно.

> Поправь если я ошибаюсь — с твоей точки зрения весь вопрос сводится к наличию выделенных полей в заголовках транспортного уровня и, при необходимости, специальной процедуре регистрации дополнительного соединения?

нет, дополнительные поля ничего не дадут. а вот если бы была унифицированная процедура регистрации дополнительного соединения... было бы здорово, ее траверсию вполне мог бы выполнять файрвол и создавать по необходимости дополнительные стейты. а так, получается, что ты точишь файрволл под каждый отдельный плохо спроектированный протокол, и это имхо идеалогически не верно. но приходится это делать, блин.

в любом случае, фтп менять никто не будет, например ж)

с SIPом вообще весело. нафига надо было включать ип адрес источника в заголовок пакета, причем два раза (в сдп он тоже есть)? слава богу, помагает обычный упнп или стун. глупо, все таки, разрабатывать протоколы без учета текущей ситуации в интернете, чтобы потом разрабатывать методы борьбы с недостатками этих протоколов

> Замечание абсолютно справедливое для случая с 1 диском. Для количества дисков >1 это существенно менее существенно.

Не согласен. Предположим, нужно записать, скажем, 4 МБ в пул из четырех дисков. По умолчанию и при прочих ZFS чередует диски каждые 512K (4 блока максимального размера), то есть на каждый диск придется по 1 МБ. Что быстрее - выделить место и записать этот 1 МБ одним куском или 8 кусками по 128КБ с перемещениями головки между операциями, если головки при этом будут передвигаться на минимальное расстояние в одном направлении (а не из туда-сюда начала в конец диска)?

> Для Ынтырпрайз массивов - не нужно.

Для ентерпрайз-массивов - да, но ZFS же любит и самые обычные диски. К тому же машинки типа Sun Fire X4540 и недавно обсуждавшегося самосборного аналога никто не отменял.

>Мне кажется, нормальным выходом в стиле ИЕТФ стали бы публичные конекшн-прокси.

Хм. А на какие шиши их обслуживать? Это даже не днс, когда деньги на обслуживание инфраструктуры можно, например, за регистрацию доменов наскрести.
Тем более нагрузка на них, как мне кажется, будет весьма значительна.
Ну и главное — это решает только половину проблемы (см. ниже).

>А если подумать глобальнее, то если убрать нат, проблема отпадет фактически

Отпадет только одна проблема — проход через нат. Проблема фильтрации соединений (на стороне клиента или сервера) все равно останется.

>а вот если бы была унифицированная процедура регистрации дополнительного соединения... было бы здорово, ее траверсию вполне мог бы выполнять файрвол и создавать по необходимости дополнительные стейты

Все уперлось в слово «унифицированная». Конечно, это более изящно, чем встраивать в фаервол набор шаблонов для разных соединений. Но имхо это просто формальность, упрощающая жизнь разработчикам фаервола. С точки зрения пользователей и админов того же линуха ситуация не изменится — подгрузил нужный модуль и сразу же получил профит. Сложившаяся де-факто ситуация — процедуры регистрации новых соединений не унифицированы, но они есть, и вполне юзабельны.

Ведь все равно приходится мириться с разнообразием, скажем, протоколов — у TCP свои заморочки, у UDP свои. Конечно, протоколов прикладного уровня больше, чем транспортного. Но ведь и связанные соединения используют отнюдь не все.

В общем, мне сложившаяся ситуация, конечно, не нравится, но ничего катастрофического я в ней не вижу. Разумеется, нужно принять меры, чтобы избежать подобных ошибок в будущем, но с тем, что уже сложилось, так или иначе придется работать. И я не вижу ничего зазорного в том, что фаервол лезет не только в заголовки, но и в payload. Главное, чтобы процедура жрала мало ресурсов и давала 100% эффективность (именно поэтому l7-filter в его современном виде мне не нравится).

>> Замечание абсолютно справедливое для случая с 1 диском. Для количества дисков >> 1 это существенно менее существенно.

> Не согласен. Предположим, нужно записать, скажем, 4 МБ в пул из четырех дисков. По умолчанию и при прочих ZFS чередует диски каждые 512K (4 блока максимального размера), то есть на каждый диск придется по 1 МБ. Что быстрее - выделить место и записать этот 1 МБ одним куском или 8 кусками по 128КБ с перемещениями головки между операциями, если головки при этом будут передвигаться на минимальное расстояние в одном направлении (а не из туда-сюда начала в конец диска)?

ZFS не пишет блоками больше 128К, поэтому 1М будет записан 8 кусками в любом случае. Для 1 диска - нужно будет записать 4 блока, пока будет записано 12 блоков на 3 оставшиеся. Последовательно они будут записаны или вразнобой в этом случае - несущественно. А если подумать сколько времени потребуется для дефрагментации дисков после 8 часов записи в COW?

> Хм. А на какие шиши их обслуживать? Это даже не днс, когда деньги на обслуживание инфраструктуры можно, например, за регистрацию доменов наскрести.
> Тем более нагрузка на них, как мне кажется, будет весьма значительна.

не то что бы оперейшнал костс днса полностью покрываются с регистрации. в основном, это деньги спонсоров.

> Ну и главное — это решает только половину проблемы (см. ниже).

насчет фильтрации, тут ты прав. но с этим придется жить =(

> Все уперлось в слово «унифицированная». Конечно, это более изящно, чем встраивать в фаервол набор шаблонов для разных соединений. Но имхо это просто формальность, упрощающая жизнь разработчикам фаервола. С точки зрения пользователей и админов того же линуха ситуация не изменится — подгрузил нужный модуль и сразу же получил профит. Сложившаяся де-факто ситуация — процедуры регистрации новых соединений не унифицированы, но они есть, и вполне юзабельны.

ты прав, я смотрю на этот вопрос с точки зрения девелопера (что естественно, я девелопер) =)
особенно раздражает ипв6. а ведь затея-то какая была - упростить всем жизнь! а получилось еще хуже.

> И я не вижу ничего зазорного в том, что фаервол лезет не только в заголовки, но и в payload. Главное, чтобы процедура жрала мало ресурсов и давала 100% эффективность (именно поэтому l7-filter в его современном виде мне не нравится).

вот в этом-то все дело. если уж лазить в прикладной уровень, то логично пойти дальше и реализовать полноценный л7 фильтр. а это оверкилл и большинству вообще не нужно, особенно если учесть вероятное потребление ресурсов. полный л7 без гигантских нагрузок на проц не будет. именно поэтому я вспомнил мс форефронт (ниче-такой л7, к слову).

> ZFS не пишет блоками больше 128К,

Утверждение неверно в общем случае. Оно было бы верным, если бы звучало, например, так - в настоящее время ZFS не использует логические блоки размером более 128КБ.

А вот какими кусками (заметьте, не блоками!) данные попадают на диск - зависит от того, насколько эффективно сработает аггрегация записи, что в свою очередь определяется тем, можем ли мы выделять пространстро непрерывно или нет, а также некоторыми другими факторами. Все подробности можно найти здесь:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/z...

> поэтому 1М будет записан 8 кусками в любом случае.

Так что 8 логических блоков размером 128К каждый может быть записан одним куском в 1М, а может и гораздо большим количеством кусочков размера даже меньшего, чем размер логического блока

> Для 1 диска - нужно будет записать 4 блока, пока будет записано 12 блоков на 3 оставшиеся. Последовательно они будут записаны или вразнобой в этом случае - несущественно.

Данные на эти диски будут писаться параллельно (если ресурсы позволяют), так что если на одном диске логические блоки расположатся последовательно один за другим без промежутков, то они их можно будет склеить в одну большую операцию , сэкономив, таким образом, как минимум 7 seek'ов. А это знаете ли время, и весьма ограниченный ресурс обычных дисков.

Если бы это было не важно, скажите, зачем бы стали заморачиваться с исправлением вот этого, например, бага:

6854621 RAID-Z should mind the gap on writes http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6854621

> А если подумать сколько времени потребуется для дефрагментации дисков после 8 часов записи в COW?

Да сколько бы ни потребовалось - есть случаи, когда это может быть необходимо. Кстати, как минимум имеет смысл дефрагментировать снимки - они ведь не изменяются. С учетом того, что их можно делать много, можно получать вполне себе измеримый профит от их дефрагментации

> Утверждение неверно в общем случае....
> Все подробности можно найти здесь: ...
> зависит от того, насколько эффективно сработает аггрегация записи

Теоретизировать можно сколько угодно. Сделай zpool побольше, проведи тесты на чтение запись блоками разной длинны, поизучай статистику iostat. После этого можно обсудить насколько переменной длинны блок у zfs и как она аггрегирует данные для записи. Могу изложить свои наблюдения, но боюсь они расходятся с тем что пишут в интернетах.

> Так что 8 логических блоков размером 128К каждый может быть записан одним куском в 1М

Не может. См. абзац выше.

> сэкономив, таким образом, как минимум 7 seek'ов

Это может верно для случая когда один процесс занимается последовательной записью. Если процессов выполняющих ввод-вывод несколько - слова про 7 сэкономленных сиков смешны.

> есть случаи, когда это может быть необходимо.

Попросил бы пример. но см. 2 абзаца ниже :)

> Кстати, как минимум имеет смысл дефрагментировать снимки

Это, как мнимум бред. Прошу прощения. Если не меняются исходные данные - при чем тут снимки? Если меняются - что дефрагметировать?

Сдается мне, эту дискуссию пора заканчивать)

> Теоретизировать можно сколько угодно. Сделай zpool побольше, проведи тесты на чтение запись блоками разной длинны, поизучай статистику iostat. После этого можно обсудить насколько переменной длинны блок у zfs и как она аггрегирует данные для записи. Могу изложить свои наблюдения, но боюсь они расходятся с тем что пишут в интернетах.

Излагайте, вместе с методикой проведения измерений и наблюдений.

>> Так что 8 логических блоков размером 128К каждый может быть записан одним куском в 1М

>Не может. См. абзац выше.

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

>> сэкономив, таким образом, как минимум 7 seek'ов

> Это может верно для случая когда один процесс занимается последовательной записью. Если процессов выполняющих ввод-вывод несколько - слова про 7 сэкономленных сиков смешны.

Даже если их несколько, в тот момент, когда дело доходит до записи непосредственно на диск, блоки, имеющие общую границу, аггрегируются. При этом, конечно, количество сэкономленныз seek'ов может оказаться и меньше, но даже если из окажется не семь, а два, это все равно будет выигрыш.

>> есть случаи, когда это может быть необходимо.

>Попросил бы пример. но см. 2 абзаца ниже :)

Примеров можно найти в архивах zfs-discuss@opensolaris.org. Народ в некоторых случаях даже был вынужден делать дефрагментацию путем 'zfs send | zfs receive" в новый пустой пул.

>> Кстати, как минимум имеет смысл дефрагментировать снимки

> Это, как мнимум бред. Прошу прощения. Если не меняются исходные данные - при чем тут снимки? Если меняются - что дефрагметировать?

Я бы рекомендовал вам быть помегче в высказываниях. Дефрагментация может осуществляться с разными целями. В случае дефрагментации файлов цель, как правило, расположить блоки файла последовательно. Однако можно делать и другую дефрагментацию - дефрагментацию свободного пространства, с целью получить большее количество свободных областей большего размера, чтобы впоследствии можно было более эффективно производить запись в эти области, иными словами, чтобы аггрегации было где развернуться. Так вот снапшоты могут быть идеальным кандидатом для этого - их содержимое не меняется.

> Сдается мне, эту дискуссию пора заканчивать)

Потому что аргументов, кроме "это, как минимум бред" не осталось, а признать недостаточную аргументированность собственной позиции не получается? Так пожалуйста, вам никто не мешает закончить эту дискуссию в любой момент.

> Если у вас не получилось, это не означает, что это невозможно в принципе.

Можно тест, из результатов которого будет видно что zfs пишет блоками по 1М? )

> Излагайте, вместе с методикой проведения измерений и наблюдений.

Простейший тест - на свежей zfs запустить создание большого файла, блоками например от 8 до 512К и посмотреть в иостате какими блоками идет запись на диск.

Чуть более сложный - на полученном файле запустить случайную запись блоками по 8К в несколько потоков и посмотреть какими блоками идет ввод-вывод. Возможно, удивиться, почему не смотря на 100% запись идет чтение-запись блоками по 128К :)

Попробовать уменьшить recsize для файловой системы, прогнать те-же тесты и сравнить производительность.

Мои результаты говорят мне, что zfs в большинстве случаев (т.е. почти во всех) кладет на всё и использует блок 128К, попытка указать recsize меньше ведет к падению производительности. Причем, как для фс так и для zvol-ов.

> Народ в некоторых случаях даже был вынужден делать дефрагментацию путем 'zfs send | zfs receive" в новый пустой пул.

В моем случае как был поток ~600Мб/сек полгода назад, так и остался. И к слову - да, я считаю что ZFS сильно грузит процессор, даже на многопроцессорных энтерпрайзах характер работы ОС меняется очень сильно. Но zfs, буквально как тузик грелку рвет ufs. В моем случае.

По поводу остального

> но даже если из окажется не семь, а два, это все равно будет выигрыш.

Да, сохраним весьма ограниченный ресурс жесткого диска. Сколько времени и сиков потребуется для дефрагментации? )

> тобы аггрегации было где развернуться
как широко? :) если речь о 128К-1М - где это будет существенно?

> Так вот снапшоты могут быть идеальным кандидатом для этого - их содержимое не меняется.

Что именно не меняется? И что считать снапшотом? Неизмененные блоки которые являются общими для фс и для снапшота, измененные блоки фс, которые относятся к снапшоту, или что? и что из них нужно дефрагментировать и когда?

> Я бы рекомендовал вам быть помегче в высказываниях.

А то что? :)

Чтобы не разводить флейма, попытаюсь выразить мое отношение к дефрагментации в ZFS в целом ) Для нескольких дисков дефрагментация может быть проблемой, но как правило в этом случае не нужен ZFS :) В случае массивов среднего уровня и выше дефрагментация не zdkztncz проблемой. Поэтому, по моему мнению, дефрагментатор zfs (как и вообще *fs) - проблема домашних компьютеров. Поэтому вероятность ее появления соответствующая. Как и в случае ext*/ufs/etc.

> Можно тест, из результатов которого будет видно что zfs пишет блоками по 1М? )

А если будет видно, что пишутся куски 800КБ или 2МБ, это будет считаться?

> Простейший тест - на свежей zfs запустить создание большого файла, блоками например от 8 до 512К и посмотреть в иостате какими блоками идет запись на диск.

И что? То, какими блоками это в конечном итоге идет на диск зависит и от нижележащих уровней.

> Чуть более сложный - на полученном файле запустить случайную запись блоками по 8К в несколько потоков и посмотреть какими блоками идет ввод-вывод. Возможно, удивиться, почему не смотря на 100% запись идет чтение-запись блоками по 128К :)

Вас это удивляет? Меня нет. Ожидаемое поведение.

> Попробовать уменьшить recsize для файловой системы, прогнать те-же тесты и сравнить производительность.

Надеюсь, прежде чем прогонять те же самые тесты после изменения recordsize вы файл скопировали, а старый удалили?

> Мои результаты говорят мне, что zfs в большинстве случаев (т.е. почти во всех) кладет на всё и использует блок 128К, попытка указать recsize меньше ведет к падению производительности. Причем, как для фс так и для zvol-ов.

Скорее всего, вы что-то делаете не так.

> В моем случае как был поток ~600Мб/сек полгода назад, так и остался. ... Но zfs, буквально как тузик грелку рвет ufs. В моем случае.

Рад за вас. Знаю случаи, когда эффекты фрагментации свободного пространства начинали проявляться на почти пустом пуле. Но это уже пофиксили.

>Да, сохраним весьма ограниченный ресурс жесткого диска. Сколько времени и сиков потребуется для дефрагментации? )

Ответ - it depends. Память нынче дешевая, опять же L2ARC есть, так что seek'ов может понадобится не так уж и много, это во-первых. Во-вторых, она может делаться тогда, когда эти seek'и никому не нужны - в периоды минимальной нагрузки и с минимальным приоритетом.

> как широко? :) если речь о 128К-1М - где это будет существенно?

Это может быть очень существенно при записи блоков ZIL, если активность синхронной записи высокая.

>> Так вот снапшоты могут быть идеальным кандидатом для этого - их содержимое не меняется.

> Что именно не меняется? И что считать снапшотом? Неизмененные блоки которые являются общими для фс и для снапшота, измененные блоки фс, которые относятся к снапшоту, или что? и что из них нужно дефрагментировать и когда?

Да я ж сверху по-русски вроде написал. Содержимое снимков не меняется. С точки зрения пользователя снимок - это зафиксированное состояния его данных на определенный момент времени. А уж то, как и где эти данные располагаются и остаются ли при этом неизменными метаданные - это уже особенности реализации.

Если между локами данных снимка есть участки свободного пространства, их можно консолидировать, перемещая, но не изменяя при этом блоки данных снимка.

>> Я бы рекомендовал вам быть помягче в высказываниях.

> А то что? :)

А должно обязательно быть что-то? Просто так, из уважения к собеседнику.

> Чтобы не разводить флейма, попытаюсь выразить мое отношение к дефрагментации в ZFS в целом ) Для нескольких дисков дефрагментация может быть проблемой, но как правило в этом случае не нужен ZFS :) В случае массивов среднего уровня и выше дефрагментация не zdkztncz проблемой. Поэтому, по моему мнению, дефрагментатор zfs (как и вообще *fs) - проблема домашних компьютеров. Поэтому вероятность ее появления соответствующая. Как и в случае ext*/ufs/etc.

Дефрагментация является проблемой - дефрагментатора пока нету :-) Фрагментация же может являться, а может нет - это зависит от активности приложений/пользователей, политики создания/удаления снимков, активности синхронной записи при отсутствии LogZilla.

>насчет фильтрации, тут ты прав. но с этим придется жить =(

Вооот. Итак, IPv6 не дает полноценного решения обсуждаемой проблемы.

Кроме того, ВНЕЗАПНО вспомнился еще один класс задач (акромя фильтрации и ната), для которых связанные соединения создают трудности — это классификация пакетов для QoS и динамической маршрутизации.

Собсно, интересно твое мнение, как правильно решать эту задачу средствами pf.

>если уж лазить в прикладной уровень, то логично пойти дальше и реализовать полноценный л7 фильтр. а это оверкилл и большинству вообще не нужно

Во-во. Поэтому логичнее (имхо) остановиться там, где заканчивается высокая эффективность при низком потреблении ресурсов.
Все-таки полноценный классификатор седьмого уровня нужен для довольно узкого класса задач. Например, лично мне в линухе вполне хватает отслеживания связанных соединений + критерия ipp2p, позволяющего без особых проблем выделять наиболее распространенные P2P-сети. И не могу вспомнить случаев, чтобы этого не хватало. Ну а все, что сверх того — художественные экзерсисы, которые мало кому нужны. В крайнем случае, пусть циску ставят :)

> Кроме того, ВНЕЗАПНО вспомнился еще один класс задач (акромя фильтрации и ната), для которых связанные соединения создают трудности — это классификация пакетов для QoS и динамической маршрутизации.

насчет динамической маршрутизации, то я не вижу, в чем тут проблема (может я просто туплю под вечер). а что касается qos, то тут должно применять ровно то же решение, что и для фильтра.
вот когда будет очень интересная проблема, так это если применяется, например, rsvp. вот тогда связанные соединения действительно могут быть очень неприятными, и, как минимум, рсвп тут будет вносить гораздо большую задержку на установление соединения, чем в случае с одним поток. вообще, все решения базирующиеся на попытках выделить в connectionless ip трафике потоки сильно страдают от этой фигни.

> Собсно, интересно твое мнение, как правильно решать эту задачу средствами pf.

прозрачные прокси. сегодня, это не дает всего того, чего бы хотелось, но хотя бы базовую функциональность обеспечивает.

> В крайнем случае, пусть циску ставят :)

я лично активно против цисок там, где их можно избежать. и л7 фильтр это задача ну _совсем_ не для кисок, с их игрушечными процессорами.

> вот когда будет очень интересная проблема, так это если применяется, например, rsvp. вот тогда связанные соединения действительно могут быть очень неприятными, и, как минимум, рсвп тут будет вносить гораздо большую задержку на установление соединения, чем в случае с одним поток. вообще, все решения базирующиеся на попытках выделить в connectionless ip трафике потоки сильно страдают от этой фигни.

кстати, а что для такой фигни можно сделать в линуксе? есть что-то?

>> Можно тест, из результатов которого будет видно что zfs пишет блоками по 1М? )
> А если будет видно, что пишутся куски 800КБ или 2МБ, это будет считаться?

Вполне. Прошу.

> И что? То, какими блоками это в конечном итоге идет на диск зависит и от нижележащих уровней.

zfs - часть ядра, iostat - уровень ядра. От каких более нижних уровней зависит размер блока записи файловой системы и как их увидеть?

>насчет динамической маршрутизации, то я не вижу, в чем тут проблема (может я просто туплю под вечер)

Не-не-не, такие монстры как BGP, RIP, OSPF здесь ни при чем.
Речь шла о простых (решаемых локально) задачах, например, стохастическая балансировка между несколькими провайдерами, или балансировка на основании загруженности доступных каналов (в линухе это делается все тем же iptables + iproute2). При этом может понадобиться пустить весь «куст» связанных соединений через один канал. Скажем, если управляющее соединение FTP пойдет через одного прова с одним айпишником, а соединение данных — через другого прова с другим айпишником, навряд ли получится корректно отфильтровать последнее в точке назначения.

>а что касается qos, то тут должно применять ровно то же решение, что и для фильтра.

Т.е. прозрачная прокся добавляет правила для заворота на ALTQ?

>л7 фильтр это задача ну _совсем_ не для кисок, с их игрушечными процессорами

В каждой шутке есть доля шутки :)
Емнип, цискари очень понтовались своей л7-фильтрацией. Вот пусть и расхлебывают :)

>кстати, а что для такой фигни можно сделать в линуксе? есть что-то?

К сожалению, абсолютно не в курсе проблемы :(

> Речь шла о простых (решаемых локально) задачах, например, стохастическая балансировка между несколькими провайдерами, или балансировка на основании загруженности доступных каналов (в линухе это делается все тем же iptables + iproute2). При этом может понадобиться пустить весь «куст» связанных соединений через один канал. Скажем, если управляющее соединение FTP пойдет через одного прова с одним айпишником, а соединение данных — через другого прова с другим айпишником, навряд ли получится корректно отфильтровать последнее в точке назначения.

ну, это уже чисто линуксовые развороты, вот пусть иптаблес их и разруливает. весь остальной мир для мультихоминга использует нормальный бгп.

> Т.е. прозрачная прокся добавляет правила для заворота на ALTQ?
т.е. именно с альтекью она пока и не работает, и это в минус. впрочем, можно написать генерик правила для заворацивания траффика по очередям, а уже фильтровать и натить его правилами, добавляемыми проксей в анчор. работать будет вполне себе нормально.

> Емнип, цискари очень понтовались своей л7-фильтрацией. Вот пусть и расхлебывают :)
у них очень классный л7. на железках $8.000+ (и это еще для не очень большой нагрузки, так сказать, минимальная конфигурация для среднего офиса)

> К сожалению, абсолютно не в курсе проблемы :(
жаль =(
я бы с удовольствием послушал авторитетное мнение по данному вопросу. может, hizel бы что сказал, если он нас каким-то чудом читает?

>весь остальной мир для мультихоминга использует нормальный бгп.

Ключевое слово было «простые» :)
Допустим, у тебя дома есть два (или даже три) провайдера. Сразу возникает идея сделать как минимум отказоустойчивость, как максимум — балансировку нагрузки. Неужели ты для этого openbgpd поднимать будешь? Может, еще и AS официально зарегистрируешь? ;)

Айпистолы отлично понимают условия вида «если такой-то интерфейс поднят» (iface), «если такая-то переменная истинна» (condition), «если свободная полоса у канала A сейчас больше, чем у канала B» (rateest), «каждый n-й раз» или «с заданной вероятностью» (statistic) и т.п. В зависимости от этих условий можно выставлять ту или иную маркировку соединений, и она автоматом скопируется на весь «букет». После чего в игру вступают правила роутинга. Все достаточно просто и прозрачно.
А какие аналоги этому есть в опенке?

>впрочем, можно написать генерик правила для заворацивания траффика по очередям

Мм, не понял. А если, допустим, FTP-трафику нужен один приоритет, HTTP-трафику другой, сипу третий? Ведь основная нагрузка приходится как раз на «побочные» коннекты.

> Ключевое слово было «простые» :)
> Допустим, у тебя дома есть два (или даже три) провайдера. Сразу возникает идея сделать как минимум отказоустойчивость, как максимум — балансировку нагрузки. Неужели ты для этого openbgpd поднимать будешь? Может, еще и AS официально зарегистрируешь? ;)

дома я такого не использую, только фейловер, а так - да, конечно.

> А какие аналоги этому есть в опенке?

по пунктам:

> условия вида «если такой-то интерфейс поднят» (iface)
ifstated

> «если такая-то переменная истинна» (condition)
match? без контекста непонятно, пф не язык программирования, в отличие от. это и преимущество, и недостаток

> «если свободная полоса у канала A сейчас больше, чем у канала B» (rateest)

я не совсем понимаю, как файрволл может определить свободную пропускную способность канала. это непредсказуемая игра в неправдивый расчет, имхо. такого, на сколько мне известно, в пф нет.

> «каждый n-й раз» или «с заданной вероятностью» (statistic)
это есть.

> После чего в игру вступают правила роутинга.

вообщем, эта твоя схема реализуема и на опене, особенно с появлением множественных таблиц маршрутизации.

> Мм, не понял. А если, допустим, FTP-трафику нужен один приоритет, HTTP-трафику другой, сипу третий? Ведь основная нагрузка приходится как раз на «побочные» коннекты.

ну да, а что тут не так? (hint: match keyword)


я ни в коем случае не спорю, что всяких разных "плюшек" на все случаи жизни в линуксе больше ;)

к слову, ничего этого не светит в пф из фрибсд. он там слишком стар и не интегрирован со всем остальным. я уж не говорю про динамическую маршрутизацию.

>match? без контекста непонятно

Просто в глубинах procfs создается специальный каталог, в котором лежат специальные файлики. В эти файлы можно писать нули и единички. Каждый файл соответствует логической переменной. В общем, простой способ наладить взаимодействие между фаерволом и произвольной юзерспейсовкой прогой без изменения списка правил.

>я не совсем понимаю, как файрволл может определить свободную пропускную способность канала.

Строго говоря, под этим подразумевалась разность между гарантированной пропускной способностью и занятой полосой. Гарантированная полоса задается ручками, а занятую фаерволу померить не проблема. Согласен, для нефиксированной ширины полосы это не работает :) Но я же про домашних провайдеров.

>вообщем, эта твоя схема реализуема и на опене, особенно с появлением множественных таблиц маршрутизации.

Это хорошо. Но если вернуться к первоначальному вопросу — будут ли там проблемы со связанными соединениями?

>ну да, а что тут не так? (hint: match keyword)

Потыкал в pf faq, перешерстил весь man pf.conf, но ничего более вразумительного, чем match in all scrub не нашел. Можешь специально для тупого меня скинуть ссылку на понятное объяснение?

> Просто в глубинах procfs создается специальный каталог, в котором лежат специальные файлики. В эти файлы можно писать нули и единички. Каждый файл соответствует логической переменной. В общем, простой способ наладить взаимодействие между фаерволом и произвольной юзерспейсовкой прогой без изменения списка правил.

нет, такого нет. но есть возможность применять якори, в принципе их тоже просто использовать.

> Это хорошо. Но если вернуться к первоначальному вопросу — будут ли там проблемы со связанными соединениями?

нет, не должно быть проблем, разумеется, при грамотной настройке. не поленился, попробовал. с активным/пассивным фтп вполне работает.

> Потыкал в pf faq, перешерстил весь man pf.conf, но ничего более вразумительного, чем match in all scrub не нашел. Можешь специально для тупого меня скинуть ссылку на понятное объяснение?

ну тут все просто. там, где раньше можно было писать только пасс/блок, теперь можно делать матч, каким-то образом меняя параметры подпадающих под правило пакетов, но не определяя действие для них. например:
match proto tcp port ssh tag SSH
match tagged SSH queue qssh
match in from $lan rtable 2
match in from <admin> route-to { ($if1 $gw1), ($if2 $gw2) } source-hash dup-to $loghost
такие правила будут менять поведение пф с пакетами, но не повлияют на конечное решение - пропустить или заблокировать.

>match tagged SSH queue qssh

Да, про тегирование я и забыл. Вот что значит середина ночи и хронический недосып :)

Ага, понял. И параметр -T у ftp-proxy?

>не поленился, попробовал. с активным/пассивным фтп вполне работает.

А что служило в качестве критерия выбора канала?
И интересно было бы посмотреть конфиг.

> Ага, понял. И параметр -T у ftp-proxy?
да ж)

> А что служило в качестве критерия выбора канала?
ип источника + тег о фтп. я держу отдельные очереди для себя и брата, а в них разделяю траффик на несколько категорий.

> И интересно было бы посмотреть конфиг.
потом, хорошо? я не дома.

кстати, я где-то прослоупочил, теперь ftp-proxy имеет ключ -q с помощью которого можно указать очередь, которую присваивать фтп коннекшенам. но так все они попадут в одну очередь, а я по старинке тэгами могу нарезать, как мне надо.

и еще кстати, благодаря новому синтаксису пф, теперь правила, необходимые для включения фтп-прокси сократились до двух:
anchor "ftp-proxy/*"
pass in quick proto tcp to port ftp rdr-to 127.0.0.1 port 8021

pf подходит для более-менее простых случаев. для чего-то интересного - уже не судьба.

выше уже упоминали про сип.
К примеру, оба клиента за nat(pf) и пытаются друг другу позвонить. sip proxy при этом имеет public ip.
сильно сомневаюсь, что без костылей в виде stun у них это получится.

так же, выше упоминали sctp: максимум, что может пф - это заблочить/разрешить его по номеру протокола в заголовке пакета. iptables этот протокол понимает так же хорошо, как и tcp.

Далее, добавление своих модулей в pf. Например, я хочу добавить sctp в pf. Для iptables есть прекрасная документация по написанию своих расширеший, всё что нам надо - это хидеры iptables и хидеры ядра.
а в pf?

и у пф беда с производительностью: он работает только на одном ядре, а при любых операциях по удалению/добавлению стейтов блочится целиком.

>ип источника + тег о фтп

Если я все правильно понял, получается практически статика :(
А меня интересовала как раз динамика, хотя бы в таком простейшем виде, как probability.
Или ты полагаешь, что подобные задачи следует решать _только_ на уровне BGP?

>> ип источника + тег о фтп
> Если я все правильно понял, получается практически статика :(

эммм.. не понял.

> А меня интересовала как раз динамика, хотя бы в таком простейшем виде, как probability.

ты хочешь, чтобы пакеты иногда попадали в одну очередь, а иногда в другую?

это все, по большому счету, справедливо, но я попытаюсь на кое-что ответить.

> pf подходит для более-менее простых случаев. для чего-то интересного - уже не судьба.

да ладно тебе, у меня в хозяйстве есть очень большие и сложные рулесеты, и все пучком. тем не менее, я не стану спорить, что иптейблс гибче, это действительно так. однако ситуаций, где нельзя было бы извернуться на пф исчезающе мало, а главные его достоинства - это простота и интеграция с остальным сетевым хозяйством.

> выше уже упоминали про сип.
> К примеру, оба клиента за nat(pf) и пытаются друг другу позвонить. sip proxy при этом имеет public ip.
> сильно сомневаюсь, что без костылей в виде stun у них это получится.

речь шла о сип прокси не в терминологии сип, а в терминологии коннекшенов, грубо говоря. по сути, это такой же костыль, как и для фтп, только для сип ж) да, без него или без стуна не пойдет. ну и что? он решает по-сути ту же задачу, что и этот ваш модуль для иптаблеса, только немного по-другому - это отдельная приблуда.

> так же, выше упоминали sctp: максимум, что может пф - это заблочить/разрешить его по номеру протокола в заголовке пакета. iptables этот протокол понимает так же хорошо, как и tcp.

это да, минус. пока полноценной поддержки нет, как и для dccp, afaik.
с другой стороны, много ли ты знаешь приложений, которые им реально пользуются? напиши их названия, если не сложно, я давно хочу на него глянуть что называется, in the wild.

> Далее, добавление своих модулей в pf. Например, я хочу добавить sctp в pf. Для iptables есть прекрасная документация по написанию своих расширеший, всё что нам надо - это хидеры iptables и хидеры ядра.
> а в pf?

а в пф есть очень грамотный и простой пф.ц. даже я в нем без труда разобрался. не нужно писать модуль, нужно написать одну свою функцию и добавить ее вызов в pf_test()

> и у пф беда с производительностью: он работает только на одном ядре, а при любых операциях по удалению/добавлению стейтов блочится целиком.

это фактически беда всего опена. кернел только на бут процессоре. с этим постепенно борятся, вычищая биглок.

>однако ситуаций, где нельзя было бы извернуться на пф исчезающе мало, а главные его достоинства - это простота и интеграция с остальным сетевым хозяйством.

если речь про openbsd - возможно. в той же freebsd - это пятая нога.

к примеру, на пф не нарисовать вот такое:
http://citrin.ru/freebsd:ng_ipfw_ng_bpf (зачем это было нужно: http://ospf-ripe.livejournal.com/2194.html)

нельзя интеллектуально шейпить(например, ставить долгоиграющие закачки в более низкоприоритетную очередь, а коротким пакетам давать больший приоритет).

в случае ethernet-линков, пф ничего не знает о mac-адресах(да, я в курсе что пф - это L3/L4)
Хотя, название свое он оправдывает: пакетный фильтр.

>он решает по-сути ту же задачу, что и этот ваш модуль для иптаблеса, только немного по-другому - это отдельная приблуда.

так ведь слишком много приблуд надо, чтобы всё работало. Тем более, вопрос производительности никто не отменял.

>с другой стороны, много ли ты знаешь приложений, которые им реально пользуются? напиши их названия, если не сложно, я давно хочу на него глянуть что называется, in the wild.

реально - это sigtran, которым мы активно пользуемся. Ещё - AMQP, но этого у нас нет.

>а в пф есть очень грамотный и простой пф.ц. даже я в нем без труда разобрался.

ужос там. сравните, например, с этим:
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/net/netfilter/xt_connbytes.c

> не нужно писать модуль, нужно написать одну свою функцию и добавить ее вызов в pf_test()

вот это и плохо. т.е. выливается это всё либо в пересборку ядерного модуля + pfctl, либо ядра + pfctl.

Для расширения iptables надо лишь хидеры iptables + хидеры ядра.

>это фактически беда всего опена. кернел только на бут процессоре. с этим постепенно борятся, вычищая биглок.

у меня на трафике в ~ 80kpps пф начинал вести себя неадекватно. Ессно, настройки стейтов были неумолчальные(увеличен лимит на их число).

Для сравнения: linux у меня прекрасно жил при 2.5млн стейтов и трафике в 130-160kpps.

у меня на трафике в ~ 80kpps пф начинал вести себя неадекватно. Ессно, настройки стейтов были неумолчальные(увеличен лимит на их число).

Для сравнения: linux у меня прекрасно жил при 2.5млн стейтов и трафике в 130-160kpps.

Для сравнения: http://forum.nag.ru/forum/index.php?act=Print&client=printer&f=3&...

Автор: jab 14.8.2008, 21:02

Цитата(inxs @ 14.8.2008, 19:54) * jab, а сколько ваш фряшный бордер с натом вытягивает мегабит и ппс? (в пике)

С натом и BGP full view ? По pps я честно говоря его выше 180kpps не разгонял, не было необходимости. Час пик уже прошел... Покажу что есть в данный момент.

== # netstat -w1 input (Total) output packets errs bytes packets errs bytes colls 128130 0 79788655 127818 0 79482180 0 121542 0 75465803 121252 0 75157305 0 124374 0 77834445 124089 0 77548316 0 123320 0 75186138 122985 0 74879403 0 123846 0 75480545 123521 0 75116702 0 124009 0 74640749 123653 0 74342600 0 123523 0 74245890 123169 0 73898181 0 120299 0 73143371 119931 0 72851570 0 120553 0 73749712 120194 0 73457174 0 124835 0 77081028 124496 0 76779200 0

== pf nat:

Status: Enabled for 210 days 05:35:21 Debug: Urgent

State Table Total Rate current entries 99467 searches 1824079804380 100422.1/s inserts 17189382859 946.3/s removals 17189283392 946.3/s

== top

last pid: 44559; load averages: 1.88, 1.96, 1.97 up 210+05:36:44 22:00:15 20 processes: 1 running, 19 sleeping CPU states: 0.0% user, 0.0% nice, 46.1% system, 28.6% interrupt, 25.4% idle Mem: 338M Active, 3052K Inact, 66M Wired, 87M Buf, 347M Free Swap:

Этот бордер старый, ( CPU: Intel® Core™2 CPU 6600 @ 2.40GHz ) на нем 6.2-RELEASE c polling и kern.polling.idle_poll=1, новые бордеры на 7.0 показывать не буду. :-) Пусть клевещут.

молодец, iZEN догадался что сморозил бред про sctp и удалил сообщение.

Потому что таки да, conntrack умеет стейты для sctp.

>Для сравнения: http://forum.nag.ru/forum/index.php?act=Print&client=printer&f=3&...

и? давно я эти цифры видел, ещё в 2008.

Только вот когда осознать о чём речь идёт знаний не хватает, ты начинаешь кидаться ссылками на статьи с похожими словами.

по тем цифрам, что привел jab:

121kpps, current entries 99467 searches 1824079804380 100422.1/s inserts

121kpps и 100k стейтов. в моих цифрах 130-160kpps при 2.5млн стейтов.
причём, у меня камень с меньшим кэшем и я не заморачивался с балансировкой по 2м ядрам(у jab'а - E6600 с 4Мб L2, у меня - E2180 с 1Мб L2)

Как выше уже говорил, pf живёт только на 1 ядре, в отличие от iptables.

И в догонку: в linux есть LC-trie, позволяющий делать 80млн лукапов по RIB в секунду на p4 2.8GHz.

Vyatta вообще отрапортовалась о возможности отроутить 10G.

>ты хочешь, чтобы пакеты иногда попадали в одну очередь, а иногда в другую?

Вообще-то речь шла о случайном выборе провайдера. И, разумеется, не для отдельных пакетов, а для каждого нового соединения. Так можно?

> если речь про openbsd - возможно. в той же freebsd - это пятая нога.

об OpenBSD, конечно. ты мне скажи, что у фри не пятая нога и реализовано архитектурно грамотно?

> к примеру, на пф не нарисовать вот такое:
> http://citrin.ru/freebsd:ng_ipfw_ng_bpf (зачем это было нужно: http://ospf-ripe.livejournal.com/2194.html)

это интересно. я думаю, покопаюсь в этом, может и добавлю поддержку таких финтов в пф. достаточно ли будет возможности фильтровать по значению произвольного набора байт (линки смотрел вскользь)? типа так:

pass in inet proto tcp bytes L5 [40] = 0xFE #сороковый байт начиная с конца заголовка тцп должен быть равен ФЕ в хексе
pass in inet bytes L3 [40:42] >= 1234567 #байты с сорокового по сорок второй начиная с начала заголовка ИП должны быть больше или равны 1234567

есть пожелания?

> нельзя интеллектуально шейпить(например, ставить долгоиграющие закачки в более низкоприоритетную очередь, а коротким пакетам давать больший приоритет).

нельзя. но можно делить пакеты по тосу и ак/не ак в тцп.

> в случае ethernet-линков, пф ничего не знает о mac-адресах(да, я в курсе что пф - это L3/L4)
> Хотя, название свое он оправдывает: пакетный фильтр.

да, тут именно что так и задумано. а насчет маков, так можно поднять фильтр соответствия мака заданной айпишке, и отбрасывать непроходящие по этому критерию кадры еще до ip_input()

> вот это и плохо. т.е. выливается это всё либо в пересборку ядерного модуля + pfctl, либо ядра + pfctl.

забудем про фрю, в пересборку ядра. для меня это не проблема и не вопрос, если пишешь нечто в ядре. модули - удобно, но совершенно не критично.

> у меня на трафике в ~ 80kpps пф начинал вести себя неадекватно.
> Ессно, настройки стейтов были неумолчальные(увеличен лимит на их число).

хммм. 100кппс и 3.5 ляма стейтов. все пучком. хотел бы посмотреть на больший пакетрейт, но у меня больше нет, у меня лоадбалансинг с фейловером через carp+pfsync. пробовать прибить одну ноду не буду, а то если упадет, то меня уволят и опен снесут нахрен в пользу цисок, которые до моего прихода и стояли.

>> ты хочешь, чтобы пакеты иногда попадали в одну очередь, а иногда в другую?

> Вообще-то речь шла о случайном выборе провайдера. И, разумеется, не для отдельных пакетов, а для каждого нового соединения.

а, я думал это еще относится к фтп-прокси и очередям.

> Так можно?

да, конечно. есть несколько вариантов: для соединений, рандомно, поочереди, с определенными долями (probability) и тд...

> Vyatta вообще отрапортовалась о возможности отроутить 10G.
это интересно. на каком железе? они, кстати, таки дальше на квагге?

>> он решает по-сути ту же задачу, что и этот ваш модуль для иптаблеса, только немного по-другому - это отдельная приблуда.

> так ведь слишком много приблуд надо, чтобы всё работало. Тем более, вопрос производительности никто не отменял.

зато они все отдельные. модульность, епт. с точки зрения пф, никакой дополнительной поддержки не надо, все и так есть.
а производительность вполне адекватная, хватает пакеты ведь не идут через юзерспейс, прокси только смотрит установку соединения и добавляет нужные правила в пф, все остальное - стандартная работа пф.

> реально - это sigtran, которым мы активно пользуемся. Ещё - AMQP, но этого у нас нет.

спасибо большое.

> ужос там. сравните, например, с этим:
> http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/net/netfilter/xt_connbytes.c

мда. действительно очень просто. тем не менее, и пф.с тоже не то чтобы кошмарен =)

>да, конечно. есть несколько вариантов: для соединений, рандомно, поочереди, с определенными долями (probability) и тд...

Хорошо.
Ну и возвращаясь к исходному вопросу: можно ли в эту схему корректно впихнуть ftp-proxy?

>что у фри не пятая нога и реализовано архитектурно грамотно?

GEOM и NetGraph?

>Как выше уже говорил, pf живёт только на 1 ядре, в отличие от iptables.

Если почитать форум nag.ru, то PF уже давно и успешно похоронили под IPFW, и именно там, где IPTABLES не хватает.