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?)
Posted by geoff2 at December 22, 2004 10:56 AMYou are bring up something I had been thinking about for roughly a couple of years ago when I first ran across Zones documentation.
Here's my take. Your abstract question of "how does all this work together" is a good one. A vast majority of the packaged applications should work fine in a zone. Those packages that want to touch the kernel (like a firewall) won't work. The model for SamFS/QFS is configure them in the global zone and present them to (and mount them in) the local zone.
Yes, the administrative models do change somewhat, but not in a way that will put a heavy burden on the admin. In fact, by consolidating servers and services, the admin's life will get easier. For example, OS patches and backups should occur in the global zone, completely taking that responsibility away from the local admin. Cool.
There is going to be a lot of learning going on by the customers and by Sun as we learn how our customers want to use zones. For example, customers really want to put zone "filesystems" on NFS to failover zones between hardware nodes. Can't do that yet.
Posted by: John Clingan at December 22, 2004 10:42 PM