Storage Boards Cleanup
To make it easier to find information about HPE Storage products and solutions, we are doing spring cleaning. This includes consolidation of some older boards, and a simpler structure that more accurately reflects how people use HPE Storage.
Disk Arrays
cancel
Showing results for 
Search instead for 
Did you mean: 

Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

SOLVED
Go to solution
Keith C. Patterson
Frequent Advisor

Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Hello all,
I have a customer who is adamant that there is some software or
hardware or combination of both that allows the secondary volume of a
mirror to instantaneously see the data that was created on the primary.
In all of my experience with both Windows and UNIX environments I have
not come across anything that does this.
Of course, the mirror can be created at the hardware level and in that
sense it is an exact mirror. However, in order for the filesystem to be
able to pick up the synced data it must be unmounted and then
remounted, usually with an fsck on UNIX prior to remounting.
This applies to whether or not the mirrored volume is on the same host
or a different host altogether.
Can anyone dispute this, if so can you tell me how the software is able
to pick up the changes to the volume and push it up to the filesystem
level dynamically?
Also, can anyone give me a good explanation of why this isn't possible
if this turns out to be the case? I believe it has to do with the
filesystem needing to reread in its inode table but can't say for sure.

Thanks for any advice.
8 REPLIES
Steven Clementi
Honored Contributor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Keith:


Not exactly sure where you going with this, but on a Smart Array Controller.... mirrored writes happen simulatously, thus.. you have an exact replica any given point in time.

Example... You have a 2 disk array for your OS. As your OS makes changes and.or you add/delete/modify files on the logical disk... all changes happen together on both disks. If you make a change, and as long as you wait for the change to confirm being "done" (like a file copy process or something), pull t he second drive and put it in another server... the exact contents would be from the moment you pulled out the disk. The file you just copied would be there, changes to a file... there, updates to the system... there.


This is the hardware level. In windows software based RAID, I am not sure if there is a delay. Not sure how UNIX works at all.

Now... are you talking about software mirroring with a product like OV Storage Mirroring? or similiar? 2 seperate systems mirroring data? or data on the same system but 2 seperate drives?.....


Steven
Steven Clementi
HP Master ASE, Storage and Clustering
MCSE (NT 4.0, W2K, W2K3)
VCP (ESX2, Vi3, vSphere4, vSphere5)
RHCE
NPP3 (Nutanix Platform Professional)
Devender Khatana
Honored Contributor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Hi,

In software level mirroring of any HPUx system as well any update is written to both the copies untill both are available. When anyone of the two is lost, the data updation to the failed drive is interepted and all future write take place to only the working copy. And in case of failure of any of the two copies the file system mounted from those is not effected. After recoverying the failed disk you need to manually sync the contents of the new disk with the working disk folowwed by which all writes start happening to both drives again simultaneously.

Same is the case with Windows software raid as well.

Also if you have adopted hardware level raid, your OS will not come to know unless both copies of mirror have failed and array has marked logical drive as failed.

HTH,
Devender
Impossible itself mentions "I m possible"
Keith C. Patterson
Frequent Advisor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Steven,
Your comment:
"pull t he second drive and put it in another server... the exact contents would be from the moment you pulled out the disk. The file you just copied would be there, changes to a file... there, updates to the system... there."

is exactly what I am referring to. Of course I am aware that the contents will be available on the second, but only after you "pull the second drive and put in on another server".
What I was arguing was that there is no way to do this dynamically without having to put the drive on a new server.
With a SAN even I don't think this would work where the primary is visible to server A and the secondary (mirror) is availale to server B. You would still need to sync, unmount then mount the filesystem for the copied file to be seen on the mirror.

Thanks for your response.
Keith C. Patterson
Frequent Advisor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Maybe I wasn't clear on this. I'm not talking about RAID, I'm really referring to snapshots, specifically copy-on-write.
Can a secondary host see the snapshot data on the secondary volume without unmounting and remounting the drive/volume/filesystem?

Thanks.
Uwe Zessin
Honored Contributor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

A snapshot appears as another disk. On some storage controllers (e.g. EVA) the snapshot is even writeable.

What the snapshot provides is a 'crash-consistent' 'copy' of the source data. Just pretend that you have pulled a mirrored disk from a system and now put it in a second system. The volume has not been dismounted properly and not all data might have been flushed to disk.


Once the snapshot has been created, the second host must usually scan for the device (SCSI LUN) and then mount it.

On many operating systems, a host MUST NOT have access to the primary (original) volume and the snapshot at the same time, because the snapshot carries the same meta data (e.g. disk signature, volume identifier). This confuses the OS or one of its components. For example, it assumes that the snapshot device is just another path to the same data. This can cause all kinds of data corruptions.

If you create another snapshot (is this what you mean by 'sync'?) to map it to the second server, the old volume must be removed first for the same reasons just explained. Also, some operating systems write a 'token' to the volume when they mount it. If you change the volume by presenting a new snapshot at the same SCSI address, the token does no longer match and the operating system prevents further access to the volume. In some cases you might even need to reboot the server - Windows, for example, _loves_ to cache a lot of (meta) data.


Of course, we can no longer talk about 'mirrors', because a snapshot, once taken, is not updated with new data from the original volume. It must not(!), because this would cause unexpected meta data changes for the second host. The usual result is file system corruption and even system crashes due to file system inconsistencies.
.
Vincent Fleming
Honored Contributor
Solution

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Well...

Then there is the XP Disk Arrays...

The XP is a bit different with Business Copy than most arrays. The BC's are kept "in sync" (SYNC mode) most of the time, and "split off" (PAIR SPLIT mode) when you want to make a Point-in-time (PIT) copy.

I never tried it, but I don't see why you couldn't keep the BC volume presented to a server while it's in SYNC mode. You should be able to read the BC in SYNC mode.

You are correct that host O/Ses don't deal with this senario well at all. Since UNIX and Windoze cache file metadata (in UNIX it's called an inode cache), if the underlying structure of the filesystem changes without the server knowing about it (ie: the primary updates the disk, and the secondary server doesn't know of it), the in-core cache is invalid, and will likely cause a panic.

Hence the unmount/mount being required - it would flush the metadata cache on the unmount.

Now, with the XP, you can RESYNC the BC also. Once in SPLIT mode, you can tell it to RESYNC, and when that's complete it will go back into SYNC mode, and you're ready to SPLIT again.

Note that the XP now has Snapshots as well as the standard BC I've described.


One thing you might be able to use is a Cluster Filsystem - it allows more than one server to read/write a filesystem on a SAN at the same time. Last I heard, the Veritas one works. There are others out there also. Note that a Cluster FS is not a copy of the volume, but the actual primary volume that is accessed by 2 or more servers at the same time.

Regards,

Vince

No matter where you go, there you are.
Stuart Abramson
Trusted Contributor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

I have been told that EMC TimeFinder/BCV software (on EMC hardware, of course) will allow this feature.

I've never used it myself.
Keith C. Patterson
Frequent Advisor

Re: Mirrored volume - data immediately available on the mirrored volume without umounting and remounting

Qestions answered. Meta data was the key.