Slashdot Mirror
The Rise of the Programmable Data Center
As data centers become more common and more advanced, there's been a movement to automate and consolidate control of data center components, and an industry is starting to grow around it.
"While VMware pushes a programmable data model based on its technologies, vendors such as Puppet Labs are making the case for a more platform-neutral approach. Puppet Labs has developed a declarative language for configuring systems that can be extended across the data center: the organization recently announced the creation of an open source project in conjunction with EMC, called Razor, to accomplish that goal.
There’s already open source project known as Chef, created by Opscode, with a similar set of goals. In a similar vein, Reflex Systems, a provider of virtualization management tools, is trying to drum interest in VQL, a query language that the company specifically developed for IT pros."
Is it just me or is this literal nonsense?
All data centers are made out of inherently programmable machines. In fact, the vast majority run at least a little custom code. What's the alternative to a "programmable" data center? A finite state data center? The article itself doesn't really justify the term either. "We use virtualization to make data centers more managable." Really? Welcome to the 2007. "Holistic administration"? We use pink crystals to lower disk fragmentation.
Maybe I'm just old now. I was afraid of that.
The article isn't very good, but I think it boils down to "infrastructre as code", whereby all of your infrustructre is definable through software. It has many advantages, including repeatability and version control. The idea has been around for a long time, but it is only now gaining traction.
aka Skynet.
You can keep posting it, but unfortunately I think most of the slashdot audience has no interest in content that actually originates from slashdot. If these were actual in-depth analyses and not just lightweight sponsored PR fluff - you'd possibly get more interest. For the most part, though, it feels like a strained and artificial attempt at pushing advertisements as tech content.
I understand there needs to be a monetization strategy, but you don't want to pick one that's likely to drive away the people you're trying to sell to.
OT? Possibly, though I'd argue that I'm on-topic of the larger issue when it comes to these posts.
Yeah, SMI-S was supposed to save us from vendor tool lockin for the storage sector, never happened. The SMI-S layers are so complex and the API so flexible that by the time a third party can understand how to control the product via SMI-S the array is either obsolete or the internal management piece has changed enough that the effort is worthless.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
"datacenter" once had a reasonably well-defined meaning: a physical location where computers were maintained. but in the context of this article, it has come to mean "the entiity of what is _in_ the machineroom, and everything about how everything works".
for instance, to me, a datacenter consists of one or a couple of HPC clusters. each cluster is fairly standalone (though possibly with shared filesystems, etc). there's not a lot of reconfiguration to do: I don't want anything reprovisioned, because every node in a cluster simply boots the same NFS-root image. (statefull installs of clusters are so 1995...)
to amazon, a datacenter is a vast army of VM-hosting nodes (not unlike my HPC nodes), with S3-like storage infrastructure. of course, the latter takes the form of a cluster, really, which also does not want to be reprovisioned all the time. sure, adding some nodes, but the new nodes need to become as much like the old nodes as possible.
VMware seems to be pushing this as a way to grow their already prodigious lock-in. people whose brains have been sucked into the VMware way of thinking really seem to like a single console for controlling all provisioning. extending from provisioning a set of VM hosts to datacenter-wide provisioning is mainly just about switch management, routing design, etc. technically, nothing is gained, but the appeal of a single ring to rule them all - well, we know where that leads.
I once took a look at puppet and cfg...it seems to me that both required root or a process running with root capabilities on ALL boxes that they controlled. There is some SERIOUS danger running ONE script on all of your servers. These "automation" tools have cute ways of trying to avoid this...but, ultimately you are running an automated script on all of your boxes. Not always a "pleasant" feeling ;-) (You can run the script on just a few servers at a time...it just prolongs the agony of running a script as root on your servers ;-)
How does this differ from running OpsWare or BladeLogic and installing agents on all servers in the DC? That's how I've been doing it at last couple jobs.
Indeed.
Unless mandated by some requirement, infrastructure documentation gets out of date really damn fast. Would be cool if the equiptment itself could some how blast out info that was more tied in the physical realm (racks being aware of whats plugged into it's slots, power cables knowing where they go, etc..) but that comes into the realm of "you'll have 10 standards in half a year, and most vendors won't support any of them".
Every data center component that interacts with another component, be it a cable, disk, some firmware, an OS, a CPU, a DIMM, switch, PDU, etc., has a management/operational burden. It's actually worse than that, because every distinct implementation of a component is likely to have quirks that require special attention. So, there is another multiplier in that equation.
It can be very hard to offload this burden. Ideally, it is somebody else's problem, they make a integrated solution at a competitive price and you don't have to spend your life scripting around basic issues like inventory management, firmware updates, IP address reassignments, etc.
One of the best tools are the various virtualization platforms. Once you get that software layer up and running, you can generally treat all instances in the same way and then you can have uniform management above that line.
HW is more difficult. My experience with IBM, HP, and Dell may be out of date, and my Cisco experience is from inside Cisco, so this may sound like an advert. But you really owe it to yourself to take a good look at Cisco UCS. It was designed for automated management. HW discovery, FW updates and server identities (WWN, MAC, GUIDs) are all managed through CLI, GUI, and/or XML-based APIs. Time from breaking the shipping box open to having a server in production is minimal. Lot's of things that ordinarily waste time, cabling, power, and patience just work. And if you wind up not liking it, you can always replace it with something else that runs all of the interesting OSs while consuming and producing lots of storage and network packets.
[disclamer: I didn't promise you anything here, I just encouraged you to consider some options]