0sennijLis

0sennijLis

На Пикабу
29К рейтинг 14 подписчиков 12 подписок 49 постов 30 в горячем
Награды:
Ежегодное приключениеПизанская ёлкаМакаронная статуяСкуфзаводЧайкам тут не местоЗа киберзащитуЗа киноманство5 лет на Пикабу лучший авторский текстовый пост недели
53

Делает ли домашняя лаборатория вас реально лучше в администрировании?

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

— Это по работе?

И вы замираете. Потому что нет, не по работе. Вы просто тратите вечер на то, чтобы что-нибудь сломать и потом починить — ради того, чтобы разобраться.

Всё это ради того, чтобы потом наступил тот самый момент, когда на настоящей работе что-то рушится, все стоят в ступоре, а вы спокойны. Потому что именно это вы уже ломали дома. Семнадцать раз. Вы знаете, что делать. Знаете, куда смотреть. Вы уже были здесь.

Вот что даёт домашняя лаборатория. Она превращает теоретические знания в практические.

Вопрос, который задают все (и на который обычно дают сильно разные ответы)

Я много раз наблюдал, как инженеры мучаются с этим вопросом. Они видят, как кто-то дома собирает сложные стенды, запускает мини-копии продакшн-систем прямо у себя в квартире. И начинают думать: это вообще реально помогает, или тупо дорогое хобби?

Короткий ответ — зависит разумеется от того, что вы с этим делаете.

Развёрнутый ответ — если вы используете свой стенд, чтобы изучать то, к чему на работе вас не подпускают, вы прокачиваете навыки, которые однажды могут спасти вашу карьеру.

А если вы просто скупаете железки и бездумно повторяете туториалы — вы всего лишь собираете дорогую пыль.

Что на самом деле помогает на работе

Расскажу про одного человека, который собрал у себя дома небольшой кластер. Ничего особенного — просто старые компьютеры, базовые конфигурации, изучение основ.

А потом однажды на работе всё рухнуло. Продакшон упал наглухо. 18 часов на телефоне с поддержкой — и никуда не продвинулись. Команда в тупике. Полный ступор.

Этот человек за 8 часов поднял замену. Идеально ли всё работало? Нет. Готово ли было к долгой эксплуатации? Даже близко нет. Но система хотя бы продолжила жить, пока остальные искали нормальное решение.

Навыки, которые реально переносятся в работу

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

Сети перестают быть чем-то непонятным, когда вы пытаетесь разобраться, почему контейнеры видят друг друга, но не выходят в интернет. Хранилища начинают иметь смысл, когда вы забиваете диск под завязку и видите, как всё начинает тормозить. Бэкапы становятся настоящими, когда вы теряете данные, которые вам были дороги.

Это не самые эффектные навыки. Но когда на собеседовании вас спрашивают: «объясните, как работает этот сетевой механизм», и вы отвечаете не по учебнику, а из собственного опыта — это совсем другое ощущение.

Вы учитесь, ломая вещи. Потом чиня их. Потом ломая снова — но уже по-другому.

«Но у меня нет на это денег»

Вы видите все эти навороченные домашние кластеры (ну или слышите про них) и думаете, что нужно потратить несколько десятков тысяч рублей. На самом деле нет, не нужно.

Ваша тренировочная площадка может быть:

  • парой виртуалок на ноутбуке,

  • бесплатными облачными сервисами, где можно поиграться,

  • старым компом, пылящимся в шкафу,

  • или просто вашим основным компьютером, когда вы им не пользуетесь.

Тренировочная среда — это любое место, где можно безопасно накосячить. Ей не нужно выглядеть круто. Главное — чтобы вы могли ломать что угодно, не ломая работу.

Когда домашние лаборатории не помогают (чтобы быть уж до конца честными)

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

Проблемы, которые вы решаете дома, совсем другие. Дома вы боретесь с дешёвым железом и странными сетевыми глюками. На работе — с политиками безопасности и… другими людьми. (А это порой куда сложнее любой технической задачи.)

Но что действительно переносится — это способ мышления. Та самая уверенность, когда вы уже десятки раз всё ломали и чинили. Узнавание шаблонов, которое помогает сразу понять, куда смотреть.

Согласно исследованиям 2025 года, ИИ ускоряет обучение с беспрецедентной скоростью — и может сделать инженеров в пять раз эффективнее. В сочетании с практикой это буквально меняет темп, с которым вы осваиваете новое.

Некоторые отличные инженеры, которых я знаю, вообще не интересуются домашними лабораториями. Им просто не хочется тратить время на это — и это нормально. Не всем нужно, чтобы технологии были ещё и хобби.

Но если вы только входите в профессию, хотите расти быстрее, чем позволяет работа, или стремитесь разобраться в вещах, на которые на проекте нет времени — тогда домашняя лаборатория — это невероятно эффективный инструмент.

Что реально работает (по опыту тех, кто это сделал)

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

Кто-то крутит кластеры из разных типов виртуалок. Кто-то использует облака — и при этом держит расходы почти на нуле. Кто-то собирает полноценные стеки, а потом переносит эти же шаблоны в прод, когда нужно.

Один из самых эффективных подходов — собрать полноценную систему локально. Не демо “для галочки”, а полный стек: всё связано между собой, есть базы данных, кеш, мониторинг и автоматическое деплоймент. Настоящая продакшн-система, только у вас на ноутбуке.

Общая черта у всех, кто получил пользу от такого подхода, — они снова и снова что-то строят, ломают и чинят. Вот это и есть практика. Именно она формирует навык.

То, о чём обычно не говорят

Домашние лаборатории дают вам преимущество — но не такое, как вы думаете.

Они не делают вас умнее. Не заменяют годы настоящего опыта. И сами по себе не превращают вас в синьора.

Но они дают вам «повторы». А исследования показывают, что при практическом обучении люди усваивают на 25–60% больше информации, чем при обычных методах.

Когда продакшн падает, и все ищут, кто это починит, вы хотите быть тем, кто спокоен. Потому что вы уже видели что-то подобное. Может, не в таком масштабе, не с такими симптомами — но достаточно близко, чтобы мозг знал, с чего начать.

Разница между тем, кто впадает в ступор во время инцидента, и тем, кто спокойно начинает разбираться, чаще всего сводится к опыту. Если вы дома регулярно что-то ломали и чинили, вырабатывается системное мышление.

Домашние стенды развивают распознавание паттернов. Инстинкт починки. Понимание, куда смотреть первым делом, когда всё горит.

Ошибки всё равно будут. Паника — тоже. Но у вас будет больше инструментов в голове. А это и есть разница между тем, кто замирает, и тем, кто начинает действовать.

Как начать, не закапываясь в планировании

Вам не нужен план. Вам не нужно что-то покупать. Вам не нужно уже сейчас понимать, что именно вы делаете.

Выберите одну вещь, которую хотите понять лучше. Всего одну.

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

Ключ — сделать всё достаточно «настоящим», чтобы при поломке вам пришлось действительно чинить, а не просто перезапускать туториал. Думать, читать логи, формулировать гипотезы, проверять их.

Проблема с резюме (которую домашняя лаборатория сама по себе не решит)

Можно собрать идеальный стенд, досконально знать, как всё работает, — и при этом так ни разу и не пройти первичный отбор.

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

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

Что это всё на самом деле значит

Настоящая ценность — не в железе, не в тулзах и даже не в сертификатах.

Ценность — в уверенности, которая приходит, когда вы уже делали что-то своими руками. Когда знаете: да, всё сломается — но у вас есть способ разобраться. Вы уже были в этом месте. Может, не точно в таком, но достаточно близко.

Когда я вижу инженеров с домашними лабораториями и без — разница видна сразу. Те, кто практикуется, мыслят системно. Знают, куда смотреть. Не паникуют, когда что-то не работает с первого раза — потому что уже поняли, что это нормально.

Остальные всё ещё ожидают, что всё заработает сразу. Быстрее застревают. Ждут, пока кто-то подскажет ответ.

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

Даже опытные инженеры косячат в своих лабораториях. Именно это и есть показатель роста. В тот момент, когда вы перестаёте что-то ломать, вы перестаёте развиваться.

Так что идите и сломайте что-нибудь. Нарочно. Посмотрите, что произойдёт. Именно тем и живёт настоящее обучение.

Показать полностью
36

Один rclone, чтобы править всеми

Небольшая заметка о, на мой взгляд, не слишком популярном и за счет этого сильно недооцененном решении, которое в своё время здорово помогло мне собрать все подключения моих облачных хранилищ в одном месте.

Речь конечно о rclone.

Эта утилита особенно удобна, когда нужно работать с несколькими облаками как с обычными папками: можно просматривать содержимое, копировать файлы между сервисами и делать это прямо из файлового менеджера — без лишних обёрток и веб-интерфейсов.

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

По опыту оно стабильно работает с Gdrive, Dropbox, YandexDisk, Nextcloud.

Единственная проблема с которой столкнулся - медленная работа с Gdrive, но тут проблема не rclone, а скорее нюансы конфигурации для конкретного случая. Так что на всякий случай оставлю здесь конфигурацию, которая у меня заработала без тормозов для Gdrive:

exec_always --no-startup-id rclone mount \

--bind 0.0.0.0 \

--umask=002 \

--gid=1002 \

--uid=1000 \

--allow-other \

--timeout=1h \

--poll-interval=15s \

--dir-cache-time=1000h \

--cache-dir=/opt/rclone/cache/gmedia \

--vfs-cache-mode=full \

--vfs-cache-max-size=150G \

--vfs-cache-max-age=12h \

yourdrive: ~/путь/к/диску

Решающим тут к слову тогда оказался --bind 0.0.0.0 - он заставляет использовать строго IPv4.

Если требуется более гибкая настройка или хочется понять, что именно делают все эти флаги — рекомендую заглянуть в официальную документацию rclone. Там всё довольно понятно и подробно описано.

Показать полностью
20

Продвинутая защита Nginx

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

Логирование в формате JSON

JSON — лучший выбор формата для логов Nginx по двум основным причинам. Во-первых, он гораздо более читаем для человека. Во-вторых, передача логов в такие системы, как OpenSearch, для последующего мониторинга или в рамках SIEM-решений становится сильно проще.

Вот простой пример из nginx.conf:

log_format json-logger escape=json '{

"type": "access-log",

"time": "$time_iso8601",

"remote-ip": "$remote_addr",

"x-forward-for": "$proxy_add_x_forwarded_for",

"request-id": "$request_id",

"request-length": "$request_length",

"response-bytes": "$bytes_sent",

"response-body-size": "$body_bytes_sent",

"status": "$status",

"vhost": "$host",

"protocol": "$server_protocol",

"path": "$uri",

"query": "$args",

"duration": "$request_time",

"backend-duration": "$upstream_response_time",

"backend-status": "$upstream_status",

"method": "$request_method",

"referer": "$http_referer",

"user-agent": "$http_user_agent",

"active-connections": "$connections_active"

}';

access_log /var/log/nginx/access.log json-logger;

Это приведёт к следующему выводу в файле access.log:

{

"type": "access-log",

"time": "2025-02-25T16:02:54+00:00",

"remote-ip": "130.61.78.239",

"x-forward-for": "130.61.78.239",

"request-id": "38750f2a1a51b196fa0a76025b0d1be9",

"request-length": "258",

"response-bytes": "353",

"response-body-size": "167",

"status": "404",

"vhost": "3.69.78.187",

"protocol": "HTTP/1.1",

"path": "/lib/phpunit/Util/PHP/eval-stdin.php",

"query": "",

"duration": "0.016",

"backend-duration": "0.016",

"backend-status": "404",

"method": "GET",

"referer": "",

"user-agent": "Custom-AsyncHttpClient",

"active-connections": "1"

}

Параметризация запросов

Большие размеры тела запроса, длительные тайм-ауты и чрезмерно увеличенные настройки KeepAlive могут негативно повлиять на производительность. Чтобы повысить эффективность, лучше устанавливать эти параметры на минимально возможные значения — при этом, само собой, соблюдая требования вашего приложения.

Пример из nginx.conf:

client_max_body_size 10M;

client_body_timeout 10s;

client_header_timeout 10s;

keepalive_timeout 5s 5s;

Описание параметров:

  • client_max_body_size

Определяет максимальный размер тела HTTP-запроса, который клиент может отправить. Если лимит превышен, Nginx возвращает ошибку 413 Request Entity Too Large.

  • client_body_timeout

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

  • client_header_timeout

Устанавливает максимальное время ожидания полного заголовка HTTP-запроса от клиента. Если лимит превышен — соединение также закрывается.

  • keepalive_timeout

Определяет, как долго будет оставаться открытым соединение Keep-Alive после последнего запроса.

Первый параметр (например, 5s) задаёт тайм-аут на стороне сервера. Второй (опциональный) параметр передаётся клиенту как предложение о том, как долго он может держать соединение открытым.

Ограничение количества запросов

На случай если клиент пытается перегрузить веб-сервер частыми запросами, Nginx предоставляет возможность настроить "зоны ограничения запросов" (limit request zones) — для контроля трафика по различным параметрам.

Пример настройки (реверс-прокси с зоной ограничения запросов):

limit_req_zone $binary_remote_addr zone=limitreqsbyaddr:20m rate=15r/s;

limit_req_status 429;

upstream app.localhost {

server localhost:8080;

}

server {

listen 443 ssl;

server_name app.devlab.intern;

location / {

limit_req zone=limitreqsbyaddr burst=10;

proxy_pass http://app.localhost;

}

}

Пояснение параметров:

  • $binary_remote_addr

Используется для настройки зоны ограничения по IP-адресу клиента. Адрес сохраняется в бинарной форме (это снижает потребление памяти).

  • zone=limitreqsbyaddr:20m

Создаёт общую (shared) область памяти объёмом 20 МБ с именем limitreqsbyaddr. В этой зоне хранятся данные о лимитах для разных IP-адресов.

  • rate=15r/s

Ограничивает количество запросов до 15 запросов в секунду на IP. Превышение лимита приводит к отклонению избыточных запросов.

  • limit_req_status 429;

При превышении лимита Nginx возвращает статус 429 Too Many Requests, что означает: "Слишком много запросов за короткое время".

Эта конфигурация помогает защитить сервисы от перегрузки и злоупотреблений.

Ограничение только на необходимые HTTP-методы

На мой взгляд, ограничение допустимых HTTP-методов только теми, которые действительно необходимы или поддерживаются приложением (например, REST API), — это чистый и логичный способ синхронизации настроек веб-сервера с логикой приложения. Это помогает не только предотвратить неправильное использование API или вызов нежелательных методов, но и блокирует потенциально опасные запросы вроде TRACE. Кроме того, это снижает ненужную нагрузку на сервер, устраняя неподдерживаемые или неуместные запросы.

Пример: разрешён только метод GET (HEAD разрешается по умолчанию):

# HEAD is implicit

limit_except GET {

deny all;

}

Пример: разрешить все методы, кроме TRACE и PATCH:

if ($request_method ~ ^(PATCH|TRACE)$) {

return 405;

}

Простая защита от ботов

Если на сервер поступают запросы от ботов или плохо сконфигурированных сканеров (часто с «говорящими» user-agent'ами), можно внести путаницу и затруднить их работу, возвращая нестандартный статус HTTP от самого Nginx.

Для этого создаём файл bot.protection.conf в директории /etc/nginx/snippets со следующим содержимым:

map $http_user_agent $blacklist_user_agents {

~*wpscan 1;

~*dirbuster 1;

~*gobuster 1;

}

Вы можете дополнять список по мере необходимости.

Внутри конфигурации виртуального хоста (VHost) подключите файл следующим образом:

include /etc/nginx/snippets/bot.protection.conf;

if ($blacklist_user_agents) {

return 444;

}

HTTP 444 также можно «весело» использовать для предотвращения угадывания служебных файлов, таких как .env:

# <your-domain>/.bash_history for example ends with HTTP 444.

location ~ /\. {

return 444;

}

Что означает HTTP 444?

HTTP 444 — это нестандартизированный статус-код, используемый в NGINX, который заставляет сервер мгновенно закрыть соединение без отправки заголовков ответа клиенту. Чаще всего используется для отклонения вредоносных или некорректно оформленных запросов. Интересный побочный эффект: некоторые сканеры не умеют корректно обрабатывать такие ответы, что добавляет дополнительный уровень защиты.

Включение TCP Fast Open

TCP Fast Open — это важное улучшение в Nginx, которое позволяет более эффективно устанавливать TCP-соединения. Эта функция даёт возможность начать передачу данных уже во время начального рукопожатия, что заметно ускоряет процесс установления соединения. Особенно полезна она в условиях высокой сетевой задержки, так как помогает сократить латентность и повысить производительность.

Проверка поддержки TCP Fast Open в ядре Linux

Выполните следующую команду:

cat /proc/sys/net/ipv4/tcp_fastopen

Если в ответе вернётся 1, функция уже включена. Если нет — включите её командой:

echo 1 > /proc/sys/net/ipv4/tcp_fastopen

Использование в конфигурации Nginx

Добавьте параметр fastopen в директивы listen:

listen [::]:443 ssl http2 fastopen=500;

listen 443 ssl http2 fastopen=500;

Число 500 — это количество подключений, которые могут использовать TCP Fast Open одновременно (значение можно адаптировать под вашу нагрузку).

Сжатие с помощью GZip

GZip — это метод сжатия данных, позволяющий уменьшить размер файлов. При этом исходные данные можно полностью восстановить путём распаковки («разархивирования») сжатого файла.

Для веб-приложений и сайтов GZip особенно важен, поскольку HTTP-протокол поддерживает передачу данных в сжатом виде до того, как они попадут в сеть.

Почему GZip важен:

  • Снижение трафика: при включённом GZip размер передаваемых файлов уменьшается, что приводит к меньшему потреблению пропускной способности.

  • Экономия на хостинге: меньше трафика — ниже затраты на обслуживание.

  • Ускорение загрузки для пользователей: посетители получают более лёгкие файлы, что сокращает время загрузки страниц.

Пример конфигурации:

gzip on;

gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

Эта настройка включает GZip и указывает типы содержимого, которые следует сжимать (текст, CSS, JavaScript, XML, JSON и др.).

Показать полностью
12

Повышение производительности с использованием LVM Striping

В области управления хранилищами приоритетом является достижение оптимальной производительности дисков. Стремление к более быстрому доступу к данным, уменьшению задержек и повышению количества операций ввода-вывода (I/O) и пропускной способности привело к использованию передовых техник. Одной из таких является LVM Striping (полосование), мощная функция менеджера логических томов (LVM), которая существенно повышает производительность дисковых томов.

Линейный (Linear) LVM против LVM Striping:

1.1 — Линейный LVM:

Линейная конфигурация, являющаяся стандартным подходом для LVM, подразумевает последовательное добавление нескольких физических томов (дисков) в группу томов (Volume Group). Данные последовательно записываются на эти диски: сначала заполняется один диск, затем следующий, и так далее.

Хотя линейный LVM прост и удобен для расширения хранилищ, он не полностью раскрывает потенциал параллельной обработки и увеличения общей пропускной способности.

1.2 — LVM Striping (Полосование):

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

Процесс создания полос:

  1. Создание полос:

  • Данные разделяются на сегменты («полосы»).

  • Каждая полоса записывается на отдельный диск в составе логического тома.

2. Параллельная запись полос:

  • Полосы записываются параллельно на несколько физических томов (дисков).

3. Равномерное распределение:

  • Полосы равномерно распределены по дискам, предотвращая появление узкого места (bottleneck).

4. Увеличение IOPS и пропускной способности:

  • Благодаря параллельной записи полос LVM Striping существенно увеличивает общую производительность и пропускную способность логического тома.

1.3 — Пример использования:

Рассмотрим пример с тремя дисками, каждый из которых обеспечивает пропускную способность 125 МБ/с:

  • При использовании LVM Striping суммарная производительность составит 375 МБ/с.

  • В случае же с линейным LVM, производительность останется равной 125 МБ/с, вне зависимости от количества добавленных дисков.

Настройка Linear LVM и Striping LVM:

В этом разделе мы создадим две группы томов (Volume Groups, VG): одну линейную, вторую — с полосованием, каждая с использованием трёх дисков. Затем создадим логические тома (Logical Volumes, LV), отформатируем и смонтируем их.

2.1 — Исходные данные:

  • Сервер: AWS EC2 instance типа m4.10xlarge

  • EBS-диски: 6 штук по 20ГБ (тип GP3, 3000 IOPS, 125MiB/s пропускная способность каждый)

  • ОС: Amazon Linux 2

Просмотр подключенных дисков:

# lsblk

2.2 — Создание групп томов (VG):

Создадим две группы томов:

# vgcreate vg_linear /dev/sdb /dev/sdc /dev/sdd
# vgcreate vg_striping /dev/sde /dev/sdf /dev/sdg

# vgs

2.3 — Создание линейного логического тома (Linear LVM):

# lvcreate -l 100%FREE -n lv_linear vg_linear

Параметры:

  • -l 100%FREE — задействовать весь доступный объем VG.

  • -n lv_linear — имя логического тома.

  • vg_linear — целевая группа томов.

2.4 — Создание логического тома с полосованием (Striping LVM):

# lvcreate -l 100%FREE -i 3 -I 64k -n lv_striping vg_striping

Параметры:

  • -l 100%FREE — задействовать весь объем VG.

  • -i 3 — количество полос (равно числу дисков).

  • -I 64k — размер полосы.

  • -n lv_striping — имя логического тома.

  • vg_striping — целевая группа томов.

2.5 — Проверка созданных LV:

Проверка линейного LV:

# lvdisplay -m /dev/vg_linear/lv_linear

Проверка LV с полосованием:

# lvdisplay -m /dev/vg_striping/lv_striping

Здесь мы можем увидеть различные детали наших настроек.

2.6 — Форматирование и монтирование LV:

# mkfs.xfs /dev/vg_linear/lv_linear

# mkfs.xfs /dev/vg_striping/lv_striping

# mkdir /mnt/linear

# mkdir /mnt/striping

# mount /dev/vg_linear/lv_linear /mnt/linear/

# mount /dev/vg_striping/lv_striping /mnt/striping/

# df -h

LV успешно смонтированы.

3 — Тестирование производительности LV (benchmark):

Для тестирования используем инструмент fio:

# yum install fio -y

3.1 — Тестирование линейного LV:

Чтобы сравнить LV, мы будем использовать файл конфигурации FIO, который поможет нам генерировать трафик на 400м:

# cat fio_config-1.fio

[global]

ioengine=libaio

runtime=60

time_based

direct=1

rw=write

size=10G

bs=512K

rate=400M

numjobs=16

[job1]

filename=/mnt/linear/testfile

Запуск тестирования с созданным конфигом:

# fio fio_config-1.fio

Одновременно с этим в отдельном терминале запустим iostat, чтобы контролировать использование дисков:

# iostat -xdmt 2

Видим, что используется только один диск xvdb со скоростью 125 МБ/с.

Ту же картину нам демонстрирует и fio:

Операции записи были выполнены исключительно на одном диске.

3.2 — Тестирование LV с полосованием:

Теперь снова запустим fio, но изменим параметр filename в файле конфигурации:

filename=/mnt/striping/testfile

Запускаем iostat:

Все три диска работают параллельно, суммарная скорость равна 375 МБ/с (125 x 3).

Аналогичную картинку нам демонстрирует и fio:

Вывод:

LVM Striping является мощным решением для организаций, которые хотят максимально эффективно использовать ресурсы своих хранилищ. Распределяя данные параллельно на несколько дисков, LVM Striping не только значительно увеличивает производительность, но и обеспечивает масштабируемость и гибкость управления хранилищами.

Используйте LVM Striping, чтобы раскрыть потенциал параллельной обработки данных и вывести производительность дисковой подсистемы на новый уровень.

Показать полностью 14
19

Влияние максимального размера I/O-запросов на производительность систем Linux

В области оптимизации производительности Linux важнейшим фактором является производительность дискового ввода-вывода (I/O), которая существенно влияет на общую эффективность системы. Одним из ключевых параметров, влияющих на производительность дискового ввода-вывода, является максимальный размер I/O-запроса, определяемый параметром max_sectors_kb. Понимание и настройка этого параметра могут привести к значительному улучшению производительности системы. В этой статье мы рассмотрим понятие максимального размера I/O, его важность в системах Linux, а также его влияние на производительность в целом.

Понимание максимального размера I/O (max_sectors_kb)

Параметр max_sectors_kb определяет максимальный размер отдельного I/O-запроса в килобайтах. Он устанавливает объём данных, который может быть передан в рамках одного I/O-запроса. Значение параметра max_sectors_kb ограничено логическим размером блока файловой системы и аппаратными возможностями устройства хранения данных. Оно не может быть меньше логического размера блока, делённого на 1024, и не должно превышать значение параметра max_hw_sectors_kb, который является параметром только для чтения и показывает максимально поддерживаемый аппаратурой размер запроса.

Минимальное значение = max(1, logical_block_size/1024) 

Максимальное значение = max_hw_sectors_kb

Примечание: Максимальный размер I/O в Linux преимущественно применим к ядрам версии 4.x и выше. Рекомендуется проверить это в конкретном ядре вашей системы. Хотя впрочем очевидно - если у вас не какой-нибудь embedded, то ядро скорее всего будет выше 5.x

Важность в системах Linux

В Linux параметр максимального размера I/O существенно влияет на эффективность чтения и записи данных с устройств хранения. Он оказывает влияние на следующие аспекты производительности:

1. Баланс между пропускной способностью и задержками:

  • Пропускная способность (Throughput): Крупные размеры I/O-запросов увеличивают общую пропускную способность ввода-вывода за счёт обработки больших блоков данных за одну операцию. Это снижает накладные расходы на обработку множества мелких запросов, особенно эффективно при работе с последовательными потоками данных (видеостриминг, резервные копии баз данных).

  • Задержки (Latency): В то время как большие размеры I/O-запросов могут повысить пропускную способность для больших наборов наборов, они также могут увеличить задержку отдельных операций. Это происходит потому, что более крупные запросы требуют больше времени для завершения. Поэтому необходим баланс между улучшением производительности и допустимым уровнем задержек, особенно в чувствительных к задержкам интерактивных или real-time приложениях. В таких случаях предпочтительнее меньшие размеры запросов.

2. Использование CPU:

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

3. Использование памяти:

  • Максимальный размер I/O влияет на объём выделяемой памяти под буферы ввода-вывода, что также отражается на общем использовании памяти системой.

Факторы, влияющие на максимальный размер I/O

Есть несколько факторов, которые влияют на максимальный размер запросов в Linux:

  • Аппаратные ограничения: Значение max_sectors_kb не должно превышать аппаратные возможности накопителя (значение параметра max_hw_sectors_kb). Превышение аппаратного лимита может привести к ошибкам или снижению производительности.

  • Драйверы устройств: Драйверы контроллеров хранения и накопителей могут задавать свои лимиты на размер запросов.

  • Ограничения файловых систем: У разных файловых систем разные лимиты на размер запроса ввода-вывода.

  • Параметры ядра Linux: Настройки блочных устройств ядра влияют на размер запроса.

Бенчмаркинг и мониторинг

Для определения оптимального размера I/O-запросов необходимо проводить тестирование (бенчмарки) и мониторить показатели производительности (например, с помощью утилиты iostat).

Рекомендуется учитывать:

  • Red Hat советует, чтобы значение max_sectors_kb было кратно оптимальному размеру I/O и внутреннему размеру блока стирания устройства. Если таких данных нет, рекомендуется выставить значение, совпадающее с логическим размером блока устройства.

  • Характеристики рабочей нагрузки: разные приложения выигрывают от разных размеров I/O.

  • Особенности накопителя: HDD и SSD имеют разные оптимальные диапазоны размеров I/O.

  • Ресурсы системы: доступная память и мощность CPU влияют на выбор оптимального размера I/O.

Практические аспекты настройки

Для настройки max_sectors_kb используется команда:

/sys/block/{device}/queue/max_sectors_kb

Например:

echo 256 | sudo tee /sys/block/sda/queue/max_sectors_kb

Данная команда устанавливает максимальный размер запроса в 256 КБ для диска /dev/sda. Перед изменениями желательно протестировать настройки на тестовой системе во избежание негативного влияния на производительность или стабильность системы.

Изменения параметра действуют только до перезагрузки системы. Чтобы изменения сохранялись, добавьте команду в rc.local или настройте сервис для применения параметров при загрузке.

Практическое исследование

Рассмотрим практический сценарий. Создадим лабораторную среду на Linux-сервере и проверим производительность диска. Нагрузку (IOPS) будем генерировать с помощью инструмента fio, а мониторинг производительности проводить с помощью утилиты iostat. Наша задача — оценить влияние параметра max_sectors_kb на производительность системы.

Среда для тестирования:

  • Тип EC2-инстанса: c5.12xlarge

  • EBS-том:

  • тип: GP3

  • размер: 20 GiB

  • IOPS: 3000

  • пропускная способность: 750 MB/s

  • Операционная система: Amazon Linux 2

Проверка дисков и установка fio

Для начала проверим доступные диски:

Мы будем создавать нагрузку на диск nvme1n1 при помощи утилиты fio и параллельно мониторить производительность диска, в частности показатель IOPS. Если fio не установлен, используйте команды ниже:

Для Amazon Linux:

sudo yum install -y fio

Для Ubuntu:

sudo apt-get install -y fio

Запуск теста

Откройте два терминала одновременно:

Терминал 1: Генерируем нагрузку:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Терминал 2: Мониторим диск:

iostat 1 -d /dev/nvme1n1

Обратите внимание, что в команде fio мы задали размер запроса 256 KiB.

Наблюдения

На первом скриншоте видно, что утилита fio генерирует 1082 IOPS, однако утилита iostat показывает примерно 2164 IOPS (то есть в два раза больше).

Причина различий

Чтобы выяснить причину этого несоответствия, проверим значение параметра max_sectors_kb:

cat /sys/block/nvme1n1/queue/max_sectors_kb

Объяснение:

Инструмент fio создавал IOPS с размером 256 KiB, а max_sectors_kb был установлен на значение 128 KiB. В результате ядро Linux разбивало каждый запрос на два меньших запроса по 128 KiB каждый (256 KiB = 128 KiB × 2). Именно поэтому количество операций, регистрируемых iostat, было в два раза больше, чем указывал fio (1082 × 2 = 2164).

Важно: Увеличение числа запросов из-за неправильно настроенного max_sectors_kb может негативно повлиять на производительность сервера и привести к троттлингу производительности диска (например, EBS-тома), если число операций превышает базовый уровень IOPS.

Проверка максимального аппаратного лимита max_hw_sectors_kb

Проверим максимальное значение I/O, которое поддерживает наш сервер:

cat /sys/block/nvme1n1/queue/max_hw_sectors_kb

Результат: наш сервер поддерживает максимальный размер I/O-запроса в 256 KiB.

Попытка увеличения max_sectors_kb

Попробуем увеличить значение до 512 KiB:

echo 512 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Результат: Мы получили ошибку «Invalid argument» («Недопустимый аргумент»), так как указали значение, превышающее аппаратный лимит max_hw_sectors_kb.

Теперь установим допустимое значение 256 KiB:

echo 256 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Результат: Значение успешно изменено на 256 KiB.

Повторный запуск теста fio

Повторим тест командой:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Результат: После изменения параметра max_sectors_kb количество операций IOPS, отображаемое fio и iostat, совпало.

Заключение:

Максимальный размер I/O-запроса (max_sectors_kb) является мощным инструментом для тонкой настройки производительности дисковой подсистемы в Linux. Правильно подобранное значение позволяет оптимизировать производительность ввода-вывода и снизить нагрузку на CPU, однако следует учитывать возможное увеличение задержек и аппаратные ограничения. Любые изменения параметров производительности следует предварительно тестировать и внимательно анализировать перед внедрением в продуктивную среду. Это гарантирует стабильность работы системы и её оптимальную производительность в различных сценариях.

Показать полностью 9
88

Ответ на пост «Мегафон радует»3

Оооо. Подержите моё пиво.

Со мной недавно Мегафон тоже интересный фокус пытался провернуть.

У меня редкий (по нынешним меркам) тариф с безлимитным интернетом. И меня, внезапно, всё устраивает (даже учитывая что они нещадно режут полосу для анлимов). Тем более за 715 рублей в месяц.

Но тут внезапно приходит смска от мегафона с следующим содержанием:

Вот это великодушие @megafon. Тариф на 100 с лишним рублей дороже и с гораздо более худшими условиями. Что тут сказать.

Расчёт очевидно на то, что какой-то процент людей проморгает сообщение, а после смены тарифа обратно уже ничего не будет поменять.
А как только этот вариант отработает, придумают что-то более изощрённое.
И главное смысла особого менять оператора нет. У других в том или ином виде тоже присутствуют регулярные попытки нае обмануть клиента. Это же конторы одного профиля:

Показать полностью 3
Отличная работа, все прочитано!