Jump to content
Калькуляторы

pavelak

Пользователи
  • Content Count

    20
  • Joined

  • Last visited

About pavelak

  • Rank
    Абитуриент
  1. более чем интересно
  2. итак -- во первых нужно отталкиваться от того что задачка может решаться двумя разными способами 1. определить полосу на всех пользователей и отдельно для каждого создать подклассы 2. определить полосы под конкретные сервисы а остальное поделить на всех ИМХО -- второй вариант проще итого создаём очереди для приоритетного трафика подготовка tc qdisc del root dev $interface rmmod cls_flow rmmod cls_u32 rmmod sch_htb rmmod sch_sfq insmod sch_sfq insmod sch_htb insmod cls_flow insmod cls_u32 tc qdisc add dev $interface root handle 1: htb default 10 # r2q 3 #создаём очередь для высокоприоритетного трафика гарантированной шириной в 10мбит с расшарением до 20мбит и максимальным приоритетом tc class add dev $interface parent 1:1 classid 1:5 htb rate 10Mbit ceil 10mbit rate 20mbit prio 0 #разрешаем использовать полосу нашей сети равномерно через netfilter-conntrack по хостам в нашей сети в случае если conntrack не используется можно использовать ключ dst tc filter add dev $interface parent 5: protocol ip handle 10 flow hash keys nfct-dst divisor 512 #то-же самое делаем для менее приоритетного трафика -- единственное отличие в приоритете tc class add dev $interface parent 1:1 classid 1:10 htb rate 80mbit ceil 90mbit prio 6 tc qdisc add dev $interface parent 1:10 handle 10: sfq perturb 10 #устанавливаем фильтр, который как раз и отвечает за равномерное распределение, опять-же смотрим на ключ nfct-dst и заменяем его на dst если conntrack не используется tc filter add dev $interface parent 5: protocol ip handle 5 flow hash keys nfct-dst divisor 512 tc filter add dev $interface parent 10: protocol ip handle 10 flow hash keys nfct-dst divisor 512 #divisor отвечает за то, сколько хостов в сети (максимальный дивизор на sfq равен 1024), в нашем случае сеть /24 - поэтому используем 512 #устанавливаем фильтры для типа трафика, в данном случае для всей нашей сети 10.0.10.0/24 будет использоваться только высокоприоритетная очередь, и амксимальная скорость соответственно будет 20мбит tc filter add dev $interface parent 1: protocol ip prio 2 u32 match ip dst 10.0.10.0/24 flowid 1:5 #соответственно в данном случае для высокоприоритетного трафика (потому как он обычно разномастный) удобнее всего использовать выставление меток на уровне iptables -j MARK/CONNMARK с последующим просовыванием его в определённую очередь на основе этой метки
  3. sirmax продакшен продакшену рознь, и использование виртуализции имеет свои области применения стоит пару серверов поддержки базовой IT инфраструктуры. задавайте.
  4. если именно xen -- то лучше сразу на сайт citrix -- если нужна виртуализация рекомендую присмотреться к последнему CentOS и KVM.
  5. поставить openvpn, настроить, и соеденить в бридж -- всё легко и просто на winxp -- никакой транслячии и маршрутизации -- полноченный ethernet поверх ip.
  6. во первых между двумя wifi линками особой скорости всё равно не получить -- к тому-же эту самую инкапсуляцию по условиям задачи нужно делать на linux'овых машинах -- и самая дохлый писюк легко это осилит даже на перле. ansi c программистов насколько я могу ошибаться найти довольно просто везде и всюду.
  7. Если вы это мне - абсолютно не наш вариант. Мы раздаём фиксированные, но разные полосы и ничего между ними не делим. Не хватает аплинка - подключаем второй. Смысл использования imq/ifb появляется только тогда, когда исходящий трафик идёт на разных логических линках (не бондится). Если аплинк один - исходящий интерфейс и есть тот самый ifb/imq, и без всяких извращений типа патча в и так дырявое ведро. весь мой пост сводился к тому, что нужно чаще использовать склассификатор flow как более удобную замену хешам, пост ^^^ не асилил.
  8. посмотрел сегодня на vtun.sf.net -- там практически всё что нужно для решения задачи способом, предложенным мной. модуль ядра писать -- это изврат -- легче заюзать netfilter tproxy, а там как-раз можно и на перле написать быстренько.
  9. например нам нужно поделить полосу в 10 мегабит на сетку, в случае неиспользования кем-то полосы , она делиться на остальных равномерно tc qdisc del root dev $interface опционально rmmod cls_flow rmmod cls_u32 rmmod sch_htb rmmod sch_sfq insmod sch_sfq insmod sch_htb insmod cls_flow insmod cls_u32 сам шэйпер tc qdisc add dev $interface root handle 1: htb default 20 # r2q 3 tc class add dev $interface parent 1:1 classid 1:10 htb rate 10mbit ceil 10mbit prio 1 tc qdisc add dev $interface parent 1:10 handle 10: sfq perturb 10 tc filter add dev $interface parent 10: protocol ip handle 10 flow hash keys nfct-dst divisor 512 #divisor отвечает за то, сколько хостов в сети (максимальный дивизор на sfq равен 1024) tc filter add dev $interface parent 1: protocol ip prio 2 u32 match ip dst 192.168.0.0/24 flowid 1:10 #в данном случае наша сеть 192.168.0.0/24 шайпер "вешается" на исходящий на пользователей интерфейс , в случае использования динамических интерфейсов на самом шэйпере необходимо использовать либо imq либо ifb P.S. это всё для Linux
  10. не нужно ничего сжимать -- это сильно усложняет. а если делать через socat - то достаточно написать небольшую программу которая умеет stdio и функцию таймера
  11. для "ускорения" передачи kernel-userspace для не ядерных реализаций коллекторов советую присмотреться к http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/