Работа по шифрованию в nginx ведется в библиотеке OpenSSL (и аналогичных), подозревать их в неэффективном коде при исполнении на CPU оснований пока не было. Есть, однако, криптоускорители как отдельные физические устройства: Intel QAT - через модифицированный OpenSSL, или в сетевых картах Mellanox NVidia ConnectX Dx через kTLS (не копирует лишний раз данные между вебсервером и ядром). Последние используют в Netflix (под freebsd) Нет оснований считать, что реализация на Go будет делать что-то эффективней в разы. Ну по крайней мере до публикаций результатов тестов с понятной методологией P.S.: TLS с ключами RSA 4096 жрут в полтора раза больше CPU на сервере, чем с RSA 2048
DDoS, как несложно предположить, это огромное количество соединений. Вы при нагрузочном добивались того, чтобы LA от TLS был равен половине числа ядер сервера? А это обычный случай при ddos. Nginх при этом жрет только проц, а traefik еще и RAM гигабайтами, потому что на соединение тратит в 10-20 раз больше памяти. Нисколько не спорю с функциональностью ingress / api gateway, но терминировать TLS/ фильтровать DDoS предпочитаю на отдельных нодах с nginx
Речь про то, что если запрос (active probing) к подозреваемому сайту дает HTTP ответ с заголовком server: nginx, а TLS пробы показывают что это golang - то это прокси P.S.: Надеюсь вам не придется видеть, как работают прокси на golang под DDoS, с которым nginx справляется
Можно реализовать это "api" /api/geoip средствами конфига nginx, работать будет вероятно даже быстрее, чем на rust. Учитывая количество полезного кода, с написанием такого проекта справилась бы любая LLM
Не подскажете, почему у последнего AppleTV нет поддержки AV1, несмотря на членство Apple в AOM, и что железо они делают сами? Ну и нет, речь была не про AV1, в разработку и продвижение которого Google вложило кучу денег (и да, сертифицируют железо для GMS тоже они), использование которого сильно экономит трафик в сетях (15% netflix и 16% youtube от глобального интернет-трафика), то есть для них экономически обосновано А про китайские инновационные кодеки, которые за пределами Китая никто не использует, да и данных об аппаратных декодерах в массовых устройствах даже в Китае нет
Российские видеосервисы не производят телефоны, телевизоры (ну разве что приставки, и то, оболочку на стандартное железо), не ставят свои сборки андроидов с экспериментальными кодеками (софтовыми?). А значит, ограничены существующим железом/софтом, которое в худшем случае поддерживает H.264 High. Ок, можно поделить на 3 варианта девайсов: старые (264), Apple (265), новые (AV1), но какие, простите, инновационные кодеки? Где им тут место?
Прошу прощения, запамятовал, на Noctua менял в Gen7, там просто надо было пины в HPшный разъем в другом порядке засунуть. Но для Gen8 процедура похожая - в этом видео есть распиновка коннектора для подключения
Это у gen7-то бесшумный? Шумел, почти как родной корпусной вентилятор. Впрочем, можно было перепаять на что-то потише. БП ExeGate и аналогичные - отвратительные штатные вентиляторы, но стоят копейки. Пришлось тоже перепаять
В gen8 стандартный вентилятор, менялся на новый Noctua или любой другой тихий или не очень. Распиновка разъема другая, менялась иголкой. Штатный работал очень шумно сам по себе, это не брак. Но после замены вентиляторов на тихие, шумными становятся диски на 7200rpm. Сейчас, учитывая фан-базу пользователей gen8, есть много вариантов - как по корпусам, так и по железу. Но нормальные по качеству корпуса, слоты для дисков с легким извлечением, матери с удаленной консолью, да еще и за нормальные деньги... По сравнению с новым микросервером за 9-11 тыр в те времена...
А какой, собственно, "правильный" ответ на вопрос, чем отличается современный коммутатор от маршрутизатора? И что вообще сейчас можно считать коммутатором? Много портов = коммутатор? Не умеет L3?
Вероятно, это следствие требования локальности джойнов. Если данные по старым ключам шардирования вставляются после изменения числа шардов, новые будут попадать на другие шарды. В целом, если шардируется только одна таблица, запросы к distributed таблице будут возвращать корректные данные. Но если несколько, и джойнятся только внутри одного шарда - могут быть проблемы
Ну речь конечно не про rand(), а про xxHash, cityHash, murmurHash. Не ясно, были ли какие-то особые требования, которые привели к выбору именно консистентного хэша
Но в целом проблематика ясна - несколько таблиц, шардированных по одному ключу, и строгое требования нахождения их в одном шарде. Это в целом решалось бы, если например номер посылки увеличивался, и можно было бы отделять вставку и выборку старых отправлений в 3х шардах от новых, в 4 шардах.
3.2ТБ - это очень небольшой объем, вы храните только последние данные? А архивные куда деваете?
Зачем решардировать старые данные, если период их хранения ограничен? Просто заранее добавлять шарды, с учетом того, что полную нагрузку они будут нести через год. Да и востребованность старых данных как правило сильно ниже, важнее распределение по всем добавленным шардам новых данных? Требование локальности джойнов проще ослабить, или решардировать только меняющиеся/недавние данные.
Зачем консистентный хэш? Ключ в виде номера посылки не будет повторяться, записи по этому ключу дополняются новыми только короткое время. При добавлении шардов все равно часть ключей переедет на другой шард, то есть требование строгой локальности перестанет выполняться
Еще чуть-чуть воды добавить, и можно как книгу издать. Тем не менее, причина возникновения НЕ была обнаружена. А, вероятно, она всего лишь в замене кодов символов при формировании PDF, обычно ПО использует это для font subsetting (когда глифы для букв шрифта включаются в PDF только если буква встречается в тексте), а тут могло быть следствием косяков особенностей библиотеки
За практику деньги платят. Учитывая то, что курс должен проходить готовый DevOps, было бы странно на работе, где ему предстоит внедрять DevSecOps, не платили бы зарплату за две уже имеющиеся квалификации из трех
Зачем такие сложности по запуску виртуалки MacOS x86 на Intel Mac, если это штатно работает на бесплатной VMWare Fusion < 13.0.0 ? Для запуска гостевой MacOS ARM на Apple Silicon есть также бесплатный UTM
За подозрения в недостаточной проверки владения доменом был заблокирован корневой сертификат WoSign. Ну не только, якобы они выпустили левый серт для github.com задним числом. Но ssl.com это ненарочно, им простят
Если найти методологию тестирования Intel (согласно которой пишутся эти вот самые цифры 3.2 на чтение, 1.8 на запись), то из нее [примерно] следует, что сделано это при условии локальной записи/чтения блоками 256к (или даже 512к?), на сырое устройство без файловой системы. Для тестов 1М пусть ок, предположим что эффективнее чем 256к, но на 16к получить цифры, превышающее Интеловые - выглядит странно. То ли префетч/батчинг, то ли погрешность измерения/методики. Ну или предположить, что транспорт так хорош, что быстрее локальных дисков. А какие локальные показатели (fio) с машины куда воткнуты диски?
Это обычный пресс-релиз для профильных и непрофильных СМИ, на хабре конечно интереснее было бы прочитать инженерные подробности
Работа по шифрованию в nginx ведется в библиотеке OpenSSL (и аналогичных), подозревать их в неэффективном коде при исполнении на CPU оснований пока не было. Есть, однако, криптоускорители как отдельные физические устройства: Intel QAT - через модифицированный OpenSSL, или в сетевых картах
MellanoxNVidia ConnectX Dx через kTLS (не копирует лишний раз данные между вебсервером и ядром). Последние используют в Netflix (под freebsd)Нет оснований считать, что реализация на Go будет делать что-то эффективней в разы. Ну по крайней мере до публикаций результатов тестов с понятной методологией
P.S.: TLS с ключами RSA 4096 жрут в полтора раза больше CPU на сервере, чем с RSA 2048
DDoS, как несложно предположить, это огромное количество соединений.
Вы при нагрузочном добивались того, чтобы LA от TLS был равен половине числа ядер сервера? А это обычный случай при ddos. Nginх при этом жрет только проц, а traefik еще и RAM гигабайтами, потому что на соединение тратит в 10-20 раз больше памяти. Нисколько не спорю с функциональностью ingress / api gateway, но терминировать TLS/ фильтровать DDoS предпочитаю на отдельных нодах с nginx
Речь про то, что если запрос (active probing) к подозреваемому сайту дает HTTP ответ с заголовком server: nginx, а TLS пробы показывают что это golang - то это прокси
P.S.: Надеюсь вам не придется видеть, как работают прокси на golang под DDoS, с которым nginx справляется
Можно реализовать это "api" /api/geoip средствами конфига nginx, работать будет вероятно даже быстрее, чем на rust.
Учитывая количество полезного кода, с написанием такого проекта справилась бы любая LLM
Не подскажете, почему у последнего AppleTV нет поддержки AV1, несмотря на членство Apple в AOM, и что железо они делают сами?
Ну и нет, речь была не про AV1, в разработку и продвижение которого Google вложило кучу денег (и да, сертифицируют железо для GMS тоже они), использование которого сильно экономит трафик в сетях (15% netflix и 16% youtube от глобального интернет-трафика), то есть для них экономически обосновано
А про китайские инновационные кодеки, которые за пределами Китая никто не использует, да и данных об аппаратных декодерах в массовых устройствах даже в Китае нет
Российские видеосервисы не производят телефоны, телевизоры (ну разве что приставки, и то, оболочку на стандартное железо), не ставят свои сборки андроидов с экспериментальными кодеками (софтовыми?). А значит, ограничены существующим железом/софтом, которое в худшем случае поддерживает H.264 High. Ок, можно поделить на 3 варианта девайсов: старые (264), Apple (265), новые (AV1), но какие, простите, инновационные кодеки? Где им тут место?
Прошу прощения, запамятовал, на Noctua менял в Gen7, там просто надо было пины в HPшный разъем в другом порядке засунуть. Но для Gen8 процедура похожая - в этом видео есть распиновка коннектора для подключения
Это у gen7-то бесшумный? Шумел, почти как родной корпусной вентилятор. Впрочем, можно было перепаять на что-то потише. БП ExeGate и аналогичные - отвратительные штатные вентиляторы, но стоят копейки. Пришлось тоже перепаять
В gen8 стандартный вентилятор, менялся на новый Noctua или любой другой тихий или не очень. Распиновка разъема другая, менялась иголкой. Штатный работал очень шумно сам по себе, это не брак. Но после замены вентиляторов на тихие, шумными становятся диски на 7200rpm.
Сейчас, учитывая фан-базу пользователей gen8, есть много вариантов - как по корпусам, так и по железу. Но нормальные по качеству корпуса, слоты для дисков с легким извлечением, матери с удаленной консолью, да еще и за нормальные деньги... По сравнению с новым микросервером за 9-11 тыр в те времена...
А какой, собственно, "правильный" ответ на вопрос, чем отличается современный коммутатор от маршрутизатора? И что вообще сейчас можно считать коммутатором? Много портов = коммутатор? Не умеет L3?
Вероятно, это следствие требования локальности джойнов. Если данные по старым ключам шардирования вставляются после изменения числа шардов, новые будут попадать на другие шарды. В целом, если шардируется только одна таблица, запросы к distributed таблице будут возвращать корректные данные. Но если несколько, и джойнятся только внутри одного шарда - могут быть проблемы
Ну речь конечно не про rand(), а про xxHash, cityHash, murmurHash. Не ясно, были ли какие-то особые требования, которые привели к выбору именно консистентного хэша
Но в целом проблематика ясна - несколько таблиц, шардированных по одному ключу, и строгое требования нахождения их в одном шарде. Это в целом решалось бы, если например номер посылки увеличивался, и можно было бы отделять вставку и выборку старых отправлений в 3х шардах от новых, в 4 шардах.
А как вы обеспечиваете отказоустойчивость шардов?
3.2ТБ - это очень небольшой объем, вы храните только последние данные? А архивные куда деваете?
Зачем решардировать старые данные, если период их хранения ограничен? Просто заранее добавлять шарды, с учетом того, что полную нагрузку они будут нести через год. Да и востребованность старых данных как правило сильно ниже, важнее распределение по всем добавленным шардам новых данных? Требование локальности джойнов проще ослабить, или решардировать только меняющиеся/недавние данные.
Зачем консистентный хэш? Ключ в виде номера посылки не будет повторяться, записи по этому ключу дополняются новыми только короткое время. При добавлении шардов все равно часть ключей переедет на другой шард, то есть требование строгой локальности перестанет выполняться
Еще чуть-чуть воды добавить, и можно как книгу издать.
Тем не менее, причина возникновения НЕ была обнаружена. А, вероятно, она всего лишь в замене кодов символов при формировании PDF, обычно ПО использует это для font subsetting (когда глифы для букв шрифта включаются в PDF только если буква встречается в тексте), а тут могло быть следствием
косяковособенностей библиотекиЗа практику деньги платят. Учитывая то, что курс должен проходить готовый DevOps, было бы странно на работе, где ему предстоит внедрять DevSecOps, не платили бы зарплату за две уже имеющиеся квалификации из трех
ГеоДНС, Anycast, балансировка по методам, кэширование и прочий CDN.. Нет, не слышали. А в статье точно только форматирование от чатгпт?
Зачем такие сложности по запуску виртуалки MacOS x86 на Intel Mac, если это штатно работает на бесплатной VMWare Fusion < 13.0.0 ?
Для запуска гостевой MacOS ARM на Apple Silicon есть также бесплатный UTM
Да там изначально так было. "CALs are required for every user or device accessing a server". Просто CAL пока не на месяц
За подозрения в недостаточной проверки владения доменом был заблокирован корневой сертификат WoSign. Ну не только, якобы они выпустили левый серт для github.com задним числом.
Но ssl.com это ненарочно, им простят
Если найти методологию тестирования Intel (согласно которой пишутся эти вот самые цифры 3.2 на чтение, 1.8 на запись), то из нее [примерно] следует, что сделано это при условии локальной записи/чтения блоками 256к (или даже 512к?), на сырое устройство без файловой системы. Для тестов 1М пусть ок, предположим что эффективнее чем 256к, но на 16к получить цифры, превышающее Интеловые - выглядит странно. То ли префетч/батчинг, то ли погрешность измерения/методики. Ну или предположить, что транспорт так хорош, что быстрее локальных дисков.
А какие локальные показатели (fio) с машины куда воткнуты диски?