Pull to refresh

Comments 36

Я правильно понимаю, что на фотографии 14 винтов заняли 10U?
Нет, фотография просто стандартная «картинка для привлечения внимания» :)
На ней FAS2050 (под «полосатой» крышкой в нем 20 «встроенных» дисков SAS или SATA), ниже две полки расширения емкости DS14MK4, в каждой по 14 дисков FC. FAS2050 — 4U, DS14 — 3U

Это довольно старые и FAS, и полки.

Сегодня модно использовать FAS3000 (два контроллера в 3U или 6U, в зависимости от конфигурации), или FAS2040 (12 «встроенных» дисков SAS или SATA), плюс полки DS4243 — 24 диска 3,5" в 4U, или DS2246 — 24 диска 2,5" в 2U.
То есть, например, в 2U можно уместить 24 диска SAS 600GB, или в 4U — 24 диска SATA 2TB (в DS2246 только SAS, в DS4243 — SAS, SATA или SSD).

Плотнее, чем 24 HDD в 2U вроде никто еще не пакует.
А если всё хорошо и дедуплицированные данные занимают почти весь объём диска, но изменяется содержимое только одного файла и уже нет возможности «раздедуплицировть» его в этот же диск, а другого диска нету?
Не совсем понял вопрос.
Что делать, если мы используем дедупликацию, все место заняли, и какой-то раздел захотелось развернуть в «дуплицированный», исходный вид?

Ну а вы как думаете :) Конечно, чудес в данном случае нет, данные же где-то надо хранить.
Но «раздедупликация» это, во-первых, все же, по опыту, не слишком частая процедура, обычно оно случается либо сразу (свернули, и что-то не понравилось, тогда тут же на то же место что было и развернули), либо уж никогда (все хорошо, все работает, и ничего разворачивать не нужно).

Или я вас не так понял?
Вот цитата из этой же статьи:
> Все хорошо, пока какой-либо программе не понадобится изменить этот второй блок у любого из этих файлов. Изменив содержимое одного файла мы, тем самым, автоматически изменяем содержимое и второго файла…
>… А при необходимости записать изменение в данные файла, из пула свободных блоков выделяется место, куда производится запись

Я говорю про то, что память уже забита под завязку, а на этот самый «изменённый второй блок» пула свободных блоков не хватит?
У хорошего сисадмина не доходит до записи последнего 4KB-блока на диске ;)
На такой же вопрос потенциального клиента NetApp вы ответите так же?
А вы не тупая блондинка покупающая сумку Louis vuitton в ГУМ'е и правило «клиет всегда прав» тут не оправданно. Если вы ИТ специалист вы должны адекватно подходить к преобретению ИТ ресурсов.

Говорю вам как тот самый состоявшийся потонциальный клиет пользующийся почти всеми фичами данных стораждей (дедупликацией уж точно)
Что такое «ГУМ'е»?

Я, как придирчивый потенциальный клиент, хочу знать всё. И дело даже не в том, что нужно адекватно оценивать ресурсы — это безусловно. Но я хочу узнать как реагирует данное решение на пограничные ситуации.
При нехватке места, попытается расширить том, на котором лежат данные, если это позволено в свойстах тома, и есть место. Либо удалить какое-то количество снэпшотов и высвободить запертые в них блоки, либо, если ни то ни другое не вышло, перейти в offline с сообщением «нет места для записи».
Вот именно такого ответа я и ждал. Спасибо.
А чем это отличается от ситуации, когда приложение пытается дописать ещё 4КВ на полностью забитый диск? Получит OutOfStorageSpace какой-нибудь. Это уже проблемы клиентского софта — как обрабатывать закончившееся место на диске.
В том-то и дело, что ничем т.к. дедупликация оффлайновая и она ничего не разозмет так что места не хватит, а просто напишет, что не достаточно места :)
Ну давайте все же не доводит ситуацию до анекдотической истории про «японскую бензопилу и суровых сибирских мужиков»
Да, если ломать что-то, то оно сломается, кто б сомневался :)

Кстати говоря, данные при этом, как я написал amarao, не повреждаются, просто data offline, read-only
Да, кстати, вопрос, как обрабатывается ситуация OOM? Я имею в виду, ситуацию, когда место заканчивается в момент записи на уже существующие области (которые раньше были дедуплицированы, а теперь вдруг не стали).

Интересует практическое поведение, писала машина, писала, и… (допустим, речь про iscsi).
Тут есть несколько вариантов. Во первых volume, это та структура, которая несет на себе один или несколько LUN-ов, может автоматически расширяться (autogrow), если на вышележащей структуре, так называемом aggregate (в него объединены физические диски, максимальный размер aggregate для ONTAP 7 — 16TB, для ONTAP8 — в зависимости от модели (мощности) контроллера, вплоть до 100TB) есть свободное место для роста. Либо попытаться удалить снэпшоты (например самые ранние по времени создания, это настраивается, что, и в каком порядке).

Если «все запущено» до состояния «расти некуда, удалить нечего, а места все равно под запись нет», тогда LUN становится offline (и, если я правильно помню, может быть примонтирован как read-only), чтобы сохранить уже записанные данные в целости.
Кому интересны живые данные вместо усредненных маркетинговых, вот что у меня получилось:
Виртуалки Hyper-V поднятые не с нуля, а виртуализированные с физических, разные операционки и т.п.: 40% экономии
MS SQL Backup: 60% экономии
Каталоги пользователей: 24% экономии (жду сжатия там будет ещё круче)
Oracle: не дедуплицируется :)
Там еще стоит не забыть про то, что наличие снэпшотов ухудшает deduplication rate, то есть если у вас на диске взято изрядно снэпшотов, на момент первого запуска дедупликации, то блоки, запертые в снэпшотах, в дедупликацию не попадают и ей не обработаются.
Рекомендуется перед первым запуском дедупликации удалить снэпшоты, дедуплицировать, затем можно брать их снова, на дедуплицированном томе снэпшоты будут браться также дедуплицированные.
Да, точно. Важное замечание. Именно поэтому у меня снапшоты делаются после операции дедупликации.
Немножко не в тему. Есть ли решение для подключение нескольких серверов к одной корзине? HP storageworks 2000 позволяет подключить 4 FiberChannel, те 4 сервера. Хочется больше. Около 10, манагеры в магазинах — сильно тупят, им надо тупо продать.
Ну, это зависит от контроллера. Обычно в контроллере есть сколько-то портов, и если они не заняты, например дисковыми полками расширения, то в них можно напрямую, без коммутатора, включать хосты-сервера.
Портов 2 на контроллер (обычно контроллеров 2) серии FAS2000, либо 4 в FAS3100/3200, но части их может быть занята полками.

Но, если честно, выглядит это странно. Тут бывает или «экономим на всем», или «используем FC», вместе они у меня не складываются. :)
Если все так плохо, что нет денег на FC-коммутаторы, то может нафиг этот FC, почему бы не использовать iSCSI вместо него?

Если же идти прямым путем, и обязательно нужно FC, то вам нужно один или два (для отказоустойчивости) FC HBA в каждый сервер, суммарно это будет два по 10, плюс два порта — подключение стораджа.
11+11 используемых портов это 2 16-портовых коммутатора, каких-нибудь Brocade Silkworm 2x0E, или что-нибудь из QLogic.
Да у меня не очень понятная ситуация сложилось, до меня была закуплена куча серверов (с которыми уже увы придется работать) вместо 1 нормального блейда + корзины + коммутатора FC.
Сейчас мысль проста.
На 10 серверах запустить esxi, и использовать общую корзину для хранение образов + отдельный backup.

Вот и ищу решение для общего хранение образов виртуальных машин.
Может подскажите что нибудь? :), а то реально спросить некого, или форум на данную тематику.
Ну так как тема частная и оффтопик, то айдате в приват с этим.
Берите любую iSCSI полку, в зависимости от бюджета смотрите на резервирование контроллеров, multipath и т.д.
Полезная информативная статься. Спасибо.
Однако, не могу удержаться от небольшого «красноглазия»:
Такой механизм стал носить название субфайловой или блочной дедупликации. Он уже не реализуем на уровне стандартной UNIX-like файловой системы, так как линки в ней могут адресоваться только на файлы, причем на файлы в целом.
— в общем так, но некоторые файловые системы (вполне себе unix-like) могут и такое, например ZFS, хотя это не только ФС, строго говоря.
Могут, так как принцип работы у них аналогичный WAFL, но вот пока в «широкий продакшн» они не вышли, дедупликация на ZFS допилена только в этом году, а у NetApp использующих ее систем уже десятками тысяч по миру считают, так как в официальном продакшне дедупликация с 2007 года.
А кто спорит? :) Это я просто «для восстановления справедливости» написал. Не более того.
Кроме того отдаю себе отчет в различиях online и offline дедупликации, о которой в статье речь.
ZFS писали ушедшие в из NetApp инженеры ;)
Ну не знаю насчет этого, но то, что принципы (я верю в справедливость, и в то, что красть в чистом виде никто не крал) ZFS-ом перекатаны «один в один» очень тщательно и дотошно. :)
Ну что-ж, это только подтверждает правильность выбранного нетаппом решения в WAFL.
Да, под UNIX-like я все же имел ввиду «потомков Berkley's FFS», ZFS это все же совсем иной коленкор.
Согласен. Всё же выражение Unix-like предполагает весьма широкую трактовку, думаю не стоит на этом заострять внимание. Суть разлячия о котором мы говорим — файловая/блочная дедупликация. Это главное и этого, пожалуй, достаточно.
Простите, пост давно уже на хабре но постараюсь задать пару неудобных вопросов:

1 — В чем практическое отличие от ZFS на Solaris? (ключевое слово — «практическое»).
2 — Есть ли данные сравнения производительности Solaris(9) и систем NetApp?

Спасибо.
А чем эти вопросы «неудобные»? Или в смысле «неудобные» вам, оттого, что криво сформулированные? ;)

1. Не понял вопроса. Вы предлагаете сравнить софт (ZFS это файловая система, и только) и «железо», «аппаратный продукт», который много что делает кроме того, как несет на себе файловую систему.
Уточните что именно с чем именно вы хотите сравнить.

2. Опять же, что, с чем, и на чем сравниваем?
На NetApp нельзя поставить Solaris, поэтому сравнить только софт (Solaris это OS, софт, и только) невозможно.
Sign up to leave a comment.