Возможно я не очень хорошо понимаю сети. В моем представлении это работает так, что Клауд провайдер может настроить свою сеть до внешних провайдеров таким образом, каким желает. Но когда пакеты выходят за пределы сети провайдера, они уже живут своей собсвтенной жизнью. И он никак не может оказать влияние на то, как пойдут пакеты. За исключением того случая, когда Клауд провайдер имеет в распоряжении свои магистральные сети, или каким то образом договорился с другими провайдерами, чтобы настроили для него маршрутизацию. Иначе как клауд провайдер может настроить путь из точки А в точку Б, если сети, по которым пойдут пакеты, ему не принадлежат?
Графана и Прометеус стоят почти в каждом kubernetes кластере. Не представляю какое обновление должны выкатить, чтобы нельзя было больше в графане показать набор точек на графике))) Speedtest ничего почти не жрет, за исключением момента замера, в прочем как и iperf3.
Ваше решение предполагает 1) сделать кронджобу, которая запускает iperf 2) сделать кронджобу, которая парсит лог файл 3) поднять smtp сервер, для того чтобы слать емейлы. (или использовать готовый, но его надо интегрировать) 4) как то продумать логику замеров, для того чтобы при замере между сереров А и Б понять что проблема в сервере А (а не в сервере Б). То есть надо измерять с каждого сервера несколько других и потом аггрегивать эти данные. При этом ваше решение вообще не работает в кейсе 2 нод. Так как как не проводи замеры, никода не поймешь, на какой стороне проблема. 5) Сделать общее хранилище логов, чтобы еще одна кронджоба проходилась по всем замерам и аггрегировала данные, для того чтобы понять в каком именно сервере проблема.
Возможно я чего либо не понимаю, но мне ваше решение кажется гораздо более сложным. Хотя в нем есть плюсы, если правильно все сделать, то можно получить более точные данные.
И это все, вместо того чтобы сделать helm install и добавить дешборд в графане. Графана и Прометеус в кластере обычно уже есть. У меня во всяком случае были, задолго до того, как появился speedtest-exporter.
Вообще странно слышать про то что speedtest может показывать большую скорость чем есть на самом деле, и мне даже немного сложно в такое проверить. Могу представить ситуацию, когда speedtest показывает меньше. И да, если надо тестить скорость соединения между двумя ЦОД тогда логично использовать iperf (speedtest том такое измерять странно). Когда же надо протестировать скорость выхода в интернет, мне кажется логичнее использовать speedtest. В связке с несколькими ip адресами speedtest. Так как в вашем кейсе, возможно просто конечные сервера имели ограниченную пропускную способность, а ваш ЦОД( с которого вы проводили замер) как раз имел скорость, которую показал speedtest.
У меня просто кейс, в котором ни один из серверов не имеет гарантированную полосу пропускания. Как в таком кейсе с помощью iperf получать данные, котоым можно доверять? Можно с разных серверов проводить замеры, потом как то аггрегировать эти данные и выяснять на котором из серверов просел bandwidth? В моем конкретном случае speedtest выдаст более точные результаты, так как я уже прикрепил результаты своих замеров. При использовании iperf на замеры будет накладываться эта зигзагообразная кривая. Если же у вас в кластере есть сервре, который с гарантией дает 1-2-3 гигабита, то с него можно проводить такие замеры, у меня же такого сервера в кластере нет
Согласен. Результат speedtest может давать погрешности. Я думал о варианте iperf, но отказался от него, так как необходимо иметь хотябы один эталонный сервер, с которого будут проводиться замеры. А это дополнительные денежные затраты. Но в качестве альтернативы можно рассматривать.
Насколько я понял, в этом кейсе полоса пропускания клиента, может стать узким местом сети. То есть вы можете измерять свою полосу пропускания, а не сервера. Также встает вопрос, как хранить эти данные. Потому что метрики нужны также в виде истории. А хранить каким то кастомным образом данные от 20 серверов, которые к тому же могут часто перезагружатся и тд не очень удобно. Зачем заниматься этим, если есть возможность использовать готовые решения. Либо я просто вас не понял
Кроме проблемы с настройкой сервера под VPN есть и другая проблема для большинства пользователей. Сейчас рублями сложно оплатить заграничные сервера. Нужна иностранная карта, которая есть не у всех.
Вы правы, когда подписка стоит копейки, условно 100-200 рублей, очень сложно делать рекламу, так как стоимость одной конверсии выходит гораздо выше чем приносит один покупатель. Но мы сейчас не делаем рекламу, и весь трафик пользователей - это пользователи которые приходят сами по рекомендации и тд. И на текущий момент этот трафик меня устраивает. Условно можно увеличивать количество пользователей на 10 процентов каждый месяц. Если сделать грамотно воронку то реклама особо и не нужна.
Про скачивание торрентов я напишу в следующих статьях. А можете привести примеры кейсов, где люди с похожим бизнесом пострадали. Я просто таких случаев не знаю, хотелось бы ознакомиться с ними подробнее, заранее спасибо)
Как раз таки в кейсе с моим деплоем можно немного поправить код, и будет работать как с гитхабом гитлабом и битбакетом. Буквально пару строчек поправить, и будет работать с чем угодно. А если использовать GitHub Actions etc... то придется каждый раз при переезде с одного провайдера на другой править конфиги
Я соглашусь с вами, что чаще приоритетнее использовать готовые решения, но иногда бывает желание написать что то свое, иногда это помогает узнавать что то новое, так что в велосипедах не вижу ничего плохого, благодаря ним появляется выбор и возможность использовать какие то альтернативы. Согласитесь что не очень круто когда для решения какого то вопроса есть только один возможный вариант. Поэтому лично я ничего не имею против велосипедов, вопрос в их качестве, а когда есть другие люди, которым твой велосипед может понравиться, то велосипед в теории может и перестать быть велосипедом благодаря большому количеству пулл реквестов )
По поводу приведенного эксперимента, он был поставлен некорректно. То есть мыши вероятно вымерли из за инцеста
Возможно я не очень хорошо понимаю сети. В моем представлении это работает так, что Клауд провайдер может настроить свою сеть до внешних провайдеров таким образом, каким желает. Но когда пакеты выходят за пределы сети провайдера, они уже живут своей собсвтенной жизнью. И он никак не может оказать влияние на то, как пойдут пакеты. За исключением того случая, когда Клауд провайдер имеет в распоряжении свои магистральные сети, или каким то образом договорился с другими провайдерами, чтобы настроили для него маршрутизацию. Иначе как клауд провайдер может настроить путь из точки А в точку Б, если сети, по которым пойдут пакеты, ему не принадлежат?
Справедливое замечание)
Графана и Прометеус стоят почти в каждом kubernetes кластере.
Не представляю какое обновление должны выкатить, чтобы нельзя было больше в графане показать набор точек на графике)))
Speedtest ничего почти не жрет, за исключением момента замера, в прочем как и iperf3.
Ваше решение предполагает
1) сделать кронджобу, которая запускает iperf
2) сделать кронджобу, которая парсит лог файл
3) поднять smtp сервер, для того чтобы слать емейлы. (или использовать готовый, но его надо интегрировать)
4) как то продумать логику замеров, для того чтобы при замере между сереров А и Б понять что проблема в сервере А (а не в сервере Б). То есть надо измерять с каждого сервера несколько других и потом аггрегивать эти данные. При этом ваше решение вообще не работает в кейсе 2 нод. Так как как не проводи замеры, никода не поймешь, на какой стороне проблема.
5) Сделать общее хранилище логов, чтобы еще одна кронджоба проходилась по всем замерам и аггрегировала данные, для того чтобы понять в каком именно сервере проблема.
Возможно я чего либо не понимаю, но мне ваше решение кажется гораздо более сложным. Хотя в нем есть плюсы, если правильно все сделать, то можно получить более точные данные.
И это все, вместо того чтобы сделать helm install и добавить дешборд в графане. Графана и Прометеус в кластере обычно уже есть. У меня во всяком случае были, задолго до того, как появился speedtest-exporter.
Вообще странно слышать про то что speedtest может показывать большую скорость чем есть на самом деле, и мне даже немного сложно в такое проверить. Могу представить ситуацию, когда speedtest показывает меньше. И да, если надо тестить скорость соединения между двумя ЦОД тогда логично использовать iperf (speedtest том такое измерять странно). Когда же надо протестировать скорость выхода в интернет, мне кажется логичнее использовать speedtest. В связке с несколькими ip адресами speedtest. Так как в вашем кейсе, возможно просто конечные сервера имели ограниченную пропускную способность, а ваш ЦОД( с которого вы проводили замер) как раз имел скорость, которую показал speedtest.
У меня просто кейс, в котором ни один из серверов не имеет гарантированную полосу пропускания. Как в таком кейсе с помощью iperf получать данные, котоым можно доверять? Можно с разных серверов проводить замеры, потом как то аггрегировать эти данные и выяснять на котором из серверов просел bandwidth? В моем конкретном случае speedtest выдаст более точные результаты, так как я уже прикрепил результаты своих замеров. При использовании iperf на замеры будет накладываться эта зигзагообразная кривая. Если же у вас в кластере есть сервре, который с гарантией дает 1-2-3 гигабита, то с него можно проводить такие замеры, у меня же такого сервера в кластере нет
Кстати, speedtest позволяет задать пул серверов, и тогда результат будет более точным
Согласен. Результат speedtest может давать погрешности. Я думал о варианте iperf, но отказался от него, так как необходимо иметь хотябы один эталонный сервер, с которого будут проводиться замеры. А это дополнительные денежные затраты. Но в качестве альтернативы можно рассматривать.
Насколько я понял, в этом кейсе полоса пропускания клиента, может стать узким местом сети. То есть вы можете измерять свою полосу пропускания, а не сервера. Также встает вопрос, как хранить эти данные. Потому что метрики нужны также в виде истории. А хранить каким то кастомным образом данные от 20 серверов, которые к тому же могут часто перезагружатся и тд не очень удобно. Зачем заниматься этим, если есть возможность использовать готовые решения. Либо я просто вас не понял
Спасибо за наводку. Не знал про возможность использовать SSL напрямую с IP адресом
Нет, не начну)
Кроме проблемы с настройкой сервера под VPN есть и другая проблема для большинства пользователей. Сейчас рублями сложно оплатить заграничные сервера. Нужна иностранная карта, которая есть не у всех.
Вы правы, когда подписка стоит копейки, условно 100-200 рублей, очень сложно делать рекламу, так как стоимость одной конверсии выходит гораздо выше чем приносит один покупатель. Но мы сейчас не делаем рекламу, и весь трафик пользователей - это пользователи которые приходят сами по рекомендации и тд. И на текущий момент этот трафик меня устраивает. Условно можно увеличивать количество пользователей на 10 процентов каждый месяц. Если сделать грамотно воронку то реклама особо и не нужна.
Про скачивание торрентов я напишу в следующих статьях. А можете привести примеры кейсов, где люди с похожим бизнесом пострадали. Я просто таких случаев не знаю, хотелось бы ознакомиться с ними подробнее, заранее спасибо)
Да, вы правы, допустил ошибку, сейчас поправлю)
Данная статья не про то как я привлек много клиентов, а просто пересказ моей истории)
Здравсвтуйте) Про балансировку DNS я напишу в следующей статье, это как раз один из вариантов к которому я пришел в дальнейшем.
Как раз таки в кейсе с моим деплоем можно немного поправить код, и будет работать как с гитхабом гитлабом и битбакетом. Буквально пару строчек поправить, и будет работать с чем угодно. А если использовать GitHub Actions etc... то придется каждый раз при переезде с одного провайдера на другой править конфиги
Я соглашусь с вами, что чаще приоритетнее использовать готовые решения, но иногда бывает желание написать что то свое, иногда это помогает узнавать что то новое, так что в велосипедах не вижу ничего плохого, благодаря ним появляется выбор и возможность использовать какие то альтернативы. Согласитесь что не очень круто когда для решения какого то вопроса есть только один возможный вариант.
Поэтому лично я ничего не имею против велосипедов, вопрос в их качестве, а когда есть другие люди, которым твой велосипед может понравиться, то велосипед в теории может и перестать быть велосипедом благодаря большому количеству пулл реквестов )
Спасибо за комментарий) Я просто знал что они платные и уже особо дальше не стал смотреть в эту сторону) В будущем буду брать в расчет GitHub Actions)