Pull to refresh

Comments 28

Пора бы уже описывать процесс работы SnapMirror и SnapVault применительно к cluster-mode. Там репликация уже идет только на уровне томов. Но такой финт там тоже возможен. Правда команд чуть больше придется ввести.
Всему своё время. Мне было актуально именно для 7M, так что решил об этом написать.
Функционал zfs send|zfs receive анналогичен snapmirror. Используем в одном месте для баккапов.
При этом на получателе волумы в rw, можно использовать для распаковки или для запуска ВМ, достаточно только синхронизацию разорвать.
У самого дома есть RAID-Z, так что я в курсе :)

Не удивительно что некоторые функции WAFL так похожи (а к таким относятся снепшоты и построенная на них асинхронная репликация), ведь ZFS и WAFL используют некоторые общие технологии описанные в кросс-патентах StorageTek и NetApp. Компания StorageTek была в последующем выкуплена Sun Microsystems (ныне Oracle).

Так и вышло, что некоторые технологии NetApp попали в ZFS.
Если я правильно помню, то не столько некоторые технологии попали в zfs, сколько некоторые разработчики из нетапа ушли в Сторажтек/Сан, где создали продукт базово более развитый, чем wafl.
В наших нетапах до сих пор нет онлайн дедупликации и компресии без дедупа, а на zfs сторе и то и другое онлайн и включается независимо.
Вы меня искренне улыбнули.

Онлайн Дедубликация у Нетапа есть там, где это действительно нужно.
А сотрудники, так они вечно то туда, то обратно, кто же за ними уследит?
Что касается стореджтек, то там дело было не в уходе или «перебеге» сотрудников, а в том что Сан переккпил эту компанию до того, как нетап успел выкупить кроспатенты.
> Онлайн Дедубликация у Нетапа есть там, где это действительно нужно.
Не смешите меня маркетингом.
Дедуп нужен всем, даже в домашней файлопомойке сгодится, а вовсе не там, где нетап хочет его продавать.
Собственно zfs хороший тому пример: нужен дедуп? купи память, он у тебя будет.
Вам стоило бы больше узнать об WAFL.
К примеру:
  • про QoS работающим по IOPs и MB/s,
  • про API для интеграции со сторонним софом, таким как разнообразные БД, Виртаулизации, софтом по бекапированию и т.д для обеспечения конистентных, с точки зрения приложения, снепшотов.
  • про MetroCluster
  • про разного рода счетчики нагрузки на WAFL и разрезы их просмотра и бесплатные утилиты для построения графиков и отчётов
  • про бесплатный продукт (Oncommand Performance) позволяющие найти узкие места и устранить их
  • про внедрённые технологии Спинакера (SpinNP) сделавшие WAFL полноценной кластерной файловой системой
  • про то, как происходит запись на SSD

И ещё очень много чего спрятанного «за сценой». Просто в энтерпрайз эти вещи сами собой разумеющиеся и NetApp о них практически не говорит. И складывается впячетление типа: «Ха, так оно же в ZFS тоже есть» или «Ха, в ZFS есть онлайн дедубликация, а у WAFL её нет».

Прежде чем делать подобного рода заявления, вам стоило бы сначала попробовать соотнести «масштабы решений».

Мне нравится ZFS для домашней файлопомойки, в плане консистентности и не повреждаемости данных от зависаний и перезагрузок, так что ею в этом смысле очень доволен. Но в плане реализации и не глюкавости (собственно из-за чего происходят эти зависания и перезагрузки) пока что похвастаться нечем.
Как обычно, из всех заявленых фич, конечному пользователю может оказаться достаточно 20%.

Зависания и перезагрузки? Не видел. У нас нетап и zfs (коммерческие с поддержкой) сторы стоят буквально в соседних стойках. Для нас они практически идентичны по всем критическим показателям.
Нетап, не нетап — Главное чтобы вам было хорошо и вам подходило.

Про 20% таки да. Так наверное и есть. Только одним нужны одни 20%, другим — другие 20%, третьим — третьи.
А когда их нет то их нет — ни 20 ни 10.
И к стати если вы чем-то не пользуетесь потому что об этом не знаете, это не значит что оно «не нужно».
Это всего лишь значит что вы об этом не знаете и из-за этого не польуетесь.

Даже на своей домашней файлопомойке с линукс контейнерами я бы хотел иметь возможность нарезать QoS по IOPs. А ввиду способа записи на диск SSD и пока что не доступного для ZFS on LInux Trim, подключённый диск быстро убъётся. Я также не отказался бы от алгоритма упреждающего чтения. И т.д. и т.д. что уже годами есть на FAS системах.
> нарезать QoS по IOPs
Делается в esxi на уровне вм/диска.

>не доступного для ZFS on LInux Trim
Trim не нужен. Современные ssd избавились от этого костыля с помощью нормального хаускипинга.

> подключённый диск быстро убъётся
Третий год работает дома ocx vertex3 на убой, в качестве flashcache для виртуалок и торрентов (запись регулярно). До сих пор не убил половину ресурса. Можно не думать про ресурс. В сторах, кстати, анналогичные цифры получаются, ресурс по записи превышает время эксплуатации сервера/стора.

> Я также не отказался бы от алгоритма упреждающего чтения. И т.д. и т.д.
Это называется параноя. К реальным эксплуатационным характеристикам отношения не имеет.
L2ARC работает только на чтение, а вот хотелось бы на запись тоже. Только тогда стрёмно на счёт консистентности данных становится.

Вот когда я начал говорить тазисами «хотелок» вы наверное поняли глупость всей ситуации с ними?

Нарезать косы для дисковой подисстемы лучше на дисковой подсистеме. А не резать гланды через одно место, хотя кто же говорит, что этого физически нельзя сделать? К тому же у меня LXC, там с косами пока не так всё хорошо, а в комбинации с ZFS вообще не понятно.
Кроме того, когда у вас косы заданы на одной СХД это более удобно, чем ходить по разнородным хостам и настраивать его там.
> L2ARC работает только на чтение, а вот хотелось бы на запись тоже.
Вы не знаете или не умеете zfs: Cache device — на чтение, log device — на запись.
Если линух, то flashcache — все в одном.

> Только тогда стрёмно на счёт консистентности данных становится.
Это от незнания, полагаю.

> Вот когда я начал говорить тазисами «хотелок» вы наверное поняли глупость всей ситуации с ними?
Тут мысль вообще непонятная.

> Кроме того, когда у вас косы заданы на одной СХД это более удобно, чем ходить по разнородным хостам и настраивать его там.
Вы делаете мне смешно. У нас этих нетапов десятки, если уже не сотня. А все esxi администрируются из одной точки — vcenter.
Я вас удивлю наверное, но не у всех людей везде ESXi.

Если вы перестали меня понимать, то предлагаю на сим закончить этот разговор.
Что касается онлайн дедубликации, о каком маркетинге вы говорите?

Это опенсоурс комюнити встраивает всё что «хочется» не взирая на глюкавость и тормоза и для домашних решений, и это вполне даже нечиго. Кто-то же должен слать багрепорты?

А вот играки рынка СХД уровня ентерпрайз, такой логикой не руководствуются. Для продакшн СХД оффлайн дедубликации на обычных вращающихся дисках выполняет поставленные задачи. Онлайн дедубликация нужна для All-Flash СХД.

Так что внедрять технологию нужно только тогда, когда наберёт популярность All-Flash системы, т.е. сейчас.
> Это опенсоурс комюнити встраивает всё что «хочется» не взирая на глюкавость
Прежде, чем оно оказалось в опенсорсе, оно было в сторах от сана, ентерпрайзнее некуда.

> оффлайн дедубликации выполняет поставленные задачи
Ну да. Не влезает в maintenance window, например.
Требует запаса места на волуме, сначала мы разворачиваем виртуалки, потом ждем сутки пока дедуп их свернет. Удобно.

> Онлайн дедубликация нужна для All-Flash СХД.
У вас голова так забита маркетинговым булшитом, что очень трудно дискутировать. Вы на нетап, что-ли, работаете?
Дело не в маркетинге, а в объективной реальности. На низкоскоросных вращающихся дисках можно получить падение производительности от онлайн дедубликации — Овчинка выделки не стоит.

Одно дело хотелки, а другое нажёжность работы.

Онлайн дедубликация, чтобы не тормозила всю СХД нужно проделать не малую работу по оптимизации и тестированию. И если уж её делать, то на SSD дисках, которые нужно «беречь» от перезаписи. Всему своё время.

Пока нетап отдавал более низкие приоритеты на одни задачи, он ставил более приоритетные на другие задачи, к примеру на те что превёл выше.
> Онлайн дедубликация, чтобы не тормозила всю СХД нужно проделать не малую работу по оптимизации и тестированию.

Это опять какой-то маркетинговый бушлит. Что бы работала онлайн дедупликация нужна только память для хранения таблицы и немного проца. Нагрузка на реальные диски от этого не меняется. Более того, кеш/флешкеш используется более эффективно.
Ну может для вас это маркетинговый секрет, но производительность процов и количество памяти на СХД обычно напрямую связана с типами дисков под которые они расчитаны. Больше SSD — больше памяти и процессорной мошности и наоборот.

«Немного», это сколько?
Для домашней файлопомойки «немного» это одно, а для СХД с сотней и тысячей дисков это «немного», немного больше.
А можно узнать как в вашем понимание происходит процесс дедупликации?
В версии DataONTAP 8.3.1 появилась Inline детекция нулей и их дедубликация
В версии 8.3.2 появилась Inline дедубликация данных для FlashPool и AFF систем, что позволит продлить срок службы SSD дисков.
habrahabr.ru/post/270625
Ага, сегодня смотрел презентацию с московского представления нетапа, что было пару недель как.
Наконец в 8.3.1 анонсировали онлайн компрессию и дедуп не убивающие проц хранилки.
То, чем уже лет пять(?) я пользуюсь на ZFS сторах.
Да, в ZFS уже давно была компрессия. Всегда находятся компании, которые имеют веские агрументы использовать самую новую технологию. Для того чтобы мочь её использовать нужны кадры которые могут её сопровождать и в случае необходимости пофиксить. Ну или надеятся на лучшее. Иногда это вполне оправдано.

Важно отметить, что ZFS сама по себе очень перспективная и интересная файловая систем, но это файловая система а не СХД.
Есть компании, которые делают схд на базе zfs и осуществляют коммерческую поддержку.
Да, фич а-ля кластеризации нескольких сторов тут нет, но они нужны далеко не всем. Нам хватает банальной двухголовости, данные между разными сторами ездят редко и делаются средствами vsphere.
Я рад, что как минимум мы перестали сравнивать, скажем так: средний палец руки с тем, что он обозначает :)

Сравнивать СХД, которые используют файловую систему ZFS с NetApp FAS куда более интересно.
Only those users with full accounts are able to leave comments. Log in, please.