Комментарии 43
NATasha улыбнуло
NAS у вас в смысле Network Access Server? а то я поначалу пытался понять нафига НАТаша, если клиентам инет отдает NAS(в смысле Network Attached Storage)
Интересно посмотреть сравнительные тесты производительности этого и других натов под фри. Я наблюдал, что пф работает шустрее чем натд, нужно полагать, что этот будет шустрее обоих.
Сравнивать практически нечего :)
natd захлебывается уже на 40-50 мбит на квадкоре в независимости от глубины тюнинга. pfnat я использовал на скоростях до 80-ти мбит (субьективно на момент перехода работал так же как и вышеописаный по продуктивности) а дальше уполз с него на ipfw nat который успешно прожевывает на данный момент в районе 350-400 мбит на каждом из хостов.
У pf насколько помниться проблемы с smp.
natd захлебывается уже на 40-50 мбит на квадкоре в независимости от глубины тюнинга. pfnat я использовал на скоростях до 80-ти мбит (субьективно на момент перехода работал так же как и вышеописаный по продуктивности) а дальше уполз с него на ipfw nat который успешно прожевывает на данный момент в районе 350-400 мбит на каждом из хостов.
У pf насколько помниться проблемы с smp.
А зачем net.inet.tcp.maxtcptw=40960?
P.S.
Сысоев проделал большую работу по тюнигу freebsd + nginx, но после публикации его материала все пользуются рекомендуемыми ним sysctl, даже не задумываясь про конечную роль сервера. А NAT бокс и веб сервер это не одно и тоже – при транзитном трафике сокеты, syncookies и т.п. не используются.
:(
Реквестирую статью по sysctl.conf с описанием популярных параметров и главное с рекомендацией когда надо, а когда не надо, использовать конкретный параметр.
P.S.
Сысоев проделал большую работу по тюнигу freebsd + nginx, но после публикации его материала все пользуются рекомендуемыми ним sysctl, даже не задумываясь про конечную роль сервера. А NAT бокс и веб сервер это не одно и тоже – при транзитном трафике сокеты, syncookies и т.п. не используются.
:(
Реквестирую статью по sysctl.conf с описанием популярных параметров и главное с рекомендацией когда надо, а когда не надо, использовать конкретный параметр.
> Как-то субъективно, при хорошенькой нагрузке на канале (у меня вылазит при >250Mbit/s) может
> требоваться периодический рестарт экземпляра nat-а, в целях высвобождения памяти, которую съедают
> таблички оного
А коннекты при этом не рвутся у пользователей?
> требоваться периодический рестарт экземпляра nat-а, в целях высвобождения памяти, которую съедают
> таблички оного
А коннекты при этом не рвутся у пользователей?
Рвуться что логично но происходит сие раз в неделю кроном, что считаю не трагичным.
сейчас раз в неделю, а завтра будет какой-то всплеск трафика и все встанет пока скрипт не запустится или админ не проснется. там разве нельзя настроить автоматический экспайр записей в таблице ната? на манер /proc/sys/net/netfilter/nf_conntrack_generic_timeout в линухе
Там собственно все сводится не к експайру а к тому что сессии насколько я понимаю продолжают считаться живыми. В любом случае up to 400 mbit/s на 1 сервере я считаю нормальным показателем и не жлоблюсь на масштабирование когда для следующей натилки начинает маячить ~300.
В общем «админ не проснется» и «все встанет» на протяжении последних 2 лет использования как-то не возникало :)
В общем «админ не проснется» и «все встанет» на протяжении последних 2 лет использования как-то не возникало :)
По поводу биллинга, раз уж тема зашла — посоветуйте что-нибудь под фряху на пару сотен клиентов, авторизация MAC+IP, подсчёт трафика не обязателен, а приятной фичей была бы турбо-кнопка — возможность на короткое время за дополнительную плату клиенту самостоятельно увеличить себе скорость. Существуют вообще такие или только самому изобретать?
stargazer, например. Собственно он не столько биллинг, сколько отличная платформа для написания решения «под себя». «Турбокнопка» под него пишется ровно за 10 минут, как и ночные ускорения и прочие плюшки.
Собственно свободно держит по опыту до 6k+ юзеров на одном хосте. Прост, как доска. Писать нужно много, самому, с любовью. :)
Собственно свободно держит по опыту до 6k+ юзеров на одном хосте. Прост, как доска. Писать нужно много, самому, с любовью. :)
Биллинг интересен для узкого круга читателей, а вот маршрутизация igmp трафика на FreeBSD интересна многим — IPTV смотрит бОльшее число человеков…
отличная заметка и настроение подняли)
kldload ipfw
использую пограничным шлюзом ipfw + pf(для ната) и netflow( снимаю прямо с интерфейса).
когда-то давным давно тестировали ipfw nat, natd,pf… лучшие показатели по стабильности и загрузки ресурсов где-то от 400 до600мб от 60к сессий были у pf. И кстати не всегда по загрузке цпу можно понять, что сервер вышел за пределы обработки допустимых объемов траффика. Тестировать можно пингом через шлюз какого-то хоста, и если задержки стали увеличиваться — значит не тянет.
Кста вопрос в догонку, а в ipfw позволено натить не одним адресом, а пулом адресов(перечнем айпишников или сетью)?
когда-то давным давно тестировали ipfw nat, natd,pf… лучшие показатели по стабильности и загрузки ресурсов где-то от 400 до600мб от 60к сессий были у pf. И кстати не всегда по загрузке цпу можно понять, что сервер вышел за пределы обработки допустимых объемов траффика. Тестировать можно пингом через шлюз какого-то хоста, и если задержки стали увеличиваться — значит не тянет.
Кста вопрос в догонку, а в ipfw позволено натить не одним адресом, а пулом адресов(перечнем айпишников или сетью)?
>>а в ipfw позволено натить не одним адресом, а пулом адресов(перечнем айпишников или сетью)?
Единственное чего действительно может не хватать – это нормального способа nat-ить из под пула адресов. Единственное что в этом случае приходит в голову это наплодить множество экземпляров на алиасах, но выглядит, это не так красиво как скажем у pfnat.
>>от 400 до600мб от 60к сессий были у pf.
60к… мечта :)
У меня от 100 в среднем при 150-170 кппс.
Собственно субъективно что у pf что у ipfw nat/ng nat нагрузка растет геометрически как раз отталкиваясь от количества established. Отнатить до 600-700 мбит на 1-10 абонентов можно практически без глубокого тюнинга. Далее вступают в дело физические ограничения сетевух, размеры буферов и скорость выделения памяти.
Единственное чего действительно может не хватать – это нормального способа nat-ить из под пула адресов. Единственное что в этом случае приходит в голову это наплодить множество экземпляров на алиасах, но выглядит, это не так красиво как скажем у pfnat.
>>от 400 до600мб от 60к сессий были у pf.
60к… мечта :)
У меня от 100 в среднем при 150-170 кппс.
Собственно субъективно что у pf что у ipfw nat/ng nat нагрузка растет геометрически как раз отталкиваясь от количества established. Отнатить до 600-700 мбит на 1-10 абонентов можно практически без глубокого тюнинга. Далее вступают в дело физические ограничения сетевух, размеры буферов и скорость выделения памяти.
вы действительно считаете, что переодический рестарт ната на роутещем серевере это прожакшн решение?
После линуксового iproute2 синтаксис ipfw — просто чудо как хорош… да и по сравнению с iptables.
Насколько я понял, этот НАТ будет работать только в ситуации, когда на выход есть только один канал. А вот если добавится ещё один, с внешним адресом, например, 8.8.8.7 и настройками типа тех, что указаны в статье, то при заходе пакетов по этому каналу мы обломается. А произойдёт это потому, что ответ сервер пошлёт по «умолчальному» маршруту, который идёт через 8.8.8.8. И нужно помимо подмены назначения делать ещё подмену источника. неплохо было бы описать ещё и этот момент.
>Во-первых, потому, что я сторонник простых и очевидных решений, поддерживаемость которых возможна практически с первого взгляда без длительных медитаций и размышлений на тему «а как это работает? Оо». К сожалению, я не могу отнести к таковым нетривиальные гибриды вида ipfw+pfnat.
…
>В-третьих я использую ipfw, и люблю его – за простоту, наглядность, предсказуемость, dummynet а гибриды вида ipfw+pf+altq… в общем смотрим «Во-первых».
Сначала выказываем фи связке ipfw+pf, потом записываем в преимущества. ООк
>Итого в базовом варианте нам нужно следующее
>Перебрать ядро с поддержкой ipfw, ipfw nat, libalias ну и дальше по вкусу
А что, в 7.0 модулями это всё уже не цепляется? Как печально, терпеть не могу тупую ручную работу типа пересборки ядра.
…
>В-третьих я использую ipfw, и люблю его – за простоту, наглядность, предсказуемость, dummynet а гибриды вида ipfw+pf+altq… в общем смотрим «Во-первых».
Сначала выказываем фи связке ipfw+pf, потом записываем в преимущества. ООк
>Итого в базовом варианте нам нужно следующее
>Перебрать ядро с поддержкой ipfw, ipfw nat, libalias ну и дальше по вкусу
А что, в 7.0 модулями это всё уже не цепляется? Как печально, терпеть не могу тупую ручную работу типа пересборки ядра.
1. высказываю — фи, преимущества — просто более глубокое понимание схемы прохождения пакета через ядро.
2. цепляетяся, чо ж не цепляться.
Вызовы внутри ядра происходят быстрее, чем вызовы внешних модулей — не тратится время на переключение контекстов исполнения, адреса входов в процедуры являются статическими, и вычисляются в процессе компиляции, а не каждый раз во время исполнения. (С)
Сидите дальше на ядрах с тоннами GENERIC мусора?
Как печально (С)
2. цепляетяся, чо ж не цепляться.
Вызовы внутри ядра происходят быстрее, чем вызовы внешних модулей — не тратится время на переключение контекстов исполнения, адреса входов в процедуры являются статическими, и вычисляются в процессе компиляции, а не каждый раз во время исполнения. (С)
Сидите дальше на ядрах с тоннами GENERIC мусора?
Как печально (С)
>Вызовы внутри ядра происходят быстрее, чем вызовы внешних модулей — не тратится время на переключение контекстов исполнения, адреса входов в процедуры являются статическими, и вычисляются в процессе компиляции, а не каждый раз во время исполнения
Это бред.
Контекст у модулей ядра и самого ядра один и тот же — ядерный.
Как в случае модулей, так и в случае статической компиляции вызовы функций происходят по указателю, никакой разницы нет.
>Сидите дальше на ядрах с тоннами GENERIC мусора?
Этот «мусор» есть совершенно не просит, и т.к. мегабайта памяти мне не жаль, а своего времени очень даже, сижу, да.
А вы таки бегаете как ошпареный, пересобирая ядро каждый раз, когда нужно добавить новую карточку или дисковый контроллер, и тешите себя надеждой что в этом есть какой-то смысл и оптимизация?
Лучше бы вложили этот ресурс в изучение матчасти.
Это бред.
Контекст у модулей ядра и самого ядра один и тот же — ядерный.
Как в случае модулей, так и в случае статической компиляции вызовы функций происходят по указателю, никакой разницы нет.
>Сидите дальше на ядрах с тоннами GENERIC мусора?
Этот «мусор» есть совершенно не просит, и т.к. мегабайта памяти мне не жаль, а своего времени очень даже, сижу, да.
А вы таки бегаете как ошпареный, пересобирая ядро каждый раз, когда нужно добавить новую карточку или дисковый контроллер, и тешите себя надеждой что в этом есть какой-то смысл и оптимизация?
Лучше бы вложили этот ресурс в изучение матчасти.
ядро собирается на средней машине меньше 5 минут, вы именно за это время «учили матчасть»?
Ядро собирается минут 20 на одноядерном атлоне, если не отключать сборку всех модулей.
Ещё нужно время на редактирование конфига и ребут машины.
В сумме пусть будет 30 минут.
Серверов под моим управлением сейчас штук 20, если на каждый тратить 30 минут, получается 10 часов чистого времени. Каждый раз, когда надо будет обновить систему.
Гм, что же выбрать — 10 часов мартышкиного труда или 10 часов полезного времяпрепровождения? Даже не знаю ;)
Ещё нужно время на редактирование конфига и ребут машины.
В сумме пусть будет 30 минут.
Серверов под моим управлением сейчас штук 20, если на каждый тратить 30 минут, получается 10 часов чистого времени. Каждый раз, когда надо будет обновить систему.
Гм, что же выбрать — 10 часов мартышкиного труда или 10 часов полезного времяпрепровождения? Даже не знаю ;)
[irony]будет чуть больше серверов — думаю научитесь автоматизировать рутинные операции, какраз и время появится для изучения матчасти[/irony]
Уймитесь уже.
Уймитесь уже.
Покажите-ка ваш скрипт, который пишет конфиг ядра за вас. Надо полагать, он с голосовым управлением?
Уймусь, как только вы перестаните гнать тупак а-ля статьи на опеннете пятилетней давности, где софт на фре вручную рекомендуют собирать. Разгребай потом грабли после начитавшихся такого студентов.
Пересборка ядра — явно лишнее звено, покуда вы этого очевидного факта не признаёте, приходится дожимать.
Уймусь, как только вы перестаните гнать тупак а-ля статьи на опеннете пятилетней давности, где софт на фре вручную рекомендуют собирать. Разгребай потом грабли после начитавшихся такого студентов.
Пересборка ядра — явно лишнее звено, покуда вы этого очевидного факта не признаёте, приходится дожимать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткий обзор ядерного NAT-а в FreeBSD