Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр
Грибные блоки - красочная головоломка, в которой вам предстоит передвигать блоки и заполнять ряды, чтобы собирать грибочки в корзину! Попробуйте продержаться как можно дольше!

Грибные блоки

Головоломки, Расслабляющая, Пазлы

Играть

Топ прошлой недели

  • AlexKud AlexKud 38 постов
  • SergeyKorsun SergeyKorsun 12 постов
  • SupportHuaport SupportHuaport 5 постов
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

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

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня

Linux + Системное администрирование

С этим тегом используют

Windows IT Программирование Ubuntu IT юмор Компьютер Программист Сисадмин Работа Мат Все
107 постов сначала свежее
17
aidaho6
aidaho6
17 дней назад
GNU/Linux

Улучшения в RMON: расширенный Ping, группировка алертов и трассировка через MTR⁠⁠

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

Рассказываем, какие улучшения появились в RMON.

Улучшения в RMON: расширенный Ping, группировка алертов и трассировка через MTR IT, Linux, Сайт, Мониторинг, DevOps, Системное администрирование, Длиннопост

Ping стал умнее

Раньше проверка ping в RMON отправляла один пакет — это было достаточно для грубой оценки, но плохо отражало реальное состояние канала. Теперь всё иначе:

  • Можно указать количество ICMP-пакетов в настройках проверки.

  • Система собирает и отображает:

    • min RTT

    • max RTT

    • avg

    • mean

Это особенно полезно, если канал нестабилен: одиночный ping может случайно показать “всё хорошо”, хотя на деле теряются пакеты или резко плавает задержка.

| Возможность | SmokePing | RMON |

|-----------------------------|----------------|---------------------------|

| Графики RTT и потерь | ✅ Да | ✅ Да |

| Группировка алертов | ❌ Нет | ✅ Да |

| Настраиваемое кол-во пакетов| ✅ Частично | ✅ Да |

| Интерактивный веб-интерфейс | ❌ (CGI) | ✅ Современный UI |

| MTR из разных регионов | ❌ Нет | ✅ Да |

| Проверки из нескольких точек| ❌ (1 сервер) | ✅ Геораспределённые агенты |

| Telegram/Slack уведомления | Только через внешние скрипты | ✅ Встроено |

| API | ❌ Ограничен | ✅ Полноценный REST API |

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

RMON же изначально создавался с упором на:

  • простую установку;

  • удобный интерфейс;

  • встроенные нотификации и API;

  • и главное — распределённый мониторинг из разных географий.

Группировка алертов

Пользователи с несколькими агентами в разных регионах сталкивались с таким сценарием:

"Падает один хост — и мы получаем 5+ одинаковых алертов от каждого региона".

Теперь алерты по одному хосту автоматически агрегируются:

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

  • Упрощается логирование, снижается "шум" в системах алертинга (Telegram, Slack и т.п.)

MTR на месте

Мы добавили возможность запускать MTR (traceroute с расширенной статистикой) из конкретного региона:

Улучшения в RMON: расширенный Ping, группировка алертов и трассировка через MTR IT, Linux, Сайт, Мониторинг, DevOps, Системное администрирование, Длиннопост
  • Прямо из веб-интерфейса или API

  • Можно быстро проверить маршрут от нужного агента до целевого хоста

Это особенно удобно при отладке проблем между регионами, в CDN, или при работе с провайдером.


Что дальше

Мы продолжаем развивать RMON как инструмент для распределённого мониторинга, ориентированный на:

  • телеметрию от агентов из разных регионов;

  • гибкую конфигурацию проверок;

  • удобную интеграцию с Telegram, Slack, Prometheus, Zabbix и другими системами.

Если вы хотите точно знать, где и когда у вас реально деградирует сеть — попробуйте RMON: https://rmon.io

Показать полностью 1
[моё] IT Linux Сайт Мониторинг DevOps Системное администрирование Длиннопост
16
35
0sennijLis
0sennijLis
1 месяц назад
Лига Сисадминов

Один 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. Там всё довольно понятно и подробно описано.

Показать полностью
Linux IT Github Облачное хранилище Google Drive Dropbox Яндекс Диск Системное администрирование Текст
12
20
0sennijLis
0sennijLis
2 месяца назад
Лига Сисадминов

Продвинутая защита 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 и др.).

Показать полностью
IT Linux Гайд Системное администрирование Nginx Компьютерные сети Текст Длиннопост
9
rbayram
rbayram
2 месяца назад
IT-юмор

Pinguinux⁠⁠

Pinguinux IT, Linux, Программирование, Системное администрирование, Картинка с текстом
Показать полностью 1
IT Linux Программирование Системное администрирование Картинка с текстом
31
2
ScriptKiddie86
2 месяца назад

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot")⁠⁠

Мониторинг и алертинг серверов — важные инструменты для обеспечения бесперебойной работы веб-сайтов и сервисов. Проблемы могут возникнуть в любой момент: перегрузка сервера, сбои хостинга или ошибки в коде. Хорошая система мониторинга не только вовремя обнаруживает сбои, но и предупреждает о потенциальных проблемах — например, если сайт начал грузиться медленнее или часть запросов завершается с ошибками. Чем раньше вы выявите проблему, тем быстрее сможете её устранить, минимизировав неудобства для пользователей. Существует множество решений для мониторинга, например UpTimeRobot.

1/2

Самый крупный сервис UpTimeRobot

Мы же сегодня с вами рассмотрим его open-source альтернативу - Uptime Kuma. Его автором является Louis Lam, а сам проект расположен в GitHub. Это простой в настройке, но мощный инструмент, который позволяет в реальном времени отслеживать работу сайтов, API и серверов, мгновенно оповещая о любых сбоях. В отличие от платных аналогов, это решение, которое можно развернуть на собственном сервере, сохраняя полный контроль над данными. Uptime Kuma поддерживает различные типы проверок (HTTP, TCP, DNS, ping) и интеграции с Telegram, Slack, Discord и другими мессенджерами.

1/3

Uptime Kuma

Для работы Uptime Kuma подойдет любой сервер — можно использовать недорогой VPS или даже домашний компьютер в локальной сети. Однако важно учесть один нюанс: если развернуть мониторинг на той же машине, где работают основные сервисы, то при её отключении вы останетесь без уведомлений. Поэтому идеальный вариант — выделить для Kuma отдельный сервер или VPS в отдельной сети. Так вы всегда будете в курсе проблем, даже если основной хостинг перестанет работать.

В данной статье мы рассмотрим развертывание Kuma в Docker, по этому далее в статье у нас будет инструкция для Ubuntu 24.02 LTS, с предустановленным docker. У меня это виртуальная машина в Hyper-V. Приступим!

Разворачиваем Kuma

Подключаемся к своему серверу через PuTTy:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

Все готово к настройке

Создаем папку для нашего сервиса:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

sudo mkdir -p /opt/docker/uptime-kuma

Создаем docker-compose.yml файл с одним сервисом — Uptime Kuma. Используем порт 3001 и Bind Mount для сохранения данных:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

sudo nano /opt/docker/uptime-kuma/docker-compose.yml

Создаем каталог для данных (который прописали на предыдущем шаге в volumes):

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

sudo mkdir -p /opt/docker/uptime-kuma/kuma/data

Переходим в каталог сервиса:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

cd /opt/docker/uptime-kuma

Запускаем сервис. Docker скачает необходимые образы и запустит контейнер:

1/2

sudo docker-compose up -d

Открываем веб-интерфейс в браузере (в моем случае — 192.168.0.110:3001). Uptime Kuma предложит выполнить первоначальную настройку: создать пользователя и выбрать язык:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

http://192.168.0.110:3001

После настройки мы попадаем на главную страницу Uptime Kuma (её функционал мы рассмотрим позже):

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

Главная страница Uptime Kuma

Настраиваем доменное имя и HTTPS

Работать с IP-адресом не всегда удобно, поэтому лучше настроить доступ через доменное имя. Вариантов реализации много — можно использовать локальную DNS, hosts-файл или зарегистрировать настоящий домен. В моём случае я просто добавлю запись kuma.demo в hosts-файл на своём компьютере, но вы можете выбрать любой другой подходящий способ:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

http://kuma.demo:3001/

Для защиты данных нам нужно организовать безопасное HTTPS-соединение. Для этого мы поставим перед Uptime Kuma веб-сервер Caddy — он автоматически получает SSL-сертификаты и шифрует трафик. Я выбрал Caddy вместо nginx за его простоту и удобство конфигурации. В обновлённом docker-compose.yml обратите внимание на важные изменения:

  • Убрана публикация портов Uptime Kuma (cервисы внутри одного compose-файла могут общаться между собой по именам контейнеров без проброса портов)

  • Весь внешний трафик теперь идёт через Caddy

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

sudo nano /opt/docker/uptime-kuma/docker-compose.yml

Создаем каталоги для Caddy:

- sudo mkdir -p /opt/docker/uptime-kuma/caddy/etc/caddy
- sudo mkdir -p /opt/docker/uptime-kuma/caddy/data
- sudo mkdir -p /opt/docker/uptime-kuma/caddy/config

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

Создаем файл Caddyfile с конфигурацией:

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

sudo nano /opt/docker/uptime-kuma/caddy/etc/caddy/Caddyfile

Перезапускаем сервисы. При редактировании docker-compose.yml, он сам поймет что обновилось и изменилось и перезапустит/запустит только новые контейнеры:

1/2

sudo docker-compose up -d

Теперь у нас есть полностью настроенный экземпляр Uptime Kuma, доступный по доменному имени с поддержкой HTTPS. В следующей статье разберем, как добавить сайты для мониторинга и настроить уведомления

Мониторинг сайтов с помощью Uptime Kuma ("self-hosted UpTimeRobot") Гайд, Linux, Мониторинг, Системное администрирование, Сайт, Длиннопост

https://kuma.demo/

Итог

Мы развернули и настроили собственный экземпляр Uptime Kuma. Это потребовало некоторых усилий, но в результате мы получили мощный инструмент мониторинга, к тому же бесплатный (если не считать стоимость VPS и домена).

Для лиги лени @KumaCloudBot

Показать полностью 21
[моё] Гайд Linux Мониторинг Системное администрирование Сайт Длиннопост
6
12
0sennijLis
0sennijLis
2 месяца назад
Лига Сисадминов

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

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

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

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

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

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

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

  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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

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

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

# vgs

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

# lvcreate -l 100%FREE -n lv_linear vg_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

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

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

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

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

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

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

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

# lvdisplay -m /dev/vg_linear/lv_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

# lvdisplay -m /dev/vg_striping/lv_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

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

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

filename=/mnt/striping/testfile

Запускаем iostat:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

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

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Вывод:

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

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

Показать полностью 14
Системное администрирование Linux Shell IT Исследования Сервер Длиннопост
7
19
0sennijLis
0sennijLis
2 месяца назад
Лига Сисадминов

Влияние максимального размера 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

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

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Мы будем создавать нагрузку на диск 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.

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Наблюдения

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

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

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

cat /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Объяснение:

Инструмент 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-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

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

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

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

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

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

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

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

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

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

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

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

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

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

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

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

Заключение:

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

Показать полностью 9
Системное администрирование Компьютерное железо Linux Исследования Производительность Сервер Длиннопост
1
12
NeuralNet.2025
NeuralNet.2025
2 месяца назад
GNU/Linux

Разбор обычных проблем при обновлении ArchLinux⁠⁠

Проблема: перестал запускаться blueman-manager - программа для управления bluetooth подключениями.

$ blueman-manager

Traceback (most recent call last):

File "/usr/bin/blueman-manager", line 15, in <module>

from blueman.main.Manager import Blueman

ModuleNotFoundError: No module named 'blueman'

Эту проблему в общем виде я уже знаю - обновил python на 3.13 а библиотеки остались в путях "...3.10" поэтому он их не видит.

Хороший вариант будет обновить систему в этом случае (как и во многих других когда не охота решать проблемы, возникшие на пустом месте)

$ sudo pacman -Suy

:: Synchronizing package databases...

core 118.0 KiB 274 KiB/s 00:00 [########################################################] 100%

extra 7.6 MiB 9.22 MiB/s 00:01 [########################################################] 100%

multilib 133.8 KiB 801 KiB/s 00:00 [########################################################] 100%

:: Starting full system upgrade...

:: Replace lib32-sdl2 with multilib/lib32-sdl2-compat? [Y/n] y

:: Replace p7zip with extra/7zip? [Y/n] y

:: Replace sdl2 with extra/sdl2-compat? [Y/n] y

:: Replace webrtc-audio-processing with extra/webrtc-audio-processing-0.3? [Y/n] y

resolving dependencies...

looking for conflicting packages...

error: failed to prepare transaction (could not satisfy dependencies)

:: installing icu (76.1-1) breaks dependency 'libicui18n.so=75-64' required by electron28

:: installing icu (76.1-1) breaks dependency 'libicuuc.so=75-64' required by electron28

:: installing flac (1.5.0-1) breaks dependency 'libFLAC.so=12-64' required by electron28

Тут можно вызвать пояснительную команду: чего ему надо?


Эта ошибка pacman говорит о конфликте зависимостей. Обновление системы пытается установить новые версии пакетов icu (76.1-1) и flac (1.5.0-1), но у вас установлен пакет electron28, который жестко зависит от старых версий библиотек из этих пакетов (libicui18n.so=75-64, libicuuc.so=75-64, libFLAC.so=12-64).

Что происходит:

  1. pacman -Suy хочет обновить icu и flac.

  2. Новые icu и flac предоставляют библиотеки libicu*.so=76-64 и libFLAC.so=13-64 (или похожие новые версии).

  3. Пакет electron28 требует именно старые версии (...=75-64, ...=12-64).

  4. pacman не может одновременно удовлетворить требование electron28 (старые библиотеки) и установить новые версии icu и flac (которые предоставляют новые библиотеки). Поэтому он останавливает транзакцию.

Почему electron28 вызывает проблему:

Пакет electron28 скорее всего:

  1. Из AUR (Arch User Repository): Пакеты из AUR собираются локально и могут отставать от обновлений в официальных репозиториях. Мантейнер пакета electron28 в AUR еще не обновил его для сборки с новыми icu и flac.

  2. Из неофициального репозитория: Аналогично AUR, репозиторий может отставать.

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

Решение:

Самый частый и рекомендуемый способ - временно удалить пакет, вызывающий конфликт, обновиться, а затем попробовать установить его снова (он, вероятно, потребует пересборки из AUR).

  1. Определите, что зависит от electron28: Чтобы понять, нужен ли вам electron28 напрямую, или он нужен для какой-то другой программы:

    pacman -Qi electron28 | grep "Required By"

    # Или более подробно:

    pactree -r electron28

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

  2. Удалите electron28:

    sudo pacman -Rdd electron28

    • Внимание: Флаг -dd используется для игнорирования зависимостей при удалении. Используйте его с осторожностью. В данном случае он нужен, чтобы pacman не ругался, что удаление electron28 сломает сам electron28 (что логично).

    • Альтернатива (безопаснее): Если electron28 нужен какой-то программе (например, some-app), лучше удалить и программу, и electron28 вместе: sudo pacman -R some-app electron28.

  3. Запустите обновление системы снова:

    sudo pacman -Suy

    Теперь конфликта быть не должно, и система обновится.


Сработало. Обновилось. Проблемы ушли. Но, правда, пришлось откатить ядро 6.14.2-arch1-1 на прошлую версию 6.12.1-arch1-1 которая была установлена потому что в новом пакете ядра больше нет модуля reiserfs, а у меня все еще эта файловая система.

$ uname -r

6.12.1-arch1-1

В 2011м когда ArchLinux был установлен на этот ноут версия ядра была 2.6.33
За 14 лет много ядер сменилось, а система работает как вечная несмотря на все проблемы с обновлениями, которые иногда бывают.

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

Разбор обычных проблем при обновлении ArchLinux Arch, Linux, Обновление, Системное администрирование, Пользователи, Уверенный пользователь, Длиннопост
Показать полностью 1
[моё] Arch Linux Обновление Системное администрирование Пользователи Уверенный пользователь Длиннопост
16
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии