GPNP Profile Internals & OLR Internals for Oracle RAC 11G

GPNP Profile Internals (Oracle RAC 11G)

The GPnP profile is a XML file located at location /profiles/peer as profile.xml. Each node of the cluster maintains a copy of this profile locally and is maintained by GPnP daemon along with mdns daemon.

Now before understanding why Oracle came up with GPnP profile, we need to focus on what it contains.

GPnP defines a node’s meta data about network interfaces for public and private interconnect, the ASM server parameter file, and CSS voting disks. This profile is protected by a wallet against modification. If you have to manually modify the profile, it must first be unsigned with $GRID_HOME/bin/gpnptool, modified, and then signed again with the same utility, however there is a very slight chance you would ever be required to do so.

Now we’ll use the gpnptool with get option to dump this xml file into standard output. Below is the formatted output for the ease of readability.

http://www.xyz/gpnp-profile&#8221

;
xmlns:gpnp=”http://xyz/gpnp-profile”
xmlns:orcl=”http://xyz/gpnp-profile”
xmlns:xsi=”http://xyz/XMLSchema-instance”
xsi:schemaLocation=”http://xyz/gpnp-profile gpnp-profile.xsd”
ProfileSequence=”3″ ClusterUId=”002c207a71cvaljgkcea7bea5b3a49″
ClusterName=”Cluster01″ PALocation=””>
Network-Profile>


Use=”cluster_interconnect”/>

CSS-Profile id=”css” DiscoveryString=”+asm” LeaseDuration=”400″ />
ASM-Profile id=”asm” DiscoveryString=””
SPFile=”+DATA/prod/asmparameterfile/registry.253.699915959″ />
…

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

Now that we have understood the content of a GPnP profile, we need to understand how the Clusterware uses this information to start. From 11gr2 you have the option of storing the OCR and Voting disk on ASM, but clusterware needs OCR and Voting disk to start crsd & cssd and both these files are on ASM which itself is a resource for the node. so how does the clusterware starts, which files it accesses to get the information needed to start clusterware, to resolve this Oracle came up with two local operating system files OLR & GPnP.

When a node of an Oracle Clusterware cluster restarts, OHASD is started by platform-specific means.OHASD has access to the OLR (Oracle Local Registry) stored on the local file system. OLR provides needed data to complete OHASD initialization

OHASD brings up GPnP Daemon and CSS Daemon. CSS Daemon has access to the GPNP Profile stored on the local file system.
The Voting Files locations on ASM Disks are accessed by CSSD with well-known pointers in the ASM Disk headers and CSSD is able to complete initialization and start or join an existing cluster.
OHASD starts an ASM instance and ASM can now operate with CSSD initialized and operating. The ASM instance uses special code to locate the contents of the ASM SPFILE, assuming it is stored in a Diskgroup.
With an ASM instance operating and its Diskgroups mounted, access to Clusterware’s OCR is available to CRSD.OHASDstarts CRSD with access to the OCR in an ASM Diskgroup.And thus Clusterware completes initialization and brings up other services under its control.

Thus with the use of GPnP profile several information stored in it along with the information in the OLR several tasks have been automated or eased for the administrators.

I hope the above information helps you in understanding the Grid plug and play profile, its content, its usage and why was it required. Please comment below if you need more information on GPnP as in the complete dump of the profile, how GPnP daemon and mdns daemon communicates to maintain the updated profile on all the nodes, how does oifcfg, crsctl, asmcmd and other utilities does uses IPC to alter the content of these files accordingly, etc.

======================================================================

OLR Internals (Oracle RAC)Share on Facebook

• Share on Twitter

With 11gr2 Oracle introduced Oracle Local Registry (OLR), OLR is the OCR’s local counterpart and a new feature introduced with Grid Infrastructure. The OLR file is located in the grid_home/cdata/.olr & the location of OLR is stored in /etc/oracle/olr.loc. Each node has its own copy of the file in the Grid Infrastructure software home. The OLR stores important security contexts used by the Oracle High Availability Service early in the start sequence of Clusterware. The information stored in the OLR is needed by the Oracle High Availability Services
daemon (OHASD) to start; this includes data about GPnP wallets, Clusterware configuration, and version information. The information in the OLR and the Grid Plug and Play configuration file are needed to locate the voting disks. If they are stored in ASM, the discovery string in the GPnP profile will
be used by the cluster synchronization daemon to look them up.

In the following post I’ll try to describe the purpose of OLR, why Oracle has to come up with this file, what is stored in this file.
To understand all these questions we need to understand what it contains, hence taking dump of OLR

ocrdump -local -stdout

[SYSTEM.OHASD.RESOURCES.ora!DB11G!db][SYSTEM.OHASD.RESOURCES.ora!DB11G!db.CONFIG]ORATEXT: ACL=owner:grid:rwx,pgrp:asmdba:r-x,other::r–,group:oinstall:r-x,user:oracle:rwx~ACTION_FAILURE_TEMPLATE=
~ACTION_SCRIPT=~ACTIVE_PLACEMENT=1~AGENT_FILE~NAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX
~AUTO_START=restore~BASE_TYPE=ora.cluster_resource.type~CARDINALITY=1~CHECK_INTERVAL=1
~CHECK_TIMEOUT=30~CLUSTER_DATABASE=false~DATABASE_TYPE=SINGLE~DB_UNIQUE_NAME=DB11G
~DEFAULT_TEMPLATE=PROPERTY(RESOURCE_CLASS=database) PROPERTY(DB_UNIQUE_NAME= CONCAT(PARSE(%NAME%, ., 2), %USR_ORA_DOMAIN%, .)) ELEMENT(INSTANCE_NAME= %GEN_USR_ORA_INST_NAME%) ELEMENT(DATABASE_TYPE=%DATABASE_TYPE%)~DEGREE=1~DESCRIPTION=Oracle Database resource~ENABLED=1
~FAILOVER_DELAY=0~FAILURE_INTERVAL=60~FAILURE_THRESHOLD=1~GEN_AUDIT_FILE_DEST=/oradata/DB11G/admin/adump~GEN_START_OPTIONS=open~GEN_USR_ORA_INST_NAME=DB11G
~HOSTING_MEMBERS=~INSTANCE_FAILOVER=1~LOAD=1~LOGGING_LEVEL=1~MANAGEMENT_POLICY=AUTOMATIC
~NAME=ora.DB11G.db~NLS_LANG=~NOT_RESTARTING_TEMPLATE=~OFFLINE_CHECK_INTERVAL=0
~ONLINE_RELOCATION_TIMEOUT=0~ORACLE_HOME=/opt/oracle/product/base/11.2.0.3~ORACLE_HOME_OLD=
~PLACEMENT=balanced~PROFILE_CHANGE_TEMPLATE=~RESTART_ATTEMPTS=2~ROLE=PRIMARY~SCRIPT_TIMEOUT=60
~SERVER_POOLS=~SPFILE=/opt/oracle/product/base/11.2.0.3/dbs/spfileDB11G.ora
~START_DEPENDENCIES=weak(type:ora.listener.type,uniform:ora.ons)hard(ora.DB11G_DATA_DG.dg,ora.DB11G_ARCH_DG.dg) pullup(ora.DB11G_DATA_DG.dg,ora.DB11G_ARCH_DG.dg)~START_TIMEOUT=600~STATE_CHANGE_TEMPLATE=
~STOP_DEPENDENCIES=hard(intermediate:ora.asm,shutdown:ora.DB11G_DATA_DG.dg,shutdown:ora.DB11G_ARCH_DG.dg
~STOP_TIMEOUT=600~TYPE=ora.database.type~TYPE_ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r–~TYPE_NAME=ora.database.type
~TYPE_VERSION=3.2~UPTIME_THRESHOLD=1h~USR_ORA_DB_NAME=~USR_ORA_DOMAIN=~USR_ORA_ENV=
~USR_ORA_FLAGS=~USR_ORA_INST_NAME=DB11G~USR_ORA_OPEN_MODE=open~USR_ORA_OPI=false
~USR_ORA_STOP_MODE=immediate~VERSION=11.2.0.3.0

I tried to format the output as much as I can, the point here is to understand that there is a lot of information present in OLR like ORA_CRS_HOME, Clusterware version, Clusterware configuration, localhost version, activeversion, GPnP details, OCR latest backup time and location, node name, status of resources of the node as in which to be started and which not, and also the start & stop dependencies of resources etc.
Start & Stop Dependencies are classified as weak (Should fulfill) & hard (Must fulfill).

Now we’ll understand the purpose of this file, we know that OCR needs to be accessible by Clusterware to know which resources to be started on a node, but as from 11gr2, Oracle has given the luxury to store OCR in ASM how does Clusterware accesses this information while ASM (which itself is a resource for the node) is Down, here comes the OLR. Since OLR is an locally available file on operating system there is no dependencies and this file could be read by any process with appropriate privileges.

The High Availability Services stack consists of daemons that communicate with their peers on the other nodes. As soon as the High Availability Services stack is up, the cluster node can join the cluster and use the shared components (e.g., the OCR). The startup sequence of the High Availability Services stack is stored partly in the Grid Plug and Play profile, but that sequence also depends on information stored in the OLR.

Now the question that comes to our mind is if we have OLR then why do we need OCR, to explain this we compared the keys of OLR & OCR.
Comparing the OCR with the OLR reveals that the OLR has far fewer keys; for example, ocrdump reported 704 different keys for the OCR vs. 526 keys for the OLR on our installation. If you compare only the keys again, you will notice that the majority of keys in the OLR deal with the OHASD process, whereas the majority of keys in the OCR deal with the CRSD. This confirms that you need the OLR (along with the GPnP profile) to start the High Availability Services stack.

I hope the above information helps you in understanding OLR, its purpose, its content, its usage and why was it required. 

====================================================

For Ref: https://nitishanandsrivastava.wordpress.com/
==============================================