I've relocated this post from my 360.yahoo.com page to here so I can keep all this stuff in one place.
As long as I'm rambling about grid computing, Solaris 10 and Veritas, I want to put this into print. I have this vision floating in my head and I need to start writing it down so I can mold it and shape it into something real when the technologies mature.
The Dev environment:
So, my ideal for Veritas, grid and Solaris 10 (or 11, 12, what ever it ends up being supported in) is to have, a say, three node 4 socket, 2 (or more) core cluster with a crap load of ram for development. It would run Veritas’ next generation cluster. It’s dependant on that to do some of the neat stuff I’d like to do. It would be attached to the SAN and containers would be built and developed on these two. You have three nodes so you can test OS and veritas patches on one node and still have a ‘grid’ on the other two. You pile the environments on these two boxes. Over subscribe the CPU’s like crazy. And over subscribe the ram a bit too, but that can be detrimental, especially considering RAM size to price. By using the VCS-NGC you can move a zone from box to box ‘live’. That’s right; I believe Veritas will have the ability to migrate a zone, state and all, between two hosts. They already demoed the ability to move a running PeopleSoft environment between hosts. The pieces are there. N1 or Grid should only serve to make this even easier. Now you can do neat stuff with resource allocation. You can move ‘idle’ dev zones around to maximize CPU (which is why you over-subscribe them). You can move everybody off of some boxes to do some performance testing. The posiblities are endless. VMWare already has the ability to vmotion VM’s between ESX servers. This isn’t anything new, just can’t quite be done in Sun land yet. Anyway, back to the life cycle. At some point, a 'golden master' is built. It could simply be a direct copy of the dev container, or it could be a separate build. Doesn't really matter really, it's more dependant on how the dev shop works. But a release is cut, tagged, branched, what ever you want to call it. An in-array copy is made of this environment (BCV, snapclone, shadow copy, flash snap, call it what you want). Promote that copy to the test environment.
The test environment:
Test is a scaled back version of dev, but it’s still a clustere/grid type environment. you should test the HA features of the grid/zone/container away. So the BCV is copied onto the test environment. You could simply use the BCV volumes, or you could copy down to ‘real storage’ to get a better performance picture. It depends on your testing philosophy really. Me, I plunk it back down to real storage. The environment doesn’t need to be too big because you never have as many testers as you have developers working at the same time. The release is passed! YAY! Now we BCV it again, TWICE! One goes to the training environment (We all have those right???), the other becomes the container that will become production.
On to production:
Here’s where I’m fuzzy on what to do. Ideally, I would love to contract this part out to a ‘grid service provider.’ I simply need a way to get my ‘zone’ onto the grid via some fat pipe between my shop and the provider. I’m not all that psyched about just turning it over to someone I don’t even know however, so maybe the production grid is in house. I go back and forth on this a lot. Depends on how many problems I’ve had with our production environment I guess. If our prod is giving me fits, then I say ‘outsource the whole shit-can!’ but then I read an article about lax security in hiring or how cleaning crews have basically unlimited access to buildings and think twice (that’s going to be a subject for another time… ‘if I were a corporate spy…’). Anyway, the big thing for me, is the entire environment gets promoted the entire way. Not just the code, or the directory tree, but the entire thing. No need to worry about missing libraries. No more forgotten /etc/system parameters (well there aren’t many of those that are left anymore, but you get the idea). The process also goes full circle. The production environment is still in dev! How easy is it to test upgrades?
This idea will work today with today’s shipping tech by the way. If a zone is created on a discrete, clone-able volume on the array, there’s nothing stopping you from doing this today. You have to do some things by hand, and it has to go offline to switch boxes in dev, but you can do it all. In fact, you really only need Solaris 10 I guess. But I’m a veritas fan-boy so I’m not going to consider that option. I mean I can walk the 10 miles to work rather than drive, but I don’t. The car (and for Solaris boxes Veritas products) is a more elegant solution. I’ll get there at some point. That’s really the whole point of this blog I guess. How do I get there from here (Solaris 8, tarring dirs between hosts, dev, test and prod not matching at all…)? And how do I keep track of how I did get there.
Anyway, I’ve rambled enough. Hopefully I can circle back and make these fragments into a more cohesive and realistic plan.
Tags:
Solaris Sun containers grid computing
