Начнем с сегодняшнего дня приводить в порядок свой долгострой и назовем его Rain Project. У каждого уважающего себя долгостроя должно быть какое-то кодовое имя иначе карабль не поплывет если его никак не назвать. Ибо так завещал капитан Врунгель.

База данных Postgresql

Установка Postgresql в Ubuntu Linux

Я почему-то упустил момент с базой данных и у меня как оказалось в кластере нет ни одной базы Postgresql и в принципе в них и надобности то небыло до сегодняшнего дня. Итак, исправим эту досадную оплошность и установим базу данных Postgresql на первый хост (srv-prod-rain-01).

# aptitude install postgresql-all
# systemctl enable postgresql
# systemctl start postgresql

Во первых, надо разрешить удаленный доступ к базе данных и разрешим доступ в /etc/postgresql/16/main/pg_hba.conf с любого узла в сети. Не будем себя искуственно ограничивать, так как у нас все и так закрыто Firewall-ом.

host    all             all             0.0.0.0/0               scram-sha-256

Так-же необходимо принимать соединения на всех интерфейсах, для чего в файле /etc/postgresql/16/main/postgresql.conf меняем параметр.

listen_addresses = '*'

И перезапускаем сервис.

# systemctl restart postgresql@16-main.service

Базовый тюнинг Postgresql

И после установки сразу проведем небольшую базовую настройку. Проект у меня не HighLoad поэтому настройка минимальная.

Память

• shared_buffers
  Кеш для данных БД. Рекомендация: 15–25 % от ОЗУ (например, 4 GB при 16 GB ОЗУ). Но не ставьте слишком много, системе тоже нужен кеш.
• work_mem
  Память на один запрос (сортировки, хеши). Можно начать с 4–16 MB и в дальнейшем посмотреть на производительность базы. Но учтите, что если запросов много, высокое значение может съесть всю память.
• maintenance_work_mem
  Больше для системных операций таких как VACUUM, CREATE INDEX и т. п. Можно смело поставить 5-10% от ОЗУ.
• effective_cache_size
  Оценка доступного дискового кеша (ОС + shared_buffers). В принципе можно поставить 50–75 % от ОЗУ.

Журналирование (WAL)

• wal_buffers
  Буфер для WAL. Обычно 16-20 MB достаточно. При высокой нагрузке можно увеличить.
• checkpoint_timeout
  Как часто делаются чекпоинты (по умолчанию 5 мин). Можно увеличить до 10–30 мин для снижения нагрузки на диск если уверены в стабильности вашей системы.
• max_wal_size
  Максимальный размер WAL между чекпоинтами. Увеличьте при больших нагрузках (например, 2 GB).

Процессы и воркеры

• max_worker_processes
  Общее число фоновых процессов. По умолчанию число ядер сервера.
• max_parallel_workers_per_gather
  Число параллельных воркеров на запрос. Можно попробовать 2–4 воркера.
• max_parallel_workers
  Общее число параллельных воркеров. Должно быть меньше max_worker_processes.

Подключение

• max_connections
  Максимальное число подключений. Не ставьте слишком много, подключения выделяются сразу и расходуют память. Не много конечно, но имеем накладные расходы. Для веб‑приложений часто хватает около 200, но тут уже от приложения зависит.

Дополнительные рекомендации

• Автовакуум (autovacuum)
  Не отключайте ни в коем случае и обязательно настройте autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor для часто обновляемых таблиц.
• Индексы
  Анализируйте медленные запросы EXPLAIN (ANALYZE, BUFFERS) и добавляйте индексы там, где это нужно.
• Статистика
  Убедитесь, что default_statistics_target достаточно высок (по умолчанию 100) для точных планов запросов.
• Логирование
  Включите logging_collector и настройте log_min_duration_statement (например, 100 ms) для выявления медленных запросов.

Инструменты для анализа

pg_stat_statements — топ медленных запросов.
pg_stat_activity — текущие подключения и запросы.
EXPLAIN (ANALYZE, BUFFERS) — детальный план запроса.

Для моего мини-сервера с 4 ГБ оперативной памяти и двумя ядрами прикинем, по оптимизации нечно вроде такого.

shared_buffers = 1GB
work_mem = 16MB
maintenance_work_mem = 1GB
effective_cache_size = 2GB
wal_buffers = 16MB
checkpoint_timeout = 30min
max_wal_size = 1GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 8
max_connections = 150
autovacuum = on
log_min_duration_statement = 100ms

Базовые пользователи для удаленного доступа

Сменим пароль пользователя postgres, настроим доступ до базы с помощью Dbeaver и создадим непривелигированного пользователя и базу данных владельцем которой он будет являться. В целом типовые операции.

# su postgres
$ psql 
# ALTER USER postgres WITH PASSWORD 'xxxPASSWORDxxx';
# CREATE USER zabbix_user WITH PASSWORD 'xxxPASSWORDxxx';
# CREATE DATABASE zabbix_db WITH OWNER zabbix_user;

Уменьшение размера журнала SystemD

Места на моем FreeTier сервере как говорится кот наплакал, а журнал SystemD занимает почти 3 гигабайта места.

# du -hs /var/log/* | grep journal
2.9G    /var/log/journal

Как-то это расточительно и надо навести порядок. И для этого во первых меняем парамерт лимита на размер журнала в файле /etc/systemd/journald.conf.

[Journal]
SystemMaxUse=30M

Перезапускаем сервис.

# systemctl restart systemd-journald

Проверяем.

# du -hs /var/log/* | grep journal
65M     /var/log/journal

Получилось больше лимита, но да и черт с ним главное, что не 2.5 ГБ ненужного мусора.

Установка Zabbix-сервера и Zabbix-агента

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

Установка репозитария

# wget https://repo.zabbix.com/zabbix/7.4/release/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.4+ubuntu22.04_all.deb
# dpkg -i zabbix-release_latest_7.4+ubuntu22.04_all.deb
# apt update

Устанавливаем серверную часть, фронтенд и агент второй версии

База данных у нас уже есть и нам нужен только фронтенд и бэкенд.

# apt install zabbix-server-pgsql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent2 php-pgsql

Инициализация базы данных

# su postgres
# zcat /usr/share/zabbix/sql-scripts/pgsql/server.sql.gz | psql -u zabbix_user -h 127.0.0.1 zabbix_db

Настройка параметров доступа к базе данных

Файл /etc/zabbix/zabbix_server.conf

DBName=zabbix_db
DBUser=zabbix_user
DBPassword=xxxPASSWORDxxx

Перезапускаем сервис и проверям, что он работает.

# systemctl enable zabbix-server
# systemctl restart zabbix-server

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

# netstat -tulpn | grep 10051
tcp        0      0 0.0.0.0:10051           0.0.0.0:*               LISTEN      1062/zabbix_server  
tcp6       0      0 :::10051                :::*                    LISTEN      1062/zabbix_server

Дополнительный тюнинг заббикс

По окончании настройки Zabbix проводим дополнительную настройку по статье «Мониторинг серверов PostgreSQL при помощи Zabbix«

Транспортный контейнер L2TP/IP-SEC в Squid

В данном случае решался вопрос создания контейнера в котором будет реализован прокси-сервер Squid имеющий доступ в сеть интернет через тунель L2TP/IP-SEC (зарубежом). Данное решение используется для доступа к заблокированным в РФ репозитариям ПО.

Из особенностей реализации был организован контейнер с дополнительными параметрами доступа к ppp-устройству хоста для полноценной работы StrongSwan.

# lxc config device add srv-lxc-prod-rain-01 mypppdevice unix-char source=/dev/ppp uid=0 gid=0 mode=0600

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

Сервис SystemD выглядит следующим образом (/etc/systemd/system/lxd-4-squid.service).

[Unit]
Description=NAT network for Squid
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/nat-4-squid.sh

[Install]
WantedBy=multi-user.target