- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 22:51 , 23-Апр-24 (1) –2
Nginx уже не актуален, провальная инвестиция ф5.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 01:06 , 24-Апр-24 (16)
Ну, своё бабло они на этом сгребли. Причём, насколько я слышал, больше на продаже готовых коробок (программно-аппаратных комплексов), чем на nginx plus.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 07:39 , 24-Апр-24 (28)
А что сейчас актуально?
Не троллинга для, правда интересно.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 08:28 , 24-Апр-24 (30) +4
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 09:22 , 24-Апр-24 (39)
envoy — прокси-сервер
nginx — веб-серверТы уверен, что понимаешь о чем говоришь?
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Анониматор, 11:19 , 24-Апр-24 (45) +1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 14:39 , 24-Апр-24 (52) –3
> nginx — веб-серверnginx — это веб-сервер, прокси-сервер и кэширующий сервер.
HTTP-утка, которая и ходит, и летает, и плавает, но все это делает не очень хорошо.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 15:30 , 24-Апр-24 (54)
> HTTP-утка, которая и ходит, и летает, и плавает, но все это делает не очень хорошо.По сравнению с HTTP-утюгом апачем, который в основном норовит на ногу упасть - не так уж и плохо.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 15:49 , 24-Апр-24 (59)
Игра была равна. Ну, разве что конкретно на задачах PHP nginx+php-fpm жрет меньше памяти, чем mod_php.А в остальном — апач такая же утка.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 01:07 , 25-Апр-24 (68)
> Игра была равна. Ну, разве что конкретно на задачах PHP nginx+php-fpm жрет
> меньше памяти, чем mod_php.Там еще кеширование есть, и вообще - в целом core куда эффективнее опача голимого. Опач это вообще такая штука, которой место - в их же могильнике. > А в остальном — апач такая же утка. Он не утка, он утюг. Ходит, плавает и летает примерно одинаково. Т.е. можно водить на поводке за шнур, если делать совсем нехрен. Всплытие умеет исключительно отрицательное. А полет... ну, если с самолета выкинуть...
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , noc101, 02:55 , 26-Апр-24 (76) +1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 09:11 , 24-Апр-24 (34) –1
Сейчас актуальны сервера-однодневки на го, конфигурируемые ямлом и пиарящиеся девопснёй.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , нах., 09:23 , 24-Апр-24 (40) +4
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 15:31 , 24-Апр-24 (55)
> быстрапачинить на коленке правда тоже не получится, но у них конь-тиниус
> дизинтегрейшн и a/b подход, поэтому...ой...нате вам пока заглушку "проводятся
> технические работы, мы вернемся как только тимлид выйдет из творческого запоя"Ну так тимлид сопьется, или к конкуренту уйдет. И останется старуха у разбитой заглушки. Показываемой сабжем поди, да? :)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Фняк, 23:36 , 24-Апр-24 (65)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 02:02 , 25-Апр-24 (69)
Давно уже как ранжировать стали умнее, так что вся эта SEOятина
потехоньку заглохла.Трепыхалось там еще какая-то по-ень с семантическим ядром, но
и против этих говн ввели голосование и пользователи реальные
зарегистрированные все эти поисковые мусорыне сайты сливали
в ноль почти в первый день. Так что сейчас если ты не в рейтинге Боженова, то ты лох
и сайт твой не дороже борща стоит
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Anon123999, 10:14 , 24-Апр-24 (43) +2
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 22:53 , 23-Апр-24 (2) +2
> Стабильный выпуск проекта FreeNginx 1.26.0А сколько процентов у FreeNginx?
Они хоть что-то сами сделали за это время?
Или только git fetch origin и поехали?
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 08:19 , 24-Апр-24 (29) +6 [^]
А думаешь просто было придумать название? Это было колоссальное психическое напряжение, после которого требуется отпуск в несколько лет.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , mister_0, 22:57 , 23-Апр-24 (3) –11 [V]
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 23:05 , 23-Апр-24 (4) +5
Пусть каждый AI пишет свой веб сервер, потом они сами друг другу делать будут ревью и по результатам, будут заново переписывать, главное чтобы конфигурационный файл подходил, а использовать ты сможешь любую версию от любого месяца
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 23:12 , 23-Апр-24 (5) +10 [^]
> доля Microsoft IIS снизилась с 5.6% до 4.8%.Удивительно, что он вообще в интернете используется. Да и в интранете
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , нах., 00:20 , 24-Апр-24 (12) –5 [V]
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 01:08 , 24-Апр-24 (17) +6 [^]
> тут вам уже пытались разжевыватьНо в итоге, никто, кроме любителей IIS, сладкий хлеб есть не стал. Даже предварительно разжёванный.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 15:33 , 24-Апр-24 (56)
> Но в итоге, никто, кроме любителей IIS, сладкий хлеб есть не стал.
> Даже предварительно разжёванный.Но пытались то как. Годядика аж ублажали во все мыслимые. Но не, даже так не прокатило. Со временем народ просек что паркинг с пачкой фэйк-хостов еще не вебсайт и вынес это в отдельную номинацию :)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , penetrator, 01:31 , 24-Апр-24 (18) +2
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , glad_valakas, 05:38 , 24-Апр-24 (23)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 15:26 , 24-Апр-24 (53)
> потому что веб-морда Exchange. и SharePoint. и чего-то еще.Пиратские?
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 15:34 , 24-Апр-24 (57)
> потому что веб-морда Exchange. и SharePoint. и чего-то еще.При том процент этого всего относительно вон того - ну вы сами поняли, ага :). Где-то там ниже плинтуса, горстка неудачников будет с этим отношаться, прикованные к стойке. Но остальным на это все будет решительно похрен.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , нах., 09:13 , 24-Апр-24 (36) –1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , noc101, 02:56 , 26-Апр-24 (77)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 03:17 , 24-Апр-24 (21) +1
А что в этом удивительного?IIS - это единственный веб-сервер, который пригоден для высоконагруженных приложений, работающих на железе без виртуализации. IIS поддерживает современные многопроцессорные сервера и синтетические ускорения предоставляемые в современных сетевых адаптерах.
- Обработка TLS у него в ядре и всегда была в ядре. Есть сетевые адаптеры, которые могут сделать offload и убрать криптогорафию с центральных процессоров.
- Обработка HTTP у него в ядре, причем с версии 6 (2003/XP).
- Встроенная поддержка HTTP/2 начиная с версии 10 (2016)
- Встроенная поддержка HTTP/3 в последней стабильной версии (2022) В отличии от привычных вам веб-серверов IIS - это полноценная реализация UNIX Internet Daemon. Только в отличии от привычных для Linux реализаций, его супер-сервер работает в ядре ОС и большая часть привычных обработчиков обрабатывается там же. То есть вместо того чтобы пихать поддержку транспорта QUIC в OpenSSL, потому что толком некуда из-за требований к TLS 1.3 для HTTP/3, она в ядре и связана с сетевым стеком. Кроме того он интегрирован с сервисной моделью и не дёргает процесс с диска на каждый запрос, а перенаправляет их либо в свой воркер (экземпляр службы публикации), либо в другую службу по TCP (но это значит что это служба использует WCF). Вот представьте себе ситуацию:
У вас есть двухпроцессорный сервер с двумя сетевыми адаптерами, каждый из которых подключен по PCI Express к своему процессору. Далее настроен бондинг так, чтобы количество аппаратных Rx-очередей каждого адаптера у вас "суммировалось". Например, скажем ASIC сетевого адаптера поддерживает 16 аппаратных очередей, значит он может слать одновременно на 16 разных ядер разделив входязий поток. Бондинг должен быть настроен так, чтобы оба адаптера задействовали по 16 ядер с каждого процессора. Далее с учётом требований по скорости обработки у вас либо есть LRO/LSO (жонглирование с MTU, когда адаптер принимает TCP и QUIC пакеты с MTU 1500, а отправляет на CPU в ядро с MTU 64K, меняя MSS в рамках одного потока и потом производит обратную операцию при отправке), тогда у вас выше пропускная способность сети, меньше переключаются контексты исполнения, либо это выключено, тогда у вас ниже задержки в потоке, но нагрузка на CPU выше.
После того как TCP и QUIC в ядре ОС у вас это приняли это передаётся в модули ядра TLS и HTTP, которые дальше производят балансировку нагрузки по рабочим процессам в пространстве пользователя с учетом того, какие воркере на какой NUMA-ноде запущены и откуда шел трафик изначально. Естественно при таком сложном тюнинге производительности мы предполагаем, что у вас есть 4 уровня балансировки и правильно настроена сеть:
1. DNS Round Robin между регионами/локациями указывают на L4-баласнировщики/файрволы
2. L4-баласнировщики в режиме Direct Return указывают на фермы L7-балансировщиков
3. У вас настроена балансировка потоков трафика по ECMP и для внутреннего роустинга применятся BGP
4. L7-балансировщиков... ну это просто ваша HAproxy или сабж из новости, но тогда у вас однопроцессорный сервер.
И вот потом у вас IIS-ы. Просто когда nginx научится нормально работать на современных многопроцессорных серверах... хотя опять же зачем ему...
Ну то есть он же не apache с его модулями и пайплайнами для приложений. То есть в общем случае nginx это мордочка, которая стоит перед FastCGI, либо это реверс-прокси (см п.4). Для первого он подходит (обслуживание PHP и Python через FastCGI), опять же, если у вас виртуалка, или однопроцессорный сервер. Для реверс-прокси он всегда уступает HAproxy.
Или когда nginx научится работать с чем-то кроме FastCGI и научится быть сервером приложений как IIS, хотя это вынесли/задумали в nginx Unit, но и он с железом работает от слова "никак". И да у IIS есть традиционные Legacy-применения, типа перепубликовать WCF-службу как вебсервис, всякие старый софт, которым нужен .NET Framework, а не современный .NET. Или если есть интранетное приложение, которое оформлено как ISAPI-плагин на C/C++, а не как CGI. В остальном, если кому-то нужен IIS, то это значит, что кто-то хочет работать на железе с высокой производительностью и отказывается дарить инфраструктуре виртуализации 10-25% производительности, просто чтобы исправить отсутствие поддержки NUMA в софте. Он в принципе всем хорош, но у него есть 2 проблемы:
1. CI/CD приложений... всё это можно, но придётся поморочиться, особенно когда оно кластерное.
2. Цена, он получается очень дорогой. Просто смотрите, тем кто пишет микросервисы производительность приложений не нужна. Им нужна масштабируемость. Им нужно арендовать 100500 виртуалок в облаке, поставить в эти виртуалки кубернетис, туда понапихать свои микросервисы и пользоваться этим так, чтобы кубик попинывал их барахло, когда сервисы падают. Хотя и тут тоже не понятно зачем nginx...
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 04:13 , 24-Апр-24 (22) +2
> У вас есть двухпроцессорный сервер с двумя сетевыми адаптерами, каждый из которых подключен по ... выше.И всё это даёт снижение задержек аж на 0.001% на фоне общего времени ответа приложения.
Круто, да. > Просто смотрите, тем кто пишет микросервисы производительность приложений не нужна. Им нужна масштабируемость. Им нужно арендовать 100500 виртуалок в облаке, поставить в эти виртуалки кубернетис, туда понапихать свои микросервисы и пользоваться этим так, чтобы кубик попинывал их барахло, когда сервисы падают. Именно так серьёзный продакшон и работает. Потому что в системе из 200 сервисов, написанных 60 разными командами, никто не будет наяривать на снижение задержек на пару наносекунд.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , нах., 09:15 , 24-Апр-24 (37) –1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 13:11 , 24-Апр-24 (47) +1
> И всё это даёт снижение задержек аж на 0.001% на фоне общего времени ответа приложения.70%-130% задержек для IO: https://shbakram.github.io/assets/papers/akram-caos12.pdf И всё потому что вы, как и многие не понимают проблематику гетерогенных компьютеров (несимметричные ядра в одном CPU) и современных многопроцессорных систем (ccNUMA).
https://www.cse.wustl.edu/~angelee/cse539/papers/numa.pdf Поймите, сама концепция Shared Memory традиционная для UNIX из 70-х умерла вместе с последним Pentium 4. А вместе с ней померли традиционные SMP-системы (симметричная многопроцессорность). У вас больше нет северного моста к которому подключается RAM, все процессоры и высокоскоростные сопроцессорные шины. Сейчас уже не 2007-й. Теперь каждый процессор имеет свой набор периферийных устройств, свой набор RAM и представляет собой NUMA-узел. Узлы связаны интерконнект-шиной, которая нужна только для соблюдения когерентности кэша. Кэш третьего уровня при этом используется как буфер с каждой стороны для межпроцессорной передачи данных. Нету никакой "быстрой" общей памяти, который процессы могут использовать через системные вызовы fork или clone. Если данные шли по сети или из стораджа на процессор CPU1, а дочерний процесс находится на CPU2, то весь этот набор данных не просто займет интерконнект-шину, но еще и создаст паразитную нагрузку на CPU1.
И не забудьте что у вас там с контекстами исполнения! Receive Datapath - это вообще-то I/O, которое обрабатывается драйверами в привилегированном режиме. NIC и HBA делают прерывание для приёма. Ваш юзерспейс на CPU1 и на CPU2 должен будет уступить процессорное время для этой передачи. Вы понимаете серьёзность того что я говорю? OpenMP знаете что такое (модель fork-join)? Ну так вот забудьте про это. Они там вроде обновили спецификацию, но мне еще предстоить увидеть OpenMP софт для Linuxб который нативно поддерживает NUMA API на стороне приложения. > Круто, да. Вы действительно не увидите разницу в производительности, если используете продукты вроде nginx или postgresql. Причем наоборот, возможны конфигурации, когда виртуалка с postgresql будет быстрее чем физический сервер. Но это проблема самих программ, которые не умеют оптимально работать на архитектуре ccNUMA (Xeon Scalable, AMD Epyc). Все продукты, кто используют shared memory лучше виртуализовать, а все кто представляет архитектуру аналогичную initd, умеют опрашивать аппаратную топологию, спавнить рабочие процессы и рулить передачей данных и кэшем в NUMA-системе лучше ставить на физику. Вот за этим и нужен IIS. > Потому что в системе из 200 сервисов, написанных 60 разными командами, никто не будет наяривать на снижение задержек на пару наносекунд. Когда люди применяют микросервисную архитектуру они по умолчанию готовы снижать производительность в десятки раз подарив её сетевым задержкам, медленным объектым хранилищам и готовы куски кода уложить в облако. Работа в стиле: нам нужно формировать квартальный отчет, давайте арендуем мощности в клауде высчитаем его там и потом вернем мощности обратно. Не все фирмы так делают. А вообще когда мы говорим про сторадж, то там задержка в пару миллисекунд может выливаться в 100 кратное снижение производительности всего приложения. Вам нужна симметрия и выравнивание устройств по NUMA и затем вам нужна поддержка NUMA в ваших приложениях:
https://cdrdv2-public.intel.com/782330/782330_Performance_Im...
Но в мире Linux люди либо не образованы, либо бредовые фанатики... Я же помню в конце нулевых пылкие презентации академических линуксоидов, рассказывающих на конференциях "NUMA не взлетит", "NUMA слишком сложна", "NUMA не нужна". И вот в 2024-ом году у нас все процессоры построены на NUMA причем то что у вас он 1 ничего не гарантирует: https://lenovopress.lenovo.com/lp1499.pdf Сейчас в общем случае у вас есть 4 DRAM контроллера на сокете, но не все процессорные ядра могут получить к ним доступ с одинаковой скоростью. С одной стороны у вас есть ядра которые далеко от конкретного контроллера, с другой стороны у вас есть ядра, которые вообще не могут собирать данные из RAM и должны быть сгруппированы в кластер с тем ядром котороt может. Особенно хорошо будет это видно на всяких 128-ядерных AMD EPYC, в которых реальных ядер от силы 16 в зависимости от модели, а остальные - всего навсего потоки исполнения. Раньше для этого использовали SMT/HyperThreading, но эта технология проклята, спекулятивное выполнение слишком опасно для ряда задач повышает производительность до +25%, а для других снижает на -15%. В условиях когда в пятом поколении у вас clock разный на разных ядрах у вас по умолчанию процессор хочет работать в режиме Sub-NUMA Clustering, когда один SoC предствляется двумя или четырьмя узлами NUMA в системе. А вся разница между кластерными режимами в принципах маппинга кэша к RAM. И не забывайте про PCI Express и MMIO. Периферийные устройства на таком процессоре цепляются к "производительным" ядрам и мапятся в их областях памяти для организации receive datapath. Остальные узлы NUMA не имеют прямого доступа, если включен SNC, только через L3-кэш. Всё это нужно знать если вы работаете с:
- HPC
- СУБД
- строите инфраструктуру виртуализации
Если же вы "пользователь" кубернетиса, то вам это знать не надо. Дядя инженер, который настраивал вам облако своё или покупное делает это вместо вас. Проблема в том, что ОС Windows и её IIS в частности всё это умеет из коробки прямо на бареметале, а с Linux всё как всегда:
- ядро всё умеет, ну почти всё... то есть сторадж там фиговый, и сеть тонна легаси, когда все типы синтетических ускорений ввендорских драйверах, которыми нужно рулить через DPDK, но ccNUMA оно умеет и отдаёт в юзерспейс правильно.
- в юзерспейсе есть исторически не адлаптированный софт, которые не умеет с этим работать
- базилион дистрибутивов, которые отказываются внедрять базовую поддержку в юзерспейс и пользоваться этим.
То есть если вы не энтерпрайз, а какой-нибудь амазон или гугл, то вы можете собрать собственный дистрибутив под правильное железо и построить поверх него своё облако и свою инфраструктуру. Если вы обычный энтерпрайз и вам нужны физические сервера у вас Microsoft и его продукты, они работают. Если вы используете Linux в ентерпрайзе средней руки, вам нужно поставить Hyper-V или ESXi и виртуализировать в нем всё так, чтобы в каждой виртуалке был только один узел NUMA и тогда можно работать. Или вы думаете что пресловутые контейнерные среды вроде Kubernetes способны заниматься планированием ресурсов контейнеров по NUMA на бареметале? Спойлер: нет. Их оттого и ставят внутрь виртуалок.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Всем Анонимам Аноним, 14:23 , 24-Апр-24 (50)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 17:36 , 24-Апр-24 (63) +2
> Как вы сами и написали, кому нужны микросекунды, то все патчи уже есть в ядре линукс и все можно настроить.Я сказал следующее:
1. Чтобы "настроить", там создают свои корпоративные дистрибутивы, переписывают юзерспейс и тюнят под сетевую нагрузку. Такой объем сопровождения могут себе позволить единицы. В дистрибутивах Linux это всё не доступно, потому что если функция доступна в ядре совсем не значит, что дистрибутив это внедрил. Торвальдс же периодически скандалит на эту тему.
2. В подавляющем большинстве Linux софта, таком как nginx/apache/PostgreSQL и прочее нет поддержки NUMA от слова "СОВСЕМ". Нужно переписать этот софт, чтобы добавить поддержку. То что в ядре можно настроить еще не значит, что ваш сервер приложений и БД смогут этим пользоваться. Наоборот, чтобы пользоваться nginx и postgres нужно отключить NUMA везде и заставить физический сервер прикидываться, что её нет и получать потом рандомные задержки при обработке запросов. ИЛИ просто ставить это на виртуалки и потерять ~20 процентов производительности. Для серверов БД эта цифра может быть ещё выше.
3. Среди админов Linux встречаются невыносимые необразованные фанатики, которые не понимают ни как работает компьютер, ни как работает их ОС, ни как работает их софт. Фантазёры, админящие свой домашний комп и максимум 5-10 серверов в ООО Рога и Копыта. Я специально для таких и описываю, что и зачем бывает нужно
4. IIS - это сейчас единственный сервер приложений и веб-сервер, поддерживающий работу высоконагруженных приложений на bare metal.
5. Правильно настроенная инфраструктура виртуализации способна скрыть от приложения тот факт, что в системе несколько процессоров и оптимизировать нагрузку и возникающие задержки в обработке запросов из-за того что софт не поддерживает современные CPU и сервера.
6. Те, кому нужна высокая производительность и высокий КПД, применили тонну других оптимизаций, которые никогда не покажут, что вычислениями на бекенде занимается IIS. Малому бизнесу и nginx с posgtre в виртуалке хватит. Добавить я также к сказанному ранее хочу еще вот что:
1. Поддержка TLS есть в ядре Linux и FreeBSD. nginx способен с ней работать. В сочетании с ASIC-ами Chelsio можно вынести нагрузку на сетевки. Это очень часть применяется при создании балансировщиков нагрузки и файрволов. Ввиду других технических особенностей stateful-файрволов и роутеров BGP они всегда должны иметь один узел NUMA, поэтому на такой харварный балансировщик NGFW или как сейчас модно назвать такие тачки, можно и nginx поставить. Просто если это всё не нужно, тогда зачем так стремятся этого добиться.
2. IIS закрыл все свои направления по фронтенд-балансировщикам, хотя CDN в Azure до сих пор работает на модифицированном IIS ARR. Ну то есть решения по CDN на IIS тоже возможны. IIS ARR умеел строить сложный геораспределенный иерархичный кэш. Хотя по опыту использования IIS именно для этой задачи я порекомендую HAproxy+Varnish. Про остальную ахинею, кто кому звонить будет и про финансовые проценты вообще обсуждать лень. Это всё разговоры в пользу бедных. Реальность в том, что I/O при неверной работе с NUMA падает в разы и это касается как сети, так и стораджа. То есть и веб-серверов и серверов БД. И это факты приведенные в исследовательской статье выше. А еще документацию к своим любимым продуктам почитайте в разрезе поддержки NUMA.
Если человек поставил PostgreSQL, nginx и еще тонну Linux-софта на физический двухсокетник, то этот человек необразованный олух. А если он потом просит еще один сервер ему купить, то его реально проще уволить.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 19:09 , 24-Апр-24 (64)
Хорошо, если хотят выжать всё - на железо ставят. Если попроще - вируталки. А как решается проблема если надо таскать сервис по разным машинам? Железо отказало, второй такой же сервер надо развернуть для балансировки, утащить сервер в другой цод и тому подобное. Как решают с системами что ставят на само железо?
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 00:15 , 25-Апр-24 (66)
Тут, скорее было бы уместно поинтересоваться, как горизонтально масштабировать такие системы. Допустим, за десять минут нагрузка удваивается, и существующие серваки перестают вывозить.Но с нейрогенерированным рекламным бредом (там есть здравые мысли, но разбросаны так неуместно, что явно видно отсутствие понимания смысла) разговаривать — неблагодарное дело.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 08:22 , 25-Апр-24 (72) +1
Мне пока интересовал вопрос по денежным и временным ресурсам. Технически как сделать это второй вопрос. А горизонтально что можно услышать. Да какой-нибудь балансировщик с лимитом на число сессий или загруженности серверов.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 03:18 , 25-Апр-24 (70)
Весь ваш комментарий наводит на мысль, что вы не админили физические сервера...Если физические сервер сломался - это равнозначно тому что сломался сервер виртуализации. Вам нужно устранить поломку и восстановиться из бекапа. Молодые люди, почему-то сейчас не понимают, что бекапы снапшотами - это не фича инфраструктуры виртуализации. Это просто снапшоты ФС. NTFS прекрасно поддеживает снапшоты и всю систему можно восстановить из резервной копии. Однако, есть нюанс. Для полностью автоматического восстановления вам нужно:
1. Иметь выделенную сеть/VLAN для управления
2. Настроить DHCP и PXE
3. Ваша инфраструктура бэкапа должна дать вам загрузочный образ, который загрузит его родную LiveOS, подключится к репозиторию бэкапов и восстановит снапшот. Если у вас был один сервер, а нужно сделать 2, то вы просто берете и ставите второй сервер. Балансировщики нагрузки ставятся всегда отдельно от бэкенд-серверов. Там нет разницы на виртуалки они балансируют или на физические сервера. Сами балансировщики тоже могут быть как виртуальные так и физические аплаянсы. В зависимости от типа сервиса вам может потребоваться:
1. Ничего. Для стейтлесс-сервисов ничего не нужно
2. Сессионная привязка к бэкенду. Для сервисов у которых есть понятия постоянной сессии, когда одно клиентское соединение шлёт зависимые друг от друга последовательные запросы. Если вам нужно мигрировать сервис с одного сервера на другой, то это часть CI/CD пайплайна. Вы должны были написать скрипты обновления и деплоя своего сервиса. Если ваш сервис настолько стейтфул что работает напрямую с хранилищем, например файлами на дисках, вам нужна кластеризация. Кластерное хранилище может быть либо средствами SAN/FC, либо програмно определяемое на этом же кластере, составленное из локальных дисков. Если вам нужно унести сервер в другой ДЦ, вам видней как это лучше организовать. Я только хочу сказать, что даже в случае требований наличия кластерного стораджа, вы можете сделать растянутый кластер, применяющий логическую репликацию нужных сервису данных из одного ДЦ в другой ДЦ. Это всё стандартные функции. То есть если у вас есть:
- PXE и у вас настроена шаблонизация и установка образов ОС на физику
- Вы покупаете +/- однотипное серверное оборудование (в больших развертываниях всегда так)
Вы вообще не увидите разницы в вопросах сопровождения. Ну разве что во времени. Клонировать шаблон виртуалки на соседний сервер быстрее, чем накатить этот шаблон на физический сервер по сети. Вообще виртуализация - это технология уплотнения серверов, не более того. Вот есть у вас стойка, а вам нужно поставить сервер в котором 1 процессор 4 ядра, 32 ГБ RAM и до 500 ГБ места на диске. Это целый юнит. А тем временем этот сервер всё равно будет жрать электричество и занимать порты коммутатора.
Хостинг провайдеры, а теперь и облака давно промывают молодёжи мозги, будто виртуализация это круто. Нет.
Виртуализация позволяет им продать VDS на ушатанном хосте, на котором оверкоммит по процессору 10. То же самое с микросервисами и облаками. Всё что я писал выше я писал про веб-приложения. С БД всё гораздо мрачнее. В общем случае реляционные СУБД не должны ставиться на виртуальную машину никогда, кроме тех случаев, когда глупый сервер БД не поддерживает работу на физических серверах. Не буду вам писать про кластеризацию СУБД, логическую и бинарную репликацию и балансировку через read-only routing. А то это как-то мимо темы.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 08:32 , 25-Апр-24 (73)
> Если у вас был один сервер, а нужно сделать 2, то вы просто берете и ставите второй сервер.
> Вы вообще не увидите разницы в вопросах сопровождения. Ну разве что во времени. Клонировать шаблон виртуалки на соседний сервер быстрее, чем накатить этот шаблон на физический сервер по сети.То есть как и думалось - чудес не бывает. При виртуализации средне-потолочного сервиса надо на 20% больше ресурсов. При железном решении - на 100% больше. Время простоя с Fault to Tolerance каким-нибудь в первом случае гораздо меньше.
Осталось список ПО где-то собрать что лучше запускать на физике. аля 1с, постгре и прочее и будет хорошо.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 12:47 , 25-Апр-24 (75)
Переход с виртуальной машины на физический сервер - это естественная часть вертикального масштабирования. Горизонтальное зависит от сервиса, не о нем сейчас речь.Мы начинаем с виртуальной машины в несколько ядер и несколько гигабайт RAM и смотрим на производительность и добавляем ресурсы, если их мало.
Проблема втом что в один прекрасный момент вам докидывание не поможет. Требование перехода к физике возникает на сервисе, на котором мониторинг показывает удивительные вещи:
1. Внутренний мониторинг сервиса по производительности, например время ответа на запрос, ниже желаемого (SLA вы определяете сами).
2. Утилизация CPU не доходит до 100%
3. Переключение контекстов исполнения для виртуального процессора выше чем 14000 переключений в секунду на ядро.
4. Параметры uptime/load average на сервере виртуализации в этот момент нормальные, то есть соседние виртуалки вам не отобрали ресурсы.
Сочетание этих трёх пунктов - верный признак того, что пора ставить физический сервер. Любая попытка выдать больше ресурсов (ядер и RAM) не приведет к росту показателя 1, а лишь снизит утилизацию в показателе 2. В этой ситуации вы имеете дело с паразитной нагрузкой от виртуализации.
Опять же мы считаем по п.4 что это не проблема перегрузки самого сервера виртуализации. Нужно запустить отладчик в ОС и посмотреть, а что отжимает себе процессорное время. Если это сетевой стек ядра, то у вас еще сть шанс решить проблему при помощи SR-IOV, если ваша инфраструктура виртуализации к этом готова и есть поддержка на железе, и это разрешено исходя из безопасности. Самая частая проблема такого потолка производительности это receive datapath для сети:
1. Данные пришли на физический адаптер узла виртуализации
2. Данные попали на некую шину в ядре ОС для последующей передачи на виртуальный адаптер
3. Виртуальный адаптер выполняющийся на одних ядрах тоже имеет свой receive datapath в сетевой стек гостевой ОС
4. Виртуальный драйверы принимающие потоки могут находиться на других ядрах.
Из-за множественной пересылки, если все пункты на разных ядрах у вас возникнут задержки, а каждая операция приёма данных по сети имеет высокий приоритет и прерывает выполнения задач пространства пользователя в пользу операции приёма данных.
SR-IOV позволит вам пробросить виртуальные функции (SR-IOV VF) вашего физического сетевого адаптера напрямую в виртуалку, тогда это работает так:
1. Данные пришли на физический адаптер узла виртуализации
2. Виртуальные драйверы принимают поток напрямую с сетевки, проброшенной в виртуалку причем на тех же ядрах/vCPU, которые ждут данные, потому что у вас доступно использование Receive Side Scaling в этом случае.
Опять же, SR-IOV убирает изоляцию, ваша виртуалка смотрит тогда на ваш физический коммутатор, будто она в него включена веревкой. Однако это наряду с увеличением "приоритета" виртуалки - ваш последний шанс. Если и это не помогает вы меняете виртуалку на физику. И да, как вы правильно заметили есть сервисы, которые лучше не ставить на виртуалки никогда, если можно сделать физические сервера:
1. Серверы работающие в реальном времени
RTC и телефония - это самое чувствительное. Для качества связи вы должны не просто не иметь потерь, а выдавать потоки с консистентыми предсказуемыми задержками, избегая джиттера. Для работы этих серверов требуется тюнинг драйверов сетевых адаптерв, чтобы выдать качественный поток. 2. Сервера БД
Сервера SQL всегда требуют тюнинг параметров процессора. SQL-запросы работают так, что они никогда не работают со своими данными сразу. При выполнении запроса вы сначала вычисляете сам запрос, потом работаете с индексами данных и только потом с самими данными. Из-за этого всё интеллектуальное кэширование на L1/L2 кэше бесполезно. Там всегда cache miss, его нужно оключать, чтобы сама процедура интеллектуального кэширования не занимала процессорное время. Плюс в зависимости от развертывания там может быть заморочка со стораджем. 3. Сервера приложений, которые зависят от скорости хранилища и сети. Их тысячи, но самый известный в СНГ пример - это 1С. Если у вас тупит сторадж на SQL-сервере, то у вас начнется каскадная деградация всех сервисов-приложений. Причем, сам сервер приложения начнёт отъедать ресурсы RAM и CPU и на нем начнутся проблемы. Проблема здесь как раз про виртуализацию сторадж-подсистемы и сети. Виртуализация создаёт не просто дополнительную нагрузку. Она по цепочке всё замедляет. 4. Сессионные терминальные серверы
Это почему-то мало кому очевидно, но сессионный терминальный сервер это вообще-то реалтаймовый сервер по кодированию видео и аудио, на котором кроме всего прочего запущены приложения. То есть это гарантировано подпадает под п.1 и зачастую на него публикуют клиентские части от приложений п.3.
Если вам нужно виртуализировать пользовательские сессии примените Virtual Desktop и выдайте пользователям клиентские виртуалки. Если у вас сессионный терминал, на котором вы публикуете приложения, сделайте его физическим.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 09:08 , 26-Апр-24 (78)
Спасибо.
Как всегда упирается всё в убеждении людей. Что надо дать денег на физику во много гографически распределённых точек. А потом сидеть тюнить весь этот стек.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 13:58 , 24-Апр-24 (49)
Крутой текст, спасибо. У нас IIS в качестве сервера приложений за балансировщиком, так что сканеры в статистике увидят балансировщик. Выбор IIS больше обусловлен legacy причинами.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 12:09 , 25-Апр-24 (74)
> Крутой текст, спасибо.
> У нас IIS в качестве сервера приложений за балансировщиком, Все что надо знать о IIS и его крутой нагрузочной способности. Спасибо :).
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 16:45 , 24-Апр-24 (60) +1
> Удивительно, что он вообще в интернете используется. Да и в интранете Ничего удивительного, очень много легаси сервисов крутится ещё на IIS. Как правило всегда это что то с Пролом связанное, но команда которая разрабатывала уже давно в полном составе уволилпсь, а люди которые пришли им на замену боятся это трогать.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , tcpip, 23:26 , 23-Апр-24 (10) +1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Алексей, 23:53 , 23-Апр-24 (11) +2
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Skullnet, 02:55 , 24-Апр-24 (20) +1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , glkoo, 08:34 , 24-Апр-24 (31) +1
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 08:58 , 24-Апр-24 (33) +1
а куда там спасибо говорить? может лучше заказным письмом отправить?
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , myster, 12:33 , 24-Апр-24 (46)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Фняк, 01:00 , 25-Апр-24 (67)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Skullnet, 01:14 , 27-Апр-24 (80)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 18:25 , 27-Апр-24 (81)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 08:57 , 24-Апр-24 (32)
Ютуб через http/3 в основном. Когда у гулага плохой день, переключается на http/2 и лагает.
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Ононимуз, 11:08 , 24-Апр-24 (44)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Zulu, 00:00 , 27-Апр-24 (79)
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 09:53 , 24-Апр-24 (41) –1 [V]
- Выпуск nginx 1.26.0 с поддержкой HTTP/3 , Аноним, 17:02 , 24-Апр-24 (62) –1
>Стабильный выпуск проекта FreeNginx 1.26.0, развивающего форк Nginx, был опубликован две недели назад. Разработку форка ведёт Максим ДунинА чо он опубликовал свой форк под разрешительной лицензией - БЗД кляуз 2. >FreeNginx позиционируется как некоммерческий проект, обеспечивающий разработку кодовой базы Nginx без корпоративного вмешательства. Чтобы обеспечить кодовую базу от коропорастов надо опубликовывать сырцы под копилефтной лицензией. А тут классическая пермиссивщина.
|
Версия для распечатки
Выпуск nginx 1.26.0 с поддержкой HTTP/3 ,
opennews, 23-Апр-24, 22:51 [смотреть все]
