Учу матчасть :)

Как заповедали старшие – изучаю вооружение потенциального противника :)

Нашел тут EMC CLARiiON Best Practices for Performance and Availability (FLARE 30, 01.03.2011) и сижу, читаю.

Особо примечательные места выделяю. Ничего, что я сегодня без перевода? По-моему, в выделенном все достаточно понятно.

Уделяю особое внимание storage pool-ам и LUN-ам в них, так как только в pool-ах возможны новые фишечки, такие как FAST и thin provisioning.

Страница 63 и ниже (специально даю пространное цитирование, чтобы не быть попрекомым в выдирке из контекста.

Conceptually, the storage pool is a file system overlaid onto a traditional RAID group of drives. This file system adds overhead to performance and capacity utilization for thin and thick LUNs. Thick LUNs have less of a performance overhead than thin LUNs due to the granularity of space allocation and mapping between virtual and physical layers.

In addition, availability should be considered when implementing pools. A pool with a large number of drives will be segmented into multiple private RAID groups. Data from many LUNs will be distributed over one or more of the pool’s RAID groups. The availability of the pool includes the availability of all the pool’s RAID groups considered as one. (Availability is at the single RAID group level with traditional LUNs.) Workloads requiring the highest level of performance, availability, and capacity utilization should continue to use traditional FLARE LUNs. As with traditional LUNs, storage pool drive count and capacity need to be balanced with expected LUN count and workload requirements. To get started quickly, begin with the recommended initial pool size, expand in the recommended increments, and don’t greatly exceed the recommended maximum pool size found in the Quick Guidelines” section below.

Тут поясню, что в документе под FLARE LUN, здесь и далее, понимаются “классические” LUN-ы, то есть созданные поверх обычных RAID на физических дисках, в противоположность pool LUN.

Creating storage pools

For the most deterministic performance create few homogeneous storage pools with a large number of storage devices. A homogeneous pool has the same type, speed, and size drives in its initial allocation of drives. Heterogeneous pools have more than one type of drive. See the “Fully Automated Storage Tiering (FAST) Virtual Provisioning” section for heterogeneous pool management.

A single RAID level applies to all the pool’s private RAID groups. Pools may be created to be of RAID types 5, 6, or 10. Use the general recommendations for RAID group provisioning of FLARE LUNs when selecting the provisioning of the storage pool’s RAID types.

When provisioning a pool with SATA drives with capacities of 1 TB or larger, we strongly (выделение в документе, прим romx) recommend RAID level 6. All other drive types can use either RAID level 5 or 10.

 

Там же, страница 66 и далее.

EMC recommendations for creating homogeneous pools are as follows:

  • We recommend Fibre Channel hard drives for Virtual Provisioning pools with thin LUNs due to their overall higher performance and availability.
  • Create pools using storage devices that are the same type, speed and size for the most predictable performance. It may be advisable to keep Fibre Channel and SATA hard drives in separate pools to service different workloads with varying performance and storage utilization needs.
  • Usually, it is better to use the RAID 5 level for pools. It provides the highest user data capacity per number of pool storage devices and proven levels of availability across all drive types. Use RAID 6 if the pool is composed of SATA drives and will eventually exceed a total of 80 drives. Use RAID 6 if the pool is made up of any number of large capacity (more 1 TB) SATA drives.
  •  Initially, provision the pool with the largest number of hard drives as is practical within the storage system’s maximum limit. For RAID 5 pools the initial drive allocation should be at least five drives and a quantity evenly divisible by five. RAID 6 pool initial allocations should be evenly divisible by eight. RAID 10 pool initial allocations should be evenly divisible by eight.
    • lf you specify 15 drives for a RAID 5 pool - Virtual Provisioning creates three 5-drive (4+1) RAID groups. This is optimal provisioning.
    • lf you specify 18 drives for a RAID 5 pool - Virtual Provisioning creates three 5-drive (4+1) RAID groups and one 3-drive (2+1) RAID group. This provisioning is less optimal.
    • lf you specify 10 drives for a RAID 6 pool — Virtual Provisioning creates one 10-drive (8+2) RAID group. This is larger than standard, because an additional group cannot be created. It is acceptable, because the RAID groups are the same size.
    • lf you specify 10 drives for a RAID 1/0 pool — Virtual Provisioning creates one 8-drive (4+4) and one 2-drive ( 1+1) RAID group. This is not optimal, because some pool resources will be serviced by a single drive pair. For RAID 10 pools, if the number of drives you specify in pool creation or expansion isn’t divisible by eight, and if the remainder is 2, the recommendation is to add additional drives or remove Iwo drives to that disk count to avoid a private RAID group of two drives being created.
  • In a storage pool, the subscribed capacity is the amount of capacity that has been assigned to thin and thick LUNs. When designing your system, make sure that the expected subscribed capacity does not exceed the capacity that is provided by maximum number of drives allowed in a storage system’s pool. This ensures that increased capacity utilization of thin LUNs can be catered for by pool expansion as necessary.

 

Expanding homogeneous storage pools

A homogeneous pool is a storage pool with drives of a single type. For best performance expand storage pools infrequently, maintain the original character of the pool’s storage devices, and make the largest practical expansions.

  • Expand the pool using the same type and same speed hard drives used in the original pool.
  • Expand the pool in large increments. For RAID leveL 5 pools use increments of drives evenly divisible by five, not Less than five. RAID 6 pools should be expanded using eight-drive evenly divisible increments. Pools may be expanded with any amount of drives. You should expand the pool with the largest practical number of drives. Pools should not be expanded with fewer than a single RAID group’s number of drives. The performance of the private RAID groups within the pool by a smaller, later expansion may be different from the pool’s original RAID groups. Doubling the size of a pool is the optimal expansion.

 

Creating pool LUNs

The general recommendations toward traditional LUNs apply to pool LUNs. (See the ‘LUN provisioning” section on page 55.)

The largest capacity pool LUN that can be created is 14 TB.

 

Avoid trespassing pool LUNs. Changing a pool LUN’s SP ownership may adversely affect performance. After a pool LUN trespass, a pool LUN’s private information remains under control of the original owning SP. This will cause the trespassed LUN’s lOs to continue to be handled by the original owning SP. This results in both SPs being used in handling the IOs. Involving both SPs in an I/O increases the time used to complete an I/O. Note that the private RAID groups servicing I/O to trespassed pool LUNs may also be servicing I/O to non-trespassed pool LUNs at the same time. There is the possibility of dual SP access for the period some pool LUNs are trespassed. If a host path failure results in some LUNs trespassing in a shared pool, the failure should be repaired as soon as possible and the ownership of those trespassed LUNs be returned to their default SP.

SP это дисковый контроллер, Storage Processor.

Pools with high bandwidth workloads

When planning to use a pool LUNs in a high bandwidth workload, the required storage for the LUN should be pre-allocated. For FLARE revision 30.0 and later, thick LUNs should be used. For virtual provisions using earlier versions of FLARE a pre-allocation of the storage should be performed.

Pre-allocation results in sequential addressing within the pool’s thin LUN ensuring high bandwidth performance. Pre-allocation can be performed in several ways including migrating from a traditional LUN; performing a full format of the file system, performing a file write from within the host file system; or creating a single Oracle table from within the host application. In addition, only one concurrent preallocation per storage pool should be performed at any one time. More than one thin LUN per pool being concurrently pre-allocated can reduce overall SP performance.

 

Capacity overhead

There is a fixed capacity overhead associated with each LUN created in the pool. Take into account the number of LUNs anticipated to be created, particularly with small allocated capacity pools.

A pool LUN is composed of both metadata and user data. both of which come from the storage pool. A pool LUN’s metadata is a capacity overhead that subtracts from the pool’s user data capacity. Thin and thick LUNs make different demands on available pool capacity when they are created. Note the User Consumed Capacity of a thin LUN is some fraction of the User Capacity of the LUN.

Any size thin LUN will consume about 3 GB of pool capacity: slightly more than 1 GB of capacity for metadata, an initial 1 GB of pool capacity for user data. An additional 1 GB of pool capacity is prefetched before the first GB is consumed in anticipation of more usage. This totals about 3 GB. The prefetch of 1 GB of metadata remains about the same from the smallest though to the largest (>2 TB host-dependent) LUNs. Additional metadata is allocated from the first 1 GB of user data as the LUN’s user capacity increases.

To estimate the capacity consumed for a thin LUN follow this rule of thumb:

Consumed capacity = (User Consumed Capacity * 0,02) + 3GB.

 

LUN compression

LUN compression is a separately licensable feature available with FLARE 30.0 and later.

Compression performs an algorithmic data compression of pool-based LUNs. All compressed LUNs are thin LUNs. Compressed LUNs can be in one or more pools. FLARE LUNs can also be compressed. If a FLARE LUN is provisioned for compression, it will be converted into a designated pool-based thin LUN. Note that a Virtual Provisioning pool with available capacity is required before a FLARE LUN can be converted to a compressed LUN. The conversion ofa FLARE LUN to a compressed thin LUN is considered a LUN migration.

 

Compressed LU N performance characteristics

Compression should only be used for archival data that is infrequently accessed. Accesses to a compressed LUN may have significantly higher response time accesses to a Virtual Provisioning pool-based LUN. The duration of this response time is dependent on the size and type of the 10, and the degree of compression. Note that at the host Level, with a fully operational write cache, delays for writes to compressed LUNs are mitigated.

 

Be aware, that as with many semiconductor-based storage devices. that Flash drive uncached write performance is slower than their read performance. To most fully leverage Flash drive performance, they are recommended for use with workloads having a large majority of read lOs to writes.

The following I/O type recommendations should be considered in using Flash drives with parity RAID 5 groups using the default settings:

  • For sequential reads: When four or greater threads can be guaranteed, Flash drives have up to twice the bandwidth of Fibre Channel hard drives with large-block, sequential reads. This is because the Flash drive does not have a mechanical drive’s seek time.
  • For random reads: Flash drives have the best random read performance of any CLARiiON storage device. Throughput is particularly high with the ideal block size of 4 KB or less. Throughput decreases as the block size increases from the maximum.
  • For sequential writes: Flash drives are somewhat slower than Fibre Channel hard drives with single threaded write bandwidth. They are somewhat higher in bandwidth to Fibre Channel when high concurrency is guaranteed.
  • For random writes: Flash drives have superior random write performance over Fibre Channel hard drives. Throughput is particularly high with highly concurrent access using a 4 KB block size. Throughput decreases with increasing block size.

 

Продолжаю читать…

Как и ранее, готов обсуждать тему со специалистами в EMC CLARiiON, если они, в свою очередь, готовы соблюдать правила данного блога: вести дискуссию спокойно, аргументированно и вежливо к ее участникам, даже если они и придерживаются иных взглядов.

19 комментариев

  1. Александр:

    Могу добавить, что разница в производительности (сам замерял на девственном CX4-240) 10-15% между LUN’ом на пуле и LUN’ом на рейдгруппе. Вообщем пул делался на таком же рейде и на тех же дисках так что эксперимент получился без примесей.

  2. Евгений:

    Скоро надо будет второй блог открывать aboutemc.ru bkb aboutvnx.ru =)

  3. Александр:

    Спасибо, а что за профиль нагрузки был, OLTP-like?

    Евгений:

    Надеюсь, что до этого дело не дойдет. Опять же, блог называется “системы хранения данных как объект разговора”, не уточняя, что именно системы хранения NetApp, хотя я говорю, в первую очередь, о них.

    Тут же откуда все это богатство? Начав рыть какую-то тему, я, порой, закапываюсь в материал и источники довольно глубоко. Часто пост уже опубликован, а я продолжаю интересоваться темой, находить все новые. Ну и жалко было бы как-то интересной добычей не поделиться.
    EMC компания большая, технологий в ней много, есть в чем копаться. Ну и, потом, как уже сказано выше: “Воин - знай тактико-технческие характеристики техники вероятного противника!” :)

    Когда возникает спор с EMC-шниками, хорошо бы темой владеть, опять же, по отношению к высказываемому в дискуссии применимо старинное правило: “Доверяй - но проверяй!” ;)

  4. firehunter:

    Я подозреваю, что в NetApp FAS производительность на Flexible Volume и на Traditional Volume тоже должна отличаться. Правда тестировать нет времени, да коробки свободной тоже нет.
    По крайней мере я встречал описание что сам OnTap стал чуть медленнее, когда в нем появилась поддержка FlexVol. Как утверждалось - просто из за большого размера кода. На современных процессорах это наверное уже не важно :)

  5. firehunter:

    Вряд ли. Я не вижу, какие за этим могут быть физические основания. Я понимаю, очего возможно падение в случае перехода от FLARE LUN к Pool LUN у CLARiiON, добавляется довольно непростой сам по себе слой с оверхедом, которого нет у FLARE LUN.

    Но у NetApp И под Traditional Vol, И под FlexVol лежит _одна и та же_ WAFL. То есть она, может быть, и добавляет какой-то оверхед, но один и тот же, что для Traditional, что для FlexVol.
    В пользу этого также говорит и то, что нет ни одной рекомендации предпочитать Traditional Vol при повышенных требованиях к производительности, как, например, это написано в цитируемом документе. Он остается только для legacy systems.

    С физической точки зрения (опуская некоторые малозначащие подробности), aggregate во FlexVol это и есть тот же самый Traditional Vol! Просто поверх этого “псевдо-vol, traditional type” созданы логические “партиции”. Но разбиение на партиции не ухудшает производительность, так как не добавляет дополнительной сложности или оверхеда.

  6. firehunter:

    romx: надо тестировать, если действительно интересно, есть ли разница в производительности. Думаю что и читателям блога будет это интересно. Вряд ли цифры будут отличаться больше чем на один-два процента.
    Оверхед есть, его не может не быть :) И речь не про WAFL, а именно про дополнительный уровень абстракции, появившийся с FlexVol.

  7. firehunter:

    romx: кстати, мне в голову пришло, что на современных версиях OnTap FlexVol могут быть быстрее по сравнению с Traditional. Наверняка код FlexVol последние годы улучшался с точки зрения производительности, его переписывали, оптимизировали и пр. А код, который относится у Traditional скорее всего не подвергался никаким изменениям. Или может быть, что сейчас код общий для обоих типов томов.

  8. > Оверхед есть, его не может не быть :) И речь не про WAFL, а именно про дополнительный уровень абстракции, появившийся с FlexVol.

    Так в том-то и дело, что нету там нового уровня абстракции. Оттого, что вы кладете свои файлы не в C:\, а в C:\folder ведь не появляется “новый уровень абстракции”?

  9. firehunter:

    >Так в том-то и дело, что нету там нового уровня абстракции. Оттого, что вы кладете свои файлы не в C:\, а в C:\folder ведь не появляется “новый уровень абстракции”?
    С точки зрения программного кода - да, появляется, если раньше не было дерева каталогов и был только один.

  10. > firehunter:

    Не совсем так. Корневая директория - тоже директория. Механизмы работы файловой системы от того, лежит файл в корневой директории, или в поддиректории в ней, не изменяются.
    С точки зрения кода это просто у файла чуть более длинное имя, не c:\filename.ext, а c:\folder\filename.ext
    Возможно чуть больше времени занимает конкретная операция seek, если мы делаем просмотр директории с неизвестным содержимым, но, для NetApp, это не наш случай, к нашим томам для доступа к их данным мы всегда обращаемся по конкретному имени (пути).

  11. Firehunter:

    romx:

    Собственно дискурсия носит теоритеческий характер. На практике надо сравнивать на каком либо старом оборудовании оба типа томов на современной версии ontap и плюс к этому на версии ontap где еще не было FlexVol.

  12. firehunter:

    romx: Когда код становится сложнее, обычно он дольше выполняется. Не всегда, но обычно. Вы с этим согласны?
    В любом случае, чтобы расставить точки на “и”, надо тестировать. Без теста - это теоретическая полемика, которая к реальности имеет опосредованное отношение.
    Тест, на мой взгляд имеет смысл проводить на достаточно старой системе, которая будет способна работать под старой версией Ontap, где еще не было Flexvol. И проводить три теста: два на достаточно новой OnTap, с FlexVol и Traditional и отдельный тест на старой версии Ontap, в которой еще не было FlexVol. При этом желательно иметь достаточно кол-во шпинделей, чтобы центральный процессор был бы узким местом.

  13. firehunter:

    Ну можно проще, взять какую-нибудь версию из ранних 7.0, какую-нибудь массовую 7.0.5, например, где только появился FlexVol, и сравнить.
    Я ни разу не слышал ничего о значительной разнице в производительности, даже при первом появлении 7.0 (я еще вовсю 6.х в продакшне застал).

  14. firehunter:

    romx:

    Я не утверждаю, что разница в производительности обязательно должна быть значительная. Как мне кажется, наоборот, речь скорее всего будет идти о долях процента или чуть больше.

  15. Freedom:

    Вышла новая дока, уже по VNX - EMC Unified Storage Best Practices for Performance and Availability

    http://www.emc.com/collateral/hardware/white-papers/h8268-vnx-block-best-practices.pdf

  16. Антон:

    Ребята, помогите перевести предложение, плиз!
    MirrorView/A does NOT have any checks to consider Thin Pool space on secondary array
    Я не имею представление, что значит Thin Pool space и все такое, т.к. не программист…
    Буду оч. благодарен за ответ и возможные пояснения на примитивном уровне.
    Спасибо.

  17. Антон:

    Вы не по адресу вопросы задаете. Это вам надо специалистам по EMC задавать, тут таких нет, мы другими стораджами занимаемся, и говорим о них. EMC тут изредка, и с дилетантской позиции обсуждается.

  18. Александр:

    romx:

    по поводу профиля нагрузки. Времени было в обрез (как всегда вообщем) поэтому тестил на скорую руку все подряд на заморачиваясь на профилях чтоб просто понять что лучше выбрать для задач, как случайный доступ так и последовательный разными блоками (4K 16K 64K). К сожалению, не скажу в каком случае пул меньше теряют производительности, а 10-15% это общая картина… “средняя температура по поликлинике”

    P.S. В отпуске был поэтому затянул с ответом.

  19. Алексей:

    To Антон:

    MirrorView/A does NOT have any checks to consider Thin Pool space on secondary array
    Это значит, что массив с primary mirror image не проверяет, хватает ли места в storage pool для secondary mirror image и админ клариона должен проверить это сам

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

20/0.154

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией NetApp, Inc. Излагаемая в этом блоге точка зрения выражает мнение исключительно его автора и может не совпадать с позицией NetApp, Inc.

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.