One of the
joys problems with all of this cool stuff that we have at Sun is figuring out how it all fits together… or doesn’t. Case in point: I was reading John Clingan’s piece about Zones on an E25K, and I started to think about how one might use such a beast. Suppose one was running a horizontally-scaled load-balanced Sun Java System Application Server Enterprise Edition 7 2004Q2 (surely there must be a simpler name) configuration on a cluster of V880s. Can I rehost this in a collection of zones on an E25K? What works? What breaks? How much of my administrative model carries over, and how much has to change? (Everybody talks about ABI compatibility, but compatibility of administrative models is just as important. It’s one of the major issues with Linux today, and it’s bound to affect how we run Linux apps in Solaris x86.)
And that got me thinking about clustered data bases (we use the Clustra technology to support App Server failover), and from that to storage and file systems. (I’m an old NFS guy.) One of Sun’s hidden gems is QFS (OK lawyers, Sun StorEdge QFS software), a massively scalable high performance file system. Although designed for (and mostly used in) high performance technical computing, it’s getting a lot of attention in other applications, due in part to the symbiosis with SAM-FS (Sun StorEdge SAM-FS software), a policy-based archiving system. (Think SarbOx. Think Infinite Mailbox.) Do QFS and SAM-FS work in zones? I turn to the on-line documentation: Solaris Containers-Resource Management and Solaris Zones: “Mounting File Systems in Zones: Options for mounting file systems in non-global zones are described in the following table. Procedures for these mounting alternatives are provided in Configuring, Verifying, and Committing a Zone and Mounting File Systems in Running Non-Global Zones.” Followed by a long table, which doesn’t include SAM-FS or QFS. Hmmm. Can’t tell from this. More reading required, I guess. And so it goes.
There’s nothing wrong with this. It’s just an inevitable combinatorial explosion, exacerbated by our commitment to preserve backward compatibility. (In other words, you can never take a feature out of Solaris.) The challenge is in managing unrealistic expectations. (It isn’t all going to work together seamlessly from day one; in fact some combinations may never work together. It all depends on the business case.) The upside lies in the opportunities for serendipitous synergy. (Or should that be synergistic serendipity?)