.
A key component to the XtremIO data flow is XtremIO Data Protection (XDP). The XDP algorithm
simultaneously combines the most desirable traits of traditional RAID algorithms, and avoids their
weaknesses. XDP requires no user configuration or management.
Traditional RAID algorithms have to consider how to keep data contiguous, so as to avoid disk
drive head seeks. XDP presumes random access media, such as Flash, is present in the array, and
it can lay out data and read it back in highly efficient ways that would heavily penalize a diskbased
RAID algorithm. XDP also significantly enhances the endurance of the underlying Flash
media compared to any previous RAID algorithm
simultaneously combines the most desirable traits of traditional RAID algorithms, and avoids their
weaknesses. XDP requires no user configuration or management.
Traditional RAID algorithms have to consider how to keep data contiguous, so as to avoid disk
drive head seeks. XDP presumes random access media, such as Flash, is present in the array, and
it can lay out data and read it back in highly efficient ways that would heavily penalize a diskbased
RAID algorithm. XDP also significantly enhances the endurance of the underlying Flash
media compared to any previous RAID algorithm
Each X-Brick DAE is configured with N+2 row and diagonal parity, which offers faster rebuild
times. If one of the SSDs in an X-Brick fails, XDP automatically rebuilds the data to unused space
on the remaining SSDs, using distributed parity and data on the remaining SSDs, while
dynamically reconfiguring incoming new writes into a 22+2 stripe size to maintain N+2 double
failure protection for all new data written to the array. XDP always maintains a reserved capacity
on each drive to perform this drive rebuild.
This reserved capacity is factored out of XtremIO’s usable physical capacity per X-Brick. In a 10
TB X-Brick, we have 8.33 TB of usable physical space. In a 20 TB X-Brick, we have 16.67 TB of
usable physical space. Because of this methodology, not only does XtremIO not require hot
spares, but every available SSD is always active and adding to the array’s performance.
Once the rebuild completes, and the failed drive is replaced, incoming writes will once again be
written to the standard 23+2 stripe. This adaptability allows XDP to tolerate a sequence of up to
six (6) non-concurrent SSD failures, without having the administrator rush to the data center to
replace the six failed SSDs. XDP does not support two drives failing at the same time, or a second
drive failing before the first is rebuilt, for this will result in data loss. XtremIO can continue to
rebuild failed drives again and again, while serving user I/Os, as long as there is still available
capacity in the array.
times. If one of the SSDs in an X-Brick fails, XDP automatically rebuilds the data to unused space
on the remaining SSDs, using distributed parity and data on the remaining SSDs, while
dynamically reconfiguring incoming new writes into a 22+2 stripe size to maintain N+2 double
failure protection for all new data written to the array. XDP always maintains a reserved capacity
on each drive to perform this drive rebuild.
This reserved capacity is factored out of XtremIO’s usable physical capacity per X-Brick. In a 10
TB X-Brick, we have 8.33 TB of usable physical space. In a 20 TB X-Brick, we have 16.67 TB of
usable physical space. Because of this methodology, not only does XtremIO not require hot
spares, but every available SSD is always active and adding to the array’s performance.
Once the rebuild completes, and the failed drive is replaced, incoming writes will once again be
written to the standard 23+2 stripe. This adaptability allows XDP to tolerate a sequence of up to
six (6) non-concurrent SSD failures, without having the administrator rush to the data center to
replace the six failed SSDs. XDP does not support two drives failing at the same time, or a second
drive failing before the first is rebuilt, for this will result in data loss. XtremIO can continue to
rebuild failed drives again and again, while serving user I/Os, as long as there is still available
capacity in the array.
In any parity-based RAID algorithm (including XDP), there is less I/O overhead for writing a full
stripe than in updating an existing stripe with new data. An update requires reading existing data
and parity blocks, computing new parity, and writing the new data and updated parity. Thus, full
stripe writes are always desirable, and easy to perform when an array is empty. However, as an
array fills, most writes will be overwrites of existing data blocks, forcing more stripe updates to
occur and lowering performance.
The common strategy is to perform a garbage collection function that looks for stale data in
existing stripes and re-packs it into full stripes, allowing space to be reclaimed for full stripe
writes. In a Flash array, this leads to unpredictable performance, as I/O cycles are being
consumed by array overhead. Also, this wears the Flash drives sooner.
XDP has been designed for partial stripe updates. This is critical to maintaining performance over
the long-term in a production setting, once the array has been filled and file systems and
applications are overwriting old data with new data. XtremIO is optimized for the situation that
every array eventually reaches, which is no contiguous free space remaining. XDP places new
writes in the emptiest stripes because it incurs the lowest parity update overhead
stripe than in updating an existing stripe with new data. An update requires reading existing data
and parity blocks, computing new parity, and writing the new data and updated parity. Thus, full
stripe writes are always desirable, and easy to perform when an array is empty. However, as an
array fills, most writes will be overwrites of existing data blocks, forcing more stripe updates to
occur and lowering performance.
The common strategy is to perform a garbage collection function that looks for stale data in
existing stripes and re-packs it into full stripes, allowing space to be reclaimed for full stripe
writes. In a Flash array, this leads to unpredictable performance, as I/O cycles are being
consumed by array overhead. Also, this wears the Flash drives sooner.
XDP has been designed for partial stripe updates. This is critical to maintaining performance over
the long-term in a production setting, once the array has been filled and file systems and
applications are overwriting old data with new data. XtremIO is optimized for the situation that
every array eventually reaches, which is no contiguous free space remaining. XDP places new
writes in the emptiest stripes because it incurs the lowest parity update overhead
Displayed here is a comparison between RAID 1, 5, 6, and XDP when it comes to capacity
overhead and read/write stripe updates. Due to the fact that XDP performs partial stripes more
efficiently than traditional RAID, we get a total of 1.22 I/Os for both read and write backend disk
I/Os in random workloads.
overhead and read/write stripe updates. Due to the fact that XDP performs partial stripes more
efficiently than traditional RAID, we get a total of 1.22 I/Os for both read and write backend disk
I/Os in random workloads.
XtremIO provides native thin provisioning. All volumes are thin provisioned as they are created.
Since XtremIO dynamically calculates the location of the 8 KB data blocks, it never pre-allocates
or thick provisions storage space before writing the actual data. Thin provisioning is not a configurable property of a volume, it is always enabled.
Unlike traditional methodologies, XtremIO thin provisioning is inherent to the storage system.
There is no performance loss or capacity overhead. Furthermore, there is no volume
defragmentation necessary, since all blocks are distributed over the entire array by design
Since XtremIO dynamically calculates the location of the 8 KB data blocks, it never pre-allocates
or thick provisions storage space before writing the actual data. Thin provisioning is not a configurable property of a volume, it is always enabled.
Unlike traditional methodologies, XtremIO thin provisioning is inherent to the storage system.
There is no performance loss or capacity overhead. Furthermore, there is no volume
defragmentation necessary, since all blocks are distributed over the entire array by design
time and allowing users to access that data when needed, even when the source volume has changed. At first, snapshots do not consume any capacity. Snapshot capacity consumption only occurs if a change on the source volume requires writing a new unique block. Snapshots can be either writeable, or mounted read-only. You can take snapshots from either the source or any snapshot of the source volume.
Snapshots can be used in a number of use cases, including:
• Logical corruption protection where snapshots are used to recover from any logical data corruption
• Backup
• Development and Test
• Clones where persistent writeable snapshots are used
• Offline processing to offload the processing of data from a production server to another less
utilized server
Snapshots can be used in a number of use cases, including:
• Logical corruption protection where snapshots are used to recover from any logical data corruption
• Backup
• Development and Test
• Clones where persistent writeable snapshots are used
• Offline processing to offload the processing of data from a production server to another less
utilized server
XtremIO data deduplication reduces physical data, by eliminating redundant data blocks. Deduplication takes place at the block level, eliminating duplicated blocks of data that occur. Data compression compacts data into a smaller space and allows more capacity on the SSDs. XtremIO compresses the data after all duplications have been removed. This ensures that the compression is performed only for unique data blocks. Data compression is always inline and is never performed as a post-processing activity, therefore, unique data is always written only once. Data compression further reduces the data footprint by reducing the amount of physical data that must be written on the SSD and this improves the endurance of the SSDs. Compression is always on and cannot be disabled. XtremIO's data deduplication and data compression complement each other and increase total
data reduction rates.\
data reduction rates.\
No comments:
Post a Comment