Nginx на стероидах — расширяем функционал с помощью LUA

Окей, вопрос про блокировки тут наверное и не приоритетный. Два остальные вопроса не решены совсем )
Навскидку, если даже брать только resize, в данном конкретном случае у меня получается 25-30 локаций и довольно сложно что-то сделать, если с файлом что-то не так или его нет. На lua у нас возможности шире и легко дописать именно то, что необходимо. Бизнес штука такая, необходимость у них часто резкая и часто мечется в разных плоскостях )))

Nginx на стероидах — расширяем функционал с помощью LUA

Главная причина — resize не единственное, что было заложено в требованиях к сервису, imagemagick все же надо было оставить.
Также, файл нам надо надо сначала достать из хранилища и это на пару с самой пережимкой все блокирует nginx-овский воркер. Плюс сам модуль весьма прожорлив под нагрузкой.

Nginx на стероидах — расширяем функционал с помощью LUA

Если все прикрыто кэшами, везде включен keepalive, то работает очень быстро. И что самое главное, не надо по каждому чиху поднимать и заставлять работать медленный комбайн, как в случае если все сделано на php.

Nginx на стероидах — расширяем функционал с помощью LUA

В самом модуле, который ходит в базу, мы тоже можем определить все что угодно для любого события.

Nginx на стероидах — расширяем функционал с помощью LUA

Вызов сабреквеста по факту в итоге возвратит нам какой-либо статус. Что с ним потом делать, решать тоже нам. Например,

content_by_lua '
                local res = ngx.location.capture("/some_other_location")
                if res.status == 503 then
                ngx.exit(ngx.HTTP_INTERNAL_SERVER_ERROR)
                end';

Если логично будет отдать 503, можно отдавать )) Если нужно что-то еще, не проблема тоже.

Nginx на стероидах — расширяем функционал с помощью LUA

Postgresql в основном. Он просто не успевает )) Искусственно ограничили количество одновременных запросов в локацию, где дергается база данных и воткнули пулеры, например pgpool2. Для redis и memcache тоже есть пулер, twemproxy. Если мощностей не хватает, добавляем еще бекендов с базой, оно все умеет балансироваться.

«Идеальный» www кластер. Часть 1. Frontend: NGINX + Keepalived (vrrp) на CentOS

LVS (ipvs) решает все проблемы напрочь, плюс там в обвязках (pyball, например) много интересного функционала. Keepalived выглядит каким-то прошлым веком.

Centrifuge — так просто, как возможно, но не проще этого

Ну. Вместо центрифуги будет другая PUB_SUB штука. Не очень понял вопрос.

Centrifuge — так просто, как возможно, но не проще этого

Почти доделал такую штуку прямо на nginx+lua ))

Пишем сервер, который не падает под нагрузкой

Из коробки не очень получается.
Проблема в том, что для балансировки нам нужно точно знать состояние бекендов. Мы сейчас у себя исследуем такую штуку. Правда там похапэ, это несколько сложнее, чем нода )) Авторизация у нас по ключам.

1. Сделано. Используем openresty. В LUA вынесли все коды ошибок и сделали firewall. Запрос прежде всего должен пробиться через lua, где ему скажут, можно ли вообще идти дальше. Если можно, то с какими лимитами и на какой бекенд.
2. Еще не сделано. По приложениям ползает паук, который проводит самодиагностику и оценку производительности бекенда со всеми его связями и зависимостями — по факту и в прогнозе на минуту вперед. Теоритически выставляет некое количество баллов для бекенда. Самый быстрый и незанятый получает, скажем 100 баллов. Если есть затупы, баллов будет меньше. Информация складывается опять в LUA, через, скажем redis. Тут все работает напрямую, очень быстро.
3. Еще не сделано. Есть еще несколько гипервизоров, которым можно сказать поднять дополнительные мощности — виртуалки с бекендами.
Если мы везде тупим, то пора поднимать еще виртуалку в большом геокластере.

На выходе получаем nginx-as-web-application, который точно знает, куда и как ему зарутить запрос.
Тема вообще интересная, рекомендую ))

dCache — xранилище, где живёт ХИГГС

Совсем экзотика )) Можно в GRID к ученым подключиться, например. В остальном выглядит не очень удобно. Как большая библиотека, где надо в бахиллах шепотом разговаривать, а под землей миллиарды книг ))

Подозреваю, что файлы сюда надо складывать медленно и сравнительно нечасто, постгрес умрет без надлежащего вакуума очень быстро.

>> В связи с натурой экспериментальных данных dCache не предусматривает изменение хранимых файлов.
Удалить и записать заново?

В сети не нашел ни бенчей, ни сравнений.

Пишем сервер, который не падает под нагрузкой

По мне, так было бы лучше сразу не пятисотить. Лучше что-нибудь такое, что честно мониторит бекенды, а если они заняты — просто переселяет пользователя в медленный пул, честно его предупредив перед этим. А тем временем поднять еще бекендов в автоматическом или полуавтоматическом режимах. Например, с помощью модулей openresty легко можно так сделать на lua. Сразу же активировать несколько ступеней защиты.
В общем как-то это все неправильно — кидать пачку пятисотых, если мы сильно заняты, и больше ничего не делать.

Мигрируем на Chef Server 11

И это тоже. Еще у них была очень большая проблема с поиском.
Вот история, как его ускорили в 16 раз.

Так ли необходимо высшее образование системному администратору?

По идее, с этим не шутят. Означают, что вы здоровы, подготовлены, осознаете и научены водить от_около_тонны_и_выше механизм, который легко убивает и кромсает. Что сейчас творится, я воспринимать отказываюсь, и могу вам ответить, что в большинстве случаев — подтверждение ничего.

Так ли необходимо высшее образование системному администратору?

Гуманитарное, работаю, вроде не жалуются ))

Мигрируем на Chef Server 11

Стало «более лучше». Но есть и неприятные баги, например
— environments сбиваются
— статус нод не весь
— авторег не очень работает без приседаний
— не очень люблю приложения с embedded, хочу настроить все сам. Тем более внутри всего, что они туда понапихали без бутылки не разберешься. Отладить и исправить багу стало сложнее в разы ))

Но мы особо и не ковырялись, развернули один раз, нестыковки и проблемы поправили, баги зарепортили и оно да, лучше стало и быстрее.

Масштабируемый отказоустойчивый файловый сервис на базе CTDB, GlusterFS

«SElinux я отключаю...» Есть вообще кто-нибудь, кто пользуется этой хреновиной ))

Не очень понял, зачем использовать CTDB и какие задачи он решает. Если балансировка и отказоустойчивость, то можно просто обойтись LVS+Pyball (например).

Мифы про облака

Ошибок полно, хотел написать в личку, но почти в каждом предложении ошибки.

Автоматизируем мониторинг: низкоуровневое обнаружение

Оно умеет, если использовать ZabbixAPI.

map.createSelements, map.updateSelements, map.deleteSelements

Масштабируя Zabbix

Есть несколько путей, да. Но то, что это все жесткие костыли — это факт )) Думаю вообще код хакнуть, там несложно вроде впилить сжатие ))

Только не могу найти в интернетиках, чем чревато и кто так уже делал.