Проблем со скоростью или стабильностью не было.
Мы заметили только плюсы, но у нас не высоконагруженный сервер.
Traefik максимально простой, в отличие от nginx ничего не кэширует. В Nginx приходилось добавлять страницу index в исключения, т.к. кэширование этой страницы ломает SPA приложение.
Советую еще посмотреть TrueNas core (бывший Freenas), эта ОС тоже отлично подойдет для хранения ZFS реплик и может полностью забрать на себя вопросы создания снимков на удаленных хостах и их репликацию по расписанию.
Тулинг для реплик в последней версии обновили. Там можно настроить все мыслимые опции,
* можно задать реплику дерева датасетов, но исключить конкретные узлы.
* можно использовать реплицировать ТОЛЬКО уже имеющиеся на проде снимки, либо делать снимки по расписанию и сразу их реплицировать.
* можно автоматизировать удаление старых (сделанных утилитой) снимков на проде, а на сервере бэкапов их оставить.
* можно делать бэкап с удаленного сервера на удаленный сервер, с удаленного сервера на на локальный, или с локального на удаленный. Главное чтобы был доступ по SSH и ZFS. Бэкап с Proxmox на локальный пул Freenas работает.
* можно добавить создание закладок ZFS на проде для снимков, которые используются для реплик, чтобы если вдруг на боевом сервере почистят снимки и удалят последний релицированный снимок, все равно можно было бы продолжить репликацию. Иначе пришлось бы создавать новую резервную копию
* можно настроить уведомления на почту, в случае проблем с заданиями репликации
Если использовать ZFS в качестве файловой системы на нодах, то есть вариант обойтись без общего хранилища. Можно настроить ассинхронную репликацию + HA. Если нода выйдет из строя, PVE кластер запустит ее копию на реплике, при этом будут потеряны последние пару минут (зависит от частоты реплик).
Хороший вариант, во многих случаях.
Однако возможно в вашем описании так же имеются не точности. Например, довольно важный факт, вынесенный из статьи: данные из ZIL никогда не читаются. (не перемещаются из ZIL в пул)
При штатной работе сервера (без аварий) записи попадают в пул из ОЗУ группами транзакций, независимо от того были ли они синхронными или асинхронными.
Т.е ZIL не собирает транзакции, не кэширует, и читается только во время аварии. В ZIL дублируются синхронные операции, и там остаются на случай аварии.
Меня сбили с толку (а вдруг не сбили, вдруг так и есть?) статьи в которых говорится, что в ZIL пишется ALL DATA: (Пример 1)
By default, the short-term ZIL storage exists on the same hard disks as the long-term pool storage at the expense of all data being written to disk twice: once to the short-term ZIL and again across the long-term pool Источник (Пример 2)
The ZFS Intent Log is a logging mechanism where all the of data to be written is stored, then later flushed as a transactional write. Источник (Пример 3)
Иллюстрирует что при выключенном SYNC — ZIL просто переходит в RAM область.
«So, if that's the case, then what exactly is going on? Well, there actually resides a ZIL in RAM when you enable „sync=disabled“ on your dataset» Источник
Спасибо за терпение, и обсуждение, я проголосую за ваши комментарии!
ZIL не может не использоваться — это базовая часть ZFS.
В случае sync — операция будет зафиксирована на диске, а уже потом вернется ответ (поведение по умолчанию sync=on). Так же доступны опции sync=off — когда sync фактически игнорируется и записи кладутся на диск группами транзакций и sync=always — когда каждая транзакция кладется на диск, без всяких sync.
ZIL со включенным sync дает преимущества асинхронной записи.
ZIL не фиксирует только метаданные
ZIL не служит для ускорения, наоборот он замедляет работу системы, он служит для надежности.
Ознакомьтесь для начала с этим: www.ixsystems.com/blog/o-slog-not-slog-best-configure-zfs-intent-log
И перестаньте читать рунет — он заполонен бредом относительно ZIL и sync в ZFS. Не верным переводом.
1) lz4 «бесплатный», более того по многочисленным тестам lz4 ускоряет чтение\запись за счет того, что в тот же raw объем помещается больше «логического объема» данных.
2) сжатие внутри бд и внутри файловой системы — это разные вещи разные уровни. Чтобы это понять, нужно представлять как работает любая COW файловая система. Файлы в ней не представляют собой «кусок диска» который был изначально захвачен базой (при последовательном доступе к диску). Copy-on-Write пишет в свободные блоки (в другое место на диске) при ЛЮБОМ изменении части исходных файлов (блоков).
Как всегда актуальная и качественная информация, спасибо, вы лучшие! Недавно я побывал на 2х ваших слёрмах и остался крайне доволен. Вы имеете и успешно применяете хорошие практики, используете оркестранты для декларативного описания инфраструктуры, такого обширного мониторинга как у вас я еще не видел (моя больная тема), когда видишь, что у кого-то получается, это вдохновляет!
Во-первых, спасибо за проделанную работу! Я теперь хотя бы знаю как в линуксе можно тестировать файловые системы!
Во-вторых, прошу вас напишите, что ZFS хоть и медленная при записи (быстрая при чтении), но обладает огромным преимуществом перед классическими файловыми системами. Механизмом снимков и COW дизайном.
Собственно из-за некоторых из преимуществ у нее такая медленная запись, т.к. она имеет транзакционную природу и запись производится в несколько этапов. Для особых случаев, где важна и скорость и надежность данных, можно добавить Intel Optane в пул ZFS, в качестве Log устройства.
То есть я хочу сказать, что скорость не всегда главное и вы можете отпугнуть людей. Часто ZFS работает «достаточно» быстро и в этом случае не вижу причин ее не использовать.
Сравнение было бы более корректно с любой другой COW файловой системой со встроенными снимками или с LVM + рэйд
Это может быть так. Но это не обязательно так.
Автор хочет показать основные принципы, а придраться к словам может любой «профессионал». Я думаю, что если бы автор описал все тонкости, это была бы другая статья.
К сожалению, коммерческие системы виртуализации, такие, как Hyper-V, ESXI нельзя настроить на проброс видеокарт, не предназначенных для этого. Это договоренность производителей видеокарт и гипервизоров.
Вам нужен гипервизор KVM. Для простоты советую использовать Proxmox (это такой законченный продукт для виртуализации, использующей KVM).
Нужно решить 2 проблемы:
1) Виртуализация с поддержкой проброса видеокарты
2) Не лагающий стриминг.
Решения:
1) Proxmox — на хабре уже печатали статьи об этом гипервизоре и о том, как пробрасывать видеокарту внутрь VM
2) Steam трансляции — безоговорочный лидер для игр. Попробуйте, между 2 обычными компами. Никаких лагов, все летает. Кроме того в отличие от RDP, игры не будут капризничать.
К сожалению не смог найти достоверной информации, но мне кажется, что вы правы.
Думаю со временем это перестанет быть проблемой, потому, что в рамках экосистемы Windows 10 — мажорные обновления бесплатны и появляются раз в пол года.
Часы тикают и рано или поздно любая ОС от Microsoft, установленная на компьютер, будет Windows 10
Мы заметили только плюсы, но у нас не высоконагруженный сервер.
Traefik максимально простой, в отличие от nginx ничего не кэширует. В Nginx приходилось добавлять страницу index в исключения, т.к. кэширование этой страницы ломает SPA приложение.
Тулинг для реплик в последней версии обновили. Там можно настроить все мыслимые опции,
* можно задать реплику дерева датасетов, но исключить конкретные узлы.
* можно использовать реплицировать ТОЛЬКО уже имеющиеся на проде снимки, либо делать снимки по расписанию и сразу их реплицировать.
* можно автоматизировать удаление старых (сделанных утилитой) снимков на проде, а на сервере бэкапов их оставить.
* можно делать бэкап с удаленного сервера на удаленный сервер, с удаленного сервера на на локальный, или с локального на удаленный. Главное чтобы был доступ по SSH и ZFS. Бэкап с Proxmox на локальный пул Freenas работает.
* можно добавить создание закладок ZFS на проде для снимков, которые используются для реплик, чтобы если вдруг на боевом сервере почистят снимки и удалят последний релицированный снимок, все равно можно было бы продолжить репликацию. Иначе пришлось бы создавать новую резервную копию
* можно настроить уведомления на почту, в случае проблем с заданиями репликации
Хороший вариант, во многих случаях.
Хороший материал 2
Однако возможно в вашем описании так же имеются не точности. Например, довольно важный факт, вынесенный из статьи: данные из ZIL никогда не читаются. (не перемещаются из ZIL в пул)
При штатной работе сервера (без аварий) записи попадают в пул из ОЗУ группами транзакций, независимо от того были ли они синхронными или асинхронными.
Т.е ZIL не собирает транзакции, не кэширует, и читается только во время аварии. В ZIL дублируются синхронные операции, и там остаются на случай аварии.
Меня сбили с толку (а вдруг не сбили, вдруг так и есть?) статьи в которых говорится, что в ZIL пишется ALL DATA:
(Пример 1)
By default, the short-term ZIL storage exists on the same hard disks as the long-term pool storage at the expense of all data being written to disk twice: once to the short-term ZIL and again across the long-term pool Источник
(Пример 2)
The ZFS Intent Log is a logging mechanism where all the of data to be written is stored, then later flushed as a transactional write. Источник
(Пример 3)
Иллюстрирует что при выключенном SYNC — ZIL просто переходит в RAM область.
«So, if that's the case, then what exactly is going on? Well, there actually resides a ZIL in RAM when you enable „sync=disabled“ on your dataset» Источник
Спасибо за терпение, и обсуждение, я проголосую за ваши комментарии!
В случае sync — операция будет зафиксирована на диске, а уже потом вернется ответ (поведение по умолчанию sync=on). Так же доступны опции sync=off — когда sync фактически игнорируется и записи кладутся на диск группами транзакций и sync=always — когда каждая транзакция кладется на диск, без всяких sync.
ZIL со включенным sync дает преимущества асинхронной записи.
ZIL не фиксирует только метаданные
ZIL не служит для ускорения, наоборот он замедляет работу системы, он служит для надежности.
Ознакомьтесь для начала с этим: www.ixsystems.com/blog/o-slog-not-slog-best-configure-zfs-intent-log
И перестаньте читать рунет — он заполонен бредом относительно ZIL и sync в ZFS. Не верным переводом.
2) сжатие внутри бд и внутри файловой системы — это разные вещи разные уровни. Чтобы это понять, нужно представлять как работает любая COW файловая система. Файлы в ней не представляют собой «кусок диска» который был изначально захвачен базой (при последовательном доступе к диску). Copy-on-Write пишет в свободные блоки (в другое место на диске) при ЛЮБОМ изменении части исходных файлов (блоков).
Во-вторых, прошу вас напишите, что ZFS хоть и медленная при записи (быстрая при чтении), но обладает огромным преимуществом перед классическими файловыми системами. Механизмом снимков и COW дизайном.
Собственно из-за некоторых из преимуществ у нее такая медленная запись, т.к. она имеет транзакционную природу и запись производится в несколько этапов. Для особых случаев, где важна и скорость и надежность данных, можно добавить Intel Optane в пул ZFS, в качестве Log устройства.
То есть я хочу сказать, что скорость не всегда главное и вы можете отпугнуть людей. Часто ZFS работает «достаточно» быстро и в этом случае не вижу причин ее не использовать.
Сравнение было бы более корректно с любой другой COW файловой системой со встроенными снимками или с LVM + рэйд
Снимки и надежность очень важны!
Автор хочет показать основные принципы, а придраться к словам может любой «профессионал». Я думаю, что если бы автор описал все тонкости, это была бы другая статья.
Вам нужен гипервизор KVM. Для простоты советую использовать Proxmox (это такой законченный продукт для виртуализации, использующей KVM).
Про то, как пробрасывать видеокарту внутрь KVM почитайте тут:
habrahabr.ru/post/339456
PS: Xen тоже это позволяет, но как гипервизор он для меня давно умер…
1) Виртуализация с поддержкой проброса видеокарты
2) Не лагающий стриминг.
Решения:
1) Proxmox — на хабре уже печатали статьи об этом гипервизоре и о том, как пробрасывать видеокарту внутрь VM
2) Steam трансляции — безоговорочный лидер для игр. Попробуйте, между 2 обычными компами. Никаких лагов, все летает. Кроме того в отличие от RDP, игры не будут капризничать.
Думаю со временем это перестанет быть проблемой, потому, что в рамках экосистемы Windows 10 — мажорные обновления бесплатны и появляются раз в пол года.
Часы тикают и рано или поздно любая ОС от Microsoft, установленная на компьютер, будет Windows 10