you are rigth:Vplex witness is used for guranting the survivality in case of vplex interconnect failure.
As you know, vplex is a storage virtualization solution, it make two storage arrays appear as a SINGLE storage array to the hosts. every block written to the vplex cluster will go to both storage arrays. each of the storage arrays has an exact copy of data. so for the CRS and Voting disk files, storage array 1 and storage array 2 all maintain the same copy of data. To clarify, for an Oracle RAC database, the number of CRS and Voting disk files do not change, not matter how many RAC nodes you add to the cluster. so in a extended RAC database deployment, storage array 1 maintain a copy of CRS and Voting disk files, storage array 2 also maintain an exact copy of CRS and Voting disk files as storage array 1. If one of the underlying storage array goes down, the access to the CRS and Voting disks files will be redirect to the surviving storage array, the access to the storage array will not be disrupted, and the instance will not aware what is happening on the underlying storage array.
One of the advantages of using the VPLEX witness is that it removes the need for a voting disk at a 3rd site.It is explained in detail in the following whitepaper
The synchronization services component (CSS) of the Oracle Clusterware, which synchronizes the Oracle RAC nodes, maintains two heartbeat mechanisms
1) the disk heartbeat to the voting device and
2) the network heartbeat across the interconnect
Both of these heartbeat mechanisms have an associated timeout value.
The disk heartbeat has an internal i/o timeout interval (DTO Disk Timeout), in seconds, where an i/o to the voting disk must complete: 200s
The css misscount parameter (MC), is the maximum time, in seconds, that a network heartbeat can be missed, it defaults to 45s. On VPLEX it is recommended that css miscount is set to a value of 45 seconds. It is based on worst case scenario for VPLEX Metro reconfiguration and RAC will comply based on quorum accessibility only at the site VPLEX determined as surviving.
We have tested and validated this in a number of use cases and through elab we tested, validated and certified, with Oracle, these failures and more all the way down to the component level in the attached network, arrays and servers.
You can see this in action in at the EMC demo center. The links are below.
blue_or_white
13 Posts
0
September 18th, 2012 01:00
Hi, buddies
you are rigth:Vplex witness is used for guranting the survivality in case of vplex interconnect failure.
As you know, vplex is a storage virtualization solution, it make two storage arrays appear as a SINGLE storage array to the hosts. every block written to the vplex cluster will go to both storage arrays. each of the storage arrays has an exact copy of data. so for the CRS and Voting disk files, storage array 1 and storage array 2 all maintain the same copy of data. To clarify, for an Oracle RAC database, the number of CRS and Voting disk files do not change, not matter how many RAC nodes you add to the cluster. so in a extended RAC database deployment, storage array 1 maintain a copy of CRS and Voting disk files, storage array 2 also maintain an exact copy of CRS and Voting disk files as storage array 1. If one of the underlying storage array goes down, the access to the CRS and Voting disks files will be redirect to the surviving storage array, the access to the storage array will not be disrupted, and the instance will not aware what is happening on the underlying storage array.
dba_hba
63 Posts
0
September 19th, 2012 00:00
YongDae
One of the advantages of using the VPLEX witness is that it removes the need for a voting disk at a 3rd site.It is explained in detail in the following whitepaper
https://community.emc.com/servlet/JiveServlet/downloadBody/18796-102-1-66849/h8930-vplex-metro-oracle-rac-wp.pdf
The synchronization services component (CSS) of the Oracle Clusterware, which synchronizes the Oracle RAC nodes, maintains two heartbeat mechanisms
1) the disk heartbeat to the voting device and
2) the network heartbeat across the interconnect
Both of these heartbeat mechanisms have an associated timeout value.
The disk heartbeat has an internal i/o timeout interval (DTO Disk Timeout), in seconds, where an i/o to the voting disk must complete: 200s
The css misscount parameter (MC), is the maximum time, in seconds, that a network heartbeat can be missed, it defaults to 45s. On VPLEX it is recommended that css miscount is set to a value of 45 seconds. It is based on worst case scenario for VPLEX Metro reconfiguration and RAC will comply based on quorum accessibility only at the site VPLEX determined as surviving.
We have tested and validated this in a number of use cases and through elab we tested, validated and certified, with Oracle, these failures and more all the way down to the component level in the attached network, arrays and servers.
You can see this in action in at the EMC demo center. The links are below.
The Chinese Language Version is here
The English Language Version is here