Skip to content

Zones: Not just for geeks

November 19, 2004

The server consolidation pendulum seems swings back and forth from large consolidated (SMP) architectures to single blade CPUs racked and stacked to the sky. Inevitably, the momentum always seems to come back to the form factor of:

one project == one (or more) servers

Why? Consolidation sounds wonderful in practice – but there a lot of operational issues that come in to play. Consolidated environments require monumental planning for change control. You need to gain agreement with all of the communities that share the server. Not all of them will want the change, or see it as desirable (“the last time you guys upgraded you broke my database”). Much politiking and calls to directors will ensue when one group threatens to block the change, or another insists they can’t meet their schedule without it.

Access to consolidated environments also needs to be tightly controlled due to high risk of having all your eggs in one basket. Limited root access sounds like a good thing (TM) but it is often necessary to give out administrative access to a system in order let some SME install a complex piece of software. Often the policy of “no project root access” is relaxed when it becomes expedient.

And finally, some software products don’t easily co-exist in a consolidated environment. You may need to install multiple versions of a product to support a legacy environment.

For these reasons, many organizations lean towards providing isolated server environments for each project. This makes the developers happy (they have their own sandbox to play in), but makes the folks who sign the cheques rather peeved (you are telling me I have 2 floors of rack mounted servers, running at 5% utilization, and I need to buy more?)

Zones provide nice lightweight alternative to over consolidated environments that keep us geeks happy (we each get our own sandbox), and make the accountants ecstatic (you mean I dont need to buy another box? )?

Some of the practical beneifits:

  • They provide administrative isolation: Each project can be given full access to thier own zone. The project manager is happy (they can use their own resources to install software), and the UNIX admins can sleep at night knowing the developers can only mess up their own environment 🙂
  • Supporting multiple releases or instances becomes simple. Zones are easy to create – so there is no reason why a project group can’t have dozens of instances ( for dev, qa, individual developer sandboxes, etc.).
  • When people start to trust the technology to provide true isolation, they don’t mind sharing the server with other groups. Utilization goes up

There are so many cool things in Solaris 10, but I think customers are going to find zones as the big ticket item. This will really change the way people think about deploying services.

Comments are closed.

%d bloggers like this: