Что касается онлайн дедубликации, о каком маркетинге вы говорите?
Это опенсоурс комюнити встраивает всё что «хочется» не взирая на глюкавость и тормоза и для домашних решений, и это вполне даже нечиго. Кто-то же должен слать багрепорты?
А вот играки рынка СХД уровня ентерпрайз, такой логикой не руководствуются. Для продакшн СХД оффлайн дедубликации на обычных вращающихся дисках выполняет поставленные задачи. Онлайн дедубликация нужна для All-Flash СХД.
Так что внедрять технологию нужно только тогда, когда наберёт популярность All-Flash системы, т.е. сейчас.
про API для интеграции со сторонним софом, таким как разнообразные БД, Виртаулизации, софтом по бекапированию и т.д для обеспечения конистентных, с точки зрения приложения, снепшотов.
про MetroCluster
про разного рода счетчики нагрузки на WAFL и разрезы их просмотра и бесплатные утилиты для построения графиков и отчётов
про бесплатный продукт (Oncommand Performance) позволяющие найти узкие места и устранить их
про внедрённые технологии Спинакера (SpinNP) сделавшие WAFL полноценной кластерной файловой системой
про то, как происходит запись на SSD
И ещё очень много чего спрятанного «за сценой». Просто в энтерпрайз эти вещи сами собой разумеющиеся и NetApp о них практически не говорит. И складывается впячетление типа: «Ха, так оно же в ZFS тоже есть» или «Ха, в ZFS есть онлайн дедубликация, а у WAFL её нет».
Прежде чем делать подобного рода заявления, вам стоило бы сначала попробовать соотнести «масштабы решений».
Мне нравится ZFS для домашней файлопомойки, в плане консистентности и не повреждаемости данных от зависаний и перезагрузок, так что ею в этом смысле очень доволен. Но в плане реализации и не глюкавости (собственно из-за чего происходят эти зависания и перезагрузки) пока что похвастаться нечем.
Онлайн Дедубликация у Нетапа есть там, где это действительно нужно.
А сотрудники, так они вечно то туда, то обратно, кто же за ними уследит?
Что касается стореджтек, то там дело было не в уходе или «перебеге» сотрудников, а в том что Сан переккпил эту компанию до того, как нетап успел выкупить кроспатенты.
Не удивительно что некоторые функции WAFL так похожи (а к таким относятся снепшоты и построенная на них асинхронная репликация), ведь ZFS и WAFL используют некоторые общие технологии описанные в кросс-патентах StorageTek и NetApp. Компания StorageTek была в последующем выкуплена Sun Microsystems (ныне Oracle).
Так и вышло, что некоторые технологии NetApp попали в ZFS.
Так подробно я расписываю для того, чтобы люди понимали не только о том, что рекомендации есть, но также и откуда они проистекают. Понимание сути вопроса помогает более интеллектуально решать задачи.
А цена на SSD диски сегодня одна, завтра другая — короче всё может поменяться. Поэтому вопрос, стоит ли хранить vSwap (тип 1) на SSD датасторе, может быть пересмотрен в будущем или в индивидуальном порядке.
Так что надеюсь, что статья достаточно универсальная, чтобы быть актуальной в течении ближайших пары лет.
Ну когда система взята на вооружение крупными датацентрами, они много багфиксят или репортят о багах.
И обычно всё начинается с датацентров, а потом плавно спускается до компаний из 50 сотрудников, так было с виртуалдизацией серверов.
И вот тот момент, когда пора технологии спускаться, это когда датацентры отладили, довольны и пишут стати о ней ;)
Спасибо. Конкретно эта стать, это рекомендации для работы VMware с масивами NetApp.
У массивов NetApp рекомендации производителя для работы с мультипасингом именно такие. Позже дам ссылку на KB.
Иногда есть «Общие правила», а ингода есть более «часные» правила, которые перекрывают первые, это как раз тот случай.
Стоит также отметить, что системы с CoW часто требуют специально выделенной области под снепшоты, жестко заданного размера.
Т.е. использует ваш снепшот этот резерв, не использует или использует не на полную — не важно — место зарезервировано.
В то время, как снепшоты нетапа вовсе не требуют наличия заранее заданного пространства. Если лун у нас толстый, а для снепшота не хватает пространства он не снимиться, запуститься механизм (если включён) автоудаления снепшотов (гибко настраивается). Это не задействованное пространство может быть использовано, к примеру под снепшоты от другого вольюма (которому это может быть «больше нужно»), это определённая гибкость и экономия.
Здесь нужно разделить ситуацию на два момента: используется ли thing provisioning или не используется.
Если thing Provisioning не используется, то ситуация «со снепшотами у нетапа», будет аналогична — лун будет продолжать работать, а снепшоты не смогут сниматься.
Вопрос со снепшотами нетапа более комплексный на самом деле.
Так к примеру если включить на вольюме механизм Snapshot Autodelete, он будет удалять старые снепшоты, перед тем как снять новые если место закончилось.
Если вы сравниваете ситуацию с «нового места» у вас нет, то сравнивайте её с тем, что его нет и для вашего LUN на CoW иначе это не корректное сравнение.
COW это стратегия, которая может применяться как на блочных устройствах так и н файловых системах.
Момент заключается в том, что когда мы имеем один снепшот, то данные которые к нему относяться в первоначальный момент остаются на своих местах и ещё не перемещены в «резерв». Это отложенное действие которое будет выполнено только с теми данными, к оторым будет обрашение на перезапись и только в тот момент они начнут копироваться, когда это обращение произойдёт (иначе снепшот снимался бы слишком долго). Типа pay-as-you-go.
Вот теперь представьте у вас есть первый снепшот, идут операции перезаписи, которые время от времени попадают на старые блоки данных из снепшота, это генерирует дополнительные операции на перенос этих данных. Теперь представьте что таких снапшотов два, три и т.д, каждый такой снепшот — и всё по-новому. Чем интенсивнее перезапись данных (которые попадают на блоки в снепшотах, ещё не перенесённых в резерв), тем больше паразитических операций. Чем больше снепшотов, тем больше вероятность, что такие данные будут относиться к снепшоту и ещё не будут перенесены.
Каждая операция записи при попадании на блок из снепшота будет генерировать дополнительную операцию на чтение старого блока и записи старого блока в новое место (резерв). Таким образом вместо одной операции имеем три.
В высоконагруженных системах типа Баз Данных это будет носить наиболее выраженный неприятный эффект: блоки обычно маленькие 8KB разбросаны то там то тут, а средний показатель перезаписи 30-50%. На вращающихся жестких дисках операции поиска будут занимать много времени + дополнительные две операции (тоже мелкими блоками) и соответственно сразу будут увеличиваться латенси, что для высоконагруженных систем, как паравило, очень заметно.
Многие производители пытаются оптимизировать эти операции различными путями (заранее залаживая больше производительности, добавляя кеши, оптимизируя чтение и запись), но архитектура COW изначально была создана с изъяном и по-прежнему достаточно сильно влияют на производительность.
IOMeter разбит на две части: собственно сам генератор нагрузки (Dinamo) и GUI интерфейс, которые могут связываться по сети. Так что можно генерировать нагрузку на линукс машине, а смотреть на винде. Или попробовать запустить GUI под Vine.
Это опенсоурс комюнити встраивает всё что «хочется» не взирая на глюкавость и тормоза и для домашних решений, и это вполне даже нечиго. Кто-то же должен слать багрепорты?
А вот играки рынка СХД уровня ентерпрайз, такой логикой не руководствуются. Для продакшн СХД оффлайн дедубликации на обычных вращающихся дисках выполняет поставленные задачи. Онлайн дедубликация нужна для All-Flash СХД.
Так что внедрять технологию нужно только тогда, когда наберёт популярность All-Flash системы, т.е. сейчас.
К примеру:
И ещё очень много чего спрятанного «за сценой». Просто в энтерпрайз эти вещи сами собой разумеющиеся и NetApp о них практически не говорит. И складывается впячетление типа: «Ха, так оно же в ZFS тоже есть» или «Ха, в ZFS есть онлайн дедубликация, а у WAFL её нет».
Прежде чем делать подобного рода заявления, вам стоило бы сначала попробовать соотнести «масштабы решений».
Мне нравится ZFS для домашней файлопомойки, в плане консистентности и не повреждаемости данных от зависаний и перезагрузок, так что ею в этом смысле очень доволен. Но в плане реализации и не глюкавости (собственно из-за чего происходят эти зависания и перезагрузки) пока что похвастаться нечем.
Онлайн Дедубликация у Нетапа есть там, где это действительно нужно.
А сотрудники, так они вечно то туда, то обратно, кто же за ними уследит?
Что касается стореджтек, то там дело было не в уходе или «перебеге» сотрудников, а в том что Сан переккпил эту компанию до того, как нетап успел выкупить кроспатенты.
Не удивительно что некоторые функции WAFL так похожи (а к таким относятся снепшоты и построенная на них асинхронная репликация), ведь ZFS и WAFL используют некоторые общие технологии описанные в кросс-патентах StorageTek и NetApp. Компания StorageTek была в последующем выкуплена Sun Microsystems (ныне Oracle).
Так и вышло, что некоторые технологии NetApp попали в ZFS.
А цена на SSD диски сегодня одна, завтра другая — короче всё может поменяться. Поэтому вопрос, стоит ли хранить vSwap (тип 1) на SSD датасторе, может быть пересмотрен в будущем или в индивидуальном порядке.
Так что надеюсь, что статья достаточно универсальная, чтобы быть актуальной в течении ближайших пары лет.
И обычно всё начинается с датацентров, а потом плавно спускается до компаний из 50 сотрудников, так было с виртуалдизацией серверов.
И вот тот момент, когда пора технологии спускаться, это когда датацентры отладили, довольны и пишут стати о ней ;)
Для доступа по второй ссылке нужен NetApp Now ID.
У массивов NetApp рекомендации производителя для работы с мультипасингом именно такие. Позже дам ссылку на KB.
Иногда есть «Общие правила», а ингода есть более «часные» правила, которые перекрывают первые, это как раз тот случай.
Т.е. использует ваш снепшот этот резерв, не использует или использует не на полную — не важно — место зарезервировано.
В то время, как снепшоты нетапа вовсе не требуют наличия заранее заданного пространства. Если лун у нас толстый, а для снепшота не хватает пространства он не снимиться, запуститься механизм (если включён) автоудаления снепшотов (гибко настраивается). Это не задействованное пространство может быть использовано, к примеру под снепшоты от другого вольюма (которому это может быть «больше нужно»), это определённая гибкость и экономия.
Если thing Provisioning не используется, то ситуация «со снепшотами у нетапа», будет аналогична — лун будет продолжать работать, а снепшоты не смогут сниматься.
Вопрос со снепшотами нетапа более комплексный на самом деле.
Так к примеру если включить на вольюме механизм Snapshot Autodelete, он будет удалять старые снепшоты, перед тем как снять новые если место закончилось.
Момент заключается в том, что когда мы имеем один снепшот, то данные которые к нему относяться в первоначальный момент остаются на своих местах и ещё не перемещены в «резерв». Это отложенное действие которое будет выполнено только с теми данными, к оторым будет обрашение на перезапись и только в тот момент они начнут копироваться, когда это обращение произойдёт (иначе снепшот снимался бы слишком долго). Типа pay-as-you-go.
Вот теперь представьте у вас есть первый снепшот, идут операции перезаписи, которые время от времени попадают на старые блоки данных из снепшота, это генерирует дополнительные операции на перенос этих данных. Теперь представьте что таких снапшотов два, три и т.д, каждый такой снепшот — и всё по-новому. Чем интенсивнее перезапись данных (которые попадают на блоки в снепшотах, ещё не перенесённых в резерв), тем больше паразитических операций. Чем больше снепшотов, тем больше вероятность, что такие данные будут относиться к снепшоту и ещё не будут перенесены.
Каждая операция записи при попадании на блок из снепшота будет генерировать дополнительную операцию на чтение старого блока и записи старого блока в новое место (резерв). Таким образом вместо одной операции имеем три.
В высоконагруженных системах типа Баз Данных это будет носить наиболее выраженный неприятный эффект: блоки обычно маленькие 8KB разбросаны то там то тут, а средний показатель перезаписи 30-50%. На вращающихся жестких дисках операции поиска будут занимать много времени + дополнительные две операции (тоже мелкими блоками) и соответственно сразу будут увеличиваться латенси, что для высоконагруженных систем, как паравило, очень заметно.
Многие производители пытаются оптимизировать эти операции различными путями (заранее залаживая больше производительности, добавляя кеши, оптимизируя чтение и запись), но архитектура COW изначально была создана с изъяном и по-прежнему достаточно сильно влияют на производительность.
Главное чтобы вы знали плюсы, минусы, были с ними согласны и довольны.