Стандарты дают гарантии: бери вот этот соответствующий стандарту кабель и на таких длинах он будет работать. Это не означает, что другой подешевле не будет, ну или подлиннее. Может вам и повезет, но уже без гарантий. А еще очень важна температура. К примеру, начиная с 20℃ в кабеле усиливается затухание сигнала (вот тут, к примеру есть табличка). Поэтому то, что вроде как работало на 10Гбит ранее, в период включения батарей почему-то может и перестать. Или базовую станцию на крыше запустили и опять то, что хорошо работало, почему-то перестало.
Я хочу сказать, что особого смысла в этих экспериментах не будет – они исключительно индивидуальны: right here, right now.
За счет специальной обработки сигнала т.н. гибридными схемами. Каждая пара работает в полном дуплексе. Таймеры обеих сторон синхронизированы по одной из них. Они одновременно отправляют информацию в канал. При этом получатель видит как свой сигнал, так и отправленный другой стороной наложенными. Но он знает, что и когда отправлял сам. Это позволяет убрать собственный сигнал из полученного и восстановить то, что было передано другой стороной.
Дома, или в офисе любой бронированный кабель в конце концов закончится каким-нибудь LC-, или SC- коннектором около которого волокно кто-нибудь и переломит.
Я не эксперт в пром. сетях, но насколько мне известно, Profinet использует Ethernet как транспорт, являясь набором протоколов более высокого уровня. При этом, то, что используется как транспорт обычно именуется Industrial Ethernet, который, как я понимаю, хоть и в основе использует IEEE 802.3 стандарты, но может быть очень vendor specific. И NBASE-T1L серия стандартов как раз и является попыткой унифицировать физический уровень передачи, очистить его от патентных ограничений и упростить интеграцию.
Это случилось с появлением 1000Base-T. В нём поддерживался только полный дуплекс. И, да, за счет этого фактическая пропускная способность нагруженной сети выросла чуть не двукратно.
Для сложной бизнес логики haproxy сложно конфигурировать и этому придется учить людей, тогда как конфиги nginx умеют делать в том, или ином виде многие. Можно разделить зоны ответственности и взять лучшее от двух продуктов.
Вот об этом хотелось рассказать и о том, чего это будет стоить. А лобовых сравнений nginx и haproxy по производительности довольно много. Спойлер: они зависят от того, кто и как тестирует :) Но, в целом, если усреднить, результаты близки и выбирать нужно по каким-то другим факторам.
Всё перепуталось :) * Начальный вариант: есть хост с nginx который работает с бекендами на других хостах. На Nginx довольно сложные конфиги с кучей locations, рерайтов, редиректов, зависимостей от заголовков и прочих фронтендных радостей. Там же секции upstream со всеми бекендами. Это все, конечно, можно попотеть и перенести на haproxy. Но потом это все еще и придется поддерживать. А, к сожалению, "читабельность" сложных конфигураций у haproxy значительно ниже, чем у nginx. * Конечный вариант: nginx с прежними сложными конфигами и теми же владельцами, но с upstream, по сути из одной строчки, смотрящей на haproxy, который живет на том же хосте, что и nginx. Конечные бекенды по прежнему удаленные и о них знает только haproxy. По итогу мы можем править бизнес-логику на nginx и логику распределения на haproxy. Каждый продукт занимается своим делом.
Спасибо за интересный вопрос, на "почему не XXX" всегда сложно отвечать, так как вариантов много, они все замечательные и можно долго спорить :) Пройдемся по пунктам:
* Проверки работоспособности бекендов. На мой взгляд, tengine, как и любой другой форк, это уже не совсем nginx. Можно доверять проекту и использовать его, но кодовая база – иная и развиваемая в интересах одного конкретного клиента. В нашем случае – это было важно. О причинах я писал в комментариях выше (поддержка, аудит кода, совместимость, и т.д.). Впрочем, agent_check и возможности динамического изменения весов в tengine кажется все равно нет (выкручусь я). Или есть?
* Одновременные запросы к бекенду. limit_req прекрасен, но он все таки, как вы верно заметили про RPS, а не про одновременное количество запросов, которое сервер выдержит. К примеру, если сервер отвечает за 10 мс, но умирает по памяти на 101 одновременном клиенте, то при 200 запросах в секунду мы можем как выжить, так и не выжить – как повезет. С другой стороны, если мы гарантируем, что больше 100 запросов на сервер не будут переданы еодиномоментно – 10000 RPS вполне могут быть обслужены. Всё зависит от сценария и иметь обе возможности в доступности – вдвойне замечательно.
* "синхронизированные счетчики". Я, извините, не очен понял – это вопрос про agent_check и веса? Или про встроенные в haproxy распределенно-синхронизируемые счетчики?
* Про VTS уже за меня ответили – haproxy все-таки тут более открыт для анализа. Да я и говорил "отсутствие встроенного способа получения вменяемой статистики", т.е. внешние существуют, но на них придется завязываться, а тот же VTS даже сейчас в версии 0.2.2, что нисколько не умаляет его заслуг, но несколько лишает уверенности.
А теперь попробую ответить на "зачем". Главный плюс, который мы получили от такого бутерброда, если убрать в сторону тактические преймущества конкретных продуктов, – разделение зон ответственности. Мы растащили собственно работу с бекендами и бизнес-логику сайтов. В результате, все тот же nginx можно было легко заменить на любой другой подходящий прокси-сервис, если того требовала задача (и мы так делали), а доставка трафика от бекендов при этом никак не менялась. И наоборот – различные конфигурации бекендов для различных локаций никак не отражались на конфигурации nginx, что очень упрощало и делало более безопасной его настройку.
Где-то между 100 и 200 одновременными подключениями на хост при генерируемом ответе в 1мб на хосте-сервере кончается память, OOM убивает сервис и systemd его перезапускает.
Чуть выше отвечал про tengine – форки интересные есть, но очень много вопросов возникает при "промышленном" использовании: * А если протестированная под nginx конфигурация под angie поведет себя как-то иначе? * А тестировали ли они свой проект под теми нагрузками, которые нас интересуют? А вытянет сто бекендов, а тысячу? * А как там с аудитом кода на безопасность? * А как быстро ответят на вопрос о проблеме и починят найденный баг? * А будет ли проект поддерживаться через год-другой? Если брать широко используемые инструменты всё становится несколько проще. Ну или уже писать своё, если есть ресурсы.
Это уже вопрос доверия к кодовой базе и её сопровождению. Все проблемы с тем же haproxy (там был сложный период большого рефакторинга, после которого появился рабочий nbthreads) мейнтейнеры решали в пределах недели после баг репорта. Один раз даже сообщил о баге в пятницу вечером, а в субботу уже был патч. И это без платного контракта. Были ли у вас прецеденты решения проблем с авторами tengine? Есть ли какая-то статистика?
Тут есть интересный момент. Так как на lo-интерфейсе висит адрес 127.0.0.1 (с маской /8), то при подключении к 127.0.0.2, например, будет образовано соединение между 127.0.0.1:клиентский_порт и 127.0.0.2:серверный _порт. Что все равно ограничивает доступное количество клиентских портов. С отдельным /128 адресом на lo-интерфейсе такого уже не произойдет, так как соединение будет с того же адреса.
Ну и бардак с адресами, как я писал, в случае 127.0.0.2 и т.д. будет редкостный. Ipv6 позволяет лучше все упорядочить.
Мы примерно так и поступили, но со списком бекендов в haproxy. Это позволило отделить динамическое управление бекендами от конфигурации собственно сайта в Nginx.
Если речь идет о тестировании живым трафиком – это типовые reverse proxy (например, haproxy) + небольшой самописный прокси-сервис, позволяющий нарезать трафик точно по RPS. Танк – он все-таки про оффлайн стенды.
Спасибо за замечание, добавил и эту часть истории.
Стандарты дают гарантии: бери вот этот соответствующий стандарту кабель и на таких длинах он будет работать. Это не означает, что другой подешевле не будет, ну или подлиннее. Может вам и повезет, но уже без гарантий. А еще очень важна температура. К примеру, начиная с 20℃ в кабеле усиливается затухание сигнала (вот тут, к примеру есть табличка). Поэтому то, что вроде как работало на 10Гбит ранее, в период включения батарей почему-то может и перестать. Или базовую станцию на крыше запустили и опять то, что хорошо работало, почему-то перестало.
Я хочу сказать, что особого смысла в этих экспериментах не будет – они исключительно индивидуальны: right here, right now.
За счет специальной обработки сигнала т.н. гибридными схемами. Каждая пара работает в полном дуплексе. Таймеры обеих сторон синхронизированы по одной из них. Они одновременно отправляют информацию в канал. При этом получатель видит как свой сигнал, так и отправленный другой стороной наложенными. Но он знает, что и когда отправлял сам. Это позволяет убрать собственный сигнал из полученного и восстановить то, что было передано другой стороной.
Спасибо, что заметили ошибку! Исправил.
Может мой домашний провайдер какой-то уникальный, а все остальные молодцы, но нет, никаких розеток.
Спасибо за похвалу!
Дома, или в офисе любой бронированный кабель в конце концов закончится каким-нибудь LC-, или SC- коннектором около которого волокно кто-нибудь и переломит.
Я не эксперт в пром. сетях, но насколько мне известно, Profinet использует Ethernet как транспорт, являясь набором протоколов более высокого уровня. При этом, то, что используется как транспорт обычно именуется Industrial Ethernet, который, как я понимаю, хоть и в основе использует IEEE 802.3 стандарты, но может быть очень vendor specific. И NBASE-T1L серия стандартов как раз и является попыткой унифицировать физический уровень передачи, очистить его от патентных ограничений и упростить интеграцию.
Это случилось с появлением 1000Base-T. В нём поддерживался только полный дуплекс. И, да, за счет этого фактическая пропускная способность нагруженной сети выросла чуть не двукратно.
Интересно было бы сравнить современные объемы продаж UTP и оптоволокна в SOHO сегменте. Я, к сожалению, не нашел такой статистики в публичном доступе.
Для сложной бизнес логики haproxy сложно конфигурировать и этому придется учить людей, тогда как конфиги nginx умеют делать в том, или ином виде многие. Можно разделить зоны ответственности и взять лучшее от двух продуктов.
Вот об этом хотелось рассказать и о том, чего это будет стоить. А лобовых сравнений nginx и haproxy по производительности довольно много. Спойлер: они зависят от того, кто и как тестирует :) Но, в целом, если усреднить, результаты близки и выбирать нужно по каким-то другим факторам.
Всё перепуталось :)
* Начальный вариант: есть хост с nginx который работает с бекендами на других хостах. На Nginx довольно сложные конфиги с кучей locations, рерайтов, редиректов, зависимостей от заголовков и прочих фронтендных радостей. Там же секции upstream со всеми бекендами. Это все, конечно, можно попотеть и перенести на haproxy. Но потом это все еще и придется поддерживать. А, к сожалению, "читабельность" сложных конфигураций у haproxy значительно ниже, чем у nginx.
* Конечный вариант: nginx с прежними сложными конфигами и теми же владельцами, но с upstream, по сути из одной строчки, смотрящей на haproxy, который живет на том же хосте, что и nginx. Конечные бекенды по прежнему удаленные и о них знает только haproxy.
По итогу мы можем править бизнес-логику на nginx и логику распределения на haproxy. Каждый продукт занимается своим делом.
Спасибо за интересный вопрос, на "почему не XXX" всегда сложно отвечать, так как вариантов много, они все замечательные и можно долго спорить :) Пройдемся по пунктам:
* Проверки работоспособности бекендов. На мой взгляд, tengine, как и любой другой форк, это уже не совсем nginx. Можно доверять проекту и использовать его, но кодовая база – иная и развиваемая в интересах одного конкретного клиента. В нашем случае – это было важно. О причинах я писал в комментариях выше (поддержка, аудит кода, совместимость, и т.д.). Впрочем, agent_check и возможности динамического изменения весов в tengine кажется все равно нет (выкручусь я). Или есть?
* Одновременные запросы к бекенду.
limit_reqпрекрасен, но он все таки, как вы верно заметили про RPS, а не про одновременное количество запросов, которое сервер выдержит. К примеру, если сервер отвечает за 10 мс, но умирает по памяти на 101 одновременном клиенте, то при 200 запросах в секунду мы можем как выжить, так и не выжить – как повезет. С другой стороны, если мы гарантируем, что больше 100 запросов на сервер не будут переданы еодиномоментно – 10000 RPS вполне могут быть обслужены. Всё зависит от сценария и иметь обе возможности в доступности – вдвойне замечательно.* "синхронизированные счетчики". Я, извините, не очен понял – это вопрос про agent_check и веса? Или про встроенные в haproxy распределенно-синхронизируемые счетчики?
* Про VTS уже за меня ответили – haproxy все-таки тут более открыт для анализа. Да я и говорил "отсутствие встроенного способа получения вменяемой статистики", т.е. внешние существуют, но на них придется завязываться, а тот же VTS даже сейчас в версии 0.2.2, что нисколько не умаляет его заслуг, но несколько лишает уверенности.
А теперь попробую ответить на "зачем". Главный плюс, который мы получили от такого бутерброда, если убрать в сторону тактические преймущества конкретных продуктов, – разделение зон ответственности. Мы растащили собственно работу с бекендами и бизнес-логику сайтов. В результате, все тот же nginx можно было легко заменить на любой другой подходящий прокси-сервис, если того требовала задача (и мы так делали), а доставка трафика от бекендов при этом никак не менялась. И наоборот – различные конфигурации бекендов для различных локаций никак не отражались на конфигурации nginx, что очень упрощало и делало более безопасной его настройку.
Где-то между 100 и 200 одновременными подключениями на хост при генерируемом ответе в 1мб на хосте-сервере кончается память, OOM убивает сервис и systemd его перезапускает.
Чуть выше отвечал про tengine – форки интересные есть, но очень много вопросов возникает при "промышленном" использовании:
* А если протестированная под nginx конфигурация под angie поведет себя как-то иначе?
* А тестировали ли они свой проект под теми нагрузками, которые нас интересуют? А вытянет сто бекендов, а тысячу?
* А как там с аудитом кода на безопасность?
* А как быстро ответят на вопрос о проблеме и починят найденный баг?
* А будет ли проект поддерживаться через год-другой?
Если брать широко используемые инструменты всё становится несколько проще. Ну или уже писать своё, если есть ресурсы.
Это уже вопрос доверия к кодовой базе и её сопровождению. Все проблемы с тем же haproxy (там был сложный период большого рефакторинга, после которого появился рабочий nbthreads) мейнтейнеры решали в пределах недели после баг репорта. Один раз даже сообщил о баге в пятницу вечером, а в субботу уже был патч. И это без платного контракта.
Были ли у вас прецеденты решения проблем с авторами tengine? Есть ли какая-то статистика?
Тут есть интересный момент. Так как на lo-интерфейсе висит адрес 127.0.0.1 (с маской /8), то при подключении к 127.0.0.2, например, будет образовано соединение между 127.0.0.1:клиентский_порт и 127.0.0.2:серверный _порт. Что все равно ограничивает доступное количество клиентских портов. С отдельным /128 адресом на lo-интерфейсе такого уже не произойдет, так как соединение будет с того же адреса.
Ну и бардак с адресами, как я писал, в случае 127.0.0.2 и т.д. будет редкостный. Ipv6 позволяет лучше все упорядочить.
Мы примерно так и поступили, но со списком бекендов в haproxy. Это позволило отделить динамическое управление бекендами от конфигурации собственно сайта в Nginx.
А что, конкретно, вы считаете улучшится?