Releasing Solaris 10 Sun introduced a new concept for OS based virtualization, called Solaris Zones.
A Zone is a virtual instance of a (Solaris) guest operating system within a (Solaris) host system. The concept is pretty similar to BSD Jails or Linux VServer and comparable to an extended chroot environment: the guest operating systems share the same kernel and drivers but run within an isolated environment containing an individual directory structure, user management and so on. All guest systems (also referred to as "local" zones) are accessible from the "global zone" which is the host system. Within the local zone neither other zones nor the host system is accessible or even viewable.

This way a lot of independent OS environments can be created and hosted within one physical server hardware.

 

Why installing SAP in a virtual environment?

Well, of course the benefits of installing applications in virtualized environments depend on the business case.

Anyway, in general there are some general advantages which should be valid for the most scenarios including

• Increasing system stability and security using isolation of different systems, e.g. separating a database server from the SAP application server using different zones
• Lower costs for computing centers/ administration
• Higher Flexibility
• New ways for Backups, Tests, Maintenance, Upgrades, Patches etc.

Of course there are various other reasons. You may want to read further resources for more information take a look at[1].

 

Why not installing SAP in virtual environments?

Where's light, there's shadow. Of course there are some (big) disadvantages when using virtualization techniques. Here are some of them:

• Performance loss caused by virtualization (up to ~40% depending on the type and the implementation of the virtualization solution)
• Additional knowledge, configuration and administration is required
• Virtualization software may cause unpredictable errors
• Host system is a potential single point of failure (SPOF) for all hosted systems
• restricted support by SAP (e.g. Note 674851)

 

Why installing SAP in Solaris Zones?

Of course the Solaris Zones solution is just one way of implementing virtualization concepts. There are various implementations on the market which could be used and they all have their special benefits and disadvantages.

One simple answer why one would choose to use Solaris Zones could be: It's a supported environment. That's important due to SAP does not support all virtualization types and products in general at the moment. Therefore you might risk the support for your SAP system when installing it in an unsupported environment.

Anyway, a much more practical reason is: Zones are pretty easy to use! And they are included in every Solaris 10 distribution by default.

Here are some other pros and cons for installing a SAP system within a Zone:

(+) Resource Management available (Solaris Containers [2] - CPU, network consumption and Memory consumption can be limited explicitly)
(+) Proven OS technology with easy administration tools
(+) Low overhead (Sun official statement: ~3% workload for virtualization)
(+) New Zettabyte file system (ZFS) with many features including Snapshot, Clones, build-in logical volume management etc.
(+) Inter-machine transport available [3]
(+) Very cost efficient
(-) Only Solaris as host operating system and guest operating systems is supported
(-) Zone-specific kernel changes not available
(-) Not applicable with every application and service (e.g. NFS)
(-) I/O cannot be limited via resource pooling

 

How to do it

Setting up a new zone is pretty easy. However, I don't want to explain zone creation in detail (because there are already various resources available which do that much better then I could [4]). But I want to give a quick overview about the zone creation and administration tools to provide a first impression how to handle with zones

Tools

zonecfg
zonecfg is an interface for adapting the zone configuration files. To create or modify zones this command should be used. You can add file systems, resource pools, or network cards using this tool. Changes take effect after rebooting a zone. All zone configuration information is stored in an xml file located in the global zone (/etc/zones/<zonename>.xml and /etc/zones/index). This tool is only available in the global zone.

zoneadm
This command is used for central zone administration including starting, stopping, and (un)installing a zone. "zoneadm" is only available in the global zone.

zlogin
Using zloging you can login to local zones from the global zone. Usually the syntax of using it should be similar to "zlogin -C -e\@. my_zone_name" where "@." is the escape character. When you want to log out from a zone, use exit until you prompted for your user credentials. Then press "@." to get back to the global zone.
Note: After installing a network you may configure additional access to the zone, e.g. via secure shell or remote login.

zonename
To get the name of the current zone the "zonename" command is used. For example, the name of the global zone is always "global". It is available in all zones.

 

Steps to create a zone: Example

It is pretty easy to create a new zone from scratch and should be done in a few minutes:

 
Creating a new zone:
zonecfg -z my_new_zone create
This will open the zone configuration tool. Here you can specify the path to the zone, network settings etc. The tool creates a kind of template for a new zone which is stored within an xml file. Therefore you may reuse it later.

Installing the zone
Once a zone is created, you have to install the zone before using it. This may take a while.
zoneadm -z my_new_zone install
To uninstall the zone, use the parameter "uninstall" instead of install. This will erase everything installed within the zone including the file system structure

Booting the zone
zoneadm -z my_new_zone boot

Logon to the zone
zlogin -C -e\@. my_new_zone
Now you can login to the zone. The configuration wizards (as after a "normal" solaris installation) will appear and ask you for passwords, network settings and so on.

 

Known Issues

The setup of SAP within a zone is pretty much the same as setting up the system within a regular Solaris environment. But some zone limitations may require workarounds.

Read-Only directories

Please read Wolfgang Pungartnik's comment regarding read-only directories!
The /usr directory is only writeable in the global zone which means within the host system. There is only read-only access available within the local zone (i. e. within the virtual environments). This may cause problems if you want to install a SAP system within a zone due to the fact SAPInst requires /usr as installation directory. A workaround is to create an alias in the global zone which links e.g. to /sap. This way you may create a directory named /sap within the local zone's root directory and the installer is linked to this directory automatically.

Fig. 1: Global/ Local files structure

If you are plan to install a database in a different zone, you need to create a /sap directory there, too. Otherwise the installer searches /usr/sap for existing installations and crashes due to the link is pointing to nowhere.

There are also other directories mounted read-only from the global zone (e.g. /sbin) which may cause errors when installing additional software, e.g. database tools.

NFS

Another restriction of local zones is that the implementation of a NFS server is not possible at the moment. If you want to share the /sapmnt directory via NFS you need to do this in the global zone.

Access to the file system of another zone

If you are planning to use several zones you may need to get access to a directory of other zones. For example, if you are installing the database instance within another zone you can get access to the /sapmnt directory of the SAP zone directly. To do so, just may use the Loopback File Systems (LOFS) which enables mounting resources locally, e.g. one directory to another location. This is specified within the zone configuration file as listed below.

Start the zone configuration tool (zonecfg), add a new file system (add fs) and set the type to LOFS (set type=lofs). You also need to provide the source directory (set special=…) and the destination directory (set dir=…). Here's a simple example configuration for a database zone configuration:

fs:
   dir: /sapmnt
   special: /sappool/sapvol/sap_zone/root/sapmnt
   type: lofs

 

Solaris installation problems

Due to Zones are virtualized Solaris 10 environments during the installation the standard Solaris installation problems may occur. For instance, the /home directory is read-only due to the auto-mount feature is enabled by default. This usually causes problems with the installer when creation of the users is required.

Other zone limitations

The concept of zones includes that the kernel of the host system is used. Therefore other limitations may occur when adapting the OS kernel is required. Also the read-only directories mounted from the global zone may cause problems.

 

Conclusions

You may ask yourself: Ok, it is possible to install SAP in Solaris Zones, there are some benefits and disadvantages. But is that all you wanted to show me?

Well, of course virtualization does not fit to every scenario. And if you do not really need it you shouldn't use it. Anyway, there are pretty interesting concepts you can realize applying virtualization techniques.

For example, I already created a prototype using Solaris Zones, ZFS, and a bash script which creates a shadow system within a few seconds without any downtimes of the productive SAP system or database instance. This shadow system may be used for upgrades, patches, backups and so on afterwards and can improve the availability of SAP systems dramatically. And all this is done using native OS functions. Nice, isn't it?

Read More: Creating SAP system clones using Solaris 10 virtualization concepts

 

---

References

[1] http://www.kernelthread.com/publications/virtualization/
[2] In Suns terminology a zone which also uses resource management capabilities is called a "container" instead of a "zone".
[3] http://www.sun.com/software/solaris/howtoguides/moving_containers.jsp
[4] http://www.sun.com/software/solaris/containers_learning_center.jsp, http://www.opensolaris.org/os/community/zones/