A Look at Solaris 10 and Sun's Dual Core Fire V40z

Getting a Feel for Solaris 10

Solaris has always had the edge over Linux when it comes to scalability; SunOS had its roots in big iron. As a FreeBSD user first and a Linux user second (and a Windows user a distant third), a lot of things felt very familiar inside Solaris 10. Sun's Java Desktop System, JDS, is immediately recognizable as a SUSE derivative. We won't touch on JDS too much in the next couple pages, but instead focus on the underlying kernel and some Solaris's more interesting and original features.

As we mentioned earlier, scalability is a big issue but if anyone can tackle that obstacle, it's Sun. Sun spent a lot of time getting Solaris 10 ready for x86, and as you will see in our benchmarks section, the "Slowlaris" moniker might be dead. Solaris 10 features a new scheduler that allows per-CPU optimizations as well as faster string functions, SSE2 support and new x86_64 specific libc system calls. Granted, we would like to see some SSE3 optimizations as well, but these features sound pretty good for now.

One of the neatest, unexpected features in Solaris 10 was Zones; also known as N1 Grid Containers. Zones behave very similar to UserMode Linux (UML); each Zone is a virtual instance of Solaris 10 with it's own IP address and user land. However, Zones are different because each virtual OS shares the base kernel. This is a huge performance boost for the virtual operating system because each instance is not constantly waiting for resources like in UML; they can just demand them when necessary. Zones can be configured to only utilize a specified amount of resources as well. Of course the downfall to this is if a single Zone is compromised, the whole system is effectively compromised. Fortunately, compromising a Solaris 10 system is not an easy task either; additional Process Rights Management and User Rights Management are prevalent in Solaris 10.

David Comay from Sun writes:

One of the design goals of Zones was to ensure that if a single zone *was* compromised that the whole system would *not* also be compromised. We believe that we achieved that to a very large extent in Solaris 10. From an isolation perspective, the primary weakness is that there is a single kernel and if a user program somehow trips over a kernel bug and causes the system to panic, then of course, that affects the whole system. But from a security perspective, someone who is a privileged user (namely, root) in a zone can only cause damage to that zone and *not* the system as a whole. The virtualization that Zones provides ensures that they're not able to see, affect or modifyprocesses and their data running in other zones on the system.

Dynamic Tracing (DTrace) was another heavily hyped feature of Solaris 10, and rightfully so. DTrace, and it's scripting language D, allow an administrator or a developer to observe and debug problems in a production system with very little overhead. The problem with traditionally debugging tools like gdb, truss, pstack and ptrace is several fold:

• We need to either monitor everything on the system, or only very specific processes - it would be impossible to trace every process on the system
• We can only view a core dump of a snapshot in time - often times administrators and developers have transient problems
• Usually, a program like gdb needs to halt or stop the system - in a production server this isn't acceptable
• A poor debugging routine can actually be more detrimental than helpful - debugging a system incorrectly can actually bring it down, which is totally unacceptable at times

DTrace can effectively do the same as truss, pstack or ptrace but it can also be used on a production system without completely crippling it via "Probes" that are inserted all over the OS. Sun's DTrace introduction conference explains some of DTrace's functionality in a 40 minute session for those really interested in all of it's features. It's kind of like installing 30,000 debug statements all over the kernel, and allowing the admin to collect data from these probes whenever they would like via DTrace.

Solaris is really a developer's dream. During the V40z's brief stay in our labs, we actually used the machine extensively for development of our RTPE software platform; partially because the V40z is 10 times more powerful than our entire RTPE cluster, but partially because of DTrace, MDB and libumem. Using some of the examples from the DTrace introduction above, we were able to use the analyzer to isolate instances where some of our RTPE bots were getting preempted for supposedly no reason at all. Kudos to that team at Sun!

Just a few weeks ago Sun opened Solaris 10 to all with OpenSolaris; Sun's partially open sourced version of Solaris under the CDDL license. OpenSolaris now provides much of the OS core for modification, but not the entire OS just yet. According to the OpenSolaris roadmap, crypto and storage drivers should be available soon, which would be a great step forward for the entire FOSS community.