Серверная оптимизация *

Ansible – это мощный и простой инструмент автоматизации с открытым кодом. Он помогает оптимизировать множество задач по эксплуатации ИТ-инфраструктуры, от самых простых, наподобие установки программных пакетов, до весьма сложных, вроде развертывания кластера с несколькими узлами или многоэтапного обновления операционной системы. Сегодня мы расскажем, как оптимизировать плейбуки и модули Ansible, чтобы создаваемые вами автоматизации работали быстрее.

Прим. Wunder Fund: наш СТО Эмиль по совместительству является известным white-hat хакером и специалистом по информационной безопасности, и эту статью он предложил как хорошее знакомство с фаззером afl и вообще с фаззингом как таковым.

Этот материал открывает серию из трёх статей (она продолжает материалы о фаззинге FTP-серверов и FreeRDP), посвящённых фаззинг-тестированию реализации протокола HTTP, представленной в Apache HTTP Server. Это — один из самых популярных веб-серверов и в представлении он не нуждается. Так, Apache HTTP — это один из первых HTTP-серверов, разработка которого началась в 1995 году. По состоянию на январь 2021 года под его управлением работали более чем 300000000 серверов, а значит — он использовался на 26% таких систем и занимал второе место по распространённости, немного уступая лишь Nginx (31%).

В этой статье я вкратце расскажу о том, как работает Apache, и освещу кое-какие идеи, которые помогут всем желающим лучше понять суть кастомных мутаторов, и то, как можно эффективно их применять для исследования реализаций протокола HTTP.

OpenShift широко используется в мире в качестве платформы для критически важных корпоративных приложений. От таких приложений ждут, что они будут работать в режиме высокой доступности, выдавая типичные для отрасли «пять девяток» и обеспечивая непрерывное обслуживание конечных пользователей и клиентов. OpenShift предлагает целый ряд технологий развертывания в режиме высокой доступности, помогающих не допускать простоя приложения, даже когда его экземпляры или нижележащая ИТ-инфраструктура деградируют или перезапускаются. Сегодня мы рассмотрим девять лучших практик обеспечения высокой доступности приложений на платформе OpenShift.

Несмотря на ударные темпы распространения платформ оркестрации контейнеров, вроде Kubernetes или Red Hat OpenShift, подавляющее большинство Java-нагрузок в мире по-прежнему выполняются на виртуальных машинах или на «голом железе». Однако перенос корпоративных нагрузок, и в частности, приложений Red Hat JBoss Enterprise Application Platform (EAP), в облако рано или поздно состоится, и OpenShift представляется здесь естественным выбором. Сегодня мы вкратце ответим на типовые вопросы, которые возникают при таком переходе, и покажем на примере, как он производится.

Что будет, если к Perfmon применить быстрое преобразование Фурье? Или функцию корреляции? Получится #черте_что!

Рано или поздно любой разработчик или администратор СУБД, имеющий дело с MySQL, сталкивается с проблемой блокировок. Всё дело в природе MySQL как системы с конкурентным доступом на чтение/запись. Я расскажу о видах блокировок в MySQL, их преимуществах и недостатках, о проблемах, которые они вызывают, а также дам полезные советы по обнаружению и способам борьбы с блокировками.

SELinux, как и все средства безопасности, снижает производительность системы. И хотя для большинства рабочих нагрузок такое влияние невелико (см., например, проведенное  порталом Phoronix тестирование на примере платформы Fedora 31), некоторые операции, как выяснилось, могут выполняться быстрее. Кроме того, в SELinux есть определенные шероховатости, неоправданно увеличивающие размер образов виртуальных машин или требования по оперативной памяти. Сегодня мы расскажем о недоработках в SELinux, которые нашел, устранил и закоммитил наш инженер-программист, который работает в команде Red Hat, занимающейся SELinux.

Многие из вас уже были в серверной, заглядывали туда краем глаза или в крайнем случае видели в фильмах. В кино зачастую серверная выглядит, как кабина пилота космического челнока, но в жизни всё намного прозаичней – под IT-инфраструктуру переоборудуют старую кладовку, ставят туда пару стоек и кондиционер. Но по уму надо проектировать комнату или строить отдельное здание.

В последнее время я довольно часто сталкиваюсь с оптимизацией процессов загрузки и обработки информации. Периодически вижу не самые оптимальные, а то и вредные для производительности решения причем от разработчиков middle и senior уровня. Поэтому хотелось бы подробнее описать общий подход к написанию правильных и быстрых многопоточных архитектур с максимальной утилизацией ресурсов, но при этом с минимально возможным в каждом отдельном случае количеством потоков.

Рассказываем о тестировании платформы Supermicro на основе дисков форм-фактора E1.S.

Архитектура Kubernetes хорошо подходит для организаций типа FAANG, но может оказаться избыточной и чрезмерно сложной для прочих.

1. Kubernetes разработан для компаний типа FAANG

Yandex Rate Limiter (далее просто YARL) — это сервис лимитирования нагрузки для распределённых сервисов. Его особенность в том, что он способен работать с миллионами квот, имея при этом очень низкие накладные расходы на проверку квоты. Если совсем кратко, это система распределённых Leaky Bucket'ов, с помощью которых можно ограничивать разные величины, связанные со временем: скорость передачи данных по сети, запросы в секунду и т. п.

Меня зовут Денис Кореневский, я работаю в службе разработки внутреннего хранилища Яндекса, и сегодня я расскажу, как YARL устроен внутри, почему мы вообще написали своё решение и с какими трудностями нам пришлось столкнуться в процессе создания. Добро пожаловать под кат.