Оптимизация хранения данных

Предыстория

Есть сервер используемый для веб разработки. На сервере различные конфигурации сайтов (версии PHP, MySQL, Apache и т.д.) настроены в виде контейнеров OpenVZ. Для комфортной работы его наиболее востребованные ресурсы (исходники и базы данных) хранятся на SSD (Intel DC S3500 480G в RAID1), а прочие данные на HDD (обычные SATA диски в RAID1). Посредством LVM хранилище на SSD разбито примерно пополам между исходниками и OpenVZ (основной объем - базы данных).

С некоторых пор в исходниках стало недоставать свободного места. Приходится просить разработчиков убирать ненужные исходники или архивировать давно неиспользуемые. Поскольку atime отключен, то трудно сказать наверняка когда пользовались этими данными, можно ли их архивировать и нужны ли они вообще. Кое-как это работало в самом начале, но позже народ "устал" и делать отказывается под разными предлогами. Я их не виню :)

Поиск решения

Несмотря на внушительный общий объем исходников (около 180G) объем "горячих" данных невелик - 10-30G. С этими данными разработчики работают в данный момент и именно к ним нужно обеспечить быстрый доступ на чтение/запись. Остальной объем данных считается "холодным" и он может потребоваться спустя пару дней, недель или не потребоваться вовсе. Тут предсказать трудно.

Поскольку экстенсивный рост (докупить еще SSD дисков) довольно дорог (сейчас два дополнительных SSD класса Intel DC S3500 на 480G стоят примерно 900$), то я пробую пойти интенсивным путем и оптимизировать использование уже установленных.

Мне нужно ускорить массив обычных SATA дисков через использование SSD. По предварительной прикидке под эту задачу подойдут:

• Flashcache
• EnhanceIO
• dm-cache
• bcache
• Btier

Года два назад у меня уже был опыт использования FlashCache в режиме writeback. Понравилось, что он может быть использован поверх устройства с данными (cache backend) без предварительной подготовки этого устройства. В режиме writeback (на ssd кешируется и запись и чтение) позволяет сохранять состояние кеша между перезагрузками.

EnhanceIO является "улучшенной" версией Flashcache и использует его наработки. Что конкретно там улучшили я пока не разбирался.

Про dm-cache я слышал, но использовать не доводилось. Знаю только, что он требует форматирования cache backend перед использованием.

Аналогично bcache - только слышал, но пользоваться не доводилось.

Btier к кешированию не имеет никакого отношения. Это tiered storage который самостоятельно балансирует данные между разными бэкендами (ssd, sata, iscsi, etc) в зависимости от их использования.

Flashcache, EnhanceIO, dm-cache, bcache - это все варианты реализации кеширования записи на hdd через ssd. Они отличаются деталями реализации, но суть работы у них одна. А вот btier это интересный вариант. Он позволяет создать многоуровневую схему хранения данных значительного объема и автоматически мигрировать данные между уровнями в зависимости от их использования. Попробую для начала его, а дальше будет видно.

Munin-node на Arduino

Написал реализацию munin-node для Arduino. Для подключения к сети используется Ethernet shield. Сейчас мониторится относительная влажность и температура, но в планах добавить датчик CO₂ и переписать на esp8266. В идеале хочется отказаться от Arduino вообще и использовать только ESP8266 с батарейным питанием.

Вначале было два датчика: DHT11 и DHT22, но их показания по части влажности отличались почти на 10%. Чтобы набрать кворум добавил еще 3 датчика DHT22. Теперь два старых датчика показывают похожие значения, а три новых почти не отличаются в показаниях между собой, но не совпадают с двумя старыми примерно на 10%.

Относительная влажность

Температура

Считается, что комфортный уровень влажности для человека это 40-60%. До включения отопления было 40-50%.

Собрал Midnight Commander под ARM

В виде эксперимента собрал последнюю стабильную версию Midnight Commander (4.8.15) в своем репозитарии под ARM. В итоге получилось так:

• Debian Wheezy (i386, amd64, armel, armhf)
• Debian Jessie (i386, amd64, armel, armhf, arm64)
• Debian Stretch (i386, amd64)
• Debian Sid (i386, amd64)
• Ubuntu Precise (i386, amd64, armel, armhf)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Vivid (i386, amd64)
• Ubuntu Wily (i386, amd64)

Любопытно насколько это востребовано и под какие железки.

Обратная сборка пакета tvheadend

Вчера вечером ставил обновления на домашнем сервере и не заметил обновление tvheadend. Был tvheadend 3.4.27, а обновился до 4.0.8. В итоге отвалилась настройка всех каналов в IPTV. Новая версия здорово отличается от старой и разбираться с ней нет никакого желания. У меня уже есть набор скриптов tvheadend-iptv-damavik, который делает всю черную работу.

Чтобы решить проблему малой кровью нужно установить старую версию пакета и заново импортировать настройки каналов и EPG. Полез в /var/cache/apt/archives - есть только новая версия. Собрался поискать пакет в бэкапе bacula, но вспомнил, что /var/cache/apt/archives исключен из бэкапа. В репозитарии tvheadend нужный пакет тоже недоступен, а поиск в гугле по названию пакета дает только ссылки на apt.tvheadend.org.

Хоть сам пакет и исключен из бэкапа, но ведь содержимое пакета в бэкапе есть. Нужно только извлечь нужные файлы, метаданные пакета и собрать пакет обратно. Сначала восстанавливаем метаданные - для этого выбираю восстановление бэкапа сервера, предшествующего дате 2015-12-19 00:00:00 и восстанавливаю директорию /var/lib/dpkg. Восстановленные данные будут находиться в /bacula/restore/.

Создаю директорию /root/tvheadend_3.4.27~gfbda802~wheezy_amd64 - сюда будут складываться нужные файлы пакета. Из бэкапа мне нужен /bacula/restore/var/lib/dpkg/info/tvheadend.list - тут описано содержимое пакета, которое мне нужно дополнительно восстановить из бэкапа. В сумме нужно восстановить следующие файлы и директории:

• /usr/share/tvheadend/
• /usr/share/doc/tvheadend/
• /usr/share/man/tvheadend.1.gz
• /etc/default/tvheadend
• /etc/init.d/tvheadend
• /etc/init/tvheadend.conf
• /usr/bin/tvheadend

Восстановленные файлы перемещаем в /root/tvheadend_3.4.27~gfbda802~wheezy_amd64. Данные пакета готовы, теперь очередь метаданных.

Создаем директорию /root/tvheadend_3.4.27~gfbda802~wheezy_amd64/DEBIAN/. Восстановленные файлы метаданных /bacula/restore/var/lib/dpkg/info/tvheadend.* перемещаем в /root/tvheadend_3.4.27~gfbda802~wheezy_amd64/DEBIAN и переименовываем чтобы убрать префикс tvheadend. из имени файла (tvheadend.md5sums -> md5sums, tvheadend.postinst -> postinst, и т.д.).

Для окончательной сборки пакета не хватает только файла DEBIAN/control - его содержимое можно взять в var/lib/dpkg/status.

Теперь собираем пакет

cd /root/tvheadend_3.4.27~gfbda802~wheezy_amd64
dpkg-deb -b . ../tvheadend_3.4.27~gfbda802~wheezy_amd64.deb
dpkg -i ../tvheadend_3.4.27~gfbda802~wheezy_amd64.deb

Осталось восстановить из бэкапа /home/hts/.hts/ и перезапустить tvheadend.

UPDATE: В комментарии напомнили, что недостает шага по фиксированию версии пакета. Можно либо через dpkg selections:

echo tvheadend hold | sudo dpkg --set-selections

либо через aptitude

sudo aptitude hold tvheadend

Или можно пошаманить с apt pinning.

Найти все пакеты, зависящие от ALSA, но не зависящие от PulseAudio

Найти все пакеты в системе, которые зависят от ALSA (пакет libasound2), но не зависящих от pulseaudio (пакет libpulse0)

$ awk -F: '/^(Package|Depends):/ {if ($1 ~ /^Package/) pkg=$2; if ($1 ~ /^Depends/ && $0 ~ /libasound2/ && $0 !~ /libpulse0/) print pkg}' /var/lib/dpkg/status
 gstreamer0.10-alsa
 iceweasel
 mencoder
 apulse
 libportaudio2
 audacity
 libcanberra0
 vlc-nox
 libflite1
 libsox-fmt-alsa
 libasound2
 recordmydesktop
 libwine-development
 alsa-utils
 chromium
 rdesktop
 openjdk-7-jre
 libkcompactdisc4
 libmlt6
 teamviewer5

В части пакетов функциональность pulseaudio реализуется плагинами (например vlc или gstreamer), но с чего начать уже видно.

NCQ в Linux как возможная причина медленной работы дисков

На этой неделе собирал php 5.5.30 для Debian Jessie и часто пользовался pbuilder. В какой-то момент заметил, что pbuilder слишком долго распаковывает пакеты в chroot. Проверил работу дискового массива через iostat - один из дисков зеркального RAID был занят на 10-20%, а второй на 100%. В сервере установлены два одинаковых диска TOSHIBA DT01ACA300 на 3Tb:

$ sudo hdparm -i /dev/sd{a,b}
/dev/sda:

 Model=TOSHIBA DT01ACA300, FwRev=MX6OABB0, SerialNo=Z3GHLUVGS
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode


/dev/sdb:

 Model=TOSHIBA DT01ACA300, FwRev=MX6OABB0, SerialNo=X2S0833WS
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=5860533168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

Из двух дисков собран RAID1 в mdadm, а уровнем выше находится LVM.

Создал тестовый том /dev/VolGroup0/test и натравил на него fio со следующим конфигом:

[randwrite]
blocksize=4k
filename=/dev/VolGroup0/test
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32

Замеры показали около 10-30 iops, хотя должно быть 100 и более. Попробовал переключить IO scheduler на noop:

$ echo noop | sudo tee /sys/block/sda/queue/scheduler
$ echo noop | sudo tee /sys/block/sdb/queue/scheduler

Никакой разницы. А потом выключил ncq:

$ sudo hdparm -Q1 /dev/sd{a,b}

/dev/sda:
 setting queue_depth to 1
 queue_depth   =  1

/dev/sdb:
 setting queue_depth to 1
 queue_depth   =  1

После этого iops в fio стал стабильно выше 100. Для наглядности включил ncq обратно и iops через несколько секунд iops "испортился". Пока выключил, а дальше видно будет.

Trusted/Untrusted X11 форвардинг через SSH в Debian

Если вы пользуетесь trusted/untrusted форвардингом X11 через SSH в Debian, то вам стоит помнить, что в Debian оно ведет себя не так, как принято в апстриме.

-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.

X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the
user's X authorization database) can access the local X11 display
through the forwarded connection. An attacker may then be able
to perform activities such as keystroke monitoring.

For this reason, X11 forwarding is subjected to X11 SECURITY
extension restrictions by default. Please refer to the ssh -Y
option and the ForwardX11Trusted directive in ssh_config(5) for
more information.

Т.е. без явного кручения "ручки" всегда используется trusted режим. Чтобы вернуть привычное поведение нужно задать ForwardX11Trusted=no в ~/.ssh/config или /etc/ssh/ssh_config.

Для справки: в untrusted режиме X11 клиент не имеет доступа к содержимому чужих окон и не может инжектить события клавиатуры/мыши.