It is small xml file located in $GRID_HOME/gpnp/<hostname>/profiles/peer under the name profile.xml. It is used to establish the correct global personality of a node. Each node maintains a local copy of the GPnP Profile and is maintanied by the GPnP Deamon (GPnPD) .
So from the above dump we can see that GPnP profile contains following information:-
1) Cluster Name
2) Network Profile
3) CSS-Profile tag
4) ASM-Profile tag
GPnP Service The GPnP service is collectively provided by all the GPnP agents. It is a distributed method of replicating profiles. The service is instantiated on each node in the domain as a GPnP agent. The service is peer-to-peer; there is no master process. This allows high availability because any GPnP agent can crash and new nodes will still be serviced. GPnP requires standard IP multicast protocol (provided by mDNS) to locate peer services.
Using multicast discovery, GPnP locates peers without configuration. This is how a GPnP agent on a new node locates another agent that may have a profile it should use.
Name Resolution:
A name defined within a GPnP domain is resolvable in the following cases:
Hosts inside the GPnP domain use normal DNS to resolve the names of hosts outside of the GPnP domain.They contact the regular DNS service and proceed. They may get the address of the DNS server by global configuration or by having been told by DHCP.
Within the GPnP domain, host names are resolved using mDNS. This requires an mDNS responder on each node that knows the names and addresses used by this node, and operating system client library support for name resolution using this multicast protocol. Given a name, a client executes gethostbyname, resulting in an mDNS query. If the name exists, the responder on the node that owns the name will respond with the IP address. The client software may cache the resolution for the given time-to-live value.
Machines outside the GPnP domain cannot resolve names in the GPnP domain by using multicast. To resolve these names, they use their regular DNS. The provisioning authority arranges the global DNS to delegate a subdomain (zone) to a known address that is in the GPnP domain. GPnP creates a service called GNS to resolve the GPnP names on that fixed address. The node on which the GNS server is running listens for DNS requests. On receipt, they translate and forward to mDNS, collect responses, translate, and send back to the outside client. GNS is “virtual” because it is stateless. Any node in the multicast domain may host the server.
Only the GNS configuration is global:
1) The address on which to listen on standard DNS port 53
2) The name(s) of the domains to be serviced.
There may be as many GNS entities as needed for availability reasons. Oracle-provided GNS may use CRS
to ensure availability of a single GNS provider.
SCAN and Local Listeners:
When a client submits a connection request, the SCAN listener listening on a SCAN IP address and the SCAN port are contacted on the client’s behalf. Because all services on the cluster are registered with the SCAN listener, the SCAN listener replies with the address of the local listener on the least-loaded node where the service is currently being offered. Finally, the client establishes a connection to the service through the listener on the node where service is offered. All these actions take place transparently to the client without any explicit configuration required in the client. During installation, listeners are created on nodes for the SCAN IP addresses. Oracle Net Services routes application requests to the least loaded instance providing the service.
Because the SCAN addresses resolve to the cluster, rather than to a node address in the cluster, nodes can beadded to or removed from the cluster without affecting the SCAN address configuration.
We can also check GPnP profile using below command :
