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


    Астрологи объявили месяц статей о домашних 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


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



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


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


    После установки, не забудьте прописать pve-no-subscription для репозитория Proxmox, чтобы иметь возможность устанавливать из него пакеты.


    cat /etc/apt/sources.list.d/pve-enterprise.list 
    deb http://download.proxmox.com/debian jessie pve-no-subscription

    Установка 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-essential

    Скачаем исходники 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 есть неплохая статья на русском языке:



    На этом пожалуй все, теперь вы имеете 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.
    Остальные строки подключают необходимые директории к файловой системе гостя.


    Стоит обратить ваше внимание на то, что если внутри подключаемых в контейнер zfs-датасторов вы имеете другие, то их так же необходимо добавить в конфигурацию контейнера, иначе рискуете получить несколько неприятных багов. Приведу пример:


    mp0: /tank/data,mp=/data
    mp3: /tank/data/Music,mp=/data/Music
    mp4: /tank/data/Pictures,mp=/data/Pictures

    Внутри контейнера нам необходимо установить 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

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

    А у вас дома есть NAS? Какую систему используете?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 49
    • +2
      Отличный пост, спасибо. От proxmox отказался потому, что основная система помимо виртуализации должна ещё на телевизор Kodi показывать. Пробрасывать виртуальную машину на основной экран вместе с аппаратным ускорением я счёл геморройным. Правда, сейчас взял бы Ubuntu Server LTS, а не Debian.
      • +1

        У меня для таких целей есть отдельная Android-приставка с Kodi и примаунченной шарой, а сервер в коридоре жужжит :)

        • 0
          У меня тоже в коридоре. В шкафу. А оттуда через стену в зал. Плюс там хорошая звуковая карта. Акустика работает независимо от экрана. Можно музыку включить автономно тем же Kodi.
          • 0

            Ого, а управляете чем? — если приложение для телефона, то какое?
            Меня официальное Kore не устраивает тем, что там нельзя музыку по папочкам проигрывать, приходится использовать проприетарное Yatse, но должен признать, что оно достаточно неплохое.


            Для управления TV, приставкой и звуком использую универсальный пульт с гироскопом MeLE F10 Deluxe:


            прикольная штука

            • +1
              Yatse. Разработчик — очень контактный швед. Активная разработка, очень хороший комбайн. Из ключевых фишек — возможность их меню share в андроид бросать все подряд на экран Kodi. YouTube, прямой стрим своего видео с телефона.
              • +1
                Связался с автором Yatse, он обещал рассказать про новые фичи, которые он планирует и прочее. Там сильно расширяется поддержка других медиасервисов помимо Kodi. Если получится, приеду его на хабр с гуглопееводчиком. Или пусть на английском пишет, здесь это не проблема. Я все равно пост планировал по headless Kodi.
          • +2
            Я всё таки настроил снова себе Proxmox c пробросом аппаратного ускорения в контейнер и установил в нём Ubuntu 16.04 с KDE plasma 5 и Kodi. Проброс в виртуальную машину был бы круче, но у меня дешевая материнка, на ней нет IOMMMU. Проброс видеокарты и аудио в lxc-containert делается довольно просто — нужно всего лишь развернуть в проксмоксе убунту-контейнер из стандартного шаблона, дописать пару строк в стандартно сгенерированный конфиг lxc и один раз запустить простенький скрипт внутри контейнера. После этого можно пользоваться контейнером как основным десктопом или как htpc (в моём случае и то и другое). Как настроить такое я описывал на stackexchange. Дальше я устанавливал kubuntu-desktop, но, правда, пришлось установить slim, т.к. я не смог запустить sdm. В моём случае видеокарта — AMD встроенная в проц.
            • +1

              В proxmox классно то, что он ставится по сути на чистый Debian, пользуюсь в качестве десктопа, аналогично можно вместо wm поставить kodi (не самое чистое решение конечно, но работает прекрасно).

              • +1
                Это неплохой вариант, если устраивает debian-desktop. LXC/qemu desktop помимо «чистоты» позволяет более современное ПО ставить, другие дистрибутивы, под qemu, если пробросить видеокарту через iommu, можно вообще хоть на винде сидеть. Можно даже два десктопа на одном сервере так поднять. По идее, Ryzen в этом плане открывает новые горизонты: при невысокой цене работает ECC и IOMMU даже на недорогих материнках. На практике там пока что проблемы с IOMMU groups и ECC не на всех материнках полностью гладко работает, но может быть, скоро эти проблемы будут решены. На Intel такое только на серверных чипсетах можно запилить.
                • 0
                  Знаете, я когда-то гнался за отдельной виртуализацией каждого сервиса, но в конце-концов в рамках домашнего NAS от этого для меня больше проблем, чем пользы.

                  Более свежее ПО — в рамках десктопа с proxmox прекрасно работает testing репозитарий Дебиана, ставил из него всё, что нужно.

                  Всегда за безопасность, но придерживаюсь рационального (для меня) подхода, что не везде виртуализация нужна.
                  • +1
                    Согласен, в крайности ударяться не стоит, но, мне кажется, отделить сервер-гипервизор и десктоп — как раз случай когда виртуализация избавляет от проблем и предоставляет нужную гибкость.
                    • 0
                      Кстати, а какое свежее ПО в вашем случае используете, которого нет в Jessie? Лично я тяну из backports только видеодрайвер (т.к. для skylake нужен свежий) и браузер.
                      • +1
                        Софт для разработки: gcc6, всякие библиотеки типа boost последних версий, python >=3.5. Ещё KDE plasma, у меня 4K монитор, а поддержка high-dpi на новых версиях значительно лучше. Хочу даже на Arch/Manjaro перейти, именно что бы легко было последние версии нужного софта использовать. На ноуте вот KDE-Neon поставил — не нарадуюсь :)
              • 0
                а чем XMBC не понравился? Старенький? я думал его задача просто показывать фильмы из папки, запоминать на каком месте я остановил просмотр и предлагать продолжить с этого места.
                у меня стоит Jessie с иксами, на него накатил Proxmox, через одну виртуалку вывожу свои компы в всемирную сеть. Ну и мне хватает простой самбы что бы я мог делать на шарах все, а ребенок и жена только читать.
                • 0
                  Как минимум поддержка пультами типа Yatse уже дропнута. Даже в старом Debian уже его нет. У меня сейчас Debian Stretch.
              • +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.
                • 0

                  Вам спасибо, за интерес и не менее интересные коментарии :)


                  1) С флешкой у меня не завелось, все флешки в доме перепробовал. :) Сколько с root на флешке не связывлся и дома и на работе, всегда система либо очень сильно тормозит, либо вообще не заводится.
                  Вот и в последний раз даже USB3.0 флешку специально для этого купил, думал таких проблем не будет, ан нет, даже это не спасло. Может у вас какая-то супер-флешка?


                  2) У меня тоже была такая идея, но хотелось реализации именно на хосте а не в виртуальной машине, потому что a) только так можно получить живую производительность, и b) обе системы прекрассно работают и делят между собой одни ресурсы и могут использовать один и тот же пул zfs.

                  • +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 и добиваются очень большой производительности, так что, наверное, при желании, можно и это настроить.
                    • 0

                      Флешки пробовал разные, но подозреваю все они сильно хуже по скорости случайной записи чем флешки в приведенной вами ссылке, думаю что проблема именно в этом.
                      FreeNAS тормозил над каждым действием в веб-морде.
                      Proxmox 4.4 и 5.0 beta1 и Debian 8 устанавилвались очень долго, но в конце установки выдавал ошибку. Debian не грузился с ошибкой что не может найти root-раздел. Из опций только noatime,nodiratime указал при установке.
                      Спасибо за информацию, в следующий раз куплю нормальную флешку и обязательно попробую еще раз!

                      • +1
                        Debian не грузился с ошибкой что не может найти root-раздел

                        Это лечится через rootdelay в аргументах grub, я выше ссылку давал.
                        Спасибо за информацию, в следующий раз куплю нормальную флешку и обязательно попробую еще раз!
                        У меня в одном из серверов стоит Lexar JumpDrive S23 16GB, которая по сегодняшним меркам так себе, но для Proxmox хватает вполне.
                • 0

                  Домашний NAS — а что в качестве железного сервера? ZFS с дедупликацией какие ресурсы потребляет?

                  • 0

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

                    • 0
                      Домашний 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 всегда свободно строго)


                      Прелесть дедупликации что ее можно в любой момент выключить/включить.

                      • 0
                        Про отключение дедупликации — отмечу, что в настоящий момент применение изменений к уже записанным данным не осуществляется, так что отключить можно, но для полного исключения требуются определённые движения (по сути нужна перезапись данных).
                        • 0

                          Возможно я что-то не так понимаю, но ведь полного исключения и не нужно?
                          Чем плохо то что сдедуплицированные данные такими и останутся на всегда? — ведь основной процесс дедупликации просто перестанет работать, не так ли?

                          • +4
                            При дедуплицации в системе будет всегда присутствовать т.н. Dedup table (DDT), по которому и происходит привязка дублей. На неё и требуется ОЗУ.

                            Если интересно, готов рассказать про многие вопросы ZFS, т.к. являюсь контрибьютором. В планах статья-howto с описанием дел на настоящий момент.
                            • 0
                              статья-howto с описанием дел на настоящий момент

                              было бы очень интересно!
                              Будет ли когда-нибудь шифрование из коробки? Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке? Что на счёт ssd-кеширования? Как я понимаю, сейчас ZIL и L2ARC не позволяют полноценный кеш организовать, по сравнению с bcache, например?
                              • +1
                                Отвечу сразу здесь:
                                Будет ли когда-нибудь шифрование из коробки?

                                Да, уже год активно дорабатывается и шлифуется. При чём оно разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/recieve и scrub отправлять и проверять данные на целостность без ключа.

                                Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке?

                                В целом производительность будет улучшаться в следующем мажорном выпуске, но явных проблем с дедупликацией нет. Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока), если DDT в неё не помещается, то будет ухудшение производительности.
                                Отдельно упомяну, что в бета-релизе проведена большая работа по оптимизации управления данными в ОЗУ (сокращённо ABD)

                                Что на счёт ssd-кеширования

                                ZIL выносит журнал на отдельный носитель, а L2ARC очень похож на bcache со своими особенностями. Вот отличная статья по этому поводу.
                                Отдельно стоит отметить, что в случае ZFS часто хватает просто добавить ОЗУ, ARC прекрасно борется с вымыванием кеша.
                                На своём десктопе использую 2 WD RED в виде mirror с 16гб ОЗУ, после прогрева кеша машина работает не хуже, чем с ZFS на бюджетном SSD.

                                • 0
                                  Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока),

                                  В том то и дело, что требования к ОЗУ гигантские, как мне кажется. Допустим у нас 10TB данных, средний блок 64k — выходит ~156*10^6 блоков. Хеш одного блока пусть будет 32 бита, тогда выходит что нужно 10TB/64kB*4=625MB ОЗУ. Даже если взять 8 байтный хеш — всё равно выходит ~1 GB. В случае коллизии (вероятность которой примерно 10^-11 для 8 байтного хеша) можно просто сверить весь блок.
                                  • +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
                                    



                                    На мои 800гб корневого пула, вообще не оптимизированного для dedup (а также 230гб бекапов с размером блока 1МБ) он дал всего лишь коэффициент 1.18, при этом на DDT потребуется 10.8М*320=3456мб ОЗУ. Оракл не рекомендует включать дедупликацию при коэффициенте меньше 2, я с ними полностью согласен.

                                    Дедупликация — это прекрасно, но практически бесплатное lz4 сжатие (а для большинства HDD оно только ускоряет) в случае неповторяющихся данных намного целесообразнее.

                                    Полезная ссылка.
                                    • 0
                                      Мне, кажется, столько большая константа (320, когда достаточно не более 8+4 на dataHash+blockID) портит всю малину. 1-2 гигабайта на 10ТБ было бы no-brainer, а так… Но это, конечно, лишь мои фантазии, наверняка у разработчиков были свои причины, из-за которых вышло 320.
                                      • 0
                                        Стоит уточнить цифры для ZFS:
                                        — используемый sha256 (ваш dataHash) = 32 байт
                                        — block pointer (ваш blockID) (blkptr_t) = 128 байт

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

                                        Причина такого большого block pointer кроется в самой идее ZFS, и от этого никуда не деться. По этому базовый блок 128кб, он позволяет уменьшить накладные расходы. Больше блок — меньше накладные расходы, но при чтении файла с размером больше блока придётся прочитать ещё 1 полный блок (где находится окончание файла).
                                        • +1
                                          используемый sha256 (ваш dataHash) = 32 байт
                                          но зачем хранить весь sha256 в оперативке? достаточно было бы первые 4-8 байт, а в случае коллизий уже пересчитывать полный. То же самое с block pointer, можно было бы пересчитывать сокращённую форму в blkptr_t налету.
                                          • 0
                                            А зачем весь blkptr_t, не достаточно было бы blk_dva (32 байта)? Можно ли хранить не blkptr_t/blk_dva а только смещение на адрес, по которому этот самый blkptr_t можно узнать/вычислить?
                                            • +2

                                              Мне нравится ваш ход мыслей! :)
                                              По предложениям ответить не могу, т.к. в нутра этой части не лазил, но мы всегда открыты к предложениям! Если готовы — можете внести свои предложения в виде issue, или сразу пулл реквестом, помогу с любым вопросом в части оформления, а другие участники всегда подскажут по коду, сообщество очень доброжелательное.

                            • 0

                              обязательно пишите! — мы все очень сильно ждем :)

                              • 0

                                Вопрос, ответ на который кажется очевидным, но всё же. Если ZFS+дедупликацию использовать для хранения несжатых бэкапов Proxmox на самом сервере — какие ресурсы это потребует, с учётом того что коэффициент будет наверняка очень высоким, сохранится ли 20 гигабайт на терабайт данных, не будет ли проблем с самим проксмоксом? Сервер 48 гигабайт РАМ+терабайт SATA (ZFS) +2x200 SSD — сможет ли справиться с этой задачей без больших потерь памяти? Стоит ли включить дедупликацию на SSD, где лежат образы виртуалок?
                                Вопрос навеян Вашим комментарием "Не советую применять дедупликацию в ZFS где-либо, кроме промышленного файлового хранилища".

                                • 0
                                  Для бекапов можно еще рассмотреть вариант snapshot + zfs send, тогда и без дедупликации все ок.
                                  • +1

                                    Всё верно, в таком случае используется snapshot, он позволяет создавать инкрементальные срезы хоть каждую минуту. Но сразу оговорюсь, что не стоит подменять им полноценный бекап на другую машину (а в таком случае снапшоты также прекрасно передаются по сети в инкрементальном режиме).


                                    Вообще, после zfs я уже не представляю, как можно жить без снапшотов и хеширования данных. На моей машине настроено создание снапшота всей системы раз в 15 минут, и это никак не влияет ни на производительность, ни на простои (см. https://github.com/zfsonlinux/zfs-auto-snapshot )


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

                                    • 0
                                      Буду очень ждать)
                      • 0

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

                        • 0
                          Сомнительно выглядит установка OMV и Proxmox на одну физическую систему. В виртуалку ставить ZFS не имеет никакого смысла по понятным причинам, а в вашем сетапе кто гарантирует, что кастомное ядро Proxmox будет нормально работать с нутром от OMV?
                          • +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

                            В остальном гарантий вам конечно же никто не даст, но для себя я проверил все работает как часы, что будет дальше? — поживем увидим :)

                          • 0
                            В свое время собирали Proxmox на ZFS для офиса. Были неприятно удивлены невозможности делать клоны машин со снапшотов (только с текущего состояния) и откатывать не до последнего снепшота. Судя по комментариям на форумах — это стандартное ограничение ZFS, из-за чего пришлось от него отказаться (сейчас CEPH). Может быть я что-то делал неправильно, или оно так у всех?
                            • 0
                              Сам ZFS позволяет делать clone со снапшотов (в рамках понятий ZFS), скорее всего это не реализовано в веб-интерфейсе proxmox (он также не видит созданные мной вручную снапшоты).
                            • 0
                              OMV 3.x весьма странное создание. ИМХО ему еще нужно время на стабилизацию состояния.
                              • 0
                                Вместо:
                                apt install build-essentials
                                

                                Нужно:
                                apt install build-essential
                                
                                • 0
                                  спасибо, исправил

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.