Комментарии 71
Лимитировать его по скорости не возможно, можно лишь отбрасывая избыточный. А это чревато значительной деградацией качества работы сети.
Ну…
Допустим, на порту в сторону сервера стоит настройка, позволяющая передать ему в единицу времени не более 100кб.
А реально прилетело 150кб трафика. Из них 50кб будет выброшено.
Стек TCP заметит потери, и пройдет через slow start. В результате в следующий квант времени данных наверняка будет меньше, чем 100кб, постепенно снова приближаясь к этой цифре еще через несколько интервалов времени. Таким образом, мы успешно лимитировали трафик по скорости. Хоть и довольно грубо.
Это я только что упрощенно описал работу полисера. И строго говоря, все ISP делают так же, и неважно, хомячковый пользователь или ентерпрайзный. С UDP трафиком в общем и целом сложнее, но ведь наверняка на XEN можно применять полисеры только к определенным классам трафика. В отличие от TCP, UDP редко норовит выжрать всю полосу, какую ему дали. Или опуститься до уровня портов («TCP 80 зарезать на 10мб/с»). Тем более что рубильник будет передан пользователю.
Или у вас задача — дать серверам сеть без потерь (то есть ровно 0% дропов)? Вряд ли, у вас ведь не гоняют FCoE от виртуалки до виртуалки, верно? :) В остальных случаях потери вполне допустимы и являются штатным способом ограничения полосы пропускания.
Здорово, а теперь представьте, что к серверу много запросов, а не один. Полоса уже занята, полисер дропает все лишне на всём порту, новые соединения вообще не могут установиться. Фильтрация отдельных протоколов тут тоже не поможет и технически сложно реализуема. И да, мы стараемся гарантировать 0% loss.
А теперь представьте себе, что квант времени — десятки миллисекунд (как оно и есть на самом деле). И задумайтесь, почему на паршивых каналах (тот же диалап) многопоточная закачка дает отличные результаты.
Еще раз: все провайдеры вешают пользователям полисеры в обе стороны. Только так скорость ограничивается до тарифной. У вас часто не устанавливаются соединения?
Еще раз: все провайдеры вешают пользователям полисеры в обе стороны. Только так скорость ограничивается до тарифной. У вас часто не устанавливаются соединения?
Есть берст и другие нюансы, у провайдеров на шейперах стоят большие буферы. Диалап и ограничения в физических каналах- это совсем другое.
Я знаю только одного провайдера, использующего шейпинг. Это легко понять по тому, как RTT подскакивает до небес при полной утилизации. Но правильный провайдер полисит трафик. Это любой свитч умеет.
Не путайте совершенно разные понятия.
С точки зрения временного отрезка в секунду, police 56k ничем не отличается от диалапа. Ну разве что задержка выше, сильнее колеблется, и потери менее предсказуемые.
Блин, учите основы QoS. Это же самая база.
Не путайте совершенно разные понятия.
С точки зрения временного отрезка в секунду, police 56k ничем не отличается от диалапа. Ну разве что задержка выше, сильнее колеблется, и потери менее предсказуемые.
Блин, учите основы QoS. Это же самая база.
Вот тут человек может и не совсем в теме технически, но эксперимент интересный
www.nn.ru/community/gorod/internet/?do=read&thread=2416010&topic_id=54466871
www.nn.ru/community/gorod/internet/?do=read&thread=2416010&topic_id=54466871
Вывод: РТ и билайн используют полисер, раз не начинают расти софтовые очерели при congestion, и, соответственно, не растет RTT. То есть нормальные провайдеры.
А вот мой онлайм, у которого в остальном замечательная архитектура, шейпит трафик, гад (проводился аналогичный эксперимент). Это хуже, чем дропать малую толику пакетов: страдать начинают все пакеты.
А вот мой онлайм, у которого в остальном замечательная архитектура, шейпит трафик, гад (проводился аналогичный эксперимент). Это хуже, чем дропать малую толику пакетов: страдать начинают все пакеты.
Ерунда. Практика показывает, что это работает. В корп. WAN сети пробовали дропать входящий тсп по гибкой классификации (своя максимальная полоса для разных групп по хостам/сервисам при упирании в bandwith). Учитывая нежелание/невозможность делать нормальный QoS на out-е партнерами, добивались волне себе приемлимых результатов. Congestion control у тсп при таких дропах пусть и грубо, но давал результат.
У меня дома приоритезация голоса во входящем направлении настроена методом полисинга всего остального на где-то 85% полосы канала. Разница ощущается невооруженным ухом (у меня uTorrent постоянно что-то качает).
Да, тоже так делали. Вроде часть полосы простаивает по факту, но с другой стороны, бизнес приложения, недополучившие эти копейки против випов, у которых видеоконференция с мегавипами на квадраты развалилась (или не развалилась) — выбор тут очевиден.
Ну корпоративные видеоконференции обычно через интернет не пускают… Но в целом все верно.
VHS?
А у нас и не через инет. IP VPN ессно. QoS пров обеспечивает худо- бедно (несколько очередей, только маркай трафик, по крайней мере в теории), а вот управление очередями на рутерах пограничных почти нет ни у кого на других площадках. И вообще бардак. Провы последней мили tos занулять даже могут, столкнулся тут недавно к огромному удивлению.
Такие вещи в первую очередь проверяются. Я предпочитаю пустить UDP флуд средствами ostinato и попутно тыщу пингов с роутера, маркированных EF. Пока хоть один дропается — имею мозги провайдеру.
Кстати, сколько он делает? У меня hping3 утыкается в 200Мбит/с на копию, с хоста за раз больше 800-900 мегабит не получается сделать.
Расскажите, как вам это удается (про мозги).
Вот живая недавняя история, в которой не помогли ни официальные письма, ни контакты руководства, только личный контак с инженегром
forum.nag.ru/forum/index.php?showtopic=79770
Вот живая недавняя история, в которой не помогли ни официальные письма, ни контакты руководства, только личный контак с инженегром
forum.nag.ru/forum/index.php?showtopic=79770
Для этого надо быть довольно крупным клиентом, со своим персональным менеджером, на которого тут же эскалируем проблемы при любых проволочках. Инженегров знать не обязательно.
Мы даже добились того, что у некоторых провайдеров время заведения аварийной заявки снизилось с двух часов до 5-и минут :)
Уже половина всех провайдеров одарила нас подарками к НГ, вторая половина на подходе…
Мы даже добились того, что у некоторых провайдеров время заведения аварийной заявки снизилось с двух часов до 5-и минут :)
Уже половина всех провайдеров одарила нас подарками к НГ, вторая половина на подходе…
Конкретно мы — всего лишь филиал. Но филиал большого холдинга, реально крупного клиента. И персональный менеджер есть. На счет него вообще прикольно. В памятке это было все указано — позвонили — он у нас больше не работает, кто нас сейчас курирует? — вам перезвонят. Причем челу, который на наг-е в личку постучался, никаких проблем не составило проверить реальность снижения емкости PDH (последняя миля). И он им(местным) даже писал (и вроде звонил). Потом оказалось, что эти каналы у них у самих на аутсорсе. Ногу сломишь разбираться. Инженегр из истории при этом угорал по полной, он нам сразу сказал, что так будет, в самой начале истории.
Задумайтесь, как работает RED для тсп. Отличие ин от оут только в том, что когда оно на ин — пакеты уже как бы утилизировали полосу. Но дроп вызовет тот же эффект, что и если бы он был на оут-е дальней стороной сделан — тсп скорость сбросит. Да, некие дополнительные потери для полосы, но при том же, в конечном счете более длительном эффекте «осаживания» тсп сессии.
Несмотря на некоторый теоретический профит даже при одном классе трафика, на практике RED задействуют только на неприоритетных классах при наличии рядом приоритетных.
На высокоскоростных физических интерфейсах очереди наполняются/опустошаются слишком быстро, чтобы чуть заблаговременное предупреждение всех отправителей о проблеме сыграло роль. А вот при разбиении на классы WRED позволит вышибать из очереди неприоритетные классы до того, как очередь переполнится и дропаться начнет всё (включая приоритетное).
Но снова: мы говорим о миллисекундах, а не о минутах. События происходят очень быстро, и общий процент потерь будет исчисляться ничтожными долями процента.
На высокоскоростных физических интерфейсах очереди наполняются/опустошаются слишком быстро, чтобы чуть заблаговременное предупреждение всех отправителей о проблеме сыграло роль. А вот при разбиении на классы WRED позволит вышибать из очереди неприоритетные классы до того, как очередь переполнится и дропаться начнет всё (включая приоритетное).
Но снова: мы говорим о миллисекундах, а не о минутах. События происходят очень быстро, и общий процент потерь будет исчисляться ничтожными долями процента.
А random detect внутри недефолтового класса имеет смысл? Ну в том смысле, что бы тяжелая сессия не монополизировала полосу класса?
На самом деле дефолтный класс (CS0) не должен быть самым неприоритетным. Нужно создать отдельные классы под некритичный тяжелый трафик, и маркировать их, скажем, CS1.
Да, WRED имеет смысл везде, где будут тяжелые TCP потоки, и где чувствительный к потерям UDP — редкий гость.
Да, WRED имеет смысл везде, где будут тяжелые TCP потоки, и где чувствительный к потерям UDP — редкий гость.
А будет ли WRED при этом вреден там, где оценка на счет тяжелых тсп потоков окажется ошибочной? Или только бесполезен, а не вреден?
Ну он может дропать чуть больше того, что дропать не следует, и при этом все равно профакапить переполнение очередей и tail drop.
А еще такой глупый вопрос, не сочтите за назойливость :) Допустим есть конструкция вида
policy-map…
class ....1
bandwidth…
class ...2
bandwidth…
…
Принадлежность к классу матчится по сетям/портам.
Если трафик одного из классов упрется в свой bandwidth, то на то, что именно подропается именно внутри класса будет ли влиять маркировка tos/dscp? Ну, допустим, само приложение маркирует свой трафик и эта маркировка до нас в неизменном виде долетает.
policy-map…
class ....1
bandwidth…
class ...2
bandwidth…
…
Принадлежность к классу матчится по сетям/портам.
Если трафик одного из классов упрется в свой bandwidth, то на то, что именно подропается именно внутри класса будет ли влиять маркировка tos/dscp? Ну, допустим, само приложение маркирует свой трафик и эта маркировка до нас в неизменном виде долетает.
Если трафик одного из классов упрется в свой bandwidth, то на то, что именно подропается именно внутри класса будет ли влиять маркировка tos/dscp?
Смотря как настроить.
Неплохая статейка — communitystring.com/2008/08/weighted-random-early-detection-wred/.
Если больше ничего внутри класса не делать, только бэндвич.
«WRED is configured on a physical interface or in a class within a policy map with the random-detect command. By default WRED will only look at IPP and not DSCP»
По дефолту есть некие пороги для каждого класса.
По дефолту есть некие пороги для каждого класса.
Ну и само собой, что говоря упрется, имеется в виду действительно упрется, т.е. занять у других будет нельзя, все под потолок работают.
100кб буфера — это вы сильно много берёте. Размеры буфера очень маленькие — в единицы килобайт. И в результате режутся не «широкие» пики, а узкие, то есть пакеты начинают теряться рано. Формально правильно — по сути издевательство и плохой канал связи. Так что шейперы на исходящие — это всегда зло.
Смотря какой Tc выбран.
В единицы килобайт ставят только на том же диалапе. Когда bc сравним с размером пакета — это плохо. Обычно же сотни килобайт или мегабайты, смотря сколько полосы надо выдать.
И вообще-то шейпер и полисер — принципиально разные штуки. Исходящий шейпер применяется везде, обычно в сторону провайдера, когда тарифная скорость не равна канальной, ради создания собственных очередей. Но шейпинг на свитчах не поддерживается.
В единицы килобайт ставят только на том же диалапе. Когда bc сравним с размером пакета — это плохо. Обычно же сотни килобайт или мегабайты, смотря сколько полосы надо выдать.
И вообще-то шейпер и полисер — принципиально разные штуки. Исходящий шейпер применяется везде, обычно в сторону провайдера, когда тарифная скорость не равна канальной, ради создания собственных очередей. Но шейпинг на свитчах не поддерживается.
Мы с вами продолжаем обсуждать netback/netfront в Xen'е, или абстрактную теорию шейпинга?
Не шейпинга. Полисинга.
ESX умеет полисить, а XEN — нет?
ESX умеет полисить, а XEN — нет?
Полисинг по типам трафика? Теоретически ovs умеет выставлять флаги qos, и обрабатывать их, но netback/netfront — нет, они работают на слишком низком уровне.
Можно было бы задуматься о сложных правилах OVS, но эта фича явно не на неделю работы, а польза от неё — мягко говоря не очевидная, так что мы сделали то, что было просто сделать. ratelimit на уровне netback/netfront практически бесплатный, не требует сложной логики и решает большую часть задач.
Заметим, ratelimit на входящий трафик ставит другой вопрос: кто оплачивает «отрезанную» полосу? Трафик-то уже пришёл.
Можно было бы задуматься о сложных правилах OVS, но эта фича явно не на неделю работы, а польза от неё — мягко говоря не очевидная, так что мы сделали то, что было просто сделать. ratelimit на уровне netback/netfront практически бесплатный, не требует сложной логики и решает большую часть задач.
Заметим, ratelimit на входящий трафик ставит другой вопрос: кто оплачивает «отрезанную» полосу? Трафик-то уже пришёл.
«Трафик-то уже пришёл.»
В общем да. Но для тсп факт отрезания загонит его в рамки за счет congestion control. Правда он будет постоянно пытаться выбиваться и опять будет возникать вопрос отрезанной полосы, но не фатально.
В общем да. Но для тсп факт отрезания загонит его в рамки за счет congestion control. Правда он будет постоянно пытаться выбиваться и опять будет возникать вопрос отрезанной полосы, но не фатально.
На более-менее загруженных серверах проблема не с установленными соединениями и процентом потерь, а с потерей ранних пакетов (SYN/ACK) для новых сессий, а так же плохо закрывающиеся коннекты существующих (FIN).
Нет никакой проблемы, если выбрать настройки полисера пропорционально нагрузке. Если от системы ожидается принятие десятка мегабит, то не надо резать на 100к, и все дела. Вы же сами писали, что рассмотренная в топике фича — страховка. Не вижу никаких проблем поставить полисер на 10мб/с, если в сутки ожидается от силы 1мб/с входящего трафика.
Ну почему «серверные админы» никогда не понимают, что в случае TCP/IP небольшой процент потерь — норма жизни и штатный механизм контроля полосы пропускания? Когда я моим коллегам из соседних отделов объяснял, что, оказывается, «ограничение полосы для системы» = «дропанье всего превосходящего полосу трафика», у них тоже был культурный шок. Они думали, какая-то уличная магия замедляет отправку пакетов. Видимо, краем уха про ECN слышали…
Если запустите сниффер — увидите, что при попытке создания нового TCP соединения SYN уйдет минимум трижды (если на первые два не увидит SYN ACK). Все три пакета потеряются? Только при очень жестоком превышении выделенной полосы, и средствами одного только TCP такого вряд ли удастся добиться. В остальных случаях тоже имеются ретрансмиты, в том числе и на FIN. И чем больше будет потоков, тем меньше будет страдать каждый из них, и тем ближе общая утилизация канала приблизится к выделенной полисером полосе.
Еще раз. Полисер — это нормально. Все этой штукой пользуются. При настройке в соответствии со здравым смыслом никаких проблем не возникает. Никто не заставляет выкручивать его на 56к.
При случае посчитайте, сколько трафика там будет приходить. Лучше не в теории, а на практике.
Все поголовно провайдеры применяют исходящий полисер прямо на порту абонента (самые неадекватные применяют шейпер). Соответственно — они тоже дропают трафик, который уже пришел. И?
Ну почему «серверные админы» никогда не понимают, что в случае TCP/IP небольшой процент потерь — норма жизни и штатный механизм контроля полосы пропускания? Когда я моим коллегам из соседних отделов объяснял, что, оказывается, «ограничение полосы для системы» = «дропанье всего превосходящего полосу трафика», у них тоже был культурный шок. Они думали, какая-то уличная магия замедляет отправку пакетов. Видимо, краем уха про ECN слышали…
Если запустите сниффер — увидите, что при попытке создания нового TCP соединения SYN уйдет минимум трижды (если на первые два не увидит SYN ACK). Все три пакета потеряются? Только при очень жестоком превышении выделенной полосы, и средствами одного только TCP такого вряд ли удастся добиться. В остальных случаях тоже имеются ретрансмиты, в том числе и на FIN. И чем больше будет потоков, тем меньше будет страдать каждый из них, и тем ближе общая утилизация канала приблизится к выделенной полисером полосе.
Еще раз. Полисер — это нормально. Все этой штукой пользуются. При настройке в соответствии со здравым смыслом никаких проблем не возникает. Никто не заставляет выкручивать его на 56к.
кто оплачивает «отрезанную» полосу? Трафик-то уже пришёл.
При случае посчитайте, сколько трафика там будет приходить. Лучше не в теории, а на практике.
Все поголовно провайдеры применяют исходящий полисер прямо на порту абонента (самые неадекватные применяют шейпер). Соответственно — они тоже дропают трафик, который уже пришел. И?
Почитайте www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800a3a25.shtml.
График результата работы полисера вроде бы пугает, но оно будет так только на исключительно низких битрейтах и при единичных потоках. При мегабитах трафика и десятках потоков график работы полисера будет выглядеть почти таким же смазанным, как график работы шейпера.
Ну и там внизу пример настройки полисера на жалкие 3мбит/с. Bc около 100 килобайт. Это достаточно, чтобы ни о каком плохом качестве связи и речи не было. И фактически, если у вас дома интернет-канал составляет 3мбит/с по ethernet — на порту провайдера будет та же настройка. И торренты при этом наверняка выжмут те самые 3мбит/с или около того.
График результата работы полисера вроде бы пугает, но оно будет так только на исключительно низких битрейтах и при единичных потоках. При мегабитах трафика и десятках потоков график работы полисера будет выглядеть почти таким же смазанным, как график работы шейпера.
Ну и там внизу пример настройки полисера на жалкие 3мбит/с. Bc около 100 килобайт. Это достаточно, чтобы ни о каком плохом качестве связи и речи не было. И фактически, если у вас дома интернет-канал составляет 3мбит/с по ethernet — на порту провайдера будет та же настройка. И торренты при этом наверняка выжмут те самые 3мбит/с или около того.
«Покупаем „воздух“ — не дорого, только у Селектел!
Чтобы не дай бог получать столько же, за сколько платите — ограничьте себя!»
Чтобы не дай бог получать столько же, за сколько платите — ограничьте себя!»
Если на машину накладываются ограничения, то оплачиваются только потреблённые ресурсы, то есть «прижатые» лимитами. Кстати, если у вас есть сервера, которые могут работать на воздухе, а не на электричестве, рассмотрим ваше предложение.
До момента запуска серверов, которые работают на воздухе, приходится использовать сервера, которые используют электричество, увы.
До момента запуска серверов, которые работают на воздухе, приходится использовать сервера, которые используют электричество, увы.
Лимиты нужны, чтобы не получилось как тут: habrahabr.ru/post/143039/
Какой в этом большой смысл?
Вы и сейчас берете машину под вырост, платя, к примеру, не за все 8 ядер, а только за потребленное кол-во часов процессорного времени.
Поэтому скорее всего такие настройки будут полезны как защита от больших сумм в биллинге при атаках на сервер (типа DDOS или в этом роде)
Ну и для тестирования
Вы и сейчас берете машину под вырост, платя, к примеру, не за все 8 ядер, а только за потребленное кол-во часов процессорного времени.
Поэтому скорее всего такие настройки будут полезны как защита от больших сумм в биллинге при атаках на сервер (типа DDOS или в этом роде)
Ну и для тестирования
Особого смысла нет. Фича простая, её просили. Сделали, заодно проверили работу нашей системы по совместной разработке ПО. Уложились — 5 дней на всё (около 10 часов).
Да смысл есть всё-таки. Например стартап. На начальном этапе можно резать ресурсы — натестироваться и не вылезать из бюджета. Как только появятся деньги — снимать лимиты и летать!
Кстати так и поступил — порезал процессор и трафик. А то бывают всплески ночью до десятков мегабит от любимых поисковых систем.
Кстати так и поступил — порезал процессор и трафик. А то бывают всплески ночью до десятков мегабит от любимых поисковых систем.
И какая теперь минимальная цена в месяц одного сервера, если зарезать все до минимума? Чисто для тестов простецких например?
..cred-based скедулера Xen..
Простите, но это рукалицо.жпг
А как вы произносите скедулер?
Внезапно: «планировщик» :-)
Шедулер. Или шеджьюла (ну не знаю я, как такое русскими буквами написать). Смотря с кем общаюсь — с русскими или иностранцами.
Шокирующие новости: иногда стоящие подряд буквы могут читаться не так же, как они же по отдельности.
Шокирующие новости: иногда стоящие подряд буквы могут читаться не так же, как они же по отдельности.
Ох уж этот американ инглиш…
Только все равно не «скедул», а хотя бы «скеджул».
Только все равно не «скедул», а хотя бы «скеджул».
Уели.
Зачем вы гласную «u» произносите как «ж»?
Вы тоже читаете английские слова по буквам? :)
Рекомендую поизучать немецкий. Там вообще временами пишется «еу», а читается «ой»…
В habrahabr.ru/company/selectel/blog/159193/#comment_5616653 коллега дал ссылку на произношение.
Рекомендую поизучать немецкий. Там вообще временами пишется «еу», а читается «ой»…
В habrahabr.ru/company/selectel/blog/159193/#comment_5616653 коллега дал ссылку на произношение.
Нет, но «du» я не произношу как «дж» и, как мне очень сильно кажется, носители языка — тоже. И даже по ссылке, кстати :)
sched·ule [skej-ool, -oo l, -oo-uh l; British shed-yool, shej-ool]
dictionary.reference.com/browse/scheduler. Там еще значок динамика…
То, как оно звучит на самом деле, русскими буквами не выражается. Это лишь очень грубое приближение, показывающее общую концепцию звучания. Иначе будете считаться вторым Мутко с его «лет ми спик фром май харт ин инглиш».
dictionary.reference.com/browse/scheduler. Там еще значок динамика…
То, как оно звучит на самом деле, русскими буквами не выражается. Это лишь очень грубое приближение, показывающее общую концепцию звучания. Иначе будете считаться вторым Мутко с его «лет ми спик фром май харт ин инглиш».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Добровольные лимиты для облачных серверов