mercredi mai 27, 2009

Flying LDoms with fldom tool

In case of hardware Failure it is good to have a very simple way to manually restart LDoms in few seconds in one other server. The Warm and Cold Migration is a very good way for moving LDoms from a primary physical platform to a secondary physical platform. But in case of crash of primary platform the Migration could be hard to use.  Also if we wish to have a simple way to easily move at any time a several LDoms to a pool of several physical servers it could be hard to  maintain all vdisks configurations in all physical servers for all LDoms.
One simple solution is to create all vdisks in a share file system (NFS - PXFS) or failover file system (ZFS - metaset) and export the LDom and all associated vdisks and vswitches configurations in that File System. Then we can used this exported informations on the secondary platform to restart the LDom. Before restart the LDom on secondary platform we must check the availability of resources (CPU/MAU/Memory), services (vdiskservers/vswitches) and all backend files needed to restart the LDom. Then we can recreate all vdiskserverdevices on the right backends with right options for the specific LDom.
The fldom (Flying LDom) tool can be used to easily manage Flying Ldoms. This tools allow us to export LDom configuration in share or failover file system. Export option example:

The fldom tool allow us to detach the LDom from one server (remove it and delete all vdsdev), and attach the LDom  to a new server (check needed services and resources, recreate all needed vdsdev, create and bind the LDom). Attach and detach options example:

So it is very easy to quickly restart the LDom in any server in case of primary platform failure with fldom attach option and exported informations. For example primary T5xx0 Failure scenario:

If using ZFS as failover file system for Flying LDoms without SunCluster we have to be careful of ZFS import with force option as there is no yet the support of Multi-import protection in ZFS.
The fldom tool is available here for download as simple Solaris package. Don't forget to call SunPS to successfully help you to  implement this Flying LDoms solution with fldom tool. The next step will be HA-LDom to allow automatic LDom  failover with SunCluster, I hope coming soon. Have fun with LDoms.

vendredi mai 15, 2009

Using Solaris Package Companion v0.9 to minimize Solaris 10 with zones

Last month I have worked for a French bank using 28 whole root zones on one M9000 Solaris 10 domain. At the first installation the size needed to store all zonepath was very big. The time needed to apply patches or upgrade Solaris with LU was too long. So the customer ask us to reduce the size of Solaris by removing all not needed packages.

When we reduce or minimize Solaris Operating System (Solaris OS), it is not permissible to remove any software packages that are found in the smallest Sun-provided installation cluster (SUNWcmreq metacluster). It is also not permit to remove packages if there exist any dependencies on the software package being removed, those dependencies must be addressed and satisfied prior to the removal of the package.

Solaris 10 has now 2164 packages grouped in 188 Clusters and 7 metaclusters. When we want to remove packages or clusters from Solaris we have to know the dependencies and reverse dependencies between packages or clusters. We may also need to know the package list of one given cluster or Metacluster or need to know in which cluster is one given package or... This informations are available in solaris metadata packages files but are not very easy to read.

Glenn Brunette has developed great tool call Solaris Package Companion available at opensolaris used to answer every questions we need to minimize Solaris. With this tools we where able to securely remove this cluster list and this packages list and the size of Solaris 10 (SUNWCuser) was no more than 1.2 Gbytes on M9000 server.


Jerome Blanchet


« mai 2009