Great Solaris 10 features paving the way to Solaris 11
By Karoly Vegh-Oracle on Mar 14, 2012
What do customers need the most for their UNIX platform's operation? Time. And headcount, obviously. In both of these fields there is usually room for improvement in corporations these times. That is, even though Solaris 11 is out, and it is the greatest Solaris release ever, some customers will probably need time to upgrade their platforms from Solaris 10 - we understand that. We strongly recommend moving to Solaris 11 as soon as you can, but we also know that business goes first, with service availability hand-in-hand with operations. In this post I list up some of the technologies that are available already in S10, and will ease the move to S11.
First a short disclaimer:
- Not long ago I was still a system engineer at a customer, running a lot of S10 installations. We have used most of the features mentioned here. I personally have learned a lot from Jörg Möllenkamp's Less Known Solaris Features book (available in PDF on his blog here) and am thankful for him taking the time and effort for documenting and releasing it, it helped a lot. Most of the mentioned features here are in detail discussed there.
- All these features are of course part of Solaris, no extra costs, they are already there.
- Many customers run Solaris 10 the traditional way, just like we were used to run Solaris for 20 years now, with initscripts, patchsessions in singleuser mode, applications in the global zone, with SVM, UFS, sharing the rootuser - the listed features should improve the administration experience.
Let's get on with the list.
Liveupgrade (LU), allows you to create clones of your OS instance within the same box, while it is up and running. These clones, also called Alternate BootEnvironments can be patched or upgraded (actually changed in any way, like application installation), without a change or downtime of the running system. If you are done with the changes, you can boot your new bootenvironment, and run the patched/changed OS instance there. If the patch/upgrade hasn't worked out, you can reboot back to the original (primary) bootenvironment any time to the unchanged OS instance. This way you reduce downtime, and reduce risk of the updates. It's like a safety net.
Back in my days we also used it sometime just to regularly create a complete fallback instance of the OS installation, in case a junior admin removes /usr or something.
Where to read about it? In the above mentioned LKSF book, Section 3, or in the official Solaris 10 documentation in the Live Upgrade section: http://docs.oracle.com/cd/E23823_01/html/E23801/index.html
In Solaris 11 LU has been enhanced and is now called bootenvironments.
This virtualisation method is the most lightweight kind - zones are about userspace separation of your applications, an OS virtualisation, with their separate software packages, daemons, users, IP addresses. They are also well integrated with resource management, that is you can separate now different environments having them in different zones, and you can also guarantee them a minimum amount of CPU power. I have written a short post comparing zones to LDOMs. The conclusion there was: even if it is the only application that will run on that server, put it in a zone.
Zones integrate with Solaris Cluster too. Back in my systemadministrator days we have defined them as standard technology, and every new application went into zones.
See the Zones section in the Solaris 10 documentation: http://docs.oracle.com/cd/E18752_01/html/817-1592/index.html
Zones have been improved in Solaris 11, and you can run Solaris10-branded-zones on top of Solaris 11.
III. Resource Management
RM is about ensuring that the resource consumption of a workload (presumably in a zone) does not hinder or interfere with the resource consumption of another one (presumably in another zone or project). The most obvious example is running your application environments in zones, running the zones themselves in a cpupool and the global zone in a different one. In the resourcepool of the zones you can then enable the FairShareScheduler practically guaranteeing to each zone a minimum set of cpushares while allowing them to consume more as long as the cpupool isn't 100% utilized. With this straightforward configuration you reserved some power in the global zone, and practically overcomitted your resources of the cpupool running the zones.
For examples, see the documentation about Resource Pools: http://docs.oracle.com/cd/E18752_01/html/817-1592/rmpool-1.html
Using RM is a good way to prepare for consolidation projects.
ZFS is the last word in filesystems. And volume management. And RAID. These three all in one. No more hardpartitioning your disks for SVM, no more static sized UFS filesystems. ZFS administration is very simple (the two main commands being zfs and zpool - see their intuitive subcommands) and very dynamic. ZFS is supported on Solaris 10 as root filesystem - if you convert your system to ZFS, you can have several LiveUpgrade (see above) Alternate BooteEnvironments within the root-zpool (usually named rpool) based on ZFS snapshots/clones, which are differential, that is only the differences between two environments are written to disk. You can move from UFS to ZFS with LiveUpgrade too.
ZFS also provides lots of features, dynamically changeable recordsizes, quota and reservation, snapshots, dumps (zfs send/receive), tuneable I/O performance, and a lot more.
ZFS is the only supported root-filesystem on Solaris 11, moving to this technology on Solaris 10 already will ease your way to S11.
For documentation, see the ZFS Administration Guide: http://docs.oracle.com/cd/E23823_01/html/819-5461/index.html
The Service Management Facility allows you to define services running your OS and running on your OS. These services implement dependency between serviceinstances, essentially guaranteeing a concistent systemstartup and service health. That is, your NFS service will not be started before the networking service has been started up and is running. SMF is also a consistent interface to run your services/daemons with, should they be a resourcepool-daemon, a virtual-networking service, a packetfilter or a webserver - all manageable with the svcs/svcadm commands, configurable with svccfg/svcprop.
Solaris 11 utilizes SMF even heavier, you will find that the packetfilter rules can be stored in SMF, or that even the nsswitch.conf is dynamically generated at starting the relevant service.
For more information on SMF on S10 see the System Administration Guide's section about Managing Services: http://docs.oracle.com/cd/E23823_01/html/817-1985/hbrunlevels-25516.html#scrolltoc
We could go on with RBAC, DTrace, JumpStart, BART and the CryptoFramework, should you be interested in those, please put your inputs in the comments below. Again: the main message is: Go for Solaris 11 if you can. If you need to run Solaris 10, we recommend deploying the mentioned technologies, they can and will improve your daily systemengineering business and prepare your platform for the move to Solaris 11.