Экономим usable space. “Bad but useful practices”.

Многие пользователи NetApp, в особенности их младших моделей (Low Enterprise Class, FAS2020 и FAS2050) часто жалуются на большие потери при создании usable space. Зачастую usable space может составлять всего 50% от raw, а иногда бывает и того менее.
Действительно, на системах с малым числом дисков, а зачастую именно такие попадают в сравнительно небольшие компании и проекты, величина пространства, которая отнимается по умолчанию из дискового пространства такой системы довольно велика. Чем больше в системе дисков, тем меньшую роль это играет, однако на небольших системах этот эффект довольно значителен.

Что с этим делать, и насколько это серьезная проблема?

Как вы уже знаете, индивидуальные настройки системы хранения NetApp находятся на создаваемом при первом запуске системы томе vol0 в директории /etc. В отличие от решений конкурентов, этот том не какой-то специальный, а самый обыкновенный, и все содержимое его за исключением занятого под /etc мы можем использовать для хранения пользовательских данных.

Однако такой том нужен для каждого из двух контроллеров, и, в случае использования RAID-4 мы потратим на их создание как минимум 2 диска на parity disks для их RAID-групп (и 4 в случае RAID-DP), плюс еще диски на parity для RAID-групп данных. Плюс hot spare. Вот и убегает, при создании системы с настройками “по умолчанию”, половина всех доступных дисков. Хотя, говоря начистоту, при использовании RAID-10 в “других система хранения” мы тоже получаем 50% usable от raw, но в данном случае все равно как-то жаба грызет.

??так, каким хитрым способом можно получить максимально возможное количество usable space на системе типа FAS2020A, с, допустим, дисками SATA 1TB 7200RPM?

С самого начала скажу, что нижеописанная схема никакой не Best Practices (а скорее даже Bad Practices), но тем не менее позволят получить максимум usable space на небольших системах, типа FAS2020. Если вас угораздило купить такую, да еще с небольшим количеством больших дисков SATA в базе, невзирая на все, что вам говорили при этом при продаже - читайте дальше.

Можно создать aggr0 из всего пары дисков в RAID-4 (1 диск данных и 1 диск parity), и разместить на нем vol0 для первого контроллера. На этом vol0 находится служебная информация, необходимая для загрузки и работы контроллера, директория /etc, поэтому создавать его придется на “полностью чистой” системе из меню Maintenace mode. Служебная директория займет примерно мегабайт 30. Остальное место, почти терабайт, мы можем использовать для хранения каких-нибудь наших данных. По умолчанию на vol0 создается директория home, в которой можно разместить homedir подключенных к NAS пользователей. Однако следует помнить, что быстродействие тома, построеного на RAID из всего двух дисков будет невелико. Так что лучше если это будут какие-нибудь не критичные к быстродействию данные

Оставшиеся 10 дисков мы распределяем таким образом: 1 диск оставляем в hot spare*, а все оставшиеся 9 помещаем в один большой aggregate, в одну RAID-группу типа RAID-4 или RAID-DP (1 или 2 pariy, 8 или 7 дисков данных). ?? на этой большой группе создаем vol0 для второго контроллера.
А все оставшееся место, за вычетом 30Mb на содержимое /etc, мы можем занять нашими данными, причем они будут распределены уже по “длинному” и, следовательно, более быстродействующему RAID.

Disk layout

Disk layout

Отмечу, что, если не ошибаюсь, начиная с ONTAP 7.3, для системы хранения NetApp назначается 2 диска hot spare на каждый контроллер, что для малых систем, на мой взгляд, чересчур расточительно. Это значение можно изменить в системных опциях*.

Преимущества:

  1. Мы получаем величину usable space равную 75% от raw (из 12 дисков выпадают 3: 1 на parity на первом контроллере, 1 на parity на втором контроллере, 1 на общий spare)
  2. Мы получаем большой раздел “одним куском”, и можем, например, создать на нем LUN размером 8TB (больше все равно не поддерживается на 2020)
  3. Этот большой раздел получается относительно быстродейстующий, так как распределен на максимально возможное в данном случае количество дисков.

Недостатки:

  1. Мы, по сути, делаем резко асимметричную систему, в которой контроллер 1 практически не занят, и вся рабочая нагрузка по обслуживанию доступа к данным ложится на второй.
  2. RAID-4 менее отазоустойчив, чем RAID-DP, в особености на SATA, и обеспечивает более долгое время ребилда в случае сбоя.
  3. 1 spare на 2 контроллера это “не рекомендованная” NetApp конфигурация.
  4. Такая схема разбиения “не рекомендуется” NetApp для использования.

Так что на свой страх и риск.

* Необходимо изменить системный параметр:
set options raid.min_spare_count 1

Комментарии (2)

  1. При этом, второй контроллер, которому не достался spare будет безбожно ругаться на отсутствие оного и пытаться слать CALL HOME в AutoSupport )
    Хотя документация говорит, что сообщения об ошибках можно отключить (но сделать RAID-DP вместо RAID4)
    Setting the raid.min_spare_count option to 0 disables low spare warnings. You might want to
    do this if you do not have enough disks to provide hot spares (for example if your storage system
    does not support external disk shelves). You can disable the warnings only if the following
    requirements are met:
    • Your system has 16 or fewer disks.
    • You have no RAID groups that use RAID4.
    Note: You cannot create aggregates that use RAID4 protection while the
    raid.min_spare_count option is set to 0. If either of these requirements is no longer met
    after this option has been set to 0, the option is automatically set back to 1.

  2. А еще в недостатки можно отнести:
    - без RAID-DP второй контроллер (который содержит только /vol/vol0 на RAID4) невозможно будет произвести nondisruptive обновление прошивок дисков.

Оставить комментарий