- Community Home
- >
- Storage
- >
- Midrange and Enterprise Storage
- >
- HPE EVA Storage
- >
- Re: Continuous Access Question
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-03-2011 09:17 AM
тАО02-03-2011 09:17 AM
Should a failure occur with one EVA, I need to know the setting that would provide the "quickest" recovery on the backup EVA. The source and destination servers will mostly be Microsoft Clusers (MSCS).
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-03-2011 11:03 AM
тАО02-03-2011 11:03 AM
Re: Continuous Access Question
HP StorageWorks Cluster Extension (CLX) software offers protection against system downtime from fault, failure and disasters after using Replication in EVA
http://h20338.www2.hp.com/ActiveAnswers/cache/414462-0-0-0-121.html
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-03-2011 11:10 AM
тАО02-03-2011 11:10 AM
Re: Continuous Access Question
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-03-2011 03:58 PM
тАО02-03-2011 03:58 PM
Re: Continuous Access Question
In other words, if you present your destination vdisks to your servers, they won't be able to see the disks anyway until you failover. If so, the setting dos not matter when you are dealing with the servers that are accessing the source luns... you want them to be able to read/write at that time when/after you need to failover.
Steven
HP Master ASE, Storage, Servers, and Clustering
MCSE (NT 4.0, W2K, W2K3)
VCP (ESX2, Vi3, vSphere4, vSphere5, vSphere 6.x)
RHCE
NPP3 (Nutanix Platform Professional)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-03-2011 04:06 PM
тАО02-03-2011 04:06 PM
Re: Continuous Access Question
I guess my core question is.....Is there any reason not to create them all as Read Only instead of None or Inquire Only? I just don't see any reason to have it as "None" or even "Inquire Only".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2011 01:33 AM
тАО02-04-2011 01:33 AM
Re: Continuous Access Question
This is what the help says:
#
None. The virtual disk cannot be presented to hosts.
#
Inquiry only. The virtual disk can be presented to hosts, but hosts can only make SCSI inquiries. No host I/O is allowed. This mode is typically used with host clusters.
#
Read only. The virtual disk can be presented to hosts, but for read only.
We leave ours set to None, which doesn't make sense as when we failover the LUN IS presented to the DR server. Then the servers boot automatically when they see the storage as they are powered on cycling the boot devices.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2011 01:44 AM
тАО02-04-2011 01:44 AM
Re: Continuous Access Question
Sorry, but "backup" or "cluster failovers without CLX" are *NOT* valid reasons to use R/O or INQ_O.
In the case of R/O you risk writing corrupted data to tape or crashing your backup server -
no offense, but that's why I wrote: "explain ... how a file system works".
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2011 06:00 AM
тАО02-04-2011 06:00 AM
Re: Continuous Access Question
Also, I don't understand your comment about corrupt data to tape and crashing backup servers. Tape has nothing to do with anything and how would our backup servers crash when using Read Only as opposed to None? The data is still replicated in the same way.
Thanks to all. I hope I'm not sounding critical of everyone but I still haven't heard a valid reason to use one over the other in terms of Read Only, Inq Only, and None.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2011 07:17 AM
тАО02-04-2011 07:17 AM
SolutionINQ_O is used in some special VMware failover environments to pre-populate SCSI targets/LUNS.
If you mount a destination vdisk R/O (if the operation system allows this...) while the EVA is going on with the replication in the background, the data/meta-data is changing all the time. Such changes are not expected by filesystems like NTFS which do local caching because they expect that no other instance is doing changes.
Inconsistencies in the meta-data can lead to crashes of the filesystem software which downs the entire OS. A 'stable' view to the filesystem is provided through snapshots or clones.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2011 08:34 AM
тАО02-04-2011 08:34 AM