• ZFS: архитектура, особенности и отличия от других файловых систем
    0
    Советую еще посмотреть TrueNas core (бывший Freenas), эта ОС тоже отлично подойдет для хранения ZFS реплик и может полностью забрать на себя вопросы создания снимков на удаленных хостах и их репликацию по расписанию.

    Тулинг для реплик в последней версии обновили. Там можно настроить все мыслимые опции,
    * можно задать реплику дерева датасетов, но исключить конкретные узлы.
    * можно использовать реплицировать ТОЛЬКО уже имеющиеся на проде снимки, либо делать снимки по расписанию и сразу их реплицировать.
    * можно автоматизировать удаление старых (сделанных утилитой) снимков на проде, а на сервере бэкапов их оставить.
    * можно делать бэкап с удаленного сервера на удаленный сервер, с удаленного сервера на на локальный, или с локального на удаленный. Главное чтобы был доступ по SSH и ZFS. Бэкап с Proxmox на локальный пул Freenas работает.
    * можно добавить создание закладок ZFS на проде для снимков, которые используются для реплик, чтобы если вдруг на боевом сервере почистят снимки и удалят последний релицированный снимок, все равно можно было бы продолжить репликацию. Иначе пришлось бы создавать новую резервную копию
    * можно настроить уведомления на почту, в случае проблем с заданиями репликации
  • Кластеризация в Proxmox VE
    0
    Если использовать ZFS в качестве файловой системы на нодах, то есть вариант обойтись без общего хранилища. Можно настроить ассинхронную репликацию + HA. Если нода выйдет из строя, PVE кластер запустит ее копию на реплике, при этом будут потеряны последние пару минут (зависит от частоты реплик).
    Хороший вариант, во многих случаях.
  • Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
    +1
    Вы правы, я ошибся. Нашел хороший материал, который это подтвердил 1
    Хороший материал 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» Источник

    Спасибо за терпение, и обсуждение, я проголосую за ваши комментарии!

  • Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
  • Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
  • Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
    0
    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. Не верным переводом.
  • Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
    0
    1) lz4 «бесплатный», более того по многочисленным тестам lz4 ускоряет чтение\запись за счет того, что в тот же raw объем помещается больше «логического объема» данных.
    2) сжатие внутри бд и внутри файловой системы — это разные вещи разные уровни. Чтобы это понять, нужно представлять как работает любая COW файловая система. Файлы в ней не представляют собой «кусок диска» который был изначально захвачен базой (при последовательном доступе к диску). Copy-on-Write пишет в свободные блоки (в другое место на диске) при ЛЮБОМ изменении части исходных файлов (блоков).
  • Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE
    –1
    Не верное. ARC — это вид кэша, к записи он отношение не имеет. Sync в ZFS вернет факт записи в ZIL, то есть на диск. Где вас таких делают?
  • Секреты сборки и пересылка SSH в Docker 18.09
    +3
    Как всегда актуальная и качественная информация, спасибо, вы лучшие! Недавно я побывал на 2х ваших слёрмах и остался крайне доволен. Вы имеете и успешно применяете хорошие практики, используете оркестранты для декларативного описания инфраструктуры, такого обширного мониторинга как у вас я еще не видел (моя больная тема), когда видишь, что у кого-то получается, это вдохновляет!
  • Детальный разбор того, что Google показал на конференции FlutterLive (и что это значит для Dart и мира)
    0
    Если нужно, чтобы компоненты выглядели нативно, то нужно писать свой UI под каждую платформу.
  • Еще один способ увидеть коммуникации приложений
    0
    Спасибо, пригодится!
  • Производительность mdadm raid 5,6,10 и ZFS zraid, zraid2, ZFS striped mirror
    +1
    Во-первых, спасибо за проделанную работу! Я теперь хотя бы знаю как в линуксе можно тестировать файловые системы!
    Во-вторых, прошу вас напишите, что ZFS хоть и медленная при записи (быстрая при чтении), но обладает огромным преимуществом перед классическими файловыми системами. Механизмом снимков и COW дизайном.

    Собственно из-за некоторых из преимуществ у нее такая медленная запись, т.к. она имеет транзакционную природу и запись производится в несколько этапов. Для особых случаев, где важна и скорость и надежность данных, можно добавить Intel Optane в пул ZFS, в качестве Log устройства.

    То есть я хочу сказать, что скорость не всегда главное и вы можете отпугнуть людей. Часто ZFS работает «достаточно» быстро и в этом случае не вижу причин ее не использовать.

    Сравнение было бы более корректно с любой другой COW файловой системой со встроенными снимками или с LVM + рэйд

    Снимки и надежность очень важны!
  • Что такое виртуализация и как работает виртуальный сервер
    0
    Это может быть так. Но это не обязательно так.
    Автор хочет показать основные принципы, а придраться к словам может любой «профессионал». Я думаю, что если бы автор описал все тонкости, это была бы другая статья.
  • Анонсирована новая версия MongoDB: будет апдейт безопасности и свежие инструменты
    0
    Естественно. Это проблема такой сложности, что кажется ее невозможно решить :)
  • Анонсирована новая версия MongoDB: будет апдейт безопасности и свежие инструменты
    0
    Самое «вкусное» забыли. $lookup теперь может быть с условием (передача pipeline, т.е. можно использовать всю мощь aggregation framework в условии)
  • Обзор нового высокопроизводительного RDP кодека
    0
    К сожалению, коммерческие системы виртуализации, такие, как Hyper-V, ESXI нельзя настроить на проброс видеокарт, не предназначенных для этого. Это договоренность производителей видеокарт и гипервизоров.

    Вам нужен гипервизор KVM. Для простоты советую использовать Proxmox (это такой законченный продукт для виртуализации, использующей KVM).

    Про то, как пробрасывать видеокарту внутрь KVM почитайте тут:
    habrahabr.ru/post/339456

    PS: Xen тоже это позволяет, но как гипервизор он для меня давно умер…
  • Обзор нового высокопроизводительного RDP кодека
    0
    Нужно решить 2 проблемы:
    1) Виртуализация с поддержкой проброса видеокарты
    2) Не лагающий стриминг.

    Решения:
    1) Proxmox — на хабре уже печатали статьи об этом гипервизоре и о том, как пробрасывать видеокарту внутрь VM
    2) Steam трансляции — безоговорочный лидер для игр. Попробуйте, между 2 обычными компами. Никаких лагов, все летает. Кроме того в отличие от RDP, игры не будут капризничать.
  • Обзор нового высокопроизводительного RDP кодека
    0
    К сожалению не смог найти достоверной информации, но мне кажется, что вы правы.
    Думаю со временем это перестанет быть проблемой, потому, что в рамках экосистемы Windows 10 — мажорные обновления бесплатны и появляются раз в пол года.

    Часы тикают и рано или поздно любая ОС от Microsoft, установленная на компьютер, будет Windows 10
  • Обзор нового высокопроизводительного RDP кодека
    0
    Боюсь, что для энерго-эффективного процессора ноутбука может быть сложно захватывать видео и рендерить RDP FullHD. К сожалению у меня нет отдельной платы видео захвата.
    Не исключаю, что VNC в игровых сценариях может работать лучше… Но я все равно остался крайне доволен. Старый и новый RDP — земля и небо. Поверьте. К тому же все шрифты и текст теперь пиксель-в-пиксель. Ничего не раздражает глаз. Реакция на нажатие в Word\Excel моментальная.

    Кстати, небольшой офтоп. Во время сравнения шрифтов и текста, я отчетливо понял, что мой 27 дюймовый IPS монитор от Acer несравненно хуже монитора жены. Dell Ultrasharp.
    Косые линии в SketchUp имеют на моем мониторе какую то рябь или стробицу.
    Думали, что проблема в RDP, оказалось в мониторе! Заказал себе новый монитор в магазине.
  • Обзор нового высокопроизводительного RDP кодека
    0
    Насчет тонких клиентов, думаю, что работать будет, когда обновят прошивку, так как MS умудрились сделать совместимость с обычными h264 кодерами\декодерами.
    Версия Windows10, где установлен RDP сервер должна быть самой свежей 1709. Посмотреть версию Windows можно при помощи winver (пуск — выполнить — winver)

    Кстати, забыл указать в статье, я пробовал клиент RDP из магазина Windows Store и к моему великому удивлению AVC444 кодек не запустился. RDP работало со старыми добрыми тормозами. Хотя я думаю, что если форсировать новый кодек на сервере, то все заработает.

    Принудительное включение кодека и его настройки можно выполнить через групповые политики.
    Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment

    Подробности здесь
  • Обзор нового высокопроизводительного RDP кодека
    0
    Я понял, но сжатие в RDP можно вообще выключить или настроить соотношение качество\скорость. По-умолчанию это соотношение = баланс.

    Думаю с появлением h264 у MS была дилемма, оставить как было, или использовать новый на тот момент «быстрый» кодек в ущерб качеству. Теперь такой дилеммы не стоит.
    Возрадуемся!
  • Обзор нового высокопроизводительного RDP кодека
    0
    Точнее вероятно он доступен, но как я писал в статье, раньше с ним были проблемы и он был отключен по-умолчанию!
  • Обзор нового высокопроизводительного RDP кодека
    0
    Windows Server 2016 получает обновления функций из LTS канала. Другими словами новый кодек все еще не доступен для сервера.
  • Обзор нового высокопроизводительного RDP кодека
    0
    После обновления сервера (ПК в вашем случае) тормоза должны исчезнуть!
  • Обзор нового высокопроизводительного RDP кодека
    0
    Возможно. Но не будем спорить о значениях слов… думаю мы оба правы.
    В любом случае, результат достойный.
    Не важно заслуга ли это кодека или чего то другого. Это работает!
  • Обзор нового высокопроизводительного RDP кодека
    0
    И еще h264 AVC444, это не h264. Он не должен быть четче за счет битрейда, на самом деле это практически h265 (backport, если хотите), которые имеет те же характеристики!

    Посмотрите первое видео из моей статьи и вы увидите, что в среднем на FullHD ролике, развернутом на весь экран, новый кодек требует в 2 раза меньшую полосу пропускания и работает существенно быстрее и четче.

    В сценариях повседневного использования разница между старым и новым кодеком будет в среднем еще выше! По моим прикидкам экономия полосы 60-80%
  • Обзор нового высокопроизводительного RDP кодека
    0
    Я конечно не специалист, но вот, что говорит сам Microsoft:
    cloudblogs.microsoft.com/enterprisemobility/2016/01/11/remote-desktop-protocol-rdp-10-avch-264-improvements-in-windows-10-and-windows-server-2016-technical-preview

    «As part of the AVC 444 mode in RDP 10 we solved the challenge to get 4:4:4 quality text with 4:2:0 hardware encoders / decoders. In addition, with the AVC 444 mode we were able to improve the frame throughput significantly, for example with 1440p we can achieve a consistent frame rates of up to 50 fps on standard hardware.»

    Так, что вы правы, не все так просто, и вероятно они решили попутно некоторое количество технических ребусов.
  • Обзор нового высокопроизводительного RDP кодека
    0
    Очень не дурно. Добавлю, что в вашем виджете скорость измеряется в MiB (мебибайтах). Это значит, что 1,6 MiB на виджете будет равно 12,8 Mbps. Учитывая не полноэкранное видео, не FullHD разрешение и много статических элементов, могу сказать, что RDP намного экономнее расходует канал.
  • Обзор нового высокопроизводительного RDP кодека
    0
    Так и отклик, это главное, что улучшилось! Возможно я не очень хорошо осветил это.
  • Обзор нового высокопроизводительного RDP кодека
    0
    Да, игровой компьютер до обновления работал на 1703. Виртуальные машины для тестов, я готовил с нуля. На всякий случай покажу как форсировать новый кодек, но вроде бы этого больше не требуется!
    habrastorage.org/webt/ty/m9/_r/tym9_rymm41f3y6l7izvxiwaftc.png
  • Обзор нового высокопроизводительного RDP кодека
    0
    Надеюсь данный скриншот ответит на большинство ваших вопросов!
    hsto.org/webt/hc/vx/t-/hcvxt-dxwpcafqjv8buqo95gkuu.png

    Дело в том, что RDP получает в свое распоряжение видеокарту хоста. Доступно вся мощь, я проверял, но есть одно «но». Некоторые программы очевидно просто не желают запускаться в RDP режиме.
    Запустить SketchUp в RDP я не смог! Мне пришлось запустить его в консольном сеансе, затем подключиться по RDP ^)
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    0
    Мне вот интересно, за что минусуют… написали бы, не поленились. Я искренне не понимаю.
    В чем проблема базы в контейнере? Ничего, кроме красоты нечеловеческой и гибкости мы не заметили… Напомню, это рабочий проект

    «Всегда считал, что данные не должны находиться в контейнерах.» Ну так напиши почему ты так считал!!! Мы же здесь не в гадалку собрались играть. (Заметьте, я никому минусы не ставлю, и стараюсь ответить максимально развернуто..)
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    –1
    Вы очевидно путаете контейнеры и Docker :)
    Контейнеры в практическом смысле тоже самое что виртуальные машины.
    Докер — очень своеобразная штука. Докер использует контейнеры, но можно сказать выворачивает «идею» наизнанку…

    Короче в сети есть мнение что docker = container. Это не так! Возможно я сделаю об этом отдельную статью.

    Контейнеры = виртуальные машины (если не брать во внимание «иллюзию» изоляции)

    Как это не печально, докер сдел так, что когда люди слышат слово «контейнер», они думают «докер». Черт возьми, как сильно они ошибаются!

    Почитайте как работают Linux Container (LXC) или FreeBSD jails! Мне очень повезло, я познакомился с Jails во FreeBSD еще до того как появился Docker и начал засирать мозги специалистам.
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    0
    Напомню, что в ZFS реплицируются снимки. Снимки в ZFS Read Only.
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    0
    То, о чем вы говорите, это уже репликация (репликацию можно сделать в другую файловую систему, в файл, или на удаленную площадку).
    С точки зрения практической ценности, описанное в статье можно называть клоном, который мы можем использовать в разработке и тестировании.

    Главное преимущество описано: не нагружает сервер и не занимает время.
    Я показал как можно использовать превосходную технологию. Вам решать когда и где :)
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    0
    Если у вас неприятность на проде, бакап делать уже поздно.

    В том то и дело, что не поздно. На проде делаются моментальные снимки каждый час по крону. Эти же снимки затем отправляются на бэкап ассинхронно.
    То есть ZFS дает нам возможность версионирования прода. Мы делаем клон с любого удобного снимка. То есть у нас так и так все карты на руках.
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    0
    Отчасти вы конечно же правы. Но вы снова забываете о контексте. Нельзя бездумно перенимать чужой опыт. Как я уже говорил, наш проект для внутренних нужд. Там нет персональных данных. Кроме того им занимается, внимание — 1 senior Fullstack .net программист, который является нашим сотрудником, работает fulltime. У него и так есть доступ ко многим вещам.
    И да, порой тесты и разработка гораздо эффективнее, когда работа идет с реальным данными.
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    +1
    Обычно dev/test разворачивают с бэкапа. (вы же их делаете?) Для разработки отставание клона в день-два не существенно.

    На самом деле последнее время так и происходит.

    Цепочка реплик выглядит так:
    Prod Server -> Backup Server (удаленная площадка) -> Hyper-V VM на ноутбуке разработчика

    Но зачастую держать отдельную машину для тестирования и разработки не имеет смысла. Например базы для тестирования мы получаем именно описанным мною в статье способом!

    Не забудьте, что база должна жить рядом с приложением! Если между ними будет высокий Latancy, будет худо.

    То есть я хочу сказать, простую вещь. Реплики то мы делаем, но на той стороне некому запустить базу и приложение, на это нужны громадные ресурсы, которыми не обладает наш Backup Server.
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    +4
    Я понял, вы придираетесь к мелочам, вместо того что бы оценить, а нужно ли то, что вы предлагаете разработчикам и тестировщикам? Всегда стоит конкретная задача, мы не делаем сферических коней в вакуме. Так вот, копия такого уровня консистентности, подходит как для разработки, так и для тестирования.

    Думаю, что проблема в понимании кроется еще и в том, что вы не работали с NoSQL базами. Там нет релляций. Коллекции данных не связаны базой данных так, как они были бы связаны в SQL. Логика сохранения консистентности частично обязана присутствовать в самом приложении в связи с этим. Архитектура такова.
  • Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности
    +1
    «Не говоря о том что ZFS сам по себе не быстр (но это уже offtop)»
    Да, есть нюансы, но их обсуждение потребует отдельной статьи. Знаете я очень много думал, а не перейти ли на другую файловую систему, скажем более быструю… Но каждый раз прихожу к тому, что слишком многое теряю в этом случае. Короче мое мнение: ZFS не самая быстрая, но точно самая надежная и одна из самых удобных! Я не отрицаю, что у ZFS есть недостатки, но ничего лучше я не видел.