Patrick Petit's Weblog

Software Served on a Silver Plate

I wanted get my feet wet with that new thing (maybe not so new) called para-virtualization. So, I self-volunteered to play with Sun's port of Xen on OpensSolaris in a practical proof-of-concept (POC), which consisted in building a pre-installed and pre-configured Roller Blog Server disk image. A kind of virtual appliance if you wish. It may sound too much buzz words for an honest proposal, but I truly believe (as many others) that the manufacturing of pre-built disk images may radically change the way software vendors and integrators will distribute software in the future.

It happens also that the OpenSolaris community is actively involved in supporting Xen[1], which makes the experimentation worth a try as a "eat your own dog food" exercice.

Ready to Use Roller Blog Server

In what provisioning software using pre-built disk images is different from the traditional 'pkgadd' way?

For one thing, it's extremely more practical and time saving.

The image integrates all the right components, patches and settings to work out-of-the-box. From an administrator prospective, it means no installation and configuration hassle. For example, we recently put together a Roller server on the Internet to facilitate the collaboration with a SematicWeb community group working on a SPARQL endpoint experimental project. This project uses the D2RQ library to query the SQL database of Roller[2]. As we already had a working Roller server domU, which we just cloned and modified its disk image that we copied on a connected machine. As far as the provisioning of new servers goes that was about it. It took couple hours instead of couple days if we had it done the old way.

The Roller Server disk image is composed of Solaris Nevada, Glassfish, Derby DB, J2SE and Roller Weblogger components. The life-cycle management of the server and database is handled by SMF for which, I had to write the start and stop methods as well as the manifests that are not provided with the product.

A set of (re)configuration scripts were also developed to enable system id config (and unconfig) when the domU is booted for the first time. These features confer the Roller Server disk image appliance-like capabilities:

• Self-contained, pre-installed and pre-configured services

• Self healing in the sense that the services are automatically (re)started by SMF. In case of failure, a root cause analysis, which is very basic in the POC, could be nicely carried out using the Application Server's Uniform Logging Format (ULF) data, which identify the source and severity of an error.

• Reset. The appliance can be restored to an "as-manufactured" state. Invokation of sys-unconfig(), delete the Derby DB, undeploy Roller and cleanup the server logs.

While the Application Server and Derby components are pre-built, along with the OS, in a disk image, Roller and the database are in contrast, installed and configured when the domU is booted for the first time. The initial boot sequence execute the usual system's configuration (sysidtool stuffs), create the Derby DB and populate the schema, create the tables, and finally deploy the WAR file of Roller that is bundled with the disk image.

This process is used to facilitate the sharing of reference images (a.k.a. golden images) across multiple instances of the same service. One can also save additional disk space by booting the domU on the snapshot of a cloned disk image. The snapshot would then hold all the local changes consecutive to booting and running the domU. In that respect, I have done some testing with ZFS emulated volume (zvol), which unfortunately failed short due to a bug in ZFS preventing the use of zvol as the virtual block device of a Xen virtual machine. See defect id CR 6458021 to check the resolution status.

SMF Manifests and Methods

I created the SMF manifests and methods for Derby, Glassfish and Roller. The manifests should be located under /var/svc/manifest/site and the methods for start, stop and refresh under /lib/svc/method. The Roller service is automatically started by svc.startd to reach the multi-user-server milestone (a.k.a. init level 3), whereas the Derby and Glassfish services are implicitely started as a result of resolving the 'require_all' dependencies specified for Roller. As an example, I provide "as is" and "without warranties of any kind" the manifests and methods I used in the POC:

• roller, glassfish and derby methods

• roller.xml, glassfish.xml and derby.xml manifests

Feel free to comment and improve these scripts as needed.

---

[1] OpenSolaris Xen Community

[2] More on this in Henry Story's SPARQLing Roller entry.

[2] Components version:

• SunOS 5.11 matrix-build-2006-08-16 i86xen i386 i86xen

• xen v3.0.2-3-sun chgset 'Mon Aug 14 06:30:03 2006 -0700 9671:7419a66ebaeb'

• Sun Java System Application Server Platform Edition 9.0 (build b48)

• Roller Weblogger 3.0 (incubating)

Posted at 04:40PM Nov 13, 2006 by ppetitsm in Sun  |  Comments[1]