Datan consistency : Mirror UX vs EMC SRDF

[Mark van Hassel]

We have a discussion going about the pros and cons of using either EMC SRDF or MirrorUX in a serviceguarded environment. The discussion is mostly about data integrity. EMC says that there is a possiblity that the data is not consistent when a write is done, it is written to the first disk and than the system crashes: the write is not done on the second mirror. Database recovery tools won't help since the underlying data is not consistens (after failover LVM does not know which disk is up to date when starting to symchronise the vg's).

Does anyone have any ideas about this ? Is SRDF ALWAYS consistent ? Any good documents about this besides the SAME document ?

Thanks for your help.

Mark

[harry d brown jr]

Mark,

Mirror/UX is NOT going to REMOTELY mirror disks, whereas with SRDF you "could".

And whether you are using Mirror/UX or SRDF'd Mirrored root disks is irrelevant when the system is writing a piece of data and the system fails, or even if you have a poorly written application that performs multiple commits to a logical transaction, you can still LOSE data!

There is absolutely no way to ensure 100% data integrity or prevent any data loss. All you can do with MirrorUX and/or EMC's SRDF is reduce the likely hood of data loss and/or corruption.


live free or die
harry

[Mark van Hassel]

Harry,

Why can't we remotely mirror disks ? We have a SAN that is spread over almost 8 km. We do not encounter any problems with Mirror-UX.

[harry d brown jr]

We mirror disks with SRDF, and yes boot/roots disks, but HP's MirrorUX is for disk that the server can see via SCSI/FIBRE (local), not networked drives.

If you have a SAN and your two locations are ONE BIG FABRIC, then it's possible to use HP's MirrorUX.

live free or die
harry

[Stefan Farrelly]

Hmm. I always thought writes to mirror devices was done simeltaneously, not sequentially.

Ive got to say that over 13 years using HP-UX and Mirror/UX and ive seen lots and lots of crashes, and Ive never seen a problem where the mirror was no good and couldnt be booted from - so thats a vote for Mirror/UX, or that the supposed possibility proposed by EMC that the mirror may be inconsistent is so small (or untrue) as to not warrant any consideration.

Weve been using EMC SRDF for over 3 years now and the problem is building up experience using it. I think you need a lot of courses, experience setting it up, dealing with problems, etc. to be really really confident in it. It works absolutely fine for us - except on one ocassion where a server 'lost' an EMC disk (ioscan reported NO_HW) and eventually EMC got it back but it was a different disk and EMC couldnt explain why - except that something got screwed up in the database on the Win2k box which controls updates we make on the fly (ESN manager / control centre).

So, for us its easy, with so much experience in a reliable Mirror/UX I would always prefer that. Now, if we had someone on the team with 13 years experience in EMC's SRDF then I would possibly reconsider using it instead of Mirror/UX. Certainly my boss wants to do this, all our HP's to boot off EMC and use EMC products only, but we just dont have, or see how we can easily get, the necessary experienced person to administer it.

[Mark van Hassel]

Stefan,

I totally agree with you. The chances that a database will become corrupt because LVM synched the wrong extents are small but is there nevertheless. I also agree with the fact that maintenace wise, Mirror UX is preferable. We do have Metro clusters based on SRDF, but the problem indeed is experience.

With stand alone system theer would not be a problem when the system crashes since the Mirror Write Cache will take care of proper synchronisation. Hower in a fail over situation this is not the case and the database can become corrupt.

[Vince Inman]

In any discussion where SRDF and something else (in this case Mirror/UX), it should be noted that the basis of the mirroring is at different levels.

SRDF is an array based mirroring function whereas MirrorUX is an O/S based function.


Yet another point to consider is that SRDF is not a cheap solution and has it's own inherent set of h/w, s/w, and network requirements to be considered a viable solution. Experience in it's utilization is also a very big factor in it's successful utilization. MirrorUX by comparison is almost free when compared to SRDF.

SRDF is not bulletproof, my experience with it has shown that it can get wildly out of sync and warrants observation on a iterative basis to ensure that it is properly up to date. I have seen occurrences where EMC has had to intervene in order to unlock locked volumes so that syncing could resume.

I can't foresee a situation where a MirrorUX volume would get out of sync to the point where the data on it would be unusable, although that is possible.

The same could be said of SRDF. However for the $$$, unless the mirror is remote based (such as with SRDF), that remote mirror would not be accessed anyway.

[Mark van Hassel]

Thanks for your responses so far. I am aware about the costs of SRDF versus Mirror UX, but that is not an issue here. EMC states that there is a risk of data inconsistency: when blocks are written to the volumes and then the system crashes it could be that one disk is updated and the other is not. After the fail over, LVM will not know which extent is "leading" when syncing the volumes.

In my opinion there is always a data inconsistency risk when a system crashes no matter what disk system or mirroring tooling you use.

[Stephen Andreassend]

Hi,

If SRDF is configured properly you can have 0 data loss, it can operate in synchronous mode or asynchronous mode.

In the former case, control will only return to the application once the EMC you are directly connected to is satisfied that the write has been successful at both sites. So there is a performance dip here as there are multiple requests over the remote fibre link. On the plus side, the writes are confirmed once they are written to the redundant controller cache, not physical disks, so this does help limit the delay. Oracle is certified in this configuration as the order of writes is guaranteed, Oracle must be able to assume that once a block is written, it is safe. A transaction is committed only once the redo log writes have been completed on both EMCs, so 0 data loss. When a commit fails, the transaction rollbacks back.

In asynchronous mode, writes are not guaranteed and you risk data loss, but maintain performance. In the case of a crash when using this config with Oracle, it is not certified or recommended. If Oracle finds that the datafiles are not consistent then its most likely that an incomplete recovery will have to be performed to make the remote database copy usable.
ie data loss. If you need to maintain performance and you are using Oracle, then their DataGuard product might be more cost effective.

If your application is not doing extreme write throughput, then certainly a db server running on top of SRDF in synchronous mode is a feasible option, albeit not cheap.

Steve

[Keith Clark]

Hi Mark,

HP has an excellent document called "Designing Disaster Tolerant MC/ServiceGuard Clusters" that discusses the pros and cons of your two solutions, plus logical data replication and the "ideal replication" solution. It may help answer some of your questions. Try this URL:

http://docs.hp.com/hpux/onlinedocs/B7660-90010/B7660-90010.html

Search for "Protecting Data through Replication". You will see that both H/W and S/W replication suffer from the same issue. The logical write order is not maintained by either. This means neither one can guarantee consistency.

Check with your database vendor and/or application vendor for a certified solution and ask them to guarentee it....


Good luck,

Keith