Комментарии к записи: Right-sized Usable Capacity для разных дисков

Автор: Расчет полезного пространства (usable space) от сырого (raw) для дискового массива Netapp | Системная архитектура и все-все-все

Thu, 10 Apr 2014 05:16:37 +0000

[...] x реальная_емкость_диска. Реальную емкость диска можно посмотреть тут. У нас получается 47 x 560ГБ = 26 [...]

Автор: romx

romx — Sat, 17 Dec 2011 12:58:53 +0000

В http://blog.aboutnetapp.ru/about
написан email: romx@mail.ru

Автор: Gera

Gera — Sat, 17 Dec 2011 12:53:22 +0000

Скажите, а как-бы к Вам на почту обратиться? ??ли в Скайп стукнуться?

Автор: Gera

Gera — Sat, 17 Dec 2011 12:49:22 +0000

Вау! ??нтереснейший документ оказался. Похоже я для себя найду там ответы на некоторое вопросы, которые не то чтобы меня мучили… так, раздражали. :-) Спасибо!

Автор: romx

romx — Sat, 17 Dec 2011 11:27:00 +0000

Gera:

Пробовать-то всегда лучше, но не всегда возможно, это во-первых, а во-вторых есть опасность не вытянуть все потенциально возможное, например просто не разобравшись с настройками и конфигурацией, ла много может быть причин. Особенно у начинающих с таким проблемы возникают. Опубликованные результаты все же проходят тщательный контроль методики, и там меньше опасности встретить явный факап конфигурации.

> Точное название приведите плиз, а то не могу найти в NOW…

tr-3838 Storage Subsystem Configuration Guide
Только он не в NOW а на fieldportal.

Автор: Gera

Gera — Sat, 17 Dec 2011 11:06:49 +0000

Я не очень доверяю различным подобного рода “опубликованным результатам” хотя бы в силу того, что в таких экспериментах есть масса нюансов, которые могут кардинально изменить картину. Предпочитаю все потрогать ручками в конкретных применениях.
Плюс к этому часто документы весьма противоречивы. В том-же NetApp-е в документации на Data ONTAP есть места, которые можно по разному понимать. Вот недавно наткнулся на подобное с FlexClon. В документации есть описание трех команд: vol clone create; lun clone create; clone. В последней явно указано, что требуется лицензия FlexClone. В первых двух про лицензии - молчек.
В общем лучше пробовать! :-)
На счет документа “Storage Subsystem FAQ”… Точное название приведите плиз, а то не могу найти в NOW…

Автор: romx

romx — Sat, 17 Dec 2011 10:43:25 +0000

Gera:

> К сожалению пока не удалось понаблюдать поведение системы с “медленными” дисками и FlashCash

Можно попробовать оценить и интерполировать согласно опублкованым результатам SPECsfs2008 и SPC-1/E

> А Вы откуда эти цифры взяли? С реальных систем?

??з Storage Subsystem FAQ, который в целом, к сожалению, недоступен для не-партнеров.

Автор: Gera

Gera — Sat, 17 Dec 2011 07:48:37 +0000

Да, про FlashCash знаю не по наслышке. ??спытывали на стенде у клиента с “быстрыми” (FC) дисками. В таком варианте использования FlashCash дал изумительную изоляцию очень приличной нагрузки по чтению на запись, скорость которой была критична для задач клиента. Со стороны записи (после “прогрева” FlashCash) это выглядело как будто вообще чтения не было.
К сожалению пока не удалось понаблюдать поведение системы с “медленными” дисками и FlashCash…
Про SSD… Если вычесть 1/9 для этих дисков zone checksum, то получается меньше чем у Вас. :-(
А Вы откуда эти цифры взяли? С реальных систем?

Автор: romx

romx — Sat, 17 Dec 2011 01:15:30 +0000

Gera:

> С SSD дисками мне дела иметь не приходилось, но вдруг попадется клиент богатый! :-) Расскажите, почему с SSD дисками у нас с вами получается разница существенная?

Не знаю, но при наличии FlashCache можно SSD у NetApp просто игнорировать. Это специальное решение для узкой конкретной задачи. Вот видите, я даже не знаю почему. Подозреваю, что причина там та же, что у SATA, вынужденное использование схемы 8+1 (zone checksum) из- за конструктивной невозможности использовать сектор произвольного размера.

Автор: Gera

Gera — Fri, 16 Dec 2011 20:13:26 +0000

Хм… Я был уверен, что эти 8 байт не влияют столь значительно… :-/ Мне казалось что это расширение идет исключительно за счет “внутренних” резервов. Ну типа все равно место на дорожке под 0 не используют…
Спасибо за науку! Буду и для FC/SAS дисков учитывать дополнительные 1,8%.
С SSD дисками мне дела иметь не приходилось, но вдруг попадется клиент богатый! :-) Расскажите, почему с SSD дисками у нас с вами получается разница существенная? Я, считая по моему прикидочному алгоритму, получаю 100 GB = 100*10^9 / (1024*1024*1024)= 93,13 GiB Даже вычитание 1,8% не помогает… :-( Разница то почти 10%…