SAP TIPS AND BEST PRACTICES
Moving installed SAP systems in zones between hosts in ten minutes
Andre Boegelsack
04.05.2007
Rating: --- (out of 5)
This blog entry is about how to move installed SAP systems from one host to another one in about ten minutes. We will start with some few prerequisites and going on to the main subject of this blog: moving the SAP systems. We will guide you through the whole process by a step-by-step-guide. So let us start now.
Prerequisites
If you want to move a SAP system in a zone, there are some prerequisites and considerations that need to be noted before starting to install SAP in zones and subsequently move them within the host system environment.
- Move the zones only to a host on the same hardware platform, otherwise you can have potential source of quite intensive administrative tasks.
- Install the central instance and database instance in two different zones on two different storage locations. These storage locations have to be movable, meaning that whenever you move the zones, you also have to move the storage location. This task can be achieved very easily by using Storage Area Network (SAN) or local storage, like SCSI/SAS drivers.
- To make the operations much easier, we recommend to install the central instance and database instance using ZFS pools.
- Store the zone configuration in a separate file within a separate directory of the ZFS pool.
Starting configuration
In our scenario we have two hosts, two zones and two ZFS pools. Have a look on the following picture for more information:
[IMAGE]
We intend to move the zones from hosts one and two to the new hosts three and four, because the later ones have more capable hardware, which is strongly needed.
Furthermore we do not intend to reinstall the central instance or the database instance. Of course, data loss can not be tolerated but we are willing to accept a short interruption of normal service that is ideally minimized. In the target configuration the two zones are ...
To continue reading for free, register below or login
To read more you must become a member of SearchSAP.com
running on host three and four and are still stored on the SAN. The old hosts are disconnected from the SAN. The next subsection shows the necessary steps to move from the initial to the target setting in a step-by-step fashion.
Moving a SAP system onto new host
This step-by-step guide is intended to show all necessary steps for moving an SAP system’s zones to the two new hosts. If you follow this instruction, the process should be straight forward and no difficulties are to be expected.
Shut down SAP system
Connect to the zone G62AS1 and shut down the contained SAP system. An example thereof is given in the following command line statements.
The stopsap script stops the central instance and the central services. Then it is necessary to disconnect from zone G62AS1 and in turn establish a connection to zone G62DB1. Within this zone the stopdb script is used to stop the MaxDB instance.
Shut down and detach zones
For disconnecting both zones, we have to stop them first. After stopping each zone, we detach it.
Shut down and detach the first zone:
Now, let's shut down and detach the second zone:
Now that the zones are offline and detached, we can export the underlying ZFS pools and ‘move’ them to the new host systems.
Export ZFS pools
In order to export the ZFS pools, we connect to the host one again and export the ZFS pool, which is named ‘zfs<sid>’.
Exporting a ZFS pool means: stop all I/O, unmount the devices and export them. The same operation has to be done on the second host:
After completing these steps, all the ZFS pools are logically disconnected from the host systems. In order to move the zones to the new hosts, we have to reconfigure the SAN and thus make the storage available for the two new hosts three and four.
Disconnecting and connecting storage
This chapter depends on what type of storage you use for your server. However, you will have to disconnect and connect the storage from the old hosts to the new ones. We will not show how to do this here.
Import ZFS pools
After the storages are connected, try to discover the exported ZFS pool:
Solaris’ information that no pools are available is no reason to worry. As we know the name of the pools we can force Solaris to import the pools by explicitly providing the pool’s name:
The command will import the new ZFS pool and mount it to the initial directory. Having performed this step, the underlying storage is ready and the zones can now be attached.
Attach the zones
Before attaching the zones to the new hosts, we will have to validate the zone configuration. It is therefore necessary to have a look into the zone configuration and, if necessary (!), update the interface name.
Right after this step, usually the installation of the zone would follow. However it was already installed on the old host, which is why zoneadm will respond with an error message, if you try to install the zone. Also if you try to boot the zone, zoneadm will give you an error too, complaining that the zone has to be installed firstly.
So instead of installing or booting the zone, the zoneadm attach command needs to be issued, which simply attachs the zone. After attaching, the zone can be booted.
Hint: Similarly we have to do the same procedure on host four, which contains the database instance zone. Having successfully performed all indicated steps, the zones are now up and running and the restart of the SAP system can begin.
Start database and central instance
We connect to both zones and start the central instance and the database instance which will look similar to the following command line snippet.
After restarting the SAP system, we ensure that it is operational by connecting to it via the SAPGui or via HTTP Web Browser.
Quick Review
We showed how to move a SAP system from one host to another using Solaris’ virtualization concept - zones. As pointed out, only a small number of steps are necessary to achieve this goal. In hosting scenarios, where you have to deal with peak loads in a timely fashion, this is a great advantage. This is especially true, since Solaris’ concept offers potential for automating the steps necessary to move a zone. This could be exploited by creating a simple tool, which switches zones from one host to another.
As we stated, although it is possible to move and then boot a zone from e.g. a SPARC host to a x64 host, it is very difficult to develop a full adaptive environment based on zone. This difficulty arises from the fact that the SAP and MaxDB kernels are hardware-specific, implying that you can not use the MaxDB kernel for Solaris SPARC on a Solaris x64 platform and the other way around. The same is true for the SAP kernel.
Andre Boegelsack works as SAP and Solaris adminstrator at the SAP University Competence Center in Munich/Germany.
This content is reposted from the SAP Developer Network.
Copyright 2007, SAP Developer Network
SAP Developer Network (SDN) is an active online community where ABAP, Java, .NET, and other cutting-edge technologies converge to form a resource and collaboration channel for SAP developers, consultants, integrators, and business analysts. SDN hosts a technical library, expert blogs, exclusive downloads and code samples, an extensive eLearning catalog, and active, moderated discussion forums. SDN membership is free.
Want to read more from this author? Click here to read Andre Boegelsack's Weblog. Click here to read more about Application Servers on SDN.
|
|
|
|
|
|
