| Oracle® Grid Infrastructure Installation Guide 11g Release 2 (11.2) for Solaris Operating System Part Number E17213-07 |
|
|
PDF · Mobi · ePub |
| Oracle® Grid Infrastructure Installation Guide 11g Release 2 (11.2) for Solaris Operating System Part Number E17213-07 |
|
|
PDF · Mobi · ePub |
This chapter describes the difference between a Typical and Advanced installation for Oracle Grid Infrastructure for a cluster, and describes the steps required to complete a Typical installation.
This chapter contains the following sections:
There are two installation options for Oracle Grid Infrastructure installations:
Typical Installation: The Typical installation option is a simplified installation with a minimal number of manual configuration choices. Oracle recommends that you select this installation type for most cluster implementations.
Advanced Installation: The Advanced Installation option is an advanced procedure that requires a higher degree of system knowledge. It enables you to select particular configuration choices, including additional storage and network choices, use of operating system group authentication for role-based administrative privileges, integration with IPMI, or more granularity in specifying Oracle Automatic Storage Management roles.
With Oracle Clusterware 11g release 2 (11.2), during installation Oracle Universal Installer (OUI) generates Fixup scripts (runfixup.sh) that you can run to complete required preinstallation steps.
Fixup scripts are generated during installation. You are prompted to run scripts as root in a separate terminal session. When you run scripts, they complete the following configuration tasks:
If necessary, sets kernel parameters required for installation and runtime to at least the minimum value.
Reconfigures primary and secondary group memberships for the installation owner, if necessary, for the Oracle Inventory directory and the operating system privileges groups.
Sets shell limits if necessary to required values.
Note:
In Solaris 10, you are not required to make changes to the
/etc/system file to implement the System V IPC. Solaris 10 uses the resource control facility for its implementation. However, Oracle recommends that you set both resource control and /etc/system/ parameters. Operating system parameters not replaced by resource controls continue to affect performance and security on Solaris 10 systems.Complete the following manual configuration tasks
See Also:
Chapter 2, "Advanced Installation Oracle Grid Infrastructure for a Cluster Preinstallation Tasks" and Chapter 3, "Configuring Storage for Grid Infrastructure for a Cluster and Oracle Real Application Clusters (Oracle RAC)" if you need any information about how to complete these tasksEnter the following commands to check available memory:
# /usr/sbin/prtconf | grep "Memory size" # /usr/sbin/swap -s
The minimum required RAM is at least 4 GB of RAM for Oracle Grid Infrastructure for a Cluster installations, including installations where you plan to install Oracle RAC. For systems with 4 GB to 16 GB RAM, use swap space equal to RAM. For systems with more than 16 GB RAM, use 0.75 x RAM as the swap space. If you use non-swappable memory, such as ISM, then you should deduct the memory allocated to this space from the available RAM before calculating swap space. If you plan to install Oracle Database or Oracle RAC on systems using DISM, then available swap space must be at least equal to the sum of the SGA sizes of all instances running on the servers.
If the swap space and the Grid home are on the same filesystem, then add together their respective disk space requirements for the total minimum space required.
df -h
This command checks the available space on file systems. If you use normal redundancy for Oracle Clusterware files, which is three Oracle Cluster Registry (OCR) locations and three voting disk locations, then you should have at least 2 GB of file space available on shared storage volumes reserved for Oracle Grid Infrastructure files.
Note:
You cannot install OCR or voting disk files on raw partitions. You can install only on Oracle ASM, or on supported network-attached storage or cluster file systems. The only use for raw devices is as Oracle ASM disks.If you plan to install on Oracle ASM, then to ensure high availability of OCR or voting disk files on Oracle ASM, you need to have at least 2 GB of disk space for Oracle Clusterware files in three separate failure groups, with at least three physical disks. Each disk must have at least 1 GB of capacity to ensure that there is sufficient space to create Oracle Clusterware files.
Ensure you have at least 5.5 GB of space for the Oracle Grid Infrastructure for a Cluster home (Grid home) This includes Oracle Clusterware and Oracle Automatic Storage Management (Oracle ASM) files and log files, and includes the Cluster Health Monitor repository.
df -h /tmp
Ensure that you have at least 1.5 GB of space in /tmp. If this space is not available, then increase the size, or delete unnecessary files in /tmp.
Ensure that you have the following available:
During Typical installation, you are prompted to confirm the default Single Client Access Name (SCAN), which is used to connect to databases within the cluster irrespective of which nodes they are running on. By default, the name used as the SCAN is also the name of the cluster. The default value for the SCAN is based on the local node name. If you change the SCAN from the default, then the name that you use must be globally unique throughout your enterprise.
In a Typical installation, the SCAN is also the name of the cluster. The SCAN and cluster name must be at least one character long and no more than 15 characters in length, must be alphanumeric, and may contain hyphens (-).
For example:
NE-Sa89
If you require a SCAN that is longer than15 characters, then be aware that the cluster name defaults to the first 15 characters of the SCAN.
Before starting the installation, you must have at least two interfaces configured on each node: One for the private IP address and one for the public IP address.
If you do not enable GNS, then the public and virtual IP addresses for each node must be static IP addresses, configured before installation for each node, but not currently in use. Public and virtual IP addresses must be on the same subnet.
Oracle Clusterware manages private IP addresses in the private subnet on interfaces you identify as private during the installation interview.
The cluster must have the following addresses configured:
The cluster must have the following addresses configured:
A public IP address for each node, with the following characteristics:
Static IP address
Configured before installation for each node, and resolvable to that node before installation
On the same subnet as all other public IP addresses, VIP addresses, and SCAN addresses
A virtual IP address for each node, with the following characteristics:
Static IP address
Configured before installation for each node, but not currently in use
On the same subnet as all other public IP addresses, VIP addresses, and SCAN addresses
A Single Client Access Name (SCAN) for the cluster, with the following characteristics:
Three Static IP addresses configured on the domain name server (DNS) before installation so that the three IP addresses are associated with the name provided as the SCAN, and all three addresses are returned in random order by the DNS to the requestor
Configured before installation in the DNS to resolve to addresses that are not currently in use
Given a name that does not begin with a numeral
On the same subnet as all other public IP addresses, VIP addresses, and SCAN addresses
Conforms with the RFC 952 standard, which allows alphanumeric characters and hyphens ("-"), but does not allow underscores ("_").
A private IP address for each node, with the following characteristics:
Static IP address
Configured before installation, but on a separate, private network, with its own subnet, that is not resolvable except by other cluster member nodes
After installation, when a client sends a request to the cluster, the Oracle Clusterware SCAN listeners redirect client requests to servers in the cluster.
Note:
Oracle strongly recommends that you do not configure SCAN VIP addresses in the hosts file. Use DNS resolution for SCAN VIPs. If you use the hosts file to resolve SCANs, then you will only be able to resolve to one IP address and you will have only one SCAN address.See Also:
Appendix C, "Understanding Network Addresses" for more information about network addressesIn previous releases, to make use of redundant networks for the interconnect, bonding, trunking, teaming, or similar technology was required. Oracle Grid Infrastructure and Oracle RAC can now make use of redundant network interconnects, without the use of other network technology, to enhance optimal communication in the cluster. This functionality is available starting with Oracle Database 11g Release 2 (11.2.0.2).
Redundant Interconnect Usage enables load-balancing and high availability across multiple (up to 4) private networks (also known as interconnects).
During installation, you are asked to identify the planned use for each network interface that OUI detects on your cluster node. You must identify each interface as a public or private interface, or as "do not use." For interfaces that you plan to have used for other purposes—for example, an interface dedicated to a network file system—you must identify those instances as "do not use" interfaces, so that Oracle Clusterware ignores them.
Redundant Interconnect Usage cannot protect interfaces used for public communication. If you require high availability or load balancing for public interfaces, then use a third party solution. Typically, bonding, trunking or similar technologies can be used for this purpose.
You can enable Redundant Interconnect Usage for the private network by selecting multiple interfaces to use as private interfaces. Redundant Interconnect Usage creates a redundant interconnect when you identify more than one interface as private. This functionality is available starting with Oracle Grid Infrastructure 11g Release 2 (11.2.0.2).
Refer to the tables listed in Section 2.7, "Identifying Software Requirements" for the list of required packages for your operating system.
Enter the following commands to create default groups and users:
One system privileges group for all operating system-authenticated administration privileges, including Oracle RAC (if installed):
# groupadd -g 1000 oinstall # groupadd -g 1031 dba # useradd -u 1101 -g oinstall -G dba oracle # mkdir -p /u01/app/11.2.0/grid # mkdir -p /u01/app/oracle # chown -R oracle:oinstall /u01 # chmod -R 775 /u01/
This set of commands creates a single installation owner, with required system privileges groups to grant the OraInventory system privileges (oinstall), and to grant the OSASM/SYSASM and OSDBA/SYSDBA system privileges. It also creates the Oracle base for both Oracle Grid Infrastructure and Oracle RAC, /u01/app/oracle. It creates the Grid home (the location where Oracle Grid Infrastructure binaries are stored), /u01/app/11.2.0/grid.
You must have space available either on a supported file system or on Oracle ASM for Oracle Clusterware files (voting disk files and Oracle Cluster Registries), and for Oracle Database files, if you install standalone or Oracle Real Application Clusters Databases. Creating Oracle Clusterware files on block or raw devices is no longer supported for new installations.
Review the relevant sections in Chapter 3 for the installation option you want to configure.
Start OUI from the root level of the installation media. For example:
./runInstaller
Select Install and Configure Grid Infrastructure for a Cluster, then select Typical Installation. In the installation screens that follow, enter the configuration information as prompted.
If you receive an installation verification error that cannot be fixed using a fixup script, then review Chapter 2, "Advanced Installation Oracle Grid Infrastructure for a Cluster Preinstallation Tasks" to find the section for configuring cluster nodes. After completing the fix, continue with the installation until it is complete.
|
 Copyright © 2007, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|