|
|
United States-English | |
|
|
 |
|
Managing MC/ServiceGuard Extension for SAP R/3: > Chapter 1 Understanding MC/ServiceGuard Extension
for SAP
Directory Structures |
|
|
This section provides a deeper understanding of the directory layout. For information about LVM setup, refer to the section, “Planning the Volume Manager Setup”. Depending upon your particular setup, the following important groups of directories need special treatment: Use a standard setup for the following common directories and their files that are kept locally on any host of the cluster:
The contents of this group of directories must be synchronized manually on all hosts of the cluster. Do not automatically make /home/<SID>adm the same on all of the hosts. For example, it is possible to install an additional application server on a host of the cluster that is not be part of any package. If it is local to its host, the SAP R/3 startup scripts are only needed on its dedicated host. You do not need to distribute them to other hosts. Change the SAP R/3 startup scripts startsap_<local_hostname>_<id> individually in the home directory of <SID>adm on all cluster nodes, to configure different startup profiles. The central instance can be configured differently, depending on which node it is actually started. Be careful with this option. You have to make sure by yourself that the central instance is capable of doing its work in any of the possible configurations. The standard HP-UX configuration files are local. To prevent malfunction, never delete the mutual .rhosts entries of the root user and <SID>adm on any of the nodes. The SAP R/3 option to introduce a local copy of the ORACLE_HOME directory /oracle/<SID> allows you to use older versions of the ORACLE client software in combination with a more recent ORACLE server release. This provides more flexibility and is useful if the operating system releases are supported by a different client than the server component. In switchover environments only external application servers can take advantage of this. The server component has to be able to run on all nodes. You cannot use an operating system release with a server component that is not supported. This is true for any host within the cluster. Within a cluster, the client and server components must have the same release number. This is important, because /oracle/<SID> also acts as a mountpoint for the directories of the server component. The client software residing on a local disk is no longer accessible after a mount takes place. This happens, if the database switches to a host on which an application server is running. The whole process remains transparent to the running application server because the database server directories deliver the same files at the same places. Every file is where the application server expects it. Already opened files can still be accessed, even though they are no longer visible in the directory tree. Please note, that the application server will only have read access. No writing will occur.
Changing shared disk directory files on any host of the cluster affects the whole cluster. Files in the following directories and all subdirectories are normally shared:
The files in these directories are only available on a host if the package they belong to is running on it. MC/ServiceGuard switches them to another node with the package. Under a two package concept the three /export and /oracle directories belong to the database package. The /usr directories belong to the central instance package. Never use /usr/sap/<SID> as mountpoint on a shared disk. You risk making the Instance Directory of an internal application server unreachable if a switchover takes place. All filesystems mounted below /export are part of the crossmounting. Please note that /oracle/<SID> is treated differently for performance reasons. Directories handled by the automounter are mounted automatically as needed. This is true not only for the nodes of the cluster, if you use external application servers, they will also need them. Automounter directories are:
These directories are NFS-mounted from their equivalents inside of the /export directory of the nodes which run the packages. The automounter uses the relocatable IP addresses. This ensures that the directories are quickly available again after a switchover. There are two important issues concerning these directories:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
