Creating SAP system clones using Solaris 10 virtualization concepts (Part 1)
Releasing Solaris 10 Sun introduced a new concept for OS based virtualization, called Solaris Zones.
A Zone is a virtual instance of a guest operating system (Solaris or Linux) within a Solaris host system.
This technique can be used to build an clone of a running(!) SAP system which can be used for an update, patch, test and so on afterwards.
This is the first part of a blogger series describing how to easily create runable shadow copies of productive systems using Sun Solaris 10 native OS virtualization functionalities (Solaris Zones).
These shadow systems can be used for applying updates, patches or similar tasks which would result in a downtime of the productive system usually.
After the desired task was performed successfully the shadow systems can be switched with the productive systems. This way the planned downtime of the productive system landscape can be reduced dramatically.
In this part you will get a short overview about the general concepts. The following parts provide a step-by-step approach based on a SAP NetWeaver 2004s SR1 system (usage type EP) running on Solaris 10 operating system.
If you want to get more information about how to install a SAP system within a Zone take a look at Installing SAP systems in Solaris 10 Zones.
The setup described below presumes an existing system landscape based on Solaris 10. The SAP system and the database system need to be installed and running within two separated local zones. Also root access to global and local zones is required.
Please note that the database zone and the SAP zone is connected via a private virtual network card interconnection directly. Also the SAP system and the database are installed using virtual hostnames. This way the systems can communicate to each other independently using host files.
Public communication is performed using a public virtual network card which is resolved via DNS.
These interfaces can be configured easily within the zone configuration tool.
The basic idea of this setup is to provide a shadow system for update purposes. The shadow system represents a clone of the “source” system. The shadow system can be started, stopped, or even modified independently.
This way it is possible to run an update or patch of the sap and/ or database system without downtime of the productive system landscape. Of course this strategy is limited: During the update of the shadow system, the “original” system needs to run in read-only mode.
The following diagrams visualize the basic idea. First shadow copies of the existing zones are created.
Afterwards the update is applied to the shadow systems as shown in figure 3.
If the update succeeded, the public network interfaces are switched. This means that the public interfaces of the “source” zones are disabled and new public interfaces using the configuration of the “source” zones are enabled within the shadow zones configuration. The entries within the DNS links to the shadow system now and the clients are rerouted to these systems therefore.
Of course this kind of setup can be applied for a wide variety of different scenarios, like internal tests, demos, backups and so on.
Ok, let’s summarize the setup described above:
- First, clones of the SAP zone and the database zone are created.
- Afterwards the shadow systems can be started and the upgrade (or anything else) can be preformed. During this timeframe the source-systems (which are still the productive ones) are in read-only mode. This means that all changes on the systems will be lost after the zones are switched.
- If the update succeeded (and only if the update succeeded!) the zones are switched. This is done using a switch of the public virtual network cards.
Figure 5 shows the effective downtime and also the read-only timeframe based on the concept described.
The next step describes how to clone a running SAP system and the database. Afterwards two new clone-based zones will be created and configured.