Steps if SAP R/3 is Already Installed |
 |
Logon as root to the system where
the SAP R/3 Central Instance is installed. If the database is installed
on a different host, also open a shell as root on the database machine.
Stop SAP R/3 and the database if they are not already.
Verify that the existing volume group layout is
compliant with the needs of the MC/ServiceGuard package(s) as specified
in Table 2-3 “Device Minor Values” of Step Title not available.
Test the following:
If you install using the two package
concept, make sure that database specific filesystems and Central
Instance specific filesystems are separated onto different volume
groups.
Specify one mountpoint as /usr/sap/<SID>. For MC/ServiceGuard, change this to /usr/sap/<SID>/DVEBMGS<INSTNR>. If /usr/sap/<SID> is the mountpoint you have to move some files
to a local logical volume and change the mountpoint. For example:
mkdir /usr/sap/<SID>.new
cd /usr/sap/<SID>
bdf . # Remember the filesystem column.
# It will be refered to as <dev_path> later.
find . -depth -print|cpio -pd /usr/sap/<SID>.new
cd /
umount /usr/sap/<SID>
rmdir /usr/sap/<SID>
mv /usr/sap/<SID>.new /usr/sap/<SID>
chmod 751 /usr/sap/<SID>
chown <SID>adm:sapsys /usr/sap/<SID>
cd /usr/sap/<SID>/DVEBMGS<INSTNR>
rm -r * # be careful with this
cd ..
mount <dev_path> /usr/sap/<SID>/DVEBMGS<INSTNR>
cd DVEBMGS<INSTNR>
ls
# remove everything that is different from DVEBMGS<INSTNR>,
# Example: rm -r SYS
# rm -r D00
cd DVEBMGS<INSTNR>
find . -depth -print|cpio -pd /usr/sap/<SID>/DVEBMGS<INSTNR>
rm -r * # be careful with this
cd ..
rmdir DVEBMGS<INSTNR>
|
Mark all volume groups as members of the cluster.
This only works if the cluster services are already available. For
example:
cd /
# umount all logical volumes of the volume group
vgchange -a n <vg_name>
vgchange -c y <vg_name>
vgchange -a e <vg_name>
# remount the logical volumes·
|
The device minor numbers must be different from
all device minor numbers gathered on the other hosts. Verify this
by comparing numbers listed in Table 2-2 “Volume Groups Needed for MC/ServiceGuard Packages” in Step Title not available to the numbers listed in Table 2-1 “Hosts and Device Minor Numbers” in
Step Title not available.
Create and distribute mapfiles for all shared volume
groups.
Comment out the references to any filesystem that is mentioned
in Step Title not available from the /etc/fstab.
If there are additional internal application servers on the
cluster hosts:
Logon to all cluster hosts that have application servers installed.
Verify the following:
Application servers in the cluster
must have an instance number which is different from the instance
number of the Central Instance. Execute the command:
ls -d /usr/sap/<SID>/*<INSTNR> |
It should reply with No Match. If it does not, reinstall the
instance with another instance ID.
Comment out /etc/fstab entries to filesystems mentioned in Step Title not available.
If you use SAP R/3 4.0B or higher, /oracle/SID must not be a mountpoint of a local filesystem.
You can use /oracle as mountpoint.
The usage of local executables with the SAPCPE mechanism is
required for SGeSAP environments. You can do this now, because it
prevents hangs when performing a su to <sid>adm later in this installation.
Check if the Central Instance host and all application servers
have a directory called, type:
/usr/sap/<SID>/SYS/exe/ctrun. |
If the directories exists, you are done. The system is already
using local executables through sapcpe.
If the directories do not exist, setup sapcpe. Refer to your OSS notes and the SAP R/3 online
documentation for information about how to do this.
Steps if SAP R/3 is Not Installed
Yet |
|
SAP R/3 is installed on one host. This remains true even if
you want to distribute the database and Central Instance using the
three-tier concept. MC/ServiceGuard allows you to remove one or
the other later. The host you choose now will become the primary
host.
Logon to the primary host as root.
Create the shared volume groups using the minor numbers specified
in Step Title not available. Use the command line interface
to create the whole volume group, and later, the distribution. Do
not use SAM. SAM will scramble the minor numbers. For example:
mkdir /dev/vgsap<SID>
mknod /dev/vgsap<SID>/group c 64 0x080000
pvcreate <pv_path>
vgcreate vgsap<SID> <pv_path>
vgchange -c y vgsap<SID>
lvcreate -n lvsap<SID> vgsap<SID>
vgchange -a e vgsap<SID>
|
Refer to your SAP R/3 documentation for a description on how
to distribute the filesystems on physical disks. Refer to the SAP
R/3 installation documents to find out about the filesystem sizes
you need. Use lvextend and mkfs -F vxfs commands to create the filesystems on the shared
volume groups. Create and distribute the mapfiles with vgexport(1m).
If there is a different SAP R/3 system already installed on
another cluster node, propagate the additional SAP R/3 HP-UX users
and groups to all the nodes of the cluster. This prevents conflicts
with the UIDs. The SAP R/3 installation process creates users, groups
and services and it performs local consistency checks. It is possible,
that UIDs, GIDs or service ports already exist on other cluster
hosts.
Synchronize the /etc/passwd, /etc/group and /etc/services files of the cluster nodes so that they have the
same contents. This prevents conflicts later in the installation
process.
Logon to the primary host as root.
Create the mountpoints as recommended in the SAP R/3 installation documents,
except, do not use /usr/sap/<SID> as a mountpoint. Mount one level below the instance
directory. For example:
mkdir -p /usr/sap/<SID>/DVEBMGS<INSTNR>
... |
The filesystems should be distributed on disks and volume
groups as recommended in Step Title not available. But instead
of using the mountpoints below /export that are suggested in Step Title not available, create mountpoints below / as recommended by the SAP R/3 documentation. For
example:
mkdir -p /sapmnt/<SID>
mkdir -p /usr/sap/trans
mkdir -p /informix
...
|
Mount all created filesystems manually. Do not create entries
in /etc/fstab.
Begin SAP R/3 installation now. Install the complete system
on the primary machine. Refer to your standard SAP R/3 documentation
and OSS notes on how to do this.
If you use R3SETUP to install, the space check might fail. Modify
the SPACECHECK entries in the .R3S file in the installation directory to reflect the
mountpoint changes. For example:
Search for [Z_CENTRDBSPACECHECK_IND_IND] in CENTRDB.R3S.
The @SAPDIR@/@SAPSYSTEMNAME@ entries check the diskspace of /usr/sap/<SID>.
Additional free space caused by the logical volume that is
mounted below at the mountpoint /usr/sap/<SID>/DVEBMGS<INSTNR> is not counted.
Do not continue until SAP R/3 is properly installed on the
primary node.
If internal application servers are needed:
Setup application servers with R3INST/R3SETUP as usual. If you install an application server
on a node within the cluster, consider the following:
Application servers in the cluster
must have an instance number which is different from the instance
number of the Central Instance.
Do not create /etc/fstab entries. Mount manually to avoid problems with
the automounter later on.
The usage of local executables with the SAPCPE mechanism is
required for SGeSAP environments. Do this now to prevents hangs
when performing a su to <sid>adm later in this installation process. Refer to your
OSS notes and the SAP R/3 online documentation for information.
Printable version
