Расчет дисковой емкости: 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-ов.