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

В области управления хранилищами приоритетом является достижение оптимальной производительности дисков. Стремление к более быстрому доступу к данным, уменьшению задержек и повышению количества операций ввода-вывода (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, чтобы раскрыть потенциал параллельной обработки данных и вывести производительность дисковой подсистемы на новый уровень.

Проблема: перестал запускаться 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 лет много ядер сменилось, а система работает как вечная несмотря на все проблемы с обновлениями, которые иногда бывают.

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

В начале 2024 года, в условиях активного импортозамещения и опасений возможных принудительных мер со стороны властей по переходу на отечественное ПО, мы начали искать альтернативные решения. Основываясь на опыте использования 1С, которое активно применяется в России, и после изучения материалов Гилева, мы решили рассмотреть PostgresPro Ent.

Проведя базовые тесты, нас устроила его функциональность, встроенная кластеризация BiHa PostgresPro Ent и административная панель PPEM. Все выглядело красиво и удобно. В итоге было принято решение закупить лицензии на PostgresPro Ent для двух серверов и развернуть на них часть баз 1С.

Развертывание прошло быстро и без значительных затруднений. Мы создали несколько инстансов для удобства восстановления, так как в отличие от MSSQL, в Postgres нельзя работать с резервными копиями отдельных баз данных без риска потери данных, а только с инстансом целиком.

В процессе эксплуатации выявились некоторые неприятные особенности. В частности, очень долгое резервное копирование с использованием pg_probackup. База 1С на MS SQL, объемом около 100 ГБ, копируется на сервер резервного копирования за 5-10 минут, в то время как аналогичная база на PostgresPro Enterprise требует более 2 часов. Многие могут предложить использовать более мощное оборудование или смотреть в сторону инкрементальных бэкапов (в плане обслуживания MSSQL мы используем как полные таки и инкрементальные). Но проблема заключается в самой логике работы pg_probackup, которая не позволяет сразу архивировать все файлы в один архив и далее работать уже с ними, а фактически учитывая структуру базы 1С там не одна тысяча мелких файлов которые очень "замечательно" копируются по сети, даже 10GBps не изменяет ситуацию. Также возникло множество мелких вопросов, требующих дополнительных компетенций, но пути решения были найдены, хотя и не всегда оптимальные. Вывод: PostgresPro требуется значительного много времени что бы догнать MS SQL в удобстве использования и обслуживания.

Однако главная особенность PostgresPro Enterprise заключается в следующем: при покупке бессрочной лицензии PostgresPro Enterprise, после окончания базовой подписки на техническую поддержку, вы не можете использовать ПО как вам хочется. Вы становитесь привязанными к тому оборудованию, на которое было установлено ПО (вспомним OEM лицензии от MicroSoft), и ваша бессрочная лицензия фактически превращается в лицензию по подписке. Этот факт выяснился через год после покупки, когда мы решили заменить серверы на более новые. Доступ к репозиторию уже был закрыт, так как закончился срок базовой техподдержки. Обращения в техническую поддержку не дали результатов: ответ сводился к предложению купить подписку на техническую поддержку или отказаться от использования ПО.

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

p.s. Если у администрации ресурса возникнут сомнения в правдивости этого поста, могу предоставить номера обращений и даже предоставить скрины ответов PostgresPro Enterprise.