Quote Originally Posted by d2globalinc
I'm looking at putting in place something similar. With iSCSI HA fallover - I take it from what your saying that if the primary server writes something to disk, it doesn't acknowledge the write action until the secondary does too? Does the secondary use any kind of caching with its writes so that at least it could have some sort of buffer before slowing down the writes on the primary? Just something im trying to get a grasp on.. What type of connection do you have between primary and secondary servers? 1GbE, 10GbE?

Thanks!

- D2G
Right, that's my understanding. I haven't done performance testing with Writeback on vs. writeback off, because I've only used it in an HA failover environment. The recommendation is to have writethrough on (i.e., writeback off) so that in the event of a hardware failure on the primary OR secondary, the data will be consistent. I suppose you could set the secondary to use writeback for its luns, but then you'd have the case where you failover from your primary to secondary, and now your writes don't have the 100% integrity guaranteed by writethrough. That may be an edge case.

I have two servers (Silicon Mechanics boxes) configured with six network interfaces, two bonded for iscsi, two bonded for replication, and two bonded for management. They're all 1gb ethernet. In my case, I haven't felt like the replication was holding back write performance. The writes per sec are still going to be limited by how many disks you have and what their performance capabilities are. My workload is VMWare virtual machines, and that means it skews more towards random i/o as opposed to sequential, so having the write cache enabled or disabled probably doesn't make that much difference as far as performance goes. If I was using DSS for a heavily database-oriented sequential write workload I would probably notice it more.

In my environment it bothers me more that I have a box of disks sitting idle instead of contributing their spindles to help improve read performance. I'm considering breaking the replication / HA pair apart, using each DSS individually to split the workload between them, and then looking at some software for the data replication. In other words, put 20 vm guests on DSS-A and 20 vm's on DSS-B, and cross-replicate them so that if either DSS goes down, the replicas are present on the other box. Plus that would allow me to have two independent DSS storage groups so I can use storage vmotion to migrate all of my vm's to one DSS, update the software on the other one, move them the other direction, update, etc. I'm still leery of doing a software update on a HA failover pair while the vm's are powered up and in production.

Hope that helps,
James