Right-sized Usable Capacity для разных дисков
Я уже упоминал, что начиная с DataONTAP 7.3.1 емкость aggregate в системах NetApp FAS рассчитывается исходя из “правильной” usable емкости дисков, “после налогов и вычетов” и без учета дисков parity.
Вот каковы right-sized емкости используемых в системах NetApp дисков, исчисленных в “двоичных” единицах (по основанию 1024):
| Marketed Capacity | Right-sized Usable Capacity |
| 100 GB (SSD) | 84.574 MiB |
| 300 GB (FC/SAS) | 272.000 MiB |
| 450 GB (FC/SAS) | 418.000 MiB |
| 500 GB (SATA) | 423.111 MiB |
| 600 GB (FC/SAS) | 560.000 MiB |
| 1 TB (SATA) | 847.555 MiB |
| 2 GB (SATA) | 1.695.466 MiB |
При дальнейших расчетах также не забывайте про “основание 1024”, то есть, что
1695466 MiB = 1655,7 GiB = 1,62 TiB
При расчетах в “двоично-десятичной” арифметике для перехода от “мегабайтов” к “гигабайтам” недостаточно “сдвинуть запятую в числе на три позиции влево”, помните об этом . Разница между “терабайтом” и “тебибайтом” составляет почти 10%!
У меня при расчетах наблюдается небольшое расхождение. Я считаю так:
300 GB = 300*10^9 / (1024*1024*1024) = 279,396 GiB
Разница с Вашими 272 CiB (думаю, что указание на MiB в Вашей таблице - ошибка) небольшая, но тем не менее интересно откуда она берется? Поделитесь формулой!
Gera:
Вы еще два аспекта забыли. Во-первых, для дисков SAS сектор размером не 512, а 520 байт (+8 байт на каждые 512), а для дисков SATA плюс один полный сектор 512 байт на каждые 8 секторов по 512 байт. Во-вторых сам термин right-sized означает необходимое уменьшение по минимальному доступному для данного размера диску любого из поставляемых вендоров. Не секрет, что диски для систем хранения поставляются от разных производителей. Это и Seagate, и Hitachi, диски эти могут чуть-чуть отличаться по количеству секторов. Поэтому рекомендуется взять “наименьшее общее кратное” от всех поставляемых вендором системы хранения дисков данного размера, чтобы не оказаться в ситуации, когда на замену вышедшему из строя приехал диск другой модели, который на несколько (десятков, сотен) секторов меньше, чем те, из которых собран RAID, и новый диск в RAID не встанет.
Про SATA я помню, что необходимо вычесть еще 1/9 часть от полученного места (на сколько помню “zone checksum”?). Потому и привел пример именно с SAS дисками, где у нас с Вами было небольшое расхождение. А вот увеличение сектора до 520 байт на usable размер не должно бы влиять, так как эти 8 байт все равно для контрольной суммы используются (block cheksum - да?).
Спасибо за инфу про “необходимое уменьшение по минимальному доступному для данного размера диску любого из поставляемых вендоров”. Про это не знал и очень недоумевал почему Data ONTAP из показанных Physical 1736350304 секторов (для 1TB SATA) использует только 1735794176. В общем-то погрешность совсем маленькая - около 0,03%. При расчете клиенту количества необходимых дисков этим можно и пренебречь. :-)
Gera:
> А вот увеличение сектора до 520 байт на usable размер не должно бы влиять, так как эти 8 байт все равно для контрольной суммы используются (block cheksum - да?).
Нет, но они же, эти 8 байт на сектор ведь вычитаются из объема, в которых хранятся данные, вель эти 8 байт заняты служебной информацией, а не пользовательскими данными.
То есть, допустим, можно разместить 10240 пользовательских байт в 20 секторах при размере сектора 512 байт, и это займет ровно 10240 байт, или же в секторах размером 520 байт эти же 10240 пользовательских байт займут 10400 байт на диске, так как часть места будет занята служебной информацией секторов.
То есть использование сектора 512b data + 8b crc приводит к эквивалентному уменьшению доступной для данных места примерно на 1,8%
Хм… Я был уверен, что эти 8 байт не влияют столь значительно… :-/ Мне казалось что это расширение идет исключительно за счет “внутренних” резервов. Ну типа все равно место на дорожке под 0 не используют…
Спасибо за науку! Буду и для FC/SAS дисков учитывать дополнительные 1,8%.
С SSD дисками мне дела иметь не приходилось, но вдруг попадется клиент богатый! :-) Расскажите, почему с SSD дисками у нас с вами получается разница существенная? Я, считая по моему прикидочному алгоритму, получаю 100 GB = 100*10^9 / (1024*1024*1024)= 93,13 GiB Даже вычитание 1,8% не помогает… :-( Разница то почти 10%…
Gera:
> С SSD дисками мне дела иметь не приходилось, но вдруг попадется клиент богатый! :-) Расскажите, почему с SSD дисками у нас с вами получается разница существенная?
Не знаю, но при наличии FlashCache можно SSD у NetApp просто игнорировать. Это специальное решение для узкой конкретной задачи. Вот видите, я даже не знаю почему. Подозреваю, что причина там та же, что у SATA, вынужденное использование схемы 8+1 (zone checksum) из- за конструктивной невозможности использовать сектор произвольного размера.
Да, про FlashCash знаю не по наслышке. ??спытывали на стенде у клиента с “быстрыми” (FC) дисками. В таком варианте использования FlashCash дал изумительную изоляцию очень приличной нагрузки по чтению на запись, скорость которой была критична для задач клиента. Со стороны записи (после “прогрева” FlashCash) это выглядело как будто вообще чтения не было.
К сожалению пока не удалось понаблюдать поведение системы с “медленными” дисками и FlashCash…
Про SSD… Если вычесть 1/9 для этих дисков zone checksum, то получается меньше чем у Вас. :-(
А Вы откуда эти цифры взяли? С реальных систем?
Gera:
> К сожалению пока не удалось понаблюдать поведение системы с “медленными” дисками и FlashCash
Можно попробовать оценить и интерполировать согласно опублкованым результатам SPECsfs2008 и SPC-1/E
> А Вы откуда эти цифры взяли? С реальных систем?
??з Storage Subsystem FAQ, который в целом, к сожалению, недоступен для не-партнеров.
Я не очень доверяю различным подобного рода “опубликованным результатам” хотя бы в силу того, что в таких экспериментах есть масса нюансов, которые могут кардинально изменить картину. Предпочитаю все потрогать ручками в конкретных применениях.
Плюс к этому часто документы весьма противоречивы. В том-же NetApp-е в документации на Data ONTAP есть места, которые можно по разному понимать. Вот недавно наткнулся на подобное с FlexClon. В документации есть описание трех команд: vol clone create; lun clone create; clone. В последней явно указано, что требуется лицензия FlexClone. В первых двух про лицензии - молчек.
В общем лучше пробовать! :-)
На счет документа “Storage Subsystem FAQ”… Точное название приведите плиз, а то не могу найти в NOW…
Gera:
Пробовать-то всегда лучше, но не всегда возможно, это во-первых, а во-вторых есть опасность не вытянуть все потенциально возможное, например просто не разобравшись с настройками и конфигурацией, ла много может быть причин. Особенно у начинающих с таким проблемы возникают. Опубликованные результаты все же проходят тщательный контроль методики, и там меньше опасности встретить явный факап конфигурации.
> Точное название приведите плиз, а то не могу найти в NOW…
tr-3838 Storage Subsystem Configuration Guide
Только он не в NOW а на fieldportal.
Вау! ??нтереснейший документ оказался. Похоже я для себя найду там ответы на некоторое вопросы, которые не то чтобы меня мучили… так, раздражали. :-) Спасибо!
Скажите, а как-бы к Вам на почту обратиться? ??ли в Скайп стукнуться?
В http://blog.aboutnetapp.ru/about
написан email: romx@mail.ru
[...] x реальная_емкость_диска. Реальную емкость диска можно посмотреть тут. У нас получается 47 x 560ГБ = 26 [...]