SRL Disk Performance

[Joe_Angelis]

I'm trying to find some information on how to determine what disks to put your SRL on.  I've found a lot of information on what size to estimate but not what disks to put it on except that it should be fast RAID 1/0.  We are using async mode and since the OS will write to the SRL first them confirm the write to the OS before actually writing to the primary volume it would seem logical that the SRL then becomes your bottleneck in terms of disk I/O.  E.g. if I've estimated that my Exchange box needs 1000 IOPS then it would seem the SRL would need to be capable of 1000 IOPS in order to properly service Exchange and further that the disks for the primary volume does not necessarily need to be able to handle 1000 IOPS since the OS won't we waiting for blocks to be written on the primary volume.

Is this true?  Can anyone give me some specific advice on how the SRL disks should be spec'd in relation to Application disk performance requirements?

Thanks.

[Hywel_Mallett]

I can't give you any specific advice or guidelines, but as you say, it would seem to make sense to have the SRL on fast disk. One point I did read somewhere was that in async mode, write performance can actually be improved, as writes are confirmed after writing to the SRL, and the SRL writes sequentially, rather than at random.

[Ignignokt]

Budget considerations seem to trump all other concerns, in most Exchange environments. To replicate a transaction intensive application like exchange, the WAN interconnect will more likely be the limitation.

(Just a guess so far, as the only dimension mentioned is IOPs)

My next guess is that you have a low to mid-range array for disk.

Give the SRL it's own LUN. If the array offers backend striping, do so.

If you don't have an array and are sweating it with JBOD, buy Volume Manager.

If you have to stripe disk, take stats before you settle for a layout.

The network will be the bottleneck.

Unless you have dark fibre or the machine is within 500 meters.

Trust me. I've done it on way bigger boxen.

[maral]

Your logic is correct.

In order to prevent an SRL bottleneck, SRL performance should be proportional to the sum of all volumes you intend on replicating. This can be calculated as IOPS or MB/s.

The difference (which has been pointed out) between the SRL and data volumes is the read / write pattern. The SRL is read and written sequentially. Under optimal circumstances it is only written too. However, if your network suffers an outage; upon re-establishing connectivity VVR will read from the SRL in order to synchronise the secondary with the primary. The amount that needs to be read is subject to the duration of the network outage and volume of writes accumulated during the outage. We call this SRL readback.

Consequently, to cater for current performance and some level of readback it would be ideal to provision additional performance. For example, say a factor of 110% of the data volumes performance.

With respect to physical SRL layout there are three strategies available:

1. Dedicate disk spindles to the SRL

Benefit of this strategy is that performance is deterministic. Downside is when allocating disk with performance in mind it is inevitable that you will be left with spare capacity that can not be used elsewhere (for performance reasons).

2. Use the SAME approach.

Stripe and Mirror Everything so that data and SRL volumes share a portion of the disks available performance and capacity.

Benefit of this strategy is balanced performance and optimal capacity utilisation. Downside is you add risk by adopting a shared model since a striped disk layouts performance is only as good as its weakest link (i.e. hot spot). Having said that, if the upfront design is thorough and reporting / performance monitoring is ongoing the risk is manageable.

3. Use solid state disk

Benefit of this strategy is that performance is deterministic and capacity utilisation is optimal since solid state disks capacity and performance ratios are more in line with the SRL's capacity / performance mix. Downside is obviously expense and availability.

Unfortunately, there is no silver bullet nor do I believe in them. The strategy you adopt should be aligned with your projects objectives and systems posture (e.g. is the environment risk averse? If so, use dedicated disks or solid state. If the environment is cost conscious use the SAME approach).

Hope this helps.

Message Edited by maral on 07-30-200709:40 PM