When the application failover happens in VMware Guest enviorments, the VCS is responsible for failing over the application to other vm/vcs node on diffrent ESX host.
In a scenario where the ESX/ESXi host itself faults, the VCS agents begin to fail over the application to the failover target system that resides on another host. The VMwareDisks agent communicates with the new ESX/ESXi host and initiates a disk detach operation on the faulted virtual machine. The agent then attaches the disk to the new failover target virtual machine.
In this senario, how are the stale i/o from failing over guest/ESX host avoided? Are we on the mercy of VMware to take care of it? With SCSI3 PR this was the main problem that was solved. Moreover in such senario's even a garceful online detach wouldnt have gone through. I didnt find any references on VMware discussions forums as well.
My customer wants to know about it, before he can deploy the application.
here is a list of vxfs mount options that may be used depending on the context/deployment - you may have buffered IOs that are not yet written to disk (stale IOs as you mention) or just write bypass the buffer if thats a concern for specific filesystems/data by using direct io:
Thanks. But I was concerned about i/o which are inflight. Like on the wire to complete and the VM/ESX host failure happens. In such situation I dont think the DIRECT mode would be either helpful. To avoid such situations I thought VCS used SCSI3 PR on physical clusters. Now that its virtual and attach/detach is the way to go, I was hoping this would do the similar job when you do a remote detach of disk.
Nope even in the case of physical clusters inflight transactions would get lost. It is usually the client apps that must ensure that the intended writes happened successfully, if not (the client apps) would retry the writes.
the in-flight transactions would get lost. How is that possible? Then what is the use SCSI3 PR in physical cluster? I am confused now.
Anyhow it sounds like the detach would take care of in-flight transactions in VMware host. Since I saw in symantec website that SCSI3 PR is a challenge in VMware enviornments, Symantec took the attach and detach route. That is the reason I wanted to know, would the detach do the same as SCSI3 PR would do on remote node during fail over/recovery.
I/O Fencing is a base part of Veritas Cluster Server focused on properly handling a cluster partition event or the loss of cluster communication. I/O Fencing consists of two distinct components, Membership Arbitration and Data Protection; together they are able to deliver maximum data *integrity* in a cluster environment --so you can be rest assured that no two cluster partitions will write to the shared disks in an uncoordinated manner (in the event of a cluster partition). It does not intended to recover/re-route inflight/stale IOs from clients. I hope that clarifies. For additional details on fencing with VCS, please see:
Previously, SFHA or SFCFS cluster used to support non-SCSI3 server-based I/O fencing in virtual environments. i.e. you need to configure CPS (coordination point servers). For details please see https://sort.symantec.com/public/documents/sfha/6.0/aix/productguides/html/sfcfs_install/ch10s04.htm
But now it introduces support for SCSI3 I/O fencing with SFHA and SFCFS clusters of VMware Virtual
Machines with some limittaions. For details, please see http://clientui-kb.symantec.com/resources/sites/BUSINESS/content/live/TECHNICAL_SOLUTION/169000/TECH169366/en_US/TechNote_VMware_IOFencing.pdf