Расчет дисковой емкости: Zone и Block Checksums
??так, в предыдущем посте я показал вам, почему "диск на два терабайта" вовсе не обладает емкостью в "два терабайта" (по крайней мере с точки зрения устройства, использующего "двоичную" арифметику. Однако в случае NetApp это не единственный "сюрприз" для новичка.
Я уже рассказывал в этом блоге, почему NeApp, наряду с некоторыми другими вендорами, использует на дисках сектор размером 520 байт, то есть на 8 байт больше, чем "традиционный", 512 байт. ??спользование такого сектора обеспечивает лучшую сохранность данных, устойчивость к некоторым специфическим дисковым ошибкам, и позволяет организовать, например, дедупликацию данных.
Однако использование такого сектора, и получение всех связанных с ним плюсов, также приводит к увеличению расхода raw-пространства, прежде чем оно станет usable.
Если в случае использование дисков SAS или FC мы можем просто задать необходимый размер сектора при низкоуровневом форматировании, то все сложнее с дисками SATA. Диски SATA имеют фиксированный сектор, размером 512 байт, и не имеют возможности задавать его размер произвольно, таково ограничение и негибкость протокола SATA.
Поэтому для того, чтобы обеспечить идентичный функционал как для SAS/FC, так и для SATA, в системах NetApp используется следующий метод.
Как вы уже знаете, логический сектор WAFL в OS Data ONTAP равен 4096 байт данных, то есть состоит из восьми "низкоуровневых" секторов диска. Если в случае SAS/FC мы храним дополнительную информацию о секторе в дополнительных 8 байтах на каждый из 8 секторов (суммарно на логический сектор WAFL мы получаем 64 байта таких данных), то, поскольку SATA нам такой возможности не предоставляет, мы вынуждены под хранение этих 64 байт занять отдельный сектор на диске, размером 512 байт. Таким образом, на каждые 8 секторов по 512 байт на диске SATA, мы занимаем один сектор, размером 512 байт, под хранение 64 байт служебных данных. Не слишком экономично, но у нас нет иного варианта.
Однако это, как нетрудно заметить, на 1/9 уменьшает доступную для хранения данных емкость диска SATA.
Технология "расширенного сектора" для FC и SAS-дисков принято называть "Block Checksum (BCS)", технологию "девятого сектора" - "Zone checksum" или "8/9th"
Для того, чтобы посмотреть сколько же в распоряжении NetApp оказывается емкости на диске, можно использовать команду sysconfig -r, которая покажет "правильную" (rightsized) емкость дисков в MiB и блоках.
Вот каковы результаты для диска SATA на "2TB"
Phys (MB/blks)
————–
1695759/3472914816
В прошлом посте я уже приводил выдержку из техспеки диска WDC RE4 на "2TB". В ней указывалось, что диск содержит 3 907 029 168 секторов. Почему же NetApp видит тут только 3 472 914 816?
Посчитаем:
Эффект "отбрасывания" каждого девятого сектора это будет для числа секторов коэффициент 0,88 "в периоде".
Умножим паспортное количество секторов на 0,88… и получим:
3 907 029 168 x 0.88… = 3 472 914 816 секторов размером 512 байт для хранения непосредственно данных.
Сколько же это в мегабайтах, или правильнее - в "мебибайтах"?
3 472 914 816 доступных секторов x 512 байт = 1 778 132 385 792 байт
1 778 132 385 792 байт/1024 = 1 736 457 408 kiB/1024 = 1 695 759 MiB = 1 656 GiB
Таким образом, в "двоичной арифметике", принятой в компьютере (и OS Data ONTAP в том числе), мы получаем доступной в NetApp емкость одного диска "SATA 2TB" равной чуть более 1,65 "тебибайт".
??менно исходя из этой емкости одного диска следует высчитывать общую емкость системы хранения, обратите на этот факт особое внимание, чтобы не оказаться, что нужный объем хранения просто не лезет на неосмотрительно малое купленное количество дисков.
Вот тут я бы хотел, чтобы написанное далее было бы выделено жирным, крупным и ярким шрифтом, и было ясно осознано моими читателями, прежде чем мы двинемся дальше.
Все описанное выше не является недостатком систем хранения NetApp (как это, зачастую, желают представить некоторые из наших уважаемых конкурентов и оппонентов). Все описанное выше это не НЕДОСТАТОК, это СВОЙСТВО. Точно также, как "свойством", а не "недостатком" является описанное в предыдущем посте "уменьшение" размера диска при переходе от измерения емкости диска "в попугаях" к емкости "в слоненках".
Да, сперва нам кажется, что отдать 15% от "паспортной" емкости это довольно жестокое требование, в особенности по сравнению с другими системами, которые, как будто, такого "налога" и не требуют. Но помните, что всегда вы что-то получите назад (это свойство любых налогов, по крайней мере в нормальной стране;).
"Отобранный" у вас "каждый девятый сектор", вернется к вам более высокой надежностью хранения, возможностью использовать быстрый "RAID с двойной четностью", не страдающий недостатками "обычного RAID-6", возможностью использовать thin provisioning и дедупликацию.
В итоге, как показывает практика, вы получаете обратно в usable, заметно больше, чем эти отданные сперва "15%".
Обратите также внимание, что "15%" это только при использовании Zone Checksum на SATA.
При использовании дисков SAS/FC, использующих Block Checksum, например дисков SAS "450GB", их rightsized-емкость для системы будет равна 408,2GiB, что составляет уменьшение примерно на 9,5%.
В следующем посте мы обсудим формирование и ограничения aggregates и flexvol-ов.
А другие вендоры как SATA используют?
/а уведомление об ответах на коммент как-то могут в почту приходить? Где это настраивается?
>Таким образом, на каждые 8 секторов по 512 байт на диске SATA, мы занимаем один сектор, размером 512 байт, под хранение 64 байт служебных данных. Не слишком экономично, но у нас нет иного варианта.
??нтеренсто, что мешало дополнительный сектор занимать не на 64, а на полный объем?
> А другие вендоры как SATA используют?
Ты имеешь ввиду из тех, кто используют сектор 520 байт? Не знаю. Возможно не используют его на SATA. Дело в том, что NetApp использует эти расширенные данные, например, для дедупликации, ибыло бы странно, когда дедупликация есть только на SAS/FC, но нет на SATA.
> /а уведомление об ответах на коммент как-то могут в почту приходить? Где это настраивается?
А мне приходит :-P
На самом деле просто до недавних пор такой надобности не было, комментировали мало и редко, но если теперь стало надо, то попробую сделать.
> ??нтеренсто, что мешало дополнительный сектор занимать не на 64, а на полный объем?
Ну а нет туда больше ничего, что можно было бы там хранить. Там хранятся CRC секторов, составляющих блок WAFL. Этих секторов в блоке - 8. У каждого по 8 байт расширенной информации, в котором хранится CRC. Нельзя в этом секторе хранить CRC больше чем на один блок WAFL, это логически всю кухню усложняет, и будет влиять и на так неблестящую производительность SATA дисков.
> /а уведомление об ответах на коммент как-то могут в почту приходить? Где это настраивается?
>> А мне приходит :-P
>> На самом деле просто до недавних пор такой надобности не было, комментировали мало и редко, но если теперь стало надо, то попробую сделать.
ОЧЕНЬ хочется уведомления. ??наче писать комментарий смысла нет - общение на этом заканчивается (т.к. я не увижу никогда ответов).
>Ну а нет туда больше ничего, что можно было бы там…
Улыбнулся :о)
>> ??нтеренсто, что мешало дополнительный сектор занимать не на 64, а на полный объем?
Я имел в виду, что сектор размером в 512к смог бы вместить информацию о 64 секторах данных, и был бы занят полностью. Т. о. на каждые 64 сектора приходился бы один служебный.
> Я имел в виду, что сектор размером в 512к смог бы вместить информацию о 64 секторах данных, и был бы занят полностью. Т. о. на каждые 64 сектора приходился бы один служебный.
Я понял, но как вы это себе представляете? Мы работаем с блоком WAFL, данные которого не просто лежат в секторе N+1, а лежат где-то в каком-то произвольном секторе на массиве, причем не просто лежат в секторе, а с каким-то произвольным смещением. Где всю эту информацию о поиске этого блока, и смещения в нем для данного набора секторов, входящих в WAFL хранить, как извлекать?
Все это видится усложенением на пустом месте, причем усложнением не просто так, а еще и с солидным ухудшением производительности.?? ради чего? Ради 10% места на SATA?
Оффтоп
Такие бы статьи почитать некоторым знакомым мне пресейлам )))
> Такие бы статьи почитать некоторым знакомым мне пресейлам )))
Подключайте их, не стесняйтесь :)
Я тоже таким когда-то был.
>Обратите также внимание, что “15%” это только при использовании Zone Checksum на SATA
??нтересно, а в дисках NL-SAS так же применяется Zone Checksum как и на SATA или там Block Checksum как на FC/SAS?
Если верно второе, то почему NetApp до сих пор не выпускает поддержку дисков NL-SAS?
Don Serjio:
Вот что по этому поводу пишет Storage Subsystem Technical FAQ за апрель 2011:
Key points about NL-SAS:
* Only one single drive manufacturer has currently launched an NL-SAS product (as of February 2011).
Other vendors will probably be bringing NL-SAS products to market, but at the moment NL-SAS drives are single source.
* Until announced by EMC, there were no major network storage vendors using NL-SAS. They are the first major network storage vendor to ship NL-SAS and currently (February 2011) are single sourced.
Single-sourced products for enterprise storage configurations are dangerous because they completely limit the ability of the storage vendor to respond to supply chain and quality issues.
* New capacity points for NL-SAS (for example, 2TB) have lagged behind their equivalent SATA capacities in terms of release schedules from the drive manufacturer.
* NL-SAS is still a SATA drive internally. It has additional hardware and electronics associated with the built-in SAS interface.
Key points about the NetApp bridged-SAS (SATA+dongle) solution:
* By using an external dongle, we can support any vendor’s SATA drive, which makes BSAS more flexible than NL-SAS. This allows NetApp to multisource a drive, which in turn allows NetApp to deliver supply continuity, competitive pricing, and quality.
* NL-SAS is still a SATA drive, just like the NetApp BSAS drive is a SATA drive. In both cases, steps have been taken to allow the drive to plug into SAS architectures and mitigate performance implications related to translation of ATA to SCSI. Competitors might claim that NL-SAS performance is better than NetApp’s BSAS solution. A small advantage in performance might be apparent in mircobenchmarks as
a result of the integrated nature of the SAS interface. However, this difference would be imperceptible when looking at real-world workloads and system-level performance.
* NetApp’s BSAS drives (SATA) use 512-byte sectors, whereas NL-SAS uses 520-byte sectors. This allows NL-SAS drives to present more usable capacity per drive when compared to a NetApp BSAS drive using block checksums (BCS) 8/9 formatting. NetApp will be introducing advanced zone checksums (AZCS) in a future release of Data ONTAP that will eliminate the capacity overhead associated with BSC 8/9.
Я подозреваю, что NL-SAS просто нет в достаточном количестве на свободном рынке, все производство скупается EMC. :)