Сервер у себя дома

В прошлой статье я описывал процесс настройки файлового сервера с доступом к файлам по SMB из любой точки, где есть интернет, через WireGuard. На тот момент система базировалась на мини ПК с док-станцией для подключения жёстких дисков. Использование док-станции, работающей через USB 3.2 Gen 1 ограничивало скорость работы с дисками значением 5 Гбит/с. На жёстких дисках Seagate Ironwolf ST4000VN006 мне получилось получилось намерить скорость 205 МБ/с, это совпадает с указанной в их характеристиках скоростью 202 МБ/с (1 616 Мбит/с). Таким образом, через док-станцию получится работать на максимальной скорости только с тремя дисками из четырёх. Поскольку в системе из прошлой статьи использовалось только два жёстких диска на 4 Тб под RAID 1, USB не ограничивал скорость, однако с того времени этого дискового пространства мне стало не хватать, что вызвало необходимость установить большее количество дисков. Правильным подходом будет использование современных SATA III интерфейсов, их скорость достигает 600 МБ/с, при этом для подключения диска обычно используется только один SATA разъём.

Наличие мини ПК, работающего 24 на 7 позволило мне развернуть свои пет-проекты без аренды VPS и попробовать различные self-hosted сервисы, такие как менеджер паролей Vaultwarden, собственное хранилище репозиториев git - Gitea, XMPP-сервер. Хочется продолжать их использовать и пробовать новые решения, поэтому теперь мои требования к домашним вычислительным мощностям повысились: нужно 8 Тб места на SMB шаре и возможность удобно разворачивать и управлять self-hosted решениями.

Поскольку теперь нужно помимо SMB разворачивать дополнительные сервисы, было решено использовать виртуальные машины. Структура один процесс - один сервер (ВМ) позволяет отделять сервисы друг от друга. С использованием сервера виртуальных машин можно реализовать такую структуру и гибко управлять ограничениями по ресурсам для каждого сервиса.

В этой статье я расскажу, как собирал и настраивал полноценный сервер виртуальных машин, близкий к корпоративным решениям. При проектировании был сделан акцент на чёткое разделение уровней доступа для пользователей из локальной сети, сети WireGuard и интернета; также было настроено бэкапирование данных, хранящихся на RAID, и конфигураций виртуальных машин.

Хард

Сервер собирается под хостинг виртуальных машин с небольшими решениями, и на момент составления конфигурации я ещё не знаю, что в конечном итоге мне потребуется хостить. Я решил исходить из расчёта 10 средних ВМ на 4 ГБ ОЗУ и 4 ядра и 10 маленьких ВМ 2 ГБ ОЗУ и 2 ядра. В сумме получается 60 ГБ ОЗУ и 60 ядер. Это не означает, что я ограничен только двадцатью виртуальными машинами. На сервере будет стоять Proxmox, поддерживающий механизмы overcommitment ядер и памяти, что позволит использовать незанятые ресурсы ВМ под новые машины.

Процессоров, имеющих 56 логических ядер, не много и цены даже на вторичном рынке довольно высокие. Для моих целей не критична частота работы процессора, поэтому меня заинтересовала возможность собрать двухпроцессорное решение. Если взять процессоры Intel Xeon e5 2680 v4 с частотой 2.4 ГГц, в каждом по 14 ядер и 28 потоков, то в итоге получается 56 логических ядер. Под такую систему я нашёл китайскую материнскую плату Atermiter X99 Dual с двумя сокетами LGA 2011-3 на чипсете Intel C612.

Плата является серверным решением, что определяет требования к оперативной памяти, обязательно наличие ECC. Это технология коррекции однобитовых ошибок в данных. Она повышает надёжность системы, из-за этого широко распространена в серверах. Сборка системы пришлась как раз на кризис оперативной памяти, что вызвало трудности в подборе нужных планок. Планки я покупал Б/У, поэтому пришлось установить планки от разных производителей с разной частотой. Сначала я купил неподходящие планки, в итоге через сервер прошло 4 разных модели RAM, результаты привожу в таблице:

Ошибкой было взять модуль памяти KSM26RS4/32MEI. На 32 ГБ RDIMM в конфигурации 1Rx4, получается плотность DRAM-чипов 16-Гбит, процессоры Intel Xeon e5 2680 v4 не поддерживают такую плотность. За время сборки мне пришлось поработать с несколькими видами памяти: UDIMM и RDIMM. UDIMM память самый распространённый вид оперативной памяти, чаще всего ставится в обычные компьютеры. RDIMM память - это регистровая память. Она отличается наличием специального чипа - регистра. В UDIMM памяти обращения процессора происходят напрямую к ячейкам памяти, а в RDIMM они проходят через регистр на планке. Регистр буферизует сигналы команд и адресов между контроллером памяти и чипами DRAM, снижая электрическую нагрузку на выходы контроллера памяти. Это позволяет поддерживать больше планок на канал и повышает стабильность. Сначала система работала на одной UDIMM планке. Модули UDIMM и RDIMM несовместимы и не могут работать в одной системе. Среди серверных ECC планок на вторичном рынке гораздо больше RDIMM планок, для упрощения дальнейшего увеличения количества планок было решено перейти на RDIMM планки. В итоге имеем 3 планки по 32 ГБ: Micron MTA36ASF4G72PZ-2G6D1QG и два модуля Samsung M393A4K40BB0-CPB0Q, всего 96 ГБ ОЗУ. Этого вполне достаточно для запуска нужного мне количества виртуальных машин.

У планок Samsung заявлена частота 2133 МГц, а у Micron 2666 МГц. При установке планок с разными частотами система будет работать на том профиле, который поддерживают все планки (обычно это частота самой медленной планки). У меня система запускается на 2400 МГц, это происходит из-за того, что модули Samsung умеют стабильно работать на этой частоте, хотя заявлена более низкая. При этом 2400 МГц это максимальная частота памяти, с которой могут работать Intel Xeon E5-2680v4.

Нормальную документацию по материнской плате мне найти не удалось, поэтому планки пришлось ставить наугад. В многопроцессорных системах используется архитектура NUMA (Non-Uniform Memory Access). Каждый процессор представляет собой NUMA узел. У узла есть локальная оперативная память (обычно ближайшая на плате к процессору). На Atermiter X99 Dual восемь слотов разделены на два участка по четыре, каждый является локальным для своего процессора. Если процессору не хватает локальной памяти, то он может обратиться к памяти другого узла по общей шине. При этом внутри узла память может работать в многоканальном режиме Intel Xeon E5-2680v4 поддерживает четыре канала.

Планки, стоящие в первых двух слотах и последних двух слотах каждого участка, на этой материнской плате относятся к одному каналу, получается четырёхканальный режим работы невозможен. Я попробовал установить планки через одну, чтобы была одна планка на первый канал и вторая на второй, даже получилось запуститься в двухканальном режиме. Однако после перезагрузки с той же конфигурацией запуститься не получилось с кодом 67. Я надеялся, что хотя бы получу преимущества NUMA архитектуры, но, вероятно, из-за несимметричных объёмов памяти на процессорах система не может сконфигурировать два NUMA узла и остаётся на одном:

Это означает, что любой доступ к памяти проходит через общую шину, что вносит задержки в обращения. Я пробовал менять настройки NUMA в BIOS и вставлять планки разными способами, но добиться работы NUMA или двухканального режима не смог. Основные версии: на плате есть ограничение по порядку заполнения слотов, для двухканального режима на каждом из процессоров нужны все восемь планок; для работы NUMA нужно одинаковое количество памяти на обоих узлах.

Я остался на таком расположении планок:

Красный - планки Samsung, Синий - Micron

Для расширения объёма хранилища я взял ещё 4 жёстких диска Seagate IronWolf ST4000VN006 по 4 Тб в дополнение к двум от прошлой сборки. В сумме получается 6 дисков на 6 SATA портов. Для дальнейшего расширения необходимо будет докупить HBA-карту (Host Bus Adapter) для подключения дисков к шине PCI-E. На рынке есть решения в виде разветвителей для SATA разъёмов но на такой материнской плате они могут работать только в режиме CBS (Command-Based Switching), т.е. параллельная работа с дисками невозможна. Для операционной системы и дисков самих виртуальных машин нужен быстрый NVMe SSD. Взял первый попавшийся Apacer AS2280P4U PRO на 1 Тб. Аналогично была взята дешёвая видеокарта Gt710, так как процессоры не имеют встроенной графики.

Поскольку планируется установка большого количества жёстких дисков, в качестве корпуса я выбрал полноценный серверный 4U ящик ExeGate Pro 4U660. На передней панели расположено 24 слота под 3,5-дюймовые диски. Он продавался с блоком питания на 1200 Вт в комплекте. Для моих целей этого более чем достаточно: мощных видеокарт пока не планируется, процессоры Xeon потребляют немного.

Важным аспектом при сборке серверов и организации их в стойки является грамотное охлаждение. В стандартах ANSI/TIA-942 по построению ЦОД описан метод холодных и горячих коридоров, который широко применяется на практике. Воздух заходит в серверную через холодный коридор, проходит через всё оборудование и уходит через горячий. Для получения максимальной эффективности охлаждения серверы проектируются следующим образом: на корпусе устанавливаются вентиляторы на вдув на передней панели и на выдув на задней. Внутри корпуса для отвода тепла от всех компонентов, в том числе процессоров и видеокарт, используются радиаторы, которые охлаждаются потоком воздуха из холодного коридора. Данная схема охлаждения совсем не подходит домашнему серверу. В условиях квартиры невозможно организовать холодные и горячие коридоры. Вдобавок к этому серверные вентиляторы даже для корпусов 4U имеют диаметр около 80 мм, для организации достаточного потока воздуха они вращаются на больших RPM, к тому же серверные платы редко поддерживают регулировку оборотов. Исходя из этого было принято решение установить на процессоры обычные башни Xilence M504D (которые еле поместились вдвоём), а на вдув и выдув первые попавшиеся 80-мм вентиляторы для обычных ПК - ID-COOLING NO Series. Как уже упоминалось, комплектующих с большим потреблением и, соответственно, нагревом нет, так что понижение эффективности охлаждения допустимо. Со штатными вентиляторами, которые шли в комплекте с корпусом, уровень шума около сервера был около 70 дБ; с новыми вентиляторами уровень шума рядом с сервером 30 дБ. Из соседних жилых комнат вообще не слышно, что меня устраивает.

Так должно быть:

Так есть:

Сборка не вызвала больших сложностей: чтобы подключить все вентиляторы, потребовалось два разветвителя; башни на процессоры встали впритык, но встали. К передней панели с дисками подключается питание от БП через molex (один разъём на два диска) и SATA к материнской плате на каждый диск. Мысленно я разделил переднюю панель сервера на две секции: основной массив и массив для бэкапов. В первом будет четыре диска с основным RAID массивом, а в нижнем два диска с RAID 0 под бэкапы. Светодиоды на передней панели удалось подключить без проблем по схеме.

Чтобы минимизировать время простоя сервера при перебоях с питанием нужно в BIOS поставить параметр PCH state after G3 в значение On. После этого при возобновлении питания система запустится автоматически. G3 - это обозначение для состояния системы без питания от сети. Таким образом, G0 - рабочее состояние; G1 - сон; G2 - выключен, но может быть запущен через Wake On Lan.

В итоге был собран сервер со следующими характеристиками: 96 ГБ ОЗУ на 2400 МГц, 28 (56) ядер процессора по 2,4 ГГц, 1 Тб SSD, 24 Тб HDD на комплектующих:

Софт

В качестве операционной системы под виртуальные машины был выбран знакомый мне с работы Proxmox. Это решение с открытым исходным кодом на базе Debian. Позволяет управлять виртуальными машинами, бэкапами (и любыми кастомными джобами) через веб интерфейс. Proxmox VE использует гипервизоры KVM и LXC и предоставляет к ним API с интерфейсом. Поддерживает полноценную виртуализацию (KVM) и контейнерную (LXC). При настройке виртуальных машин я предпочёл использовать KVM для большей изоляции.

Процесс установки происходит так же, как и у обычных операционных систем: образ записывается на флешку и производится загрузка с него. Конкретно с образом Proxmox есть проблема: Rufus не может правильно записать образ. Я использовал утилиту dd: sudo dd if=./proxmox-ve_9.1-1.iso of=/dev/sdd bs=4M status=progress. При самой установке у меня возникла проблема с драйверами для видео. Пришлось добавить параметр для пропуска загрузки этих драйверов - nomodeset в команду бута, которая доступна при нажатии клавиши "e" на моменте выбора вида установки Proxmox.

После конфигурации пароля администратора Proxmox готов к использованию. Первоочерёдной задачей является создание виртуальной машины под файл-сервер. По моим наблюдениям SMB при нагрузке спокойно может использовать всю оперативную память виртуалки, поэтому машине я выделил 32 ГБ и 4 ядра, хотя на процессор нагрузка получается не сильная, можно выделить и меньше ядер. Настройка сервера выполняется аналогично с предыдущей статьёй.

Так как сейчас количество дисков выросло снова разворачивать RAID 1 нет смысла. Нужен другой вид RAID, позволяющий увеличить доступное дисковое пространство. Также важным фактором является скорость чтения и записи. Планируется подключать SMB шару ко многим виртуальным машинам, поэтому нужна максимальная скорость работы с дисками. В сервере 6 дисков, 2 нужно оставить под бэкапы, получается 4 диска на основной массив. Для выбора была составлена сравнительная таблица:

По ёмкости требованиям соответствуют: RAID 0, RAID 10, RAID 5, RAID 6. По скорости чтения/записи: RAID 1, RAID 0, RAID 10. RAID 0 не рассматривается, так как не предоставляет защиты от выхода из строя дисков. В итоге для достижения поставленных целей был выбран RAID 10.

В прошлой статье упоминалась необходимость использования специализированной файловой системы под RAID. Тогда для упрощения процесса я использовал ext4. Сейчас же я установил ZFS. Эта файловая система поддерживает self-healing за счёт хранения контрольных сумм файлов (схоже с механизмами RAID 5, RAID 6). Под метаданные файловой системы (контрольные суммы, ZFS IntentLog и пр.) из 8 Тб собранного массива ушло около 200 ГБ. Первичная синхронизация дисков заняла больше дня. После неё массив можно вводить в эксплуатацию.

Поскольку планируется использовать SMB шару на нескольких серверах и для личных целей, нужно настроить политики доступа к файлам на шаре. Каждый сервер - отдельный SMB-пользователь. В конфигурационном файле SMB для каждой директории прописываются пользователи, у которых есть доступ к конкретной директории. SMB-пользователи базируются на пользователях операционной системы, это может вызвать проблемы с доступом. Я пришёл к следующему решению: на файл-сервере создаётся группа под всех пользователей SMB в системе. Права на работу со всеми файлами на массиве выдаются этой группе. Организацией доступа через шару занимается сервис SMB. В этом случае важно исключить возможность входа пользователей SMB в систему, чтобы они не могли при помощи удаленного доступа к системе получить доступ к чужим файлам. Это реализуется через указание специального shell для пользователя: /usr/sbin/nologin.

Каждая виртуальная машина имеет свой адрес в сети. На данный момент на сервере работает 16 виртуальных машин, тесно взаимодействующих с друг другом.

Где возможно использовалось развёртывание сервисов без Docker. Поскольку сервисы и так изолированы виртуальными машинами тратить вычислительные ресурсы на работу Docker на каждой машине излишне.

Часть сервисов должна быть доступна из интернета, ещё часть через WireGuard туннель. На данный момент у меня нет статического IP-адреса от оператора, поэтому любые запросы извне локальной сети проходят через VPS. У него есть статический IP, в прошлой статье он использовался для хостинга wg-easy и организации туннеля. В текущей системе он также обеспечивает работу туннеля. На самом сервере к туннелю подключены ВМ wireguard и gateway. Первая производит перенаправление трафика на некоторые сервисы, которые должны быть доступны из WireGuard. Для HTTP трафика используется nginx, для отдельных портов iptables. Изначально для трансляции портов я использовал socat, но позже перешёл на iptables, так как он более производителен за счёт работы только с сетевым и транспортным уровнями модели OSI. Таким образом, если проброс какого-то сервиса не настроен на машине wireguard, пользователь из туннеля не сможет получить доступ к сервису. Аналогичная схема работает для gateway: трафик с VPS полностью переадресуется на него. На нём стоит nginx для управления проксированием и сертификатами. Если на gateway не настроено проксирование запросов на сервис, то он не доступен из интернета. Таким образом обеспечивается политика белых списков для доступа из туннеля и интернета: запрещено всё, что не разрешено.

Теперь схема из прошлой статьи выглядит следующим образом:

Красным показан путь трафика при запросе к файл-серверу из WireGuard (используется адрес управляющей трафиком машины 10.8.0.15), синим - путь при запросе веб интерфейса Gitea по адресу git.serafimdev.com

Бэкапы

Proxmox предоставляет удобный инструментарий для бэкапирования конфигураций виртуальных машин. Через интерфейс настраивается джоба ежедневных бэкапов. Бэкапы складываются на ту же самую шару, которая без проблем добавляется через интерфейс. Для предотвращения переполнения хранилища настраиваются параметры retention для удаления старых бэкапов. Жёсткие диски с RAID исключены из бэкапов, так как будут бэкапироваться отдельно.

Использование RAID с дублированием данных не является бэкапом, так как RAID подвержен ошибкам в функционировании софта и не защищает от случайного удаления файлов. Нужно организовать полноценное бэкапирование всего массива на 8 Тб данных. Бэкапы будут храниться на отдельном массиве RAID 0, собранном на file-server. Для создания резервных копий используется rsnapshot он делает версионированные бэкапы через hard links. То есть в каждой новой версии бэкапа сохраняются только изменённые файлы, остальные файлы являются ссылками на версии из предыдущей версии. Инструмент поддерживает настройку политик retention для предотвращения переполнения дисков.

Бэкапы ставятся на cron, а политики retention применяются при создании нового бэкапа.

Так как объём данных большой особое внимание уделено оптимизации. В конфигурации /etc/rsnapshot.conf включён link_dest, который заставляет rsnapshot использовать rsync --link-dest, обновляя только изменившиеся файлы. Для ускорения удаления старых snapshot включён use_lazy_deletes, чтобы процесс удаления не блокировал весь бэкап и не создавал лишнюю нагрузку на диски. В конфиг добавлены параметры rsync (--numeric-ids, --delete, --delete-excluded, --partial) для уменьшения лишних операций и обеспечения корректного докачивания больших файлов без повторного копирования. Для /mnt/storage и /mnt/backup в fstab добавлены параметры noatime, чтобы чтение файлов не генерировало лишние записи на диски в виде меток времени доступа.

Вывод

Вместо старого решения был собран полноценный сервер виртуальных машин на серверных комплектующих. Итоговая конфигурация: 96 ГБ ОЗУ на 2400 МГц, 28 (56) ядер процессора по 2,4 ГГц, 1 Тб SSD, 24 Тб HDD. Успешно установлен Proxmox и поднята домашняя инфраструктура на виртуальных машинах. Настроены политики доступа из WireGuard и интернета. Система способна перезапускаться без ошибок при отключении питания и предоставляет доступ к RAID 10 по SMB. По сравнению с предыдущим решением скорости работы с шарой получились следующими:

В локальной сети утилизация канала выросла с 79,2% до 88% это может быть либо погрешностью (измерение скорости записи не самый надёжный инструмент), либо результатом увеличения количества оперативной памяти с 16 ГБ до 32 ГБ. Замеры с нормальным интернетом в первой статье были проведены неверно: использовался компьютер в локальной сети с NAS. Хоть работа и велась по адресу NAS в WireGuard, вероятно, трафик ходил через локальную сеть. На плохом мобильном интернете скорость передачи такая же, как и на прошлом решении, при этом мобильный интернет в этот раз ловил лучше. Видимо есть некое ограничение передачи в нестабильных сетях, в которое я упёрся в обоих случаях. Несмотря на усложнение системы: теперь используется RAID 10, а не RAID 1; добавился промежуточный узел - ВМ WireGuard для контроля трафика. Получилось добиться не ухудшения скоростей работы.

Конфигурации виртуальных машин бэкапируются на основной массив. При этом основной RAID 10 бэкапируется на RAID 0 с использованием жёстких ссылок.

Дальнейшие пути улучшения инфраструктуры:

• Получение статического IP и перенос wg-easy на виртуальную машину. При этом VPS следует оставить, чтобы не допустить утечки IP-адреса сервера
• Запуск DNS сервера
• Развёртывание новых сервисов на существующей инфраструктуре
• Увеличение объёма ОЗУ, достижение корректного разделения процессоров на NUMA узлы и многоканальности
• Увеличение объёма хранилища путём установки дополнительных HDD и HBA модуля
• Организация автоматических бэкапов на устройство в другой географической локации