AppFirst is releasing support of our collection technology for Solaris platforms. We are doing a beta release for a few users to get validation and feedback.
Solaris certainly isn’t a growth market, to be sure. So, why develop a collection technology for Solaris platforms? I suppose the simple answer is; completeness.
We have a number of customers that continue to use proprietary Unix systems. These systems most often host relatively critical services. In most cases, there has been significant investment in the services hosted by proprietary Unix systems, in particular Solaris.
As AppFirst continues to pursue the notion of assembling, in one collection, the most complete IT operations data, it is actually fairly natural to include Solaris at some point.
This release supports Solaris 10 x86, Solaris 11 x86, Solaris 10 Sparc, and Solaris 11 Sparc. Our test matrix is getting fairly large at this point as we include all the necessary instances of Windows, Linux, FreeBSD, and Solaris.
We are investigating support of Solaris 8 and 9 in branded zones. This a bit of a stretch. We know that. Everyone should be off Solaris 8 by now, no doubt. But, it’s sort of like what Sir Edmund Hillary said of climbing Mt Everest: because it’s there. We want to know if it’s possible. Stay tuned. For those of you scoffing at why we would even consider Solaris 8 and 9, chances are you will be vindicated. For those of you who share my curiosity in the matter, we’ll let you know the why and wherefore.
Vagaries of Solaris
We were a bit surprised by the fact that the detailed OS services we use were actually pretty consistent across Solaris platforms. It’s been a few years since I dabbled with Solaris. It was quite refreshing to see what has been done with Solaris 11.
Many of the open source libraries that are the basis of application stacks in a Linux world are readily available in Solaris 11. Our list includes things like curl, libcurl, libz and openssl. A pleasant surprise. Not the case with Solaris 10, but that’s to be expected.
The biggest surprise we ran into was the use of atomic functions for 32 bit Sparc. Where possible, we have been using the intrinsic functions provided by gcc. These are available and work well for Solaris i386, x86_64 & 64 bit Sparc. There is no atomic cas, compare and swap, for 32 bit Sparc. Apparently there is an issue with the instruction set for 32 bit Sparc. The gcc people just decided to not implement this. There is a native atomic cas provided by Solaris that works for 32 bit Sparc.
We were a bit mystified by curl on Solaris 10 Sparc. It seems pretty silly; http://curl.haxx.se/mail/lib-2008-09/0051.html. The net effect is you end up building from source a 32 bit and a 64 bit curl. Not an issue on Solaris 11 Sparc. While it’s an annoyance, it’s not a show stopper.
As you would expect, we did the bulk of our development on Solaris 10 & 11 x86 using VMs. For whatever it’s worth, we never did get Parallels to create a VM using Solaris. We had to use VMware.
We tested on Sparc hardware using a customer’s servers. While this causes a bit of trepidation because we are on someone else’s server doing testing, it actually worked quite well.
We don’t have plans to install Sparc hardware any time soon. We plan to do support using Sparc hardware from the people who have the servers and the need for the information. Is this feasible? We would like to hear from you on this topic. Is it a workable approach?
As you can probably guess, the next platform is AIX. We are serious in our quest for complete IT operational data. That includes all data from all platforms. We’d like to hear from you. Let us know what you think.
And, if you’re a Solaris user and want to try our Solaris collector in beta, sign up for our Beta program and we’ll follow up with a custom installer for you.