Forwarded from Nrjwolf ⚡️IT Developer
Forwarded from Yehor
Кому не сложно,зайдите в бота @kinofb_bot,напишите старт и впишите любой фильм,сделал фидбек,а проверить не могу
Forwarded from Fᴏʀᴅᴇɴ
Так что летает мысль, что надо собрать 2-3 кодеров для разработки всего этого
Forwarded from Fᴏʀᴅᴇɴ
Понятное дело что потом тоже надо будет каким-то образом монетизировать, но в любом случае проект серьезный
Forwarded from Cool Admin
Вот инструкция как отправить отдельное приложение в отдельный интерфейс на Linux при помощи namespaces.
Самое приятное, что статья платная, а вся важная инфа доступна бесплатно =)
https://xakep.ru/2018/01/15/vpn-linux-network-namespaces/
Самое приятное, что статья платная, а вся важная инфа доступна бесплатно =)
https://xakep.ru/2018/01/15/vpn-linux-network-namespaces/
xakep.ru
VPN не для всех. Туннелируем трафик отдельных приложений с помощью Linux network namespaces
VPN — это замечательная штука, которая повышает твою анонимность и безопасность. Но постоянно сидеть под VPN может быть неудобно: хочешь, например, зайти в интернет-банк со своего реального IP, но на закачке стоит пара новых эпизодов любимого сериала. В Linux…
Forwarded from Cool Admin
Ребята из Linkmeup (https://t.me/linkmeup_podcast) откопали охрененную презентацию про траблшутинг беспроводных сетей (и про софт и железо для этого). Маст рид. 52 слайда годноты http://www.globeron.com/freedownload/services/Globeron-1-2-3-ToolsToAnalyzeRoaming.pdf
Forwarded from Cool Admin
Вот вам, под вечер, неплохой перевод статьи про WebSocket (и немного про HTTP/2+SSE)
https://habrahabr.ru/company/ruvds/blog/342346/
И обзорная статья про отказоустойчивость в MS SQL 2017 в редакции Standart (с примерами и скриптами)
https://habrahabr.ru/post/342248/
https://habrahabr.ru/company/ruvds/blog/342346/
И обзорная статья про отказоустойчивость в MS SQL 2017 в редакции Standart (с примерами и скриптами)
https://habrahabr.ru/post/342248/
Forwarded from Cool Admin
Балансировка нагрузки каналов связи всегда была темой с некоторой долей магии.
Особенно, если речь идёт, про связь с не фиксированными скоростями, например 4G.
Каким образом мы можем балансировать такие каналы связи?
Существует две стратегии (о который известно автору ;) Обе не без изъяна.
Per Host\Connection classifier
В этом подходе мы балансируем нагрузку на каналы по пользователям (одних "налево", одних "направо") или по соединениям.
Часть пользователей или соединений будут «видеть» внешний мир через первый модем, часть через второй (третий, пятый и тд). Мы можем делить равномерно или не очень, определяя отпавший\плохой канал или не обращая на это внимание.
Балансировка по соединениям может нарушать работу некоторых служб, протоколов или веб систем, однако она позволит распределить нагрузку более равномерно. Балансировка по пользователям — прозрачна, но менее равномерна.
У этого подхода есть недостаток — максимальная скорость любого соединения будет равна максимальной скорости того канала (модема), на который данному соединения суждено попасть. Т.е. скорость связи не суммируется. Имеем два канала по 50 мегабит, но сотка не достижима. Это обидно.
Per Package classifier
Существует другой подход — по пакетная балансировка нагрузки между каналами.
Этот подход лишён недостатка в предедущем решении — скорость модемов, с точки зрения проходящего трафика, суммируется. Если мы будем иметь два канала по 50 мегабит, то, теоретически, пользователь сможет использовать их оба "на полную катушку".
Но. Всегда есть но.
Первая проблема (это ты) — это NAT. Для построения такой балансировки нам необходимо использовать некую внешнюю точку приземления трафика и выхода его наружу (и маскарадинга). Т.е. Нам будет необходимо построить два туннеля в какой-либо Датацентр и выпускать пользовательский трафик наружу там. Нууу такое.
А вторая (все твои мечты) — не фиксированные скорости.
Дело в том, что при пакетной балансировке, скорость модемов будет суммироваться не совсем честно.
Если один из каналов в какой-либо момент времени потеряет в скорости и сможет пропустить через себя только 5 мегабит, то общая ширина канала составит 10 мегабит, даже если второй будет способен пропустить в десять раз больше.
Более медленный канал, в силу специфики такой балансировки, будет как бы «тормозить» более быстрый.
(азаза обещал два) Per Package and Signal Quality classifier
Выходом из сложившейся ситуации — будет пакетная балансировка с учётом качества каналов.
Это наиболее гибкий и сложный в реализации способ. Но и он не идеален.
Дело в том, что информация о качестве эфира поступает к нам с задержкой, мы всегда видим картину прошлого, а не текущего статуса, и тем более мы не можем прогнозировать ухудшение качества связи.
Но это лучше чем ничего.
Хозяйке на заметку: Качество сигнала лучше всего получать при помощи AT команд (например, AT+CSQ) если они поддерживаются вашим устройством
Итак, если у вас нет своего ДЦ или хоста с хорошим каналом связи - ваш путь первый, если есть и связь устойчивая - второй, если связь не устойчивая и устройство умеет в скрипты (или автобалансинг) - третий путь ваш.
Stay connected and sorry for the long silence
Особенно, если речь идёт, про связь с не фиксированными скоростями, например 4G.
Каким образом мы можем балансировать такие каналы связи?
Существует две стратегии (о который известно автору ;) Обе не без изъяна.
Per Host\Connection classifier
В этом подходе мы балансируем нагрузку на каналы по пользователям (одних "налево", одних "направо") или по соединениям.
Часть пользователей или соединений будут «видеть» внешний мир через первый модем, часть через второй (третий, пятый и тд). Мы можем делить равномерно или не очень, определяя отпавший\плохой канал или не обращая на это внимание.
Балансировка по соединениям может нарушать работу некоторых служб, протоколов или веб систем, однако она позволит распределить нагрузку более равномерно. Балансировка по пользователям — прозрачна, но менее равномерна.
У этого подхода есть недостаток — максимальная скорость любого соединения будет равна максимальной скорости того канала (модема), на который данному соединения суждено попасть. Т.е. скорость связи не суммируется. Имеем два канала по 50 мегабит, но сотка не достижима. Это обидно.
Per Package classifier
Существует другой подход — по пакетная балансировка нагрузки между каналами.
Этот подход лишён недостатка в предедущем решении — скорость модемов, с точки зрения проходящего трафика, суммируется. Если мы будем иметь два канала по 50 мегабит, то, теоретически, пользователь сможет использовать их оба "на полную катушку".
Но. Всегда есть но.
Первая проблема (это ты) — это NAT. Для построения такой балансировки нам необходимо использовать некую внешнюю точку приземления трафика и выхода его наружу (и маскарадинга). Т.е. Нам будет необходимо построить два туннеля в какой-либо Датацентр и выпускать пользовательский трафик наружу там. Нууу такое.
А вторая (все твои мечты) — не фиксированные скорости.
Дело в том, что при пакетной балансировке, скорость модемов будет суммироваться не совсем честно.
Если один из каналов в какой-либо момент времени потеряет в скорости и сможет пропустить через себя только 5 мегабит, то общая ширина канала составит 10 мегабит, даже если второй будет способен пропустить в десять раз больше.
Более медленный канал, в силу специфики такой балансировки, будет как бы «тормозить» более быстрый.
(азаза обещал два) Per Package and Signal Quality classifier
Выходом из сложившейся ситуации — будет пакетная балансировка с учётом качества каналов.
Это наиболее гибкий и сложный в реализации способ. Но и он не идеален.
Дело в том, что информация о качестве эфира поступает к нам с задержкой, мы всегда видим картину прошлого, а не текущего статуса, и тем более мы не можем прогнозировать ухудшение качества связи.
Но это лучше чем ничего.
Хозяйке на заметку: Качество сигнала лучше всего получать при помощи AT команд (например, AT+CSQ) если они поддерживаются вашим устройством
Итак, если у вас нет своего ДЦ или хоста с хорошим каналом связи - ваш путь первый, если есть и связь устойчивая - второй, если связь не устойчивая и устройство умеет в скрипты (или автобалансинг) - третий путь ваш.
Stay connected and sorry for the long silence
Forwarded from Cool Admin
Проблемы с загрузкой компьютера? Эта «простая и наглядная» схема поможет вам) (на самом деле)
Forwarded from Cool Admin
boot_failure_troubleshooting_flowchart.pdf
307.2 KB
*в более лучшем качестве. (cпасибо, *sm1Ly)
Forwarded from Cool Admin
На случай если вы пропустили релиз новой версии Монстра Мониторинга 3.4
https://habrahabr.ru/company/zabbix/blog/336084/
Более подробно тут:
https://www.zabbix.com/documentation/3.4/manual/introduction/whatsnew340
https://habrahabr.ru/company/zabbix/blog/336084/
Более подробно тут:
https://www.zabbix.com/documentation/3.4/manual/introduction/whatsnew340
Хабр
Вышел Zabbix 3.4
Привет! Хотим поделиться новостью, что у нас появилась новая версия опенсорс системы мониторинга Zabbix 3.4, доступная для скачивания: Из нового: Переработа...
Forwarded from Cool Admin
Перевод отличной статьи от Брендана Грегга про Load Average в Linux.
Мне особенно понравился момент про поиск информации о патче 0.99.14.
https://habrahabr.ru/company/mailru/blog/335326/
Очень подробно и детально. Спасибо майлу за перевод, Брендану за исследование.
Оригинал http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html
Мне особенно понравился момент про поиск информации о патче 0.99.14.
https://habrahabr.ru/company/mailru/blog/335326/
Очень подробно и детально. Спасибо майлу за перевод, Брендану за исследование.
Оригинал http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html
Habr
Load Average в Linux: разгадка тайны
Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда...