Как стать автором
Обновить

Комментарии 43

NATasha улыбнуло
не придумалось ничего умнее для семплового хоста :)
а почему нет NAStya?
она работает Network Attached Storage-м :)
NAS у вас в смысле Network Access Server? а то я поначалу пытался понять нафига НАТаша, если клиентам инет отдает NAS(в смысле Network Attached Storage)
Network Access Server отправляет клиентов к НАТаше :)
это понятно. просто не знаю почему у меня NAS ассоциируется сначала в первую очередь с Network Attached Storage:) потому и удивила сначала схема, пока не вспомнил что есть еще Network Access Server.
только что сам подумал что по схеме у меня какой-то публичный дом получается :)
Интересно посмотреть сравнительные тесты производительности этого и других натов под фри. Я наблюдал, что пф работает шустрее чем натд, нужно полагать, что этот будет шустрее обоих.
Сравнивать практически нечего :)

natd захлебывается уже на 40-50 мбит на квадкоре в независимости от глубины тюнинга. pfnat я использовал на скоростях до 80-ти мбит (субьективно на момент перехода работал так же как и вышеописаный по продуктивности) а дальше уполз с него на ipfw nat который успешно прожевывает на данный момент в районе 350-400 мбит на каждом из хостов.

У pf насколько помниться проблемы с smp.
400 мбит натд и не снилось :)

При таких объемах трафика не проще ли взять внешних адресов на всех?
Не проще иногда :)
А зачем net.inet.tcp.maxtcptw=40960?

P.S.
Сысоев проделал большую работу по тюнигу freebsd + nginx, но после публикации его материала все пользуются рекомендуемыми ним sysctl, даже не задумываясь про конечную роль сервера. А NAT бокс и веб сервер это не одно и тоже – при транзитном трафике сокеты, syncookies и т.п. не используются.
:(

Реквестирую статью по sysctl.conf с описанием популярных параметров и главное с рекомендацией когда надо, а когда не надо, использовать конкретный параметр.
эм, каюсь — не заметил пастнув не из той заготовки :(

А так для транзитного трафика больше стараюсь крутить сетевухи на тему dev.em.Х и hw.em.rxd/txd ну а далее по списку nmbclusters, dummynet, maxlen…
НЛО прилетело и опубликовало эту надпись здесь
Покажите в моем топике слово «ниодной» а не «мало». :)
> Как-то субъективно, при хорошенькой нагрузке на канале (у меня вылазит при >250Mbit/s) может
> требоваться периодический рестарт экземпляра nat-а, в целях высвобождения памяти, которую съедают
> таблички оного

А коннекты при этом не рвутся у пользователей?
Рвуться что логично но происходит сие раз в неделю кроном, что считаю не трагичным.
сейчас раз в неделю, а завтра будет какой-то всплеск трафика и все встанет пока скрипт не запустится или админ не проснется. там разве нельзя настроить автоматический экспайр записей в таблице ната? на манер /proc/sys/net/netfilter/nf_conntrack_generic_timeout в линухе
Там собственно все сводится не к експайру а к тому что сессии насколько я понимаю продолжают считаться живыми. В любом случае up to 400 mbit/s на 1 сервере я считаю нормальным показателем и не жлоблюсь на масштабирование когда для следующей натилки начинает маячить ~300.

В общем «админ не проснется» и «все встанет» на протяжении последних 2 лет использования как-то не возникало :)
По поводу биллинга, раз уж тема зашла — посоветуйте что-нибудь под фряху на пару сотен клиентов, авторизация MAC+IP, подсчёт трафика не обязателен, а приятной фичей была бы турбо-кнопка — возможность на короткое время за дополнительную плату клиенту самостоятельно увеличить себе скорость. Существуют вообще такие или только самому изобретать?
stargazer, например. Собственно он не столько биллинг, сколько отличная платформа для написания решения «под себя». «Турбокнопка» под него пишется ровно за 10 минут, как и ночные ускорения и прочие плюшки.

Собственно свободно держит по опыту до 6k+ юзеров на одном хосте. Прост, как доска. Писать нужно много, самому, с любовью. :)
Биллинг интересен для узкого круга читателей, а вот маршрутизация igmp трафика на FreeBSD интересна многим — IPTV смотрит бОльшее число человеков…
НЛО прилетело и опубликовало эту надпись здесь
отличная заметка и настроение подняли)
спасибо, немногие считают мой «юмор» здоровым.
использую пограничным шлюзом ipfw + pf(для ната) и netflow( снимаю прямо с интерфейса).
когда-то давным давно тестировали 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 абонентов можно практически без глубокого тюнинга. Далее вступают в дело физические ограничения сетевух, размеры буферов и скорость выделения памяти.
вы действительно считаете, что переодический рестарт ната на роутещем серевере это прожакшн решение?
После линуксового iproute2 синтаксис ipfw — просто чудо как хорош… да и по сравнению с iptables.
Ну, в Ubuntu и Debian есть еще ufw. Глубоко не копался, но по первому впечатлению — надстройка над iptables с ipfw-like синтаксисом.
Насколько я понял, этот НАТ будет работать только в ситуации, когда на выход есть только один канал. А вот если добавится ещё один, с внешним адресом, например, 8.8.8.7 и настройками типа тех, что указаны в статье, то при заходе пакетов по этому каналу мы обломается. А произойдёт это потому, что ответ сервер пошлёт по «умолчальному» маршруту, который идёт через 8.8.8.8. И нужно помимо подмены назначения делать ещё подмену источника. неплохо было бы описать ещё и этот момент.
для такого случая в статье и предусмотрен options ROUTETABLES=2 :)

А вообще балансировку аплинков веселее производить бжп раутером.
Тогда неплохо было бы описать какие опции для чего предназначены. Я, например, ещё не настраивал ipfw и если мне придётся это делать, то разобраться по статье что к чему будет непросто. Разве что только скопипастить готовое решение.
>Во-первых, потому, что я сторонник простых и очевидных решений, поддерживаемость которых возможна практически с первого взгляда без длительных медитаций и размышлений на тему «а как это работает? Оо». К сожалению, я не могу отнести к таковым нетривиальные гибриды вида ipfw+pfnat.

>В-третьих я использую ipfw, и люблю его – за простоту, наглядность, предсказуемость, dummynet а гибриды вида ipfw+pf+altq… в общем смотрим «Во-первых».

Сначала выказываем фи связке ipfw+pf, потом записываем в преимущества. ООк

>Итого в базовом варианте нам нужно следующее
>Перебрать ядро с поддержкой ipfw, ipfw nat, libalias ну и дальше по вкусу

А что, в 7.0 модулями это всё уже не цепляется? Как печально, терпеть не могу тупую ручную работу типа пересборки ядра.
1. высказываю — фи, преимущества — просто более глубокое понимание схемы прохождения пакета через ядро.
2. цепляетяся, чо ж не цепляться.

Вызовы внутри ядра происходят быстрее, чем вызовы внешних модулей — не тратится время на переключение контекстов исполнения, адреса входов в процедуры являются статическими, и вычисляются в процессе компиляции, а не каждый раз во время исполнения. (С)

Сидите дальше на ядрах с тоннами GENERIC мусора?
Как печально (С)
>Вызовы внутри ядра происходят быстрее, чем вызовы внешних модулей — не тратится время на переключение контекстов исполнения, адреса входов в процедуры являются статическими, и вычисляются в процессе компиляции, а не каждый раз во время исполнения

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

>Сидите дальше на ядрах с тоннами GENERIC мусора?

Этот «мусор» есть совершенно не просит, и т.к. мегабайта памяти мне не жаль, а своего времени очень даже, сижу, да.

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

Лучше бы вложили этот ресурс в изучение матчасти.
ядро собирается на средней машине меньше 5 минут, вы именно за это время «учили матчасть»?
Ядро собирается минут 20 на одноядерном атлоне, если не отключать сборку всех модулей.
Ещё нужно время на редактирование конфига и ребут машины.
В сумме пусть будет 30 минут.

Серверов под моим управлением сейчас штук 20, если на каждый тратить 30 минут, получается 10 часов чистого времени. Каждый раз, когда надо будет обновить систему.

Гм, что же выбрать — 10 часов мартышкиного труда или 10 часов полезного времяпрепровождения? Даже не знаю ;)
[irony]будет чуть больше серверов — думаю научитесь автоматизировать рутинные операции, какраз и время появится для изучения матчасти[/irony]

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

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

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

Публикации

Истории