Начал активнее использовать SSD.

Ну, прежде всего – мне давно уже перестало хватать места на ноутбуке. Некоторое время спасался тем, что использовал компактную SATA SSD на 500 ГБ, размещенную вместе с m.2 – она периодически отваливалась, а некоторое время назад умерла окончательно. Хотя еще до ее смерти место под блокчейны закончилось и я начал использовать prune у bitcoind.

На замену расковырял Patriot Flare на 60 ГБ, оставшийся от майнинг-ригов – единственный бывший у меня компактный вариант. Но 60 ГБ – так себе “замена”. Использовал под какие-то кэши; все остальное – на основном NVMe на 1 ТБ, а prune “зажал” по-максимуму.

В итоге понял, что пришло время что-то менять и пора обновлять диск. Выбор пал на Samsung SSD 980 PRO 2TB. С учетом того, что ноутбук далеко не новый и быстрой pci-e там нет, то предельные скорости интересовали мало и данная модель была хорошим выбором с заделом на будущее – и за относительно небольшие деньги: когда-то (примерно 5 лет назад) в 2 раза дороже покупал заменяемый сейчас диск на 1 ТБ.

Диск приехал, всунул его и старый в какую-то материнку от ригов, где нашлась возможность вставить m.2 напрямую и через переходник в pci-e-слот. Пришлось развернуть под задачу новую систему, ибо других вариантов под рукой на тот момент не оказалось. Побитно скопировал диски – получалось на скорости около 700 МБ/сек. Дальше – удаление / создание заново последнего раздела; pvresize; lvresize. Линейная скорость через hdparm – около 2 ГБ/сек – в принципе, как и на старом.

Освободившийся диск решил использовать в домашнем сервере. Однако это было позже, а на волне работ с SSD решил использовать имеющиеся SSD для ускорения NAS’а. Сначала использовал еще один Patriot Flare для размещения кэша motion – тысячи jpeg’ов, которые писались на диск при появлении движения и каждый час перечитывались, чтобы склеиться в timelapse-видео. Использование SSD ощутимо ускорило этот процесс.

Еще одной проблемой была неправильная разбивка – я выделил под корень около 5 ГБ и поначалу этого хватало. Однако по мере обновления системы между релизами, а также навешивания новых функций на NAS (то же видеонаблюдение) место стало заканчиваться. Основная проблема вылезла из-за логов – иногда они разрастались очень быстро и свободного места не оставалось вообще, что приводило к подвисанию motioneye, росту LA и ОЧЕНЬ долгому заходу на сервер.  Поэтому вторым элементом, вынесенным на SSD, был каталог с логами.

Однако диск был без резервирования и решение было довольно костыльным, хотя и помогло. Поэтому решил двигаться дальше и сделать правильно: использовал через pci-e/m.2-переходник SSD на 256 ГБ, который шел изначально с моим ноутбуком и все эти годы лежал практически без дела. Сделал на нем раздел под /boot, раздел в размер Patriot Flare и 3-й раздел на оставшемся месте. По факту сейчас используется только 2-й раздел в зеркале Patriot Flare. Скорость у NVMe вышла совсем невысокая – около 600-700 МБ/сек, но все же быстрее, чем у SATA-диска (там вообще около 250 МБ/с), поэтому для SATA у RAID’а поставил флаги writemostly – использовать его только для записи, если возможно, а все чтение делать с NVMe.

В итоге имею быстрый RAID на SSD, где создал 2 раздела – под корень (теперь уже нормального размера) + под кэш для motion’а. NAS – а, в частности, логин на него и базовые операции – зашевелился явно шустрее.

Что касается сервера – сначала поставил освободившийся терабайтник с ноута в него. Не сказать, что там позарез был необходим SSD-диск, но чего железу зря простаивать? Терабайтник провалялся бы несколько лет так же, как и 256-ка без какой-либо пользы, а так – можно было бы убрать один из дисков, а второй поставить в режим writemostly. У одного из дисков, кстати, наработка была уже 66351 час – т.е., 7,5 лет :).

Честно говоря, пока не знаю, куда применить старое железо. Есть уже несколько таких дисков – 1 ТБ на 7200 оборотов. Есть несколько miniITX-материнок на AMD C60, купленных за бесценок. Одна даже в корпусе стоит. Плееров в хозяйстве хватает. Какие-то miniNAS делать? Вроде достаточно основного. Плюс лежит переделанный примитивный NAS-карман – туда тоже засунул диск на 1 ТБ, но так это все и не начал использовать. Может в будущем появятся какие-то идеи…

Так вот, поставил SSD в сервер (на материнке штатно есть m.2 pci-e), завел в RAID – практически без проблем. Практически – так как выяснилось, что SSD-то не на 1 ТБ, а только 960 ГБ. Так как я практикую обычно нарезку диска на разделы, объединение разделов в RAID, а уже RAID’ы добавляю в PV, то гладко получилось смигрировать почти все, кроме последнего раздела – тот не вмещался на новый диск. Однако раздел на нем не занимал все пространство, поэтому на SSD создал новый RAID, добавил его в PV, сделал pvmove на старый массив и потом смог вывести его из VG, удалить PV и остановить старый RAID. Далее – добавил этот раздел уже к новому RAID’у для сохранения отказоустойчивости.

Примерно тогда же уже решил: гулять – так гулять. Заказал еще один SSD на 1 ТБ – Samsung SSD 980 1TB. Подобный тому, что купил для ноута, но не Pro и на 1 ТБ, поэтому ощутимо дешевле. У меня еще оставался один переходник pci-e 16x -> m.2, поэтому второй SSD планировал подключить через него. По высоте переходник как раз умещался в miniITX-корпусе. Диск приехал, выбрал момент, погасил сервер с мыслью “сейчас поставлю RAID мигрироваться за 5 минут и пойду заниматься своими делами”, и…

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

Я не знаю, какой магией все грузилось до этого. Все (в частности – установка системы и то, что касается загрузчиков и загрузки) делалось лет 5 назад. Какое-то время не обновлял – была проблема с более новыми ядрами, из-за чего на сервере переставала работать сетевая карта. Заметку в блоге тогда так и не написал. Не так давно обновил (наверное, уже через релиз относительно того, где была проблема) – сейчас все работает без проблем на Debian 11. Сервер нормально проходил через перезагрузки при длительных отключениях света. Но что именно изменилось при выводе старого диска из RAID’а я так и не знаю.

При запуске получил сообщение о том, что не может найти файл /grub/x86_64-efi/normal.mod, после чего попадал в recovery console GRUB’а. Где файл был раньше и куда делся – не ясно. Спешно начал выискивать какие-нибудь загрузочные диски; команды GRUB’а не помнил от слова “совсем”. Сервер лежит, интернета нет. Диск для возможности загрузки сервера нашел. Да, файла не было. Скопировал с ноута и перенес на флешке, но это особо не помогло. Уже сложно сказать сейчас, на какой пробе был какой результат – возможно, после копирования файла при загрузке попадал уже в другую консоль GRUB’а. Команд, как уже сказал, не помнил совсем. Организовал на ноуте хоть какой-то интернет через мобилку, сфотографировал мануалы по GRUB’у, начал пробовать как-то загрузить систему на сервере. Про Xen речь еще даже не шла. В итоге, бегая то к ноуту, то в подвал к серверу, кое-как запустил систему – стоит отметить еще, что EFI-раздел отдельно, а /boot, куда монтируется этот EFI-раздел – отдельно и на RAID’е, так что запускал уже “хоть как-то”. Без штатных опций ядра сеть не поднималась, скрипт iptables’а выдавал кучу ругани и блочил все подряд. В итоге уже через время более-менее бодро поднимал систему и сеть для возможности захода с ноута.

Проблема с загрузкой так и оставалась непонятной. Указанный файл был из пакета grub-efi-amd64-bin. GRUB’а в системе не было вообще. Как все грузилось раньше – непонятно. Интернета на сервере не было, поставить пакеты напрямую нельзя. Скачал их на ноуте, скопировал на сервер, поставил. Ребут – встречает только консоль GRUB’а. Исходя из того, что раньше ж как-то все работало, начал копать в сторону EFI-загрузки. Начал немного осваиваться с efibootmgr, управлял последовательностями загрузки, добавлял и убирал опции. Ничего. Если в efibootmgr было несколько опций – различные диски, старт основной системы и, в том числе, старт dom0, то в BIOS’е минимальный вариант у меня был только EFI OS, без Xen’а. Который давал мне в итоге только консоль GRUB’а – или ругань на отсутствующий файл в том случае, если я сносил пакет GRUB’а. Как он на него ссылается – я так и не понял. Все, что можно было переустановить касательно загрузки – переустанавливал несколько раз.

Согласно мануалу, загрузка Xen’а должна была идти напрямую, но этого не происходило. Продолбавшись какое-то время и брутфорся все приходящие в голову способы, решил двигаться в сторону второго способа – GRUB с chainload. Вернул обратно те пакеты, что ставил, снова получил консоль загрузчика, но в итоге понял, что надо бы создать ему конфиг-файл. Пример конфиг файла есть по указанной ссылке. Косяк возник лишь с тем, что надо было добавить опции set timeout=1 для автовхода, плюс добавить set root=(hd0,gpt1). Плюс добавить boot после chainloader’а. Плюс карта устройств из системы (сгенерированная командой grub-mkdevicemap и та, что была актуальна во время работы GRUB’а, отличались. Все это делалось методом проб и ошибок, но у меня хотя бы стало выходить запустить систему нормально. Итоговый файл /boot/grub/grub.cfg выглядит так:

set timeout=1
menuentry "XEN EFI" {
insmod part_gpt
insmod search_fs_uuid
insmod chain
set root=(hd0,gpt1)
chainloader (hd0,gpt1)/EFI/xen/xen.efi
boot
}

При этом все равно проскакивает какая-то ошибка, но дальше происходит загрузка. Те же команды (вроде даже без set root), введенные вручную в консоли, ошибок не вызывали и загрузка проходила гладко.

Честно говоря, так и не знаю, что именно поменялось. Возможно, материнка как-то по-особому работает с SATA-дисками и с NVMe и с последними не может нормально общаться. Почему не проходила прямая загрузка Xen-образа – тоже непонятно. Возможно, косяк EFI. Но в итоге к ночи и с chainloader’ом в GRUB’е я таки получил свою систему обратно. Уже когда закончил с софтовой частью, поснимал все старые диски для лучшей вентиляции. Сейчас на сервере нет подвижных частей совсем.

По дискам. Kingston более горячий, плюс так вышло, что размещен возле радиатора процессора (мне уже не хотелось заниматься еще и этим, так что оставил так, как было изначально). При синхронизации RAID’а температура росла до совсем уж неприличных значений – порядка 90 градусов у него и 70 у Самсунга. При обычной работе это 42 и 38 соответственно. Но решил заказать радиаторы под m.2-диски на Али. Приедут – поставлю.

По скорости.

hdparm --direct -tT /dev/nvme?n1

/dev/nvme0n1:
Timing O_DIRECT cached reads: 1284 MB in 1.99 seconds = 646.43 MB/sec
Timing O_DIRECT disk reads: 1836 MB in 3.00 seconds = 611.46 MB/sec

/dev/nvme1n1:
Timing O_DIRECT cached reads: 690 MB in 2.00 seconds = 345.67 MB/sec
Timing O_DIRECT disk reads: 1044 MB in 3.00 seconds = 347.91 MB/sec

Первый – Kingston в m.2 , второй – Samsung в переходнике в pci-e-слоте. Скорости сильно ниже возможностей дисков, так что остается только шина. Почему такая разница – непонятно. Но в итоге более медленный диск поставил в writemostly-режим командой

for i in /sys/block/md*/md/dev-nvme1n1p?/state ; do echo writemostly > $i ; done

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

Из оставшихся и выявленных проблем – сейчас (после обновления до Debian 11) не восстанавливаются domU. Благо, критичных сервисов сейчас дома не работает и это не так важно, но с проблемой надо будет разобраться.

И надо наконец-то разобраться с стартом сетевых интерфейсов.

Mini-update:

• Поставил приехавший с Aliexpress радиатор на Kingston. Температура не особо поменялась, но диск в режиме write mostly, поэтому он особо и не работает. Во время бэкапа температура растет до 45 градусов, в простое около 40. Показательно будет в первое воскресенье месяца, когда идет проверка RAID’а. Ждем.
• А вот на NAS’е с диском на 256 ГБ разница заметна хорошо: было 60 градусов, стало около 45.
• Внезапно обнаружил, что с играми с загрузчиком потерялся параметр dom0_mem. В итоге для Dom0 выделялось около 4 ГБ памяти и под все domU уже не хватало. В итоге фейлился запуск, например, mysql. Запихнул параметр во все конфиги обратно (в частности, /etc/default/grub.d/xen.cfg), но не уверен, что оно все правильно теперь работает. В общем, при следующей перезагрузке надо будет не забыть все проверить.