как зажать вход

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

как зажать вход

irix
Hello Openbsd,

  Как   зажать входящий поток до 10 мегабит на каждый ip в
  локалке,  на  одиноко  стоящем  компьютере  с  самбой  и  опёнкой, в
  локальной  сети. Ну там рассуждения на тему "зачем зажимать вход ?", в
  мусор.  Вот  пришёл  к  вам  умный  заказчик  и задал вопрос "КАК?",
  предложите  ему  решение на опёнке как это можно сделать на altq. Ну
  это немного в тему недопорта конционера :)

--
Best regards,
 irix                          mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Stanislav Kruchinin
> входящий поток до 10 мегабит на каждый ip

Что имеется в виду: трафик от сервера к юзерам или все-таки от юзеров на сервер?
Шейпинг исходящего от сервера трафика делается стандартно, как описанов манах по
altq. Если на одиноко стоящем сервере нужно ограничивать входящий трафик, то
поможет только FreeBSD с dummynet или Linux с tc и IFB. Причем FreeBSD
предпочтительнее, т.к. IFB у меня иногда глючил. Нужно понимать, что ограничение
входящего трафика делается только косвенно: засчет отбрасывания пакетов и
рассылки уведомлений о перегрузке, чтобы отправитель уменьшил у себя окно. В
этом случае можно ограничивать packetrate, а не полосу пропускания, т.к. размер
полезной нагрузки приходящих пакетов и задержки, через которые они приходят,
заранее неизвестны.

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


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Sergey Yudin-2
In reply to this post by irix

>   Как   зажать входящий поток до 10 мегабит на каждый ip в
>   локалке,  на  одиноко  стоящем  компьютере  с  самбой  и  опёнкой, в
>   локальной  сети. Ну там рассуждения на тему "зачем зажимать вход ?", в
>   мусор.
а куда рассуждения о том,  что входящий трафик на промежуточном узле
можно "зажать" только отбрасывая нормальные уже принятые и посчитанные
пакеты ?

>   Вот  пришёл  к  вам  умный  заказчик  и задал вопрос "КАК?",
>   предложите  ему  решение на опёнке как это можно сделать на altq. Ну
>   это немного в тему недопорта конционера :)
>
>  


Reply | Threaded
Open this post in threaded view
|

Файловый сервер

Sergey Yudin-2
In reply to this post by Stanislav Kruchinin

> В любом случае, файловый сервер на OpenBSD с samba -- это само по себе странное
> решение, не говоря уже "шейпинге" входящего трафика.
>
>  
А какое решение для файлового сервера будет более адекватным ? Ищу на
что бы перейти с Netware 4.11


Reply | Threaded
Open this post in threaded view
|

Re: Файловый сервер

Stanislav Kruchinin
Sergey Yudin wrote:
>
>> В любом случае, файловый сервер на OpenBSD с samba -- это само по себе
>> странное
>> решение, не говоря уже "шейпинге" входящего трафика.
>>
>>  
> А какое решение для файлового сервера будет более адекватным ? Ищу на
> что бы перейти с Netware 4.11
>

Выбор ОС и способа организации хранилища зависит много от чего: от железа,
размеров файлов, возможностей масштабирования, скоростных характеристик... Я
предполагаю, что ваше хранилище будет нераспределенным, т.е. все вертится и
масштабируется в пределах одной машины. В качестве ОС, естественно, должен быть
Linux, т.к. там на данный момент есть неплохие файловые системы, zero copy
sockets и неплохие возможности по настройке i/o-подсистемы ядра. Во FreeBSD тоже
что-то есть в этом плане, но если те извращения, которые позволяет делать GEOM,
не нужны, то не стоит и связываться.

Предполагается, что жесткие диски и подходящий SATA/SAS RAID-контроллер от
3ware/Areca/Adaptec вы уже купили, и он нормально работает в Linux. Если же
хранилище будет совсем небольшим, диска на 4, то проще и дешевле cделать
software RAID, а то и вообще обойтись без RAID.

Если разделы будут более 2 Тб, то для работы с ними нужно использовать GUID
partition table. Определитесь, нужны ли для данного решения возможности,
предоставляемые LVM. В частности, LVM полезен если хочется создавать разделы в
пределах нескольких физических устройств (RAID-контроллеров). Для изменения
размеров раздела в пределах одного устройства LVM не обязателен, т.к. это можно
делать прямым редактированием таблицы разделов. В любом случае, файловая система
должна поддерживать изменение размеров в нужную сторону.

Если объем хранилища будет только увеличиваться, и файлы в основном большие
(iso, фильмы), то лучше использовать XFS. Если файлы небольшие и приоритетом
является надежность, а не скорость, то лучше использовать ext3 или ext4.


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Anton Maksimenkov-2
In reply to this post by Sergey Yudin-2
copy

10 февраля 2009 г. 14:49 пользователь engineer <[hidden email]> написал:
>>>  Как   зажать входящий поток до 10 мегабит на каждый ip в
>>>  локалке,  на  одиноко  стоящем  компьютере  с  самбой  и  опёнкой, в
>>>  локальной  сети. Ну там рассуждения на тему "зачем зажимать вход ?", в
>>>  мусор.
>>
>> а куда рассуждения о том,  что входящий трафик на промежуточном узле можно
>> "зажать" только отбрасывая нормальные уже принятые и посчитанные пакеты ?
>
не, не так. можно же не отбрасывать, а не подтверждать приём. или
задержать. по идее после этого TCP стек отправителя должен
попридержать коней. Насчёт IP, если мне память правильно изменяет, то
там управления потоком нету, так что да, тока отброс.

Тем не менее да, не столь давно мне тоже пришло понимание, что
зажимать вход имеет право на жизнь. Да, отбрасывая пришедшие пакеты,
хер сними, что они "уже попали на интерфейс". Смысл в том, чтобы они
не попали приложению - самбе ли, вебсерверу ли.
В опёнке я не вижу способа кроме как ставить промежуточную машину м/у
сервером и "остальной сетью". Во фряхе можно как я понимаю обойтись
без промежуточной.

ЗЫЖ самбов... не надо, не мучайте себя и остальное. для виндовой сети
виндосервер - самое то. всё остальное - изврат ужасный. вспоминаю
как я самбу пытал... ойййо. лучшеб делом занимался. или ещё чем. ибо
потерянное время.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Oleg Safiullin
engineer wrote:

> copy
>
> 10 февраля 2009 г. 14:49 пользователь engineer <[hidden email]> написал:
>>>>  Как   зажать входящий поток до 10 мегабит на каждый ip в
>>>>  локалке,  на  одиноко  стоящем  компьютере  с  самбой  и  опёнкой, в
>>>>  локальной  сети. Ну там рассуждения на тему "зачем зажимать вход ?", в
>>>>  мусор.
>>> а куда рассуждения о том,  что входящий трафик на промежуточном узле можно
>>> "зажать" только отбрасывая нормальные уже принятые и посчитанные пакеты ?
> не, не так. можно же не отбрасывать, а не подтверждать приём. или
> задержать. по идее после этого TCP стек отправителя должен
> попридержать коней. Насчёт IP, если мне память правильно изменяет, то
> там управления потоком нету, так что да, тока отброс.
>
> Тем не менее да, не столь давно мне тоже пришло понимание, что
> зажимать вход имеет право на жизнь. Да, отбрасывая пришедшие пакеты,
> хер сними, что они "уже попали на интерфейс". Смысл в том, чтобы они
> не попали приложению - самбе ли, вебсерверу ли.
> В опёнке я не вижу способа кроме как ставить промежуточную машину м/у
> сервером и "остальной сетью". Во фряхе можно как я понимаю обойтись
> без промежуточной.
>
> ЗЫЖ самбов... не надо, не мучайте себя и остальное. для виндовой сети
> виндосервер - самое то. всё остальное - изврат ужасный. вспоминаю
> как я самбу пытал... ойййо. лучшеб делом занимался. или ещё чем. ибо
> потерянное время.
> --
> engineer

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

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

Приведу здесь пример pf.conf благодяря которому понятие забитый насмерть канал (1мбит) просто
исчезло как класс. Сразу, чтобы избежать вопросов: в правилах очереди пишутся и на входящие правила -
очереди действовать будут на ответы по этим правилам.

Еще некоторое замечание: не сильно давно было замечено умирание в случае запуска Windows Update на
Windows Server 2008 (или Vista) - при этом идет качание примерно в столько потоков, сколько всего упдатов надо
накатить. Проверка показала, что умирание происходило из-за запаздывания DNSных пакетов (правило было, но оно стало
мало эффективным в свете последних изменений в bindах итд). Решилось явным прописыванием правила для `user named'.

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

Ну а правила собственно вот (по возможности откоментировал, но мог чего-то и упустить :)
В общем случае исходные условия таковы:
        - провайдерский LAN и пиринговые сети (описаны в файле /etc/pf.local который не приводится) - 100Mbps
        - инет 1Mbps
Если есть просто канал заданной ширины все можно сделать проще.

--
# Сетевые интерфейсы.
#
ext_if = "fxp0"
int_if = "fxp1"

# Обслуживаемые TCP и UDP сервисы. В данный список не требуется
# включать tcp/smtp.
#
tcp_svc = "ftp ssh domain www smtps imaps"
udp_svc = "domain"

# TCP сервисы, обслуживаемые внутренним сервером.
#
rdr_e11_svc = "telnet"
rdr_e11_hst = "10.10.10.194"

# Хосты, с которыми устанавливаются IPSec тунели.
#
esp_peers = "89.31.114.53"


# Таблицы белого и черного списков spamd и списка сетей, которые нужно
# пропускать к почтовому серверу без проверки.
#
table <spamd-white> persist
table <spamd-black> file "/etc/mail/spamd.black"
table <spamd-bypass> file "/etc/mail/spamd.bypass"

# Таблица локальных адресов с которых ведется активная рассылка.
#
table <spammers> persist

# Таблица черного списка (заполняется из sshwatchd или другой программы).
#
table <blocked> persist

# Таблица локальных сетей провайдера.
#
table <local> file "/etc/pf.local"

# Таблица сетей, которые доступны через тунели.
#
table <tunnel-networks> const {
        10.11.12.20/24
}


# Отключить фильтрацию трафика на loopback, туннельных и
# IPSec интерфейсах.
#
set skip on { lo enc0 }


# Выполнять нормализацию входящих пакетов.
#
scrub in


# Настройка очередей:
#  90 Mbit/s - локальная сеть провайдера
# 900 Kbit/s - обычный интернет трафик
# 100 Kbit/s - высокоприоритетный трафик
#
altq on $ext_if bandwidth 100Mb hfsc queue { lan wan }
queue lan bandwidth 90% hfsc
queue wan bandwidth 1% hfsc { pri def }
queue pri bandwidth 10% priority 7 hfsc (realtime 10%)
queue def bandwidth 90% priority 5 hfsc (default)


# Транслировать внутренние адреса в (основной) адрес внешнего
# интерфейса.
#
nat on $ext_if from !($ext_if) -> ($ext_if:0)

# Подключить правила трансляции/переадресации, создаваемые
# ftp-proxy.
#
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"

# Не пропускать адреса из черного списка к переадресованным
# сервисам.
#
no rdr on $ext_if from <blocked>

# Пропустить FTP соединения через ftp-proxy кроме локальных
# соединений и сетей, доступных через тунели.
#
no rdr on $int_if inet proto tcp to <tunnel-networks> port ftp
rdr on $int_if inet proto tcp to !(self) port ftp -> 127.0.0.1 port 8021

# Перенаправить входящие SMTP сессии (для адресов, не входящих в белый
# список spamd) в spamd для проверки.
#
no rdr on $ext_if inet proto tcp from <spamd-bypass> to port smtp
rdr pass on $ext_if inet proto tcp from { <spamd-black> !<spamd-white> } \
        to ($ext_if) port smtp -> 127.0.0.1 port spamd

# Переадресовать TCP сервисы, обслуживаемые внутренним сервером.
#
rdr pass on $ext_if inet proto tcp to ($ext_if) port { $rdr_e11_svc } \
        -> $rdr_e11_hst

# Разрешить обращение к переадресованным сервисам из внутренней сети.
#
rdr pass on $int_if inet proto tcp to ($ext_if) port { $rdr_e11_svc } \
        tag INT_IF -> $rdr_e11_hst
nat on $int_if tagged INT_IF -> ($int_if:0)


# Предотвращение IP spoofing. Принудительная блокировка адресов из
# черного списка.
#
antispoof quick for ($int_if)
block in quick on $ext_if to !($ext_if)
block in quick on $ext_if from <blocked>

# Подключить правила, создаваемые ftp-proxy.
#
anchor "ftp-proxy/*"

# По умолчанию блокировать и писать в лог любой трафик на внешнем
# интерфейсе, возвращая RST для входящих TCP соединений.
#
block log on $ext_if
block return-rst in log on $ext_if inet proto tcp

# Блокируем без записи в лог мусор (multicast, broadcast, netbios, ssdp).
#
block in quick on $ext_if inet to { 224/4 255.255.255.255 }
block in quick on $ext_if inet proto udp \
        to port { netbios-ns netbios-dgm ssdp }

# Разрешить исходящий трафик.
#
pass out quick on $ext_if inet from ($ext_if) to <local> queue lan
pass out quick on $ext_if inet proto udp to port { domain 4711 } queue pri
pass out quick on $ext_if inet proto tcp to port { telnet 5190 } queue pri
pass out quick on $ext_if inet user named queue pri
pass out quick on $ext_if inet proto tcp queue (def pri)
pass out on $ext_if inet

# Разрешить входящие ICMP ping пакеты. Остальные ICMP относятся к
# TCP/UDP и разрешаются их статами.
#
pass in quick on $ext_if inet proto icmp from <local> to ($ext_if) \
        icmp-type echoreq code 0 queue lan
pass in quick on $ext_if inet proto icmp to ($ext_if) icmp-type echoreq code 0

# Разрешить подключения к обслуживаемым TCP сервисам.
#
pass in on $ext_if inet proto tcp from <local> to ($ext_if) port { $tcp_svc } \
        queue lan
pass in on $ext_if inet proto tcp to ($ext_if) port { $tcp_svc } \
        queue (def pri)

# Раздать очереди входящим соединениям ftp-proxy. В /etc/rc.conf.local
# должно быть ftpproxy_flags="-T ftp-proxy"
#
pass in quick on $ext_if inet proto tcp from <local> tagged ftp-proxy \
        queue lan
pass in quick on $ext_if inet proto tcp tagged ftp-proxy queue (def pri)

# Разрешить SMTP сессии для адресов, прошедших проверку. Писать их в log
# для spamlogd.
#
pass in log on $ext_if inet proto tcp from <local> to ($ext_if) port smtp \
        queue lan
pass in log on $ext_if inet proto tcp to ($ext_if) port smtp queue (def pri)

# Разрешить входящие TCP соединения для FTP сервера (passive mode) и
# FTP клиента (active mode).
#
pass in on $ext_if inet proto tcp from <local> to ($ext_if) port > 49151 \
        user >= 0 queue lan
pass in on $ext_if inet proto tcp to ($ext_if) port > 49151 user >= 0 \
        queue (def pri)

# Разрешить обращение к обслуживаемым UDP сервисам.
#
pass in on $ext_if inet proto udp from <local> to ($ext_if) port { $udp_svc } \
        queue lan
pass in on $ext_if inet proto udp to ($ext_if) port { $udp_svc }

# Разрешить установку IPSec тунелей.
#
pass in on $ext_if inet proto udp from { $esp_peers } to ($ext_if) \
        port isakmp queue lan
pass in on $ext_if inet proto esp from { $esp_peers } to ($ext_if) \
        queue lan

# Не пропускать из внутренней сети SMTP соединения к чужим адресам.
# Полностью блокировать SMTP при обнаружении быстрой рассылки.
#
block in log quick on $int_if inet proto tcp to !(self) port smtp
block in log quick on $int_if inet proto tcp from <spammers> to port smtp
pass in quick on $int_if inet proto tcp to port smtp \
        keep state (max-src-conn-rate 5/10 overload <spammers> flush)

--
INS -- CАНЮТ ИНСТАЛЛ ПРИЖИЛЕГЕД ТАСК ФРОМ НОН-ПРИЖИЛЕГЕД ТЕРМИНАЛ


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Stans Sataa
In reply to this post by Anton Maksimenkov-2
engineer пишет:
> ЗЫЖ самбов... не надо, не мучайте себя и остальное. для виндовой сети
> виндосервер - самое то. всё остальное - изврат ужасный. вспоминаю
> как я самбу пытал... ойййо. лучшеб делом занимался. или ещё чем. ибо
> потерянное время.

Может не в самбе дело, а в прямоте рук?

--
Best regards,
 Stans
       


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Anton Maksimenkov-2
In reply to this post by Oleg Safiullin
> Не вдаваясь в подробности и по сути не совсем в тему если исходить из
> исходного вопроса...
> Придержать входящее к самой машине в принципе можно, но потребуются довески
> (как и во фре собственно,
> только там довески уже встроены :)
>
> В общем же случае как правило под `порезать входящий трафик' подразумевается
> `сделать так, чтобы канал не забивался в усмерть', а в этом случае можно
> обойтись и без наезда
> на входящие трафик.
>
> Приведу здесь пример pf.conf благодяря которому понятие забитый насмерть
> канал (1мбит) просто
> исчезло как класс. Сразу, чтобы избежать вопросов: в правилах очереди
> пишутся и на входящие правила -
> очереди действовать будут на ответы по этим правилам.

Млин. Нарисовал бы топологию что ли... Хотя и без этого я так понимаю
машинка эта шлюзик от локалки к провайдеру. Соответственно, локалка
чётко лимитится путём так сказать  её "помечания" на входящих
правилах. Но обрезка идёт на исходящем (провайдерском) ифейсе.
Да, да. Это я в курсе и чтобы не повторяться так и писал сразу: "В
опёнке я не вижу способа кроме как ставить промежуточную машину м/у
сервером и "остальной сетью".
В данном случае "сервер" это у вас провайдер, "остальная сеть" -
локалка. Ну а промежуточная машина между ними - это ваш шлюз, для
которого приведены правила pf. Короче тут как я понимаю мы воду в
ступе трём.

НО.
>как правило под `порезать входящий трафик' подразумевается `сделать так, чтобы канал не забивался в усмерть',
Пойдём отсюда.
В фразе имеется ввиду "входящий трафик"=трафик из локалки в инет (на
внутреннем ифейсе), а "канал"=это трафик на внешнем ифейсе. Так, да?
Не всегда так.

Теперь. Возьмём ситуацию - PPPoE сервера на фряхе (нетграф и
прочее.... ну нету на опёнке решения для провайдера). Один интерфейс -
в него вся PPPoE локалка втыкается (в него входит и выходит из него
же). Другой интерфейс - ну грубо говоря "в интирнет".
Стоит задача чтобы трафик "из локалки в локалку" не сильно забивал
pppoe'шный интерфейс, то есть чтобы "интирнет" выливался клиентам в
локалку более широкоприоритетным потоком (если надо), чем локальный
ослотрафик.
Мне видится вариант решения - "порезать на входе локальный трафик на
уровень ХХХМбит/с". То есть более чем эти ХХХМбит не дойдёт до ядра и
не сроутится обратно в локалку.

Может не самый удачный пример... Скажете - так обрезай его когда он
обратно выходить будет...
Ладно, возьмём более другой. Аплоадинг на ФТП, платный типа. Нужно
гарантированно не дать юзеру вливать на сервак больше чем ХХХКбит/с.
Или, для бесплатных вообще ХКбит. Да, пускай он валит безоглядки свои
мегабиты. Но мы их на входящем ифейсе тупо отбрасываем и "до ядра", до
ФТП, до диска грубо говоря не дойдёт больше этих ХХХКбит/с.

Что всё это даёт. Во-первых, не надо допиливать функционал по
ограничению к|мбит/с в приложение. Во-вторых, вообще эта нагрузка (и
функционал в приложении) сильно лишняя - доставка всего этого от
сетевухи через ядро в юзерспейс (буферы, копирования, cpu...),
переключение контекстов на юзерспейс и обратно, вычисление там,
отбрасывание... Когда можно
а) отсечь это на этапе ядра;
б) не занимать буферы во всей цепочке после отсечения, не тратить
время, cpu и mem на их выделение и хранение;
в) чуть сократить задержку полезным пакетам (это моё ИМХО на основе
представления о том, что большое количество "висящих" буферов, уже
занятых задерживаемыми пакетами, даст доп.нагрузку на обработку этих
цепочек mbuf'ов и всяких прочих очередей на выделение памяти под новые
цепочки, сопутствующие структуры и т.д. - всё что перетасовывается в
процессе пока пакет пройдёт сквозь ядро).

Это всё даёт возможность направить оставшуюся мощность машины на
полезные задачи.
Помойму так! (с) В.Пух.


ЗЫЖ 11 февраля 2009 г. 13:12 пользователь Stans I. <[hidden email]> написал:
>> самбов... не надо, не мучайте себя и остальное.
> Может не в самбе дело, а в прямоте рук?
Огласите количество лет общения с компами, с виндами, с юниксами и с
самбой. И количество компов в локалке, ну примерно.
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Oleg Safiullin
> Млин. Нарисовал бы топологию что ли... Хотя и без этого я так понимаю

А оно мне надо? ;)
Я написал, что это не совсем по теме и вкратце разъяснил исходные условия и результат, нго только потому, что оно есть живое и часто
спрашивали об этом :)
Остальное пусть делает тот кому нужно. По этой же причине не стану развивать тему разницы между "ну нету" и "ну не знаю как" - из
первого письма можно было догадаться как (и из него же понятно, что это не только встроенными средствами).

--
INS -- CАНЮТ ИНСТАЛЛ ПРИЖИЛЕГЕД ТАСК ФРОМ НОН-ПРИЖИЛЕГЕД ТЕРМИНАЛ


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Anton Maksimenkov-2
> Остальное пусть делает тот кому нужно. По этой же причине не стану развивать
> тему разницы между "ну нету" и "ну не знаю как" - из первого письма можно

Это мне, на тему "ну нету провайдерского PPPoE решения для провайдера
на опёнке", или что-то совсем другое?
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Oleg Safiullin
engineer wrote:
>> Остальное пусть делает тот кому нужно. По этой же причине не стану развивать
>> тему разницы между "ну нету" и "ну не знаю как" - из первого письма можно
>
> Это мне, на тему "ну нету провайдерского PPPoE решения для провайдера
> на опёнке", или что-то совсем другое?

На эту :)
Хотя таких тем было дофига в том числе в этов листе.
Достаточно вспомнить (перечисляю только то, что вспомнил в виду того, что до сих пор используется [много лет]):
- sendmail не работает с maildir
- sendmail не работает виртуальными усерами
- нельзя обратиться к переадресованным на наружнем интерфейсе сервисам изнутри
итд.

По вышеуказанному вопросу сразу скажу: решение неуклюжее, неудобное и если его и делать, то скорее ради интереса, чем для
практической пользы :)

Понятно, что наличие решения (или даже "решения") далеко не всегда означет, что его нужно использовать.
Точно также бесполезно сравнивать возможности PF и ipfw - это в принципе разные вещи по реализации.

Просто уточнение и не более, что в принципе - можно :)
Порекомендовать (и уж тем более назвать их простыми) методы, которые первыми пришли в голову я бы не решился :)
Если интересно, в привате могу дать пару намеков, только на ночь не читать ;)

--
INS -- CАНЮТ ИНСТАЛЛ ПРИЖИЛЕГЕД ТАСК ФРОМ НОН-ПРИЖИЛЕГЕД ТЕРМИНАЛ


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Stanislav Kruchinin
In reply to this post by Oleg Safiullin
Oleg Safiullin wrote:
>
> Не вдаваясь в подробности и по сути не совсем в тему если исходить из
> исходного вопроса...
> Придержать входящее к самой машине в принципе можно, но потребуются
> довески (как и во фре собственно,
> только там довески уже встроены :)

В оригинале вопрос ставился как ограничение входящего трафика для каждого
юзерского IP, а не просто ограничить входящий трафик до 10 Мбит. В Опене без
промежуточной машины так не получится, да и то наверное придется руками
прописывать queue для каждого IP. Во Фре это делается динамическими пайпами, в
Линуксе ограничивать входящий пакетрейт per IP можно с помощью каких-то модулей
iptables или tc + IFB, но правила будут сложнее фряшных.


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Oleg Safiullin
Stanislav Kruchinin wrote:

> Oleg Safiullin wrote:
>> Не вдаваясь в подробности и по сути не совсем в тему если исходить из
>> исходного вопроса...
>> Придержать входящее к самой машине в принципе можно, но потребуются
>> довески (как и во фре собственно,
>> только там довески уже встроены :)
>
> В оригинале вопрос ставился как ограничение входящего трафика для каждого
> юзерского IP, а не просто ограничить входящий трафик до 10 Мбит. В Опене без
> промежуточной машины так не получится, да и то наверное придется руками

И опять неверно.
По прежнему все написанное ранее в силе. Получится.
Другой вопрос - стоит ли так извращаться :)


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Stanislav Kruchinin
Oleg Safiullin wrote:

>>
>> В оригинале вопрос ставился как ограничение входящего трафика для каждого
>> юзерского IP, а не просто ограничить входящий трафик до 10 Мбит. В
>> Опене без
>> промежуточной машины так не получится, да и то наверное придется руками
>
> И опять неверно.
> По прежнему все написанное ранее в силе. Получится.
> Другой вопрос - стоит ли так извращаться :)
>
>
>

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

Вот описание очередей:

altq on $ext_if bandwidth 100Mb hfsc queue { lan wan }
  queue lan bandwidth 90% hfsc
  queue wan bandwidth 1% hfsc { pri def }
    queue def bandwidth 90% priority 5 hfsc (default)
    queue pri bandwidth 10% priority 7 hfsc (realtime 10%)

Вот правило, которое перенаправляет трафик от _всех_ IP в одну очередь wan,
распределяя входящий трафик в def, а исходящий в pri (т.к. в правилах стоит pass
in, вместо pass out).

pass in on $ext_if inet proto tcp to ($ext_if) port { $tcp_svc } \
    queue (def pri)

При этом все IP будут делить между собой полосы пропускания, которые стоят в
определениях def и pri.

Для того, чтобы предоставить каждому из N IP-адресов свою полосу, скажем, в 1%
нужно создать N очередей

altq on $ext_if bandwidth 100Mb hfsc queue { Q1 Q2 ... QN }
  queue Q1 bandwidth 1% hfsc
  queue Q2 bandwidth 1% hfsc
  ...
  queue QN bandwidth 1% hfsc

и трафик каждого IP-адреса направить в свою очередь.

pass in on $ext_if from $ip1 ... queue (Q1)
pass in on $ext_if from $ip2 ... queue (Q2)
..
pass in on $ext_if from $ipN ... queue (QN)


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Anton Maksimenkov-2
>>> В оригинале вопрос ставился как ограничение входящего трафика для каждого
>>> юзерского IP, а не просто ограничить входящий трафик до 10 Мбит. В
>>> Опене без
>>> промежуточной машины так не получится, да и то наверное придется руками
>> И опять неверно.
>> По прежнему все написанное ранее в силе. Получится.
>> Другой вопрос - стоит ли так извращаться :)
> Я чего-то не понимаю, объясните пожалуйста мне как с помощью тех правил можно
> выделить каждому IP свою гарантированную полосу без создания очередей вручную.

+1

скажи, скажи...?
--
engineer
Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Dinar Talypov
In reply to this post by Stanislav Kruchinin
On Wed, 11 Feb 2009 22:04:27 +0300
Stanislav Kruchinin <[hidden email]> wrote:

> Oleg Safiullin wrote:
> >>
> >> В оригинале вопрос ставился как ограничение входящего трафика для каждого
> >> юзерского IP, а не просто ограничить входящий трафик до 10 Мбит. В
> >> Опене без
> >> промежуточной машины так не получится, да и то наверное придется руками
> >
> > И опять неверно.
> > По прежнему все написанное ранее в силе. Получится.
> > Другой вопрос - стоит ли так извращаться :)
> >
> >
> >
>
> Я чего-то не понимаю, объясните пожалуйста мне как с помощью тех правил можно
> выделить каждому IP свою гарантированную полосу без создания очередей вручную.
>
> Вот описание очередей:
>
> altq on $ext_if bandwidth 100Mb hfsc queue { lan wan }
>   queue lan bandwidth 90% hfsc
>   queue wan bandwidth 1% hfsc { pri def }
>     queue def bandwidth 90% priority 5 hfsc (default)
>     queue pri bandwidth 10% priority 7 hfsc (realtime 10%)
>
> Вот правило, которое перенаправляет трафик от _всех_ IP в одну очередь wan,
> распределяя входящий трафик в def, а исходящий в pri (т.к. в правилах стоит pass
> in, вместо pass out).
>
> pass in on $ext_if inet proto tcp to ($ext_if) port { $tcp_svc } \
>     queue (def pri)
>
> При этом все IP будут делить между собой полосы пропускания, которые стоят в
> определениях def и pri.
>
> Для того, чтобы предоставить каждому из N IP-адресов свою полосу, скажем, в 1%
> нужно создать N очередей
>
 А стоит ли это делать для каждого IP?



--
Динар Талыпов


Reply | Threaded
Open this post in threaded view
|

Re: Файловый

Mike Belopuhov
In reply to this post by Stanislav Kruchinin
On Tue, Feb 10, 2009 at 18:03 +0300, Stanislav Kruchinin wrote:

> Sergey Yudin wrote:
> >
> >> В любом случае, файловый сервер на OpenBSD с samba -- это само по себе
> >> странное
> >> решение, не говоря уже "шейпинге" входящего трафика.
> >>
> >>  
> > А какое решение для файлового сервера будет более адекватным ? Ищу на
> > что бы перейти с Netware 4.11
> >
>
> Выбор ОС и способа организации хранилища зависит много от чего: от железа,
> размеров файлов, возможностей масштабирования, скоростных характеристик... Я
> предполагаю, что ваше хранилище будет нераспределенным, т.е. все вертится и
> масштабируется в пределах одной машины. В качестве ОС, естественно, должен быть
> Linux, т.к. там на данный момент есть неплохие файловые системы, zero copy
> sockets и неплохие возможности по настройке i/o-подсистемы ядра. Во FreeBSD тоже
> что-то есть в этом плане, но если те извращения, которые позволяет делать GEOM,
> не нужны, то не стоит и связываться.
>
> Предполагается, что жесткие диски и подходящий SATA/SAS RAID-контроллер от
> 3ware/Areca/Adaptec вы уже купили, и он нормально работает в Linux. Если же
> хранилище будет совсем небольшим, диска на 4, то проще и дешевле cделать
> software RAID, а то и вообще обойтись без RAID.
>
> Если разделы будут более 2 Тб, то для работы с ними нужно использовать GUID
> partition table. Определитесь, нужны ли для данного решения возможности,
> предоставляемые LVM. В частности, LVM полезен если хочется создавать разделы в
> пределах нескольких физических устройств (RAID-контроллеров). Для изменения
> размеров раздела в пределах одного устройства LVM не обязателен, т.к. это можно
> делать прямым редактированием таблицы разделов. В любом случае, файловая система
> должна поддерживать изменение размеров в нужную сторону.
>
> Если объем хранилища будет только увеличиваться, и файлы в основном большие
> (iso, фильмы), то лучше использовать XFS. Если файлы небольшие и приоритетом
> является надежность, а не скорость, то лучше использовать ext3 или ext4.
>

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

единственное только чего в линухе нет по сравнению с Netware -- разграничения
доступа к ресурсам, но можно сделать через LDAP/Active Directory на самбе
или группы на NFS'е.  NFS тоже кривой кстати.

а вообще самым адекватным файл-сервером по фичам именно файл-сервера был и
остается Netware.


Reply | Threaded
Open this post in threaded view
|

Re[2]: как зажать вход

irix
In reply to this post by Oleg Safiullin
Hello Oleg,

Можешь дать пару намёков тормозить tcp соединения по ипам?
В  портах  нашёл  узерспайс тормозилку для приложений trickle, но тоже
нето.  Может  быть  есть  ещё  чтото  наподобие или какие нибудь особо
извращённые способы ?


Wednesday, February 11, 2009, 2:16:16 PM, you wrote:

OS> engineer wrote:
>>> Остальное пусть делает тот кому нужно. По этой же причине не стану развивать
>>> тему разницы между "ну нету" и "ну не знаю как" - из первого письма можно
>>
>> Это мне, на тему "ну нету провайдерского PPPoE решения для провайдера
>> на опёнке", или что-то совсем другое?

OS> На эту :)
OS> Хотя таких тем было дофига в том числе в этов листе.
OS> Достаточно вспомнить (перечисляю только то, что вспомнил в виду
OS> того, что до сих пор используется [много лет]):
OS> - sendmail не работает с maildir
OS> - sendmail не работает виртуальными усерами
OS> - нельзя обратиться к переадресованным на наружнем интерфейсе сервисам изнутри
OS> итд.

OS> По вышеуказанному вопросу сразу скажу: решение неуклюжее,
OS> неудобное и если его и делать, то скорее ради интереса, чем для
OS> практической пользы :)

OS> Понятно, что наличие решения (или даже "решения") далеко не
OS> всегда означет, что его нужно использовать.
OS> Точно также бесполезно сравнивать возможности PF и ipfw - это в
OS> принципе разные вещи по реализации.

OS> Просто уточнение и не более, что в принципе - можно :)
OS> Порекомендовать (и уж тем более назвать их простыми) методы,
OS> которые первыми пришли в голову я бы не решился :)
OS> Если интересно, в привате могу дать пару намеков, только на ночь не читать ;)




--
Best regards,
 irix                            mailto:[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: как зажать вход

Ilya A. Kovalenko
In reply to this post by irix


>   Как зажать входящий поток до 10 мегабит
входящий трафик можно шейпить на шлюзе как исходящий на внутреннем
интерфейсе

>   на каждый ip в локалке,
создать по одной или две очереди и одно-два правила на рыло, чтобы 100 мегабит не
делилось только на 10 пользователей, то root придется делать заведомо больше реального

по другому на ALTQ, AFAIK, никак

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

>   Ну там рассуждения на тему "зачем зажимать вход ?", в
>   мусор.
да, этими разговорами и фрицы с другими буржуями достали. Де факто,
нормальный TCP-трафик можно успешно ограничивать и на входящем. Тупой
же флуд или несогласованный трафик (UDP, ICMP, etc) нельзя ограничить
не повредив ему ни во входящем, ни в исходящем направлениях.


12