All-In-One: Proxmox + OpenMediaVault или ещё одна идея для домашнего NAS / forpes.ru

Главная
All-In-One: Proxmox + OpenMediaVault или ещё одна идея для домашнего NAS

All-In-One: Proxmox + OpenMediaVault или ещё одна идея для домашнего NAS +18

06.05.2017 13:46

kvaps 47 8600 Источник

Астрологи объявили месяц статей о домашних NAS на Хабре, так что поделюсь и своей историей успеха...

Не так давно я попробовал новый FreeNAS Coral. Понравилось мне в нем если не все, то очень многое: это и новый гипервизор bhyve, и повсеместное использование 9P для проброса файловой системы на гостя, а так же идея с docker и многое другое.

Кроме того я ещё больше влюбился в ZFS со всеми её плюшками, такими как дедупликация и сжатие на лету.

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

В статье так же будет немного рассказано про Docker и автоматический прокси с автоматическим получением сертификатов Letsencrypt.

Для начала расскажу что же мне все таки не понравилось в FreeNAS Corral:

Не готов для production. (недавно этот релиз вообще отозвали)
Работа с docker удобна только в случае единичных контейнеров, в случае когда контейнеров много управление через веб-морду становится крайне неэффективным.
Контейнеры запускаются внутри виртуальных машин с Linux, а порты проксируются через хост, что в принципе не плохо, но подразумевает некий оверхед в сравнении если бы они запускались прямо на хосте.
Гипервизор bhyve пока не поддерживает live-snapshots.
Нет возможности создавать виртуальные машины не из шаблонов. (по крайней мере в GUI)
Система установленая на флешку ужасно тормозила.

В принципе со всем этим можно было бы жить, но как я говорил флешка с системой сдохла и теперь у меня есть новые идеи:

Систему нужно устанавливать на жёсткий диск, пусть даже самый простой, но на диск, а не на флешку.
Идея с установленной системы отдельно от данных хороша, но сколько я флешек не перепробовал (включая USB 3.0) всё равно работает очень плохо и безбожно тормозит. Так что ставить будем на отдельный HDD.
ZFS в качестве основанной файловой системы. ZFS позволяет не думать как мне распределять ресурсы хранилища между файловыми системами и виртуальными машинами, она поддерживает моментальные снимки (снапшоты), дедупликацию и сжатие на лету, а также известный RAIDZ.
Proxmox в качестве системы управления виртуализацией. Здесь есть все что необходимо: это поддержка как полной так и контейнерный виртуализации, снапшоты, автоматические бекапы и многое другое, а главное ZFS тут предлагается по умолчанию и работает прямо из коробки.
Proxmox целиком и полностью управляется через современный веб-интерфейс на ExtJS:

Proxmox так-же позволяет подключаться к консоли виртуальной машины через веб-интерфейс:

для этого используется HTML5 клиент noVNC

OpenMediaVault в качестве системы управления хранилищем.

При выборе хранилища основным критерием была поддержка ZFS и работа на linux, а не на FreeBSD т.к. его хотелось установить на хостовую систему вместе с Proxmox а не на отдельную виртуальную машину.

Я рассматривал несколько софтин на эту роль, пробовал даже openATTIC — к сожалению поддержка ZFS там оказалась довольно слаба и на данный момент многих опций там просто нет, хотя я уверен что с CEPH дело предстоит несколько иначе.

В поисках я наткнулся на замечательный плагин добавляющмй поддержку zfs для OpenMediaVault — он даёт полный контроль над ZFS. Вместе с самим OpenMediaVault он полностью реализует все те функции, чего я так долго хотел получить от хранилища.
OpenMediaVault, как и Proxmox, целиком и полностью управляется через современный веб-интерфейс на ExtJS:

Proxmox и OpenMediaVault будут составлять ядро нашей системы, в результате чего мы получим многофункциональный комбайн продвинутой системы хранилища и продвинутой системы виртуализации в одной коробке, все данные при этом, как и диски виртуальных машин будут храниться на ZFS.
В случае если понадобится развернуть какой то новый сервис, всегда можно создать отдельную
виртуальную машину или контейнер для этого. Об этом я раскскажу чуть позже.

Обе системы поставляются и работают на Debian, что с одной стороны должно существенно упростить задачу, но с другой стороны обе системы несут в себе огромное количество пакетов и зависимостей, которые периодически могут пересекаться и конфликтовать между ссобой.
И специально для вас я написал небольшую инструкцию о том как сделать это.

Как установить OpenMediaVault на Proxmox

Установка Proxmox

Вам понадобится установочный диск, взять его можно на официальном сайте:

https://www.proxmox.com/en/downloads/category/iso-images-pve
(нам нужна 4 версия, так как она основана на Debian 8 Jessie)

Установка проста и интуитивно понятна, так что думаю, не вызовет у вас лишних вопросов.
Скажу только что желательно иметь отдельный физический диск под систему, чтобы в случае чего её всегда можно было бы безболезненно переустановить, не затрагивая при этом диски с данными.

При установке Proxmox можно так же выбрать файловую систему ZFS или даже настроить програмный RAID.

Установка OpenMediaVault

Установим репозитроий OpenMediaVault 3.0 Erasmus:

echo "deb http://packages.openmediavault.org/public erasmus main" > /etc/apt/sources.list.d/openmediavault.list

Как я говорил ранее, пакет openmediavault имеет некоторые неразрешимые зависимости с компонентами Proxmox, в часности это качается пакета watchdog, который в Proxmox начиная с версии 4.0 является fencing-демоном по умолчанию. В нашем случае он установлен по умолчанию как зависимость от proxmox-ve, но мы его не используем т.к. не используем кластеризацию.

В любом случае эти зависимости нам нужно как-то разрешить, и поэтому мы пересоберем deb-пакет для openmediavault.

Подготовим окружение для сборки:

apt install build-essentials

Скачаем исходники OpenMediaVault 3.0 Erasmus, и перейдем в директорию для сборки:

wget https://github.com/openmediavault/openmediavault/archive/3.x.tar.gz -O - | tar xzvf -
cd openmediavault-3.x/deb/openmediavault

Эта команда покажет нам необходимые зависимости, которые мы должны установить в системе перед сборкой пакета:

dpkg-checkbuilddeps

Исходя из вывода предыдущей команды установим необходимые пакеты:

apt install debhelper fakeroot gettext dh-systemd doxygen

Теперь нам нужно удалить watchdog из зависимостей, для этого отредактируем debian/control и удалим оттуда watchdog.
Также необходимо удалить требование версии для doxygen:

vim debian/control
# remove: watchdog
# remove version: doxygen (>= 1.8.9.1)

Проверим зависимости для сборки еще раз:

dpkg-checkbuilddeps

И запустим саму сборку:

dpkg-buildpackage -us -uc

После сборки вы получите готовый deb-пакет, который мы и установим в систему:

cd ..
dpkg -i openmediavault_*.deb

Теперь установим остальные зависимости, для этого запустим:

aptitude -f install

Теперь можно запустить скрипт для начальной конфигурации, поменять пароль администратора / порт веб-сервера и что-нибудь еще:

omv-firstaid

Установка плагина ZFS:

Плагин openmediavault-zfs устанавливается отдельно от OpenMediaVault и так как он тоже имеет неразрешимые зависимости мы тоже соберем его вручную:

Скачаем исходники, и перейдем в директорию для сборки:

wget https://github.com/OpenMediaVault-Plugin-Developers/openmediavault-zfs/archive/master.tar.gz -O - | tar xzvf - 
cd openmediavault-zfs-master

Подправим зависимости, удалим zfs-dkms так-как в Proxmox начиная с версии 4.0, ZFS уже идет в комплекте с ядром, до кучи за ненадобностью удалим так же linux-headers-* / pve-headers :

vim debian/control
# remove: zfs-dkms
# remove: linux-headers-amd64 | pve-headers | linux-headers-3.16.0-4-all

Проверим зависимости для сборки:

dpkg-checkbuilddeps

Запустим сборку:

dpkg-buildpackage -us -uc

После сборки установим полученный пакет и зависимости для него:

cd ..
dpkg -i openmediavault-zfs_*.deb
aptitude -f install

Если возникнут трудности со сброкой пакетов, в документации Debian есть неплохая статья на русском языке:

[https://www.debian.org/doc/manuals/maint-guide/build.ru.html](Глава 6. Сборка пакета)

На этом пожалуй все, теперь вы имеете Proxmox и OpenMediaVault установленные на одной системе, самое время перейти в GUI создать и настроить пулы ZFS и подключить их в Proxmox.
Как это сделать я описывать не буду, об этом и так полно информации в интернете.

Что дальше?

Дальше самое интересное, теперь можно приступить к настройке дополнительных сервисов.
Из них я хочу показать как настроить:

Wordpress — это один из самых простых и распространненых движков для построения сайтов.
Nextcloud — ваше личное облако и интерфейс для доступа к файлам.
Deluge — на мой взгляд лучшая торрентокачалка.
Emby — свободный медиа сервер, позволяет стримить мультимедиа прямо в браузере или через DLNA.
nginx-proxy — который будет автоматически генерировать конфиг и все эти сервисы проксировать.
nginx-proxy-companion — будет получать и обновлять сертификаты в автоматическом порядке.

Каждый из этих сервисов будет доступен на субдомене и защищен SSL, с валидным сертификатом от Letsencrypt. На помощь нам придет Docker, думаю что это гораздо проще чем вы могли бы себе это представить.

Я полагаю вы уже настроили хранилище ZFS и подключили его в интерфейс Proxmox.

В моем конкретном случае есть два пула:

rpool — это тот что создал proxmox при установке
tank — это RAIDZ пул из трех дисков с данными

Также я создал четыре основных датастора:

tank/pve — для виртуальных машин Proxmox
tank/docker — здесь будут храниться данные сервисов запущенных в docker
tank/cloud — для данных nextcloud
tank/data — основная файлопосойка, внутри есть еще несколько датасторов, таких как Music, Photos, Movies, каждый со своими настройками, например для Music и Photos включена дедупликация, так как у меня большое количество повторяющихся файлов, которые я неизвсестно когда разгребу...

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

lxc.aa_profile: unconfined
lxc.cap.drop:
mp0: /tank/data,mp=/data
mp1: /tank/cloud,mp=/cloud
mp2: /tank/docker,mp=/docker

Первые две выдают контейнеру больше прав, так что становится возможным запустить другие конейнеры внутри него, это необходимо для функционирования docker.
Остальные строки подключают необходимые директории к файловой системе гостя.

Внутри контейнера нам необходимо установить docker и docker-compose, а после этого я покажу как у меня все организованно.

Docker

В директории /docker у меня созданы директории для каждого отдельного сервиса:

# ls /docker/
deluge  emby nextcloud  nginx-proxy wordpress

В каждой директории лежит отдельный docker-compose.yml файл и данные каждого отдельного контейнера.

К примеру так выглядит docker-compose.yml:

для nginx-proxy и nginx-proxy-companion

nginx-proxy:
  restart: on-failure:5
  image: jwilder/nginx-proxy:alpine
  ports:
    - "80:80"
    - "443:443"
  volumes:
    - ./certs:/etc/nginx/certs:ro
    - ./vhost.d:/etc/nginx/vhost.d
    - ./html:/usr/share/nginx/html
    - /var/run/docker.sock:/tmp/docker.sock:ro
  labels:
    - "com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy=true"

nginx-proxy-companion:
  restart: on-failure:5
  image: jrcs/letsencrypt-nginx-proxy-companion
  volumes:
    - ./certs:/etc/nginx/certs:rw
    - /var/run/docker.sock:/var/run/docker.sock:ro
  volumes_from:
    - nginx-proxy

Вы можете зайти в директорию с nginx-proxy и выполнив docker-compose up вы проучите готовый запущенный сервис, это очень удобно!

Контейнер nginx-proxy в двух словах работает следующим образом, он запускается слушает docker.sock и в случае если обраружит запущенный контейнер с переменной VIRTUAL_HOST, то сгенерирует конфиг для этого виртуального хоста, с проксированием на виртуальный ip контейра.
Контейнер nginx-proxy-companion работает схожим образом, если обнаруживает запущенный контейнер с переменной LETSENCRYPT_HOST он автоматически получает для него сертификат.

Для более подробной информации совертую обратиться к официальной страничке проектов:

nginx-proxy — который будет автоматически генерировать конфиг и все эти сервисы проксировать.
nginx-proxy-companion — будет получать и обновлять сертификаты в автоматическом порядке.

Сразу должен предупредить, nginx-proxy не работает с Compose file version 2, т.к. требует чтобы между контейнерами была одна общая сеть.
Так что необходимо использлвать только Compose file version 1, либо держать все сервисы в одном конфиге.

Теперь сами конфиги:

для Wordpress:

mysql:
  restart: on-failure:5
  image: mariadb:10.0
  hostname: mysql
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ./mysql:/var/lib/mysql
  environment:
    - MYSQL_ROOT_PASSWORD=seekac7aexoh2eithut6sie1eYaeNgei
    - MYSQL_DATABASE=example_org
    - MYSQL_USER=example_org
    - MYSQL_PASSWORD=imieth7iev4dah6eeraik6Ohz6oiVup7

wordpress:
  restart: on-failure:5
  image: wordpress
  hostname: example.org
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ./wordpress:/var/www/html
  links:
    - mysql:mysql
  environment:
    - "VIRTUAL_HOST=example.org,www.example.org"
    - "LETSENCRYPT_HOST=example.org,www.example.org"
    - "LETSENCRYPT_EMAIL=admin@example.org"

для Nextcloud:

nextcloud:
  restart: on-failure:5
  image: nextcloud
  hostname: cloud
  domainname: example.org
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ./nextcloud:/var/www/html
    - /cloud:/cloud
    - /data:/data
  links: 
    - mysql:mysql
    - redis:redis
  environment:
    - "VIRTUAL_HOST=cloud.example.org"
    - "LETSENCRYPT_HOST=cloud.example.org"
    - "LETSENCRYPT_EMAIL=admin@example.org"

redis:
  restart: on-failure:5
  image: redis
  hostname: redis
  volumes:
    - /etc/localtime:/etc/localtime:ro

mysql:
  restart: on-failure:5
  image: mariadb:10.0
  hostname: mysql
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ./mysql:/var/lib/mysql
  environment:
    - MYSQL_ROOT_PASSWORD=ei8aiWaeDaeDoo8aida0woaNaiy8deer
    - MYSQL_DATABASE=nextcloud
    - MYSQL_USER=nextcloud
    - MYSQL_PASSWORD=rahGhied8lei6ogh2keitie1chaiheex

для Deluge:

deluge:
  restart: on-failure:5
  image: linuxserver/deluge
  hostname: torrent
  domainname: example.org
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ./config:/config
    - /data:/data
  ports: 
    - 53160:53160
    - 53160:53160/udp
    - 8112:8112
    - 58846:58846
    - 6881:6881
  expose:
    - 8112
  environment:
    - PUID=33
    - PGID=33
    - "VIRTUAL_HOST=torrent.example.org"
    - "VIRTUAL_PORT=8112"
    - "LETSENCRYPT_HOST=torrent.example.org"
    - "LETSENCRYPT_EMAIL=admin@example.org"

для Emby:

emby:
  restart: on-failure:5
  image: emby/embyserver
  volumes:
    - /etc/localtime:/etc/localtime:ro
    - ./config:/config
    - /data:/data
  environment:
    - APP_UID=33
    - APP_GID=33
  net: host

Для emby я использлвал net: host — это означает что контейнер будет использовать хостовую сеть вместо виртуальной сети для docker. Этот шаг необходим для работы DLNA-сервера. По той же причине не указанны VIRTUAL_HOST и LETSENCRYPT_HOST переменные.

Но стойте, как же быть? — как добавить такой контейнер к nginx-proxy?
А как быть если я хочу иметь доступ к веб-интерфейсам Proxmox и OpenMediaVault снаружи? — а они запущены вообще не в docker и даже не на этом хосте.

Решение не заставило себя долго искать, для подключений такого типа можно создать еще один отдельный прокси контейнер:

docker-compose.yml

nginx-local:
  restart: on-failure:5
  image: nginx
  expose:
    - 80
  environment:
    - "VIRTUAL_HOST=media.example.org,pve.example.org,nas.example.org"
    - "LETSENCRYPT_HOST=media.example.org,pve.example.org,nas.example.org"
    - "LETSENCRYPT_EMAIL=admin@example.org"
  volumes:
    - ./local-config:/etc/nginx/conf.d

С таким конфигом:

local-config/default.conf

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the
# scheme used to connect to this server
map $http_x_forwarded_proto $proxy_x_forwarded_proto {
  default $http_x_forwarded_proto;
  ''      $scheme;
}

# If we receive X-Forwarded-Port, pass it through; otherwise, pass along the
# server port the client connected to
map $http_x_forwarded_port $proxy_x_forwarded_port {
  default $http_x_forwarded_port;
  ''      $server_port;
}

# Set appropriate X-Forwarded-Ssl header
map $scheme $proxy_x_forwarded_ssl {
  default off;
  https on;
}

access_log off;
# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;
# Mitigate httpoxy attack (see README for details)
proxy_set_header Proxy "";

server {
        server_name _; # This is just an invalid value which will never trigger on a real hostname.
        listen 80;
        return 503;
}

# media.example.org
server {
        server_name media.example.org;
        listen 80 ;
        location / {
                proxy_pass http://192.168.100.20:8096/;
        }
}

# pve.example.org
server {
        server_name pve.example.org;
        listen 80 ;
        location / {
                proxy_pass https://192.168.100.10:8006/;
        }
}

# nas.example.org
server {
        server_name nas.example.org;
        listen 80 ;
        location / {
                proxy_pass http://192.168.100.10:8080/;
        }
}

На этом все, теперь у вас есть NAS с виртуализацией и несколько отличных сервисов, защищенных SSL по последнему писку моды:

https://example.org
https://cloud.example.org
https://torrent.example.org
https://media.example.org
https://nas.example.org
https://pve.example.org

Спасибо за внимание и удачи в экспериментах :)

Поделиться с друзьями

-->

Комментарии (47)

Meklon
06.05.2017 18:29
#10206552
+2
Отличный пост, спасибо. От proxmox отказался потому, что основная система помимо виртуализации должна ещё на телевизор Kodi показывать. Пробрасывать виртуальную машину на основной экран вместе с аппаратным ускорением я счёл геморройным. Правда, сейчас взял бы Ubuntu Server LTS, а не Debian.
1. kvaps
  06.05.2017 18:36
  #10206556
  +1
  У меня для таких целей есть отдельная Android-приставка с Kodi и примаунченной шарой, а сервер в коридоре жужжит :)
  1. Meklon
    06.05.2017 18:45
    #10206564
    У меня тоже в коридоре. В шкафу. А оттуда через стену в зал. Плюс там хорошая звуковая карта. Акустика работает независимо от экрана. Можно музыку включить автономно тем же Kodi.
    
    kvaps
    06.05.2017 19:02
    #10206574
    Ого, а управляете чем? — если приложение для телефона, то какое?
    Меня официальное Kore не устраивает тем, что там нельзя музыку по папочкам проигрывать, приходится использовать проприетарное Yatse, но должен признать, что оно достаточно неплохое.
    
    Для управления TV, приставкой и звуком использую универсальный пульт с гироскопом MeLE F10 Deluxe:
    
    прикольная штука
    
    Meklon
    06.05.2017 19:27
    #10206586
    +1
    Yatse. Разработчик — очень контактный швед. Активная разработка, очень хороший комбайн. Из ключевых фишек — возможность их меню share в андроид бросать все подряд на экран Kodi. YouTube, прямой стрим своего видео с телефона.
    
    Meklon
    07.05.2017 20:41
    #10207272
    +1
    Связался с автором Yatse, он обещал рассказать про новые фичи, которые он планирует и прочее. Там сильно расширяется поддержка других медиасервисов помимо Kodi. Если получится, приеду его на хабр с гуглопееводчиком. Или пусть на английском пишет, здесь это не проблема. Я все равно пост планировал по headless Kodi.
1. DaylightIsBurning
  06.05.2017 21:53
  #10206670
  +2
  Я всё таки настроил снова себе Proxmox c пробросом аппаратного ускорения в контейнер и установил в нём Ubuntu 16.04 с KDE plasma 5 и Kodi. Проброс в виртуальную машину был бы круче, но у меня дешевая материнка, на ней нет IOMMMU. Проброс видеокарты и аудио в lxc-containert делается довольно просто — нужно всего лишь развернуть в проксмоксе убунту-контейнер из стандартного шаблона, дописать пару строк в стандартно сгенерированный конфиг lxc и один раз запустить простенький скрипт внутри контейнера. После этого можно пользоваться контейнером как основным десктопом или как htpc (в моём случае и то и другое). Как настроить такое я описывал на stackexchange. Дальше я устанавливал kubuntu-desktop, но, правда, пришлось установить slim, т.к. я не смог запустить sdm. В моём случае видеокарта — AMD встроенная в проц.
1. gmelikov
  06.05.2017 23:15
  #10206708
  +1
  В proxmox классно то, что он ставится по сути на чистый Debian, пользуюсь в качестве десктопа, аналогично можно вместо wm поставить kodi (не самое чистое решение конечно, но работает прекрасно).
  1. DaylightIsBurning
    06.05.2017 23:43
    #10206754
    +1
    Это неплохой вариант, если устраивает debian-desktop. LXC/qemu desktop помимо «чистоты» позволяет более современное ПО ставить, другие дистрибутивы, под qemu, если пробросить видеокарту через iommu, можно вообще хоть на винде сидеть. Можно даже два десктопа на одном сервере так поднять. По идее, Ryzen в этом плане открывает новые горизонты: при невысокой цене работает ECC и IOMMU даже на недорогих материнках. На практике там пока что проблемы с IOMMU groups и ECC не на всех материнках полностью гладко работает, но может быть, скоро эти проблемы будут решены. На Intel такое только на серверных чипсетах можно запилить.
    
    gmelikov
    06.05.2017 23:50
    #10206762
    Знаете, я когда-то гнался за отдельной виртуализацией каждого сервиса, но в конце-концов в рамках домашнего NAS от этого для меня больше проблем, чем пользы.
    
    Более свежее ПО — в рамках десктопа с proxmox прекрасно работает testing репозитарий Дебиана, ставил из него всё, что нужно.
    
    Всегда за безопасность, но придерживаюсь рационального (для меня) подхода, что не везде виртуализация нужна.
    
    DaylightIsBurning
    06.05.2017 23:53
    #10206764
    +1
    Согласен, в крайности ударяться не стоит, но, мне кажется, отделить сервер-гипервизор и десктоп — как раз случай когда виртуализация избавляет от проблем и предоставляет нужную гибкость.
    
    gmelikov
    06.05.2017 23:59
    #10206772
    Кстати, а какое свежее ПО в вашем случае используете, которого нет в Jessie? Лично я тяну из backports только видеодрайвер (т.к. для skylake нужен свежий) и браузер.
    
    DaylightIsBurning
    07.05.2017 00:08
    #10206788
    +1
    Софт для разработки: gcc6, всякие библиотеки типа boost последних версий, python >=3.5. Ещё KDE plasma, у меня 4K монитор, а поддержка high-dpi на новых версиях значительно лучше. Хочу даже на Arch/Manjaro перейти, именно что бы легко было последние версии нужного софта использовать. На ноуте вот KDE-Neon поставил — не нарадуюсь :)
1. n1mda
  07.05.2017 00:15
  #10206802
  а чем XMBC не понравился? Старенький? я думал его задача просто показывать фильмы из папки, запоминать на каком месте я остановил просмотр и предлагать продолжить с этого места.
  у меня стоит Jessie с иксами, на него накатил Proxmox, через одну виртуалку вывожу свои компы в всемирную сеть. Ну и мне хватает простой самбы что бы я мог делать на шарах все, а ребенок и жена только читать.
  1. Meklon
    07.05.2017 12:24
    #10206942
    Как минимум поддержка пультами типа Yatse уже дропнута. Даже в старом Debian уже его нет. У меня сейчас Debian Stretch.

DaylightIsBurning
06.05.2017 22:15
#10206680
+1
Спасибо за статью, почерпнул для себя некоторые моменты. У меня очень похожий сетап, тоже All-in-One проксмос, тоже zfs, тоже сервисы на докере и nginx аналогично настроен. У меня два All-in-one сервера уже ~5 лет работают. Последний вариант уже почти год — работает отлично. Отличия:
1) Я всё же установил proxmox на флешку. Последние версии проксмокса работают с флешек как часы — никаких проблем. Плюс флешки довольно легко клонировать и, если одна помирает, можно склонировать её образ на новую.
2) NAS установлен в отдельной виртуальной машине, в эту машину проброшены диски через virtio. Не могу сказать, что это обеспечивает сказочную производительность дисковой подсистемы, но с настройками «по умолчанию» выходит 40-50 MB/s, мне хватает хватает и я даже не пытался добиться большего.
3) All-in-one включает роутер, который реализован как виртуальная машина с openwrt.
4) Там же десктоп/htpc в виде lxc контейнера с пробросом видеокарты (lxc.cgroup.devices.allow, lxc.mount.entry). На контейнере Ubuntu 16.04 и KDE plasma 5 с Kodi, аппаратное ускорение работает ОК, при том что видео встроенное в дешевый AM1-процессор от AMD и используется 4К монитор.
5) Виртуалка с роутером и NAS лежит прямо на флешке, на которой proxmox. Когда стартует Proxmox, он стартует роутер и NAS, а затем уже с хранилища на NAS стартуют остальные виртуалки/контейнеры.
Ну и для докер контейнеров у меня отдельная вирт. машина, а не lxc.
1. kvaps
  06.05.2017 22:50
  #10206696
  Вам спасибо, за интерес и не менее интересные коментарии :)
  
  1) С флешкой у меня не завелось, все флешки в доме перепробовал. :) Сколько с root на флешке не связывлся и дома и на работе, всегда система либо очень сильно тормозит, либо вообще не заводится.
  Вот и в последний раз даже USB3.0 флешку специально для этого купил, думал таких проблем не будет, ан нет, даже это не спасло. Может у вас какая-то супер-флешка?
  
  2) У меня тоже была такая идея, но хотелось реализации именно на хосте а не в виртуальной машине, потому что a) только так можно получить живую производительность, и b) обе системы прекрассно работают и делят между собой одни ресурсы и могут использовать один и тот же пул zfs.
  1. DaylightIsBurning
    06.05.2017 23:31
    #10206730
    +1
    флешки обычные на 16/32 GB, usb 3.0, но стоят в портах 2.0. Я, правда, выбирал чтобы не самые тормознутые, но без фанатизма, по 8-10 евро брал примерно. Proxmox довольно мало обращается к диску сам по себе, роутер тоже, даже обычный убунту-сервер, сам по себе большой производительности от диска не требует. А какие у Вас были проблемы? Что именно тормозило?
    Я устанавливал прямо обычным установщиком Proxmox'a, с флешки на флешку, как тут описано. Обратите внимание на rootdelay. Дополнительно настраивал что бы меньше обращений к диску было, как советуют во всяких («устаревших») мануалах по установке линукса на SSD, но не знаю, какую роль эти настройки играют, наверное, и без них ок. Главное чтобы свопа на флешке не было, наверное.
    Вот мои настройки:
    > systemctl enable tmp.mount > cat /etc/fstab /dev/pve/root / ext4 commit=120,noatime,nodiratime,errors=remount-ro 0 1 UUID=219E-7546 /boot/efi vfat defaults 0 1 #/dev/pve/swap none swap sw 0 0 proc /proc proc defaults 0 0 > tail -n3 /etc/default/tmpfs RAMTMP=yes RAMRUN=yes RAMLOCK=yes
    2.b) Ну они и так делят ресурсы и используют один и тот же пул zfs. У меня настроено и через NFS и через ZFS-over-iSCSI, оба варианта поддерживаются в Proxmox. Мне кажется, лучше максимально разделить службы по контейнерам/вм в данном случае. С производительностью, наверное, сложнее, но люди же используют SAN и добиваются очень большой производительности, так что, наверное, при желании, можно и это настроить.
    
    kvaps
    07.05.2017 00:04
    #10206782
    Флешки пробовал разные, но подозреваю все они сильно хуже по скорости случайной записи чем флешки в приведенной вами ссылке, думаю что проблема именно в этом.
    FreeNAS тормозил над каждым действием в веб-морде.
    Proxmox 4.4 и 5.0 beta1 и Debian 8 устанавилвались очень долго, но в конце установки выдавал ошибку. Debian не грузился с ошибкой что не может найти root-раздел. Из опций только noatime,nodiratime указал при установке.
    Спасибо за информацию, в следующий раз куплю нормальную флешку и обязательно попробую еще раз!
    
    DaylightIsBurning
    07.05.2017 00:17
    #10206814
    +1
    Debian не грузился с ошибкой что не может найти root-раздел
    
    Это лечится через rootdelay в аргументах grub, я выше ссылку давал.
    
    Спасибо за информацию, в следующий раз куплю нормальную флешку и обязательно попробую еще раз!
    У меня в одном из серверов стоит Lexar JumpDrive S23 16GB, которая по сегодняшним меркам так себе, но для Proxmox хватает вполне.

Pilat
06.05.2017 22:26
#10206686
Домашний NAS — а что в качестве железного сервера? ZFS с дедупликацией какие ресурсы потребляет?
1. gmelikov
  06.05.2017 23:20
  #10206714
  Не советую применять дедупликацию в ZFS где-либо, кроме промышленного файлового хранилища, лучше просто использовать lz4 сжатие.
1. kvaps
  06.05.2017 23:38
  #10206744
  Домашний NAS — а что в качестве железного сервера?
  CPU: AMD FX-8300 Vishera
  RAM: 16GB DDR3
  HDD: 3x2TB (raidz) TOSHIBA DT01ACA200
  
  ZFS с дедупликацией какие ресурсы потребляет?
  Здесь пишут что нужно расчитывать 20GB RAM на каждый TB данных
  
  На деле у меня два датастора со включенной дедупликацией, общий объем данных в которых ~850GB, примерно треть в них повторяется. Данные обновляются редко (музыка и фотографии)
  Остальные данные около ~400GB хранятся на датасторах без дедупликации но с lz4 сжатием на лету.
  Эти данные находятся в постоянном в доступе (раздаются торрентом или проигрываются удаленно).
  
  CPU: утилизируется на 2-5%
  RAM: используется почти все 16G, 4G из которых выделено в контейнер с докером, но при этом в swap не лезет (~500M всегда свободно строго)
  
  Прелесть дедупликации что ее можно в любой момент выключить/включить.
  1. gmelikov
    06.05.2017 23:43
    #10206752
    Про отключение дедупликации — отмечу, что в настоящий момент применение изменений к уже записанным данным не осуществляется, так что отключить можно, но для полного исключения требуются определённые движения (по сути нужна перезапись данных).
    
    kvaps
    06.05.2017 23:48
    #10206758
    Возможно я что-то не так понимаю, но ведь полного исключения и не нужно?
    Чем плохо то что сдедуплицированные данные такими и останутся на всегда? — ведь основной процесс дедупликации просто перестанет работать, не так ли?
    
    gmelikov
    06.05.2017 23:55
    #10206768
    +4
    При дедуплицации в системе будет всегда присутствовать т.н. Dedup table (DDT), по которому и происходит привязка дублей. На неё и требуется ОЗУ.
    
    Если интересно, готов рассказать про многие вопросы ZFS, т.к. являюсь контрибьютором. В планах статья-howto с описанием дел на настоящий момент.
    
    DaylightIsBurning
    07.05.2017 00:03
    #10206778
    статья-howto с описанием дел на настоящий момент
    
    было бы очень интересно!
    Будет ли когда-нибудь шифрование из коробки? Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке? Что на счёт ssd-кеширования? Как я понимаю, сейчас ZIL и L2ARC не позволяют полноценный кеш организовать, по сравнению с bcache, например?
    
    gmelikov
    08.05.2017 15:28
    #10207954
    +1
    Отвечу сразу здесь:
    
    Будет ли когда-нибудь шифрование из коробки?
    
    Да, уже год активно дорабатывается и шлифуется. При чём оно разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/recieve и scrub отправлять и проверять данные на целостность без ключа.
    
    Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке?
    
    В целом производительность будет улучшаться в следующем мажорном выпуске, но явных проблем с дедупликацией нет. Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока), если DDT в неё не помещается, то будет ухудшение производительности.
    Отдельно упомяну, что в бета-релизе проведена большая работа по оптимизации управления данными в ОЗУ (сокращённо ABD)
    
    Что на счёт ssd-кеширования
    
    ZIL выносит журнал на отдельный носитель, а L2ARC очень похож на bcache со своими особенностями. Вот отличная статья по этому поводу.
    Отдельно стоит отметить, что в случае ZFS часто хватает просто добавить ОЗУ, ARC прекрасно борется с вымыванием кеша.
    На своём десктопе использую 2 WD RED в виде mirror с 16гб ОЗУ, после прогрева кеша машина работает не хуже, чем с ZFS на бюджетном SSD.
    
    DaylightIsBurning
    08.05.2017 16:13
    #10207968
    Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока),
    
    В том то и дело, что требования к ОЗУ гигантские, как мне кажется. Допустим у нас 10TB данных, средний блок 64k — выходит ~156*10^6 блоков. Хеш одного блока пусть будет 32 бита, тогда выходит что нужно 10TB/64kB*4=625MB ОЗУ. Даже если взять 8 байтный хеш — всё равно выходит ~1 GB. В случае коллизии (вероятность которой примерно 10^-11 для 8 байтного хеша) можно просто сверить весь блок.
    
    gmelikov
    08.05.2017 23:10
    #10208284
    +1
    В том то и дело, что требования к ОЗУ гигантские
    
    Вы о выше упомянутых 20гб? Это очень завышенная оценка, FreeBSD даёт оценку в ~ 5 гб на 1тб.
    Тут прекрасно описан метод работы DDT, там же приводятся конкретные цифры — 320 байт на каждую запись (уникальный блок).
    
    Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
    
    zdb -S название_пула
    
    На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.
    
    Вот симуляция для моего пула (бекапы, /home, /, немного виртуалок, одним словом дедуплицировать особо нечего):
    
    Simulated DDT histogram
    bucket allocated referenced ______ ______________________________ ______________________________ refcnt blocks LSIZE PSIZE DSIZE blocks LSIZE PSIZE DSIZE ------ ------ ----- ----- ----- ------ ----- ----- ----- 1 9.79M 767G 611G 613G 9.79M 767G 611G 613G 2 894K 47.7G 39.0G 39.3G 1.89M 101G 82.4G 83.1G 4 112K 3.52G 2.28G 2.37G 541K 17.0G 11.1G 11.6G 8 32.9K 1.17G 925M 968M 348K 13.1G 10.1G 10.6G 16 12.0K 529M 397M 418M 239K 10.1G 7.62G 8.03G 32 10.5K 925M 726M 734M 480K 42.3G 33.0G 33.4G 64 892 39.7M 30.0M 31.3M 80.0K 3.71G 2.77G 2.89G 128 419 23.1M 18.7M 19.2M 73.7K 4.19G 3.40G 3.47G 256 208 13.6M 10.9M 11.1M 73.1K 4.86G 3.92G 3.99G 512 76 4.90M 3.85M 3.91M 49.4K 3.29G 2.60G 2.64G 1K 13 1.01M 827K 840K 16.4K 1.20G 981M 999M 2K 2 130K 5.50K 8K 6.19K 508M 19.1M 24.8M 8K 5 640K 404K 404K 41.8K 5.22G 3.30G 3.30G Total 10.8M 821G 655G 656G 13.6M 974G 772G 776G dedup = 1.18, compress = 1.26, copies = 1.01, dedup * compress / copies = 1.48
    
    DaylightIsBurning
    09.05.2017 00:20
    #10208354
    Мне, кажется, столько большая константа (320, когда достаточно не более 8+4 на dataHash+blockID) портит всю малину. 1-2 гигабайта на 10ТБ было бы no-brainer, а так… Но это, конечно, лишь мои фантазии, наверняка у разработчиков были свои причины, из-за которых вышло 320.
    
    gmelikov
    09.05.2017 19:58
    #10208978
    Стоит уточнить цифры для ZFS:
    — используемый sha256 (ваш dataHash) = 32 байт
    — block pointer (ваш blockID) (blkptr_t) = 128 байт
    
    Это только базовые цифры для минимального варианта реализации. Также там точно есть счётчик повторений, глубже копать не стал, но эти цифры уже дают понимание, что требования не такие уж и раздутые.
    
    Причина такого большого block pointer кроется в самой идее ZFS, и от этого никуда не деться. По этому базовый блок 128кб, он позволяет уменьшить накладные расходы. Больше блок — меньше накладные расходы, но при чтении файла с размером больше блока придётся прочитать ещё 1 полный блок (где находится окончание файла).
    
    DaylightIsBurning
    09.05.2017 20:04
    #10208990
    +1
    используемый sha256 (ваш dataHash) = 32 байт
    но зачем хранить весь sha256 в оперативке? достаточно было бы первые 4-8 байт, а в случае коллизий уже пересчитывать полный. То же самое с block pointer, можно было бы пересчитывать сокращённую форму в blkptr_t налету.
    
    DaylightIsBurning
    09.05.2017 20:14
    #10209006
    А зачем весь blkptr_t, не достаточно было бы blk_dva (32 байта)? Можно ли хранить не blkptr_t/blk_dva а только смещение на адрес, по которому этот самый blkptr_t можно узнать/вычислить?
    
    gmelikov
    09.05.2017 20:37
    #10209036
    +2
    Мне нравится ваш ход мыслей! :)
    По предложениям ответить не могу, т.к. в нутра этой части не лазил, но мы всегда открыты к предложениям! Если готовы — можете внести свои предложения в виде issue, или сразу пулл реквестом, помогу с любым вопросом в части оформления, а другие участники всегда подскажут по коду, сообщество очень доброжелательное.
    
    DaylightIsBurning
    10.05.2017 13:56
    #10209960
    +2
    https://github.com/zfsonlinux/zfs/issues/6116
    
    kvaps
    07.05.2017 00:06
    #10206786
    обязательно пишите! — мы все очень сильно ждем :)
    
    Pilat
    07.05.2017 00:54
    #10206830
    Вопрос, ответ на который кажется очевидным, но всё же. Если ZFS+дедупликацию использовать для хранения несжатых бэкапов Proxmox на самом сервере — какие ресурсы это потребует, с учётом того что коэффициент будет наверняка очень высоким, сохранится ли 20 гигабайт на терабайт данных, не будет ли проблем с самим проксмоксом? Сервер 48 гигабайт РАМ+терабайт SATA (ZFS) +2x200 SSD — сможет ли справиться с этой задачей без больших потерь памяти? Стоит ли включить дедупликацию на SSD, где лежат образы виртуалок?
    Вопрос навеян Вашим комментарием "Не советую применять дедупликацию в ZFS где-либо, кроме промышленного файлового хранилища".
    
    DaylightIsBurning
    07.05.2017 00:58
    #10206832
    Для бекапов можно еще рассмотреть вариант snapshot + zfs send, тогда и без дедупликации все ок.
    
    gmelikov
    07.05.2017 01:38
    #10206838
    +1
    Всё верно, в таком случае используется snapshot, он позволяет создавать инкрементальные срезы хоть каждую минуту. Но сразу оговорюсь, что не стоит подменять им полноценный бекап на другую машину (а в таком случае снапшоты также прекрасно передаются по сети в инкрементальном режиме).
    
    Вообще, после zfs я уже не представляю, как можно жить без снапшотов и хеширования данных. На моей машине настроено создание снапшота всей системы раз в 15 минут, и это никак не влияет ни на производительность, ни на простои (см. https://github.com/zfsonlinux/zfs-auto-snapshot )
    
    Спасибо всем за поддержку, статье быть, и не одной:)
    
    Meklon
    07.05.2017 20:45
    #10207278
    Буду очень ждать)

gmelikov
06.05.2017 23:22
#10206724
По поводу установки на флеш или hdd — вообще без разницы, т.к. тот же ZFS прекрасно отделяет и резервирует систему.

guglez
07.05.2017 18:34
#10207158
Сомнительно выглядит установка OMV и Proxmox на одну физическую систему. В виртуалку ставить ZFS не имеет никакого смысла по понятным причинам, а в вашем сетапе кто гарантирует, что кастомное ядро Proxmox будет нормально работать с нутром от OMV?
1. kvaps
  07.05.2017 21:33
  #10207304
  +1
  А какаое конкретно нутро вы имеете ввиду? OMV состоит их стандартных демонов и веб-морды к ним, никаких хитрых и дополнительных модулей ядра он не использует.
  Плагин ZFS — да, требует модуль ядра zfs, но он и так уже присутствует в Proxmox, потому мы и выпилили его из зависимостей. В остальном это всего лишь управлялка.
  
  Кстати, что мне показалось странным, в зависимостях плагина можно обнаружить пакет pve-headers, а это означает что разработчик допускает возможность совместной установки плагина с кастомным ядром Proxmox.
  
  списки зависимостей
  openmediavult:
  
  perl:any libjs-extjs5 php5-fpm libpam-modules php5-cgi php5-cli php5-pam sudo ethtool python3-dialog acl ifenslave resolvconf iproute2 xfsprogs jfsutils ntfs-3g hdparm sdparm ifupdown mdadm postfix libsasl2-modules bsd-mailx python3-dbus cpufrequtils rsyslog logrotate smartmontools openssl openssh-server openssh-blacklist-extra uuid tzdata nfs-kernel-server proftpd-basic wget util-linux samba samba-common-bin rsync apt-utils snmpd avahi-daemon libnss-mdns iptables monit acpid beep gdisk rrdtool collectd cron anacron cron-apt quota quotatool whiptail lvm2 watchdog ca-certificates perl libjson-perl liblocale-po-perl proftpd-mod-vroot libjavascript-minifier-xs-perl coreutils xmlstarlet mount parted bash diffutils lsof socat rrdcached locales nginx bash-completion python3 python3-apt pm-utils wpasupplicant systemd systemd-sysv btrfs-tools samba-vfs-modules pciutils python3-pyudev python3-natsort jq ntp python3-netifaces udev apt-transport-https python3-lxml debconf debconf-2.0 init-system-helpers
  
  openmediavault-zfs:
  
  linux-headers-amd64 pve-headers linux-headers-3.16.0-4-all openmediavault openmediavault-omvextrasorg zfs-dkms zfsutils-linux zfsutils zfs-zed

shadowlord
08.05.2017 13:53
#10207864
В свое время собирали Proxmox на ZFS для офиса. Были неприятно удивлены невозможности делать клоны машин со снапшотов (только с текущего состояния) и откатывать не до последнего снепшота. Судя по комментариям на форумах — это стандартное ограничение ZFS, из-за чего пришлось от него отказаться (сейчас CEPH). Может быть я что-то делал неправильно, или оно так у всех?
1. gmelikov
  08.05.2017 15:07
  #10207932
  Сам ZFS позволяет делать clone со снапшотов (в рамках понятий ZFS), скорее всего это не реализовано в веб-интерфейсе proxmox (он также не видит созданные мной вручную снапшоты).

E3AP
09.05.2017 00:54
#10208370
OMV 3.x весьма странное создание. ИМХО ему еще нужно время на стабилизацию состояния.

	FreeNAS 9
	FreeNAS 10
	OpenMediaVault
	NAS4Free
	Synology
	QNAP
	Обычный дистрибутив с вручную настроенными демонами
	Другая / свободная
	Другая / проприетарная
	Нет
	Любой дистрибутив и Docker