Following are a list of guidelines regarding zone clusters:
When you first install the operating system instances on a domain, that domain is automatically designated as the global zone. Any domains or zones that you create from that point forward are nonglobal zones.
Global zones and nonglobal zones cannot run RAC clusterware in the same domain. When a Database Domain is created and an operating system is installed on the Database Domain, that domain is considered a global zone. The following scenarios describe what is and is not acceptable in that situation:
If you have two Database Domains (global zones) and those Database Domains are members of a cluster, you cannot create zones on those Database Domains and have those zones as members of their own clusters. Because those zones would be considered non-global zones, you cannot have those non-global zones running RAC clusterware within Database Domains that are also running RAC clusterware.
If you have two Database Domains (global zones) but those Database Domains are not members of a cluster, then you can create zones on those Database Domains and have those zones as members of their own clusters.
Each zone that is a member of that cluster should use the same number of cores.
Clusters should be created where the zones that are members of a cluster should be on separate Database Domains, and the cluster spans across both SPARC T5-8 servers so that there is not a single point of failure.
You can cluster zones together across multiple Database Domains that are of different sizes. For example, you can create a two-node cluster, where there is one zone on the Database Domains on the two SPARC T5-8 servers, and those zones are clustered together, even if one of the Database Domains is a Medium Domain and the other Database Domain is a Small Domain. The private interface connections (the IB connections) are limited to the lower number from the smaller domain, based on the IB HCAs available to the zone.