What is IO
When it comes to performance issues the term you hear really often is IO. IO is a shortcut for input/output and it is basically communication between storage array and the host. Inputs are the data received by the array, and outputs are the data sent from it. To analyze and tune performance, you must understand the workload that an application and/or host is generating. Application workloads have IO characteristics. Those characteristics may be described in terms of:
- IO size
- IO access pattern
- thread count
- read/write ratio
In this post I would like to shortly go through those characteristics, because many people understands IO only as a “number of operations”, without the awareness of what this number actually means and how to understand it. Very often when people are talking about IO, what they might mean is IOPS – which is basically number of IOs per second. But to talk about IOPS and understand the number – you first have to understand and consider IO characteristics.
IO size
IO request size has an affect on performance throughput – in general, the larger the IO size, the higher the storage bandwidth. What is very often overlooked is that in most cases tools are showing the average IO size. Bare in mind that most production workloads have a mix of IO sizes.
IO access pattern
In terms of access patterns we very often use terms:
- random read/write – there is no sequential activity at all (near zero), the read and writes are purely random, almost impossible to boost performance with cache.
- sequential read/write – the exact opposite – purely sequential access, with no randomness at all. In such environments using storaga cache can really boost the performance.
In the real word you will almost never find 100% random or 100% sequential data access. Even in sequential environment there might be number of different sequential activities at the same time, which actually build randomness when switching between them.
IO access pattern may relate to IO size, with larger IO size (like 64kB etc) you most often deal with more sequential data access, whereas with small IO size (8kB for example) the access is most often random
Thread count
How many different activities are going on in the same time. If you have a single threaded IO access patterns, it means that host sends a write to a storage system, and waits for the acknowledge from the storage system that the write has completed. And once its completed it will send next write and so on. In real word most applications will produce multiple threads at the same time. They don’t have to wait for single response to send another request. If we go deeper here – one disk can do only one operation at a time. If multiple IO are targeted to the same disk we have a queue. Using queues storage system can optimize the way it works. The worst type of performance is when the tread count is 1 – how can you optimize single thread?
Read/write ratio
Writes are most expensive (performance wise) then reads. Mostly because the system has to determine where to put new chunk of data. Once it decides where to place the data the write itself is time consuming due to RAID write penalty (Of course it depends on the RAID level placed underneath). With enterprise storage system it actually changes – very often writes are faster, because they are placed into cache, and then the acknowledge to the host is send (later on writes from cache to actual hard drives are send in optimized way by storage system). Whereas reads – especially random reads, are very often un-cached and have to be fetched from hard drives.
Read/Write ratio is really important in terms of replication. Obviously only writes are being replicated, reads are not.
Workload IO and (some of the most popular) RAID Types
RAID 1/0
- Best for small random write-intensive workloads. The RAID penalty with RAID 1/0 is only 2. That’s the lowest of all the RAID types (that actually give you some kind of failure protection)
RAID 5
- Good mix of performance and protection. But the RAID penalty is 4, so the performance is much worst with small random writes.
- Best with client write IO size of 64 KB or lager – full stripe writes can really boost the performance, you can write the entire stripe without a need of reading the parity information – which of course lower the RAID penalty.
- Best practice is to use RAID 5 for workloads that have random writes of 30% or less.
RAID 6
- More protection due to two parity disks, but at the same time higher RAID penalty – which is 6.
- Very often used with NL-SAS drives (or SATA drives) which are the cheapest in terms of TB/$, but are the slowest.
Don’t forget that latent disk errors are one of the biggest problems with RAID technology. If you are rebuilding a RAID, Unrecoverable Read Error (URE) can stop a RAID rebuild in its track, essentially making the entire RAID volume unusable.
http://www.smbitjournal.com/2012/05/when-no-redundancy-is-more-reliable/
Typical ranges for hard drives are around 1 x 10^14 bits which means that 1 out of every 10^14 bits cannot be read. This means if you have 12TBs or 12x 1TB drives your probability of encountering a URE is one (i.e. it’s going to happen). If you have 2TB drives, then all you need is 6x 2TB drives and you will encounter a URE. If you have a RAID-5 group that has seven 2TB drives and one drive fails, the RAID rebuild has to read all of the remaining disks (all six of them). At that point you are almost guaranteed that during the RAID-5 rebuild, you will hit a URE and the RAID rebuild will fail. This means you have lost all of your data.
http://www.lucidti.com/zfs-checksums-add-reliability-to-nas-storage