Software RAID systems takes number of EBS Volumes and
present them as one volume to the user. A RAID 0 (known as a striped volume)
splits data evenly across two or more volumes (striped) without parity information. Example: The chunks of data from the
same file are distributed across the disks that form the RAID array as
illustrated in the below diagram (coming soon)
By writing data in small chunks across several EBS volumes,
the performance of those volumes can be aggregated. Since I/O is distributed
across the volumes in a stripe manner, if you add a volume in the array, you
get the straight addition of throughput as well (most times). For example,
where a single PIOPS volume is restricted to its individual I/O performance and
disk RPM’s, a write to an array made up of several volumes combines the I/O of
all those PIOPS Volumes. So, a stripe made up of six PIOPS volumes with a throughput of
1800 IOPS each would together have a total I/O performance of up to 10800 IOPS.
You can create EBS stripes on both Standard and PIOPS EBS Volumes. Note:
Performance of the stripe is limited to the worst performing volume in the set. Usually
EBS Striping is chosen in cases where I/O performance is more important than
fault tolerance (such as a heavily used database, Search engine servers) and
where data replication is already set up separately.
To create a six-volume stripe set on Linux, use a command
like the following.
$ sudo mdadm --create /dev/md0 --level=0 --chunk=64
--raid-devices=6 /dev/sdf /dev/sdg /dev/sdh /dev/sdi /dev/sdj /dev/sdk
Why 64 KB RAID chunk size?
The RAID chunk size should suit the I/O characteristics of
the data you are working with. Important factor here is the size of the average
I/O request you're going to place on the RAID Volume; as general rule; if you
want big I/O requests, you should opt for smaller RAID chunk sizes, and if I/O
will be small, you should go for larger chunks sizes.
Let me illustrate the chunk sizing with following scenarios:
Scenario 1: Let us imagine your application works with
lots of video or large image files, which means, you will need to spread data
across individual volumes as much as possible. For this scenario use smaller
RAID chunk sizes (for example, Block size 512 bytes-> 8 KB) because you want
to take data from one volume while the others seek the next chunks to be read.
Scenario 2: Let
us imagine you are running a database in which the amount of data read on each
operation is small (4KB ->16KB). Here you want a single I/O to deal with one
volume (drive) with one seek rather than the action is split between more than
one volume and multiple seeks. So, for use cases such as databases and exchange
servers, you should go for a bigger RAID chunk size say 64 KB or larger.
EBS Article Series (continued..)
Part 1: Understanding Amazon Elastic Block Store
Part 2: Understanding Standard EBS Volumes
Part 3: Understanding EBS PIOPS Volumes
Part 4: Understanding EBS-Optimized Instances
Part 5: Understanding Latency in EBS
Part 7: 10% of your provisioned IOPS 99.9% of the time
Part 8: Performance Tuning - Pre Warming the EBS volume
Part 9: Performance Tuning - EBS Striping
Part 10: Performance Tuning - IO Block Size
Part 11: Understanding Amazon EBS Snapshots
Part 12: Securing Amazon EBS volumes - EBS Encryption using SecureCloud
Part 13: Amazon EBS Security Best practices and tips
EBS Article Series (continued..)
Part 1: Understanding Amazon Elastic Block Store
Part 2: Understanding Standard EBS Volumes
Part 3: Understanding EBS PIOPS Volumes
Part 4: Understanding EBS-Optimized Instances
Part 5: Understanding Latency in EBS
Part 7: 10% of your provisioned IOPS 99.9% of the time
Part 8: Performance Tuning - Pre Warming the EBS volume
Part 9: Performance Tuning - EBS Striping
Part 10: Performance Tuning - IO Block Size
Part 11: Understanding Amazon EBS Snapshots
Part 12: Securing Amazon EBS volumes - EBS Encryption using SecureCloud
Part 13: Amazon EBS Security Best practices and tips
No comments:
Post a Comment