2
vtricks.com http://vtricks.com/?p=79 November 23, 2012 DataCore’s SANsymphony-V Part 1 – Disk Pools, Virtual Disks & Storage Allocation Units  After my in troduction to DataCo re Softwa re and SA Nsymphon y-V this is th e first tech nical article of this se ries. This series isn’t meant to be a step by step guide, rather it should provide you with some basic knowledge on how SANsymphony-V works. Let’s start with disk pools and virtual disks. In the first step let’s look at disk pools in general. A disk pool as the name indicates pools together physical (backend) storage and allows to use the pool capacity to be used as a resource to create so called virtual disks. Virtual disks and disk pools have a tight relationship and that’s why a proper pool design is crucial to avoid performance issues. There are two possible approaches to pool storage resources. The classic approach is to use multiple pools to group disks with similar performance characteristics. The second option is to put all disks into a single disk pool and use a feature called “Auto-Tiering”. This enables SANsymphony-V to place and move blocks of data based between different types of storage. I’ll provide a separate post on “Auto-Tiering” tiering so I’ll skip that for now. The following screenshot depicts the available options when creating a new disk pool:  Maximum number of tiers:  This defines how many different types of storage (Tiers/performance classes) to pool will be made ofl. The number can be changed at any time. Storage allocation unit size:  This setting could be seen as stripe size which will be striped across the attached psychical disks. DataCore calles them “Storage Allocation Units” (SAU). A single SAU can only reside on a single physical disk, a single SAU won’t be distributed across multiple disks. During the creation or afterwards physical disks can be added to the disk pool. When talking about phyiscal disks, I’m referring RAID volumes/arrays. Of course it’s also possible to use single disks of a JBOD, but to achieve a certain level of performance it’s recommended to use multiple disks within a RAID. Once the pool has been created and all space has been reclaimed (filled wit h zeros),the virt ual disks or vDisks can be carved up from the pool and served to the application hosts. Creating a vDisk is quite simple, all that is required the desired size and the disk pool. But what about the 128 MB SAU/stripe size? Even for me this initially sounded pretty big. SANsymphony-V stripes data across all off of the attached physical disks inside a disk pool.

Vtricks.com-DataCores SANsymphonyV Part 1 Disk Pools Virtual Disks Amp Storage Allocation Units

Embed Size (px)

Citation preview

8/10/2019 Vtricks.com-DataCores SANsymphonyV Part 1 Disk Pools Virtual Disks Amp Storage Allocation Units

http://slidepdf.com/reader/full/vtrickscom-datacores-sansymphonyv-part-1-disk-pools-virtual-disks-amp-storage 1/2

vtricks.com http://vtricks.com/?p=79

November 23,2012

DataCore’s SANsymphony-V Part 1 – Disk Pools, Virtual Disks& Storage Allocation Units

After my introduction to DataCore Software and SANsymphony-V this is the first technical article of this series.This series isn’t meant to be a step by step guide, rather it should provide you with some basic knowledge on howSANsymphony-V works. Let’s start with disk pools and virtual disks.

In the first step let’s look at disk pools in general. A disk pool as the name indicates pools together physical(backend) storage and allows to use the pool capacity to be used as a resource to create so called virtual disks.Virtual disks and disk pools have a tight relationship and that’s why a proper pool design is crucial to avoidperformance issues.

There are two possible approaches to pool storage resources. The classic approach is to use multiple pools to

group disks with similar performance characteristics. The second option is to put all disks into a single disk pooland use a feature called “Auto-Tiering”. This enables SANsymphony-V to place and move blocks of data basedbetween different types of storage. I’ll provide a separate post on “Auto-Tiering” tiering so I’ll skip that for now.

The following screenshot depicts the available options when creating a new disk pool:

Maximum number of tiers: This defines how many different types of storage (Tiers/performance classes)to pool will be made ofl. The number can be changed at any time.

Storage allocation unit size: This setting could be seen as stripe size which will be striped across theattached psychical disks. DataCore calles them “Storage Allocation Units” (SAU). A single SAU can onlyreside on a single physical disk, a single SAU won’t be distributed across multiple disks.

During the creation or afterwards physical disks can be added to the disk pool. When talking about phyiscal disks,I’m referring RAID volumes/arrays. Of course it’s also possible to use single disks of a JBOD, but to achieve acertain level of performance it’s recommended to use multiple disks within a RAID.

Once t he pool h as been created and all space has been reclaimed (filled wit h zeros),the virt ual disks or vDiskscan be carved up from the pool and served to the application hosts. Creating a vDisk is quite simple, all that isrequired the desired size and the disk pool.

But what about the 128 MB SAU/stripe size? Even for me this initially sounded pretty big.

SANsymphony-V stripes data across all off of the attached physical disks inside a disk pool.

8/10/2019 Vtricks.com-DataCores SANsymphonyV Part 1 Disk Pools Virtual Disks Amp Storage Allocation Units

http://slidepdf.com/reader/full/vtrickscom-datacores-sansymphonyv-part-1-disk-pools-virtual-disks-amp-storage 2/2

For sure the SSV won’t rewrite 128 MB every time, it can send writes anywhere between 4kB and 1MB to thebackend disks. To further increase the performance SANsymphony-V will make use of caching and I/Ocoalescing. Storage Allocation Units can also be seen as containers to map physical blocks to a virtual disk whichin the end is a virtual construct made of SAUs.

It’s possible to reduce the stripe size but this can have an impact on the overall performance simply becauseoverhead introduced by the total number of SAUs managed by SANsymphony-V.

An important point to consider when designing a disk pool is that each RAID volume will represent an I/O queuewhere SSV can issue I/Os to. I have prepared two little videos to show you the difference between random andsequential I/Os and how data gets distributed based on its characteristics.

Random write I/O gets evenly spread across disks whereas sequential write I/O will be processed sequential.Thisensures that random I/O gets processed as fast as possible and sequential I/O stays sequential and isn’t blendedinto random I/O just to send it so different disks.

So it’s quite a challenge to find the right size (sweat spot) for RAID sets. Only with detailed knowledge about theexpected workload, it would be possible give a proper recommendation.

With SANsymphony-V 10 DataCore has introduced a major enhancement to the disk pools called “Intelligent re-balancing” . This is an which is an ongoing process to ensure an even distribution of all SAUs across all physicaldisks within a storage tier. This avoids piling of SAUs which belong to a particular vDisk on a just a few backenddisks. This also heavily favors the “distributed” volumes I mentioned in another post . Currently I/O metrics are nottaken into account to avoid additional stress due to data movement caused by a temporarily increased load. Morenew features can be found here .